Partage de fichiers zéro confiance : ne faites confiance à personne
Appliquez les principes de sécurité zéro confiance au partage de fichiers. Pourquoi considérer chaque réseau comme hostile mène à un meilleur chiffrement.
Le partage de fichiers zéro confiance part du principe que le réseau est hostile, le serveur est compromis, et l'appareil du destinataire peut être infecté — puis chiffre en conséquence. Les fichiers sont chiffrés dans le navigateur de l'expéditeur avec AES-256-GCM avant qu'un seul octet ne transite, les clés dérivent d'un mot de passe plus un sel stocké dans le fragment URL, et le serveur ne manipule que du texte chiffré opaque. C'est le modèle opérationnel codifié dans NIST SP 800-207 appliqué au transfert de fichiers : vérifiez explicitement, accordez le moindre privilège, et supposez une violation à chaque couche.
Les trois hypothèses qui guident la conception
La zéro confiance commence par trois prémisses. Premièrement, le transport est compromis — les proxies d'entreprise font l'inspection TLS, le Wi-Fi de café fait de l'ARP spoofing, et des écoutes de backbone par des États-nations existent (documentées par Snowden en 2013, toujours opérationnelles selon les reportages Bloomberg de 2024). Deuxièmement, le serveur est compromis — les fournisseurs cloud sont violés (AWS en 2019, Microsoft en 2023), les administrateurs peuvent mal tourner, et les réquisitions judiciaires arrivent discrètement. Troisièmement, l'appareil du destinataire peut être infecté — un employé tourne sur un Chrome obsolète, un malware récolte les fichiers déchiffrés. Chaque décision de conception découle de ces trois hypothèses.
Le chiffrement côté client comme premier principe
Si le serveur peut voir le texte en clair, ce n'est pas de la zéro confiance. Tout commence par le navigateur de l'expéditeur exécutant la Web Crypto API : générer une clé de 256 bits, la dériver du mot de passe utilisateur avec PBKDF2 à 600 000 itérations, chiffrer le fichier avec AES-256-GCM, et seulement alors streamer le texte chiffré vers le serveur. Firefox Send a prouvé que cela fonctionnait à l'échelle grand public avant que Mozilla l'arrête en 2020. Les successeurs modernes — HexaTransfer, Wormhole, Skiff — reprennent le schéma. Le serveur tient des octets qu'il ne peut pas lire.
Le matériel de clé ne quitte jamais les terminaux
La clé de déchiffrement doit atteindre le destinataire sans toucher le serveur. Deux mécanismes fonctionnent. Premièrement, l'astuce du fragment URL : la clé vit après # dans l'URL de téléchargement, que les navigateurs n'envoient jamais dans les requêtes HTTP. Deuxièmement, les clés dérivées d'un mot de passe : l'expéditeur communique un mot de passe au destinataire par un canal séparé (Signal, appel téléphonique, Psst! de 1Password), et le navigateur du destinataire redérive la clé. Les deux maintiennent le matériel de clé hors des journaux serveur, des caches CDN et des sauvegardes de base de données — ce qui compte quand la violation inévitable survient.
Vérifier le code qui s'exécute dans le navigateur
La zéro confiance côté client est plus difficile que côté serveur parce que le serveur expédie le JavaScript qui fait le chiffrement. Un serveur malveillant pourrait pousser un bundle backdooré à un utilisateur ciblé. Mitigations : publier les hashes SHA-384 de chaque version, les signer avec Sigstore ou une clé PGP d'entreprise, et encourager les utilisateurs avancés à vérifier avec des extensions navigateur comme Code Verify (Meta l'expédie pour WhatsApp Web). Les en-têtes CSP avec script-src 'self' et Subresource Integrity bloquent l'injection depuis des CDN compromis. Rien de tout cela n'est parfait, mais ça réduit la surface d'attaque.
Authentification sans secrets partagés stockés au repos
Les mots de passe envoyés par email et stockés dans des bases de données serveur sont l'antithèse de la zéro confiance. Remplacez-les par des passkeys WebAuthn liées à l'appareil du destinataire — la clé privée ne quitte jamais le Secure Enclave, et le serveur ne stocke que la clé publique. Pour les transferts ponctuels, utilisez OPAQUE (RFC 9380) pour une authentification par mot de passe qui ne transmet ni ne stocke jamais le mot de passe côté serveur. Les liens magiques envoyés à des adresses email pré-vérifiées offrent un chemin intermédiaire : l'entropie du token (128 bits) remplace le besoin d'un secret stocké.
Segmenter les transferts par sensibilité
Tous les fichiers ne méritent pas les mêmes contrôles. Un service de partage de fichiers zéro confiance devrait laisser les expéditeurs classer leurs envois : public (sans mot de passe, expiration 7 jours), interne (mot de passe, expiration 48 heures), confidentiel (mot de passe + 2FA, expiration 4 heures, téléchargement unique), restreint (passkey + liaison IP + expiration 15 minutes). Automatisez la classification par type de fichier quand c'est possible : .pdf déclaration fiscale → confidentiel ; .docx contrats → interne ; .psd maquettes marketing → public. NIST SP 800-171 appelle cela la gestion des informations non classifiées contrôlées, et cela s'applique naturellement aux flux de transfert.
Traiter l'appareil du destinataire comme non fiable
Une fois que Bob déchiffre le mémo juridique de 5 Mo d'Alice, il se retrouve dans son dossier Téléchargements. Si son ordinateur portable est compromis, le fichier fuit. La réflexion zéro confiance s'étend ici : encouragez les destinataires à déchiffrer vers un stockage éphémère (Tails OS, une session invité Chrome OS), évitez de déchiffrer sur des machines partagées, et effacez agressivement après usage. Pour les transferts à enjeux élevés, utilisez des visionneuses protégées qui déchiffrent dans un onglet de navigateur bac à sable et empêchent le téléchargement — le destinataire voit le .pdf mais n'obtient jamais les octets sur disque. Évidemment c'est un compromis en UX ; réservez-le au niveau le plus élevé.
Journaliser sans devenir un système de surveillance
Un journal d'audit zéro confiance journalise ce qu'il doit pour la réponse aux incidents et la conformité, rien de plus. Hachez les adresses IP quotidiennement, stockez uniquement les familles User-Agent (pas les chaînes complètes), ne journalisez jamais les mots de passe ou les clés, et conservez pendant la période minimale que chaque réglementation exige — 90 jours pour le RGPD Article 30, 6 ans pour HIPAA 164.316. Le journal lui-même vit sur du stockage en ajout seul (S3 Object Lock, mode compliance) pour qu'un administrateur compromis ne puisse pas couvrir ses traces. Publier des racines Merkle quotidiennement sur un tableau d'affichage public ajoute une vérification externe.
Là où la zéro confiance rencontre la réalité juridique
La zéro confiance ne vous exempte pas des demandes des forces de l'ordre. Elle change ce que vous pouvez remettre — du texte chiffré que vous ne pouvez pas déchiffrer, des hashes IP que vous ne pouvez pas inverser, des journaux de qui a accédé à quel slug. C'est généralement suffisant pour satisfaire un mandat valide tout en gardant les données des utilisateurs privées de la surveillance de masse. Publiez un rapport de transparence (à l'ancien modèle de Twitter) montrant les volumes de demandes et les taux de réponse. Documentez votre minimisation des données dans la politique de confidentialité pour que les utilisateurs comprennent les compromis : vous pouvez vérifier qu'un fichier a été transféré, mais vous ne pouvez pas le lire ni identifier le destinataire avec certitude.
Essayez sur hexatransfer.com — gratuit, sans compte, jusqu'à 10 Go.
Envoyez vos fichiers volumineux en toute sécurité avec le chiffrement de bout en bout
Transférez des fichiers jusqu'à 10 Go gratuitement avec le chiffrement de bout en bout. Aucun compte requis. Vos fichiers sont chiffrés dans votre navigateur avant l'envoi — personne d'autre ne peut les lire.
Envoyer un fichier