🎯 Objectif de la semaine
Maîtriser les fondamentaux de la sécurité cloud AWS : comprendre le modèle de responsabilité partagée, créer et durcir des instances EC2, configurer IAM avec moindre privilège. Démontrer pourquoi une mauvaise configuration cloud peut mener à des compromissions massives en quelques secondes et comment appliquer les principes de sécurité traditionnels dans ce nouvel environnement.
Pourquoi c'est critique : 94% des entreprises utilisent le cloud public, et 99% des failles cloud sont dues à des erreurs de configuration client. Le cloud ne supprime pas la sécurité – il la déplace.
Centres de données"] A2["Hôte virtualisation
Hyperviseur"] A3["Réseau backbone
Connectivité globale"] A4["Régions & Zones
de Disponibilité"] end subgraph "👤 Client (Vous)" C1["Données clients
& contenus"] C2["Système d'exploitation
guest"] C3["Applications
& middleware"] C4["Config sécurité
IAM, Security Groups"] end subgraph "🔐 Responsabilité Mutuelle" M1["Chiffrement données
(in transit/at rest)"] M2["Patch management
(guest OS)"] M3["Configuration réseau
& firewall"] M4["IAM & authentification"] end end style A1 fill:#0a0e17,stroke:#ff9900,stroke-width:2px,color:#fff style C1 fill:#0a0e17,stroke:#00d4ff,stroke-width:2px,color:#fff style M1 fill:#0a0e17,stroke:#00f5a0,stroke-width:2px,color:#fff
📚 Sujet – Théorie (1 heure)
Le Cloud : Nouveau Terrain, Nouvelles Règles
Le cloud public n'est pas un simple "serveur distant" – c'est un changement paradigmatique dans la manière dont nous déployons, gérons et sécurisons l'informatique. AWS, Azure et GCP offrent une puissance quasi-infinie, mais cette puissance s'accompagne de nouvelles surfaces d'attaque.
Les 4 Piliers AWS pour la Sécurité
EC2
Elastic Compute Cloud
Instances virtuelles
- AMI sécurisée
- Security Groups
- Key pairs
IAM
Identity & Access Management
Contrôle d'accès
- Users/Roles
- Policies JSON
- MFA obligatoire
VPC
Virtual Private Cloud
Réseau isolé
- Subnets publics/privés
- Route tables
- NACLs
CloudWatch
Monitoring & Logging
Observabilité
- Metrics
- Logs
- Alarms
Les 5 Misconfigurations Cloud Mortelles
1. Security Groups : Porte Ouverte au Monde
Erreur : 0.0.0.0/0 sur SSH/RDP
Impact : Attaque brute-force immédiate
Solution : "My IP only" ou bastion host
2. IAM : Droits Administrateur Pour Tous
Erreur : AdministratorAccess attaché à un user
Impact : Compromission de compte = perte totale
Solution : Least privilege, roles temporaires
3. S3 : Buckets Publics Non Intentionnels
Erreur : ACLs publiques sans authentification
Impact : Fuite de données massive
Solution : Block public access activé
4. Pas de MFA sur Root Account
Erreur : Compte root sans MFA
Impact : Takeover complet du compte AWS
Solution : MFA obligatoire, root inutilisé
La Mentalité "Cloud-Native" de Sécurité
💡 Les 6 Principes du Gardien Cloud
- Tout est API : Infrastructure as Code (Terraform, CloudFormation)
- Zero Trust par défaut : Aucune confiance implicite, même interne
- Éphémère par design : Instances jetables, pas de pets
- Monitoring exhaustif : CloudTrail + CloudWatch + GuardDuty
- Secrets managés : AWS Secrets Manager, pas de hardcoding
- Automation sécurité : AWS Config rules, Security Hub
Coûts Cloud : Le Piège Invisible
⚠️ Attention aux Coûts AWS
AWS Free Tier a des limites strictes. Sans vigilance, les coûts peuvent exploser :
- Instances running 24/7 : Coûts même si inactives
- Snapshots EBS : Stockage accumulé
- Load Balancers : Coûts horaires
- Data transfer out : Sortie Internet coûteuse
Règle d'or : Taggez toutes les ressources et configurez des budgets avec alerts.
🔍 Mission pratique – Laboratoire (2 heures)
Architecture du Lab AWS
10.0.1.0/24"] --> EC2["🖥️ EC2 Instance
Amazon Linux 2023
t2.micro"] S2["Subnet Privé
10.0.2.0/24"] --> DB["🗄️ (Optionnel)
RDS MySQL"] end SG["🛡️ Security Group
SSH: Mon IP uniquement"] --> EC2 KP["🔑 Key Pair
pctamalou-key.pem"] --> EC2 IAM["👤 IAM User
lab-user (least privilege)"] --> C end CW["📊 CloudWatch Alarm"] -.->|"CPU > 80%"| EC2 CT["📝 CloudTrail Logs"] -.->|"Audit API calls"| C style EC2 fill:#0a0e17,stroke:#00d4ff,stroke-width:2px,color:#fff style SG fill:#0a0e17,stroke:#00f5a0,stroke-width:2px,color:#fff style IAM fill:#0a0e17,stroke:#9d4edd,stroke-width:2px,color:#fff
⚠️ Précautions Critiques AWS
🔐 Sécurité Compte AWS :
- MFA obligatoire sur compte root ET IAM users
- Ne jamais utiliser root pour opérations quotidiennes
- Configurer billing alerts immédiatement
- Cleanup systématique après chaque lab
- Pas de clés AWS en clair dans le code/git
Étapes Détaillées de Configuration
Étape 1 : Création et Sécurisation du Compte AWS
# IMPORTANT: Ces étapes se font via la console web AWS
# Pas de CLI avant d'avoir configuré IAM proprement
# 1. Création compte AWS (si nouveau)
# https://aws.amazon.com/fr/free/
# 2. Activation MFA sur compte root
# Console → IAM → Dashboard → Activate MFA on your root account
# 3. Création IAM User avec droits limités
# IAM → Users → Create user → "lab-user"
# Attach policies: "IAMUserChangePassword" + "AmazonEC2FullAccess" (temporaire)
# 4. Configuration billing alerts
# Billing Dashboard → Budgets → Create budget
# Type: Cost budget, Amount: 10 USD, Alert à 80%
🔐 Pourquoi ne pas utiliser root ?
Le compte root AWS a des pouvoirs absolus (suppression de compte inclus). Un compromis = catastrophe totale. Utilisez toujours des IAM users avec least privilege.
Étape 2 : Configuration VPC et Networking
# Via Console AWS:
# 1. VPC → Your VPCs → Create VPC
# Name: pctamalou-vpc
# IPv4 CIDR: 10.0.0.0/16
# Tenancy: Default
# 2. Create Subnets
# - Public: 10.0.1.0/24 (eu-west-1a)
# - Private: 10.0.2.0/24 (eu-west-1b)
# 3. Internet Gateway
# VPC → Internet Gateways → Create → Attach to pctamalou-vpc
# 4. Route Tables
# Public subnet: Route to 0.0.0.0/0 via IGW
# Private subnet: No route to IGW (isolé)
Étape 3 : Lancement d'Instance EC2 Sécurisée
📋 Checklist Sécurité EC2
- ✅ AMI officielle (Amazon Linux 2023)
- ✅ Instance type t2.micro (gratuit)
- ✅ Key pair nouvelle (pas de réutilisation)
- ✅ Security Group restrictif (My IP only)
- ✅ Storage chiffré (EBS encryption)
- ✅ IAM Role avec least privilege
# Console EC2 → Launch Instance
# 1. Name: pctamalou-ec2-secure
# 2. AMI: Amazon Linux 2023 AMI (gratuit tier eligible)
# 3. Instance type: t2.micro (vCPU: 1, RAM: 1 GiB)
# 4. Key pair: Create new key pair
# Name: pctamalou-key-2026
# Download .pem file → chmod 400 immédiatement
chmod 400 ~/Downloads/pctamalou-key-2026.pem
# 5. Network settings: Edit
# VPC: pctamalou-vpc
# Subnet: Public subnet (10.0.1.0/24)
# Auto-assign public IP: Enable
# 6. Security group: Create new
# Name: pctamalou-sg-restrictive
# Description: Security Group PCTAMALOU - Least privilege
# Rule 1: SSH TCP 22 - Source: My IP (automatiquement votre IP)
# Rule 2: (AUCUNE AUTRE RÈGLE PAR DÉFAUT)
# 7. Configure storage: 8 GiB gp3 (gratuit)
# Encryption: Enable (EBS encryption)
# 8. Advanced details: IAM instance profile
# Create new IAM role: ec2-ssm-role
# Permissions: AmazonSSMManagedInstanceCore (pour Session Manager)
Étape 4 : Hardening de l'Instance via Session Manager
💡 Pourquoi Session Manager ? Plus sécurisé que SSH direct : pas de ports ouverts, logging complet, pas besoin de key pair sur disque.
# 1. Connect via Session Manager (préféré)
# EC2 → Instances → Select instance → Connect → Session Manager
# Cliquez Connect → Terminal intégré dans le navigateur
# 2. Mise à jour et hardening de base
sudo yum update -y --security
sudo amazon-linux-extras install epel -y
# 3. Création utilisateur non-root
sudo useradd -m -s /bin/bash gardien
sudo passwd gardien # Mot de passe fort: Min 12 caractères, complexe
echo 'gardien ALL=(ALL) NOPASSWD:ALL' | sudo tee /etc/sudoers.d/gardien
sudo chmod 440 /etc/sudoers.d/gardien
# 4. Désactivation root SSH
sudo sed -i 's/^PermitRootLogin yes/PermitRootLogin no/' /etc/ssh/sshd_config
sudo systemctl restart sshd
# 5. Installation et configuration fail2ban
sudo yum install fail2ban -y
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo systemctl enable fail2ban
sudo systemctl start fail2ban
# 6. Configuration monitoring de base
sudo yum install amazon-cloudwatch-agent -y
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard
Étape 5 : Configuration IAM Least Privilege
# Via Console IAM (pas CLI pour ce lab)
# 1. Création policy custom pour EC2 limité
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:StartInstances",
"ec2:StopInstances",
"ec2:RebootInstances"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": "arn:aws:ec2:eu-west-1:YOUR_ACCOUNT_ID:instance/*",
"Condition": {
"StringEquals": {
"ssm:resourceTag/Environment": "Lab"
}
}
}
]
}
# 2. Attacher cette policy au user lab-user
# Remplacer AmazonEC2FullAccess par cette policy custom
# 3. Activation MFA sur lab-user
# IAM → Users → lab-user → Security credentials → Manage MFA device
Étape 6 : Monitoring avec CloudWatch
# Via Console CloudWatch
# 1. Création alarm CPU
# CloudWatch → Alarms → Create alarm
# Metric: EC2 → Per-Instance Metrics → CPUUtilization
# InstanceId: votre-instance-id
# Threshold: > 80% for 5 minutes
# Notification: (optionnel) créer SNS topic
# 2. Activation CloudTrail
# CloudTrail → Trails → Create trail
# Name: pctamalou-cloudtrail
# Storage location: New S3 bucket
# Log file validation: Enable
# Data events: (optionnel) S3 + Lambda
# 3. Vérification via AWS Config
# AWS Config → Get started
# Resource types: EC2 instances, Security groups, IAM users
# Rules: cloudtrail-enabled, ec2-instance-managed-by-systems-manager
Exercice Avancé : Détection de Misconfiguration
🎯 Défi de Sécurité Cloud
Créez intentionnellement ces misconfigurations, puis détectez-les :
- Security Group trop permissif : Ajoutez
0.0.0.0/0sur SSH - IAM over-privileged : Attachez
AdministratorAccessà lab-user - S3 bucket public : Créez un bucket avec ACL public
Outils de détection :
# 1. AWS Security Hub (activé dans la console)
# 2. Scout Suite (outil open-source)
pip install scoutsuite
scout aws --profile lab-user
# 3. Prowler (compliance checking)
git clone https://github.com/prowler-cloud/prowler
cd prowler
./prowler -p lab-user
Documentez chaque misconfiguration trouvée et sa correction.
Étape 7 : Cleanup et Facturation
# PROCÉDURE DE CLEANUP OBLIGATOIRE
# 1. Terminer l'instance EC2
# EC2 → Instances → Actions → Instance state → Terminate
# 2. Supprimer les EBS volumes (si pas supprimés automatiquement)
# EC2 → Volumes → Delete (ceux non attachés)
# 3. Supprimer le Security Group
# EC2 → Security Groups → Delete
# 4. Supprimer le Key Pair
# EC2 → Key Pairs → Delete
# 5. Supprimer le VPC (attention: supprime tout)
# VPC → Your VPCs → Actions → Delete VPC
# Cocher "Delete associated objects"
# 6. Vérifier la facturation
# Billing Dashboard → Cost Explorer → This month
# Vérifier que tout est à 0 USD (ou proche)
# 7. Désactiver/désinscrire des services payants
# Security Hub, GuardDuty, Inspector (désactiver si activés)
📋 Objectif de la semaine – Checklist de validation
✅ Compétences techniques acquises
- Compte AWS sécurisé avec MFA root + IAM
- Instance EC2 avec Security Group restrictif
- Connexion via Session Manager (pas SSH public)
- IAM policy least privilege custom
- Monitoring CloudWatch + CloudTrail
- Cleanup complet sans coûts résiduels
🧠 Changement mental accompli
- Compréhension profonde du modèle responsabilité partagée
- Conscience que "cloud =/= sécurité par défaut"
- Habitude de toujours configurer MFA + billing alerts
- Vision infrastructure comme code, pas comme clics manuels
💪 Pour aller plus loin :
Refaites ce lab avec Terraform (Infrastructure as Code). Ajoutez un bastion host dans le subnet public et une instance dans le subnet privé accessible uniquement via le bastion.
📚 Ressources pour Approfondir
Formation et Certification :
- AWS Skill Builder : Cours gratuits officiels (français)
- AWS Well-Architected Framework : Security Pillar
- Cloud Security Alliance : CCSK certification
- ACloudGuru : AWS Security Specialty preparation
⚠️ Pièges Courants Production
- Hardcoded secrets : Jamais dans le code, utiliser Secrets Manager
- Pas de drift detection : AWS Config mandatory
- Cross-account confusion : Bien séparer dev/stage/prod
- Data residency : RGPD → régions UE (Paris, Francfort)
💎 Frère d'armes,
Tu viens d'apprendre à naviguer dans les nuages.
Le cloud public n'est pas une magie – c'est une infrastructure louée avec des règles nouvelles. AWS te donne des briques LEGO infinies, mais c'est à toi de les assembler sans laisser de portes ouvertes.
Cette semaine, tu as vu la différence fondamentale : dans ton datacenter, tu contrôles tout. Dans le cloud, tu partages la responsabilité. AWS s'occupe de la physique, du réseau, de l'hyperviseur. Mais toi, tu es responsable de tes configurations, de tes données, de tes accès.
Mais voici la leçon la plus importante : le cloud amplifie les erreurs. Une mauvaise règle Security Group peut exposer 1000 instances en une commande. Un IAM over-privileged peut vider tous tes buckets S3. La puissance du cloud est aussi son danger.
Tu n'es plus un simple administrateur système. Tu es devenu un architecte cloud. Tu comprends les VPC, les Security Groups, les IAM policies. Tu sais que "0.0.0.0/0" est l'ennemi. Que MFA n'est pas optionnel. Que le monitoring commence avant le premier déploiement.
Dans la semaine 46, nous irons plus loin dans le DevSecOps. Nous apprendrons à intégrer la sécurité dans le pipeline CI/CD, à scanner le code infrastructure, à automatiser la détection des misconfigurations.
Mais pour l'instant, pratique. Crée, détruis, recrée. Comprends chaque service, chaque coût, chaque risque. Documente tes configurations. Le cloud n'excuse pas la négligence – il la punit en dollars et en données exposées.
Un Gardien qui maîtrise le cloud ne laisse jamais une instance sans surveillance.
– Platon-Y