Logo

Livre blanc sur la sécurité et la confidentialité (présentation)Chapitre 4

Chapitre 4 Authentification, autorisation et contrôle d'accès

Ce chapitre définit le modèle d'identité de FileBolt, les couches de jetons et les frontières du contrôle d'accès. L'envoi et le téléchargement utilisent des jetons d'accès de courte durée (sessions côté serveur, par consultation, expirables, à portée limitée) pour contrôler l'accès au texte chiffré et au manifeste. Les actions de gestion de l'expéditeur utilisent des jetons de connexion de longue durée stockés sur le client. Le système DOIT prendre en charge la révocation, et les données d'audit DOIVENT être visibles uniquement par l'expéditeur.

4.0 Résumé

  • Jeton d'accès de courte durée : contrôle l'accès au texte chiffré et au manifeste ; session côté serveur (consultation) ; DOIT être lié au transferId ; DOIT avoir une portée limitée ; DOIT expirer.
  • Jeton de connexion de longue durée : utilisé pour la gestion par l'expéditeur (suppression/révocation/audit) ; stocké sur le client ; NE DOIT PAS être utilisé par les destinataires pour accéder au texte chiffré.
  • Séparation des clés et de l'autorisation : les jetons ne contrôlent que l'accès au texte chiffré ; la capacité de déchiffrement provient de la CEK placée dans le fragment d'URL (voir le chapitre 5).

4.1 Modèle d'identité

  • Le système prend en charge un modèle d'identité d'utilisateur payant pour la gestion par l'expéditeur.
  • La connexion de l'expéditeur PEUT utiliser un lien magique à usage unique ; le client stocke un jeton de connexion de longue durée après une authentification réussie.
  • Les destinataires n'ont pas besoin de compte pour les téléchargements par défaut (voir la documentation UX) ; l'accès est contrôlé par le lien/le jeton.

4.2 Modèle d'autorisation et couches de jetons

Deux types de jetons sont utilisés, avec une séparation stricte des responsabilités :

  1. Jeton d'accès de courte durée (session / consultation) : pour l'envoi/le téléchargement du texte chiffré et la lecture du manifeste ; DOIT être lié au transferId ; DOIT expirer ; DOIT avoir une portée limitée par opération.
  2. Jeton de connexion de longue durée : pour les actions de gestion par l'expéditeur ; NE DOIT PAS accorder de capacité de déchiffrement.

4.2.2 Exemples de portées

  • upload_chunk : envoyer des blocs de texte chiffré pour un transferId donné.
  • read_manifest : lire le manifeste d'un transferId donné.
  • download_chunk : télécharger des blocs de texte chiffré pour un transferId donné.

4.3 Autorisation d'envoi

  • Les API d'envoi DOIVENT valider la portée du jeton et son lien avec le transferId avant d'accepter du texte chiffré.
  • Les envois de blocs DEVRAIENT être idempotents par (transferId, fileId, chunkIndex).
  • En cas de jeton invalide ou de non-concordance, le système DOIT refuser l'accès par défaut (fail closed).

4.4 Autorisation de téléchargement

  • L'accès au manifeste et au texte chiffré DOIT exiger un jeton valide et à portée limitée ; les jetons DOIVENT être limités dans le temps.
  • Les destinataires NE DOIVENT PAS pouvoir énumérer d'autres transferts ni accéder à des blocs en dehors du transferId auquel le jeton est lié.
  • La limitation de débit PEUT être appliquée pour prévenir les abus (voir le chapitre 7) sans empêcher la reprise des transferts.

4.5 Révocation et invalidation anticipée

  • Les expéditeurs DOIVENT pouvoir révoquer un transfert ; la révocation DOIT rendre les jetons inutilisables pour tout accès ultérieur.
  • La révocation DEVRAIT déclencher un nettoyage/une accélération du TTL du texte chiffré lorsque c'est possible.
  • L'UX du destinataire DOIT indiquer clairement l'état révoqué/expiré et la marche à suivre (contacter l'expéditeur).

4.6 Audit et isolation des permissions

  • Les preuves de livraison (téléchargements, compteurs) DOIVENT être visibles uniquement par l'expéditeur par défaut.
  • Les API d'audit DOIVENT exiger l'authentification de l'expéditeur et DOIVENT être isolées des jetons d'accès des destinataires.

4.7 Journalisation et minimisation des données sensibles

  • Les journaux NE DOIVENT PAS contenir de fragments d'URL, de CEK ni d'éléments permettant de dériver une clé.
  • Les journaux DEVRAIENT minimiser les données personnelles et se concentrer sur les événements pertinents pour la sécurité (échecs de jeton, révocation, limites de débit).
  • Les messages d'erreur DOIVENT être exploitables mais ne doivent pas divulguer de secrets.

4.8 Identifiants d'affirmation associés