Amazon SCS-C02: Gestion de l'identité et des accès — 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.

Identités, principaux et évaluation des politiques

IAM fait la distinction entre les identités (utilisateurs, groupes, rôles) et les principaux (l’entité authentifiée qui effectue une requête). Les utilisateurs sont pérennes avec des informations d’identification statiques ; les rôles n’ont pas d’informations d’identification propres et sont assumés pour obtenir des jetons STS à durée de vie limitée. Les groupes sont des conteneurs permettant d’attacher des politiques aux utilisateurs — ils ne sont jamais des principaux et ne peuvent pas être assumés.

Chaque appel d’API passe par une chaîne d’évaluation déterministe : un Refus (Deny) explicite l’emporte toujours, puis les SCP au niveau de l’organisation doivent autoriser, puis les frontières de permissions (permissions boundaries) doivent autoriser, puis les politiques de session (le cas échéant) doivent autoriser, et enfin au moins une politique basée sur l’identité ou sur la ressource doit contenir une autorisation (Allow). L’absence de toute couche d’autorisation (Allow) entraîne un refus implicite. C’est pourquoi la superposition est importante : une politique d’identité accordant s3:* est sans effet si une SCP refuse s3:DeleteBucket ou si une frontière de permissions omet complètement S3.

Les politiques basées sur les ressources (politiques de bucket S3, politiques de clé KMS, politiques de sujet SNS, politiques de fonction Lambda) peuvent accorder un accès directement à un principal sans aucune politique d’identité du côté de l’appelant — au sein du même compte. Pour un accès inter-comptes, la politique d’identité dans le compte source et la politique de ressource dans le compte cible doivent toutes deux autoriser l’action.

Rôles, politiques de confiance (Trust Policies) et AssumeRole

Un rôle possède deux documents de politique : la politique de confiance (qui peut l’assumer) et une ou plusieurs politiques de permissions (ce qu’ils peuvent faire une fois le rôle assumé). La politique de confiance est une politique basée sur les ressources appliquée au rôle lui-même, utilisant l’action sts:AssumeRole. Sans une politique de confiance correspondante, AssumeRole échoue avec une erreur AccessDenied même si l’appelant dispose de sts:AssumeRole dans sa politique d’identité.

Pour la délégation entre comptes, la politique de confiance nomme le compte de confiance ou un ARN de rôle/utilisateur spécifique dans ce compte, et — ce qui est essentiel pour l’accès par des tiers — impose un ExternalId :

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": { "sts:ExternalId": "unique-shared-secret-9271" }
    }
  }]
}

L’ExternalId protège contre le problème du député confus (confused deputy) : sans lui, un fournisseur SaaS tiers assumant des rôles dans de nombreux comptes clients pourrait être amené par erreur à agir sur le rôle d’un autre client. Omettre sts:ExternalId dans la condition, ou passer une valeur incorrecte lors de l’appel sts:AssumeRole, produit une erreur AccessDenied lors de l’assumption — une erreur de configuration courante lors de l’intégration de fournisseurs tels que les outils de surveillance ou de CSPM.

Pour les services AWS (Lambda, EC2, tâches ECS), la politique de confiance nomme un principal de service, par ex. "Service": "lambda.amazonaws.com". Une fonction Lambda nécessitant un accès à S3 doit assumer un rôle d’exécution dont la politique de permissions accorde s3:GetObject et s3:PutObject sur le bucket ; de manière équivalente, une politique de bucket S3 peut nommer l’ARN du rôle de la fonction comme principal. L’un ou l’autre de ces mécanismes fonctionne seul au sein d’un même compte.

Frontières de permissions (Permissions Boundaries)

Une frontière de permissions est un contrôle avancé attaché à un utilisateur ou à un rôle qui plafonne les permissions maximales que cette identité peut avoir, quelles que soient les permissions accordées par les politiques basées sur l’identité. Les permissions effectives sont l’intersection de la politique d’identité et de la frontière. Si une politique de groupe accorde ec2:* mais que la frontière n’autorise que ec2:Describe*, l’utilisateur ne peut qu’effectuer des actions de description.

Les frontières sont couramment utilisées pour la délégation de permissions : permettre aux développeurs de créer des rôles IAM pour leurs applications, mais exiger que chaque rôle qu’ils créent soit associé à une frontière spécifique. La politique IAM du développeur inclut une condition telle que "iam:PermissionsBoundary": "arn:aws:iam::123456789012:policy/DevBoundary" sur les actions iam:CreateRole et iam:PutRolePolicy. Cela empêche l’escalade de privilèges tout en permettant le libre-service.

Une idée fausse fréquente est que l’appartenance à un groupe ou des politiques attachées supplémentaires peuvent « outrepasser » une frontière ou une SCP. Ce n’est pas le cas — la frontière et la SCP sont des plafonds, pas des planchers.

Application du MFA via des conditions

Deux clés de condition pilotent la politique MFA : aws:MultiFactorAuthPresent (booléen, vrai si la session a été obtenue en utilisant le MFA) et aws:MultiFactorAuthAge (numérique, secondes écoulées depuis la validation du MFA). L’application du MFA pour les API sensibles et le plafonnement de la durée de vie de la session ressemblent à ceci :

{
  "Effect": "Allow",
  "Action": ["rds:DeleteDBInstance", "kms:ScheduleKeyDeletion"],
  "Resource": "*",
  "Condition": {
    "Bool":            { "aws:MultiFactorAuthPresent": "true" },
    "NumericLessThan": { "aws:MultiFactorAuthAge": "7200" }
  }
}

Deux heures correspondent à 7 200 secondes. L’utilisation de BoolIfExists au lieu de Bool est subtilement dangereuse pour les appels de principaux de service qui ne contiennent jamais cette clé — il est évalué à vrai et contourne de fait la vérification pour ces appelants. Préférez donc Bool lorsque l’intention est d’appliquer la règle à un utilisateur humain.

Comme les requêtes CLI et SDK utilisant des clés d’accès à long terme ne transportent pas de contexte MFA, les utilisateurs doivent d’abord appeler sts:GetSessionToken (avec --serial-number et --token-code) ou sts:AssumeRole avec --serial-number/--token-code pour obtenir des informations d’identification temporaires qui incluent le contexte MFA. Ces informations d’identification à durée de vie limitée satisfont alors la condition MultiFactorAuthPresent :

aws sts get-session-token \
  --serial-number arn:aws:iam::123456789012:mfa/alice \
  --token-code 123456 \
  --duration-seconds 7200

IAM Identity Center et Fédération

IAM Identity Center (anciennement AWS SSO) centralise l’accès des collaborateurs au sein d’une AWS Organization. Les ensembles d’autorisations (Permission sets) sont des modèles qu’Identity Center matérialise sous forme de rôles IAM dans chaque compte cible lorsqu’un utilisateur ou un groupe est assigné. Les assignations lient trois éléments : un principal (utilisateur ou groupe du répertoire Identity Center ou d’un IdP externe comme Okta/Entra ID), un ensemble d’autorisations, et un ou plusieurs comptes.

Les ensembles d’autorisations peuvent contenir des politiques gérées par AWS, des politiques gérées par le client (référencées par leur nom, elles doivent donc exister dans chaque compte cible), des politiques en ligne, et un périmètre d’autorisations (permissions boundary). Lorsque vous modifiez un ensemble d’autorisations, Identity Center reprovisionne les rôles sous-jacents — vous ne modifiez jamais ces rôles directement.

Pour la fédération SAML en dehors d’Identity Center, AWS valide la signature de l’assertion par rapport aux métadonnées de l’IdP enregistrées sur l’objet fournisseur SAML IAM. Lorsque l’IdP renouvelle son certificat de signature, le téléversement du fichier XML des métadonnées mis à jour est requis ; sinon, STS renvoie InvalidIdentityToken / Response Signature Invalid. La mise à jour des métadonnées avec aws iam update-saml-provider --saml-metadata-document file://metadata.xml --saml-provider-arn ... est le correctif le plus simple — il n’est pas nécessaire de recréer le fournisseur ou de reconfigurer les relations d’approbation.

Compte Racine, Rapports d’Informations d’Identification et Moindre Privilège

L’utilisateur racine (root) dispose d’un accès complet non révocable et doit être traité comme une identité de secours (« break-glass ») : activez un dispositif MFA matériel ou virtuel, supprimez toutes les clés d’accès racine, ne l’utilisez pas pour le travail quotidien et stockez les informations d’identification hors ligne. Utilisez des SCP au niveau de la racine de l’organisation ou d’une UO (OU) pour empêcher même les administrateurs des comptes membres de désactiver GuardDuty, de supprimer CloudTrail ou de quitter des régions spécifiques. Les SCP n’accordent jamais d’autorisations — elles ne font que filtrer ce que l’IAM dans le compte membre peut accorder.

Le principe du moindre privilège est mis en œuvre avec des outils plutôt qu’à l’intuition. Générez le rapport d’informations d’identification (credential report) IAM (aws iam generate-credential-report puis get-credential-report) pour trouver les utilisateurs inactifs, les clés d’accès vieillissantes et les utilisateurs sans MFA. Utilisez IAM Access Analyzer pour identifier les politiques de ressources qui exposent des données à d’autres comptes et pour générer des politiques ajustées à partir de l’activité CloudTrail. Utilisez les données de dernier accès (last-accessed) (aws iam get-service-last-accessed-details) pour élaguer les autorisations de service inutilisées des rôles.

Un dernier piège qu’il convient de nommer explicitement : supposer que l’ajout d’un ‘Allow’ à une identité est suffisant. Si une politique de clé KMS ne nomme pas votre rôle, qu’une SCP refuse l’action, ou qu’un périmètre d’autorisations l’omet, l’appel échouera quand même. Auditez toujours la pile complète — SCP, périmètre, politique d’identité, politique de ressource et politique de session — lors du dépannage d’un AccessDenied.

Problème Pratique : Scénario d’Utilisation

Scénario : Meridian Financial exploite une AWS Organization à trois comptes pour les charges de travail de gestion, de production et de développement, avec des données de trading et client sensibles dans le compte de production. Ils disposent actuellement d’un mélange d’utilisateurs IAM hérités à longue durée de vie, de comptes pour des sous-traitants et d’un fournisseur d’identité SAML Okta, ce qui entraîne des contrôles d’accès incohérents et des configurations de rôles éparpillées entre les comptes.

Défi : Un incident récent a impliqué les informations d’identification compromises d’un sous-traitant qui a assumé un rôle inter-comptes sans MFA et a effectué des actions excessives, car il n’y avait ni périmètre d’autorisations ni ensembles d’autorisations centralisés. Meridian doit renforcer la fédération, l’approbation des rôles, et imposer le MFA et le moindre privilège sur l’ensemble des comptes.

Approche Recommandée :

Déployer AWS IAM Identity Center intégré avec Okta SAML comme plan d’identité fédérée unique et migrer tous les utilisateurs humains et les sous-traitants depuis les utilisateurs IAM à longue durée de vie vers des comptes basés sur Identity Center, en désactivant la console/les clés pour les utilisateurs IAM hérités.
Créer des ensembles d’autorisations centralisés dans IAM Identity Center qui correspondent à des rôles IAM dans les comptes membres et mettre en œuvre des périmètres d’autorisations IAM (définis comme des politiques IAM) pour tous les rôles ; déployer ces périmètres et modèles de rôle sur l’ensemble des comptes à l’aide d’AWS CloudFormation StackSets.
Mettre à jour les politiques d’approbation des rôles inter-comptes pour n’autoriser sts:AssumeRole qu’à partir des ARN de principaux d’Identity Center et inclure des conditions exigeant le MFA (par ex., aws:MultiFactorAuthPresent) et des restrictions de compte source ; exiger que les balises de session transportent des attributs d’identité.
Imposer le MFA au niveau de l’IdP (Okta) et refléter cette application dans AWS en exigeant des conditions MFA sur les sessions de rôle ; interdire la création d’accès à la console ou de nouveaux utilisateurs IAM en appliquant des Politiques de Contrôle de Service (SCP) dans AWS Organizations.
Activer AWS CloudTrail, AWS Config et IAM Access Analyzer pour la surveillance continue et la validation des politiques, et envoyer les résultats (findings) à CloudWatch/GuardDuty pour les alertes et les flux de travail de remédiation automatisée.

Justification : La centralisation de la fédération via IAM Identity Center, l’application du moindre privilège avec des ensembles et des périmètres d’autorisations, l’exigence du MFA dans les politiques d’approbation, et l’application de SCP au niveau de l’organisation ainsi que la surveillance s’alignent sur les meilleures pratiques AWS pour réduire le rayon d’impact (« blast radius »), empêcher l’escalade de privilèges et assurer l’auditabilité.

Rôles IAM et politiques d’approbation : PassRole et AssumeRole

Un rôle IAM possède deux surfaces de politique distinctes, et leur confusion est la cause principale de la plupart des échecs d’autorisation inter-comptes. La politique d’approbation (le AssumeRolePolicyDocument) répond à la question de qui peut endosser le rôle et sous quelles conditions. La politique de permissions répond à la question de ce que le rôle peut faire une fois endossé. Les deux doivent autoriser l’action ; la politique d’approbation seule n’accorde jamais l’accès à S3, KMS, ou quoi que ce soit d’autre.

Lorsqu’un principal appelle sts:AssumeRole, STS évalue la politique d’approbation du rôle cible par rapport à l’identité appelante ainsi qu’au contexte de la session (adresse IP source, état MFA, balises de session, ID externe). Le principal appelant doit également avoir une autorisation (Allow) basée sur l’identité pour sts:AssumeRole sur l’ARN de ce rôle. C’est cette double exigence qui rend l’endossement de rôle sécurisé au-delà des frontières d’un compte.

Une politique d’approbation inter-comptes canonique qui exige le MFA et un ID externe ressemble à ceci :

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "Bool": { "aws:MultiFactorAuthPresent": "true" },
      "NumericLessThan": { "aws:MultiFactorAuthAge": "3600" },
      "StringEquals": { "sts:ExternalId": "unique-partner-id-8842" }
    }
  }]
}

La clé aws:MultiFactorAuthPresent n’a de sens que dans la politique d’approbation d’un rôle pouvant être endossé, car le contexte MFA est établi lors de l’appel à STS, et non lors des appels de service en aval. Ajouter des conditions MFA à la politique de compartiment S3 ou à la politique de permissions du rôle est une erreur courante : la session du rôle endossé ne contient généralement pas aws:MultiFactorAuthPresent=true même si l’utilisateur humain d’origine s’est authentifié avec le MFA, donc ces conditions refusent silencieusement toutes les actions. Appliquez le MFA au moment de l’endossement ; utilisez aws:MultiFactorAuthAge pour forcer une nouvelle authentification pour les sessions de longue durée.

PassRole est le deuxième point de blocage qui piège dans les scénarios d’examen. Lorsque vous demandez à un service comme CloudFormation, EC2, Lambda ou CodeBuild de s’exécuter en tant que rôle, l’identité appelante doit avoir `iam:PassRole

Problème pratique : Scénario d’utilisation

Scénario : Meridian Financial gère une AWS Organization multi-comptes avec des comptes distincts pour la production, le développement et l’outillage CI/CD ; ils utilisent des rôles IAM centralisés pour les déploiements inter-comptes et des agents CI tiers qui endossent des rôles pour effectuer des changements d’infrastructure. Les frontières d’identité sont appliquées par les politiques d’approbation des rôles et certaines équipes utilisent des profils d’instance et des fonctions Lambda de longue durée auxquels est accordée la permission iam:PassRole pour attacher des rôles à des instances ou des tâches.

Défi : Un audit récent a révélé qu’une permission iam:PassRole trop large permettait à un principal CI/CD de passer un rôle Administrateur à un profil d’instance EC2, et un attaquant a exploité une relation d’approbation AssumeRole pour obtenir des privilèges excessifs sur plusieurs comptes.

Approche recommandée :

Utilisez AWS CloudTrail et Amazon EventBridge pour identifier les appels API iam:PassRole et sts:AssumeRole récents, et exécutez des requêtes dans CloudTrail Lake ou Athena pour lister quels principaux ont passé quels ARN de rôle et à quel moment.
Exécutez IAM Access Analyzer (pour IAM) sur l’ensemble des comptes pour découvrir les expositions de politiques d’approbation basées sur les ressources et lister les rôles qui sont endossables depuis l’extérieur de l’Organisation ou par des principaux externes.
Remplacez les politiques iam:PassRole larges par des politiques IAM de moindre privilège qui spécifient les ARN de rôle exacts dans la ressource (Resource), et ajoutez des clés de condition telles que aws:PassedToService ou aws:PrincipalOrgID pour limiter qui et quoi peut recevoir le rôle.
Renforcez les politiques d’approbation des rôles pour exiger des conditions — utilisez aws:PrincipalOrgID, sts:ExternalId pour les tiers, exigez aws:SourceIdentity et appliquez des durées de session maximales — pour empêcher un AssumeRole large par des principaux inconnus.
Configurez des règles Amazon EventBridge pour détecter les anomalies iam:PassRole et AssumeRole, envoyez des alertes à Amazon SNS et créez des playbooks Lambda automatisés pour révoquer ou corriger les politiques trop larges, et enregistrez les résultats dans AWS Security Hub et AWS Config pour une conformité continue.

Justification : Cette approche applique le principe du moindre privilège et de la défense en profondeur en resserrant les cibles de PassRole et les politiques d’approbation, tout en permettant la détection et la remédiation automatisée grâce à la journalisation et à la surveillance — conformément aux meilleures pratiques AWS pour IAM et la fédération.

Tous les domaines · Détection des menaces et alertes →

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