Amazon SCS-C02: Gouvernance, configuration et automatisation — Guide d'étude

By Laurynas Brazys · 24 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

Fait partie du AWS Security Specialty SCS-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.

Service Control Policies et garde-fous au niveau de l’organisation

Les Service Control Policies (SCP) forment la limite la plus externe de ce que tout principal peut faire au sein d’une AWS Organization. Une SCP n’est pas une politique IAM — elle n’accorde aucune autorisation, elle définit seulement les permissions maximales disponibles pour les comptes sous une UO ou pour l’ensemble de l’organisation. Un Allow dans une politique IAM, une politique de ressource ou une limite de permissions (permissions boundary) est complètement inerte si une SCP refuse l’action. C’est précisément cette asymétrie qui fait des SCP l’outil approprié pour les garde-fous à l’échelle de l’organisation : restrictions de Région, services interdits, protection des rôles IAM gérés de manière centralisée et application du chiffrement lors de la création de ressources.

Une SCP canonique refusant la création de tables DynamoDB et de compartiments S3 non chiffrés ressemble à ceci :

Version: "2012-10-17"
Statement:
  - Sid: DenyUnencryptedS3
    Effect: Deny
    Action: s3:CreateBucket
    Resource: "*"
    Condition:
      StringNotEquals:
        s3:x-amz-server-side-encryption-aws-kms-key-id: !Ref CmkArn
  - Sid: DenyUnencryptedDdb
    Effect: Deny
    Action: dynamodb:CreateTable
    Resource: "*"
    Condition:
      "Null":
        dynamodb:SSESpecificationEnabled: "true"

Un piège courant consiste à essayer d’appliquer des règles comme « personne dans l’organisation ne peut utiliser us-east-2 » ou « personne ne peut désactiver CloudTrail » via des politiques IAM attachées dans chaque compte. Même avec une limite de permissions et un alignement des politiques d’identité, un administrateur local peut s’octroyer une porte de sortie. Seule une SCP appliquée à la racine ou à une UO est fiable, car elle contraint même l’utilisateur root des comptes membres (à l’exception d’une poignée d’actions non restreignables).

Les SCP devraient également protéger les rôles d’accès d’urgence (break-glass) et d’administration déléguée : ajoutez un Deny explicite sur toute action ciblant un rôle tel que OrganizationAccountAccessRole ou SecurityAudit, à moins que l’ aws:PrincipalArn de l’appelant ne corresponde à une liste approuvée.

AWS Config, packs de conformité et application multi-comptes

AWS Config fournit la couche d’évaluation continue qui complète les SCP (qui préviennent) par la détection (qui observe et signale les dérives). Un pack de conformité (conformance pack) est un ensemble de règles Config — à la fois des règles gérées comme s3-bucket-server-side-encryption-enabled et des règles personnalisées basées sur Lambda ou Guard — empaqueté sous la forme d’un seul artefact YAML déployable avec des actions de remédiation optionnelles.

Pour déployer une base de référence standard à l’échelle de l’organisation, deux mécanismes sont combinés :

• Des CloudFormation StackSets depuis le compte de gestion avec des permissions gérées par le service et AutoDeployment: Enabled pour que tout nouveau compte rejoignant l’organisation reçoive automatiquement une pile qui active l’enregistreur (recorder) et le canal de livraison (delivery channel) de Config. Cela résout le problème d’amorçage : un pack de conformité ne peut pas évaluer un compte où Config n’est pas activé.

• Des packs de conformité déployés depuis le compte administrateur délégué (par exemple security-01) en utilisant PutOrganizationConformancePack. Cela propage un ensemble de règles cohérent à chaque compte actuel et futur sans avoir à intervenir manuellement sur chaque compte.

Le modèle administrateur délégué + agrégateur est important : il permet à l’équipe de sécurité de voir la conformité de tous les comptes en un seul endroit tout en autorisant les équipes applicatives à ajouter leurs propres règles localement. Déployer les mêmes règles directement depuis le compte de gestion fonctionnerait, mais cela viole le principe du moindre privilège et empêche les audits de séparation des tâches.

CloudFormation Guard, StackSets et Service Catalog

La prévention doit être décalée vers la gauche (shift left). CloudFormation Guard (cfn-guard) est un moteur de politique en tant que code (policy-as-code) qui analyse les modèles CloudFormation (ou tout JSON/YAML) et les évalue par rapport à des règles déclaratives avant le déploiement. Une règle Guard ressemble à ceci :

rule s3_encrypted {
  Resources.*[ Type == "AWS::S3::Bucket" ] {
    Properties.BucketEncryption exists
    Properties.BucketEncryption.ServerSideEncryptionConfiguration[*] {
      ServerSideEncryptionByDefault.SSEAlgorithm == "aws:kms"
    }
  }
}

Intégrer cela dans une étape de CI/CD — généralement en tant qu’étape de conteneur Docker qui exécute cfn-guard validate -r rules.guard -d template.yaml — fait échouer le pipeline avant la création de toute ressource non conforme. En cas de violation, le pipeline publie sur un sujet SNS auquel l’équipe de sécurité est abonnée, leur donnant de la visibilité sans devenir un goulot d’étranglement pour les approbations manuelles. Se fier uniquement aux StackSets ou à la revue des jeux de modifications (change sets) CloudFormation pour notifier l’équipe de sécurité est un piège : aucun de ces services n’émet de résultats de conformité par ressource, et au moment où une pile est créée, la ressource existe déjà dans le compte.

Service Catalog complète Guard pour le dernier kilomètre. Au lieu de laisser les développeurs écrire du CloudFormation arbitraire, l’équipe plateforme publie des produits validés (bases de VPC, modèles RDS, clusters EKS) en tant que portefeuilles Service Catalog partagés entre les comptes via AWS RAM. Les développeurs les lancent avec des paramètres contraints, et un rôle IAM de contrainte de lancement (launch constraint) provisionne les ressources avec des permissions élevées que le développeur ne détient pas personnellement. Cela offre un modèle de déploiement en libre-service et auditable où le modèle sous-jacent a déjà passé les vérifications de Guard.

Les StackSets eux-mêmes nécessitent une configuration correcte : utilisez le modèle de permission SERVICE_MANAGED lors du déploiement depuis le compte de gestion de l’organisation, activez l’accès de confiance pour CloudFormation dans Organizations, et configurez les rôles d’exécution avec soin. La paire AdministrationRoleARN/ExecutionRoleName (en mode autogéré) ou les rôles liés à un service (en mode géré par le service) doivent avoir la permission iam:PassRole accordée au rôle de service CloudFormation qui crée réellement les ressources. Oublier d’attacher un rôle de service CloudFormation et se fier plutôt aux informations d’identification de l’utilisateur qui déploie conduit à des erreurs intermittentes AccessDenied sur iam:PassRole — une cause fréquente d’échec des opérations de StackSet. Le modèle correct est d’utiliser un rôle de service dédié par pile avec uniquement les permissions nécessaires pour créer les types de ressources déclarés.

Pipelines de remédiation automatisée

Lorsque Config détecte une non-conformité, la remédiation doit être automatique pour tout ce qui peut être corrigé de manière sûre et autonome. Le flux d’événements est le suivant :

• Config publie un événement Compliance Change sur le bus d’événements par défaut.

• Une règle EventBridge filtre les résultats NON_COMPLIANT sur des règles spécifiques et cible soit un document Systems Manager Automation (pour les correctifs simples et idempotents comme l’activation du chiffrement S3), une fonction Lambda (pour les correctifs au niveau de l’API), soit une machine d’état Step Functions (pour les workflows en plusieurs étapes nécessitant des approbations, des tentatives ou une orchestration inter-services).

Par exemple, si la règle s3-bucket-public-read-prohibited se déclenche, un runbook SSM Automation AWS-DisableS3BucketPublicReadWrite y remédie. Pour des flux plus complexes — par exemple, une politique de clé KMS qui dérive et doit être réconciliée tout en notifiant l’équipe propriétaire — Step Functions coordonne les actions : lire la politique actuelle, la comparer à la version de référence (« golden version »), appeler kms:PutKeyPolicy, puis publier sur SNS. Stocker la logique de remédiation dans Step Functions plutôt que dans une seule fonction Lambda offre une observabilité sur chaque étape et des sémantiques de nouvelle tentative claires.

IAM Access Analyzer et validation de politique

IAM Access Analyzer répond à deux questions distinctes. Premièrement, les analyseurs d’accès externe identifient les ressources (S3, KMS, rôles IAM, Lambda, SQS, Secrets Manager) dont les politiques accordent l’accès à des principaux en dehors d’une zone de confiance définie — soit le compte, soit l’organisation. Activez l’analyseur au niveau de l’organisation depuis le compte administrateur délégué afin que les résultats soient agrégés de manière centralisée.

Deuxièmement, la validation de politique et la génération de politique d’Access Analyzer s’exécutent pendant la phase de création. aws accessanalyzer validate-policy renvoie des avertissements de sécurité, des erreurs et des suggestions (par exemple, en signalant un Resource: "*" trop large combiné à des actions sensibles). Intégrez cette commande à la même étape CI/CD que cfn-guard afin que les politiques IAM intégrées dans CloudFormation soient vérifiées avant le déploiement. Access Analyzer peut également générer une politique de moindre privilège à partir de l’historique CloudTrail, remplaçant une politique générique (« wildcard ») par les actions exactes qu’un rôle a réellement utilisées — la réponse mécanique à « appliquer le moindre privilège pour l’accès aux données », complétée par une politique de clé KMS délimitée qui n’autorise kms:Decrypt que lorsque le service appelant est S3, DynamoDB, Lambda ou EKS via des conditions kms:ViaService.

Problème pratique : Scénario d’utilisation

Scénario : Meridian Financial gère une AWS Organization multi-comptes qui inclut des comptes de production, de pré-production (« staging »), de bac à sable (« sandbox ») et un compte de sécurité centralisé. Ils déploient des charges de travail avec un mélange de modèles CloudFormation et de modèles créés par les développeurs dans le bac à sable ; la propriété est fédérée entre les équipes, et ils doivent respecter la gouvernance interne pour le chiffrement des données et l’accès au moindre privilège.

Défi : Des développeurs dans le bac à sable ont accidentellement créé des compartiments S3 publics et des politiques IAM trop permissives qui se sont propagées à d’autres comptes, et l’équipe de sécurité manque d’une application et d’une validation de modèles cohérentes et automatisées à travers l’Organisation.

Approche recommandée :

1. Créer des politiques de contrôle de service (SCP) au niveau de l’Organisation pour refuser l’accès public à S3, imposer le chiffrement des compartiments et restreindre les actions IAM privilégiées à la racine de l’Organisation afin de fournir des garde-fous préventifs.
2. Depuis le compte de sécurité central, déployer un agrégateur AWS Config et des Conformance Packs à l’aide de CloudFormation StackSets sur chaque compte et région pour évaluer en continu l’accès public S3, les modèles d’attachement de politiques IAM et la conformité du chiffrement.
3. Intégrer les règles CloudFormation Guard (cfn-guard) dans le pipeline CI/CD (CodePipeline/CodeBuild) et exiger l’utilisation de produits Service Catalog pour l’infrastructure approuvée, afin que les modèles soient validés et que seules les piles conformes puissent être provisionnées.
4. Activer la remédiation automatisée d’AWS Config avec des documents SSM Automation ou des runbooks Lambda pour les résultats à haute priorité (bloquer automatiquement l’accès public S3, corriger les politiques IAM trop larges) et déclencher des workflows supplémentaires via EventBridge.
5. Exécuter IAM Access Analyzer et la validation de politique de manière centralisée, ingérer les résultats dans Security Hub, et automatiser la création de tickets ou les playbooks de remédiation pour les politiques inter-comptes ou trop permissives découvertes.

Justification : Cette approche combine des garde-fous préventifs à l’échelle de l’organisation (SCP), une détection continue (Config/Conformance Packs), une validation des modèles en amont (« shift-left ») (cfn-guard/Service Catalog), et une remédiation automatisée avec IAM Access Analyzer pour appliquer le moindre privilège et atteindre une gouvernance multi-comptes cohérente, conformément aux meilleures pratiques AWS.

AWS Config : Règles d’organisation, agrégateurs et administration déléguée

AWS Config est le fondement de la conformité détective sur AWS. Il enregistre en continu les configurations des ressources et les évalue par rapport à des règles — soit gérées par AWS (par exemple, restricted-ssh, vpc-flow-logs-enabled, encrypted-volumes), soit personnalisées (basées sur Lambda ou Guard). À l’échelle de l’entreprise, trois décisions d’architecture importent plus que les règles elles-mêmes : comment les règles sont déployées, comment les résultats sont agrégés et qui est propriétaire de l’outillage.

Pour les déploiements multi-comptes et multi-régions sous AWS Organizations, le modèle correct consiste à désigner un compte administrateur délégué (généralement le compte de sécurité ou d’audit, et non le compte de gestion) via aws organizations register-delegated-administrator --service-principal=config-multiaccountsetup.amazonaws.com. Depuis ce compte, utilisez PutOrganizationConfigRule ou PutOrganizationConformancePack pour diffuser les règles à chaque compte membre et dans chaque région. Ignorer l’administration déléguée vous oblige à activer Config manuellement dans chaque compte ou à tout exécuter depuis le compte de gestion — cette dernière option enfreint la séparation des tâches et la première n’est pas scalable au-delà d’une poignée de comptes.

Les règles d’organisation poussent une définition de règle unique ; les agrégateurs collectent les évaluations qui en résultent. Créez un agrégateur dans le compte administrateur délégué avec une OrganizationAggregationSource couvrant tous les comptes et toutes les régions. Le tableau de bord de l’agrégateur répond alors à des questions comme « quels VPC à travers 200 comptes n’ont pas de Flow Logs ? » sans avoir à jongler avec des rôles inter-comptes. Notez que les agrégateurs sont en lecture seule : ils font remonter l’état de conformité mais n’effectuent pas eux-mêmes de remédiation.

Packs de conformité pour l’application de lignes de base

Un pack de conformité regroupe des règles Config et leurs actions de remédiation dans un seul modèle YAML. AWS fournit des packs alignés sur des référentiels comme PCI DSS, HIPAA, NIST 800-53 et CIS. Le déploiement d’un pack de conformité d’organisation depuis l’administrateur délégué cible des UO spécifiques — par exemple, en appliquant un pack plus strict à l’UO Prod qu’à l’UO Sandbox. C’est le moyen le plus efficace d’appliquer une ligne de base cohérente sur des centaines de comptes, car un seul appel d’API propage l’ensemble de règles et son câblage de remédiation partout à la fois.

Resources:
  EncryptedVolumesRule:
    Type: AWS::Config::ConfigRule
    Properties:
      ConfigRuleName: encrypted-volumes
      Source:
        Owner: AWS
        SourceIdentifier: ENCRYPTED_VOLUMES
  EncryptedVolumesRemediation:
    Type: AWS::Config::RemediationConfiguration
    Properties:
      ConfigRuleName: encrypted-volumes
      TargetType: SSM_DOCUMENT
      TargetId: AWSConfigRemediation-EncryptS3BucketVolume
      Automatic: true
      MaximumAutomaticAttempts: 3
      RetryAttemptSeconds: 60

Modèles de remédiation automatique

Il existe deux chemins de remédiation canoniques, et le choix entre eux dépend des exigences de latence et de complexité.

Le chemin de remédiation natif à Config utilise AWS::Config::RemediationConfiguration pour invoquer un runbook SSM Automation chaque fois qu’une règle signale l’état NON_COMPLIANT. AWS fournit des runbooks prédéfinis tels que AWS-EnableVPCFlowLogs, AWSConfigRemediation-RemoveUnrestrictedSourceIngressRules et AWSConfigRemediation-EncryptSNSTopic. Ce chemin est déclaratif, s’intègre proprement avec les packs de conformité et est idéal lorsqu’un délai de plusieurs minutes est acceptable.

Le chemin piloté par EventBridge est requis lorsque la latence est importante ou lorsqu’une orchestration personnalisée est nécessaire. Config émet un événement Config Rules Compliance Change à chaque transition d’état. Une règle EventBridge filtre sur detail.newEvaluationResult.complianceType = NON_COMPLIANT et cible une fonction Lambda (ou une Step Function, ou directement un runbook SSM). Comme EventBridge se déclenche quelques secondes après l’évaluation, des fenêtres de remédiation inférieures à la minute deviennent réalisables.

{
  "source": ["aws.config"],
  "detail-type": ["Config Rules Compliance Change"],
  "detail": {
    "configRuleName": ["restricted-ssh"],
    "newEvaluationResult": { "complianceType": ["NON_COMPLIANT"] }
  }
}

Le handler Lambda appelle alors RevokeSecurityGroupIngress sur le SG incriminé. Quel que soit le chemin que vous choisissez, l’automatisation doit assumer un rôle IAM avec les permissions minimales pour modifier la ressource cible. Un mode d’échec fréquent est une règle Config dont l’état de conformité bascule indéfiniment entre NON_COMPLIANT et COMPLIANT parce que le runbook de remédiation rencontre une erreur AccessDenied — Config enregistre l’invocation mais continue silencieusement. Inspectez toujours l’historique d’exécution de SSM Automation et accordez au rôle du runbook les permissions de modification spécifiques dont il a besoin (par exemple, ec2:CreateFlowLogs, iam:PassRole pour le rôle de livraison des flow-logs, et logs:CreateLogGroup).

Systems Manager Automation et Patch Manager

Les runbooks SSM Automation sont le pilier de la remédiation impérative. Ce sont des documents YAML/JSON versionnés décrivant des étapes — appels d’API, approbations, branchements — exécutées par un rôle IAM que vous spécifiez. Au-delà de la remédiation déclenchée par Config, ils exécutent des tâches d’hygiène planifiées : la rotation des clés d’accès, le balisage des volumes EBS non attachés ou la terminaison des instances arrêtées après 30 jours.

Patch Manager est un sous-système de SSM qui maintient les systèmes d’exploitation en conformité avec une ligne de base de correctifs (patch baseline) (un ensemble de correctifs approuvés, de classifications et de filtres de sévérité). Les instances sont regroupées en groupes de correctifs (patch groups) via le tag Patch Group ; une fenêtre de maintenance planifie l’exécution du document AWS-RunPatchBaseline sur ces groupes. L’état de conformité remonte dans Config et Security Hub, bouclant ainsi la boucle entre l’état au niveau de l’OS et le reporting organisationnel.

Service Catalog, CloudFormation StackSets et garde-fous préventifs

La détection et la remédiation sont réactives. Pour prévenir la non-conformité, utilisez des contrôles préventifs :

• Service Catalog publie des modèles CloudFormation organisés et paramétrés en tant que produits. Les développeurs lancent des schémas approuvés (un VPC renforcé, un cluster RDS chiffré) sans avoir besoin d’autorisations IAM pour les services sous-jacents, ce qui applique la séparation des tâches entre l’équipe de la plateforme et les consommateurs.

• CloudFormation StackSets déploie des piles identiques à travers les comptes et les Régions. Avec des autorisations gérées par le service et le ciblage par OU, une seule opération déploie des enregistreurs Config, des rôles IAM ou des détecteurs GuardDuty dans chaque compte de l’organisation, y compris ceux nouvellement créés via le déploiement automatique.

• Les Service Control Policies (SCPs) sont le seul mécanisme qui peut refuser purement et simplement un appel d’API à la frontière de l’organisation. Config et SSM ne peuvent pas empêcher un appel RunInstances qui manque de chiffrement — ils ne peuvent que détecter et corriger après coup. Tenter d’appliquer des interdictions strictes (« pas de compartiments S3 publics, jamais ») uniquement avec des règles Config laisse une fenêtre de temps entre la création de la ressource et sa correction. Associez une règle de détection Config à une SCP telle que le refus de s3:PutBucketPublicAccessBlock pour combler cette lacune.

Reprise après sinistre : Sauvegarde, modèles et contrôle de code source

Atteindre les objectifs RPO/RTO nécessite que les données et les définitions d’infrastructure soient récupérables. AWS Backup centralise les politiques de sauvegarde pour EBS, RDS, DynamoDB, EFS et FSx ; les politiques de sauvegarde de l’organisation appliquent des plans à travers les comptes membres, et les copies inter-Régions et inter-comptes protègent contre la perte d’une Région et la compromission d’un compte. Le RPO est défini par la fréquence des sauvegardes ; le RTO dépend des mécanismes de restauration (une restauration PITR de DynamoDB prend quelques minutes ; une restauration de snapshot RDS entre Régions peut prendre une heure).

La récupération de l’infrastructure repose sur des modèles CloudFormation stockés dans CodeCommit (ou un autre fournisseur Git) comme source unique de vérité. Le redéploiement d’un StackSet à partir de modèles versionnés reconstruit les VPC, IAM et les piles applicatives dans une Région de reprise en quelques minutes. Conserver les modèles uniquement dans la console — sans aucun dépôt — rend le RTO imprévisible car il n’y a pas d’artefact reproductible.

Analyse des pièges

Trois idées fausses conduisent systématiquement à de mauvaises réponses. Premièrement, considérer Config comme un contrôle préventif : il évalue après que CloudTrail a enregistré le changement, donc les véritables interdictions nécessitent des SCP. Deuxièmement, configurer la remédiation sans un rôle IAM avec une portée adéquate — le document SSM existe et la règle Config se déclenche, mais le runbook échoue silencieusement en raison d’erreurs de permission. Troisièmement, exécuter des services à l’échelle de l’organisation depuis le compte de gestion au lieu d’enregistrer un administrateur délégué, ce qui force une activation manuelle par compte et empêche les agrégateurs à l’échelle de l’organisation de fonctionner correctement.

Problème pratique : Scénario d’utilisation

Scénario : Meridian Financial gère un environnement AWS multi-comptes avec des comptes de production, de développement et de sécurité distincts sous AWS Organizations. L’équipe de sécurité doit prouver la conformité continue avec les contrôles internes et les régulateurs tout en gérant des centaines d’instances EC2, de compartiments S3 et de fonctions Lambda à travers les régions.

Défi : Un audit récent a révélé des instances EC2 sans correctifs, des compartiments S3 publics et une application incohérente des bases de référence entre les comptes ; la remédiation est manuelle et lente, et les contrôles préventifs ne sont pas appliqués uniformément.

Approche recommandée :

1. Désigner le compte de sécurité comme administrateur délégué d’AWS Config et déployer un agrégateur AWS Config via CloudFormation StackSets pour collecter les données de configuration et de conformité de tous les comptes et régions.
2. Déployer des Conformance Packs AWS Config au niveau de l’organisation depuis le compte de sécurité (en utilisant des StackSets) pour codifier les contrôles de base (accès public S3, chiffrement, balisage) afin que les mêmes règles s’appliquent de manière cohérente.
3. Attacher des actions de remédiation automatique AWS Config aux règles à haut risque qui invoquent des documents AWS Systems Manager Automation (enregistrés comme runbooks de remédiation) afin que les violations déclenchent automatiquement une remédiation via SSM Automation ou Run Command.
4. Utiliser AWS Systems Manager Patch Manager avec des SSM Patch Baselines et State Manager pour définir des groupes de correctifs et automatiser l’application des correctifs du système d’exploitation sur tous les comptes ; transmettre les résultats de conformité des correctifs à l’agrégateur Config.
5. Publier des modèles CloudFormation approuvés dans AWS Service Catalog et utiliser CloudFormation StackSets pour déployer ou mettre à jour des piles conformes ; appliquer des garde-fous préventifs avec les Service Control Policies d’AWS Organizations pour bloquer la création de ressources non autorisées (par exemple, en désactivant la création de compartiments S3 publics).
6. Configurer Amazon EventBridge (CloudWatch Events) et SNS pour notifier l’équipe de sécurité en cas de non-conformité et pour déclencher des flux de travail SSM Automation supplémentaires pour les incidents complexes.

Justification : La centralisation de la détection avec l’agrégateur Config et les conformance packs, l’automatisation de la remédiation via SSM, et l’application de garde-fous préventifs via Service Catalog/StackSets et les SCPs fournissent des contrôles cohérents et auditables ainsi qu’une remédiation rapide, conformément aux meilleures pratiques AWS en matière de sécurité, de conformité et de moindre privilège.

← Sécurité en périphérie et des applications · Tous les domaines · Vulnérabilités →

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

Parcourir Amazon →