Gestion des clés de chiffrement : qui contrôle vraiment l'accès à vos fichiers
Imaginez que votre cloud est un coffre-fort dans une banque. Le chiffrement AES-256, c’est l’épaisseur du blindage. Très bien. Mais la seule question qui compte, c’est : qui a la clé du coffre ? Si c’est la banque, elle peut l’ouvrir quand elle veut (ou quand un juge le lui demande). Si c’est vous, la banque ne peut même pas vérifier ce qu’il y a dedans. Cette analogie résume tout le débat sur la gestion des clés de chiffrement dans le cloud. Et si vous arrivez depuis la page sur la sécurité et le chiffrement cloud, vous savez que cette question est plus importante que l’algorithme utilisé. L’ENISA le confirme : la gestion des clés est le point de défaillance le plus fréquent dans les architectures cloud.
La réponse directe : il existe trois modèles de gestion des clés dans le cloud – clés gérées par le fournisseur (le défaut partout), clés apportées par le client (BYOK), et clés dérivées côté client (zero-knowledge). Chacun offre un niveau de contrôle différent, et chacun a des compromis fonctionnels que les commerciaux préfèrent ne pas mentionner.
Trois modèles, trois niveaux de contrôle
Modèle 1 : clés gérées par le fournisseur. C’est le défaut sur Google Drive, OneDrive, Dropbox, et kDrive en configuration standard. Le fournisseur génère la clé, la stocke dans son infrastructure (souvent dans un service dédié comme AWS KMS ou Google Cloud KMS), et l’utilise pour chiffrer et déchiffrer vos fichiers de manière transparente. Vous ne voyez jamais la clé, vous ne savez pas où elle est, et vous ne pouvez pas la révoquer indépendamment. C’est pratique – pas de clé à gérer, pas de risque de la perdre – mais c’est aussi un acte de confiance totale envers le fournisseur.
Avantage : zéro friction. Inconvénient : le fournisseur peut techniquement accéder à vos données. Et s’il est américain, il peut y être contraint par le Cloud Act sans même vous en informer.
Modèle 2 : BYOK (Bring Your Own Key). Vous fournissez votre propre clé au fournisseur, qui l’utilise pour chiffrer vos données. Google Workspace Enterprise, AWS, Azure – tous proposent le BYOK. Le principe est séduisant : « c’est ma clé, donc je garde le contrôle ». En réalité, c’est plus nuancé. La clé est importée dans l’infrastructure du fournisseur. Elle est stockée dans un HSM (Hardware Security Module), un composant matériel certifié qui rend l’extraction théoriquement impossible. Mais la clé est utilisée par les serveurs du fournisseur pour chiffrer et déchiffrer vos données – ce qui signifie qu’elle est déchargée en mémoire à chaque opération. Le fournisseur ne « possède » pas votre clé au sens du stockage, mais il y a accès au sens opérationnel.
BYOK est une amélioration réelle pour les entreprises soumises à des réglementations spécifiques (banque, santé, défense) qui doivent pouvoir démontrer qu’elles contrôlent leur propre matériel cryptographique. Pour un indépendant ou une PME, c’est une complexité supplémentaire pour un bénéfice marginal par rapport au modèle standard.
Modèle 3 : clés côté client (zero-knowledge). La clé ne quitte jamais votre appareil. Elle est dérivée de votre mot de passe localement, via un algorithme lent et résistant au brute-force (Argon2, bcrypt, PBKDF2). Le serveur ne reçoit que des données chiffrées et ne possède aucun moyen de les déchiffrer. Tresorit, Sync.com, Proton Drive – c’est leur modèle. Et c’est le seul modèle où « le fournisseur ne peut pas lire vos données » est une affirmation mathématique, pas une promesse contractuelle.
Quand le zero-knowledge rencontre la réalité
Le modèle zero-knowledge semble idéal sur le papier. Mais comme l’explique notre page sur le zero-knowledge dans le cloud, il y a un prix : si vous perdez votre mot de passe et votre clé de récupération, vos données sont mathématiquement inaccessibles. Pas de bouton « réinitialiser ». Pas de support client miraculeux. C’est la conséquence logique d’un système où personne d’autre que vous ne peut déchiffrer quoi que ce soit.
En entreprise, ça pose un vrai problème de continuité. Si l’administrateur qui détient la clé maître quitte la société, tombe malade, ou décède, l’accès aux données de l’entreprise peut être compromis. Les solutions existent (clés de récupération déposées dans un coffre physique, partage de secret Shamir entre plusieurs administrateurs), mais elles ajoutent une couche de processus que beaucoup de PME ne sont pas prêtes à gérer.
Le chiffrement en transit et au repos utilise aussi des clés
On a tendance à penser « gestion des clés » uniquement pour le chiffrement au repos, mais le chiffrement en transit utilise aussi des clés – celles des certificats TLS. La différence, c’est que les clés TLS sont éphémères (Perfect Forward Secrecy) et négociées automatiquement à chaque connexion. Vous n’avez jamais à les gérer. Les clés de chiffrement au repos, en revanche, sont persistantes : elles doivent exister aussi longtemps que les données existent, ce qui pose des questions de rotation, de stockage sécurisé et de révocation.
La rotation des clés – le fait de remplacer périodiquement la clé de chiffrement par une nouvelle – est une bonne pratique recommandée par à peu près tous les référentiels de sécurité (NIST SP 800-57, ISO 27001). En pratique, les fournisseurs cloud qui gèrent les clés font cette rotation automatiquement (Google tourne ses clés tous les 90 jours). Avec BYOK, c’est votre responsabilité. Avec le zero-knowledge, la rotation implique de re-chiffrer toutes vos données avec la nouvelle clé – un processus lourd que peu d’utilisateurs font.
Quel modèle choisir ? Pour la plupart des utilisateurs et des PME, le modèle « clés gérées par le fournisseur » avec un fournisseur européen ou suisse (comme Infomaniak) offre le meilleur rapport sécurité/simplicité. Si votre secteur impose une traçabilité des clés (finance, santé), BYOK est le minimum réglementaire. Si vos données sont si sensibles que même votre fournisseur ne doit pas pouvoir les lire, le zero-knowledge est la seule option – mais préparez un plan de récupération des clés solide, parce que le jour où vous en aurez besoin, il sera trop tard pour l’improviser.