Wenn eine AWS Service Control Policy eine Aktion erlaubt, können Nutzer im Konto sie ausführen?

Viele Kandidaten hören „Richtlinie, die erlaubt“ und denken an ein IAM-Allow. In AWS Organizations ist das anders, und ein Irrtum führt zu falscher Sicherheit oder Aussperrung.

Eine Obergrenze, keine Gewährung

Die AWS-Dokumentation ist eindeutig: SCPs „gewähren keine Berechtigungen“ und setzen „eine Leitplanke“ für die Aktionen, die IAM-Nutzer und -Rollen der Organisation ausführen dürfen. Ein Principal braucht eine identitäts- oder ressourcenbasierte Richtlinie, die die Aktion gewährt, und jede SCP oberhalb des Kontos muss sie erlauben. Ein Nutzer ohne IAM-Richtlinie hat keinen Zugriff, selbst wenn die SCPs alles erlauben.

Was SCPs nicht abdecken

SCPs wirken nur auf Mitgliedskonten. Auf Nutzer oder Rollen im Verwaltungskonto und auf dienstverknüpfte Rollen haben sie keine Wirkung. Auch Principals aus Konten außerhalb der Organisation sind nicht betroffen. Deshalb sollte das Verwaltungskonto möglichst wenig enthalten.

Operative Falle

AWS empfiehlt, SCPs vor dem Anhängen an die Root zu testen, über eine OU und mit schrittweisem Verschieben von Konten. Wer die Standardrichtlinie FullAWSAccess ohne Ersatz entfernt, lässt alle Aktionen der Mitgliedskonten scheitern.

Warum die Distraktoren verlocken

„SCPs gewähren Zugriff“ verwechselt sie mit IAM-Allow. „Nur Root“ und „nur das Verwaltungskonto“ kehren den echten Geltungsbereich um.

Was Interviewer hören wollen

„Eine Obergrenze, keine Gewährung — effektive Rechte sind die Schnittmenge“, plus die Ausnahmen für Verwaltungskonto und dienstverknüpfte Rollen.