Chiffrement et protection des données

Le même fichier, deux risques différents

Un ingénieur support capture le trafic réseau entre une application et sa base de données pendant qu'il dépanne un problème, assis dans un café. Si cette connexion n'est pas chiffrée, cet ingénieur, ou n'importe qui d'autre sur le même Wi-Fi lançant la même capture, peut lire chaque mot de passe et chaque champ qui transite, en clair, au moment même où cela se produit.

Imaginez maintenant un tout autre moment : des mois plus tard, un disque de sauvegarde mis au rebut de cette même base de données est revendu sans avoir été effacé, et quelqu'un le branche. Si les données qu'il contenait n'ont jamais été chiffrées, cette personne les lit directement sur le disque, sans capturer le moindre paquet réseau.

Mêmes données, deux points d'attaque complètement différents, séparés de plusieurs mois. Se protéger de l'un ne protège en rien de l'autre, et c'est pour cela que les plateformes cloud traitent ces deux risques comme deux contrôles distincts : le chiffrement en transit pour les données en mouvement, et le chiffrement au repos pour les données immobiles.

Chiffrement au repos : AES-256 et le chiffrement côté serveur

Le chiffrement au repos protège les données écrites sur un support de stockage, disques, sauvegardes, fichiers de base de données, pour que quiconque accède au support physique ou logique sans autorisation ne voie qu'un texte illisible. Le mécanisme standard chez tous les grands fournisseurs cloud est AES-256, le chiffrement par bloc à 256 bits, appliqué automatiquement ou sur demande aux données au moment où elles sont écrites.

AWS appelle son approche par défaut le chiffrement côté serveur : le service de stockage chiffre lui-même les données avant de les écrire et les déchiffre à la lecture, entièrement à l'intérieur du service, à l'aide de clés gérées par un système de gestion de clés. Un client ne manipule généralement pas le chiffrement directement ; il choisit une option de gestion des clés, et le service de stockage s'occupe du reste.

Chiffrement en transit : TLS

Le chiffrement en transit protège les données pendant qu'elles se déplacent entre deux points d'un réseau, une application mobile et un serveur, un load balancer et une instance applicative, un microservice et un autre. Le mécanisme standard est TLS, Transport Layer Security, qui enveloppe une connexion pour que quiconque capture le trafic brut ne voie que du texte chiffré, jamais la requête ou la réponse elle-même.

Tous les points de terminaison de l'API AWS exigent aujourd'hui au minimum TLS 1.2, et prennent tous en charge TLS 1.3, la version plus récente et plus rapide du protocole. Cette base reflète une tendance partagée par tout le secteur : les anciennes versions de TLS, et leur prédécesseur SSL, se retirent progressivement à mesure que des faiblesses cryptographiques s'accumulent, et les recommandations actuelles ne cessent de relever le minimum accepté.

L'angle mort : les données en cours d'utilisation

Remarquez ce qu'aucune des deux protections ne couvre. Une fois qu'une requête atteint le serveur applicatif, les données doivent être déchiffrées en mémoire, brièvement, pour que l'application puisse réellement s'en servir : faire un calcul, afficher une page, vérifier une condition. Cet état en mémoire porte parfois le nom de données en cours d'utilisation, et il se situe hors de portée du chiffrement standard au repos et en transit. C'est un problème plus étroit et plus spécialisé, et c'est pour cela que « tout est chiffré partout » simplifie la réalité : le chiffrement au repos et en transit couvre l'écrasante majorité du trajet d'une requête, mais pas l'instant où l'application manipule activement les données en clair.

Gestion des clés : séparer qui peut déchiffrer de qui détient la clé

Chiffrer des données ne résout que la moitié du problème ; contrôler qui peut les déchiffrer est l'autre moitié, et c'est le rôle d'un service de gestion de clés. AWS KMS s'exécute à l'intérieur de modules matériels de sécurité (HSM) conçus pour qu'une clé en clair ne quitte jamais le module, pas même pour les employés d'AWS. Une demande de chiffrement ou de déchiffrement est autorisée indépendamment par les mêmes permissions IAM que celles de la leçon précédente, ce qui signifie que l'accès aux données et l'accès à la clé qui les déverrouille forment deux couches contrôlées séparément. Compromettre l'une ne livre pas automatiquement l'autre, et chaque utilisation d'une clé est journalisée, ce qui donne une piste d'audit exacte de quand et par qui une donnée a été déchiffrée.

La frontière : service de clés géré ou module matériel dédié

La plupart des charges de travail utilisent un service de clés géré comme AWS KMS : du matériel partagé, multi-locataire, derrière une API simple, AWS s'occupant du provisionnement, des correctifs et de la disponibilité. Certaines charges de travail, en général poussées par une exigence réglementaire précise, ont besoin d'un module matériel de sécurité dédié à la place, comme AWS CloudHSM, donnant au client un contrôle administratif direct sur du matériel mono-locataire qu'il gère seul. La règle de décision reste étroite : partez du service géré par défaut, et ne réservez le matériel dédié qu'au cas où une exigence de conformité impose spécifiquement un contrôle mono-locataire, puisque cette option échange la simplicité contre une charge de mise à l'échelle et d'administration que le client porte désormais seul.

Idée reçue : le chiffrement remplace le contrôle d'accès

Il est tentant de considérer que « tout est chiffré » clôt la conversation sur la sécurité. Ce n'est pas le cas. Le chiffrement protège les données contre quelqu'un qui vole le support de stockage ou intercepte le trafic réseau sans autorisation. Il ne fait rien contre quelqu'un qui détient déjà des identifiants valides et autorisés, qu'il s'agisse d'un employé légitime ou d'un attaquant qui en a hameçonné un, pour lire des données qu'il a le droit de consulter, parce que tout l'intérêt du chiffrement est que l'accès autorisé le déchiffre correctement. C'est exactement l'écart que les contrôles IAM de la leçon précédente existent pour combler, et les deux protections sont censées travailler ensemble, pas se substituer l'une à l'autre.

Repères d'examen : au repos ou en transit

Où cela vous mène

Le chiffrement au repos et le chiffrement en transit protègent les mêmes données à deux moments différents de leur trajet, et une conception complète a besoin des deux, puisqu'en couvrir un seul laisse l'autre grand ouvert. Aucun des deux, pourtant, ne décide qui a le droit de demander ces données en premier lieu ; ce travail restait à la gestion des identités et des accès de la leçon précédente. Ensemble, les deux contrôles répondent à « qui peut agir » et « que se passe-t-il si un disque ou un réseau est compromis quand même ». La leçon suivante aborde une question liée : comment une équipe prouve, à un auditeur ou à un régulateur, que les deux contrôles sont réellement en place.