← Zurück zur Übersicht

AWS SCP Guardrails: Fünf Service Control Policies für eine sichere Organisation

Service Control Policies (SCPs) setzen in AWS Organizations Grenzen, die kein Administrator in einem Member-Account aufheben kann. Fünf gezielte Policies reichen aus, um die häufigsten Fehlkonfigurationen zu verhindern: einen ungeschützten Root User, abgeschaltetes CloudTrail-Logging, Ressourcen in unerwünschten Regionen, angreifbare Instanz-Metadaten und öffentlich zugängliche S3-Buckets.

Im Dezember habe ich gezeigt, wie sich der AWS Root User mit SCPs einschränken lässt. Das zugehörige GitHub-Repository aws-scp-examples ist seitdem zu einer kleinen Sammlung von Sicherheits-Guardrails gewachsen. Dieser Artikel stellt alle fünf Policies vor und erklärt, worauf Sie beim Ausrollen achten sollten.

Warum SCPs die erste Verteidigungslinie sind

IAM-Policies regeln, was eine Identität in einem Account tun darf. Wer dort Administratorrechte besitzt, kann diese Policies aber jederzeit ändern. SCPs wirken eine Ebene darüber: Sie definieren die maximal verfügbaren Berechtigungen eines Accounts oder einer Organizational Unit (OU). Ein Deny in einer SCP gilt auch für Administratoren und den Root User des Member-Accounts.

Wichtig ist, was SCPs nicht tun: Sie gewähren keine Berechtigungen, sie filtern nur. Außerdem gelten sie nicht für den Management-Account der Organisation und nicht für Service-Linked Roles. Der Management-Account sollte deshalb ohnehin keine Workloads beherbergen.

Fünf Guardrails im Überblick

Jede Policy im Repository adressiert ein konkretes Risiko und ist als eigenständige JSON-Datei abgelegt. Sie lassen sich einzeln oder kombiniert an OUs anhängen:

• Root User komplett sperren: root-user-block-all.json verbietet dem Root User jede Aktion. Das ist die richtige Wahl für die meisten Workload-Accounts.
• Root User als Break-Glass-Zugang: root-user-basic.json erlaubt nur das Entsperren fehlkonfigurierter S3-Bucket-, SQS- und SNS-Policies sowie die Verwaltung der eigenen MFA. Zusätzlich sind Anfragen nur von vertrauenswürdigen IP-Adressen zulässig, und der Root User darf keine MFA-Geräte anderer IAM-User verändern.
• Basis-Sicherheit der Organisation: basic-org-security-settings.json verhindert, dass CloudTrail gestoppt, gelöscht oder umkonfiguriert wird, dass ein Account die Organisation verlässt und dass Ressourcen außerhalb der freigegebenen Regionen entstehen. Globale Dienste wie IAM, CloudFront oder Route 53 sind von der Regionssperre ausgenommen, ebenso die Control-Tower-Ausführungsrolle.
• IMDSv2 erzwingen: enforce-imdsv2.json blockiert API-Aufrufe mit Credentials, die über IMDSv1 bezogen wurden, verlangt IMDSv2 beim Start neuer EC2-Instanzen, begrenzt das Hop-Limit auf maximal 2 und schützt die Metadaten-Einstellungen vor nachträglichen Änderungen.
• S3 Block Public Access sperren: protect-s3-account-public-access-block.json verhindert, dass die Account-weite Einstellung für S3 Block Public Access verändert wird. Nur die zentrale Administratorrolle aus IAM Identity Center ist ausgenommen.

Ausnahmen bewusst gestalten

Eine Guardrail, die jede Änderung verbietet, wird früher oder später zum Hindernis. Deshalb arbeiten mehrere Policies mit gezielten Ausnahmen über den Bedingungsschlüssel aws:PrincipalArn. Die Metadaten- und S3-Einstellungen darf nur die AdministratorAccess-Rolle aus IAM Identity Center ändern, der Platzhalter im ARN macht die Ausnahme dabei unabhängig von der Region, in der Identity Center läuft. Die Regionssperre nimmt die Rolle aus, mit der AWS Control Tower Accounts verwaltet.

Bei der IMDSv2-Policy steckt die Ausnahme in der Logik selbst: Der Schlüssel ec2:RoleDelivery ist nur bei Anfragen mit Instanz-Credentials gesetzt. Aufrufe von Benutzern, Lambda-Funktionen oder Containern ohne EC2-Rolle sind daher nicht betroffen. Das Hop-Limit von 2 erlaubt weiterhin Container auf EC2-Instanzen, die IMDSv2 über eine zusätzliche Netzwerkschicht erreichen.

SCPs sicher ausrollen

Bevor Sie die Policies einsetzen, ersetzen Sie die Platzhalter: die IP-Adresse 203.0.113.10/32 für den Break-Glass-Zugang, die erlaubten Regionen sowie die ARNs Ihrer Administratorrollen. Hängen Sie jede SCP zuerst an eine Test-OU mit einem nicht produktiven Account und prüfen Sie Ihre Deployment-Pipelines, bevor Sie die Policy auf weitere OUs ausweiten.

Beachten Sie auch die Limits von AWS Organizations: Eine SCP darf maximal 5.120 Zeichen umfassen, und pro Root, OU oder Account lassen sich höchstens fünf SCPs anhängen. Die Policies im Repository sind deshalb thematisch getrennt und bleiben deutlich unter der Größengrenze, sodass Sie sie flexibel kombinieren können.

Fazit

Fünf kompakte SCPs schließen die häufigsten Lücken in einer AWS-Organisation, und zwar zentral und unabhängig davon, wie sorgfältig einzelne Teams ihre Accounts konfigurieren. Mit sauber definierten Ausnahmen und einem schrittweisen Rollout bleiben sie wirksam, ohne den Betrieb zu behindern.

← Zurück zur Übersicht