Chiffrement : ce qu’il protège vraiment, et ce qu’il ne protège pas

« Les données sont chiffrées » est la réponse la plus fréquente aux questionnaires sécurité, et l’une des moins informatives. Chiffrées où, contre qui, et qui détient les clés ?

Le chiffrement en transit

Il protège les données pendant leur circulation sur un réseau. C’est aujourd’hui la norme, y compris en interne.

Contre quoi il protège : l’écoute passive sur le réseau, l’interception sur un réseau non maîtrisé.

Contre quoi il ne protège pas : tout ce qui se passe aux extrémités. Un poste compromis voit les données en clair avant chiffrement et après déchiffrement. Un serveur compromis aussi.

C’est pourquoi une attaque par hameçonnage n’est en rien gênée par le fait que la messagerie soit chiffrée en transit.

Le chiffrement au repos

Il protège les données stockées : disques, bases, sauvegardes.

Contre quoi il protège : le vol physique d’un support — portable perdu, disque sorti d’un serveur, bande de sauvegarde égarée. C’est aussi ce qui évite qu’un matériel réformé devienne une fuite.

Contre quoi il ne protège pas : un attaquant qui accède au système en fonctionnement. Sur une machine allumée, le déchiffrement est transparent : un compte disposant des droits lit les données en clair, chiffrement ou non.

C’est le malentendu le plus coûteux. Un chiffrement de disque n’a aucun effet contre un rançongiciel qui s’exécute avec des privilèges sur la machine.

Le chiffrement de bout en bout

Les données sont chiffrées chez l’émetteur et déchiffrées chez le destinataire, l’intermédiaire n’ayant jamais accès au contenu.

Ce qu’il change : le prestataire qui héberge ne peut pas lire. C’est le seul modèle qui protège réellement contre le fournisseur lui-même, ou contre une réquisition le visant.

Ce qu’il coûte : beaucoup de fonctions deviennent impossibles — recherche côté serveur, analyse antivirale, prévention des fuites, récupération en cas de perte de clé. Ce n’est pas un défaut : c’est la contrepartie.

Le vrai sujet : les clés

Un système de chiffrement vaut ce que vaut sa gestion de clés. Trois questions déterminent tout :

• Qui détient les clés ? Si c’est votre fournisseur cloud, il peut techniquement accéder aux données. Voir la responsabilité partagée.
• Où sont-elles stockées ? Une clé sur le même serveur que les données chiffrées n’apporte presque rien.
• Que se passe-t-il si on les perd ? Sans séquestre, les données sont définitivement perdues. C’est un risque de disponibilité, exigé par l’article 32 du RGPD.

Le cycle de vie complet — génération, distribution, stockage, rotation, révocation, destruction — fait l’objet de la mesure 8.24 d’ISO/IEC 27002:2022.

Ce que la réglementation en attend

Le RGPD cite le chiffrement à l’article 32 comme mesure appropriée, sans l’imposer. Son intérêt est double : il réduit le risque, et il peut dispenser d’informer les personnes concernées en cas de violation lorsque les données sont rendues incompréhensibles.

Attention à la portée : cette dispense suppose que les clés n’aient pas été compromises. Dans une intrusion avec privilèges, c’est rarement le cas.

L’article 21 de NIS 2 mentionne également le recours à la cryptographie parmi les mesures attendues.

Ce qu’il faut vérifier chez vous

1. Les postes nomades sont-ils chiffrés, et le déchiffrement demande-t-il une authentification distincte du système ?
2. Les sauvegardes sont-elles chiffrées, et où sont les clés ?
3. Les flux d’administration sont-ils chiffrés, y compris en interne ?
4. Qui, dans l’organisation, peut accéder aux clés ? Est-ce tracé ?
5. Existe-t-il une procédure de séquestre et de récupération testée ?

La cinquième question est celle qui met le plus souvent en difficulté.

Sources

• ISO/IEC 27002:2022, mesure 8.24 — utilisation de la cryptographie
• Règlement (UE) 2016/679 (RGPD), articles 32 et 34
• ANSSI — guides de sélection d’algorithmes cryptographiques

Aller plus loin

Ces vérifications font partie de l’audit 360. L’articulation avec les exigences réglementaires relève de la gouvernance, risques et conformité.