Organizations, OUs und SCP-Strategie

AWS Organizations ermöglicht Ihnen, viele AWS-Konten zentral als eine Struktur zu verwalten. Darin legen Service Control Policies (SCPs) Berechtigungsobergrenzen fest, und Organizational Units (OUs) gruppieren Konten für die Zielauswahl von Richtlinien. Eine gut entworfene Hierarchie ist eine zentrale Fähigkeit für den Governance-Bereich der SCS-C02-Prüfung.

Eine Organisation verfügt an der Spitze über ein Verwaltungskonto (früher Master), einen Root-Container und OUs, die verschachtelt werden können, um Mitgliedskonten zu gruppieren. Richtlinien, die auf einer beliebigen Ebene angehängt sind, werden an alles darunterliegende weitergegeben. Mit diesem Baum können Sie Kontrollen mit nur einer Zuordnung breit oder gezielt anwenden.

Eine Organizational Unit (OU) gruppiert Konten mit gemeinsamen Governance-Anforderungen, beispielsweise eine „Production“-OU, eine „Sandbox“-OU und eine „Security“-OU. Wenn Sie ein SCP an eine OU anhängen, gilt es für jedes darin enthaltene Konto. Ordnen Sie Konten daher nach den Richtlinien, die sie erben sollen.

SCPs werden im Baum nach unten vererbt: Ein Konto unterliegt den SCPs der Root, seiner übergeordneten OUs und seiner eigenen Richtlinien, die gemeinsam ausgewertet werden. Damit eine Aktion zulässig ist, muss sie auf jeder Ebene erlaubt sein. Ein Deny an beliebiger Stelle in der Kette blockiert sie. Diese kumulative Wirkung ist zentral für das Design von SCPs.

Es gibt zwei Strategien. Eine Deny-Liste geht von der standardmäßigen FullAWSAccess-Richtlinie aus und fügt explizite Deny-Anweisungen für Dinge hinzu, die Sie niemals zulassen möchten, etwa das Deaktivieren von CloudTrail. Eine Allow-Liste entfernt FullAWSAccess und führt ausdrücklich nur zulässige Services auf – eine deutlich strengere Vorgehensweise. Die meisten Organisationen beginnen aus Gründen der Flexibilität mit einer Deny-Liste.

Dieses SCP verbietet jedem, die CloudTrail-Protokollierung zu stoppen. Dies ist eine häufig organisationsweit eingesetzte Schutzmaßnahme, damit kein Mitgliedskonto die Prüfprotokollierung ausblenden kann.

Eine wichtige Regel: SCPs gewähren niemals Berechtigungen, sondern legen nur das Maximum fest. Eine Aktion muss sowohl durch ein SCP als auch durch eine IAM-Richtlinie im Konto erlaubt sein. Ein SCP mit Allow-Liste macht Services lediglich für eine Zuweisung verfügbar; IAM muss sie weiterhin gewähren.

SCPs gelten nicht für das Verwaltungskonto und beeinflussen auch serviceverknüpfte Rollen nicht. In manchen Fällen wirken sie sich außerdem nicht auf ressourcenbasierte Richtlinien aus, die Berechtigungen von außerhalb der Organisation gewähren. Wenn Sie diese Ausnahmen kennen, vermeiden Sie falsche Antworten in Szenarien, in denen ein SCP etwas blockieren soll, was es nicht blockieren kann.

Zwei klassische Schutz-SCPs verweigern das Verlassen der Organisation (organizations:LeaveOrganization) und verhindern, dass Mitgliedskonten Sicherheitsservices deaktivieren, etwa GuardDuty, Security Hub, Config und CloudTrail. Werden sie auf der Root-Ebene angewendet, stellen sie sicher, dass sich kein Mitgliedskonto der Governance entziehen oder die Erkennung der Organisation blind schalten kann. Das ist eine dringend empfohlene Basiskonfiguration.

Ein typischer Aufbau: ein grundlegendes SCP mit Deny-Liste auf der Root-Ebene (CloudTrail schützen, das Verlassen der Organisation verhindern, Regionen einschränken), strengere SCPs für die Production-OU und lockerere für eine Sandbox-OU. Wenn Sie Konten nach ihrem Risikoprofil in OUs gruppieren, können Sie die Governance mit minimalem Richtlinienwildwuchs präzise abstimmen.

Organizations strukturiert Konten unter einer Root und einem Verwaltungskonto in OUs. SCPs werden im Baum nach unten vererbt, und eine Aktion benötigt auf jeder Ebene eine Allow-Berechtigung. Wählen Sie eine Strategie mit Deny-Liste (flexibel) oder Allow-Liste (streng), denken Sie daran, dass SCPs nur begrenzen, aber niemals Berechtigungen gewähren, und dass sie nicht für das Verwaltungskonto oder serviceverknüpfte Rollen gelten.

Testen Sie Ihre SCP-Strategie.

AWS Organizations gruppiert Konten unter einer Root und einem Verwaltungskonto in OUs. SCPs werden im Baum nach unten vererbt und erfordern auf jeder Ebene eine Allow-Berechtigung; jede Deny-Berechtigung blockiert. Verwenden Sie eine Strategie mit Deny-Liste (flexibel) oder Allow-Liste (streng). SCPs begrenzen nur, gewähren aber niemals Berechtigungen und gelten nicht für das Verwaltungskonto oder serviceverknüpfte Rollen.