eadl:bloc4:fm4:td2

Différences

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

Lien vers cette vue comparative

Prochaine révision		 Révision précédente
eadl:bloc4:fm4:td2 [2026/06/14 12:42] – créée jcheroneadl:bloc4:fm4:td2 [2026/06/14 17:07] (Version actuelle) – [6. Correction – restriction du backend] jcheron
Ligne 1: Ligne 1:
-====== TD2 – Sécurisation réseau AWS (VPC, Subnets, Security Groups) ======+====== TD2 – Sécurisation réseau AWS (VPC, Security Groups, ALB) ======
  
 ===== Objectifs ===== ===== Objectifs =====
  
-  * Comprendre les bases du réseau AWS (VPC, subnets, routing) +  * Comprendre la segmentation réseau dans AWS avec VPC et subnets 
-  * Identifier les mauvaises pratiques réseau +  * Identifier les mauvaises pratiques de sécurité réseau 
-  * Sécuriser une infrastructure existante +  * Mettre en place un point d'entrée unique avec un ALB 
-  * Implémenter une segmentation réseau simple +  * Contrôler les flux réseau avec les Security Groups 
-  * Industrialiser avec Terraform+  * Appliquer le principe du moindre privilège sur chaque couche
  
 ===== Contexte ===== ===== Contexte =====
  
-Vous intervenez dans la même startup.+Vous intervenez en tant qu'ingénieur DevOps dans une startup.
  
-Une première infrastructure a été déployée rapidement via Terraform et Ansible.+L'équipe de développement a déployé une application backend sur AWS via Terraform.
  
-Objectif initial : mettre en ligne une application web.+Le déploiement a été fait rapidement pour respecter un délai.
  
 Résultat : Résultat :
  
-  * tout fonctionne +  * l'application fonctionne 
-  * mais aucune règle de sécurité réseau n’a été pensée+  * mais toute l'infrastructure est directement exposée sur Internet
  
-Un audit révèle :+Un audit de sécurité interne a identifié trois problèmes critiques :
  
-  * exposition publique excessive +  * le port applicatif du backend est ouvert à Internet 
-  * absence de segmentation réseau +  * le port de la base de données est ouvert à Internet 
-  * règles de sécurité trop permissives+  * aucun point d'entrée centralisé ne permet de contrôler le trafic
  
-===== Objectif technique =====+Votre mission : transformer l'architecture sans interrompre le service.
  
-Reconcevoir le réseau pour :+===== Architecture cible =====
  
-  * isoler les composants +L'architecture actuelle : 
-  * limiter les flux + 
-  * respecter les bonnes pratiques AWS+  Internet → Backend (port 80 ouvert partout) 
 +  Internet → DB (port 5432 ouvert partout) 
 + 
 +L'architecture cible : 
 + 
 +  Internet → ALB (port 80) → Backend (port 80, privé) → DB (port 5432, isolée)
  
 ===== Contraintes ===== ===== Contraintes =====
  
-  * Ne pas casser l’accès à l’application web +  * L'application doit rester accessible depuis Internet 
-  * Appliquer le principe du moindre accès réseau +  * Le backend ne doit plus être accessible directement depuis Internet 
-  * Utiliser Terraform uniquement +  * La base de données ne doit être accessible que depuis le backend 
-  * Architecture simple et compréhensible+  * Tout le code est en Terraform
  
-===== Infrastructure existante =====+===== Pré-requis =====
  
-Fichier : `network/main.tf`+  * Terraform installé et configuré 
 +  * Credentials AWS valides 
 +  * Notions de base : VPC, subnet, Security Group 
 + 
 +===== Infrastructure de départ ===== 
 + 
 +L'infrastructure existante présente plusieurs problèmes volontaires. 
 + 
 +Lire le code attentivement avant de l'appliquer. 
 + 
 +Fichier : `td2/network/main.tf`
 <sxh js> <sxh js>
 provider "aws" { provider "aws" {
-  region = "eu-west-1"+  region = "eu-west-3"
 } }
  
 +# VPC principal
 resource "aws_vpc" "main" { resource "aws_vpc" "main" {
-  cidr_block = "10.0.0.0/16"+  cidr_block           = "10.0.0.0/16" 
 +  enable_dns_hostnames = true 
 + 
 +  tags = { 
 +    Name = "td2-vpc" 
 +  }
 } }
  
-resource "aws_subnet" "public" { +# Passerelle Internet 
-  vpc_id     = aws_vpc.main.id +resource "aws_internet_gateway" "igw" { 
-  cidr_block = "10.0.1.0/24"+  vpc_id = aws_vpc.main.id 
 + 
 +  tags = { 
 +    Name = "td2-igw" 
 +  }
 } }
  
-resource "aws_instance" "web" { +# Subnet public – AZ a 
-  ami           = "ami-123456" +resource "aws_subnet" "public_a" { 
-  instance_type = "t2.micro" +  vpc_id                  = aws_vpc.main.id 
-  subnet_id     = aws_subnet.public.id+  cidr_block              = "10.0.1.0/24" 
 +  availability_zone       = "eu-west-3a" 
 +  map_public_ip_on_launch = true 
 + 
 +  tags = { 
 +    Name = "td2-public-a" 
 +  }
 } }
  
-resource "aws_security_group" "web_sg" { +# Subnet public – AZ b (requis par l'ALB) 
-  name   = "web-sg"+resource "aws_subnet" "public_b" { 
 +  vpc_id                  = aws_vpc.main.id 
 +  cidr_block              = "10.0.2.0/24" 
 +  availability_zone       = "eu-west-3b" 
 +  map_public_ip_on_launch = true 
 + 
 +  tags = { 
 +    Name = "td2-public-b" 
 +  } 
 +} 
 + 
 +# Subnet privé – DB 
 +resource "aws_subnet" "private" { 
 +  vpc_id            = aws_vpc.main.id 
 +  cidr_block        = "10.0.3.0/24" 
 +  availability_zone = "eu-west-3a" 
 + 
 +  tags = { 
 +    Name = "td2-private" 
 +  } 
 +} 
 + 
 +# Table de routage publique 
 +resource "aws_route_table" "public" { 
 +  vpc_id = aws_vpc.main.id 
 + 
 +  route { 
 +    cidr_block = "0.0.0.0/0" 
 +    gateway_id = aws_internet_gateway.igw.id 
 +  } 
 + 
 +  tags = { 
 +    Name = "td2-rt-public" 
 +  } 
 +} 
 + 
 +resource "aws_route_table_association" "public_a" { 
 +  subnet_id      = aws_subnet.public_a.id 
 +  route_table_id = aws_route_table.public.id 
 +} 
 + 
 +resource "aws_route_table_association" "public_b" { 
 +  subnet_id      = aws_subnet.public_b.id 
 +  route_table_id = aws_route_table.public.id 
 +} 
 +</sxh> 
 + 
 +Fichier : `td2/network/security_groups.tf` 
 +<sxh js> 
 +# Security Group backend – PROBLEME VOLONTAIRE 
 +# Ce fichier sera modifié au cours du TD 
 +resource "aws_security_group" "backend_sg" { 
 +  name   = "backend-sg"
   vpc_id = aws_vpc.main.id   vpc_id = aws_vpc.main.id
  
   ingress {   ingress {
 +    description = "HTTP depuis Internet"
 +    from_port   = 80
 +    to_port     = 80
 +    protocol    = "tcp"
 +    cidr_blocks = ["0.0.0.0/0"]
 +  }
 +
 +  egress {
     from_port   = 0     from_port   = 0
     to_port     = 0     to_port     = 0
     protocol    = "-1"     protocol    = "-1"
 +    cidr_blocks = ["0.0.0.0/0"]
 +  }
 +
 +  tags = {
 +    Name = "backend-sg"
 +  }
 +}
 +
 +# Security Group DB – PROBLEME VOLONTAIRE
 +resource "aws_security_group" "db_sg" {
 +  name   = "db-sg"
 +  vpc_id = aws_vpc.main.id
 +
 +  ingress {
 +    description = "PostgreSQL depuis Internet"
 +    from_port   = 5432
 +    to_port     = 5432
 +    protocol    = "tcp"
     cidr_blocks = ["0.0.0.0/0"]     cidr_blocks = ["0.0.0.0/0"]
   }   }
Ligne 82: Ligne 191:
     protocol    = "-1"     protocol    = "-1"
     cidr_blocks = ["0.0.0.0/0"]     cidr_blocks = ["0.0.0.0/0"]
 +  }
 +
 +  tags = {
 +    Name = "db-sg"
 +  }
 +}
 +</sxh>
 +
 +Fichier : `td2/network/instances.tf`
 +<sxh js>
 +resource "aws_instance" "backend" {
 +  ami                    = "ami-0f61de2873e29e866"
 +  instance_type          = "t2.micro"
 +  subnet_id              = aws_subnet.public_a.id
 +  vpc_security_group_ids = [aws_security_group.backend_sg.id]
 +
 +  user_data = <<-EOF
 +    #!/bin/bash
 +    yum install -y python3
 +    python3 -m http.server 80 &
 +  EOF
 +
 +  tags = {
 +    Name = "td2-backend"
 +  }
 +}
 +
 +resource "aws_db_instance" "db" {
 +  identifier             = "td2-db"
 +  engine                 = "postgres"
 +  engine_version         = "15"
 +  instance_class         = "db.t3.micro"
 +  allocated_storage      = 20
 +  username               = "admin"
 +  password               = "changeme123"
 +  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 = "td2-db"
 +  }
 +}
 +
 +resource "aws_db_subnet_group" "main" {
 +  name       = "td2-db-subnet-group"
 +  subnet_ids = [aws_subnet.private.id, aws_subnet.public_b.id]
 +
 +  tags = {
 +    Name = "td2-db-subnet-group"
   }   }
 } }
 </sxh> </sxh>
  
-===== Ressources =====+===== Commandes Terraform =====
  
-Fichier : `commandes/terraform.txt`+Fichier : `td2/commandes/terraform.txt`
 <sxh bash> <sxh bash>
 +# Initialiser le projet
 terraform init terraform init
 +
 +# Vérifier le plan sans appliquer
 terraform plan terraform plan
 +
 +# Appliquer la configuration
 terraform apply terraform apply
 +
 +# Récupérer les outputs
 +terraform output
 +
 +# Détruire l'infrastructure
 terraform destroy terraform destroy
 </sxh> </sxh>
  
-===== 1. Compréhension de l’existant =====+===== 1. Lecture du code ===== 
 + 
 +Lire les trois fichiers avant toute manipulation.
  
 <WRAP round question> <WRAP round question>
-Quels composants réseau sont présents ?+Lister les ressources présentes dans le code.
  
-Que manque-t-il pour une architecture AWS correcte ?+Pour chaque ressource, indiquer : 
 +  * son rôle 
 +  * le subnet dans lequel elle est placée 
 +  * les ports ouverts en entrée
 </WRAP> </WRAP>
  
 <WRAP round question> <WRAP round question>
-Pourquoi cette infrastructure fonctionne malgré tout ?+Pourquoi l'ALB nécessite-t-il deux subnets dans deux zones de disponibilité différentes ?
  
-Quels sont les risques immédiats ?+Quelle contrainte AWS cela reflète-t-il ?
 </WRAP> </WRAP>
  
-===== 2. Analyse des problèmes =====+<WRAP round question> 
 +La base de données est une instance RDS et non une instance EC2. 
 + 
 +Quelle est la différence en termes de gestion et de sécurité ? 
 +</WRAP> 
 + 
 +===== 2. Identification des problèmes ===== 
 + 
 +<WRAP round todo> 
 +Identifier dans `security_groups.tf` les deux règles les plus dangereuses. 
 + 
 +Pour chaque règle : 
 +  * expliquer ce qu'elle autorise concrètement 
 +  * expliquer ce qu'un attaquant pourrait faire avec cet accès 
 +</WRAP>
  
 <WRAP round question> <WRAP round question>
-Identifier les problèmes de sécurité :+Le mot de passe de la base de données est en clair dans le fichier Terraform.
  
-  * au niveau du VPC +Quel problème cela pose-t-il ? 
-  * au niveau des subnets + 
-  * au niveau des Security Groups+Ce problème sera traité dans un TD ultérieur sur la gestion des secrets.
 </WRAP> </WRAP>
  
 <WRAP round question> <WRAP round question>
-Quelle est la règle la plus dangereuse dans ce code ?+La base de données RDS est placée dans un subnet group qui inclut le subnet `public_b`.
  
-Pourquoi ?+Est-ce un problème ? Pourquoi ?
 </WRAP> </WRAP>
  
-===== 3. Mise en pratique – segmentation réseau =====+===== 3. Déploiement de l'infrastructure initiale =====
  
 <WRAP round todo> <WRAP round todo>
 +Appliquer la configuration telle quelle :
  
-Modifier l’architecture pour :+  terraform apply
  
-  * créer 2 subnets : +Relever les outputs suivants : 
-    * public (web) +  * IP publique de l'instance backend 
-    * privé (backend ou base de données)+  * endpoint de la base RDS 
 +</WRAP>
  
-  * ajouter un Internet Gateway+Fichier : `td2/network/outputs.tf` 
 +<sxh js> 
 +output "backend_public_ip" { 
 +  value       = aws_instance.backend.public_ip 
 +  description = "IP publique du backend" 
 +} 
 + 
 +output "db_endpoint" { 
 +  value       = aws_db_instance.db.endpoint 
 +  description = "Endpoint de la base de données" 
 +} 
 +</sxh> 
 + 
 +<WRAP round todo> 
 +Tester l'accès au backend depuis un navigateur ou curl : 
 + 
 +  curl http://<backend_public_ip> 
 + 
 +Tenter une connexion à la base de données depuis votre poste : 
 + 
 +  psql -h <db_endpoint> -U admin -d postgres 
 + 
 +Noter le résultat de chaque test. 
 +</WRAP> 
 + 
 +<WRAP round question> 
 +Le backend répond-il ?
  
-  * rendre uniquement le subnet public accessible depuis Internet+La connexion à la base de données est-elle possible depuis votre poste ?
  
 +Pourquoi ce comportement est-il problématique dans un contexte de production ?
 </WRAP> </WRAP>
  
-===== 4. Mise en pratique – sécurisation des flux =====+===== 4. Mise en place de l'ALB =====
  
 <WRAP round todo> <WRAP round todo>
 +Créer le fichier suivant sans modifier les Security Groups existants.
 +</WRAP>
  
-Corriger les Security Groups :+Fichier : `td2/network/alb.tf` 
 +<sxh js> 
 +# Security Group de l'ALB 
 +resource "aws_security_group" "alb_sg" { 
 +  name   = "alb-sg" 
 +  vpc_id = aws_vpc.main.id
  
-  * Autoriser uniquement : +  ingress { 
-    * HTTP (80) depuis Internet vers le serveur web +    description = "HTTP depuis Internet" 
-    * SSH (22) uniquement depuis votre IP+    from_port   = 80 
 +    to_port     = 80 
 +    protocol    = "tcp" 
 +    cidr_blocks = ["0.0.0.0/0"] 
 +  }
  
-  * Interdire tout le reste+  egress { 
 +    from_port   = 0 
 +    to_port     = 0 
 +    protocol    = "-1" 
 +    cidr_blocks = ["0.0.0.0/0"] 
 +  }
  
-</WRAP>+  tags = { 
 +    Name = "alb-sg" 
 +  } 
 +}
  
-===== Point d’attention (erreur volontaire) =====+# Application Load Balancer 
 +resource "aws_lb" "main" { 
 +  name               = "td2-alb" 
 +  internal           = false 
 +  load_balancer_type = "application" 
 +  security_groups    = [aws_security_group.alb_sg.id] 
 +  subnets            = [aws_subnet.public_a.id, aws_subnet.public_b.id]
  
-Le code actuel autorise :+  tags = { 
 +    Name = "td2-alb" 
 +  } 
 +}
  
-  * tous les ports +# Target Group 
-  * tous les protocoles +resource "aws_lb_target_group" "backend" { 
-  * depuis n’importe où+  name     = "td2-backend-tg" 
 +  port     = 80 
 +  protocol = "HTTP" 
 +  vpc_id   = aws_vpc.main.id
  
-<WRAP round question> +  health_check { 
-Pourquoi cette configuration est-elle fréquente en phase de développement ?+    path                = "/" 
 +    healthy_threshold   = 2 
 +    unhealthy_threshold = 2 
 +    interval            = 30 
 +  }
  
-Pourquoi devient-elle critique en production ? +  tags = { 
-</WRAP>+    Name = "td2-backend-tg" 
 +  } 
 +}
  
-===== 5. Apparition d’un problème =====+# Attachement du backend au Target Group 
 +resource "aws_lb_target_group_attachment" "backend" { 
 +  target_group_arn = aws_lb_target_group.backend.arn 
 +  target_id        = aws_instance.backend.id 
 +  port             = 80 
 +}
  
-Après sécurisation :+# Listener HTTP 
 +resource "aws_lb_listener" "http" { 
 +  load_balancer_arn = aws_lb.main.arn 
 +  port              = 80 
 +  protocol          = "HTTP"
  
-  * votre application web ne répond plus+  default_action { 
 +    type             = "forward" 
 +    target_group_arn = aws_lb_target_group.backend.arn 
 +  } 
 +} 
 +</sxh> 
 + 
 +<WRAP round todo> 
 +Ajouter l'output du DNS de l'ALB dans `outputs.tf` : 
 + 
 +  output "alb_dns" { 
 +    value       = aws_lb.main.dns_name 
 +    description = "DNS public de l'ALB" 
 +  } 
 + 
 +Appliquer : 
 + 
 +  terraform apply 
 + 
 +Tester l'accès via l'ALB : 
 + 
 +  curl http://<alb_dns> 
 + 
 +Tester également l'accès direct au backend : 
 + 
 +  curl http://<backend_public_ip> 
 +</WRAP>
  
 <WRAP round question> <WRAP round question>
-Quelles sont les causes possibles ?+Les deux accès fonctionnent-ils ?
  
-Quels éléments réseau faut-il vérifier ?+Qu'est-ce que cela démontre sur l'état actuel de la sécurisation ? 
 + 
 +L'ALB est-il suffisant seul pour sécuriser le backend ?
 </WRAP> </WRAP>
  
-===== 6. Analyse =====+===== 5. Erreur courante – le backend reste exposé ===== 
 + 
 +L'ALB est en place mais le Security Group du backend n'a pas été modifié. 
 + 
 +Le port 80 du backend est toujours ouvert sur `0.0.0.0/0`.
  
 <WRAP round question> <WRAP round question>
-Vérifier :+Pourquoi ajouter un ALB ne suffit-il pas à protéger le backend ?
  
-  * association du Security Group +Quel composant contrôle réellement les accès réseau sur une instance AWS ? 
-  * table de routage +</WRAP> 
-  * subnet public vs privé + 
-  * présence d’une IP publique+===== 6. Correction – restriction du backend ===== 
 + 
 +<WRAP round todo> 
 +Modifier `security_groups.tf`.
  
-Lequel de ces éléments est souvent oublié ?+Remplacer la règle ingress du Security Group `backend_sg` : 
 +  * supprimer l'accès depuis `0.0.0.0/0` 
 +  * autoriser uniquement le trafic depuis le Security Group de l'ALB
 </WRAP> </WRAP>
  
-===== 7. Correction =====+Fichier : `td2/network/security_groups.tf` 
 +<sxh js> 
 +resource "aws_security_group" "backend_sg" { 
 +  name   = "backend-sg" 
 +  vpc_id = aws_vpc.main.id 
 + 
 +  ingress { 
 +    description     = "HTTP depuis l'ALB uniquement" 
 +    from_port       = 80 
 +    to_port         = 80 
 +    protocol        = "tcp" 
 +    security_groups = [aws_security_group.alb_sg.id] 
 +  } 
 + 
 +  egress { 
 +    from_port   = 0 
 +    to_port     = 0 
 +    protocol    = "-1" 
 +    cidr_blocks = ["0.0.0.0/0"] 
 +  } 
 + 
 +  tags = { 
 +    Name = "backend-sg" 
 +  } 
 +} 
 + 
 +resource "aws_security_group" "db_sg" { 
 +  name   = "db-sg" 
 +  vpc_id = aws_vpc.main.id 
 + 
 +  ingress { 
 +    description     = "PostgreSQL depuis le backend uniquement" 
 +    from_port       = 5432 
 +    to_port         = 5432 
 +    protocol        = "tcp" 
 +    security_groups = [aws_security_group.backend_sg.id] 
 +  } 
 + 
 +  egress { 
 +    from_port   = 0 
 +    to_port     = 0 
 +    protocol    = "-1" 
 +    cidr_blocks = ["0.0.0.0/0"] 
 +  } 
 + 
 +  tags = { 
 +    Name = "db-sg" 
 +  } 
 +} 
 +</sxh>
  
 <WRAP round todo> <WRAP round todo>
 +Appliquer les modifications :
  
-Corriger l’infrastructure pour :+  terraform apply
  
-  * restaurer l’accès web +Tester les deux accès :
-  * conserver les règles de sécurité+
  
 +  # Via l'ALB – doit fonctionner
 +  curl http://<alb_dns>
 +
 +  # Direct – doit échouer
 +  curl http://<backend_public_ip>
 </WRAP> </WRAP>
  
-===== 8. Extension =====+<WRAP round question> 
 +L'accès direct au backend est-il maintenant bloqué ?
  
-<WRAP round todo>+L'accès via l'ALB fonctionne-t-il toujours ?
  
-Ajouter :+Que se passe-t-il si le Health Check de l'ALB échoue ? 
 +Comment vérifier l'état du Target Group dans la console AWS ? 
 +</WRAP>
  
-  * un NAT Gateway pour le subnet privé +===== 7. Problème potentiel – Health Check =====
-  * permettre au backend d’accéder à Internet sans être exposé+
  
 +Après modification des Security Groups, l'ALB peut afficher le backend comme "unhealthy".
 +
 +<WRAP round question>
 +Expliquer ce qu'est un Health Check d'ALB.
 +
 +Quel flux réseau le Health Check génère-t-il ?
 +
 +Depuis quelle source arrive ce flux sur le backend ?
 </WRAP> </WRAP>
  
 <WRAP round question> <WRAP round question>
-Pourquoi ne faut-il jamais exposer directement une base de données sur Internet ?+Si le backend est "unhealthy", l'ALB cesse de lui envoyer du trafic. 
 + 
 +Le service devient indisponible même si le backend fonctionne. 
 + 
 +Quelle règle dans le Security Group du backend pourrait causer ce blocage ?
 </WRAP> </WRAP>
  
-===== 9. Bonnes pratiques =====+<WRAP round todo> 
 +Vérifier dans la console AWS : 
 +  * aller dans EC2 > Target Groups 
 +  * vérifier le statut de l'instance dans le Target Group 
 +  * lire le message d'erreur du Health Check si présent 
 +</WRAP> 
 + 
 +===== 8. Diagnostic et correction ===== 
 + 
 +<WRAP round todo> 
 +Si le Health Check échoue, identifier la cause : 
 + 
 +  * le port 80 est-il bien ouvert depuis le Security Group de l'ALB ? 
 +  * le service python3 est-il démarré sur l'instance ? 
 +  * la règle egress de l'ALB permet-elle les réponses ? 
 + 
 +Corriger la règle manquante et réappliquer. 
 +</WRAP> 
 + 
 +===== 9. Vérification finale ===== 
 + 
 +<WRAP round todo> 
 +Réaliser les tests suivants et noter les résultats dans un tableau : 
 + 
 +  * accès HTTP via l'ALB → attendu : 200 
 +  * accès HTTP direct au backend → attendu : timeout ou refus 
 +  * connexion PostgreSQL depuis votre poste → attendu : timeout ou refus 
 +  * connexion PostgreSQL depuis le backend → attendu : possible 
 +</WRAP>
  
 <WRAP round question> <WRAP round question>
-Pourquoi faut-il privilégier :+Comment vérifier qu'un flux est bien bloqué et non juste lent ?
  
-  * plusieurs subnets ? +Quelle différence entre un timeout et un Connection refused en termes de Security Group ?
-  * des Security Groups spécifiques par rôle ? +
-  * une séparation public / privé ?+
 </WRAP> </WRAP>
  
-===== Challenge final =====+===== 10. Extension – déplacement du backend en subnet privé =====
  
-Objectif :+Le backend a une IP publique car il est dans un subnet public.
  
-  * Le serveur web doit être accessible depuis Internet (HTTP) +Ce n'est pas nécessaire si l'ALB gère tout le trafic entrant.
-  * Le backend doit être inaccessible depuis Internet +
-  * Le backend doit être accessible uniquement depuis le serveur web+
  
 <WRAP round todo> <WRAP round todo>
 +Modifier `instances.tf` pour déplacer le backend dans le subnet privé :
  
-Implémenter cette architecture avec :+  subnet_id = aws_subnet.private.id
  
-  * 2 Security Groups +Supprimer également le `map_public_ip_on_launch` implicite.
-  * règles de flux précises+
  
 +Appliquer et vérifier que l'ALB continue de fonctionner.
 </WRAP> </WRAP>
  
 <WRAP round question> <WRAP round question>
-Pourquoi utiliser un Security Group comme source plutôt qu’une IP ?+Le backend n'a plus d'IP publique. 
 + 
 +Est-il encore accessible depuis Internet ? 
 + 
 +Comment l'ALB peut-il atteindre une instance dans un subnet privé ? 
 + 
 +Quel composant réseau manque pour que le backend puisse faire des appels sortants (mises à jour, appels API externes) ?
 </WRAP> </WRAP>
  
-===== Bonus =====+===== Challenge final ===== 
 + 
 +Objectif : valider l'architecture complète Internet → ALB → Backend → DB.
  
 <WRAP round todo> <WRAP round todo>
 +Dessiner l'architecture finale avec :
 +  * les subnets (public_a, public_b, private)
 +  * les composants dans chaque subnet
 +  * les Security Groups et leurs règles
 +  * les flux autorisés avec les ports
 +</WRAP>
  
-Ajouter :+<WRAP round todo> 
 +Répondre aux questions suivantes par écrit :
  
-  * un Load Balancer en frontal +  * Quel composant est le seul point d'entrée depuis Internet ? 
-  * plusieurs instances web+  * Quelles ressources ne sont plus accessibles directement depuis Internet ? 
 +  * Quel principe de sécurité est appliqué sur chaque Security Group ? 
 +  * Que se passe-t-il si l'ALB est supprimé ? L'application reste-t-elle accessible ? 
 +</WRAP> 
 + 
 +===== Bonus ===== 
 + 
 +<WRAP round todo> 
 +Ajouter une seconde instance backend dans `public_b` : 
 + 
 +  resource "aws_instance" "backend_b" { 
 +    ami                    = "ami-0f61de2873e29e866" 
 +    instance_type          = "t2.micro" 
 +    subnet_id              = aws_subnet.public_b.id 
 +    vpc_security_group_ids = [aws_security_group.backend_sg.id] 
 +    ... 
 +  }
  
 +Attacher cette instance au même Target Group.
 </WRAP> </WRAP>
  
 <WRAP round question> <WRAP round question>
-Quel est l’impact sécurité d’un Load Balancer par rapport à une instance seule ?+Quels sont les avantages d'avoir deux instances backend derrière un ALB ? 
 + 
 +Répondre selon deux axes : 
 +  * disponibilité : que se passe-t-il si une instance tombe ? 
 +  * sécurité : l'exposition du système augmente-t-elle ou diminue-t-elle ?
 </WRAP> </WRAP>
  
  • eadl/bloc4/fm4/td2.1781433768.txt.gz
  • Dernière modification : il y a 6 semaines
  • de jcheron