AWS Academy Cloud Security Foundations

Modules 1 à 8
Module 1 : Introduction & Bienvenue
1. Structure du Module 1
Ce module d'introduction pose les bases du programme AWS Academy Cloud Security Foundations. Il détaille
les attentes du cours, les prérequis techniques et méthodologiques, ainsi que les objectifs globaux
d'apprentissage.
● Section 1 : Prérequis et objectifs du cours.
● Section 2 : Vue d'ensemble du cours (les 8 modules).
● Section 3 : Présentation de la certification cible : AWS Certified Security - Specialty.
● Activité pratique : Jeu de piste dans la documentation officielle AWS (AWS Documentation Scavenger
Hunt).

2. Prérequis du Cours
Pour aborder ce cours dans les meilleures conditions et maximiser vos chances de réussite, il est fortement
recommandé de posséder les compétences et connaissances suivantes :
● Cours préalable recommandé : Avoir terminé avec succès le cours AWS Academy Cloud Foundations
ou disposer d'une expérience équivalente sur les services de base AWS (EC2, S3, VPC, IAM).
● Systèmes distribués : Posséder une connaissance pratique des architectures distribuées et des
communications client-serveur.
● Réseaux : Avoir des notions pratiques sur les concepts fondamentaux de réseau : protocoles (TCP/IP,
HTTP/HTTPS, DNS, SSH, RDP), adressage IP (IPv4, masques de sous-réseau) et routage.
● Architectures multi-tiers : Comprendre le fonctionnement des architectures logicielles à plusieurs
niveaux (N-tier), notamment la séparation entre la couche de présentation, la couche applicative et la
couche de données.
● Cloud Computing : Être familiarisé avec les concepts généraux de l'informatique en nuage (IaaS, PaaS,
SaaS, élasticité, mutualisation des ressources).
Précisions terminologiques :
● Connaissance pratique (Working knowledge) : Signifie que vous êtes capable de manipuler et d'utiliser
un outil ou un concept avec succès, même si vous n'en comprenez pas tous les détails de fonctionnement
interne.
● Familiarité (Familiarity) : Signifie que vous avez déjà été exposé au concept et que vous en comprenez
les bases théoriques sans nécessairement l'avoir implémenté de manière approfondie.

3. Objectifs d'Apprentissage
À la fin de ce cours, vous serez en mesure de :
1. Identifier les avantages de la sécurité dans le cloud et définir la répartition du partage des responsabilités
au sein d'Amazon Web Services (AWS).
2. Utiliser efficacement les fonctionnalités d'AWS IAM (Identity and Access Management) pour sécuriser les
identités et gérer finement les autorisations.
3. Sécuriser les accès réseau aux ressources déployées sur AWS en concevant des architectures VPC
robustes et isolées.
 4. Expliquer les différentes méthodes et outils disponibles pour chiffrer les données au repos (at rest) et en
transit.
5. Déterminer quels services AWS utiliser pour assurer la surveillance (monitoring), la détection des
menaces et la réponse automatisée aux incidents de sécurité.

4. Plan et Programme du Cours

Le programme est structuré autour de 8 modules conçus pour vous amener progressivement vers une maîtrise
des fondamentaux de la sécurité sur AWS :
● Module 1 : Bienvenue (Introduction et présentation du programme).
● Module 2 : Introduction à la sécurité sur AWS (Concepts fondamentaux, philosophie et modèle de
responsabilité partagée).
● Module 3 : Sécurisation de l'accès aux ressources Cloud (Gestion des identités et des accès avec IAM).
● Module 4 : Sécurisation de votre infrastructure (Sécurité réseau avec VPC, pare-feu applicatifs et
durcissement d'instances).
● Module 5 : Protection des données dans vos applications (Chiffrement au repos/en transit et gestion des
clés avec KMS).
● Module 6 : Journalisation (Logging) et Surveillance (Monitoring) (Centralisation des logs et détection
proactive des anomalies).
● Module 7 : Réponse et gestion des incidents (Mécanismes d'isolation et automatisation de la
remédiation).
● Module 8 : Transition vers la certification (Préparation aux examens AWS et méthodologie).

5. Modalités Pédagogiques
Ce cours adopte une approche active et équilibrée combinant théorie et pratique à travers différents supports :
● Supports de cours (Slides) : Présentations théoriques structurées pour poser les bases conceptuelles
indispensables.
● Activités de réflexion et d'exploration :
○ Module 1 : Jeu de piste dans la documentation AWS.
○ Module 2 : Analyse de scénarios concrets sur le modèle de responsabilité partagée.
○ Module 6 : Analyse et interprétation d'un fichier de log brut (JSON CloudTrail et VPC Flow Logs).
● Démonstrations guidées par l'instructeur :
○ Module 3 : Configuration d'une politique de ressources multi-comptes sur Amazon S3.
○ Module 6 : Découverte opérationnelle d'AWS Security Hub.
● Travaux pratiques (Labs) en environnement AWS réel :
○ Module 3 : Utilisation des politiques basées sur les ressources pour sécuriser un compartiment
(bucket) S3.
○ Module 4 : Sécurisation des ressources d'un VPC à l'aide des groupes de sécurité (Security Groups).
○ Module 5 : Chiffrement des données au repos à l'aide d'AWS Key Management Service (AWS KMS).
○ Module 6 : Surveillance et alertes de sécurité avec AWS CloudTrail et Amazon CloudWatch.
○ Module 7 : Résolution et remédiation automatique d'un incident à l'aide d'AWS Config et AWS
Lambda.

6. Évaluation des Connaissances

Pour mesurer votre progression tout au long de votre parcours, deux types d'évaluations sont mis à votre
disposition :
● Contrôles de connaissances (Knowledge checks) : Disponibles de manière intermédiaire pour les
modules 2 à 7. Les questions portent directement sur le contenu des diapositives, les concepts clés et les
guides de travaux pratiques.
 ● Évaluation finale du cours (Course assessment) : Un examen de synthèse composé de 25 questions
à choix multiples tirées au sort de manière aléatoire, couvrant l'intégralité du programme.

Module 2 : Introduction à la sécurité sur AWS

1. Structure du Module 2
Ce module pose les bases indispensables pour comprendre la philosophie de sécurité d'AWS, les principes de
conception fondamentaux qui régissent les architectures cloud sécurisées, ainsi que la répartition cruciale des
rôles de sécurité entre AWS et vous.
● Section 1 : Sécurité dans le Cloud AWS (Security in the AWS Cloud).
● Section 2 : Principes de conception de la sécurité (Security design principles).
● Section 3 : Le modèle de responsabilité partagée (Shared responsibility model).
● Activité pratique : Analyse et mise en situation du modèle de responsabilité partagée.

2. Objectifs d'Apprentissage
À la fin de ce module, vous serez en mesure de :
1. Identifier les caractéristiques de sécurité et les avantages stratégiques de l'informatique en nuage
(visibilité, contrôle, conformité automatisée).
2. Identifier les principes fondamentaux de sécurité sur lesquels repose le cadre d'architecture AWS (AWS
Well-Architected Framework - Pilier Sécurité).
3. Déterminer avec précision quelle partie d'une application ou d'une infrastructure le client est responsable
de sécuriser dans le cloud par rapport à ce qu'AWS sécurise.

3. Aperçu des Sections

Section 1 : Sécurité dans le Cloud AWS
La sécurité chez AWS est la priorité absolue. Contrairement aux datacenters traditionnels sur site (on-
premise), le cloud AWS offre des avantages uniques :
● Visibilité et contrôle complets : Vous savez exactement quelles ressources sont déployées et qui y
accède à tout moment.
● Automatisation de la sécurité : Réduction des risques d'erreurs humaines grâce à l'infrastructure en
tant que code (IaC) et aux outils de remédiation automatique.
● Conformité et certifications : AWS maintient des certifications de sécurité rigoureuses (ISO 27001,
SOC 1/2/3, PCI-DSS Level 1, HIPAA, RGPD), dont les clients héritent en partie pour simplifier leurs
propres audits.
Section 2 : Principes de conception de la sécurité
Le pilier Sécurité du Well-Architected Framework recommande sept principes de conception clés :
1. Mettre en œuvre un socle d'identité solide : Appliquer le principe du moindre privilège et centraliser la
gestion des identités.
2. Garantir la traçabilité : Surveiller, alerter et auditer toutes les actions et modifications de configuration
en temps réel.
3. Appliquer la sécurité à tous les niveaux (Défense en profondeur) : Utiliser plusieurs mécanismes de
contrôle (pare-feu réseau, chiffrement, politiques IAM, protections d'instances).
4. Protéger les données au repos et en transit : Utiliser des mécanismes de chiffrement robustes et gérer
rigoureusement les clés de chiffrement.
5. Garder les personnes à l'écart des données : Réduire ou éliminer l'accès direct aux données par les
humains afin de limiter les risques de fuites accidentelles ou de modifications malveillantes (privilégier les
 outils automatisés).
6. Se préparer aux incidents de sécurité : Développer des plans de réponse aux incidents, des
procédures de quarantaine et des runbooks automatisés.
7. Automatiser les meilleures pratiques de sécurité : Intégrer des contrôles de sécurité automatisés
directement dans vos pipelines de déploiement et votre gouvernance de ressources.
Section 3 : Le modèle de responsabilité partagée
C'est le concept pilier de la sécurité dans le cloud. Il définit clairement la frontière de responsabilité entre AWS
et le client.

+-----------------------------------------------------------------------------------------------------------------------------------------------+
| RESPONSABILITÉ DU CLIENT (Sécurité DANS le cloud) |
| - Données clients (chiffrement, accès) |
| - Gestion des identités et des accès (IAM, MFA, permissions) |
| - Configuration du système d'exploitation invité (OS de l'EC2, correctifs) |
| - Configuration du réseau virtuel (VPC, Security Groups, NACLs) |
| - Applications et code applicatif |
+-----------------------------------------------------------------------------------------------------------------------------------------------+
|========================= LA FRONTIÈRE DE LA RESPONSABILITÉ ========================|
+-----------------------------------------------------------------------------------------------------------------------------------------------+
| RESPONSABILITÉ D'AWS (Sécurité DU cloud) |
| - Infrastructure globale physique (Régions, Zones de Disponibilité, Edge Locations) |
| - Matériel physique (Serveurs, stockage) |
| - Logiciel d'infrastructure (Hyperviseur de virtualisation) |
| - Services managés natifs (Sécurité physique des datacenters, réseaux physiques) |
+-----------------------------------------------------------------------------------------------------------------------------------------------+

● AWS est responsable de la sécurité DU cloud : AWS protège l'infrastructure globale qui exécute
l'ensemble des services proposés dans le cloud AWS. Cela inclut la sécurité physique des centres de
données, le réseau physique, les serveurs de calcul, le stockage physique et l'hyperviseur de
virtualisation.
● Le Client est responsable de la sécurité DANS le cloud : Le client est responsable de la configuration
des services qu'il déploie. Cela comprend la gestion de ses données, l'application des correctifs sur le
système d'exploitation de ses instances EC2, les politiques d'accès IAM, le chiffrement des données et la
configuration des pare-feu réseau (Security Groups et NACLs).

Module 3 : Sécurisation de l'accès aux ressources cloud

1. Structure du Module 3
Ce module traite en profondeur d'AWS IAM, le système de contrôle d'accès central d'AWS. Il aborde
l'authentification (qui êtes-vous ?) et l'autorisation (qu'avez-vous le droit de faire ?), ainsi que la gestion multi-
comptes sécurisée.
● Section 1 : Les fondamentaux d'IAM (IAM fundamentals).
● Section 2 : S'authentifier avec IAM (Authenticating with IAM).
● Section 3 : Autoriser avec IAM (Authorizing with IAM).
● Section 4 : Exemples d'autorisation avec IAM.
● Section 5 : Services additionnels d'authentification et de gestion des accès.
● Section 6 : Gestion multi-comptes avec AWS Organizations.
 ● Lab pratique : Politiques basées sur les ressources (Resource-based policies) et accès multi-comptes
pour un compartiment Amazon S3.

2. Objectifs d'Apprentissage
À la fin de ce module, vous serez en mesure de :
1. Expliquer le rôle et les fonctionnalités clés d'AWS IAM dans le contrôle des accès aux API AWS.
2. Distinguer l'authentification (vérifier l'identité) de l'autorisation (accorder des droits).
3. Créer et configurer des utilisateurs, des groupes, des rôles et des politiques IAM conformes au principe
du moindre privilège.
4. Décrire et analyser la structure d'un document de politique JSON IAM et comprendre la logique
d'évaluation des permissions d'AWS.
5. Implémenter des politiques basées sur les ressources (Resource-based policies) pour l'accès inter-
comptes.
6. Identifier les services de gestion d'identité d'entreprise (SSO/IAM Identity Center, Fédération, Directory
Service, Cognito).
7. Expliquer l'utilisation d'AWS Organizations et des politiques de contrôle de services (SCP) pour définir
des barrières de sécurité à l'échelle de l'entreprise.

3. Aperçu des Sections

Section 1 : Les fondamentaux d'IAM
AWS IAM est un service global (non régional) et gratuit qui gère les identités et leurs permissions.
● Utilisateur IAM (IAM User) : Représente une entité physique (un utilisateur) ou une application
spécifique au sein de votre compte AWS. Il possède des identifiants permanents (mot de passe pour la
console, clés d'accès statiques pour l'API).
● Groupe IAM (IAM Group) : Un regroupement logique d'utilisateurs IAM. Il permet d'assigner des
politiques de permissions à plusieurs personnes simultanément. Note importante : Un groupe n'est pas
une identité (il ne peut pas être listé comme "Principal" dans une politique).
● Rôle IAM (IAM Role) : Une identité temporaire ne possédant pas d'identifiants statiques. À la place,
lorsqu'une entité (un service AWS comme EC2, un utilisateur IAM ou un utilisateur externe fédéré)
endosse un rôle, AWS Security Token Service (STS) lui génère des clés de sécurité temporaires (valides
pour une courte durée).
Section 2 : S'authentifier avec IAM
L'authentification identifie un "Principal" (l'appelant) via trois méthodes principales d'accès :
1. La console de gestion AWS : Accès graphique sécurisé par nom d'utilisateur, mot de passe et
authentification multifacteur (MFA). La MFA (FIDO2, jetons matériels, ou applications virtuelles
d'authentification) est indispensable pour sécuriser tous les accès, en particulier pour l'utilisateur racine
(Root).
2. L'interface en ligne de commande (CLI) ou les SDK (Code) : Accès programmatique via une paire de
clés d'accès statiques : Access Key ID (identifiant public) et Secret Access Key (clé secrète).
3. La fédération d'identités : Permet à des utilisateurs externes (ex. issus de Microsoft Active Directory
d'entreprise) de s'authentifier sur AWS via des standards industriels comme SAML 2.0 ou OpenID
Connect (OIDC) sans avoir besoin de créer des utilisateurs IAM individuels.
Section 3 : Autoriser avec IAM
L'autorisation détermine les privilèges accordés via des Politiques IAM (Policies) écrites au format JSON.

Structure d'un document de politique JSON :

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowS3ReadWrite",
"Effect": "Allow",
"Principal": "*",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::mon-compartiment-securise/*",
"Condition": {
"IpAddress": {
"aws:SourceIp": "[Link]/24"
}
}
}
]
}

● Sid (Statement ID) : Identifiant optionnel pour décrire l'instruction.

● Effect : Détermine si l'instruction autorise (Allow) ou interdit (Deny) l'action.
● Principal : Spécifie qui est visé par la politique (obligatoire uniquement dans les politiques basées sur les
ressources).
● Action : Liste les appels d'API spécifiques qui sont ciblés (ex. s3:GetObject).
● Resource : Désigne les ressources AWS précises ciblées, identifiées par leur ARN (Amazon Resource
Name).
● Condition : Clauses optionnelles de filtrage fin (ex. restreindre l'appel à une plage d'adresses IP ou
exiger que l'utilisateur soit authentifié par MFA).
Logique d'évaluation des permissions d'AWS :
 1. Refus par défaut (Default Deny) : Par défaut, toute requête est refusée.
2. Interdiction explicite (Explicit Deny) : S'il existe une règle Deny explicite (dans n'importe quelle
politique applicable), elle prévaut sur toutes les autres règles et l'accès est bloqué.
3. Autorisation explicite (Allow) : Si aucun Deny n'est présent, la requête doit être explicitement autorisée
par un Allow pour être acceptée. Sinon, elle est rejetée par défaut.
Types de politiques :

● Politiques basées sur l'identité (Identity-based) : Attachées à un utilisateur, un groupe ou un rôle IAM.
Elles définissent ce que l'identité peut faire.
● Politiques basées sur les ressources (Resource-based) : Attachées directement à une ressource (ex.
politique de compartiment S3). Elles indiquent directement qui (quel Principal) est autorisé à effectuer des
actions sur cette ressource.
Section 4 : Exemples d'autorisation avec IAM
● Rôles IAM pour les services AWS (Profils d'instance) : Au lieu d'écrire des clés d'accès en dur dans le
code d'une application hébergée sur une instance EC2, on attache un rôle IAM à cette instance.
L'instance récupère automatiquement et de manière transparente des identifiants temporaires via le
service de métadonnées d'instance (IMDS).
● Accès inter-comptes (Cross-Account) : Permet à un utilisateur du Compte A d'accéder à une
ressource dans le Compte B. Cela se fait soit en utilisant une politique basée sur les ressources (dans le
Compte B) désignant l'utilisateur du Compte A comme Principal, soit en configurant l'utilisateur du
Compte A pour qu'il endosse temporairement un rôle IAM défini dans le Compte B.
Section 5 : Services complémentaires de gestion d'accès
● AWS Directory Service : Connecte vos ressources AWS à un annuaire Active Directory existant ou
déploie un service AD managé dans AWS.
● AWS IAM Identity Center (successeur d'AWS Single Sign-On) : Centralise la gestion des accès à
authentification unique (SSO) pour l'intégralité de vos comptes AWS et applications cloud d'entreprise.
● Amazon Cognito : Gère l'authentification, l'enregistrement et les profils des utilisateurs de vos
applications web et mobiles à destination de vos clients finaux, avec support de la fédération via Google,
Apple ou Facebook.
Section 6 : AWS Organizations
Permet de regrouper et de gérer de façon centralisée plusieurs comptes AWS au sein d'une structure
hiérarchique contenant des Unités Organisationnelles (OUs).
● Politiques de contrôle de services (SCP - Service Control Policies) : Permettent de définir des
barrières de sécurité maximales pour chaque compte ou OU. Les SCP ne confèrent aucune permission,
mais elles restreignent les API accessibles au sein d'un compte. Par exemple, une SCP peut interdire
l'utilisation d'une région spécifique ou bloquer la suppression des logs CloudTrail pour l'ensemble des
utilisateurs d'un compte, y compris l'utilisateur Root.

Module 4 : Sécurisation de votre infrastructure

1. Structure du Module 4
Ce module détaille la protection des infrastructures réseau et de calcul d'AWS. Il se concentre sur l'isolement
du réseau avec Amazon VPC, les pare-feu applicatifs et réseau, ainsi que la sécurisation des instances
virtuelles.
● Section 1 : Structure d'une application à trois niveaux (Structure of a three-tier web application).
● Section 2 : Utilisation d'un VPC (Using a VPC).
● Section 3 : Configuration de sous-réseaux publics et privés et protocoles Internet.
● Section 4 : Utilisation des groupes de sécurité AWS (Using AWS security groups).
● Section 5 : Utilisation des listes de contrôle d'accès réseau (Using AWS network ACLs).
● Section 6 : Utilisation des équilibreurs de charge AWS (Using AWS load balancers).
● Section 7 : Synthèse de l'architecture (Pulling it all together).
● Section 8 : Protection de vos ressources de calcul (Protecting your compute resources).
● Lab pratique : Sécurisation des ressources VPC par le biais des groupes de sécurité.

2. Objectifs d'Apprentissage
À la fin de ce module, vous serez en mesure de :
1. Définir les composants fondamentaux d'un Amazon VPC et leur rôle comme frontières logiques de
sécurité.
2. Décrire l'architecture d'une application à trois niveaux et l'intérêt de la segmentation réseau.
3. Configurer des sous-réseaux publics et privés avec des tables de routage, des passerelles Internet (IGW)
et des passerelles NAT.
4. Distinguer le fonctionnement, la gestion d'état et l'ordre d'évaluation des groupes de sécurité par rapport
aux NACLs.
5. Expliquer comment les équilibreurs de charge (ELB/ALB) améliorent la sécurité par le masquage
d'architecture et la gestion du chiffrement SSL/TLS.
6. Appliquer le principe de défense en profondeur au trafic réseau.
7. Mettre en œuvre les meilleures pratiques de durcissement et d'accès sécurisé sans clé SSH aux
instances EC2 (Systems Manager Session Manager).

3. Aperçu des Sections

Section 1 : Structure d'une application à trois niveaux
La segmentation est un principe de sécurité essentiel. Une architecture web classique à trois niveaux sépare
les fonctions réseaux et applicatives en couches distinctes :
1. Couche Présentation (Serveurs Web / Équilibreurs de charge) : Reçoit directement les requêtes de
l'Internet public et gère les connexions des utilisateurs finaux.
 2. Couche Logique Applicative (Serveurs d'Applications) : Traite la logique métier de l'application. Elle
est placée en réseau privé et ne doit jamais communiquer directement avec l'Internet public.
3. Couche Données (Bases de données / Stockage) : Stocke les informations persistantes (Amazon
RDS, DynamoDB). Elle est hautement isolée et accessible uniquement à partir de requêtes initiées par la
couche applicative.
Section 2 : Utilisation d'un VPC
Amazon VPC (Virtual Private Cloud) est un réseau virtuel isolé au niveau de votre compte AWS et rattaché à
une région spécifique.
● Frontière d'isolement : Par défaut, aucun trafic n'entre ou ne sort d'un VPC sans configuration réseau
explicite.
● Bloc d'adresses CIDR : Le VPC se voit attribuer une plage d'adresses IP privées (ex. $[Link]/16$),
que vous pouvez ensuite diviser pour créer des sous-réseaux.
Section 3 : Configuration de sous-réseaux publics et privés
Un sous-réseau (subnet) est un segment d'adresses IP situé dans une zone de disponibilité (AZ) spécifique du
VPC.
● Sous-réseau Public : Contient les ressources exposées à l'extérieur. Sa table de routage contient une
route explicite acheminant le trafic vers une Passerelle Internet (IGW - Internet Gateway).
● Sous-réseau Privé : Contient les ressources sensibles. Sa table de routage ne dispose d'aucune route
vers l'IGW.
● Passerelle NAT (NAT Gateway) : Déployée dans un sous-réseau public, elle permet aux ressources du
sous-réseau privé d'initier des communications sortantes (ex. pour télécharger des correctifs de sécurité
OS) tout en bloquant toute tentative de connexion entrante initiée par des tiers depuis Internet.
● Tables de routage (Route Tables) : Contiennent les règles d'aiguillage (routes) réseau au niveau de
chaque sous-réseau.
Section 4 : Groupes de sécurité AWS (Security Groups)
Les groupes de sécurité agissent comme des pare-feu virtuels au niveau des instances (cartes réseau
virtuelles ENI).
● Stateful (À état) : Si vous autorisez un trafic entrant (ex. HTTP sur le port 80), le trafic de réponse sortant
correspondant est automatiquement autorisé, sans avoir besoin d'ouvrir explicitement le port sortant.
● Règles d'autorisation uniquement : On ne peut configurer que des règles de type Allow. Tout trafic non
explicitement autorisé est bloqué par défaut.
● Portée : Évalués globalement avant même que le paquet réseau n'atteigne le système d'exploitation de
l'instance.
Section 5 : Listes de contrôle d'accès réseau (Network ACLs)
Les NACLs agissent comme des pare-feu virtuels au niveau des sous-réseaux.
● Stateless (Sans état) : Les NACLs ne mémorisent pas l'état des connexions. Le trafic de réponse doit
être explicitement autorisé par une règle inverse (règle sortante pour un flux entrant).
● Autorisations et Interdictions (Allow & Deny) : Permettent de rejeter explicitement des adresses IP ou
des plages d'adresses réseau (pratique pour bloquer une attaque provenant d'adresses IP malveillantes
identifiées).
● Ordre d'évaluation : Les règles sont lues et appliquées de manière ordonnée et séquentielle selon des
numéros de règles croissants (la règle 100 est évaluée avant la règle 200). La première règle qui
correspond au trafic s'applique immédiatement.
Tableau Comparatif : Groupes de Sécurité vs NACLs
 Caractéristique Groupe de Sécurité (Security Liste de Contrôle d'Accès
Group) Réseau (NACL)
Niveau d'application Instance (Carte réseau virtuelle - Sous-réseau entier
ENI)
Gestion de l'état Stateful (Réponse Stateless (Réponse à autoriser
automatiquement autorisée) explicitement)
Types de règles Uniquement des règles Règles d'autorisation (Allow) et
d'autorisation (Allow) d'interdiction (Deny)
Ordre d'évaluation Toutes les règles sont évaluées Règles évaluées dans l'ordre
globalement numérique croissant
Section 6 : Équilibreurs de charge AWS (Elastic Load Balancing)
L'ELB distribue le trafic entrant sur plusieurs serveurs. L'Application Load Balancer (ALB) opère au niveau
de la couche applicative (Couche 7 du modèle OSI).
● Terminaison SSL/TLS (Déchargement SSL) : L'ALB gère le chiffrement et déchiffre le trafic HTTPS à la
place des instances de calcul d'arrière-plan (backend), centralisant les certificats via AWS Certificate
Manager (ACM).
● Masquage d'architecture : Les instances web n'ont pas d'IP publiques et ne sont pas directement
exposées à Internet ; elles ne reçoivent que le trafic filtré provenant de l'ALB.
● Sécurité intégrée : S'associe nativement avec AWS WAF (pare-feu d'application web pour bloquer les
injections SQL ou attaques XSS) et bénéficie d'une protection anti-DDoS automatique avec AWS Shield.
Section 7 : Synthèse de l'architecture
Une architecture réseau de production hautement sécurisée combine ces éléments de la façon suivante :
1. Les clients externes se connectent à l'ALB positionné dans un sous-réseau public.
2. L'ALB valide le certificat SSL/TLS et achemine les requêtes HTTP/HTTPS déchiffrées vers les serveurs
web situés dans des sous-réseaux privés.
3. Le groupe de sécurité des serveurs web privés n'accepte le trafic que s'il provient exclusivement du
groupe de sécurité de l'ALB.
4. Les bases de données sont placées dans un sous-réseau privé encore plus isolé, avec un groupe de
sécurité restreignant l'accès au port de la base de données (ex. TCP 3306 pour MySQL) en provenance
uniquement de la couche applicative.
Section 8 : Protection de vos ressources de calcul
● Durcissement d'image (Hardening) : Créer des AMIs sécurisées débarrassées des packages et
services inutiles (AMIs certifiées CIS ou "Golden Images").
● Gestion des correctifs (Patch Management) : Automatiser l'analyse et l'application des mises à jour
système à l'aide d'AWS Systems Manager (SSM) Patch Manager.
● AWS Systems Manager Session Manager : Permet d'administrer les instances EC2 à distance via un
shell web ou CLI sécurisé sans avoir besoin d'ouvrir le port SSH 22 ou RDP 3389 dans les groupes de
sécurité, éliminant ainsi le besoin d'adresses IP publiques, de bastions ou de gestion de clés SSH privées
statiques.

Module 5 : Protection des données dans votre application

1. Structure du Module 5
Ce module se concentre sur l'un des aspects les plus critiques de la sécurité cloud : la protection des données
contre les accès non autorisés, la divulgation ou l'altération. Il aborde le chiffrement au repos et en transit avec
un focus sur Amazon S3 et AWS KMS.
 ● Section 1 : Protection des données au repos (Protecting data at rest).
● Section 2 : Fonctionnalités de protection d'Amazon S3 (Amazon S3 protection features).
● Section 3 : Protection par chiffrement (Protection through encryption).
● Section 4 : Protection des données en transit (Protecting data in transit).
● Section 5 : Bonnes pratiques de protection des données dans Amazon S3 (Best practices).
● Section 6 : Autres services de protection des données.
● Lab pratique : Chiffrement des données au repos à l'aide d'AWS Key Management Service (AWS KMS).

2. Objectifs d'Apprentissage
À la fin de ce module, vous serez en mesure de :
1. Décrire l'importance et les mécanismes de protection des données au repos et en transit.
2. Identifier les fonctionnalités de sécurité clés d'Amazon Simple Storage Service (Amazon S3) pour
restreindre l'accès et auditer les modifications.
3. Chiffrer des données dans Amazon S3 de manière transparente et sécurisée.
4. Différencier le chiffrement côté client (CSE) et le chiffrement côté serveur (SSE).
5. Distinguer les trois types de chiffrement côté serveur : SSE-S3, SSE-KMS et SSE-C.
6. Appliquer les meilleures pratiques de sécurité d'Amazon S3 pour éliminer les risques de fuites
accidentelles de données.
7. Expliquer le rôle de services de sécurité AWS clés tels que AWS KMS, AWS CloudHSM, Amazon Macie
et AWS Secrets Manager.

3. Aperçu des Sections

Section 1 : Protection des données au repos
Les données au repos font référence aux données stockées de manière persistante sur un support physique
(disques durs, SSD, stockage objet, bases de données).
● Menaces associées : Vol physique de matériel de stockage, accès non autorisés par contournement du
système de fichiers ou compromission d'identifiants de comptes.
● Contrôles essentiels :
○ Chiffrement : Transformation des données en texte chiffré illisible à l'aide d'algorithmes de
chiffrement symétrique robustes (comme AES-256). Même en cas de compromission physique du
support, les données restent inexploitables sans la clé de déchiffrement.
○ Contrôle d'accès : Restriction stricte des accès physiques et logiques aux supports de stockage.
Section 2 : Fonctionnalités de protection d'Amazon S3
Amazon S3 offre un ensemble complet de fonctionnalités intégrées pour protéger et contrôler l'accès aux
objets stockés :
● Blocage des accès publics S3 (S3 Block Public Access) : Option de sécurité globale (au niveau du
compartiment ou du compte AWS) qui empêche de rendre des objets ou des compartiments S3 publics
par inadvertance, remplaçant ainsi les autorisations d'ACL ou de politiques de compartiment trop
permissives.
● Politiques de compartiment (S3 Bucket Policies) : Politiques basées sur les ressources qui définissent
précisément qui (quels utilisateurs, rôles ou comptes AWS) a le droit d'effectuer quelles actions sur les
objets du compartiment.
● Listes de contrôle d'accès (ACL S3) : Méthode historique de gestion des accès individuels pour chaque
objet. (Remarque : AWS recommande aujourd'hui de désactiver les ACL au profit des politiques de
compartiment et d'IAM pour centraliser le contrôle).
● Contrôle de version (Versioning) : Permet de conserver plusieurs variantes d'un objet dans le même
compartiment. Protège contre les suppressions accidentelles et les écrasements de données malveillants.
 ● Verrouillage d'objets (S3 Object Lock) : Permet de mettre en œuvre un modèle de stockage WORM
(Write Once, Read Many). Il empêche la suppression ou la modification d'un objet pendant une période
de rétention définie, idéal pour la conformité légale et la protection contre les ransomwares.
Section 3 : Protection par chiffrement
AWS divise les techniques de chiffrement d'Amazon S3 en deux grandes catégories :

A. Chiffrement côté serveur (SSE - Server-Side Encryption)

Amazon S3 chiffre l'objet lors de sa réception dans le centre de données, puis le déchiffre automatiquement
lors de sa récupération par un utilisateur autorisé.
1. SSE-S3 (Server-Side Encryption with Amazon S3 Managed Keys) : S3 gère entièrement le
chiffrement, le déchiffrement et le cycle de vie des clés de chiffrement de façon transparente. Il utilise
l'algorithme AES-256. C'est la méthode de chiffrement par défaut, la plus simple et sans surcoût.
2. SSE-KMS (Server-Side Encryption with AWS KMS Keys) : Les clés de chiffrement sont stockées et
gérées dans AWS Key Management Service. Offre un contrôle granulaire des politiques d'accès aux clés
(qui peut chiffrer/déchiffrer) et génère des pistes d'audit détaillées dans AWS CloudTrail pour chaque
utilisation de la clé de chiffrement.
3. SSE-C (Server-Side Encryption with Customer-Provided Keys) : Le client fournit sa propre clé de
chiffrement dans les en-têtes de requêtes HTTP. Amazon S3 effectue l'opération de
chiffrement/déchiffrement mais ne stocke jamais la clé du client. Si vous perdez la clé, vous perdez
définitivement l'accès aux données.
B. Chiffrement côté client (CSE - Client-Side Encryption)

Les données sont chiffrées localement sur les serveurs ou postes de travail du client avant d'être envoyées sur
le réseau à destination d'Amazon S3. AWS ne voit jamais le texte en clair ni les clés de chiffrement. Peut
s'appuyer sur des clés gérées localement ou sur des clés gérées dans AWS KMS via l'utilisation du SDK AWS
Encryption.

Section 4 : Protection des données en transit

Les données en transit se déplacent d'un point A à un point B sur un réseau (ex. entre un navigateur web et un
serveur applicatif, ou entre deux services cloud).
● Menaces associées : Interception de paquets (eavesdropping), attaques de l'homme du milieu (man-in-
the-middle).
● Mécanismes de protection :
○ HTTPS/TLS : Chiffre la session réseau. L'utilisation de politiques de compartiment permet d'imposer
l'utilisation exclusive du protocole HTTPS (aws:SecureTransport: true) pour rejeter les connexions
HTTP non sécurisées.
○ VPN IPsec (AWS Site-to-Site VPN) : Établit un tunnel sécurisé et chiffré entre un réseau d'entreprise
sur site et un VPC AWS à travers Internet.
○ AWS Direct Connect : Liaison réseau dédiée et privée entre votre infrastructure locale et AWS
(n'utilise pas l'Internet public, offrant ainsi un niveau de sécurité et de performance accru).
Section 5 : Bonnes pratiques de protection des données dans Amazon S3
● Activer le chiffrement par défaut : S'assurer que tout nouvel objet déposé dans un compartiment est
chiffré automatiquement.
● Activer le blocage des accès publics S3 (S3 Block Public Access) : Sauf nécessité absolue (ex.
hébergement d'un site web statique public).
● Utiliser le principe du moindre privilège : Restreindre les politiques IAM et de compartiment.
 ● Activer l'authentification MFA pour la suppression (MFA Delete) : Exige un code de sécurité à usage
unique issu d'un appareil physique ou virtuel pour supprimer définitivement une version d'un objet.
● Activer les journaux d'accès (S3 Server Access Logs) et AWS CloudTrail : Pour enregistrer et
analyser toutes les requêtes d'accès aux données à des fins d'audit et de détection d'anomalies.
Section 6 : Autres services de protection des données
● AWS Key Management Service (AWS KMS) : Service managé qui permet de créer, contrôler et faire
tourner facilement des clés de chiffrement symétriques et asymétriques. Les clés sont hautement
sécurisées au sein de modules de sécurité matériels (HSM).
● AWS CloudHSM : Fournit des instances de modules de sécurité matériels dédiés (HSM) directement
dans votre VPC. Recommandé pour les cas d'usage hautement réglementés exigeant le contrôle
physique exclusif du matériel de stockage des clés (certifié FIPS 140-2 Level 3).
● Amazon Macie : Service de sécurité entièrement géré qui utilise le machine learning et la
correspondance de motifs pour découvrir, classifier et protéger automatiquement les données sensibles
(comme les numéros de sécurité sociale, les informations de cartes de crédit ou les clés API) stockées
dans Amazon S3.
● AWS Secrets Manager : Permet de stocker de manière centralisée, de récupérer de façon dynamique et
de faire pivoter automatiquement des secrets applicatifs (tels que des identifiants de bases de données,
des clés d'API et des mots de passe) tout au long de leur cycle de vie.

Module 6 : Journalisation et Surveillance (Logging and

Monitoring)
1. Structure du Module 6
Ce module examine comment acquérir une visibilité totale sur votre infrastructure AWS à travers la
centralisation des logs, l'analyse en temps réel et les alertes automatisées.
● Section 1 : Importance de la journalisation et de la surveillance.
● Section 2 : Capture et collecte (Capture and collect).
● Section 3 : Services AWS avec journaux intégrés (AWS services with built-in logs).
● Section 4 : Surveillance et rapports (Monitor and report).
● Section 5 : Bonnes pratiques de journalisation et de surveillance.
● Section 6 : Services AWS supplémentaires pour la sécurité et l'audit.
● Activité pratique : Analyse et lecture d'un fichier journal (Reading a Log File).
● Lab pratique : Surveillance et alertes avec AWS CloudTrail et Amazon CloudWatch.

2. Objectifs d'Apprentissage
À la fin de ce module, vous serez en mesure de :
1. Expliquer l'importance stratégique de la journalisation et de la surveillance pour la posture de sécurité
globale.
2. Identifier le rôle d'AWS CloudTrail dans le suivi des appels d'API et de l'activité des utilisateurs.
3. Distinguer les événements de gestion (Management Events) et les événements de données (Data
Events) dans CloudTrail.
4. Décrire le fonctionnement d'Amazon CloudWatch pour la collecte de logs, la gestion des métriques et le
déclenchement d'alarmes.
5. Lire et analyser un fichier journal brut (comme un log CloudTrail ou un log de flux VPC) pour identifier des
activités suspectes.
6. Citer les principaux services AWS dotés de journaux d'accès intégrés (VPC Flow Logs, S3 Server Access
Logs, ELB Access Logs).
 7. Appliquer les meilleures pratiques d'architecture pour sécuriser et centraliser les logs de sécurité.
8. Expliquer la complémentarité des services de sécurité avancés tels que AWS Config, AWS Security Hub,
Amazon GuardDuty et Amazon Inspector.

3. Aperçu détaillé des Sections

Section 1 : Importance de la journalisation et de la surveillance
La journalisation (logging) consiste à enregistrer de manière chronologique les événements survenant dans un
système. La surveillance (monitoring) consiste à analyser activement ces données en temps réel pour en
évaluer la santé, la performance et la sécurité.

Pourquoi journaliser et surveiller ?

● Visibilité continue : Savoir exactement quelles ressources sont créées, modifiées ou supprimées.
● Conformité réglementaire : Prouver aux auditeurs que les contrôles de sécurité sont actifs (ex. PCI-
DSS, SOC 2, RGPD).
● Détection des menaces : Repérer les comportements anormaux (ex. tentatives de connexion échouées
en masse, appels d'API non autorisés).
● Réponse aux incidents : Reconstituer le fil des événements après une faille pour identifier le point
d'entrée et l'étendue des dégâts.
Les trois piliers de l'observabilité :

1. Les Logs (Journaux) : Enregistrements textuels détaillés d'un événement discret (ex. "L'utilisateur Alice
a supprimé la base de données à 14h02").
2. Les Métriques : Données numériques mesurées sur un intervalle de temps (ex. Taux d'utilisation du
CPU, nombre de requêtes par seconde).
3. Les Traces : Représentation du parcours d'une requête à travers les différents composants d'une
application distribuée (microservices).
Section 2 : Capture et collecte
Pour analyser des logs, il faut d'abord les capturer et les stocker de manière fiable. AWS s'appuie
principalement sur deux services fondamentaux pour cette étape.

A. AWS CloudTrail : L'auditeur de votre compte AWS

CloudTrail enregistre toutes les actions effectuées par un utilisateur, un rôle IAM ou un service AWS. Chaque
action est capturée sous forme d'un événement d'API.
● Événements de gestion (Management Events) : Enregistrent les opérations de plan de contrôle
(control plane) effectuées sur vos ressources AWS. Activés par défaut gratuitement (historique de 90
jours). Exemples : Création d'un compartiment S3, attachement d'une politique IAM, démarrage d'une
instance EC2.
● Événements de données (Data Events) : Enregistrent les opérations de plan de données (data plane)
au sein des ressources elles-mêmes. Désactivés par défaut car ils génèrent un volume très élevé de
données (payants). Exemples : Lecture/écriture d'un objet spécifique dans S3 (GetObject, PutObject),
invocation d'une fonction AWS Lambda.
Sécurisation des journaux CloudTrail :

Les logs CloudTrail sont stockés dans un compartiment Amazon S3.

● Chiffrement : Chiffrement par défaut ou via une clé gérée par le client (SSE-KMS) pour une sécurité
accrue.
● Validation de l'intégrité des fichiers journaux : CloudTrail génère des fichiers de signature à l'aide
d'algorithmes de hachage (SHA-256) et de signatures numériques (RSA). Cela permet de vérifier si un
 log a été modifié, supprimé ou falsifié après son écriture.
● Protection contre la suppression : Utilisation de politiques S3 strictes, de S3 Object Lock (WORM) ou
du verrouillage MFA Delete.
B. Amazon CloudWatch Logs : La centralisation applicative et système

CloudWatch Logs permet de centraliser les logs provenant de vos systèmes d'exploitation, de vos applications
et de divers services AWS.
● Log Stream (Flux de journaux) : Une séquence d'événements de journalisation provenant d'une même
source (ex. un fichier log spécifique sur une instance EC2).
● Log Group (Groupe de journaux) : Une collection de flux de journaux qui partagent les mêmes
paramètres de rétention, de chiffrement et de contrôle d'accès.
● L'agent Unified CloudWatch : Un logiciel à installer sur vos instances EC2 ou serveurs sur site (on-
premises) pour collecter et envoyer automatiquement les logs système (ex. /var/log/secure, logs Apache)
et les métriques de niveau OS (utilisation de la mémoire RAM, espace disque) vers CloudWatch Logs.
Activité pratique : Analyse et lecture d'un fichier journal
1. Exemple de journal d'événement AWS CloudTrail (Format JSON)

Lorsqu'un utilisateur effectue une action non autorisée, CloudTrail génère un événement structuré ainsi :

{
"eventVersion": "1.08",
"userIdentity": {
"type": "IAMUser",
"principalId": "AIDAIFDZJOVEXAMPLE",
"arn": "arn:aws:iam::123456789012:user/[Link]",
"accountId": "123456789012",
"userName": "[Link]"
},
"eventTime": "2026-05-19T08:15:30Z",
"eventSource": "[Link]",
"eventName": "StopInstances",
"awsRegion": "eu-west-3",
"sourceIPAddress": "[Link]",
"userAgent": "aws-cli/2.4.27 Python/3.8.8",
"errorCode": "[Link]",
"errorMessage": "You are not authorized to perform this operation.",
"requestParameters": {
"instancesSet": {
"items": [
{
"instanceId": "i-0abcd1234efgh5678"
}
]
}
}
}

Analyse de l'incident :

● Qui ? L'utilisateur IAM [Link] ([Link]).

 ● Quand ? Le 19 mai 2026 à 08:15:30 UTC (eventTime).
● Quoi ? Il a tenté d'arrêter l'instance EC2 i-0abcd1234efgh5678 (eventName: StopInstances sur
eventSource: [Link]).
● Comment ? Depuis l'adresse IP publique [Link] (sourceIPAddress) via l'interface en ligne de
commande AWS CLI (userAgent).
● Résultat ? Un échec critique de type Accès refusé (errorCode: [Link]), ce qui
indique une tentative d'action en dehors de ses privilèges IAM autorisés.
2. Exemple de ligne de log de flux VPC (VPC Flow Logs)

Les VPC Flow Logs ne sont pas au format JSON, mais sous forme de lignes délimitées par des espaces
(selon un format par défaut) :

2 123456789012 eni-0f12a3bc45de67f89 [Link] [Link] 443 51234 6 15 7680 1621412130

1621412190 REJECT OK

Analyse des champs principaux :

● 2 : Version du format de log.

● 123456789012 : ID du compte AWS.
● eni-0f12a3bc45de67f89 : L'interface réseau de destination.
● [Link] & [Link] : Adresse IP source (interne) et adresse IP de destination (externe).
● 443 & 51234 : Port source (HTTPS) et port de destination (port éphémère).
● 6 : Protocole IP (6 correspond à TCP, 17 à UDP).
● 15 & 7680 : Nombre de paquets transférés (15) et taille totale en octets (7680).
● REJECT : L'action prise par les règles de sécurité (bloqué par le Security Group ou la Network ACL).
● OK : Statut du log.
Section 3 : Services AWS avec journaux intégrés
En dehors de CloudTrail, de nombreux services AWS génèrent leurs propres journaux d'accès spécialisés
pour tracer le trafic de données :
1. VPC Flow Logs (Journaux de flux VPC) : Capture les métadonnées sur le trafic IP entrant et sortant
des interfaces réseau (ENI) de votre VPC. Utilité de sécurité : Identifier si une ressource compromise
communique avec des adresses IP malveillantes connues ou détecter des scans de ports internes.
2. Amazon S3 Server Access Logs (Journaux d'accès S3) : Fournit des enregistrements détaillés pour
toutes les requêtes faites à un compartiment S3 spécifique. Utilité de sécurité : Tracer qui a téléchargé,
modifié ou supprimé un fichier sensible (ex. "Qui a lu le fichier [Link] ?").
3. Elastic Load Balancing (ELB) Access Logs : Enregistre des informations détaillées sur les requêtes
envoyées à vos équilibreurs de charge (Application, Network ou Classic Load Balancers). Utilité de
sécurité : Analyser les schémas de trafic HTTP/HTTPS, identifier l'adresse IP d'origine des clients et
mesurer la latence applicative.
4. Amazon Route 53 Resolver Query Logs : Enregistre toutes les requêtes DNS émises par les
ressources au sein de votre VPC (comme les requêtes de résolution de noms de domaine externes).
Utilité de sécurité : Détecter les tentatives d'exfiltration de données par tunnel DNS ou l'accès à des
domaines d'hameçonnage (phishing).
Section 4 : Surveillance et rapports (Monitor and report)
La simple collecte de logs est insuffisante en cas d'attaque active. Amazon CloudWatch fournit des outils pour
analyser, visualiser et réagir automatiquement.
 ● CloudWatch Metrics (Métriques) : Représentations temporelles de valeurs numériques. Les métriques
sont regroupées dans des Espaces de noms (Namespaces) (ex. AWS/EC2). Elles contiennent des
Dimensions (paires clé-valeur, ex. InstanceId: i-12345) pour filtrer les données.
● CloudWatch Alarms (Alarmes) : Surveillent une seule métrique (ou le résultat d'une expression
mathématique) sur une période donnée.
○ États d'une alarme : OK (tout est normal), ALARM (le seuil configuré est dépassé),
INSUFFICIENT_DATA (pas assez de données pour conclure).
○ Actions automatisées : Envoyer une notification par e-mail via Amazon SNS (Simple Notification
Service), déclencher un groupe d'Auto Scaling pour ajouter des serveurs, ou exécuter une action EC2
(ex. redémarrer ou arrêter une instance défaillante).
● CloudWatch Dashboards (Tableaux de bord) : Pages d'accueil personnalisables dans la console AWS
qui affichent des graphiques de métriques pour surveiller visuellement l'ensemble de vos ressources en
un coup d'œil.
● CloudWatch Logs Insights : Moteur de recherche interactif et puissant qui vous permet d'analyser vos
logs CloudWatch à l'aide d'un langage de requête de type SQL. Vous pouvez filtrer, regrouper et trier des
millions de lignes de logs en quelques secondes pour isoler rapidement les erreurs ou activités
anormales.
Section 5 : Bonnes pratiques de journalisation et de surveillance
Pour concevoir un système d'audit robuste et conforme aux cadres de sécurité d'AWS (Well-Architected
Framework), appliquez ces principes :
1. Centralisation dans un compte d'archivage dédié : Envoyez tous vos logs CloudTrail et VPC Flow
Logs vers un compartiment S3 situé dans un compte AWS de sécurité séparé (souvent géré par l'équipe
de sécurité et isolé des développeurs).
2. Appliquer le moindre privilège sur les logs : Restreignez l'accès en lecture aux fichiers de logs.
Personne, y compris les administrateurs systèmes au quotidien, ne devrait pouvoir modifier ou supprimer
les fichiers de logs (utilisation de politiques de clés KMS et de politiques de compartiment S3 restrictives).
3. Activer CloudTrail globalement : Assurez-vous d'activer CloudTrail dans toutes les régions AWS de
votre compte. Cela garantit que si un attaquant tente de lancer des ressources non autorisées dans une
région inutilisée (comme une région éloignée pour miner des cryptomonnaies), son activité sera
immédiatement enregistrée.
4. Définir des politiques de rétention adaptées : Ne conservez pas les logs indéfiniment dans des
classes de stockage coûteuses. Utilisez les politiques de cycle de vie Amazon S3 pour archiver
automatiquement les anciens logs vers Amazon S3 Glacier après une certaine période (ex. 90 jours) afin
de réduire drastiquement les coûts.
5. Automatiser la détection et la réponse : Ne comptez pas sur l'analyse humaine manuelle. Configurez
des filtres de métriques et des alarmes pour recevoir des notifications instantanées en cas d'anomalies de
sécurité majeures.
Section 6 : Services AWS supplémentaires pour la sécurité et l'audit
● AWS Config : Service de suivi continu qui enregistre l'historique de configuration de vos ressources AWS
et évalue leur conformité par rapport à des règles prédéfinies ou personnalisées (Config Rules).
Exemple : Une règle Config peut vérifier automatiquement si un compartiment S3 est rendu public et
déclencher une remédiation pour le refermer immédiatement.
● Amazon GuardDuty : Service managé de détection des menaces à base d'intelligence artificielle.
GuardDuty analyse en continu et de manière transparente les logs CloudTrail, VPC Flow Logs, les logs
DNS et les logs d'audit EKS pour repérer les activités suspectes (comme des connexions depuis le
réseau Tor, du minage de cryptomonnaie ou des exfiltrations de données S3).
 ● Amazon Inspector : Service de gestion des vulnérabilités automatisé. Il analyse en continu les instances
EC2, les images de conteneurs dans Amazon ECR et les fonctions AWS Lambda à la recherche de
vulnérabilités logicielles connues (CVE) et d'expositions réseau involontaires.
● AWS Security Hub : Console de sécurité centralisée qui rassemble, organise et hiérarchise les alertes
de sécurité (findings) issues de multiples services AWS (GuardDuty, Inspector, Macie, IAM Access
Analyzer) ainsi que de solutions de partenaires tiers. Il évalue également votre posture de sécurité par
rapport aux meilleures pratiques de l'industrie (normes CIS AWS Foundations, PCI-DSS, etc.).

4. Activités Pratiques et Évaluation

Lab dirigé 6.1 : Surveillance et alertes avec AWS CloudTrail et Amazon CloudWatch
Dans ce laboratoire pratique, vous apprenez à configurer un flux d'alerte de bout en bout pour être averti
immédiatement lorsqu'une tentative d'appel d'API non autorisée est détectée dans votre compte AWS :
1. Étape 1 : Activer un journal d'activité (Trail) : Créer un nouveau Trail CloudTrail configuré pour
envoyer ses événements à la fois vers Amazon S3 (archivage) et vers un groupe de logs Amazon
CloudWatch Logs (analyse en temps réel).
2. Étape 2 : Créer un filtre de métrique (Metric Filter) : Définir un filtre de recherche dans CloudWatch
Logs pour identifier les erreurs d'accès refusé.
○ Modèle de filtrage utilisé : { ($.errorCode = "*UnauthorizedOperation") || ($.errorCode =
"AccessDenied") }
3. Étape 3 : Créer une alarme CloudWatch : Associer ce filtre de métrique à une alarme CloudWatch. Si le
filtre de métrique détecte plus de 3 tentatives d'accès refusé en moins de 5 minutes, l'alarme passe à
l'état ALARM.
4. Étape 4 : Configurer une notification SNS : Configurer l'alarme pour qu'elle envoie automatiquement
un message d'alerte à une rubrique Amazon SNS. Cette rubrique distribue ensuite un e-mail d'alerte
contenant les détails de l'incident aux administrateurs de sécurité.
5. Étape 5 : Tester le flux : Tenter délibérément d'exécuter une action interdite (ex. essayer de modifier
une politique IAM ou d'arrêter une instance système avec un rôle restreint) et observer la réception de la
notification d'alerte par e-mail en moins de quelques minutes.
Contrôle des connaissances (Knowledge Check)
La validation de ce module nécessite de maîtriser :
● La différence entre CloudTrail (qui a fait quoi au niveau de l'API AWS) et CloudWatch (état,
performance, métriques et logs système/applicatifs des ressources).
● La sécurisation des fichiers de logs d'audit (validation d'intégrité, contrôle d'accès strict, MFA delete et
archivage à long terme).

Module 7 : Réponse et gestion des incidents (Responding to

and Managing an Incident)
1. Structure du Module 7
Ce module vous enseigne comment identifier, isoler et corriger les incidents de sécurité dans le cloud AWS en
exploitant la puissance de la détection et de l'automatisation.
● Section 1 : Identifier un incident (Identifying an incident).
● Section 2 : Phase de découverte et de reconnaissance (Discovery and recognition).
● Section 3 : Phase de résolution et de restauration (Resolution and recovery).
● Section 4 : Bonnes pratiques pour la gestion d'un incident (Best practices).
● Lab pratique : Remédiation d'un incident à l'aide d'AWS Config et AWS Lambda.
2. Objectifs d'Apprentissage
À la fin de ce module, vous serez en mesure de :
1. Définir ce qu'est un incident de sécurité dans le cloud et comprendre son cycle de vie selon les
frameworks d'industrie (NIST/SANS).
2. Distinguer la responsabilité d'AWS de celle du client en matière de réponse aux incidents.
3. Identifier les services AWS prenant en charge la phase de découverte et de reconnaissance (GuardDuty,
Security Hub, Inspector, Macie, AWS Config).
4. Expliquer comment les services AWS facilitent la résolution et la restauration (AWS Lambda, Systems
Manager Incident Manager, Amazon Detective, AWS Backup).
5. Appliquer les meilleures pratiques d'isolation des ressources (comme une instance EC2 compromise)
pour préserver les preuves forensics.
6. Concevoir et déployer une boucle de remédiation automatisée associant la surveillance de configuration
d'AWS Config et l'exécution de code serveur sans serveur via AWS Lambda.

3. Aperçu détaillé des Sections

Section 1 : Identifier un incident (Identifying an incident)
Un incident de sécurité est un événement ou une série d'événements indésirables ou inattendus qui
présentent une probabilité significative de compromettre les opérations de l'entreprise et de menacer la
sécurité des informations.

Le cycle de vie de la réponse aux incidents (aligné sur le NIST SP 800-61) :

1. Préparation (Preparation) : Établir des outils, des politiques de sécurité, des équipes de réponse
(CSIRT) et des runbooks (procédures de réponse pré-établies).
2. Détection et Analyse (Detection and Analysis) : Identifier les signes d'un incident (alertes, anomalies)
et déterminer sa nature, sa gravité et sa portée.
3. Confinement, Éradication et Restauration (Containment, Eradication, and Recovery) :
○ Confinement : Empêcher l'incident de s'étendre (ex. isoler l'hôte compromise du réseau).
○ Éradication : Supprimer les composants de la menace (ex. supprimer les logiciels malveillants,
révoquer les accès et désactiver les clés compromises).
○ Restauration : Remettre les systèmes affectés en production de manière sécurisée (ex. restaurer
depuis des sauvegardes propres et auditées).
4. Activité post-incident (Post-Incident Activity) : Analyser les leçons apprises (Lessons Learned) pour
améliorer les processus et renforcer les défenses futures.
Le modèle de responsabilité partagée en cas d'incident :

● AWS est responsable de : La réponse aux incidents affectant l'infrastructure globale physique, les
hyperviseurs de virtualisation et les services managés natifs AWS (la sécurité du cloud).
● Le Client est responsable de : La réponse aux incidents affectant ses données, ses configurations
d'accès et réseaux, ses systèmes d'exploitation invités sur EC2, ses applications et ses identifiants IAM
(la sécurité dans le cloud).
Section 2 : Phase de découverte et de reconnaissance
Identifier un incident le plus tôt possible réduit drastiquement son coût et son impact. AWS propose un
écosystème de services pour surveiller, corréler et lever des alertes sur les menaces :
 1. Amazon GuardDuty : Analyse en continu des milliards d'événements issus de sources AWS (VPC Flow
Logs, DNS Query Logs, CloudTrail, S3 Data Events). Utilise l'apprentissage automatique (Machine
Learning) et le profilage comportemental pour détecter des activités hautement suspectes telles que les
communications avec des serveurs de commande et contrôle (C&C), le minage clandestin de
cryptomonnaies ou des escalades de privilèges inhabituelles.
2. AWS Security Hub : Agit comme un agrégateur centralisé. Il collecte et standardise les alertes de
sécurité (findings) issues de services AWS (GuardDuty, Inspector, Macie, IAM Access Analyzer) et de
solutions tierces partenaires. Il fournit une vue unifiée de la posture de sécurité et de conformité du
compte.
3. Amazon Inspector : Scanne en continu les charges de travail actives (instances EC2, conteneurs
Amazon ECR, fonctions Lambda) pour y découvrir des vulnérabilités logicielles (CVE) et des expositions
réseau involontaires.
4. Amazon Macie : Détecte et protège les données sensibles (comme les données personnelles - PII, ou
les données de cartes de crédit - PCI) stockées dans Amazon S3 à l'aide de l'analyse de modèles et du
Machine Learning.
5. AWS Config : Assure un inventaire continu des ressources et évalue leur conformité par rapport à un
état de configuration idéal (ex. "La règle de groupe de sécurité interdisant le port 22 ouvert à tous est-elle
respectée ?").
Section 3 : Phase de résolution et de restauration
Une fois la menace identifiée, l'équipe de sécurité doit agir vite pour limiter l'impact. AWS fournit des outils
d'automatisation pour rationaliser et accélérer cette phase :
1. AWS Systems Manager Incident Manager : Aide les équipes à planifier, suivre et réagir aux incidents
via des plans de réponse automatisés (Response Plans). Il automatise la chaîne de notification (escalade
vers les ingénieurs d'astreinte) et intègre des checklists interactives (runbooks) basées sur AWS Systems
Manager Automation.
2. AWS Lambda (La clé de la remédiation automatique) : Permet d'exécuter du code de remédiation en
réponse à une alerte (sans serveurs à gérer). Exemples d'actions Lambda : Révoquer une session IAM
compromise, appliquer un groupe de sécurité restrictif de "Quarantaine" sur une instance EC2 affectée,
ou désactiver instantanément une clé d'accès d'un utilisateur suspecté de fuite de données.
3. Amazon Detective : Simplifie les enquêtes de sécurité approfondies. Il extrait, assemble et analyse
automatiquement les données d'événements provenant de vos ressources AWS (VPC Flow Logs,
CloudTrail, GuardDuty). Il génère une carte interactive des relations et des comportements au fil du
temps pour vous aider à comprendre rapidement la cause racine d'une alerte complexe.
4. AWS Backup : Centralise et automatise la sauvegarde des données sur les services AWS, garantissant
la disponibilité de copies conformes et non altérées pour la phase de restauration après un incident de
corruption de données ou de ransomware.
Section 4 : Bonnes pratiques pour la gestion d'un incident
● Ne détruisez pas les preuves volatiles (Éviter le "Stop/Reboot" immédiat) : Si vous suspectez qu'une
instance EC2 a été piratée, n'éteignez pas et ne redémarrez pas l'instance immédiatement. Le
redémarrage efface la mémoire RAM (mémoire volatile), qui contient des indices précieux (processus en
cours d'exécution, connexions réseau actives, clés de chiffrement temporaires).
● Pratiquer l'isolation réseau (Quarantaine) : Modifiez le groupe de sécurité (Security Group) de
l'instance pour bloquer toutes les communications entrantes et sortantes, sauf celles provenant de
l'adresse IP dédiée de votre équipe d'investigation.
● Créer une copie conforme pour l'analyse légale (Forensics) : Prenez un instantané (Snapshot) du
volume Amazon EBS de l'instance compromise. Partagez et montez cet instantané sur une instance
d'analyse isolée dans un compte AWS dédié à l'investigation numérique (Forensics Account).
 ● Préparez et testez des "Game Days" : Simulez régulièrement des attaques (ex. vol de clés d'accès,
attaque par déni de service) pour tester l'efficacité de vos outils de détection, vos processus de
communication et vos automatisations.

4. Activités Pratiques et Évaluation

Lab dirigé 7.1 : Remédiation d'un incident à l'aide d'AWS Config et AWS Lambda
Dans ce laboratoire pratique, vous apprenez à configurer un mécanisme d'auto-remédiation (Self-Healing /
Auto-Remediation) pour corriger automatiquement un changement de configuration non conforme et
dangereux sur un groupe de sécurité :

1. Étape 1 : Comprendre l'environnement et accorder les privilèges : Analyser les rôles AWS Identity
and Access Management (IAM) préconfigurés. Vérifier que le rôle de la fonction Lambda possède les
droits nécessaires (ec2:RevokeSecurityGroupIngress, config:PutEvaluations) pour modifier l'infrastructure
et communiquer son statut à AWS Config.
2. Étape 2 : Activer AWS Config : Initialiser AWS Config pour qu'il enregistre les types de ressources
spécifiques dans votre compte AWS, en particulier les groupes de sécurité EC2
(AWS::EC2::SecurityGroup).
3. Étape 3 : Déployer la fonction AWS Lambda de remédiation : Créer une fonction AWS Lambda (en
Python utilisant la bibliothèque SDK boto3). Cette fonction reçoit un événement JSON d'AWS Config
contenant les détails du groupe de sécurité modifié. Si elle identifie une règle non conforme (ex: ouverture
totale du port SSH 22 au monde entier [Link]/0), elle exécute l'appel API revoke_security_group_ingress
pour supprimer instantanément cette règle.
4. Étape 4 : Créer une règle de conformité personnalisée dans AWS Config : Créer une règle AWS
Config personnalisée (Custom Config Rule) qui s'appuie sur la fonction Lambda créée à l'étape
précédente. Configurer cette règle pour qu'elle se déclenche sur tout changement de configuration
(Configuration changes) des groupes de sécurité.
5. Étape 5 : Simuler l'incident et vérifier la remédiation : Aller dans la console Amazon EC2 et modifier
volontairement un groupe de sécurité en y ajoutant une règle d'accès HTTP (port 80) ou SSH (port 22)
ouverte à toutes les adresses IP ([Link]/0). Observer AWS Config évaluer la ressource comme "Non
conforme" (Non-compliant). Vérifier dans les journaux Amazon CloudWatch de la fonction Lambda que le
script s'est exécuté avec succès. Retourner sur la console EC2 : la règle non autorisée a été
automatiquement et immédiatement purgée du groupe de sécurité sans aucune intervention humaine
manuelle.
Contrôle des connaissances (Knowledge Check)
La validation de ce module nécessite de maîtriser :
● La différence entre la phase de découverte (identifier l'attaque grâce à GuardDuty/Security Hub) et la
phase de résolution (contenir la menace grâce à Lambda).
● La raison pour laquelle on privilégie la mise en quarantaine réseau d'une instance EC2 via les Security
Groups plutôt que son arrêt immédiat lors d'une analyse forensics.
● Le fonctionnement du couplage entre AWS Config et AWS Lambda pour appliquer une gouvernance de
sécurité continue et automatisée.

Module 8 : Transition vers la certification (Bridging to

Certification)
1. Objectifs de la Certification AWS de Sécurité
L'objectif de ce module est de faire la transition entre les connaissances théoriques et pratiques acquises
durant le cours et les exigences de l'examen de certification AWS Certified Security - Specialty (SCS-C02).

Cette certification valide votre capacité technique à concevoir, déployer et administrer des solutions de
sécurité complexes sur le cloud AWS. Elle atteste de votre expertise dans la sécurisation des charges de
travail, la conformité réglementaire, le chiffrement des données et la gestion avancée des incidents.

2. Guide d'Analyse des Domaines d'Examen

L'examen est découpé en 5 domaines de compétences clés, tous abordés à travers les différents modules de
ce cours.

Domaine 1 : Threat Detection and Incident Response (Détection des menaces et réponse aux
incidents) — 22%
● Concepts clés à réviser :
○ La mise en place de plans de réponse automatisés avec Systems Manager Incident Manager.
○ La détection comportementale et les alertes générées par Amazon GuardDuty.
○ Le fonctionnement des enquêtes sur la cause racine des vulnérabilités avec Amazon Detective.
○ Le processus forensic sur EC2 : isolation réseau (remplacement du Security Group par un groupe
restrictif "quarantaine"), création d'un instantané EBS pour analyse légale, préservation de la
mémoire volatile (RAM) en évitant l'arrêt immédiat de l'instance.
Domaine 2 : Security Logging and Monitoring (Journalisation et surveillance de la sécurité) —
22%
● Concepts clés à réviser :
○ La configuration multi-région et multi-comptes d'AWS CloudTrail.
○ La sécurisation des fichiers journaux (chiffrement KMS, validation d'intégrité via signatures
numériques, protection d'écriture WORM avec S3 Object Lock).
○ L'analyse en temps réel et la mise en place d'alertes via des filtres de métriques et alarmes Amazon
CloudWatch couplés à des rubriques Amazon SNS.
○ L'agrégation des alertes et l'analyse de conformité avec AWS Security Hub et AWS Config.
Domaine 3 : Infrastructure Security (Sécurité de l'infrastructure) — 20%
● Concepts clés à réviser :
○ La conception de réseaux VPC sécurisés : isolation des sous-réseaux (publics vs privés),
acheminement du trafic via les tables de routage, passerelles Internet et NAT.
 ○ La défense en profondeur au niveau réseau : l'association intelligente des groupes de sécurité
(Stateful, niveau instance, autorisations uniquement) et des Network ACLs (Stateless, niveau sous-
réseau, règles ordonnées d'autorisation et d'interdiction).
○ La protection contre les attaques applicatives et DDoS à l'aide d'AWS WAF (Web Application
Firewall) et d'AWS Shield (Standard et Advanced).
○ L'accès d'administration à distance sécurisé et audité sans clés SSH statiques via SSM Session
Manager.
Domaine 4 : Identity and Access Management (Gestion des identités et des accès) — 22%
● Concepts clés à réviser :
○ L'implémentation du principe du moindre privilège à l'aide de politiques IAM basées sur l'identité,
politiques basées sur les ressources (S3 Bucket Policies, KMS Key Policies) et barrières de
permissions.
○ La logique d'évaluation des politiques AWS : la priorité absolue accordée à l'instruction d'interdiction
explicite (Explicit Deny) sur toute règle d'autorisation (Allow).
○ L'utilisation d'identifiants temporaires et de rôles IAM pour les applications et ressources (profils
d'instance EC2).
○ La gouvernance multi-comptes via AWS Organizations et les Service Control Policies (SCPs) pour
interdire globalement des services ou des actions.
○ Les solutions de fédération d'identités et d'authentification unique d'entreprise (AWS IAM Identity
Center).
Domaine 5 : Data Protection (Protection des données) — 14%
● Concepts clés à réviser :
○ Le cycle de vie et la gestion des clés cryptographiques avec AWS Key Management Service (AWS
KMS) (clés gérées par AWS vs clés gérées par le client, rotation automatique des clés, politiques de
clés).
○ La différence entre le chiffrement côté serveur (SSE-S3, SSE-KMS, SSE-C) et le chiffrement côté
client (CSE).
○ L'obligation de configurer des politiques de clés de chiffrement strictes pour autoriser l'accès aux
données chiffrées (l'accès aux données dans un compartiment S3 chiffré par KMS exige à la fois les
autorisations S3 et les autorisations kms:Decrypt sur la clé KMS).
○ L'application de politiques HTTPS uniquement pour les données en transit via les conditions S3
(aws:SecureTransport).
○ La détection automatique de données sensibles et de conformité avec Amazon Macie, et la gestion
sécurisée des secrets d'API via AWS Secrets Manager.

3. Conseils Stratégiques pour l'Examen

● Comprendre le Modèle de Questions : L'examen SCS-C02 comporte 65 questions (choix multiples et
réponses multiples) à compléter en 170 minutes.
● Lisez attentivement l'énoncé du problème : Repérez les mots-clés stratégiques tels que "le plus
sécurisé", "au moindre coût", "avec le moins d'effort d'administration" ou "automatique". Une solution
techniquement viable peut être éliminée si elle n'est pas optimale financièrement ou si elle exige trop de
développement personnalisé.
● Maîtrisez le principe de moindre privilège : De nombreuses questions décrivent un cas où un
utilisateur ou un service n'arrive pas à accéder à une ressource. Vous devrez diagnostiquer quelle
politique bloque l'accès (politique IAM, politique de compartiment S3, politique de clé KMS, ou SCP
d'Organization).
● Méthode par Élimination : Identifiez et éliminez immédiatement les options qui violent les bonnes
pratiques de sécurité AWS (par exemple, le stockage de clés d'accès IAM statiques dans du code
 applicatif, ou l'ouverture du port SSH 22 à tout le monde [Link]/0 pour résoudre un problème
d'administration).
● Ressources recommandées pour parfaire votre préparation :
○ AWS Ramp-Up Guide: Security (parcours officiel d'apprentissage AWS).
○ AWS Security Best Practices (Livre blanc officiel).
○ AWS KMS Best Practices (Livre blanc officiel).
○ La réalisation approfondie de questions blanches officielles sur le portail AWS Skill Builder.