Du vergibst im Mitgliedskonto großzügig Rechte, hängst AdministratorAccess an eine Rolle, und trotzdem schlägt eine simple Aktion fehl. Kein Tippfehler, keine fehlende Policy. Eine Ebene über dem Konto greift eine Service Control Policy (SCP), und die sticht jede IAM-Policy im Konto aus. Dieser Artikel zeigt, warum das so ist, wo die eine dokumentierte Ausnahme liegt und wie du eine SCP vor dem Rollout testest statt sie live zu erleben.

Das Missverständnis: Admin-Rechte im Konto reichen nicht

IAM-Policies gelten innerhalb eines einzelnen AWS-Accounts. Eine SCP liegt eine Ebene darüber, auf AWS-Organizations-Ebene, und wird auf Organisationseinheiten (OUs) oder einzelne Mitgliedskonten angehängt. Die AWS-Dokumentation zu Service Control Policies sagt es direkt: eine SCP gewährt niemals Berechtigungen, sie zieht nur eine Obergrenze. Wörtlich: „an SCP never grants permissions“. Egal wie weit du IAM im Konto öffnest, die SCP kann das Ergebnis trotzdem kappen.

Deny statt Allow: die eigentliche Wirkung

Das Zusammenspiel ist eine Schnittmenge, keine Vereinigung. Was am Ende erlaubt ist, ergibt sich aus der logischen Schnittmenge dessen, was die SCP zulässt, und dessen, was die identitätsbasierte oder ressourcenbasierte Policy im Konto erlaubt. Eine SCP kann in zwei Modi arbeiten: als reine Deny-Liste, die bestimmte Aktionen organisationsweit sperrt, oder als Allow-Liste, wenn du die Standardpolicy FullAWSAccess ersetzt und nur noch explizit aufgeführte Services zulässt. In beiden Fällen gilt laut Dokumentation: eine SCP schränkt die Berechtigungen für IAM-User und -Rollen in Mitgliedskonten ein, einschließlich des Root-Users des Mitgliedskontos, selbst wenn der Kontoadministrator die AdministratorAccess-Policy mit */*-Rechten an den User hängt.

Root-User ist mitgemeint, nicht ausgenommen

Das ist der Teil, der am häufigsten unterschätzt wird. Eine SCP betrifft laut AWS-Dokumentation alle User und Rollen eines angehängten Kontos, inklusive Root-User, selbst wenn der Kontoadministrator die AdministratorAccess-Policy an den User hängt. Das ist keine Randnotiz, sondern die Kernaussage der ganzen Seite. Eine Umschreibung über besonders privilegierte Rollen ändert daran nichts, die SCP wertet Konto für Konto aus, nicht Rolle für Rolle.

Die wichtigste dokumentierte Ausnahme: der Management-Account

Die zentrale Ausnahme betrifft den Management-Account der Organisation selbst: er ist von den SCPs ausgenommen, die er auf andere Konten anwendet. SCPs wirken nur auf Mitgliedskonten, inklusive delegierter Administratorkonten, nicht auf User und Rollen im Management-Account selbst. Wer also im Management-Account arbeitet, bewegt sich außerhalb der eigenen Guardrails, was ein eigenes Risiko ist und kein Freifahrtschein. Daneben dokumentiert AWS eine Handvoll weiterer, enger gefasster Ausnahmen, etwa bestimmte service-linked roles und einzelne Root-Aktionen bei Enterprise Support, CloudFront-Schlüsselpaaren oder Lightsail-DNS-Zonen. Für den Alltag einer Organisationsstruktur ist die Management-Account-Ausnahme trotzdem die praktisch relevante.

Guardrail-Beispiel: CloudTrail vor dem Abschalten schützen

Ein klassisches Einsatzbeispiel ist der Schutz von Audit-Logging vor dem eigenen Kontoadministrator. Die folgende SCP verhindert, dass irgendeine Rolle in den betroffenen Konten den CloudTrail-Trail stoppt, löscht oder umkonfiguriert, unabhängig davon, welche IAM-Rechte sonst vergeben sind:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyCloudTrailTampering",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:StopLogging",
        "cloudtrail:DeleteTrail",
        "cloudtrail:UpdateTrail"
      ],
      "Resource": "*"
    }
  ]
}

Hängst du diese SCP an eine OU, gilt sie für jedes Konto darunter, Deny schlägt dabei jedes Allow auf jeder tieferen Ebene. Genau diese Eigenschaft macht Deny-Statements zum Werkzeug für organisationsweite Guardrails, nicht einzelne IAM-Policies im Konto.

SCPs testen, bevor sie live gehen

AWS rät ausdrücklich davon ab, eine neue SCP direkt an den Root der Organisation zu hängen, ohne ihre Wirkung getestet zu haben. Zwei Wege ohne Risiko für den Produktivbetrieb:

• Der IAM Policy Simulator kann SCPs in die Auswertung einbeziehen und dir für eine gewählte Identität zeigen, ob eine Aktion am Ende erlaubt oder verweigert wird. Die simulierten Policies werden dabei nirgendwo gespeichert oder tatsächlich angehängt.
• aws organizations list-policies-for-target --target-id <ID> --filter SERVICE_CONTROL_POLICY zeigt dir, welche SCPs an einem konkreten Root, einer OU oder einem Konto aktuell direkt hängen, bevor du eine neue Policy aufsetzt.

Teste neue SCPs zuerst an einer einzelnen OU mit wenigen Konten, nicht am Organisations-Root.

Abgrenzung zum IAM-Artikel

Im Beitrag AWS IAM ohne Schmerzen ging es um Rollen und Policies innerhalb eines einzelnen AWS-Accounts. Hier liegt die Ebene darüber: die Organisationsgrenze über mehrere Konten, Deny-only-Wirkung statt Rechtevergabe, und der Root-User ist mitbetroffen statt ausgenommen.

Wenn du deine Organisationsstruktur gegen genau diese Guardrails prüfen willst, schreib mir an mm@mhm-dl.de.

Über das Anmeldeformular für den Newsletter trägst du deine E-Mail-Adresse ein, kreuzt die Einwilligung an und bestätigst die Anmeldung danach per Mail. Mit der Anmeldung willigst du ein, dass der Newsletter unter anderem folgende Themen behandelt: Schulungen zu Docker, Kubernetes, CI/CD, Git-Workflows und DevSecOps-Werkzeugen sowie die Anforderungen aus NIS2, CRA und DORA und deren technische Umsetzung.