eadl:bloc4:fm4:td2

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:td2 [2026/06/14 12:59] – 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, flux applicatifs) ======+====== TD2 – Sécurisation réseau AWS (VPC, Security Groups, ALB) ======
  
 ===== Objectifs ===== ===== Objectifs =====
  
-  * Comprendre l’architecture réseau AWS (VPC, subnets, routage) +  * Comprendre la segmentation réseau dans AWS avec VPC et subnets 
-  * Identifier des failles réseau dans une infrastructure existante +  * Identifier les mauvaises pratiques de sécurité réseau 
-  * Mettre en place une segmentation réseau (public / privé) +  * Mettre en place un point d'entrée unique avec un ALB 
-  * Contrôler les flux entre services (web, backend, base de données) +  * Contrôler les flux réseau avec les Security Groups 
-  * Appliquer le principe du moindre accès réseau avec Terraform+  * Appliquer le principe du moindre privilège sur chaque couche
  
 ===== Contexte ===== ===== Contexte =====
  
-Vous intervenez dans une startup.+Vous intervenez en tant qu'ingénieur DevOps dans une startup.
  
-Une application a été déployée rapidement pour un MVP.+L'équipe de développement a déployé une application backend sur AWS via Terraform.
  
-Architecture actuelle :+Le déploiement a été fait rapidement pour respecter un délai.
  
-  * un serveur web accessible depuis Internet +Résultat :
-  * un backend applicatif +
-  * une base de données+
  
-Tout fonctionne, mais aucun design réseau n’a été pensé.+  * l'application fonctionne 
 +  * mais toute l'infrastructure est directement exposée sur Internet
  
-Un audit de sécurité impose :+Un audit de sécurité interne a identifié trois problèmes critiques :
  
-  * isolation des composants +  * le port applicatif du backend est ouvert à Internet 
-  * suppression des accès inutiles +  * le port de la base de données est ouvert à Internet 
-  * contrôle strict des flux réseau+  * 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 l’architecture réseau pour :+===== Architecture cible =====
  
-  * exposer uniquement le serveur web +L'architecture actuelle : 
-  * isoler le backend + 
-  * sécuriser la base de données +  Internet → Backend (port 80 ouvert partout) 
-  * contrôler précisément les flux entre les composants+  Internet → DB (port 5432 ouvert partout) 
 + 
 +L'architecture cible : 
 + 
 +  Internet → ALB (port 80) → Backend (port 80, privé) → DB (port 5432, isolée)
  
 ===== Contraintes ===== ===== Contraintes =====
  
-  * Le serveur web doit rester accessible en HTTP +  * L'application doit rester accessible depuis Internet 
-  * Le backend ne doit pas être accessible depuis Internet +  * Le backend ne doit plus être accessible directement depuis Internet 
-  * La base de données ne doit jamais être exposée +  * La base de données ne doit être accessible que depuis le backend 
-  * Chaque flux doit être justifié +  * Tout le code est en Terraform
-  * Toute la configuration doit être faite avec 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" "main" { +# 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.main.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_instance" "backend" { +# Subnet public – AZ b (requis par l'ALB) 
-  ami           = "ami-123456" +resource "aws_subnet" "public_b" { 
-  instance_type = "t2.micro" +  vpc_id                  = aws_vpc.main.id 
-  subnet_id     = aws_subnet.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" 
 +  }
 } }
  
-resource "aws_instance" "db" { +# Subnet privé – DB 
-  ami           = "ami-123456" +resource "aws_subnet" "private" { 
-  instance_type = "t2.micro" +  vpc_id            = aws_vpc.main.id 
-  subnet_id     = aws_subnet.main.id+  cidr_block        = "10.0.3.0/24" 
 +  availability_zone = "eu-west-3a" 
 + 
 +  tags = { 
 +    Name = "td2-private" 
 +  }
 } }
  
-resource "aws_security_group" "all_open" { +# Table de routage publique 
-  name   = "all-open"+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 97: 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> </sxh>
  
-===== Ressources =====+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]
  
-Commandes utiles :+  user_data = <<-EOF 
 +    #!/bin/bash 
 +    yum install -y python3 
 +    python3 -m http.server 80 & 
 +  EOF
  
-Fichier : `commandes/terraform.txt`+  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> 
 + 
 +===== Commandes Terraform ===== 
 + 
 +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. Analyse de l’existant =====+===== 1. Lecture du code ===== 
 + 
 +Lire les trois fichiers avant toute manipulation.
  
 <WRAP round question> <WRAP round question>
-Identifier les problèmes de sécurité présents dans cette infrastructure.+Lister les ressources présentes dans le code.
  
-Indiquer : +Pour chaque ressource, indiquer : 
-  * les problèmes critiques +  * son rôle 
-  * les problèmes de conception+  * le subnet dans lequel elle est placée 
 +  * les ports ouverts en entrée
 </WRAP> </WRAP>
- 
-===== 2. Compréhension des flux ===== 
  
 <WRAP round question> <WRAP round question>
-Quels sont les flux nécessaires au fonctionnement ?+Pourquoi l'ALB nécessite-t-il deux subnets dans deux zones de disponibilité différentes ?
  
-Lister précisément :+Quelle contrainte AWS cela reflète-t-il ? 
 +</WRAP>
  
-  * Internet → Web +<WRAP round question> 
-  * Web → Backend (port ?) +La base de données est une instance RDS et non une instance EC2.
-  * Backend → DB (port ?)+
  
-Quels flux doivent être interdits ?+Quelle est la différence en termes de gestion et de sécurité ?
 </WRAP> </WRAP>
  
-===== 3. Mise en pratique – segmentation réseau =====+===== 2. Identification des problèmes =====
  
 <WRAP round todo> <WRAP round todo>
 +Identifier dans `security_groups.tf` les deux règles les plus dangereuses.
  
-Modifier l’infrastructure pour créer :+Pour chaque règle : 
 +  * expliquer ce qu'elle autorise concrètement 
 +  * expliquer ce qu'un attaquant pourrait faire avec cet accès 
 +</WRAP>
  
-  * 1 subnet public (web) +<WRAP round question> 
-  * 1 subnet privé (backend + db)+Le mot de passe de la base de données est en clair dans le fichier Terraform. 
 + 
 +Quel problème cela pose-t-il ?
  
 +Ce problème sera traité dans un TD ultérieur sur la gestion des secrets.
 </WRAP> </WRAP>
  
-===== 4. Mise en pratique – accès Internet =====+<WRAP round question> 
 +La base de données RDS est placée dans un subnet group qui inclut le subnet `public_b`. 
 + 
 +Est-ce un problème ? Pourquoi ? 
 +</WRAP> 
 + 
 +===== 3. Déploiement de l'infrastructure initiale =====
  
 <WRAP round todo> <WRAP round todo>
 +Appliquer la configuration telle quelle :
  
-Permettre :+  terraform apply
  
-  * accès Internet au serveur web +Relever les outputs suivants : 
-  * accès sortant pour le backend (updates)+  * IP publique de l'instance backend 
 +  * endpoint de la base RDS 
 +</WRAP>
  
-Ajouter les composants nécessaires.+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>
  
 <WRAP round question> <WRAP round question>
-Pourquoi le backend ne doit-il pas avoir d’IP publique ?+Le backend répond-il ? 
 + 
 +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>
  
-===== 5. Mise en pratique – Security Groups =====+===== 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>
  
-Créer 3 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
  
-  * web-sg +  ingress { 
-  * backend-sg +    description = "HTTP depuis Internet" 
-  * db-sg+    from_port   = 80 
 +    to_port     = 80 
 +    protocol    = "tcp" 
 +    cidr_blocks = ["0.0.0.0/0"] 
 +  }
  
-Définir les règles suivantes :+  egress { 
 +    from_port   = 0 
 +    to_port     = 0 
 +    protocol    = "-1" 
 +    cidr_blocks = ["0.0.0.0/0"] 
 +  }
  
-  * web : +  tags = { 
-    - HTTP depuis Internet +    Name = "alb-sg" 
-  * backend : +  } 
-    - accessible uniquement depuis web +}
-  * db : +
-    - accessible uniquement depuis backend+
  
-</WRAP>+# 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]
  
-===== 6. Erreur volontaire =====+  tags = { 
 +    Name = "td2-alb" 
 +  } 
 +}
  
-Un développeur propose la règle suivante pour le backend :+# Target Group 
 +resource "aws_lb_target_group" "backend" { 
 +  name     = "td2-backend-tg" 
 +  port     = 80 
 +  protocol = "HTTP" 
 +  vpc_id   = aws_vpc.main.id
  
-  * autoriser le port 8080 depuis 0.0.0.0/0+  health_check { 
 +    path                = "/" 
 +    healthy_threshold   = 2 
 +    unhealthy_threshold = 2 
 +    interval            = 30 
 +  } 
 + 
 +  tags = { 
 +    Name = "td2-backend-tg" 
 +  } 
 +} 
 + 
 +# 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 
 +} 
 + 
 +# Listener HTTP 
 +resource "aws_lb_listener" "http" { 
 +  load_balancer_arn = aws_lb.main.arn 
 +  port              = 80 
 +  protocol          = "HTTP" 
 + 
 +  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>
-Pourquoi cette règle est dangereuse ?+Les deux accès fonctionnent-ils ?
  
-Dans quel cas peut-elle sembler fonctionner correctement ?+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>
  
-===== 7. Apparition d’un problème =====+===== 5. Erreur courante – le backend reste exposé =====
  
-Après mise en place des règles :+L'ALB est en place mais le Security Group du backend n'a pas été modifié.
  
-  * le site web fonctionne +Le port 80 du backend est toujours ouvert sur `0.0.0.0/0`.
-  * mais l’application ne répond plus correctement+
  
 <WRAP round question> <WRAP round question>
-Que vérifier en priorité ?+Pourquoi ajouter un ALB ne suffit-il pas à protéger le backend ?
  
-  * Security Groups ? +Quel composant contrôle réellement les accès réseau sur une instance AWS ? 
-  * ports ? +</WRAP>
-  * flux autorisés ?+
  
 +===== 6. Correction – restriction du backend =====
 +
 +<WRAP round todo>
 +Modifier `security_groups.tf`.
 +
 +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>
  
-===== 8. 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 :
 +
 +  terraform apply
  
-Corriger les règles pour :+Tester les deux accès :
  
-  * restaurer la communication web → backend +  # Via l'ALB – doit fonctionner 
-  * restaurer backend → DB+  curl http://<alb_dns>
  
 +  # Direct – doit échouer
 +  curl http://<backend_public_ip>
 </WRAP> </WRAP>
  
-===== 9. 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 +===== 7. Problème potentiel – Health Check =====
-  * permettre au backend de faire des mises à jour 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>
-Quelle différence entre :+Si le backend est "unhealthy", l'ALB cesse de lui envoyer du trafic.
  
-  * Internet Gateway +Le service devient indisponible même si le backend fonctionne. 
-  * NAT Gateway ?+ 
 +Quelle règle dans le Security Group du backend pourrait causer ce blocage ?
 </WRAP> </WRAP>
  
-===== 10. 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 utiliser :+Comment vérifier qu'un flux est bien bloqué et non juste lent ?
  
-  * un Security Group par service ? +Quelle différence entre un timeout et un Connection refused en termes de Security Group ?
-  * des règles basées sur des Security Groups plutôt que des IP ?+
 </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.
  
-  * Web accessible depuis Internet (port 80) +Ce n'est pas nécessaire si l'ALB gère tout le trafic entrant.
-  * Backend inaccessible depuis Internet +
-  * DB inaccessible depuis Internet +
-  * Backend accessible uniquement depuis Web +
-  * DB accessible uniquement depuis Backend+
  
 <WRAP round todo> <WRAP round todo>
 +Modifier `instances.tf` pour déplacer le backend dans le subnet privé :
  
-Implémenter l’architecture complète.+  subnet_id = aws_subnet.private.id
  
-Vérifier que :+Supprimer également le `map_public_ip_on_launch` implicite.
  
-  * aucun flux inutile n’est autorisé +Appliquer et vérifier que l'ALB continue de fonctionner. 
-  * chaque règle est justifiée+</WRAP> 
 + 
 +<WRAP round question> 
 +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 second serveur web +  * Quel composant est le seul point d'entrée depuis Internet ? 
-  * un Load Balancer+  * 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>
-Pourquoi un Load Balancer améliore aussi la sécurité ?+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.1781434766.txt.gz
  • Dernière modification : il y a 6 semaines
  • de jcheron