Cloud & IT Cert Prep · Leçon

KMS, ACM et modèles de chiffrement

Gérez les clés de chiffrement avec AWS KMS, fournissez et renouvelez les certificats TLS avec ACM, puis choisissez entre le chiffrement côté client, côté serveur et en transit.

KMS, ACM et modèles de chiffrement est une leçon Cloud & IT Cert Prep gratuite sur CoddyKit. Ceci est la leçon 1 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage Cloud & IT Cert Prep, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours Cloud & IT Cert Prep comprend 4 leçons au total.

Chiffrement sur AWS : présentation

Le chiffrement est un contrôle de sécurité fondamental qui protège la confidentialité des données, même si le support de stockage est compromis ou si un accès est obtenu par d’autres moyens. AWS fournit un chiffrement au repos (pour les données stockées dans des bases de données, S3 ou EBS) et en transit (pour les données circulant sur les réseaux). Services essentiels : AWS Key Management Service (KMS) gère les clés de chiffrement pour le chiffrement au repos. AWS Certificate Manager (ACM) fournit et gère les certificats TLS pour le chiffrement en transit. Il est essentiel de comprendre quand et comment appliquer chacun de ces services pour le domaine de l’architecture de sécurité de SAA-C03.

# Encryption coverage on AWS:
# At rest (KMS):
#   S3, EBS, RDS, DynamoDB, EFS, SQS,
#   Lambda env vars, Secrets Manager, SSM Parameter Store

# In transit (ACM/TLS):
#   ALB listeners (HTTPS), API Gateway, CloudFront,
#   Direct Connect, VPN, inter-service communication

# Both:
#   S3 Server-Side Encryption + HTTPS only policy

AWS KMS : Key Management Service

AWS KMS est un service entièrement géré permettant de créer et de contrôler des clés de chiffrement. KMS utilise des Hardware Security Modules (HSM) pour protéger les clés : le matériel de clé ne quitte jamais le HSM sans être chiffré. KMS s’intègre à la plupart des services AWS pour le chiffrement côté serveur. Types de clés : AWS Managed Keys (gratuites, renouvelées automatiquement chaque année, vous ne pouvez pas les contrôler directement), Customer Managed Keys (CMK) (1 $/mois chacune, vous contrôlez la rotation, la stratégie de clé et la suppression). Custom Key Store utilise votre propre cluster CloudHSM pour les exigences de conformité imposant des HSM dédiés.

# Create a Customer Managed Key (CMK)
aws kms create-key \
  --description 'Production database encryption key' \
  --key-usage ENCRYPT_DECRYPT \
  --origin AWS_KMS \
  --tags TagKey=Purpose,TagValue=RDS-Encryption

# Create an alias for the key
aws kms create-alias \
  --alias-name alias/prod-db-key \
  --target-key-id arn:aws:kms:us-east-1:123:key/abc-def

# CMK costs: $1/month + $0.03 per 10,000 API calls

Stratégies de clé et octrois KMS

Chaque clé KMS possède une stratégie de clé — une stratégie basée sur les ressources qui contrôle les personnes et services pouvant utiliser et gérer la clé. Contrairement aux stratégies IAM, qui sont basées sur l’identité, les stratégies de clé sont obligatoires : la stratégie de clé doit explicitement accorder l’accès pour que les stratégies IAM prennent effet. Bonne pratique : séparer l’administration de la clé (qui peut gérer la clé) de l’utilisation de la clé (quels services et rôles peuvent chiffrer et déchiffrer). Utilisez les key grants pour accorder temporairement un accès délégué — par exemple, autoriser temporairement un cluster EMR à utiliser une clé KMS pour une tâche sans modifier la stratégie de clé.

# KMS key policy: grant RDS and admin access
{
  'Statement': [
    {
      'Sid': 'Enable root account full access',
      'Principal': {'AWS': 'arn:aws:iam::123:root'},
      'Action': 'kms:*',
      'Effect': 'Allow'
    },
    {
      'Sid': 'Allow RDS to use this key',
      'Principal': {'Service': 'rds.amazonaws.com'},
      'Action': ['kms:Encrypt','kms:Decrypt','kms:GenerateDataKey'],
      'Effect': 'Allow'
    }
  ]
}

Chiffrement enveloppe KMS

KMS utilise le chiffrement enveloppe pour protéger efficacement de grandes quantités de données. Vous ne pouvez pas chiffrer directement plus de 4 Ko avec une clé KMS. À la place : KMS génère une Data Encryption Key (DEK) — une clé aléatoire utilisée pour chiffrer localement vos données réelles. La DEK est ensuite chiffrée par votre clé KMS (la Key Encryption Key). Vous stockez la DEK chiffrée avec les données chiffrées. Pour déchiffrer, vous appelez d’abord KMS afin de déchiffrer la DEK, puis vous utilisez localement la DEK en clair pour déchiffrer les données. C’est ainsi que fonctionnent en interne les chiffrements S3, EBS et RDS.

# Generate a Data Key (for envelope encryption)
aws kms generate-data-key \
  --key-id alias/my-key \
  --key-spec AES_256

# Response contains:
# Plaintext: base64-encoded DEK (use to encrypt data locally)
# CiphertextBlob: KMS-encrypted DEK (store alongside data)

# To decrypt:
# 1. Call kms:Decrypt(CiphertextBlob) -> plaintext DEK
# 2. Use plaintext DEK to decrypt data locally
# 3. Zeroize plaintext DEK from memory
aws kms decrypt --ciphertext-blob fileb://encrypted-dek.bin

Rotation des clés KMS

La rotation des clés est une bonne pratique de sécurité qui remplace périodiquement le matériel cryptographique de la clé, limitant ainsi la période d’exposition en cas de compromission. Pour les Customer Managed Keys, vous pouvez activer une rotation automatique annuelle : KMS génère un nouveau matériel de clé et l’utilise pour les nouvelles opérations de chiffrement, tout en conservant l’ancien matériel pour déchiffrer les données existantes. Les AWS Managed Keys effectuent automatiquement une rotation chaque année. Le matériel de clé importé ne prend PAS en charge la rotation automatique (vous devez effectuer la rotation manuellement). Après la rotation, les nouvelles opérations KMS utilisent automatiquement le nouveau matériel de clé, sans modification de l’application.

# Enable automatic annual key rotation
aws kms enable-key-rotation \
  --key-id alias/prod-db-key

# Verify rotation is enabled
aws kms get-key-rotation-status \
  --key-id alias/prod-db-key

# Manual rotation (for imported key material):
# 1. Create a new CMK
# 2. Update all services to use new key
# 3. Re-encrypt existing data with new key
# 4. Schedule old key for deletion (minimum 7-day waiting period)

Options de chiffrement côté serveur S3

S3 prend en charge trois options de chiffrement côté serveur : SSE-S3 — S3 gère les clés à l’aide d’AES-256 ; cette option est gratuite et offre un contrôle minimal. SSE-KMS — utilise une clé KMS (gérée par AWS ou CMK), fournit une piste d’audit des clés dans CloudTrail, prend en charge les stratégies de clé et entraîne un coût par appel d’API KMS. SSE-C — vous fournissez et gérez le matériel de clé avec chaque requête ; S3 ne stocke jamais la clé. Utilisez SSE-KMS lorsque vous devez contrôler et auditer qui a utilisé la clé et à quel moment. Utilisez SSE-S3 pour les données peu sensibles lorsque la simplicité et le coût sont prioritaires. Imposez le chiffrement avec une stratégie de compartiment qui refuse PutObject sans chiffrement.

# Enforce SSE-KMS on all new S3 objects
aws s3api put-bucket-policy \
  --bucket my-secure-bucket \
  --policy '{
    "Statement": [{
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::my-secure-bucket/*",
      "Condition": {
        "StringNotEquals": {
          "s3:x-amz-server-side-encryption": "aws:kms"
        }
      }
    }]
  }'

# Set default encryption for bucket
aws s3api put-bucket-encryption \
  --bucket my-secure-bucket \
  --server-side-encryption-configuration '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"aws:kms","KMSMasterKeyID":"alias/my-key"}}]}'

AWS Certificate Manager (ACM)

AWS Certificate Manager (ACM) fournit, gère et renouvelle automatiquement les certificats SSL/TLS pour les services AWS, sans frais. Les certificats ACM peuvent être utilisés avec ALB, NLB, CloudFront, API Gateway et AppSync. ACM gère automatiquement le cycle de vie des certificats : il les renouvelle 60 jours avant leur expiration et déploie le renouvellement de manière transparente. Vous pouvez demander des certificats pour les domaines que vous possédez (validés par DNS ou par e-mail) ou importer des certificats tiers. Les certificats ACM ne sont NOT pas téléchargeables : ils sont liés au service AWS auquel ils sont associés.

# Request a public ACM certificate
aws acm request-certificate \
  --domain-name app.example.com \
  --subject-alternative-names '*.example.com' \
  --validation-method DNS

# ACM returns a CNAME record to add to Route 53
# Add the CNAME -> ACM validates domain ownership
# Certificate is issued and auto-renews annually

# Attach to ALB listener (HTTPS:443)
aws elbv2 create-listener \
  --load-balancer-arn <ALB-ARN> \
  --protocol HTTPS --port 443 \
  --certificates CertificateArn=arn:aws:acm:us-east-1:123:certificate/abc \
  --default-actions Type=forward,TargetGroupArn=<TG-ARN>

ACM Private Certificate Authority

ACM Private CA (Certificate Authority) vous permet de créer une hiérarchie de CA privée entièrement gérée pour émettre des certificats destinés aux ressources internes — instances EC2, conteneurs, interfaces de programmation internes et appareils IoT. Contrairement aux certificats ACM publics (utilisés avec les services accessibles depuis Internet), les certificats d’une CA privée peuvent être émis pour n’importe quel nom d’hôte ou adresse IP interne. Utilisez Private CA pour : le TLS mutuel (mTLS) entre microservices, l’authentification par certificat pour les VPN et les exigences de conformité liées à la PKI interne. Private CA coûte 400 $ par mois pour la CA, auxquels s’ajoutent 0,75 $ par certificat émis.

# Create ACM Private Certificate Authority
aws acm-pca create-certificate-authority \
  --certificate-authority-type ROOT \
  --certificate-authority-configuration '{
    "KeyAlgorithm": "RSA_2048",
    "SigningAlgorithm": "SHA256WITHRSA",
    "Subject": {
      "Country": "US",
      "Organization": "Example Corp",
      "CommonName": "Example Corp Internal CA"
    }
  }'

# Issue certificate from private CA
aws acm request-certificate \
  --domain-name internal-service.example.internal \
  --certificate-authority-arn arn:aws:acm-pca:us-east-1:123:certificate-authority/xxx

Chiffrement EBS et RDS

Pour le chiffrement des volumes EBS, activez-le lors de la création du volume (ou copiez un volume existant en activant le chiffrement). Toutes les données du volume, y compris les instantanés, sont chiffrées à l’aide de la clé KMS que vous spécifiez. Le chiffrement EBS est transparent pour le système d’exploitation : aucune modification de l’application n’est nécessaire. Pour le chiffrement RDS, activez-le lors de la création de l’instance de base de données ; vous ne pouvez pas chiffrer directement une instance RDS existante qui ne l’est pas. Solution de contournement : créez un instantané chiffré à partir d’une instance non chiffrée, puis restaurez-le sur une nouvelle instance chiffrée. Les instantanés EBS et RDS chiffrés restent chiffrés lorsqu’ils sont copiés.

# Enable account-level EBS default encryption
aws ec2 enable-ebs-encryption-by-default
aws ec2 modify-ebs-default-kms-key-id \
  --kms-key-id alias/prod-ebs-key

# Encrypt an existing unencrypted RDS instance:
# 1. Create unencrypted snapshot
aws rds create-db-snapshot \
  --db-instance-identifier mydb \
  --db-snapshot-identifier mydb-plain-snapshot

# 2. Copy snapshot with encryption
aws rds copy-db-snapshot \
  --source-db-snapshot-identifier mydb-plain-snapshot \
  --target-db-snapshot-identifier mydb-encrypted-snapshot \
  --kms-key-id alias/prod-db-key

Chiffrement côté Client ou côté serveur

Comprendre la distinction entre le chiffrement côté serveur et le chiffrement côté Client est important pour l’examen SAA-C03. Chiffrement côté serveur : AWS chiffre les données après les avoir reçues et les déchiffre avant de les transmettre ; les données sont en clair entre votre application et AWS. Chiffrement côté Client : vous chiffrez les données avant de les envoyer à AWS ; AWS ne stocke que le texte chiffré et ne voit jamais les données en clair. Utilisez le chiffrement côté Client pour les données les plus sensibles lorsque vous ne pouvez pas faire confiance au fournisseur cloud pour gérer les données en clair, par exemple les dossiers médicaux ou les données financières soumises à des réglementations strictes.

# Client-side encryption with AWS Encryption SDK
# (conceptual Python example)

# 1. Application encrypts data locally using KMS DEK
# from aws_encryption_sdk import KmsKeyProvider, encrypt

# key_provider = KmsKeyProvider(key_ids=['alias/my-key'])
# ciphertext, _ = encrypt(
#     source=b'Sensitive patient data',
#     key_provider=key_provider
# )

# 2. Send ciphertext to S3
# s3.put_object(Bucket='hipaa-data', Key='record.enc', Body=ciphertext)

# AWS only stores ciphertext - cannot decrypt without your key policy

Accès KMS entre comptes

Les clés KMS peuvent être partagées entre des comptes AWS pour les scénarios de chiffrement entre comptes. Par exemple, si l’application du compte A écrit des données chiffrées dans un compartiment S3 appartenant au compte B, la clé KMS du compte A doit autoriser le principal du compte B à l’utiliser. Configurez la politique de clé KMS dans le compte A afin d’accorder l’accès entre comptes, puis créez une politique IAM dans le compte B pour autoriser le rôle à utiliser la clé du compte A. Ce modèle est courant dans les architectures de partage de données et les architectures multi-comptes où un compte central gère les clés de chiffrement.

# KMS key policy: allow cross-account access
# (in Account A's key policy)
{
  'Sid': 'Allow Account B to use this key',
  'Effect': 'Allow',
  'Principal': {
    'AWS': 'arn:aws:iam::999999999999:root'
  },
  'Action': [
    'kms:Encrypt',
    'kms:Decrypt',
    'kms:ReEncrypt*',
    'kms:GenerateDataKey*',
    'kms:DescribeKey'
  ],
  'Resource': '*'
}

# Account B IAM policy also needed to allow the role to use it

Vérification rapide

Évaluez votre compréhension des concepts AWS Solutions Architect (SAA-C03) abordés dans cette leçon.

Récapitulatif de la leçon

Dans cette leçon, vous avez appris que : KMS gère les clés de chiffrement avec la protection HSM et prend en charge les CMK pour un contrôle d’accès précis et des pistes d’audit, ACM fournit et renouvelle automatiquement les certificats TLS pour les services AWS sans frais, et le chiffrement peut être appliqué côté serveur (KMS) ou côté Client, le côté serveur étant le modèle le plus courant pour les charges de travail natives AWS. Imposez le chiffrement à l’aide de politiques de compartiment qui refusent les opérations non chiffrées. Nous allons maintenant découvrir GuardDuty, Inspector et Macie.

Questions Fréquemment Posées

La leçon « KMS, ACM et modèles de chiffrement » est-elle gratuite ?

Oui — le texte complet de « KMS, ACM et modèles de chiffrement » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours Cloud & IT Cert Prep, passe à CoddyKit PRO. Le cours Cloud & IT Cert Prep comprend 4 leçons au total.

Qu'est-ce que j'apprendrai dans « KMS, ACM et modèles de chiffrement » ?

Gérez les clés de chiffrement avec AWS KMS, fournissez et renouvelez les certificats TLS avec ACM, puis choisissez entre le chiffrement côté client, côté serveur et en transit. Tu pratiques Cloud & IT Cert Prep avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.

Dois-je avoir de l'expérience pour commencer Cloud & IT Cert Prep ?

Aucune expérience préalable n'est requise. Cloud & IT Cert Prep sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 1 sur 4.

Combien de temps prend la leçon « KMS, ACM et modèles de chiffrement » ?

La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.

Peux-tu écrire et exécuter du code dans cette leçon Cloud & IT Cert Prep ?

Oui. Chaque leçon Cloud & IT Cert Prep inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.

Toutes les leçons de ce cours

← Retour à Cloud & IT Cert Prep