Différences

Ci-dessous, les différences entre deux révisions de la page.

--- eadl:bloc4:fm4:td3 [2026/06/24 07:55] – [1. Analyse de l'existant] jcheron
+++ eadl:bloc4:fm4:td3 [2026/06/25 03:35] (Version actuelle) – jcheron
@@ Ligne 5: / Ligne 5: @@
   * Supprimer les secrets en clair dans une infrastructure Terraform
   * Utiliser AWS Secrets Manager pour stocker des identifiants sensibles
-  * Activer le chiffrement des données au repos sur RDS et S3
+  * Créer et utiliser une clé KMS Customer Managed Key
+  * Activer le chiffrement des données au repos sur RDS et S3 avec KMS
   * Comprendre la différence entre chiffrement au repos et en transit
   * Mettre en place une traçabilité avec CloudTrail
   * Identifier une action suspecte via les logs
+  * Récupérer des ressources existantes via des data sources AWS
 ===== Contexte =====
@@ Ligne 18: / Ligne 20: @@
 Un nouvel audit de sécurité interne est réalisé.
-Trois failles critiques sont identifiées malgré les corrections du TD2 :
+Quatre failles critiques sont identifiées malgré les corrections du TD2 :
   * le mot de passe de la base de données est stocké en clair dans `instances.tf`
   * la base de données RDS n'est pas chiffrée au repos
+  * le bucket S3 applicatif n'est pas chiffré
   * aucune trace des actions réalisées sur le compte AWS n'est conservée
-Ces trois points constituent des non-conformités bloquantes pour toute certification de sécurité (ISO 27001, SOC 2, RGPD).
+Ces points constituent des non-conformités bloquantes pour toute certification de sécurité (ISO 27001, SOC 2, RGPD).
-Votre mission est de corriger ces trois failles en prolongeant l'infrastructure du TD2.
+Votre mission est de corriger ces failles en prolongeant l'infrastructure du TD2.
 ===== Pré-requis =====
   * Projet Terraform du TD2 déployé et fonctionnel
+  * Ressources TD2 taguées avec `Name = "td2-vpc"`, `Name = "td2-private"`, etc.
   * ALB opérationnel, Security Groups en place
-  * Accès AWS avec droits suffisants : IAM, Secrets Manager, S3, RDS, CloudTrail
+  * Accès AWS avec droits suffisants : IAM, Secrets Manager, KMS, S3, RDS, CloudTrail
   * Terraform en version 1.5 ou supérieure
 ===== Structure du projet =====
-Le TD3 s'appuie sur les ressources existantes du TD2 et ajoute trois nouveaux modules.
+Le TD3 est un projet Terraform indépendant.
-<sxh bash;gutter:false>
+Il ne modifie pas le code du TD2.
-td3/
-├── main.tf
-├── variables.tf
-├── outputs.tf
-├── providers.tf
-└── modules/
-    ├── secrets/
-    │   └── main.tf
-    ├── database/
-    │   └── main.tf
-    ├── storage/
-    │   └── main.tf
-    └── logging/
-        └── main.tf
-</sxh>
-Le dossier `td2/` n'est pas modifié directement.
+Il récupère les ressources existantes via des data sources AWS interrogeant l'API par tags.
-Les ressources existantes du TD2 sont récupérées via des data sources Terraform.
+Fichier : `td3/structure.txt`
+<sxh bash>
+tp-aws/
+├── td1/                  # IAM – roles, policies
+├── td2/                  # Réseau – VPC, subnets, ALB, Security Groups
+└── td3/                  # Secrets, KMS, chiffrement, logs
+    ├── main.tf
+    ├── variables.tf
+    ├── outputs.tf
+    └── modules/
+        ├── secrets/
+        │   ├── main.tf
+        │   ├── variables.tf
+        │   └── outputs.tf
+        ├── kms/
+        │   ├── main.tf
+        │   ├── variables.tf
+        │   └── outputs.tf
+        ├── storage/
+        │   ├── main.tf
+        │   ├── variables.tf
+        │   └── outputs.tf
+        └── logging/
+            ├── main.tf
+            ├── variables.tf
+            └── outputs.tf
+</sxh>
-<WRAP round question>
+===== 1. Récupération des ressources du TD2 =====
-Pourquoi utilise-t-on des data sources plutôt que de copier les ressources du TD2 dans TD3 ?
-Que se passerait-il si on déclarait une deuxième fois la même ressource avec le même nom ?
+Objectif : comprendre comment un projet Terraform peut interroger une infrastructure existante sans accéder à son state.
-</WRAP>
-===== 1. Analyse de l'existant =====
+TD3 utilise des data sources AWS natifs.
-<WRAP round todo>
+Ces data sources envoient des requêtes directement à l'API AWS et filtrent les ressources par tags.
-Ouvrir le fichier `td2/network/instances.tf`.
-Localiser la ressource `aws_db_instance.db`.
+Cela suppose que les ressources TD2 ont été correctement taguées.
-</WRAP>
 <WRAP round question>
-Relever les trois problèmes de sécurité présents dans cette ressource.
+Pourquoi TD3 ne peut-il pas utiliser directement les outputs du TD2 sans configuration supplémentaire ?
-Pour chaque problème, indiquer :
+Quelle est la différence entre un data source AWS et un `terraform_remote_state` ?
-  * ce qui est en cause dans le code
-  * ce qu'un attaquant ou un développeur malveillant pourrait faire
-  * si ce problème est visible dans Git
 </WRAP>
-<WRAP round question>
+Fichier : `td3/main.tf`
-Le fichier `instances.tf` est versionné dans Git.
+<sxh js>
+provider "aws" {
+  region = "eu-west-3"
+}
-Un développeur a poussé ce fichier il y a trois mois sur le dépôt de l'équipe.
+# Récupération du VPC créé dans TD2
+data "aws_vpc" "main" {
+  tags = {
+    Name = "td2-vpc"
+  }
+}
-Le mot de passe a été changé depuis, mais il reste dans l'historique Git.
+# Récupération du subnet privé créé dans TD2
+data "aws_subnet" "private" {
+  tags = {
+    Name = "td2-private"
+  }
+}
-Comment retrouver ce mot de passe dans l'historique Git ?
+# Récupération du subnet privé secondaire créé dans TD2
+data "aws_subnet" "private_b" {
+  tags = {
+    Name = "td2-private-b"
+  }
+}
-Pourquoi changer le mot de passe ne suffit-il pas si le fichier a déjà été commité ?
+# Récupération du Security Group RDS créé dans TD2
+data "aws_security_group" "rds" {
+  tags = {
+    Name = "td2-sg-rds"
+  }
+}
+# Récupération du Security Group de l'application créé dans TD2
+data "aws_security_group" "app" {
+  tags = {
+    Name = "td2-sg-app"
+  }
+}
+</sxh>
+<WRAP round todo>
+Vérifier dans le code TD2 que chaque ressource est bien taguée avec les valeurs attendues ci-dessus.
+Si un tag est absent ou différent, le data source échouera avec une erreur `no matching resource found`.
+Corriger les tags dans TD2 si nécessaire avant de poursuivre.
 </WRAP>
 <WRAP round question>
-La ressource `aws_db_instance.db` dans le TD2 ne contient pas le paramètre `storage_encrypted`.
+Que se passe-t-il si deux ressources AWS portent le même tag `Name` dans la même région ?
-Quelle est la valeur par défaut de ce paramètre dans AWS ?
-Que signifie concrètement une base non chiffrée au repos ?
+Quel comportement Terraform adopte-t-il dans ce cas ?
 </WRAP>
-===== 2. Declaration des providers =====
+===== 2. Identification du problème =====
-Le module `storage` utilisera le provider `random` pour générer des suffixes uniques sur les noms de buckets S3.
+Objectif : identifier les secrets en clair dans l'infrastructure TD2.
-Les noms de buckets S3 sont globaux sur AWS : deux comptes ne peuvent pas avoir le même nom.
+Voici un extrait du fichier `instances.tf` tel qu'il existe après le TD2.
-<WRAP round todo>
+Fichier : `td2/instances.tf` — lecture seule, ne pas modifier
-Créer le fichier de déclaration des providers.
+<sxh js>
-</WRAP>
+resource "aws_db_instance" "db" {
+  identifier        = "td2-db"
+  engine            = "postgres"
+  instance_class    = "db.t3.micro"
+  allocated_storage = 20
-Fichier : `td3/providers.tf`
+  username = "admin"
-<sxh hcl>
+  password = "S3cr3tP@ss!"
-terraform {
-  required_providers {
-    aws = {
-      source  = "hashicorp/aws"
-      version = "~> 5.0"
-    }
-    random = {
-      source  = "hashicorp/random"
-      version = "~> 3.0"
-    }
-  }
-}
-provider "aws" {
+  skip_final_snapshot = true
-  region = "eu-west-3"
 }
 </sxh>
-<WRAP round help>
+<WRAP round question>
-Pourquoi faut-il déclarer explicitement le provider `random` alors qu'il ne communique pas avec AWS ?
+Identifier au moins trois problèmes de sécurité dans ce bloc.
-Que se passe-t-il si on l'utilise sans le déclarer dans le bloc `required_providers` ?
+Pour chaque problème, expliquer la conséquence concrète en cas de fuite du fichier `.tf` ou du state Terraform.
 </WRAP>
-===== 3. Declaration des variables =====
+<WRAP round todo>
+Ne pas appliquer ce fichier tel quel.
-Le mot de passe initial doit être injecté au moment de l'exécution.
+Ne pas modifier le TD2 non plus.
-Il ne doit jamais apparaître dans un fichier `.tf`.
+La correction se fait uniquement dans TD3.
-<WRAP round todo>
-Créer le fichier de variables.
 </WRAP>
-Fichier : `td3/variables.tf`
+===== 3. Création du module secrets =====
-<sxh hcl>
-variable "db_initial_password" {
+Objectif : stocker les identifiants de la base de données dans AWS Secrets Manager.
-  description = "Mot de passe initial de la base de donnees. Injecte via tfvars ou variable d'environnement."
+Fichier : `td3/modules/secrets/variables.tf`
+<sxh js>
+variable "secret_name" {
+  type        = string
+  description = "Nom du secret dans Secrets Manager"
+  default     = "td3/db/credentials"
+}
+variable "db_username" {
+  type        = string
+  description = "Nom d'utilisateur de la base de données"
+  default     = "td3admin"
+}
+variable "db_password" {
   type        = string
+  description = "Mot de passe de la base de données"
   sensitive   = true
 }
 </sxh>
-<WRAP round todo>
+Fichier : `td3/modules/secrets/main.tf`
-Créer le fichier de valeurs local pour les tests.
+<sxh js>
-</WRAP>
+resource "aws_secretsmanager_secret" "db_credentials" {
+  name                    = var.secret_name
+  recovery_window_in_days = 7
-Fichier : `td3/terraform.tfvars`
+  tags = {
-<sxh hcl>
+    Name = "td3-secret-db"
-db_initial_password = "InitialPass123!"
+    TD   = "td3"
+  }
+}
+resource "aws_secretsmanager_secret_version" "db_credentials" {
+  secret_id = aws_secretsmanager_secret.db_credentials.id
+  secret_string = jsonencode({
+    username = var.db_username
+    password = var.db_password
+  })
+}
 </sxh>
-<WRAP round todo>
+Fichier : `td3/modules/secrets/outputs.tf`
-Créer le fichier `.gitignore` pour protéger les fichiers sensibles.
+<sxh js>
-</WRAP>
+output "secret_arn" {
+  value       = aws_secretsmanager_secret.db_credentials.arn
+  description = "ARN du secret contenant les identifiants de la base de données"
+}
-Fichier : `td3/.gitignore`
+output "secret_name" {
-<sxh bash>
+  value       = aws_secretsmanager_secret.db_credentials.name
-*.tfvars
+  description = "Nom du secret dans Secrets Manager"
-*.tfstate
+}
-*.tfstate.backup
-.terraform/
-.terraform.lock.hcl
 </sxh>
-<WRAP round help>
+<WRAP round question>
-Le paramètre `sensitive = true` est déclaré sur la variable.
+Le paramètre `sensitive = true` sur la variable `db_password` masque la valeur dans les logs Terraform.
-Est-ce que cela empêche le mot de passe d'apparaître dans le fichier `terraform.tfstate` ?
+Cela signifie-t-il que le mot de passe est chiffré dans le state Terraform ?
-Pourquoi le state file est-il également considéré comme un fichier sensible ?
+Où le mot de passe est-il stocké en clair malgré ce paramètre ?
 </WRAP>
-<WRAP round help>
+<WRAP round question>
-En production, on n'utilise pas de fichier `terraform.tfvars`.
+Le paramètre `recovery_window_in_days = 7` signifie que le secret n'est pas supprimé immédiatement.
-Comment injecter une valeur sensible sans fichier, uniquement via le terminal ?
+Pourquoi AWS impose-t-il cette fenêtre de récupération par défaut ?
-Quelle variable d'environnement Terraform lit-il automatiquement pour la variable `db_initial_password` ?
+Comment forcer la suppression immédiate si nécessaire, et dans quel cas cela est-il risqué ?
 </WRAP>
-===== 4. Recuperation des ressources existantes du TD2 =====
+===== 4. Erreur volontaire – secret introuvable =====
-Plutôt que de recréer les ressources, on les référence via des data sources.
+Objectif : comprendre ce qui se passe quand une application tente de lire un secret inexistant.
-<WRAP round todo>
+Voici un data source intentionnellement incorrect.
-Créer le fichier principal du TD3.
-</WRAP>
-Fichier : `td3/main.tf`
+Fichier : `td3/debug/wrong_secret.tf` — ne pas appliquer
-<sxh hcl>
+<sxh js>
-# Recuperation du VPC existant du TD2
+data "aws_secretsmanager_secret" "db_credentials" {
-data "aws_vpc" "td2" {
+  name = "td3/db/credential"
-  filter {
-    name   = "tag:Name"
-    values = ["td2-vpc"]
-  }
-}
-# Recuperation du Security Group du backend TD2
-data "aws_security_group" "backend" {
-  filter {
-    name   = "tag:Name"
-    values = ["backend-sg"]
-  }
-  vpc_id = data.aws_vpc.td2.id
-}
-# Recuperation du subnet group RDS existant
-data "aws_db_subnet_group" "main" {
-  name = "td2-db-subnet-group"
 }
 </sxh>
-<WRAP round help>
+<WRAP round todo>
-Une data source ne crée rien dans AWS.
+Lire le code ci-dessus sans l'appliquer.
-Que fait Terraform quand il rencontre un bloc `data` lors d'un `terraform plan` ?
+Identifier l'erreur sans regarder la réponse ci-dessous.
-Que se passe-t-il si la ressource référencée n'existe pas ?
+Écrire la correction avant de lire la suite.
 </WRAP>
-===== 5. Module secrets =====
+Le nom du secret dans Secrets Manager est `td3/db/credentials` avec un `s` final.
-Objectif : stocker le mot de passe dans AWS Secrets Manager, pas dans le code.
+Le data source ci-dessus cherche `td3/db/credential` sans `s`.
-<WRAP round todo>
+L'erreur retournée par Terraform sera :
-Créer le module de gestion des secrets.
+Fichier : `td3/debug/wrong_secret_error.txt`
+<sxh bash>
+Error: reading Secrets Manager Secret: ResourceNotFoundException:
+Secrets Manager can't find the specified secret.
+</sxh>
+<WRAP round question>
+Ce type d'erreur peut-il survenir en production alors que le secret existe bien ?
+Citer au moins deux situations réelles où cette erreur peut apparaître même si le nom est correct.
 </WRAP>
-Fichier : `td3/modules/secrets/main.tf`
+===== 5. Récupération du secret dans RDS =====
-<sxh hcl>
-variable "db_password" {
-  type      = string
-  sensitive = true
-}
-resource "aws_secretsmanager_secret" "db_credentials" {
+Objectif : utiliser le secret Secrets Manager dans la configuration RDS plutôt que des valeurs en clair.
-  name                    = "td3/database/credentials"
-  description             = "Identifiants de la base de donnees TD3"
-  recovery_window_in_days = 0
-}
-resource "aws_secretsmanager_secret_version" "db_credentials" {
+Fichier : `td3/modules/secrets/main.tf` — ajouter après les ressources existantes
+<sxh js>
+data "aws_secretsmanager_secret_version" "db_credentials" {
   secret_id = aws_secretsmanager_secret.db_credentials.id
-  secret_string = jsonencode({
+  depends_on = [aws_secretsmanager_secret_version.db_credentials]
-    username = "td3admin"
-    password = var.db_password
-  })
 }
-output "secret_arn" {
+locals {
-  description = "ARN du secret a transmettre au module database"
+  db_secret = jsondecode(
-  value       = aws_secretsmanager_secret.db_credentials.arn
+    data.aws_secretsmanager_secret_version.db_credentials.secret_string
+  )
 }
 </sxh>
-<WRAP round help>
+<WRAP round question>
-Le secret est stocké au format JSON avec deux champs : `username` et `password`.
+Pourquoi utilise-t-on `depends_on` ici ?
-Pourquoi utilise-t-on un objet JSON plutôt qu'une simple chaîne de caractères ?
-Quel avantage si on doit ajouter le port ou le nom de la base plus tard ?
+Que se passerait-il si Terraform tentait de lire le secret avant que la version soit créée ?
 </WRAP>
-<WRAP round help>
+===== 6. Création du module KMS =====
-Le paramètre `recovery_window_in_days = 0` supprime le secret immédiatement lors d'un `terraform destroy`.
-Quelle est la valeur par défaut d'AWS pour ce paramètre ?
+Objectif : créer une clé de chiffrement gérée par le client (Customer Managed Key) pour chiffrer les données au repos.
-Pourquoi cette valeur par défaut existe-t-elle en production ?
+<WRAP round question>
-</WRAP>
+Avant de créer la clé, répondre aux questions suivantes :
-<WRAP round todo>
+Quelle est la différence entre une clé AWS managée et une CMK (Customer Managed Key) ?
-Ajouter l'appel au module dans le fichier principal.
+Dans quel cas une CMK est-elle obligatoire plutôt que recommandée ?
 </WRAP>
-Fichier : `td3/main.tf` — ajouter après les data sources
+Fichier : `td3/modules/kms/variables.tf`
-<sxh hcl>
+<sxh js>
-module "secrets" {
+variable "key_alias" {
-  source      = "./modules/secrets"
+  type        = string
-  db_password = var.db_initial_password
+  description = "Alias de la clé KMS"
+  default     = "alias/td3-key"
+}
+variable "account_id" {
+  type        = string
+  description = "ID du compte AWS courant"
 }
 </sxh>
-===== 6. Probleme volontaire : ordre d'execution =====
+Fichier : `td3/modules/kms/main.tf`
+<sxh js>
+data "aws_caller_identity" "current" {}
-<WRAP round todo>
+resource "aws_kms_key" "main" {
-Avant d'aller plus loin, tenter d'écrire à la main un bloc `data` qui lirait le secret qu'on vient de créer :
+  description             = "Clé KMS TD3 – chiffrement RDS et S3"
+  deletion_window_in_days = 10
+  enable_key_rotation     = true
+  policy = jsonencode({
+    Version = "2012-10-17"
+    Statement = [
+      {
+        Sid    = "EnableRootAccess"
+        Effect = "Allow"
+        Principal = {
+          AWS = "arn:aws:iam::${var.account_id}:root"
+        }
+        Action   = "kms:*"
+        Resource = "*"
+      }
+    ]
+  })
+  tags = {
+    Name = "td3-kms-key"
+    TD   = "td3"
+  }
+}
-<sxh hcl>
+resource "aws_kms_alias" "main" {
-data "aws_secretsmanager_secret_version" "test" {
+  name          = var.key_alias
-  secret_id = "td3/database/credentials"
+  target_key_id = aws_kms_key.main.key_id
 }
 </sxh>
-Ajouter ce bloc temporairement dans `main.tf` et lancer :
+Fichier : `td3/modules/kms/outputs.tf`
+<sxh js>
+output "key_arn" {
+  value       = aws_kms_key.main.arn
+  description = "ARN de la clé KMS"
+}
-<sxh bash>
+output "key_id" {
-terraform plan
+  value       = aws_kms_key.main.key_id
+  description = "ID de la clé KMS"
+}
 </sxh>
-</WRAP>
-<WRAP round help>
+<WRAP round question>
-Que se passe-t-il lors du plan ?
+Le paramètre `enable_key_rotation = true` active la rotation automatique de la clé.
-Terraform signale-t-il une erreur, et si oui, laquelle ?
+Que signifie concrètement la rotation d'une clé KMS ?
-Pourquoi Terraform ne peut-il pas garantir que le secret existe au moment où la data source est évaluée ?
+Les données chiffrées avec l'ancienne version de la clé deviennent-elles inaccessibles après rotation ?
 </WRAP>
-<WRAP round help>
+<WRAP round question>
-Quelle est la différence fondamentale entre un bloc `resource` et un bloc `data` dans le cycle d'exécution Terraform ?
+La policy KMS donne accès à `arn:aws:iam::ACCOUNT_ID:root`.
-Lequel est évalué lors de la phase de lecture, avant toute création ?
+Pourquoi cette entrée est-elle obligatoire dans une policy KMS ?
-</WRAP>
-<WRAP round todo>
+Que se passe-t-il si elle est absente ?
-Supprimer ce bloc temporaire avant de continuer.
 </WRAP>
-===== 7. Module database =====
+===== 7. Création du module storage =====
-Objectif : remplacer la ressource RDS du TD2 par une version sécurisée.
+Objectif : déployer une instance RDS chiffrée et un bucket S3 chiffré en utilisant la clé KMS du module précédent.
-La dépendance entre le secret et la base est gérée implicitement via le passage de l'ARN en variable.
+Fichier : `td3/modules/storage/variables.tf`
+<sxh js>
+variable "kms_key_arn" {
+  type        = string
+  description = "ARN de la clé KMS utilisée pour le chiffrement"
+}
-Terraform comprend qu'il doit créer le secret avant de lire son contenu car la valeur vient d'un output du module `secrets`.
+variable "db_username" {
-<WRAP round todo>
-Créer le module base de données.
-</WRAP>
-Fichier : `td3/modules/database/main.tf`
-<sxh hcl>
-variable "secret_arn" {
   type        = string
-  description = "ARN du secret contenant les identifiants de la base"
+  description = "Nom d'utilisateur transmis depuis Secrets Manager"
 }
-variable "db_subnet_group_name" {
+variable "db_password" {
   type        = string
-  description = "Nom du subnet group RDS existant"
+  description = "Mot de passe transmis depuis Secrets Manager"
+  sensitive   = true
 }
-variable "vpc_security_group_ids" {
+variable "subnet_ids" {
   type        = list(string)
-  description = "Liste des Security Group IDs autorises a acceder a la base"
+  description = "Liste des IDs de subnets privés récupérés depuis TD2"
 }
-data "aws_secretsmanager_secret_version" "db_credentials" {
+variable "security_group_id" {
-  secret_id = var.secret_arn
+  type        = string
+  description = "ID du Security Group RDS récupéré depuis TD2"
 }
-locals {
+variable "bucket_name" {
-  db_creds = jsondecode(data.aws_secretsmanager_secret_version.db_credentials.secret_string)
+  type        = string
+  description = "Nom du bucket S3 applicatif"
 }
+</sxh>
-resource "aws_db_instance" "main" {
+Fichier : `td3/modules/storage/main.tf`
-  identifier        = "td3-database"
+<sxh js>
+resource "aws_db_subnet_group" "main" {
+  name       = "td3-db-subnet-group"
+  subnet_ids = var.subnet_ids
+  tags = {
+    Name = "td3-db-subnet-group"
+    TD   = "td3"
+  }
+}
+resource "aws_db_instance" "db" {
+  identifier        = "td3-db"
   engine            = "postgres"
   engine_version    = "15"
@@ Ligne 381: / Ligne 470: @@
   allocated_storage = 20
-  db_name  = "td3app"
+  username = var.db_username
-  username = local.db_creds["username"]
+  password = var.db_password
-  password = local.db_creds["password"]
-  db_subnet_group_name   = var.db_subnet_group_name
+  db_subnet_group_name   = aws_db_subnet_group.main.name
-  vpc_security_group_ids = var.vpc_security_group_ids
+  vpc_security_group_ids = [var.security_group_id]
+  storage_encrypted = true
+  kms_key_id        = var.kms_key_arn
-  storage_encrypted   = true
   skip_final_snapshot = true
   tags = {
-    Name = "td3-database"
+    Name = "td3-db"
+    TD   = "td3"
   }
 }
-output "db_endpoint" {
+resource "aws_s3_bucket" "app" {
-  description = "Endpoint de connexion a la base de donnees"
+  bucket = var.bucket_name
-  value       = aws_db_instance.main.endpoint
-}
-</sxh>
-<WRAP round todo>
-Ajouter l'appel au module database dans le fichier principal.
-</WRAP>
-Fichier : `td3/main.tf` — ajouter après le module secrets
-<sxh hcl>
-module "database" {
-  source      = "./modules/database"
-  secret_arn  = module.secrets.secret_arn
-  db_subnet_group_name   = data.aws_db_subnet_group.main.name
-  vpc_security_group_ids = [data.aws_security_group.backend.id]
-}
-</sxh>
-<WRAP round help>
-La valeur `module.secrets.secret_arn` est transmise en variable au module database.
-Terraform en déduit-il automatiquement que le module `database` dépend du module `secrets` ?
-Dans quel cas faudrait-il ajouter un `depends_on` explicite malgré tout ?
-</WRAP>
-<WRAP round help>
-Le paramètre `storage_encrypted = true` a été ajouté.
-Que protège exactement ce chiffrement ?
-Ce chiffrement protège-t-il les données qui transitent entre le backend et la base de données ?
-Quel mécanisme complémentaire protège les données en transit vers RDS ?
-</WRAP>
-===== 8. Module storage =====
-Objectif : créer un bucket S3 avec chiffrement et blocage des accès publics.
-<WRAP round todo>
-Créer le module de stockage.
-</WRAP>
-Fichier : `td3/modules/storage/main.tf`
-<sxh hcl>
-resource "random_id" "bucket_suffix" {
-  byte_length = 4
-}
-resource "aws_s3_bucket" "secure_data" {
-  bucket = "td3-secure-data-${random_id.bucket_suffix.hex}"
   tags = {
-    Name = "td3-secure-data"
+    Name = "td3-s3-app"
+    TD   = "td3"
   }
 }
-resource "aws_s3_bucket_server_side_encryption_configuration" "secure_data" {
+resource "aws_s3_bucket_server_side_encryption_configuration" "app" {
-  bucket = aws_s3_bucket.secure_data.id
+  bucket = aws_s3_bucket.app.id
   rule {
     apply_server_side_encryption_by_default {
-      sse_algorithm = "AES256"
+      sse_algorithm     = "aws:kms"
+      kms_master_key_id = var.kms_key_arn
     }
     bucket_key_enabled = true
@@ Ligne 468: / Ligne 508: @@
 }
-resource "aws_s3_bucket_public_access_block" "secure_data" {
+resource "aws_s3_bucket_public_access_block" "app" {
-  bucket = aws_s3_bucket.secure_data.id
+  bucket = aws_s3_bucket.app.id
   block_public_acls       = true
@@ Ligne 475: / Ligne 515: @@
   ignore_public_acls      = true
   restrict_public_buckets = true
-}
-output "bucket_name" {
-  description = "Nom du bucket S3 securise"
-  value       = aws_s3_bucket.secure_data.id
 }
 </sxh>
-<WRAP round todo>
+<WRAP round question>
-Ajouter l'appel au module storage dans le fichier principal.
+Le chiffrement `storage_encrypted = true` sur RDS protège-t-il les données en transit ou au repos ?
+Quel mécanisme protège les données en transit entre l'application et RDS ?
 </WRAP>
-Fichier : `td3/main.tf` — ajouter après le module database
+<WRAP round question>
-<sxh hcl>
+Le paramètre `bucket_key_enabled = true` est activé sur le bucket S3.
-module "storage" {
-  source = "./modules/storage"
-}
-</sxh>
-<WRAP round help>
+Rechercher dans la documentation AWS ce que cette option apporte.
-La configuration `apply_server_side_encryption_by_default` est activée.
-Que se passe-t-il si un développeur uploade un fichier sans spécifier de chiffrement dans son appel SDK ou CLI ?
+Quel est l'impact sur les coûts et les performances ?
-La configuration par défaut s'applique-t-elle automatiquement ?
 </WRAP>
-<WRAP round help>
+===== 8. Erreur volontaire – chiffrement impossible =====
-Les quatre paramètres `block_public_acls`, `block_public_policy`, `ignore_public_acls` et `restrict_public_buckets` sont tous activés.
-Les Security Groups du TD2 contrôlent déjà le trafic réseau vers les instances.
+Objectif : comprendre pourquoi RDS ne peut pas chiffrer une instance existante non chiffrée.
-Pourquoi bloquer également les accès publics au niveau du bucket S3 ?
+Imaginer le scénario suivant : une instance RDS existe déjà en production sans chiffrement, et un ingénieur ajoute `storage_encrypted = true` et `kms_key_id` dans le fichier Terraform, puis applique le changement.
-S3 est-il soumis aux Security Groups ?
+<WRAP round question>
+Avant de chercher la réponse, réfléchir à ce qui va se passer.
+Est-ce que Terraform va modifier l'instance en place ?
+Est-ce que le chiffrement peut être activé sur une instance RDS existante sans interruption ?
+Quelle est la procédure correcte dans ce cas ?
 </WRAP>
-===== 9. Module logging =====
+<WRAP round todo>
+Rechercher dans la documentation AWS RDS la section relative au chiffrement d'une instance existante.
-Objectif : tracer toutes les actions réalisées sur le compte AWS via CloudTrail.
+Décrire en cinq étapes la procédure à suivre pour migrer une instance non chiffrée vers une instance chiffrée.
+</WRAP>
-CloudTrail écrit ses logs dans un bucket S3 dédié.
+===== 9. Création du module logging =====
-AWS exige une policy bucket explicite pour autoriser CloudTrail à écrire.
+Objectif : activer CloudTrail pour conserver une trace de toutes les actions réalisées sur le compte AWS.
-Sans cette policy, la ressource `aws_cloudtrail` échoue au déploiement.
+Fichier : `td3/modules/logging/variables.tf`
+<sxh js>
+variable "bucket_name" {
+  type        = string
+  description = "Nom du bucket S3 destiné à recevoir les logs CloudTrail"
+}
-<WRAP round todo>
+variable "kms_key_arn" {
-Créer le module de logging.
+  type        = string
-</WRAP>
+  description = "ARN de la clé KMS pour chiffrer les logs CloudTrail"
+}
-Fichier : `td3/modules/logging/main.tf`
+variable "account_id" {
-<sxh hcl>
+  type        = string
-data "aws_caller_identity" "current" {}
+  description = "ID du compte AWS courant"
+}
+</sxh>
-resource "aws_s3_bucket" "cloudtrail_logs" {
+Fichier : `td3/modules/logging/main.tf`
-  bucket = "td3-cloudtrail-${data.aws_caller_identity.current.account_id}"
+<sxh js>
+resource "aws_s3_bucket" "cloudtrail" {
+  bucket = var.bucket_name
   tags = {
-    Name = "td3-cloudtrail-logs"
+    Name = "td3-s3-cloudtrail"
+    TD   = "td3"
   }
 }
-resource "aws_s3_bucket_public_access_block" "cloudtrail_logs" {
+resource "aws_s3_bucket_public_access_block" "cloudtrail" {
-  bucket = aws_s3_bucket.cloudtrail_logs.id
+  bucket = aws_s3_bucket.cloudtrail.id
   block_public_acls       = true
@@ Ligne 547: / Ligne 596: @@
 }
-resource "aws_s3_bucket_policy" "cloudtrail_logs" {
+resource "aws_s3_bucket_policy" "cloudtrail" {
-  bucket = aws_s3_bucket.cloudtrail_logs.id
+  bucket = aws_s3_bucket.cloudtrail.id
   policy = jsonencode({
@@ Ligne 560: / Ligne 609: @@
         }
         Action   = "s3:GetBucketAcl"
-        Resource = aws_s3_bucket.cloudtrail_logs.arn
+        Resource = aws_s3_bucket.cloudtrail.arn
       },
       {
@@ Ligne 569: / Ligne 618: @@
         }
         Action   = "s3:PutObject"
-        Resource = "${aws_s3_bucket.cloudtrail_logs.arn}/AWSLogs/${data.aws_caller_identity.current.account_id}/*"
+        Resource = "${aws_s3_bucket.cloudtrail.arn}/AWSLogs/${var.account_id}/*"
         Condition = {
           StringEquals = {
@@ Ligne 578: / Ligne 627: @@
     ]
   })
-  depends_on = [aws_s3_bucket_public_access_block.cloudtrail_logs]
 }
 resource "aws_cloudtrail" "main" {
-  name                          = "td3-audit-trail"
+  name                          = "td3-cloudtrail"
-  s3_bucket_name                = aws_s3_bucket.cloudtrail_logs.id
+  s3_bucket_name                = aws_s3_bucket.cloudtrail.id
   include_global_service_events = true
   is_multi_region_trail         = false
   enable_log_file_validation    = true
+  kms_key_id                    = var.kms_key_arn
   tags = {
-    Name = "td3-audit-trail"
+    Name = "td3-cloudtrail"
+    TD   = "td3"
   }
-  depends_on = [aws_s3_bucket_policy.cloudtrail_logs]
+  depends_on = [aws_s3_bucket_policy.cloudtrail]
 }
+</sxh>
-output "cloudtrail_name" {
+Fichier : `td3/modules/logging/outputs.tf`
-  description = "Nom du trail CloudTrail actif"
+<sxh js>
-  value       = aws_cloudtrail.main.name
+output "cloudtrail_arn" {
+  value       = aws_cloudtrail.main.arn
+  description = "ARN du trail CloudTrail"
 }
-</sxh>
-<WRAP round todo>
+output "cloudtrail_bucket" {
-Ajouter l'appel au module logging dans le fichier principal.
+  value       = aws_s3_bucket.cloudtrail.bucket
-</WRAP>
+  description = "Nom du bucket contenant les logs CloudTrail"
-Fichier : `td3/main.tf` — ajouter en dernier
-<sxh hcl>
-module "logging" {
-  source = "./modules/logging"
 }
 </sxh>
-<WRAP round help>
+<WRAP round question>
-La policy S3 contient deux instructions distinctes : `AWSCloudTrailAclCheck` et `AWSCloudTrailWrite`.
+Le paramètre `enable_log_file_validation = true` active la validation de l'intégrité des fichiers de logs.
-Pourquoi CloudTrail a-t-il besoin de lire l'ACL du bucket avant d'y écrire ?
+Quel problème cela permet-il de détecter ?
-Que se serait-il passé si on avait appliqué `aws_cloudtrail` sans cette policy ?
+Quel mécanisme technique AWS utilise-t-il pour garantir cette intégrité ?
 </WRAP>
-<WRAP round help>
+<WRAP round question>
-Le paramètre `enable_log_file_validation = true` est activé.
+CloudTrail trace les appels API AWS.
-Que génère AWS pour permettre cette validation ?
+Citer trois exemples d'actions tracées par CloudTrail dans le cadre de ce TD.
-Comment un administrateur peut-il vérifier qu'un fichier de log n'a pas été modifié ou supprimé ?
+Citer deux exemples d'actions qui ne sont pas tracées par CloudTrail.
 </WRAP>
-<WRAP round help>
+===== 10. Assemblage dans main.tf =====
-CloudTrail enregistre les appels API réalisés sur le compte AWS.
-Les modifications de Security Groups réalisées dans le TD2 via Terraform auraient-elles été enregistrées si CloudTrail avait été actif à ce moment ?
+Objectif : relier tous les modules entre eux et injecter les data sources TD2 dans les modules TD3.
-Quelle différence entre CloudTrail et VPC Flow Logs ?
+Fichier : `td3/variables.tf`
-</WRAP>
+<sxh js>
+variable "db_password" {
+  type        = string
+  description = "Mot de passe de la base de données – ne pas committer"
+  sensitive   = true
+}
-===== 10. Fichier outputs global =====
+variable "s3_app_bucket_name" {
+  type        = string
-<WRAP round todo>
+  description = "Nom du bucket S3 applicatif"
-Créer le fichier d'outputs du projet TD3.
+  default     = "td3-app-bucket-demo"
-</WRAP>
+}
-Fichier : `td3/outputs.tf`
+variable "s3_logs_bucket_name" {
-<sxh hcl>
+  type        = string
-output "db_endpoint" {
+  description = "Nom du bucket S3 pour les logs CloudTrail"
-  description = "Endpoint de la base de donnees TD3"
+  default     = "td3-cloudtrail-logs-demo"
-  value       = module.database.db_endpoint
 }
+</sxh>
-output "secure_bucket_name" {
+Fichier : `td3/main.tf` — compléter après les data sources
-  description = "Nom du bucket S3 securise"
+<sxh js>
-  value       = module.storage.bucket_name
+data "aws_caller_identity" "current" {}
+module "kms" {
+  source     = "./modules/kms"
+  account_id = data.aws_caller_identity.current.account_id
 }
-output "cloudtrail_name" {
+module "secrets" {
-  description = "Nom du trail CloudTrail actif"
+  source      = "./modules/secrets"
-  value       = module.logging.cloudtrail_name
+  db_username = "td3admin"
+  db_password = var.db_password
 }
-</sxh>
-===== 11. Deploiement complet =====
+module "storage" {
+  source = "./modules/storage"
-<WRAP round todo>
+  kms_key_arn = module.kms.key_arn
-Initialiser le projet et vérifier le plan avant d'appliquer.
-<sxh bash>
+  db_username = module.secrets.db_username
-cd td3/
+  db_password = module.secrets.db_password
-terraform init
-terraform plan
-terraform apply
-</sxh>
-Relever les outputs après application.
+  subnet_ids = [
-</WRAP>
+    data.aws_subnet.private.id,
+    data.aws_subnet.private_b.id
+  ]
-<WRAP round help>
+  security_group_id = data.aws_security_group.rds.id
-Lors du `terraform plan`, combien de ressources sont listées comme a créer ?
-Les data sources vers le TD2 apparaissent-elles dans le plan ?
+  bucket_name = var.s3_app_bucket_name
+}
-Que se passe-t-il si le VPC `td2-vpc` n'existe pas au moment du plan ?
+module "logging" {
-</WRAP>
+  source      = "./modules/logging"
+  bucket_name = var.s3_logs_bucket_name
+  kms_key_arn = module.kms.key_arn
+  account_id  = data.aws_caller_identity.current.account_id
+}
+</sxh>
-===== 12. Simulation d'un incident et lecture des logs =====
+<WRAP round question>
+Le module `secrets` expose `db_username` et `db_password` via ses outputs.
-Objectif : vérifier que CloudTrail trace bien les actions réalisées sur le compte.
+Regarder la définition des outputs dans `td3/modules/secrets/outputs.tf`.
-<WRAP round todo>
+Que faut-il ajouter sur l'output `db_password` pour que la valeur ne s'affiche pas dans le terminal lors d'un `terraform output` ?
-Modifier temporairement un Security Group du TD2 via Terraform.
+</WRAP>
-Par exemple, rouvrir le port 5432 sur `0.0.0.0/0` dans `td2/network/security_groups.tf`.
+Fichier : `td3/modules/secrets/outputs.tf` — ajouter les outputs manquants
+<sxh js>
+output "db_username" {
+  value       = var.db_username
+  description = "Nom d'utilisateur de la base de données"
+}
-Appliquer ce changement :
+output "db_password" {
+  value       = var.db_password
+  description = "Mot de passe de la base de données"
+  sensitive   = true
+}
+</sxh>
+===== 11. Déploiement et vérification =====
+Fichier : `td3/commandes/terraform.txt`
 <sxh bash>
-cd td2/
+# Se placer dans le dossier td3
-terraform apply
+cd tp-aws/td3
-</sxh>
-Attendre deux minutes.
+# Initialiser le projet
+terraform init
-Se connecter à la console AWS et naviguer vers :
+# Vérifier le plan – inspecter les ressources créées et les data sources résolus
+terraform plan -var="db_password=VotreMotDePasse123!"
-  CloudTrail > Event history
+# Appliquer
+terraform apply -var="db_password=VotreMotDePasse123!"
-Filtrer par nom d'événement : `AuthorizeSecurityGroupIngress`
+# Vérifier les outputs
-</WRAP>
+terraform output
-<WRAP round help>
+# Vérifier le secret dans AWS CLI
-L'événement est-il visible dans CloudTrail ?
+aws secretsmanager get-secret-value --secret-id td3/db/credentials --region eu-west-3
-Quelles informations sont disponibles dans le détail de l'événement :
+# Vérifier que le bucket S3 est bien chiffré
-  * quel utilisateur ou rôle IAM a réalisé l'action ?
+aws s3api get-bucket-encryption --bucket td3-app-bucket-demo --region eu-west-3
-  * depuis quelle adresse IP ?
-  * à quelle heure exactement ?
-  * quelle ressource a été modifiée ?
-</WRAP>
-<WRAP round help>
+# Vérifier que CloudTrail est actif
-Un Security Group du TD2 a été ouvert sur Internet par erreur un vendredi soir.
+aws cloudtrail get-trail-status --name td3-cloudtrail --region eu-west-3
+</sxh>
-L'équipe le découvre le lundi matin.
+<WRAP round todo>
+Après le déploiement, vérifier manuellement dans la console AWS :
-Comment CloudTrail permet-il de répondre aux questions suivantes sans CloudTrail et avec CloudTrail :
+  * Secrets Manager : le secret `td3/db/credentials` est visible et déchiffrable
-  * depuis combien de temps la faille est-elle ouverte ?
+  * KMS : la clé `alias/td3-key` est active avec rotation activée
-  * qui a fait la modification ?
+  * RDS : l'instance `td3-db` indique `Encrypted: Yes` dans ses propriétés
-  * s'agit-il d'une erreur ou d'un acte malveillant ?
+  * S3 : le bucket applicatif indique `SSE-KMS` dans ses propriétés de chiffrement
+  * CloudTrail : le trail `td3-cloudtrail` est actif et envoie des logs dans le bucket
 </WRAP>
+===== 12. Lecture des logs CloudTrail =====
+Objectif : naviguer dans les logs CloudTrail pour retrouver une action spécifique.
 <WRAP round todo>
-Remettre le Security Group du TD2 dans son état sécurisé après l'exercice.
+Dans la console AWS, ouvrir CloudTrail puis Event History.
-<sxh bash>
+Filtrer les événements par type `CreateSecret`.
-cd td2/
-terraform apply
-</sxh>
-</WRAP>
-<WRAP round help>
+Retrouver l'événement correspondant à la création du secret TD3.
-Pourquoi est-il important de conserver les logs CloudTrail pendant au moins un an ?
-Quelles obligations légales ou réglementaires peuvent imposer cette durée en France et en Europe ?
+Identifier les champs suivants dans l'événement :
+  * `userIdentity` : qui a réalisé l'action
+  * `eventTime` : quand
+  * `sourceIPAddress` : depuis quelle IP
+  * `requestParameters` : quel secret a été créé
 </WRAP>
-===== 13. Vérification globale =====
+<WRAP round question>
+Un collègue vous signale qu'une clé KMS a été désactivée à 3h du matin sans explication.
-<WRAP round todo>
+Quelle requête effectuer dans CloudTrail pour retrouver cet événement ?
-Vérifier les points suivants avant de passer au challenge :
-  * aucun mot de passe n'apparait dans les fichiers `.tf`
+Quels champs de l'événement permettent d'identifier l'auteur de l'action ?
-  * le fichier `terraform.tfvars` est présent dans `.gitignore`
-  * le secret est visible dans la console AWS Secrets Manager sous le nom `td3/database/credentials`
-  * la ressource `aws_db_instance` dans le module database contient `storage_encrypted = true`
-  * le bucket S3 applicatif a le chiffrement AES256 actif
-  * le bucket S3 applicatif a les quatre blocages d'accès public actifs
-  * CloudTrail est actif dans la console AWS
-  * la validation des fichiers de log est activée sur le trail
 </WRAP>
 ===== Challenge final =====
-**Axe secrets**
+L'audit de sécurité est terminé.
-<WRAP round help>
+Rédiger un rapport de remédiation qui couvre les quatre axes suivants.
-Où est physiquement stocké le mot de passe de la base de données maintenant ?
-Comparer avec la situation du TD2 : qui pouvait y accéder avant, qui peut y accéder maintenant ?
+**Axe 1 – Secrets**
-Comment restreindre l'accès au secret uniquement au rôle IAM du backend, en vous appuyant sur ce que vous avez appris au TD1 ?
+Expliquer comment les identifiants RDS sont maintenant gérés.
-</WRAP>
-**Axe chiffrement**
+Comparer l'état avant TD3 et l'état après TD3.
-<WRAP round help>
+Indiquer ce qui resterait à améliorer si l'application backend devait récupérer elle-même le secret.
-Le paramètre `storage_encrypted = true` sur RDS protège-t-il les données pendant leur transfert entre le backend et la base ?
-Quel mécanisme complémentaire faut-il activer pour protéger les données en transit ?
+**Axe 2 – Clés KMS**
-Dans quel cas le chiffrement AES256 de S3 ne suffit-il pas a garantir la confidentialite des données ?
+Décrire le cycle de vie de la clé créée dans ce TD.
-</WRAP>
-**Axe traçabilité**
+Expliquer ce qui se passe lors de la rotation automatique.
-<WRAP round help>
+Indiquer le délai de suppression et pourquoi il est important.
-Un stagiaire supprime accidentellement la ressource CloudTrail via `terraform destroy` sur le module logging.
-Quelles sont les conséquences immédiates pour la traçabilité du compte ?
+**Axe 3 – Chiffrement des données**
-Comment aurait-on pu protéger cette ressource contre une suppression accidentelle ?
+Compléter le tableau suivant :
-Chercher le paramètre Terraform qui permet de protéger une ressource contre la destruction.
+Fichier : `td3/rapport/chiffrement.md`
-</WRAP>
+<sxh bash>
+| Ressource  | Type de chiffrement | Clé utilisée        | Données protégées         |
+|------------|---------------------|---------------------|---------------------------|
+| RDS        | SSE-KMS             | CMK alias/td3-key   | Données au repos          |
+| S3 app     | SSE-KMS             | CMK alias/td3-key   | Objets stockés            |
+| S3 logs    | ?                   | ?                   | ?                         |
+| Transit RDS| ?                   | ?                   | ?                         |
+</sxh>
-**Axe architecture**
+**Axe 4 – Traçabilité**
+Décrire ce que CloudTrail trace dans le contexte de ce TD.
+Expliquer pourquoi le bucket de logs est lui-même protégé par une policy stricte.
+Indiquer comment détecter une tentative de suppression des logs CloudTrail.
 <WRAP round todo>
-Produire un schéma de l'architecture complète en prolongement du schéma réalisé au TD2.
+Produire un schéma de l'infrastructure TD3 complète incluant :
-Le schéma doit inclure :
+  * toutes les ressources déployées dans TD3
-  * les composants du TD2 : ALB, backend, Security Groups, subnets
+  * les ressources récupérées en data sources depuis TD2
-  * les ajouts du TD3 : Secrets Manager, RDS chiffré, S3 applicatif, CloudTrail et son bucket
   * les flux de données entre chaque composant avec les ports concernés
   * une légende distinguant les flux chiffrés et les flux non chiffrés
@@ Ligne 819: / Ligne 895: @@
 Fichier : `td3/modules/secrets/main.tf` — ajouter après la ressource `aws_secretsmanager_secret_version`
-<sxh hcl>
+<sxh js>
 variable "rotation_lambda_arn" {
   type        = string
@@ Ligne 837: / Ligne 913: @@
 </sxh>
-<WRAP round help>
+<WRAP round question>
 Le bloc `count = var.rotation_lambda_arn != "" ? 1 : 0` est utilisé ici.
 Que signifie ce pattern dans Terraform ?
-Pourquoi est-il utile de rendre la rotation optionnelle plutôt que obligatoire dans ce module ?
+Pourquoi est-il utile de rendre la rotation optionnelle plutôt qu'obligatoire dans ce module ?
 </WRAP>
-<WRAP round help>
+<WRAP round question>
-Après une rotation automatique du secret, l'application backend doit récupérer le nouveau mot de passe.
+Après une rotation automatique, l'application backend doit récupérer le nouveau mot de passe.
 Si l'application a mis le mot de passe en cache au démarrage, que se passe-t-il après une rotation ?