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 FullLawsAccess
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 Dienstleistungen in Ihrer Organisation zuzulassen. DenyAnweisungen sind eine effektive Methode, um Einschränkungen zu implementieren, die für einen größeren Teil Ihrer Organisation oder Organisationseinheiten gelten sollten, da sie sich auf alle Konten auswirken, die ihr unterstehen, wenn OU-level sie an der Wurzel angewendet werden oder wenn sie angewendet werden.
Tipp
Sie können die Daten, auf die der Dienst zuletzt zugegriffen hat, in IAM verwenden, um Ihre SCPs zu aktualisieren und den Zugriff auf die Daten zu beschränken AWS-Services , die Sie benötigen. Weitere Informationen finden Sie unter Anzeigen der Daten des letzten Zugriffs auf den Organizations-Service für Organizations im IAM-Benutzerhandbuch.
AWS Organizations hängt bei der Erstellung einen AWS verwalteten SCP mit dem Namen FullAWSAccess Allow-Anweisung verwenden, um nur bestimmte Dienste zuzulassen. Sie können wählen, ob Sie FullAwsAccess entweder auf der Stammebene oder auf jeder Ebene ersetzen möchten. Wenn Sie dem Stamm eine dienstspezifische Zuteilungsliste hinzufügen, gilt diese automatisch für alle Organisationseinheiten und Konten, die ihr untergeordnet sind. Das heißt, eine einzige Richtlinie auf Stammebene bestimmt die effektive Liste der zulässigen Dienste in der gesamten Organisation, wie in Szenario 7 gezeigt. Alternativ können Sie FullAWSAccess für jede Organisationseinheit und jedes Konto entfernen und ersetzen, sodass Sie detailliertere Servicegenehmigungslisten 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 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 demonstrieren, wie mehrere Service Control Policies (SCPs) in einer AWS Organisation angewendet werden können, sollten Sie die folgende Organisationsstruktur und die folgenden Szenarien berücksichtigen.
Szenario 1: Auswirkungen der Deny-Richtlinien
Dieses Szenario zeigt, wie sich Ablehnungsrichtlinien auf höheren Unternehmensebenen auf alle darunter liegenden Konten auswirken. Wenn für die Sandbox-Organisationseinheit sowohl die Richtlinien „ AWS Vollzugriff“ als auch „S3-Zugriff verweigern“ gelten und für Konto B die Richtlinie „EC2-Zugriff verweigern“ gilt, hat das Ergebnis, dass Konto B nicht auf S3 (von der OU-level Verweigerung) und von EC2 (von der Sperrung auf Kontoebene aus) zugreifen kann. Konto A hat keinen S3-Zugriff (aufgrund der Sperrung). OU-level
Szenario 2: Zulassungsrichtlinien müssen auf allen Ebenen 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 in der Sandbox-Organisationseinheit die Richtlinie „EC2-Zugriff zulassen“ gilt, die nur explizit den Zugriff auf EC2-Dienste zulässt, haben Konto A und B nur EC2-Zugriff.
Szenario 3: Auswirkung des Fehlens einer Allow-Anweisung auf der Stammebene
Wenn der Root nur eine Deny-Anweisung ohne die Allow-Anweisung „ AWS Vollzugriff“ enthält, erhalten alle Mitgliedskonten keinen Servicezugriff. SCPs benötigen auf jeder Ebene im Pfad ein ausdrückliches Allow. Ein Deny-only SCP im Stammverzeichnis blockiert daher jeden Dienst, es sei denn, ein explizites Allow deckt ihn ab.
Szenario 4: Layered Deny-Anweisungen und daraus resultierende Berechtigungen
Dieses Szenario zeigt eine zweistufige, tiefe OU-Struktur. Sowohl die Root- als auch die Workloads-Organisationseinheit haben „ AWS Vollzugriff“, die Test-OU hat „ AWS Vollzugriff“ mit „EC2-Zugriff verweigern“ und die Produktions-OU hat „ AWS Vollzugriff“. Daher hat Konto D den gesamten Servicezugriff außer EC2, und Konto E und F haben den gesamten Servicezugriff.
Szenario 5: Erlauben Sie den Richtlinien auf der OU-level , den Servicezugriff einzuschränken
Dieses Szenario zeigt, wie Zulassungsrichtlinien verwendet werden können, um den Zugriff auf bestimmte Dienste einzuschränken. Die Test-OU hat die Richtlinie „EC2-Zugriff zulassen“, was bedeutet, dass nur EC2-Dienste für Konto D zulässig sind. Die Produktions-OU behält den „ AWS Vollzugriff“ bei, sodass die Konten E und F Zugriff auf alle Dienste haben. Dies zeigt, wie restriktivere Genehmigungsrichtlinien implementiert werden können, OU-level während auf der Stammebene eine umfassendere Zulässigkeit beibehalten wird.
Szenario 6: Die Sperrung wirkt Root-level 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 Zulassungsrichtlinien auf niedrigeren Ebenen. Für das Stammverzeichnis gelten sowohl die Richtlinien „ AWS Vollzugriff“ als auch „S3-Zugriff verweigern“. Obwohl für die Test-OU die Richtlinie „S3-Zugriff zulassen“ gilt, hat die S3-Verweigerung auf Stammebene Vorrang. Konto D hat keinen Servicezugriff, da die Test-OU nur den S3-Zugriff zulässt, S3 jedoch auf der Stammebene verweigert wird. Die Konten E und F können auf andere Dienste außer S3 zugreifen, da dies auf der Stammebene ausdrücklich verweigert wird.
Szenario 7: Durch benutzerdefinierte Richtlinien auf Stammebene können die Zugriffsbeschränkungen eingeschränkt werden OU-level
Dieses Szenario zeigt, wie SCPs mit expliziten Serviceerlaubnislisten funktionieren, wenn sie auf Stammebene innerhalb einer AWS Organizations angewendet werden. Auf der Stammebene der Organisation sind zwei benutzerdefinierte „Service Allow“ -SCPs angehängt, die explizit den Zugriff auf eine begrenzte Anzahl von AWS Diensten zulassen — 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-Policy hat Vorrang und schränkt den Zugriff effektiv nur auf IAM, EC2, S3 und CloudWatch Dienste ein, unabhängig von den umfassenderen Berechtigungen, die auf niedrigeren Organisationsebenen gewährt werden.
