Chiffrement des données : au repos, en transit, en usage — ce qui compte
« Nos données sont chiffrées » ne dit presque rien tant qu'on ne précise pas dans quel état — au repos, en transit ou en usage — et surtout qui détient les clés. Chaque état protège contre des menaces différentes, et un chiffrement sans gestion des clés sérieuse n'est qu'une assurance sur le papier.
Trois états, trois menaces différentes
Une donnée est toujours dans l'un de trois états : stockée sur un support (au repos), en train de circuler sur un réseau (en transit), ou en cours de traitement dans la mémoire d'une machine (en usage). Chaque état a ses menaces propres : vol ou copie d'un disque, d'une bande ou d'une image de machine virtuelle pour le premier ; interception et détournement de trafic pour le deuxième ; lecture de la mémoire par un logiciel malveillant, un administrateur d'hyperviseur ou un autre locataire d'une plateforme partagée pour le troisième. Dire « c'est chiffré » sans préciser l'état, c'est répondre à côté de la question.
Au repos et en transit : les fondamentaux, bien faits
Au repos : nécessaire, pas suffisant
Le chiffrement de disque ou de volume protège contre le vol physique, le recyclage de matériel et la copie brute d'un support. Mais il est transparent pour tout ce qui s'exécute légitimement : une application vulnérable ou un compte compromis lit les données déchiffrées, comme n'importe quel utilisateur autorisé. D'où l'intérêt des couches supérieures — chiffrement au niveau de la base de données, voire du champ pour les données les plus sensibles — plus contraignantes à opérer mais opposables à un attaquant déjà entré. Et le périmètre doit inclure ce qu'on oublie : sauvegardes, exports, copies de travail. Une base chiffrée dont l'export part en clair sur un partage de fichiers n'est pas une base chiffrée.
En transit : TLS partout, y compris en interne
Le chiffrement du trafic externe est acquis presque partout. Le point faible est le trafic interne, dit « est-ouest » : entre applications et bases de données, entre services, entre sites. Beaucoup d'architectures considèrent le réseau interne comme sûr ; or il suffit d'un poste compromis pour que cette hypothèse s'effondre et que l'attaquant écoute. La cible raisonnable : du TLS aussi en interne, des certificats inventoriés et renouvelés automatiquement — un certificat expiré provoque des pannes, et les « contournements temporaires » qui s'ensuivent durent des années — et le chiffrement des flux de réplication et de sauvegarde, souvent les plus riches.
En usage : le chaînon le plus récent
Pendant le traitement, les données sont en clair dans la mémoire. C'est ce que vise l'informatique confidentielle : des enclaves matérielles qui gardent la mémoire chiffrée même en cours d'exécution, opposables à l'hébergeur lui-même ou à un hyperviseur compromis. La technologie mûrit, mais elle compte surtout pour des données très sensibles traitées sur une infrastructure partagée. Pour la plupart des organisations, la question se pose autrement : choisir un hébergement où l'opérateur est techniquement et contractuellement encadré — le cœur du débat sur la souveraineté des données.
La gestion des clés : le vrai sujet
La question décisive n'est pas l'algorithme — les standards actuels sont robustes — mais : qui détient les clés ? Car qui détient les clés peut lire les données, quel que soit le niveau de chiffrement affiché. Les points à trancher : où les clés sont stockées (un gestionnaire de clés dédié, adossé si besoin à un module matériel de sécurité, jamais à côté des données — sinon voler le serveur revient à voler la clé) ; qui les administre (l'administrateur des systèmes ne doit pas être l'administrateur des clés) ; comment elles vivent (rotation régulière, révocation en cas de doute) ; et comment elles sont elles-mêmes sauvegardées — perdre une clé, c'est perdre définitivement la donnée.
Chez un prestataire cloud, trois modèles coexistent : clés gérées par le fournisseur (simple, mais il peut techniquement déchiffrer), clés apportées par le client, ou clés détenues par le client hors de portée du fournisseur. Le bon choix dépend de la sensibilité des données et de vos obligations — et il doit figurer noir sur blanc dans le contrat d'hébergement, comme le rappelle notre article sur les DPA et l'hébergement. Sur le cloud privé SOVALYX, ces arbitrages se règlent contractuellement : chiffrement systématique au repos et en transit, et clés sous votre contrôle si votre conformité l'exige.
Les erreurs répandues, d'un coup d'œil
| Erreur courante | Pourquoi c'est un problème | Bon réflexe |
|---|---|---|
| « Le disque est chiffré, nous sommes couverts » | Ne protège ni d'un compte compromis ni d'une application vulnérable | Ajouter un chiffrement base ou champ pour les données sensibles |
| Clés stockées avec les données | Voler le serveur, c'est voler la clé | Gestionnaire de clés séparé, droits distincts |
| TLS uniquement en façade | Le trafic interne s'écoute dès qu'un poste tombe | Chiffrer aussi les flux internes et de réplication |
| Certificats non inventoriés | Expirations, pannes, contournements « temporaires » durables | Inventaire et renouvellement automatisés |
| Sauvegardes et exports en clair | Ils concentrent l'essentiel des données | Chiffrer sauvegardes et exports, contrôler leurs destinations |
| Aucun plan de perte de clé | Clé perdue égale donnée perdue | Procédure de sauvegarde et de recouvrement des clés, testée |
Comment SOVALYX peut vous aider
SOVALYX chiffre systématiquement les données au repos et en transit sur son cloud privé, et vous laisse la maîtrise des clés lorsque votre conformité l'exige (KMS dédié, séparation des rôles). Un audit ciblé identifie rapidement les angles morts — exports, sauvegardes, flux internes. Contact : +230 5830 3314.
Parler sécurité avec un ingénieur🧰 L'outil qui va avec : Votre sauvegarde survivrait-elle à un ransomware ? — gratuit · 2 minutes.
Relu et optimisé par IA.