Amazon SCS-C02: Identiteit en Toegangsbeheer — Studiegids

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

Onderdeel van de AWS Security Specialty SCS-C02 — Studiegids. Oefen met geverifieerde antwoorden in het Amazon-examencentrum, of doe getimede oefentests op ExamRoll.io.

Identiteiten, Principals en Beleidsevaluatie

IAM maakt onderscheid tussen identiteiten (users, groups, roles) en principals (de geauthenticeerde entiteit die een verzoek doet). Users hebben een lange levensduur met statische credentials; roles hebben geen eigen credentials en worden aangenomen (assumed) om kortlevende STS-tokens op te leveren. Groups zijn containers om policies aan users te koppelen — ze zijn nooit principals en kunnen niet worden aangenomen.

Elke API-aanroep doorloopt een deterministische evaluatieketen: een expliciete Deny heeft altijd voorrang, vervolgens moeten SCP’s op organisatieniveau toestemming geven, dan moeten permissions boundaries toestemming geven, dan moeten eventuele session policies toestemming geven, en ten slotte moet ten minste één identity- of resource-based policy een Allow bevatten. Het ontbreken van een Allow-laag resulteert in een impliciete deny. Daarom is gelaagdheid belangrijk: een identity policy die s3:* toestaat, is zinloos als een SCP s3:DeleteBucket weigert of een permissions boundary S3 volledig weglaat.

Resource-based policies (S3 bucket policies, KMS key policies, SNS topic policies, Lambda function policies) kunnen rechtstreeks toegang verlenen aan een principal zonder enige identity policy aan de kant van de aanroeper — binnen hetzelfde account. Voor cross-account toegang moeten zowel de identity policy in het bronaccount als de resource policy in het doelaccount de actie toestaan.

Roles, Trust Policies en AssumeRole

Een role heeft twee beleidsdocumenten: de trust policy (wie de rol mag aannemen) en een of meer permissions policies (wat ze kunnen doen nadat de rol is aangenomen). De trust policy is een resource-based policy op de role zelf, die de sts:AssumeRole-actie gebruikt. Zonder een overeenkomende trust policy mislukt AssumeRole met AccessDenied, zelfs als de aanroeper sts:AssumeRole in zijn identity policy heeft.

Voor cross-account delegatie benoemt de trust policy het vertrouwde account of een specifieke role/user ARN in dat account, en — cruciaal voor toegang door derden — dwingt het een ExternalId af:

{
  "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" }
    }
  }]
}

De ExternalId beschermt tegen het confused deputy-probleem: zonder dit zou een externe SaaS-provider die rollen aanneemt in de accounts van veel verschillende klanten, misleid kunnen worden om acties uit te voeren op de rol van de verkeerde klant. Het weglaten van sts:ExternalId in de condition, of het doorgeven van de verkeerde waarde tijdens sts:AssumeRole, leidt tot een AccessDenied bij het aannemen van de rol — een veelvoorkomende misconfiguratie bij het onboarden van leveranciers zoals monitoring- of CSPM-tools.

Voor AWS-services (Lambda, EC2, ECS-taken) benoemt de trust policy een service principal, bijv. "Service": "lambda.amazonaws.com". Een Lambda-functie die S3-toegang nodig heeft, moet een execution role aannemen waarvan de permissions policy s3:GetObject en s3:PutObject op de bucket toestaat; op een vergelijkbare manier kan een S3 bucket policy de ARN van de rol van de functie als principal benoemen. Beide mechanismen werken afzonderlijk binnen één enkel account.

Permissions Boundaries

Een permissions boundary is een geavanceerde controlemaatregel die aan een user of role wordt gekoppeld en die de maximale permissies beperkt die een identiteit ooit kan hebben, ongeacht wat identity-based policies toekennen. De effectieve permissies zijn de doorsnede van de identity policy en de boundary. Als een group policy ec2:* toestaat, maar de boundary alleen ec2:Describe* toelaat, kan de user alleen describe-acties uitvoeren.

Boundaries worden vaak gebruikt voor permissiedelegatie: ontwikkelaars toestaan om IAM-rollen voor hun applicaties te creëren, maar vereisen dat elke rol die ze aanmaken een specifieke boundary heeft. De IAM-policy voor de ontwikkelaar bevat een condition zoals "iam:PermissionsBoundary": "arn:aws:iam::123456789012:policy/DevBoundary" op iam:CreateRole en iam:PutRolePolicy. Dit voorkomt privilege escalation en maakt tegelijkertijd self-service mogelijk.

Een veelvoorkomend misverstand is dat groepslidmaatschap of extra gekoppelde policies een boundary of SCP kunnen “overschrijven”. Dat kunnen ze niet — de boundary en SCP zijn plafonds, geen vloeren.

MFA-handhaving via Conditions

Twee condition keys sturen het MFA-beleid aan: aws:MultiFactorAuthPresent (Boolean, true als de sessie met MFA is verkregen) en aws:MultiFactorAuthAge (numeriek, seconden sinds MFA is gevalideerd). Het afdwingen van MFA voor gevoelige API’s en het beperken van de sessieduur ziet er als volgt uit:

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

Twee uur is 7.200 seconden. Het gebruik van BoolIfExists in plaats van Bool is subtiel gevaarlijk voor aanroepen door service principals die deze key nooit meedragen — het evalueert naar true en omzeilt effectief de controle voor die aanroepers. Geef daarom de voorkeur aan Bool wanneer de intentie is om dit voor menselijke gebruikers af te dwingen.

Omdat CLI- en SDK-verzoeken die langetermijn-access keys gebruiken geen MFA-context meedragen, moeten gebruikers eerst sts:GetSessionToken (met --serial-number en --token-code) of sts:AssumeRole (met --serial-number/--token-code) aanroepen om tijdelijke credentials te verkrijgen die de MFA-context wél bevatten. Die kortlevende credentials voldoen vervolgens aan de MultiFactorAuthPresent-condition:

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

IAM Identity Center en Federatie

IAM Identity Center (voorheen AWS SSO) centraliseert de toegang voor medewerkers binnen een AWS Organization. Permissiesets zijn templates die Identity Center materialiseert als IAM-rollen binnen elk doelaccount wanneer een gebruiker of groep wordt toegewezen. Toewijzingen koppelen drie dingen: een principal (een gebruiker of groep uit de Identity Center-directory of een externe IdP zoals Okta/Entra ID), een permissieset en een of meer accounts.

Permissiesets kunnen door AWS beheerde policies, door de klant beheerde policies (waarnaar wordt verwezen met een naam, dus ze moeten in elk doelaccount bestaan), inline policies en een permissiegrens (permissions boundary) bevatten. Wanneer u een permissieset bewerkt, herprovisioneert Identity Center de onderliggende rollen — u bewerkt die rollen nooit rechtstreeks.

Voor SAML-federatie buiten Identity Center valideert AWS de handtekening van de assertion aan de hand van de IdP-metadata die is geregistreerd op het IAM SAML-providerobject. Wanneer de IdP zijn ondertekeningscertificaat roteert, is het uploaden van de bijgewerkte metadata-XML vereist; anders retourneert STS InvalidIdentityToken / Response Signature Invalid. Het bijwerken van de metadata met aws iam update-saml-provider --saml-metadata-document file://metadata.xml --saml-provider-arn ... is de oplossing met de minste overhead — het is niet nodig om de provider opnieuw aan te maken of vertrouwensrelaties opnieuw te configureren.

Root-account, Credentialrapporten en Least Privilege

De root-gebruiker heeft onverwijderbare volledige toegang en moet worden behandeld als een break-glass identiteit: schakel een hardware- of virtueel MFA-apparaat in, verwijder eventuele root-toegangssleutels, gebruik het niet voor dagelijks werk en bewaar de credentials offline. Gebruik SCP’s op het niveau van de organization root of OU om te voorkomen dat zelfs beheerders in member-accounts GuardDuty uitschakelen, CloudTrail verwijderen of specifieke regio’s verlaten. SCP’s verlenen nooit permissies — ze filteren alleen wat IAM in het member-account kan toekennen.

Least privilege wordt geïmplementeerd met tools in plaats van op intuïtie. Genereer het IAM credentialrapport (aws iam generate-credential-report en vervolgens get-credential-report) om ongebruikte gebruikers, verouderde toegangssleutels en gebruikers zonder MFA te vinden. Gebruik IAM Access Analyzer om resource-policies te identificeren die data cross-account blootstellen en om op maat gemaakte policies te genereren op basis van CloudTrail-activiteit. Gebruik data over laatste toegang (aws iam get-service-last-accessed-details) om ongebruikte servicepermissies uit rollen te verwijderen.

Een laatste valkuil die het waard is om expliciet te benoemen: aannemen dat het toevoegen van een ‘Allow’ voor een identiteit voldoende is. Als een KMS-sleutelpolicy uw rol niet benoemt, een SCP de actie weigert, of een permissiegrens deze weglaat, mislukt de aanroep alsnog. Audit altijd de volledige stack — SCP, boundary, identity policy, resource policy en session policy — bij het troubleshooten van AccessDenied.

Praktijkprobleem: Gebruiksscenario

Scenario: Meridian Financial beheert een AWS Organization met drie accounts voor management-, productie- en ontwikkelingsworkloads, met gevoelige handels- en klantgegevens in het productieaccount. Ze hebben momenteel een mix van verouderde, langdurige IAM-gebruikers, accounts voor contractanten en een Okta SAML-identityprovider, wat leidt tot inconsistente toegangscontroles en verspreide rolconfiguraties over de accounts.

Uitdaging: Een recent incident betrof de gecompromitteerde credentials van een contractant die een cross-account rol aannam zonder MFA en buitensporige acties uitvoerde omdat er geen permissiegrenzen of gecentraliseerde permissiesets waren. Meridian moet de federatie en rolvertrouwensrelaties versterken en MFA en least privilege over alle accounts afdwingen.

Aanbevolen Aanpak:

Implementeer AWS IAM Identity Center geïntegreerd met Okta SAML als het enige gefedereerde identiteitsvlak en migreer alle menselijke gebruikers en contractanten van langdurige IAM-gebruikers naar op Identity Center gebaseerde accounts, waarbij consoletoegang/sleutels voor verouderde IAM-gebruikers worden uitgeschakeld.
Creëer gecentraliseerde permissiesets in IAM Identity Center die mappen naar IAM-rollen in member-accounts en implementeer IAM-permissiegrenzen (gedefinieerd als IAM-policies) voor alle rollen; implementeer deze grenzen en roltemplates over de accounts met behulp van AWS CloudFormation StackSets.
Werk cross-account rolvertrouwenspolicies bij om alleen sts:AssumeRole toe te staan vanaf de principal-ARN’s van Identity Center en voeg condities toe die MFA (bijv. aws:MultiFactorAuthPresent) en bronaccountbeperkingen vereisen; vereis dat sessietags identiteitsattributen bevatten.
Dwing MFA af op de IdP (Okta) en reflecteer deze handhaving in AWS door MFA-condities te vereisen voor rolsessies; verbied het aanmaken van consoletoegang of nieuwe IAM-gebruikers door Service Control Policies (SCP’s) toe te passen in AWS Organizations.
Schakel AWS CloudTrail, AWS Config en IAM Access Analyzer in voor continue monitoring en policyvalidatie, en stuur bevindingen naar CloudWatch/GuardDuty voor alarmering en geautomatiseerde herstelworkflows.

Redenering: Het centraliseren van federatie via IAM Identity Center, het afdwingen van least privilege met permissiesets en -grenzen, het vereisen van MFA in vertrouwenspolicies, en het toepassen van SCP’s op organisatieniveau plus monitoring, sluit aan bij de best practices van AWS om de ‘blast radius’ te verkleinen, privilege-escalatie te voorkomen en auditeerbaarheid te bieden.

IAM-rollen en vertrouwensbeleid: PassRole en AssumeRole

Een IAM-rol heeft twee afzonderlijke beleidsinterfaces, en verwarring hiertussen is de hoofdoorzaak van de meeste autorisatiefouten tussen accounts. Het vertrouwensbeleid (de AssumeRolePolicyDocument) beantwoordt wie de rol mag aannemen en onder welke voorwaarden. Het permissiebeleid beantwoordt wat de rol kan doen zodra deze is aangenomen. Beide moeten de actie toestaan; het vertrouwensbeleid alleen verleent nooit toegang tot S3, KMS of iets anders.

Wanneer een principal sts:AssumeRole aanroept, evalueert STS het vertrouwensbeleid van de doelrol ten opzichte van de aanroepende identiteit plus de sessiecontext (bron-IP, MFA-status, sessietags, externe ID). De aanroepende principal moet ook een op identiteit gebaseerde Allow hebben voor sts:AssumeRole op die rol-ARN. Deze dubbele vereiste maakt het veilig om rollen aan te nemen over accountgrenzen heen.

Een canoniek cross-account vertrouwensbeleid dat MFA en een externe ID vereist, ziet er als volgt uit:

{
  "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" }
    }
  }]
}

De aws:MultiFactorAuthPresent-sleutel is alleen zinvol in het vertrouwensbeleid van een aanneembare rol, omdat de MFA-context wordt vastgesteld bij de STS-aanroep, niet bij downstream service-aanroepen. Het toevoegen van MFA-voorwaarden aan het S3-bucketbeleid of aan het permissiebeleid van de rol is een veelgemaakte fout: de assumed-role-sessie bevat meestal geen aws:MultiFactorAuthPresent=true, zelfs als de oorspronkelijke menselijke gebruiker met MFA heeft geauthenticeerd, waardoor die voorwaarden stilzwijgend alles weigeren. Dwing MFA af op het moment van aannemen; gebruik aws:MultiFactorAuthAge om herauthenticatie af te dwingen voor langdurige sessies.

PassRole is de tweede poort die een struikelblok vormt in examenscenario’s. Wanneer je een service zoals CloudFormation, EC2, Lambda of CodeBuild vertelt om als een rol te draaien, moet de aanroepende identiteit de permissie iam:PassRole hebben.

Praktijkprobleem: Use-Case Scenario

Scenario: Meridian Financial beheert een multi-account AWS Organization met aparte accounts voor productie, ontwikkeling en CI/CD-tooling; ze gebruiken gecentraliseerde IAM-rollen voor cross-account implementaties en CI-agents van derden die rollen aannemen om infrastructuurwijzigingen door te voeren. Identiteitsgrenzen worden afgedwongen door het vertrouwensbeleid van rollen en sommige teams gebruiken langdurige instance profiles en Lambda-functies die iam:PassRole hebben gekregen om rollen te koppelen aan instances of taken.

Uitdaging: Een recente audit ontdekte een te ruime iam:PassRole-permissie die een CI/CD-principal in staat stelde een Administrator-rol door te geven aan een EC2 instance profile, en een aanvaller misbruikte een AssumeRole-vertrouwensrelatie om buitensporige privileges over meerdere accounts te verkrijgen.

Aanbevolen Aanpak:

Gebruik AWS CloudTrail en Amazon EventBridge om recente iam:PassRole- en sts:AssumeRole-API-aanroepen te identificeren, en voer query’s uit in CloudTrail Lake of Athena om een lijst te maken van welke principals welke rol-ARN’s hebben doorgegeven en wanneer.
Voer IAM Access Analyzer (voor IAM) uit over de accounts om blootstellingen in resource-gebaseerd vertrouwensbeleid te ontdekken en maak een lijst van rollen die kunnen worden aangenomen van buiten de Organization of door externe principals.
Vervang ruime iam:PassRole-beleidsregels door IAM-beleidsregels met minimale rechten (least privilege) die exacte rol-ARN’s specificeren in Resource, en voeg condition keys toe zoals aws:PassedToService of aws:PrincipalOrgID om te beperken wie en wat de rol kan ontvangen.
Versterk het vertrouwensbeleid van rollen om voorwaarden te vereisen—gebruik aws:PrincipalOrgID, sts:ExternalId voor derden, vereis aws:SourceIdentity en dwing maximale sessieduren af—om te voorkomen dat onbekende principals breed AssumeRole kunnen gebruiken.
Configureer Amazon EventBridge-regels om iam:PassRole- en AssumeRole-anomalieën te detecteren, stuur waarschuwingen naar Amazon SNS en creëer geautomatiseerde Lambda-playbooks om te ruime beleidsregels in te trekken of te herstellen, en leg bevindingen vast in AWS Security Hub en AWS Config voor continue compliance.

Rationale: Deze aanpak dwingt het principe van ’least privilege’ en ‘defense-in-depth’ af door PassRole-doelen en vertrouwensbeleid aan te scherpen, terwijl detectie en geautomatiseerd herstel mogelijk worden gemaakt door logging en monitoring—in lijn met de best practices van AWS voor IAM en federatie.

Alle domeinen · Bedreigingsdetectie en Alarmering →

Oefen deze vragen → · Getimede oefening op ExamRoll.io →