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 limites du contrôle d'accès. Le chargement et le téléchargement utilisent des jetons d'accès de courte durée (sessions côté serveur, basées sur la recherche, expirant, étendues) pour contrôler le texte chiffré et l'accès au manifeste. Les actions de gestion des expéditeurs 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 : portes d'accès au texte chiffré/manifeste ; session côté serveur (recherche) ; DOIT se lier à transferId ; DOIT avoir une portée ; DOIT expirer.
  • Jeton de connexion longue durée : utilisé pour la gestion des expéditeurs (supprimer/révoquer/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 autorisation : les jetons contrôlent uniquement l'accès au texte chiffré ; la capacité de déchiffrement provient du CEK dans le fragment d'URL (voir 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 des expéditeurs.
  • La connexion de l'expéditeur PEUT utiliser un lien magique unique ; le client stocke un jeton de connexion de longue durée après une authentification réussie.
  • Les destinataires ne sont pas tenus d'avoir un compte pour les téléchargements par défaut (voir la documentation UX) ; l'accès est contrôlé par lien/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/recherche) : pour le téléchargement/téléchargement du texte chiffré et de la lecture du manifeste ; DOIT se lier à transferId ; DOIT expirer ; DOIT être limité par opération.
  2. Jeton de connexion longue durée : pour les actions de gestion des expéditeurs ; NE DOIT PAS accorder la capacité de déchiffrement.

4.2.2 Exemples de portée

  • upload_chunk: téléchargez des fragments de texte chiffré pour un transferId spécifique.
  • read_manifest: lire le manifeste pour un transferId spécifique.
  • download_chunk: téléchargez des fragments de texte chiffré pour un transferId spécifique.

4.3 Autorisation de téléchargement

  • Les API de téléchargement DOIVENT valider la portée du jeton et la liaison transferId avant d’accepter le texte chiffré.
  • Les téléchargements de fragments DEVRAIENT être idempotents selon (transferId, fileId, chunkIndex).
  • En cas de jeton invalide ou de disparité, le système DOIT échouer en cas de fermeture.

4.4 Autorisation de téléchargement

  • L’accès au manifeste et au texte chiffré DOIT nécessiter un jeton valide et étendu ; les jetons DOIVENT être limités dans le temps.
  • Les destinataires NE DOIVENT PAS être capables d’énumérer d’autres transferts ou d’accéder à des fragments en dehors de l’ID de transfert lié.
  • La limitation du débit PEUT être appliquée pour la prévention des abus (voir chapitre 7) sans interrompre la possibilité de reprise.

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 un accès ultérieur.
  • La révocation DEVRAIT déclencher un nettoyage/une accélération TTL pour le texte chiffré lorsque cela est possible.
  • L'UX du destinataire DOIT indiquer clairement le statut révoqué/expiré et l'étape suivante (contacter l'expéditeur).

4.6 Isolement des audits et des autorisations

  • Les preuves de livraison (téléchargements, décomptes) DOIVENT être visibles par l'expéditeur uniquement 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 du destinataire.

4.7 Journalisation et minimisation des données sensibles

  • Les journaux NE DOIVENT PAS contenir de fragments d'URL, de CEK ou de matériel de clé dérivée.
  • Les journaux DEVRAIENT minimiser les données personnelles et se concentrer sur les événements liés à la sécurité (échecs de jetons, révocation, limites de débit).
  • Les messages d'erreur DOIVENT être exploitables mais ne doivent pas divulguer de secrets.

4.8 ID de réclamation associés