Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

SCP-Bewertung

Da Sie mehrere Dienststeuerungsrichtlinien (SCPs) auf unterschiedlichen Ebenen anhängen können AWS Organizations, können Sie besser verstehen, wie sie bewertet SCPs werden, um SCPs die richtigen Ergebnisse zu erstellen.

Wie SCPs arbeiten Sie mit Allow

Damit eine Berechtigung für ein bestimmtes Konto erteilt werden kann, muss auf jeder Ebene, vom Stamm bis hin zu jeder OU, im direkten Pfad zum Konto (einschließlich des Zielkontos selbst) eine ausdrückliche Allow Erklärung vorhanden sein. Aus diesem Grund wird bei der Aktivierung SCPs eine AWS verwaltete SCP-Richtlinie mit dem Namen Full AWS Organizations angehängtAWSAccess, die alle Dienste und Aktionen zulässt. Wenn diese Richtlinie auf keiner Organisationsebene entfernt und nicht ersetzt wird, werden alle Konten OUs und Konten unter dieser Ebene daran gehindert, Maßnahmen zu ergreifen.

Sehen wir uns zum Beispiel das in den Abbildungen 1 und 2 gezeigte Szenario an. Damit eine Berechtigung oder ein Dienst für Konto B zugelassen werden kann, muss ein SCP, der die Erlaubnis oder den Dienst gewährt, an Root, die Produktionsorganisation und an Konto B selbst angehängt werden.

Die SCP-Bewertung folgt einem deny-by-default Modell, was bedeutet, dass alle Berechtigungen, die in der nicht ausdrücklich erlaubt SCPs sind, verweigert werden. Wenn SCPs auf keiner der Ebenen, wie Root, Production OU oder Account B, eine Zulassungsanweisung vorhanden ist, wird der Zugriff verweigert.

Abbildung 1: Beispiel für eine Organisationsstruktur mit einer Allow Erklärung, die an Root, Production OU und Account B angehängt ist

Abbildung 2: Beispiel für eine Organisationsstruktur mit fehlender Allow Erklärung bei Production OU und deren Auswirkung auf Account B

Wie SCPs arbeitet man mit Deny

Damit eine Berechtigung für ein bestimmtes Konto verweigert werden kann, kann jeder SCP vom Stamm bis zu jeder OU im direkten Pfad zum Konto (einschließlich des Zielkontos selbst) diese Berechtigung verweigern.

Nehmen wir zum Beispiel an, der Produktionsorganisation ist ein SCP zugeordnet, für den eine ausdrückliche Deny Anweisung für einen bestimmten Dienst angegeben ist. Zufällig ist auch ein weiterer SCP an Root und Account B angehängt, der explizit den Zugriff auf denselben Dienst ermöglicht, wie in Abbildung 3 dargestellt. Infolgedessen wird sowohl Konto A als auch Konto B der Zugriff auf den Dienst verweigert, da eine Ablehnungsrichtlinie, die einer beliebigen Ebene in der Organisation zugewiesen ist, für alle Konten OUs und Mitgliedskonten, die sich darunter befinden, geprüft wird.

Abbildung 3: Beispiel für eine Organisationsstruktur mit einer Deny-Anweisung, die der Produktionsorganisation beigefügt ist, und deren Auswirkungen auf Konto B

Strategie für die Verwendung SCPs

Beim Schreiben können SCPs Sie eine Kombination aus Allow und Deny -Anweisungen verwenden, um beabsichtigte Aktionen und Dienste in Ihrer Organisation zu ermöglichen. DenyKontoauszüge sind ein wirksames Mittel zur Implementierung von Einschränkungen, die für einen größeren Teil Ihrer Organisation gelten sollten, oder OUs weil sie, wenn sie auf Stamm- oder OU-Ebene angewendet werden, sich auf alle Konten auswirken, denen das Unternehmen untersteht.

Sie können beispielsweise eine Richtlinie mithilfe von Deny Kontoauszügen Verhindern, dass Mitgliedskonten die Organisation verlassen auf Stammebene implementieren, die für alle Konten in der Organisation gilt. Ablehnungsaussagen unterstützen auch das Bedingungselement, das bei der Erstellung von Ausnahmen hilfreich sein kann.

AWS Organizations fügt jedem Root, jeder Organisationseinheit und jedem Konto bei der Erstellung ein AWS verwaltetes SCP mit dem Namen Full AWSAccess hinzu. Diese Richtlinie lässt alle Services und Aktionen zu. Sie können Full AWSAccess durch eine Richtlinie ersetzen, die nur eine Reihe von Diensten zulässt, sodass neue Dienste nur zulässig AWS-Services sind, wenn sie durch eine Aktualisierung ausdrücklich zugelassen werden. SCPs Wenn Ihre Organisation beispielsweise nur die Nutzung einer Teilmenge von Diensten in Ihrer Umgebung zulassen möchte, können Sie eine Allow-Anweisung verwenden, um nur bestimmte Dienste zuzulassen.

JSON

{
"Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:*",
                "cloudwatch:*",
                "organizations:*"
            ],
            "Resource": "*"
        }
    ]
}

Eine Richtlinie, die die beiden Aussagen kombiniert, könnte wie das folgende Beispiel aussehen. Sie verhindert, dass Mitgliedskonten die Organisation verlassen, und ermöglicht die Nutzung der gewünschten AWS -Dienste. Der Organisationsadministrator kann die vollständige AWSAccess Richtlinie trennen und stattdessen diese Richtlinie anhängen.

JSON

{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:*",
                "cloudwatch:*",
                "organizations:*"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Deny", 
            "Action":"organizations:LeaveOrganization",
            "Resource": "*" 
        }
    ]
}

Betrachten Sie die folgende Organisationsstruktur und die folgenden Szenarien, um zu demonstrieren, wie mehrere Dienststeuerungsrichtlinien (SCPs) in einer AWS Organisation angewendet werden können.

Szenario 1: Auswirkungen von Deny-Richtlinien

Dieses Szenario zeigt, wie sich Ablehnungsrichtlinien auf höheren Organisationsebenen auf alle unten aufgeführten Konten auswirken. Wenn für die Sandbox-Organisationseinheit sowohl die Richtlinien „ AWS Vollzugriff“ als auch „Zugriff auf S3 verweigern“ gelten und Konto B die Richtlinie „ EC2 Zugriff verweigern“ hat, hat dies zur Folge, dass Konto B nicht auf S3 zugreifen kann (von der Verweigerung auf OU-Ebene) und EC2 (von der Sperrung auf Kontoebene). Konto A hat keinen S3-Zugriff (aufgrund der Sperrung auf OU-Ebene).

Szenario 2: Zulassungsrichtlinien müssen auf jeder Ebene existieren

Dieses Szenario zeigt, wie Richtlinien zum Zulassen funktionieren SCPs. Damit auf einen Dienst zugegriffen werden kann, muss es auf jeder Ebene, vom Stammverzeichnis bis zum Konto, eine ausdrückliche Genehmigung geben. Da für die Sandbox-Organisationseinheit die Richtlinie „ EC2 Zugriff zulassen“ gilt, die den Zugriff auf EC2 Dienste nur ausdrücklich erlaubt, haben Konto A und B nur EC2 Zugriff.

Szenario 3: Auswirkung des Fehlens einer Zulassungsanweisung auf Stammebene

Das Fehlen einer „Zulassen“ -Anweisung auf Stammebene in einem SCP ist eine kritische Fehlkonfiguration, die effektiv den gesamten Zugriff auf AWS Dienste und Aktionen für alle Mitgliedskonten in Ihrer Organisation blockiert.

Szenario 4: Mehrschichtige Deny-Anweisungen und daraus resultierende Berechtigungen

In diesem Szenario wird eine zweistufige Struktur der Organisationseinheit demonstriert. Sowohl die Stammorganisationseinheit als auch die Workload-Organisationseinheit haben „ AWS Vollzugriff“, die Test-OU hat „ AWS Vollzugriff“ mit „ EC2 Zugriff verweigern“ und die Produktionsorganisationseinheit hat „ AWS Vollzugriff“. Somit hat Konto D alle Servicezugriffe, außer dass Konto E EC2 und F den gesamten Servicezugriff haben.

Szenario 5: Erlauben Sie Richtlinien auf OU-Ebene, um den Dienstzugriff einzuschränken

Dieses Szenario zeigt, wie Zulassungsrichtlinien verwendet werden können, um den Zugriff auf bestimmte Dienste einzuschränken. Die Test-OU verfügt über die Richtlinie „ EC2 Zugriff zulassen“, was bedeutet, dass nur EC2 Dienste für Konto D zugelassen sind. Die Produktionsorganisationseinheit behält den „ AWS Vollzugriff“ bei, sodass die Konten E und F Zugriff auf alle Dienste haben. Dies zeigt, wie restriktivere Zulassungsrichtlinien auf OU-Ebene implementiert werden können, während auf der Stammebene umfassendere Genehmigungsrichtlinien beibehalten werden können.

Szenario 6: Die Ablehnung auf Root-Ebene wirkt sich auf alle Konten aus, unabhängig von den Genehmigungen auf niedrigerer Ebene

Dieses Szenario zeigt, dass sich eine Ablehnungsrichtlinie auf Stammebene auf alle Konten in der Organisation auswirkt, unabhängig von den Zulassungsrichtlinien auf niedrigerer Ebene. Für das Stammverzeichnis gelten sowohl die Richtlinien „ AWS Vollzugriff“ als auch „Zugriff auf S3 verweigern“. Obwohl für die Test-OU die Richtlinie „S3-Zugriff zulassen“ gilt, hat die S3-Verweigerung auf Stammebene Vorrang. Konto D hat keinen Dienstzugriff, da die Test-OU nur S3-Zugriff erlaubt, S3 jedoch auf Stammebene verweigert wird. Die Konten E und F können aufgrund der ausdrücklichen Ablehnung auf Stammebene auf andere Dienste mit Ausnahme von S3 zugreifen.