Temps de lecture : 12 minutes

Dans un contexte où la sécurité des données occupe une place prépondérante, la protection des informations sensibles est devenue une priorité majeure pour de nombreuses entreprises. Nous avons accompagné l’une d’elles, leader dans son domaine et présente sur tous les continents, à déployer une solution de chiffrement robuste visant à sécuriser ses données critiques hébergées sur des environnements AWS soumis à de fortes contraintes de disponibilité.

Dans cet article, nous allons découvrir comment nous avons aidé notre client à mettre en place une solution de chiffrement simple, efficace à un faible coût d’infrastructure permettant une tarification flexible et transparente, sans engagement ni frais initiaux.

Avant de démarrer, qu’est-ce que le chiffrement ?

Le chiffrement est l’un des éléments fondamentaux de la cybersécurité qui permet de préserver la confidentialité des informations. D’un point de vue technique, il implique la transformation des données à l’aide d’un secret partagé entre l’émetteur et le destinataire. Les données ainsi chiffrées sont protégées lorsqu’elles sont stockées dans les infrastructures cloud, ou lorsqu’elles transitent entre une source et son destinataire. Ainsi, même en cas d’accès physique aux données, l’hébergeur ne peut y accéder sans disposer de la clé de chiffrement appropriée.

Il existe deux types de chiffrement, le chiffrement symétrique et le chiffrement asymétrique. 

Le chiffrement symétrique : 

Le chiffrement symétrique, également appelé algorithme de clé privée ou partagée, utilise la même clé pour le chiffrement et le déchiffrement.

Exemple 1 : 

Dans cet exemple, il est supposé que la clé a été préalablement partagée entre Alice et Bob.

• Bob envoie un message à Alice. Alice déchiffre le message reçu à l’aide de la clé de chiffrement connue.
• Si Eve réussit à intercepter le message, elle ne peut pas le lire car elle ne dispose pas de la clé de déchiffrement.

Exemple 1 : Schéma d’échange de messages entre Bob et Alice – Méthode de chiffrement symétrique

Le chiffrement asymétrique : 

Le chiffrement asymétrique, également appelé cryptographie à clé publique, utilise deux clés distinctes pour chiffrer et déchiffrer les données: la clé publique partagée entre toutes les parties pour le chiffrement et la clé privée connue uniquement par une partie servant au déchiffrement. Ainsi, toute personne disposant de la clé publique peut alors envoyer un message chiffré, mais seule la partie détenteur de la clé privée peut déchiffrer le message.

Exemple 2 : 

• Bob génère une key pair (une clé privée et une clé publique) (1) et distribue sa clé publique à Alice (2). Alice chiffre son message à l’aide de la clé publique de Bob (3) et renvoie le message chiffré à Bob (4).
• A l’aide de sa clé privée, Bob déchiffre le message chiffré (5).
• Si Eve réussit à intercepter le message, elle ne peut pas le lire car elle ne dispose pas de la clé de déchiffrement.

Exemple 2 : Schéma d’échange de messages entre Bob et Alice – Méthode de chiffrement asymétrique

Maintenant que nous savons tous ce qu’est le chiffrement, revenons à notre client.

Problématique 

La politique de sécurité de notre client exige la mise en œuvre du chiffrement sur l’ensemble de ses ressources AWS.
Pour répondre à cette exigence, nous avons accompagné notre client dans la réalisation d’un projet visant à chiffrer toutes ses ressources AWS. 
L’objectif est de garantir une conformité aux normes de sécurité établies et d’améliorer l’intégration cloud pour une gestion plus efficace et sécurisée des ressources sur la plateforme AWS.

Périmètre

Nous avons listé et catégorisé l’ensemble des ressources non chiffrées (volumes EBS, Bucket S3 …), soit environ un millier de ressources dans le cloud AWS comprenant plusieurs centaines de To de données, réparties sur environ 400 comptes et sur une soixantaine de Business Units.

Cette analyse nous a permis de réaliser un pattern d’architecture et de mener une étude de faisabilité afin d’évaluer les impacts potentiels de la mise en place du chiffrement sur chaque type de service AWS.

Évaluation des possibilités et choix de la solution

Nous avons étudié les options suivantes : clés managées par AWS, les clés CMK KMS, le Cloud HSM d’AWS et même si ce n’était pas le choix du client pour des raisons de coûts notamment, nous avons également envisagé la possibilité d’intégrer un boîtier HSM tiers, tel qu’un boîtier hébergé chez le client.

• AWS Customer Managed Key
  • Clés créées et gérées par l’utilisateur. Vous avez la possibilité de modifier leurs propriétés, leurs permissions, de les supprimer et de planifier leur rotation. Vous avez également la possibilité de consulter leurs autorisations et d’auditer leur utilisation via AWS CloudTrail.
• AWS Managed Key
  • Clés créées et gérées par AWS. Vous avez la possibilité de consulter leurs permissions et d’auditer leur utilisation via AWS CloudTrail. Cependant, vous ne pouvez pas modifier leurs propriétés, effectuer leur rotation, modifier leurs permissions ni les supprimer.
• AWS CloudHSM
  • Service de module de sécurité matérielle (HSM) hébergé dans le cloud qui vous permet d’effectuer des opérations cryptographiques et de stocker des clés de chiffrement.
• Customer Managed HSM Device
  • Matériel électronique dont la propriété, la gestion et l’administration sont exclusivement réservées au client, offrant un service de sécurité qui consiste à générer, stocker et protéger des clefs cryptographiques ainsi qu’effectuer des opérations cryptographiques sensibles.

Type of key	Can view KMS/Owned key metadata	Can manage KMS/Owned key	Used only for my AWS account	Automatic rotation	Pricing
AWS Customer Managed Key	Yes	Yes	Yes	Optional. Every year (approximately 365 days)	– Monthly fee (pro-rated hourly) – Per-use fee
AWS Managed Key	Yes	No	Yes	Required. Every year (approximately 365 days)	– No monthly fee – Per-use fee (some AWS services pay this fee for you)
AWS CloudHSM	Yes	Yes	As needed	As needed	– Existing customers $5,000 initially for AWS CloudHSM, then an hourly rate. – New customers have no initial cost, only an hourly fee ranging from $1 to $3 depending on the AWS region.
Customer Managed HSM Device	Yes	Yes	As needed	As needed	Several hundred/thousand dollars.

Tableau comparatif

Choix de la solution de chiffrement AWS 

Nous avons effectué nos choix via une grille prenant en compte le prix, le maintien en condition opérationnelle et l’évolutivité.

Après une analyse approfondie des différentes options de chiffrement sur AWS et des différentes contraintes, la solution CMK KMS (Customer Managed Keys Key Management Service) a été retenue pour répondre aux besoins spécifiques du client. 

Cette solution a été privilégiée en raison de sa capacité à répondre aux diverses problématiques de sécurité, notamment l’externalisation des backups chiffrés (impossible avec les AWS Managed Keys) et la rotation automatique des clés. 

De plus, la CMK KMS offre une gestion centralisée des clés de chiffrement tout en permettant un accès maîtrisé et sécurisé à ces clés pour quelques dollars par mois et reste une solution bien moins coûteuse que Cloud HSM

Nous avons également choisi de partir sur une architecture basée sur un compte central dédié aux clés CMK KMS. Ce compte ne servira qu’à stocker les clés de chiffrement des différentes ressources de notre organisation AWS, avec une isolation qui permet de restreindre l’accès à un nombre très limité de personnes.

Le projet repose donc sur une architecture host vs. services:

• Host (cf. « Encryption account »): 1 compte AWS centralisant les clés afin de fournir un service
• Services: N comptes AWS qui sont “clients” du service mis à disposition par le Host

Ci-dessous l’architecture globale de la solution mise en place :

Architecture globale de la solution de chiffrement

Déploiement et configuration de la solution de chiffrement AWS

L’architecture de la solution a été déployée en Terraform selon les principes de l’Infrastructure as Code (IaC), et en respectant les bonnes pratiques en matière de déploiement et d’intégration continue. Cette approche répond non seulement aux normes de qualité, de maturité et de sécurité du code chez notre client, mais aussi aux exigences et convictions de Devoteam quant à la qualité du delivery réalisé pour nos clients.

Nous avons validé deux types d’utilisation de clés, ce qui nous a conduit à découper notre solution en deux scénarios : 

• Scénario 1 : Une clé par compte pour tous les services
  • Scénario standard déployé par défaut sur tout le périmètre
    
• Scénario 2 : Une clé par application par compte et par région.
  • Scénario à la demande, qui permet de chiffrer les ressources d’une application avec des clés dédiées à cette dernière. Ce scénario est particulièrement adapté aux applications sensibles.

Scénario n° 1 : Une clé par compte pour tous les services (Scénario standard)

Pour chaque service, une clé KMS CMK est créée par région et par compte. (exemple: on crée une clé dédiée au chiffrement des volumes EBS pour un compte spécifique dans une région donnée).

Si des ressources existent dans une autre région, un replica de cette clé est également créé dans ladite région afin de chiffrer les ressources qui y sont hébergées.

Schéma du scénario 1

Scénario n° 2 : Une clé par application par compte et par région (Scénario à la demande)

Pour chaque application, une clé KMS CMK est créée par région et par compte et permet de chiffrer toutes les ressources d’une application.

Si des ressources de cette application existent sur une autre région, un replica de cette clé est également créée dans ladite région afin de chiffrer les ressources qui y sont hébergées grâce à l’option multi-regions proposée par AWS pour les clés KMS.

Schéma du scénario 2

Avantages de la solution retenue

La centralisation des clés de chiffrement sur un compte dédié présente plusieurs avantages significatifs pour le client:

• Gouvernance :

Cette solution nous a permis d’implémenter une gestion centralisée de l’ensemble des clés de chiffrement, facilitant ainsi la mise en œuvre et la maintenance des politiques de sécurité. 

• Auditabilité :

La centralisation des clés de chiffrement sur un compte dédié a simplifié le suivi de la conformité réglementaire et les audits de sécurité en fournissant un point central pour la gestion et la surveillance des clés.

• Pricing :

Le coût mensuel d’une clé est de $1 par mois/région plafonné à $3 par mois/région après deux rotations*, ce qui représente une solution rentable pour la gestion des clés de chiffrement à grande échelle.

* Plafonnement à $3/clé après deux rotations appliquée à partir de la première semaine de Mai 2024 – cf annonce AWS du 12 Avril 2024
Plus de détails sur la méthode de facturation des clés KMS

Limitations observées

Malgré ses nombreux avantages, la centralisation des clés de chiffrement sur un compte dédié présente également un inconvénient majeur. En effet, du fait de la centralisation, il devient un Single Point of Failure (SPOF) pour le chiffrement et nécessite une gestion particulière.

En effet, si le compte central dédié au chiffrement contenant toutes les clés de chiffrement est compromis, il devient impossible de déchiffrer les ressources protégées par ces clés. C’est pour cela que sa protection est un des enjeux majeurs dans le cadre du déploiement de cette solution.

Comment répondre aux limitations ?

I- Protection du compte central : 

Afin de se prémunir de tout risque de compromission sur le compte central dédié au chiffrement, nous avons mis en place un certains nombre de mesures :

• Accès restreint au compte :

L’accès au compte central dédié au chiffrement a été restreint à une liste d‘utilisateurs maîtrisée et uniquement accessible via login, mot de passe + Multi Factor authentication (MFA) physique. 

• Traçabilité et remédiation efficace :

La journalisation des évènements revêt une importance capitale, car elle assure une traçabilité en temps réel  et une historisation des activités sur les infrastructures. Elle permet aussi le déclenchement des actions de remédiation nécessaires.

• Exploitation des logs : 

Les logs récoltés sont ensuite acheminées vers notre outil SIEM (Security Information and Event Management), permettant ainsi d’identifier en temps réel toute activité suspecte ou illégitime.

II- Protection des clés de chiffrement : 

• AWS Service Control Policies (SCP) : 

Nous avons mis en place une SCP sur le compte de management (master d’org) qui empêche la suppression d’une clé KMS CMK à toute personne autre que les administrateurs sur le compte central dédié au chiffrement.

• AWS KMS Key policy : 

Les permissions de chaque clé ont été configurées selon le principe du least privilege afin de restreindre les actions sur chaque clé. Seuls les services ou rôles connus sont autorisés à effectuer des opérations de chiffrement ou de déchiffrement à partir d’une clé KMS CMK.

• Proactivité : 

Nous avons implémenté un mécanisme de surveillance proactive à l’aide des services de sécurité d’AWS tels que GuardDuty, Security Hub, SCP, Config. Toutes les actions réalisées sur le compte central sont scrupuleusement surveillées, collectées via CloudWatch et CloudTrail, puis stockées dans des buckets S3. 

Les données recueillies par ce système de surveillance nous ont permis de créer un système de notifications pour alerter les administrateurs de la plateforme en cas de modification sur une clé, afin de surveiller toute altération (modification de permissions, mise à jour des utilisateurs/administrateurs, etc…).

Vous trouverez ci-joint l’architecture du système de notification mis en place.

Schéma du système du mécanisme mis en place en cas de tentative de suppression d’une clé KMS

• Protection de la clé par AWS :

La suppression d’une clé AWS KMS est une opération destructrice et potentiellement dangereuse, car elle efface le matériel de la clé ainsi que toutes les métadonnées associées. Après la suppression, il n’est plus possible de déchiffrer les données, rendant cette action irréversible et les données irrécupérables. Pour atténuer les risques d’une suppression illégitime ou non, AWS KMS impose un délai d’attente compris entre 7 et 30 jours avant la suppression effective d’une clé. Par défaut, ce délai est fixé à 30 jours.

• AWS Key rotation : 

Dans le but de nous conformer aux exigences de la politique de sécurité groupe et aux bonnes pratiques recommandées par les normes de sécurité, nous avons implémenté un mécanisme de rotation des clés KMS CMK dans le but de renforcer la sécurité des données en limitant la durée de validité des clés existantes.

AWS effectue automatiquement une rotation à une fréquence au choix, comprise entre 90 jours et 2560 jours, soit 7 ans après la création de la clé correspondante.

Mécanisme de rotation de clé

Conclusion

En synthèse, afin de résoudre les défis de sécurité auxquels notre client était confronté en matière de chiffrement, nous avons mis en place une solution de chiffrement conforme aux normes de sécurité des données sur AWS. 

Notre approche a commencé par une explication détaillée du chiffrement, mettant en avant les deux principaux types; symétrique et asymétrique, afin d’en poser les bases théoriques.

Par la suite, nous avons examiné les spécificités et les contraintes propres à notre client, évaluant différentes solutions de chiffrement envisageables. Cette évaluation nous a amené à choisir la solution CMK KMS (Customer Managed Keys Key Management Service) comme étant la plus adaptée pour répondre à ses besoins.

L’architecture mise en œuvre, caractérisée par la centralisation des clés de chiffrement sur un compte dédié, a été conçue pour offrir une gestion simplifiée, centralisée et économique des clés. Malgré les avantages indéniables de cette approche, nous avons dû relever le défi majeur lié au risque de devenir un Single Point Of Failure (SPOF) potentiel.

Pour prévenir ce risque, nous avons mis en place des mesures de protection robustes, à la fois au niveau du compte central et des clés de chiffrement elles-mêmes.

En conclusion, le déploiement de cette solution de chiffrement illustre parfaitement l’alliance entre les exigences de sécurité du client et les meilleures pratiques du cloud, garantissant ainsi la confidentialité des données sensibles des entreprises dans un environnement cloud complexe, soumis à des contraintes de disponibilité fortes et en constante évolution.