Amazon DOP-C02: Sécurité, conformité et gouvernance — Guide d'étude

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

Fait partie du AWS DevOps Engineer Professional DOP-C02 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Amazon, ou passez des tests chronométrés sur ExamRoll.io.

Vue d’ensemble

La sécurité, la conformité et la gouvernance sur AWS reposent sur des contrôles déterministes qui s’étendent à travers les comptes et les Régions sans ralentir la livraison. Une conception robuste superpose des contrôles d’identité (IAM, limites de permissions et politiques de contrôle de service), une gouvernance multi-comptes (AWS Organizations et Control Tower), une évaluation et une remédiation continues (AWS Config), la détection des menaces (Security Hub, GuardDuty, Inspector), l’hygiène des secrets, le chiffrement avec AWS KMS et l’isolation réseau (groupes de sécurité VPC, NACL, points de terminaison et PrivateLink). L’objectif est de minimiser le rayon d’impact, de prouver la conformité en continu, et d’automatiser la prévention et la remédiation tout en préservant le moindre privilège et l’autonomie des développeurs.

Identité, politiques et gouvernance multi-comptes

Les rôles IAM, les politiques, les limites de permissions et les SCP fonctionnent ensemble pour former l’ensemble des permissions effectives. Les politiques basées sur l’identité d’un rôle IAM définissent les actions autorisées ; la politique d’approbation du rôle définit qui peut l’assumer. Les limites de permissions plafonnent ce qu’un principal peut faire, indépendamment de ce que disent les politiques d’identité. Les SCP dans AWS Organizations fixent le maximum absolu pour tout principal dans un compte membre (y compris l’utilisateur root). Les politiques basées sur les ressources (pour S3, KMS, Secrets Manager, etc.) peuvent autoriser un accès inter-comptes, mais elles ne peuvent pas non plus dépasser les limites imposées par les SCP ou les limites de permissions. La permission effective est l’intersection de : politiques d’identité ∩ limite de permissions ∩ politiques de session (si présentes) ∩ politique de ressource (si applicable) ∩ SCP, tout Deny explicite ayant la priorité.

Utilisez les limites de permissions pour permettre un libre-service sécurisé dans un seul compte. Par exemple, un pipeline de distribution pour développeurs peut créer des rôles uniquement s’il attache une limite qui refuse iam:PassRole sauf pour des motifs spécifiques, refuse kms:Decrypt sur des clés sensibles, et plafonne les types d’instance EC2. Les limites ne peuvent être attachées que par des principaux qui possèdent déjà iam:PutRolePermissionsBoundary ; protégez ce droit de manière stricte.

Les SCP sont des garde-fous à l’échelle de l’organisation. Les garde-fous courants incluent l’interdiction de désactiver AWS Config ou CloudTrail, l’empêchement des invitations externes à l’organisation, le refus des modifications de l’administrateur délégué d’IAM Identity Center et la restriction des Régions. Préférez les modèles d’autorisation explicite par exception avec des conditions (par exemple, autoriser les modifications par un rôle d’administration central) pour minimiser les frictions. Autorisez toujours la création et l’utilisation des rôles liés à un service nécessaires (par exemple, pour GuardDuty, Inspector, Config), sinon vos SCP bloqueront par inadvertance la configuration des services.

AWS Organizations fournit des unités d’organisation (OU) hiérarchiques pour séparer les environnements (par exemple, Sandbox, Dev, Prod), les types de charges de travail et les voies d’exception. Héritez des SCP des OU parentes pour éviter la dérive des politiques. Utilisez la distribution de comptes pour standardiser la configuration des comptes : Account Factory d’AWS Control Tower (console) ou Account Factory for Terraform (AFT) pour l’intégrer dans le CI/CD. AFT ajoute des workflows de type GitOps, la détection de dérive et des feature flags (par exemple, le provisionnement du support Enterprise), et s’adapte à des centaines de comptes avec des garde-fous de base cohérents.

AWS Control Tower automatise une landing zone avec des garde-fous prescriptifs. Les garde-fous préventifs sont des SCP que Control Tower gère ; les garde-fous détectifs sont des règles AWS Config qu’il déploie. Control Tower intègre IAM Identity Center pour le SSO et les ensembles de permissions. Utilisez des ensembles de permissions basés sur l’ABAC avec des attributs pour le contrôle d’accès afin de limiter la portée des actions par aws:PrincipalTag ou des attributs d’identité. Étendez la base avec Customizations for AWS Control Tower (CfCT) pour déployer automatiquement des packs CloudFormation, SCP et Config par OU/compte. Conservez des OU d’exception pour héberger les charges de travail nécessitant des politiques sur mesure sans affaiblir les garde-fous globaux.

Conformité continue et remédiation automatisée

Activez AWS Config à l’échelle de l’organisation depuis un compte administrateur délégué. Activez l’enregistrement pour toutes les ressources dans toutes les Régions et agrégez la configuration à travers l’Organisation avec un agrégateur d’organisation. Utilisez des règles gérées pour les contrôles courants (par exemple, ebs-encryption-by-default, restricted-ssh, s3-bucket-level-public-access-prohibited) et créez des règles personnalisées basées sur Lambda pour une logique sur mesure (par exemple, vérifier la cadence de rotation des clés KMS par rapport à une politique de 90 jours ou imposer des balises et des valeurs par défaut). Les packs de conformité regroupent les règles, les paramètres et la remédiation en ensembles versionnés et déployables par OU ; maintenez-les dans un système de contrôle de version et déployez-les via des StackSets ou CfCT pour la cohérence et l’auditabilité.

La remédiation automatisée boucle la boucle. Associez l’évaluation non conforme de chaque règle à un runbook SSM Automation qui applique la ligne de base : attacher un profil d’instance par défaut, appliquer une balise avec une valeur par défaut, activer/désactiver le blocage de l’accès public S3, ou redémarrer une instance EC2 pour maintenance. Utilisez des documents paramétrés et des entrées dynamiques (par exemple, à partir du résultat de Config) pour garder les runbooks génériques. Pour les ressources à haut risque, configurez la remédiation pour qu’elle s’exécute automatiquement ; pour les actions sensibles, exigez une approbation de changement ou une invocation manuelle via EventBridge et ChatOps. Protégez Config lui-même avec des SCP qui refusent d’arrêter l’enregistreur ou de supprimer les canaux de livraison, sauf par un administrateur central.

Firewall Manager complète cette couche pour une politique en tant que service à travers les comptes, en utilisant Organizations. Déléguez un administrateur central et créez des politiques pour les associations de web ACL WAF sur les ALB/API Gateway exposés sur Internet, l’audit et le nettoyage des groupes de sécurité VPC, ou la propagation des règles DNS Firewall. Cela déplace l’application future de la détection/remédiation vers la prévention.

Détection des menaces, hygiène des secrets et gestion des vulnérabilités

Security Hub sert de tableau de bord centralisé pour les résultats (findings) à travers les comptes et les Régions. Activez-le avec un administrateur délégué, agrégez les résultats et activez les standards pertinents (AWS Foundational Security Best Practices, CIS, PCI DSS le cas échéant). Les résultats sont acheminés au format ASFF (AWS Security Finding Format), normalisant les entrées provenant de GuardDuty, Inspector, IAM Access Analyzer, Config, Macie et des outils partenaires. Configurez des modèles (patterns) EventBridge pour router les résultats critiques vers des automatisations de remédiation (SSM Automation, Lambda) et des notifications (SNS, chat).

GuardDuty fournit une détection de menaces gérée sans vous obliger à gérer les pipelines de logs du plan de données. Il analyse les événements de gestion et de données de CloudTrail, les logs de flux VPC (VPC Flow Logs), les logs de requêtes DNS de Route 53 Resolver et les logs d’audit d’EKS pour détecter les comportements anormaux, l’exfiltration d’identifiants, le minage de cryptomonnaies, l’exfiltration DNS, et plus encore. Activez la protection contre les malwares (Malware Protection) pour l’analyse de S3 et EC2/EBS en cas d’activité suspecte. Utilisez l’activation automatique à l’échelle de l’organisation et archivez systématiquement les résultats à faible signal avec des règles de suppression (suppression rules) pour vous concentrer sur les actions à entreprendre.

Amazon Inspector évalue en continu les instances EC2 (via l’agent SSM) pour les CVE de paquets, les images de conteneurs ECR pour les vulnérabilités avant le déploiement, et les fonctions Lambda pour les CVE des paquets de code. Inspector exige que les instances EC2 aient l’agent SSM installé, que le profil d’instance autorise les permissions SSM et que le trafic sortant (egress) vers les points de terminaison (endpoints) SSM/KMS soit possible (via des VPC endpoints si l’accès à Internet est restreint). Configurez Inspector pour envoyer les résultats à Security Hub et déclencher des flux de travail de correctifs avec Systems Manager Patch Manager ou une remédiation basée sur des runbooks. Utilisez des balises (tags) pour définir le périmètre des ressources à analyser et pour séparer les charges de travail de bac à sable (sandbox) de celles qui sont réglementées.

Secrets Manager centralise le stockage des secrets, leur rotation et l’accès inter-comptes avec une forte auditabilité. Préférez Secrets Manager aux banques de paramètres (parameter stores) pour les identifiants qui nécessitent une rotation, en tirant parti de la rotation intégrée pour RDS/Aurora ou de la rotation basée sur Lambda pour les systèmes externes. Les étiquettes de préproduction (staging labels) (AWSCURRENT, AWSPREVIOUS) permettent une rotation sans interruption de service. Exécutez les fonctions Lambda de rotation dans des VPC avec les points de terminaison nécessaires (Secrets Manager, RDS, KMS) et restreignez le trafic sortant (egress). Pour une consommation inter-comptes, attachez une politique basée sur les ressources qui accorde aux principaux (principals) d’autres comptes l’autorisation GetSecretValue ; assurez-vous que la politique de la clé KMS (CMK) du secret autorise les principaux du consommateur à déchiffrer et, si nécessaire, à créer des autorisations (grants). Pour la reprise après sinistre ou les contrôles de localité, répliquez les secrets entre les Régions et alignez les fenêtres de rotation.

Protection des données et sécurité réseau

Concevez le chiffrement à l’aide de KMS avec des politiques de clé explicites. Les politiques de clé, et pas seulement les politiques IAM, autorisent en fin de compte les principaux (principals) à effectuer des opérations cryptographiques sur une CMK. Adoptez un modèle de politique de clé basé sur les rôles et le moindre privilège : déléguez l’administration à un rôle d’administrateur KMS central ; accordez des droits d’utilisation de manière restreinte aux rôles des charges de travail (workloads) ; interdisez le caractère générique kms:* pour éviter une élévation accidentelle des privilèges. Utilisez des clés de condition (kms:EncryptionContext:*) pour lier le déchiffrement aux contextes attendus. Les clés multi-régions permettent un chiffrement actif-actif où les données sont répliquées entre les régions.

Les autorisations (grants) sont l’outil approprié pour déléguer une utilisation de clé temporaire ou à portée très limitée sans modifier la politique de clé, et elles sont requises pour certains flux de services (par ex., EC2 Auto Scaling utilisant des modèles de lancement chiffrés, utilisation d’AMI inter-comptes). Pour permettre à un autre compte de créer des autorisations (grants), la politique de clé doit autoriser kms:CreateGrant aux principaux de ce compte ; le bénéficiaire de l’autorisation (grantee) doit fournir un jeton d’autorisation (grant token) pour une utilisation immédiate dans le même chemin d’appel. Pour les AMI chiffrées inter-comptes, copiez et chiffrez l’AMI avec une CMK, partagez l’AMI, autorisez le compte cible à créer des autorisations (grants) sur la CMK, et faites en sorte que le rôle lié au service (service-linked role) cible reçoive une autorisation (grant).

Le chiffrement d’enveloppe (envelope encryption) est le modèle par défaut : générez une clé de données avec KMS, chiffrez les données localement avec la clé de données en clair, puis ne stockez que le texte chiffré (ciphertext) et la clé de données chiffrée. À la lecture, appelez KMS Decrypt pour récupérer la clé de données en clair en mémoire. Cela minimise les appels à KMS pour les charges utiles volumineuses (payloads) et limite l’exposition de la clé en clair. Là où c’est pris en charge, utilisez le chiffrement côté serveur géré par le service SSE-KMS (S3, EBS, RDS) pour la simplicité opérationnelle, mais continuez d’aligner les politiques de clé pour les producteurs/consommateurs inter-comptes.

La sécurité du VPC commence par des groupes de sécurité (security groups) appliquant le moindre privilège. Les groupes de sécurité sont avec état (stateful) ; le trafic de retour est implicitement autorisé. Préférez les références de groupes de sécurité aux règles basées sur des blocs CIDR pour éviter les listes d’autorisation d’IP fragiles et pour conserver l’intention dans le code d’infrastructure. Les autorisations de sortie par défaut sont risquées ; restreignez explicitement le trafic sortant (egress) aux destinations requises et utilisez des points de terminaison VPC (VPC endpoints) pour l’accès aux services AWS. Les NACL sont sans état (stateless) et évaluées en premier ; conservez-les comme des contrôles généraux au niveau du sous-réseau avec des retours explicites pour les ports éphémères uniquement lorsque vous devez mettre en œuvre une frontière supplémentaire ou répondre à des exigences réglementaires ; sinon, privilégiez les groupes de sécurité pour la facilité de gestion.

Éliminez les dépendances à Internet en utilisant des points de terminaison VPC. Les points de terminaison de passerelle (Gateway endpoints) (S3, DynamoDB) acheminent le trafic en privé sur le réseau AWS ; associez une politique de point de terminaison pour restreindre les compartiments (buckets) ou les tables accessibles. Les points de terminaison d’interface (Interface endpoints) (AWS PrivateLink) exposent les services AWS (Secrets Manager, KMS, SSM, ECR, CloudWatch) via des adresses IP privées ; déployez-les dans des sous-réseaux avec les bons groupes de sécurité et activez le DNS privé pour que les noms de service standard se résolvent en adresses privées. Pour les microservices producteur-consommateur répartis sur plusieurs comptes/VPC, publiez un service de point de terminaison (endpoint service) adossé à un NLB et demandez aux consommateurs de créer des points de terminaison d’interface vers celui-ci via PrivateLink, évitant ainsi les appairages (peering) ou les passerelles de transit (transit gateways) et maintenant le trafic hors de l’Internet public. Combinez ces contrôles avec des sous-réseaux sans NAT ni IGW, et une inspection centralisée du trafic sortant (egress) là où un accès à Internet est requis.

Scénario de problème pratique

Expedia Group s’étend à des centaines de comptes AWS dans plusieurs régions et doit appliquer une base de sécurité stricte : pas de trafic sortant vers Internet pour les charges de travail, remédiation automatisée des erreurs de configuration, détection centralisée des menaces, rotation des secrets et partage inter-comptes contrôlé d’AMI chiffrées pour des images de référence standardisées (golden images).

Établir une gouvernance multi-comptes avec AWS Organizations et AWS Control Tower

Action : Créer des unités d’organisation (OU) pour Sandbox, Dev, Prod et Security. Déployer Control Tower pour établir la landing zone, activer les garde-fous (guardrails) obligatoires et intégrer IAM Identity Center. Utiliser Account Factory for Terraform (AFT) pour distribuer les comptes via une approche GitOps.
Pourquoi : Control Tower fournit des garde-fous clés en main et appliqués en continu (SCP et règles Config). AFT standardise la création de comptes à grande échelle et codifie les bases de référence dans un système de contrôle de version.

Rédiger des SCP pour appliquer des garde-fous globaux avec des exceptions

Action : Attacher des SCP qui interdisent la désactivation de CloudTrail et d’AWS Config, restreignent les régions et empêchent les ACL publiques sur S3. Inclure des exceptions basées sur des conditions pour un rôle d’administrateur de sécurité dans l’OU Security. Autoriser la création/l’utilisation des rôles liés à un service (service-linked roles) requis.
Pourquoi : Les SCP plafonnent les privilèges pour tous les principaux, y compris le compte root, empêchant ainsi la dérive de configuration tout en autorisant des exceptions contrôlées pour les opérations centrales.

Déployer des packs de conformité (conformance packs) Config avec remédiation automatisée

Action : Depuis le compte d’administrateur délégué de la sécurité, activer AWS Config à l’échelle de l’organisation et créer un agrégateur. Déployer un pack de conformité qui impose le chiffrement EBS par défaut, un accès SSH restreint, des balises (tags) obligatoires avec des valeurs par défaut, et un WAF requis sur les points d’entrée publics. Mapper chaque règle à des documents SSM Automation pour des corrections automatiques (par ex., attacher le profil d’instance par défaut, définir les balises manquantes sur ‘weekly’).
Pourquoi : Les packs de conformité fournissent une politique sous forme de code (policy-as-code) cohérente et auditable avec une auto-remédiation qui maintient les environnements dans un état conforme sans générer une surcharge de tickets.

Centraliser la détection avec Security Hub, GuardDuty et Inspector

Action : Activer GuardDuty et Inspector à l’échelle de l’organisation avec un administrateur délégué. Activer les standards de Security Hub (AWS FSBP et CIS) et agréger les résultats (findings). Créer des règles EventBridge pour acheminer les résultats de haute sévérité vers des runbooks SSM Automation et un sujet (topic) SNS pour l’équipe d’astreinte.
Pourquoi : La détection gérée et l’évaluation des vulnérabilités offrent une couverture continue avec une surcharge opérationnelle minimale, et Security Hub consolide les signaux pour un tri et une réponse plus rapides.

Appliquer le moindre privilège IAM avec des périmètres d’autorisations (permission boundaries) et l’ABAC

Action : Dans les comptes provisionnés par AFT, exiger que les rôles créés par les développeurs attachent un périmètre d’autorisations qui refuse iam:PassRole sauf à des rôles sélectionnés et qui limite les API à fort impact. Utiliser les ensembles d’autorisations (permission sets) de IAM Identity Center avec l’ABAC pour définir la portée des actions en fonction des balises d’équipe.
Pourquoi : Les périmètres d’autorisations permettent un libre-service sécurisé tout en empêchant l’élévation de privilèges ; l’ABAC réduit la prolifération des politiques et reste aligné sur les attributs d’identité.

Renforcer les chemins réseau avec les points de terminaison VPC et PrivateLink

Action : Supprimer les IGW/NAT des sous-réseaux applicatifs. Créer des points de terminaison d’interface pour KMS, Secrets Manager, SSM, ECR, CloudWatch, et des points de terminaison de passerelle pour S3/DynamoDB avec des politiques de point de terminaison restrictives. Publier les services de plateforme internes via des NLB adossés à PrivateLink pour une consommation inter-comptes.
Pourquoi : La connectivité privée élimine l’exposition à Internet et garantit que les services restent joignables dans des environnements verrouillés.

Mettre en œuvre une stratégie de clés KMS avec des autorisations (grants) pour les AMI inter-comptes

Action : Créer des CMK par environnement avec des politiques de clé à portée de rôle. Dans le compte de création d’images, chiffrer les AMI de référence (golden AMIs) et les partager. Mettre à jour la politique de la CMK pour permettre aux comptes cibles de créer des autorisations (grants), puis créer des autorisations pour les rôles liés à un service dans ces comptes cibles.
Pourquoi : Les autorisations (grants) fournissent une délégation à portée limitée et auditable sans avoir à modifier les politiques de clé pour chaque consommateur, permettant à Auto Scaling de lancer des instances à partir d’AMI chiffrées entre les comptes.

Standardiser la rotation des secrets et l’accès inter-comptes

Action : Stocker les identifiants de base de données et d’API dans Secrets Manager. Mettre en œuvre la rotation par Lambda pour les cibles non-RDS et activer la rotation intégrée pour RDS. Pour les secrets de plateforme partagés, attacher des politiques basées sur les ressources accordant GetSecretValue aux rôles consommateurs dans d’autres comptes et s’assurer que les politiques de CMK autorisent le déchiffrement. Placer les fonctions Lambda de rotation dans des VPC avec les points de terminaison nécessaires.
Pourquoi : La rotation automatisée réduit le risque lié aux identifiants ; les politiques basées sur les ressources alignées avec KMS permettent une consommation inter-comptes sécurisée tout en préservant le moindre privilège et les pistes d’audit.

Cette architecture offre à Expedia Group des garde-fous applicables, une conformité démontrable, des corrections automatisées et des chemins d’accès aux données étroitement contrôlés, tout en préservant la vélocité des développeurs grâce à un libre-service sécurisé et une connectivité privée.

← Surveillance · Tous les domaines · Conteneurs et opérations serverless →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →