Amazon SCS-C02: Identitäts- und Zugriffsverwaltung — Lernleitfaden

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

Teil des AWS Security Specialty SCS-C02 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Amazon-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Identitäten, Prinzipale und Richtlinienauswertung

IAM unterscheidet zwischen Identitäten (Benutzer, Gruppen, Rollen) und Prinzipalen (der authentifizierten Entität, die eine Anfrage stellt). Benutzer sind langlebig und haben statische Anmeldeinformationen; Rollen haben keine eigenen Anmeldeinformationen und werden angenommen (assumed), um kurzlebige STS-Token zu erhalten. Gruppen sind Container, um Benutzern Richtlinien zuzuordnen – sie sind niemals Prinzipale und können nicht angenommen werden.

Jeder API-Aufruf durchläuft eine deterministische Auswertungskette: Ein explizites Deny hat immer Vorrang, dann müssen SCPs auf Organisationsebene die Aktion erlauben, dann müssen Berechtigungsgrenzen sie erlauben, dann müssen eventuelle Sitzungsrichtlinien sie erlauben, und schließlich muss mindestens eine identitäts- oder ressourcenbasierte Richtlinie ein Allow enthalten. Fehlt eine dieser Allow-Ebenen, führt dies zu einem impliziten Deny. Deshalb ist diese Schichtung so wichtig: Eine Identitätsrichtlinie, die s3:* gewährt, ist bedeutungslos, wenn eine SCP s3:DeleteBucket verweigert oder eine Berechtigungsgrenze S3 vollständig ausschließt.

Ressourcenbasierte Richtlinien (S3-Bucket-Richtlinien, KMS-Schlüsselrichtlinien, SNS-Themenrichtlinien, Lambda-Funktionsrichtlinien) können einem Prinzipal direkt Zugriff gewähren, ohne dass eine Identitätsrichtlinie auf der Seite des Aufrufers erforderlich ist – innerhalb desselben Kontos. Für kontoübergreifenden Zugriff müssen sowohl die Identitätsrichtlinie im Quellkonto als auch die Ressourcenrichtlinie im Zielkonto die Aktion erlauben.

Rollen, Vertrauensrichtlinien und AssumeRole

Eine Rolle hat zwei Richtliniendokumente: die Vertrauensrichtlinie (wer sie annehmen darf) und eine oder mehrere Berechtigungsrichtlinien (was der Prinzipal nach dem Annehmen der Rolle tun darf). Die Vertrauensrichtlinie ist eine ressourcenbasierte Richtlinie für die Rolle selbst, die die Aktion sts:AssumeRole verwendet. Ohne eine passende Vertrauensrichtlinie schlägt AssumeRole mit AccessDenied fehl, selbst wenn der Aufrufer sts:AssumeRole in seiner Identitätsrichtlinie hat.

Für die kontoübergreifende Delegierung benennt die Vertrauensrichtlinie das vertrauenswürdige Konto oder einen spezifischen Rollen-/Benutzer-ARN in diesem Konto und erzwingt – was für den Zugriff durch Dritte entscheidend ist – eine 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" }
    }
  }]
}

Die ExternalId schützt vor dem Problem des verwirrten Stellvertreters (Confused Deputy Problem): Ohne sie könnte ein Drittanbieter (SaaS), der Rollen in vielen Kundenkonten annimmt, dazu verleitet werden, Aktionen im Namen der Rolle eines falschen Kunden auszuführen. Das Weglassen von sts:ExternalId in der Bedingung oder die Übergabe eines falschen Wertes bei sts:AssumeRole führt zu einem AccessDenied beim Annehmen der Rolle – eine häufige Fehlkonfiguration beim Onboarding von Anbietern wie Monitoring- oder CSPM-Tools.

Für AWS-Services (Lambda, EC2, ECS-Tasks) benennt die Vertrauensrichtlinie einen Service-Prinzipal, z. B. "Service": "lambda.amazonaws.com". Eine Lambda-Funktion, die S3-Zugriff benötigt, sollte eine Ausführungsrolle (Execution Role) annehmen, deren Berechtigungsrichtlinie s3:GetObject und s3:PutObject für den Bucket gewährt; alternativ kann eine S3-Bucket-Richtlinie den Rollen-ARN der Funktion als Prinzipal benennen. Beide Mechanismen funktionieren für sich allein innerhalb eines einzigen Kontos.

Berechtigungsgrenzen (Permissions Boundaries)

Eine Berechtigungsgrenze (Permissions Boundary) ist eine erweiterte Kontrolle, die einem Benutzer oder einer Rolle zugeordnet wird und die maximalen Berechtigungen begrenzt, die diese Identität jemals haben kann, unabhängig davon, was identitätsbasierte Richtlinien gewähren. Die effektiven Berechtigungen sind die Schnittmenge der Identitätsrichtlinie und der Berechtigungsgrenze. Wenn eine Gruppenrichtlinie ec2:* gewährt, die Berechtigungsgrenze aber nur ec2:Describe* erlaubt, kann der Benutzer nur Beschreibungsaktionen ausführen.

Berechtigungsgrenzen werden häufig zur Delegierung von Berechtigungen verwendet: Entwicklern wird erlaubt, IAM-Rollen für ihre Anwendungen zu erstellen, aber es wird gefordert, dass jede von ihnen erstellte Rolle eine bestimmte Berechtigungsgrenze trägt. Die IAM-Richtlinie für den Entwickler enthält eine Bedingung wie "iam:PermissionsBoundary": "arn:aws:iam::123456789012:policy/DevBoundary" für iam:CreateRole und iam:PutRolePolicy. Dies verhindert eine Eskalation von Berechtigungen (Privilege Escalation) und ermöglicht gleichzeitig Self-Service.

Ein häufiges Missverständnis ist, dass eine Gruppenzugehörigkeit oder zusätzlich angehängte Richtlinien eine Berechtigungsgrenze oder eine SCP „überschreiben“ können. Das können sie nicht – die Berechtigungsgrenze und die SCP sind Obergrenzen (Ceilings), keine Untergrenzen (Floors).

MFA-Erzwingung durch Bedingungen

Zwei Bedingungsschlüssel (Condition Keys) steuern die MFA-Richtlinie: aws:MultiFactorAuthPresent (boolesch, wahr, wenn die Sitzung mit MFA erstellt wurde) und aws:MultiFactorAuthAge (numerisch, Sekunden seit der MFA-Validierung). Das Erzwingen von MFA für sensible APIs und die Begrenzung der Sitzungsdauer sieht wie folgt aus:

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

Zwei Stunden sind 7.200 Sekunden. Die Verwendung von BoolIfExists anstelle von Bool ist für Aufrufe von Service-Prinzipalen, die diesen Schlüssel niemals mitführen, auf subtile Weise gefährlich – es wird als „wahr“ ausgewertet und umgeht die Prüfung für diese Aufrufer effektiv. Bevorzugen Sie daher Bool, wenn die Durchsetzung für menschliche Benutzer beabsichtigt ist.

Da CLI- und SDK-Anfragen, die langlebige Zugriffsschlüssel (Access Keys) verwenden, keinen MFA-Kontext mitführen, müssen Benutzer zuerst sts:GetSessionToken (mit --serial-number und --token-code) oder sts:AssumeRole (mit --serial-number/--token-code) aufrufen, um temporäre Anmeldeinformationen zu erhalten, die den MFA-Kontext enthalten. Diese kurzlebigen Anmeldeinformationen erfüllen dann die Bedingung MultiFactorAuthPresent:

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

IAM Identity Center und Föderation

IAM Identity Center (ehemals AWS SSO) zentralisiert den Zugriff von Mitarbeitern über eine gesamte AWS Organization. Berechtigungssätze sind Vorlagen, die das Identity Center als IAM-Rollen in jedem Zielkonto materialisiert, wenn ein Benutzer oder eine Gruppe zugewiesen wird. Zuweisungen verknüpfen drei Elemente: einen Prinzipal (Benutzer oder Gruppe aus dem Identity-Center-Verzeichnis oder einem externen IdP wie Okta/Entra ID), einen Berechtigungssatz und ein oder mehrere Konten.

Berechtigungssätze können von AWS verwaltete Richtlinien, vom Kunden verwaltete Richtlinien (referenziert über ihren Namen, daher müssen sie in jedem Zielkonto existieren), Inline-Richtlinien und eine Berechtigungsgrenze (Permissions Boundary) enthalten. Wenn Sie einen Berechtigungssatz bearbeiten, stellt das Identity Center die zugrunde liegenden Rollen neu bereit – Sie bearbeiten diese Rollen niemals direkt.

Für die SAML-Föderation außerhalb des Identity Centers validiert AWS die Signatur der Assertion anhand der IdP-Metadaten, die im IAM-SAML-Provider-Objekt registriert sind. Wenn der IdP sein Signaturzertifikat rotiert, ist das Hochladen der aktualisierten Metadaten-XML erforderlich; andernfalls gibt STS InvalidIdentityToken / Response Signature Invalid zurück. Die Aktualisierung der Metadaten mit

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

ist die Lösung mit dem geringsten Aufwand – es ist nicht nötig, den Provider neu zu erstellen oder Vertrauensstellungen neu zu konfigurieren.

Root-Konto, Anmeldeinformationsbericht und Prinzip der geringsten Rechte

Der Root-Benutzer hat einen nicht entfernbaren Vollzugriff und muss als Break-Glass-Identität behandelt werden: Aktivieren Sie ein Hardware- oder virtuelles MFA-Gerät, löschen Sie alle Root-Zugriffsschlüssel, verwenden Sie ihn nicht für die tägliche Arbeit und speichern Sie die Anmeldeinformationen offline. Verwenden Sie SCPs auf der Root-Ebene der Organisation oder auf OU-Ebene, um zu verhindern, dass selbst Administratoren in Mitgliedskonten GuardDuty deaktivieren, CloudTrail löschen oder bestimmte Regionen verlassen. SCPs gewähren niemals Berechtigungen – sie filtern nur, was IAM im Mitgliedskonto gewähren kann.

Das Prinzip der geringsten Rechte wird eher mit Werkzeugen als mit Intuition operationalisiert. Generieren Sie den IAM-Anmeldeinformationsbericht (zuerst

undefined

, dann

undefined

), um ungenutzte Benutzer, veraltende Zugriffsschlüssel und Benutzer ohne MFA zu finden. Verwenden Sie IAM Access Analyzer, um Ressourcenrichtlinien zu identifizieren, die Daten kontoübergreifend freigeben, und um passgenaue Richtlinien aus CloudTrail-Aktivitäten zu generieren. Nutzen Sie Daten zum letzten Zugriff (

undefined

), um ungenutzte Service-Berechtigungen aus Rollen zu entfernen.

Eine letzte Falle, die es wert ist, explizit benannt zu werden: die Annahme, dass das Hinzufügen eines „Allow“ in der Identitätsrichtlinie ausreicht. Wenn eine KMS-Schlüsselrichtlinie Ihre Rolle nicht nennt, ein SCP die Aktion verweigert oder eine Berechtigungsgrenze sie auslässt, schlägt der Aufruf dennoch fehl. Überprüfen Sie bei der Fehlerbehebung von AccessDenied immer den gesamten Stack – SCP, Berechtigungsgrenze, Identitätsrichtlinie, Ressourcenrichtlinie und Sitzungsrichtlinie.

Praktisches Problem: Anwendungsszenario

Szenario: Meridian Financial betreibt eine AWS Organization mit drei Konten für Management-, Produktions- und Entwicklungs-Workloads, wobei sich sensible Handels- und Kundendaten im Produktivkonto befinden. Sie haben derzeit eine Mischung aus veralteten, langlebigen IAM-Benutzern, Konten für Auftragnehmer und einem Okta-SAML-Identitätsanbieter, was zu inkonsistenten Zugriffskontrollen und verteilten Rollenkonfigurationen über die Konten hinweg führt.

Herausforderung: Bei einem kürzlichen Vorfall haben kompromittierte Anmeldeinformationen eines Auftragnehmers eine kontoübergreifende Rolle ohne MFA übernommen und übermäßige Aktionen durchgeführt, da es keine Berechtigungsgrenzen oder zentralisierten Berechtigungssätze gab. Meridian muss die Föderation und die Rollen-Vertrauensstellungen härten sowie MFA und das Prinzip der geringsten Rechte kontoübergreifend durchsetzen.

Empfohlener Ansatz:

Bereitstellung von AWS IAM Identity Center, integriert mit Okta SAML, als einzige föderierte Identitätsebene und Migration aller menschlichen Benutzer und Auftragnehmer von langlebigen IAM-Benutzern zu Identity-Center-basierten Konten, wobei Konsole/Schlüssel für veraltete IAM-Benutzer deaktiviert werden.
Erstellung zentralisierter Berechtigungssätze im IAM Identity Center, die auf IAM-Rollen in Mitgliedskonten abgebildet werden, und Implementierung von IAM-Berechtigungsgrenzen (definiert als IAM-Richtlinien) für alle Rollen; Bereitstellung dieser Grenzen und Rollenvorlagen über Konten hinweg mithilfe von AWS CloudFormation StackSets.
Aktualisierung der Vertrauensrichtlinien für kontoübergreifende Rollen, sodass sie sts:AssumeRole nur von den Prinzipal-ARNs des Identity Centers erlauben und Bedingungen enthalten, die MFA (z. B. aws:MultiFactorAuthPresent) und Einschränkungen für das Quellkonto erfordern; Vorschreiben, dass Sitzungs-Tags Identitätsattribute tragen.
Durchsetzung von MFA beim IdP (Okta) und Widerspiegelung dieser Durchsetzung in AWS, indem MFA-Bedingungen für Rollensitzungen gefordert werden; Verweigerung der Erstellung von Konsolenzugriff oder neuen IAM-Benutzern durch die Anwendung von Service Control Policies (SCPs) in AWS Organizations.
Aktivierung von AWS CloudTrail, AWS Config und IAM Access Analyzer zur kontinuierlichen Überwachung und Validierung von Richtlinien und Senden der Ergebnisse an CloudWatch/GuardDuty für Alarmierung und automatisierte Behebungsworkflows.

Begründung: Die Zentralisierung der Föderation über das IAM Identity Center, die Durchsetzung des Prinzips der geringsten Rechte mit Berechtigungssätzen und -grenzen, die Forderung nach MFA in Vertrauensrichtlinien und die Anwendung von SCPs auf Organisationsebene sowie die Überwachung entsprechen den AWS Best Practices, um den Schadensradius zu reduzieren, Rechteausweitung zu verhindern und Überprüfbarkeit zu gewährleisten.

IAM-Rollen und Vertrauensrichtlinien: PassRole und AssumeRole

Eine IAM-Rolle hat zwei unterschiedliche Richtlinienoberflächen, und deren Verwechslung ist die Hauptursache für die meisten kontoübergreifenden Autorisierungsfehler. Die Vertrauensrichtlinie (das AssumeRolePolicyDocument) beantwortet, wer die Rolle übernehmen kann und unter welchen Bedingungen. Die Berechtigungsrichtlinie beantwortet, was die Rolle nach der Übernahme tun kann. Beide müssen die Aktion erlauben; die Vertrauensrichtlinie allein gewährt niemals Zugriff auf S3, KMS oder irgendetwas anderes.

Wenn ein Prinzipal sts:AssumeRole aufruft, wertet STS die Vertrauensrichtlinie der Zielrolle anhand der aufrufenden Identität sowie des Sitzungskontexts (Quell-IP, MFA-Status, Sitzungs-Tags, externe ID) aus. Der aufrufende Prinzipal muss zusätzlich eine identitätsbasierte Allow-Berechtigung für sts:AssumeRole auf den ARN dieser Rolle haben. Diese doppelte Anforderung macht die Rollenübernahme über Kontogrenzen hinweg sicher.

Eine kanonische kontoübergreifende Vertrauensrichtlinie, die MFA und eine externe ID erfordert, sieht wie folgt aus:

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

Der Schlüssel aws:MultiFactorAuthPresent ist nur in der Vertrauensrichtlinie einer übernehmbaren Rolle von Bedeutung, da der MFA-Kontext beim STS-Aufruf hergestellt wird, nicht bei nachgelagerten Service-Aufrufen. Das Hinzufügen von MFA-Bedingungen zur S3-Bucket-Richtlinie oder zur Berechtigungsrichtlinie der Rolle ist ein häufiger Fehler: Die Sitzung der übernommenen Rolle trägt normalerweise nicht aws:MultiFactorAuthPresent=true, selbst wenn sich der ursprüngliche menschliche Benutzer mit MFA authentifiziert hat, sodass diese Bedingungen stillschweigend alles verweigern. Erzwingen Sie MFA zum Zeitpunkt der Übernahme; verwenden Sie aws:MultiFactorAuthAge, um eine erneute Authentifizierung für langlebige Sitzungen zu erzwingen.

PassRole ist die zweite Hürde, die in Prüfungsszenarien zu Fehlern führt. Wenn Sie einem Dienst wie CloudFormation, EC2, Lambda oder CodeBuild anweisen, als eine Rolle ausgeführt zu werden, muss die aufrufende Identität die Berechtigung iam:PassRole haben.

Praktisches Problem: Anwendungsfallszenario

Szenario: Meridian Financial betreibt eine AWS Organization mit mehreren Konten für Produktion, Entwicklung und CI/CD-Tooling; sie verwenden zentralisierte IAM-Rollen für kontoübergreifende Deployments und CI-Agents von Drittanbietern, die Rollen übernehmen, um Infrastrukturänderungen durchzuführen. Identitätsgrenzen werden durch Vertrauensrichtlinien für Rollen durchgesetzt, und einige Teams verwenden langlebige Instanzprofile und Lambda-Funktionen, denen iam:PassRole gewährt wird, um Rollen an Instanzen oder Tasks anzuhängen.

Herausforderung: Eine kürzlich durchgeführte Prüfung ergab eine zu weitreichende iam:PassRole-Berechtigung, die es einem CI/CD-Prinzipal ermöglichte, eine Administrator-Rolle an ein EC2-Instanzprofil zu übergeben. Ein Angreifer nutzte ein AssumeRole-Vertrauen aus, um übermäßige Berechtigungen über Konten hinweg zu erlangen.

Empfohlene Vorgehensweise:

Verwenden Sie AWS CloudTrail und Amazon EventBridge, um kürzliche iam:PassRole- und sts:AssumeRole-API-Aufrufe zu identifizieren, und führen Sie Abfragen in CloudTrail Lake oder Athena aus, um aufzulisten, welche Prinzipale welche Rollen-ARNs wann übergeben haben.
Führen Sie IAM Access Analyzer (für IAM) kontoübergreifend aus, um ressourcenbasierte Vertrauensrichtlinien-Expositionen aufzudecken und Rollen aufzulisten, die von außerhalb der Organisation oder von externen Prinzipalen übernommen werden können.
Ersetzen Sie weitreichende iam:PassRole-Richtlinien durch IAM-Richtlinien mit den geringsten Rechten, die genaue Rollen-ARNs in Resource angeben, und fügen Sie Bedingungsschlüssel wie aws:PassedToService oder aws:PrincipalOrgID hinzu, um einzuschränken, wer und was die Rolle erhalten kann.
Härten Sie die Vertrauensrichtlinien für Rollen, um Bedingungen zu erfordern – verwenden Sie aws:PrincipalOrgID, sts:ExternalId für Drittanbieter, fordern Sie aws:SourceIdentity und erzwingen Sie maximale Sitzungsdauern –, um eine weitreichende Übernahme der Rolle (AssumeRole) durch unbekannte Prinzipale zu verhindern.
Konfigurieren Sie Amazon EventBridge-Regeln, um iam:PassRole- und AssumeRole-Anomalien zu erkennen, senden Sie Warnungen an Amazon SNS und erstellen Sie automatisierte Lambda-Playbooks, um zu weitreichende Richtlinien zu widerrufen oder zu korrigieren, und zeichnen Sie die Ergebnisse in AWS Security Hub und AWS Config für eine kontinuierliche Compliance auf.

Begründung: Dieser Ansatz setzt das Prinzip der geringsten Rechte und der tiefgreifenden Verteidigung (Defense-in-Depth) durch, indem er die PassRole-Ziele und Vertrauensrichtlinien verschärft und gleichzeitig die Erkennung und automatische Behebung durch Protokollierung und Überwachung ermöglicht – im Einklang mit den Best Practices von AWS für IAM und Föderation.

Alle Domänen · Bedrohungserkennung und Alarmierung →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →