• 20 heures
  • Moyenne

Ce cours est visible gratuitement en ligne.

course.header.alt.is_certifying

J'ai tout compris !

Mis à jour le 09/03/2023

Chiffrez vos communications et vos données

 

Avant de déployer le site de The Green Earth Post en production, il faut s’assurer que celui-ci est bien sécurisé pour éviter tout risque de piratage. Un site sécurisé est un site dont les données sont chiffrées. En effet, Dora vous dit que, dans sa précédente entreprise, ils ont déjà subi un piratage qui a mis leur site web hors service pendant plusieurs jours et leur a coûté cher. Votre rôle en tant qu'architecte de solutions est également d'anticiper ces événements et de ne pas les laisser se produire. Par conséquent, nous verrons dans cette partie les moyens pour y parvenir.

Découvrez les types de chiffrement

Il existe deux systèmes de chiffrement :

  • Le chiffrement symétrique utilise une clé secrète pour chiffrer et déchiffrer des données. Ce chiffrement est adapté aux situations où l’on souhaite chiffrer de gros volumes de données sans les partager. L’algorithme AES-256 est l’implémentation la plus répandue de ce chiffrement.

Illustration du fonctionnement d'une clé de chiffrement symétrique : une seule clé est utilisée pour chiffrer et déchiffrer les données.
Fonctionnement du chiffrement/déchiffrement symétrique
  • Le chiffrement asymétrique utilise deux clés. Une clé publique pour chiffrer les données et une clé privée pour les déchiffrer. Cette solution est efficace contre les attaques de l’homme du milieu

Illustration du chiffrement/déchiffrement asymétrique. - Une clé publique est utilisée pour chiffrer les données. - Une clé privée est utilisée pour déchiffrer les données.
Fonctionnement du chiffrement/déchiffrement asymétrique

Les protocoles SSL/TLS sont basés sur ce chiffrement. Lors d’une connexion avec un client, le serveur transmet un certificat TLS contenant sa clé publique et un nom de domaine (DNS). Les certificats sont signés par des autorités de certification (certificate authority - CA) qui valident leur identité. Un certificat est dit public si la CA est reconnue publiquement (exemple Let’s Encrypt), ce qui est nécessaire pour être authentifié sur Internet. Sinon, le certificat est dit privé et il est utile pour les réseaux privés d’entreprises.

Gérez vos certificats SSL avec AWS

Le service régional AWS Certificate Manager (ACM) vous permet de provisionner, gérer et déployer des certificats SSL/TLS nécessaires pour le chiffrement en transit de sites web sécurisés par HTTPS. ACM vous permet de créer et d’importer des certificats privés ou publics et gère le processus de leur renouvellement. ACM s’intègre facilement avec les services AWS :

Illustration du fonctionnement et intégration du service AWS Certificate Manager. De gauche à droite :  - AWS Private CA - Création/intégration des certificats - AWS Certificate Manager (ACM) - Liste d'éléments : ELB, CloudFront, APU Gateway - Clien
Fonctionnement et intégration du service AWS Certificate Manager

A - Autorité de certification privée
B- Provisionne, gère et déploie les certificats TLS privés et publics.

Le site de The Green Earth Post nécessitera un certificat public. ACM vous permet :

  • soit de demander gratuitement un certificat public qui est disponible en quelques heures. Les certificats générés par ACM sont automatiquement renouvelés 60 jours avant leur expiration. Il vous faudra spécifier :

    • une liste de noms de domaine :

      • complets (fully qualified domain name - FQDN), par exemple `www.example.com/` ;

      • ou apex, par exemple `*.example.com` ;

    • une validation par DNS ou email ;

  • soit d’importer un certificat public, mais vous devrez gérer le renouvellement. Toutefois, AWS peut vous notifier 45 jours avant l'expiration pour appliquer les actions nécessaires.

Fonctionnement d’une notification journalière avant expiration du certificat, par le service AWS ACM ou par le service AWS Config
Fonctionnement d’une notification journalière avant expiration du certificat, par le service AWS ACM ou par le service AWS Config

Chiffrez vos communications

En utilisant un équilibreur de charge face aux instances EC2, celles-ci ne sont plus directement exposées à Internet. C’est donc l’équilibreur qui fait la jonction entre le trafic public et le privé. Il est possible d’ajouter à l'équilibreur un certificat public fourni par ACM pour chiffrer le trafic public. Nous obtenons cette architecture logique :

Illustration du fonctionnement de l’architecture logique. De gauche à droite : - Client - ELB - EC2 En bas : ACM Une flèche relie ACM et ELB de bas en haut.
Fonctionnement de l’architecture logique composée d’un équilibreur de charge, d’un certificat fourni par ACM et d’une instance EC2. 

A - Trafic public sur Internet.
B - ELB et les instances EC2 communiquent avec leur IP locale via le réseau privé du VPC. 

Dans le cas spécifique de notre site web, nous obtenons l’architecture suivante :

Illustration de l'architecture finale pour le contenu dynamique.
Fonctionnement de l’architecture finale pour le contenu dynamique.

A - Communications sécurisées par HTTPS grâce au certificat délivré par ACM.

B - Un équilibreur de charge de type ALB

C - ELB et les instances communiquent avec leurs IP locales. Pas besoin de HTTPS.

D - ACM provisionne, gère et déploie le certificat TLS public.

E - Les instances EC2 associées à un groupe Auto Scaling doivent être déployées dans les sous-réseaux privés.

Nous avons vu dans le précédent chapitre qu’il était possible de lier des groupes cibles aux équilibreurs de type ALB et NLB. Imaginons que notre équilibreur desserve, non pas un site web, mais plusieurs sites web de différents noms de domaine. Comme un certificat est lié à un nom de domaine, il nous faudrait donc fournir plusieurs certificats à notre équilibreur. Or, lors de l'établissement de la liaison TLS entre un client et notre équilibreur, ce dernier doit lui communiquer son certificat public.

Mais, lequel des certificats communiquer s’il y en a plusieurs ?!

C’est là qu’intervient l’Indication du Nom du Serveur (Server Name Indication - SNI), une extension du protocole TLS. En effet, lors de l’établissement de liaison TLS, un client utilise le SNI pour spécifier le nom d'hôte qu'il souhaite atteindre. L’équilibreur sera alors capable de déterminer le certificat approprié.

Illustration de l’importance de l’Indication du Nom du Serveur dans l’établissement d’une liaison TLS
Illustration de l’importance de l’Indication du Nom du Serveur dans l’établissement d’une liaison TLS

Chiffrez vos données

Le service régional AWS Key Management Service (KMS) vous permet de créer et de gérer facilement des clés de chiffrement. Grâce à AWS IAM, vous pouvez gérer les autorisations pour chiffrer et/ou déchiffrer des données. Généralement, vous utiliserez des clés KMS de chiffrement symétrique, mais vous pouvez créer des clés KMS asymétriques. Cela est utile dans les cas où le chiffrement symétrique doit se faire en dehors du cloud AWS, comme montré ci-dessous.

Utilisation, par un datacenter on-premises, d’une clé asymétrique créée avec le service AWS KMS
Utilisation, par un datacenter on-premises, d’une clé asymétrique créée avec le service AWS KMS

KMS vous permet de créer trois types de clé :

  • Clé gérée par AWS (AWS Managed Key) – C’est une clé créée, gérée et utilisée par un service AWS intégré. Lorsque vous utilisez un service (S3, RDS…) avec chiffrement KMS, AWS génère une clé KMS pour ce service. La clé est créée avec un alias au format `aws/service-name` (par exemple aws/redshift). La rotation de la clé se fait automatiquement chaque année.

  • Clé gérée par le client (Customer Managed Key) – C’est une clé symétrique ou asymétrique que vous créez, gérez totalement (autorisations IAM, rotation, alias…). Vous pouvez activer la rotation automatique réalisée chaque année. Ce type de clé entraîne des frais mensuels.

  • Clé gérée par le client importée (Customer Managed Key imported) – C’est une clé que vous devez créer en important les éléments de clé (key material). La rotation de la clé se fait seulement manuellement.

La fonctionnalité Multi-régions dans AWS KMS permet de dupliquer une clé d'une région AWS à une autre. Plus besoin de déchiffrer les données avant de les copier dans une autre région et de les chiffrer à nouveau avec une nouvelle clé.

Illustration de la fonctionnalité Multi-régions dans AWS KMS
Illustration de la fonctionnalité Multi-régions dans AWS KMS

Cette fonctionnalité, comme montré ci-dessous, est utile pour DynamoDB Global Table et Global Aurora.

Illustration de l'utilisation d’une clé multi-région par DynamoDB Global Table et Global Aurora
Utilisation d’une clé multi-région par DynamoDB Global Table et Global Aurora

À vous de jouer !

Votre rôle ici est de vous assurer que le chiffrement des zones de stockage est bien activé pour le site The Green Earth Post. Il s’agit de la base de données RDS et du compartiment S3.

Les actions à réaliser :

  • Assurez-vous que la base RDS est chiffrée avec AWS KMS.

  • Activez le chiffrement avec le bon type de clé de chiffrement pour le  compartiment S3. Pour valider cela, vérifiez que le site web statique est toujours accessible depuis Internet. 

Regardez ce screencast pour vérifier que vous avez fait cet exercice correctement :

Stockez vos secrets

En plus du chiffrement des données et des communications, il faut également sécuriser nos secrets (mots de passe, clés privées…) servant à nos applications pour se connecter à d’autres applications, par exemple à RDS. Le service AWS Secrets Manager vous permet d’y stocker vos secrets de façon sécurisée, comme ci-dessous.

Instance EC2 qui s’authentifie à une base de données RDS en utilisant les identifiants de connexion stockés dans le service AWS Secrets Manager
Instance EC2 qui s’authentifie à une base de données RDS en utilisant les identifiants de connexion stockés dans le service AWS Secrets Manager

Ses atouts sont :

  • de chiffrer les secrets avec une clé KMS ;

  • d’activer la rotation automatique des secrets à l'aide d’une fonction lambda.

  • de prendre en charge la mise à jour des secrets sur RDS, DocumentDB, Redshift pendant la rotation ;

  • de valider les autorisations des demandes d’accès aux secrets par AWS IAM.

Avant que AWS Secrets Manager ne soit créé, c’est le service AWS System Manager (SSM) qui servait à stocker de façon sécurisée et hiérarchique les secrets, grâce à sa fonctionnalité Parameter Store. SSM est un ensemble de fonctionnalités qui vous aident à gérer vos applications et votre infrastructure exécutées dans le AWS Cloud.

SSM Parameter Store est également adapté pour y stocker des paramètres tels que des url, des ports, des noms de fichiers. Il inclut des paramètres standards (gratuits) et des paramètres avancés (payants). Avec ces derniers, vous pouvez créer des paramètres avec une durée de vie associée (time to live). 

Illustration de l'intégration d’une instance EC2 avec le service AWS Systems Manager Parameter Store
Intégration d’une instance EC2 avec le service AWS Systems Manager Parameter Store

En résumé

  • Le protocole SSL/TLS (chiffrement asymétrique) vous permet de sécuriser vos communications.

  • Le service AWS Certificate Manager s’intègre aux services ELB et CloudFront pour fournir des certificats publics.

  • Le chiffrement symétrique vous permet de chiffrer les données de vos zones de stockage.

  • Le service AWS KMS vous permet de créer des clés de chiffrement pour chiffrer de façon symétrique les données de vos zones de stockage.

Excellent travail sur le chiffrement ! Nous découvrirons dans le prochain chapitre comment améliorer les performances du site web.

Exemple de certificat de réussite
Exemple de certificat de réussite