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 16:15] – 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 (ALB, Backend, DB) ======+====== TD2 – Sécurisation réseau AWS (VPC, Security Groups, ALB) ======
  
 ===== Objectifs ===== ===== Objectifs =====
  
-  * Comprendre la segmentation réseau dans AWS +  * 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 
-  * Introduire un point d’entrée sécurisé (ALB) +  * Mettre en place un point d'entrée unique avec un ALB 
-  * Contrôler les flux avec les Security Groups +  * Contrôler les flux réseau avec les Security Groups 
-  * Appliquer le principe du moindre privilège+  * 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 application backend est déployée sur AWS avec une base de données.+L'équipe de développement a déployé une application backend sur AWS via Terraform.
  
-Le déploiement a été fait rapidement via Terraform.+Le déploiement a été fait rapidement pour respecter un délai.
  
 Résultat : Résultat :
  
-  * l’application fonctionne +  * l'application fonctionne 
-  * mais toute l’infrastructure est exposée+  * 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 :
  
-  * suppression des accès directs aux composants internes +  * le port applicatif du backend est ouvert à Internet 
-  * mise en place d’une architecture sécurisée +  * 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.
  
-Transformer l’architecture actuelle :+===== Architecture cible =====
  
-  * Internet → Backend (actuel, non sécurisé)+L'architecture actuelle :
  
-en :+  Internet → Backend (port 80 ouvert partout) 
 +  Internet → DB (port 5432 ouvert partout)
  
-  * Internet → ALB → Backend → DB+L'architecture cible : 
 + 
 +  Internet → ALB (port 80) → Backend (port 80, privé) → DB (port 5432, isolée)
  
 ===== Contraintes ===== ===== Contraintes =====
  
-  * L’application doit rester accessible +  * L'application doit rester accessible depuis Internet 
-  * Le backend ne doit plus être exposé directement +  * Le backend ne doit plus être accessible directement depuis Internet 
-  * La base de données doit être isolée +  * La base de données ne doit être accessible que depuis le backend 
-  * Utiliser Terraform uniquement+  * 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" {
Ligne 53: Ligne 66:
 } }
  
 +# 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" 
 +  }
 } }
  
 +# Subnet public – AZ a
 +resource "aws_subnet" "public_a" {
 +  vpc_id                  = aws_vpc.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"
 +  }
 +}
 +
 +# Subnet public – AZ b (requis par l'ALB)
 +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" { resource "aws_subnet" "private" {
-  vpc_id     = aws_vpc.main.id +  vpc_id            = aws_vpc.main.id 
-  cidr_block = "10.0.2.0/24"+  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" { resource "aws_security_group" "backend_sg" {
   name   = "backend-sg"   name   = "backend-sg"
Ligne 72: Ligne 154:
  
   ingress {   ingress {
 +    description = "HTTP depuis Internet"
     from_port   = 80     from_port   = 80
     to_port     = 80     to_port     = 80
     protocol    = "tcp"     protocol    = "tcp"
     cidr_blocks = ["0.0.0.0/0"]     cidr_blocks = ["0.0.0.0/0"]
 +  }
 +
 +  egress {
 +    from_port   = 0
 +    to_port     = 0
 +    protocol    = "-1"
 +    cidr_blocks = ["0.0.0.0/0"]
 +  }
 +
 +  tags = {
 +    Name = "backend-sg"
   }   }
 } }
  
 +# Security Group DB – PROBLEME VOLONTAIRE
 resource "aws_security_group" "db_sg" { resource "aws_security_group" "db_sg" {
   name   = "db-sg"   name   = "db-sg"
Ligne 84: Ligne 179:
  
   ingress {   ingress {
 +    description = "PostgreSQL depuis Internet"
     from_port   = 5432     from_port   = 5432
     to_port     = 5432     to_port     = 5432
     protocol    = "tcp"     protocol    = "tcp"
     cidr_blocks = ["0.0.0.0/0"]     cidr_blocks = ["0.0.0.0/0"]
 +  }
 +
 +  egress {
 +    from_port   = 0
 +    to_port     = 0
 +    protocol    = "-1"
 +    cidr_blocks = ["0.0.0.0/0"]
 +  }
 +
 +  tags = {
 +    Name = "db-sg"
   }   }
 } }
 +</sxh>
  
 +Fichier : `td2/network/instances.tf`
 +<sxh js>
 resource "aws_instance" "backend" { resource "aws_instance" "backend" {
-  ami           = "ami-123456" +  ami                    = "ami-0f61de2873e29e866" 
-  instance_type = "t2.micro" +  instance_type          = "t2.micro" 
-  subnet_id     = aws_subnet.public.id+  subnet_id              = aws_subnet.public_a.id
   vpc_security_group_ids = [aws_security_group.backend_sg.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_instance" "db" { +resource "aws_db_instance" "db" { 
-  ami           = "ami-123456" +  identifier             = "td2-db" 
-  instance_type = "t2.micro" +  engine                 = "postgres" 
-  subnet_id     = aws_subnet.private.id+  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]   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 sont présents ?+Lister les ressources présentes dans le code.
  
-Quelle est l’architecture actuelle ?+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 architecture fonctionne-t-elle malgré ses défauts ?+Pourquoi l'ALB nécessite-t-il deux subnets dans deux zones de disponibilité différentes ? 
 + 
 +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 :+Le mot de passe de la base de données est en clair dans le fichier Terraform.
  
-  * exposition du backend +Quel problème cela pose-t-il ?
-  * exposition de la base de données +
-  * placement des ressources+
  
 +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 – introduction d’un ALB =====+===== 3. Déploiement de l'infrastructure initiale =====
  
-Objectif :+<WRAP round todo> 
 +Appliquer la configuration telle quelle :
  
-  * créer un point d’entrée unique+  terraform apply 
 + 
 +Relever les outputs suivants : 
 +  * IP publique de l'instance backend 
 +  * endpoint de la base RDS 
 +</WRAP> 
 + 
 +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> <WRAP round todo>
 +Tester l'accès au backend depuis un navigateur ou curl :
  
-Créer :+  curl http://<backend_public_ip>
  
-  * un Application Load Balancer +Tenter une connexion à la base de données depuis votre poste :
-  * un Security Group associé +
-  * autoriser HTTP depuis Internet+
  
 +  psql -h <db_endpoint> -U admin -d postgres
 +
 +Noter le résultat de chaque test.
 +</WRAP>
 +
 +<WRAP round question>
 +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>
 +
 +===== 4. Mise en place de l'ALB =====
 +
 +<WRAP round todo>
 +Créer le fichier suivant sans modifier les Security Groups existants.
 </WRAP> </WRAP>
  
-Fichier : `network/alb.tf`+Fichier : `td2/network/alb.tf`
 <sxh js> <sxh js>
 +# Security Group de l'ALB
 resource "aws_security_group" "alb_sg" { resource "aws_security_group" "alb_sg" {
   name   = "alb-sg"   name   = "alb-sg"
Ligne 168: Ligne 373:
  
   ingress {   ingress {
 +    description = "HTTP depuis Internet"
     from_port   = 80     from_port   = 80
     to_port     = 80     to_port     = 80
     protocol    = "tcp"     protocol    = "tcp"
     cidr_blocks = ["0.0.0.0/0"]     cidr_blocks = ["0.0.0.0/0"]
 +  }
 +
 +  egress {
 +    from_port   = 0
 +    to_port     = 0
 +    protocol    = "-1"
 +    cidr_blocks = ["0.0.0.0/0"]
 +  }
 +
 +  tags = {
 +    Name = "alb-sg"
   }   }
 } }
-</sxh> 
  
-===== 4. 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]
  
-L’ALB est ajouté.+  tags = { 
 +    Name = "td2-alb" 
 +  } 
 +}
  
-Mais rien n’a été modifié sur le backend.+# Target Group 
 +resource "aws_lb_target_group" "backend" { 
 +  name     = "td2-backend-tg" 
 +  port     = 80 
 +  protocol = "HTTP" 
 +  vpc_id   = aws_vpc.main.id 
 + 
 +  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> <WRAP round todo>
-Tester :+Ajouter l'output du DNS de l'ALB dans `outputs.tf` :
  
-  * accès via ALB +  output "alb_dns" { 
-  * accès direct au backend+    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>
  
 <WRAP round question> <WRAP round question>
-Pourquoi peut-on toujours accéder directement au backend ?+Les deux accès fonctionnent-ils ?
  
-Quel est le problème ?+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>
  
-===== 5. Correction – sécurisation du backend =====+===== 5. Erreur courante – le backend reste exposé =====
  
-<WRAP round todo>+L'ALB est en place mais le Security Group du backend n'a pas été modifié.
  
-Modifier le Security Group du backend :+Le port 80 du backend est toujours ouvert sur `0.0.0.0/0`.
  
-  * autoriser uniquement le trafic depuis l’ALB+<WRAP round question> 
 +Pourquoi ajouter un ALB ne suffit-il pas à protéger le backend ? 
 + 
 +Quel composant contrôle réellement les accès réseau sur une instance AWS ? 
 +</WRAP> 
 + 
 +===== 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>
  
-Fichier : `network/backend_sg.tf`+Fichier : `td2/network/security_groups.tf`
 <sxh js> <sxh js>
 resource "aws_security_group" "backend_sg" { resource "aws_security_group" "backend_sg" {
Ligne 212: Ligne 502:
  
   ingress {   ingress {
 +    description     = "HTTP depuis l'ALB uniquement"
     from_port       = 80     from_port       = 80
     to_port         = 80     to_port         = 80
Ligne 217: Ligne 508:
     security_groups = [aws_security_group.alb_sg.id]     security_groups = [aws_security_group.alb_sg.id]
   }   }
-} 
-</sxh> 
  
-===== 6. Correction – sécurisation de la base =====+  egress { 
 +    from_port   = 0 
 +    to_port     = 0 
 +    protocol    = "-1" 
 +    cidr_blocks = ["0.0.0.0/0"] 
 +  }
  
-<WRAP round todo> +  tags = { 
- +    Name = "backend-sg" 
-Modifier le Security Group de la base : +  } 
- +}
-  * autoriser uniquement le backend+
  
-</WRAP> 
- 
-Fichier : `network/db_sg.tf` 
-<sxh js> 
 resource "aws_security_group" "db_sg" { resource "aws_security_group" "db_sg" {
   name   = "db-sg"   name   = "db-sg"
Ligne 237: Ligne 526:
  
   ingress {   ingress {
 +    description     = "PostgreSQL depuis le backend uniquement"
     from_port       = 5432     from_port       = 5432
     to_port         = 5432     to_port         = 5432
     protocol        = "tcp"     protocol        = "tcp"
     security_groups = [aws_security_group.backend_sg.id]     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> </sxh>
  
-===== 7. Apparition d’un problème =====+<WRAP round todo> 
 +Appliquer les modifications :
  
-Après modification :+  terraform apply
  
-  * l’application peut ne plus répondre+Tester les deux accès : 
 + 
 +  # Via l'ALB – doit fonctionner 
 +  curl http://<alb_dns> 
 + 
 +  # Direct – doit échouer 
 +  curl http://<backend_public_ip> 
 +</WRAP>
  
 <WRAP round question> <WRAP round question>
-Pourquoi ?+L'accès direct au backend est-il maintenant bloqué ? 
 + 
 +L'accès via l'ALB fonctionne-t-il toujours ?
  
-Quels flux ont pu être bloqués ?+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> </WRAP>
  
-===== 8. Analyse =====+===== 7. Problème potentiel – Health Check ===== 
 + 
 +Après modification des Security Groups, l'ALB peut afficher le backend comme "unhealthy".
  
 <WRAP round question> <WRAP round question>
-Vérifier :+Expliquer ce qu'est un Health Check d'ALB.
  
-  * règles de Security Groups +Quel flux réseau le Health Check génère-t-il ? 
-  * ports utilisés + 
-  * configuration du backend+Depuis quelle source arrive ce flux sur le backend ?
 </WRAP> </WRAP>
  
-===== 9. Correction =====+<WRAP round question> 
 +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 round todo> <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>
  
-Corriger les règles pour :+===== 8. Diagnostic et correction =====
  
-  * restaurer le fonctionnement +<WRAP round todo> 
-  * conserver la sécurité+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> </WRAP>
  
-===== 10. Extension =====+===== 9. Vérification finale =====
  
 <WRAP round todo> <WRAP round todo>
 +Réaliser les tests suivants et noter les résultats dans un tableau :
  
-Ajouter :+  * 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>
  
-  * HTTPS sur l’ALB +<WRAP round question> 
-  * redirection HTTP → HTTPS+Comment vérifier qu'un flux est bien bloqué et non juste lent ?
  
 +Quelle différence entre un timeout et un Connection refused en termes de Security Group ?
 </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.
  
-  * seul l’ALB est accessible depuis Internet +Ce n'est pas nécessaire si l'ALB gère tout le trafic entrant.
-  * le backend est privé +
-  * la base est isolée+
  
 <WRAP round todo> <WRAP round todo>
 +Modifier `instances.tf` pour déplacer le backend dans le subnet privé :
  
-Mettre en place :+  subnet_id = aws_subnet.private.id
  
-  * 3 Security Groups +Supprimer également le `map_public_ip_on_launch` implicite.
-  * flux stricts entre chaque couche+
  
 +Appliquer et vérifier que l'ALB continue de fonctionner.
 </WRAP> </WRAP>
  
 <WRAP round question> <WRAP round question>
-Dessiner les flux réseau autorisés+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 :
  
-  * une seconde instance backend +  * Quel composant est le seul point d'entrée depuis Internet ? 
-  * équilibrage de charge+  * 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’intérêt du load balancing en termes de sécurité et de disponibilité ?+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.1781446523.txt.gz
  • Dernière modification : il y a 6 semaines
  • de jcheron