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
Anmerkung
Die Informationen in diesem Abschnitt gelten nicht für deklarative Richtlinientypen, einschließlich Backup-Richtlinien, Tag-Richtlinien, Chat-Anwendungsrichtlinien oder Opt-Out-Richtlinien für KI-Dienste. Weitere Informationen finden Sie unter Grundlegendes zur deklarativen Richtlinienvererbung.
Da Sie in mehrere Service Control Policies (SCPs) auf unterschiedlichen Ebenen in AWS Organizations anfügen können, kann Ihnen das Verständnis, wie SCPs bewertet werden, helfen, SCPs zu erstellen, die zu den richtigen Ergebnissen führen.
So funktionieren SCPs 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 von SCPs eine AWS verwaltete SCP-Richtlinie AWS Organizations mit dem Namen FullAWSAccess angehängt, die alle Dienste
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-Evaluierung folgt einem standardmäßigen Verweigerungsmodell, was bedeutet, dass alle Berechtigungen, die in den SCPs nicht ausdrücklich erlaubt sind, verweigert werden. Wenn in den 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
So arbeiten SCPs 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 untergeordneten Organisationseinheiten und Mitgliedskonten 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 zur Verwendung von SCPs
Beim Schreiben von SCPs können 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 Ihres Unternehmens oder Ihrer Organisationseinheiten gelten sollten, da sie, wenn sie im Stammverzeichnis oder in den Organisationseinheiten angewendet werden, sich auf alle Konten auswirken, die dem Unternehmen unterstehen. OU-level
Tipp
Sie können die Daten des Dienstes, auf den zuletzt zugegriffen wurde, in IAM verwenden, um Ihre SCPs so zu aktualisieren, AWS-Services dass der Zugriff nur auf die benötigten Daten beschränkt wird. Weitere Informationen finden Sie unter Anzeigen der Daten des letzten Zugriffs auf den Organizations-Service für Organizations im IAM-Benutzerhandbuch.
AWS Organizations fügt jedem Root, jeder Organisationseinheit und jedem Konto bei der Erstellung ein AWS verwaltetes SCP mit dem Namen FullWSAccessAllow-Anweisung verwenden, um nur bestimmte Dienste zuzulassen. Sie können wählen, ob FullAWSAccess entweder auf der Stammebene oder auf jeder Ebene ersetzt werden soll. Wenn Sie eine dienstspezifische Zulassungsliste SCP an das Stammverzeichnis anhängen, gilt diese automatisch für alle Organisationseinheiten und Konten darunter. Das bedeutet, dass eine einzige Richtlinie auf Stammebene die effektive Dienstzulassungsliste für die gesamte Organisation festlegt, wie in Szenario 7 gezeigt. Alternativ können Sie FullAWSAccess in jeder Organisationseinheit und jedem Konto entfernen und ersetzen, sodass Sie detailliertere Service-Zulassungslisten implementieren können, die sich je nach Organisationseinheit oder einzelnen Konten unterscheiden.
Hinweis: Wenn Sie sich ausschließlich auf Allow-Anweisungen und das implizite Deny-by-Default-Modell verlassen, kann dies zu unbeabsichtigtem Zugriff führen, da umfassendere oder sich überschneidende Allow-Anweisungen restriktivere Anweisungen außer Kraft setzen können.
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 FullAWSAccess-Richtlinie trennen und stattdessen diese Richtlinie anfügen.
Um zu veranschaulichen, wie mehrere Service Control Policies (SCPs) in einem AWS Unternehmen angewendet werden können, sollten Sie sich die folgende Organisationsstruktur und die folgenden Szenarien ansehen.
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 (von der OU-level Verweigerung) und EC2 (von der Verweigerung auf Kontoebene) zugreifen kann. Konto A hat keinen S3-Zugriff (aufgrund der Sperrung). OU-level
Szenario 2: Zulassungsrichtlinien müssen auf jeder Ebene existieren
Dieses Szenario zeigt, wie Zulassungsrichtlinien in SCPs funktionieren. Damit auf einen Dienst zugegriffen werden kann, muss es auf jeder Ebene, vom Stammverzeichnis bis zum Konto, eine ausdrückliche Genehmigung geben. Da die Sandbox-Organisationseinheit über eine Richtlinie „EC2-Zugriff zulassen“ verfügt, die nur den Zugriff auf EC2-Dienste 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 veranschaulicht. 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 Dienstzugriffe außer EC2 und Konto E und F haben alle Dienstzugriffe.
Szenario 5: Erlauben Sie Richtlinien am OU-level , 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 eine Richtlinie „EC2-Zugriff zulassen“, was bedeutet, dass nur EC2-Dienste für Konto D zulässig 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 der Stammebene implementiert OU-level und gleichzeitig eine umfassendere Zulassung beibehalten werden können.
Szenario 6: Root-level Verweigern wirkt sich auf alle Konten aus, unabhängig von den Genehmigungen auf niedrigerer Ebene
Dieses Szenario zeigt, dass sich eine Ablehnungsrichtlinie auf der Stammebene auf alle Konten in der Organisation auswirkt, unabhängig von den Zulassungsrichtlinien auf niedrigeren Ebenen. 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.
Szenario 7: Benutzerdefiniert auf Stammebene ermöglichen es Richtlinien, den Zugriff einzuschränken OU-level
Dieses Szenario zeigt, wie SCPs mit expliziten Listen für Dienstgenehmigungen funktionieren, wenn sie auf Stammebene innerhalb eines AWS Organizations angewendet werden. Auf der Stammebene der Organisation sind zwei benutzerdefinierte „Service Allow“ -SCPs angehängt, die ausdrücklich den Zugriff auf eine begrenzte Anzahl von AWS Diensten ermöglichen — SCP_1 erlaubt IAM und Amazon EC2, SCP_2 erlaubt Amazon S3 und Amazon. CloudWatch Auf der Ebene der Organisationseinheit (OU) bleibt die standardmäßige FullAWSAccess-Richtlinie beigefügt. Aufgrund des Überschneidungsverhaltens können die Konten A und B unter diesen Organisationseinheiten jedoch nur auf die Dienste zugreifen, die vom SCP auf Stammebene ausdrücklich zugelassen wurden. Die restriktivere Root-Richtlinie hat Vorrang, wodurch der Zugriff effektiv nur auf IAM, EC2, S3 und CloudWatch Dienste beschränkt wird, unabhängig von den umfassenderen Berechtigungen, die auf niedrigeren Organisationsebenen gewährt werden.
