eadl:bloc4:fm4:td3

Différences

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

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision
Révision précédente
eadl:bloc4:fm4:td3 [2026/06/24 08:09] – [3. Declaration des variables] jcheroneadl:bloc4:fm4:td3 [2026/06/25 03:35] (Version actuelle) jcheron
Ligne 1: Ligne 1:
-====== TD3 – Gestion des secrets, chiffrement et traçabilité AWS ====== 
- 
-===== Objectifs ===== 
- 
-  * 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 
-  * 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 
- 
-===== Contexte ===== 
- 
-Suite au TD2, l'infrastructure réseau est opérationnelle. 
- 
-Le VPC est segmenté, l'ALB filtre le trafic entrant, les Security Groups isolent chaque couche. 
- 
-Un nouvel audit de sécurité interne est réalisé. 
- 
-Trois 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 
-  * 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). 
- 
-Votre mission est de corriger ces trois failles en prolongeant l'infrastructure du TD2. 
- 
-===== Pré-requis ===== 
- 
-  * Projet Terraform du TD2 déployé et fonctionnel 
-  * ALB opérationnel, Security Groups en place 
-  * Accès AWS avec droits suffisants : IAM, Secrets Manager, 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. 
- 
-<sxh bash;gutter:false> 
-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. 
- 
-Les ressources existantes du TD2 sont récupérées via des data sources Terraform. 
- 
-<WRAP round question> 
-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 ? 
-</WRAP> 
- 
-===== 1. Analyse de l'existant ===== 
- 
-<WRAP round todo> 
-Ouvrir le fichier `td2/network/instances.tf`. 
- 
-Localiser la ressource `aws_db_instance.db`. 
-</WRAP> 
- 
-<WRAP round question> 
-Relever les trois problèmes de sécurité présents dans cette ressource. 
- 
-Pour chaque problème, indiquer : 
-  * 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> 
-Le fichier `instances.tf` est versionné dans Git. 
- 
-Un développeur a poussé ce fichier il y a trois mois sur le dépôt de l'équipe. 
- 
-Le mot de passe a été changé depuis, mais il reste dans l'historique Git. 
- 
-Comment retrouver ce mot de passe dans l'historique Git ? 
- 
-Pourquoi changer le mot de passe ne suffit-il pas si le fichier a déjà été commité ? 
-</WRAP> 
- 
-<WRAP round question> 
-La ressource `aws_db_instance.db` dans le TD2 ne contient pas le paramètre `storage_encrypted`. 
- 
-Quelle est la valeur par défaut de ce paramètre dans AWS ? 
- 
-Que signifie concrètement une base non chiffrée au repos ? 
-</WRAP> 
- 
-===== 2. Declaration des providers ===== 
- 
-Le module `storage` utilisera le provider `random` pour générer des suffixes uniques sur les noms de buckets S3. 
- 
-Les noms de buckets S3 sont globaux sur AWS : deux comptes ne peuvent pas avoir le même nom. 
- 
-<WRAP round todo> 
-Créer le fichier de déclaration des providers. 
-</WRAP> 
- 
-Fichier : `td3/providers.tf` 
-<sxh js> 
-terraform { 
-  required_providers { 
-    aws = { 
-      source  = "hashicorp/aws" 
-      version = "~> 5.0" 
-    } 
-    random = { 
-      source  = "hashicorp/random" 
-      version = "~> 3.0" 
-    } 
-  } 
-} 
- 
-provider "aws" { 
-  region = "eu-west-3" 
-} 
-</sxh> 
- 
-<WRAP round question> 
-Pourquoi faut-il déclarer explicitement le provider `random` alors qu'il ne communique pas avec AWS ? 
- 
-Que se passe-t-il si on l'utilise sans le déclarer dans le bloc `required_providers` ? 
-</WRAP> 
- 
 ====== TD3 – Gestion des secrets, chiffrement et traçabilité AWS ====== ====== TD3 – Gestion des secrets, chiffrement et traçabilité AWS ======
  
Ligne 150: Ligne 10:
   * Mettre en place une traçabilité avec CloudTrail   * Mettre en place une traçabilité avec CloudTrail
   * Identifier une action suspecte via les logs   * Identifier une action suspecte via les logs
 +  * Récupérer des ressources existantes via des data sources AWS
  
 ===== Contexte ===== ===== Contexte =====
Ligne 173: Ligne 34:
  
   * Projet Terraform du TD2 déployé et fonctionnel   * 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   * ALB opérationnel, Security Groups en place
   * Accès AWS avec droits suffisants : IAM, Secrets Manager, KMS, S3, RDS, CloudTrail   * Accès AWS avec droits suffisants : IAM, Secrets Manager, KMS, S3, RDS, CloudTrail
Ligne 179: Ligne 41:
 ===== Structure du projet ===== ===== Structure du projet =====
  
-Le TD3 s'appuie sur les ressources existantes du TD2 et ajoute quatre nouveaux modules.+Le TD3 est un projet Terraform indépendant. 
 + 
 +Il ne modifie pas le code du TD2. 
 + 
 +Il récupère les ressources existantes via des data sources AWS interrogeant l'API par tags.
  
 Fichier : `td3/structure.txt` Fichier : `td3/structure.txt`
 <sxh bash> <sxh bash>
-td3/ +tp-aws/ 
-├── main.tf +├── td1/                  # IAM – roles, policies 
-├── variables.tf +├── td2/                  # Réseau – VPC, subnets, ALB, Security Groups 
-├── outputs.tf +└── td3/                  # Secrets, KMS, chiffrement, logs 
-└── modules/ +    ├── main.tf 
-    ├── secrets/ +    ├── variables.tf 
-    │   ── main.tf +    ├── outputs.tf 
-    ├── kms/ +    └── modules/ 
-    │   ── main.tf +        ├── secrets/ 
-    ├── storage/ +        │   ── main.tf 
-    │   ── main.tf +        │   ├── variables.tf 
-    └── logging/ +        │   └── outputs.tf 
-        └── main.tf+        ├── kms/ 
 +        │   ── main.tf 
 +        │   ├── variables.tf 
 +        │   └── outputs.tf 
 +        ├── storage/ 
 +        │   ── main.tf 
 +        │   ├── variables.tf 
 +        │   └── outputs.tf 
 +        └── logging/ 
 +            ├── main.tf 
 +            ├── variables.tf 
 +            └── outputs.tf
 </sxh> </sxh>
  
-Le fichier `td3/main.tf` orchestre les quatre modules et récupère les ressources du TD2 via des data sources.+===== 1Récupération des ressources du TD2 =====
  
-===== 1Analyse de l'existant =====+Objectif : comprendre comment un projet Terraform peut interroger une infrastructure existante sans accéder à son state.
  
-Lire le fichier `td2/network/instances.tf` avant toute manipulation.+TD3 utilise des data sources AWS natifs.
  
-<WRAP round question> +Ces data sources envoient des requêtes directement à l'API AWS et filtrent les ressources par tags.
-Localiser la ligne où le mot de passe de la base de données est défini.+
  
-Répondre aux questions suivantes : +Cela suppose que les ressources TD2 ont été correctement taguées.
-  * Qui peut lire ce mot de passe concrètement ? +
-  * Ce fichier est-il souvent versionné dans Git en entreprise ? +
-  * Quelles sont les conséquences si ce dépôt est public ou partagé avec un prestataire ? +
-</WRAP>+
  
 <WRAP round question> <WRAP round question>
-Dans `td2/network/instances.tf`, la ressource `aws_db_instance` ne contient pas le paramètre `storage_encrypted`.+Pourquoi TD3 ne peut-il pas utiliser directement les outputs du TD2 sans configuration supplémentaire ?
  
-Quelle est la valeur par défaut de ce paramètre dans AWS ? +Quelle est la différence entre un data source AWS et un `terraform_remote_state` ?
- +
-Comment vérifier l'état du chiffrement d'une instance RDS existante dans la console AWS ?+
 </WRAP> </WRAP>
- 
-<WRAP round question> 
-Aucun service de logging n'est présent dans le TD2. 
- 
-Citer deux situations concrètes en production où l'absence de logs rend la gestion d'incident impossible. 
-</WRAP> 
- 
-===== 2. Récupération des ressources du TD2 ===== 
- 
-Le TD3 ne redéploie pas les ressources du TD2. 
- 
-Il les récupère via des data sources Terraform pour les réutiliser. 
  
 Fichier : `td3/main.tf` Fichier : `td3/main.tf`
 <sxh js> <sxh js>
-terraform { 
-  required_providers { 
-    aws = { 
-      source  = "hashicorp/aws" 
-      version = "~> 5.0" 
-    } 
-    random = { 
-      source  = "hashicorp/random" 
-      version = "~> 3.0" 
-    } 
-  } 
-} 
- 
 provider "aws" { provider "aws" {
   region = "eu-west-3"   region = "eu-west-3"
 } }
  
-Recuperation du compte AWS courant +Récupération du VPC créé dans TD2 
-data "aws_caller_identity" "current" {} +data "aws_vpc" "main" { 
- +  tags = 
-# Recuperation de la region courante +    Name = "td2-vpc"
-data "aws_region" "current" {} +
- +
-# Recuperation du VPC cree au TD2 +
-data "aws_vpc" "td2" { +
-  filter +
-    name   = "tag:Name+
-    values ["td2-vpc"]+
   }   }
 } }
  
-Recuperation du Security Group backend du TD2 +Récupération du subnet privé créé dans TD2 
-data "aws_security_group" "backend_sg" { +data "aws_subnet" "private" { 
-  filter +  tags = 
-    name   = "tag:Name+    Name = "td2-private"
-    values ["backend-sg"]+
   }   }
 } }
  
-module "secrets" { +# Récupération du subnet privé secondaire créé dans TD2 
-  source = "./modules/secrets"+data "aws_subnet" "private_b" { 
 +  tags = { 
 +    Name = "td2-private-b" 
 +  }
 } }
  
-module "kms" { +# Récupération du Security Group RDS créé dans TD2 
-  source     = "./modules/kms+data "aws_security_group" "rds" { 
-  account_id = data.aws_caller_identity.current.account_id +  tags = { 
-  region     = data.aws_region.current.name+    Name = "td2-sg-rds
 +  }
 } }
  
-module "storage" { +# Récupération du Security Group de l'application créé dans TD2 
-  source  = "./modules/storage+data "aws_security_group" "app" { 
-  kms_key_arn = module.kms.key_arn+  tags = { 
 +    Name = "td2-sg-app
 +  }
 } }
 +</sxh>
  
-module "logging" { +<WRAP round todo> 
-  source     = "./modules/logging+Vérifier dans le code TD2 que chaque ressource est bien taguée avec les valeurs attendues ci-dessus. 
-  account_id data.aws_caller_identity.current.account_id + 
-  kms_key_arn module.kms.key_arn+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> 
 +Que se passe-t-il si deux ressources AWS portent le même tag `Name` dans la même région ? 
 + 
 +Quel comportement Terraform adopte-t-il dans ce cas ? 
 +</WRAP> 
 + 
 +===== 2. Identification du problème ===== 
 + 
 +Objectif : identifier les secrets en clair dans l'infrastructure TD2. 
 + 
 +Voici un extrait du fichier `instances.tf` tel qu'il existe après le TD2. 
 + 
 +Fichier : `td2/instances.tf` — lecture seule, ne pas modifier 
 +<sxh js> 
 +resource "aws_db_instance" "db" { 
 +  identifier        = "td2-db
 +  engine            "postgres" 
 +  instance_class    "db.t3.micro" 
 +  allocated_storage = 20 
 + 
 +  username = "admin" 
 +  password = "S3cr3tP@ss!" 
 + 
 +  skip_final_snapshot = true
 } }
 </sxh> </sxh>
  
 <WRAP round question> <WRAP round question>
-Pourquoi utilise-t-on des data sources plutôt que de redéclarer les ressources du TD2 ?+Identifier au moins trois problèmes de sécurité dans ce bloc.
  
-Que se passerait-il si on redéclarait `aws_vpcavec le même CIDR dans un nouveau fichier Terraform ?+Pour chaque problème, expliquer la conséquence concrète en cas de fuite du fichier `.tfou du state Terraform.
 </WRAP> </WRAP>
  
-===== 3Gestion des secrets avec Secrets Manager =====+<WRAP round todo> 
 +Ne pas appliquer ce fichier tel quel.
  
-Objectif : supprimer le mot de passe en clair de `instances.tf`.+Ne pas modifier le TD2 non plus.
  
-<WRAP round todo> +La correction se fait uniquement dans TD3.
-Créer le module secrets.+
 </WRAP> </WRAP>
  
-Fichier : `td3/modules/secrets/main.tf`+===== 3. Création du module secrets ===== 
 + 
 +Objectif : stocker les identifiants de la base de données dans AWS Secrets Manager. 
 + 
 +Fichier : `td3/modules/secrets/variables.tf`
 <sxh js> <sxh js>
 +variable "secret_name" {
 +  type        = string
 +  description = "Nom du secret dans Secrets Manager"
 +  default     = "td3/db/credentials"
 +}
 +
 variable "db_username" { variable "db_username" {
   type        = string   type        = string
   description = "Nom d'utilisateur de la base de données"   description = "Nom d'utilisateur de la base de données"
-  default     = "admin"+  default     = "td3admin"
 } }
  
Ligne 323: Ligne 205:
   sensitive   = true   sensitive   = true
 } }
 +</sxh>
  
 +Fichier : `td3/modules/secrets/main.tf`
 +<sxh js>
 resource "aws_secretsmanager_secret" "db_credentials" { resource "aws_secretsmanager_secret" "db_credentials" {
-  name        = "td3/db/credentials+  name                    = var.secret_name 
-  description = "Identifiants de la base de donnees RDS TD3"+  recovery_window_in_days = 7 
 + 
 +  tags = { 
 +    Name = "td3-secret-db" 
 +    TD   = "td3" 
 +  }
 } }
  
 resource "aws_secretsmanager_secret_version" "db_credentials" { resource "aws_secretsmanager_secret_version" "db_credentials" {
   secret_id = aws_secretsmanager_secret.db_credentials.id   secret_id = aws_secretsmanager_secret.db_credentials.id
 +
   secret_string = jsonencode({   secret_string = jsonencode({
     username = var.db_username     username = var.db_username
Ligne 336: Ligne 227:
   })   })
 } }
 +</sxh>
  
 +Fichier : `td3/modules/secrets/outputs.tf`
 +<sxh js>
 output "secret_arn" { output "secret_arn" {
   value       = aws_secretsmanager_secret.db_credentials.arn   value       = aws_secretsmanager_secret.db_credentials.arn
-  description = "ARN du secret contenant les identifiants RDS"+  description = "ARN du secret contenant les identifiants de la base de données"
 } }
-</sxh> 
  
-Fichier : `td3/variables.tf` +output "secret_name" { 
-<sxh js> +  value       aws_secretsmanager_secret.db_credentials.name 
-variable "db_password" { +  description = "Nom du secret dans Secrets Manager"
-  type        string +
-  description = "Mot de passe initial de la base de donnees" +
-  sensitive   = true+
 } }
 </sxh> </sxh>
  
-Le mot de passe est transmis via une variable sensible, jamais écrit en dur.+<WRAP round question> 
 +Le paramètre `sensitive = true` sur la variable `db_password` masque la valeur dans les logs Terraform.
  
-Pour appliquer, Terraform demandera la valeur au moment de l'exécution :+Cela signifie-t-il que le mot de passe est chiffré dans le state Terraform ?
  
-Fichier : `td3/commandes/terraform.txt` +Où le mot de passe est-il stocké en clair malgré ce paramètre ? 
-<sxh bash> +</WRAP>
-# Appliquer en fournissant le mot de passe de maniere interactive +
-terraform apply -var="db_password=MonMotDePasse123!" +
- +
-# Ou via une variable d'environnement sans valeur dans le code +
-export TF_VAR_db_password="MonMotDePasse123!" +
-terraform apply +
-</sxh>+
  
 <WRAP round question> <WRAP round question>
-Pourquoi utilise-t-on `sensitive truesur la variable `db_password` ?+Le paramètre `recovery_window_in_days 7signifie que le secret n'est pas supprimé immédiatement.
  
-Que change ce paramètre dans l'affichage Terraform ?+Pourquoi AWS impose-t-il cette fenêtre de récupération par défaut ?
  
-Est-ce suffisant pour garantir que le mot de passe ne sera jamais visible ?+Comment forcer la suppression immédiate si nécessaire, et dans quel cas cela est-il risqué ?
 </WRAP> </WRAP>
  
-<WRAP round question> +===== 4. Erreur volontaire – secret introuvable =====
-Pourquoi utilise-t-on un JSON pour stocker le secret plutôt qu'une simple chaîne ?+
  
-Quel avantage cela apporte-t-il si l'application doit récupérer le secret programmatiquement ? +Objectif : comprendre ce qui se passe quand une application tente de lire un secret inexistant.
-</WRAP>+
  
-===== 4Problème volontaire – dépendance entre modules =====+Voici un data source intentionnellement incorrect. 
 + 
 +Fichier : `td3/debug/wrong_secret.tf` — ne pas appliquer 
 +<sxh js> 
 +data "aws_secretsmanager_secret" "db_credentials"
 +  name "td3/db/credential" 
 +
 +</sxh>
  
 <WRAP round todo> <WRAP round todo>
-Tenter d'appliquer uniquement le module secrets :+Lire le code ci-dessus sans l'appliquer.
  
-  terraform apply -target=module.secrets+Identifier l'erreur sans regarder la réponse ci-dessous.
  
-Puis observer ce qui se passe si on tente de lire le secret immédiatement dans le module storage sans `depends_on`.+Écrire la correction avant de lire la suite.
 </WRAP> </WRAP>
  
-<WRAP round question> +Le nom du secret dans Secrets Manager est `td3/db/credentials` avec un `s` final.
-Terraform gère les dépendances implicites entre ressources du même fichier.+
  
-Pourquoi cette dépendance implicite ne fonctionne-t-elle pas toujours entre modules différents ?+Le data source ci-dessus cherche `td3/db/credential` sans `s`.
  
-Dans quels cas faut-il utiliser `depends_onexplicitement ?+L'erreur retournée par Terraform sera : 
 + 
 +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> </WRAP>
  
-===== 5. Création d'une clé KMS =====+===== 5. Récupération du secret dans RDS =====
  
-Objectif : créer une clé de chiffrement gérée par le client (CMK).+Objectif : utiliser le secret Secrets Manager dans la configuration RDS plutôt que des valeurs en clair.
  
-<WRAP round question+Fichier : `td3/modules/secrets/main.tf` — ajouter après les ressources existantes 
-AWS propose deux types de clés KMS : +<sxh js
-  * les clés AWS managées (aws/rds, aws/s3...) +data "aws_secretsmanager_secret_version" "db_credentials" { 
-  * les clés Customer Managed Keys (CMK)+  secret_id = aws_secretsmanager_secret.db_credentials.id
  
-Quelle est la différence concrète entre les deux en termes de contrôle ?+  depends_on = [aws_secretsmanager_secret_version.db_credentials] 
 +}
  
-Qui peut utiliser une clé AWS managée ?+locals { 
 +  db_secret = jsondecode( 
 +    data.aws_secretsmanager_secret_version.db_credentials.secret_string 
 +  ) 
 +
 +</sxh>
  
-Qui décide des droits d'accès sur une CMK ?+<WRAP round question> 
 +Pourquoi utilise-t-on `depends_on` ici ? 
 + 
 +Que se passerait-il si Terraform tentait de lire le secret avant que la version soit créée ?
 </WRAP> </WRAP>
  
-<WRAP round todo+===== 6. Création du module KMS ===== 
-Créer le module KMS.+ 
 +Objectif : créer une clé de chiffrement gérée par le client (Customer Managed Key) pour chiffrer les données au repos. 
 + 
 +<WRAP round question
 +Avant de créer la clé, répondre aux questions suivantes : 
 + 
 +Quelle est la différence entre une clé AWS managée et une CMK (Customer Managed Key) ? 
 + 
 +Dans quel cas une CMK est-elle obligatoire plutôt que recommandée ?
 </WRAP> </WRAP>
  
-Fichier : `td3/modules/kms/main.tf`+Fichier : `td3/modules/kms/variables.tf`
 <sxh js> <sxh js>
-variable "account_id" {+variable "key_alias" {
   type        = string   type        = string
-  description = "ID du compte AWS courant"+  description = "Alias de la clé KMS" 
 +  default     = "alias/td3-key"
 } }
  
-variable "region" {+variable "account_id" {
   type        = string   type        = string
-  description = "Region AWS courante"+  description = "ID du compte AWS courant"
 } }
 +</sxh>
 +
 +Fichier : `td3/modules/kms/main.tf`
 +<sxh js>
 +data "aws_caller_identity" "current" {}
  
-resource "aws_kms_key" "td3" { +resource "aws_kms_key" "main" { 
-  description             = "Cle KMS TD3 – chiffrement RDS et S3" +  description             = "Clé KMS TD3 – chiffrement RDS et S3" 
-  deletion_window_in_days = 7+  deletion_window_in_days = 10
   enable_key_rotation     = true   enable_key_rotation     = true
  
Ligne 439: Ligne 361:
     Statement = [     Statement = [
       {       {
-        Sid    = "Acces administrateur au compte"+        Sid    = "EnableRootAccess"
         Effect = "Allow"         Effect = "Allow"
         Principal = {         Principal = {
Ligne 449: Ligne 371:
     ]     ]
   })   })
 +
 +  tags = {
 +    Name = "td3-kms-key"
 +    TD   = "td3"
 +  }
 } }
  
-resource "aws_kms_alias" "td3" { +resource "aws_kms_alias" "main" { 
-  name          = "alias/td3-key" +  name          = var.key_alias 
-  target_key_id = aws_kms_key.td3.id+  target_key_id = aws_kms_key.main.key_id
 } }
 +</sxh>
  
 +Fichier : `td3/modules/kms/outputs.tf`
 +<sxh js>
 output "key_arn" { output "key_arn" {
-  value       = aws_kms_key.td3.arn +  value       = aws_kms_key.main.arn 
-  description = "ARN de la cle KMS TD3"+  description = "ARN de la clé KMS"
 } }
  
 output "key_id" { output "key_id" {
-  value       = aws_kms_key.td3.id +  value       = aws_kms_key.main.key_id 
-  description = "ID de la cle KMS TD3"+  description = "ID de la clé KMS"
 } }
 </sxh> </sxh>
  
 <WRAP round question> <WRAP round question>
-Le paramètre `deletion_window_in_days 7est défini sur la clé KMS.+Le paramètre `enable_key_rotation trueactive la rotation automatique de la clé.
  
-Que se passe-t-il si on supprime cette clé alors que des données RDS ou S3 sont chiffrées avec elle ?+Que signifie concrètement la rotation d'une clé KMS ?
  
-Pourquoi AWS impose-t-il un délai minimum avant la suppression effective d'une clé ?+Les données chiffrées avec l'ancienne version de la clé deviennent-elles inaccessibles après rotation ?
 </WRAP> </WRAP>
  
 <WRAP round question> <WRAP round question>
-Le paramètre `enable_key_rotation = trueest activé.+La policy KMS donne accès à `arn:aws:iam::ACCOUNT_ID:root`.
  
-Que signifie la rotation d'une clé KMS concrètement ?+Pourquoi cette entrée est-elle obligatoire dans une policy KMS ?
  
-La rotation de la clé KMS invalide-t-elle les données déjà chiffrées avec l'ancienne version ?+Que se passe-t-il si elle est absente ?
 </WRAP> </WRAP>
  
-<WRAP round question> +===== 7Création du module storage =====
-La key policy autorise `kms:*` pour le root du compte.+
  
-Pourquoi cette règle est-elle nécessaire dans une key policy ?+Objectif : déployer une instance RDS chiffrée et un bucket S3 chiffré en utilisant la clé KMS du module précédent.
  
-Que se passerait-il si on supprimait cette règle et qu'aucun autre principal n'était autorisé ? +Fichier : `td3/modules/storage/variables.tf`
-</WRAP> +
- +
-===== 6. Chiffrement de la base de données RDS ===== +
- +
-Objectif activer le chiffrement au repos sur RDS avec la CMK. +
- +
-<WRAP round todo> +
-Modifier `td2/network/instances.tf` pour activer le chiffrement et utiliser le secret Secrets Manager. +
-</WRAP> +
- +
-Fichier : `td2/network/instances.tf`+
 <sxh js> <sxh js>
-# Recuperation du secret cree dans le module TD3 +variable "kms_key_arn" { 
-data "aws_secretsmanager_secret_version" "db_credentials" { +  type        = string 
-  secret_id = "td3/db/credentials"+  description = "ARN de la clé KMS utilisée pour le chiffrement" 
 +}
  
-  depends_on +variable "db_username"
-    aws_secretsmanager_secret_version.db_credentials +  type        string 
-  ]+  description = "Nom d'utilisateur transmis depuis Secrets Manager"
 } }
  
-locals +variable "db_password" 
-  db_secret jsondecode( +  type        string 
-    data.aws_secretsmanager_secret_version.db_credentials.secret_string +  description = "Mot de passe transmis depuis Secrets Manager" 
-  )+  sensitive   = true
 } }
  
-resource "aws_instance" "backend" { +variable "subnet_ids" { 
-  ami                    "ami-0f61de2873e29e866" +  type        list(string) 
-  instance_type          = "t2.micro+  description = "Liste des IDs de subnets privés récupérés depuis TD2
-  subnet_id              = aws_subnet.private.id +}
-  vpc_security_group_ids = [aws_security_group.backend_sg.id]+
  
-  user_data = <<-EOF +variable "security_group_id" { 
-    #!/bin/bash +  type        = string 
-    yum install -y python3 +  description = "ID du Security Group RDS récupéré depuis TD2"
-    python3 -m http.server 80 & +
-  EOF +
- +
-  tags = { +
-    Name = "td2-backend" +
-  }+
 } }
  
-resource "aws_db_instance" "db" { +variable "bucket_name" { 
-  identifier             = "td3-db" +  type        string 
-  engine                 = "postgres" +  description = "Nom du bucket S3 applicatif"
-  engine_version         = "15" +
-  instance_class         = "db.t3.micro" +
-  allocated_storage      = 20 +
- +
-  username = local.db_secret.username +
-  password = local.db_secret.password +
- +
-  storage_encrypted = true +
-  kms_key_id        var.kms_key_arn +
- +
-  db_subnet_group_name   = aws_db_subnet_group.main.name +
-  vpc_security_group_ids = [aws_security_group.db_sg.id] +
-  skip_final_snapshot    = true +
- +
-  tags = { +
-    Name = "td3-db" +
-  }+
 } }
 +</sxh>
  
 +Fichier : `td3/modules/storage/main.tf`
 +<sxh js>
 resource "aws_db_subnet_group" "main" { resource "aws_db_subnet_group" "main" {
   name       = "td3-db-subnet-group"   name       = "td3-db-subnet-group"
-  subnet_ids = [aws_subnet.private.id, aws_subnet.public_b.id]+  subnet_ids = var.subnet_ids
  
   tags = {   tags = {
     Name = "td3-db-subnet-group"     Name = "td3-db-subnet-group"
 +    TD   = "td3"
   }   }
 } }
  
-variable "kms_key_arn" { +resource "aws_db_instance" "db" { 
-  type        string +  identifier        "td3-db" 
-  description = "ARN de la cle KMS utilisee pour le chiffrement RDS+  engine            = "postgres
-} +  engine_version    = "15" 
-</sxh>+  instance_class    = "db.t3.micro" 
 +  allocated_storage = 20
  
-<WRAP round question> +  username = var.db_username 
-Le chiffrement `storage_encrypted true` protège les données au repos.+  password var.db_password
  
-Quel mécanisme protège les données en transit entre le backend et RDS ?+  db_subnet_group_name   = aws_db_subnet_group.main.name 
 +  vpc_security_group_ids = [var.security_group_id]
  
-Le chiffrement au repos protège-t-il contre un accès non autorisé via SQL si les credentials sont compromis ? +  storage_encrypted = true 
-</WRAP>+  kms_key_id        = var.kms_key_arn
  
-<WRAP round question> +  skip_final_snapshot = true
-L'identifiant de la base est passé de `td2-db` à `td3-db`.+
  
-Que se passe-t-il si on tente de modifier `storage_encrypted` sur une instance RDS existante ? +  tags { 
- +    Name "td3-db
-Pourquoi AWS impose-t-il cette contrainte ? +    TD   = "td3
-</WRAP> +  }
- +
-===== 7. Problème volontaire – chiffrement RDS immuable ===== +
- +
-<WRAP round todo> +
-Tenter de modifier une instance RDS existante non chiffrée pour activer le chiffrement : +
- +
-  terraform apply +
- +
-Observer le message d'erreur Terraform. +
-</WRAP> +
- +
-<WRAP round question> +
-Terraform indique qu'il doit détruire et recréer l'instance RDS. +
- +
-Pourquoi le chiffrement d'une instance RDS ne peut-il pas être activé à chaud ? +
- +
-Quelles précautions prendre en production avant de forcer cette opération ? +
-</WRAP> +
- +
-===== 8. Création d'un bucket S3 sécurisé ===== +
- +
-Objectif : créer un bucket S3 avec chiffrement SSE-KMS et blocage d'accès public. +
- +
-<WRAP round todo> +
-Créer le module storage. +
-</WRAP> +
- +
-Fichier : `td3/modules/storage/main.tf` +
-<sxh js> +
-variable "kms_key_arn" { +
-  type        = string +
-  description = "ARN de la cle KMS utilisee pour le chiffrement S3+
-} +
- +
-resource "random_id" "bucket_suffix"+
-  byte_length = 4+
 } }
  
-resource "aws_s3_bucket" "app_data" { +resource "aws_s3_bucket" "app" { 
-  bucket = "td3-app-data-${random_id.bucket_suffix.hex}"+  bucket = var.bucket_name
  
   tags = {   tags = {
-    Name = "td3-app-data"+    Name = "td3-s3-app" 
 +    TD   = "td3"
   }   }
 } }
  
-resource "aws_s3_bucket_public_access_block" "app_data"+resource "aws_s3_bucket_server_side_encryption_configuration" "app" { 
-  bucket = aws_s3_bucket.app_data.id +  bucket = aws_s3_bucket.app.id
- +
-  block_public_acls       = true +
-  block_public_policy     = true +
-  ignore_public_acls      = true +
-  restrict_public_buckets = true +
-+
- +
-resource "aws_s3_bucket_server_side_encryption_configuration" "app_data" { +
-  bucket = aws_s3_bucket.app_data.id+
  
   rule {   rule {
Ligne 652: Ligne 508:
 } }
  
-output "bucket_name" { +resource "aws_s3_bucket_public_access_block" "app" { 
-  value       = aws_s3_bucket.app_data.id +  bucket = aws_s3_bucket.app.id 
-  description "Nom du bucket S3 applicatif"+ 
 +  block_public_acls       true 
 +  block_public_policy     = true 
 +  ignore_public_acls      = true 
 +  restrict_public_buckets = true
 } }
 </sxh> </sxh>
  
 <WRAP round question> <WRAP round question>
-Dans ce TD la valeur de `sse_algorithmest `aws:kms`.+Le chiffrement `storage_encrypted = truesur RDS protège-t-il les données en transit ou au repos ?
  
-Dans le TD précédent la valeur était `AES256`. +Quel mécanisme protège les données en transit entre l'application et RDS ?
- +
-Quelle est la différence concrète entre ces deux modes de chiffrement S3 ? +
- +
-Quel mode offre le plus de contrôle sur la clé de chiffrement ?+
 </WRAP> </WRAP>
  
 <WRAP round question> <WRAP round question>
-Le paramètre `bucket_key_enabled = true` est activé.+Le paramètre `bucket_key_enabled = true` est activé sur le bucket S3.
  
-Rechercher ce que fait ce paramètre.+Rechercher dans la documentation AWS ce que cette option apporte.
  
-Quel impact a-t-il sur les coûts liés à KMS ?+Quel est l'impact sur les coûts et les performances ?
 </WRAP> </WRAP>
 +
 +===== 8. Erreur volontaire – chiffrement impossible =====
 +
 +Objectif : comprendre pourquoi RDS ne peut pas chiffrer une instance existante non chiffrée.
 +
 +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.
  
 <WRAP round question> <WRAP round question>
-Les quatre paramètres de `aws_s3_bucket_public_access_block` sont tous à `true`.+Avant de chercher la réponse, réfléchir à ce qui va se passer.
  
-Expliquer ce que bloque concrètement chacun des quatre paramètres.+Est-ce que Terraform va modifier l'instance en place ?
  
-Pourquoi ce bloc est-il indépendant du chiffrement ?+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> </WRAP>
- 
-===== 9. Mise en place du logging avec CloudTrail ===== 
- 
-Objectif : tracer toutes les actions réalisées sur le compte AWS. 
  
 <WRAP round todo> <WRAP round todo>
-Créer le module logging.+Rechercher dans la documentation AWS RDS la section relative au chiffrement d'une instance existante. 
 + 
 +Décrire en cinq étapes la procédure à suivre pour migrer une instance non chiffrée vers une instance chiffrée.
 </WRAP> </WRAP>
  
-Fichier : `td3/modules/logging/main.tf`+===== 9. Création du module logging ===== 
 + 
 +Objectif : activer CloudTrail pour conserver une trace de toutes les actions réalisées sur le compte AWS. 
 + 
 +Fichier : `td3/modules/logging/variables.tf`
 <sxh js> <sxh js>
-variable "account_id" {+variable "bucket_name" {
   type        = string   type        = string
-  description = "ID du compte AWS courant"+  description = "Nom du bucket S3 destiné à recevoir les logs CloudTrail"
 } }
  
 variable "kms_key_arn" { variable "kms_key_arn" {
   type        = string   type        = string
-  description = "ARN de la cle KMS utilisee pour le chiffrement des logs"+  description = "ARN de la clé KMS pour chiffrer les logs CloudTrail"
 } }
  
-resource "random_id" "bucket_suffix" { +variable "account_id" { 
-  byte_length 4+  type        string 
 +  description = "ID du compte AWS courant"
 } }
 +</sxh>
  
-resource "aws_s3_bucket" "cloudtrail_logs" { +Fichier : `td3/modules/logging/main.tf` 
-  bucket = "td3-cloudtrail-${var.account_id}-${random_id.bucket_suffix.hex}"+<sxh js> 
 +resource "aws_s3_bucket" "cloudtrail" { 
 +  bucket = var.bucket_name
  
   tags = {   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   block_public_acls       = true
Ligne 725: 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({   policy = jsonencode({
Ligne 738: Ligne 609:
         }         }
         Action   = "s3:GetBucketAcl"         Action   = "s3:GetBucketAcl"
-        Resource = aws_s3_bucket.cloudtrail_logs.arn+        Resource = aws_s3_bucket.cloudtrail.arn
       },       },
       {       {
Ligne 747: Ligne 618:
         }         }
         Action   = "s3:PutObject"         Action   = "s3:PutObject"
-        Resource = "${aws_s3_bucket.cloudtrail_logs.arn}/AWSLogs/${var.account_id}/*"+        Resource = "${aws_s3_bucket.cloudtrail.arn}/AWSLogs/${var.account_id}/*"
         Condition = {         Condition = {
           StringEquals = {           StringEquals = {
Ligne 760: Ligne 631:
 resource "aws_cloudtrail" "main" { resource "aws_cloudtrail" "main" {
   name                          = "td3-cloudtrail"   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   include_global_service_events = true
   is_multi_region_trail         = false   is_multi_region_trail         = false
Ligne 766: Ligne 637:
   kms_key_id                    = var.kms_key_arn   kms_key_id                    = var.kms_key_arn
  
-  depends_on [ +  tags { 
-    aws_s3_bucket_policy.cloudtrail_logs +    Name = "td3-cloudtrail" 
-  ]+    TD   = "td3" 
 +  
 + 
 +  depends_on = [aws_s3_bucket_policy.cloudtrail]
 } }
 +</sxh>
  
 +Fichier : `td3/modules/logging/outputs.tf`
 +<sxh js>
 output "cloudtrail_arn" { output "cloudtrail_arn" {
   value       = aws_cloudtrail.main.arn   value       = aws_cloudtrail.main.arn
   description = "ARN du trail CloudTrail"   description = "ARN du trail CloudTrail"
 +}
 +
 +output "cloudtrail_bucket" {
 +  value       = aws_s3_bucket.cloudtrail.bucket
 +  description = "Nom du bucket contenant les logs CloudTrail"
 } }
 </sxh> </sxh>
  
 <WRAP round question> <WRAP round question>
-La bucket policy pour CloudTrail contient deux statements distincts.+Le paramètre `enable_log_file_validation = true` active la validation de l'intégrité des fichiers de logs.
  
-Expliquer le rôle de chacun : +Quel problème cela permet-il de détecter ?
-  * `AWSCloudTrailAclCheck` +
-  * `AWSCloudTrailWrite`+
  
-Que se passerait-il si cette policy était absente ?+Quel mécanisme technique AWS utilise-t-il pour garantir cette intégrité ?
 </WRAP> </WRAP>
  
 <WRAP round question> <WRAP round question>
-Le paramètre `enable_log_file_validation = true` est activé.+CloudTrail trace les appels API AWS.
  
-Que permet concrètement la validation des fichiers de log ?+Citer trois exemples d'actions tracées par CloudTrail dans le cadre de ce TD.
  
-Dans quel scénario cette fonctionnalité est-elle particulièrement utile ?+Citer deux exemples d'actions qui ne sont pas tracées par CloudTrail.
 </WRAP> </WRAP>
  
-<WRAP round question> +===== 10Assemblage dans main.tf =====
-CloudTrail enregistre les appels API réalisés sur le compte AWS.+
  
-Cocher parmi ces actions celles qui sont tracées par CloudTrail : +Objectif relier tous les modules entre eux et injecter les data sources TD2 dans les modules TD3.
-  * création d'un Security Group +
-  * modification d'une règle IAM +
-  * upload d'un fichier dans S3 +
-  * requête SQL vers RDS +
-  * connexion SSH vers une instance EC2 +
-  * suppression d'un secret Secrets Manager+
  
-Justifier les réponses non évidentes. +Fichier : `td3/variables.tf`
-</WRAP> +
- +
-===== 10. Simulation d'un incident ===== +
- +
-Objectif : utiliser CloudTrail pour retracer une action suspecte. +
- +
-<WRAP round todo> +
-Réaliser une action volontairement suspecte dans AWS. +
- +
-Modifier un Security Group existant du TD2 pour ouvrir temporairement le port 22 depuis `0.0.0.0/0` : +
- +
-  terraform apply -target=module.network +
- +
-Attendre deux minutes, puis supprimer cette règle : +
- +
-  terraform apply +
-</WRAP> +
- +
-<WRAP round todo> +
-Aller dans la console AWS. +
- +
-Naviguer vers : CloudTrail > Event history. +
- +
-Rechercher l'événement `AuthorizeSecurityGroupIngress`. +
- +
-Identifier : +
-  * l'heure de l'action +
-  * l'identité qui a réalisé l'action +
-  * les paramètres de la règle ajoutée +
-</WRAP> +
- +
-<WRAP round question> +
-CloudTrail enregistre l'identité qui a réalisé chaque action. +
- +
-Si plusieurs développeurs partagent le même utilisateur IAM, que perd-on en termes de traçabilité ? +
- +
-Quel principe de gestion des identités du TD1 est directement lié à cette problématique ? +
-</WRAP> +
- +
-<WRAP round question> +
-Les logs CloudTrail sont stockés dans S3. +
- +
-Par défaut, combien de temps sont-ils conservés dans CloudTrail Event History ? +
- +
-Pourquoi stocker les logs dans S3 permet-il une conservation plus longue ? +
-</WRAP> +
- +
-===== 11. Vérification globale ===== +
- +
-<WRAP round todo> +
-Vérifier les points suivants dans le code Terraform et dans la console AWS : +
- +
-  * le mot de passe n'apparaît plus dans aucun fichier `.tf` +
-  * la variable `db_password` est marquée `sensitive = true` +
-  * la base RDS a `storage_encrypted = true` et un `kms_key_id` renseigné +
-  * le bucket S3 applicatif a `sse_algorithm = "aws:kms"+
-  * le bucket S3 applicatif a les quatre paramètres `public_access_block` à `true` +
-  * CloudTrail est actif et écrit dans son bucket dédié +
-  * la clé KMS a `enable_key_rotation = true` +
-</WRAP> +
- +
-===== Challenge final ===== +
- +
-**Axe secrets** +
- +
-<WRAP round todo> +
-Répondre aux questions suivantes par écrit : +
- +
-  * Où est stocké physiquement le secret de la base après le TD3 ? +
-  * Qui peut lire ce secret dans AWS ? +
-  * Que se passe-t-il si le secret Secrets Manager est lui-même chiffré avec la clé KMS TD3 et que cette clé est supprimée ? +
-  * Quelles seraient les trois premières actions à réaliser si le mot de passe de la base était compromis ? +
-</WRAP> +
- +
-**Axe KMS** +
- +
-<WRAP round question> +
-La clé KMS est utilisée à la fois pour RDS, S3 et CloudTrail. +
- +
-Quels sont les avantages de centraliser sur une seule clé ? +
- +
-Quels sont les risques de cette approche ? +
- +
-Comment organiserait-on les clés KMS dans un environnement de production avec plusieurs équipes et plusieurs applications ? +
-</WRAP> +
- +
-**Axe chiffrement** +
- +
-<WRAP round question> +
-Dresser un tableau récapitulatif avec les colonnes suivantes : +
- +
-  * Ressource (RDS, S3, Secrets Manager, CloudTrail) +
-  * Type de chiffrement (au repos, en transit, les deux) +
-  * Algorithme ou mécanisme utilisé +
-  * Clé utilisée (AWS managée ou CMK TD3) +
- +
-Dans quel cas le chiffrement AES256 de S3 ne suffit-il pas à garantir la confidentialité des données ? +
-</WRAP> +
- +
-**Axe traçabilité** +
- +
-<WRAP round question> +
-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 ? +
- +
-Comment aurait-on pu protéger cette ressource contre une suppression accidentelle ? +
- +
-Rechercher le paramètre Terraform qui permet de protéger une ressource contre la destruction. +
-</WRAP> +
- +
-**Axe architecture** +
- +
-<WRAP round todo> +
-Produire un schéma de l'architecture complète en prolongement du schéma réalisé au TD2. +
- +
-Le schéma doit inclure : +
-  * les composants du TD2 : ALB, backend, Security Groups, subnets +
-  * les ajouts du TD3 : Secrets Manager, KMS, 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 +
-</WRAP> +
- +
-===== Bonus ===== +
- +
-**Rotation automatique des secrets** +
- +
-<WRAP round todo> +
-Rechercher dans la documentation AWS comment activer la rotation automatique d'un secret Secrets Manager pour une base PostgreSQL. +
- +
-Identifier l'ARN de la Lambda de rotation fournie par AWS pour PostgreSQL dans la région `eu-west-3`. +
- +
-Ajouter la rotation dans le module secrets. +
-</WRAP> +
- +
-Fichier : `td3/modules/secrets/main.tf` — ajouter après la ressource `aws_secretsmanager_secret_version`+
 <sxh js> <sxh js>
-variable "rotation_lambda_arn" {+variable "db_password" {
   type        = string   type        = string
-  description = "ARN de la Lambda de rotation fournie par AWS pour PostgreSQL+  description = "Mot de passe de la base de données – ne pas committer
-  default     ""+  sensitive   true
 } }
  
-resource "aws_secretsmanager_secret_rotation" "db_credentials" { +variable "s3_app_bucket_name" { 
-  count               var.rotation_lambda_arn != "" ? 1 : 0 +  type        string 
-  secret_id           aws_secretsmanager_secret.db_credentials.id +  description = "Nom du bucket S3 applicatif
-  rotation_lambda_arn = var.rotation_lambda_arn +  default     "td3-app-bucket-demo"
- +
-  rotation_rules { +
-    automatically_after_days = 30 +
-  }+
 } }
-</sxh> 
  
-<WRAP round question> +variable "s3_logs_bucket_name" { 
-Le bloc `count = var.rotation_lambda_arn != "" ? 1 : 0` est utilisé ici. +  type        string 
- +  description = "Nom du bucket S3 pour les logs CloudTrail
-Que signifie ce pattern dans Terraform ? +  default     = "td3-cloudtrail-logs-demo"
- +
-Pourquoi est-il utile de rendre la rotation optionnelle plutôt qu'obligatoire dans ce module ? +
-</WRAP> +
- +
-<WRAP round question> +
-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 ? +
- +
-Comment une application bien conçue doit-elle récupérer les secrets pour éviter ce problème ? +
-</WRAP> +
- +
-===== 4. Recuperation des ressources existantes du TD2 ===== +
- +
-Plutôt que de recréer les ressources, on les référence via des data sources. +
- +
-<WRAP round todo> +
-Créer le fichier principal du TD3. +
-</WRAP> +
- +
-Fichier : `td3/main.tf` +
-<sxh hcl> +
-# Recuperation du VPC existant du TD2 +
-data "aws_vpc" "td2" { +
-  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> </sxh>
  
-<WRAP round help+Fichier : `td3/main.tf` — compléter après les data sources 
-Une data source ne crée rien dans AWS.+<sxh js
 +data "aws_caller_identity" "current" {}
  
-Que fait Terraform quand il rencontre un bloc `data` lors d'un `terraform plan` ? +module "kms" { 
- +  source     "./modules/kms
-Que se passe-t-il si la ressource référencée n'existe pas ? +  account_id data.aws_caller_identity.current.account_id
-</WRAP> +
- +
-===== 5Module secrets ===== +
- +
-Objectif : stocker le mot de passe dans AWS Secrets Manager, pas dans le code. +
- +
-<WRAP round todo> +
-Créer le module de gestion des secrets. +
-</WRAP> +
- +
-Fichier : `td3/modules/secrets/main.tf` +
-<sxh hcl> +
-variable "db_password" { +
-  type      string +
-  sensitive = true+
 } }
  
-resource "aws_secretsmanager_secret" "db_credentials" { 
-  name                    = "td3/database/credentials" 
-  description             = "Identifiants de la base de donnees TD3" 
-  recovery_window_in_days = 0 
-} 
- 
-resource "aws_secretsmanager_secret_version" "db_credentials" { 
-  secret_id = aws_secretsmanager_secret.db_credentials.id 
- 
-  secret_string = jsonencode({ 
-    username = "td3admin" 
-    password = var.db_password 
-  }) 
-} 
- 
-output "secret_arn" { 
-  description = "ARN du secret a transmettre au module database" 
-  value       = aws_secretsmanager_secret.db_credentials.arn 
-} 
-</sxh> 
- 
-<WRAP round help> 
-Le secret est stocké au format JSON avec deux champs : `username` et `password`. 
- 
-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 ? 
-</WRAP> 
- 
-<WRAP round help> 
-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 ? 
- 
-Pourquoi cette valeur par défaut existe-t-elle en production ? 
-</WRAP> 
- 
-<WRAP round todo> 
-Ajouter l'appel au module dans le fichier principal. 
-</WRAP> 
- 
-Fichier : `td3/main.tf` — ajouter après les data sources 
-<sxh hcl> 
 module "secrets" { module "secrets" {
   source      = "./modules/secrets"   source      = "./modules/secrets"
-  db_password = var.db_initial_password+  db_username = "td3admin" 
 +  db_password = var.db_password
 } }
-</sxh> 
  
-===== 6Probleme volontaire : ordre d'execution =====+module "storage"
 +  source "./modules/storage"
  
-<WRAP round todo> +  kms_key_arn = module.kms.key_arn
-Avant d'aller plus loin, tenter d'écrire à la main un bloc `data` qui lirait le secret qu'on vient de créer :+
  
-<sxh hcl> +  db_username = module.secrets.db_username 
-data "aws_secretsmanager_secret_version" "test" { +  db_password module.secrets.db_password
-  secret_id "td3/database/credentials" +
-+
-</sxh>+
  
-Ajouter ce bloc temporairement dans `main.tf` et lancer :+  subnet_ids = [ 
 +    data.aws_subnet.private.id, 
 +    data.aws_subnet.private_b.id 
 +  ]
  
-<sxh bash> +  security_group_id = data.aws_security_group.rds.id
-terraform plan +
-</sxh> +
-</WRAP>+
  
-<WRAP round help> +  bucket_name var.s3_app_bucket_name
-Que se passe-t-il lors du plan ? +
- +
-Terraform signale-t-il une erreur, et si oui, laquelle ? +
- +
-Pourquoi Terraform ne peut-il pas garantir que le secret existe au moment où la data source est évaluée ? +
-</WRAP> +
- +
-<WRAP round help> +
-Quelle est la différence fondamentale entre un bloc `resource` et un bloc `data` dans le cycle d'exécution Terraform ? +
- +
-Lequel est évalué lors de la phase de lecture, avant toute création ? +
-</WRAP> +
- +
-<WRAP round todo> +
-Supprimer ce bloc temporaire avant de continuer. +
-</WRAP> +
- +
-===== 7Module database ===== +
- +
-Objectif : remplacer la ressource RDS du TD2 par une version sécurisée. +
- +
-La dépendance entre le secret et la base est gérée implicitement via le passage de l'ARN en variable. +
- +
-Terraform comprend qu'il doit créer le secret avant de lire son contenu car la valeur vient d'un output du module `secrets`. +
- +
-<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"+
 } }
  
-variable "db_subnet_group_name" { +module "logging" { 
-  type        = string +  source      = "./modules/logging
-  description = "Nom du subnet group RDS existant" +  bucket_name = var.s3_logs_bucket_name 
-+  kms_key_arn module.kms.key_arn 
- +  account_id  data.aws_caller_identity.current.account_id
-variable "vpc_security_group_ids" { +
-  type        = list(string) +
-  description = "Liste des Security Group IDs autorises a acceder a la base" +
-+
- +
-data "aws_secretsmanager_secret_version" "db_credentials"+
-  secret_id = var.secret_arn +
-+
- +
-locals { +
-  db_creds jsondecode(data.aws_secretsmanager_secret_version.db_credentials.secret_string) +
-+
- +
-resource "aws_db_instance" "main" { +
-  identifier        = "td3-database" +
-  engine            "postgres" +
-  engine_version    = "15" +
-  instance_class    = "db.t3.micro" +
-  allocated_storage = 20 +
- +
-  db_name  = "td3app" +
-  username = local.db_creds["username"+
-  password = local.db_creds["password"+
- +
-  db_subnet_group_name   = var.db_subnet_group_name +
-  vpc_security_group_ids = var.vpc_security_group_ids +
- +
-  storage_encrypted   = true +
-  skip_final_snapshot = true +
- +
-  tags = { +
-    Name = "td3-database" +
-  } +
-+
- +
-output "db_endpoint"+
-  description = "Endpoint de connexion a la base de donnees" +
-  value       = aws_db_instance.main.endpoint+
 } }
 </sxh> </sxh>
  
-<WRAP round todo+<WRAP round question
-Ajouter l'appel au module database dans le fichier principal. +Le module `secrets` expose `db_username` et `db_password` via ses outputs.
-</WRAP>+
  
-Fichier : `td3/main.tf` — ajouter après le module secrets +Regarder la définition des outputs dans `td3/modules/secrets/outputs.tf`.
-<sxh hcl> +
-module "database"+
-  source      = "./modules/database" +
-  secret_arn  = module.secrets.secret_arn+
  
-  db_subnet_group_name   = data.aws_db_subnet_group.main.name +Que faut-il ajouter sur l'output `db_passwordpour que la valeur ne s'affiche pas dans le terminal lors d'un `terraform output` ?
-  vpc_security_group_ids = [data.aws_security_group.backend.id] +
-+
-</sxh> +
- +
-<WRAP round help> +
-La valeur `module.secrets.secret_arnest 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_onexplicite malgré tout ?+
 </WRAP> </WRAP>
  
-<WRAP round help> +Fichier : `td3/modules/secrets/outputs.tf` — ajouter les outputs manquants 
-Le paramètre `storage_encrypted = true` a été ajouté. +<sxh js
- +output "db_username" { 
-Que protège exactement ce chiffrement ? +  value       var.db_username 
- +  description = "Nom d'utilisateur de la base de données"
-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" { +output "db_password" { 
-  bucket "td3-secure-data-${random_id.bucket_suffix.hex}" +  value       var.db_password 
- +  description = "Mot de passe de la base de données
-  tags = { +  sensitive   = true
-    Name = "td3-secure-data+
-  +
-+
- +
-resource "aws_s3_bucket_server_side_encryption_configuration" "secure_data"+
-  bucket = aws_s3_bucket.secure_data.id +
- +
-  rule { +
-    apply_server_side_encryption_by_default { +
-      sse_algorithm = "AES256" +
-    } +
-    bucket_key_enabled = true +
-  } +
-+
- +
-resource "aws_s3_bucket_public_access_block" "secure_data"+
-  bucket = aws_s3_bucket.secure_data.id +
- +
-  block_public_acls       = true +
-  block_public_policy     = true +
-  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> </sxh>
  
-<WRAP round todo> +===== 11Déploiement et vérification =====
-Ajouter l'appel au module storage dans le fichier principal. +
-</WRAP>+
  
-Fichier : `td3/main.tf— ajouter après le module database +Fichier : `td3/commandes/terraform.txt
-<sxh hcl+<sxh bash
-module "storage" { +# Se placer dans le dossier td3 
-  source = "./modules/storage" +cd tp-aws/td3
-+
-</sxh>+
  
-<WRAP round help> +# Initialiser le projet 
-La configuration `apply_server_side_encryption_by_default` est activée.+terraform init
  
-Que se passe-t-il si un développeur uploade un fichier sans spécifier de chiffrement dans son appel SDK ou CLI ?+# Vérifier le plan – inspecter les ressources créées et les data sources résolus 
 +terraform plan -var="db_password=VotreMotDePasse123!"
  
-La configuration par défaut s'applique-t-elle automatiquement ? +# Appliquer 
-</WRAP>+terraform apply -var="db_password=VotreMotDePasse123!"
  
-<WRAP round help> +# Vérifier les outputs 
-Les quatre paramètres `block_public_acls`, `block_public_policy`, `ignore_public_acls` et `restrict_public_buckets` sont tous activés.+terraform output
  
-Les Security Groups du TD2 contrôlent déjà le trafic réseau vers les instances.+# Vérifier le secret dans AWS CLI 
 +aws secretsmanager get-secret-value --secret-id td3/db/credentials --region eu-west-3
  
-Pourquoi bloquer également les accès publics au niveau du bucket S3 ?+# Vérifier que le bucket S3 est bien chiffré 
 +aws s3api get-bucket-encryption --bucket td3-app-bucket-demo --region eu-west-3
  
-S3 est-il soumis aux Security Groups ? +# Vérifier que CloudTrail est actif 
-</WRAP> +aws cloudtrail get-trail-status --name td3-cloudtrail --region eu-west-3
- +
-===== 9. Module logging ===== +
- +
-Objectif : tracer toutes les actions réalisées sur le compte AWS via CloudTrail. +
- +
-CloudTrail écrit ses logs dans un bucket S3 dédié. +
- +
-AWS exige une policy bucket explicite pour autoriser CloudTrail à écrire. +
- +
-Sans cette policy, la ressource `aws_cloudtrail` échoue au déploiement. +
- +
-<WRAP round todo> +
-Créer le module de logging. +
-</WRAP> +
- +
-Fichier : `td3/modules/logging/main.tf` +
-<sxh hcl> +
-data "aws_caller_identity" "current" {} +
- +
-resource "aws_s3_bucket" "cloudtrail_logs"+
-  bucket = "td3-cloudtrail-${data.aws_caller_identity.current.account_id}" +
- +
-  tags = { +
-    Name = "td3-cloudtrail-logs" +
-  } +
-+
- +
-resource "aws_s3_bucket_public_access_block" "cloudtrail_logs"+
-  bucket = aws_s3_bucket.cloudtrail_logs.id +
- +
-  block_public_acls       = true +
-  block_public_policy     = true +
-  ignore_public_acls      = true +
-  restrict_public_buckets = true +
-+
- +
-resource "aws_s3_bucket_policy" "cloudtrail_logs"+
-  bucket = aws_s3_bucket.cloudtrail_logs.id +
- +
-  policy = jsonencode({ +
-    Version = "2012-10-17" +
-    Statement = [ +
-      { +
-        Sid    = "AWSCloudTrailAclCheck" +
-        Effect = "Allow" +
-        Principal = { +
-          Service = "cloudtrail.amazonaws.com" +
-        } +
-        Action   = "s3:GetBucketAcl" +
-        Resource = aws_s3_bucket.cloudtrail_logs.arn +
-      }, +
-      { +
-        Sid    = "AWSCloudTrailWrite" +
-        Effect = "Allow" +
-        Principal = { +
-          Service = "cloudtrail.amazonaws.com" +
-        } +
-        Action   = "s3:PutObject" +
-        Resource = "${aws_s3_bucket.cloudtrail_logs.arn}/AWSLogs/${data.aws_caller_identity.current.account_id}/*" +
-        Condition = { +
-          StringEquals = { +
-            "s3:x-amz-acl" = "bucket-owner-full-control" +
-          } +
-        } +
-      } +
-    ] +
-  }) +
- +
-  depends_on = [aws_s3_bucket_public_access_block.cloudtrail_logs] +
-+
- +
-resource "aws_cloudtrail" "main"+
-  name                          = "td3-audit-trail" +
-  s3_bucket_name                = aws_s3_bucket.cloudtrail_logs.id +
-  include_global_service_events = true +
-  is_multi_region_trail         = false +
-  enable_log_file_validation    = true +
- +
-  tags = { +
-    Name = "td3-audit-trail" +
-  } +
- +
-  depends_on = [aws_s3_bucket_policy.cloudtrail_logs] +
-+
- +
-output "cloudtrail_name"+
-  description = "Nom du trail CloudTrail actif" +
-  value       = aws_cloudtrail.main.name +
-}+
 </sxh> </sxh>
  
 <WRAP round todo> <WRAP round todo>
-Ajouter l'appel au module logging dans le fichier principal. +Après le déploiement, vérifier manuellement dans la console AWS :
-</WRAP>+
  
-Fichier : `td3/main.tf— ajouter en dernier +  * Secrets Manager le secret `td3/db/credentialsest visible et déchiffrable 
-<sxh hcl> +  * KMS : la clé `alias/td3-key` est active avec rotation activée 
-module "logging" { +  * RDS l'instance `td3-dbindique `Encrypted: Yesdans ses propriétés 
-  source = "./modules/logging" +  * S3 : le bucket applicatif indique `SSE-KMS` dans ses propriétés de chiffrement 
-} +  * CloudTrail : le trail `td3-cloudtrailest actif et envoie des logs dans le bucket
-</sxh> +
- +
-<WRAP round help> +
-La policy S3 contient deux instructions distinctes : `AWSCloudTrailAclChecket `AWSCloudTrailWrite`+
- +
-Pourquoi CloudTrail a-t-il besoin de lire l'ACL du bucket avant d'y écrire ? +
- +
-Que se serait-il passé si on avait appliqué `aws_cloudtrail` sans cette policy ?+
 </WRAP> </WRAP>
  
-<WRAP round help> +===== 12Lecture des logs CloudTrail =====
-Le paramètre `enable_log_file_validation true` est activé.+
  
-Que génère AWS pour permettre cette validation ? +Objectif : naviguer dans les logs CloudTrail pour retrouver une action spécifique.
- +
-Comment un administrateur peut-il vérifier qu'un fichier de log n'a pas été modifié ou supprimé ? +
-</WRAP> +
- +
-<WRAP round help> +
-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 ? +
- +
-Quelle différence entre CloudTrail et VPC Flow Logs ? +
-</WRAP> +
- +
-===== 10Fichier outputs global =====+
  
 <WRAP round todo> <WRAP round todo>
-Créer le fichier d'outputs du projet TD3. +Dans la console AWS, ouvrir CloudTrail puis Event History.
-</WRAP>+
  
-Fichier : `td3/outputs.tf` +Filtrer les événements par type `CreateSecret`.
-<sxh hcl> +
-output "db_endpoint"+
-  description = "Endpoint de la base de donnees TD3" +
-  value       = module.database.db_endpoint +
-}+
  
-output "secure_bucket_name"+Retrouver l'événement correspondant à la création du secret TD3.
-  description = "Nom du bucket S3 securise" +
-  value       = module.storage.bucket_name +
-}+
  
-output "cloudtrail_name"+Identifier les champs suivants dans l'événement :
-  description = "Nom du trail CloudTrail actif" +
-  value       = module.logging.cloudtrail_name +
-+
-</sxh>+
  
-===== 11. Deploiement complet ===== +  * `userIdentity` : qui a réalisé l'action 
- +  * `eventTime` : quand 
-<WRAP round todo> +  * `sourceIPAddress` : depuis quelle IP 
-Initialiser le projet et vérifier le plan avant d'appliquer. +  * `requestParameters` : quel secret a été créé
- +
-<sxh bash> +
-cd td3/ +
-terraform init +
-terraform plan +
-terraform apply +
-</sxh> +
- +
-Relever les outputs après application.+
 </WRAP> </WRAP>
  
-<WRAP round help+<WRAP round question
-Lors du `terraform plan`, combien de ressources sont listées comme créer ?+Un collègue vous signale qu'une clé KMS été désactivée à 3h du matin sans explication.
  
-Les data sources vers le TD2 apparaissent-elles dans le plan ?+Quelle requête effectuer dans CloudTrail pour retrouver cet événement ?
  
-Que se passe-t-il si le VPC `td2-vpc` n'existe pas au moment du plan ?+Quels champs de l'événement permettent d'identifier l'auteur de l'action ?
 </WRAP> </WRAP>
  
-===== 12. Simulation d'un incident et lecture des logs =====+===== Challenge final =====
  
-Objectif : vérifier que CloudTrail trace bien les actions réalisées sur le compte.+L'audit de sécurité est terminé.
  
-<WRAP round todo> +Rédiger un rapport de remédiation qui couvre les quatre axes suivants.
-Modifier temporairement un Security Group du TD2 via Terraform.+
  
-Par exemple, rouvrir le port 5432 sur `0.0.0.0/0` dans `td2/network/security_groups.tf`.+**Axe 1 – Secrets**
  
-Appliquer ce changement :+Expliquer comment les identifiants RDS sont maintenant gérés.
  
-<sxh bash> +Comparer l'état avant TD3 et l'état après TD3.
-cd td2/ +
-terraform apply +
-</sxh>+
  
-Attendre deux minutes.+Indiquer ce qui resterait à améliorer si l'application backend devait récupérer elle-même le secret.
  
-Se connecter à la console AWS et naviguer vers :+**Axe 2 – Clés KMS**
  
-  CloudTrail > Event history+Décrire le cycle de vie de la clé créée dans ce TD.
  
-Filtrer par nom d'événement : `AuthorizeSecurityGroupIngress` +Expliquer ce qui se passe lors de la rotation automatique.
-</WRAP>+
  
-<WRAP round help> +Indiquer le délai de suppression et pourquoi il est important.
-L'événement est-il visible dans CloudTrail ?+
  
-Quelles informations sont disponibles dans le détail de l'événement : +**Axe 3 – Chiffrement des données**
-  quel utilisateur ou rôle IAM a réalisé l'action ? +
-  depuis quelle adresse IP ? +
-  à quelle heure exactement ? +
-  quelle ressource a été modifiée ? +
-</WRAP>+
  
-<WRAP round help> +Compléter le tableau suivant :
-Un Security Group du TD2 a été ouvert sur Internet par erreur un vendredi soir. +
- +
-L'équipe le découvre le lundi matin. +
- +
-Comment CloudTrail permet-il de répondre aux questions suivantes sans CloudTrail et avec CloudTrail : +
-  * depuis combien de temps la faille est-elle ouverte ? +
-  * qui a fait la modification ? +
-  * s'agit-il d'une erreur ou d'un acte malveillant ? +
-</WRAP> +
- +
-<WRAP round todo> +
-Remettre le Security Group du TD2 dans son état sécurisé après l'exercice.+
  
 +Fichier : `td3/rapport/chiffrement.md`
 <sxh bash> <sxh bash>
-cd td2+| Ressource  | Type de chiffrement | Clé utilisée        | Données protégées         | 
-terraform apply+|------------|---------------------|---------------------|---------------------------| 
 +| 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> </sxh>
-</WRAP> 
  
-<WRAP round help> +**Axe 4 – Traçabilité**
-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 ? +Décrire ce que CloudTrail trace dans le contexte de ce TD.
-</WRAP>+
  
-===== 13Vérification globale =====+Expliquer pourquoi le bucket de logs est lui-même protégé par une policy stricte.
  
-<WRAP round todo> +Indiquer comment détecter une tentative de suppression des logs CloudTrail.
-Vérifier les points suivants avant de passer au challenge : +
- +
-  * aucun mot de passe n'apparait dans les fichiers `.tf` +
-  * 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** +
- +
-<WRAP round help> +
-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 ? +
- +
-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 ? +
-</WRAP> +
- +
-**Axe chiffrement** +
- +
-<WRAP round help> +
-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 ? +
- +
-Dans quel cas le chiffrement AES256 de S3 ne suffit-il pas a garantir la confidentialite des données ? +
-</WRAP> +
- +
-**Axe traçabilité** +
- +
-<WRAP round help> +
-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 ? +
- +
-Comment aurait-on pu protéger cette ressource contre une suppression accidentelle ? +
- +
-Chercher le paramètre Terraform qui permet de protéger une ressource contre la destruction. +
-</WRAP> +
- +
-**Axe architecture**+
  
 <WRAP round todo> <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   * 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   * une légende distinguant les flux chiffrés et les flux non chiffrés
Ligne 1600: Ligne 895:
  
 Fichier : `td3/modules/secrets/main.tf` — ajouter après la ressource `aws_secretsmanager_secret_version` Fichier : `td3/modules/secrets/main.tf` — ajouter après la ressource `aws_secretsmanager_secret_version`
-<sxh hcl>+<sxh js>
 variable "rotation_lambda_arn" { variable "rotation_lambda_arn" {
   type        = string   type        = string
Ligne 1618: Ligne 913:
 </sxh> </sxh>
  
-<WRAP round help>+<WRAP round question>
 Le bloc `count = var.rotation_lambda_arn != "" ? 1 : 0` est utilisé ici. Le bloc `count = var.rotation_lambda_arn != "" ? 1 : 0` est utilisé ici.
  
 Que signifie ce pattern dans Terraform ? 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>
  
-<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 ? Si l'application a mis le mot de passe en cache au démarrage, que se passe-t-il après une rotation ?
  • eadl/bloc4/fm4/td3.1782281394.txt.gz
  • Dernière modification : il y a 3 semaines
  • de jcheron