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.
# Wie die Logik des AWS Erzwingungscodes Anfragen zur Zulassung oder Verweigerung des Zugriffs auswertet
Der AWS Durchsetzungscode entscheidet, ob eine Anfrage, an die gesendet wird, zugelassen oder abgelehnt werden AWS soll. AWS bewertet alle Richtlinien, die für den Anforderungskontext gelten. Im Folgenden finden Sie eine Zusammenfassung der Bewertungslogik AWS für Richtlinien.
+ Standardmäßig werden alle Anforderungen implizit verweigert, mit Ausnahme des Root-Benutzer des AWS-Kontos s, der vollen Zugriff hat.
+ Um zugelassen zu werden, müssen Anfragen ausdrücklich durch eine Richtlinie oder einen Richtliniensatz zugelassen werden, die der unten stehenden Auswertungslogik folgen.
+ Eine explizite Verweigerung überschreibt eine explizite Zulassung.
Die Richtlinienauswertung kann unterschiedlich sein, je nachdem, ob sich die Anfrage auf ein einzelnes Konto oder auf eine kontoübergreifende Anfrage bezieht. Details dazu, wie eine Entscheidung zur Richtlinienauswertung für eine IAM-Rolle oder einen Benutzer innerhalb eines einzelnen Kontos getroffen wird, finden Sie unter [Richtlinienauswertung für Anfragen innerhalb eines einzelnen Kontos](reference_policies_evaluation-logic_policy-eval-basics.md). Details dazu, wie eine Entscheidung zur Richtlinienauswertung für kontenübergreifende Anfragen getroffen wird, finden Sie unter [Logik für die kontoübergreifende Richtlinienauswertung](reference_policies_evaluation-logic-cross-account.md).
+ **Auswertung für eine Zugriffsverweigerung** – Standardmäßig werden alle Anforderungen verweigert. Dieser Vorgang wird als [implizite Zugriffsverweigerung](reference_policies_evaluation-logic_AccessPolicyLanguage_Interplay.md) bezeichnet. Der AWS Durchsetzungscode bewertet alle Richtlinien innerhalb des Kontos, die für die Anfrage gelten. Dazu gehören AWS Organizations SCPs und RCPs, ressourcenbasierte Richtlinien, identitätsbasierte Richtlinien, IAM-Berechtigungsgrenzen und Sitzungsrichtlinien. Der Durchführungscode sucht in allen diesen Richtlinien nach einer `Deny`-Anweisung, die für die Anforderung gilt. Dieser Vorgang wird als [explizite Zugriffsverweigerung](reference_policies_evaluation-logic_AccessPolicyLanguage_Interplay.md) bezeichnet. Wenn der Durchsetzungscode auch nur eine explizite Verweigerung findet, die zutrifft, gibt der Durchsetzungscode die endgültige Entscheidung **Verweigern** zurück. Wenn es keine ausdrückliche Verweigerung gibt, wird die Auswertung des Erzwingungscodes fortgesetzt.
+ **AWS Organizations RCPs**— Der Durchsetzungscode bewertet die AWS Organizations Ressourcenkontrollrichtlinien (RCPs), die für die Anfrage gelten. RCPs gelten für Ressourcen des Kontos, an das sie angehängt RCPs sind. Findet der Vollstreckungscode keine zutreffenden `Allow` Aussagen in der RCPs, gibt der Vollstreckungscode die endgültige Entscheidung „**Ablehnen**“ zurück. Beachten Sie, dass eine so genannte AWS verwaltete Richtlinie automatisch erstellt und an jede Entität in Ihrer Organisation angehängt `RCPFullAWSAccess` wird, einschließlich der Stammrichtlinie, jeder Organisationseinheit und AWS-Konto wann sie aktiviert RCPs sind. `RCPFullAWSAccess`kann nicht getrennt werden, daher wird es immer eine `Allow` Aussage geben. Wenn kein RCP vorhanden ist oder wenn das RCP die angeforderte Aktion zulässt, wird die Auswertung des Durchsetzungscodes fortgesetzt.
+ **AWS Organizations SCPs**— Der Durchsetzungscode bewertet die AWS Organizations Dienstkontrollrichtlinien (SCPs), die für die Anfrage gelten. SCPs gelten für Hauptkunden des Kontos, mit dem sie verknüpft SCPs sind. Findet der Vollstreckungscode keine zutreffenden `Allow` Aussagen in der SCPs, gibt der Vollstreckungscode eine endgültige Entscheidung zurück**.** Wenn keine SCP vorhanden ist oder wenn die SCP die angeforderte Aktion zulässt, wird die Erzwingungscodeauswertung fortgesetzt.
+ **Ressourcenbasierte Richtlinien** - Innerhalb desselben Kontos wirken sich ressourcenbasierte Richtlinien unterschiedlich aus, abhängig von der Art des Prinzipals, der auf die Ressource zugreift, und dem Prinzipal, der in der ressourcenbasierten Richtlinie zulässig ist. Abhängig von der Art des Prinzipals, kann ein `Allow` in einer ressourcenbasierten Richtlinie zu einer endgültigen Entscheidung von `Allow` führen, auch wenn eine implizite Ablehnung in einer identitätsbasierten Richtlinie, Berechtigungsgrenze oder Sitzungsrichtlinie vorhanden ist.
Für die meisten Ressourcen benötigen Sie zum Gewähren des Zugriffs nur ein explizites `Allow` für den Prinzipal in einer identitätsbasierten oder ressourcenbasierten Richtlinie. [IAM-Rollenvertrauensrichtlinien](access_policies-cross-account-resource-access.md#access_policies-cross-account-delegating-resource-based-policies) und [KMS-Schlüsselrichtlinien](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) sind Ausnahmen von dieser Logik, da sie den Zugriff für [Auftraggeber](reference_policies_elements_principal.md) ausdrücklich zulassen müssen. Ressourcenbasierte Richtlinien für andere Services als IAM und AWS KMS erfordern möglicherweise auch eine ausdrückliche `Allow`-Anweisung innerhalb desselben Kontos, um Zugriff zu gewähren. Weitere Informationen finden Sie in der Dokumentation zu dem bestimmten von Ihnen verwendeten Service.
Für Anfragen zur Richtlinienauswertung für ein einzelnes Konto unterscheidet die ressourcenbasierte Richtlinienlogik sich von anderen Richtlinientypen, wenn der angegebene Prinzipal ein IAM-Benutzer, eine IAM-Rolle oder ein Sitzungsprinzipal ist. Zu den Sitzungsprinzipalen gehören [IAM-Rollensitzungen](reference_policies_elements_principal.md#principal-role-session) oder ein [AWS STS IAM-Verbundbenutzerprinzipal](reference_policies_elements_principal.md#sts-session-principals). Wenn eine ressourcenbasierte Richtlinie dem IAM-Benutzer oder dem Sitzungssprinzipal, der die Anforderung stellt, die Berechtigung direkt erteilt, wirkt sich eine implizite Ablehnung in einer identitätsbasierten Richtlinie, einer Berechtigungsgrenze oder einer Sitzungsrichtlinie nicht auf die endgültige Entscheidung aus.
+ **IAM-Rolle** – Ressourcenbasierte Richtlinien, die Berechtigungen für einen IAM-Rollen-ARN erteilen, sind durch eine implizite Verweigerung in einer Berechtigungsgrenze oder einer Sitzungsrichtlinie beschränkt. Sie können die Rollen-ARN im Prinzipal-Element oder im Bedingungsschlüssel `aws:PrincipalArn` angeben. In beiden Fällen handelt es sich bei dem Prinzipal, der die Anfrage stellt, um die **IAM-Rollensitzung**.
Berechtigungsgrenzen oder Sitzungsrichtlinien, schränken die gewährten Berechtigungen nicht ein, wenn der `aws:PrincipalArn`-Bedingungsschlüssel mit einem Platzhalter (\$1) im Prinzipal-Element verwendet wird, es sei denn, die identitätsbasierten Richtlinien enthalten eine explizite Verweigerung. Weitere Informationen finden Sie unter [IAM-Rollenauftraggeber](reference_policies_elements_principal.md#principal-roles).
**Beispielrolle ARN**
```
arn:aws:iam::111122223333:role/examplerole
```
+ **IAM-Rollensitzung** – Innerhalb desselben Kontos gewähren ressourcenbasierte Richtlinien, die einem IAM-Rollensitzungs-ARN Berechtigungen erteilen, auch direkt Berechtigungen für die angenommene Rollensitzung. Berechtigungen, die direkt für eine Sitzung gewährt werden, sind nicht durch eine implizite Verweigerung in einer identitätsbasierten Richtlinie, einer Berechtigungsgrenze oder einer Sitzungsrichtlinie beschränkt. Wenn Sie eine Rolle übernehmen und eine Anfrage stellen, ist der Prinzipal, der die Anfrage stellt, der ARN der IAM-Rollensitzung und nicht der ARN der Rolle selbst. Weitere Informationen finden Sie unter [Rollensitzungsgsprinzipale](reference_policies_elements_principal.md#principal-role-session).
**Beispiel für eine Rollensitzung ARN**
```
arn:aws:sts::111122223333:assumed-role/examplerole/examplerolesessionname
```
+ **IAM-Benutzer** - Innerhalb desselben Kontos sind ressourcenbasierte Richtlinien, die einem IAM-Benutzer-ARN (das kein Verbundbenutzersitzung ist) Berechtigungen erteilt, nicht durch eine implizite Verweigerung in einer identitätsbasierten Richtlinie oder Berechtigungsgrenze beschränkt.
**Beispiel eines IAM-Benutzer-ARN**
```
arn:aws:iam::111122223333:user/exampleuser
```
+ **AWS STS Federated User Principal** — Eine föderierte Benutzersitzung ist eine Sitzung, die durch einen Aufruf erstellt wird. [`GetFederationToken`](id_credentials_temp_request.md#api_getfederationtoken) Wenn ein Verbundbenutzer eine Anfrage stellt, ist der Prinzipal, der die Anfrage stellt, der ARN des Verbundbenutzers und nicht der ARN des IAM-Benutzers, der den Verbund erstellt hat. Innerhalb desselben Kontos erteilen ressourcenbasierte Richtlinien, die einem Verbundbenutzer-ARN Berechtigungen gewähren, der Sitzung direkt Berechtigungen. Berechtigungen, die direkt für eine Sitzung gewährt werden, sind nicht durch eine implizite Verweigerung in einer identitätsbasierten Richtlinie, einer Berechtigungsgrenze oder einer Sitzungsrichtlinie beschränkt.
Wenn jedoch eine ressourcenbasierte Richtlinie dem ARN des IAM-Benutzers, der den Verbund erstellt hat, die Berechtigung erteilt, werden Anfragen des Verbundbenutzers während der Sitzung durch eine implizite Verweigerung in einer Berechtigungsgrenze oder Sitzungsrichtlinie eingeschränkt.
**Beispiel für Verbundbenutzersitzung-ARN**
```
arn:aws:sts::111122223333:federated-user/exampleuser
```
+ **Identitätsbasierte Richtlinien** – Der Durchsetzungscode überprüft die identitätsbasierten Richtlinien für den Prinzipal. Für einen IAM-Benutzer gehören hierzu Benutzerrichtlinien und Richtlinien von Gruppen, zu denen der Benutzer gehört. Wenn es keine Anweisungen gibt, die die angeforderte Aktion zulassen, dann wird die Anforderung implizit verweigert und der Durchsetzungscode gibt die endgültige Entscheidung **Verweigert** zurück. Wenn eine Anweisung in einer der anwendbaren identitätsbasierten Richtlinien die angeforderte Aktion zulässt, wird die Code-Auswertung fortgesetzt.
+ **IAM-Berechtigungsgrenzen** – Der Durchsetzungscode prüft, ob die vom Prinzipal verwendete IAM-Entität über eine Berechtigungsgrenze verfügt. Wenn die Richtlinie, die verwendet wird, um die Berechtigungsgrenze festzulegen, die angeforderte Aktion nicht zulässt, dann wird die Anforderung implizit verweigert. Der Code gibt die finale Entscheidung **Zugriffsverweigerung** zurück. Wenn keine Berechtigungsgrenze vorhanden ist oder die Berechtigungsgrenze die angeforderte Aktion zulässt, wird die Code-Auswertung fortgesetzt.
+ **Sitzungsrichtlinien** – Der Durchsetzungscode prüft, ob es sich bei dem Prinzipal um einen Sitzungsprinzipal handelt. Zu den Sitzungsprinzipalen gehören eine IAM-Rollensitzung oder eine AWS STS Verbundbenutzersitzung. Wenn der Prinzipal kein Sitzungsprinzipal ist, gibt der Durchsetzungscode eine endgültige Entscheidung von**Erlauben** zurück.
Bei Sitzungsprinzipalen prüft der Durchsetzungscode, ob in der Anfrage eine Sitzungsrichtlinie übergeben wurde. Sie können eine Sitzungsrichtlinie übergeben, während Sie die AWS API AWS CLI oder verwenden, um temporäre Anmeldeinformationen für eine Rolle oder einen AWS STS Verbundbenutzerprinzipal abzurufen. Wenn Sie keine Sitzungsrichtlinie übergeben haben, wird eine Standardsitzungsrichtlinie erstellt und der Durchsetzungscode gibt die endgültige Entscheidung **Zulassen** zurück.
+ Wenn die Sitzungsrichtlinie vorhanden ist und die angeforderte Aktion nicht zulässt, dann wird die Anforderung implizit verweigert. Der Code gibt die finale Entscheidung **Zugriffsverweigerung** zurück.
+ Der Durchsetzungscode prüft, ob es sich beim Prinzipal um eine Rollensitzung handelt. Wenn der Prinzipal eine Rollensitzung ist, lautet die Anforderung **Erlaubt**. Andernfalls wird die Anfrage implizit abgelehnt und der Durchsetzungscode gibt die endgültige Entscheidung **Verweigern** zurück.
+ Wenn eine Sitzungsrichtlinie vorhanden ist und die angeforderte Aktion erlaubt, dann gibt der Durchführungscode eine endgültige Entscheidung von **Erlauben** zurück.
# Richtlinienauswertung für Anfragen innerhalb eines einzelnen Kontos
## Richtlinienauswertung für eine IAM-Rolle
Das folgende Ablaufdiagramm liefert Details dazu, wie eine Entscheidung zur Richtlinienauswertung für eine IAM-Rolle innerhalb eines einzelnen Kontos getroffen wird.
![\[Ablaufdiagramm für die Auswertung einer IAM-Rolle innerhalb eines einzelnen Kontos\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/images/PolicyEvaluationSingleAccountRole.png)
## Richtlinienauswertung für einen IAM-Benutzer
Das folgende Ablaufdiagramm liefert Details dazu, wie eine Entscheidung zur Richtlinienauswertung für einen IAM-Benutzer innerhalb eines einzelnen Kontos getroffen wird.
![\[Ablaufdiagramm für die Auswertung eines IAM-Benutzers innerhalb eines einzelnen Kontos\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/images/PolicyevaluationSingleAccountUser.png)
## Beispielauswertung identitätsbasierter Richtlinien und ressourcenbasierter Richtlinien
Die gebräuchlichsten Richtlinientypen sind identitätsbasierte Richtlinien und ressourcenbasierte Richtlinien. Wenn Zugriff auf eine Ressource angefordert wird, werden alle Berechtigungen AWS ausgewertet, die durch die Richtlinien für **mindestens eine Zulassen** innerhalb desselben Kontos gewährt wurden. Eine explizite Zugriffsverweigerung in einer der Richtlinien setzt eine Zugriffserlaubnis außer Kraft.
**Wichtig**
Wenn entweder die identitätsbasierte Richtlinie oder die ressourcenbasierte Richtlinie innerhalb desselben Kontos die Anforderung zulässt und die andere nicht, ist die Anforderung trotzdem zulässig.
Angenommen, Carlos hat den Benutzernamen `carlossalazar`, und er versucht, eine Datei im Amazon S3-Bucket `amzn-s3-demo-bucket-carlossalazar-logs` zu speichern.
Außerdem wird davon ausgegangen, dass die folgende Richtlinie dem IAM-Benutzer `carlossalazar` zugeordnet ist.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowS3ListRead",
"Effect": "Allow",
"Action": [
"s3:GetBucketLocation",
"s3:GetAccountPublicAccessBlock",
"s3:ListAccessPoints",
"s3:ListAllMyBuckets"
],
"Resource": "arn:aws:s3:::*"
},
{
"Sid": "AllowS3Self",
"Effect": "Allow",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket-carlossalazar/*",
"arn:aws:s3:::amzn-s3-demo-bucket-carlossalazar"
]
},
{
"Sid": "DenyS3Logs",
"Effect": "Deny",
"Action": "s3:*",
"Resource": "arn:aws:s3:::*log*"
}
]
}
```
------
Die `AllowS3ListRead` -Anweisung in dieser Richtlinie erlaubt Carlos, eine Liste aller Buckets im Konto anzuzeigen. Die `AllowS3Self`-Anweisung erlaubt Carlos vollständigen Zugriff auf den Bucket mit demselben Namen wie seinem Benutzernamen. Die `DenyS3Logs`-Anweisung verweigert Carlos den Zugriff auf S3-Buckets mit der Zeichenfolge `log` im Namen.
Außerdem ist die folgende ressourcenbasierte Richtlinie (eine sogenannte Bucket-Richtlinie) dem Bucket `amzn-s3-demo-bucket-carlossalazar` zugeordnet.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:user/carlossalazar"
},
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket-carlossalazar/*",
"arn:aws:s3:::amzn-s3-demo-bucket-carlossalazar"
]
}
]
}
```
------
Diese Richtlinie gibt an, dass nur der Benutzer `carlossalazar` auf den Bucket `amzn-s3-demo-bucket-carlossalazar` zugreifen kann.
Wenn Carlos seine Anfrage zum Speichern einer Datei im `amzn-s3-demo-bucket-carlossalazar-logs` Bucket AWS stellt, bestimmt er, welche Richtlinien für die Anfrage gelten. In diesem Fall gelten nur die identitätsbasierte Richtlinie und die ressourcenbasierte Richtlinie. Beides sind Berechtigungsrichtlinien. Da keine Berechtigungsgrenzen gelten, wird die Auswertungslogik auf die folgende Logik reduziert.
![\[Flussdiagramm zum Entscheidungsprozess\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/images/EffectivePermissionsShort.png)
AWS sucht zunächst nach einer `Deny` Aussage, die für den Kontext der Anfrage gilt. Es findet einen, weil die identitätsbasierte Richtlinie Carlos explizit den Zugriff auf alle S3-Buckets verweigert, die für die Protokollierung verwendet werden. Carlos wird der Zugriff verweigert.
Gehen Sie davon aus, dass er dann seinen Fehler erkennt und versucht, die Datei im `amzn-s3-demo-bucket-carlossalazar` Bucket zu speichern. AWS sucht nach einer `Deny` Aussage und findet keine. Dann überprüft es die Berechtigungsrichtlinien. Sowohl die identitätsbasierte Richtlinie, als auch die ressourcenbasierte Richtlinie lassen die Anforderung zu. AWS Erlaubt daher die Anfrage. Hätte eine von ihnen die Anweisung ausdrücklich abgelehnt, wäre die Anforderung abgelehnt worden. Wenn einer der Richtlinientypen die Anforderung zulässt und der andere nicht, ist die Anforderung weiterhin zulässig.
# Logik für die kontoübergreifende Richtlinienauswertung
Sie können einem Auftraggeber in einem Konto gestatten, auf Ressourcen in einem zweiten Konto zuzugreifen. Dies wird als kontenübergreifender Zugriff bezeichnet. Wenn Sie kontenübergreifenden Zugriff zulassen, wird das Konto, in dem der Auftraggeber existiert, als *vertrauenswürdiges*-Konto bezeichnet. Das Konto, in dem die Ressource existiert, ist das *vertrauende* Konto.
Um den kontenübergreifenden Zugriff zu ermöglichen, weisen Sie eine ressourcenbasierte Richtlinie für die freizugebende Ressource zu. Sie müssen außerdem eine identitätsbasierte Richtlinie für die Identität zuweisen, die in der Anforderung als Prinzipal fungiert. Die ressourcenbasierte Richtlinie im vertrauenden Konto muss den Auftraggeber des vertrauenswürdigen Kontos angeben, der Zugriff auf die Ressource hat. Sie können das gesamte Konto oder seine IAM-Benutzer, AWS STS Verbundbenutzerprinzipale, IAM-Rollen oder Sitzungen mit übernommenen Rollen angeben. Sie können auch einen Dienst als Prinzipal angeben. AWS Weitere Informationen finden Sie unter [So legen Sie einen Prinzipal fest](reference_policies_elements_principal.md#Principal_specifying).
Die identitätsbasierte Richtlinie des Auftraggebers muss den angeforderten Zugriff auf die Ressource im vertrauenden Service zulassen. Sie können dies tun, indem Sie die ARN der Ressource angeben.
In können Sie eine ressourcenbasierte Richtlinie einer IAM-Rolle zuordnen, um Auftraggeber in anderen Konten diese Rolle übernehmen zu lassen. Die ressourcenbasierte Richtlinie der Rolle wird als Rollenvertrauensrichtlinie bezeichnet. Nach dem Übernehmen dieser Rolle können die zugelassenen Auftraggeber die resultierenden temporären Anmeldeinformationen verwenden, um auf mehrere Ressourcen in Ihrem Konto zuzugreifen. Dieser Zugriff wird in der identitätsbasierten Berechtigungsrichtlinie der Rolle definiert. Informationen darüber, wie sich das Zulassen von kontenübergreifendem Zugriff mit Rollen von dem Zulassen von kontenübergreifendem Zugriff mit anderen ressourcenbasierten Richtlinien unterscheidet, finden Sie unter [Kontoübergreifender Zugriff auf Ressourcen in IAM](access_policies-cross-account-resource-access.md).
**Wichtig**
Andere Services können sich auf die Richtlinienauswertungslogik auswirken. AWS Organizations Unterstützt beispielsweise [Dienststeuerungsrichtlinien](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) und [Ressourcensteuerungsrichtlinien](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html), die auf Prinzipale und Ressourcen in einem oder mehreren Konten angewendet werden können. AWS Resource Access Manager unterstützt [Richtlinienfragmente](https://docs.aws.amazon.com/ram/latest/userguide/permissions.html), die steuern, welche Aktionen Principals auf Ressourcen ausführen dürfen, die mit ihnen gemeinsam genutzt werden.
## Festlegen, ob eine kontenübergreifende Anforderung zulässig ist
Bei kontenübergreifenden Anforderungen muss der Anforderer in der vertrauenswürdigen `AccountA` eine identitätsbasierte Richtlinie haben. Diese Richtlinie muss ihnen gestatten, eine Anforderung an die Ressource in der vertrauenden `AccountB` zu stellen. Zusätzlich muss die ressourcenbasierte Richtlinie in `AccountB` dem Anforderer in `AccountA` den Zugriff auf die Ressource gestatten.
AWS Führt zwei Bewertungen durch, wenn Sie eine kontenübergreifende Anfrage stellen. AWS bewertet die Anfrage im vertrauenswürdigen Konto und im vertrauenswürdigen Konto. Weitere Informationen darüber, wie eine Anforderung innerhalb eines einzelnen Kontos ausgewertet wird, finden Sie unter [Wie die Logik des AWS Erzwingungscodes Anfragen zur Zulassung oder Verweigerung des Zugriffs auswertet](reference_policies_evaluation-logic_policy-eval-denyallow.md). Die Anforderung ist nur dann zulässig, wenn beide Auswertungen eine Entscheidung von `Allow` zurückgeben.
![\[Kontoübergreifende Auswertung\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/images/policy_cross-account-eval-simple.png)
1. Wenn ein Auftraggeber in einem Konto eine Anforderung für den Zugriff auf eine Ressource in einem anderen Konto stellt, ist dies eine kontenübergreifende Anforderung.
1. Der anfordernde Auftraggeber ist im vertrauenswürdigen Konto (`AccountA`) vorhanden. Wenn AWS dieses Konto auswertet, prüft es die identitätsbasierte Richtlinie und alle Richtlinien, die eine identitätsbasierte Richtlinie einschränken können. Weitere Informationen finden Sie unter [Auswerten von identitätsbasierten Richtlinien mit Berechtigungsgrenzen](reference_policies_evaluation-logic.md#policy-eval-basics-id-bound).
1. Die angeforderte Ressource ist im vertrauenden Konto (`AccountB`) vorhanden. Wenn AWS dieses Konto auswertet, prüft es die ressourcenbasierte Richtlinie, die der angeforderten Ressource zugeordnet ist, sowie alle Richtlinien, die eine ressourcenbasierte Richtlinie einschränken können. Weitere Informationen finden Sie unter [Auswerten identitätsbasierter Richtlinien mit ressourcenbasierten Richtlinien](reference_policies_evaluation-logic.md#policy-eval-basics-id-rdp).
1. AWS lässt die Anfrage nur zu, wenn beide Bewertungen der Kontorichtlinien die Anfrage zulassen.
Das folgende Flussdiagramm veranschaulicht detaillierter, wie eine Entscheidung zur Richtlinienauswertung für eine kontoübergreifende Anforderung getroffen wird. Auch hier gilt, AWS dass die Anfrage nur dann zulässig ist, wenn beide Prüfungen der Kontorichtlinien die Anfrage zulassen.
![\[Detaillierte kontoübergreifende Richtlinienauswertung\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/images/PolicyEvaluationCrossAccount.png)
## Beispiel für kontenübergreifende Richtlinienauswertung
Das folgende Beispiel zeigt ein Szenario, in dem einer Rolle in einem Konto Berechtigungen durch eine ressourcenbasierte Richtlinie in einem zweiten Konto gewährt werden.
Angenommen, Carlos ist ein Entwickler mit einer IAM-Rolle mit dem Namen `Demo` im Konto 111111111111. Er möchte eine Datei im `amzn-s3-demo-bucket-production-logs` Amazon S3-Bucket im Konto 222222222222 speichern.
Nehmen Sie außerdem an, dass der `Demo`-IAM-Rolle die folgende Richtlinie zugeordnet ist.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowS3ListRead",
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "*"
},
{
"Sid": "AllowS3ProductionObjectActions",
"Effect": "Allow",
"Action": "s3:*Object*",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket-production/*"
},
{
"Sid": "DenyS3Logs",
"Effect": "Deny",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::*log*",
"arn:aws:s3:::*log*/*"
]
}
]
}
```
------
Die `AllowS3ListRead`-Anweisung in dieser Richtlinie erlaubt es Carlos, eine Liste aller Buckets in Amazon S3 anzuzeigen. Die `AllowS3ProductionObjectActions`-Anweisung gewährt Carlos Vollzugriff auf Objekte im `amzn-s3-demo-bucket-production`-Bucket.
Zusätzlich wird die folgende ressourcenbasierte Richtlinie (eine so genannte Bucket-Richtlinie) an den `amzn-s3-demo-bucket-production`-Bucket im Konto 222222222222 angehängt.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject*",
"s3:PutObject*",
"s3:ReplicateObject",
"s3:RestoreObject"
],
"Principal": { "AWS": "arn:aws:iam::111111111111:role/Demo" },
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket-production/*"
}
]
}
```
------
Diese Richtlinie erlaubt der Rolle `Demo`, auf Objekte im Bucket `amzn-s3-demo-bucket-production` zuzugreifen. Die Rolle kann die Objekte im Bucket erstellen und bearbeiten, jedoch nicht löschen. Die Rolle kann den Bucket nicht selbst verwalten.
Wenn Carlos seine Anfrage zum Speichern einer Datei im `amzn-s3-demo-bucket-production-logs` Bucket AWS stellt, bestimmt er, welche Richtlinien für die Anfrage gelten. In diesem Fall ist die der `Demo`-Rolle zugeordnete identitätsbasierte Richtlinie die einzige Richtlinie, die im Konto `111111111111` gilt. In Konto `222222222222` ist keine ressourcenbasierte Richtlinie für den `amzn-s3-demo-bucket-production-logs`-Bucket festgelegt. Wenn AWS das Konto ausgewertet wird`111111111111`, wird die Entscheidung von `Deny` zurückgegeben. Das liegt daran, dass die `DenyS3Logs`-Anweisung in der identitätsbasierten Richtlinie den Zugriff auf alle Log-Buckets explizit verweigert. Weitere Informationen darüber, wie eine Anforderung innerhalb eines einzelnen Kontos ausgewertet wird, finden Sie unter [Wie die Logik des AWS Erzwingungscodes Anfragen zur Zulassung oder Verweigerung des Zugriffs auswertet](reference_policies_evaluation-logic_policy-eval-denyallow.md).
Da die Anforderung innerhalb eines der Konten explizit verweigert wird, besteht die endgültige Entscheidung darin, die Anforderung zu verweigern.
![\[Anfrage an amzn-s3-bucket demo-bucket-production-logs\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/images/policy_cross-account-eval-example.png)
Gehen Sie davon aus, dass Carlos dann seinen Fehler erkennt und versucht, die Datei im Bucket zu speichern. `Production` AWS überprüft zunächst das Konto`111111111111`, um festzustellen, ob die Anfrage zulässig ist. Es gilt nur die identitätsbasierte Richtlinie, die die Anfrage zulässt. AWS überprüft dann das Konto. `222222222222` Nur die ressourcenbasierte Richtlinie, die dem `Production`-Bucket zugeordnet ist, gilt und lässt die Anforderung zu. Da beide Konten die Anforderung zulassen, besteht die endgültige Entscheidung darin, die Anforderung zuzulassen.
![\[Anforderung an den Produktions-Bucket\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/images/policy_cross-account-eval-example-correct.png)