Points clés
- Le chiffrement ne peut être ajouté en couche sur une architecture existante sans compromis — il doit être conçu dès la phase d'architecture.
- Les architectures modernes (microservices, cloud hybride, API-first) multiplient les surfaces de chiffrement à gérer.
- La performance et la latence sont des contraintes réelles qui influencent les choix cryptographiques et d'architecture.
- La gestion des clés dans une architecture distribuée est un problème d'orchestration autant que de sécurité.
Chiffrement by design : principe et implications
Intégrer le chiffrement dans une architecture globale signifie le traiter comme une exigence fonctionnelle dès la conception, et non comme une couche de sécurité ajoutée après coup. Cette approche — cohérente avec les principes de Privacy by Design et de Security by Design — implique que les décisions d'architecture (choix de bases de données, de formats de stockage, de protocoles de communication) tiennent compte des contraintes cryptographiques dès le départ.
L'ajout de chiffrement sur une architecture non prévue pour l'accueillir génère invariablement des compromis : performances dégradées, clés gérées de manière ad hoc, couverture partielle liée aux contraintes des composants existants. Ces compromis s'accumulent et créent des configurations hybrides difficiles à auditer.
Les spécificités des architectures distribuées
Dans une architecture microservices ou cloud hybride, chaque service est une entité potentiellement déployée dans un environnement différent (conteneurs, fonctions serverless, machines virtuelles, bare metal). Chaque communication inter-service est une surface de chiffrement à traiter. La multiplication des endpoints rend la gestion manuelle des certificats et des clés impossible à l'échelle.
Le service mesh (Istio, Linkerd) répond à ce problème en automatisant le chiffrement des communications inter-services (mTLS) et la gestion du cycle de vie des certificats. Il déplace la complexité cryptographique hors des applications elles-mêmes, mais crée une nouvelle couche d'infrastructure à sécuriser et à monitorer.
Performance, latence et choix cryptographiques
Le chiffrement a un coût computationnel. AES-256-GCM est aujourd'hui accéléré matériellement sur la quasi-totalité des processeurs modernes (AES-NI), rendant son surcoût négligeable pour la plupart des cas d'usage. En revanche, les opérations asymétriques (RSA, ECDH pour l'échange de clés) restent coûteuses et doivent être évitées dans les chemins critiques à haute fréquence.
Pour les systèmes à très haute throughput (bases de données analytiques, systèmes de traitement de flux temps réel), le chiffrement homomorphe ou le chiffrement au niveau colonne peuvent être des alternatives au chiffrement systématique, à condition que le modèle de menace le justifie. Ces choix doivent être documentés et révisés régulièrement à mesure que les capacités cryptographiques évoluent.
Gestion des clés dans les architectures distribuées
Un KMS (Key Management Service) centralisé — qu'il soit géré en interne (HashiCorp Vault, Thales Luna) ou délégué au cloud provider (AWS KMS, Azure Key Vault, GCP Cloud KMS) — est un prérequis pour toute architecture distribuée. Il centralise la génération, le stockage, la rotation et la révocation des clés, tout en fournissant une piste d'audit des opérations cryptographiques.
La question de la dépendance au cloud provider mérite une attention particulière. Déléguer la gestion des clés à AWS KMS crée une dépendance fonctionnelle et potentiellement juridique. Certaines réglementations (RGPD, secteur bancaire européen) imposent un contrôle démontrable sur les clés de chiffrement, ce qui peut nécessiter d'utiliser des clés gérées par le client (CMK) ou des HSM dédiés plutôt que des services partagés.
Chiffrement et zéro confiance
L'architecture zéro confiance (Zero Trust) modifie fondamentalement la logique du chiffrement : dans un modèle périmétrique, le chiffrement protège les flux sortants du réseau de confiance ; dans un modèle zéro confiance, chaque flux — y compris les communications internes — est chiffré et authentifié. Cette évolution augmente la couverture cryptographique mais exige une infrastructure de gestion des identités et des certificats proportionnellement plus robuste.