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.
# Auswertungslogik für Richtlinien
Wenn ein Principal versucht AWS-Managementkonsole, die AWS API oder den AWS CLI zu verwenden, sendet dieser Principal eine *Anfrage*. AWS Wenn ein AWS Dienst die Anfrage empfängt, AWS führt er mehrere Schritte durch, um zu bestimmen, ob die Anfrage zugelassen oder abgelehnt werden soll.
1. **Authentifizierung** — authentifiziert AWS zunächst den Prinzipal, der die Anfrage stellt, falls erforderlich. Dieser Schritt ist für einige wenige Services, wie z. B. Amazon S3, die einige Anforderungen von anonymen Benutzern erlauben, nicht notwendig.
1. **[Verarbeitung des Anforderungskontexts](reference_policies_evaluation-logic_policy-eval-reqcontext.md)**— AWS verarbeitet die in der Anfrage gesammelten Informationen, um festzustellen, welche Richtlinien für die Anfrage gelten.
1. **[Wie die Logik des AWS Erzwingungscodes Anfragen zur Zulassung oder Verweigerung des Zugriffs auswertet](reference_policies_evaluation-logic_policy-eval-denyallow.md)**— AWS bewertet alle Richtlinientypen, und die Reihenfolge der Richtlinien wirkt sich darauf aus, wie sie bewertet werden. AWS verarbeitet dann die Richtlinien anhand des Anforderungskontextes, um festzustellen, ob die Anfrage zugelassen oder abgelehnt wird.
## Auswerten identitätsbasierter Richtlinien mit ressourcenbasierten Richtlinien
Identitätsbasierte Richtlinien und ressourcenbasierte Richtlinien erteilen Identitäten oder Ressourcen, an die sie angefügt sind, Berechtigungen. Wenn eine IAM-Entität (Benutzer oder Rolle) Zugriff auf eine Ressource innerhalb desselben Kontos anfordert, werden alle Berechtigungen AWS ausgewertet, die durch die identitäts- und ressourcenbasierten Richtlinien gewährt wurden. Die resultierenden Berechtigungen sind die Kombination der Berechtigungen der beiden Typen. Wenn eine Aktion durch eine identitätsbasierte Richtlinie, eine ressourcenbasierte Richtlinie oder beides zulässig ist, ist die Aktion zulässig. AWS Eine explizite Zugriffsverweigerung in einer der beiden Richtlinien überschreibt die Zugriffserlaubnis.
![\[Auswertung identitätsbasierter Richtlinien und ressourcenbasierter Richtlinien\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/images/permissions_policies_effective.png)
## Auswerten von identitätsbasierten Richtlinien mit Berechtigungsgrenzen
Bei der AWS Auswertung der identitätsbasierten Richtlinien und der Berechtigungsgrenzen für einen Benutzer stellen die resultierenden Berechtigungen die Schnittmenge der beiden Kategorien dar. Das heißt, wenn Sie einem Benutzer mit bestehenden identitätsbasierten Richtlinien eine Berechtigungsgrenze hinzufügen, reduzieren Sie möglicherweise die Aktionen, die der Benutzer ausführen kann. Wenn Sie andererseits eine Berechtigungsgrenze von einem Benutzer entfernen, können Sie die Aktionen erweitern, die dieser ausführen kann. Eine explizite Zugriffsverweigerung in einer der beiden Richtlinien überschreibt die Zugriffserlaubnis. Informationen darüber, wie andere Richtlinientypen mit Berechtigungsgrenzen ausgewertet werden, finden Sie unter [Auswerten von effektiven Berechtigungen mit Grenzen](access_policies_boundaries.md#access_policies_boundaries-eval-logic).
![\[Auswertung von identitätsbasierten Richtlinien und Berechtigungsgrenzen\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/images/permissions_boundary.png)
## Evaluierung identitätsbasierter Richtlinien mit oder AWS Organizations SCPs RCPs
Wenn ein Benutzer einem Konto angehört, das Mitglied einer Organisation ist, und auf eine Ressource zugreift, für die keine ressourcenbasierte Richtlinie konfiguriert ist, stellen die daraus resultierenden Berechtigungen die Schnittmenge der Benutzerrichtlinien, der Dienststeuerungsrichtlinien (SCPs) und der Ressourcenkontrollrichtlinie (RCP) dar. Dies bedeutet, dass eine Aktion von allen drei Richtlinientypen zugelassen werden muss. Eine explizite Verweigerung in der identitätsbasierten Richtlinie, einer SCP oder einer RCP überschreibt die Zulassung.
![\[Bewertung identitätsbasierter Richtlinien und/oder oder SCPs RCPs\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/images/permissions_scp-idp.png)
Sie können erfahren [ob Ihr Konto als Mitgliedskonto einer Organisation](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_details.html#orgs_view_account) in AWS Organizations eingerichtet ist. Mitglieder der Organisation könnten von einer SCP oder RCP betroffen sein. Um diese Daten mithilfe des AWS CLI Befehls oder der AWS API-Operation anzeigen zu können, müssen Sie über die entsprechenden Berechtigungen für Ihre `organizations:DescribeOrganization` AWS Organizations Entität verfügen. Sie benötigen zusätzliche Berechtigungen, um den Vorgang in der AWS Organizations Konsole ausführen zu können. Um zu erfahren, ob ein SCP oder RCP den Zugriff auf eine bestimmte Anfrage verweigert, oder um Ihre aktuellen Berechtigungen zu ändern, wenden Sie sich an Ihren Administrator. AWS Organizations
# Verarbeitung des Anforderungskontexts
*Wenn eine Anfrage AWS ausgewertet und autorisiert wird, fügt sie die Anforderungsinformationen zu einem Anforderungskontext zusammen.* Der Anfragekontext enthält alle Informationen, die für die Richtlinienauswertung verwendet werden können.
+ **Prinzipal** – Der Benutzer, die Rolle oder der Verbundbenutzer-Prinzipal, der die Anfrage gesendet hat. Informationen über den Auftraggeber beinhalten die Richtlinien, die diesem Auftraggeber zugeordnet sind.
+ **Aktionen** – Eine oder mehrere Aktionen, die der Prinzipal ausführen möchte.
+ **Ressourcen** — Ein oder mehrere AWS Ressourcenobjekte, für die die Aktionen oder Operationen ausgeführt werden.
+ **Ressourcendaten** – Daten zu den angeforderten Ressourcen. Dies sind zum Beispiel Informationen wie ein DynamoDB-Tabellenname oder Tag auf einer Amazon EC2-Instance.
+ **Umgebungsdaten** – Informationen über die IP-Adresse, den Benutzeragent, den SSL-Status oder die Tageszeit.
Diese Informationen werden mit den geltenden Richtlinien verglichen, um zu entscheiden, ob die Anfrage zugelassen oder abgelehnt wird. Sie können diese Eigenschaftsinformationen mithilfe des PARC-Modells (**Principal**, **Action**, **Resource** and **Condition**) organisieren, um besser zu verstehen, wie AWS Richtlinien bewertet werden.
## Das PARC-Modell verstehen
Das PARC-Modell stellt den Anfragekontext anhand der vier JSON-Elemente der Richtliniensprache dar:
+ [Principal](reference_policies_elements_principal.md) – Die Entität, die die Anfrage stellt. Ein Prinzipal stellt einen menschlichen Benutzer oder einen programmgesteuerten Workload dar, der authentifiziert und dann zur Ausführung von Aktionen in AWS-Konten autorisiert werden kann.
+ [Action](reference_policies_elements_action.md) – Der Vorgang, der gerade ausgeführt wird. Oft wird die Aktion einer API-Aktion zugeordnet.
+ [Resource](reference_policies_elements_resource.md) – Die AWS -Ressource, auf der die Aktion ausgeführt wird.
+ [Condition](reference_policies_elements_condition.md) – Zusätzliche Einschränkungen, die erfüllt sein müssen, damit die Anfrage zugelassen wird.
Das folgende Beispiel zeigt, wie das PARC-Modell einen Anfragekontext darstellen kann:
```
Principal: AIDA123456789EXAMPLE
Action: s3:CreateBucket
Resource: arn:aws:s3:::amzn-s3-demo-bucket1
Context:
- aws:UserId=AIDA123456789EXAMPLE:BobsSession
- aws:PrincipalAccount=123456789012
- aws:PrincipalOrgId=o-example
- aws:PrincipalARN=arn:aws:iam::AIDA123456789EXAMPLE:role/HR
- aws:MultiFactorAuthPresent=true
- aws:CurrentTime=...
- aws:EpochTime=...
- aws:SourceIp=...
- aws:PrincipalTag/dept=123
- aws:PrincipalTag/project=blue
- aws:RequestTag/dept=123
```
## Bedeutung des Anfragekontexts
Das Verständnis des Anfragekontexts und seiner Interaktion mit der Richtlinienauswertung ist entscheidend für:
+ Die Behebung von Zugriffsproblemen
+ Die Entwicklung effektiver und sicherer Richtlinien
+ Das vollständige Verständnis des Umfangs der durch eine Richtlinie gewährten Berechtigungen
+ Die Vorhersage des Ergebnisses von Richtlinienauswertungen in verschiedenen Szenarien
Durch die Visualisierung des Anforderungskontextes mithilfe des PARC-Modells können Sie leichter nachvollziehen, wie AWS Autorisierungsentscheidungen getroffen werden, und Ihre Richtlinien effektiver gestalten.
## Wie AWS wird der Anforderungskontext verwendet
Bei der Bewertung von Richtlinien werden die Informationen im Anforderungskontext mit den Informationen AWS verglichen, die in allen geltenden Richtlinien angegeben sind. Dazu gehören identitätsbasierte Richtlinien, ressourcenbasierte Richtlinien, IAM-Berechtigungsgrenzen, Organizations SCPs, Organizations und Sitzungsrichtlinien. RCPs
AWS Verwendet für jeden Richtlinientyp den Anforderungskontext, um Folgendes zu überprüfen:
+ Ob die Richtlinie basierend auf dem Prinzipal auf die Anfrage anwendbar ist.
+ Ob die angeforderte Aktion für die angegebene Ressource zulässig ist.
+ Ob die in der Richtlinie festgelegten Bedingungen vom Anfragekontext erfüllt werden.
Wie Richtlinien AWS bewertet werden, hängt von den Arten von Richtlinien ab, die für den Anforderungskontext gelten. Diese Richtlinientypen können innerhalb eines einzelnen AWS-Konto verwendet werden. Weitere Informationen zu diesen Richtlinientypen finden Sie unter [Richtlinien und Berechtigungen in AWS Identity and Access Management](access_policies.md). Informationen darüber, wie Richtlinien für den kontoübergreifenden Zugriff AWS bewertet werden, finden Sie unter. [Logik für die kontoübergreifende Richtlinienauswertung](reference_policies_evaluation-logic-cross-account.md)
+ **AWS Organizations Richtlinien zur Ressourcenkontrolle (RCPs)** — AWS Organizations RCPs geben die maximal verfügbaren Berechtigungen für Ressourcen innerhalb von Konten in einer Organisation oder Organisationseinheit (OU) an. RCPs gelten für Ressourcen in Mitgliedskonten und wirken sich auf die effektiven Berechtigungen für Prinzipale aus, einschließlich der Root-Benutzer des AWS-Kontos, unabhängig davon, ob die Prinzipale zu Ihrer Organisation gehören. RCPs gelten nicht für Ressourcen im Organisationsverwaltungskonto und nicht für Aufrufe von Rollen, die mit dem Dienst verknüpft sind. Wenn eine RCP vorhanden ist, sind Berechtigungen, die durch identitätsbasierte und ressourcenbasierte Richtlinien für Ressourcen in Ihren Mitgliedskonten erteilt werden, nur dann wirksam, wenn die RCP die Aktion zulässt.
+ **AWS Organizations Dienststeuerungsrichtlinien (SCPs)** — AWS Organizations SCPs geben die maximal verfügbaren Berechtigungen für Prinzipale innerhalb von Konten in einer Organisation oder Organisationseinheit (OU) an. SCPs gelten für Prinzipale in Mitgliedskonten, einschließlich der einzelnen Konten. Root-Benutzer des AWS-Kontos Wenn eine SCP vorhanden ist, sind durch identitäts- und ressourcenbasierte Richtlinien gewährte Berechtigungen an Prinzipalen in Ihren Mitgliedskonten nur wirksam, wenn die SCP die Aktion zulässt. Die einzigen Ausnahmen sind Prinzipale im Organisationsverwaltungskonto und serviceverknüpfte Rollen.
+ **Ressourcenbasierte Richtlinien** – Ressourcenbasierte Richtlinien gewähren Berechtigungen für in der Richtlinie angegebene Prinzipale. Die Berechtigungen definieren, welche Aktionen der Auftraggeber mit der Ressource, der die Richtlinie zugewiesen ist. durchführen kann.
+ **Berechtigungsgrenzen** – Berechtigungsgrenzen sind ein Feature, das die maximalen Berechtigungen festlegt, die eine identitätsbasierte Richtlinie einer IAM-Entität (Benutzer oder Rolle) gewähren kann. Wenn Sie eine Berechtigungsgrenze für eine Entität festlegen, kann die Entität nur die Aktionen ausführen, die sowohl von ihren identitätsbasierten Richtlinien als auch von ihrer Berechtigungsgrenze zugelassen werden. In einigen Fällen kann eine implizite Verweigerung in einer Berechtigungsgrenze die Berechtigungen nicht bechränken, die von einer ressourcenbasierten Richtlinie gewährt werden. Weitere Informationen 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).
+ **Identitätsbasierte Richtlinien** – Identitätsbasierte Richtlinien werden einer IAM-Identität (Benutzer, Benutzergruppe oder Rolle) angefügt und gewähren IAM-Entitäten (Benutzer und Rollen) Berechtigungen. Wenn für eine Anfrage nur identitätsbasierte Richtlinien gelten, AWS überprüft es alle diese Richtlinien auf mindestens eine. `Allow`
+ **Sitzungsrichtlinien** – Sitzungsrichtlinien sind Richtlinien, die Sie als Parameter übergeben, wenn Sie programmgesteuert eine temporäre Sitzung für eine Rolle oder Verbundbenutzersitzung erstellen. Um eine Rollensitzung programmgesteuert zu erstellen, verwenden Sie eine der `AssumeRole*`-API-Operationen. Wenn Sie dies tun und Richtlinien für die Sitzung übergeben, sind die resultierenden Sitzungsberechtigungen eine Schnittmenge der identitätsbasierten Richtlinie der IAM-Entität und der Sitzungsrichtlinien. Um eine Sitzung eines Verbundbenutzers zu erstellen, verwenden Sie die Zugriffsschlüssel eines IAM-Benutzers, um den API-Vorgang `GetFederationToken` programmatisch aufzurufen. Weitere Informationen finden Sie unter [Sitzungsrichtlinien](access_policies.md#policies_session).
Denken Sie daran, dass eine explizite Zugriffsverweigerung in all diesen Richtlinien eine Zugriffserlaubnis überschreibt.
**Anmerkung**
AWS Organizations Mit **deklarativen Richtlinien** können Sie Ihre gewünschte Konfiguration für eine bestimmte Größe AWS-Service im gesamten Unternehmen zentral deklarieren und durchsetzen. Da deklarative Richtlinien direkt auf Serviceebene angewendet werden, haben sie keinen direkten Einfluss auf die Richtlinienauswertung und sind nicht Teil des Anfragekontexts. Weitere Informationen finden Sie unter [Deklarative Richtlinien](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_declarative.html) im AWS Organizations Benutzerhandbuch.
## Beispiel für die Richtlinienauswertung mit dem PARC-Modell
Um zu veranschaulichen, wie der Anfragekontext die Richtlinienauswertung beeinflusst, betrachten wir eine Beispielrichtlinie:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:CreateBucket",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket1",
"Condition": {
"StringEquals": {
"aws:PrincipalTag/dept": "123"
}
}
}
]
}
```
------
In diesem Beispiel würde die Richtlinie die Aktion „`CreateBucket`“ nur dann zulassen, wenn der Anfragekontext den Wert „123“ für „`aws:PrincipalTag/dept`“ enthält und die Ressource mit dem Bucket-Namen „`amzn-s3-demo-bucket1`“ übereinstimmt. Die folgende Tabelle zeigt, wie AWS den Anfragekontext verwendet, um diese Richtlinie auszuwerten und Autorisierungsentscheidungen zu treffen.
| Richtlinie | Kontext anfordern | Ergebnis der Bewertung |
| --- | --- | --- |
| "StringEquals": {
"aws:PrincipalTag/dept": "123"
} | Principal: AIDA123456789EXAMPLE
Action: s3:CreateBucket
Resource: arn:aws:s3:::amzn-s3-demo-bucket1
Context:
- aws:PrincipalTag/dept=123
| **Spiel** |
| "StringEquals": {
"aws:PrincipalTag/dept": "123"
} | Principal: AIDA123456789EXAMPLE
Action: s3:DeleteBucket
Resource: arn:aws:s3:::amzn-s3-demo-bucket1
Context:
- aws:PrincipalTag/dept=123
| **Kein Spiel** |
| "StringEquals": {
"aws:PrincipalTag/dept": "123"
} | Principal: AIDA123456789EXAMPLE
Action: s3:CreateBucket
Resource: arn:aws:s3:::amzn-s3-demo-bucket1
Context:
- aws:PrincipalTag/dept=321
| **Kein Spiel** |
| "StringEquals": {
"aws:PrincipalTag/dept": "123"
} | Principal: AIDA123456789EXAMPLE
Action: s3:CreateBucket
Resource: arn:aws:s3:::amzn-s3-demo-bucket1
Context:
Kein `aws:PrincipalTag` in der Anforderung. | **Kein Spiel** |
# 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)
# Der Unterschied zwischen expliziten und impliziten Zugriffsverweigerungen
Eine Anforderung führt zu einer expliziten Zugriffsverweigerung, wenn eine anwendbare Richtlinie eine `Deny`-Anweisung enthält. Wenn Richtlinien, die auf eine Anforderung anwendbar sind, eine `Allow`-Anweisung und eine `Deny`-Anweisung enthalten, übersteuert die `Deny` -Anweisung die `Allow` -Anweisung. Die Anforderung wird abgelehnt.
Eine implizite Verweigerung tritt auf, wenn es keine entsprechende `Deny`-Anweisung, aber auch keine anwendbare `Allow`-Anweisung gibt. Da einem IAM-Prinzipal standardmäßig der Zugriff verweigert wird, muss ihm explizit erlaubt werden, eine Aktion auszuführen. Andernfalls wird ihnen der Zugriff implizit verweigert.
Bei der Planung Ihrer Autorisierungsstrategie müssen Sie Richtlinien mit `Allow`-Anweisungen erstellen, um Ihren Auftraggeber zu gestatten, erfolgreich Anforderungen durchzuführen. Sie können jedoch eine beliebige Kombination von expliziten und impliziten Zugriffsverweigerungen wählen.
Sie können beispielsweise die folgende Richtlinie erstellen, die zulässige Aktionen, implizit verweigerte Aktionen und explizit verweigerte Aktionen enthält. Die `AllowGetList`-Aussage **erlaubt** Lesezugriff auf IAM-Aktionen, die mit den Präfixen `Get` und `List` beginnen. Alle anderen Aktionen in IAM, wie `iam:CreatePolicy` sind **implizit abgelehnt**. Die `DenyReports`-Aussage **verweigert explizit** Zugriff auf IAM-Berichte durch Verweigern des Zugriffs auf Aktionen, die den `Report`-Suffix, wie `iam:GetOrganizationsAccessReport` enthalten. Wenn jemand diesem Prinzipal eine andere Richtlinie hinzufügt, um ihm Zugriff auf IAM-Berichte zu gewähren, z. B. `iam:GenerateCredentialReport`, werden berichtsbezogene Anfragen aufgrund dieser ausdrücklichen Ablehnung immer noch abgelehnt.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowGetList",
"Effect": "Allow",
"Action": [
"iam:Get*",
"iam:List*"
],
"Resource": "*"
},
{
"Sid": "DenyReports",
"Effect": "Deny",
"Action": "iam:*Report",
"Resource": "*"
}
]
}
```
------