- SolarWinds (2020) : le trafic de mise à jour entre SolarWinds et les clients était chiffré en transit (HTTPS), mais le contenu du package (le code malveillant) n\'était pas vérifié cryptographiquement — illustrant que le chiffrement du transport ne remplace pas la vérification d\'intégrité du contenu.
- Le chiffrement en transit (TLS 1.3) protège contre l\'interception réseau (MITM) et l\'écoute passive. Il ne protège pas contre un serveur compromis, un certificat mal géré ou une terminaison TLS dans une infrastructure non sécurisée.
- Le chiffrement au repos protège contre l\'accès physique aux supports de stockage et contre les sauvegardes exfiltrées. Il ne protège pas contre un système compromis dont le service de déchiffrement est actif.
- Les zones de transition — où les données passent de l\'état chiffré en transit à l\'état stocké au repos — sont les points d\'exposition les plus critiques : si le système récepteur ne chiffre pas immédiatement les données reçues, il crée une fenêtre d\'exposition.
- La terminaison TLS dans des proxies intermédiaires (load balancers, WAF) crée des zones de trafic en clair dans l\'infrastructure interne que beaucoup d\'organisations ne traitent pas avec la même rigueur que le trafic externe.
- mTLS (mutual TLS) est nécessaire pour les communications service-to-service dans les architectures microservices — sans authentification mutuelle, un service compromis peut se faire passer pour n\'importe quel autre service dans le même réseau.
La distinction entre chiffrement au repos et chiffrement en transit n\'est pas purement académique — elle détermine les vecteurs d\'attaque contre lesquels chaque mécanisme est efficace et, par conséquent, les décisions d\'architecture qui garantissent une protection réelle plutôt qu\'une conformité formelle. Un audit de sécurité qui vérifie la présence de TLS sur les endpoints exposés et de chiffrement sur les disques peut satisfaire les régulateurs sans révéler les angles morts les plus critiques.
La compréhension précise des propriétés de chaque type de chiffrement — ce qu\'il protège, contre qui, dans quelles conditions — est la base sur laquelle les architectes sécurité construisent des modèles de protection cohérents. Sans cette compréhension, les décisions d\'architecture reproduisent des patterns qui offrent une protection sur le papier sans couvrir les vecteurs d\'attaque réels.
Le chiffrement en transit : propriétés et limites
TLS 1.3 (et dans une moindre mesure TLS 1.2 avec les cipher suites appropriées) offre des propriétés cryptographiques solides pour la protection des communications réseau : confidentialité des données en transit via des échanges de clés éphémères (Perfect Forward Secrecy), intégrité via AEAD (Authenticated Encryption with Associated Data), et authentification du serveur via les certificats. Ces propriétés sont bien définies et bien comprises.
Les limites sont tout aussi précisément définies. TLS protège le canal entre deux points de terminaison — pas les données une fois arrivées à destination. Un serveur web qui reçoit des données via HTTPS et les stocke en clair dans sa base de données a bien protégé le transit mais pas le stockage. La terminaison TLS dans des équipements intermédiaires (load balancers, proxies, WAF) crée une zone de clair entre l\'équipement de terminaison et le backend — une zone souvent moins bien surveillée que le périmètre externe.
L\'incident Deutsche Bank de 2019 — transmission de données de 1 200 employés au mauvais destinataire — illustre un cas où ni le chiffrement en transit ni le chiffrement au repos ne sont des protections pertinentes. Les données ont été transmises via les systèmes de messagerie institutionnels de la banque, vraisemblablement protégés en transit. L\'erreur était dans la logique applicative (mauvais destinataire) et dans l\'absence de mécanismes de validation avant envoi. Ce cas illustre que le chiffrement — même bien déployé — ne protège pas contre les erreurs de logique applicative : si le système envoie les données au bon protocole mais à la mauvaise destination, le chiffrement du transport ne change rien à l\'exposition.
Le chiffrement au repos : propriétés et limites
Le chiffrement au repos (encryption at rest) couvre les données stockées sur des supports physiques ou logiques : disques durs, bases de données, fichiers, sauvegardes, archives. Son modèle de protection est principalement défensif contre l\'accès physique aux supports (vol de disque, revente d\'équipement sans effacement) et contre l\'extraction de sauvegardes ou d\'archives par des attaquants qui n\'ont pas accès aux systèmes actifs.
La limite principale du chiffrement au repos est sa neutralisation dès que le système qui gère les données est actif. Un service de base de données qui déchiffre les données pour les servir aux applications ne protège pas contre un attaquant ayant accès à ce service — les données sont déchiffrées en mémoire et disponibles via les interfaces normales. Le chiffrement au repos ne protège que dans les scénarios où le système de traitement des données n\'est pas compromis.
Les zones de transition et les architectures qui les minimisent
Les zones de transition — où les données passent de l\'état chiffré en transit à l\'état stocké au repos — sont les points d\'exposition les plus critiques et les moins adressés dans les architectures de chiffrement. Le temps entre la réception des données (fin du chiffrement en transit) et leur stockage chiffré au repos représente une fenêtre d\'exposition en mémoire. Dans les architectures qui traitent des volumes importants de données sensibles, cette fenêtre peut être significative si les processus de chiffrement ne sont pas dans le chemin critique de réception.
Les architectures qui minimisent les zones de transition incluent le chiffrement côté client (les données arrivent déjà chiffrées sur le serveur, qui ne manipule jamais le plaintext), les enclaves sécurisées (TEE — Trusted Execution Environments) qui permettent le traitement des données sans les exposer au système hôte, et les architectures de chiffrement préservant la confidentialité (homomorphic encryption, secure multi-party computation) qui permettent des opérations sur des données chiffrées sans nécessité de déchiffrement.
La violation Citibank de 2011 (360 000 comptes via traversal d\'API) illustre l\'importance de la distinction entre chiffrement en transit et protection logique des données. Les communications entre le client et le portail web étaient chiffrées via HTTPS — la protection du transit était en place. La vulnérabilité résidait dans la logique d\'autorisation de l\'API : en manipulant l\'identifiant de compte dans l\'URL, un attaquant authentifié pouvait accéder aux données d\'autres comptes. Le chiffrement en transit protégeait les données entre le navigateur et le serveur mais n\'avait aucune pertinence contre une logique d\'autorisation défaillante côté serveur. La séparation conceptuelle entre protection du transport et protection des données elles-mêmes est illustrée par cet incident.
La violation EasyJet de 2020 (9 millions de clients, données de paiement) a exposé des données dont certaines n\'étaient pas chiffrées au repos dans les systèmes affectés. EasyJet disposait de TLS pour les communications en transit — le site de réservation utilisait HTTPS. Les données une fois stockées dans les systèmes backend n\'étaient pas uniformément protégées. L\'enquête de l\'ICO a relevé que les mesures de sécurité n\'étaient pas cohérentes entre les systèmes exposés au public et les systèmes de stockage interne. Cette incohérence — TLS bien déployé sur le périmètre, chiffrement au repos insuffisant dans les systèmes internes — est un pattern fréquent dans les organisations qui ont prioritisé la conformité visible (HTTPS sur le site web) sur la protection profonde des données.
La violation Air India via SITA en 2021 (4,5 millions de passagers) a exposé des données incluant des informations de passeport et des données de fidélité. L\'investigation a révélé des lacunes dans le chiffrement des données transitant entre les systèmes d\'Air India et l\'infrastructure SITA. Les données de passagers transférées entre compagnies aériennes via les GDS (Global Distribution Systems) utilisent des protocoles legacy (EDIFACT, IATA PADIS) qui n\'ont pas été conçus avec le chiffrement comme priorité. Beaucoup de ces flux de données entre acteurs de l\'industrie aérienne transitent via des protocoles qui offrent peu ou pas de protection cryptographique — une dette technique sectorielle qui crée une surface d\'exposition systémique.