eadl:bloc4:fm4:td2

Ceci est une ancienne révision du document !


TD3 – Sécurisation réseau AWS avec ALB (architecture 3 tiers)

  • Comprendre le rôle d’un Load Balancer dans la sécurité
  • Mettre en place une architecture 3 tiers (ALB / backend / DB)
  • Contrôler les flux réseau avec les Security Groups
  • Éviter l’exposition directe des services internes
  • Corriger une infrastructure existante non sécurisée

Vous intervenez toujours dans la startup.

L’équipe a amélioré le réseau (VPC, subnets), mais l’application reste mal sécurisée.

Architecture actuelle :

  • une instance backend accessible publiquement
  • une base de données mal isolée
  • aucun point d’entrée centralisé

Un audit impose :

  • suppression des accès directs au backend
  • mise en place d’un point d’entrée unique
  • isolation stricte de la base de données

Mettre en place une architecture sécurisée :

  • Internet → ALB (public)
  • ALB → Backend (privé)
  • Backend → DB (privé)
  • Le backend ne doit plus être accessible depuis Internet
  • La base de données ne doit jamais être exposée
  • Utiliser uniquement Terraform
  • Ne pas casser l’accès à l’application

Fichier : `network/main.tf`

provider "aws" {
  region = "eu-west-3"
}

resource "aws_security_group" "backend_sg" {
  name   = "backend-sg"

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

resource "aws_security_group" "db_sg" {
  name = "db-sg"

  ingress {
    from_port   = 5432
    to_port     = 5432
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

Fichier : `commandes/terraform.txt`

terraform init
terraform plan
terraform apply
terraform destroy

Quels composants sont exposés sur Internet ?

Quels flux sont actuellement autorisés ?

Pourquoi cette architecture fonctionne-t-elle malgré tout ?

Quels sont les risques immédiats ?

Identifier les problèmes de sécurité :

  • backend
  • base de données

Quelle est la règle la plus critique dans cette configuration ?

Pourquoi ?

Objectif :

  • introduire un point d’entrée unique

Créer :

  • un Security Group pour l’ALB
  • autoriser HTTP (80) depuis Internet

Fichier : `network/alb.tf`

resource "aws_security_group" "alb_sg" {
  name = "alb-sg"

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

Pourquoi l’ALB peut-il être exposé publiquement ?

L’ALB est en place.

Mais le backend est toujours accessible directement.

Tester :

  • accès via ALB
  • accès direct au backend

Peut-on contourner l’ALB ?

Pourquoi est-ce un problème de sécurité ?

Objectif :

  • autoriser uniquement le trafic provenant de l’ALB

Modifier le Security Group du backend

Fichier : `network/backend_sg.tf`

resource "aws_security_group" "backend_sg" {
  name = "backend-sg"

  ingress {
    from_port       = 80
    to_port         = 80
    protocol        = "tcp"
    security_groups = [aws_security_group.alb_sg.id]
  }
}

Pourquoi utilise-t-on un Security Group comme source plutôt qu’une IP ?

Objectif :

  • autoriser uniquement le backend

Modifier le Security Group de la base de données

Fichier : `network/db_sg.tf`

resource "aws_security_group" "db_sg" {
  name = "db-sg"

  ingress {
    from_port       = 5432
    to_port         = 5432
    protocol        = "tcp"
    security_groups = [aws_security_group.backend_sg.id]
  }
}

Que se passe-t-il si un attaquant accède au backend ?

Peut-il accéder à la base de données ?

Après sécurisation :

  • l’application ne répond plus correctement

Quelles sont les causes possibles ?

Quels éléments faut-il vérifier ?

Vérifier :

  • ports autorisés
  • association des Security Groups
  • configuration de l’ALB
  • health checks

Quel élément est souvent oublié ?

Corriger :

  • les règles nécessaires
  • la connectivité ALB → backend

Ajouter :

  • HTTPS (port 443) sur l’ALB
  • redirection HTTP → HTTPS

Pourquoi HTTPS est-il indispensable en production ?

Pourquoi faut-il :

  • un point d’entrée unique ?
  • ne jamais exposer le backend ?
  • isoler la base de données ?

Objectif :

  • seul l’ALB est exposé à Internet
  • le backend est accessible uniquement depuis l’ALB
  • la base de données est accessible uniquement depuis le backend

Implémenter :

  • 3 Security Groups
  • règles strictes entre chaque couche

Dessiner les flux réseau autorisés dans votre architecture

Ajouter :

  • une deuxième instance backend
  • configuration du load balancing

Quel est l’intérêt du load balancing en plus de la sécurité ?

  • eadl/bloc4/fm4/td2.1781446243.txt.gz
  • Dernière modification : il y a 6 semaines
  • de jcheron