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:10] – jcheroneadl:bloc4:fm4:td2 [2026/06/14 17:07] (Version actuelle) – [6. Correction – restriction du backend] jcheron
Ligne 1: Ligne 1:
-====== TD3 – Sécurisation réseau AWS avec ALB (architecture 3 tiers) ======+====== TD2 – Sécurisation réseau AWS (VPC, Security Groups, ALB) ======
  
 ===== Objectifs ===== ===== Objectifs =====
  
-  * Comprendre le rôle d’un Load Balancer dans la sécurité +  * Comprendre la segmentation réseau dans AWS avec VPC et subnets 
-  * Mettre en place une architecture 3 tiers (ALB / backend / DB)+  * Identifier les mauvaises pratiques de sécurité réseau 
 +  * Mettre en place un point d'entrée unique avec un ALB
   * Contrôler les flux réseau avec les Security Groups   * Contrôler les flux réseau avec les Security Groups
-  * Éviter l’exposition directe des services internes +  * Appliquer le principe du moindre privilège sur chaque couche
-  * Corriger une infrastructure existante non sécurisée+
  
 ===== Contexte ===== ===== Contexte =====
  
-Vous intervenez toujours dans la startup.+Vous intervenez en tant qu'ingénieur DevOps dans une startup.
  
-L’équipe a amélioré le réseau (VPC, subnets), mais l’application reste mal sécurisée.+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.
  
-  * une instance backend accessible publiquement +Résultat :
-  * une base de données mal isolée +
-  * aucun point d’entrée centralisé+
  
-Un audit impose :+  * l'application fonctionne 
 +  * mais toute l'infrastructure est directement exposée sur Internet
  
-  * suppression des accès directs au backend +Un audit de sécurité interne a identifié trois problèmes critiques :
-  * mise en place d’un point d’entrée unique +
-  * isolation stricte de la base de données+
  
-===== Objectif technique =====+  * le port applicatif du backend est ouvert à Internet 
 +  * le port de la base de données est ouvert à Internet 
 +  * aucun point d'entrée centralisé ne permet de contrôler le trafic
  
-Mettre en place une architecture sécurisée :+Votre mission : transformer l'architecture sans interrompre le service.
  
-  * Internet → ALB (public) +===== Architecture cible ===== 
-  * ALB → Backend (privé) + 
-  * Backend → DB (privé)+L'architecture actuelle : 
 + 
 +  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 =====
  
-  * Le backend ne doit plus être accessible depuis Internet +  * L'application doit rester accessible depuis Internet 
-  * La base de données ne doit jamais être exposée +  * Le backend ne doit plus être accessible directement depuis Internet 
-  * Utiliser uniquement Terraform +  * La base de données ne doit être accessible que depuis le backend 
-  * Ne pas casser l’accès à l’application+  * 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 50: Ligne 66:
 } }
  
 +# VPC principal
 +resource "aws_vpc" "main" {
 +  cidr_block           = "10.0.0.0/16"
 +  enable_dns_hostnames = true
 +
 +  tags = {
 +    Name = "td2-vpc"
 +  }
 +}
 +
 +# Passerelle Internet
 +resource "aws_internet_gateway" "igw" {
 +  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" {
 +  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" { resource "aws_security_group" "backend_sg" {
   name   = "backend-sg"   name   = "backend-sg"
 +  vpc_id = aws_vpc.main.id
  
   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" 
 +  vpc_id = aws_vpc.main.id
  
   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> </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] 
 + 
 +  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> 
 + 
 +===== 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 exposés sur Internet ?+Lister les ressources présentes dans le code.
  
-Quels flux sont actuellement autorisés ?+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é 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.
  
-  * backend +Quel problème cela pose-t-il ?
-  * base de données+
  
 +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 critique dans cette configuration ?+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 – ajout d’un ALB =====+===== 3. Déploiement de l'infrastructure initiale =====
  
-Objectif :+<WRAP round todo> 
 +Appliquer la configuration telle quelle :
  
-  * introduire 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 Security Group pour l’ALB +Tenter une connexion à la base de données depuis votre poste :
-  * autoriser HTTP (80) 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" 
 +  vpc_id = aws_vpc.main.id
  
   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> 
  
-<WRAP round question> +# Application Load Balancer 
-Pourquoi l’ALB peut-il être exposé publiquement ? +resource "aws_lb" "main" { 
-</WRAP>+  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]
  
-===== 4. Erreur volontaire – faux sentiment de sécurité =====+  tags = { 
 +    Name = "td2-alb" 
 +  } 
 +}
  
-L’ALB est en place.+# Target Group 
 +resource "aws_lb_target_group" "backend" { 
 +  name     = "td2-backend-tg" 
 +  port     = 80 
 +  protocol = "HTTP" 
 +  vpc_id   = aws_vpc.main.id
  
-Mais le backend est toujours accessible directement.+  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>
 +Ajouter l'output du DNS de l'ALB dans `outputs.tf` :
  
-Tester :+  output "alb_dns" { 
 +    value       = aws_lb.main.dns_name 
 +    description = "DNS public de l'ALB" 
 +  }
  
-  * accès via ALB +Appliquer :
-  * accès direct au backend+
  
 +  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>
-Peut-on contourner l’ALB ?+Les deux accès fonctionnent-ils ?
  
-Pourquoi est-ce un problème de sécurité ?+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é =====
  
-Objectif :+L'ALB est en place mais le Security Group du backend n'a pas été modifié.
  
-  * autoriser uniquement le trafic provenant de l’ALB+Le port 80 du backend est toujours ouvert sur `0.0.0.0/0`.
  
-<WRAP round todo>+<WRAP round question> 
 +Pourquoi ajouter un ALB ne suffit-il pas à protéger le backend ?
  
-Modifier le Security Group du 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" {
-  name = "backend-sg"+  name   = "backend-sg" 
 +  vpc_id = aws_vpc.main.id
  
   ingress {   ingress {
 +    description     = "HTTP depuis l'ALB uniquement"
     from_port       = 80     from_port       = 80
     to_port         = 80     to_port         = 80
Ligne 190: Ligne 508:
     security_groups = [aws_security_group.alb_sg.id]     security_groups = [aws_security_group.alb_sg.id]
   }   }
-} 
-</sxh> 
  
-<WRAP round question> +  egress { 
-Pourquoi utilise-t-on un Security Group comme source plutôt qu’une IP ? +    from_port   = 0 
-</WRAP>+    to_port     = 0 
 +    protocol    = "-1" 
 +    cidr_blocks = ["0.0.0.0/0"] 
 +  }
  
-===== 6. Correction – sécurisation de la base de données =====+  tags = { 
 +    Name = "backend-sg" 
 +  } 
 +}
  
-Objectif : 
- 
-  * autoriser uniquement le backend 
- 
-<WRAP round todo> 
- 
-Modifier le Security Group de la base de données 
- 
-</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" 
 +  vpc_id = aws_vpc.main.id
  
   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>
  
-<WRAP round question> +<WRAP round todo> 
-Que se passe-t-il si un attaquant accède au backend ?+Appliquer les modifications :
  
-Peut-il accéder à la base de données ? +  terraform apply
-</WRAP>+
  
-===== 7. Apparition d’un problème =====+Tester les deux accès :
  
-Après sécurisation :+  # Via l'ALB – doit fonctionner 
 +  curl http://<alb_dns>
  
-  * l’application ne répond plus correctement+  # Direct – doit échouer 
 +  curl http://<backend_public_ip> 
 +</WRAP>
  
 <WRAP round question> <WRAP round question>
-Quelles sont les causes possibles ?+L'accès direct au backend est-il maintenant bloqué ? 
 + 
 +L'accès via l'ALB fonctionne-t-il toujours ?
  
-Quels éléments faut-il vérifier ?+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.
  
-  * ports autorisés +Quel flux réseau le Health Check génère-t-il ?
-  * association des Security Groups +
-  * configuration de l’ALB +
-  * health checks+
  
-Quel élément est souvent oublié ?+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.
  
-<WRAP round todo>+Le service devient indisponible même si le backend fonctionne.
  
-Corriger : +Quelle règle dans le Security Group du backend pourrait causer ce blocage ? 
- +</WRAP>
-  * les règles nécessaires +
-  * la connectivité ALB → backend+
  
 +<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> </WRAP>
  
-===== 10. Extension =====+===== 8. Diagnostic et correction =====
  
 <WRAP round todo> <WRAP round todo>
 +Si le Health Check échoue, identifier la cause :
  
-Ajouter :+  * 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 ?
  
-  * HTTPS (port 443) sur l’ALB +Corriger la règle manquante et réappliquer. 
-  * redirection HTTP → HTTPS+</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>
  
 <WRAP round question> <WRAP round question>
-Pourquoi HTTPS est-il indispensable en production ?+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>
  
-===== Bonnes pratiques =====+===== 10. Extension – déplacement du backend en subnet privé =====
  
-<WRAP round question> +Le backend a une IP publique car il est dans un subnet public.
-Pourquoi faut-il :+
  
-  * un point d’entrée unique ? +Ce n'est pas nécessaire si l'ALB gère tout le trafic entrant.
-  * ne jamais exposer le backend ? +
-  * isoler la base de données ?+
  
 +<WRAP round todo>
 +Modifier `instances.tf` pour déplacer le backend dans le subnet privé :
 +
 +  subnet_id = aws_subnet.private.id
 +
 +Supprimer également le `map_public_ip_on_launch` implicite.
 +
 +Appliquer et vérifier que l'ALB continue de fonctionner.
 </WRAP> </WRAP>
  
-===== Challenge final =====+<WRAP round question> 
 +Le backend n'a plus d'IP publique.
  
-Objectif :+Est-il encore accessible depuis Internet ?
  
-  * seul l’ALB est exposé à Internet +Comment l'ALB peut-il atteindre une instance dans un subnet privé ?
-  * le backend est accessible uniquement depuis l’ALB +
-  * la base de données est accessible uniquement depuis le backend+
  
-<WRAP round todo>+Quel composant réseau manque pour que le backend puisse faire des appels sortants (mises à jour, appels API externes) ? 
 +</WRAP>
  
-Implémenter :+===== Challenge final =====
  
-  * 3 Security Groups +Objectif : valider l'architecture complète Internet → ALB → Backend → DB.
-  * règles strictes entre chaque couche+
  
 +<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> </WRAP>
  
-<WRAP round question> +<WRAP round todo> 
-Dessiner les flux réseau autorisés dans votre architecture+Répondre aux questions suivantes par écrit : 
 + 
 +  * Quel composant est le seul point d'entrée depuis Internet ? 
 +  * 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> </WRAP>
  
Ligne 315: Ligne 675:
  
 <WRAP round todo> <WRAP round todo>
 +Ajouter une seconde instance backend dans `public_b` :
  
-Ajouter : +  resource "aws_instance" "backend_b" { 
- +    ami                    = "ami-0f61de2873e29e866" 
-  * une deuxième instance backend +    instance_type          = "t2.micro" 
-  * configuration du load balancing+    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 plus de 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.1781446243.txt.gz
  • Dernière modification : il y a 6 semaines
  • de jcheron