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](orgs_manage_policies_inheritance_mgmt.md).
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.
**Topics**
+ [So funktionieren SCPs mit Allow](#how_scps_allow)
+ [So arbeiten SCPs mit Deny](#how_scps_deny)
+ [Strategie zur Verwendung von SCPs](#strategy_using_scps)
## 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](https://console.aws.amazon.com/organizations/v2/home/policies/service-control-policy/p-FullAWSAccess) und Aktionen zulässt. Wenn diese Richtlinie entfernt und auf keiner Organisationsebene ersetzt wird, werden alle 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-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. `Deny`Kontoauszü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](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html), in [IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor-view-data-orgs.html) im *IAM-Benutzerhandbuch.*
AWS Organizations fügt jedem Root, jeder Organisationseinheit und jedem Konto bei der [https://console.aws.amazon.com/organizations/v2/home/policies/service-control-policy/p-FullAWSAccess](https://console.aws.amazon.com/organizations/v2/home/policies/service-control-policy/p-FullAWSAccess) hinzu. Diese Richtlinie lässt alle Services und Aktionen zu. Sie können **FullAWSAccess** eine Richtlinie ersetzen, die nur eine Reihe von Diensten zulässt, sodass neue Dienste nur zulässig AWS-Services sind, wenn sie durch die Aktualisierung von SCPs ausdrücklich zugelassen werden. 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. 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.
------
#### [ 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 **FullAWSAccess**-Richtlinie trennen und stattdessen diese Richtlinie anfügen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:*",
"cloudwatch:*",
"organizations:*"
],
"Resource": "*"
},
{
"Effect": "Deny",
"Action":"organizations:LeaveOrganization",
"Resource": "*"
}
]
}
```
------
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.
