Konten, Umgebungen und IAM-Grenzen

Prüfungsbezug: Domain 1.1 und 1.4: sichere Pipelines und Deployment-Strategien über Umgebungen und Konten hinweg implementieren.

Lernziel

Einen kontenübergreifenden Deployment-Pfad mit AWS-Konten, IAM-Rollen, Trust Policies, Berechtigungsrichtlinien, temporären STS-Zugangsdaten, S3-Artefaktzugriff, KMS-Key-Policies und Organisationsleitplanken entwerfen und untersuchen.

Schwierigkeitsgrad	Mittel
Lernzeit	180 Minuten
Voraussetzungen	IAM-Rollen und -Richtlinien, AWS-Organizations-Grundlagen und Pipeline-Artefakte

Berufliches Szenario

Entwicklung und Produktion teilen ein AWS-Konto und eine Administratorrolle. Entwickler können Produktionsressourcen verändern, und die Pipeline verwendet dieselben Rechte wie die Anwendung zur Laufzeit. Artefakte werden vor einem Release manuell kopiert.

Die Organisation möchte ein zentrales Bereitstellungskonto, getrennte Entwicklungs- und Produktionskonten, verschlüsselte Artefakte, keine gespeicherten Deployment-Schlüssel und einen Nachweis jeder Produktionssitzung.

„Mehrere Konten verwenden“ löst das Problem noch nicht. Die vollständige Anfrage muss an jeder überschrittenen Grenze autorisiert werden.

Warum Konten Umgebungsgrenzen sind

Ein AWS-Konto bildet eine starke Grenze für Identitäten, Quotas, Abrechnung, Dienstkonfiguration und Ressourceneigentum. Getrennte Produktions- und Nichtproduktionskonten verringern die Wahrscheinlichkeit, dass eine Entwicklungsidentität, ein Automatisierungsfehler, ein Quota-Ereignis oder ein kompromittierter Workload Produktion beeinträchtigt.

Eine häufige Struktur sieht so aus:

Organisation
|
+-- Tooling-Konto
|     +-- Source-Verbindung
|     +-- CodePipeline
|     +-- CodeBuild
|     +-- verschlüsselter Artefakt-Bucket
|
+-- Entwicklungskonto
|     +-- Deployment-Rolle
|     +-- Entwicklungs-Workload
|
+-- Produktionskonto
      +-- Deployment-Rolle
      +-- Produktions-Workload

Das Tooling-Konto orchestriert. Die Zielkonten besitzen ihre Ressourcen und bestimmen, was die Tooling-Pipeline ausführen darf. Die Pipeline erhält keine dauerhaften Zugangsdaten für die Zielkonten.

Die kontenübergreifende Autorisierungskette

Damit ein Principal aus dem Tooling-Konto eine Deployment-Rolle in Produktion verwenden kann, müssen beide Seiten zustimmen.

1. Die Pipeline- oder Action-Rolle im Tooling-Konto benötigt die Erlaubnis, sts:AssumeRole für die Zielrolle aufzurufen.
2. Die Trust Policy der Zielrolle muss dem genau festgelegten Tooling-Principal vertrauen.
3. AWS STS liefert temporäre Zugangsdaten für eine angenommene Rollensitzung.
4. Die Berechtigungsrichtlinie der Zielrolle muss die erforderlichen Deployment-Actions erlauben.
5. Resource Policies müssen den Zugriff erlauben, wenn der Zieldienst sie verwendet.
6. KMS-Key-Policy und IAM-Berechtigung müssen kryptografische Operationen für verschlüsselte Daten zulassen.
7. SCPs, Permissions Boundaries, Session Policies und ausdrückliche Denies dürfen die Anfrage nicht blockieren.

Ein Allow in einer Ebene hebt niemals ein ausdrückliches Deny in einer anderen Ebene auf. AdministratorAccess an der Zielrolle behebt weder ein SCP-Deny noch eine KMS-Key-Policy, die die Rolle nicht autorisiert.

Trust Policy und Berechtigungsrichtlinie

Die Trust Policy beantwortet: Wer darf eine Sitzung für diese Rolle erhalten? Die Berechtigungsrichtlinie der Rolle beantwortet: Was darf diese Sitzung nach der Rollenannahme ausführen?

Beispiel für die Trust Policy einer Produktions-Deployment-Rolle:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111111111111:role/CodePipelineActionRole"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Die Tooling-Action-Rolle benötigt außerdem eine Identity Policy, die den Aufruf erlaubt:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::222222222222:role/ProductionDeploymentRole"
    }
  ]
}

Diese Richtlinien ermöglichen die Rollenannahme, gewähren aber noch keine Deployment-Rechte. Eine getrennte Richtlinie an ProductionDeploymentRole sollte nur die Dienste, Actions und Ressourcen erlauben, die der gewählte Deployment-Mechanismus benötigt.

Vertraue nicht einem vollständigen Konto, wenn eine bestimmte Rolle genügt. Verwende auch keine breite Zielrichtlinie, nur weil die Pipeline vertrauenswürdig ist. Vertrauen und Autorisierung sind zwei getrennte Least-Privilege-Entscheidungen.

Temporäre Zugangsdaten und Sitzungsnachweise

AssumeRole liefert Access Key ID, Secret Access Key und Session Token mit begrenzter Gültigkeit. Die Pipeline verwendet diese Zugangsdaten für die Ziel-Action und verwirft sie nach Ende der Sitzung.

CloudTrail protokolliert die Rollenannahme und nachfolgende API-Aufrufe der angenommenen Rollensitzung. Ein aussagekräftiger Sitzungsname und konsistente Pipeline-Metadaten verbessern die Nachvollziehbarkeit. Nachweise sollten Folgendes verbinden:

• Pipeline- und Ausführungs-ID
• Quellcodeversion und Artefakt-Digest
• ursprüngliche Action-Rolle
• Zielrolle und Sitzung
• Zielkonto und Region
• Deployment-API-Aufrufe und Ergebnis

Temporäre Zugangsdaten senken das Risiko eines offengelegten Langzeitschlüssels, gleichen aber keine überprivilegierte Rolle aus. Sitzungsdauer und Rechte müssen zur Aufgabe passen.

Verschlüsselte kontenübergreifende Artefakte

Kontenübergreifende Deployments scheitern häufig am Artefaktpfad und nicht an AssumeRole.

Für ein verschlüsseltes Artefakt im Tooling-Konto sind alle Autorisierungspunkte zu betrachten:

1. Pipeline-Action-Rolle: Darf die Ziel-Deployment-Rolle annehmen.
2. Ziel-Deployment-Rolle: Darf die erforderlichen S3-Actions für Artefaktobjekt und gegebenenfalls Bucket ausführen.
3. S3-Bucket-Policy: Erlaubt den festgelegten Ziel-Principal und enthält kein widersprechendes Deny.
4. KMS-IAM-Berechtigung: Erlaubt erforderliche Operationen wie kms:Decrypt für den Schlüssel.
5. KMS-Key-Policy: Erkennt die Zielrolle oder delegiert Berechtigungen passend.
6. Verschlüsselungskontext und Bedingungen: Stimmen mit der Anfrage überein, falls die Richtlinien sie einschränken.
7. Organisationsleitplanken: Verweigern S3-, KMS-, STS- oder Deployment-Actions nicht.

Für kontenübergreifende CodePipeline-Actions sollte der Artefaktspeicher einen kundenverwalteten KMS-Schlüssel verwenden, der je nach Design über Key ID oder ARN angegeben wird. Ein KMS-Alias ist nur im besitzenden Konto eindeutig und darf nicht als universeller kontenübergreifender Bezeichner betrachtet werden.

Identitäten für Menschen, Pipeline, Deployment und Laufzeit

Identitäten dürfen nicht zusammengelegt werden, nur weil sie auf dieselbe Anwendung zugreifen.

Identität	Zweck	Typische Rechte
Föderierte menschliche Rolle	Untersuchung oder genehmigte Betriebsaktion	Lesezugriff plus eng begrenzte Betriebsaktionen
Pipeline-Service-Rolle	Pipeline-Actions orchestrieren	Actions starten, genehmigte Rollen weitergeben, Pipeline-Artefakte lesen
Kontenübergreifende Deployment-Rolle	Ressourcen über einen Deployment-Mechanismus ändern	Begrenzte Deployment-APIs und Artefaktzugriff
Workload-Rolle zur Laufzeit	Abhängigkeiten der Anwendung aufrufen	Nur APIs, die die Anwendung zur Laufzeit benötigt
Notfallrolle	Wiederherstellung unter außergewöhnlicher Kontrolle	Zeitlich begrenzt, überwacht und getrennt freigegeben

Wird die Deployment-Rolle zur Laufzeit verwendet, kann eine kompromittierte Anwendung Infrastrukturänderungsrechte erhalten. Verwenden Entwickler die Pipeline-Rolle interaktiv, bildet der Audit Trail automatisierte Bereitstellung nicht mehr zuverlässig ab.

Durchgängiger Anfragepfad

CodePipeline im Konto 111111111111 deployt ein verschlüsseltes Artefakt in Produktionskonto 222222222222.

1. CodePipeline ruft eine Action mit CodePipelineActionRole auf.
2. Diese Rolle ruft sts:AssumeRole für ProductionDeploymentRole auf.
3. STS bewertet die Berechtigung des Aufrufers und die Trust Policy der Zielrolle.
4. Die angenommene Zielrolle fordert das Artefakt aus dem Tooling-S3-Bucket an.
5. S3 bewertet IAM- und Bucket-Policy.
6. KMS bewertet IAM-Berechtigung und Key Policy vor der Entschlüsselung.
7. Der Ziel-Deployment-Dienst bewertet Rechte und Ressourcenbedingungen der Zielrolle.
8. CloudTrail in den beteiligten Konten zeichnet Rollensitzung und Dienstaufrufe auf.

Bei einem Fehler muss der erste fehlerhafte Pfeil gefunden werden. Beginne nicht damit, alle Richtlinien zu erweitern.

Systematische Untersuchung von AccessDenied

1. Exakte API, Ressourcen-ARN, Konto, Region, Principal-ARN und Fehlerzeit erfassen.
2. Prüfen, ob der Aufrufer die erwartete angenommene Rollensitzung und nicht eine ähnlich benannte menschliche oder Service-Rolle ist.
3. Bei Rollenannahme sowohl Aufruferberechtigung als auch Ziel-Trust-Policy prüfen.
4. Für die Ziel-Action Rollenrichtlinie sowie Permissions Boundary und Session Policy prüfen.
5. Resource Policy für S3, KMS, ECR, Secrets Manager oder einen anderen ressourcenbasierten Dienst prüfen.
6. Bei verschlüsselten Daten die KMS-Key-Policy getrennt prüfen.
7. SCPs und ausdrückliche Deny-Bedingungen prüfen.
8. Condition Keys wie Konto, ARN, Region, Tag, Source ARN, Verschlüsselungskontext und VPC Endpoint prüfen.
9. Mit CloudTrail und Dienstereignissen die erste verweigerte Anfrage finden.
10. Nur die engste fehlerhafte Aussage korrigieren und erneut testen; keine breite Administratorrichtlinie als Diagnoseabkürzung anhängen.

Entscheidungsmatrix

Anforderung	Bevorzugte Richtung	Begründung
Starke Umgebungsisolation	Getrennte Konten	Reduziert Blast Radius und klärt Eigentum
Kontenübergreifendes Deployment	STS AssumeRole	Liefert temporäre begrenzte Sitzungen
Menschlicher Produktionszugriff	Föderation in eine eigene Rolle	Zentrale Verwaltung und Sitzungsnachweise
Verschlüsselte gemeinsame Artefakte	S3 plus kundenverwalteter KMS-Schlüssel und ausdrückliche Richtlinien	Ermöglicht kontrollierte kontenübergreifende Autorisierung
Unabhängige Anwendungslaufzeit	Getrennte Workload-Rolle	Verhindert Deployment-Rechte zur Laufzeit
Notfallzugriff	Überwachte Notfallrolle	Trennt Ausnahmezugriff vom normalen Bereitstellungsweg

Fehlerbilder und Fehlersuche

Symptom	Wahrscheinlich fehlende Grenze
AssumeRole wird verweigert	Aufruferrichtlinie, Ziel-Trust-Policy, Boundary oder SCP
S3 GetObject wird verweigert	Rollenrichtlinie, Bucket-Policy, Objekt-ARN oder ausdrückliches Deny
S3 erfolgreich, Entschlüsselung fehlerhaft	KMS-IAM-Berechtigung, Key Policy, Schlüsselbezeichner oder Verschlüsselungskontext
Deployment kann fremde Ressourcen ändern	Zielrollenrichtlinie ist zu breit
Pipeline funktioniert, Audit-Verantwortung ist unklar	Rollen werden geteilt oder Sitzungsmetadaten sind schwach
Deployment-Dienst kann Artefakt nicht lesen	Service-Rolle, Deployment-Rolle oder Artefakteigentum ist falsch

Sicherheit und Betrieb

• Wenn möglich exakten Rollen-ARNs statt vollständigen Konten vertrauen.
• Zielrechte nach Action, Ressource, Region und Bedingungen begrenzen.
• Getrennte Deployment-Rollen für Produktion und Nichtproduktion verwenden.
• Direkte menschliche Annahme von Automatisierungsrollen verhindern, sofern sie nicht ausdrücklich erforderlich und kontrolliert ist.
• Artefaktlöschung und KMS-Schlüsselverwaltung getrennt vom Deployment schützen.
• Fehlgeschlagene und ungewöhnliche Rollenannahmen überwachen.
• Unbenutzte Rechte prüfen und Sitzungsdauer an den Betriebsbedarf anpassen.

Praxislabor: Vertrauensmodell für zwei Konten

Ziel: Einen vollständigen Autorisierungsentwurf für Tooling- und Produktionskonto erstellen.

Aufgaben

1. Tooling- und Produktionskonto, Artefakt-Bucket, KMS-Schlüssel, Action-Rolle, Deployment-Rolle und Zieldienst zeichnen.
2. Die Aufruferrichtlinie schreiben, die nur die Annahme der Produktionsrolle erlaubt.
3. Die Trust Policy der Zielrolle für die genaue Tooling-Rolle schreiben.
4. Least-Privilege-Rechte für das Ziel-Deployment definieren.
5. Erforderliche S3-Bucket-, Objekt- und KMS-Berechtigungen auflisten.
6. Annahmen zu SCP und Permissions Boundary im Diagramm ergänzen.
7. CloudTrail-Nachweise für Rollenannahme, Artefaktzugriff, Entschlüsselung und Deployment definieren.
8. Diese Fehler getrennt testen oder simulieren: falscher vertrauenswürdiger Principal, fehlendes S3-Objektrecht, fehlende KMS-Key-Policy-Berechtigung und SCP-Deny.
9. Für jeden Fehler die erste fehlgeschlagene API und die engste Richtlinienkorrektur festhalten.
10. Prüfen, dass Entwickleridentität und Workload-Rolle die Deployment-Rolle nicht annehmen können.

Validierungscheckliste

• Die Pipeline kann nur die vorgesehene Zielrolle annehmen.
• Die Trust Policy gewährt selbst keine Deployment-Actions.
• Die Zielrolle kann nur vorgesehene Ressourcen verändern.
• Artefakt- und KMS-Autorisierung sind beide ausdrücklich definiert.
• Menschliche, Pipeline-, Deployment- und Laufzeitidentität bleiben getrennt.
• CloudTrail-Nachweise identifizieren Sitzung und resultierende Aufrufe.
• Ein ausdrückliches Organisations-Deny wird nicht mit einem breiteren IAM-Allow „behoben“.

Kostenkontrolle: Richtlinienentwurf und IAM-Simulation sind kostenlos. Bei echten Ressourcen ein leeres verschlüsseltes S3-Objekt verwenden und Testrollen, Richtlinien, Bucket-Objekte sowie Schlüssel nach ihren Löschregeln entfernen.

Aufräumen

1. Inline- und angehängte Testrichtlinien entfernen.
2. Testrollen löschen, nachdem geprüft wurde, dass keine Pipeline sie verwendet.
3. Einen ausschließlich für das Labor verwendeten Artefakt-Bucket leeren und löschen.
4. Löschung eines Test-KMS-Schlüssels erst nach Prüfung abhängiger verschlüsselter Daten planen.
5. Audit-Nachweise nur entsprechend der vorgesehenen Aufbewahrungsrichtlinie erhalten oder exportieren.

Prüfungsfallen

• AccessDenied mit AdministratorAccess beheben.
• Annehmen, die Trust Policy gewähre auch Rechte für den Zieldienst.
• Aufruferseitige sts:AssumeRole-Berechtigung vergessen.
• S3-Zugriff erlauben, aber KMS-Autorisierung vergessen.
• Ein SCP als zugriffsgewährende Richtlinie betrachten.
• Gespeicherte Access Keys für kontenübergreifendes Deployment verwenden.
• Deployment-Rolle als Workload-Rolle zur Laufzeit wiederverwenden.

Wichtigste Erkenntnisse

• Konten isolieren Umgebungen, doch jede kontenübergreifende Anfrage benötigt eine vollständige Autorisierung.
• Rollenannahme erfordert Aufruferberechtigung und Zielvertrauen.
• Die Berechtigungen der angenommenen Rolle bestimmen die Ziel-Actions.
• Verschlüsselte Artefakte ergänzen unabhängige S3- und KMS-Autorisierungsebenen.
• Ausdrückliche Denies und Organisationsleitplanken überstimmen sonst gültige Allows.
• Getrennte Identitäten erhalten Least Privilege und zuverlässige Audit-Nachweise.

Wiederholungsfragen

1. Was steuert die Trust Policy einer Rolle?
2. Warum benötigt auch der Aufrufer sts:AssumeRole-Berechtigung?
3. Welche Rechte erhält eine angenommene Sitzung?
4. Warum kann S3-Zugriff erfolgreich sein, während die Artefaktentschlüsselung scheitert?
5. Warum löst AdministratorAccess nicht jedes kontenübergreifende Deny?
6. Welche Gefahr entsteht, wenn die Deployment-Rolle als Laufzeitrolle verwendet wird?
7. Welche Nachweise verbinden eine Pipeline-Ausführung mit Produktions-API-Aufrufen?
8. In welcher Reihenfolge sollte eine AccessDenied-Antwort untersucht werden?

Modellantworten

1. Sie definiert, welche Principals die Rolle unter welchen Bedingungen annehmen dürfen.
2. Kontenübergreifende Rollenannahme ist eine Vereinbarung beider Konten. Der vertrauenswürdige Aufrufer muss die Rolle anfordern dürfen, und die vertrauende Rolle muss diesen Aufrufer akzeptieren.
3. Temporäre Zugangsdaten erhalten die Rechte der angenommenen Rolle, weiter begrenzt durch Session Policy, Permissions Boundary, SCPs, Resource Policies und ausdrückliche Denies.
4. S3 und KMS autorisieren getrennt. Rolle und Bucket können GetObject erlauben, während KMS-Key-Policy oder IAM-Richtlinie Decrypt verweigert.
5. SCP, Resource Policy, KMS-Key-Policy, Permissions Boundary, Session Policy oder ausdrückliches Deny können die Anfrage weiterhin blockieren. Ein breites Identity-Allow hebt ein ausdrückliches Deny nicht auf.
6. Ein kompromittierter Workload könnte Infrastrukturänderungsrechte erhalten, und Laufzeitaktivität lässt sich nur schwer von Deployment-Aktivität unterscheiden.
7. CloudTrail-Ereignisse für Rollenannahme und APIs zusammen mit Pipeline-Ausführungs-ID, Quellcodeversion, Sitzungsname, Artefakt-Digest, Konto und Region.
8. Exakte fehlerhafte Anfrage erfassen, tatsächlichen Principal prüfen und danach Aufruferberechtigung, Trust Policy, Zielrechte, Resource Policy, KMS-Policy, Boundaries, SCPs und Bedingungen bis zum ersten Deny untersuchen.

Weiterführende Dokumentation

• Kontenübergreifender Ressourcenzugriff in IAM
• Kontenübergreifende IAM-Richtlinienauswertung
• Kontenübergreifende Pipelines in CodePipeline