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.
# IAM-JSON-Richtlinienreferenz
Dieser Abschnitt enthält detaillierte Syntax, Beschreibungen und Beispiele für die Elemente, Variablen und Auswertungslogik von JSON-Richtlinien in IAM. Weitere allgemeine Informationen finden Sie unter [Übersicht über JSON-Richtlinien](access_policies.md#access_policies-json).
Diese Referenz enthält folgende Abschnitte.
+ [Referenz zum IAM-JSON-Richtlinienelement](reference_policies_elements.md) – erfahren Sie mehr über die Elemente, die Sie beim Erstellen einer Richtlinie verwenden können. Zeigen Sie weitere Richtlinienbeispiele an und erfahren Sie mehr über Bedingungen, unterstützte Datentypen und ihre Verwendung in verschiedenen Services.
+ [Auswertungslogik für Richtlinien](reference_policies_evaluation-logic.md)— In diesem Abschnitt werden AWS Anfragen beschrieben, wie sie authentifiziert werden und wie Richtlinien AWS verwendet werden, um den Zugriff auf Ressourcen zu bestimmen.
+ [Grammatik der IAM-JSON-Richtliniensprache](reference_policies_grammar.md): – In diesem Abschnitt wird die formale Grammatik der zum Erstellen von Richtlinien in IAM verwendeten Sprache vorgestellt.
+ [AWS verwaltete Richtlinien für Jobfunktionen](access_policies_job-functions.md) – In diesem Abschnitt werden alle von AWS verwalteten Richtlinien aufgelistet, die den in der IT-Branche üblichen Auftragsfunktionen entsprechen. Verwenden Sie diese Richtlinien, um die zur Ausführung der in einer bestimmten Auftragsfunktion erwarteten Aufgaben erforderlichen Berechtigungen zu gewähren. Diese Richtlinien konsolidieren Berechtigungen für viele Services in einer einzigen Richtlinie.
+ [AWS Kontextschlüssel für globale Bedingungen](reference_policies_condition-keys.md)— Dieser Abschnitt enthält eine Liste aller AWS globalen Bedingungsschlüssel, mit denen Sie die Berechtigungen in einer IAM-Richtlinie einschränken können.
+ [IAM- und AWS STS Bedingungskontextschlüssel](reference_policies_iam-condition-keys.md)— Dieser Abschnitt enthält eine Liste aller IAM- und AWS STS Bedingungsschlüssel, mit denen Sie die Berechtigungen in einer IAM-Richtlinie einschränken können.
+ [Aktionen, Ressourcen und Bedingungsschlüssel für AWS Dienste](reference_policies_actions-resources-contextkeys.html) — Dieser Abschnitt enthält eine Liste aller AWS API-Operationen, die Sie als Berechtigungen in einer IAM-Richtlinie verwenden können. Er enthält außerdem servicespezifische Bedingungsschlüssel, die zur Feinabstimmung der Anforderung herangezogen werden können.
# Referenz zum IAM-JSON-Richtlinienelement
JSON-Richtliniendokumente bestehen aus Elementen. Die Elemente sind in der Reihenfolge aufgelistet, in der Sie in einer Richtlinie verwendet werden. Die Reihenfolge der Elemente ist unerheblich - Das Element `Resource` kann z. B. vor dem Element `Action` angeordnet sein. Sie müssen nicht alle `Condition`-Elemente in der Richtlinie angeben. Weitere Informationen zur allgemeinen Struktur und zum Zweck eines JSON-Richtliniendokuments finden Sie unter [Übersicht über JSON-Richtlinien](access_policies.md#access_policies-json).
Einige Elemente der JSON-Richtlinie schließen sich gegenseitig. Das bedeutet, dass Sie keine Richtlinie erstellen können, in der beides verwendet wird. Sie können beispielsweise `Action` und `NotAction` nicht in der gleichen Richtlinienanweisung verwenden. Auch die Paare `Principal`/`NotPrincipal` und `Resource`/`NotResource` schließen sich gegenseitig.
Die in einer Richtlinie enthaltenen Elemente sind für jeden Service unterschiedlich und davon abhängig, welche Aktionen der Service bereitstellt, welche Ressourcentypen enthalten sind usw. Wenn Sie Richtlinien für einen bestimmten Service definieren, ist es hilfreich, sich auf Richtlinienbeispiele für diesen Service zu beziehen. Eine Liste aller Services mit IAM-Unterstützung und Links zu der Dokumentation für diese Services, in der IAM und Richtlinien behandelt werden, finden Sie unter [AWS Dienste, die mit IAM funktionieren](reference_aws-services-that-work-with-iam.md).
Wenn Sie eine JSON-Richtlinie erstellen oder bearbeiten, kann IAM eine Richtlinienvalidierung durchführen, um Ihnen beim Erstellen einer effektiven Richtlinie zu helfen. IAM identifiziert JSON-Syntaxfehler, während IAM Access Analyzer zusätzliche Richtlinienüberprüfungen mit Empfehlungen zur weiteren Verfeinerung Ihrer Richtlinien bietet. Weitere Informationen zur Richtlinienvalidierung finden Sie unter [IAM-Richtlinien-Validierung](access_policies_policy-validator.md). Weitere Informationen zu den Richtlinienvalidierungen von IAM Access Analyzer Richtlinien und Empfehlungen erhalten Sie unter [Richtlinienvalidierung von IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html).
**Topics**
+ [Version](reference_policies_elements_version.md)
+ [Id](reference_policies_elements_id.md)
+ [Statement](reference_policies_elements_statement.md)
+ [Sid](reference_policies_elements_sid.md)
+ [Effect](reference_policies_elements_effect.md)
+ [Principal](reference_policies_elements_principal.md)
+ [NotPrincipal](reference_policies_elements_notprincipal.md)
+ [Action](reference_policies_elements_action.md)
+ [NotAction](reference_policies_elements_notaction.md)
+ [Resource](reference_policies_elements_resource.md)
+ [NotResource](reference_policies_elements_notresource.md)
+ [Condition](reference_policies_elements_condition.md)
+ [Variablen und Tags](reference_policies_variables.md)
+ [Unterstützte Datentypen](reference_policies_elements_datatypes.md)
# IAM-JSON-Richtlinienelemente: Version
**Hinweis zur Begriffsklärung**
Dieses `Version`JSON Richtlinienelement unterscheidet sich von einer *Richtlinienversion*. Das Richtlinienelement `Version` wird innerhalb einer Richtlinie verwendet und gibt die Version der Richtliniensprache an. Andererseits wird eine Richtlinienversion erstellt, wenn Sie in IAM eine benutzerdefinierte, verwaltete Richtlinie bearbeiten. Die vorhandene Richtlinie wird von der geänderten Richtlinie nicht überschrieben. IAM erstellt stattdessen eine neue Version der verwalteten Richtlinie. Weitere Informationen zur Unterstützung mehrerer Versionen für verwaltete Richtlinien finden Sie unter [Versioning von IAM-Richtlinien](access_policies_managed-versioning.md).
Die `Version`-Richtlinienelemente legen die Sprachsyntaxregeln fest, die für die Verarbeitung einer Richtlinie verwendet werden sollen. Um alle verfügbaren Richtlinienfunktionen zu nutzen, fügen Sie in all Ihre Richtlinien das folgende `Version`-Element **vor** dem `Statement`-Element ein.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "*"
}
]
}
```
------
IAM unterstützt die folgenden `Version`-Elementwerte:
+ `2012-10-17`. Hierbei handelt es sich um die aktuelle Version der Richtliniensprache. Sie sollte immer ein `Version`-Element einschließen mit `2012-10-17`. Andernfalls können Sie keine Funktionen verwenden, wie z. B. [Richtlinienvariablen](reference_policies_variables.md), die mit dieser Version eingeführt wurden.
+ `2008-10-17`. Dies ist eine ältere Version der Richtliniensprache. Diese Version kann in älteren Richtlinien verwendet werden. Verwenden Sie diese Version nicht für neue Richtlinien oder wenn Sie vorhandene Richtlinien aktualisieren. Neuere Features, z. B. Richtlinienvariablen, funktionieren nicht mit Ihrer Richtlinie. Beispielsweise werden Variablen wie `${aws:username}` nicht als Variablen erkannt und stattdessen als literale Zeichenketten in der Richtlinie behandelt.
# IAM-JSON-Richtlinienelemente: Id
Das `Id`-Element definiert eine optionale ID für die Richtlinie. Die Verwendung der ID in verschiedenen Services ist unterschiedlich. Die ID ist in ressourcenbasierten Richtlinien zulässig, nicht jedoch in identitätsbasierten Richtlinien.
Für Services, für die Sie ein `ID`-Element definieren können, empfehlen wir, dass Sie eine UUID (GUID) für den Wert verwenden oder dass Sie zur Sicherstellung der Eindeutigkeit eine UUID als Bestandteil der ID aufnehmen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "cd3ad3d9-2776-4ef1-a904-4c229d1642ee",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "*"
}
]
}
```
------
**Anmerkung**
Für einige AWS Dienste (z. B. Amazon SQS oder Amazon SNS) ist dieses Element möglicherweise erforderlich und es gelten Eindeutigkeitsanforderungen. Servicespezifische Hinweise zur Erstellung von Richtlinien finden Sie in der Dokumentation für den entsprechenden Service.
# IAM-JSON-Richtlinienelemente: Statement
Das Element `Statement` ist das Hauptelement einer Richtlinie. Dieses Element ist erforderlich. Das `Statement`-Element kann eine einzelne Anweisung oder ein Array von einzelnen Anweisungen enthalten. Jeder einzelne Anweisungsblock muss in geschweifte Klammern \$1 \$1 eingeschlossen sein. Bei mehreren Anweisungen muss das Array in eckige Klammern [ ] eingeschlossen sein.
```
"Statement": [{...},{...},{...}]
```
Das folgende Beispiel zeigt eine Richtlinie mit einem Array mit drei Anweisungen in einem `Statement`-Element. (Die Richtlinie gewährt Ihnen den Zugriff auf Ihre eigenen "Basisordner" in der Amazon S3-Konsole.) Die Richtlinie enthält die Variable `aws:username`, die während der Richtlinienauswertung durch den in der Anforderung enthaltenen Benutzernamen ersetzt wird. Weitere Informationen finden Sie unter [Einführung](reference_policies_variables.md#policy-vars-intro).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListAllMyBuckets",
"s3:GetBucketLocation"
],
"Resource": "arn:aws:s3:::*"
},
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
"Condition": {"StringLike": {"s3:prefix": [
"",
"home/",
"home/${aws:username}/"
]}}
},
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/home/${aws:username}",
"arn:aws:s3:::amzn-s3-demo-bucket/home/${aws:username}/*"
]
}
]
}
```
------
# IAM-JSON-Richtlinienelemente: Sid
Sie können eine `Sid` (Anweisungs-ID) als optionale Kennung für die Richtlinienanweisung angeben. Sie können jeder Anweisung in einem Statement-Array einen `Sid`-Wert zuweisen. Sie können den `Sid`-Wert als Beschreibung für die Richtlinienerklärung verwenden. In Services, bei denen Sie ein `ID`-Element angeben können, wie z. B. SQS und SNS, ist der `Sid`-Wert nur eine Sub-ID der ID des Richtliniendokuments. In IAM muss der `Sid`-Wert innerhalb einer JSON-Richtlinie eindeutig sein.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ExampleStatementID",
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "*"
}
]
}
```
------
Das `Sid`-Element unterstützt ASCII-Großbuchstaben (A-Z), Kleinbuchstaben (a–z) und Ziffern (0–9).
In IAM ist `Sid` nicht im IAM-API veröffentlicht. Sie können keine bestimmte Anweisung basierend auf dieser ID abrufen.
**Anmerkung**
Für einige AWS Dienste (z. B. Amazon SQS oder Amazon SNS) ist dieses Element möglicherweise erforderlich und es gelten Eindeutigkeitsanforderungen. Servicespezifische Hinweise zur Erstellung von Richtlinien finden Sie in der Dokumentation für den entsprechenden Service.
# IAM-JSON-Richtlinienelemente: Effect
Das Element `Effect` ist erforderlich und gibt an, ob die Anweisung eine Zugriffserlaubnis oder eine explizite Zugriffsverweigerung bewirkt. Gültige Werte für `Effect` sind `Allow` und `Deny`. Beim `Effect`-Wert ist die Groß- und Kleinschreibung zu beachten.
```
"Effect":"Allow"
```
Standardmäßig wird der Zugriff auf Ressourcen verweigert. Um den Zugriff auf eine Ressource zuzulassen, müssen Sie das `Effect`-Element auf `Allow` setzen. Um eine Zugriffserlaubnis zu überschreiben (z. B. um eine aktive Zugriffserlaubnis zu überschreiben), setzen Sie das Element `Effect` auf `Deny`. Weitere Informationen finden Sie unter [Auswertungslogik für Richtlinien](reference_policies_evaluation-logic.md).
# AWS JSON-Richtlinienelemente: Principal
Verwenden Sie das `Principal`-Element in einer ressourcebasierten JSON Richtlinie, um den Auftraggeber anzugeben, dem der Zugriff auf eine Ressource erlaubt oder verweigert wird.
Sie müssen das `Principal`-Element in [ressourcenbasierten Richtlinien](access_policies_identity-vs-resource.md) verwenden. Mehrere Services unterstützen ressourcenbasierte Richtlinien, einschließlich IAM. Der ressourcenbasierte IAM-Richtlinientyp ist eine Rollenvertrauensrichtlinie. Verwenden Sie in IAM-Rollen das `Principal`-Element in der Rollenvetrauensichtlinie, um anzugeben, wer diese Rolle übernehmen kann. Für den kontoübergreifenden Zugriff müssen Sie die 12-stellige ID des vertrauenswürdigen Kontos angeben. Informationen darüber, ob Auftraggeber in Konten außerhalb Ihrer Vertrauenszone (vertrauenswürdige Organisation oder Konto) Zugriff zur Annahme Ihrer Rollen haben, finden Sie unter [Was ist IAM Access Analyzer?](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html).
**Anmerkung**
Nachdem Sie die Rolle erstellt haben, können Sie das Konto zu „\$1“ ändern, damit jeder die Rolle übernehmen kann. Wenn Sie dies tun, empfehlen wir dringend, dass Sie den Zugriff auf die Rolle mit anderen Mitteln begrenzen, wie z. B. mit einem `Condition`-Element, das den Zugriff auf bestimmte IP-Adressen beschränkt. Schränken Sie den Zugriff auf Ihre Rolle unbedingt ein\$1
Andere Beispiele für Ressourcen, die ressourcenbasierte Richtlinien unterstützen, sind ein Amazon-S3-Bucket oder einen AWS KMS key.
Sie können das Element `Principal` nicht in einer identitätsbasierten Richtlinie verwenden. Identitätsbasierte Richtlinien sind Berechtigungsrichtlinien, die Sie an eine IAM-Identität anfügen können, wie z. B. -Benutzer, -Rollen oder -Gruppen. In diesen Richtlinien wird der Prinzipal von der Identität impliziert, der der Richtlinie angefügt ist.
**Topics**
+ [So legen Sie einen Prinzipal fest](#Principal_specifying)
+ [AWS-Konto Schulleiter](#principal-accounts)
+ [IAM-Rollenauftraggeber](#principal-roles)
+ [Rollensitzungsgsprinzipale](#principal-role-session)
+ [OIDC-Verbundprinzipale](#principal-federated-web-identity)
+ [SAML-Verbundprinzipale](#principal-saml)
+ [IAM-Benutzerprinzipal](#principal-users)
+ [Prinzipale von IAM Identity Center](#principal-identity-users)
+ [AWS STS föderierte Benutzerprinzipale](#sts-session-principals)
+ [AWS Dienstprinzipale](#principal-services)
+ [AWS Dienstprinzipale in Opt-in-Regionen](#principal-services-in-opt-in-regions)
+ [Alle Prinzipale](#principal-anonymous)
+ [Weitere Informationen](#Principal_more-info)
## So legen Sie einen Prinzipal fest
Sie geben einen Prinzipal in dem `Principal`-Element einer ressourcenbasierten Richtlinie oder in Bedingungsschlüsseln an, die Prinzipale unterstützen.
Sie können einen der folgenden Auftraggeber in einer Richtlinie angeben:
+ AWS-Konto und Root-Benutzer
+ IAM-Rollen
+ Rollensitzungen
+ IAM-Benutzer
+ Verbundbenutzer-Prinzipale
+ AWS Dienste
+ Alle Prinzipale
Sie können eine Benutzergruppe nicht als Prinzipal in einer Richtlinie (z. B. einer ressourcenbasierten Richtlinie) identifizieren, da sich Gruppen auf Berechtigungen und nicht auf die Authentifizierung beziehen, während Prinzipale authentifizierte IAM-Entitäten sind.
Sie können mehrere Auftraggeber für jeden der Auftraggebertypen in den folgenden Abschnitten mithilfe eines Arrays angeben. Arrays können einen oder mehrere Werte enthalten. Wenn Sie mehr als einen Auftraggeber im Element angeben, erteilen Sie jedem Auftraggeber Berechtigungen. Dies ist ein logisches `OR` und kein logisches `AND`, da Sie jeweils als ein Auftraggeber authentifiziert sind. Wenn Sie mehr als einen Wert angeben, verwenden Sie eckige Klammern (`[` und `]`) und trennen Sie jeden Eintrag für das Array durch Kommas. Die folgende Beispielrichtlinie definiert Berechtigungen für das 123456789012-Konto oder das 555555555555-Konto.
```
"Principal" : {
"AWS": [
"123456789012",
"555555555555"
]
}
```
**Anmerkung**
Sie können keinen Platzhalter verwenden, um einen Teil eines Namens oder eines ARNs zu ersetzen.
## AWS-Konto Schulleiter
Sie können AWS-Konto Bezeichner im `Principal` Element einer ressourcenbasierten Richtlinie oder in Bedingungsschlüsseln angeben, die Prinzipale unterstützen. Dadurch wird die Autorität des Kontos delegiert. Wenn Sie den Zugriff auf ein anderes Konto zulassen, muss ein Administrator in diesem Konto dann Zugriff auf eine Identität (IAM-Benutzer oder -Rolle) in diesem Konto gewähren. Wenn Sie eine angeben AWS-Konto, können Sie den Konto-ARN (arn:aws:iam: :root*account-ID*) oder eine verkürzte Form verwenden, die aus dem Präfix gefolgt von der Konto-ID besteht. `"AWS":`
Wenn die Konto-ID beispielsweise `123456789012` lautet, können Sie eine der folgenden Methoden verwenden, um das betreffende Konto im Element `Principal` anzugeben:
```
"Principal": { "AWS": "arn:aws:iam::123456789012:root" }
```
```
"Principal": { "AWS": "123456789012" }
```
Mit dem Konto-ARN und der verkürzten Konto-ID verhält es sich genauso. Beide delegieren Berechtigungen für das Konto. Wenn das Konto ARN im `Principal`-Element verwendet wird, werden die Berechtigungen nicht nur auf den Stamm-Benutzer des Kontos beschränkt.
**Anmerkung**
Wenn Sie eine ressourcenbasierte Richtlinie speichern, die die verkürzte Konto-ID enthält, konvertiert der Dienst sie möglicherweise in den Haupt-ARN. Dies ändert nichts an der Funktionalität der Richtlinie.
Einige AWS Dienste unterstützen zusätzliche Optionen für die Angabe eines Kontoprinzipals. Bei Amazon S3 können Sie beispielsweise eine [kanonische Benutzer-ID](https://docs.aws.amazon.com/general/latest/gr/acct-identifiers.html#FindingCanonicalId) in folgendem Format angeben:
```
"Principal": { "CanonicalUser": "79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be" }
```
Sie können mithilfe eines Arrays auch mehr als eine AWS-Konto(oder kanonische Benutzer-ID) als Prinzipal angeben. Beispielsweise können Sie mit allen drei Methoden einen Prinzipal in einer Bucket-Richtlinie angeben.
```
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:root",
"999999999999"
],
"CanonicalUser": "79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be"
}
```
## IAM-Rollenauftraggeber
Sie können den IAM-Rollenprinzipal ARNs im `Principal` Element einer ressourcenbasierten Richtlinie oder in Bedingungsschlüsseln angeben, die Prinzipale unterstützen. IAM-Rollen sind Identitäten. In IAM sind Identitäten Ressourcen, denen Sie Berechtigungen zuweisen können. Rollen vertrauen einer anderen authentifizierten Identität, um diese Rolle zu übernehmen. Dies beinhaltet einen Prinzipal in AWS oder einem Benutzer eines externen Identitätsanbieters (IdP). Wenn ein Prinzipal oder eine Identität eine Rolle übernimmt, erhalten sie temporäre Sicherheitsanmeldeinformationen mit den Berechtigungen der angenommenen Rolle. *Wenn sie diese Sitzungsanmeldedaten für die Ausführung von Vorgängen verwenden AWS, werden sie zu Rollen-Sitzungsprinzipalen.*
Wenn Sie einen Rollenprinzipal in einer ressourcenbasierten Richtlinie angeben, sind die effektiven Berechtigungen für den Prinzipal durch alle Richtlinientypen begrenzt, die Berechtigungen für die Rolle einschränken. Dies umfasst Sitzungssrichtlinien und Berechtigungsgrenzen. Weitere Informationen zur Auswertung der effektiven Berechtigungen für eine Rollensitzung finden Sie unter [Auswertungslogik für Richtlinien](reference_policies_evaluation-logic.md).
Um die Rolle ARN im `Principal`-Element anzugeben, verwenden Sie das folgende Format:
```
"Principal": { "AWS": "arn:aws:iam::AWS-account-ID:role/role-name" }
```
**Wichtig**
Wenn Ihr `Principal`-Element in einer Vertrauensrichtlinie einer Rolle einen ARN enthält, der auf eine bestimmte IAM-Rolle verweist, wird dieser ARN beim Speichern der Richtlinie in die eindeutige Prinzipal-ID der Rolle umgewandelt. Auf diese Weise wird das Risiko reduziert, dass jemand seine Berechtigungen durch Entfernen und Neuerstellen der Rolle erweitert. Normalerweise wird diese ID nicht in der Konsole angezeigt, da IAM bei der Anzeige der Vertrauensrichtlinie eine Rückumwandlung zum Rollen-ARN verwendet. Wenn Sie jedoch die Rolle löschen, wird die Beziehung aufgehoben. Die Richtlinie wird nicht mehr angewendet, selbst wenn Sie die Rolle neu erstellen, da die Auftraggeber-ID der neuen Rolle nicht mit der in der Vertrauensrichtlinie gespeicherten ID übereinstimmt. In diesem Fall wird die Prinzipal-ID in ressourcenbasierten Richtlinien angezeigt, da sie nicht mehr einem gültigen ARN zugeordnet werden AWS kann. Daher müssen Sie die Rolle bearbeiten, um die nunmehr falsche Prinzipal-ID mit dem richtigen ARN zu ersetzen, wenn Sie eine mit einem `Principal`-Element einer Vertrauensrichtlinie verknüpfte Rolle löschen und neu erstellen. Der ARN wird beim Speichern der Richtlinie erneut in die neue Auftraggeber-ID der Rolle umgewandelt. Weitere Informationen finden Sie unter [Grundlegendes AWS zum Umgang mit gelöschten IAM-Rollen](https://repost.aws/articles/ARSqFcxvd7R9u-gcFD9nmA5g/understanding-aws-s-handling-of-deleted-iam-roles-in-policies) in Richtlinien.
Alternativ können Sie den Rollenprinzipal als Prinzipal in einer ressourcenbasierten Richtlinie angeben oder [erstellen Sie eine Richtlinie mit breiter Berechtigung](#principal-anonymous) die `aws:PrincipalArn`-Bedingungsschlüssel benutzt. Wenn Sie diesen Schlüssel verwenden, erteilen Sie dem Rollensitzungsprinzipalen die Berechtigungen basierend auf dem übernommenen ARN der Rolle und nicht dem ARN der resultierenden Sitzung. Da der Bedingungsschlüssel AWS ARNs nicht konvertiert wird IDs, bleiben die dem Rollen-ARN gewährten Berechtigungen bestehen, wenn Sie die Rolle löschen und dann eine neue Rolle mit demselben Namen erstellen. Identitätsbasierte Richtlinientypen, wie z. B. Berechtigungsgrenzen oder Sitzungsrichtlinien, schränken die gewährten Berechtigungen nicht ein, indem sie den `aws:PrincipalArn`-Bedingungsschlüssel mit einem Platzhalter (\$1) im `Principal`-Element verwenden, es sei denn, die identitätsbasierten Richtlinien enthalten eine ausdrückliche Verweigerung.
## Rollensitzungsgsprinzipale
Sie können Rollensitzungen im `Principal`-Element einer ressourcenbasierten Richtlinie oder in Bedingungsschlüsseln, die Prinzipale unterstützen, angeben. Wenn ein Prinzipal oder eine Identität eine Rolle übernimmt, erhalten sie temporäre Sicherheitsanmeldeinformationen mit den Berechtigungen der angenommenen Rolle. Wenn sie diese Sitzungsanmeldedaten für die Ausführung von Vorgängen verwenden AWS, werden sie zu *Rollen-Sitzungsprinzipalen*.
Das Format, das Sie für einen Rollensitzungsprinzipal verwenden, hängt von dem AWS STS Vorgang ab, mit dem die Rolle übernommen wurde.
**Wichtig**
AWS empfiehlt, wo immer [möglich IAM-Rollenprinzipale](#principal-roles) anstelle von Rollensitzungsprinzipalen in Ihren Richtlinien zu verwenden. Verwenden Sie `Condition` Anweisungen und Bedingungsschlüssel, um den Zugriff bei Bedarf weiter einzuschränken.
Verwenden Sie das folgende Format, um den ARN des Rollensitzungsprinzipals im `Principal` Element anzugeben:
```
"Principal": { "AWS": "arn:aws:sts::AWS-account-ID:assumed-role/role-name/role-session-name" }
```
Darüber hinaus können Administratoren einen Prozess entwerfen, um zu steuern, wie Rollensitzungen ausgegeben werden. Sie können beispielsweise eine Ein-Klick-Lösung für ihre Benutzer bereitstellen, die einen vorhersehbaren Sitzungsnamen erstellt. Wenn Ihr Administrator dies tut, können Sie Rollensitzungsprinzipale in Ihren Richtlinien oder Bedingungsschlüsseln verwenden. Andernfalls können Sie die Rollen-ARN als Prinzipal im `aws:PrincipalArn`-Bedingungsschlüssel angeben. Wie Sie die Rolle als Prinzipal angeben, kann die effektiven Berechtigungen für die resultierend Sitzung ändern. Weitere Informationen finden Sie unter [IAM-Rollenauftraggeber](#principal-roles).
## OIDC-Verbundprinzipale
Ein OIDC-Verbundprinzipal ist der Prinzipal, der verwendet wird, wenn die AWS STS `AssumeRoleWithWebIdentity` API mit einem JSON-Webtoken (JWT) von einem OIDC-kompatiblen IDP, auch bekannt als OpenID Provider (OP), aufgerufen wird, um temporäre Anmeldeinformationen anzufordern. AWS [Ein OIDC-Verbundprinzipal kann einen OIDC-IDP in Ihrem AWS Konto oder die 4 integrierten Identitätsanbieter darstellen:Login with Amazon,, und Amazon Cognito. GoogleFacebook](https://docs.aws.amazon.com/cognito/latest/developerguide/role-based-access-control.html)
Benutzer, Workloads oder Systeme, denen von ihrem OIDC-IDP ein JWT ausgestellt wurde, können `AssumeRoleWithWebIdentity` mithilfe des JWT anrufen, um temporäre AWS Sicherheitsanmeldedaten für eine IAM-Rolle anzufordern, die so konfiguriert ist, dass sie dem OIDC-IDP, der das JWT ausgestellt hat, vertraut. Das JWT kann ein ID-Token, ein Zugriffstoken oder ein auf anderem Wege übermitteltes JWT-Token sein, sofern es die [Anforderungen von AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html#manage-oidc-provider-prerequisites) erfüllt. Weitere Informationen finden Sie unter [Gängige Szenarien](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_federation_common_scenarios.html) und [Anmeldeinformationen über einen OIDC-Anbieter anfordern](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html#api_assumerolewithwebidentity).
Verwenden Sie diesen Prinzipaltyp in Ihrer Rollen-Vertrauensrichtlinie, um Anrufberechtigungen `AssumeRoleWIthWebIdentity` über einen OIDC-IDP zuzulassen oder zu verweigern, der in Ihrem oder einem der vier integrierten Systeme vorhanden ist. AWS-Konto IDPs Um den OIDC-Verbundprinzipal-ARN im `Principal` Element einer Rollenvertrauensrichtlinie anzugeben, verwenden Sie eines der folgenden vier Formate für das integrierte OIDC: IDPs
```
"Principal": { "Federated": "cognito-identity.amazonaws.com" }
```
```
"Principal": { "Federated": "www.amazon.com" }
```
```
"Principal": { "Federated": "graph.facebook.com" }
```
```
"Principal": { "Federated": "accounts.google.com" }
```
Wenn Sie einen OIDC-Anbieter verwenden, den Sie Ihrem Konto hinzufügen, geben Sie beispielsweise GitHub den ARN des Anbieters in der Vertrauensrichtlinie Ihrer Rolle an. Diese Konfiguration ermöglicht es Ihnen, IAM-Richtlinien zu schreiben, die den Zugriff speziell für Benutzer steuern, die über Ihren benutzerdefinierten Identitätsanbieter authentifiziert wurden.
```
"Principal": { "Federated": "arn:aws:iam::AWS-account-ID:oidc-provider/full-OIDC-identity-provider-URL" }
```
Wenn beispielsweise GitHub der vertrauenswürdige Web-Identitätsanbieter ist, verwendet der OIDC-Rollensitzungs-ARN im `Principal`-Element einer Rollenvertrauensrichtlinie das folgende Format:
```
"Principal": { "Federated": "arn:aws:iam::AWS-account-ID:oidc-provider/tokens.actions.githubusercontent.com" }
```
Weitere Informationen finden Sie unter [Konfigurieren von OpenID Connect in Amazon Web Services](https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services).
OIDC-Verbundprinzipale werden in anderen Richtlinientypen als Rollenvertrauensrichtlinien nicht unterstützt.
## SAML-Verbundprinzipale
Ein *SAML-Verbundprinzipal ist ein Prinzipal*, der verwendet wird, wenn eine AWS STS `AssumeRoleWithSAML` API aufgerufen wird, um mithilfe einer SAML-Assertion temporäre AWS Anmeldeinformationen anzufordern. Sie können sich mit Ihrem SAML-Identitätsanbieter (IDP) anmelden und dann mit diesem Vorgang eine IAM-Rolle übernehmen. Ähnlich wie`AssumeRoleWithWebIdentity`, benötigt `AssumeRoleWithSAML` AWS keine Anmeldeinformationen für die Authentifizierung. Stattdessen authentifizieren sich Benutzer zunächst bei ihrem SAML-Identitätsanbieter und führen dann den `AssumeRoleWithSAML` API-Aufruf mithilfe ihrer SAML-Assertion durch, oder sie werden zur AWS Anmelde-/SAML-Seite weitergeleitet, um sich dort anzumelden. AWS-Managementkonsole Weitere Informationen darüber, welche Prinzipale bei dieser Operation eine Rolle übernehmen können, finden Sie unter [AWS STS Referenzen vergleichen](id_credentials_sts-comparison.md).
Verwenden Sie diesen Prinzipaltyp in Ihrer Rollenvertrauensrichtlinie, um Berechtigungen basierend auf dem vertrauenswürdigen SAML-Identitätsanbieter zu erteilen oder zu verweigern. Um dem ARN der SAML-Identitäts-Rollensitzung im `Principal`-Element eine Rollenvetrauensrichtlinie zu geben, verwenden Sie das folgende Format:
```
"Principal": { "Federated": "arn:aws:iam::AWS-account-ID:saml-provider/provider-name" }
```
## IAM-Benutzerprinzipal
Sie können IAM-Benutzer im `Principal`-Element einer ressourcenbasierten Richtlinie oder in Bedingungsschlüsseln angeben, die Prinzipale unterstützen.
**Anmerkung**
Bei einem `Principal`-Element, bei dem Benutzernamen Teil des [*Amazon-Ressourcenname*(ARN)](reference_identifiers.md#identifiers-arns) ist, wird zwischen Groß- und Kleinschreibung unterschieden.
```
"Principal": { "AWS": "arn:aws:iam::AWS-account-ID:user/user-name" }
```
```
"Principal": {
"AWS": [
"arn:aws:iam::AWS-account-ID:user/user-name-1",
"arn:aws:iam::AWS-account-ID:user/user-name-2"
]
}
```
Wenn Sie Benutzer in einem `Principal`-Element angeben, können Sie keinen Platzhalter (`*`) für "alle Benutzer" verwenden. Auftraggeber müssen stets bestimmter Benutzer angeben.
**Wichtig**
Wenn Ihr `Principal`-Element in einer Rollenvetrauensichtlinie einen ARN enthält, der auf einen bestimmten IAM-Benutzer verweist, wird dieser ARN beim Speichern der Richtlinie in die eindeutige Auftraggeber-ID des Benutzers umgewandelt. Auf diese Weise wird das Risiko reduziert, dass jemand seine Berechtigungen durch Entfernen und Neuerstellen des Benutzers erweitert. Normalerweise wird diese ID nicht in der Konsole angezeigt, da bei der Anzeige der Vertrauensrichtlinie auch eine Rückumwandlung in die Benutzer-ARN erfolgt. Wenn Sie jedoch den Benutzer löschen, wird die Beziehung aufgehoben. Die Richtlinie wird dann nicht mehr angewendet, selbst wenn Sie den Benutzer neu erstellen. Dies liegt daran, dass die Auftraggeber-ID des neuen Benutzers nicht mit der in der Vertrauensrichtlinie gespeicherten ID übereinstimmt. In diesem Fall wird die Prinzipal-ID in ressourcenbasierten Richtlinien angezeigt, da sie nicht mehr einem gültigen ARN zugeordnet werden AWS kann. Daher müssen Sie die Rolle bearbeiten, um die nunmehr falsche Auftraggeber-ID durch den richtigen ARN zu ersetzen, wenn Sie einen mit einem `Principal`-Element einer Vertrauensrichtlinie verknüpften Benutzer löschen und neu erstellen. IAM wandelt beim Speichern der Richtlinie den ARN erneut in die neue Haupt-ID des Benutzers um.
## Prinzipale von IAM Identity Center
In IAM Identity Center muss der Prinzipal in einer ressourcenbasierten Richtlinie als AWS-Konto -Prinzipal definiert werden. Um Zugriff anzugeben, verweisen Sie auf den Rollen-ARN der im Bedingungsblock festgelegten Berechtigung. Einzelheiten finden Sie unter [Referencing permission sets in resource policies, Amazon EKS, and AWS KMS](https://docs.aws.amazon.com/singlesignon/latest/userguide/referencingpermissionsets.html) im *Benutzerhandbuch zu IAM Identity Center*.
## AWS STS föderierte Benutzerprinzipale
Sie können *Verbundbenutzersitzungen* im `Principal`-Element einer ressourcenbasierten Richtlinie oder in Bedingungsschlüsseln angeben, die Prinzipale unterstützen.
**Wichtig**
AWS empfiehlt, die Verwendung von AWS STS Verbundbenutzersitzungen einzuschränken. Verwenden Sie stattdessen [IAM-Rollen](IAM/latest/UserGuide/tutorial_cross-account-with-roles.html).
Ein AWS STS föderierter Benutzerprinzipal wird durch den `GetFederationToken` Vorgang erstellt, der mit langlebigen IAM-Anmeldeinformationen aufgerufen wird. Die Berechtigungen des Verbundbenutzers ergeben sich aus der Schnittmenge des Prinzipals, der `GetFederationToken` aufgerufen hat, und der Sitzungsrichtlinien, die als Parameter an die `GetFederationToken`-API übergeben wurden.
In Root-Benutzer des AWS-Kontos können AWS sich IAM-Benutzer oder ein Benutzer mit langfristigen Zugriffsschlüsseln authentifizieren. Weitere Informationen zum Verbünden von Prinzipalen mittles dieser Produktion finden Sie unter [AWS STS Referenzen vergleichen](id_credentials_sts-comparison.md).
+ **IAM-Verbundbenutzer** – Ein IAM-Benutzer wird mithilfe des `GetFederationToken`-Vorgangs verbunden, was zu einer Verbundbenutzersitzung für diesen IAM-Benutzer führt.
+ **Root-Verbundbenutzer** – Ein Root-Benutzer wird mithilfe des `GetFederationToken`-Vorgangs verbunden, was zu einer Verbundbenutzersitzung für diesen Root-Benutzer führt.
Wenn ein IAM-Benutzer oder Root-Benutzer temporäre Anmeldeinformationen für diesen Vorgang anfordert, beginnt er eine temporäre Verbundbenutzersitzung. AWS STS Der ARN dieser Sitzung basiert auf der ursprünglichen Identität, die verbunden wurde.
Um den ARN der Verbundbenutzersitzung im `Principal`-Element anzugeben, verwenden Sie das folgende Format:
```
"Principal": { "AWS": "arn:aws:sts::AWS-account-ID:federated-user/user-name" }
```
## AWS Dienstprinzipale
Sie können AWS Dienste als `Principal` Element einer ressourcenbasierten Richtlinie oder in Bedingungsschlüsseln angeben, die Prinzipale unterstützen. Ein *Service-Prinzipal* ist eine Kennung für einen Service.
*[IAM-Rollen, die von einem Dienst übernommen werden können, werden als AWS Servicerollen bezeichnet.](id_roles.md#iam-term-service-role)* Service-Rollen müssen eine Vertrauensrichtlinie enthalten. *Vertrauensrichtlinien* sind ressourcenbasierte Richtlinien, die einer Rolle zugeordnet sind. Sie definiert, welche Auftraggeber die Rolle übernehmen können. Einige Service-Rollen haben vordefinierte Vertrauensrichtlinien. In einigen Fällen müssen Sie jedoch den Dienstauftraggeber in der Vertrauensrichtlinie angeben. Der Service-Prinzipal in einer IAM-Richtlinie kann nicht `"Service": "*"` sein.
**Wichtig**
Der Bezeichner für einen Dienstauftraggeber enthält den Servicenamen und hat normalerweise das folgende Format:
`service-name.amazonaws.com`
Der Dienstauftraggeber wird durch den Service definiert. Sie können den Service-Prinzipal für einige Services finden, indem Sie [AWS Dienste, die mit IAM funktionieren](reference_aws-services-that-work-with-iam.md) öffnen, überprüfen, ob der Service in der Spalte **Serviceverknüpfte Rolle** **Ja** hat, und den Link **Ja** öffnen, um die Dokumentation zu serviceverknüpften Rollen für diesen Service anzuzeigen. Suchen Sie den Abschnitt **Service-Linked Role Permissions (Berechtigungen von serviceverknüpften Rollen)** für diesen Service, um den Dienstauftraggeber anzuzeigen.
Das folgende Beispiel zeigt eine Richtlinie, die einer Service-Rolle angefügt werden kann. Diese Richtlinie ermöglicht zwei Services, Amazon ECS und Elastic Load Balancing, die Übernahme der Rolle. Die Services können dann sämtliche Aufgaben ausführen, zu denen die Rolle infolge der zugewiesenen Berechtigungsrichtlinie berechtigt ist (nicht dargestellt). Geben Sie zur Angabe von mehreren Dienstauftraggeber nicht zwei `Service`-Elemente an. Sie können nur ein Element angeben. Verwenden Sie stattdessen ein Array mit mehreren Dienstauftraggeber als Wert eines einzelnen `Service`-Elements.
```
"Principal": {
"Service": [
"ecs.amazonaws.com",
"elasticloadbalancing.amazonaws.com"
]
}
```
## AWS Dienstprinzipale in Opt-in-Regionen
Sie können Ressourcen in mehreren AWS Regionen bereitstellen, und für einige dieser Regionen müssen Sie sich entscheiden. Eine vollständige Liste der Regionen, für die Sie sich anmelden müssen, finden Sie im *Allgemeine AWS-Referenz*Leitfaden unter [AWS Regionen verwalten](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html).
Wenn ein AWS Dienst in einer Opt-in-Region eine Anfrage innerhalb derselben Region stellt, wird das Format des Dienstprinzipalnamens als die nicht regionalisierte Version seines Dienstprinzipalnamens identifiziert:
`service-name.amazonaws.com`
Wenn ein AWS Dienst in einer Opt-in-Region eine regionsübergreifende Anfrage an eine andere Region stellt, wird das Format des Dienstprinzipalnamens als die regionalisierte Version seines Dienstprinzipalnamens identifiziert:
`service-name.{region}.amazonaws.com`
Angenommen, Sie haben ein Amazon-SNS-Thema in der Region `ap-southeast-1` und einen Amazon-S3-Bucket in der Opt-in-Region `ap-east-1`. Sie möchten S3-Bucket-Benachrichtigungen konfigurieren, um Nachrichten im SNS-Thema zu veröffentlichen. Damit der S3-Service Nachrichten im SNS-Thema posten kann, müssen Sie dem S3-Serviceprinzipal über die ressourcenbasierte Zugriffsrichtlinie des Themas die Berechtigung `sns:Publish` erteilen.
Wenn Sie in der Themenzugriffsrichtlinie die nicht regionalisierte Version des S3-Serviceprinzipals `s3.amazonaws.com` angeben, schlägt die `sns:Publish`-Anfrage vom Bucket an das Thema fehl. Im folgenden Beispiel wird der nicht regionalisierte S3-Serviceprinzipal im `Principal`-Richtlinienelement der SNS-Themenzugriffsrichtlinie angegeben.
```
"Principal": { "Service": "s3.amazonaws.com" }
```
Da sich der Bucket in einer Opt-In-Region befindet und die Anfrage außerhalb dieser Region gestellt wurde, wird der regionalisierte Name des S3-Serviceprinzipals angezeigt: `s3.ap-east-1.amazonaws.com`. Sie müssen den regionalisierten Dienstprinzipalnamen verwenden, wenn ein AWS Dienst in einer Opt-in-Region eine Anfrage an eine andere Region sendet. Wenn Sie den regionalisierten Namen des Serviceprinzipals angegeben haben und der Bucket eine `sns:Publish`-Anfrage an das SNS-Thema in einer anderen Region stellt, ist die Anfrage erfolgreich. Im folgenden Beispiel wird der regionalisierte S3-Serviceprinzipal im `Principal`-Richtlinienelement der SNS-Themenzugriffsrichtlinie angegeben.
```
"Principal": { "Service": "s3.ap-east-1.amazonaws.com" }
```
Ressourcenrichtlinien oder auf Serviceprinzipalen basierende Zulassungslisten für regionsübergreifende Anfragen von einer Opt-In-Region an eine andere Region sind nur erfolgreich, wenn Sie den regionalisierten Serviceprinzipalnamen angeben.
**Anmerkung**
Für Vertrauensrichtlinien von IAM-Rollen empfehlen wir, den nicht regionalisierten Serviceprinzipalnamen zu verwenden. IAM-Ressourcen sind global, daher kann dieselbe Rolle in jeder Region verwendet werden.
## Alle Prinzipale
Sie können ein Platzhalterzeichen (\$1) verwenden, um alle Prinzipale im `Principal`-Element einer ressourcenbasierten Richtlinie oder in Bedingungsschlüsseln, die Prinzipale unterstützen, anzugeben. [Ressourcenbasierte Richtlinien](access_policies.md#policies_resource-based) *Erteilungs*-Berechtigungen und [Bedingungsschlüssel](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) werden verwendet, um die Bedingungen einer Richtlinienanweisung einzuschränken.
**Wichtig**
Es wird ausdrücklich empfohlen, keinen Platzhalter (\$1) im `Principal`-Element einer ressourcenbasierten Richtlinie mit `Allow`-Effekt zu verwenden, es sei denn, Sie beabsichtigen, öffentlichen oder anonymen Zugang zu gewähren. Andernfalls geben Sie die beabsichtigten Prinzipale, Services oder AWS -Konten im `Principal`-Element an und schränken dann den Zugriff im `Condition`-Element weiter ein. Dies gilt insbesondere für Vertrauensrichtlinien für IAM-Rollen, da sie es anderen Prinzipalen erlauben, Prinzipale in Ihrem Konto zu werden.
Für ressourcenbasierte Richtlinien wird durch die Verwendung eines Platzhalters (\$1) mit einem `Allow`-Effekt der Zugriff auf alle Benutzer, einschließlich anonymer Benutzer (öffentlicher Zugriff), gewährt. Für IAM-Benutzer- und Rollenprinzipale innerhalb Ihres Kontos sind keine weiteren Berechtigungen erforderlich. Für Prinzipale in anderen Konten müssen sie auch identitätsbasierte Berechtigungen in ihrem Konto haben, mit denen sie auf Ihre Ressource zugreifen können. Dies wird als [kontenübergreifender Zugriff](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html) bezeichnet.
Für anonyme Benutzer sind die folgenden Elemente gleichwertig:
```
"Principal": "*"
```
```
"Principal" : { "AWS" : "*" }
```
Sie können keinen Platzhalter verwenden, um einen Teil eines Namens oder eines ARNs zu ersetzen.
Das folgende Beispiel zeigt eine ressourcenbasierte Richtlinie, die anstelle von [AWS JSON-Richtlinienelemente: NotPrincipal](reference_policies_elements_notprincipal.md) verwendet werden kann, um alle Prinzipale *mit Ausnahme* der im Element `Condition` angegebenen ausdrücklich abzulehnen. Diese Richtlinie sollte [einem Amazon-S3-Bucket hinzugefügt](https://docs.aws.amazon.com//AmazonS3/latest/userguide/add-bucket-policy.html) werden.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "UsePrincipalArnInsteadOfNotPrincipalWithDeny",
"Effect": "Deny",
"Action": "s3:*",
"Principal": "*",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/*",
"arn:aws:s3:::amzn-s3-demo-bucket"
],
"Condition": {
"ArnNotEquals": {
"aws:PrincipalArn": "arn:aws:iam::444455556666:user/user-name"
}
}
}
]
}
```
------
## Weitere Informationen
Weitere Informationen finden Sie hier:
+ [Beispiele für Bucket-Richtlinien](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies.html) im *Benutzerhandbuch für Amazon Simple Storage Service*
+ [Beispielrichtlinien für Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/UsingIAMwithSNS.html#ExamplePolicies_SNS) im *Entwicklerhandbuch für Amazon Simple Notification Service*
+ [Beispiele für Amazon SQS Richtlinien](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/SQSExamples.html) im *Entwicklerhandbuch für Amazon Simple Queue Service*
+ [Schlüsselrichtlinien](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) im *Entwicklerhandbuch für AWS Key Management Service *
+ [Kontokennungen](https://docs.aws.amazon.com/general/latest/gr/acct-identifiers.html) in der *Allgemeine AWS-Referenz*
+ [OIDC-Verbund](id_roles_providers_oidc.md)
# AWS JSON-Richtlinienelemente: NotPrincipal
Das `NotPrincipal`-Element verwendet `"Effect":"Deny"`, um allen Prinzipalen ***außer*** dem im `NotPrincipal`-Element angegebenen Prinzipal den Zugriff zu verweigern. Bei einem Prinzipal kann es sich um einen IAM-Benutzer, einen AWS STS Verbundbenutzerprinzipal, eine IAM-Rolle, eine Sitzung mit angenommener Rolle AWS-Konto, AWS einen Dienst oder einen anderen Prinzipaltyp handeln. Weitere Informationen zu Prinzipalen finden Sie unter [AWS JSON-Richtlinienelemente: Principal](reference_policies_elements_principal.md).
`NotPrincipal` muss mit `"Effect":"Deny"` verwendet werden. Die Verwendung mit `"Effect":"Allow"` wird nicht unterstützt.
**Wichtig**
Die Verwendung von `NotPrincipal` für neue ressourcenbasierte Richtlinien wird im Rahmen Ihrer Sicherheits- und Autorisierungsstrategie nicht empfohlen. Wenn Sie `NotPrincipal` verwenden, kann die Fehlerbehebung bei den Auswirkungen mehrerer Richtlinientypen schwierig sein. Wir empfehlen, stattdessen den `aws:PrincipalArn`-Kontextschlüssel mit ARN-Bedingungsoperatoren zu verwenden.
## Wichtige Punkte
+ Das `NotPrincipal`-Element wird in ressourcenbasierten Richtlinien für einige AWS -Services, einschließlich VPC-Endpunkte, unterstützt. Ressourcenbasierte Richtlinien sind Richtlinien, die Sie direkt in eine Ressource einbinden. Sie können das `NotPrincipal`-Element weder in einer identitätsbasierten IAM-Richtlinie noch in einer IAM-Rollenvertrauensrichtlinie verwenden.
+ Verwenden Sie keine ressourcenbasierten Richtlinienanweisungen, die ein `NotPrincipal`-Richtlinienelement mit einer `Deny`-Wirkung für IAM-Benutzer oder -Rollen enthalten, denen eine Richtlinie mit Berechtigungsgrenzen angefügt ist. Das `NotPrincipal`-Element mit `Deny`-Wirkung lehnt immer jeden IAM-Prinzipal ab, an den eine Richtlinie zur Berechtigungsgrenze angefügt ist, unabhängig von den im `NotPrincipal`-Element angegebenen Werten. Dies führt dazu, dass einige IAM-Benutzer oder -Rollen, die andernfalls Zugriff auf die Ressource hätten, den Zugriff verlieren. Wir empfehlen Ihnen, Ihre ressourcenbasierten Richtlinien dahingehend zu ändern, dass Sie den Bedingungsoperator [`ArnNotEquals`](reference_policies_elements_condition_operators.md#Conditions_ARN) mit dem [`aws:PrincipalArn`](reference_policies_condition-keys.md#condition-keys-principalarn)-Kontextschlüssel verwenden, um den Zugriff zu begrenzen, anstatt das `NotPrincipal`-Element. Weitere Informationen über Berechtigungsgrenzen finden Sie unter [Berechtigungsgrenzen für IAM-Entitäten](access_policies_boundaries.md).
+ Bei Verwendung von `NotPrincipal` müssen Sie auch den Konto-ARN des nicht verweigerten Prinzipals angeben. Andernfalls könnte durch die Richtlinie der Zugriff auf das gesamte Konto mit dem Auftraggeber verweigert werden. Abhängig vom Service, den Sie in Ihre Richtlinien einschließen, validiert AWS möglicherweise erst das Konto und dann den Benutzer. Wenn ein Benutzer mit übernommener Rolle (jemand, der eine Rolle verwendet) bewertet wird, validieren Sie AWS möglicherweise zuerst das Konto, dann die Rolle und dann den Benutzer mit der übernommenen Rolle. Der Benutzer mit übernommener Rolle wird anhand des Namens der Rollensitzung identifiziert, die bei der Übernahme der Rolle durch den Benutzer angegeben wurde. Aus diesem Grund empfehlen wir dringend, dass Sie den ARN für das Konto eines Benutzers oder sowohl den ARN einer Rolle als auch den ARN für das Konto, das die Rolle enthält, mit aufnehmen.
+ Das `NotPrincipal`-Element wird in Service-Kontrollrichtlinien (SCP) und Ressourcen-Kontrollrichtlinien (RCP) nicht unterstützt.
## Alternativen zum `NotPrincipal`-Element
Bei der Verwaltung der Zugriffskontrolle in kann es Szenarien geben AWS, in denen Sie allen Prinzipalen den Zugriff auf eine Ressource explizit verweigern müssen, mit Ausnahme von einem oder mehreren von Ihnen angegebenen Prinzipalen. AWS empfiehlt die Verwendung einer Deny-Anweisung mit globalen Bedingungskontextschlüsseln für eine genauere Steuerung und einfachere Problembehandlung. Die folgenden Beispiele zeigen alternative Ansätze mit Bedingungsoperatoren wie `StringNotEquals` oder `ArnNotEquals`, um allen Prinzipalen außer den im Condition-Element angegebenen den Zugriff zu verweigern.
## Beispielszenario mit Verwendung einer IAM-Rolle
Sie können eine ressourcenbasierte Richtlinie mit einer Deny-Anweisung verwenden, um zu verhindern, dass alle IAM-Rollen außer den im Condition-Element angegebenen auf Ihre Ressourcen zugreifen oder diese bearbeiten. Dieser Ansatz folgt dem AWS Sicherheitsprinzip, dass eine ausdrückliche Ablehnung immer Vorrang vor allen Allow-Anweisungen hat, und trägt dazu bei, das Prinzip der geringsten Rechte in Ihrer gesamten AWS Infrastruktur aufrechtzuerhalten.
Anstatt `NotPrincipal` zu verwenden, empfehlen wir die Verwendung einer Deny-Anweisung mit globalen Bedingungskontextschlüsseln und dem Bedingungsoperator [`ArnNotEquals`](reference_policies_elements_condition_operators.md#Conditions_ARN), um einer IAM-Rolle explizit den Zugriff auf Ihre Ressourcen zu erlauben. Das folgende Beispiel verwendet [aws:PrincipalArn](reference_policies_condition-keys.md#condition-keys-principalarn), um der Rolle `read-only-role` explizit den Zugriff auf Amazon-S3-Buckets im Ordner `Bucket_Account_Audit` zu erlauben.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyCrossAuditAccess",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::Bucket_Account_Audit",
"arn:aws:s3:::Bucket_Account_Audit/*"
],
"Condition": {
"ArnNotEquals": {
"aws:PrincipalArn": "arn:aws:iam::444455556666:role/read-only-role"
}
}
}
]
}
```
------
## Beispielszenario mit Verwendung eines Service-Prinzipals
Mit einer Deny-Anweisung können Sie verhindern, dass alle Service-Prinzipale außer den im `Condition`-Element angegebenen auf Ihre Ressourcen zugreifen oder diese bearbeiten. Dieser Ansatz ist besonders nützlich, wenn Sie detaillierte Zugriffskontrollen implementieren oder Sicherheitsgrenzen zwischen verschiedenen Services und Anwendungen in Ihrer AWS -Umgebung festlegen müssen.
Anstatt `NotPrincipal` zu verwenden, empfehlen wir die Verwendung einer Deny-Anweisung mit globalen Bedingungskontextschlüsseln und dem Bedingungsoperator [`StringNotEquals`](reference_policies_elements_condition_operators.md#Conditions_String), um einem Service-Prinzipal explizit den Zugriff auf Ihre Ressourcen zu erlauben. Das folgende Beispiel verwendet `aws:PrincipalServiceName`, um dem Service-Prinzipal von AWS CodeBuild explizit den Zugriff auf Amazon-S3-Buckets im Ordner `BUCKETNAME` zu erlauben.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyNotCodeBuildAccess",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::BUCKETNAME",
"arn:aws:s3:::BUCKETNAME/*"
],
"Condition": {
"StringNotEqualsIfExists": {
"aws:PrincipalServiceName": "codebuild.amazonaws.com"
}
}
}
]
}
```
------
# IAM-JSON-Richtlinienelemente: Action
Das Element `Action` beschreibt die gewünschte oder gewünschten Aktionen, die zugelassen oder verweigert werden. Anweisungen müssen entweder ein `Action`- oder `NotAction`-Element enthalten. Jeder AWS Dienst hat seine eigenen Aktionen, die Aufgaben beschreiben, die Sie mit diesem Dienst ausführen können. Die Liste der Aktionen für Amazon S3 finden Sie beispielsweise [unter Specifying Permissions in a Policy](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-with-s3-actions.html) im *Amazon Simple Storage Service User Guide*, die Liste der Aktionen für Amazon EC2 finden Sie in der [Amazon EC2 API Reference](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/query-apis.html) und die Liste der Aktionen für AWS Identity and Access Management finden Sie in der [IAM](https://docs.aws.amazon.com/IAM/latest/APIReference/API_Operations.html) API Reference. Die Liste der Aktionen für andere Services finden Sie in der API-Referenz [Dokumentation](https://aws.amazon.com/documentation) des jeweiligen Services.
AWS bietet außerdem Service-Referenzinformationen im JSON-Format, um die Automatisierung von Workflows zur Richtlinienverwaltung zu optimieren. Mit den Service-Referenzinformationen können Sie neben maschinenlesbaren Dateien auf verfügbare Aktionen, Ressourcen und AWS-Services Bedingungsschlüssel zugreifen. Weitere Informationen finden Sie unter [Vereinfachte AWS-Service -Informationen für programmgesteuerten Zugriff](https://docs.aws.amazon.com/service-authorization/latest/reference/service-reference.html) in der Referenz für die Service-Autorisierung.
Sie geben einen Wert über einen Namespace als Aktionspräfix (`iam`, `ec2` `sqs`, `sns`, `s3` usw.), gefolgt von dem Namen der Aktion, die erlaubt oder abgelehnt werden soll, an. Der Name muss mit einer Aktion übereinstimmen, die vom Service unterstützt wird. Der Präfix und Aktionsname wird nicht nach Groß- und Kleinschreibung unterschieden. Zum Beispiel ist `iam:ListAccessKeys` identisch zu `IAM:listaccesskeys`. In den folgenden Beispielen sind `Action`-Elemente für verschiedene Services aufgeführt.
**Amazon SQS Aktion**
```
"Action": "sqs:SendMessage"
```
**Amazon EC2-Aktion**
```
"Action": "ec2:StartInstances"
```
**IAM-Aktion**
```
"Action": "iam:ChangePassword"
```
**Amazon S3-Aktionen**
```
"Action": "s3:GetObject"
```
Sie können mehrere Werte für das Element `Action` definieren.
```
"Action": [ "sqs:SendMessage", "sqs:ReceiveMessage", "ec2:StartInstances", "iam:ChangePassword", "s3:GetObject" ]
```
Sie können Platzhalter für die Suche nach mehreren Zeichen (`*`) und Platzhalter für die Suche nach einem einzelnen Zeichen (`?`) verwenden, um Zugriff auf alle Aktionen zu gewähren, die das jeweilige Produkt anbietet. AWS Folgendes `Action`-Element beispielsweise findet für alle S3-Aktionen Anwendung.
```
"Action": "s3:*"
```
Sie können im Aktionsnamen auch Platzhalter (`*` oder `?`) verwenden. Beispielsweise gilt folgendes `Action`-Element für alle IAM-Aktionen, die die Zeichenfolge `AccessKey` einschließlich `CreateAccessKey`, `DeleteAccessKey`, `ListAccessKeys` und `UpdateAccessKey` enthalten.
```
"Action": "iam:*AccessKey*"
```
Bei einigen Services können Sie die verfügbaren Aktionen einschränken. Zum Beispiel stellt Amazon SQS nur einen Teil aller verfügbaren Amazon SQS-Aktionen bereit. In diesem Fall wird durch den `*`-Platzhalter keine vollständige Kontrolle über die Warteschlange gewährt, sondern nur diejenige Untergruppe von Aktionen zugelassen, die Sie geteilt haben. Weitere Informationen finden Sie unter [ Richtlinien und Berechtigungen in Amazon S3](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/acp-overview.html#PermissionTypes) im *Amazon Simple Storage Service Developer Guide*.
# IAM-JSON-Richtlinienelemente: NotAction
`NotAction` ist ein erweitertes Richtlinienelement, um eine explizite Übereinstimmung mit allen Aktionen herzustellen, *mit Ausnahme* der angegebenen Aktionsliste. Die Verwendung von `NotAction` kann zu einer kürzeren Richtlinie führen, da statt einer langen Liste von zugelassenen Aktionen lediglich einige wenige nicht zugelassenen Aktionen angegeben werden. In `NotAction` angegebene Aktionen werden durch den `Allow`- oder `Deny`-Effekt in einer Richtlinienanweisung nicht beeinflusst. Dies bedeutet wiederum, dass alle nicht aufgelisteten einschlägigen Aktionen und Services zugelassen sind, wenn Sie die Anweisung `Allow` verwenden. Außerdem werden solche nicht aufgelisteten Aktionen und Services verweigert, wenn Sie die Anweisung `Deny` verwenden. Wenn Sie `NotAction` mit dem `Resource`-Element verwenden, schaffen Sie Raum für die Richtlinie. Auf diese Weise wird AWS bestimmt, welche Aktionen oder Dienste anwendbar sind. Weitere Informationen finden Sie in der folgenden Beispielrichtlinie.
**NotAction mit Zulassen**
Sie können das `NotAction` Element in einer Anweisung mit verwenden`"Effect": "Allow"`, um Zugriff auf alle Aktionen in einem AWS Dienst zu gewähren, mit Ausnahme der unter angegebenen Aktionen`NotAction`. Sie können sie mit dem `Resource`-Element verwenden, um Raum für die Richtlinie zu schaffen und die zugelassenen Aktionen auf die Aktionen zu beschränken, die für die angegebene Ressource ausgeführt werden können.
Das folgende Beispiel gestattet Benutzern den Zugriff auf die Amazon S3-Aktionen, die für jede S3-Ressource ausgeführt werden können, mit *Ausnahme* des Löschens eines Buckets. Diese Richtlinie lässt auch keine Aktionen in anderen Services zu, weil andere Service-Aktionen nicht auf die S3-Ressourcen anwendbar sind.
```
"Effect": "Allow",
"NotAction": "s3:DeleteBucket",
"Resource": "arn:aws:s3:::*",
```
Manchmal ist es sinnvoll, den Zugriff auf eine große Anzahl von Aktionen zu erlauben. Durch Verwendung des `NotAction`-Elements können Sie die Anweisung effektiv invertieren und so die Aktionsliste verkürzen. Da es beispielsweise so AWS viele Dienste gibt, möchten Sie vielleicht eine Richtlinie erstellen, die es dem Benutzer ermöglicht, alles zu tun, außer auf IAM-Aktionen zuzugreifen.
Das folgende Beispiel ermöglicht Benutzern den Zugriff auf jede Aktion in jedem AWS Dienst mit Ausnahme von IAM.
```
"Effect": "Allow",
"NotAction": "iam:*",
"Resource": "*"
```
Seien Sie vorsichtig bei der Verwendung der Elemente `NotAction` und `"Effect": "Allow"` in derselben Anweisung oder in einer anderen Anweisung innerhalb einer Richtlinie. `NotAction` stimmt mit allen Diensten und Aktionen überein, die nicht explizit aufgelistet oder auf die angegebene Ressource anwendbar sind und dazu führen könnten, dass Benutzer mehr Berechtigungen erhalten, als Sie beabsichtigt haben.
**NotAction mit Deny**
Sie können in einer Anweisung das Element `NotAction` mit `"Effect": "Deny"` verwenden, um den Zugriff auf alle aufgelisteten Ressourcen mit Ausnahme der im Element `NotAction` angegebenen Aktionen zu verweigern. Diese Kombination erteilt den aufgeführten Elementen keine Berechtigung, verweigert aber explizit den Zugriff auf die nicht aufgeführten Aktionen. Sie müssen unverändert die gewünschten Aktionen zulassen.
Das folgende Beispiel verweigert den Zugriff auf Nicht-IAM-Aktionen, wenn der Benutzer sich nicht mit MFA angemeldet hat. Hat sich der Benutzer mit MFA angemeldet, schlägt der `"Condition"`-Test fehl und die abschließende `"Deny"`-Anweisung hat keine Wirkung. Beachten Sie aber, dass dadurch kein Benutzerzugriff auf Aktionen gewährleistet ist. Es werden nur explizit alle anderen Aktionen als IAM-Aktionen verweigert.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Sid": "DenyAllUsersNotUsingMFA",
"Effect": "Deny",
"NotAction": "iam:*",
"Resource": "*",
"Condition": {"BoolIfExists": {"aws:MultiFactorAuthPresent": "false"}}
}]
}
```
------
Eine Beispielrichtlinie, mit der der Zugriff auf Aktionen außerhalb bestimmter Regionen verweigert wird, mit Ausnahme von Aktionen aus bestimmten Services; siehe [AWS: Verweigert den Zugriff auf AWS basierend auf der angeforderten Region](reference_policies_examples_aws_deny-requested-region.md).
# IAM-JSON-Richtlinienelemente: Resource
Das `Resource`-Element in einer IAM-Richtlinienanweisung definiert das Objekt bzw. die Objekte, auf die die Anweisung angewendet wird. Anweisungen müssen entweder ein – `Resource`oder ein `NotResource`-Element enthalten.
Sie geben eine Ressource mithilfe eines Amazon-Ressourcennamens (ARN) an. Das Format des ARN hängt von der AWS-Service und der spezifischen Ressource ab, auf die Sie sich beziehen. Obwohl das ARN-Format variiert, verwenden Sie immer eine ARN, um eine Ressource zu identifizieren. Weitere Informationen zum Format von ARNs finden Sie unter[ICH BIN ARNs](reference_identifiers.md#identifiers-arns). Weitere Informationen zur Angabe einer Ressource finden Sie in der Dokumentation für den Service, für dessen Ressourcen Sie eine Anweisung definieren.
**Anmerkung**
In einigen Fällen können Sie AWS-Services keine Aktionen für einzelne Ressourcen angeben. In diesen Fällen gelten alle Aktionen, die Sie im `Action`- oder `NotAction`-Element auflisten, für alle Ressourcen in diesem Service. In diesem Fall verwenden Sie das Platzhalterzeichen (`*`) im `Resource`-Element.
Das folgende Beispiel bezieht sich auf eine bestimmte Amazon SQS-Warteschlange.
```
"Resource": "arn:aws:sqs:us-east-2:account-ID-without-hyphens:queue1"
```
Das folgende Beispiel bezieht sich auf den IAM-Benutzer mit dem Namen `Bob` in einem AWS-Konto.
**Anmerkung**
Im `Resource`-Element ist für den IAM-Benutzernamen die Groß- und Kleinschreibung zu beachten.
```
"Resource": "arn:aws:iam::account-ID-without-hyphens:user/Bob"
```
## Verwendung von Platzhaltern in Ressourcen ARNs
Sie können Platzhalterzeichen (`*` und `?`) innerhalb der einzelnen Segmente einer ARN (die durch Doppelpunkte getrennten Teile) verwenden, um Folgendes darzustellen:
+ Beliebige Kombination von Zeichen (`*`)
+ Beliebiges Zeichen (`?`)
Sie können mehrere `*`- oder `?`-Zeichen in jedem Segment verwenden. Wenn der Platzhalter `*` das letzte Zeichen eines Ressourcen-ARN-Segments ist, kann er erweitert werden, sodass er über die Doppelpunktgrenzen hinaus übereinstimmt. Wir empfehlen die Verwendung von Platzhaltern (`*` und `?`) innerhalb von ARN-Segmenten, die durch einen Doppelpunkt getrennt sind.
**Anmerkung**
Im Servicesegment, das das Produkt identifiziert, können Sie keinen Platzhalter verwenden. AWS Weitere Informationen zu ARN-Segmenten finden Sie unter [Identifizieren Sie AWS Ressourcen mit Amazon-Ressourcennamen (ARNs)](reference-arns.md).
Das folgende Beispiel bezieht sich auf alle IAM-Benutzer, deren Pfad `/accounting` lautet.
```
"Resource": "arn:aws:iam::account-ID-without-hyphens:user/accounting/*"
```
Das folgende Beispiel bezieht sich auf alle Elemente in einem spezifischen Amazon S3-Bucket.
```
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*"
```
Das Sternchen (`*`) kann erweitert werden, um alles innerhalb eines Segments zu ersetzen, einschließlich Zeichen wie ein Schrägstrich (`/`), die andernfalls ein Trennzeichen innerhalb eines bestimmten Service-Namespace zu sein scheinen. Betrachten Sie beispielsweise den folgenden Amazon S3 ARN, da dieselbe Platzhaltererweiterungslogik für alle Dienste gilt.
```
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*/test/*"
```
Die Platzhalter im ARN gelten für alle folgenden Objekte im Bucket, nicht nur für das erste aufgelistete Objekt.
```
amzn-s3-demo-bucket/1/test/object.jpg
amzn-s3-demo-bucket/1/2/test/object.jpg
amzn-s3-demo-bucket/1/2/test/3/object.jpg
amzn-s3-demo-bucket/1/2/3/test/4/object.jpg
amzn-s3-demo-bucket/1///test///object.jpg
amzn-s3-demo-bucket/1/test/.jpg
amzn-s3-demo-bucket//test/object.jpg
amzn-s3-demo-bucket/1/test/
```
Betrachten Sie die letzten beiden Objekte in der vorherigen Liste. Ein Amazon-S3-Objektname kann mit dem herkömmlichen Schrägstrich (`/`) als Trennzeichen beginnen oder enden. Während `/` als Trennzeichen fungiert, gibt es keine spezifische Bedeutung, wenn dieses Zeichen innerhalb eines Ressourcen-ARN verwendet wird. Es wird wie jedes andere gültige Zeichen behandelt. Der ARN würde nicht mit den folgenden Objekten übereinstimmen:
```
amzn-s3-demo-bucket/1-test/object.jpg
amzn-s3-demo-bucket/test/object.jpg
amzn-s3-demo-bucket/1/2/test.jpg
```
## Angabe mehrerer Aktionen oder Ressourcen
Sie können mehrere Ressourcen in dem `Resource` Element angeben, indem Sie ein Array von ARNs verwenden. Das folgende Beispiel bezieht sich auf zwei DynamoDB-Tabellen.
```
"Resource": [
"arn:aws:dynamodb:us-east-2:account-ID-without-hyphens:table/books_table",
"arn:aws:dynamodb:us-east-2:account-ID-without-hyphens:table/magazines_table"
]
```
## Verwenden von Richtlinienvariablen in einer Ressource ARNs
Im `Resource`-Element können Sie JSON-[Richtlinienvariablen](reference_policies_variables.md) in dem Teil des ARN verwenden, der die Ressource angibt (d. h. im abschließenden Teil des ARN). Beispielsweise können Sie den Schlüssel `{aws:username}` als Teil einer Ressourcen-ARN verwenden, damit der aktuelle Benutzername als Teil des Ressourcennamens aufgenommen wird. Das folgende Beispiel zeigt, wie Sie den Schlüssel `{aws:username}` in einem `Resource`-Element verwenden können. Die Richtlinie gewährt Zugriff auf eine Amazon DynamoDB-Tabelle, die den Namen des aktuellen Benutzers enthält.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "dynamodb:*",
"Resource": "arn:aws:dynamodb:us-east-2:111122223333:table/${aws:username}"
}
}
```
------
Weitere Informationen zu JSON-Richtlinienvariablen finden Sie unter [IAM-Richtlinienelemente: Variablen und Tags](reference_policies_variables.md).
# IAM-JSON-Richtlinienelemente: NotResource
`NotResource` ist ein erweitertes Richtlinienelement, das explizit jeder Ressource mit Ausnahme der angegebenen entspricht. Die Verwendung von `NotResource` kann zu einer kürzeren Richtlinie führen, da statt einer langen Liste von zulässigen Ressourcen lediglich einige wenige unzulässige Ressourcen angegeben werden. Dies ist besonders nützlich für Richtlinien, die innerhalb eines einzelnen AWS -Service gelten.
Stellen Sie sich beispielsweise vor, Sie haben eine Gruppe mit dem Namen `HRPayroll`. Mitglieder von `HRPayroll` sollten auf keine Amazon S3-Ressourcen außer dem Ordner `Payroll` im Bucket `HRBucket` zugreifen dürfen. Mit der folgenden Richtlinie wird der Zugriff auf alle nicht aufgelisteten Amazon S3-Ressourcen explizit verweigert. Beachten Sie jedoch, dass diese Richtlinie dem Benutzer keine Zugriffsberechtigung auf Ressourcen gewährt.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Deny",
"Action": "s3:*",
"NotResource": [
"arn:aws:s3:::HRBucket/Payroll",
"arn:aws:s3:::HRBucket/Payroll/*"
]
}
}
```
------
Um einen Zugriff auf eine Ressource explizit zu verweigern, würden Sie normalerweise eine Richtlinie definieren, die ein `"Effect":"Deny"`- und `Resource`-Element enthält, in dem jeder Ordner einzeln aufgeführt ist. In diesem Fall müssen Sie jedoch jedes Mal, wenn Sie einen Ordner zu `HRBucket` oder eine Ressource zu Amazon S3 hinzufügen, auf die nicht zugegriffen werden soll, deren Namen zur Liste im `Resource`-Element hinzufügen. Wenn Sie stattdessen ein `NotResource`-Element verwenden, wird den Benutzern der Zugriff auf neue Ordner automatisch verweigert, es sei denn, sie fügen die Ordnernamen zum `NotResource`-Element hinzu.
Bei der Verwendung von `NotResource` sollten Sie beachten, dass die in diesem Element angegebenen Ressourcen die *einzigen* nicht eingeschränkten Ressourcen sind. Dies wiederum schränkt alle Ressourcen ein, die für die Aktion gelten würden. Im obigen Beispiel wirkt sich die Richtlinie nur auf Amazon S3-Aktionen und daher nur auf Amazon S3-Ressourcen. Wenn das `Action`-Element auch Amazon-EC2-Aktionen enthält, verweigert die Richtlinie den Zugriff auf EC2-Ressourcen, die nicht im `NotResource`-Element angegeben sind. Informationen darüber, welche Aktionen in einem Dienst die Angabe des ARN einer Ressource ermöglichen, finden Sie unter [Aktionen, Ressourcen und Bedingungsschlüssel für AWS Dienste](reference_policies_actions-resources-contextkeys.html).
## NotResource mit anderen Elementen
Sie sollten die Elemente `"Effect": "Allow"`, `"Action": "*"` und `"NotResource": "arn:aws:s3:::HRBucket"` **niemals** zusammen verwenden. Diese Anweisung ist sehr gefährlich, da sie alle Aktionen AWS auf allen Ressourcen außer dem `HRBucket` S3-Bucket zulässt. Dies würde sogar dem Benutzer erlauben, selbst eine Richtlinie hinzuzufügen, die ihm Zugriff auf `HRBucket` gewährt. Tun Sie dies nicht.
Seien Sie vorsichtig bei der Verwendung der Elemente `NotResource` und `"Effect": "Allow"` in derselben Anweisung oder in einer anderen Anweisung innerhalb einer Richtlinie. `NotResource` erlaubt alle Dienste und Ressourcen, die nicht explizit aufgeführt sind, und könnte dazu führen, dass Benutzer mehr Berechtigungen erhalten, als Sie beabsichtigt haben. Beim Verwenden der Elemente `NotResource` und `"Effect": "Deny"` in derselben Anweisung werden nicht explizit aufgelistete Services und Ressourcen verweigert.
# IAM-JSON-Richtlinienelemente: Condition
Mit dem Element `Condition` (oder dem `Condition`-*Block*) können Sie angeben, unter welchen Bedingungen eine Richtlinie wirksam ist. Das Element `Condition` ist optional. Im `Condition`-Element formulieren Sie Ausdrücke, in denen Sie [Bedingungsoperatoren](reference_policies_elements_condition_operators.md) (gleich, kleiner als usw.) verwenden, um die Kontextschlüssel und -werte in der Richtlinie mit Schlüsseln und Werten im Anforderungskontext abzugleichen. Weitere Informationen zum Anforderungskontext finden Sie unter [Bestandteile einer Anfrage](intro-structure.md#intro-structure-request).
```
"Condition" : { "{condition-operator}" : { "{condition-key}" : "{condition-value}" }}
```
Der Kontextschlüssel, den Sie in einer Richtlinienbedingung angeben, kann ein [globaler Bedingungskontextschlüssel](reference_policies_condition-keys.md) oder ein servicespezifischer Kontextschlüssel sein. Kontextschlüssel für globale Bedingungen verfügen über das Präfix `aws:`. Servicespezifische Kontextschlüssel verfügen über das Präfix des Services. Mit Amazon EC2 können Sie beispielsweise mithilfe des `ec2:InstanceType`-Kontextschlüssels eine Bedingung schreiben, die für diesen Service eindeutig ist. Informationen zum Anzeigen servicespezifischer IAM-Kontextschlüssel mit dem Präfix `iam:` finden Sie unter [IAM- und AWS STS Bedingungskontextschlüssel](reference_policies_iam-condition-keys.md).
Bei *Namen* von Kontextschlüsseln wird die Groß-/Kleinschreibung nicht beachtet. Das Einbeziehen des `aws:SourceIP`-Kontextschlüssels ist beispielsweise gleichbedeutend mit dem Testen auf `AWS:SourceIp`. Die Berücksichtigung der Groß- und Kleinschreibung bei *Werten* von Kontextschlüsseln hängt vom verwendeten [Bedingungsoperator](reference_policies_elements_condition_operators.md) ab. Die folgende Bedingung enthält beispielsweise den `StringEquals`-Operator, um sicherzustellen, dass nur von `john` gestellte Anfragen übereinstimmen. Benutzern mit dem Namen `John` wird der Zugriff verweigert.
```
"Condition" : { "StringEquals" : { "aws:username" : "john" }}
```
Die folgende Bedingung verwendet den [`StringEqualsIgnoreCase`](reference_policies_elements_condition_operators.md#Conditions_String)-Operator, damit Benutzer mit dem Namen `john` oder `John` gefunden werden.
```
"Condition" : { "StringEqualsIgnoreCase" : { "aws:username" : "john" }}
```
Einige Kontextschlüssel unterstützen Schlüssel-Wert-Paare, mit denen Sie einen Teil des Schlüsselnamens festlegen können. Beispiele hierfür sind der [`aws:RequestTag/tag-key`](reference_policies_condition-keys.md#condition-keys-requesttag)Kontextschlüssel AWS KMS [https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms-encryption-context](https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms-encryption-context), der und der [`ResourceTag/tag-key`](reference_policies_condition-keys.md#condition-keys-resourcetag)Kontextschlüssel, die von mehreren Diensten unterstützt werden.
+ Wenn Sie den `ResourceTag/tag-key`-Kontextschlüssel für einen Service wie etwa [Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-policy-structure.html#amazon-ec2-keys) verwenden, müssen Sie einen Schlüsselnamen für den `tag-key` angeben.
+ **Bei den Schlüsselnamen muss die Groß- und Kleinschreibung nicht berücksichtigt werden.** Dies bedeutet Folgendes: Wenn Sie `"aws:ResourceTag/TagKey1": "Value1"` im Bedingungselement Ihrer Richtlinie angeben, stimmt die Bedingung mit einem Ressourcen-Tag-Schlüssel mit dem Namen `TagKey1` oder `tagkey1` überein, aber nicht mit beiden.
+ AWS Dienste, die diese Attribute unterstützen, ermöglichen es Ihnen möglicherweise, mehrere Schlüsselnamen zu erstellen, die sich nur durch Groß- und Kleinschreibung unterscheiden. Ein Beispiel wäre hier das Tagging einer Amazon-EC2-Instance mit `ec2=test1` und `EC2=test2`. Wenn Sie eine Bedingung wie `"aws:ResourceTag/EC2": "test1"` verwenden, um den Zugriff auf diese Ressource zu erlauben, stimmt der Schlüsselname mit beiden Tags, jedoch nur mit einem Wert überein. Dies kann zu unerwarteten Bedingungsfehlern führen.
**Wichtig**
Als bewährte Methode stellen Sie sicher, dass Mitglieder Ihres Kontos eine konsistente Namenskonvention beim Benennen von Schlüssel-Wert-Paar-Attributen verfolgen. Beispiele hierfür sind Tags oder AWS KMS -Verschlüsselungskontexte. Sie können dies erzwingen, indem Sie den [`aws:TagKeys`](reference_policies_condition-keys.md#condition-keys-tagkeys)Kontextschlüssel für das Tagging oder den [https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms-encryption-context-keys](https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms-encryption-context-keys)für den AWS KMS Verschlüsselungskontext verwenden.
+ Eine Liste aller Bedingungsoperatoren und eine Beschreibung ihrer Funktionsweise finden Sie unter [Bedingungsoperatoren](reference_policies_elements_condition_operators.md).
+ Sofern nicht anders angegeben, können alle Kontextschlüssel mehrere Werte haben. Eine Beschreibung zum Umgang mit Kontextschlüsseln mit mehreren Werten finden Sie unter [Operatoren für mehrwertige Kontextschlüssel festlegen](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys).
+ Eine Liste aller global verfügbaren Kontextschlüssel finden Sie unter [AWS Kontextschlüssel für globale Bedingungen](reference_policies_condition-keys.md).
+ Bedingungskontextschlüssel, die von jedem Dienst definiert werden, finden Sie unter [Aktionen, Ressourcen und Bedingungsschlüssel für AWS Dienste](reference_policies_actions-resources-contextkeys.html).
## Der Anforderungskontext
Wenn ein [Principal](https://docs.aws.amazon.com/glossary/latest/reference/glos-chap.html?icmpid=docs_homepage_addtlrcs#principal) eine [Anfrage](intro-structure.md#intro-structure-request) an stellt AWS, fasst er AWS die Anforderungsinformationen in einem Anforderungskontext zusammen. Der Anforderungskontext umfasst Informationen über den Prinzipal, Ressourcen, Aktionen und andere Umgebungseigenschaften. Bei der Richtlinienbewertung werden die Eigenschaften in der Richtlinie mit den in der Anforderung gesendeten Eigenschaften abgeglichen, um die Aktionen zu bewerten und zu autorisieren, die Sie in AWS ausführen können.
Sie können das `Condition`-Element einer JSON-Richtlinie verwenden, um bestimmte Kontextschlüssel anhand des Anforderungskontexts zu testen. Sie können beispielsweise eine Richtlinie erstellen, die den CurrentTime Kontextschlüssel [aws:](reference_policies_condition-keys.md#condition-keys-currenttime) verwendet, um [es einem Benutzer zu ermöglichen, Aktionen nur innerhalb eines bestimmten Zeitraums durchzuführen.](reference_policies_examples_aws-dates.md)
Das folgende Beispiel zeigt eine Darstellung des Anforderungskontexts, wenn Martha Rivera eine Anfrage zur Deaktivierung ihres MFA-Geräts sendet.
```
Principal: AROA123456789EXAMPLE
Action: iam:DeactivateMFADevice
Resource: arn:aws:iam::user/martha
Context:
– aws:UserId=AROA123456789EXAMPLE:martha
– aws:PrincipalAccount=1123456789012
– aws:PrincipalOrgId=o-example
– aws:PrincipalARN=arn:aws:iam::1123456789012:assumed-role/TestAR
– aws:MultiFactorAuthPresent=true
– aws:MultiFactorAuthAge=2800
– aws:CurrentTime=...
– aws:EpochTime=...
– aws:SourceIp=...
```
Der Anforderungskontext wird mit einer Richtlinie abgeglichen, die es Benutzern erlaubt, ihr eigenes Gerät für die Multi-Faktor-Authentifizierung (MFA) zu entfernen, jedoch nur, wenn sie sich innerhalb der letzten Stunde (3600 Sekunden) mit MFA angemeldet haben.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Sid": "AllowRemoveMfaOnlyIfRecentMfa",
"Effect": "Allow",
"Action": [
"iam:DeactivateMFADevice"
],
"Resource": "arn:aws:iam::*:user/${aws:username}",
"Condition": {
"NumericLessThanEquals": {"aws:MultiFactorAuthAge": "3600"}
}
}
}
```
------
In diesem Beispiel stimmt die Richtlinie mit dem Anforderungskontext überein: Die Aktion ist dieselbe, die Ressource stimmt mit dem Platzhalter „\$1“ überein und der Wert für `aws:MultiFactorAuthAge` ist 2800, also kleiner als 3600, sodass die Richtlinie diese Autorisierungsanforderung zulässt.
AWS wertet jeden Kontextschlüssel in der Richtlinie aus und gibt den Wert *wahr* oder *falsch* zurück. Ein Kontextschlüssel, der in der Anfrage nicht vorhanden ist, wird als Nichtübereinstimmung betrachtet.
Der Anforderungskontext kann die folgenden Werte zurückgeben:
+ **True** – Wenn der Anforderer sich innerhalb der letzten Stunde per MFA angemeldet hat, gibt die Bedingung *true* zurück.
+ **False** – Wenn sich der Anforderer vor mehr als einer Stunde per MFA angemeldet hat, gibt die Bedingung *false* zurück.
+ **Nicht vorhanden** — Wenn der Anforderer eine Anfrage mit seinen IAM-Benutzerzugriffsschlüsseln in der AWS CLI AWS OR-API gestellt hat, ist der Schlüssel nicht vorhanden. In diesem Fall ist der Schlüssel nicht vorhanden und stimmt nicht überein.
**Anmerkung**
In einigen Fällen kann die Bedingung auch dann „true“ zurückgeben, wenn der Bedingungsschlüsselwert nicht vorhanden ist. Wenn Sie beispielsweise den `ForAllValues`-Qualifizierer hinzufügen, gibt die Anforderung „true“ zurück, wenn der Kontextschlüssel nicht in der Anforderung enthalten ist. Um zu verhindern, dass fehlende Kontextschlüssel oder Kontextschlüssel mit leeren Werten als „true“ ausgewertet werden, können Sie den [Null-Bedingungsoperator](reference_policies_elements_condition_operators.md#Conditions_Null) mit einem `false`-Wert in Ihre Richtlinie aufnehmen, um zu überprüfen, ob der Kontextschlüssel vorhanden ist und sein Wert nicht null ist.
## Der Bedingungsblock
Das folgende Beispiel zeigt das grundlegende Format eines `Condition`-Elements:
```
"Condition": {"StringLike": {"s3:prefix": ["jane/*"]}}
```
Ein Wert aus der Anfrage wird durch einen Kontextschlüssel dargestellt, in diesem Fall `s3:prefix`. Der Kontextschlüsselwert wird mit einem Wert verglichen, den Sie als Literalwert angeben, z. B. `jane/*`. Der vorzunehmende Vergleich wird vom [Bedingungsoperator](reference_policies_elements_condition_operators.md) (hier `StringLike`) bestimmt. Sie können Bedingungen erstellen, die Zeichenketten, Datumsangaben, Zahlen und vieles mehr mit typischen booleschen Vergleichen wie "gleich", "größer als" und "kleiner als" vergleichen. Wenn Sie [Zeichenfolgen-Operatoren](reference_policies_elements_condition_operators.md#Conditions_String) oder [ARN-Operatoren](reference_policies_elements_condition_operators.md#Conditions_ARN) verwenden, können Sie auch eine [Richtlinienvariable](reference_policies_variables.md) im Kontextschlüsselwert verwenden. Das folgende Beispiel enthält die Variable `aws:username`.
```
"Condition": {"StringLike": {"s3:prefix": ["${aws:username}/*"]}}
```
Unter bestimmten Umständen können Kontextschlüssel mehrere Werte enthalten. Eine Anforderung an Amazon DynamoDB könnte beispielsweise darin bestehen, mehrere Attribute einer Tabelle zurückzugeben oder zu aktualisieren. Eine Richtlinie für den Zugriff auf DynamoDB-Tabellen kann den `dynamodb:Attributes`-Kontextschlüssel enthalten, der alle in der Anfrage aufgeführten Attribute enthält. Sie können diese Attribute mit einer Liste zulässiger Attribute in einer Richtlinie mithilfe von Mengenoperatoren im Element `Condition` vergleichen. Weitere Informationen finden Sie unter [Operatoren für mehrwertige Kontextschlüssel festlegen](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys).
Wenn die Richtlinie während einer Anfrage evaluiert wird, wird der Schlüssel AWS durch den entsprechenden Wert aus der Anfrage ersetzt. (In diesem Beispiel AWS würden Datum und Uhrzeit der Anfrage verwendet.) Die Auswertung der Bedingung gibt "true" oder "false" zurück und das Ergebnis wird von der Richtlinie berücksichtigt, um die Anforderung zuzulassen oder zu verweigern.
### Mehrere Werte in einer Bedingung
Ein `Condition`-Element kann mehrere Bedingungsoperatoren enthalten, und jeder Bedingungsoperator kann mehrere Kontext-Schlüssel-Wert-Paare enthalten. Dies wird in folgender Abbildung veranschaulicht.
![\[Zwei Blockdiagramme für Bedingungs-Operatoren. Der erste Block enthält zwei Platzhalter für Kontextschlüssel mit jeweils mehreren Werten. Der zweite Bedingungsblock enthält einen Kontextschlüssel mit mehreren Werten.\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/images/AccessPolicyLanguage_Condition_Block.diagram.png)
Weitere Informationen finden Sie unter [Operatoren für mehrwertige Kontextschlüssel festlegen](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys).
# IAM-JSON-Richtlinienelemente: Bedingungsoperatoren
Verwenden Sie Bedingungsoperatoren im `Condition`-Element, um den Bedingungsschlüssel und -wert in der Richtlinie mit den Werten im Anforderungskontext abzugleichen. Weitere Informationen zum `Condition`-Element finden Sie unter [IAM-JSON-Richtlinienelemente: Condition](reference_policies_elements_condition.md).
Der Bedingungsoperator, den Sie in einer Richtlinie verwenden können, hängt vom ausgewählten Bedingungsschlüssel ab. Sie können einen globalen Bedingungsschlüssel oder einen servicespezifischen Bedingungsschlüssel auswählen. Informationen dazu, welchen Bedingungsoperator Sie für einen globalen Bedingungsschlüssel verwenden können, finden Sie unter [AWS Kontextschlüssel für globale Bedingungen](reference_policies_condition-keys.md). Informationen darüber, welchen Bedingungsoperator Sie für einen dienstspezifischen Bedingungsschlüssel verwenden können, finden Sie unter [Aktionen, Ressourcen und Bedingungsschlüssel für AWS Dienste](reference_policies_actions-resources-contextkeys.html) und wählen Sie den Service aus, den Sie anzeigen möchten.
**Wichtig**
Wenn der Schlüssel, den Sie in einer Richtlinienbedingung angeben, im Anforderungskontext nicht vorhanden ist, stimmen die Werte nicht überein und die Bedingung ist *falsch*. Wenn die Richtlinienbedingung erfordert, dass der Schlüssel *nicht* abgestimmt ist, wie `StringNotLike` oder `ArnNotLike`, und der richtige Schlüssel ist nicht vorhanden, ist die Bedingung *wahr*. [Diese Logik gilt für alle Bedingungsoperatoren außer... IfExists](#Conditions_IfExists)und [Nullprüfung](#Conditions_Null). Diese Operatoren testen, ob der Schlüssel im Anforderungskontext vorhanden ist (existiert).
Die Bedingungsoperatoren können in folgende Kategorien gruppiert werden:
+ [Zeichenfolge](#Conditions_String)
+ [Numerischer Wert](#Conditions_Numeric)
+ [Datum und Uhrzeit](#Conditions_Date)
+ [Boolesch](#Conditions_Boolean)
+ [Binary](#Conditions_BinaryEquals)
+ [IP-Adresse](#Conditions_IPAddress)
+ [Amazon Ressourcenname (ARN)](#Conditions_ARN) (nur für bestimmte Services verfügbar.)
+ [... IfExists](#Conditions_IfExists)(prüft, ob der Schlüsselwert im Rahmen einer anderen Prüfung existiert)
+ [Null](#Conditions_Null)-Prüfung (überprüft als eigenständige Prüfung, ob der Schlüsselwert vorhanden ist)
## Bedingungsoperatoren für Zeichenfolgen
Mit String-Bedingungsoperatoren können Sie `Condition`-Elemente erstellen, die den Zugriff basierend auf einen Vergleich eines Schlüssels mit einem Zeichenfolgewert einschränken.
+ **Richtlinienvariablen**: [unterstützt](reference_policies_variables.md)
+ **Platzhalter**: [unterstützt](#Conditions_String-wildcard)
****
| Bedingungsoperator | Description |
| --- | --- |
| `StringEquals` | Exakte Übereinstimmung, Unterscheidung von Groß- und Kleinschreibung |
| `StringNotEquals` | Negierte Übereinstimmung |
| `StringEqualsIgnoreCase` | Exakte Übereinstimmung, keine Unterscheidung von Groß- und Kleinschreibung |
| `StringNotEqualsIgnoreCase` | Negierte Übereinstimmung, keine Unterscheidung von Groß- und Kleinschreibung |
| `StringLike` | Übereinstimmung mit Unterscheidung von Groß- und Kleinschreibung Die Werte können einen Mehrzeichen-Übereinstimmungs-Platzhalter (\$1) oder einen Einzelzeichen-Übereinstimmungs-Platzhalter (?) an einer beliebigen Stelle in der Zeichenfolge enthalten. Sie müssen Platzhalter angeben, um teilweise Zeichenfolgenübereinstimmungen zu erzielen. Wenn ein Schlüssel mehrere Werte enthält, kann `StringLike` mit den Set-Operatoren `ForAllValues:StringLike` und `ForAnyValue:StringLike` ausgewertet werden. Weitere Informationen finden Sie unter [Operatoren für mehrwertige Kontextschlüssel festlegen](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys). |
| `StringNotLike` | Negierte Übereinstimmung mit Unterscheidung von Groß- und Kleinschreibung Die Werte können einen Mehrzeichen-Übereinstimmungs-Platzhalter (\$1) oder einen Einzelzeichen-Übereinstimmungs-Platzhalter (?) an einer beliebigen Stelle in der Zeichenfolge enthalten. |
**Example Bedingungsoperator für Zeichenfolge**
Zum Beispiel enthält die folgende Anweisung ein `Condition`-Element, das den [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principaltag](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principaltag)-Schlüssel verwendet, um anzugeben, dass der anfordernde Prinzipal mit der `iamuser-admin`-Aufgabenkategorie getaggt sein muss.
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "iam:*AccessKey*",
"Resource": "arn:aws:iam::111122223333:user/*",
"Condition": {
"StringEquals": {
"aws:PrincipalTag/job-category": "iamuser-admin"
}
}
}
}
```
Wenn der Schlüssel, den Sie in einer Richtlinienbedingung angeben, im Anforderungskontext nicht vorhanden ist, stimmen die Werte nicht überein. In diesem Beispiel ist der Schlüssel `aws:PrincipalTag/job-category` im Anforderungskontext vorhanden, wenn der Auftraggeber einen IAM-Benutzer mit angehängten Tags verwendet. Er ist auch für einen Auftraggeber enthalten, der eine IAM-Rolle mit angehängten Tags oder Sitzungstags verwendet. Wenn ein Benutzer ohne das Tag versucht, einen Zugriffsschlüssel anzuzeigen oder zu bearbeiten, gibt die Bedingung `false` zurück und die Anforderung wird durch diese Anweisung implizit abgelehnt.
Die folgende Tabelle zeigt, wie diese Richtlinie auf der Grundlage der Bedingungsschlüsselwerte in Ihrer Anfrage AWS bewertet wird.
| Richtlinienbedingung | Kontext anfordern | Ergebnis |
| --- | --- | --- |
| "StringEquals": {
"aws:PrincipalTag/job-category": "iamuser-admin"
} | aws:PrincipalTag/job-category:
– iamuser-admin
| Match |
| "StringEquals": {
"aws:PrincipalTag/job-category": "iamuser-admin"
} | aws:PrincipalTag/job-category:
– dev-ops
| Keine Übereinstimmung |
| "StringEquals": {
"aws:PrincipalTag/job-category": "iamuser-admin"
} | Kein `aws:PrincipalTag/job-category` im Anfragekontext. | Keine Übereinstimmung |
**Example Verwenden einer Richtlinienvariablen mit einem Bedingungsoperator für eine Zeichenfolge**
Im folgenden Beispiel wird der `StringLike`-Bedingungsoperator verwendet, um einen String-Abgleich mit einer [Richtlinienvariablen](reference_policies_variables.md) durchzuführen, um eine Richtlinie zu erstellen, die es einem IAM-Benutzer ermöglicht, die Amazon S3-Konsole zu verwenden, um sein eigenes "Heimatverzeichnis" in einem Amazon S3-Bucket zu verwalten. Die Richtlinie lässt die angegebenen Aktionen für ein S3-Bucket zu, solange `s3:prefix` einem angegebenen Muster entspricht.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListAllMyBuckets",
"s3:GetBucketLocation"
],
"Resource": "arn:aws:s3:::*"
},
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
"Condition": {
"StringLike": {
"s3:prefix": [
"",
"home/",
"home/${aws:username}/"
]
}
}
},
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/home/${aws:username}",
"arn:aws:s3:::amzn-s3-demo-bucket/home/${aws:username}/*"
]
}
]
}
```
Die folgende Tabelle zeigt, wie diese Richtlinie für verschiedene Benutzer auf der Grundlage des [aws:username](reference_policies_condition-keys.md#condition-keys-username) Werts im Anforderungskontext AWS bewertet wird.
| Richtlinienbedingung | Kontext anfordern | Ergebnis |
| --- | --- | --- |
| "StringLike": {
"s3:prefix": [
"home/",
"home/${aws:username}/"
]
} | aws:username:
– martha_rivera
| "StringLike": {
"s3:prefix": [
"home/",
"home/martha_rivera/"
]
} |
| "StringLike": {
"s3:prefix": [
"home/",
"home/${aws:username}/"
]
} | aws:username:
– nikki_wolf
| "StringLike": {
"s3:prefix": [
"home/",
"home/nikki_wolf/"
]
} |
| "StringLike": {
"s3:prefix": [
"home/",
"home/${aws:username}/"
]
} | Kein `aws:username` im Anforderungskontext. | Keine Übereinstimmung |
Ein Beispiel für eine Richtlinie zur Verwendung des `Condition`-Elements, um den Zugriff auf Ressourcen basierend auf einer Anwendungs-ID und einer Benutzer-ID zum OIDC-Verbund einzuschränken, finden Sie unter [Amazon S3: Ermöglicht Amazon Cognito-Benutzern den Zugriff auf Objekte in ihrem Bucket](reference_policies_examples_s3_cognito-bucket.md).
### Mehrwertige Bedingungsoperatoren für Zeichenfolgen
Wenn ein Schlüssel in der Anforderung mehrere Werte enthält, können Zeichenfolgenoperatoren mit den Set-Operatoren `ForAllValues` und `ForAnyValue` qualifiziert werden. Weitere Informationen zur Auswertungslogik mehrerer Kontextschlüssel oder -werte finden Sie unter [Operatoren für mehrwertige Kontextschlüssel festlegen](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys).
| Bedingungsoperator | Description |
| --- | --- |
| `ForAllValues:StringEquals` `ForAllValues:StringEqualsIgnoreCase` | Alle Werte für den Bedingungsschlüssel in der Anforderung müssen mit mindestens einem der Werte in Ihrer Richtlinie übereinstimmen. |
| `ForAnyValue:StringEquals` `ForAnyValue:StringEqualsIgnoreCase` | Mindestens ein Bedingungsschlüsselwert in der Anforderung muss mit einem der Werte in Ihrer Richtlinie übereinstimmen. |
| `ForAllValues:StringNotEquals` `ForAllValues:StringNotEqualsIgnoreCase` | Negierte Übereinstimmung. Keiner der Werte des Kontextschlüssels in der Anforderung stimmt mit einem der Kontextschlüsselwerte in Ihrer Richtlinie überein. |
| `ForAnyValue:StringNotEquals` `ForAnyValue:StringNotEqualsIgnoreCase` | Negierte Übereinstimmung. Mindestens ein Kontextschlüsselwert in der Anforderung darf mit KEINEM der Werte im Kontextschlüssel Ihrer Richtlinie übereinstimmen. |
| `ForAllValues:StringLike` | Alle Werte für den Bedingungsschlüssel in der Anforderung müssen mit mindestens einem der Werte in Ihrer Richtlinie übereinstimmen. |
| `ForAnyValue:StringLike` | Mindestens ein Bedingungsschlüsselwert in der Anforderung muss mit einem der Werte in Ihrer Richtlinie übereinstimmen. |
| `ForAllValues:StringNotLike` | Negierte Übereinstimmung. Keiner der Werte des Kontextschlüssels in der Anforderung stimmt mit einem der Kontextschlüsselwerte in Ihrer Richtlinie überein. |
| `ForAnyValue:StringNotLike` | Negierte Übereinstimmung. Mindestens ein Kontextschlüsselwert in der Anforderung darf mit KEINEM der Werte im Kontextschlüssel Ihrer Richtlinie übereinstimmen. |
**Example Verwenden von `ForAnyValue` mit einem Bedingungsoperator für eine Zeichenfolge**
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die es erlaubt, mithilfe der Amazon-EC2-Aktion `CreateTags` Tags an eine Instance anzuhängen. Wenn Sie `StringEqualsIgnoreCase` verwenden, können Sie Tags nur anhängen, wenn das Tag den `environment`-Schlüssel mit dem Wert `preprod` oder `storage` enthält. Wenn Sie `IgnoreCase` an den Operator anhängen, erlauben Sie, dass alle vorhandenen Tag-Werte, die großgeschrieben sind, wie `preprod`, `Preprod` und `PreProd`, als „true“ aufgelöst werden.
Wenn Sie den Modifikator `ForAnyValue` mit dem Bedingungsschlüssel [aws:TagKeys](reference_policies_condition-keys.md#condition-keys-tagkeys) hinzufügen, muss mindestens ein Tag-Schlüsselwert in der Anfrage mit dem Wert `environment` übereinstimmen. Bei der `ForAnyValue`-Vergleichsfunktion wird zwischen Groß- und Kleinschreibung unterschieden, wodurch verhindert wird, dass Benutzer eine falsche Groß-/Kleinschreibung für den Tag-Schlüssel verwenden, z. B. `Environment` statt `environment`.
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "ec2:CreateTags",
"Resource": "arn:aws:ec2:*:*:instance/*",
"Condition": {
"StringEqualsIgnoreCase": {
"aws:RequestTag/environment": [
"preprod",
"storage"
]
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": "environment"
}
}
}
}
```
Die folgende Tabelle zeigt, wie diese Richtlinie auf der Grundlage der Bedingungsschlüsselwerte in Ihrer Anfrage AWS bewertet wird.
| Richtlinienbedingung | Kontext anfordern | Ergebnis |
| --- | --- | --- |
| "StringEqualsIgnoreCase": {
"aws:RequestTag/environment": [
"preprod",
"storage"
]
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": "environment"
} | aws:TagKeys:
– environment
aws:RequestTag/environment:
– preprod
| Match |
| "StringEqualsIgnoreCase": {
"aws:RequestTag/environment": [
"preprod",
"storage"
]
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": "environment"
} | aws:TagKeys:
– environment
– costcenter
aws:RequestTag/environment:
– PreProd
| Match |
| "StringEqualsIgnoreCase": {
"aws:RequestTag/environment": [
"preprod",
"storage"
]
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": "environment"
} | aws:TagKeys:
– Environment
aws:RequestTag/Environment:
– preprod
| Keine Übereinstimmung |
| "StringEqualsIgnoreCase": {
"aws:RequestTag/environment": [
"preprod",
"storage"
]
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": "environment"
} | aws:TagKeys:
– costcenter
aws:RequestTag/environment:
– preprod
| Keine Übereinstimmung |
| "StringEqualsIgnoreCase": {
"aws:RequestTag/environment": [
"preprod",
"storage"
]
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": "environment"
} | Kein `aws:TagKeys` im Anfragekontext. aws:RequestTag/environment:
– storage
| Keine Übereinstimmung |
| "StringEqualsIgnoreCase": {
"aws:RequestTag/environment": [
"preprod",
"storage"
]
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": "environment"
} | aws:TagKeys:
– environment
Kein `aws:RequestTag/environment` im Anfragekontext. | Keine Übereinstimmung |
| "StringEqualsIgnoreCase": {
"aws:RequestTag/environment": [
"preprod",
"storage"
]
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": "environment"
} | Kein `aws:TagKeys` im Anfragekontext. Kein `aws:RequestTag/environment` im Anfragekontext. | Keine Übereinstimmung |
### Platzhalterabgleich
Operatoren für Zeichenfolgenbedingungen führen einen musterlosen Abgleich durch, der kein vordefiniertes Format erzwingt. Die Bedingungsoperatoren ARN und Datum sind eine Teilmenge von Zeichenfolgenoperatoren, die eine Struktur für den Bedingungsschlüsselwert erzwingen.
Wir empfehlen Ihnen, Bedingungsoperatoren zu verwenden, die den Werten entsprechen, mit denen Sie die Schlüssel vergleichen. Beispielsweise sollten Sie beim Vergleichen von Schlüsseln mit Zeichenfolgenwerten [Bedingungsoperatoren für Zeichenfolgen](#Conditions_String) verwenden. Ebenso sollten Sie [Bedingungsoperatoren für Amazon-Ressourcennamen (ARN)](#Conditions_ARN) verwenden, wenn Sie Schlüssel mit ARN-Werten vergleichen.
**Example**
Dieses Beispiel zeigt, wie Sie eine Grenze um Ressourcen in Ihrer Organisation erstellen können. Die Bedingung in dieser Richtlinie verweigert den Zugriff auf Amazon S3 S3-Aktionen, es sei denn, die Ressource, auf die zugegriffen wird, befindet sich in einer bestimmten Gruppe von Organisationseinheiten (OUs) in AWS Organizations. Ein AWS Organizations -Pfad ist eine textuelle Darstellung der Struktur einer Organisationseinheit.
Die Bedingung setzt voraus, dass `aws:ResourceOrgPaths` einen der aufgelisteten OU-Pfade enthält. Da `aws:ResourceOrgPaths` es sich um eine Bedingung mit mehreren Werten handelt, verwendet die Richtlinie den `ForAllValues:StringNotLike` Operator, um die Werte von mit der Liste OUs in der Richtlinie `aws:ResourceOrgPaths` zu vergleichen.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyS3AccessOutsideMyBoundary",
"Effect": "Deny",
"Action": [
"s3:*"
],
"Resource": "*",
"Condition": {
"ForAllValues:StringNotLike": {
"aws:ResourceOrgPaths": [
"o-acorg/r-acroot/ou-acroot-mediaou/",
"o-acorg/r-acroot/ou-acroot-sportsou/*"
]
}
}
}
]
}
```
Die folgende Tabelle zeigt, wie diese Richtlinie auf der Grundlage der Bedingungsschlüsselwerte in Ihrer Anfrage AWS bewertet wird.
| Richtlinienbedingung | Kontext anfordern | Ergebnis |
| --- | --- | --- |
| "ForAllValues:StringNotLike": {
"aws:ResourceOrgPaths": [
"o-acorg/r-acroot/ou-acroot-mediaou/",
"o-acorg/r-acroot/ou-acroot-sportsou/*"
]
} | aws:ResourceOrgPaths:
– o-acorg/r-acroot/ou-acroot-sportsou/costcenter/
| Match |
| "ForAllValues:StringNotLike": {
"aws:ResourceOrgPaths": [
"o-acorg/r-acroot/ou-acroot-mediaou/",
"o-acorg/r-acroot/ou-acroot-sportsou/*"
]
} | aws:ResourceOrgPaths:
– o-acorg/r-acroot/ou-acroot-mediaou/costcenter/
| Keine Übereinstimmung |
| "ForAllValues:StringNotLike": {
"aws:ResourceOrgPaths": [
"o-acorg/r-acroot/ou-acroot-mediaou/",
"o-acorg/r-acroot/ou-acroot-sportsou/*"
]
} | Kein `aws:ResourceOrgPaths:` in der Anforderung. | Keine Übereinstimmung |
## Numerische Bedingungsoperatoren
Mit numerischen Bedingungsoperatoren können Sie `Condition`-Elemente erstellen, die den Zugriff basierend auf einen Vergleich eines Schlüssels mit einem Ganzzahl- oder Dezimalzahlwert einschränken.
+ **Richtlinienvariablen**: nicht unterstützt
+ **Platzhalter**: nicht unterstützt
****
| Bedingungsoperator | Description |
| --- | --- |
| `NumericEquals` | Übereinstimmung |
| `NumericNotEquals` | Negierte Übereinstimmung |
| `NumericLessThan` | Übereinstimmung "Kleiner als" |
| `NumericLessThanEquals` | Übereinstimmung "Kleiner als oder gleich" |
| `NumericGreaterThan` | Übereinstimmung "Größer als" |
| `NumericGreaterThanEquals` | Übereinstimmung "Größer als oder gleich" |
Die folgende Anweisung enthält beispielsweise ein `Condition`-Element, das den Bedingungsoperator `NumericLessThanEquals` mit dem Schlüssel `s3:max-keys` enthält, um anzugeben, dass der Anforderer *bis zu* 10 Objekte gleichzeitig im `amzn-s3-demo-bucket` aufnehmen kann.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
"Condition": {"NumericLessThanEquals": {"s3:max-keys": "10"}}
}
}
```
------
Wenn der Schlüssel, den Sie in einer Richtlinienbedingung angeben, im Anforderungskontext nicht vorhanden ist, stimmen die Werte nicht überein. In diesem Beispiel ist der `s3:max-keys`-Schlüssel immer in der Anforderung vorhanden, wenn Sie die Operation `ListBucket` ausführen. Wenn diese Richtlinie alle Amazon S3-Operationen zulässt, sind nur die Operationen zulässig, die den `max-keys`-Kontextschlüssel mit einem Wert von kleiner oder gleich 10 enthalten.
## Bedingungsoperatoren für Datum
Mit Operatoren für Datumsbedingungen können Sie `Condition` Elemente erstellen, die den Zugriff einschränken, indem Sie einen Schlüssel mit einem date/time Wert vergleichen. Diese Bedingungsoperatoren werden mit dem Schlüssel [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-currenttime](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-currenttime) oder [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-epochtime](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-epochtime) verwendet. Sie müssen date/time Werte mit einer der [W3C-Implementierungen der ISO-8601-Datumsformate](http://www.w3.org/TR/NOTE-datetime) oder in Epochenzeit (UNIX) angeben.
+ **Richtlinienvariablen**: nicht unterstützt
+ **Platzhalter**: nicht unterstützt
****
| Bedingungsoperator | Description |
| --- | --- |
| `DateEquals` | Übereinstimmung mit einem bestimmten Datum |
| `DateNotEquals` | Negierte Übereinstimmung |
| `DateLessThan` | Übereinstimmung vor einem bestimmten Datum und einer bestimmten Uhrzeit |
| `DateLessThanEquals` | Übereinstimmung an oder vor einem bestimmten Datum und oder einer bestimmten Uhrzeit |
| `DateGreaterThan` | Übereinstimmung nach einem bestimmten Datum und einer bestimmten Uhrzeit |
| `DateGreaterThanEquals` | Übereinstimmung an oder nach einem bestimmten Datum und einer bestimmten Uhrzeit |
Beispielsweise enthält die folgende Anweisung ein `Condition`-Element, das den Bedingungsoperator `DateGreaterThan` mit dem [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-tokenissuetime](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-tokenissuetime)-Schlüssel verwendet. Diese Bedingung gibt an, dass die temporären Sicherheitsanmeldeinformationen, die für die Anforderung verwendet wurden, im Jahr 2020 ausgegeben wurden. Diese Richtlinie kann täglich programmgesteuert aktualisiert werden, um sicherzustellen, dass Kontomitglieder neue Anmeldeinformationen verwenden.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "iam:*AccessKey*",
"Resource": "arn:aws:iam::111122223333:user/*",
"Condition": {
"DateGreaterThan": {
"aws:TokenIssueTime": "2020-01-01T00:00:01Z"
}
}
}
}
```
------
Wenn der Schlüssel, den Sie in einer Richtlinienbedingung angeben, im Anforderungskontext nicht vorhanden ist, stimmen die Werte nicht überein. Der `aws:TokenIssueTime`-Schlüssel ist im Anforderungskontext nur dann vorhanden, wenn der Auftraggeber temporäre Anmeldeinformationen für die Anforderung verwendet. Der Schlüssel ist nicht in AWS CLI AWS API- oder AWS SDK-Anfragen enthalten, die mit Zugriffsschlüsseln gestellt werden. Wenn in diesem Beispiel ein IAM-Benutzer versucht, einen Zugriffsschlüssel anzuzeigen oder zu bearbeiten, wird die Anforderung verweigert.
## Boolesche Bedingungsoperatoren
Mit booleschen Bedingungsoperatoren können Sie `Condition`-Elemente erstellen, die den Zugriff basierend auf einen Vergleich eines Schlüssels mit `true` oder `false` einschränken.
Wenn ein Schlüssel mehrere Werte enthält, können boolesche Operatoren mit den Set-Operatoren `ForAllValues` und `ForAnyValue` qualifiziert werden. Weitere Informationen zur Auswertungslogik mehrerer Kontextschlüssel oder -werte finden Sie unter [Operatoren für mehrwertige Kontextschlüssel festlegen](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys).
+ **Richtlinienvariablen**: [unterstützt](reference_policies_variables.md)
+ **Platzhalter**: nicht unterstützt
****
| Bedingungsoperator | Description |
| --- | --- |
| `Bool` | Boolesche Übereinstimmung |
| `ForAllValues:Bool` | Verwendung mit dem Datentyp „Array of Bool“. Alle Booleschen Werte in den Kontextschlüsselwerten müssen mit den Booleschen Werten in Ihrer Richtlinie übereinstimmen. Um zu verhindern, dass `ForAllValues`-Operatoren fehlende Kontextschlüssel oder Kontextschlüssel mit leeren Werten als „Zulässig“ auswerten, können Sie den [Null-Bedingungsoperator](#Conditions_Null) in Ihre Richtlinie aufnehmen. |
| `ForAnyValue:Bool` | Verwendung mit dem Datentyp „Array of Bool“. Mindestens einer der Booleschen Werte in den Kontextschlüsselwerten müssen mit den Booleschen Werten in Ihrer Richtlinie übereinstimmen. |
**Example Boolescher Bedingungsoperator**
Die folgende identitätsbasierte Richtlinie verwendet den `Bool`-Bedingungsoperator mit dem [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-securetransport](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-securetransport)-Schlüssel, um die Replikation von Objekten und Objekt-Tags in den Ziel-Bucket und dessen Inhalt zu verweigern, wenn die Anforderung nicht über SSL erfolgt.
Diese Richtlinie lässt keine Aktionen zu. Verwenden Sie diese Richtlinie in Kombination mit anderen Richtlinien, die bestimmte Aktionen zulassen.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "BooleanExample",
"Action": "s3:ReplicateObject",
"Effect": "Deny",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
],
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
}
]
}
```
Die folgende Tabelle zeigt, wie diese Richtlinie auf der Grundlage der Bedingungsschlüsselwerte in Ihrer Anfrage AWS bewertet wird.
| Richtlinienbedingung | Kontext anfordern | Ergebnis |
| --- | --- | --- |
| "Bool": {
"aws:SecureTransport": "false"
} | aws:SecureTransport:
– false
| Match |
| "Bool": {
"aws:SecureTransport": "false"
} | aws:SecureTransport:
– true
| Keine Übereinstimmung |
| "Bool": {
"aws:SecureTransport": "false"
} | Kein `aws:SecureTransport` im Anfragekontext. | Keine Übereinstimmung |
## Binäre Bedingungsoperatoren
Mit dem Bedingungsoperator `BinaryEquals` können Sie `Condition`-Elemente zum Prüfen von binären Schlüsselwerten erstellen. Er vergleicht den Wert des angegebenen Schlüssel Byte für Byte mit einer [base-64](https://en.wikipedia.org/wiki/Base64)-kodierten Darstellung des Binärwertes in der Richtlinie. Wenn der Schlüssel, den Sie in einer Richtlinienbedingung angeben, im Anforderungskontext nicht vorhanden ist, stimmen die Werte nicht überein.
+ **Richtlinienvariablen**: nicht unterstützt
+ **Platzhalter**: nicht unterstützt
```
"Condition" : {
"BinaryEquals": {
"key" : "QmluYXJ5VmFsdWVJbkJhc2U2NA=="
}
}
```
| Richtlinienbedingung | Kontext anfordern | Ergebnis |
| --- | --- | --- |
| "BinaryEquals": {
"key" : "QmluYXJ5VmFsdWVJbkJhc2U2NA=="
} | key:
– QmluYXJ5VmFsdWVJbkJhc2U2NA==
| Match |
| "BinaryEquals": {
"key" : "QmluYXJ5VmFsdWVJbkJhc2U2NA=="
} | key:
– ASIAIOSFODNN7EXAMPLE
| Keine Übereinstimmung |
| "BinaryEquals": {
"key" : "QmluYXJ5VmFsdWVJbkJhc2U2NA=="
} | Kein `key` im Anfragekontext. | Keine Übereinstimmung |
## Bedingungsoperatoren für IP-Adressen
Mit Operatoren für IP-Adressbedingungen können Sie `Condition` Elemente erstellen, die den Zugriff einschränken, indem Sie einen Schlüssel mit einer IPv4 oder einer IPv6 Adresse oder einem Bereich von IP-Adressen vergleichen. Verwenden Sie sie mit dem Schlüssel [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceip](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceip). Der Wert muss im CIDR-Standardformat vorliegen (z. B. 203.0.113.0/24 oder 2001:: 1234:5678: :/64). DB8 Wenn Sie eine IP-Adresse ohne das zugehörige Routing-Präfix zuweisen, verwendet IAM den Standard-Präfixwert `/32`.
Einige Dienste unterstützen die Verwendung von:: zur Darstellung eines Bereichs von Nullen. AWS IPv6 Informationen darüber, ob ein Dienst dies unterstützt IPv6, finden Sie in der Dokumentation zu diesem Dienst.
+ **Richtlinienvariablen**: nicht unterstützt
+ **Platzhalter**: nicht unterstützt
****
| Bedingungsoperator | Description |
| --- | --- |
| `IpAddress` | Die angegebene IP-Adresse oder der angegebene IP-Bereich |
| `NotIpAddress` | Alle IP-Adressen mit Ausnahme der angegebenen IP-Adresse oder des angegebenen IP-Bereichs. |
**Example Bedingungsoperator für IP-Adressen**
In der folgenden Anweisung wird der Bedingungsoperator `IpAddress` mit dem Schlüssel `aws:SourceIp` verwendet, um anzugeben, dass die Anforderung von einer IP-Adresse zwischen 203.0.113.0 und 203.0.113.255 kommen muss.
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "iam:*AccessKey*",
"Resource": "arn:aws:iam::111122223333:user/*",
"Condition": {
"IpAddress": {
"aws:SourceIp": "203.0.113.0/24"
}
}
}
}
```
Der Bedingungsschlüssel `aws:SourceIp` wird auf die IP-Adresse aufgelöst, von der die Anforderung kommt. Wenn die Anforderungen aus einer Amazon EC2-Instance kommen, gibt `aws:SourceIp` die öffentliche IP-Adresse der Instance zurück.
Wenn der Schlüssel, den Sie in einer Richtlinienbedingung angeben, im Anforderungskontext nicht vorhanden ist, stimmen die Werte nicht überein. Der `aws:SourceIp`-Schlüssel ist immer im Anforderungskontext vorhanden, außer wenn der Anforderer einen VPC-Endpunkt für die Anforderung verwendet. In diesem Fall gibt die Bedingung `false` zurück und die Anforderung wird durch diese Anweisung implizit abgelehnt.
Die folgende Tabelle zeigt, wie diese Richtlinie auf der Grundlage der Bedingungsschlüsselwerte in Ihrer Anfrage AWS bewertet wird.
| Richtlinienbedingung | Kontext anfordern | Ergebnis |
| --- | --- | --- |
| "IpAddress": {
"aws:SourceIp": "203.0.113.0/24"
} | aws:SourceIp:
– 203.0.113.1
| Match |
| "IpAddress": {
"aws:SourceIp": "203.0.113.0/24"
} | aws:SourceIp:
– 198.51.100.1
| Keine Übereinstimmung |
Das folgende Beispiel zeigt, wie Sie IPv6 Adressen kombinieren IPv4 können, um alle gültigen IP-Adressen Ihrer Organisation abzudecken. Wir empfehlen Ihnen, die Richtlinien Ihrer Organisation mit Ihren IPv6 Adressbereichen zu aktualisieren, zusätzlich zu den IPv4 Bereichen, die Sie bereits haben, um sicherzustellen, dass die Richtlinien auch bei der Umstellung weiterhin funktionieren IPv6.
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "someservice:*",
"Resource": "*",
"Condition": {
"IpAddress": {
"aws:SourceIp": [
"203.0.113.0/24",
"2001:DB8:1234:5678::/64"
]
}
}
}
}
```
Der Bedingungsschlüssel `aws:SourceIp` funktioniert in einer JSON-Richtlinie nur, wenn Sie die geprüfte API direkt als Benutzer aufrufen. Wenn Sie stattdessen einen Service verwenden, um den Zielservice in Ihrem Namen aufzurufen, erkennt der Zielservice die IP-Adresse des aufrufenden Services und nicht die IP-Adresse des verursachenden Benutzers. Das kann passieren, wenn Sie beispielsweise AWS CloudFormation zum Aufrufen von Amazon EC2 aufrufen, um in Ihrem Namen Instances zu erstellen. Derzeit gibt es keine Möglichkeit, die ursprüngliche IP-Adresse über einen Aufrufservice an den Zielservice zur Bewertung in einer JSON-Richtlinie zu übermitteln. Verwenden Sie für diese Art von Service-API-Aufrufen nicht den Bedingungsschlüssel `aws:SourceIp`.
## Bedingungsoperatoren für Amazon-Ressourcennamen (ARN)
Mit den Bedingungsoperatoren für Amazon-Ressourcennamen (ARN) können Sie `Condition`-Elemente erstellen, die den Zugriff basierend auf einen Vergleich eines Schlüssels mit einem ARN einschränken. Der ARN wird als Zeichenfolge interpretiert.
+ **Richtlinienvariablen**: [unterstützt](reference_policies_variables.md)
+ **Platzhalter**: [unterstützt](reference_policies_elements_resource.md#reference_policies_elements_resource_wildcards)
****
| Bedingungsoperator | Description |
| --- | --- |
| `ArnEquals`, `ArnLike` | Übereinstimmung mit Unterscheidung von Groß- und Kleinschreibung des ARN Jede der sechs durch Doppelpunkt getrennten Komponenten der ARN wird separat überprüft und alle Komponenten können Mehrzeichen-Übereinstimmungs-Platzhalter (\$1) oder einen Einzelzeichen-Übereinstimmungs-Platzhalter (?) enthalten. Die `ArnEquals`- und `ArnLike`-Bedingungsoperatoren verhalten sich identisch. |
| `ArnNotEquals`, `ArnNotLike` | Negierte Übereinstimmung von ARN Die`ArnNotEquals`- und`ArnNotLike`-Bedingungsoperatoren verhalten sich identisch. |
**Example ARN-Bedingungsoperator**
Das folgende ressourcenbasierte Richtlinienbeispiel zeigt eine Richtlinie, die einer Amazon SQS-Warteschlange zugeordnet ist, an die Sie SNS-Nachrichten senden möchten. Es gibt Amazon SNS die Erlaubnis, Nachrichten an die Warteschlange (oder Warteschlangen) Ihrer Wahl zu senden, aber nur, wenn der Service die Nachrichten im Namen eines bestimmten Amazon SNS-Themas (oder Themen) sendet. Geben Sie die Warteschlange im Feld `Resource` und das Amazon SNS-Thema als Wert für den Schlüssel `SourceArn` an.
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {
"Service": "sns.amazonaws.com"
},
"Action": "SQS:SendMessage",
"Resource": "arn:aws:sqs:us-east-1:123456789012:QUEUE-ID",
"Condition": {
"ArnEquals": {
"aws:SourceArn": "arn:aws:sns:us-east-1:123456789012:TOPIC-ID"
}
}
}
}
```
Der [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn)-Schlüssel ist im Anforderungskontext nur dann vorhanden, wenn eine Ressource einen Service auslöst, um einen anderen Service im Namen des Ressourcenbesitzers aufzurufen. Wenn ein IAM-Benutzer versucht, diesen Vorgang direkt auszuführen, kehrt die Bedingung `false` zurück und die Anforderung wird implizit durch diese Anweisung abgelehnt.
Die folgende Tabelle zeigt, wie diese Richtlinie auf der Grundlage der Bedingungsschlüsselwerte in Ihrer Anfrage AWS bewertet wird.
| Richtlinienbedingung | Kontext anfordern | Ergebnis |
| --- | --- | --- |
| "ArnEquals": {
"aws:SourceArn": "arn:aws:sns:us-west-2:123456789012:TOPIC-ID"
} | aws:SourceArn:
– arn:aws:sns:us-west-2:123456789012:TOPIC-ID
| Match |
| "ArnEquals": {
"aws:SourceArn": "arn:aws:sns:us-west-2:123456789012:TOPIC-ID"
} | aws:SourceArn:
– arn:aws:sns:us-west-2:777788889999:TOPIC-ID
| Keine Übereinstimmung |
| "ArnEquals": {
"aws:SourceArn": "arn:aws:sns:us-west-2:123456789012:TOPIC-ID"
} | Kein `aws:SourceArn` im Anfragekontext. | Keine Übereinstimmung |
### Mehrwertige ARN-Bedingungsoperatoren
Wenn ein Schlüssel in der Anforderung mehrere Werte enthält, können ARN-Operatoren mit den Set-Operatoren `ForAllValues` und `ForAnyValue` qualifiziert werden. Weitere Informationen zur Auswertungslogik mehrerer Kontextschlüssel oder -werte finden Sie unter [Operatoren für mehrwertige Kontextschlüssel festlegen](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys).
| Bedingungsoperator | Description |
| --- | --- |
| `ForAllValues:ArnEquals` `ForAllValues:ArnLike` | Alle ARNs im Anforderungskontext müssen mit mindestens einem der ARN-Muster in Ihrer Richtlinie übereinstimmen. |
| `ForAnyValue:ArnEquals` `ForAnyValue:ArnLike` | Mindestens ein ARN im Anforderungskontext muss mit einem der ARN-Muster in Ihrer Richtlinie übereinstimmen. |
| `ForAllValues:ArnNotEquals` `ForAllValues:ArnNotLike` | Negierte Übereinstimmung. Keines der ARNs im Anforderungskontext enthaltenen ARN-Muster kann mit Zeichenketten-ARN-Mustern in Ihrer Richtlinie übereinstimmen. |
| `ForAnyValue:ArnNotEquals` `ForAnyValue:ArnNotLike` | Negierte Übereinstimmung. Mindestens ein ARN im Anforderungskontext darf NICHT mit einem der ARN-Muster in Ihrer Richtlinie übereinstimmen. |
**Example Verwenden von `ForAllValues` mit einem ARN-Bedingungsoperator**
Das folgende Beispiel dient `ForAllValues:ArnLike` dazu, eine logische Zustellungsquelle für Amazon CloudWatch Logs-Protokolle zu erstellen oder zu aktualisieren. Der Bedingungsblock enthält den Bedingungsschlüssel [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatchlogs.html#amazoncloudwatchlogs-policy-keys](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatchlogs.html#amazoncloudwatchlogs-policy-keys)zum Filtern der in der Anfrage ARNs übergebenen Ressource zur Protokollgenerierung. Bei Verwendung dieses Bedingungsoperators müssen alle ARNs in der Anfrage enthaltenen Informationen mit mindestens einem ARN in der Richtlinie übereinstimmen.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "logs:PutDeliverySource",
"Resource": "arn:aws:logs:us-east-1:123456789012:delivery-source:*",
"Condition": {
"ForAllValues:ArnLike": {
"logs:LogGeneratingResourceArns": [
"arn:aws:cloudfront::123456789012:distribution/*",
"arn:aws:cloudfront::123456789012:distribution/support*"
]
}
}
}
]
}
```
Die folgende Tabelle zeigt, wie diese Richtlinie auf der Grundlage der Bedingungsschlüsselwerte in Ihrer Anfrage AWS bewertet wird.
| Richtlinienbedingung | Kontext anfordern | Ergebnis |
| --- | --- | --- |
| "ForAllValues:ArnLike": {
"logs:LogGeneratingResourceArns": [
"arn:aws::cloudfront:123456789012:distribution/*",
"arn:aws::cloudfront:123456789012:distribution/support*"
]
} | logs:LogGeneratingResourceArns:
– arn:aws::cloudfront:123456789012:distribution/costcenter
| Match |
| "ForAllValues:ArnLike": {
"logs:LogGeneratingResourceArns": [
"arn:aws::cloudfront:123456789012:distribution/*",
"arn:aws::cloudfront:123456789012:distribution/support*"
]
} | logs:LogGeneratingResourceArns:
– arn:aws::cloudfront:123456789012:distribution/costcenter
– arn:aws::cloudfront:123456789012:distribution/support2025
| Match |
| "ForAllValues:ArnLike": {
"logs:LogGeneratingResourceArns": [
"arn:aws::cloudfront:123456789012:distribution/*",
"arn:aws::cloudfront:123456789012:distribution/support*"
]
} | logs:LogGeneratingResourceArns:
– arn:aws::cloudfront:123456789012:distribution/costcenter
– arn:aws::cloudfront:123456789012:distribution/admin
| Keine Übereinstimmung |
| "ForAllValues:ArnLike": {
"logs:LogGeneratingResourceArns": [
"arn:aws::cloudfront:123456789012:distribution/*",
"arn:aws::cloudfront:123456789012:distribution/support*"
]
} | logs:LogGeneratingResourceArns:
– arn:aws::cloudfront:777788889999:distribution/costcenter
| Keine Übereinstimmung |
| "ForAllValues:ArnLike": {
"logs:LogGeneratingResourceArns": [
"arn:aws::cloudfront:123456789012:distribution/*",
"arn:aws::cloudfront:123456789012:distribution/support*"
]
} | Kein `logs:LogGeneratingResourceArns` im Anforderungskontext. | Match |
Der Qualifizierer `ForAllValues` gibt „true“ zurück, wenn die Anforderung keine Kontextschlüssel enthält oder wenn der Wert des Kontextschlüssels zu einem Null-Datensatz aufgelöst wird, z. B. einer leeren Zeichenfolge. Um zu verhindern, dass fehlende Kontextschlüssel oder Kontextschlüssel mit leeren Werten als „true“ ausgewertet werden, können Sie den [Null-Bedingungsoperator](#Conditions_Null) mit einem `false`-Wert in Ihre Richtlinie aufnehmen, um zu überprüfen, ob der Kontextschlüssel vorhanden ist und sein Wert nicht null ist.
## ... IfExists Bedingungsoperatoren
Sie können `IfExists` an das Ende jedes Bedingungsoperatornamens hinzufügen, abgesehen von der `Null`-Bedingung wie z. B. `StringLikeIfExists`. Damit geben Sie zum Ausdruck: „Wenn der Bedingungsschlüssel im Kontext der Anfrage vorhanden ist, verarbeiten Sie den Schlüssel wie in der Richtlinie angegeben.“ Wenn der Schlüssel nicht vorhanden ist, wird das Bedingungselement als "true" ausgewertet. Andere Bedingungselemente in der Anweisung können weiterhin zu einer Nichtübereinstimmung führen, nicht jedoch ein fehlender Schlüssel bei einer Prüfung mit `...IfExists`. Wenn Sie ein `"Effect": "Deny"`-Element mit einem negierten Bedingungsoperator wie `StringNotEqualsIfExists` verwenden, wird die Anfrage dennoch abgelehnt, auch wenn der Bedingungsschlüssel nicht vorhanden ist.
**Beispiel mit `IfExists`**
Viele Bedingungsschlüssel beschreiben einen bestimmten Ressourcentyp und existieren nur beim Zugriff auf diesen Ressourcentyp. Diese Bedingungsschlüssel sind bei anderen Ressourcentypen nicht vorhanden. Dies stellt kein Problem dar, wenn die Richtlinienanweisung nur für einen Ressourcentyp gültig ist. Es gibt jedoch Fälle, bei denen eine einzelne Anweisung auf mehrere Ressourcentypen zutrifft, wenn beispielsweise die Richtlinienanweisung auf Aktionen aus mehreren Services Bezug nimmt oder wenn eine bestimmte Aktion innerhalb eines Services auf mehrere verschiedene Ressourcentypen in demselben Service zugreift. In solchen Fällen kann ein nur für eine Ressource gültiger Bedingungsschlüssel in einer Richtlinienanweisung dazu führen, dass das Element `Condition` in der Richtlinienanweisung fehlschlägt, sodass der `"Effect"` der Anweisung nicht angewendet wird.
Betrachten Sie beispielsweise das folgende einfache Richtlinienbeispiel:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Sid": "THISPOLICYDOESNOTWORK",
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": "*",
"Condition": {"StringLike": {"ec2:InstanceType": [
"t1.*",
"t2.*",
"m3.*"
]}}
}
}
```
------
Der *Zweck* der vorangegangenen Richtlinie besteht darin, den Benutzer zum Starten einer beliebigen Instance vom Typ `t1`, `t2` oder `m3` zu befähigen. Zum Starten einer Instance ist jedoch auch der Zugriff auf viele Ressourcen zusätzlich zu der Instance selbst erforderlich, wie z. B. Images, Schlüsselpaare, Sicherheitsgruppen usw. Die gesamte Anweisung wird gegen alle Ressourcen geprüft, die zum Starten der Instance erforderlich sind. Diese zusätzlichen Ressourcen verfügen nicht über den Bedingungsschlüssel `ec2:InstanceType`, sodass die Prüfung `StringLike` fehlschlägt und der Benutzer nicht zum Starten eines *beliebigen* Instance-Typs befähigt wird.
Um dieses Problem zu beheben, verwenden Sie stattdessen den Bedingungsoperator `StringLikeIfExists`. Auf diese Weise findet die Prüfung nur dann statt, wenn der Bedingungsschlüssel existiert. Sie können nachstehende Richtlinie folgendermaßen interpretieren: „Wenn die zu prüfende Ressource den Bedingungsschlüssel „`ec2:InstanceType`„ enthält, wird die Aktion nur zugelassen, wenn der Schlüsselwert mit `t1.`, `t2.` oder `m3.` beginnt.“ Wenn die zu prüfende Ressource nicht über diesen Bedingungsschlüssel verfügt, ist dies belanglos." Das Sternchen (\$1) in den Bedingungsschlüsselwerten wird, wenn es mit dem `StringLikeIfExists`-Bedingungsoperator verwendet wird, als Platzhalter interpretiert, um teilweise übereinstimmende Zeichenfolgen zu erzielen. Die Anweisung `DescribeActions` enthält die Aktionen, die erforderlich sind, um die Instance in der Konsole anzeigen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "RunInstance",
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": "*",
"Condition": {
"StringLikeIfExists": {
"ec2:InstanceType": [
"t1.*",
"t2.*",
"m3.*"
]
}
}
},
{
"Sid": "DescribeActions",
"Effect": "Allow",
"Action": [
"ec2:DescribeImages",
"ec2:DescribeInstances",
"ec2:DescribeVpcs",
"ec2:DescribeKeyPairs",
"ec2:DescribeSubnets",
"ec2:DescribeSecurityGroups"
],
"Resource": "*"
}
]
}
```
------
Die folgende Tabelle zeigt, wie diese Richtlinie auf der Grundlage der Bedingungsschlüsselwerte in Ihrer Anfrage AWS bewertet wird.
| Richtlinienbedingung | Kontext anfordern | Ergebnis |
| --- | --- | --- |
| "StringLikeIfExists": {
"ec2:InstanceType": [
"t1.*",
"t2.*",
"m3.*"
]
} | ec2:InstanceType:
– t1.micro
| Match |
| "StringLikeIfExists": {
"ec2:InstanceType": [
"t1.*",
"t2.*",
"m3.*"
]
} | ec2:InstanceType:
– m2.micro
| Keine Übereinstimmung |
| "StringLikeIfExists": {
"ec2:InstanceType": [
"t1.*",
"t2.*",
"m3.*"
]
} | Kein `ec2:InstanceType` im Anforderungskontext. | Match |
## Bedingungsoperator zur Prüfung der Existenz von Bedingungsoperatoren
Verwenden Sie einen Bedingungsoperator `Null`, um zu prüfen, ob ein Bedingungsschlüssel zum Zeitpunkt der Autorisierung abwesend ist. Verwenden Sie in der Richtlinienanweisung entweder `true` (der Schlüssel ist nicht vorhanden – der Wert beträgt null) oder `false` (der Schlüssel ist vorhanden und sein Wert ist ungleich null).
Sie können eine [Richtlinienvariable](reference_policies_variables.md) mit dem `Null`Bedingungsoperator verwenden.
Beispielsweise können Sie diesen Bedingungsoperator verwenden, um festzustellen, ob ein Benutzer temporäre Anmeldeinformationen oder seine eigenen verwendet, um eine Anforderung zu stellen. Wenn der Benutzer temporäre Anmeldeinformationen benutzt, ist der Schlüssel `aws:TokenIssueTime` vorhanden und hat einen Wert. Das folgende Beispiel zeigt eine Bedingung, die besagt, dass der Benutzer temporäre Anmeldeinformationen verwenden muss (der Schlüssel darf nicht fehlen), damit er die Amazon-EC2-API verwenden kann.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":{
"Action":"ec2:*",
"Effect":"Allow",
"Resource":"*",
"Condition":{"Null":{"aws:TokenIssueTime":"false"}}
}
}
```
------
# Bedingungen mit mehreren Kontextschlüsseln oder -werten
Sie können das `Condition`-Element einer Richtlinie verwenden, um mehrere Kontextschlüssel oder mehrere Werte für einen einzelnen Kontextschlüssel in einer Anfrage zu testen. Wenn Sie eine Anfrage an stellen AWS, entweder programmgesteuert oder über die AWS-Managementkonsole, enthält Ihre Anfrage Informationen über Ihren Principal, Ihren Betrieb, Ihre Tags und mehr. Mithilfe von Kontextschlüsseln können Sie die Werte der übereinstimmenden Kontextschlüssel in der Anfrage anhand der in der Richtlinienbedingung angegebenen Kontextschlüssel testen. Weitere Informationen zu den in einer Anforderung enthaltenen Informationen und Daten finden Sie unter [Der Anforderungskontext](reference_policies_elements_condition.md#AccessPolicyLanguage_RequestContext).
**Topics**
+ [Auswertungslogik für mehrere Kontextschlüssel oder -werte](#reference_policies_multiple-conditions-eval)
+ [Auswertungslogik für negierte übereinstimmende Bedingungsoperatoren](#reference_policies_multiple-conditions-negated-matching-eval)
## Auswertungslogik für mehrere Kontextschlüssel oder -werte
Ein `Condition`-Element kann mehrere Bedingungsoperatoren enthalten, und jeder Bedingungsoperator kann mehrere Kontext-Schlüssel-Wert-Paare enthalten. Die meisten Kontextschlüssel unterstützen die Verwendung mehrerer Werte, sofern nicht anders angegeben.
+ Wenn Ihre Richtlinienanweisung mehrere [Bedingungsoperatoren](reference_policies_elements_condition_operators.md) enthält, werden die Bedingungsoperatoren anhand eines logischen `AND` ausgewertet.
+ Wenn Ihre Richtlinienanweisung mehrere Bedingungsoperatoren enthält oder einem Bedingungsoperator mehrere Schlüssel angefügt sind, werden die Bedingungen anhand eines logischen `AND` ausgewertet.
+ Wenn ein einzelner Bedingungsoperator mehrere Werte für einen Kontextschlüssel enthält, werden diese Werte anhand eines logischen `OR` ausgewertet.
+ Wenn ein einzelner negierter übereinstimmender Bedingungsoperator mehrere Werte für einen Kontextschlüssel enthält, werden diese Werte anhand eines logischen `NOR` ausgewertet.
Alle Kontextschlüssel in einem Bedingungselementblock müssen zu „wahr“ aufgelöst werden, um den gewünschten `Allow`- oder `Deny`-Effekt aufzurufen. Das folgende Image veranschaulicht die Auswertungslogik für eine Bedingung mit mehreren Bedingungsoperatoren und Kontextschlüssel-Wert-Paaren.
![\[Bedingungsblock zur Erläuterung der Verwendung von AND und OR mit mehreren Kontextschlüsseln und -werten\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/images/AccessPolicyLanguage_Condition_Block_AND_2.diagram.png)
Die folgende S3-Bucket-Richtlinie veranschaulicht beispielsweise, wie das vorherige Image in einer Richtlinie dargestellt wird. Der Bedingungsblock enthält die Bedingungsoperatoren `StringEquals` und `ArnLike` sowie die Kontextschlüssel `aws:PrincipalTag` und `aws:PrincipalArn`. Um den gewünschten `Allow`- oder `Deny`-Effekt aufzurufen, müssen alle Kontextschlüssel im Bedingungsblock zu „wahr“ aufgelöst werden. Der Benutzer, der die Anforderung stellt, muss beide Prinzipal-Tag-Schlüssel haben, *Abteilung* und *Rolle*, die einen der in der Richtlinie angegebenen Tag-Schlüsselwerte enthalten. Außerdem muss der Prinzipal-ARN, der die Anfrage stellt, mit einem der in der Richtlinie angegebenen `aws:PrincipalArn`-Werte übereinstimmen, damit er als wahr ausgewertet werden kann.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ExamplePolicy",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::222222222222:root"
},
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
"Condition": {
"StringEquals": {
"aws:PrincipalTag/department": [
"finance",
"hr",
"legal"
],
"aws:PrincipalTag/role": [
"audit",
"security"
]
},
"ArnLike": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:user/Ana",
"arn:aws:iam::222222222222:user/Mary"
]
}
}
}
]
}
```
------
Die folgende Tabelle zeigt, wie diese Richtlinie auf der Grundlage der Bedingungsschlüsselwerte in Ihrer Anfrage AWS bewertet wird.
| Richtlinienbedingung | Kontext anfordern | Ergebnis |
| --- | --- | --- |
| "StringEquals": {
"aws:PrincipalTag/department": [
"finance",
"hr",
"legal"
],
"aws:PrincipalTag/role": [
"audit",
"security"
]
},
"ArnLike": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:user/Ana",
"arn:aws:iam::222222222222:user/Mary"
]
} | aws:PrincipalTag/department: legal
aws:PrincipalTag/role: audit
aws:PrincipalArn:
arn:aws:iam::222222222222:user/Mary
| **Abgleich** |
| "StringEquals": {
"aws:PrincipalTag/department": [
"finance",
"hr",
"legal"
],
"aws:PrincipalTag/role": [
"audit",
"security"
]
},
"ArnLike": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:user/Ana",
"arn:aws:iam::222222222222:user/Mary"
]
} | aws:PrincipalTag/department: hr
aws:PrincipalTag/role: audit
aws:PrincipalArn:
arn:aws:iam::222222222222:user/Nikki
| **Kein Spiel** |
| "StringEquals": {
"aws:PrincipalTag/department": [
"finance",
"hr",
"legal"
],
"aws:PrincipalTag/role": [
"audit",
"security"
]
},
"ArnLike": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:user/Ana",
"arn:aws:iam::222222222222:user/Mary"
]
} | aws:PrincipalTag/department: hr
aws:PrincipalTag/role: payroll
aws:PrincipalArn:
arn:aws:iam::222222222222:user/Mary
| **Kein Spiel** |
| "StringEquals": {
"aws:PrincipalTag/department": [
"finance",
"hr",
"legal"
],
"aws:PrincipalTag/role": [
"audit",
"security"
]
},
"ArnLike": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:user/Ana",
"arn:aws:iam::222222222222:user/Mary"
]
} | Kein `aws:PrincipalTag/role` im Anfragekontext. aws:PrincipalTag/department: hr
aws:PrincipalArn:
arn:aws:iam::222222222222:user/Mary
| **Kein Spiel** |
| "StringEquals": {
"aws:PrincipalTag/department": [
"finance",
"hr",
"legal"
],
"aws:PrincipalTag/role": [
"audit",
"security"
]
},
"ArnLike": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:user/Ana",
"arn:aws:iam::222222222222:user/Mary"
]
} | Kein `aws:PrincipalTag` im Anfragekontext. aws:PrincipalArn:
arn:aws:iam::222222222222:user/Mary
| **Kein Spiel** |
## Auswertungslogik für negierte übereinstimmende Bedingungsoperatoren
Einige [Bedingungsoperatoren](reference_policies_elements_condition_operators.md) wie `StringNotEquals` oder `ArnNotLike` verwenden negierte Übereinstimmung, um die Kontext-Schlüssel-Wert-Paare in Ihrer Richtlinie mit den Kontext-Schlüssel-Wert-Paaren in einer Anfrage zu vergleichen. Wenn in einer Richtlinie mit negierten übereinstimmenden Bedingungsoperatoren mehrere Werte für einen einzelnen Kontextschlüssel angegeben werden, funktionieren die effektiven Berechtigungen wie ein logisches `NOR`. Bei der negierten Übereinstimmung gibt ein logisches `NOR` oder `NOT OR` nur dann wahr zurück, wenn alle Werte als falsch ausgewertet werden.
Das folgende Image veranschaulicht die Auswertungslogik für eine Bedingung mit mehreren Bedingungsoperatoren und Kontextschlüssel-Wert-Paaren. Das Image enthält einen negierten übereinstimmenden Bedingungsoperator für Bedingungsschlüssel 3.
![\[Bedingungsblock zur Erläuterung der Verwendung von AND und OR mit mehreren Kontextschlüsseln und -werten bei Anwendung eines negierten übereinstimmenden Bedingungsoperators\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/images/AccessPolicyLanguage_Condition_Block_AND_Negated_NOR_2.diagram.png)
Die folgende S3-Bucket-Richtlinie veranschaulicht beispielsweise, wie das vorherige Image in einer Richtlinie dargestellt wird. Der Bedingungsblock enthält die Bedingungsoperatoren `StringEquals` und `ArnNotLike` sowie die Kontextschlüssel `aws:PrincipalTag` und `aws:PrincipalArn`. Um den gewünschten `Allow`- oder `Deny`-Effekt aufzurufen, müssen alle Kontextschlüssel im Bedingungsblock zu „wahr“ aufgelöst werden. Der Benutzer, der die Anforderung stellt, muss beide Prinzipal-Tag-Schlüssel haben, *Abteilung* und *Rolle*, die einen der in der Richtlinie angegebenen Tag-Schlüsselwerte enthalten. Da der `ArnNotLike`-Bedingungsoperator eine negierte Übereinstimmung verwendet, darf der Prinzipal-ARN des Benutzers, der die Anfrage stellt, mit keinem der in der Richtlinie angegebenen `aws:PrincipalArn`-Werte übereinstimmen, um als wahr ausgewertet zu werden.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ExamplePolicy",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::222222222222:root"
},
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
"Condition": {
"StringEquals": {
"aws:PrincipalTag/department": [
"finance",
"hr",
"legal"
],
"aws:PrincipalTag/role": [
"audit",
"security"
]
},
"ArnNotLike": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:user/Ana",
"arn:aws:iam::222222222222:user/Mary"
]
}
}
}
]
}
```
------
Die folgende Tabelle zeigt, wie diese Richtlinie auf der Grundlage der Bedingungsschlüsselwerte in Ihrer Anfrage AWS bewertet wird.
| Richtlinienbedingung | Kontext anfordern | Ergebnis |
| --- | --- | --- |
| "StringEquals": {
"aws:PrincipalTag/department": [
"finance",
"hr",
"legal"
],
"aws:PrincipalTag/role": [
"audit",
"security"
]
},
"ArnNotLike": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:user/Ana",
"arn:aws:iam::222222222222:user/Mary"
]
} | aws:PrincipalTag/department: legal
aws:PrincipalTag/role: audit
aws:PrincipalArn:
arn:aws:iam::222222222222:user/Nikki
| **Abgleich** |
| "StringEquals": {
"aws:PrincipalTag/department": [
"finance",
"hr",
"legal"
],
"aws:PrincipalTag/role": [
"audit",
"security"
]
},
"ArnNotLike": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:user/Ana",
"arn:aws:iam::222222222222:user/Mary"
]
} | aws:PrincipalTag/department: hr
aws:PrincipalTag/role: audit
aws:PrincipalArn:
arn:aws:iam::222222222222:user/Mary
| **Kein Spiel** |
| "StringEquals": {
"aws:PrincipalTag/department": [
"finance",
"hr",
"legal"
],
"aws:PrincipalTag/role": [
"audit",
"security"
]
},
"ArnNotLike": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:user/Ana",
"arn:aws:iam::222222222222:user/Mary"
]
} | aws:PrincipalTag/department: hr
aws:PrincipalTag/role: payroll
aws:PrincipalArn:
arn:aws:iam::222222222222:user/Nikki
| **Kein Spiel** |
| "StringEquals": {
"aws:PrincipalTag/department": [
"finance",
"hr",
"legal"
],
"aws:PrincipalTag/role": [
"audit",
"security"
]
},
"ArnNotLike": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:user/Ana",
"arn:aws:iam::222222222222:user/Mary"
]
} | >Kein `aws:PrincipalTag/role` im Anfragekontext. aws:PrincipalTag/department: hr
aws:PrincipalArn:
arn:aws:iam::222222222222:user/Nikki
| **Kein Spiel** |
| "StringEquals": {
"aws:PrincipalTag/department": [
"finance",
"hr",
"legal"
],
"aws:PrincipalTag/role": [
"audit",
"security"
]
},
"ArnNotLike": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:user/Ana",
"arn:aws:iam::222222222222:user/Mary"
]
} | Kein `aws:PrincipalTag` im Anfragekontext. aws:PrincipalArn:
arn:aws:iam::222222222222:user/Nikki
| **Kein Spiel** |
# Einwertige im Vergleich zu mehrwertige Kontextschlüssel
Der Unterschied zwischen einwertigen und mehrwertigen Kontextschlüsseln liegt in der Anzahl der Werte im [Anfragekontext](intro-structure.md#intro-structure-request), nicht in der Anzahl der Werte in der Richtlinienbedingung.
+ *Einwertige* Bedingungskontextschlüssel haben höchstens einen Wert im Anforderungskontext. Wenn Sie beispielsweise Ressourcen taggen AWS, wird jedes Ressourcen-Tag als Schlüssel-Wert-Paar gespeichert. Da ein Ressourcen-Tagschlüssel nur einen einzigen Tagwert haben kann, ist [aws:ResourceTag/*tag-key*](reference_policies_condition-keys.md#condition-keys-resourcetag) ein einwertiger Kontextschlüssel. Verwenden Sie keinen Bedingungssatzoperator mit einem einwertigen Kontextschlüssel.
+ *Mehrwertige* Bedingungskontextschlüssel können im Anforderungskontext mehrere Werte enthalten. Wenn Sie beispielsweise Ressourcen taggen, können Sie mehrere Tag-Schlüssel-Wert-Paare in eine einzige Anfrage aufnehmen. AWS Daher handelt es sich bei [aws:TagKeys](reference_policies_condition-keys.md#condition-keys-tagkeys) um einen mehrwertigen Kontextschlüssel. Mehrwertige Kontextschlüssel erfordern einen Bedingungssatz-Operator.
Beispielsweise kann eine Anfrage von höchstens einem VPC-Endpunkt stammen, weshalb es sich bei [aws:SourceVpce](reference_policies_condition-keys.md#condition-keys-sourcevpce) um einen einwertigen Kontextschlüssel handelt. Da ein Service über mehr als einen Prinzipal verfügen kann, der zum Service gehört, handelt es sich bei [aws:PrincipalServiceNamesList](reference_policies_condition-keys.md#condition-keys-principalservicenameslist) um einen mehrwertigen Kontextschlüssel.
**Wichtig**
Der Unterschied zwischen einwertigen und mehrwertigen Kontextschlüsseln hängt von der Anzahl der Werte im Anforderungskontext ab, nicht von der Anzahl der Werte in der Richtlinienbedingung.
## Wichtige Punkte
+ Die *einwertigen* und *mehrwertigen* Klassifizierungen sind in der Beschreibung jedes Bedingungskontextschlüssels als *Werttyp* im [AWS Kontextschlüssel für globale Bedingungen](reference_policies_condition-keys.md)-Thema enthalten.
+ Mehrwertige Kontextschlüssel in der [Service Authorization-Referenz](https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html) verwenden das Präfix „`ArrayOf`“, gefolgt vom Typ des Bedingungsoperators (z. B. „`ArrayOfString`“ oder „`ArrayOfARN`“). Dies gibt an, dass die Anfrage mehrere Werte für einen Bedingungskontextschlüssel enthalten kann.
+ Sie können jeden verfügbaren einwertigen Kontextschlüssel als Richtlinienvariable verwenden, aber Sie können keinen mehrwertigen Kontextschlüssel als Richtlinienvariable verwenden. Weitere Informationen zu Richtlinienvariablen finden Sie unter [IAM-Richtlinienelemente: Variablen und Tags](reference_policies_variables.md).
+ Bei der Verwendung von Kontextschlüsseln, die Schlüssel-Wert-Paare enthalten, ist es wichtig zu beachten, dass es zwar mehrere Tag-Schlüssel-Werte geben kann, jeder `tag-key` jedoch nur einen Wert haben kann.
+ „[aws:PrincipalTag/*tag-key*](reference_policies_condition-keys.md#condition-keys-principaltag)“, „[aws:RequestTag/*tag-key*](reference_policies_condition-keys.md#condition-keys-requesttag)“ und „[aws:ResourceTag/*tag-key*](reference_policies_condition-keys.md#condition-keys-resourcetag)“ sind einwertige Kontextschlüssel.
+ „[aws:TagKeys](reference_policies_condition-keys.md#condition-keys-tagkeys)“ definiert, welche Tag-Schlüssel in einer Anfrage zulässig sind, jedoch nicht deren Werte. Da Sie mehrere Tag-Schlüssel-Wert-Paare in eine Anfrage einfügen können, ist „`aws:TagKeys`“ ein mehrwertiger Kontextschlüssel.
+ Mehrwertige Kontextschlüssel erfordern einen Bedingungssatz-Operator. Verwenden Sie die Bedingungssatz-Operatoren `ForAllValues` oder `ForAnyValue` nicht mit einwertigen Kontextschlüsseln. Die Verwendung von Bedingungssatzoperatoren mit einwertigen Kontextschlüsseln kann zu übermäßig zulässigen Richtlinien führen.
## Operatoren für mehrwertige Kontextschlüssel festlegen
Um Ihren Bedingungskontextschlüssel mit einem [Anforderungskontext](intro-structure.md#intro-structure-request)-Schlüssel mit mehreren Werten zu vergleichen, müssen Sie die Satzoperatoren `ForAllValues` oder `ForAnyValue` verwenden. Diese Satzoperatoren werden verwendet, um zwei Sätze von Werten zu vergleichen, z. B. den Satz von Tags in einer Anfrage und den Satz von Tags in einer Richtlinienbedingung.
Die `ForAllValues`- und `ForAnyValue`-Qualifikatoren fügen dem Bedingungsoperator eine Funktionalität zum Festlegen von Operationen hinzu, sodass Sie in einer Richtlinie Anfragekontextschlüssel mit mehreren Werten anhand mehrerer Bedingungsschlüsselwerte testen können. Wenn Sie außerdem einen mehrwertigen Zeichenfolgen-Kontextschlüssel mit einem Platzhalter oder einer Variablen in Ihre Richtlinie einschließen, müssen Sie auch den `StringLike`-[Bedingungsoperator](reference_policies_elements_condition_operators.md#Conditions_String) verwenden. Mehrere Bedingungsschlüsselwerte müssen wie ein [Array](reference_policies_grammar.md#policies-grammar-json) in Klammern eingeschlossen werden, zum Beispiel `"Key2":["Value2A", "Value2B"]`.
### ForAllValues
Der Qualifizierer „`ForAllValues`“ prüft, ob der Wert jedes Elements des Anfragekontexts mit dem nachfolgenden Bedingungsoperator übereinstimmt. Die Bedingung gibt `true` zurück, wenn jeder Kontextschlüsselwert in der Anfrage mit einem Kontextschlüsselwert in der Richtlinie übereinstimmt. Sie gibt ebenfalls `true` zurück, wenn keine Kontextschlüssel in der Anfrage vorhanden sind.
**Wichtig**
Seien Sie vorsichtig, wenn Sie `ForAllValues` mit einem `Allow`-Effekt verwenden, da dies übermäßig zulässig sein kann, wenn das Vorhandensein fehlender Kontextschlüssel im Anfragekontext unerwartet ist. Sie sollten immer den [`Null`](reference_policies_elements_condition_operators.md#Conditions_Null)-Bedingungsoperator mit einem `false`-Wert in Ihre Richtlinie einschließen, um zu prüfen, ob der Kontextschlüssel vorhanden ist und sein Wert nicht null ist. Ein Beispiel finden Sie unter [Zugriffssteuerung auf der Grundlage von Tag-Schlüsseln](access_tags.md#access_tags_control-tag-keys).
#### Beispiel für ForAllValues einen Set-Operator
Im folgenden Beispiel ForAllValues wird mit aws: verwendet, TagKeys um Benutzern das Löschen bestimmter Tags zu ermöglichen, die einer EC2-Instance zugewiesen wurden. Diese Richtlinie erlaubt Benutzern nur das Löschen der Tags `environment` und `cost-center`. Sie können diese einzeln oder zusammen löschen. Die Tag-Schlüssel in der Anfrage müssen exakt mit den in der Richtlinie angegebenen Schlüsseln übereinstimmen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:DeleteTags",
"Resource": "arn:aws:ec2:us-east-1:111122223333:instance/*",
"Condition": {
"ForAllValues:StringEquals": {
"aws:TagKeys": [
"environment",
"cost-center"
]
},
"Null": {
"aws:TagKeys": "false"
}
}
}
]
}
```
------
Die folgende Tabelle zeigt, wie diese Richtlinie auf der Grundlage der Bedingungsschlüsselwerte in Ihrer Anfrage AWS bewertet wird.
| Richtlinienbedingung | Kontext anfordern | Ergebnis |
| --- | --- | --- |
| "ForAllValues:StringEquals": {
"aws:TagKeys": [
"environment",
"cost-center"
]
},
"Null": {
"aws:TagKeys": "false"
} | aws:TagKeys:
– environment
| **Abgleich** |
| "ForAllValues:StringEquals": {
"aws:TagKeys": [
"environment",
"cost-center"
]
},
"Null": {
"aws:TagKeys": "false"
} | aws:TagKeys:
– cost-center
| **Spiel** |
| "ForAllValues:StringEquals": {
"aws:TagKeys": [
"environment",
"cost-center"
]
},
"Null": {
"aws:TagKeys": "false"
} | aws:TagKeys:
– environment
– cost-center
| **Spiel** |
| "ForAllValues:StringEquals": {
"aws:TagKeys": [
"environment",
"cost-center"
]
},
"Null": {
"aws:TagKeys": "false"
} | aws:TagKeys:
– environment
– dept
| **Kein Spiel** |
| "ForAllValues:StringEquals": {
"aws:TagKeys": [
"environment",
"cost-center"
]
},
"Null": {
"aws:TagKeys": "false"
} | Kein `aws:TagKeys` im Anfragekontext. | **Kein Spiel** |
Beachten Sie, dass im letzten Beispiel das Ergebnis „Keine Übereinstimmung“ lautet, da die Null-Bedingungsprüfung eine Übereinstimmung verhindert, wenn der Kontextschlüssel fehlt. Dies ist eine bewährte Methode, um zu permissive Richtlinien zu vermeiden.
### ForAnyValue
Der Qualifikator „`ForAnyValue`“ prüft, ob mindestens ein Element des Satzes von Bedingungskontextschlüssel-Werten mit mindestens einem Element des Satzes von Bedingungskontextschlüssel-Werten in Ihrer Richtlinie übereinstimmt. Die Bedingung gibt `true` zurück, wenn einer der Kontextschlüsselwerte in der Anfrage mit einem der Kontextschlüsselwerte in der Richtlinie übereinstimmt. Wenn kein übereinstimmender Kontextschlüssel vorhanden ist oder der Schlüssel nicht existiert, gibt die Bedingung „`false`“ zurück.
**Wichtig**
Bei Verwendung von `ForAnyValue` mit einem `Deny`-Effekt wird die Richtlinie als **Keine Übereinstimmung** ausgewertet, wenn der Kontextschlüssel in der Anfrage nicht vorhanden ist. Für ein konsistentes Verhalten fügen Sie Ihrer Richtlinie eine explizite [`Null`](reference_policies_elements_condition_operators.md#Conditions_Null)-Bedingungsprüfung hinzu, um zu überprüfen, ob der Kontextschlüssel existiert. Details hierzu finden Sie unter [Bedingungsoperator zur Prüfung der Existenz von Bedingungsoperatoren](reference_policies_elements_condition_operators.md#Conditions_Null).
#### Beispiel für ForAnyValue einen Set-Operator
Im folgenden Beispiel ForAnyValue wird mit aws: verwendet, TagKeys um Benutzern das Löschen bestimmter Tags zu ermöglichen, die einer EC2-Instance zugewiesen wurden. Diese Richtlinie erlaubt Benutzern das Löschen von Tags für eine Instance, wenn die in der Anfrage angegebenen Tag-Schlüssel `environment` oder `cost-center` enthalten. Die Anfrage kann zusätzliche Tag-Schlüssel enthalten, die nicht in der Richtlinie angegeben sind, muss aber mindestens einen der angegebenen Schlüssel enthalten, um die Bedingung zu erfüllen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:DeleteTags",
"Resource": "arn:aws:ec2:us-east-1:111122223333:instance/*",
"Condition": {
"ForAnyValue:StringEquals": {
"aws:TagKeys": [
"environment",
"cost-center"
]
}
}
}
]
}
```
------
Die folgende Tabelle zeigt, wie diese Richtlinie auf der Grundlage der Bedingungsschlüsselwerte in Ihrer Anfrage AWS bewertet wird.
| Richtlinienbedingung | Kontext anfordern | Ergebnis |
| --- | --- | --- |
| "ForAnyValue:StringEquals": {
"aws:TagKeys": [
"environment",
"cost-center"
]
} | aws:TagKeys:
– environment
| **Abgleich** |
| "ForAnyValue:StringEquals": {
"aws:TagKeys": [
"environment",
"cost-center"
]
} | aws:TagKeys:
– cost-center
| **Spiel** |
| "ForAnyValue:StringEquals": {
"aws:TagKeys": [
"environment",
"cost-center"
]
} | aws:TagKeys:
– environment
– cost-center
| **Spiel** |
| "ForAnyValue:StringEquals": {
"aws:TagKeys": [
"environment",
"cost-center"
]
} | aws:TagKeys:
– environment
– dept
| **Spiel** |
| "ForAnyValue:StringEquals": {
"aws:TagKeys": [
"environment",
"cost-center"
]
} | aws:TagKeys:
– dept
| **Kein Spiel** |
| "ForAnyValue:StringEquals": {
"aws:TagKeys": [
"environment",
"cost-center"
]
} | Kein `aws:TagKeys` im Anfragekontext. | **Kein Spiel** |
# Beispiele für Bedingungsrichtlinien
In IAM-Richtlinien können Sie mehrere Werte für einwertige und mehrwertige Kontextschlüssel für den Vergleich mit dem Anforderungskontext angeben. Die folgenden Richtlinienbeispiele veranschaulichen Richtlinienbedingungen mit mehreren Kontextschlüsseln und -werten.
**Anmerkung**
Wenn Sie eine Richtlinie zur Aufnahme in dieses Referenzhandbuch vorschlagen möchten, verwenden Sie die Schaltfläche **Feedback** unten auf der Seite. Beispiele für identitätsbasierte IAM-Richtlinien finden Sie unter [Beispiele für identitätsbasierte Richtlinien in IAM](access_policies_examples.md).
## Beispiele für Bedingungsrichtlinien: Einwertige Kontextschlüssel
+ Mehrere Bedingungsblöcke mit einwertigen Kontextschlüsseln. ([Dieses Beispiel ansehen](reference_policies_condition_examples-single-valued-context-keys.md#reference_policies_condition_examples-single-valued-context-keys-1).)
+ Ein Bedingungsblock mit mehreren einwertigen Kontextschlüsseln und -werten. ([Dieses Beispiel ansehen](reference_policies_condition_examples-single-valued-context-keys.md#reference_policies_condition_examples-single-valued-context-keys-2).)
## Beispiele für Bedingungsrichtlinien: Mehrwertige Kontextschlüssel
+ Richtlinie mit Bedingungssatzoperator `ForAllValues` verweigern. ([Dieses Beispiel ansehen](reference_policies_condition_examples-multi-valued-context-keys.md#reference_policies_condition_examples-multi-valued-context-keys-1).)
+ Richtlinie mit Bedingungssatzoperator `ForAnyValue` verweigern. ([Dieses Beispiel ansehen](reference_policies_condition_examples-multi-valued-context-keys.md#reference_policies_condition_examples-multi-valued-context-keys-2).)
# Schlüsselbeispiele für mehrwertige Kontexte
Die folgenden Richtlinienbeispiele veranschaulichen, wie Richtlinienbedingungen mit mehrwertigen Kontextschlüsseln erstellt werden.
## Beispiel: Richtlinie ablehnen mit Bedingungssatzoperator ForAllValues
Das folgende Beispiel zeigt, die Verwendung einer identitätsbasierten Richtlinie zum Verweigern der Verwendung von IAM-Tagging-Aktionen, wenn bestimmte Tag-Schlüsselpräfixe in der Anfrage enthalten sind. Die Werte für [`aws:TagKeys`](reference_policies_condition-keys.md#condition-keys-tagkeys) enthalten einen Platzhalter (\$1) für eine teilweise übereinstimmende Zeichenfolge. Die Richtlinie enthält den `ForAllValues`-Satz-Operator mit Kontextschlüssel `aws:TagKeys`, da der Anforderungskontextschlüssel mehrere Werte enthalten kann. Damit der Kontextschlüssel `aws:TagKeys` übereinstimmt, muss jeder Wert im Anfragekontext mit mindestens einem Wert in der Richtlinie übereinstimmen.
Der `ForAllValues`-Satz-Operator gibt auch „true“ zurück, wenn die Anfrage keine Kontextschlüssel enthält.
Sie können verhindern, dass fehlende Kontextschlüssel oder Kontextschlüssel mit leeren Werten als „true“ ausgewertet werden, indem Sie den `Null`-Bedingungsoperator mit dem Wert `false` in Ihre Richtlinie einschließen, um zu überprüfen, ob der Kontextschlüssel in der Anforderung vorhanden ist und sein Wert nicht null ist. Weitere Informationen finden Sie unter [Bedingungsoperator zur Prüfung der Existenz von Bedingungsoperatoren](reference_policies_elements_condition_operators.md#Conditions_Null).
**Wichtig**
Diese Richtlinie lässt keine Aktionen zu. Verwenden Sie diese Richtlinie in Kombination mit anderen Richtlinien, die bestimmte Aktionen zulassen.
**Example Einen einzelnen Richtlinienbedingungswert für einen mehrwertigen Kontextschlüssel verweigern**
Im folgenden Beispiel lehnt die Richtlinie Anfragen ab, bei denen die Werte für `aws:TagKeys` in der Anfrage das Präfix **key1** nicht enthalten. Der Anfragekontext kann mehrere Werte haben, aber aufgrund des -Bedingungssatzoperators müssen alle Tag-Schlüsselwerte im Anforderungskontext mit dem Präfix **key1** beginnen.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyRestrictedTags",
"Effect": "Deny",
"Action": [
"iam:Tag*",
"iam:UnTag*"
],
"Resource": [
"*"
],
"Condition": {
"ForAllValues:StringNotLike": {
"aws:TagKeys": "key1*"
}
}
}
]
}
```
Die folgende Tabelle zeigt, wie diese Richtlinie auf der Grundlage der Bedingungsschlüsselwerte in Ihrer Anfrage AWS bewertet wird. Bei einer Deny-Anweisung wird „Übereinstimmung“ verweigert und „Keine Übereinstimmung“ nicht verweigert, sodass dies durch eine andere Anweisung zugelassen werden kann.
| Richtlinienbedingung | Kontext anfordern | Ergebnis |
| --- | --- | --- |
| "ForAllValues:StringNotLike": {
"aws:TagKeys": "key1*"
} | aws:TagKeys:
– key1:legal
| **Keine Übereinstimmung** Kann durch eine andere Anweisung zugelassen werden. |
| "ForAllValues:StringNotLike": {
"aws:TagKeys": "key1*"
} | aws:TagKeys:
– key1:hr
– key1:personnel
| **Kein Spiel** Kann durch eine andere Anweisung zugelassen werden. |
| "ForAllValues:StringNotLike": {
"aws:TagKeys": "key1*"
} | aws:TagKeys:
– key2:audit
| **Spiel** |
| "ForAllValues:StringNotLike": {
"aws:TagKeys": "key1*"
} | Kein `aws:TagKeys` im Anforderungskontext. | **Spiel** |
**Example Mehrere Richtlinienbedingungswerte für einen mehrwertigen Kontextschlüssel verweigern**
Im folgenden Beispiel lehnt die Richtlinie Anfragen ab, bei denen die Werte für `aws:TagKeys` in der Anfrage das Präfix **key1** oder **key2** nicht enthalten. Der Anfragekontext kann mehrere Werte haben, aber aufgrund des `ForAllValues`-Bedingungssatzoperators müssen alle Tag-Schlüsselwerte im Anforderungskontext mit dem Präfix **key1** oder **key2** beginnen.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyRestrictedTags",
"Effect": "Deny",
"Action": [
"iam:Tag*",
"iam:UnTag*"
],
"Resource": [
"*"
],
"Condition": {
"ForAllValues:StringNotLike": {
"aws:TagKeys": [
"key1*",
"key2*"
]
}
}
}
]
}
```
Die folgende Tabelle zeigt, wie diese Richtlinie auf der Grundlage der Bedingungsschlüsselwerte in Ihrer Anfrage AWS bewertet wird. Bei einer Deny-Anweisung wird „Übereinstimmung“ verweigert und „Keine Übereinstimmung“ nicht verweigert, sodass dies durch eine andere Anweisung zugelassen werden kann.
| Richtlinienbedingung | Kontext anfordern | Ergebnis |
| --- | --- | --- |
| "ForAllValues:StringNotLike": {
"aws:TagKeys": [
"key1*",
"key2*"
]
} | aws:TagKeys:
– key1:legal
| **Keine Übereinstimmung** Kann durch eine andere Anweisung zugelassen werden. |
| "ForAllValues:StringNotLike": {
"aws:TagKeys": [
"key1*",
"key2*"
]
} | aws:TagKeys:
– key1:hr
– key1:personnel
| **Kein Spiel** Kann durch eine andere Anweisung zugelassen werden. |
| "ForAllValues:StringNotLike": {
"aws:TagKeys": [
"key1*",
"key2*"
]
} | aws:TagKeys:
– key1:hr
– key2:audit
| **Kein Spiel** Kann durch eine andere Anweisung zugelassen werden. |
| "ForAllValues:StringNotLike": {
"aws:TagKeys": [
"key1*",
"key2*"
]
} | aws:TagKeys:
– key3:legal
| **Spiel** |
| "ForAllValues:StringNotLike": {
"aws:TagKeys": [
"key1*",
"key2*"
]
} | Kein `aws:TagKeys` im Anforderungskontext. | **Spiel** |
## Beispiel: Richtlinie mit Bedingungssatzoperator ablehnen ForAnyValue
Das folgende Beispiel für eine identitätsbasierte Richtlinie verweigert die Erstellung von Snapshots von EC2-Instance-Volumes, wenn Snapshots mit einem der in der Richtlinie angegebenen Tag-Schlüssel, `environment` oder `webserver`, gekennzeichnet sind. Die Richtlinie enthält den `ForAnyValue`-Satz-Operator mit Kontextschlüssel `aws:TagKeys`, da der Anforderungskontextschlüssel mehrere Werte enthalten kann. Wenn Ihre Tagging-Anfrage einen der in der Richtlinie angegebenen Tag-Schlüsselwerte enthält, gibt der `aws:TagKeys`-Kontextschlüssel den Wert wahr zurück und ruft den Effekt der Ablehnungsrichtlinie auf.
**Wichtig**
Diese Richtlinie lässt keine Aktionen zu. Verwenden Sie diese Richtlinie in Kombination mit anderen Richtlinien, die bestimmte Aktionen zulassen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"ec2:CreateSnapshot",
"ec2:CreateSnapshots"
],
"Resource": "arn:aws:ec2:us-west-2::snapshot/*",
"Condition": {
"ForAnyValue:StringEquals": {
"aws:TagKeys": "webserver"
}
}
}
]
}
```
------
Die folgende Tabelle zeigt, wie diese Richtlinie auf der Grundlage der Bedingungsschlüsselwerte in Ihrer Anfrage AWS bewertet wird. Bei einer Deny-Anweisung wird „Übereinstimmung“ verweigert und „Keine Übereinstimmung“ nicht verweigert, sodass dies durch eine andere Anweisung zugelassen werden kann.
| Richtlinienbedingung | Kontext anfordern | Ergebnis |
| --- | --- | --- |
| "ForAnyValue:StringEquals": {
"aws:TagKeys": "webserver"
} | aws:TagKeys:
– webserver
| **Abgleich** |
| "ForAnyValue:StringEquals": {
"aws:TagKeys": "webserver"
} | aws:TagKeys:
– environment
– webserver
– test
| **Spiel** |
| "ForAnyValue:StringEquals": {
"aws:TagKeys": "webserver"
} | aws:TagKeys:
– environment
– test
| **Kein Spiel** Kann durch eine andere Anweisung zugelassen werden. |
| "ForAnyValue:StringEquals": {
"aws:TagKeys": "webserver"
} | Kein `aws:TagKeys` im Anforderungskontext. | **Kein Spiel** Kann durch eine andere Anweisung zugelassen werden. |
# Beispiele für Richtlinien mit einwertigen Kontextschlüsseln
Die folgenden Richtlinienbeispiele veranschaulichen, wie Richtlinienbedingungen mit einwertigen Kontextschlüsseln erstellt werden.
## Beispiel: Mehrere Bedingungsblöcke mit einwertigen Kontextschlüsseln
Wenn ein Bedingungsblock mehrere Bedingungen mit jeweils einem einzelnen Kontextschlüssel enthält, müssen alle Kontextschlüssel zu „wahr“ aufgelöst werden, damit der gewünschte `Allow`- oder `Deny`-Effekt aufgerufen wird. Wenn Sie negierte übereinstimmende Bedingungsoperatoren verwenden, wird die Auswertungslogik des Bedingungswerts umgedreht.
Das folgende Beispiel ermöglicht es Benutzern, EC2-Volumes zu erstellen und während der Volume-Erstellung Tags auf die Volumes anzuwenden. Der Anforderungskontext muss einen Wert für den Kontextschlüssel `aws:RequestTag/project` enthalten. Der Wert für den Kontextschlüssel `aws:ResourceTag/environment` kann ein beliebiger Wert außer „Produktion“ sein.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:CreateVolume",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "ec2:CreateTags",
"Resource": "arn:aws:ec2:us-east-1:123456789012:volume/*",
"Condition": {
"StringLike": {
"aws:RequestTag/project": "*"
}
}
},
{
"Effect": "Allow",
"Action": "ec2:CreateTags",
"Resource": "arn:aws:ec2:us-east-1:123456789012:*/*",
"Condition": {
"StringNotEquals": {
"aws:ResourceTag/environment": "production"
}
}
}
]
}
```
------
Der Anforderungskontext muss einen Projekt-Tag-Wert enthalten und kann nicht für eine Produktionsressource zum Aufrufen des `Allow`-Effekts erstellt werden. Das folgende EC2-Volume wurde erfolgreich erstellt, da der Projektname `Feature3` mit einem `QA`-Ressourcen-Tag lautet.
```
aws ec2 create-volume \
--availability-zone us-east-1a \
--volume-type gp2 \
--size 80 \
--tag-specifications 'ResourceType=volume,Tags=[{Key=project,Value=Feature3},{Key=environment,Value=QA}]'
```
## Beispiel: Ein Bedingungsblock mit mehreren einwertigen Kontextschlüsseln und -werten
Wenn ein Bedingungsblock mehrere Kontextschlüssel enthält und jeder Kontextschlüssel über mehrere Werte verfügt, muss jeder Kontextschlüssel zu „wahr“ aufgelöst werden, damit mindestens ein Schlüsselwert für den gewünschten `Allow`- oder `Deny`-Effekt aufgerufen wird. Wenn Sie negierte übereinstimmende Bedingungsoperatoren verwenden, wird die Auswertungslogik des Wertes des Bedingungsschlüssels umgedreht.
Mit dem folgenden Beispiel können Benutzer Aufgaben in Clustern in Amazon Elastic Container Service starten und ausführen.
+ Der Anforderungskontext muss `production` **ODER** `prod-backup` für den `aws:RequestTag/environment`-Kontextschlüssel **UND** enthalten.
+ Der `ecs:cluster`-Kontextschlüssel stellt sicher, dass Aufgaben entweder auf den `default1` **ODER** `default2`-ARN-ECS-Clustern ausgeführt werden.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecs:RunTask",
"ecs:StartTask"
],
"Resource": [
"*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/environment": [
"production",
"prod-backup"
]
},
"ArnEquals": {
"ecs:cluster": [
"arn:aws:ecs:us-east-1:111122223333:cluster/default1",
"arn:aws:ecs:us-east-1:111122223333:cluster/default2"
]
}
}
}
]
}
```
------
Die folgende Tabelle zeigt, wie diese Richtlinie auf der Grundlage der Bedingungsschlüsselwerte in Ihrer Anfrage AWS bewertet wird.
| Richtlinienbedingung | Kontext anfordern | Ergebnis |
| --- | --- | --- |
| "StringEquals": {
"aws:RequestTag/environment": [
"production",
"prod-backup"
]
},
"ArnEquals": {
"ecs:cluster": [
"arn:aws:ecs:us-east-1:111122223333:cluster/default1",
"arn:aws:ecs:us-east-1:111122223333:cluster/default2"
]
} | aws:RequestTag: environment:production
ecs:cluster:
arn:aws:ecs:us-east-1:111122223333:cluster/default1
| Match |
| "StringEquals": {
"aws:RequestTag/environment": [
"production",
"prod-backup"
]
},
"ArnEquals": {
"ecs:cluster": [
"arn:aws:ecs:us-east-1:111122223333:cluster/default1",
"arn:aws:ecs:us-east-1:111122223333:cluster/default2"
]
} | aws:RequestTag: environment:prod-backup
ecs:cluster:
arn:aws:ecs:us-east-1:111122223333:cluster/default2
| Match |
| "StringEquals": {
"aws:RequestTag/environment": [
"production",
"prod-backup"
]
},
"ArnEquals": {
"ecs:cluster": [
"arn:aws:ecs:us-east-1:111122223333:cluster/default1",
"arn:aws:ecs:us-east-1:111122223333:cluster/default2"
]
} | aws:RequestTag: webserver:production
ecs:cluster:
arn:aws:ecs:us-east-1:111122223333:cluster/default2
| Keine Übereinstimmung |
| "StringEquals": {
"aws:RequestTag/environment": [
"production",
"prod-backup"
]
},
"ArnEquals": {
"ecs:cluster": [
"arn:aws:ecs:us-east-1:111122223333:cluster/default1",
"arn:aws:ecs:us-east-1:111122223333:cluster/default2"
]
} | Kein `aws:RequestTag` im Anfragekontext. ecs:cluster
arn:aws:ecs:us-east-1:111122223333:cluster/default2
| Keine Übereinstimmung |
# IAM-Richtlinienelemente: Variablen und Tags
Verwenden Sie AWS Identity and Access Management (IAM) -Richtlinienvariablen als Platzhalter, wenn Sie beim Schreiben der Richtlinie den genauen Wert einer Ressource oder eines Bedingungsschlüssels nicht kennen.
**Anmerkung**
Wenn eine Variable AWS nicht aufgelöst werden kann, kann dies dazu führen, dass die gesamte Anweisung ungültig ist. Wenn Sie beispielsweise die Variable `aws:TokenIssueTime` verwenden, wird diese nur dann in einen Wert aufgelöst, wenn der Anforderer für die Authentifizierung temporäre Anmeldeinformationen (eine IAM-Rolle) verwendet hat. Um zu verhindern, dass Variablen ungültige Anweisungen verursachen, verwenden Sie den[... IfExists Bedingungsoperator.](reference_policies_elements_condition_operators.md#Conditions_IfExists)
**Topics**
+ [Einführung](#policy-vars-intro)
+ [Verwenden von Variablen in Richtlinien](#policy-vars-using-variables)
+ [Tags als Richtlinienvariablen](#policy-vars-tags)
+ [Wo Richtlinienvariablen verwendet werden können](#policy-vars-wheretouse)
+ [Richtlinienvariablen ohne Wert](#policy-vars-no-value)
+ [Anforderungsinformationen, die Sie für Richtlinienvariablen verwenden können](#policy-vars-infotouse)
+ [Festlegen von Standardwerten](#policy-vars-default-values)
+ [Weitere Informationen](#policy-vars-formoreinfo)
## Einführung
In IAM-Richtlinien ermöglichen Ihnen viele Aktionen, einen Namen für die speziellen Ressourcen bereitzustellen, für die Sie den Zugriff steuern möchten. Die folgende Richtlinie erlaubt Benutzern beispielsweise das Auflisten, Lesen und Schreiben von Objekten im S3-Bucket `amzn-s3-demo-bucket` für `marketing`-Projekte.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:ListBucket"],
"Resource": ["arn:aws:s3:::amzn-s3-demo-bucket"],
"Condition": {"StringLike": {"s3:prefix": ["marketing/*"]}}
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": ["arn:aws:s3:::amzn-s3-demo-bucket/marketing/*"]
}
]
}
```
------
In manchen Fällen kennen Sie vielleicht den genauen Namen der Ressource nicht, wenn Sie die Richtlinie schreiben. Sie können die Richtlinie so verallgemeinern, dass sie für viele Benutzer funktioniert, ohne dass eine eindeutige Kopie der Richtlinie für jeden Benutzer erstellt werden muss. Anstatt für jeden Benutzer eine eigene Richtlinie zu erstellen, empfehlen wir Ihnen, eine einzelne Gruppenrichtlinie zu erstellen, die für jeden Benutzer in dieser Gruppe funktioniert.
## Verwenden von Variablen in Richtlinien
Sie können dynamische Werte innerhalb von Richtlinien definieren, indem Sie *Richtlinienvariablen* verwenden, die Platzhalter in einer Richtlinie festlegen.
Variablen werden mit einem **`$`**-Präfix gefolgt von einem Paar geschweifter Klammern (**`{ }`**) markiert, die den Variablennamen des Werts aus der Anfrage enthalten.
Wenn die Richtlinie ausgewertet wird, werden die Richtlinienvariablen mit Werten aus den bedingten Kontextschlüsseln ersetzt, die in der Anforderung übermittelt wurden. Variablen können in [identitätsbasierten Richtlinien, Ressourcenrichtlinien, Dienstverwaltungsrichtlinien, Sitzungsrichtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) und [VPC-Endpunkt-Richtlinien](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html) verwendet werden. Identitätsbasierte Richtlinien, die als Berechtigungsgrenzen verwendet werden, unterstützen auch Richtlinienvariablen.
Globale Bedingungskontextschlüssel können als Variablen in diensteübergreifenden AWS Anfragen verwendet werden. Servicespezifische Bedingungsschlüssel können bei der Interaktion mit AWS -Ressourcen auch als Variablen verwendet werden, sind jedoch nur verfügbar, wenn Anfragen an Ressourcen gestellt werden, die sie unterstützen. Eine Liste der für jeden AWS Dienst und jede Ressource verfügbaren Kontextschlüssel finden Sie in der [https://docs.aws.amazon.com/service-authorization/latest/reference/reference.html](https://docs.aws.amazon.com/service-authorization/latest/reference/reference.html). Unter bestimmten Umständen können Sie globale Bedingungskontextschlüssel nicht mit einem Wert füllen. Weitere Informationen zu den einzelnen Schlüsseln finden Sie unter [AWS -Kontextschlüssel für globale Bedingungen](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html).
**Wichtig**
Bei Schlüsselnamen wird nicht zwischen Groß- und Kleinschreibung unterschieden. Beispiel: `aws:CurrentTime` ist gleichbedeutend mit `AWS:currenttime`.
Sie können jeden einwertigen Bedingungsschlüssel als Variable verwenden. Sie können einen mehrwertigen Bedingungsschlüssel nicht als Variable verwenden.
Das folgende Beispiel zeigt eine Richtlinie für eine IAM-Rolle oder einen IAM-Benutzer, die einen bestimmten Ressourcennamen durch eine Richtlinienvariable ersetzt. Sie können diese Richtlinie wiederverwenden, indem Sie den `aws:PrincipalTag`-Bedingungsschlüssel nutzen. Bei der Auswertung dieser Richtlinie lässt `${aws:PrincipalTag/team}` die Aktionen nur zu, wenn der Bucket-Name mit einem Teamnamen aus dem `team`-Prinzipal-Tag endet.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:ListBucket"],
"Resource": ["arn:aws:s3:::amzn-s3-demo-bucket"],
"Condition": {"StringLike": {"s3:prefix": ["${aws:PrincipalTag/team}/*"]}}
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": ["arn:aws:s3:::amzn-s3-demo-bucket/${aws:PrincipalTag/team}/*"]
}
]
}
```
------
Die Variable wird mithilfe des Präfix `$`, gefolgt von einem Paar geschweifter Klammern (`{ }`), gekennzeichnet. Innerhalb der `${ }`-Zeichen können Sie den Namen des Wertes aus der Anforderung einfügen, den Sie in der Richtlinie verwenden möchten. Die Werte, die Sie verwenden können, werden weiter unten auf dieser Seite besprochen.
Einzelheiten zu diesem globalen Bedingungsschlüssel finden Sie unter [aws:PrincipalTag/*tag-key*](reference_policies_condition-keys.md#condition-keys-principaltag) in der Liste der globalen Bedingungsschlüssel.
**Anmerkung**
Zur Verwendung der Richtlinienvariablen müssen Sie das `Version`-Element in eine Anweisung einfügen und die Version muss auf eine Version gesetzt werden, die Richtlinienvariablen unterstützt. Variablen wurden in Version `2012-10-17` eingeführt. Frühere Versionen der Richtliniensprache unterstützen Richtlinienvariablen nicht. Wenn Sie das `Version`-Element nicht einfügen und nicht auf ein geeignetes Versionsdatum festlegen, werden Variablen wie `${aws:username}` als tatsächliche Zeichenfolgen in der Richtlinie behandelt.
Das Richtlinienelement `Version` unterscheidet sich von einer Richtlinienversion. Das Richtlinienelement `Version` wird innerhalb einer Richtlinie verwendet und gibt die Version der Richtliniensprache an. Eine Richtlinienversion hingegen wird erstellt, wenn Sie in IAM eine kundenverwaltete Richtlinie bearbeiten. Die vorhandene Richtlinie wird von der geänderten Richtlinie nicht überschrieben. IAM erstellt stattdessen eine neue Version der verwalteten Richtlinie. Weitere Informationen zum Richtlinienelement `Version` finden Sie unter [IAM-JSON-Richtlinienelemente: Version](reference_policies_elements_version.md). Weitere Informationen zu den Richtlinienversionen finden Sie unter [Versioning von IAM-Richtlinien](access_policies_managed-versioning.md).
Eine Richtlinie, die es einem Prinzipal ermöglicht, Objekte aus dem /David-Pfad eines S3-Buckets abzurufen, sieht wie folgt aus:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/David/*"
]
}
]
}
```
------
Wenn diese Richtlinie dem Benutzer `David` zugewiesen ist, erhält dieser Benutzer Objekte aus seinem eigenen S3-Bucket. Sie müssten jedoch für jeden Benutzer eine eigene Richtlinie erstellen, die den Namen des Benutzers enthält. Anschließend müssten Sie die einzelnen Richtlinien an die jeweiligen Benutzer anfügen.
Durch die Verwendung einer Richtlinienvariablen können Sie Richtlinien erstellen, die wiederverwendet werden können. Mit der folgenden Richtlinie kann ein Benutzer Objekte aus einem Amazon-S3-Bucket abrufen, wenn der Tag-Schlüsselwert für `aws:PrincipalTag` mit dem in der Anfrage übergebenen Tag-Schlüssel-Wert `owner` übereinstimmt.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Sid": "AllowUnlessOwnedBySomeoneElse",
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": ["*"],
"Condition": {
"StringEquals": {
"s3:ExistingObjectTag/owner": "${aws:PrincipalTag/owner}"
}
}
}
]
}
```
------
Wenn Sie eine Richtlinienvariable anstelle eines solchen Benutzers verwenden, müssen Sie nicht für jeden einzelnen Benutzer eine eigene Richtlinie erstellen. Im folgenden Beispiel ist die Richtlinie einer IAM-Rolle zugeordnet, die von Produktmanagern mithilfe temporärer Sicherheitsanmeldeinformationen übernommen wird. Wenn ein Benutzer eine Anfrage zum Hinzufügen eines Amazon-S3-Objekts stellt, ersetzt IAM den `dept`-Tag-Wert aus der aktuellen Anfrage durch die `${aws:PrincipalTag}`-Variable und wertet die Richtlinie aus.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowOnlyDeptS3Prefix",
"Effect": "Allow",
"Action": [
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/${aws:PrincipalTag/dept}/*"
]
}
]
}
```
------
## Tags als Richtlinienvariablen
In einigen AWS Diensten können Sie Ressourcen, die von diesen Diensten erstellt wurden, Ihre eigenen benutzerdefinierten Attribute anhängen. Sie können beispielsweise Tags auf Amazon S3-Buckets oder IAM-Benutzer anwenden. Diese Tags sind Schlüssel-Wert-Paare. Sie definieren den Tag-Schlüsselnamen und den Wert, der diesem Schlüsselnamen zugeordnet ist. Beispielsweise können Sie ein Tag mit einem **department**-Schlüssel und einem **Human Resources**-Wert erstellen. Weitere Informationen zum Markieren von IAM-Entitäten finden Sie unter [Tags für AWS Identity and Access Management Ressourcen](id_tags.md). Informationen über das Markieren von Ressourcen, die von anderen AWS -Services erstellt wurden, finden Sie in der Dokumentation des jeweiligen Services. Informationen zur Verwendung des Tag-Editors finden Sie unter [Arbeiten mit dem Tag-Editor](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/tag-editor.html) im *AWS-Managementkonsole -Leitfaden*.
Sie können IAM-Ressourcen markieren, um das Entdecken, Organisieren und Nachverfolgen Ihrer IAM-Ressourcen zu vereinfachen. Sie können IAM-Identitäten auch markieren, um den Zugriff auf Ressourcen oder auf die Markierung zu kontrollieren. Weitere Informationen über die Verwendung von Tags zur Zugriffskontrolle finden Sie unter [Steuerung des Zugriffs auf und für IAM-Benutzer und IAM-Rollen mithilfe von Tags](access_iam-tags.md).
## Wo Richtlinienvariablen verwendet werden können
Sie können Richtlinienvariablen im `Resource`-Element und in Zeichenfolgenvergleichen im `Condition`-Element verwenden.
### Ressourcen-Element
Sie können eine Richtlinienvariable im `Resource`-Element verwenden, jedoch nur im Ressourcenbereich des ARN. Dieser Teil des ARN erscheint nach dem 5. Doppelpunkt (:). Sie können keine Variable verwenden, um Teile des ARN vor dem 5. Doppelpunkt zu ersetzen, z. B. den Service oder das Konto. Weitere Informationen zum ARN-Format finden Sie unter [ICH BIN ARNs](reference_identifiers.md#identifiers-arns).
Um einen Teil eines ARN durch einen Tag-Wert zu ersetzen, umgeben Sie das Präfix und den Schlüsselnamen mit `${ }`. Das folgende Resource-Element bezieht sich beispielsweise nur auf einen Bucket, dessen Name mit dem Wert im Abteilungs-Tag des anfordernden Benutzers übereinstimmt.
`"Resource": ["arn:aws::s3:::amzn-s3-demo-bucket/${aws:PrincipalTag/department}"]`
Viele AWS Ressourcen verwenden ARNs diese, die einen vom Benutzer erstellten Namen enthalten. Die folgende IAM-Richtlinie stellt sicher, dass nur vorgesehene Benutzer mit übereinstimmenden access-project-, access-project- und access-environment-Tag-Werten ihre Ressourcen ändern können. Darüber hinaus können sie durch die Verwendung von [\$1-Platzhalterübereinstimmungen](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_resource.html) benutzerdefinierte Suffixe für Ressourcennamen zulassen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowAccessBasedOnArnMatching",
"Effect": "Allow",
"Action": [
"sns:CreateTopic",
"sns:DeleteTopic"],
"Resource": ["arn:aws:sns:*:*:${aws:PrincipalTag/access-project}-${aws:PrincipalTag/access-application}-${aws:PrincipalTag/access-environment}-*"
]
}
]
}
```
------
### Condition-Element
Sie können eine Richtlinienvariable für `Condition`-Werte in jeder Bedingung verwenden, die die String-Operatoren oder die ARN-Operatoren beinhaltet. String-Operatoren beinhalten `StringEquals`, `StringLike` und `StringNotLike`. ARN-Operatoren beinhalten `ArnEquals` und `ArnLike`. Sie können eine Richtlinienvariable nicht mit anderen Operatoren wie `Numeric`, `Date`, `Boolean`, `Binary`, `IP Address` oder `Null` verwenden. Weitere Hinweise zu Bedingungsoperatoren finden Sie unter [IAM-JSON-Richtlinienelemente: Bedingungsoperatoren](reference_policies_elements_condition_operators.md).
Beim Referenzieren eines Tags in einem `Condition`-Elementausdruck verwenden Sie das entsprechende Präfix und den Schlüsselnamen als Bedingungsschlüssel. Verwenden Sie dann den Wert, den Sie testen möchten, im Bedingungswert.
Das folgende Richtlinienbeispiel ermöglicht Benutzern beispielsweise vollständigen Zugriff, jedoch nur, wenn dem Benutzer das Tag `costCenter` zugeordnet ist. Das Tag muss auch einen Wert von entweder `12345` oder `67890` haben. Wenn das Tag keinen Wert oder einen anderen Wert hat, schlägt die Anforderung fehl.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:*user*"
],
"Resource": "*",
"Condition": {
"StringLike": {
"iam:ResourceTag/costCenter": [ "12345", "67890" ]
}
}
}
]
}
```
------
## Richtlinienvariablen ohne Wert
Wenn Richtlinienvariablen auf einen Bedingungskontextschlüssel verweisen, der keinen Wert hat oder in einem Autorisierungskontext für eine Anforderung nicht vorhanden ist, ist der Wert effektiv Null. Es gibt keinen gleichen oder ähnlichen Wert. Bedingungskontextschlüssel sind im Autorisierungskontext möglicherweise nicht vorhanden, wenn:
+ Sie servicespezifische Bedingungskontextschlüssel in Anfragen an Ressourcen verwenden, die diesen Bedingungsschlüssel nicht unterstützen.
+ Tags für IAM-Prinzipale, Sitzungen, Ressourcen oder Anfragen nicht vorhanden sind.
+ Andere Umstände, wie sie für jeden globalen Bedingungskontextschlüssel in [AWS Kontextschlüssel für globale Bedingungen](reference_policies_condition-keys.md) aufgeführt sind.
Wenn Sie eine Variable ohne Wert im Bedingungselement einer IAM-Richtlinie verwenden, und ein [IAM-JSON-Richtlinienelemente: Bedingungsoperatoren](reference_policies_elements_condition_operators.md) wie `StringEquals` oder `StringLike` nicht übereinstimmen, wird die Richtlinienanweisung nicht wirksam.
Invertierte Bedingungsoperatoren wie `StringNotEquals` oder `StringNotLike` entsprechen einem Nullwert oder stimmen mit ihm überein, da der Wert des Bedingungsschlüssels, anhand dessen sie testen, nicht dem tatsächlichen Nullwert entspricht oder diesem entspricht.
Im folgenden Beispiel muss `aws:principaltag/Team` gleich `s3:ExistingObjectTag/Team` sein, um den Zugriff zu gewähren. Der Zugriff wird ausdrücklich verweigert, wenn `aws:principaltag/Team` nicht festgelegt ist. Wenn eine Variable, die im Autorisierungskontext keinen Wert hat, als Teil des `Resource`- oder `NotResource`-Elements einer Richtlinie verwendet wird, entspricht die Ressource, die eine Richtlinienvariable ohne Wert enthält, keiner Ressource.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
"Condition": {
"StringNotEquals": {
"s3:ExistingObjectTag/Team": "${aws:PrincipalTag/Team}"
}
}
}
]
}
```
------
## Anforderungsinformationen, die Sie für Richtlinienvariablen verwenden können
Sie können das `Condition`-Element einer JSON-Richtlinie verwenden, um Schlüssel im [Anforderungskontext](reference_policies_evaluation-logic_policy-eval-reqcontext.md) mit Schlüsselwerten zu vergleichen, die Sie in Ihrer Richtlinie angeben. Wenn Sie eine Richtlinienvariable verwenden, wird die Variable in Ihrer Richtlinie durch einen Wert aus dem Anforderungskontextschlüssel AWS ersetzt.
### Auftraggeber-Schlüsselwerte
Die Werte für `aws:username`, `aws:userid` und `aws:PrincipalType` hängen davon ab, welche Art von Auftraggeber die Anforderung ausgelöst hat. Die Anforderung kann beispielsweise über die Anmeldeinformationen eines IAM-Benutzers, einer IAM-Rolle oder des Root-Benutzer des AWS-Kontos s erfolgen. In der folgenden Tabelle sind die Werte für diese Schlüssel für verschiedene Auftraggebertypen .
****
| Auftraggeber | `aws:username` | `aws:userid` | `aws:PrincipalType` |
| --- | --- | --- | --- |
| Root-Benutzer des AWS-Kontos | (Nicht vorhanden) | AWS-Konto ID | Account |
| IAM-Benutzer | IAM-user-name | [Eindeutige ID](reference_identifiers.md#identifiers-unique-ids) | User |
| AWS STS föderierter Benutzerprinzipal | (Nicht vorhanden) | account:caller-specified-name | FederatedUser |
| OIDC-Verbundprinzipal Informationen über Richtlinienschlüssel, die verfügbar sind, wenn Sie den Web-Identitätsverbund verwenden, finden Sie unter [Verfügbare Schlüssel für den AWS OIDC-Verbund](reference_policies_iam-condition-keys.md#condition-keys-wif). | (Nicht vorhanden) | *role-id*:*caller-specified-role-name* wobei `role-id` sich die [eindeutige ID der Rolle](reference_identifiers.md#identifiers-unique-ids) caller-specified-role-name befindet und die durch den an die AssumeRoleWithWebIdentity Anforderung übergebenen [RoleSessionName Parameter](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AssumeRole.html#API_AssumeRoleWithWebIdentity_RequestParameters) angegeben wird. | AssumedRole |
| SAML-Verbundprinzipal Informationen über Richtlinienschlüssel, die verfügbar sind, wenn Sie den SAML-Verbund verwenden, finden Sie unter [Eindeutige Identifizierung von Benutzern im SAML-basierten Verbund](id_roles_providers_saml.md#CreatingSAML-userid). | (Nicht vorhanden) | *role-id*:*caller-specified-role-name* wo `role-id` ist die [eindeutige ID der Rolle und die](reference_identifiers.md#identifiers-unique-ids) caller-specified-role-name wird durch das Attribute-Element spezifiziert, wobei das [Name-Attribut auf https://aws.amazon.com/SAML/ RoleSessionName attributes/](id_roles_providers_create_saml_assertions.md) gesetzt ist. | AssumedRole |
| Angenommene Rolle | (Nicht vorhanden) | *role-id*:*caller-specified-role-name* wobei die [eindeutige ID der Rolle `role-id` steht und die](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids) durch den an die Anfrage übergebenen [RoleSessionName Parameter](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html#API_AssumeRole_RequestParameters) angegeben caller-specified-role-name wird. AssumeRole | AssumedRole |
| Eine einer Amazon EC2-Instance zugeordnete Rolle | (Nicht vorhanden) | *role-id*:*ec2-instance-id* Hierbei ist `role-id` [die eindeutige ID der Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids) und „es2-instance-id“ der [eindeutige Bezeichner der EC2-Instance](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstances.html). | AssumedRole |
| Anonymer Anrufer (nur Amazon SQS, Amazon SNS und Amazon S3) | (Nicht vorhanden) | anonymous | Anonymous |
Beachten Sie für die Elemente in dieser Tabelle Folgendes:
+ *Nicht vorhanden* bedeutet, dass der Wert nicht in den aktuellen Anforderungsinformationen vorhanden ist und jeder Versuch, ihn zuzuordnen, fehlschlägt und dafür sorgt, dass die Anforderung abgelehnt wird.
+ *role-id*ist ein eindeutiger Bezeichner, der jeder Rolle bei der Erstellung zugewiesen wurde. Sie können die Rollen-ID mit dem AWS CLI folgenden Befehl anzeigen: `aws iam get-role --role-name rolename`
+ *caller-specified-name*und *caller-specified-role-name* sind Namen, die vom aufrufenden Prozess (z. B. einer Anwendung oder einem Dienst) beim Abrufen temporärer Anmeldeinformationen übergeben werden.
+ *ec2-instance-id*ist ein Wert, der der Instance beim Start zugewiesen wurde und auf der **Instance-Seite** der Amazon EC2 EC2-Konsole angezeigt wird. Sie können die Instance-ID auch anzeigen, indem Sie den AWS CLI folgenden Befehl ausführen: `aws ec2 describe-instances`
### In Anforderungen für Verbundprinzipale verfügbare Informationen
Verbundprinzipale sind Benutzer, die über ein anderes System als IAM authentifiziert werden. Beispielsweise könnte ein Unternehmen eine Anwendung für den internen Gebrauch haben, die Anrufe tätigt an AWS. Es könnte unpraktisch sein, jedem Unternehmensbenutzer, der die Anwendung verwendet, eine IAM-Identität zu geben. Das Unternehmen kann stattdessen eine Proxy-Anwendung (Middle-Tier) verwenden, die eine einzige IAM-Identität aufweist, oder das Unternehmen könnte einen SAML-Identitätsanbieter nutzen. Die Proxy-Anwendung oder der SAML-Identitätsanbieter authentifiziert einzelne Benutzer, die das Unternehmensnetzwerk verwenden. Eine Proxy-Anwendung kann dann ihre IAM-Identität verwenden, um temporäre Sicherheitsanmeldeinformationen für einzelne Benutzer abzurufen. Ein SAML-IdP kann tatsächlich Identitätsinformationen gegen AWS temporäre Sicherheitsanmeldeinformationen austauschen. Die temporären Anmeldeinformationen können dann für den Zugriff AWS auf Ressourcen verwendet werden.
Ebenso können Sie eine Anwendung für ein mobiles Gerät erstellen, in dem die Anwendung auf AWS -Ressourcen zugreifen muss. In diesem Fall können Sie den *OIDC-Verbund* verwenden, wobei die Anwendung den Benutzer mithilfe eines bekannten Identitätsanbieters authentifiziert, wie Login mit Amazon, Amazon Cognito, Facebook oder Google. Die Anwendung kann dann die Authentifizierungsinformationen des Benutzers von diesen Anbietern verwenden, um temporäre Sicherheitsanmeldeinformationen für den Zugriff auf AWS -Ressourcen abzurufen.
Die empfohlene Methode zur Verwendung des OIDC-Verbunds besteht darin, Amazon Cognito und das Mobilgerät zu nutzen. AWS SDKs Weitere Informationen finden Sie hier:
+ [Amazon-Cognito-Benutzerhandbuch](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-identity.html)
+ [Gängige Szenarien für temporäre Anmeldeinformationen](id_credentials_temp.md#sts-introduction)
### Sonderzeichen
Es gibt einige spezielle vordefinierte Richtlinienvariablen, die feste Werte haben. Diese bieten Ihnen die Möglichkeit, Zeichen darzustellen, die sonst eine besondere Bedeutung haben. Wenn diese Sonderzeichen Teil der Zeichenfolge sind, die Sie versuchen zusammenzubringen, und Sie sie einfach einfügen, würden sie fehlinterpretiert werden. Beispielsweise würde das Einfügen eines Sternchens (\$1) in die Zeichenfolge als Platzhalter interpretiert werden, der für andere Zeichen steht, und nicht tatsächlich als \$1. In solchen Fällen können Sie die folgenden vordefinierten Richtlinienvariablen verwenden:
+ **\$1\$1\$1\$1** – zu verwenden, wenn Sie ein \$1 (Sternchen) benötigen
+ **\$1\$1?\$1** – zu verwenden, wenn Sie ein ? (Fragezeichen) benötigen
+ **\$1\$1\$1\$1** – zu verwenden, wenn Sie ein \$1 (Dollarzeichen) benötigen
Diese vordefinierten Richtlinienvariablen können in einer beliebigen Zeichenfolge verwendet werden, in der Sie reguläre Richtlinien nutzen können.
## Festlegen von Standardwerten
Um einer Variablen einen Standardwert hinzuzufügen, umgeben Sie den Standardwert mit einfachen Anführungszeichen (`' '`), und trennen Sie den Variablentext und den Standardwert durch Komma und Leerzeichen (`, `) enthalten.
Zum Beispiel, wenn ein Prinzipal mit `team=yellow` gekennzeichnet ist, können sie auf `ExampleCorp's`-Amazon-S3-Bucket namens `amzn-s3-demo-bucket-yellow` zugreifen. Eine Richtlinie mit dieser Ressource ermöglicht es Teammitgliedern, auf ihren Team-Bucket zuzugreifen, nicht jedoch auf die anderer Teams. Für Benutzer ohne Team-Tags wird der Standardwert von `company-wide` für den Bucket-Namen eingestellt. Diese Benutzer können nur auf `amzn-s3-demo-bucket-company-wide`Bucket zugreifen, wo umfassende Informationen anzeigt werden können, z. B. Anweisungen für den Beitritt zu einem Team.
```
"Resource":"arn:aws:s3:::amzn-s3-demo-bucket-${aws:PrincipalTag/team, 'company-wide'}"
```
## Weitere Informationen
Weitere Informationen zu Richtlinien finden Sie in den folgenden Themen:
+ [Richtlinien und Berechtigungen in AWS Identity and Access Management](access_policies.md)
+ [Beispiele für identitätsbasierte Richtlinien in IAM](access_policies_examples.md)
+ [Referenz zum IAM-JSON-Richtlinienelement](reference_policies_elements.md)
+ [Auswertungslogik für Richtlinien](reference_policies_evaluation-logic.md)
+ [OIDC-Verbund](id_roles_providers_oidc.md)
# IAM-JSON-Richtlinienelemente: Unterstützte Datentypen
In diesem Abschnitt werden die Datentypen aufgeführt, die beim Festlegen von Werten in den JSON-Richtlinien unterstützt werden. Die Richtliniensprache unterstützt nicht alle Datentypen für jedes Richtlinienelement. Weitere Informationen zum jeweiligen Element finden Sie in den vorherigen Abschnitten.
+ Zeichenfolgen
+ Zahlen (Ganzzahlen oder Gleitkommazahlen)
+ Boolesch
+ Null
+ Listen
+ Zuordnungen
+ Strukturen (dies sind lediglich verschachtelte Zuordnungen)
In der folgenden Tabelle wird jeder Datentyp der entsprechenden Serialisierung zugeordnet. Beachten Sie, dass alle Richtlinien UTF-8-kodiert sein müssen. Wenn Sie weitere Informationen zu den JSON-Datentypen erhalten möchten, rufen Sie die Website [RFC 4627](https://datatracker.ietf.org/doc/html/rfc4627) auf.
****
| Typ | JSON |
| --- | --- |
| Zeichenfolge | Zeichenfolge |
| Ganzzahl | Zahl |
| Gleitkommazahl | Zahl |
| Boolesch | wahr falsch |
| Null | Null |
| Date | Zeichenfolge, die dem [W3C-Profil von ISO 8601](http://www.w3.org/TR/NOTE-datetime) entspricht |
| IpAddress | Zeichenfolge, die [RFC 4632](https://datatracker.ietf.org/doc/html/rfc4632) erfüllt |
| Auflisten | Array |
| Objekt | Objekt |
# 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": "*"
}
]
}
```
------
# Grammatik der IAM-JSON-Richtliniensprache
Auf dieser Seite wird eine formelle Grammatik der Sprache vorgestellt, die zum Erstellen von JSON-Richtlinien in IAM verwendet wird. Sie müssen diese Grammatik beherrschen, um Richtlinien erstellen und validieren zu können.
Beispielrichtlinien finden Sie in den folgenden Themen:
+ [Richtlinien und Berechtigungen in AWS Identity and Access Management](access_policies.md)
+ [Beispiele für identitätsbasierte Richtlinien in IAM](access_policies_examples.md)
+ [Beispielrichtlinien für die Arbeit in der Amazon EC2 EC2-Konsole](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-policies-ec2-console.html) und [Beispielrichtlinien für die Arbeit mit der AWS CLI, der Amazon EC2 EC2-CLI oder einem AWS SDK](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ExamplePolicies_EC2.html) im *Amazon EC2 EC2-Benutzerhandbuch*.
+ [Beispiele für Bucket-Richtlinien](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies.html) und [Nutzer-Richtlinien](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-policies-s3.html) finden Sie im *Benutzerhandbuch für Amazon Simple Storage Service*.
Beispiele für Richtlinien, die in anderen AWS Diensten verwendet werden, finden Sie in der Dokumentation zu diesen Diensten.
**Topics**
+ [Die Richtliniensprache und JSON](#policies-grammar-json)
+ [In dieser Grammatik verwendete Konventionen](#policies-grammar-conventions)
+ [Grammatik](#policies-grammar-bnf)
+ [Hinweise zur Richtliniengrammatik](#policies-grammar-notes)
## Die Richtliniensprache und JSON
Richtlinien werden in JSON ausgedrückt. Wenn Sie eine JSON-Richtlinie erstellen oder bearbeiten, kann IAM eine Richtlinienvalidierung durchführen, um Ihnen beim Erstellen einer effektiven Richtlinie zu helfen. IAM identifiziert JSON-Syntaxfehler, während IAM Access Analyzer zusätzliche Richtlinienüberprüfungen mit Empfehlungen zur weiteren Verfeinerung Ihrer Richtlinien bietet. Weitere Informationen zur Richtlinienvalidierung finden Sie unter [IAM-Richtlinien-Validierung](access_policies_policy-validator.md). Weitere Informationen zu IAM Access Analyzer Richtlinienvalidierungen und umsetzbaren Empfehlungen finden Sie unter [IAM Access Analyzer-Richtlinienvalidierung](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html).
Dieses Dokument enthält keine umfassende Beschreibung gültiger JSON. Nachfolgend finden Sie jedoch einige grundlegende JSON-Regeln:
+ Leerzeichen zwischen einzelnen Einheiten sind zulässig.
+ Werte müssen in Anführungszeichen stehen. Anführungszeichen sind für nummerische und boolesche Werte optional.
+ Viele Elemente wie z. B. `action_string_list` und `resource_string_list` können ein JSON-Array als Wert enthalten. Arrays können einen oder mehrere Werte enthalten. Wenn ein Array mehrere Werte enthält, steht es in eckigen Klammern (`[` und `]`), die einzelnen Werte sind durch Komma voneinander getrennt. Beispiel:
`"Action" : ["ec2:Describe*","ec2:List*"]`
+ Die grundlegenden JSON-Datentypen (Boolescher Wert, Zahl und Zeichenfolge) sind in [RFC 7159](https://datatracker.ietf.org/doc/html/rfc7159) definiert.
## In dieser Grammatik verwendete Konventionen
In dieser Grammatik werden folgende Konventionen verwendet:
+ Die folgenden Zeichen sind JSON-Token und *sind* in Richtlinien enthalten:
`{ } [ ] " , :`
+ Die folgenden Zeichen sind Sonderzeichen in der Grammatik und sind *nicht* in Richtlinien enthalten:
`= < > ( ) |`
+ Wenn für ein Element mehrere Werte zulässig sind, wird dies durch wiederholte Werte, ein Komma als Trennzeichen und eine Ellipse (`...`) dargestellt. Beispiele:
`[, , ...]`
` = { , , ... }`
Wenn mehrere Werte zulässig sind, ist es auch zulässig, nur einen Wert anzugeben. Wenn nur ein Wert angegeben wird, muss das anschließende Komma weggelassen werden. Wenn ein Element ein Array (durch [ und ] gekennzeichnet) enthalten kann, das jedoch nur einen Wert enthält, können die Klammern weggelassen werden. Beispiele:
`"Action": []`
`"Action": `
+ Ein Fragezeichen (`?`) nach einem Element gibt an, dass das Element optional ist. Beispiel:
<`version_block?>`
Weitere Informationen zu optionalen Elementen können Sie den Hinweisen nach jedem Grammatikelement entnehmen.
+ Eine vertikale Linie (`|`) zwischen Elemente gibt Alternativen an. Runde Klammern geben den Umfang der Alternativen an. Beispiel:
`("Principal" | "NotPrincipal")`
+ Elemente, bei denen es sich um Zeichenfolgen handelt, müssen von doppelten Anführungszeichen (`"`) umschlossen sein. Beispiel:
` = "Version" : ("2008-10-17" | "2012-10-17" )`
Weitere Hinweise finden Sie unter [Hinweise zur Richtliniengrammatik](#policies-grammar-notes) in der Grammatikauflistung.
## Grammatik
Die folgende Liste beschreibt die Grammatik der Richtliniensprache. Die in der Liste verwendeten Konventionen wurden im vorherigen Abschnitt beschrieben. Zusätzliche Informationen finden Sie in den nachfolgenden Hinweisen.
**Anmerkung**
Diese Grammatik beschreibt Richtlinien der Versionen `2008-10-17 ` und `2012-10-17 `. Das Richtlinienelement `Version` unterscheidet sich von einer Richtlinienversion. Das Richtlinienelement `Version` wird innerhalb einer Richtlinie verwendet und gibt die Version der Richtliniensprache an. Andererseits wird eine Richtlinienversion erstellt, wenn Sie in IAM eine benutzerdefinierte, verwaltete Richtlinie bearbeiten. Die vorhandene Richtlinie wird von der geänderten Richtlinie nicht überschrieben. IAM erstellt stattdessen eine neue Version der verwalteten Richtlinie. Weitere Informationen zum Richtlinienelement `Version` finden Sie unter [IAM-JSON-Richtlinienelemente: Version](reference_policies_elements_version.md). Weitere Informationen zu den Richtlinienversionen finden Sie unter [Versioning von IAM-Richtlinien](access_policies_managed-versioning.md).
```
policy = {
,
,
}
= "Version" : ("2008-10-17" | "2012-10-17" )
= "Id" :
= "Statement" : [ , , ... ]
= {
,
,
,
,
,
}
= "Sid" :
= "Effect" : ("Allow" | "Deny")
= ("Principal" | "NotPrincipal") : ("*" | )
= { , , ... }
= ("AWS" | "Federated" | "Service" | "CanonicalUser") :
[, , ...]
= ("Action" | "NotAction") :
("*" | | [, , ...])
= ("Resource" | "NotResource") :
: ("*" | | [, , ...])
= "Condition" : { }
= {
: { : },
: { : }, ...
}
= [, , ...]
= ( | | )
```
## Hinweise zur Richtliniengrammatik
+ Eine einzelne Richtlinie kann eine Reihe von Anweisungen enthalten.
+ Die maximale Größe für Richtlinien beträgt je nach der Entität, der die Richtlinie zugeordnet ist, zwischen 2.048 und 10.240 Zeichen. Weitere Informationen finden Sie unter [IAM und Kontingente AWS STS](reference_iam-quotas.md). Bei der Berechnung der Richtliniengröße werden Leerzeichen nicht mitgezählt.
+ Einzelne Elemente dürfen nicht mehrere Instances desselben Schlüssels enthalten. Sie können beispielsweise den Block `Effect` nicht zweimal innerhalb derselben Anweisung verwenden.
+ Blöcke können in beliebiger Reihenfolge angegeben werden. `version_block` kann beispielsweise in einer Richtlinie von `id_block` gefolgt werden. Ebenso können die Blöcke `effect_block`, `principal_block` und `action_block` in einer Anweisung in beliebiger Reihenfolge angegeben werden.
+ Der Block `id_block` ist in ressourcenbasierten Richtlinien optional. Er darf *nicht* in identitätsbasierten Richtlinien enthalten sein.
+ Das Element `principal_block` muss in ressourcenbasierten Richtlinien (z. B. in Amazon S3-Bucket-Richtlinien) sowie in Vertrauensrichtlinien für IAM-Rollen enthalten sein. Er darf *nicht* in identitätsbasierten Richtlinien enthalten sein.
+ Das `principal_map`-Element in Amazon S3-Bucket-Richtlinien kann die `CanonicalUser`-ID enthalten. Der Großtteil der ressourcenbasierten Richtlinien unterstützt dieses Mapping nicht. Weitere Informationen zur Verwendung der kanonischen Benutzer-ID in einer Bucket-Richtlinie finden Sie unter [Angeben eines Auftraggebers in einer Richtlinie](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-bucket-user-policy-specifying-principal-intro.html) im *Benutzerhandbuch für Amazon Simple Storage Service*.
+ Für Zeichenfolgewerte (`policy_id_string`, `sid_string`, `principal_id_string`, `action_string`, `resource_string`, `condition_type_string`, `condition_key_string` sowie die Zeichenfolgenversion in `condition_value`) kann es jeweils eigene Mindest- und Höchstlängen, bestimmte zulässige Werte oder ein erforderliches internes Format geben.
### Hinweise zu Zeichenfolgewerten
In diesem Abschnitt werden Zeichenfolgewerte, die in verschiedenen Elementen von Richtlinien verwendet werden, detailliert beschrieben.
**`action_string`**
Besteht aus einem Service-Namespace, einem Doppelpunkt und dem Namen einer Aktion. Aktionsnamen können Platzhalterzeichen enthalten. Beispiele:
```
"Action":"ec2:StartInstances"
"Action":[
"ec2:StartInstances",
"ec2:StopInstances"
]
"Action":"cloudformation:*"
"Action":"*"
"Action":[
"s3:Get*",
"s3:List*"
]
```
**`policy_id_string`**
Bietet eine Möglichkeit, Informationen zur Richtlinie im Ganzen bereitzustellen. Einige Services wie Amazon SQS und Amazon SNS verwenden das reservierte Element `Id`. Sofern policy\$1id\$1string nicht von einzelnen Services anderweitig beschränkt ist, sind Leerzeichen zulässig. Für einige Services muss dieser Wert innerhalb eines AWS -Kontos eindeutig sein.
Der Block `id_block` ist in ressourcenbasierten Richtlinien, nicht jedoch in identitätsbasierten Richtlinien zulässig.
Es gibt keine Längenbeschränkung, allerdings trägt diese Zeichenfolge zur Gesamtlänge der Richtlinie bei, die wiederum beschränkt ist.
```
"Id":"Admin_Policy"
"Id":"cd3ad3d9-2776-4ef1-a904-4c229d1642ee"
```
**`sid_string`**
Bietet eine Möglichkeit, Informationen zu einzelnen Anweisungen bereitzustellen. In IAM-Richtlinien sind für den Wert `Sid` nur die grundlegenden alphanummerischen Zeichen (A-Z, a-z und 0-9). Für andere AWS -Services, die ressourcenbasierte Richtlinien unterstützen, können für den Wert `Sid` andere Beschränkungen gelten. Bei einigen Diensten muss dieser Wert beispielsweise innerhalb eines eindeutig sein AWS-Konto, und bei einigen Diensten sind zusätzliche Zeichen wie Leerzeichen im `Sid` Wert zulässig.
```
"Sid":"1"
"Sid": "ThisStatementProvidesPermissionsForConsoleAccess"
```
**`principal_id_string`**
Bietet eine Möglichkeit, einen Principal mithilfe des [*Amazon-Ressourcennamens* (ARN)](reference_identifiers.md#identifiers-arns) des IAM-Benutzers AWS-Konto, der IAM-Rolle, des Verbundbenutzers oder des Benutzers mit angenommener Rolle anzugeben. Für eine AWS-Konto können Sie auch die Kurzform `AWS:accountnumber` anstelle des vollständigen ARN verwenden. Informationen zu sämtlichen Optionen einschließlich AWS -Services, übernommenen Rollen usw. finden Sie unter [So legen Sie einen Prinzipal fest](reference_policies_elements_principal.md#Principal_specifying).
Sie können das Sternchen (\$1) nur verwenden, um "alle/anonym" festzulegen. Es ist nicht möglich, damit einen Teil eines Namens oder ARN anzugeben.
**`resource_string`**
Besteht in den meisten Fällen aus einem [Amazon-Ressourcennamen](reference_identifiers.md#identifiers-arns) (ARN). Sie können Platzhalter (\$1 und ?) im Ressourcenteil des ARN verwenden. Weitere Hinweise zur Verwendung von Platzhaltern in finden Sie ARNs unter[Verwenden von Platzhaltern in Pfaden](reference-arns.md#arns-paths-wildcards).
Wenn Sie in einer identitätsbasierten Richtlinie einen unvollständigen ARN (eines mit weniger als den sechs Standardfeldern) angeben, wird der ARN AWS automatisch vervollständigt, indem Platzhalterzeichen (\$1) zu allen fehlenden Feldern hinzugefügt werden. Die Angabe `arn:aws:sqs` entspricht beispielsweise`arn:aws:sqs:*:*:*`, was Zugriff auf alle Amazon Amazon SQS SQS-Ressourcen in allen Regionen und Konten gewährt. Sitzungsrichtlinien, die an AWS STS AssumeRole, übergeben werdenAssumeRoleWithWebIdentity, und AssumeRoleWith SAML-Anfragen unterstützen jedoch keine unvollständigen Anfragen. ARNs Die Verwendung eines unvollständigen ARN in einer Sitzungsrichtlinie führt zu einem `MalformedPolicyDocumentException` Fehler.
```
"Resource":"arn:aws:iam::123456789012:user/Bob"
"Resource":"arn:aws:s3:::amzn-s3-demo-bucket/*"
```
**`condition_type_string`**
Gibt den zu testenden Bedingungstyp an, z. B. `StringEquals`, `StringLike`, `NumericLessThan`, `DateGreaterThanEquals`, `Bool`, `BinaryEquals`, `IpAddress`, `ArnEquals` usw. Eine vollständige Liste der Bedingungstypen finden Sie unter [IAM-JSON-Richtlinienelemente: Bedingungsoperatoren](reference_policies_elements_condition_operators.md).
```
"Condition": {
"NumericLessThanEquals": {
"s3:max-keys": "10"
}
}
"Condition": {
"Bool": {
"aws:SecureTransport": "true"
}
}
"Condition": {
"StringEquals": {
"s3:x-amz-server-side-encryption": "AES256"
}
}
```
**`condition_key_string`**
Identifiziert den Bedingungsschlüssel, dessen Wert getestet wird, um festzustellen, ob die Bedingung erfüllt ist. AWS definiert eine Reihe von Bedingungsschlüsseln, die in allen AWS Diensten verfügbar sind`aws:PrincipalType`, einschließlich`aws:SecureTransport`, und`aws:userid`.
Eine Liste der AWS Bedingungsschlüssel finden Sie unter[AWS Kontextschlüssel für globale Bedingungen](reference_policies_condition-keys.md). Informationen zu Bedingungsschlüsseln, die für einen Service spezifisch sind, finden Sie in der Dokumentation des betreffenden Service, wie z. B. in den folgenden Abschnitten:
+ [Angeben von Bedingungen in einer Richtlinie](https://docs.aws.amazon.com/AmazonS3/latest/userguide/amazon-s3-policy-keys.html) im *Benutzerhandbuch für Amazon Simple Storage Service*
+ [IAM-Richtlinien für Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-policies-for-amazon-ec2.html) im *Amazon-EC2-Benutzerhandbuch*.
```
"Condition":{
"Bool": {
"aws:SecureTransport": "true"
}
}
"Condition": {
"StringNotEquals": {
"s3:x-amz-server-side-encryption": "AES256"
}
}
"Condition": {
"StringEquals": {
"aws:ResourceTag/purpose": "test"
}
}
```
**`condition_value_string`**
Identifiziert den Wert von „condition\$1key\$1string“, der bestimmt, ob die Bedingung erfüllt ist. Eine vollständige Liste der gültigen Werte für einen Bedingungstyp finden Sie unter [IAM-JSON-Richtlinienelemente: Bedingungsoperatoren](reference_policies_elements_condition_operators.md).
```
"Condition":{
"ForAnyValue:StringEquals": {
"dynamodb:Attributes": [
"ID",
"PostDateTime"
]
}
}
```
# AWS verwaltete Richtlinien für Jobfunktionen
Es wird empfohlen, Richtlinien zu verwenden, die [die geringsten Rechte gewähren](best-practices.md#grant-least-privilege), d. h. nur die für die Durchführung einer Aufgabe erforderlichen Berechtigungen zu gewähren. Die sicherste Methode, die geringste Berechtigung zu erteilen, besteht darin, eine benutzerdefinierte Richtlinie mit nur den Berechtigungen zu schreiben, die Ihr Team benötigt. Sie müssen einen Prozess erstellen, damit Ihr Team bei Bedarf weitere Berechtigungen anfordern kann. Es erfordert Zeit und Fachwissen, um [von Kunden verwaltete IAM-Richtlinien zu erstellen](access_policies_create-console.md), die Ihrem Team nur die benötigten Berechtigungen bieten.
Um mit dem Hinzufügen von Berechtigungen zu Ihren IAM-Identitäten (Benutzern, Benutzergruppen und Rollen) zu beginnen, können Sie Folgendes verwenden. [AWS verwaltete Richtlinien](access_policies_managed-vs-inline.md#aws-managed-policies) AWS verwaltete Richtlinien decken allgemeine Anwendungsfälle ab und sind in Ihrem verfügbar. AWS-Konto AWS verwaltete Richtlinien gewähren keine Berechtigungen mit den geringsten Rechten. Sie müssen das Sicherheitsrisiko berücksichtigen, wenn Sie Ihren Auftraggeber mehr Berechtigungen gewähren, als sie für ihre Arbeit benötigen.
Sie können AWS verwaltete Richtlinien, einschließlich Jobfunktionen, an jede IAM-Identität anhängen. Um zu den Berechtigungen mit den geringsten Rechten zu wechseln, können Sie Access Analyzer ausführen AWS Identity and Access Management , um Prinzipale mit AWS verwalteten Richtlinien zu überwachen. Nachdem Sie erfahren haben, welche Berechtigungen sie verwenden, können Sie eine benutzerdefinierte Richtlinie schreiben oder eine Richtlinie mit nur den erforderlichen Berechtigungen für Ihr Team erstellen. Das ist weniger sicher, bietet aber mehr Flexibilität, wenn Sie erfahren, wie Ihr Team die Daten verwendet AWS.
AWS Die verwalteten Richtlinien für berufliche Funktionen sind so konzipiert, dass sie sich eng an den üblichen Aufgabenbereichen in der IT-Branche orientieren. Sie können mithilfe dieser Richtlinien ganz einfach die Berechtigungen erteilen, die Sie benötigen, um die Aufgaben, die von jemanden in einer bestimmten Auftragsfunktionen erwartet werden, auszuführen. Diese Richtlinien führen Berechtigungen für viele Services in einer einzigen Richtlinie zusammen, mit der sich leichter arbeiten lässt als mit auf vielen Richtlinien verteilten Berechtigungen.
**Verwenden von Rollen zum Kombinieren von Services**
In einigen Richtlinien werden IAM-Dienstrollen verwendet, damit Sie die Funktionen anderer AWS Dienste nutzen können. Diese Richtlinien gewähren Zugriff auf`iam:passrole`, was es einem Benutzer mit der Richtlinie ermöglicht, eine Rolle an einen AWS Dienst zu übergeben. Diese Rolle delegiert IAM-Berechtigungen an den AWS Dienst, damit dieser Aktionen in Ihrem Namen ausführen kann.
Erstellen Sie die Rollen entsprechend Ihren Anforderungen. Die Netzwerkadministrator-Richtlinie ermöglicht es beispielsweise einem Benutzer mit der Richtlinie, eine Rolle mit dem Namen "flow-logs-vpc" an den CloudWatch Amazon-Service zu übergeben. CloudWatch verwendet diese Rolle, um den vom Benutzer VPCs erstellten IP-Verkehr zu protokollieren und zu erfassen.
Damit die bewährten Sicherheitsmethoden befolgt werden, enthalten die Richtlinien für Auftragsfunktionen Filter, die die Namen der gültigen Rollen, die übergeben werden können, begrenzen. So vermeiden Sie, dass unnötige Berechtigungen zugewiesen werden. Wenn Ihre Benutzer die optionalen Servicerollen benötigen, müssen Sie eine Rolle erstellen, die der in der Richtlinie angegebenen Namenskonvention entspricht. Sie gewähren dann Berechtigungen für die Rolle. Sobald dies erledigt ist, kann der Benutzer den Service so konfigurieren, dass er die Rolle verwendet, wobei beliebige Berechtigungen der Rolle gewährt werden.
In den folgenden Abschnitten ist der Name jeder Richtlinie einen Link zur Richtliniendetailseite in der AWS-Managementkonsole. Dort können Sie das Richtliniendokument einsehen und die Berechtigungen überprüfen, die darin gewährt werden.
## Auftragsfunktion
**AWS Name der verwalteten Richtlinie: [AdministratorAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AdministratorAccess)**
**Anwendungsfall:** Dieser Benutzer hat vollständigen Zugriff und kann Berechtigungen an jeden Service und jede Ressource in AWS delegieren.
**Richtlinienaktualisierungen:** Diese Richtlinie wird AWS beibehalten und aktualisiert. Eine Historie der Änderungen für diese Richtlinie finden Sie in der IAM-Konsole, und wählen Sie dann die **Versionen der Datenlinien**-Registerkarte. Weitere Informationen zu Auftragsfunktions-Richtlinienaktualisierungen finden Sie unter [Aktualisierungen der AWS verwalteten Richtlinien für Jobfunktionen](#security-iam-awsmanpol-jobfunction-updates).
**Beschreibung der Richtlinie:** Diese Richtlinie gewährt alle Aktionen für alle AWS Dienste und für alle Ressourcen im Konto. Weitere Informationen zur verwalteten Richtlinie finden Sie [AdministratorAccess](https://docs.aws.amazon.com//aws-managed-policy/latest/reference/AdministratorAccess.html)im *Referenzhandbuch für AWS verwaltete Richtlinien*.
**Anmerkung**
Bevor ein IAM-Benutzer oder eine IAM-Rolle mit den in dieser Richtlinie festgelegten Berechtigungen auf die AWS Fakturierung und Kostenmanagement Konsole zugreifen kann, müssen Sie zuerst den IAM-Benutzer- und Rollenzugriff aktivieren. Folgen Sie dazu den Anweisungen unter [Zugriff auf die Fakturierungskonsole gewähren](getting-started-account-iam.md), um den Zugriff auf die Fakturierungskonsole zu delegieren.
## Fakturierung Auftragsfunktion
**AWS [Name der verwalteten Richtlinie: Abrechnung](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/job-function/Billing)**
**Anwendungsfall:** Dieser Benutzer muss Abrechnungsinformationen anzeigen und Zahlungen einrichten und autorisieren können. Der Benutzer kann die für den gesamten AWS Service anfallenden Kosten überwachen.
**Aktualisierungen der Richtlinien:** AWS Pflegt und aktualisiert diese Richtlinie. Eine Historie der Änderungen für diese Richtlinie finden Sie in der IAM-Konsole, und wählen Sie dann die **Versionen der Datenlinien**-Registerkarte. Weitere Informationen zu Auftragsfunktions-Richtlinienaktualisierungen finden Sie unter [Aktualisierungen der AWS verwalteten Richtlinien für Jobfunktionen](#security-iam-awsmanpol-jobfunction-updates).
**Richtlinienbeschreibung:** Diese Richtlinie gewährt volle Berechtigungen für die Verwaltung von Rechnungen, Kosten, Zahlungsmethoden, Budgets und Berichten. Weitere Beispiele für Kostenmanagement-Richtlinien finden Sie in den [AWS Billing -Richtlinienbeispielen](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-example-policies.html) im *AWS Fakturierung und Kostenmanagement -Benutzerhandbuch*. Weitere Informationen zur verwalteten Richtlinie finden Sie unter [Fakturierung](https://docs.aws.amazon.com//aws-managed-policy/latest/reference/Billing.html) im *Referenzhandbuch für von verwaltete AWS -Richtlinien*.
**Anmerkung**
Bevor ein IAM-Benutzer oder eine IAM-Rolle mit den in dieser Richtlinie festgelegten Berechtigungen auf die AWS Fakturierung und Kostenmanagement Konsole zugreifen kann, müssen Sie zunächst den IAM-Benutzer- und Rollenzugriff aktivieren. Folgen Sie dazu den Anweisungen unter [Zugriff auf die Fakturierungskonsole gewähren](getting-started-account-iam.md), um den Zugriff auf die Fakturierungskonsole zu delegieren.
## Datenbankadministrator-Auftragsfunktion
**AWS Name der verwalteten Richtlinie: [DatabaseAdministrator](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/job-function/DatabaseAdministrator)**
**Anwendungsfall:** Dieser Benutzer richtet Datenbanken in der AWS Cloud ein, konfiguriert und verwaltet sie.
**Richtlinienaktualisierungen:** AWS Verwaltet und aktualisiert diese Richtlinie. Eine Historie der Änderungen für diese Richtlinie finden Sie in der IAM-Konsole, und wählen Sie dann die **Versionen der Datenlinien**-Registerkarte. Weitere Informationen zu Auftragsfunktions-Richtlinienaktualisierungen finden Sie unter [Aktualisierungen der AWS verwalteten Richtlinien für Jobfunktionen](#security-iam-awsmanpol-jobfunction-updates).
**Richtlinienbeschreibung:** Diese Richtlinie erteilt Berechtigungen, um Datenbanken zu erstellen, zu konfigurieren und zu verwalten. Es beinhaltet den Zugriff auf AWS Datenbankdienste wie Amazon DynamoDB, Amazon Relational Database Service (RDS) und Amazon Redshift. Zeigen Sie die Richtlinie für die vollständige Liste der Datenbank-Services an, die von dieser Richtlinie unterstützt werden. Weitere Informationen zur verwalteten Richtlinie finden Sie [DatabaseAdministrator](https://docs.aws.amazon.com//aws-managed-policy/latest/reference/DatabaseAdministrator.html)im Referenzhandbuch für *AWS verwaltete* Richtlinien.
Diese Richtlinie für Jobfunktionen unterstützt die Möglichkeit, Rollen an AWS Dienste zu übergeben. Die Richtlinie gewährt die `iam:PassRole`-Aktion ausschließlich für die in der folgenden Tabelle genannten Rollen. Weitere Informationen finden Sie unter [Erstellen von Rollen und Anfügen von Richtlinien (Konsole)](access_policies_job-functions_create-policies.md) an späterer Stelle in diesem Thema.
| Anwendungsfall | Rollenname (\$1 ist ein Platzhalter) | Auszuwählender Servicerollentyp | Wählen Sie diese AWS verwaltete Richtlinie aus |
| --- | --- | --- | --- |
| Der Benutzer kann RDS-Datenbanken überwachen | [rds-monitoring-role](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html) | Amazon RDS Role for Enhanced Monitoring | [AmazonRDSEnhancedMonitoringRole](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AmazonRDSEnhancedMonitoringRole) |
| Erlauben AWS Lambda Sie die Überwachung Ihrer Datenbank und den Zugriff auf externe Datenbanken | [rdbms-lambda-access](https://aws.amazon.com/blogs/big-data/from-sql-to-microservices-integrating-aws-lambda-with-relational-databases) | Amazon EC2 | [AWSLambda\$1FullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AWSLambda_FullAccess) |
| Lambda das Hochladen von Dateien in Amazon S3 und in Amazon Redshift Cluster mit DynamoDB ermöglichen | [lambda\$1exec\$1role](https://aws.amazon.com/blogs/big-data/a-zero-administration-amazon-redshift-database-loader) | AWS Lambda | Erstellen einer neuen verwalteten Richtlinie, wie im [AWS Big Data Blog](https://aws.amazon.com/blogs/big-data/a-zero-administration-amazon-redshift-database-loader) definiert |
| Erlauben Sie Lambda-Funktionen, als Trigger für Ihre DynamoDB-Tabellen zu fungieren | [lambda-dynamodb-\$1](https://docs.aws.amazon.com/lambda/latest/dg/with-ddb.html) | AWS Lambda | [AWSLambdaDynamo-Rolle DBExecution](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AWSLambdaDynamoDBExecutionRole) |
| Erlauben Sie Lambda-Funktionen den Zugriff auf Amazon RDS in einer VPC | [lambda-vpc-execution-role](https://docs.aws.amazon.com/lambda/latest/dg/vpc-rds.html) | Erstellen einer Rolle mit einer Vertrauensrichtlinie, wie im [AWS Lambda Developer Guide](https://docs.aws.amazon.com/lambda/latest/dg/vpc-rds.html) definiert | [AWSLambdaVPCAccessExecutionRole](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AWSLambdaVPCAccessExecutionRole) |
| Erlauben AWS Data Pipeline Sie den Zugriff auf Ihre Ressourcen AWS | [DataPipelineDefaultRole](https://docs.aws.amazon.com/datapipeline/latest/DeveloperGuide/dp-iam-roles.html) | Erstellen einer Rolle mit einer Vertrauensrichtlinie, wie im [AWS Data Pipeline Developer Guide](https://docs.aws.amazon.com/datapipeline/latest/DeveloperGuide/dp-iam-roles.html) definiert | In der AWS Data Pipeline Dokumentation sind die erforderlichen Berechtigungen für diesen Anwendungsfall aufgeführt. Weitere Informationen finden Sie unter [IAM-Rollen AWS Data Pipeline](https://docs.aws.amazon.com/datapipeline/latest/DeveloperGuide/dp-iam-roles.html) |
| Anwendungen, die auf Amazon EC2-Instances ausgeführt werden, können auf Ihre AWS -Ressourcen zugreifen | [DataPipelineDefaultResourceRole](https://docs.aws.amazon.com/datapipeline/latest/DeveloperGuide/dp-iam-roles.html) | Erstellen einer Rolle mit einer Vertrauensrichtlinie, wie im [AWS Data Pipeline Developer Guide](https://docs.aws.amazon.com/datapipeline/latest/DeveloperGuide/dp-iam-roles.html) definiert | [AmazonEC2RoleforDataPipelineRole](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AmazonEC2RoleforDataPipelineRole) |
## Auftragsfunktion für Data Scientist
**AWS Name der verwalteten Richtlinie: [DataScientist](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/job-function/DataScientist)**
**Anwendungsfall:** Dieser Benutzer führt Hadoop-Aufträge und -Abfragen. Der Benutzer greift auch auf Informationen für Datenanalysen und Business Intelligence zu und analysiert diese.
**Richtlinienaktualisierungen:** Diese Richtlinie wird AWS beibehalten und aktualisiert. Eine Historie der Änderungen für diese Richtlinie finden Sie in der IAM-Konsole, und wählen Sie dann die **Versionen der Datenlinien**-Registerkarte. Weitere Informationen zu Auftragsfunktions-Richtlinienaktualisierungen finden Sie unter [Aktualisierungen der AWS verwalteten Richtlinien für Jobfunktionen](#security-iam-awsmanpol-jobfunction-updates).
**Beschreibung der Richtlinie:** Diese Richtlinie gewährt Berechtigungen zum Erstellen, Verwalten und Ausführen von Abfragen in einem Amazon EMR-Cluster sowie zur Durchführung von Datenanalysen mit Tools wie Amazon QuickSight. Die Richtlinie beinhaltet den Zugriff auf zusätzliche Data-Scientist-Services wie AWS Data Pipeline Amazon EC2, Amazon Kinesis, Amazon Machine Learning und SageMaker KI. Zeigen Sie die Richtlinie für die vollständige Liste der Data Scientist-Services an, die von dieser Richtlinie unterstützt werden. Weitere Informationen zur verwalteten Richtlinie finden Sie [DataScientist](https://docs.aws.amazon.com//aws-managed-policy/latest/reference/DataScientist.html)im *Referenzhandbuch für AWS verwaltete Richtlinien.*
Diese Richtlinie für Jobfunktionen unterstützt die Möglichkeit, Rollen an AWS Dienste zu übergeben. Eine Aussage ermöglicht die Übertragung beliebiger Rollen an SageMaker KI. Eine weitere Anweisung gewährt die `iam:PassRole`-Aktion ausschließlich für die in der folgenden Tabelle genannten Rollen. Weitere Informationen finden Sie unter [Erstellen von Rollen und Anfügen von Richtlinien (Konsole)](access_policies_job-functions_create-policies.md) an späterer Stelle in diesem Thema.
| Anwendungsfall | Rollenname (\$1 ist ein Platzhalter) | Auszuwählender Servicerollentyp | AWS verwaltete Richtlinie zur Auswahl |
| --- | --- | --- | --- |
| Ermöglichen Sie Amazon EC2-Instances den Zugriff auf für Cluster geeignete Dienste und Ressourcen | [EMR-\$1 EC2 DefaultRole](https://docs.aws.amazon.com/emr/latest/DeveloperGuide/emr-iam-roles-defaultroles.html) | Amazon EMR für EC2 | [AmazonElasticMapReduceforEC2Rolle](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AmazonElasticMapReduceforEC2Role) |
| Amazon EMR-Zugriff für den Zugriff auf den Amazon EC2-Service und die Ressourcen für Cluster erlauben | [EMR\$1 DefaultRole](https://docs.aws.amazon.com/emr/latest/DeveloperGuide/emr-iam-roles-defaultroles.html) | Amazon EMR | [EMRServiceAmazon-Richtlinie\$1v2](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AmazonEMRServicePolicy_v2) |
| Kinesis Managed Service für Apache Flink den Zugriff auf Streaming-Datenquellen erlauben | [kinesis-\$1](https://aws.amazon.com/blogs/big-data/a-zero-administration-amazon-redshift-database-loader) | Erstellen einer Rolle mit einer Vertrauensrichtlinie, wie im [AWS Big Data Blog](https://aws.amazon.com/blogs/big-data/a-zero-administration-amazon-redshift-database-loader) definiert | Weitere Informationen finden Sie im [AWS Big Data Blog](https://aws.amazon.com/blogs/big-data/a-zero-administration-amazon-redshift-database-loader). Er enthält vier mögliche Optionen, je nach Ihrem Anwendungsfall. |
| Erlauben Sie AWS Data Pipeline den Zugriff auf Ihre Ressourcen AWS | [DataPipelineDefaultRole](https://docs.aws.amazon.com/datapipeline/latest/DeveloperGuide/dp-iam-roles.html) | Erstellen einer Rolle mit einer Vertrauensrichtlinie, wie im [AWS Data Pipeline Developer Guide](https://docs.aws.amazon.com/datapipeline/latest/DeveloperGuide/dp-iam-roles.html) definiert | In der AWS Data Pipeline Dokumentation sind die erforderlichen Berechtigungen für diesen Anwendungsfall aufgeführt. Weitere Informationen finden Sie unter [IAM-Rollen AWS Data Pipeline](https://docs.aws.amazon.com/datapipeline/latest/DeveloperGuide/dp-iam-roles.html) |
| Anwendungen, die auf Amazon EC2-Instances ausgeführt werden, können auf Ihre AWS -Ressourcen zugreifen | [DataPipelineDefaultResourceRole](https://docs.aws.amazon.com/datapipeline/latest/DeveloperGuide/dp-iam-roles.html) | Erstellen einer Rolle mit einer Vertrauensrichtlinie, wie im [AWS Data Pipeline Developer Guide](https://docs.aws.amazon.com/datapipeline/latest/DeveloperGuide/dp-iam-roles.html) definiert | [AmazonEC2RoleforDataPipelineRole](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AmazonEC2RoleforDataPipelineRole) |
## Auftragsfunktion Developer Power User
**AWS Name der verwalteten Richtlinie: [PowerUserAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/PowerUserAccess)**
**Anwendungsfall:** Dieser Benutzer führt Aufgaben zur Anwendungsentwicklung durch und kann Ressourcen und Dienste erstellen und konfigurieren, die die AWS bewusste Anwendungsentwicklung unterstützen.
**Richtlinienaktualisierungen:** AWS Verwaltet und aktualisiert diese Richtlinie. Eine Historie der Änderungen für diese Richtlinie finden Sie in der IAM-Konsole, und wählen Sie dann die **Versionen der Datenlinien**-Registerkarte. Weitere Informationen zu Auftragsfunktions-Richtlinienaktualisierungen finden Sie unter [Aktualisierungen der AWS verwalteten Richtlinien für Jobfunktionen](#security-iam-awsmanpol-jobfunction-updates).
**Beschreibung der Richtlinie:** In der ersten Aussage dieser Richtlinie wird das [`NotAction`](reference_policies_elements_notaction.md)Element verwendet, um alle Aktionen für alle AWS Dienste und Ressourcen außer AWS Identity and Access Management AWS Organizations, und zuzulassen AWS -Kontenverwaltung. Die zweite Anweisung erteilt IAM-Berechtigungen zum Erstellen einer serviceverknüpften Rolle. Dies wird von einigen Services benötigt, die auf Ressourcen in einem anderen Service zugreifen müssen, z. B. ein Amazon S3-Bucket. Es gewährt auch AWS Organizations Berechtigungen zum Anzeigen von Informationen über die Organisation des Benutzers, einschließlich der E-Mail-Adresse des Verwaltungskontos und der organisatorischen Einschränkungen. Diese Richtlinie schränkt zwar IAM ein AWS Organizations, ermöglicht es dem Benutzer jedoch, alle IAM Identity Center-Aktionen durchzuführen, wenn IAM Identity Center aktiviert ist. Sie gewährt außerdem Kontoverwaltungsberechtigungen, mit denen Sie sehen können, welche AWS Regionen für das Konto aktiviert oder deaktiviert sind.
## Netzwerkadministrator-Auftragsfunktion
**AWS Name der verwalteten Richtlinie: [NetworkAdministrator](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/job-function/NetworkAdministrator)**
**Anwendungsfall:** Dieser Benutzer hat die Aufgabe, AWS Netzwerkressourcen einzurichten und zu verwalten.
**Aktualisierungen der Richtlinie:** AWS Verwaltet und aktualisiert diese Richtlinie. Eine Historie der Änderungen für diese Richtlinie finden Sie in der IAM-Konsole, und wählen Sie dann die **Versionen der Datenlinien**-Registerkarte. Weitere Informationen zu Auftragsfunktions-Richtlinienaktualisierungen finden Sie unter [Aktualisierungen der AWS verwalteten Richtlinien für Jobfunktionen](#security-iam-awsmanpol-jobfunction-updates).
**Beschreibung der Richtlinie:** Diese Richtlinie gewährt Berechtigungen zum Erstellen und Verwalten von Netzwerkressourcen in Auto Scaling, Amazon EC2, AWS Direct Connect, Route 53, Amazon CloudFront, Elastic Load Balancing AWS Elastic Beanstalk,, Amazon SNS CloudWatch, CloudWatch Logs, Amazon S3, IAM und Amazon Virtual Private Cloud. Weitere Informationen zur verwalteten Richtlinie finden Sie [NetworkAdministrator](https://docs.aws.amazon.com//aws-managed-policy/latest/reference/NetworkAdministrator.html)im Referenzhandbuch für *AWS verwaltete Richtlinien*.
Diese Jobfunktion erfordert die Fähigkeit, Rollen an AWS Dienste zu übergeben. Die Richtlinie gewährt `iam:GetRole` und `iam:PassRole` ausschließlich für die in der folgenden Tabelle genannten Rollen. Weitere Informationen finden Sie unter [Erstellen von Rollen und Anfügen von Richtlinien (Konsole)](access_policies_job-functions_create-policies.md) an späterer Stelle in diesem Thema.
| Anwendungsfall | Rollenname (\$1 ist ein Platzhalter) | Auszuwählender Servicerollentyp | AWS verwaltete Richtlinie zur Auswahl |
| --- | --- | --- | --- |
| Ermöglicht Amazon VPC, im Namen des Benutzers Logs in CloudWatch Logs zu erstellen und zu verwalten, um IP-Verkehr zu überwachen, der in und aus Ihrer VPC fließt | [flow-logs-\$1](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html#flow-logs-iam) | Erstellen einer Rolle mit einer Vertrauensrichtlinie, wie im [Amazon VPC User Guide](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html#flow-logs-iam) definiert | Für diesen Anwendungsfall gibt es keine bestehende AWS verwaltete Richtlinie, aber in der Dokumentation sind die erforderlichen Berechtigungen aufgeführt. Siehe [Amazon VPC-Leitfaden](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html#flow-logs-iam). |
## Schreibgeschützter Zugriff
**AWS Name der verwalteten Richtlinie: [ReadOnlyAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/ReadOnlyAccess)**
**Anwendungsfall** Dieser Benutzer benötigt Nur-Lese-Zugriff auf alle Ressourcen eines AWS-Konto.
**Wichtig**
Dieser Benutzer hat auch Zugriff zum Lesen von Daten in Speicherservices wie Amazon-S3-Buckets und Amazon-DynamoDB-Tabellen.
**Richtlinienaktualisierungen:** Diese Richtlinie wird AWS beibehalten und aktualisiert. Eine Historie der Änderungen für diese Richtlinie finden Sie in der IAM-Konsole, und wählen Sie dann die **Versionen der Datenlinien**-Registerkarte. Weitere Informationen zu Auftragsfunktions-Richtlinienaktualisierungen finden Sie unter [Aktualisierungen der AWS verwalteten Richtlinien für Jobfunktionen](#security-iam-awsmanpol-jobfunction-updates).
**Beschreibung der Richtlinie:** Diese Richtlinie gewährt Berechtigungen zum Auflisten, Abrufen, Beschreiben und anderweitigen Anzeigen von Ressourcen und deren Attributen. Es enthält keine mutierenden Funktionen wie Erstellen oder Löschen. Diese Richtlinie beinhaltet den schreibgeschützten Zugriff auf sicherheitsrelevante AWS Dienste wie und. AWS Identity and Access Management AWS Fakturierung und Kostenmanagement Zeigen Sie die Richtlinie für die vollständige Liste der Datenbank-Services an, die von dieser Richtlinie unterstützt werden. Weitere Informationen zur verwalteten Richtlinie finden Sie [ReadOnlyAccess](https://docs.aws.amazon.com//aws-managed-policy/latest/reference/ReadOnlyAccess.html)im Referenzhandbuch für *AWS verwaltete* Richtlinien. Wenn Sie eine ähnliche Richtlinie benötigen, die keinen Zugriff zum Lesen von Daten in Speicherservices gewährt, finden Sie weitere Informationen unter [Auftragsfunktion für Benutzer mit Lesezugriff](#jf_view-only-user).
## MCP-Serviceaktionen, voller Zugriff
**AWS Name der verwalteten Richtlinie: [AWSMcpServiceActionsFullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AWSMcpServiceActionsFullAccess)**
**Anwendungsfall:** Dieser Benutzer benötigt Zugriff auf AWS Dienste, die AWS MCP-Server verwenden. Diese Richtlinie gewährt anderen AWS Diensten keinen Zugriff auf Aktionen, die von einem MCP-Service ausgeführt werden.
**Aktualisierungen der Richtlinie:** Diese Richtlinie wird AWS beibehalten und aktualisiert. Eine Historie der Änderungen für diese Richtlinie finden Sie in der IAM-Konsole, und wählen Sie dann die **Versionen der Datenlinien**-Registerkarte. Weitere Informationen zu Auftragsfunktions-Richtlinienaktualisierungen finden Sie unter [Aktualisierungen der AWS verwalteten Richtlinien für Jobfunktionen](#security-iam-awsmanpol-jobfunction-updates).
**Beschreibung der Richtlinie:** Diese Richtlinie gewährt Berechtigungen zum Aufrufen beliebiger AWS MCP-Serviceaktionen. Sie können sie verwenden, wenn Sie keine Berechtigungen pro AWS MCP-Dienst angeben müssen. Es gewährt anderen AWS Diensten keine Berechtigungen für Aktionen, die vom MCP-Dienst ausgeführt werden. Diese Berechtigungen müssen immer separat und zusätzlich zu den MCP-Serviceaktionen erteilt werden. Weitere Informationen zur verwalteten Richtlinie finden Sie [AWSMcpServiceActionsFullAccess](https://docs.aws.amazon.com//aws-managed-policy/latest/reference/AWSMcpServiceActionsFullAccess.html)im *Referenzhandbuch für AWS verwaltete Richtlinien.*
## Auftragsfunktion Sicherheitsprüfer
**AWS Name der verwalteten Richtlinie: [SecurityAudit](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/SecurityAudit)**
**Anwendungsfall:** Dieser Benutzer überwacht Konten auf die Einhaltung der Sicherheitsanforderungen. Dieser Benutzer kann auf Protokolle und Ereignisse zugreifen, um potenzielle Sicherheitsverstöße oder mögliche bösartige Aktivitäten zu untersuchen.
**Richtlinienaktualisierungen:** Diese Richtlinie wird AWS beibehalten und aktualisiert. Eine Historie der Änderungen für diese Richtlinie finden Sie in der IAM-Konsole, und wählen Sie dann die **Versionen der Datenlinien**-Registerkarte. Weitere Informationen zu Auftragsfunktions-Richtlinienaktualisierungen finden Sie unter [Aktualisierungen der AWS verwalteten Richtlinien für Jobfunktionen](#security-iam-awsmanpol-jobfunction-updates).
**Beschreibung der Richtlinie:** Diese Richtlinie gewährt Berechtigungen zum Anzeigen von Konfigurationsdaten für viele AWS Dienste und zum Überprüfen ihrer Protokolle. Weitere Informationen zur verwalteten Richtlinie finden Sie [SecurityAudit](https://docs.aws.amazon.com//aws-managed-policy/latest/reference/SecurityAudit.html)im *Referenzhandbuch für AWS verwaltete Richtlinien*.
## Auftragsfunktion Support Benutzer
**AWS Name der verwalteten Richtlinie: AWSSupport** [Access](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AWSSupportAccess)
**Anwendungsfall:** Dieser Benutzer kontaktiert den AWS Support, erstellt Supportfälle und sieht sich den Status vorhandener Fälle an.
**Aktualisierungen der Richtlinie:** Diese Richtlinie wird AWS beibehalten und aktualisiert. Eine Historie der Änderungen für diese Richtlinie finden Sie in der IAM-Konsole, und wählen Sie dann die **Versionen der Datenlinien**-Registerkarte. Weitere Informationen zu Auftragsfunktions-Richtlinienaktualisierungen finden Sie unter [Aktualisierungen der AWS verwalteten Richtlinien für Jobfunktionen](#security-iam-awsmanpol-jobfunction-updates).
**Beschreibung der Richtlinie:** Diese Richtlinie gewährt Berechtigungen zum Erstellen und Aktualisieren von Support Fällen. Weitere Informationen zur verwalteten Richtlinie finden Sie unter [AWSSupportAccess](https://docs.aws.amazon.com//aws-managed-policy/latest/reference/AWSSupportAccess.html) im *Referenzhandbuch für AWS verwaltete Richtlinien*.
## Funktion des Systemadministrators
**AWS Name der verwalteten Richtlinie: [SystemAdministrator](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/job-function/SystemAdministrator)**
**Anwendungsfall:** Dieser Benutzer richtet Ressourcen für Entwicklungsvorgänge ein und verwaltet diese.
**Richtlinienaktualisierungen:** Diese Richtlinie wird AWS beibehalten und aktualisiert. Eine Historie der Änderungen für diese Richtlinie finden Sie in der IAM-Konsole, und wählen Sie dann die **Versionen der Datenlinien**-Registerkarte. Weitere Informationen zu Auftragsfunktions-Richtlinienaktualisierungen finden Sie unter [Aktualisierungen der AWS verwalteten Richtlinien für Jobfunktionen](#security-iam-awsmanpol-jobfunction-updates).
**Beschreibung der Richtlinie:** Diese Richtlinie gewährt Berechtigungen zum Erstellen und Verwalten von Ressourcen für eine Vielzahl von AWS Diensten, darunter Amazon AWS CloudTrail, CloudWatch, AWS CodeCommit, AWS CodeDeploy, AWS Config AWS Directory Service, Amazon EC2,, AWS Identity and Access Management, AWS Key Management Service AWS Lambda, Amazon RDS, Route 53, Amazon S3, Amazon SES, Amazon SQS und Amazon AWS Trusted Advisor VPC. Weitere Informationen zur verwalteten Richtlinie finden Sie [SystemAdministrator](https://docs.aws.amazon.com//aws-managed-policy/latest/reference/SystemAdministrator.html)im Referenzhandbuch für *AWS verwaltete Richtlinien*.
Diese Jobfunktion erfordert die Fähigkeit, Rollen an AWS Dienste zu übergeben. Die Richtlinie gewährt `iam:GetRole` und `iam:PassRole` ausschließlich für die in der folgenden Tabelle genannten Rollen. Weitere Informationen finden Sie unter [Erstellen von Rollen und Anfügen von Richtlinien (Konsole)](access_policies_job-functions_create-policies.md) an späterer Stelle in diesem Thema. Weitere Informationen zu Auftragsfunktions-Richtlinienaktualisierungen finden Sie unter [Aktualisierungen der AWS verwalteten Richtlinien für Jobfunktionen](#security-iam-awsmanpol-jobfunction-updates).
| Anwendungsfall | Rollenname (\$1 ist ein Platzhalter) | Auszuwählender Servicerollentyp | AWS verwaltete Richtlinie zur Auswahl |
| --- | --- | --- | --- |
| Apps, die in EC2-Instances in einem Amazon ECS-Cluster ausgeführt werden, können auf Amazon ECS zuzugreifen | [ecr-sysadmin-\$1](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/instance_IAM_role.html) | Amazon EC2-Rolle für EC2 Container Service | [EC2ContainerServiceforEC2Rolle bei Amazon](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AmazonEC2ContainerServiceforEC2Role) |
| Ein Benutzer kann Datenbanken überwachen | [rds-monitoring-role](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html) | Amazon RDS Role for Enhanced Monitoring | [AmazonRDSEnhancedMonitoringRole](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AmazonRDSEnhancedMonitoringRole) |
| Erlauben Sie Apps, die in EC2-Instances ausgeführt werden, den Zugriff auf AWS Ressourcen. | [ec2-sysadmin-\$1](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html) | Amazon EC2 | Beispielrichtlinie für eine Rolle, die Zugriff auf einen S3-Bucket gewährt, wie im [Amazon-EC2-Benutzerhandbuch](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html) beschrieben. Ist bei Bedarf anpassbar |
| Erlauben Sie Lambda, DynamoDB-Streams zu lesen und in Logs zu schreiben CloudWatch | [lambda-sysadmin-\$1](https://docs.aws.amazon.com/lambda/latest/dg/with-ddb.html) | AWS Lambda | [AWSLambdaDynamo-Rolle DBExecution](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/service-role/AWSLambdaDynamoDBExecutionRole) |
## Auftragsfunktion für Benutzer mit Lesezugriff
**AWS Name der verwalteten Richtlinie: [ViewOnlyAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/job-function/ViewOnlyAccess)**
**Anwendungsfall:** Dieser Benutzer kann eine Liste mit AWS Ressourcen und grundlegenden Metadaten im Konto dienstübergreifend einsehen. Der Benutzer kann Ressourceninhalt oder Metadaten, die über das Kontingent hinausgehen, nicht lesen und keine Informationen für Ressourcen auflisten.
**Aktualisierungen der Richtlinie:** AWS Verwaltet und aktualisiert diese Richtlinie. Eine Historie der Änderungen für diese Richtlinie finden Sie in der IAM-Konsole, und wählen Sie dann die **Versionen der Datenlinien**-Registerkarte. Weitere Informationen zu Auftragsfunktions-Richtlinienaktualisierungen finden Sie unter [Aktualisierungen der AWS verwalteten Richtlinien für Jobfunktionen](#security-iam-awsmanpol-jobfunction-updates).
**Beschreibung der Richtlinie:** Diese Richtlinie gewährt `List*``Describe*`,,`Get*`,`View*`, und `Lookup*` Zugriff auf Ressourcen für AWS Dienste. Informationen darüber, welche Aktionen diese Richtlinie für die einzelnen Dienste beinhaltet, finden Sie unter [ViewOnlyAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/job-function/ViewOnlyAccess). Weitere Informationen zur verwalteten Richtlinie finden Sie [ViewOnlyAccess](https://docs.aws.amazon.com//aws-managed-policy/latest/reference/ViewOnlyAccess.html)im *Referenzhandbuch für AWS verwaltete Richtlinien*.
## Aktualisierungen der AWS verwalteten Richtlinien für Jobfunktionen
Diese Richtlinien werden alle von den Diensten verwaltet AWS und auf dem neuesten Stand gehalten, sodass sie auch Unterstützung für neue Dienste und neue Funktionen bieten, sobald diese von den AWS Diensten hinzugefügt werden. Diese Richtlinien können nicht von den Kunden geändert werden. Sie können eine Kopie der Richtlinie erstellen und die Kopie dann ändern. Diese Kopie wird jedoch nicht automatisch aktualisiert, wenn neue Dienste und API-Operationen AWS eingeführt werden.
Für eine Auftragsfunktionsrichtlinie können Sie den Versionsverlauf sowie die Uhrzeit und das Datum jedes Updates in der IAM-Konsole anzeigen. Verwenden Sie dazu die Links auf dieser Seite, um die Richtliniendetails anzuzeigen. Wählen Sie dann die **Versionen der Datenlinien**, um die Versionen anzuzeigen. Auf dieser Seite werden die letzten 25 Versionen einer Richtlinie angezeigt. Um alle Versionen einer Richtlinie anzuzeigen, rufen Sie den [get-policy-version](https://docs.aws.amazon.com/cli/latest/reference/iam/get-policy-version.html) AWS CLI Befehl oder die [GetPolicyVersion](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetPolicyVersion.html)API-Operation auf.
**Anmerkung**
Sie können bis zu fünf Versionen einer vom Kunden verwalteten Richtlinie verwenden, wobei jedoch der vollständige Versionsverlauf der AWS verwalteten Richtlinien AWS beibehalten wird.
# Erstellen von Rollen und Anfügen von Richtlinien (Konsole)
Einige der zuvor aufgeführten Richtlinien ermöglichen die Konfiguration von AWS Diensten mit Rollen, die es diesen Diensten ermöglichen, Operationen in Ihrem Namen auszuführen. Die Auftragsfunktionsrichtlinien geben entweder genaue Rollennamen an, die Sie verwenden müssen, oder fügen zumindest ein Präfix an, das den ersten Teil des Namens, der verwendet werden kann, angibt. Führen Sie die Schritte in den folgenden Verfahren aus, um eine dieser Rollen zu erstellen.
**Um eine Rolle für eine AWS-Service (IAM-Konsole) zu erstellen**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die IAM-Konsole unter. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)
1. Klicken Sie im Navigationsbereich der IAM-Konsole auf **Rollen**, und wählen Sie dann **Rolle erstellen**.
1. Wählen Sie für **Vertrauenswürdige Entität** die Option **AWS-Service** aus.
1. Wählen Sie unter **Service oder Anwendungsfall** einen Service und anschließend den Anwendungsfall aus. Die Anwendungsfälle werden vom Dienst so definiert, dass sie die Vertrauensrichtlinie beinhalten, die für den Dienst erforderlich ist.
1. Wählen Sie **Weiter** aus.
1. Bei **Berechtigungsrichtlinien** hängen die Optionen vom ausgewählten Anwendungsfall ab:
+ Wenn der Service die Berechtigungen für die Rolle definiert, können Sie keine Berechtigungsrichtlinien auswählen.
+ Wählen Sie aus einer begrenzten Anzahl von Berechtigungsrichtlinien.
+ Wählen Sie aus allen Berechtigungsrichtlinien.
+ Wählen Sie keine Berechtigungsrichtlinien aus, erstellen Sie die Richtlinien, nachdem die Rolle erstellt wurde, und fügen Sie die Richtlinien dann der Rolle an.
1. (Optional) Legen Sie eine [Berechtigungsgrenze](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) fest. Dies ist ein erweitertes Feature, das für Servicerollen verfügbar ist, aber nicht für servicegebundene Rollen.
1. Öffnen Sie den Abschnitt **Berechtigungsgrenze festlegen** und wählen Sie dann **Eine Berechtigungsgrenze verwenden, um die maximalen Rollenberechtigungen zu steuern** aus.
IAM enthält eine Liste der AWS verwalteten und kundenverwalteten Richtlinien in Ihrem Konto.
1. Wählen Sie die Richtlinie aus, die für eine Berechtigungsgrenze verwendet werden soll.
1. Wählen Sie **Weiter** aus.
1. Für den **Rollennamen** hängen die Optionen vom Service ab:
+ Wenn der Name der Rolle durch den Service definiert wird, können Sie den Namen der Rolle nicht bearbeiten.
+ Wenn der Service ein Präfix für den Rollennamen definiert, können Sie ein optionales Suffix eingeben.
+ Wenn der Service den Rollennamen nicht definiert, können Sie der Rolle einen Namen geben.
**Wichtig**
Beachten Sie beim Benennen einer Rolle Folgendes:
Rollennamen müssen innerhalb Ihres AWS-Konto Unternehmens eindeutig sein und können nicht von Fall zu Fall eindeutig sein.
Erstellen Sie beispielsweise keine Rollen mit dem Namen **PRODROLE** und **prodrole**. Wenn ein Rollenname in einer Richtlinie oder als Teil einer ARN verwendet wird, muss die Groß-/Kleinschreibung des Rollennamens beachtet werden. Wenn ein Rollenname den Kunden jedoch in der Konsole angezeigt wird, z. B. während des Anmeldevorgangs, wird die Groß-/Kleinschreibung des Rollennamens nicht beachtet.
Sie können den Namen der Rolle nach ihrer Erstellung nicht mehr bearbeiten, da andere Entitäten möglicherweise auf die Rolle verweisen.
1. (Optional) Geben Sie unter **Beschreibung** eine Beschreibung für die neue Rolle ein.
1. (Optional) Um die Anwendungsfälle und Berechtigungen für die Rolle zu bearbeiten, wählen Sie in den Abschnitten **Schritt 1: Vertrauenswürdige Entitäten auswählen** oder **Schritt 2: Berechtigungen hinzufügen** die Option **Bearbeiten**.
1. (Optional) Fügen Sie Tags als Schlüssel-Wert-Paare hinzu, um die Identifizierung, Organisation oder Suche nach der Rolle zu vereinfachen. Weitere Informationen zur Verwendung von Tags in IAM finden Sie unter [Tags für AWS Identity and Access Management Ressourcen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html) im *IAM-Benutzerhandbuch*.
1. Prüfen Sie die Rolle und klicken Sie dann auf **Create Role (Rolle erstellen)**.
## Beispiel 1: Konfigurieren eines Benutzers als Datenbankadministrator (Konsole)
Dieses Beispiel zeigt die Schritte zum Konfigurieren von Alice, einem IAM-Benutzer, als [Datenbankadministrator](access_policies_job-functions.md#jf_database-administrator). Verwenden Sie die Informationen in der ersten Zeile der Tabelle in diesem Abschnitt und erlauben Sie dem Benutzer, die Amazon RDS-Überwachung zu aktivieren. Sie hängen die [DatabaseAdministrator](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/job-function/DatabaseAdministrator)Richtlinie an den IAM-Benutzer von Alice an, damit dieser die Amazon-Datenbankdienste verwalten kann. Diese Richtlinie erlaubt es Alice auch, eine Rolle namens `rds-monitoring-role` an den Amazon-RDS-Service zu übergeben, die es dem Service erlaubt, die Amazon-RDS-Datenbanken in ihrem Namen zu überwachen.
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die IAM-Konsole unter. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)
1. Wählen Sie **Policies** (Richtlinien) aus, geben Sie **database** in das Suchfeld ein und drücken Sie die Eingabetaste.
1. Wählen Sie das Optionsfeld für die **DatabaseAdministrator**Richtlinie aus, klicken Sie auf **Aktionen** und dann auf **Anhängen**.
1. Wählen Sie in der Liste der Entitäten **Alice** und dann **Attach policy** (Richtlinie anfügen) aus. Alice kann jetzt AWS Datenbanken verwalten. Damit Alice diese Datenbanken jedoch überwachen kann, müssen Sie die Servicerolle konfigurieren.
1. Klicken Sie im Navigationsbereich der IAM-Konsole auf **Roles** und wählen Sie dann **Create role**.
1. Wählen Sie den Rollentyp **AWS Service** und dann **Amazon RDS**.
1. Wählen Sie den Anwendungsfall **Amazon RDS-Rolle für die verbesserte Überwachung**.
1. Amazon RDS definiert die Berechtigungen für Ihre Rolle. Wählen Sie **Next: Review (Weiter: Prüfen)**, um fortzufahren.
1. Der Rollenname muss einer der Namen sein, die in der DatabaseAdministrator Richtlinie angegeben sind, die Alice jetzt hat. Eine davon ist **rds-monitoring-role**. Geben Sie das für den **Rollennamen** ein.
1. (Optional) Geben Sie im Feld **Role description (Rollenbeschreibung)** eine Beschreibung für die neue Rolle ein.
1. Wählen Sie nach der Überprüfung der Details **Create role (Rolle erstellen)**.
1. Alice kann jetzt **RDS Enhanced Monitoring** im Abschnitt **Monitoring** der Amazon RDS-Konsole aktivieren. Zum Beispiel kann sie dies tun, wenn sie eine DB-Instance erstellt, eine Read Replica erstellt oder eine DB-Instance ändert. Sie müssen den Rollennamen, den sie erstellt haben (rds-monitoring-role), in das Feld **Überwachungsrolle** eingeben, wenn sie **Enable Enhanced Monitoring** auf **Ja** setzen.
## Beispiel 2: Konfigurieren eines Benutzers als Netzwerkadministrator (Konsole)
Dieses Beispiel zeigt die Schritte zum Konfigurieren von Jorge, einem IAM-Benutzer, als [Netzwerkadministrator](access_policies_job-functions.md#jf_network-administrator). Es verwendet die Informationen in der Tabelle in diesem Abschnitt, um es Jorge zu erlauben, den IP-Verkehr zu und von einer VPC zu überwachen. Außerdem kann Jorge diese Informationen in den Protokollen unter Logs erfassen. CloudWatch Sie fügen die [NetworkAdministrator](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/job-function/NetworkAdministrator)Richtlinie dem IAM-Benutzer von Jorge zu, damit dieser Netzwerkressourcen konfigurieren AWS kann. Diese Richtlinie erlaubt es Jorge auch, eine Rolle, deren Name mit `flow-logs*` beginnt, an Amazon EC2 zu übergeben, wenn Sie ein Flussprotokoll erstellen. In diesem Szenario gibt es im Gegensatz zu Beispiel 1 keinen vordefinierten Servicerollentyp, sodass Sie einige Schritte anders ausführen müssen.
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die IAM-Konsole unter. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)
1. Wählen Sie im Navigationsbereich **Policies** (Richtlinien) aus, geben Sie **network** in das Suchfeld ein und drücken Sie die Eingabetaste.
1. Wählen Sie das Optionsfeld neben **NetworkAdministrator**Richtlinie aus, wählen Sie **Aktionen** und dann **Anhängen** aus.
1. Aktivieren Sie in der Liste der Benutzer das Kontrollkästchen neben **Jorge** und wählen Sie dann **Richtlinie anfügen** aus. Jorge kann jetzt AWS Netzwerkressourcen verwalten. Um IP-Datenverkehr in Ihrer VPC überwachen zu können, müssen Sie die Servicerolle jedoch konfigurieren.
1. Da die Servicerolle, die Sie erstellen müssen, keine vordefinierte verwaltete Richtlinie hat, müssen Sie diese zuerst erstellen. Wählen Sie im Navigationsbereich **Policies** und dann **Create policy**.
1. Wählen Sie im Abschnitt **Policy editor** (Richtlinien-Editor) die Option **JSON** aus und kopieren Sie den Text aus dem folgenden JSON-Richtliniendokument. Fügen Sie den folgenden Text in das **JSON**-Eingabefeld ein.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents",
"logs:DescribeLogGroups",
"logs:DescribeLogStreams"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
------
1. Beheben Sie alle Sicherheitswarnungen, Fehler oder allgemeinen Warnungen, die während der [Richtlinien-Validierung](access_policies_policy-validator.md) erzeugt wurden, und wählen Sie dann **Weiter**.
**Anmerkung**
Sie können jederzeit zwischen den Editoroptionen **Visual** und **JSON** wechseln. Wenn Sie jedoch Änderungen vornehmen oder im **Visual**-Editor **Next** (Weiter) wählen, strukturiert IAM Ihre Richtlinie möglicherweise um, um sie für den visuellen Editor zu optimieren. Weitere Informationen finden Sie unter [Umstrukturierung einer Richtlinie](troubleshoot_policies.md#troubleshoot_viseditor-restructure).
1. Geben Sie auf der Seite **Review and create** (Überprüfen und erstellen) als Richtliniennamen **vpc-flow-logs-policy-for-service-role** ein. Überprüfen Sie die **Permissions defined in this policy** (In dieser Richtlinie definierte Berechtigungen), um die durch Ihre Richtlinie erteilten Berechtigungen zu sehen, und wählen Sie dann zum Speichern **Create policy** (Richtlinie erstellen) aus.
Die neue Richtlinie wird in der Liste der verwalteten Richtlinien angezeigt und ist bereit.
1. Klicken Sie im Navigationsbereich der IAM-Konsole auf **Roles** und wählen Sie dann **Create role**.
1. Wählen Sie den Rollentyp **AWS Service** und danach **Amazon EC2**.
1. Wählen Sie den Anwendungsfall **Amazon EC2**.
1. Wählen Sie auf der Seite „**Berechtigungsrichtlinien anhängen**“ die zuvor erstellte Richtlinie aus, **vpc-flow-logs-policy- for-service-role**, und klicken Sie dann auf **Weiter: Überprüfen**.
1. Der Rollenname muss gemäß der NetworkAdministrator Richtlinie, über die Jorge jetzt verfügt, zugelassen sein. Es ist jeder Name zulässig, der mit `flow-logs-` beginnt. Geben Sie in diesem Beispiel **flow-logs-for-jorge** als **Role name** (Rollennamen) ein.
1. (Optional) Geben Sie im Feld **Role description (Rollenbeschreibung)** eine Beschreibung für die neue Rolle ein.
1. Wählen Sie nach der Überprüfung der Details **Create role (Rolle erstellen)**.
1. Jetzt können Sie die Vertrauensrichtlinie konfigurieren, die für dieses Szenario erforderlich ist. Wählen Sie auf der Seite **Rollen** die **flow-logs-for-jorge**Rolle aus (den Namen, nicht das Kontrollkästchen). Wählen Sie auf der Detailseite für Ihre neue Rolle die Registerkarte **Trust relationships (Vertrauensbeziehungen)** und anschließend **Edit trust relationship (Vertrauensbeziehung bearbeiten)**.
1. Ändern Sie die Zeile "Service" in Folgendes, wobei Sie den Eintrag für `ec2.amazonaws.com` ersetzen:
```
"Service": "vpc-flow-logs.amazonaws.com"
```
1. Jorge kann jetzt Flow-Protokolle für eine VPC oder ein Subnetz in der Amazon-EC2-Konsole erstellen. Wenn Sie das Flow-Protokoll erstellen, geben Sie die **flow-logs-for-jorge**Rolle an. Diese Rolle hat die Berechtigungen, das Protokoll zu erstellen und Daten hineinzuschreiben.
# AWS Kontextschlüssel für globale Bedingungen
Wenn ein [Principal](https://docs.aws.amazon.com/glossary/latest/reference/glos-chap.html?icmpid=docs_homepage_addtlrcs#principal) eine [Anfrage](intro-structure.md#intro-structure-request) an stellt AWS, werden AWS die Anforderungsinformationen in einem [Anfragekontext](intro-structure.md#intro-structure-request) zusammengefasst. Sie können das `Condition`-Element einer JSON-Richtlinie verwenden, um Schlüssel im Anforderungskontext mit Schlüsselwerten zu vergleichen, die Sie in Ihrer Richtlinie angeben. Informationen werden von verschiedenen Quellen bereitgestellt, darunter der Prinzipal, der die Anfrage stellt, die Ressource, an die sich die Anfrage richtet, und die Metadaten zur Anfrage selbst.
**Globale Bedingungsschlüssel** können für alle AWS -Services verwendet werden. Obwohl diese Bedingungsschlüssel in allen Richtlinien verwendet werden können, ist der Schlüssel nicht in jedem Anforderungskontext verfügbar. Beispielsweise ist der Bedingungsschlüssel `aws:SourceAccount` nur verfügbar, wenn der Aufruf Ihrer Ressource direkt von einem [AWS -Service-Prinzipal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html#principal-services) erfolgt. Weitere Informationen zu den Umständen, unter denen ein globaler Schlüssel in den Anfragekontext aufgenommen wird, finden Sie in den Informationen zur **Verfügbarkeit** für jeden Schlüssel.
Einige einzelne Services erstellen ihre eigenen Bedingungsschlüssel, die im Anfragekontext für andere Services verfügbar sind. **Serviceübergreifende Bedingungsschlüssel** sind eine Art globaler Bedingungsschlüssel, die ein Präfix enthalten, das mit dem Namen des Services übereinstimmt, z. B. `ec2:` oder `lambda:`, aber auch für andere Services verfügbar sind.
**Dienstspezifische Bedingungsschlüssel** werden für die Verwendung mit einem einzelnen AWS Dienst definiert. Beispielsweise können Sie mit Amazon S3 eine Richtlinie mit dem Bedingungsschlüssel `s3:VersionId` schreiben, um den Zugriff auf eine bestimmte Version eines Amazon-S3-Objekts zu beschränken. Dieser Bedingungsschlüssel ist für den Service eindeutig, d. h. er funktioniert nur bei Anfragen an den Amazon-S3-Service. Informationen zu dienstspezifischen Bedingungsschlüsseln finden Sie unter [Aktionen, Ressourcen und Bedingungsschlüssel für AWS Dienste](https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html). Wählen Sie dort den Dienst aus, dessen Schlüssel Sie anzeigen möchten.
**Anmerkung**
Wenn Sie Bedingungsschlüssel verwenden, die nur unter bestimmten Umständen verfügbar sind, können Sie die [IfExists](reference_policies_elements_condition_operators.md#Conditions_IfExists)Versionen der Bedingungsoperatoren verwenden. Wenn die entsprechenden Bedingungsschlüssel im Kontext einer Anforderung fehlen, kann die Richtlinienauswertung fehlschlagen. Verwenden Sie beispielsweise den folgenden Bedingungsblock mit `...IfExists`-Operatoren, um abzugleichen, ob eine Anforderung aus einem bestimmten IP-Bereich oder von einer bestimmten VPC stammt. Wenn einer oder beide Schlüssel nicht im Anforderungskontext enthalten sind, gibt die Bedingung weiterhin `true` zurück. Die Werte werden nur überprüft, wenn der angegebene Schlüssel im Anforderungskontext enthalten ist. Weitere Informationen zur Auswertung einer Richtlinie, wenn ein Schlüssel für andere Operatoren nicht vorhanden ist, finden Sie unter [Bedingungsoperatoren](reference_policies_elements_condition_operators.md).
```
"Condition": {
"IpAddressIfExists": {"aws:SourceIp" : ["xxx"] },
"StringEqualsIfExists" : {"aws:SourceVpc" : ["yyy"]}
}
```
**Wichtig**
Um Ihre Bedingung mit einem Anforderungskontext mit mehreren Schlüsselwerten zu vergleichen, müssen Sie die Set-Operatoren `ForAllValues` oder `ForAnyValue` verwenden. Verwenden Sie Satz-Operatoren nur mit mehrwertigen Bedingungsschlüssel. Verwenden Sie keine Satz-Operatoren mit einzelwertigen Bedingungsschlüssel. Weitere Informationen finden Sie unter [Operatoren für mehrwertige Kontextschlüssel festlegen](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys).
| Eigenschaften des Prinzipals | Eigenschaften einer Rollensitzung | Eigenschaften des Netzwerks | Eigenschaften der Ressource | Eigenschaften der Anfrage |
| --- | --- | --- | --- | --- |
| `aws:PrincipalArn` `aws:PrincipalAccount` `aws:PrincipalOrgPaths` `aws:PrincipalOrgID` `aws:PrincipalTag/*tag-key*` `aws:PrincipalIsAWSService` `aws:PrincipalServiceName` `aws:PrincipalServiceNamesList` `aws:PrincipalType` `aws:userid` `aws:username` | `aws:AssumedRoot` `aws:FederatedProvider` `aws:TokenIssueTime` `aws:MultiFactorAuthAge` `aws:MultiFactorAuthPresent` `aws:ChatbotSourceArn` `aws:Ec2InstanceSourceVpc` `aws:Ec2InstanceSourcePrivateIPv4` `aws:SourceIdentity` `ec2:RoleDelivery` `ec2:SourceInstanceArn` `glue:RoleAssumedBy` `glue:CredentialIssuingService` `codebuild:BuildArn` `codebuild:ProjectArn` `lambda:SourceFunctionArn` `ssm:SourceInstanceArn` `identitystore:UserId` | `aws:SourceIp` `aws:SourceVpc` `aws:SourceVpcArn` `aws:SourceVpce` `aws:VpceAccount` `aws:VpceOrgID` `aws:VpceOrgPaths` `aws:VpcSourceIp` | `aws:ResourceAccount` `aws:ResourceOrgID` `aws:ResourceOrgPaths` `aws:ResourceTag/*tag-key*` | `aws:CalledVia` `aws:CalledViaFirst` `aws:CalledViaLast` `aws:CalledViaAWSMCP` `aws:ViaAWSService` `aws:ViaAWSMCPService` `aws:CurrentTime` `aws:EpochTime` `aws:referer` `aws:RequestedRegion` `aws:RequestTag/*tag-key*` `aws:TagKeys` `aws:SecureTransport` `aws:SourceAccount` `aws:SourceArn` `aws:SourceOrgID` `aws:SourceOrgPaths` `aws:UserAgent` `aws:IsMcpServiceAction` |
## Vertrauliche Bedingungsschlüssel
Die folgenden Bedingungsschlüssel werden als vertraulich betrachtet. Für die Verwendung von Platzhaltern in diesen Bedingungsschlüsseln gibt es keine gültigen Anwendungsfälle, selbst wenn eine Teilzeichenfolge des Schlüsselwerts einen Platzhalter enthält. Dies liegt daran, dass der Platzhalter den Bedingungsschlüssel mit jedem beliebigen Wert abgleichen kann, was ein Sicherheitsrisiko darstellen könnte.
+ `aws:PrincipalAccount`
+ `aws:PrincipalOrgID`
+ `aws:ResourceAccount`
+ `aws:ResourceOrgID`
+ `aws:SourceAccount`
+ `aws:SourceOrgID`
+ `aws:SourceVpc`
+ `aws:SourceVpce`
+ `aws:VpceAccount`
+ `aws:VpceOrgID`
## Eigenschaften des Prinzipals
Verwenden Sie die folgenden Bedingungsschlüssel, um Details über den Prinzipal, der die Anfrage stellt, mit den Prinzipaleigenschaften zu vergleichen, die Sie in der Richtlinie angeben. Eine Liste der Prinzipale, die Anfragen stellen können, finden Sie unter [So legen Sie einen Prinzipal fest](reference_policies_elements_principal.md#Principal_specifying).
### aws:PrincipalArn
Verwenden Sie diesen Schlüssel, um den [Amazon-Ressourcennamen](reference_identifiers.md#identifiers-arns) (ARN) des Auftraggebers, von dem die Anforderung stammt, mit dem ARN zu vergleichen, den Sie in der Richtlinie angeben. Bei IAM-Rollen gibt der Anforderungskontext den ARN der Rolle zurück, nicht den ARN des Benutzers, der die Rolle übernommen hat.
+ **Verfügbarkeit** – Dieser Schlüssel ist im Anforderungskontext aller signierten Anforderungen enthalten. Anonyme Anforderungen enthalten diesen Schlüssel nicht. In diesem Bedingungsschlüssel können Sie die folgenden Arten von Prinzipals angeben:
+ IAM role (IAM-Rolle)
+ IAM-Benutzer
+ AWS STS verbundener Benutzerprinzipal
+ AWS-Konto Root-Benutzer
+ **Datentyp** – ARN
AWS empfiehlt, beim Vergleich [ARN-Operatoren](reference_policies_elements_condition_operators.md#Conditions_ARN) anstelle von [Zeichenkettenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String) zu verwenden ARNs.
+ **Werttyp** - Einzelwertig
+ **Beispielwerte** Die folgende Liste zeigt den Anforderungskontextwert, der für verschiedene Arten von Prinzipalen zurückgegeben wird, die Sie im `aws:PrincipalArn`-Bedingungsschlüssel angeben können:
+ **IAM-Rolle** – Der Anforderungskontext enthält den folgenden Wert für den Bedingungsschlüssel `aws:PrincipalArn`. Geben Sie den ARN der angenommenen Rollensitzung nicht als Wert für diesen Bedingungsschlüssel an. Weitere Informationen über die angenommene Rollen des Sitzungs-Prinzipals finden Sie unter [Rollensitzungsgsprinzipale](reference_policies_elements_principal.md#principal-role-session).
```
arn:aws:iam::123456789012:role/role-name
```
+ **IAM-Benutzer** – Der Anforderungskontext enthält den folgenden Wert für den Bedingungsschlüssel `aws:PrincipalArn`.
```
arn:aws:iam::123456789012:user/user-name
```
+ **AWS STS Verbundbenutzerprinzipale** — Der Anforderungskontext enthält den folgenden Wert für den Bedingungsschlüssel. `aws:PrincipalArn`
```
arn:aws:sts::123456789012:federated-user/user-name
```
+ **AWS-Konto Root-Benutzer** — Der Anforderungskontext enthält den folgenden Wert für den Bedingungsschlüssel. `aws:PrincipalArn` Wenn Sie den Root-Benutzer-ARN als Wert für den Bedingungsschlüssel `aws:PrincipalArn` angeben, werden die Berechtigungen nur für den Root-Benutzer des AWS-Konto eingeschränkt. Dies unterscheidet sich von der Angabe des Root-Benutzer-ARN im Prinzipal-Element einer ressourcenbasierten Richtlinie, die die Autorität an die AWS-Konto delegiert. Weitere Informationen zur Angabe des Root-Benutzer-ARN im Prinzipal-Element einer ressourcenbasierten Richtlinie finden Sie unter [AWS-Konto Schulleiter](reference_policies_elements_principal.md#principal-accounts).
```
arn:aws:iam::123456789012:root
```
Sie können den Root-Benutzer-ARN als Wert für den Bedingungsschlüssel `aws:PrincipalArn` in den AWS Organizations Dienststeuerungsrichtlinien (SCPs) angeben. SCPssind eine Art von Organisationsrichtlinie, die zur Verwaltung von Berechtigungen in Ihrer Organisation verwendet wird und sich nur auf Mitgliedskonten in der Organisation auswirkt. Ein SCP beschränkt die Berechtigungen für IAM-Benutzer und -Rollen in Mitgliedskonten, einschließlich des Stammverzeichnisses des Mitgliedskonten. Weitere Informationen zu den Auswirkungen von SCPs auf Berechtigungen finden Sie unter [Auswirkungen von SCP auf Berechtigungen](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html#scp-effects-on-permissions) im *AWS Organizations Benutzerhandbuch*.
### aws:PrincipalAccount
Verwenden Sie diesen Schlüssel, um das Konto, zu dem der anfordernde Auftraggeber gehört, mit der Konto-ID zu vergleichen, die Sie in der Richtlinie angeben. Bei anonymen Anforderungen gibt der Anforderungskontext `anonymous` zurück.
+ **Verfügbarkeit** – Dieser Schlüssel wird in den Anforderungskontext für alle Anforderungen, einschließlich anonymer Anforderungen, aufgenommen.
+ **Datentyp** – [Zeichenfolge](reference_policies_elements_condition_operators.md#Conditions_String)
+ **Werttyp** - Einzelwertig
Im folgenden Beispiel wird der Zugriff verweigert, mit Ausnahme von Auftraggebern mit der Kontonummer `123456789012`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyAccessFromPrincipalNotInSpecificAccount",
"Action": "service:*",
"Effect": "Deny",
"Resource": [
"arn:aws:service:us-east-1:111122223333:resource"
],
"Condition": {
"StringNotEquals": {
"aws:PrincipalAccount": [
"123456789012"
]
}
}
}
]
}
```
------
### aws:PrincipalOrgPaths
Verwenden Sie diesen Schlüssel, um den AWS Organizations Pfad für den Prinzipal, der die Anfrage stellt, mit dem Pfad in der Richtlinie zu vergleichen. Dieser Prinzipal kann ein IAM-Benutzer, eine IAM-Rolle, ein Verbundbenutzer-Prinzipal von AWS STS oder ein Root-Benutzer des AWS-Kontos sein. In einer Richtlinie stellt dieser Bedingungsschlüssel sicher, dass der Anforderer ein Kontomitglied innerhalb des angegebenen Organisationsstamms oder der angegebenen Organisationseinheiten (OUs) ist. AWS Organizations Ein AWS Organizations Pfad ist eine Textdarstellung der Struktur einer AWS Organizations Entität. Weitere Hinweise zum Verwenden und Verstehen von Pfaden finden Sie unter [Verstehen Sie den AWS Organizations Entitätspfad](access_policies_last-accessed-view-data-orgs.md#access_policies_last-accessed-viewing-orgs-entity-path).
+ **Verfügbarkeit** – Dieser Schlüssel ist nur dann im Anforderungskontext enthalten, wenn der Auftraggeber Mitglied einer Organisation ist. Anonyme Anforderungen enthalten diesen Schlüssel nicht.
+ **Datentyp** – [Zeichenfolge](reference_policies_elements_condition_operators.md#Conditions_String) (Liste)
+ **Werttyp** - Mehrwertig
**Anmerkung**
Organisationen IDs sind weltweit einzigartig, aber OU IDs und Root IDs sind nur innerhalb einer Organisation einzigartig. Dies bedeutet, dass keine zwei Organisationen dieselbe Organisations-ID verwenden. Eine andere Organisation verfügt jedoch möglicherweise über eine Organisationseinheit oder ein Stammverzeichnis mit derselben ID wie Ihre. Es wird empfohlen, immer die Organisations-ID anzugeben, wenn Sie eine Organisationseinheit oder ein Stammverzeichnis angeben.
Die folgende Bedingung gilt beispielsweise `true` für Principals in Konten, die direkt mit der Organisationseinheit verknüpft sind, aber nicht in der untergeordneten `ou-ab12-22222222` OUs Organisationseinheit.
```
"Condition" : { "ForAnyValue:StringEquals" : {
"aws:PrincipalOrgPaths":["o-a1b2c3d4e5/r-ab12/ou-ab12-11111111/ou-ab12-22222222/"]
}}
```
Die folgende Bedingung gilt `true` für Hauptbenutzer in einem Konto, das direkt mit der Organisationseinheit oder einem ihrer untergeordneten Unternehmen verknüpft ist. OUs Wenn Sie einen Platzhalter hinzufügen, müssen Sie den `StringLike`-Bedingungsoperator verwenden.
```
"Condition" : { "ForAnyValue:StringLike" : {
"aws:PrincipalOrgPaths":["o-a1b2c3d4e5/r-ab12/ou-ab12-11111111/ou-ab12-22222222/*"]
}}
```
Die folgende Bedingung gilt `true` für Hauptkunden in einem Konto, das direkt mit einer der untergeordneten Organisationseinheiten verknüpft ist OUs, jedoch nicht direkt mit der übergeordneten Organisationseinheit. Die vorherige Bedingung gilt für die Organisationseinheit oder für untergeordnete Elemente. Die folgende Bedingung gilt nur für untergeordnete Elemente (und für untergeordnete Elemente dieser Kinder).
```
"Condition" : { "ForAnyValue:StringLike" : {
"aws:PrincipalOrgPaths":["o-a1b2c3d4e5/r-ab12/ou-ab12-11111111/ou-ab12-22222222/ou-*"]
}}
```
Die folgende Bedingung ermöglicht den Zugriff für jeden Auftraggeber in der `o-a1b2c3d4e5`-Organisation, unabhängig von der übergeordneten Organisationseinheit.
```
"Condition" : { "ForAnyValue:StringLike" : {
"aws:PrincipalOrgPaths":["o-a1b2c3d4e5/*"]
}}
```
`aws:PrincipalOrgPaths` ist ein mehrwertiger Bedingungsschlüssel. Mehrwertige Bedingungsschlüssel können im Anforderungskontext mehrere Werte haben. Wenn Sie mehrere Werte mit dem `ForAnyValue`-Bedingungsoperator verwenden, muss der Pfad des Auftraggebers mit einem der in der Richtlinie aufgeführten Pfade übereinstimmen. Weitere Hinweise zu mehrwertigen Bedingungsschlüsseln finden Sie unter [Operatoren für mehrwertige Kontextschlüssel festlegen](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys).
```
"Condition": {
"ForAnyValue:StringLike": {
"aws:PrincipalOrgPaths": [
"o-a1b2c3d4e5/r-ab12/ou-ab12-33333333/*",
"o-a1b2c3d4e5/r-ab12/ou-ab12-22222222/*"
]
}
}
```
### aws:PrincipalOrgID
Verwenden Sie diesen Schlüssel, um die ID der Organisation, AWS Organizations zu der der anfordernde Principal gehört, mit der in der Richtlinie angegebenen ID zu vergleichen.
+ **Verfügbarkeit** – Dieser Schlüssel ist nur dann im Anforderungskontext enthalten, wenn der Auftraggeber Mitglied einer Organisation ist. Anonyme Anforderungen enthalten diesen Schlüssel nicht.
+ **Datentyp** – [Zeichenfolge](reference_policies_elements_condition_operators.md#Conditions_String)
+ **Werttyp** - Einzelwertig
Dieser globale Schlüssel bietet eine Alternative zur Auflistung aller Konten IDs für alle AWS Konten in einer Organisation. Sie können diesen Bedingungsschlüssel verwenden, um das Angeben des Elements `Principal` in einer [resource-based-Richtlinie](access_policies_identity-vs-resource.md) zu vereinfachen. Sie können die [Organisations-ID](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_details.html) im Bedingungselement angeben. Wenn Sie Konten hinzufügen und entfernen, schließen Richtlinien, die den `aws:PrincipalOrgID`-Schlüssel enthalten, automatisch die richtigen Konten ein und müssen nicht manuell aktualisiert werden.
Mit der folgenden Amazon S3-Bucket-Richtlinie können beispielsweise Mitglieder aller Konten in der Organisation `o-xxxxxxxxxxx` ein Objekt in den Bucket `amzn-s3-demo-bucket` einfügen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Sid": "AllowPutObject",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
"Condition": {"StringEquals":
{"aws:PrincipalOrgID":"o-xxxxxxxxxxx"}
}
}
}
```
------
**Anmerkung**
Diese globale Bedingung gilt auch für das Masterkonto einer AWS -Organisation. Diese Richtlinie verhindert, dass alle Hauptbenutzer außerhalb der angegebenen Organisation auf den Amazon-S3-Bucket zugreifen können. Dazu gehören alle AWS Dienste, die mit Ihren internen Ressourcen interagieren, z. B. das AWS CloudTrail Senden von Protokolldaten an Ihre Amazon S3 S3-Buckets. Informationen dazu, wie Sie auf sichere Weise Zugriff auf AWS Dienste gewähren können, finden Sie unter[aws:PrincipalIsAWSService](#condition-keys-principalisawsservice).
Weitere Informationen zu AWS Organizations finden Sie unter [Was ist AWS Organizations?](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) im *AWS Organizations Benutzerhandbuch*.
### aws:PrincipalTag/*tag-key*
Verwenden Sie diesen Schlüssel, um das Tag, das dem Auftraggeber angefügt ist, der die Anforderung stellt, mit dem Tag zu vergleichen, das Sie in der Richtlinie angeben. Wenn dem Auftraggeber mehr als ein Tag angefügt ist, enthält der Anforderungskontext einen `aws:PrincipalTag`-Schlüssel für jeden angefügten Tag-Schlüssel.
+ **Availability (Verfügbarkeit)** – Dieser Schlüssel ist nur dann im Anforderungskontext enthalten, wenn der Auftraggeber ein IAM-Benutzer mit angefügten Tags ist. Er ist für einen Auftraggeber enthalten, der eine IAM-Rolle mit angefügten Tags oder [Sitzungs-Tags](id_session-tags.md) verwendet. Anonyme Anforderungen enthalten diesen Schlüssel nicht.
+ **Datentyp** – [Zeichenfolge](reference_policies_elements_condition_operators.md#Conditions_String)
+ **Werttyp** - Einzelwertig
Sie können einem Benutzer oder einer Rolle benutzerdefinierte Attribute in Form eines Schlüssel-Wert-Paares hinzufügen. Weitere Informationen zur Verwendung von Tags in IAM finden Sie unter [Tags für AWS Identity and Access Management Ressourcen](id_tags.md). Sie können `aws:PrincipalTag` für die [Zugriffskontrolle](access_iam-tags.md#access_iam-tags_control-principals) für AWS -Auftraggeber einsetzen.
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen können, die es Benutzern mit dem Tag **department=hr** erlaubt, IAM-Benutzer, -Gruppen oder -Rollen zu verwalten. Um diese Richtlinie zu verwenden, ersetzen Sie die Richtlinie *italicized placeholder text* im Beispiel durch Ihre eigenen Informationen. Befolgen Sie dann die Anweisungen unter [Erstellen einer Richtlinie](access_policies_create.md) oder [Bearbeiten einer Richtlinie](access_policies_manage-edit.md).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:Get*",
"iam:List*",
"iam:Generate*"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:PrincipalTag/department": "hr"
}
}
}
]
}
```
------
### aws:PrincipalIsAWSService
Verwenden Sie diese Taste, um zu überprüfen, ob der Anruf an Ihre Ressource direkt von einem AWS [Service Principal](reference_policies_elements_principal.md#principal-services) getätigt wird. Zum Beispiel verwendet AWS CloudTrail den Service-Prinzipal `cloudtrail.amazonaws.com`, um Protokolle in Ihr Amazon S3-Bucket zu schreiben. Der Anforderungskontextschlüssel wird auf true festgelegt, wenn ein Dienst einen Dienstauftraggeber verwendet, um eine direkte Aktion für Ihre Ressourcen auszuführen. Der Kontextschlüssel wird auf false gesetzt, wenn der Dienst die Anmeldeinformationen eines IAM-Auftraggeber verwendet, um eine Anforderung im Namen des Auftraggeber zu stellen. Sie wird auch verweigert, wenn der Service eine [Servicerolle oder eine serviceverknüpfte Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#id_roles_terms-and-concepts) verwendet, um einen Aufruf im Auftrag des Prinzipals durchzuführen.
+ **Verfügbarkeit** – Dieser Schlüssel ist im Anforderungskontext aller signierten API-Anforderungen vorhanden, die AWS -Anmeldeinformationen. Anonyme Anforderungen enthalten diesen Schlüssel nicht.
+ **Datentyp** – [boolesch](reference_policies_elements_condition_operators.md#Conditions_Boolean)
+ **Werttyp** - Einzelwertig
Sie können diesen Bedingungsschlüssel verwenden, um den Zugriff auf Ihre vertrauenswürdigen Identitäten und erwarteten Netzwerkadressen zu beschränken und gleichzeitig sicheren Zugriff auf AWS Dienste zu gewähren.
Im folgenden Beispiel für eine Amazon S3 S3-Bucket-Richtlinie ist der Zugriff auf den Bucket eingeschränkt, es sei denn, die Anfrage stammt von einem Service Principal `vpc-111bbb22` oder stammt von einem Service Principal, wie CloudTrail z.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ExpectedNetworkServicePrincipal",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket1/AWS Logs/AccountNumber/*",
"Condition": {
"StringNotEqualsIfExists": {
"aws:SourceVpc": "vpc-111bbb22"
},
"BoolIfExists": {
"aws:PrincipalIsAWSService": "false"
}
}
}
]
}
```
------
Im folgenden Video erfahren Sie mehr darüber, wie Sie den Bedingungsschlüssel `aws:PrincipalIsAWSService` in einer Richtlinie verwenden können.
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/gv-_H8a42G4)
### aws:PrincipalServiceName
Verwenden Sie diesen Schlüssel, um den [Dienstauftraggeber](reference_policies_elements_principal.md#principal-services)-Namen in der Richtlinie mit dem Dienstauftraggeber zu vergleichen, der Anforderungen an Ihre Ressourcen stellt. Sie können diesen Schlüssel verwenden, um zu überprüfen, ob dieser Aufruf von einem bestimmten Dienstauftraggeber erfolgt. Wenn ein Dienstauftraggeber eine direkte Anforderung an Ihre Ressource stellt, enthält der `aws:PrincipalServiceName`-Schlüssel den Namen des Dienstauftraggebers. Der AWS CloudTrail Dienstprinzipalname lautet beispielsweise`cloudtrail.amazonaws.com`.
+ **Verfügbarkeit** — Dieser Schlüssel ist in der Anfrage enthalten, wenn der Anruf von einem AWS Dienstprinzipal getätigt wird. Dieser Schlüssel ist in keiner anderen Situation vorhanden, einschließlich der folgenden:
+ Sie wird auch verweigert, wenn der [Service eine Servicerolle oder eine serviceverknüpfte Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#id_roles_terms-and-concepts) verwendet, um einen Aufruf im Auftrag des Prinzipals durchzuführen.
+ Wenn der Dienst die Anmeldeinformationen eines IAM-Auftraggebers verwendet, um eine Anforderung im Namen des Auftraggebers zu stellen.
+ Wenn der Anruf direkt von einem IAM-Auftraggeber getätigt wird.
+ Wenn der Anruf von einem anonymen Antragsteller getätigt wird.
+ **Datentyp** – [Zeichenfolge](reference_policies_elements_condition_operators.md#Conditions_String)
+ **Werttyp** - Einzelwertig
Sie können diesen Bedingungsschlüssel verwenden, um den Zugriff auf Ihre vertrauenswürdigen Identitäten und erwarteten Netzwerkstandorte zu beschränken und gleichzeitig den Zugriff auf einen AWS Dienst sicher zu gewähren.
Im folgenden Beispiel für eine Amazon S3 S3-Bucket-Richtlinie ist der Zugriff auf den Bucket eingeschränkt, es sei denn, die Anfrage stammt von einem Service Principal `vpc-111bbb22` oder stammt von einem Service Principal, wie CloudTrail z.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ExpectedNetworkServicePrincipal",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket1/AWS Logs/AccountNumber/*",
"Condition": {
"StringNotEqualsIfExists": {
"aws:SourceVpc": "vpc-111bbb22",
"aws:PrincipalServiceName": "cloudtrail.amazonaws.com"
}
}
}
]
}
```
------
### aws:PrincipalServiceNamesList
Dieser Schlüssel enthält eine Liste aller[-Dienstauftraggeber](reference_policies_elements_principal.md#principal-services)Namen, die zum Dienst gehören. Dies ist ein erweiterter Bedingungsschlüssel. Sie können damit den Service daran hindern, nur von einer bestimmten Region aus auf Ihre Ressource zuzugreifen. Einige Dienste können regionale Dienstauftraggeber erstellen, um eine bestimmte Instance des Dienstes innerhalb einer bestimmten Region anzugeben. Sie können den Zugriff auf eine Ressource auf eine bestimmte Instance des Dienstes beschränken. Wenn ein Dienstauftraggeber eine direkte Anforderung an Ihre Ressource stellt, enthält der `aws:PrincipalServiceNamesList` eine ungeordnete Liste aller Dienst-Auftraggebernamen, die mit der regionalen Instance des Dienstes verbunden sind.
+ **Verfügbarkeit** — Dieser Schlüssel ist in der Anfrage enthalten, wenn der Anruf von einem AWS Service Principal getätigt wird. Dieser Schlüssel ist in keiner anderen Situation vorhanden, einschließlich der folgenden:
+ Sie wird auch verweigert, wenn der [Service eine Servicerolle oder eine serviceverknüpfte Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#id_roles_terms-and-concepts) verwendet, um einen Aufruf im Auftrag des Prinzipals durchzuführen.
+ Wenn der Dienst die Anmeldeinformationen eines IAM-Auftraggebers verwendet, um eine Anforderung im Namen des Auftraggebers zu stellen.
+ Wenn der Anruf direkt von einem IAM-Auftraggeber getätigt wird.
+ Wenn der Anruf von einem anonymen Antragsteller getätigt wird.
+ **Datentyp** – [Zeichenfolge](reference_policies_elements_condition_operators.md#Conditions_String) (Liste)
+ **Werttyp** - Mehrwertig
`aws:PrincipalServiceNamesList` ist ein mehrwertiger Bedingungsschlüssel. Mehrwertige Bedingungsschlüssel können im Anforderungskontext mehrere Werte haben. Sie müssen die Set-Operatoren `ForAnyValue` oder `ForAllValues` zusammen mit [String-Bedingungsoperatoren](reference_policies_elements_condition_operators.md#Conditions_String) für diesen Schlüssel verwenden. Weitere Hinweise zu mehrwertigen Bedingungsschlüsseln finden Sie unter [Operatoren für mehrwertige Kontextschlüssel festlegen](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys).
### aws:PrincipalType
Verwenden Sie diesen Schlüssel, um den Typ des Auftraggebers, der die Anforderung stellt, mit dem Auftraggebertyp zu vergleichen, den Sie in der Richtlinie angeben. Weitere Informationen finden Sie unter [So legen Sie einen Prinzipal fest](reference_policies_elements_principal.md#Principal_specifying). Für konkrete Beispiele von `principal`-Schlüsselwerten, siehe [Auftraggeber-Schlüsselwerte](reference_policies_variables.md#principaltable).
+ **Verfügbarkeit** – Dieser Schlüssel ist im Anforderungskontext für alle Anforderungen, einschließlich anonymer Anforderungen, enthalten.
+ **Datentyp** – [Zeichenfolge](reference_policies_elements_condition_operators.md#Conditions_String)
+ **Werttyp** - Einzelwertig
### aws:userid
Verwenden Sie diesen Schlüssel, um die Auftraggeber-ID des Anforderers mit der ID zu vergleichen, die Sie in der Richtlinie angeben. Bei IAM-Benutzern ist der Anforderungskontextwert die Benutzer-ID. Bei IAM-Rollen kann dieses Werteformat variieren. Weitere Informationen dazu, wie die Informationen für verschiedene Auftraggeber angezeigt werden, finden Sie unter [So legen Sie einen Prinzipal fest](reference_policies_elements_principal.md#Principal_specifying). Für konkrete Beispiele von `principal`-Schlüsselwerten, siehe [Auftraggeber-Schlüsselwerte](reference_policies_variables.md#principaltable).
+ **Verfügbarkeit** – Dieser Schlüssel ist im Anforderungskontext für alle Anforderungen, einschließlich anonymer Anforderungen, enthalten.
+ **Datentyp** – [Zeichenfolge](reference_policies_elements_condition_operators.md#Conditions_String)
+ **Werttyp** - Einzelwertig
### aws:username
Verwenden Sie diesen Schlüssel, um den Benutzernamen des Anforderers mit dem Benutzernamen zu vergleichen, den Sie in der Richtlinie angeben. Weitere Informationen dazu, wie die Informationen für verschiedene Auftraggeber angezeigt werden, finden Sie unter [So legen Sie einen Prinzipal fest](reference_policies_elements_principal.md#Principal_specifying). Für konkrete Beispiele von `principal`-Schlüsselwerten, siehe [Auftraggeber-Schlüsselwerte](reference_policies_variables.md#principaltable).
+ **Verfügbarkeit** – Dieser Schlüssel ist immer im Anforderungskontext für IAM-Benutzer enthalten. Anonyme Anfragen und Anfragen, die mithilfe der Rollen Root-Benutzer des AWS-Kontos oder IAM gestellt werden, enthalten diesen Schlüssel nicht. Anforderungen, die mit IAM Identity Center-Anmeldeinformationen gestellt werden, enthalten diesen Schlüssel nicht im Kontext.
+ **Datentyp** – [Zeichenfolge](reference_policies_elements_condition_operators.md#Conditions_String)
+ **Werttyp** - Einzelwertig
## Eigenschaften einer Rollensitzung
Verwenden Sie die folgenden Bedingungsschlüssel, um Eigenschaften der Rollensitzung zum Zeitpunkt der Sitzungsgenerierung zu vergleichen. Diese Bedingungsschlüssel sind nur verfügbar, wenn eine Anfrage von einem Prinzipal mit Rollensitzungs- oder Verbundbenutzer-Prinzipal-Anmeldeinformationen gestellt wird. Die Werte für diese Bedingungsschlüssel sind im Sitzungstoken der Rolle eingebettet.
Eine [Rolle](reference_policies_elements_principal.md#principal-roles) ist eine Art Prinzipal. Sie können die Bedingungsschlüssel aus dem Abschnitt [Eigenschaften des Prinzipals](#condition-keys-principal-properties) auch verwenden, um die Eigenschaften einer Rolle auszuwerten, wenn eine Rolle eine Anfrage stellt.
### aws:AssumedRoot
Verwenden Sie diesen Schlüssel, um zu überprüfen, ob die Anfrage mithilfe von [AssumeRoot](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoot.html)gestellt wurde. `AssumeRoot`gibt kurzfristige Anmeldeinformationen für eine privilegierte Root-Benutzersitzung zurück, mit der Sie privilegierte Aktionen für Mitgliedskonten in Ihrer Organisation ausführen können. Weitere Informationen finden Sie unter [Root-Zugriff für Mitgliedskonten zentral verwalten](id_root-user.md#id_root-user-access-management).
+ **Verfügbarkeit** — Dieser Schlüssel ist nur dann im Anforderungskontext enthalten, wenn der Principal die Anmeldeinformationen von verwendet [AssumeRoot](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoot.html), um die Anfrage zu stellen.
+ **Datentyp** – [boolesch](reference_policies_elements_condition_operators.md#Conditions_Boolean)
+ **Werttyp** - Einzelwertig
Im folgenden Beispiel wird bei Verwendung als Dienststeuerungsrichtlinie die Verwendung der langfristigen Anmeldeinformationen eines Root-Benutzers in einem AWS Organizations Mitgliedskonto verweigert. Die Richtlinie verhindert nicht, dass `AssumeRoot`-Sitzungen die von einer `AssumeRoot`-Sitzung zugelassenen Aktionen ausführen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Deny",
"Action":"*",
"Resource": "*",
"Condition":{
"ArnLike":{
"aws:PrincipalArn":[
"arn:aws:iam::*:root"
]
},
"Null":{
"aws:AssumedRoot":"true"
}
}
}
]
}
```
------
### aws:FederatedProvider
Verwenden Sie diesen Schlüssel, um die Auftraggeber-ID des Anforderers (IdP) mit der ID zu vergleichen, die Sie in der Richtlinie angeben. Das bedeutet, dass mithilfe des Vorgangs eine IAM-Rolle übernommen wurde. [https://docs.aws.amazon.com//STS/latest/APIReference/API_AssumeRoleWithWebIdentity](https://docs.aws.amazon.com//STS/latest/APIReference/API_AssumeRoleWithWebIdentity) AWS STS Wenn die temporären Anmeldeinformationen der resultierenden Rollensitzung verwendet werden, um eine Anforderung zu stellen, identifiziert der Anforderungskontext den IdP, der die ursprüngliche Verbundidentität authentifiziert hat.
+ **Verfügbarkeit** – Dieser Schlüssel ist in der Rollensitzung einer Rolle vorhanden, die mithilfe eines OpenID Connect (OIDC)-Anbieters übernommen wurde, sowie in der Rollenvertrauensrichtlinie, wenn ein OIDC-Anbieter zum Aufrufen von `AssumeRoleWithWebIdentity` verwendet wird.
+ **Datentyp** – [Zeichenfolge](reference_policies_elements_condition_operators.md#Conditions_String)\$1
+ **Werttyp** - Einzelwertig
\$1 Der Datentyp hängt von Ihrem IDP ab:
+ **Wenn Sie einen integrierten AWS IdP wie [Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html) verwenden, ist der Schlüsselwert eine Zeichenfolge.** Der Schlüsselwert kann wie folgt aussehen: `cognito-identity.amazonaws.com`.
+ Wenn Sie einen IdP verwenden, der nicht in [Amazon EKS](https://docs.aws.amazon.com//eks/latest/userguide/associate-service-account-role.html) integriert ist, ist der Schlüsselwert **ARN**. AWS[https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services](https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services) Der Schlüsselwert kann wie folgt aussehen: `arn:aws:iam::111122223333:oidc-provider/oidc.eks.region.amazonaws.com/id/OIDC_Provider_ID`.
Weitere Informationen zu externen IdPs und finden Sie `AssumeRoleWithWebIdentity` unter[Gängige Szenarien](id_federation_common_scenarios.md). Weitere Informationen finden Sie unter [Rollensitzungsgsprinzipale](reference_policies_elements_principal.md#principal-role-session).
### aws:TokenIssueTime
Verwenden Sie diesen Schlüssel, um das Datum und die Uhrzeit der Ausstellung der Sicherheitsanmeldeinformationen mit dem Datum und der Uhrzeit zu vergleichen, das bzw. die Sie in der Richtlinie angeben.
+ **Availability** – Dieser Schlüssel ist nur dann im Anforderungskontext enthalten, wenn der Auftraggeber temporäre Anmeldeinformationen für die Anforderung verwendet. Der Schlüssel ist weder in AWS CLI AWS API- noch in AWS SDK-Anfragen enthalten, die mithilfe von Zugriffsschlüsseln gestellt werden.
+ **Datentyp** – [Datum](reference_policies_elements_condition_operators.md#Conditions_Date)
+ **Werttyp** - Einzelwertig
Informationen darüber, welche Services die Verwendung von temporären Anmeldeinformationen unterstützen, finden Sie unter [AWS Dienste, die mit IAM funktionieren](reference_aws-services-that-work-with-iam.md).
### aws:MultiFactorAuthAge
Verwenden Sie diesen Schlüssel, um die Anzahl der Sekunden, die seit dem Zeitpunkt, zu dem der anfordernde Auftraggeber per MFA autorisiert wurde, verstrichen sind mit der Anzahl, die Sie in der Richtlinie angeben, zu vergleichen. Weitere Informationen zu MFA finden Sie unter [AWS Multi-Faktor-Authentifizierung in IAM](id_credentials_mfa.md).
**Wichtig**
Dieser Bedingungsschlüssel ist nicht für föderierte Identitäten oder Anfragen vorhanden, die mithilfe von Zugriffsschlüsseln zum Signieren von AWS CLI-, AWS API- oder AWS SDK-Anfragen gestellt wurden. Weitere Informationen zum Hinzufügen von MFA-Schutz zu API-Operationen mit temporären Sicherheitsanmeldeinformationen finden Sie unter [Sicherer API-Zugriff mit MFA](id_credentials_mfa_configure-api-require.md).
Um zu überprüfen, ob MFA zur Validierung von IAM-Verbundidentitäten verwendet wird, können Sie die Authentifizierungsmethode von Ihrem Identitätsanbieter AWS als Sitzungs-Tag an übergeben. Details hierzu finden Sie unter [Sitzungs-Tags übergeben AWS STS](id_session-tags.md). Um MFA für Identitäten von IAM Identity Center durchzusetzen, können Sie [Attribute für die Zugriffskontrolle aktivieren](https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-abac.html), um einen SAML-Assertionsantrag mit der Authentifizierungsmethode von Ihrem Identitätsanbieter an IAM Identity Center zu übergeben.
+ **Verfügbarkeit** – Dieser Schlüssel wird nur dann in den Anforderungskontext aufgenommen, wenn der Prinzipal für die Anfrage [temporäre Sicherheitsanmeldeinformationen](id_credentials_temp.md) verwendet. Richtlinien mit MFA-Bedingungen können an Folgendes angefügt werden:
+ Einem IAM-Benutzer oder einer IAM-Gruppe
+ Einer Ressource, wie zum Beispiel ein Amazon S3-Bucket, eine Amazon SQS-Warteschlange oder ein Amazon SNS-Thema
+ Die Vertrauensrichtlinie einer IAM-Rolle, die von einem Benutzer übernommen werden kann
+ **Datentyp** – [Numerisch](reference_policies_elements_condition_operators.md#Conditions_Numeric)
+ **Werttyp** - Einzelwertig
### aws:MultiFactorAuthPresent
Verwenden Sie diesen Schlüssel, um zu überprüfen, ob die Multi-Faktor-Authentifizierung (MFA) zur Validierung der [temporären Sicherheits-Anmeldeinformationen](id_credentials_temp.md) verwendet wurde, über die die Anforderung gestellt wurde.
**Wichtig**
Dieser Bedingungsschlüssel ist nicht für föderierte Identitäten oder Anfragen vorhanden, die mithilfe von Zugriffsschlüsseln zum Signieren von AWS CLI-, AWS API- oder AWS SDK-Anfragen gestellt wurden. Weitere Informationen zum Hinzufügen von MFA-Schutz zu API-Operationen mit temporären Sicherheitsanmeldeinformationen finden Sie unter [Sicherer API-Zugriff mit MFA](id_credentials_mfa_configure-api-require.md).
Um zu überprüfen, ob MFA zur Validierung von IAM-Verbundidentitäten verwendet wird, können Sie die Authentifizierungsmethode von Ihrem Identitätsanbieter AWS als Sitzungs-Tag an übergeben. Details hierzu finden Sie unter [Sitzungs-Tags übergeben AWS STS](id_session-tags.md). Um MFA für Identitäten von IAM Identity Center durchzusetzen, können Sie [Attribute für die Zugriffskontrolle aktivieren](https://docs.aws.amazon.com/singlesignon/latest/userguide/configure-abac.html), um einen SAML-Assertionsantrag mit der Authentifizierungsmethode von Ihrem Identitätsanbieter an IAM Identity Center zu übergeben.
+ **Availability** – Dieser Schlüssel ist nur dann im Anforderungskontext enthalten, wenn der Auftraggeber temporäre Anmeldeinformationen für die Anforderung verwendet. Richtlinien mit MFA-Bedingungen können an Folgendes angefügt werden:
+ Einem IAM-Benutzer oder einer IAM-Gruppe
+ Einer Ressource, wie zum Beispiel ein Amazon S3-Bucket, eine Amazon SQS-Warteschlange oder ein Amazon SNS-Thema
+ Die Vertrauensrichtlinie einer IAM-Rolle, die von einem Benutzer übernommen werden kann
+ **Datentyp** – [boolesch](reference_policies_elements_condition_operators.md#Conditions_Boolean)
+ **Werttyp** - Einzelwertig
Temporäre Anmeldeinformationen werden verwendet, um IAM-Rollen und IAM-Benutzer mit temporären Tokens von oder und Benutzern von [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)zu authentifizieren. [GetSessionToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html) AWS-Managementkonsole
Bei IAM-Benutzerzugriffsschlüsseln handelt es sich um langfristige Anmeldeinformationen. In einigen Fällen werden jedoch temporäre Anmeldeinformationen im Namen von IAM-Benutzern zur Ausführung von Vorgängen AWS erstellt. In diesen Fällen ist der Schlüssel `aws:MultiFactorAuthPresent` in der Anforderung vorhanden und auf einen Wert von `false` gesetzt werden. Es gibt zwei häufige Fälle, in denen dies passieren kann:
+ IAM-Benutzer in der Region verwenden AWS-Managementkonsole unwissentlich temporäre Anmeldeinformationen. Benutzer melden sich mit ihrem Benutzernamen und Passwort bei der Konsole an. Dabei handelt es sich um langfristige Anmeldeinformationen. Im Hintergrund erstellt die Konsole jedoch temporäre Anmeldeinformationen für den Benutzer.
+ Wenn ein IAM-Benutzer einen Dienst aufruft, verwendet der AWS Dienst die Anmeldeinformationen des Benutzers erneut, um eine weitere Anfrage an einen anderen Dienst zu stellen. Zum Beispiel, wenn Sie Athena aufrufen, um auf einen Amazon S3 S3-Bucket zuzugreifen, oder wenn Sie es verwenden, CloudFormation um eine Amazon EC2 EC2-Instance zu erstellen. AWS Verwendet für die nachfolgende Anfrage temporäre Anmeldeinformationen.
Informationen darüber, welche Services die Verwendung von temporären Anmeldeinformationen unterstützen, finden Sie unter [AWS Dienste, die mit IAM funktionieren](reference_aws-services-that-work-with-iam.md).
Der `aws:MultiFactorAuthPresent`-Schlüssel ist nie vorhanden, wenn ein API- oder CLI-Befehl mit langfristigen Anmeldeinformationen wie Zugriffsschlüsselpaare eines Benutzers aufgerufen wird. Wir empfehlen daher, beim Prüfen dieses Schlüssels die Versionen `...IfExists` der Bedingungsoperatoren zu verwenden.
Beachten Sie, dass das folgende `Condition`-Element ***keine*** zuverlässige Methode ist, um zu überprüfen, ob eine Anforderung über MFA authentifiziert wird.
```
##### WARNING: NOT RECOMMENDED #####
"Effect" : "Deny",
"Condition" : { "Bool" : { "aws:MultiFactorAuthPresent" : "false" } }
```
Diese Kombination aus `Deny` Effekt `Bool`-Element und `false`-Wert verweigert Anforderungen, die mit MFA authentifiziert werden können, es aber nicht waren. Dies gilt nur für temporäre Anmeldeinformationen, die die Verwendung von MFA unterstützen. Diese Anweisung verweigert nicht den Zugriff auf Anforderungen, die mit langfristigen Anmeldeinformationen gestellt wurden, oder auf Anforderungen, die per MFA authentifiziert wurden. Verwenden Sie dieses Beispiel mit Vorsicht, da seine Logik kompliziert ist und nicht prüft, ob die MFA-Authentifizierung tatsächlich verwendet wurde.
Verwenden Sie auch nicht die Kombination aus `Deny` Effekt `Null`-Element und `true`, da sie sich genauso verhält und die Logik noch komplizierter ist.
**Empfohlene Kombination**
Wir empfehlen Ihnen, den Operator [`BoolIfExists`](reference_policies_elements_condition_operators.md#Conditions_IfExists) zu verwenden, um zu überprüfen, ob eine Anforderung über MFA authentifiziert wird.
```
"Effect" : "Deny",
"Condition" : { "BoolIfExists" : { "aws:MultiFactorAuthPresent" : "false" } }
```
Diese Kombination aus `Deny`, `BoolIfExists` und `false` verweigert Anforderungen, die nicht mit MFA authentifiziert wurden. Insbesondere lehnt sie Anforderungen von temporären Anmeldeinformationen ab, die keine MFA umfassen. Es lehnt auch Anfragen ab, die mit langfristigen Anmeldeinformationen gestellt werden, wie AWS CLI z. B. AWS API-Operationen, die mithilfe von Zugriffsschlüsseln durchgeführt werden. Der Operator `*IfExists` prüft das Vorhandensein des `aws:MultiFactorAuthPresent`-Schlüssels und ob er vorhanden sein könnte oder nicht, wie durch seine Existenz angezeigt wird. Verwenden Sie diesen Operator, wenn Sie eine Anforderung ablehnen möchten, die nicht über die MFA authentifiziert wird. Dies ist sicherer, kann jedoch jeden Code oder jedes Skript beschädigen, das Zugriffsschlüssel für den Zugriff auf die AWS API AWS CLI oder verwendet.
**Alternative Kombinationen**
Sie können den [`BoolIfExists`](reference_policies_elements_condition_operators.md#Conditions_IfExists)Operator auch verwenden, um MFA-authentifizierte Anfragen AWS CLI und/oder AWS API-Anfragen zuzulassen, die mit langfristigen Anmeldeinformationen gestellt werden.
```
"Effect" : "Allow",
"Condition" : { "BoolIfExists" : { "aws:MultiFactorAuthPresent" : "true" } }
```
Diese Bedingung ist erfüllt, wenn der Schlüssel existiert und vorhanden ist **oder** wenn der Schlüssel nicht vorhanden ist. Diese Kombination aus `Allow`, `BoolIfExists`, und `true` lässt Anforderungen zu, die mit MFA authentifiziert werden, oder Anforderungen, die nicht mit MFA authentifiziert werden können. Das bedeutet AWS CLI, dass AWS API- und AWS SDK-Operationen zulässig sind, wenn der Anforderer seine langfristigen Zugriffsschlüssel verwendet. Diese Kombination erlaubt keine Anforderungen von temporären Anmeldeinformationen, die MFA umfassen könnten, aber keine MFA enthalten.
Wenn Sie eine Richtlinie mit dem visuellen Editor der IAM-Konsole erstellen und **MFA required** (MFA erforderlich), auswählen, wird diese Kombination angewendet. Diese Einstellung erfordert zwar MFA für den Konsolenzugriff, ermöglicht jedoch den programmgesteuerten Zugriff ohne MFA.
Alternativ können Sie den `Bool`-Operator verwenden, damit programmgesteuerte Anforderungen und Konsolenanforderungen nur dann zugelassen werden, wenn sie mit MFA authentifiziert werden.
```
"Effect" : "Allow",
"Condition" : { "Bool" : { "aws:MultiFactorAuthPresent" : "true" } }
```
Diese Kombination aus `Allow`, `Bool` und `true` lässt nur mit MFA authentifizierte Anforderungen zu. Dies gilt nur für temporäre Anmeldeinformationen, die die Verwendung von MFA unterstützen. Diese Anweisung erlaubt keinen Zugriff auf Anforderungen, die mit langfristigen Zugriffsschlüsseln gestellt wurden, oder auf Anforderungen, die mit temporären Anmeldeinformationen ohne MFA durchgeführt wurden.
Verwenden Sie ***keine*** Richtlinie wie die folgende Beispielrichtlinie, um auf das Vorhandensein des MFA-Schlüssels hin zu prüfen:
```
##### WARNING: USE WITH CAUTION #####
"Effect" : "Allow",
"Condition" : { "Null" : { "aws:MultiFactorAuthPresent" : "false" } }
```
Diese Kombination aus `Allow` Effekt, `Null`-Element und `false`-Wert erlaubt nur Anforderungen, die mit MFA authentifiziert werden können, unabhängig davon, ob die Anforderung tatsächlich authentifiziert ist. Dies ermöglicht alle Anforderungen, die mit temporären Anmeldeinformationen gestellt werden, und verweigert den Zugriff mit langfristigen Anmeldeinformationen. Verwenden Sie dieses Beispiel mit Vorsicht, da es nicht prüft, ob die MFA-Authentifizierung tatsächlich verwendet wurde.
### aws:ChatbotSourceArn
Verwenden Sie diesen Schlüssel, um die vom Prinzipal festgelegte Quell-Chat-Konfigurations-ARN mit der Chat-Konfigurations-ARN zu vergleichen, die Sie in der Richtlinie der IAM-Rolle angeben, die Ihrer Kanalkonfiguration zugeordnet ist. Sie können Anfragen basierend auf der von Amazon Q Developer in Chat-Anwendungen initiierten Rollensitzung autorisieren.
+ **Verfügbarkeit** – Dieser Schlüssel wird vom Amazon Q Developer-Service in Chat-Anwendungen immer dann in den Anfragekontext aufgenommen, wenn eine Rollensitzung angenommen wird. Der Schlüsselwert ist die Chat-Konfigurations-ARN, z. B. bei der [Ausführung eines AWS CLI -Befehls aus einem Chat-Kanal](https://docs.aws.amazon.com/chatbot/latest/adminguide/chatbot-cli-commands.html).
+ **Datentyp** – [ARN](reference_policies_elements_condition_operators.md#Conditions_ARN)
+ **Werttyp** - Einzelwertig
+ **Beispielwert:** – `arn:aws::chatbot::123456789021:chat-configuration/slack-channel/private_channel`
Die folgende Richtlinie verweigert Amazon-S3-Put-Anfragen für den angegebenen Bucket für alle Anfragen, die von einem Slack-Kanal stammen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ExampleS3Deny",
"Effect": "Deny",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
"Condition": {
"ArnLike": {
"aws:ChatbotSourceArn": "arn:aws:chatbot::*:chat-configuration/slack-channel/*"
}
}
}
]
}
```
------
### aws:Ec2InstanceSourceVpc
Dieser Schlüssel identifiziert die VPC, an die Amazon-EC2-IAM-Rollen-Anmeldeinformationen übermittelt wurden. Sie können diesen Schlüssel in einer Richtlinie mit dem [`aws:SourceVPC`](#condition-keys-sourcevpc)globalen Schlüssel verwenden, um zu überprüfen, ob ein Anruf von einer VPC (`aws:SourceVPC`) aus getätigt wird, die der VPC entspricht, an die die Anmeldeinformation übermittelt wurden (`aws:Ec2InstanceSourceVpc`).
+ **Verfügbarkeit** – Dieser Schlüssel ist immer dann im Anforderungskontext enthalten, wenn der Anforderer Anforderungen mit einer Amazon EC2-Rollen-Anmeldeinformation signiert. Er kann in IAM-Richtlinien, Service-Control-Richtlinien, VPC-Endpunkt-Richtlinien und Ressourcenrichtlinien verwendet werden.
+ **Datentyp** – [Zeichenfolge](reference_policies_elements_condition_operators.md#Conditions_String)
+ **Werttyp** - Einzelwertig
Dieser Schlüssel kann mit VPC-Identifikationswerten verwendet werden, ist jedoch am nützlichsten, wenn er als Variable in Kombination mit dem `aws:SourceVpc`-Kontextschlüssel verwendet wird. Dieser `aws:SourceVpc`-Kontextschlüssel ist nur dann im Anforderungskontext enthalten, wenn der Anforderer einen VPC-Endpunkt für die Anforderung verwendet. Die Verwendung von `aws:Ec2InstanceSourceVpc` mit `aws:SourceVpc` ermöglicht eine `aws:Ec2InstanceSourceVpc` breitere Verwendung, da Werte verglichen werden, die sich normalerweise zusammen ändern.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "RequireSameVPC",
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:SourceVpc": "${aws:Ec2InstanceSourceVpc}"
},
"Null": {
"ec2:SourceInstanceARN": "false"
},
"BoolIfExists": {
"aws:ViaAWSService": "false"
}
}
}
]
}
```
------
Im obigen Beispiel wird der Zugriff verweigert, wenn der `aws:SourceVpc`-Wert nicht dem `aws:Ec2InstanceSourceVpc`-Wert entspricht. Die Richtlinienerklärung ist nur auf Rollen beschränkt, die als Amazon EC2-Instance-Rollen verwendet werden, indem getestet wird, ob der `ec2:SourceInstanceARN`-Bedingungsschlüssel vorhanden ist.
Die Richtlinie ermöglicht `aws:ViaAWSService` die Autorisierung von Anfragen AWS , wenn Anfragen im Namen Ihrer Amazon EC2 EC2-Instance-Rollen gestellt werden. Wenn Sie beispielsweise eine Anfrage von einer Amazon EC2 EC2-Instance an einen verschlüsselten Amazon S3-Bucket stellen, ruft Amazon S3 in Ihrem Namen AWS KMS an. Einige der Schlüssel sind nicht vorhanden, wenn die Anfrage an AWS KMS gestellt wird.
### aws:Ec2InstanceSourcePrivateIPv4
Dieser Schlüssel identifiziert die private IPv4-Adresse der primären elastischen Netzwerk-Schnittstelle, an die die Amazon EC2-IAM-Rollen-Anmeldeinformation übermittelt wurde. Sie müssen diesen Bedingungsschlüssel zusammen mit dem zugehörigen Schlüssel `aws:Ec2InstanceSourceVpc` verwenden, um sicherzustellen, dass Sie über eine global eindeutige Kombination aus VPC-ID und privater Quell-IP verfügen. Verwenden Sie diesen Schlüssel mit `aws:Ec2InstanceSourceVpc`, um sicherzustellen, dass eine Anfrage von derselben privaten IP-Adresse aus gestellt wurde, an die die Anmeldeinformation übermittelt wurde.
+ **Verfügbarkeit** – Dieser Schlüssel ist immer dann im Anforderungskontext enthalten, wenn der Anforderer Anforderungen mit einer Amazon EC2-Rollen-Anmeldeinformation signiert. Er kann in IAM-Richtlinien, Service-Control-Richtlinien, VPC-Endpunkt-Richtlinien und Ressourcenrichtlinien verwendet werden.
+ **Datentyp** – [IP-Adresse](reference_policies_elements_condition_operators.md#Conditions_IPAddress)
+ **Werttyp** - Einzelwertig
**Wichtig**
Dieser Schlüssel sollte nicht alleine in einer `Allow`-Anweisung verwendet werden. Private IP-Adressen sind per Definition nicht global eindeutig. Sie sollten den `aws:Ec2InstanceSourceVpc`-Schlüssel jedes Mal verwenden, wenn Sie den `aws:Ec2InstanceSourcePrivateIPv4`-Schlüssel verwenden, um die VPC anzugeben, von der aus Ihre Amazon EC2-Instance-Anmeldeinformation verwendet werden kann.
Das folgende Beispiel ist eine Service Control Policy (SCP), die den Zugriff auf alle Ressourcen verweigert, sofern die Anfrage nicht über einen VPC-Endpunkt in derselben VPC wie die Rollenanmeldeinformationen eingeht. In diesem Beispiel beschränkt `aws:Ec2InstanceSourcePrivateIPv4` die Quelle der Anmeldeinformationen auf eine bestimmte Instance basierend auf der Quell-IP.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:Ec2InstanceSourceVpc": "${aws:SourceVpc}"
},
"Null": {
"ec2:SourceInstanceARN": "false"
},
"BoolIfExists": {
"aws:ViaAWSService": "false"
}
}
},
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:Ec2InstanceSourcePrivateIPv4": "${aws:VpcSourceIp}"
},
"Null": {
"ec2:SourceInstanceARN": "false"
},
"BoolIfExists": {
"aws:ViaAWSService": "false"
}
}
}
]
}
```
------
### aws:SourceIdentity
Verwenden Sie diesen Schlüssel, um die Queltidentität, die vom Auftraggeber festgelegt wurde, mit der Quellidentität zu vergleichen, die Sie in der Richtlinie angeben.
+ **Verfügbarkeit** — Dieser Schlüssel wird in den Anforderungskontext aufgenommen, nachdem eine Quellidentität festgelegt wurde, wenn eine Rolle mithilfe eines AWS STS Assume-Role-CLI-Befehls oder einer AWS STS `AssumeRole` API-Operation übernommen wird.
+ **Datentyp** – [Zeichenfolge](reference_policies_elements_condition_operators.md#Conditions_String)
+ **Werttyp** - Einzelwertig
Sie können diesen Schlüssel in einer Richtlinie verwenden, um Aktionen AWS von Prinzipalen zuzulassen, die bei der Übernahme einer Rolle eine Quellidentität festgelegt haben. Die Aktivität für die angegebene Quellidentität der Rolle erscheint in [AWS CloudTrail](cloudtrail-integration.md#cloudtrail-integration_signin-tempcreds). Auf diese Weise können Administratoren leichter feststellen, wer oder was Aktionen mit einer Rolle in AWS ausgeführt hat.
Im Gegensatz zu [`sts:RoleSessionName`](reference_policies_iam-condition-keys.md#ck_rolesessionname), nachdem die Quellidentität festgelegt wurde, kann der Wert nicht geändert werden. Es ist im Kontext der Anforderung aller Aktionen vorhanden, die von der Rolle ausgeführt werden. Wenn Sie die Sitzungsanmeldeinformationen verwenden, bleibt der Wert in nachfolgenden Rollensitzungen bestehen, um eine andere Rolle anzunehmen. Die Annahme einer Rolle von einer anderen wird als [Rollenverkettung](id_roles.md#iam-term-role-chaining) bezeichnet.
Der [`sts:SourceIdentity`](reference_policies_iam-condition-keys.md#ck_sourceidentity)Schlüssel ist in der Anfrage enthalten, wenn der Principal zunächst eine Quellidentität festlegt und gleichzeitig eine Rolle mithilfe eines AWS STS Assume-Role-CLI-Befehls oder einer AWS STS `AssumeRole` API-Operation annimmt. Der Schlüssel `aws:SourceIdentity` ist in der Anforderung für alle Aktionen vorhanden, die mit einer Rollensitzung durchgeführt werden, für die eine Quellidentität festgelegt wurde.
Die folgende Rollen-Vertrauensrichtlinie für `CriticalRole` im Konto `111122223333` enthält eine Bedingung für `aws:SourceIdentity`, die verhindert, dass ein Auftraggeber ohne eine Quellidentität, die auf Saanvi oder Diego eingestellt ist, die Rolle übernehmen kann.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AssumeRoleIfSourceIdentity",
"Effect": "Allow",
"Principal": {"AWS": "arn:aws:iam::123456789012:role/CriticalRole"},
"Action": [
"sts:AssumeRole",
"sts:SetSourceIdentity"
],
"Condition": {
"StringLike": {
"aws:SourceIdentity": ["Saanvi","Diego"]
}
}
}
]
}
```
------
Weitere Informationen zur Verwendung von Quellidentitätsinformationen finden Sie unter [Überwachen und Steuern von Aktionen mit übernommenen Rollen](id_credentials_temp_control-access_monitor.md).
### ec2:RoleDelivery
Verwenden Sie diesen Schlüssel, um die Version des Instance-Metadaten-Service in der signierten Anfrage mit den Anmeldeinformationen für die IAM-Rolle für Amazon EC2 zu vergleichen. Der Instanz-Metadatendienst unterscheidet zwischen IMDSv1 und IMDSv2 Anfragen danach, ob für eine bestimmte Anfrage entweder die `GET` Header `PUT` oder, die eindeutig sind, in dieser Anfrage vorhanden sind. IMDSv2
+ **Verfügbarkeit** – Dieser Schlüssel wird in den Anforderungskontext aufgenommen, wenn die Rollensitzung von einer Amazon-EC2-Instance erstellt wird.
+ **Datentyp** – [Numerisch](reference_policies_elements_condition_operators.md#Conditions_Numeric)
+ **Werttyp** - Einzelwertig
+ **Beispielwerte** – 1,0, 2,0
Sie können den Instanz-Metadatendienst (IMDS) für jede Instanz so konfigurieren, dass lokaler Code oder Benutzer ihn verwenden müssen. IMDSv2 Wenn Sie angeben, dass dieser verwendet werden IMDSv2 muss, funktioniert das nicht IMDSv1 mehr.
+ Instance Metadata Service Version 1 (IMDSv1) — Eine Anforderungs-/Antwortmethode
+ Instanz-Metadatendienst Version 2 (IMDSv2) — eine sitzungsorientierte Methode
Informationen zur Konfiguration der zu verwendenden Instanz finden Sie unter [Konfiguration der IMDSv2 Optionen für Instanz-Metadaten](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html).
Im folgenden Beispiel wird der Zugriff verweigert, wenn der RoleDelivery Wert ec2: im Anforderungskontext 1,0 (IMDSv1) ist. Diese Richtlinienanweisung kann allgemein angewendet werden, da sie keine Auswirkungen hat, wenn die Anfrage nicht mit Amazon-EC2-Rollen-Anmeldeinformationen signiert ist.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "RequireAllEc2RolesToUseV2",
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"NumericLessThan": {
"ec2:RoleDelivery": "2.0"
}
}
}
]
}
```
------
Weitere Informationen finden Sie unter [Beispielrichtlinien für die Arbeit mit Instance-Metadaten](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ExamplePolicies_EC2.html#iam-example-instance-metadata).
### ec2:SourceInstanceArn
Verwenden Sie diesen Schlüssel, um den ARN der Instance zu vergleichen, aus der die Sitzung der Rolle generiert wurde.
+ **Verfügbarkeit** – Dieser Schlüssel wird in den Anforderungskontext aufgenommen, wenn die Rollensitzung von einer Amazon-EC2-Instance erstellt wird.
+ **Datentyp** – [ARN](reference_policies_elements_condition_operators.md#Conditions_ARN)
+ **Werttyp** - Einzelwertig
+ **Beispielwert** — arn:aws:ec2:us-west- 2:111111111111:instance/instance-id
Richtlinienbeispiele finden Sie unter [Erlauben einer bestimmten Instance, Ressourcen in anderen AWS -Services anzuzeigen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ExamplePolicies_EC2.html#iam-example-source-instance).
### glue:RoleAssumedBy
Der AWS Glue Service legt diesen Bedingungsschlüssel für jede AWS API-Anfrage fest, bei der eine Anfrage mithilfe einer Servicerolle im Namen des Kunden gestellt AWS Glue wird (nicht durch einen Job- oder Entwickler-Endpunkt, sondern direkt durch den Service). AWS Glue Verwenden Sie diesen Schlüssel, um zu überprüfen, ob ein Anruf an eine AWS Ressource vom AWS Glue Dienst kam.
+ **Verfügbarkeit** — Dieser Schlüssel ist im Anforderungskontext enthalten, AWS Glue wenn eine Anfrage mithilfe einer Servicerolle im Namen des Kunden gestellt wird.
+ **Datentyp** – [Zeichenfolge](reference_policies_elements_condition_operators.md#Conditions_String)
+ **Werttyp** - Einzelwertig
+ **Beispielwert** – Dieser Schlüssel ist immer auf `glue.amazonaws.com` festgelegt.
Das folgende Beispiel fügt eine Bedingung hinzu, die es dem AWS Glue Service ermöglicht, ein Objekt aus einem Amazon S3 S3-Bucket abzurufen.
```
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
"Condition": {
"StringEquals": {
"glue:RoleAssumedBy": "glue.amazonaws.com"
}
}
}
```
### glue:CredentialIssuingService
Der AWS Glue Service legt diesen Schlüssel für jede AWS API-Anfrage fest und verwendet dabei eine Servicerolle, die von einem Job- oder Entwickler-Endpunkt stammt. Verwenden Sie diesen Schlüssel, um zu überprüfen, ob ein Aufruf einer AWS Ressource von einem AWS Glue Job- oder Entwickler-Endpunkt aus erfolgte.
+ **Verfügbarkeit** — Dieser Schlüssel ist im Anforderungskontext enthalten, wenn eine AWS Glue Anfrage gestellt wird, die von einem Job- oder Entwickler-Endpunkt kommt.
+ **Datentyp** – [Zeichenfolge](reference_policies_elements_condition_operators.md#Conditions_String)
+ **Werttyp** - Einzelwertig
+ **Beispielwert** – Dieser Schlüssel ist immer auf `glue.amazonaws.com` festgelegt.
Im folgenden Beispiel wird eine Bedingung hinzugefügt, die an eine IAM-Rolle angehängt ist, die von einem AWS Glue Job verwendet wird. Dadurch wird sichergestellt, dass bestimmte Aktionen darauf allowed/denied basieren, ob die Rollensitzung für eine AWS Glue Job-Laufzeitumgebung verwendet wird.
```
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
"Condition": {
"StringEquals": {
"glue:CredentialIssuingService": "glue.amazonaws.com"
}
}
}
```
### codebuild:BuildArn
Dieser Schlüssel identifiziert den CodeBuild Build-ARN, an den die Anmeldeinformationen für die IAM-Rolle übermittelt wurden. Verwenden Sie diesen Schlüssel, um zu überprüfen, ob ein Aufruf einer AWS Ressource von einem bestimmten CodeBuild Build stammt.
**Anmerkung**
Der vollständige Wert von `codebuild:BuildArn` ist nicht im Voraus bekannt, da er die dynamisch generierte Build-ID enthält.
+ **Verfügbarkeit** — Dieser Schlüssel ist immer dann im Anforderungskontext enthalten, wenn eine Anfrage von einer Rolle gestellt wird, die von übernommen wurde CodeBuild.
+ **Datentyp** – [ARN](reference_policies_elements_condition_operators.md#Conditions_ARN)
+ **Werttyp** - Einzelwertig
+ **Beispielwert** — arn:aws:codebuild:us-east- 1:123456789012:build/:12345678-1234-1234-1234-123456789012 MyBuildProject
Das folgende Beispiel ermöglicht einem bestimmten Build den Zugriff auf den angegebenen Bucket. CodeBuild `s3:GetObject`
```
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
"Condition": {
"ArnLike": {
"codebuild:BuildArn": "arn:aws:codebuild:us-east-1:123456789012:build/MyBuildProject:*"
}
}
}
```
### codebuild:ProjectArn
Dieser Schlüssel identifiziert den CodeBuild Projekt-ARN, für den die IAM-Rollenanmeldeinformationen für einen CodeBuild Build bereitgestellt wurden. Verwenden Sie diesen Schlüssel, um zu überprüfen, ob ein Aufruf einer AWS Ressource aus einem bestimmten CodeBuild Projekt stammt.
+ **Verfügbarkeit** — Dieser Schlüssel ist immer dann im Anforderungskontext enthalten, wenn eine Anfrage von einer Rolle gestellt wird, die von übernommen wurde CodeBuild.
+ **Datentyp** – [ARN](reference_policies_elements_condition_operators.md#Conditions_ARN)
+ **Werttyp** - Einzelwertig
+ **Beispielwert** — arn:aws:codebuild:us-east- 1:123456789012:project/ MyBuildProject
Das folgende Beispiel ermöglicht jedem Build aus einem bestimmten Projekt Zugriff auf den angegebenen Bucket. CodeBuild `s3:GetObject`
```
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
"Condition": {
"ArnEquals": {
"codebuild:ProjectArn": "arn:aws:codebuild:us-east-1:123456789012:project/MyBuildProject"
}
}
}
```
### lambda:SourceFunctionArn
Verwenden Sie diesen Schlüssel, um die ARN der Lambda-Funktion zu identifizieren, an die die IAM-Rollen-Anmeldeinformationen übermittelt wurden. Der Lambda-Dienst legt diesen Schlüssel für jede AWS API-Anfrage fest, die aus der Ausführungsumgebung Ihrer Funktion stammt. Verwenden Sie diesen Schlüssel, um zu überprüfen, ob ein Aufruf einer AWS Ressource aus dem Code einer bestimmten Lambda-Funktion stammt. Lambda legt diesen Schlüssel auch für einige Anfragen fest, die von außerhalb der Ausführungsumgebung kommen, z. B. das Schreiben von Protokollen in X-Ray CloudWatch und das Senden von Traces an X-Ray.
+ **Verfügbarkeit** – Dieser Schlüssel ist in den Anfrageskontext enthalten, wenn der Lambda-Funktionscode aufgerufen wird.
+ **Datentyp** – [ARN](reference_policies_elements_condition_operators.md#Conditions_ARN)
+ **Werttyp** - Einzelwertig
+ **Beispielwert** — arn:aws:lambda:us-east- 1:123456789012:function: TestFunction
Das folgende Beispiel ermöglicht einer bestimmten Lambda-Funktion den `s3:PutObject`-Zugriff auf den angegebenen Bucket.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ExampleSourceFunctionArn",
"Effect": "Allow",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
"Condition": {
"ArnEquals": {
"lambda:SourceFunctionArn": "arn:aws:lambda:us-east-1:123456789012:function:source_lambda"
}
}
}
]
}
```
------
Weitere Informationen finden Sie unter [Arbeiten mit Anmeldeinformationen für die Lambda-Ausführungsumgebung](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html#permissions-executionrole-source-function-arn) im *Entwicklerhandbuch zu AWS Lambda *.
### ssm:SourceInstanceArn
Verwenden Sie diesen Schlüssel, um den ARN der AWS Systems Manager verwalteten Instanz zu identifizieren, an den die Anmeldeinformationen für die IAM-Rolle übermittelt wurden. Dieser Bedingungsschlüssel ist nicht vorhanden, wenn die Anfrage von einer verwalteten Instance mit einer IAM-Rolle stammt, die einem Amazon-EC2-Instance-Profil zugeordnet ist.
+ **Verfügbarkeit** – Dieser Schlüssel ist in der Anfrage enthalten, wenn Anmeldeinformationen für eine Rolle an eine von AWS Systems Manager verwaltete Instance übermittelt werden.
+ **Datentyp** – [ARN](reference_policies_elements_condition_operators.md#Conditions_ARN)
+ **Werttyp** - Einzelwertig
+ **Beispielwert** — arn:aws:ec2:us-west- 2:111111111111:instance/instance-id
### identitystore:UserId
Verwenden Sie diesen Schlüssel, um die Mitarbeiteridentität des IAM Identity Center in der signierten Anfrage mit der in der Richtlinie angegebenen Identität zu vergleichen.
+ **Verfügbarkeit** – Dieser Schlüssel ist enthalten, wenn der Anfragesteller ein Benutzer des IAM Identity Center ist.
+ **Datentyp** – [Zeichenfolge](reference_policies_elements_condition_operators.md#Conditions_String)
+ **Werttyp** - Einzelwertig
+ **Beispielwert** – 94482488-3041-7026-18f3-be45837cd0e4
Sie können den Namen eines Benutzers im IAM Identity Center ermitteln, indem Sie mit UserId der API oder dem SDK eine Anfrage an die API stellen. [GetUserId](https://docs.aws.amazon.com//singlesignon/latest/IdentityStoreAPIReference/API_GetUserId.html) AWS CLI AWS AWS
## Eigenschaften des Netzwerks
Verwenden Sie die folgenden Bedingungsschlüssel, um Details über das Netzwerk, von dem die Anfrage stammt oder über das sie weitergeleitet wurde, mit den Netzwerkeigenschaften zu vergleichen, die Sie in der Richtlinie angeben.
### aws:SourceIp
Verwenden Sie diesen Schlüssel, um die IP-Adresse des Anforderers mit der IP-Adresse zu vergleichen, die Sie in der Richtlinie angeben. Der `aws:SourceIp`-Bedingungsschlüssel kann nur für öffentliche IP-Adressbereiche verwendet werden.
+ **Verfügbarkeit** – Dieser Schlüssel ist im Anforderungskontext enthalten, es sei denn, der Anforderer verwendet einen VPC-Endpunkt für die Anforderung.
+ **Datentyp** – [IP-Adresse](reference_policies_elements_condition_operators.md#Conditions_IPAddress)
+ **Werttyp** - Einzelwertig
Der `aws:SourceIp`-Bedingungsschlüssel kann in einer Richtlinie verwendet werden, um Auftraggeber zu erlauben, Anforderungen nur innerhalb eines angegebenen IP-Bereichs zu stellen.
**Anmerkung**
`aws:SourceIp`unterstützt IPv4 sowohl die IPv6 Adresse als auch den Bereich von IP-Adressen. [Eine Liste AWS-Services dieser Unterstützung IPv6 finden Sie AWS-Services IPv6 im *Amazon VPC-Benutzerhandbuch*.](https://docs.aws.amazon.com/vpc/latest/userguide/aws-ipv6-support.html)
Sie können beispielsweise die folgende identitätsbasierte Richtlinie an eine IAM-Rolle anfügen. Diese Richtlinie ermöglicht es dem Benutzer, Objekte in den `amzn-s3-demo-bucket3` Amazon S3 S3-Bucket zu legen, wenn er den Anruf aus dem angegebenen IPv4 Adressbereich tätigt. Diese Richtlinie ermöglicht auch einem AWS Dienst, [Forward Access Sessions (FAS)](access_forward_access_sessions.md) der diesen Vorgang in Ihrem Namen durchführt.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "PrincipalPutObjectIfIpAddress",
"Effect": "Allow",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket3/*",
"Condition": {
"IpAddress": {
"aws:SourceIp": "203.0.113.0/24"
}
}
}
]
}
```
------
Wenn Sie den Zugriff von Netzwerken aus einschränken müssen, die IPv4 sowohl als auch IPv6 Adressierung unterstützen, können Sie die IPv4 IPv6 Adresse oder Bereiche von IP-Adressen in die IAM-Richtlinienbedingung aufnehmen. Die folgende identitätsbasierte Richtlinie ermöglicht es dem Benutzer, Objekte in den `amzn-s3-demo-bucket3` Amazon S3 S3-Bucket zu legen, wenn der Benutzer den Anruf entweder aus bestimmten Bereichen IPv4 oder aus IPv6 Adressbereichen tätigt. Bevor Sie IPv6 Adressbereiche in Ihre IAM-Richtlinie aufnehmen, stellen Sie sicher, dass der Support, mit dem AWS-Service Sie zusammenarbeiten, unterstützt wird. IPv6 [Eine Liste AWS-Services dieser Unterstützung IPv6 finden Sie AWS-Services IPv6 im *Amazon VPC-Benutzerhandbuch*.](https://docs.aws.amazon.com/vpc/latest/userguide/aws-ipv6-support.html)
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "PrincipalPutObjectIfIpAddress",
"Effect": "Allow",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket3/*",
"Condition": {
"IpAddress": {
"aws:SourceIp": [
"203.0.113.0/24",
"2001:DB8:1234:5678::/64"
]
}
}
}
]
}
```
------
Wenn die Anforderung von einem Host stammt, der einen Amazon VPC-Endpunkt verwendet, ist der Schlüssel `aws:SourceIp` nicht verfügbar. Sie sollten stattdessen einen VPC-spezifischen Schlüssel wie [aws](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-vpcsourceip): verwenden. VpcSourceIp Weitere Informationen zur Verwendung von VPC-Endpunkten finden Sie unter [Identitäts- und Zugriffsmanagement für VPC-Endpunkte und VPC-Endpunkt-Services](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-iam.html) im *AWS PrivateLink -Leitfaden*.
**Anmerkung**
Wenn AWS-Services Sie in Ihrem Namen Anrufe AWS-Services an andere Personen tätigen (service-to-service Anrufe), wird ein bestimmter netzwerkspezifischer Autorisierungskontext unkenntlich gemacht. Wenn Ihre Richtlinie diesen Bedingungsschlüssel zusammen mit `Deny` Kontoauszügen verwendet, werden AWS-Service Principals möglicherweise unbeabsichtigt blockiert. Um die korrekte Funktion von AWS-Services unter Einhaltung Ihrer Sicherheitsanforderungen zu gewährleisten, schließen Sie Service-Prinzipale von Ihren `Deny`-Anweisungen aus, indem Sie den `aws:PrincipalIsAWSService`-Bedingungsschlüssel mit dem Wert `false` hinzufügen.
### aws:SourceVpc
Verwenden Sie diesen Schlüssel, um zu überprüfen, ob die Anfrage durch die VPC läuft, an die der VPC-Endpunkt angefügt ist. In einer Richtlinie können Sie diesen Schlüssel verwenden, um den Zugriff auf nur eine bestimmte VPC zu erlauben. Weitere Informationen finden Sie unter [Beschränkung des Zugriffs auf eine bestimmte VPC](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies-vpc-endpoint.html#example-bucket-policies-restrict-access-vpc) im *Benutzerhandbuch für Amazon Simple Storage Service*.
+ **Verfügbarkeit** – Dieser Schlüssel ist nur dann im Anforderungskontext enthalten, wenn der Anforderer einen VPC-Endpunkt für die Anforderung verwendet.
+ **Datentyp** – [Zeichenfolge](reference_policies_elements_condition_operators.md#Conditions_String)
+ **Werttyp** - Einzelwertig
In einer Richtlinie können Sie diesen Schlüssel verwenden, um den Zugriff auf eine bestimmte VPC zuzulassen oder zu beschränken.
Sie können beispielsweise die folgende identitätsbasierte Richtlinie an eine IAM-Rolle anhängen, um sie dem `amzn-s3-demo-bucket3` Amazon S3 S3-Bucket `PutObject` zu verweigern, es sei denn, die Anfrage wird von der angegebenen VPC-ID gestellt oder sie verwendet [Forward Access Sessions (FAS) AWS-Services](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html), um Anfragen im Namen der Rolle zu stellen. Im Gegensatz zu [aws:SourceIp](#condition-keys-sourceip) müssen Sie [aws:ViaAWSService](#condition-keys-viaawsservice) oder [aws:CalledVia](#condition-keys-calledvia) verwenden, um FAS-Anfragen zuzulassen, da die Quell-VPC der ursprünglichen Anfrage nicht beibehalten wird.
**Anmerkung**
Diese Richtlinie lässt keine Aktionen zu. Verwenden Sie diese Richtlinie in Kombination mit anderen Richtlinien, die bestimmte Aktionen zulassen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "PutObjectIfNotVPCID",
"Effect": "Deny",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket3/*",
"Condition": {
"StringNotEqualsIfExists": {
"aws:SourceVpc": "vpc-1234567890abcdef0"
},
"Bool": {
"aws:ViaAWSService": "false"
}
}
}
]
}
```
------
**Anmerkung**
AWS empfiehlt die Verwendung `aws:SourceVpcArn` anstelle von, `aws:SourceVpc` wenn dies von dem Service, auf den Sie abzielen, unterstützt `aws:SourceVpcArn` wird. Eine Liste der unterstützten Dienste finden Sie unter [aws: SourceVpcArn](#condition-keys-sourcevpcarn).
### aws:SourceVpcArn
Verwenden Sie diesen Schlüssel, um den ARN der VPC zu überprüfen, über die eine Anfrage über einen VPC-Endpunkt gestellt wurde. Dieser Schlüssel gibt den ARN der VPC zurück, an die der VPC-Endpunkt angehängt ist.
+ **Verfügbarkeit** — Dieser Schlüssel ist im Anforderungskontext für unterstützte Dienste enthalten, wenn eine Anfrage über einen VPC-Endpunkt gestellt wird. Der Schlüssel ist nicht für Anfragen enthalten, die über öffentliche Service-Endpunkte erfolgen. Die folgenden Services unterstützen diesen Schlüssel:
+ AWS App Runner (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsapprunner.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsapprunner.html))
+ AWS Application Discovery Service (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsapplicationdiscoveryservice.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsapplicationdiscoveryservice.html))
+ Amazon Athena (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonathena.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonathena.html))
+ AWS Cloud Map (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awscloudmap.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awscloudmap.html))
+ Amazon CloudWatch Application Insights (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatchapplicationinsights.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatchapplicationinsights.html))
+ AWS CloudFormation (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awscloudformation.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awscloudformation.html))
+ Amazon Comprehend Medical (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncomprehendmedical.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncomprehendmedical.html))
+ AWS Compute Optimizer (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awscomputeoptimizer.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awscomputeoptimizer.html))
+ Amazon; Elastic Container Registry (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticcontainerregistry.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticcontainerregistry.html))
+ Amazon Elastic Container Service (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticcontainerservice.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticcontainerservice.html))
+ Amazon Kinesis Analytics (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonkinesisanalytics.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonkinesisanalytics.html))
+ Amazon Route 53 (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonroute53.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonroute53.html))
+ AWS DataSync (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsdatasync.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsdatasync.html))
+ Amazon Elastic Block Store (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticblockstore.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticblockstore.html))
+ Amazon EventBridge Scheduler (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoneventbridgescheduler.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoneventbridgescheduler.html))
+ Amazon Data Firehose (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonkinesisfirehose.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonkinesisfirehose.html))
+ AWS HealthImaging (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awshealthimaging.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awshealthimaging.html))
+ AWS HealthLake (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awshealthlake.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awshealthlake.html))
+ AWS HealthOmics (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awshealthomics.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awshealthomics.html))
+ AWS Identity and Access Management (außer für die `iam:PassRole` Aktion) (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsidentityandaccessmanagementiam.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsidentityandaccessmanagementiam.html))
+ AWS IoT FleetWise (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsiotfleetwise.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsiotfleetwise.html))
+ AWS IoT Wireless (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsiotwireless.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsiotwireless.html))
+ AWS Key Management Service (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awskeymanagementservice.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awskeymanagementservice.html))
+ AWS Lambda (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awslambda.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awslambda.html))
+ AWS Payment Cryptography (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awspaymentcryptography.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awspaymentcryptography.html))
+ Amazon Polly (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonpolly.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonpolly.html))
+ AWS Private Certificate Authority (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsprivatecertificateauthority.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsprivatecertificateauthority.html))
+ AWS Papierkorb (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsrecyclebin.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsrecyclebin.html))
+ Amazon Rekognition (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrekognition.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrekognition.html))
+ Service Quotas (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_servicequotas.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_servicequotas.html))
+ Amazon Simple Storage Service (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazons3.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazons3.html))
+ AWS Storage Gateway (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsstoragegateway.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsstoragegateway.html))
+ AWS Systems Manager Incident Manager Kontakte (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awssystemsmanagerincidentmanagercontacts.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awssystemsmanagerincidentmanagercontacts.html))
+ Amazon Textract (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazontextract.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazontextract.html))
+ Amazon Transcribe (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazontranscribe.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazontranscribe.html))
+ AWS Transfer Family (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awstransferfamily.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awstransferfamily.html))
+ **Datentyp** – ARN
AWS empfiehlt, beim Vergleich [ARN-Operatoren](reference_policies_elements_condition_operators.md#Conditions_ARN) anstelle von [Zeichenkettenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String) zu verwenden ARNs.
+ **Werttyp** - Einzelwertig
+ **Beispielwert:** – `arn:aws:ec2:us-east-1:123456789012:vpc/vpc-0e9801d129EXAMPLE`
Im Folgenden finden Sie ein Beispiel für eine Bucket-Richtlinie, die den Zugriff auf `amzn-s3-demo-bucket` und die zugehörigen Objekte von überall außerhalb der `vpc-1a2b3c4d` VPC verweigert.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Access-to-specific-VPC-only",
"Principal": "*",
"Action": "s3:*",
"Effect": "Deny",
"Resource": ["arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"],
"Condition": {
"ArnNotEquals": {
"aws:SourceVpcArn": "arn:aws:ec2:us-east-1:*:vpc/vpc-1a2b3c4d"
}
}
}
]
}
```
### aws:SourceVpce
Verwenden Sie diesen Schlüssel, um die VPC-Endpunkt-ID der Anforderung mit der Endpunkt-ID zu vergleichen, die Sie in der Richtlinie angeben.
+ **Verfügbarkeit** – Dieser Schlüssel ist nur dann im Anforderungskontext enthalten, wenn der Anforderer einen VPC-Endpunkt für die Anforderung verwendet.
+ **Datentyp** – [Zeichenfolge](reference_policies_elements_condition_operators.md#Conditions_String)
+ **Werttyp** - Einzelwertig
In einer Richtlinie können Sie diesen Schlüssel verwenden, um den Zugriff auf einen bestimmten VPC-Endpunkt zu beschränken. Weitere Informationen finden Sie unter [Beschränkung des Zugriffs auf eine bestimmte VPC](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies-vpc-endpoint.html#example-bucket-policies-restrict-access-vpc) im *Benutzerhandbuch für Amazon Simple Storage Service*. Ähnlich wie bei der Verwendung müssen Sie Anfragen verwenden [aws:ViaAWSService](#condition-keys-viaawsservice) oder zulassen[aws:SourceVpc](#condition-keys-sourcevpc), [aws:CalledVia](#condition-keys-calledvia) die AWS-Services mithilfe von [Forward Access Sessions (FAS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html)) gestellt werden. Dies liegt daran, dass der Quell-VPC-Endpunkt der ursprünglichen Anfrage nicht beibehalten wird.
### aws:VpceAccount
Verwenden Sie diesen Schlüssel, um die AWS Konto-ID, der der VPC-Endpunkt gehört, über den die Anfrage gestellt wurde, mit der Konto-ID zu vergleichen, die Sie in der Richtlinie angeben. Dieser Bedingungsschlüssel hilft Ihnen bei der Einrichtung von Netzwerkperimeterkontrollen, indem er sicherstellt, dass Anfragen über VPC-Endpunkte erfolgen, die bestimmten Konten zugeordnet sind.
+ **Verfügbarkeit** – Dieser Schlüssel ist im Anfragekontext enthalten, wenn eine Anfrage über einen VPC-Endpunkt erfolgt. Der Schlüssel ist nicht für Anfragen enthalten, die über öffentliche Service-Endpunkte erfolgen.
Die folgenden Services unterstützen diesen Schlüssel:
+ AWS App Runner (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsapprunner.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsapprunner.html))
+ AWS Application Discovery Service (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsapplicationdiscoveryservice.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsapplicationdiscoveryservice.html))
+ Amazon Athena (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonathena.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonathena.html))
+ AWS Cloud Map (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awscloudmap.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awscloudmap.html))
+ Amazon CloudWatch Application Insights (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatchapplicationinsights.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatchapplicationinsights.html))
+ AWS CloudFormation (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awscloudformation.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awscloudformation.html))
+ Amazon Comprehend Medical (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncomprehendmedical.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncomprehendmedical.html))
+ AWS Compute Optimizer (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awscomputeoptimizer.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awscomputeoptimizer.html))
+ Amazon; Elastic Container Registry (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticcontainerregistry.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticcontainerregistry.html))
+ Amazon Elastic Container Service (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticcontainerservice.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticcontainerservice.html))
+ Amazon Kinesis Analytics (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonkinesisanalytics.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonkinesisanalytics.html))
+ Amazon Route 53 (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonroute53.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonroute53.html))
+ AWS DataSync (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsdatasync.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsdatasync.html))
+ Amazon Elastic Block Store (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticblockstore.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticblockstore.html))
+ Amazon EventBridge Scheduler (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoneventbridgescheduler.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoneventbridgescheduler.html))
+ Amazon Data Firehose (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonkinesisfirehose.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonkinesisfirehose.html))
+ AWS HealthImaging (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awshealthimaging.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awshealthimaging.html))
+ AWS HealthLake (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awshealthlake.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awshealthlake.html))
+ AWS HealthOmics (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awshealthomics.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awshealthomics.html))
+ AWS Identity and Access Management (außer für die `iam:PassRole` Aktion) (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsidentityandaccessmanagementiam.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsidentityandaccessmanagementiam.html))
+ AWS IoT FleetWise (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsiotfleetwise.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsiotfleetwise.html))
+ AWS IoT Wireless (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsiotwireless.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsiotwireless.html))
+ AWS Key Management Service (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awskeymanagementservice.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awskeymanagementservice.html))
+ AWS Lambda (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awslambda.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awslambda.html))
+ AWS Payment Cryptography (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awspaymentcryptography.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awspaymentcryptography.html))
+ Amazon Polly (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonpolly.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonpolly.html))
+ AWS Private Certificate Authority (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsprivatecertificateauthority.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsprivatecertificateauthority.html))
+ AWS Papierkorb (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsrecyclebin.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsrecyclebin.html))
+ Amazon Rekognition (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrekognition.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrekognition.html))
+ Service Quotas (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_servicequotas.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_servicequotas.html))
+ Amazon Simple Storage Service (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazons3.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazons3.html))
+ AWS Storage Gateway (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsstoragegateway.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsstoragegateway.html))
+ AWS Systems Manager Incident Manager Kontakte (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awssystemsmanagerincidentmanagercontacts.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awssystemsmanagerincidentmanagercontacts.html))
+ Amazon Textract (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazontextract.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazontextract.html))
+ Amazon Transcribe (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazontranscribe.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazontranscribe.html))
+ AWS Transfer Family (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awstransferfamily.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awstransferfamily.html))
+ **Datentyp** – [Zeichenfolge](reference_policies_elements_condition_operators.md#Conditions_String)
+ **Werttyp** - Einzelwertig
+ **Beispielwert:** – `123456789012`
Sie können diesen Bedingungsschlüssel verwenden, wenn Sie den Zugriff auf Ressourcen einschränken möchten, sodass Anfragen über VPC-Endpunkte erfolgen müssen, die Ihrem Konto gehören. Das folgende Beispiel für eine Bucket-Richtlinie für Amazon S3 ermöglicht den Zugriff, wenn die Anfrage über einen VPC-Endpunkt erfolgt, der dem angegebenen Konto gehört:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AccessToSpecificVpceAccountOnly",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/RoleName"
},
"Action": "s3:GetObject",
"Effect": "Allow",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket1/*",
"Condition": {
"StringEquals": {
"aws:VpceAccount": "111122223333"
}
}
}
]
}
```
------
**Anmerkung**
Dieser Bedingungsschlüssel wird derzeit für eine Reihe ausgewählter AWS Dienste unterstützt. Die Verwendung dieses Schlüssels mit nicht unterstützten Services kann zu unbeabsichtigten Autorisierungsergebnissen führen. Beschränken Sie den Bedingungsschlüssel in Ihren Richtlinien immer auf unterstützte Services.
Einige AWS Dienste greifen von ihren Netzwerken aus auf Ihre Ressourcen zu, wenn sie in Ihrem Namen handeln. Wenn Sie solche Dienste verwenden, müssen Sie das obige Richtlinienbeispiel bearbeiten, damit AWS Dienste von außerhalb Ihres Netzwerks auf Ihre Ressourcen zugreifen können. Weitere Informationen zu Zugriffsmustern, die bei der Durchsetzung von Zugriffskontrollen auf der Grundlage des Abfrageursprungs berücksichtigt werden müssen, finden Sie unter [Einrichten des Berechtigungs-Integritätsschutzes mithilfe von Datenperimetern](access_policies_data-perimeters.md).
### aws:VpceOrgID
Verwenden Sie diesen Schlüssel, um die ID der Organisation AWS Organizations , der der VPC-Endpunkt gehört, von dem aus die Anfrage gestellt wurde, mit der ID zu vergleichen, die Sie in der Richtlinie angeben. Dieser Bedingungsschlüssel bietet den skalierbarsten Ansatz für Netzwerkperimeterkontrollen, der automatisch alle VPC-Endpunkte einbezieht, die Konten in Ihrer Organisation gehören.
+ **Verfügbarkeit** — Dieser Schlüssel ist im Anforderungskontext enthalten, wenn eine Anfrage über einen VPC-Endpunkt gestellt wird und das VPC-Endpunkt-Besitzerkonto Mitglied einer AWS Organisation ist. Der Schlüssel ist nicht enthalten für Anfragen, die über andere Netzwerkpfade erfolgen oder wenn das VPC-Endpunkt-Besitzerkonto nicht Teil einer Organisation ist.
Die folgenden Services unterstützen diesen Schlüssel:
+ AWS App Runner (Präfix:) [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsapprunner.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsapprunner.html)
+ AWS Application Discovery Service (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsapplicationdiscoveryservice.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsapplicationdiscoveryservice.html))
+ Amazon Athena (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonathena.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonathena.html))
+ AWS B2B Data Interchange (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsb2bdatainterchange.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsb2bdatainterchange.html))
+ AWS Cloud Map (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awscloudmap.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awscloudmap.html))
+ Amazon CloudWatch Application Insights (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatchapplicationinsights.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatchapplicationinsights.html))
+ AWS CloudFormation (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awscloudformation.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awscloudformation.html))
+ Amazon Cognito (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncognitoidentity.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncognitoidentity.html))
+ Amazon Comprehend Medical (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncomprehendmedical.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncomprehendmedical.html))
+ AWS Compute Optimizer (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awscomputeoptimizer.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awscomputeoptimizer.html))
+ AWS Database Migration Service (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsdatabasemigrationservice.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsdatabasemigrationservice.html))
+ AWS Verzeichnisdienstdaten (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsdirectoryservicedata.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsdirectoryservicedata.html))
+ Amazon; Elastic Container Registry (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticcontainerregistry.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticcontainerregistry.html))
+ Amazon Elastic Container Service (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticcontainerservice.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticcontainerservice.html))
+ Amazon Kinesis Analytics (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonkinesisanalytics.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonkinesisanalytics.html))
+ Amazon Route 53 (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonroute53.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonroute53.html))
+ AWS DataSync (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsdatasync.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsdatasync.html))
+ Amazon Elastic Block Store (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticblockstore.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticblockstore.html))
+ Amazon EventBridge Scheduler (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoneventbridgescheduler.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoneventbridgescheduler.html))
+ Amazon Data Firehose (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonkinesisfirehose.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonkinesisfirehose.html))
+ AWS HealthImaging (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awshealthimaging.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awshealthimaging.html))
+ AWS HealthLake (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awshealthlake.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awshealthlake.html))
+ AWS HealthOmics (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awshealthomics.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awshealthomics.html))
+ AWS Identity and Access Management (außer für die `iam:PassRole` Aktion) (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsidentityandaccessmanagementiam.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsidentityandaccessmanagementiam.html))
+ AWS Identitätsspeicher (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsidentitystore.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsidentitystore.html))
+ AWS IoT FleetWise (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsiotfleetwise.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsiotfleetwise.html))
+ AWS IoT TwinMaker (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsiottwinmaker.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsiottwinmaker.html))
+ AWS IoT Wireless (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsiotwireless.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsiotwireless.html))
+ Amazon Keyspaces (für Apache Cassandra) (Präfix:) [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonkeyspacesforapachecassandra.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonkeyspacesforapachecassandra.html)
+ AWS Key Management Service (Präfix:) [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awskeymanagementservice.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awskeymanagementservice.html)
+ AWS Lambda (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awslambda.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awslambda.html))
+ AWS Network Firewall (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsnetworkfirewall.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsnetworkfirewall.html))
+ AWS Payment Cryptography (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awspaymentcryptography.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awspaymentcryptography.html))
+ Amazon Pinpoint SMS- und Sprachservice (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonpinpointsmsandvoiceservice.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonpinpointsmsandvoiceservice.html))
+ Amazon Polly (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonpolly.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonpolly.html))
+ AWS-Preisliste (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awspricelist.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awspricelist.html))
+ AWS Private Certificate Authority (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsprivatecertificateauthority.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsprivatecertificateauthority.html))
+ AWS Papierkorb (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsrecyclebin.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsrecyclebin.html))
+ Amazon Rekognition (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrekognition.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrekognition.html))
+ Service Quotas (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_servicequotas.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_servicequotas.html))
+ Amazon Simple Email Service (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonses.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonses.html))
+ Amazon Simple Storage Service (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazons3.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazons3.html))
+ Amazon Simple Queue Service (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonsqs.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonsqs.html))
+ AWS Storage Gateway (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsstoragegateway.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsstoragegateway.html))
+ AWS Systems Manager Incident Manager Kontakte (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awssystemsmanagerincidentmanagercontacts.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awssystemsmanagerincidentmanagercontacts.html))
+ Amazon Textract (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazontextract.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazontextract.html))
+ Amazon Transcribe (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazontranscribe.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazontranscribe.html))
+ AWS Transfer Family (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awstransferfamily.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awstransferfamily.html))
+ Amazon WorkMail (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonworkmail.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonworkmail.html))
+ **Datentyp** – [Zeichenfolge](reference_policies_elements_condition_operators.md#Conditions_String)
+ **Werttyp** - Einzelwertig
+ **Beispielwerte** — `o-a1b2c3d4e5`
Das folgende Beispiel für eine Ressourcenkontrollrichtlinie verweigert den Zugriff auf Ihr Amazon S3 und Ihre AWS Key Management Service Ressourcen, es sei denn, die Anfrage kommt über VPC-Endpunkte, die der angegebenen Organisation gehören, oder über Netzwerke von AWS Diensten, die in Ihrem Namen handeln. Einige Organisationen müssen diese Richtlinie möglicherweise weiter bearbeiten, um den Anforderungen ihrer Organisation gerecht zu werden, z. B. um externen Partnern Zugriff zu gewähren. Weitere Informationen zu Zugriffsmustern, die bei der Durchsetzung von Zugriffskontrollen auf der Grundlage des Abfrageursprungs berücksichtigt werden müssen, finden Sie unter [Einrichten des Berechtigungs-Integritätsschutzes mithilfe von Datenperimetern](access_policies_data-perimeters.md).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EnforceNetworkPerimeterVpceOrgID",
"Effect": "Deny",
"Principal": "*",
"Action": [
"s3:*",
"kms:*"
],
"Resource": "*",
"Condition": {
"BoolIfExists": {
"aws:PrincipalIsAWSService": "false",
"aws:ViaAWSService": "false"
},
"StringNotEqualsIfExists": {
"aws:VpceOrgID": "o-abcdef0123",
"aws:PrincipalTag/network-perimeter-exception": "true"
}
}
}
]
}
```
------
**Anmerkung**
Dieser Bedingungsschlüssel wird derzeit für eine Reihe ausgewählter Dienste unterstützt. AWS Die Verwendung dieses Schlüssels mit nicht unterstützten Services kann zu unbeabsichtigten Autorisierungsergebnissen führen. Beschränken Sie den Bedingungsschlüssel in Ihren Richtlinien immer auf unterstützte Services.
### aws:VpceOrgPaths
Verwenden Sie diesen Schlüssel, um den AWS Organizations Pfad für den VPC-Endpunkt, von dem aus die Anfrage gestellt wurde, mit dem Pfad zu vergleichen, den Sie in der Richtlinie angeben. Dieser Bedingungsschlüssel ermöglicht es Ihnen, Netzwerkperimeterkontrollen auf der Ebene der Organisationseinheit (OU) zu implementieren und automatisch mit Ihrer VPC-Endpunktnutzung zu skalieren, wenn Sie innerhalb der angegebenen Anzahl neue Endpunkte hinzufügen. OUs
+ **Verfügbarkeit** – Dieser Schlüssel ist im Anfragekontext enthalten, wenn eine Anfrage über einen VPC-Endpunkt erfolgt und das VPC-Endpunkt-Besitzerkonto Mitglied einer Organisation ist. Der Schlüssel ist nicht enthalten für Anfragen, die über andere Netzwerkpfade erfolgen oder wenn das VPC-Endpunkt-Besitzerkonto nicht Teil einer Organisation ist.
Die folgenden Services unterstützen diesen Schlüssel:
+ AWS App Runner (Präfix:) [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsapprunner.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsapprunner.html)
+ AWS Application Discovery Service (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsapplicationdiscoveryservice.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsapplicationdiscoveryservice.html))
+ Amazon Athena (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonathena.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonathena.html))
+ AWS Cloud Map (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awscloudmap.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awscloudmap.html))
+ Amazon CloudWatch Application Insights (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatchapplicationinsights.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatchapplicationinsights.html))
+ AWS CloudFormation (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awscloudformation.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awscloudformation.html))
+ Amazon Comprehend Medical (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncomprehendmedical.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncomprehendmedical.html))
+ AWS Compute Optimizer (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awscomputeoptimizer.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awscomputeoptimizer.html))
+ Amazon; Elastic Container Registry (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticcontainerregistry.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticcontainerregistry.html))
+ Amazon Elastic Container Service (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticcontainerservice.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticcontainerservice.html))
+ Amazon Kinesis Analytics (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonkinesisanalytics.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonkinesisanalytics.html))
+ Amazon Route 53 (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonroute53.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonroute53.html))
+ AWS DataSync (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsdatasync.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsdatasync.html))
+ Amazon Elastic Block Store (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticblockstore.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticblockstore.html))
+ Amazon EventBridge Scheduler (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoneventbridgescheduler.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoneventbridgescheduler.html))
+ Amazon Data Firehose (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonkinesisfirehose.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonkinesisfirehose.html))
+ AWS HealthImaging (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awshealthimaging.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awshealthimaging.html))
+ AWS HealthLake (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awshealthlake.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awshealthlake.html))
+ AWS HealthOmics (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awshealthomics.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awshealthomics.html))
+ AWS Identity and Access Management (außer für die `iam:PassRole` Aktion) (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsidentityandaccessmanagementiam.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsidentityandaccessmanagementiam.html))
+ AWS IoT FleetWise (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsiotfleetwise.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsiotfleetwise.html))
+ AWS IoT Wireless (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsiotwireless.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsiotwireless.html))
+ AWS Key Management Service (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awskeymanagementservice.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awskeymanagementservice.html))
+ AWS Lambda (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awslambda.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awslambda.html))
+ AWS Payment Cryptography (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awspaymentcryptography.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awspaymentcryptography.html))
+ Amazon Polly (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonpolly.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonpolly.html))
+ AWS Private Certificate Authority (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsprivatecertificateauthority.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsprivatecertificateauthority.html))
+ AWS Papierkorb (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsrecyclebin.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsrecyclebin.html))
+ Amazon Rekognition (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrekognition.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrekognition.html))
+ Service Quotas (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_servicequotas.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_servicequotas.html))
+ Amazon Simple Storage Service (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazons3.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazons3.html))
+ AWS Storage Gateway (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsstoragegateway.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsstoragegateway.html))
+ AWS Systems Manager Incident Manager Kontakte (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awssystemsmanagerincidentmanagercontacts.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awssystemsmanagerincidentmanagercontacts.html))
+ Amazon Textract (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazontextract.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazontextract.html))
+ Amazon Transcribe (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazontranscribe.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazontranscribe.html))
+ AWS Transfer Family (Präfix: [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awstransferfamily.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awstransferfamily.html))
+ **Datentyp** – [Zeichenfolge](reference_policies_elements_condition_operators.md#Conditions_String) (Liste)
+ **Werttyp** - Mehrwertig
+ **Beispielwerte** — `o-a1b2c3d4e5/r-ab12/ou-ab12-11111111/ou-ab12-22222222/`
Da `aws:VpceOrgPaths` ein mehrwertiger Bedingungsschlüssel ist, müssen Sie für diesen Schlüssel die Set-Operatoren `ForAnyValue` oder `ForAllValues` mit [String-Bedingungsoperatoren](reference_policies_elements_condition_operators.md#Conditions_String) verwenden. Das folgende Beispiel für eine Bucket-Richtlinie für Amazon S3 ermöglicht den Zugriff nur dann, wenn Anfragen über VPC-Endpunkte erfolgen, die Konten in bestimmten Organisationseinheiten gehören:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowAccessFromSpecificOrgPaths",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/RoleName"
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket1/*",
"Condition": {
"ForAnyValue:StringLike": {
"aws:VpceOrgPaths": [
"o-a1b2c3d4e5/r-ab12/ou-ab12-11111111/ou-ab12-22222222/*",
"o-a1b2c3d4e5/r-ab12/ou-ab12-11111111/ou-ab12-33333333/*"
]
}
}
}
]
}
```
------
**Anmerkung**
Dieser Bedingungsschlüssel wird derzeit für eine Reihe ausgewählter AWS Dienste unterstützt. Die Verwendung dieses Schlüssels mit nicht unterstützten Services kann zu unbeabsichtigten Autorisierungsergebnissen führen. Beschränken Sie den Bedingungsschlüssel in Ihren Richtlinien immer auf unterstützte Services.
Einige AWS Dienste greifen von ihren Netzwerken aus auf Ihre Ressourcen zu, wenn sie in Ihrem Namen handeln. Wenn Sie solche Dienste verwenden, müssen Sie das obige Richtlinienbeispiel bearbeiten, damit AWS Dienste von außerhalb Ihres Netzwerks auf Ihre Ressourcen zugreifen können. Weitere Informationen zu Zugriffsmustern, die bei der Durchsetzung von Zugriffskontrollen auf der Grundlage des Abfrageursprungs berücksichtigt werden müssen, finden Sie unter [Einrichten des Berechtigungs-Integritätsschutzes mithilfe von Datenperimetern](access_policies_data-perimeters.md).
### aws:VpcSourceIp
Verwenden Sie diesen Schlüssel, um die IP-Adresse, von der eine Anforderung stammt, mit der IP-Adresse zu vergleichen, die Sie in der Richtlinie angeben. In einer Richtlinie stimmt der Schlüssel nur dann überein, wenn die Anforderung von der angegebenen IP-Adresse stammt und über einen VPC-Endpunkt geleitet wird.
+ **Verfügbarkeit** – Dieser Schlüssel ist nur dann im Anforderungskontext enthalten, wenn die Anforderung über einen VPC-Endpunkt erfolgt.
+ **Datentyp** – [IP-Adresse](reference_policies_elements_condition_operators.md#Conditions_IPAddress)
+ **Werttyp** - Einzelwertig
Weitere Informationen finden Sie unter [Steuern des Zugriffs auf VPC-Endpunkte mithilfe von Endpunktrichtlinien](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-access.html) im *Amazon-VPC-Benutzerhandbuch*. Ähnlich wie bei der Verwendung müssen Sie Anfragen verwenden [aws:ViaAWSService](#condition-keys-viaawsservice) oder [aws:CalledVia](#condition-keys-calledvia) zulassen[aws:SourceVpc](#condition-keys-sourcevpc), die AWS-Services mithilfe von [Forward Access Sessions (FAS)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html) gestellt werden. Dies liegt daran, dass die Quell-IP der ursprünglichen Anfrage über einen VPC-Endpunkt in FAS-Anfragen nicht beibehalten wird.
**Anmerkung**
`aws:VpcSourceIp`unterstützt IPv4 sowohl die IPv6 Adresse als auch den Bereich von IP-Adressen. [Eine Liste AWS-Services dieser Unterstützung IPv6 finden Sie AWS-Services IPv6 im *Amazon VPC-Benutzerhandbuch*.](https://docs.aws.amazon.com/vpc/latest/userguide/aws-ipv6-support.html)
Verwenden Sie immer den `aws:VpcSourceIp` Bedingungsschlüssel zusammen mit den `aws:SourceVpcArn` Bedingungstasten `aws:SourceVpc``aws:SourceVpce`, oder. Wenn Sie dies nicht tun, kann eine Richtlinie API-Aufrufe von einer unerwarteten VPC zulassen, die dieselbe oder sich überschneidende IP-CIDR verwendet. Dies kann passieren, weil die IP-Adressen CIDRs von zwei, die nichts miteinander zu tun haben, identisch sein VPCs oder sich überschneiden können.
**Anmerkung**
Wenn AWS-Services Sie in Ihrem Namen Anrufe AWS-Services an andere Personen tätigen (service-to-service Anrufe), wird ein bestimmter netzwerkspezifischer Autorisierungskontext unkenntlich gemacht. Wenn Ihre Richtlinie diesen Bedingungsschlüssel zusammen mit `Deny` Kontoauszügen verwendet, werden AWS-Service Principals möglicherweise unbeabsichtigt blockiert. Um die korrekte Funktion von AWS-Services unter Einhaltung Ihrer Sicherheitsanforderungen zu gewährleisten, schließen Sie Service-Prinzipale von Ihren `Deny`-Anweisungen aus, indem Sie den `aws:PrincipalIsAWSService`-Bedingungsschlüssel mit dem Wert `false` hinzufügen.
## Eigenschaften der Ressource
Verwenden Sie die folgenden Bedingungsschlüssel, um Details über die Ressource, die das Ziel der Anfrage ist, mit den Ressourceneigenschaften zu vergleichen, die Sie in der Richtlinie angeben.
### aws:ResourceAccount
Verwenden Sie diesen Schlüssel, um die [AWS-Konto -ID](https://docs.aws.amazon.com/general/latest/gr/acct-identifiers.html) des angeforderten Ressourcenbesitzers mit dem Ressourcenkonto in der Richtlinie zu vergleichen. Sie können dann den Zugriff auf diese Ressource basierend auf dem Konto, dem die Ressource gehört, erlauben oder verweigern.
+ **Verfügbarkeit** – Dieser Schlüssel ist immer im Anforderungskontext für die meisten Service-Aktionen enthalten. Die folgenden Aktionen unterstützen diesen Schlüssel nicht:
+ AWS Audit Manager
+ `auditmanager:UpdateAssessmentFrameworkShare`
+ Amazon Detective
+ `detective:AcceptInvitation`
+ AWS Directory Service
+ `ds:AcceptSharedDirectory`
+ Amazon Elastic Block Store – Alle Aktionen
+ Amazon EC2
+ `ec2:AcceptTransitGatewayPeeringAttachment`
+ `ec2:AcceptVpcEndpointConnections`
+ `ec2:AcceptVpcPeeringConnection`
+ `ec2:CreateTransitGatewayPeeringAttachment`
+ `ec2:CreateVpcEndpoint`
+ `ec2:CreateVpcPeeringConnection`
+ Amazon EventBridge
+ `events:PutEvents`— EventBridge `PutEvents` ruft einen Event-Bus in einem anderen Konto auf, wenn dieser Event-Bus vor dem 2. März 2023 als kontenübergreifendes EventBridge Ziel konfiguriert wurde. Weitere Informationen finden Sie im * EventBridge Amazon-Benutzerhandbuch* unter Erteilen [von Berechtigungen zum Zulassen von Ereignissen aus anderen AWS Konten](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-cross-account.html#eb-receiving-events-from-another-account).
+ Amazon GuardDuty
+ `guardduty:AcceptAdministratorInvitation`
+ Amazon Macie
+ `macie2:AcceptInvitation`
+ OpenSearch Amazon-Dienst
+ `es:AcceptInboundConnection`
+ Amazon Route 53
+ `route53:AssociateVpcWithHostedZone`
+ `route53:CreateVPCAssociationAuthorization`
+ AWS Security Hub CSPM
+ `securityhub:AcceptAdministratorInvitation`
+ **Datentyp** – [Zeichenfolge](reference_policies_elements_condition_operators.md#Conditions_String)
+ **Werttyp** - Einzelwertig
**Anmerkung**
Weitere Überlegungen zu den oben genannten nicht unterstützten Aktionen finden Sie im Repository [Data Perimeter Policy Examples](https://github.com/aws-samples/data-perimeter-policy-examples) (Beispiele für Datenperimeter-Richtlinien).
Dieser Schlüssel entspricht der AWS-Konto ID für das Konto mit den in der Anfrage bewerteten Ressourcen.
Für die meisten Ressourcen in Ihrem Konto, enthält der [ARN](reference_policies_elements_condition_operators.md#Conditions_ARN) die Besitzer-Konto-ID für diese Ressource. Für bestimmte Ressourcen, wie Amazon S3-Buckets, enthält der Ressourcen-ARN nicht die Konto-ID. Die folgenden zwei Beispiele zeigen den Unterschied zwischen einer Ressource mit einer Konto-ID im ARN und einem Amazon-S3-ARN ohne Konto-ID:
+ `arn:aws:iam::123456789012:role/AWSExampleRole` – Erstellung und Eigentümerschaft der IAM-Rolle innerhalb des Kontos 123456789012.
+ `arn:aws:s3:::amzn-s3-demo-bucket2` – Erstellung und Eigentümerchaft des Amazon-S3-Buckets innerhalb des Kontos `111122223333`, wird nicht im ARN angezeigt.
Verwenden Sie die AWS Konsole, API oder CLI, um all Ihre Ressourcen und die entsprechenden Ressourcen zu finden ARNs.
Sie schreiben eine Richtlinie, die Berechtigungen für Ressourcen basierend auf der Konto-ID des Ressourcenbesitzers verweigert. Zum Beispiel verweigert die folgende identitätsbasierte Richtlinie den Zugriff auf die *angegebene Ressource*, wenn die Ressource nicht dem *angegebenen Konto* angehört.
Um diese Richtlinie zu verwenden, ersetzen Sie den *kursiv gedruckten Platzhaltertext* durch Ihre eigenen Kontoinformationen.
**Wichtig**
Diese Richtlinie lässt keine Aktionen zu. Stattdessen wird der `Deny`-Effekt verwendet, der explizit den Zugriff auf alle in der Anweisung aufgeführten Ressourcen verweigert, die nicht zu dem aufgelisteten Konto gehören. Verwenden Sie diese Richtlinie in Kombination mit anderen Richtlinien, die den Zugriff auf bestimmte Ressourcen gewähren.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyInteractionWithResourcesNotInSpecificAccount",
"Action": "service:*",
"Effect": "Deny",
"Resource": [
"arn:aws:service:us-east-1:111122223333:*"
],
"Condition": {
"StringNotEquals": {
"aws:ResourceAccount": [
"111122223333"
]
}
}
}
]
}
```
------
Diese Richtlinie verweigert den Zugriff auf alle Ressourcen für einen bestimmten AWS Dienst, es sei denn, der angegebene Benutzer AWS-Konto besitzt die Ressource.
**Anmerkung**
Einige AWS-Services erfordern Zugriff auf AWS eigene Ressourcen, die in einem anderen AWS-Konto gehostet werden. Wenn Sie `aws:ResourceAccount` in Ihren identitätsbasierten Richtlinien verwenden, kann sich dies auf die Fähigkeit Ihrer Identität auswirken, auf diese Ressourcen zuzugreifen.
Bestimmte AWS Dienste, wie z. B. AWS Data Exchange, sind AWS-Konten für den normalen Betrieb auf den Zugriff auf Ressourcen außerhalb Ihres Computers angewiesen. Wenn Sie das Element `aws:ResourceAccount` in Ihren Richtlinien verwenden, fügen Sie zusätzliche Erklärungen hinzu, um Ausnahmen für diese Services zu erstellen. Die Beispielrichtlinie [AWS: Verweigern Sie den Zugriff auf Amazon S3 S3-Ressourcen außerhalb Ihres Kontos, außer AWS Data Exchange](reference_policies_examples_resource_account_data_exch.md) zeigt, wie der Zugriff basierend auf dem Ressourcenkonto verweigert wird, während Ausnahmen für serviceeigene Ressourcen definiert werden.
Verwenden Sie diese Richtlinienbeispiele als Vorlagen für die Erstellung Ihrer eigenen benutzerdefinierten Richtlinien. Weitere Informationen finden Sie in Ihrer Service-[Dokumentation](https://docs.aws.amazon.com/index.html).
### aws:ResourceOrgPaths
Verwenden Sie diesen Schlüssel, um den AWS Organizations Pfad für die Ressource, auf die zugegriffen wurde, mit dem Pfad in der Richtlinie zu vergleichen. In einer Richtlinie stellt dieser Bedingungsschlüssel sicher, dass die Ressource einem Kontomitglied innerhalb des angegebenen Organisationsstamms oder der angegebenen Organisationseinheiten (OUs) gehört AWS Organizations. Ein AWS Organizations Pfad ist eine Textdarstellung der Struktur einer Organisationseinheit. Weitere Informationen zum Verwenden und Verstehen von Pfaden finden Sie unter [Verstehen Sie den AWS Organizations Entitätspfad](access_policies_last-accessed-view-data-orgs.md#access_policies_last-accessed-viewing-orgs-entity-path).
+ **Verfügbarkeit** – Dieser Schlüssel wird nur dann in den Anforderungskontext aufgenommen, wenn das Konto, dem die Ressource gehört, Mitglied einer Organisation ist. Dieser globale Bedingungsschlüssel unterstützt die folgenden Aktionen nicht:
+ AWS Audit Manager
+ `auditmanager:UpdateAssessmentFrameworkShare`
+ Amazon Detective
+ `detective:AcceptInvitation`
+ AWS Directory Service
+ `ds:AcceptSharedDirectory`
+ Amazon Elastic Block Store – Alle Aktionen
+ Amazon EC2
+ `ec2:AcceptTransitGatewayPeeringAttachment`
+ `ec2:AcceptVpcEndpointConnections`
+ `ec2:AcceptVpcPeeringConnection`
+ `ec2:CreateTransitGatewayPeeringAttachment`
+ `ec2:CreateVpcEndpoint`
+ `ec2:CreateVpcPeeringConnection`
+ Amazon EventBridge
+ `events:PutEvents`— EventBridge `PutEvents` ruft einen Event-Bus in einem anderen Konto auf, wenn dieser Event-Bus vor dem 2. März 2023 als kontenübergreifendes EventBridge Ziel konfiguriert wurde. Weitere Informationen finden Sie im * EventBridge Amazon-Benutzerhandbuch* unter Erteilen [von Berechtigungen zum Zulassen von Ereignissen aus anderen AWS Konten](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-cross-account.html#eb-receiving-events-from-another-account).
+ Amazon GuardDuty
+ `guardduty:AcceptAdministratorInvitation`
+ Amazon Macie
+ `macie2:AcceptInvitation`
+ OpenSearch Amazon-Dienst
+ `es:AcceptInboundConnection`
+ Amazon Route 53
+ `route53:AssociateVpcWithHostedZone`
+ `route53:CreateVPCAssociationAuthorization`
+ AWS Security Hub CSPM
+ `securityhub:AcceptAdministratorInvitation`
+ **Datentyp** – [Zeichenfolge](reference_policies_elements_condition_operators.md#Conditions_String) (Liste)
+ **Werttyp** - Mehrwertig
**Anmerkung**
Weitere Überlegungen zu den oben genannten nicht unterstützten Aktionen finden Sie im Repository [Data Perimeter Policy Examples](https://github.com/aws-samples/data-perimeter-policy-examples) (Beispiele für Datenperimeter-Richtlinien).
`aws:ResourceOrgPaths` ist ein mehrwertiger Bedingungsschlüssel. Mehrwertige Bedingungsschlüssel können im Anforderungskontext mehrere Werte haben. Sie müssen die Set-Operatoren `ForAnyValue` oder `ForAllValues` zusammen mit [String-Bedingungsoperatoren](reference_policies_elements_condition_operators.md#Conditions_String) für diesen Schlüssel verwenden. Weitere Hinweise zu mehrwertigen Bedingungsschlüsseln finden Sie unter [Operatoren für mehrwertige Kontextschlüssel festlegen](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys).
Zum Beispiel gibt die folgende Bedingung `True` für Ressourcen zurück, die zur Organisation `o-a1b2c3d4e5` gehören. Wenn Sie einen Platzhalter hinzufügen, müssen Sie den [StringLike](reference_policies_elements_condition_operators.md)-Bedingungsoperator verwenden.
```
"Condition": {
"ForAnyValue:StringLike": {
"aws:ResourceOrgPaths":["o-a1b2c3d4e5/*"]
}
}
```
Die folgende Bedingung gibt `True` für Ressourcen mit der OU-ID `ou-ab12-11111111` zurück. Es wird Ressourcen zugeordnet, die Konten gehören, die der Organisationseinheit ou-ab12-11111111 oder einem beliebigen Kind zugeordnet sind. OUs
```
"Condition": { "ForAnyValue:StringLike" : {
"aws:ResourceOrgPaths":["o-a1b2c3d4e5/r-ab12/ou-ab12-11111111/*"]
}}
```
Die folgende Bedingung gilt `True` für Ressourcen, die Konten gehören, die direkt mit der OU-ID verknüpft sind, aber nicht dem Kind. `ou-ab12-22222222` OUs Im folgenden Beispiel wird der [StringEquals](reference_policies_elements_condition_operators.md)Bedingungsoperator verwendet, um die exakte Übereinstimmungsanforderung für die OU-ID und nicht um eine Platzhalterübereinstimmung anzugeben.
```
"Condition": { "ForAnyValue:StringEquals" : {
"aws:ResourceOrgPaths":["o-a1b2c3d4e5/r-ab12/ou-ab12-11111111/ou-ab12-22222222/"]
}}
```
**Anmerkung**
Einige AWS-Services benötigen Zugriff auf AWS eigene Ressourcen, die auf anderen AWS-Konto gehostet werden. Wenn Sie `aws:ResourceOrgPaths` in Ihren identitätsbasierten Richtlinien verwenden, kann sich dies auf die Fähigkeit Ihrer Identität auswirken, auf diese Ressourcen zuzugreifen.
Bestimmte AWS Dienste, wie z. B. AWS Data Exchange, sind AWS-Konten für den normalen Betrieb auf den Zugriff auf Ressourcen außerhalb Ihres Computers angewiesen. Wenn Sie den Schlüssel `aws:ResourceOrgPaths` in Ihren Richtlinien verwenden, fügen Sie zusätzliche Erklärungen hinzu, um Ausnahmen für diese Services zu erstellen. Die Beispielrichtlinie [AWS: Verweigern Sie den Zugriff auf Amazon S3 S3-Ressourcen außerhalb Ihres Kontos, außer AWS Data Exchange](reference_policies_examples_resource_account_data_exch.md) zeigt, wie der Zugriff basierend auf dem Ressourcenkonto verweigert wird, während Ausnahmen für serviceeigene Ressourcen definiert werden. Sie können eine ähnliche Richtlinie erstellen, um den Zugriff auf Ressourcen innerhalb Ihrer Organisationseinheit (OU) mithilfe des `aws:ResourceOrgPaths`-Schlüssels zu beschränken und gleichzeitig serviceeigene Ressourcen zu berücksichtigen.
Verwenden Sie diese Richtlinienbeispiele als Vorlagen für die Erstellung Ihrer eigenen benutzerdefinierten Richtlinien. Weitere Informationen finden Sie in Ihrer Service-[Dokumentation](https://docs.aws.amazon.com/index.html).
### aws:ResourceOrgID
Verwenden Sie diesen Schlüssel, um die ID der Organisation, AWS Organizations zu der die angeforderte Ressource gehört, mit der in der Richtlinie angegebenen ID zu vergleichen.
+ **Verfügbarkeit** – Dieser Schlüssel ist nur dann im Anforderungskontext enthalten, wenn das Konto, das Eigentümer der Ressource ist, Mitglied einer Organisation ist. Dieser globale Bedingungsschlüssel unterstützt die folgenden Aktionen nicht:
+ AWS Audit Manager
+ `auditmanager:UpdateAssessmentFrameworkShare`
+ Amazon Detective
+ `detective:AcceptInvitation`
+ AWS Directory Service
+ `ds:AcceptSharedDirectory`
+ Amazon Elastic Block Store – Alle Aktionen
+ Amazon EC2
+ `ec2:AcceptTransitGatewayPeeringAttachment`
+ `ec2:AcceptVpcEndpointConnections`
+ `ec2:AcceptVpcPeeringConnection`
+ `ec2:CreateTransitGatewayPeeringAttachment`
+ `ec2:CreateVpcEndpoint`
+ `ec2:CreateVpcPeeringConnection`
+ Amazon EventBridge
+ `events:PutEvents`— EventBridge `PutEvents` ruft einen Event-Bus in einem anderen Konto auf, wenn dieser Event-Bus vor dem 2. März 2023 als kontenübergreifendes EventBridge Ziel konfiguriert wurde. Weitere Informationen finden Sie im * EventBridge Amazon-Benutzerhandbuch* unter Erteilen [von Berechtigungen zum Zulassen von Ereignissen aus anderen AWS Konten](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-cross-account.html#eb-receiving-events-from-another-account).
+ Amazon GuardDuty
+ `guardduty:AcceptAdministratorInvitation`
+ Amazon Macie
+ `macie2:AcceptInvitation`
+ OpenSearch Amazon-Dienst
+ `es:AcceptInboundConnection`
+ Amazon Route 53
+ `route53:AssociateVpcWithHostedZone`
+ `route53:CreateVPCAssociationAuthorization`
+ AWS Security Hub CSPM
+ `securityhub:AcceptAdministratorInvitation`
+ **Datentyp** – [Zeichenfolge](reference_policies_elements_condition_operators.md#Conditions_String)
+ **Werttyp** - Einzelwertig
**Anmerkung**
Weitere Überlegungen zu den oben genannten nicht unterstützten Aktionen finden Sie im Repository [Data Perimeter Policy Examples](https://github.com/aws-samples/data-perimeter-policy-examples) (Beispiele für Datenperimeter-Richtlinien).
Dieser globale Schlüssel gibt die ID der Ressourcenorganisation für eine bestimmte Anforderung zurück. Es erlaubt Ihnen, Regeln zu erstellen, die für alle Ressourcen in einer Organisation gelten, die im `Resource`-Element einer [identitätsbasierten Richtlinie](access_policies_identity-vs-resource.md) angegeben sind. Sie können die [Organisations-ID](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_details.html) im Bedingungselement angeben. Wenn Sie Konten hinzufügen und entfernen, schließen Richtlinien, die den `aws:ResourceOrgID`-Schlüssel enthalten, automatisch die richtigen Konten ein und Sie müssen sie nicht manuell aktualisieren.
Zum Beispiel verhindert die folgende Richtlinie, dass der Prinzipal der `policy-genius-dev`-Ressource Objekte hinzufügt, es sei denn, die Amazon-S3-Ressource gehört derselben Organisation an wie der Prinzipal, der die Anforderung stellt.
**Wichtig**
Diese Richtlinie lässt keine Aktionen zu. Stattdessen wird der `Deny`-Effekt verwendet, der explizit den Zugriff auf alle in der Anweisung aufgeführten Ressourcen verweigert, die nicht zu dem aufgelisteten Konto gehören. Verwenden Sie diese Richtlinie in Kombination mit anderen Richtlinien, die den Zugriff auf bestimmte Ressourcen gewähren.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Sid": "DenyPutObjectToS3ResourcesOutsideMyOrganization",
"Effect": "Deny",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::policy-genius-dev/*",
"Condition": {
"StringNotEquals": {
"aws:ResourceOrgID": "${aws:PrincipalOrgID}"
}
}
}
}
```
------
**Anmerkung**
Einige AWS-Services benötigen Zugriff auf AWS eigene Ressourcen, die auf anderen gehostet werden AWS-Konto. Wenn Sie `aws:ResourceOrgID` in Ihren identitätsbasierten Richtlinien verwenden, kann sich dies auf die Fähigkeit Ihrer Identität auswirken, auf diese Ressourcen zuzugreifen.
Bestimmte AWS Dienste, wie z. B. AWS Data Exchange, sind AWS-Konten für den normalen Betrieb auf den Zugriff auf Ressourcen außerhalb Ihres Computers angewiesen. Wenn Sie den Schlüssel `aws:ResourceOrgID` in Ihren Richtlinien verwenden, fügen Sie zusätzliche Erklärungen hinzu, um Ausnahmen für diese Services zu erstellen. Die Beispielrichtlinie [AWS: Verweigern Sie den Zugriff auf Amazon S3 S3-Ressourcen außerhalb Ihres Kontos, außer AWS Data Exchange](reference_policies_examples_resource_account_data_exch.md) zeigt, wie der Zugriff basierend auf dem Ressourcenkonto verweigert wird, während Ausnahmen für serviceeigene Ressourcen definiert werden. Sie können eine ähnliche Richtlinie erstellen, um den Zugriff auf Ressourcen innerhalb Ihrer Organisation mithilfe des `aws:ResourceOrgID`-Schlüssels zu beschränken und gleichzeitig serviceeigene Ressourcen zu berücksichtigen.
Verwenden Sie diese Richtlinienbeispiele als Vorlagen für die Erstellung Ihrer eigenen benutzerdefinierten Richtlinien. Weitere Informationen finden Sie in Ihrer Service-[Dokumentation](https://docs.aws.amazon.com/index.html).
Im folgenden Video erfahren Sie mehr darüber, wie Sie den Bedingungsschlüssel `aws:ResourceOrgID` in einer Richtlinie verwenden können.
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/cWVW0xAiWwc)
### aws:ResourceTag/*tag-key*
Verwenden Sie diesen Schlüssel, um das Tag-Schlüssel-Wert-Paar, das Sie in der Richtlinie angeben, mit dem Schlüssel-Wert-Paar zu vergleichen, das der Ressource zugeordnet ist. Beispiel: Sie können verlangen, dass der Zugriff auf eine Ressource nur gewährt wird, wenn die Ressource über den angefügten Tag-Schlüssel `"Dept"` mit dem Wert `"Marketing"` verfügt. Weitere Informationen finden Sie unter [Kontrolle des Zugriffs auf AWS Ressourcen](access_tags.md#access_tags_control-resources).
+ **Verfügbarkeit** – Dieser Schlüssel wird in den Anforderungskontext aufgenommen, wenn die angeforderte Ressource bereits angefügte Tags hat oder in Anforderungen, die eine Ressource mit einem angefügten Tag erstellen. Dieser Schlüssel wird nur für Ressourcen zurückgegeben, die [Berechtigung auf Basis von Tags](reference_aws-services-that-work-with-iam.md) unterstützen. Es gibt einen Kontextschlüssel für jedes Tag-Schlüssel-Wert-Paar.
+ **Datentyp** – [Zeichenfolge](reference_policies_elements_condition_operators.md#Conditions_String)
+ **Werttyp** - Einzelwertig
Dieser Kontextschlüssel ist so formatiert`"aws:ResourceTag/tag-key":"tag-value"`, *tag-key* dass er ein Tag-Schlüssel- und Wertepaar darstellt. *tag-value* Bei Tag-Schlüsseln wird die Groß- und Kleinschreibung nicht beachtet. Dies bedeutet Folgendes: Wenn Sie `"aws:ResourceTag/TagKey1": "Value1"` im Bedingungselement Ihrer Richtlinie angeben, stimmt die Bedingung mit einem Ressourcen-Tag-Schlüssel mit dem Namen `TagKey1` oder `tagkey1` überein, aber nicht mit beiden. Bei den Werten in diesen key/value Tag-Paaren wird zwischen Groß- und Kleinschreibung unterschieden. Dies bedeutet Folgendes: Wenn Sie `"aws:ResourceTag/TagKey1": "Production"` im Bedingungselement Ihrer Richtlinie angeben, stimmt die Bedingung mit einem Ressourcen-Tag-Wert mit dem Namen `Production` überein, jedoch nicht mit `production` oder `PRODUCTION`.
Beispiele für die Verwendung des `aws:ResourceTag`-Schlüssels zur Steuerung des Zugriffs auf IAM-Ressourcen finden Sie unter [Kontrolle des Zugriffs auf AWS Ressourcen](access_tags.md#access_tags_control-resources).
Beispiele für die Verwendung des `aws:ResourceTag` Schlüssels zur Steuerung des Zugriffs auf andere AWS Ressourcen finden Sie unter[Steuern des Zugriffs auf AWS Ressourcen mithilfe von Tags](access_tags.md).
Ein Tutorial zur Verwendung des `aws:ResourceTag`-Bedingungsschlüssels für attributbasierte Zugriffskontrolle (ABAC) finden Sie unter [IAM-Tutorial: Berechtigungen für den Zugriff auf AWS Ressourcen auf der Grundlage von Tags definieren](tutorial_attribute-based-access-control.md).
## Eigenschaften der Anfrage
Verwenden Sie die folgenden Bedingungsschlüssel, um Details zur Anfrage selbst und zum Inhalt der Anfrage mit den in der Richtlinie angegebenen Eigenschaften der Anfrage zu vergleichen.
### aws:CalledVia
Verwenden Sie diesen Schlüssel, um die Services in der Richtlinie mit den Services zu vergleichen, die im Auftrag des IAM-Auftraggebers (Benutzer oder Rolle) Anforderungen ausgegeben haben. Wenn ein Principal eine Anfrage an einen AWS Dienst stellt, verwendet dieser Dienst möglicherweise die Anmeldeinformationen des Prinzipals, um nachfolgende Anfragen an andere Dienste zu stellen. Wenn die Anfrage mithilfe von Forward Access Sessions (FAS) gestellt wird, wird diesem Schlüssel der Wert des Service-Prinzipals zugewiesen. Der Schlüssel `aws:CalledVia` enthält eine geordnete Liste aller Services in der Kette, die im Auftrag des Auftraggebers Anforderungen ausgegeben haben.
Weitere Informationen finden Sie unter [Forward Access Sessions (FAS)](access_forward_access_sessions.md).
+ **Verfügbarkeit** – Dieser Schlüssel ist in der Anforderung vorhanden, wenn ein Service, der `aws:CalledVia` unterstützt, die Anmeldeinformationen eines IAM-Auftraggebers verwendet, um eine Anforderung an einen anderen Service auszugeben. Dieser Schlüssel ist nicht vorhanden, wenn der Service eine [Servicerolle oder eine serviceverknüpfte Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#id_roles_terms-and-concepts) verwendet, um einen Aufruf im Auftrag des Prinzipals durchzuführen. Dieser Schlüssel ist auch nicht vorhanden, wenn der Auftraggeber den Aufruf direkt durchführt.
+ **Datentyp** – [Zeichenfolge](reference_policies_elements_condition_operators.md#Conditions_String) (Liste)
+ **Werttyp** - Mehrwertig
Um den `aws:CalledVia` Bedingungsschlüssel in einer Richtlinie verwenden zu können, müssen Sie die Dienstprinzipale angeben, um AWS Dienstanfragen zuzulassen oder abzulehnen. Sie können es beispielsweise verwenden, AWS CloudFormation um aus einer Amazon DynamoDB-Tabelle zu lesen und zu schreiben. DynamoDB verwendet dann die von AWS Key Management Service ()AWS KMS bereitgestellte Verschlüsselung.
Um den Zugriff zu erlauben oder zu verweigern, wenn *irgendein* Service unter Verwendung der Anmeldeinformationen des Auftraggebers eine Anforderung ausgibt, verwenden Sie den Bedingungsschlüssel `aws:ViaAWSService`. Dieser Bedingungsschlüssel unterstützt AWS Dienste.
Der `aws:CalledVia`-Schlüssel ist ein [mehrwertiger Schlüssel](reference_policies_condition-single-vs-multi-valued-context-keys.md). Sie können die Reihenfolge jedoch nicht mit diesem Schlüssel in einer Bedingung erzwingen. Anhand des obigen Beispiels gibt **User 1 (Benutzer 1)** eine Anforderung an CloudFormation aus, das DynamoDB aufruft, das wiederum AWS KMS aufruft. Dies sind drei separate Anforderungen. Der letzte Aufruf von AWS KMS wird von Benutzer 1 *über* CloudFormation und dann DynamoDB ausgeführt.
![\[Beispiel mit aws: CalledVia\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/images/condition-key-calledvia-example-diagram.png)
In diesem Fall enthält der Schlüssel `aws:CalledVia` im Anforderungskontext `cloudformation.amazonaws.com` und `dynamodb.amazonaws.com` (in dieser Reihenfolge). Wenn Ihnen nur wichtig ist, dass der Aufruf über DynamoDB irgendwo in der Kette von Anforderungen erfolgt ist, können Sie diesen Bedingungsschlüssel in Ihrer Richtlinie verwenden.
Die folgende Richtlinie ermöglicht beispielsweise die Verwaltung des genannten AWS KMS Schlüssels`my-example-key`, jedoch nur, wenn DynamoDB einer der anfordernden Dienste ist. Der Bedingungsoperator `ForAnyValue:StringEquals` stellt sicher, dass DynamoDB einer der aufrufenden Services ist. Wenn der Auftraggeber AWS KMS direkt aufruft, gibt die Bedingung `false` zurück, und die Anforderung wird von dieser Richtlinie nicht zugelassen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "KmsActionsIfCalledViaDynamodb",
"Effect": "Allow",
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey",
"kms:DescribeKey"
],
"Resource": "arn:aws:kms:us-east-1:111122223333:key/my-example-key",
"Condition": {
"ForAnyValue:StringEquals": {
"aws:CalledVia": [
"dynamodb.amazonaws.com"
]
}
}
}
]
}
```
------
Mit den Schlüsseln `aws:CalledViaFirst` und `aws:CalledViaLast` können Sie auf Wunsch erzwingen, welcher Service den ersten oder letzten Aufruf in der Kette durchführt. Die folgende Richtlinie ermöglicht beispielsweise die Verwaltung des in genannten `my-example-key` Schlüssels. AWS KMS Diese AWS KMS Operationen sind nur zulässig, wenn mehrere Anfragen in der Kette enthalten waren. Die erste Anforderung muss über CloudFormation und die letzte über DynamoDB erfolgen. Wenn andere Services mitten in der Kette Anforderungen ausgeben, ist die Operation trotzdem zulässig.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "KmsActionsIfCalledViaChain",
"Effect": "Allow",
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey",
"kms:DescribeKey"
],
"Resource": "arn:aws:kms:us-east-1:111122223333:key/my-example-key",
"Condition": {
"StringEquals": {
"aws:CalledViaFirst": "cloudformation.amazonaws.com",
"aws:CalledViaLast": "dynamodb.amazonaws.com"
}
}
}
]
}
```
------
Die Schlüssel `aws:CalledViaFirst` und `aws:CalledViaLast` sind in der Anforderung vorhanden, wenn ein Service die Anmeldeinformationen eines IAM-Auftraggebers verwendet, um einen anderen Service aufzurufen. Sie geben die ersten und letzten Services an, die in der Kette von Anforderungen Aufrufe durchgeführt haben. Nehmen wir beispielsweise an, dass CloudFormation ein anderer Dienst mit dem Namen`X Service`, aufgerufen wird, der DynamoDB aufruft, der dann aufruft. AWS KMS Der letzte Aufruf von AWS KMS wird von `User 1` *via* CloudFormation`X Service`, then und dann von DynamoDB ausgeführt. Es wurde zuerst über CloudFormation und zuletzt über DynamoDB aufgerufen.
![\[Beispiel mit aws: CalledViaFirst und aws: CalledViaLast\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/images/condition-key-calledviafirstlast-example-diagram.png)
### aws:CalledViaFirst
Verwenden Sie diesen Schlüssel, um die Services in der Richtlinie mit dem ***ersten Service*** zu vergleichen, der im Auftrag des IAM-Auftraggebers (Benutzer oder Rolle) eine Anforderung ausgegeben hat. Weitere Informationen finden Sie unter `aws:CalledVia`.
+ **Verfügbarkeit** – Dieser Schlüssel ist in der Anforderung vorhanden, wenn ein Service die Anmeldeinformationen eines IAM-Auftraggebers verwendet, um mindestens eine andere Anforderung an einen anderen Service auszugeben. Dieser Schlüssel ist nicht vorhanden, wenn der Service eine [Servicerolle oder eine serviceverknüpfte Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#id_roles_terms-and-concepts) verwendet, um einen Aufruf im Auftrag des Prinzipals durchzuführen. Dieser Schlüssel ist auch nicht vorhanden, wenn der Auftraggeber den Aufruf direkt durchführt.
+ **Datentyp** – [Zeichenfolge](reference_policies_elements_condition_operators.md#Conditions_String)
+ **Werttyp** - Einzelwertig
### aws:CalledViaLast
Verwenden Sie diesen Schlüssel, um die Services in der Richtlinie mit den *letzten Services* zu vergleichen, die im Auftrag des IAM-Auftraggebers (Benutzer oder Rolle) eine Anforderung ausgegeben haben. Weitere Informationen finden Sie unter `aws:CalledVia`.
+ **Verfügbarkeit** – Dieser Schlüssel ist in der Anforderung vorhanden, wenn ein Service die Anmeldeinformationen eines IAM-Auftraggebers verwendet, um mindestens eine andere Anforderung an einen anderen Service auszugeben. Dieser Schlüssel ist nicht vorhanden, wenn der Service eine [Servicerolle oder eine serviceverknüpfte Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#id_roles_terms-and-concepts) verwendet, um einen Aufruf im Auftrag des Prinzipals durchzuführen. Dieser Schlüssel ist auch nicht vorhanden, wenn der Auftraggeber den Aufruf direkt durchführt.
+ **Datentyp** – [Zeichenfolge](reference_policies_elements_condition_operators.md#Conditions_String)
+ **Werttyp** - Einzelwertig
### aws:ViaAWSService
Verwenden Sie diesen Schlüssel, um zu überprüfen, ob an in Ihrem Namen mithilfe von [Forward Access Sessions (FAS)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html) eine Anfrage an einen anderen Dienst AWS-Service stellt.
Der Anfragekontextschlüssel gibt `true` zurück, wenn ein Service Sitzungen mit direktem Zugriff verwendet, um eine Anfrage im Namen des ursprünglichen IAM-Prinzipals zu stellen. Der Anforderungskontextschlüssel gibt auch `false` zurück, wenn der Auftraggeber den Aufruf direkt durchführt.
+ **Verfügbarkeit** – Dieser Schlüssel ist immer im Anforderungskontext enthalten.
+ **Datentyp** – [boolesch](reference_policies_elements_condition_operators.md#Conditions_Boolean)
+ **Werttyp** - Einzelwertig
### aws:CalledViaAWSMCP
Verwenden Sie diesen Schlüssel, um die Dienste in der Richtlinie mit den AWS MCP-Diensten zu vergleichen, die Anfragen im Namen des IAM-Prinzipals (Benutzer oder Rolle) gestellt haben. Wenn ein Principal eine Anfrage an einen AWS MCP-Dienst stellt, verwendet dieser Dienst die Anmeldeinformationen des Prinzipals, um nachfolgende Anfragen an andere Dienste zu stellen. Wenn die Anfrage über einen AWS MCP-Dienst gestellt wird, wird diesem Schlüssel der Wert des Dienstprinzipals zugewiesen. Der `aws:CalledViaAWSMCP` Schlüssel enthält den Dienstprinzipalnamen des MCP-Dienstes, der Anfragen im Namen des Prinzipals gestellt hat.
+ **Verfügbarkeit** — Dieser Schlüssel ist in der Anfrage enthalten, wenn ein AWS MCP-Service die Anmeldeinformationen eines IAM-Prinzipals verwendet, um eine Anfrage an einen Dienst zu stellen. AWS Dieser Schlüssel ist auch nicht vorhanden, wenn der Auftraggeber den Aufruf direkt durchführt.
+ **Datentyp** – [Zeichenfolge](reference_policies_elements_condition_operators.md#Conditions_String)
+ **Werttyp** - Einzelwertig
Sie können diesen Bedingungsschlüssel verwenden, um den Zugriff zu erlauben oder zu verweigern, je nachdem, welcher spezifische MCP-Server die Anfrage initiiert hat. Die folgende Richtlinie verweigert beispielsweise sensible Löschvorgänge, wenn sie über einen bestimmten MCP-Server initiiert werden:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenySensitiveActionsViaSpecificMCP",
"Effect": "Deny",
"Action": [
"s3:DeleteBucket",
"s3:DeleteObject",
"dynamodb:DeleteTable"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:CalledViaAWSMCP": "aws-mcp.amazonaws.com"
}
}
}
]
}
```
### aws:ViaAWSMCPService
Verwenden Sie diesen Schlüssel, um zu überprüfen, ob ein AWS MCP-Dienst in Ihrem Namen mithilfe von Forward Access Sessions (FAS) eine Anfrage an einen anderen AWS Dienst stellt. Der Anforderungskontextschlüssel wird zurückgegeben`true`, wenn ein AWS MCP-Service eine Anfrage im Namen des ursprünglichen AWS IAM-Prinzipals an einen Dienst weiterleitet. Der Anforderungskontextschlüssel gibt auch `false` zurück, wenn der Auftraggeber den Aufruf direkt durchführt.
+ **Verfügbarkeit** — Dieser Schlüssel ist im Anforderungskontext enthalten, wenn ein AWS MCP-Server im Namen eines IAM-Prinzipals eine Anfrage an einen nachgeschalteten AWS Dienst stellt.
+ **Datentyp** – [boolesch](reference_policies_elements_condition_operators.md#Conditions_Boolean)
+ **Werttyp** - Einzelwertig
Sie können diesen Schlüssel verwenden, um bestimmte Aktionen einzuschränken, wenn sie über MCP-Server gesendet werden. Die folgende Richtlinie verweigert beispielsweise sensible Löschvorgänge, wenn sie über einen AWS MCP-Server initiiert werden:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenySensitiveActionsViaMCP",
"Effect": "Deny",
"Action": [
"s3:DeleteBucket",
"s3:DeleteObject",
"dynamodb:DeleteTable"
],
"Resource": "*",
"Condition": {
"Bool": {
"aws:ViaAWSMCPService": "true"
}
}
}
]
}
```
### aws:CurrentTime
Verwenden Sie diesen Schlüssel, um das Datum und die Uhrzeit der Anforderung mit dem Datum und der Uhrzeit zu vergleichen, das bzw. die Sie in der Richtlinie angeben. Informationen zum Anzeigen einer Beispielrichtlinie, die diesen Bedingungsschlüssel verwendet, finden Sie unter [AWS: Ermöglicht Zugriff basierend auf Datum und Uhrzeit](reference_policies_examples_aws-dates.md).
+ -**Verfügbarkeit** – Dieser Schlüssel ist immer im Anforderungskontext enthalten.
+ **Datentyp** – [Datum](reference_policies_elements_condition_operators.md#Conditions_Date)
+ **Werttyp** - Einzelwertig
### aws:EpochTime
Verwenden Sie diesen Schlüssel, um das Datum und die Uhrzeit der Anforderung in Epochen- oder Unix-Zeit mit dem Wert zu vergleichen, den Sie in der Richtlinie angeben. Dieser Schlüssel akzeptiert auch die Anzahl der Sekunden, die seit dem 1. Januar 1970 verstrichen sind.
+ **Verfügbarkeit** – Dieser Schlüssel ist immer im Anforderungskontext enthalten.
+ **Datentyp** – [Datum](reference_policies_elements_condition_operators.md#Conditions_Date), [Numerisch](reference_policies_elements_condition_operators.md#Conditions_Numeric)
+ **Werttyp** - Einzelwertig
### aws:referer
Verwenden Sie diesen Schlüssel, um den Referrer, der im Client-Browser auf die Anforderung verwiesen hat, mit dem Referrer zu vergleichen, den Sie in der Richtlinie angeben. Der `aws:referer`-Anforderungskontextwert wird vom Aufrufer in einem HTTP-Header bereitgestellt. Der `Referer`-Header ist in einer Webbrowser-Anforderung enthalten, wenn Sie einen Link auf einer Webseite auswählen. Der `Referer`-Header enthält die URL der Webseite, auf der der Link ausgewählt wurde.
+ **Verfügbarkeit** — Dieser Schlüssel ist nur dann im Anforderungskontext enthalten, wenn die Anforderung an die AWS Ressource durch einen Link von einer Webseiten-URL im Browser aufgerufen wurde. Dieser Schlüssel ist nicht für programmatische Anforderungen enthalten, da er keinen Browserlink verwendet, um auf die AWS -Ressource zuzugreifen.
+ **Datentyp** – [Zeichenfolge](reference_policies_elements_condition_operators.md#Conditions_String)
+ **Werttyp** - Einzelwertig
Sie können beispielsweise direkt über eine URL oder einen direkten API-Aufruf auf ein Amazon S3-Objekt zugreifen. Weitere Informationen finden Sie unter [Amazon S3-API-Vorgänge direkt mit einem Webbrowser](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies.html#example-bucket-policies-use-case-4). Wenn Sie von einer URL, die in einer Webseite existiert, auf ein Amazon S3-Objekt zugreifen, wird die URL der Quellwebseite in `aws:referer` verwendet. Wenn Sie auf ein Amazon S3-Objekt zugreifen, indem Sie die URL in Ihren Browser eingeben, ist `aws:referer` nicht vorhanden. Wenn Sie die API direkt aufrufen, ist `aws:referer` auch nicht vorhanden. Sie können den `aws:referer`-Bedingungsschlüssel in einer Richtlinie verwenden, um Anforderungen von einem bestimmten Referer zuzulassen, z. B. einen Link auf einer Webseite in der Domain Ihres Unternehmens.
**Warnung**
Dieser Schlüssel sollte mit Vorsicht verwendet werden. Ein öffentlich bekannter Referer-Header-Wert sollte möglichst nicht eingeschlossen werden. Nicht autorisierte Parteien können mit modifizierten oder benutzerdefinierten Browsern einen beliebigen `aws:referer`-Wert ihrer Wahl bereitstellen. Daher `aws:referer` sollte er nicht verwendet werden, um Unbefugte daran zu hindern, direkte AWS Anfragen zu stellen. Die Funktion wird nur bereitgestellt, damit Kunden ihre digitalen, in Amazon S3 gespeicherten Inhalte vor der Referenzierung auf nicht autorisierte Drittanbieter-Websites schützen können.
### aws:RequestedRegion
Verwenden Sie diesen Schlüssel, um die AWS Region, die in der Anfrage aufgerufen wurde, mit der Region zu vergleichen, die Sie in der Richtlinie angeben. Mit diesem globalen Bedingungsschlüssel können Sie steuern, welche Regionen angefordert werden können. Informationen zur Anzeige der AWS Regionen für die einzelnen Dienste finden Sie unter [Dienstendpunkte und Kontingente](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html) in der *Allgemeine Amazon Web Services-Referenz*.
+ -**Verfügbarkeit** – Dieser Schlüssel ist immer im Anforderungskontext enthalten.
+ **Datentyp** – [Zeichenfolge](reference_policies_elements_condition_operators.md#Conditions_String)
+ **Werttyp** - Einzelwertig
Globale Services wie IAM haben einen einzelnen Endpunkt. Da sich dieser Endpunkt in der US East (N. Virginia)-Region befindet, werden IAM-Anrufe immer an die us-east-1 Region gesendet. Wenn Sie beispielsweise eine Richtlinie erstellen, die den Zugriff auf alle Services verweigert, wenn die angeforderte Region nicht us-west-2 ist, schlagen die IAM-Aufrufe immer fehl. Ein Beispiel dafür, wie Sie dieses Problem umgehen können, finden Sie unter [NotAction Mit Verweigern](reference_policies_elements_notaction.md).
**Anmerkung**
Mit dem Bedingungsschlüssel `aws:RequestedRegion` können Sie steuern, welche Endpunkt eines Services aufgerufen wird, jedoch nicht die Auswirkungen der Operation. Einige Services haben regionsübergreifende Auswirkungen.
Amazon S3 verfügt beispielsweise über API-Operationen, die sich über Regionen erstrecken.
Sie können `s3:PutBucketReplication` in einer Region aufrufen (betroffen über den Bedingungsschlüssel `aws:RequestedRegion`), während andere Regionen basierend auf den Konfigurationseinstellungen der Replikation betroffen sind.
Sie können `s3:CreateBucket` aufrufen, um einen Bucket in einer anderen Region zu erstellen, und mit dem `s3:LocationConstraint`-Bedingungsschlüssel die entsprechenden Regionen steuern.
Sie können diesen Kontextschlüssel verwenden, um den Zugriff auf AWS Dienste innerhalb einer bestimmten Gruppe von Regionen einzuschränken. Mit der folgenden Richtlinie wird Benutzern beispielsweise erlaubt, alle Amazon EC2-Instances in der AWS-Managementkonsole anzuzeigen. Sie gestattet den Benutzern aber nur Änderungen an Instances in Irland (eu-west-1), London (eu-west-2) und Paris (eu-west-3).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "InstanceConsoleReadOnly",
"Effect": "Allow",
"Action": [
"ec2:Describe*",
"ec2:Export*",
"ec2:Get*",
"ec2:Search*"
],
"Resource": "*"
},
{
"Sid": "InstanceWriteRegionRestricted",
"Effect": "Allow",
"Action": [
"ec2:Associate*",
"ec2:Import*",
"ec2:Modify*",
"ec2:Monitor*",
"ec2:Reset*",
"ec2:Run*",
"ec2:Start*",
"ec2:Stop*",
"ec2:Terminate*"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestedRegion": [
"eu-west-1",
"eu-west-2",
"eu-west-3"
]
}
}
}
]
}
```
------
### aws:RequestTag/*tag-key*
Verwenden Sie diesen Schlüssel, um das Tag-Schlüssel-Wert-Paar, das in der Anforderung übergeben wurde, mit dem Tag-Paar zu vergleichen, das Sie in der Richtlinie angeben. Sie können beispielsweise prüfen, ob die Anforderung den Tag-Schlüssel `"Dept"` enthält und dieser den Wert `"Accounting"` hat. Weitere Informationen finden Sie unter [Steuern des Zugriffs bei Anfragen AWS](access_tags.md#access_tags_control-requests).
+ **Verfügbarkeit** – Dieser Schlüssel ist im Anforderungskontext enthalten, wenn Tag-Schlüssel-Wert-Paare in der Anforderung übergeben werden. Wenn mehrere Tags in der Anforderung übergeben werden, gibt es einen Kontextschlüssel für jedes Tag-Schlüssel-Wert-Paar.
+ **Datentyp** – [Zeichenfolge](reference_policies_elements_condition_operators.md#Conditions_String)
+ **Werttyp** - Einzelwertig
Dieser Kontextschlüssel ist so formatiert`"aws:RequestTag/tag-key":"tag-value"`, *tag-key* dass er ein Tag-Schlüssel- und Wertepaar darstellt. *tag-value* Bei Tag-Schlüsseln wird die Groß- und Kleinschreibung nicht beachtet. Dies bedeutet Folgendes: Wenn Sie `"aws:RequestTag/TagKey1": "Value1"` im Bedingungselement Ihrer Richtlinie angeben, stimmt die Bedingung mit einem Ressourcen-Tag-Schlüssel mit dem Namen `TagKey1` oder `tagkey1` überein, aber nicht mit beiden. Bei den Werten in diesen key/value Tag-Paaren wird zwischen Groß- und Kleinschreibung unterschieden. Dies bedeutet Folgendes: Wenn Sie `"aws:RequestTag/TagKey1": "Production"` im Bedingungselement Ihrer Richtlinie angeben, stimmt die Bedingung mit einem Anfrage-Tag-Wert mit dem Namen `Production` überein, jedoch nicht mit `production` oder `PRODUCTION`.
Dieses Beispiel zeigt, dass der Schlüssel zwar einwertig ist, Sie aber dennoch mehrere Schlüssel-Wert-Paare in einer Anforderung verwenden können, wenn die Schlüssel unterschiedlich sind.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "ec2:CreateTags",
"Resource": "arn:aws:ec2::111122223333:instance/*",
"Condition": {
"StringEquals": {
"aws:RequestTag/environment": [
"preprod",
"production"
],
"aws:RequestTag/team": [
"engineering"
]
}
}
}
}
```
------
### aws:TagKeys
Verwenden Sie diesen Schlüssel, um die Tag-Schlüssel in einer Anforderung mit den Schlüsseln zu vergleichen, die Sie in der Richtlinie angeben. Wir empfehlen, dass Sie bei der Verwendung von Richtlinien zur Zugriffskontrolle mithilfe von Tags den `aws:TagKeys`-Bedingungsschlüssel verwenden, um festzulegen, welche Tag-Schlüssel zulässig sind. Beispielrichtlinien und weitere Informationen finden Sie unter [Zugriffssteuerung auf der Grundlage von Tag-Schlüsseln](access_tags.md#access_tags_control-tag-keys).
+ **Verfügbarkeit** – Dieser Schlüssel ist in den Anforderungskontext enthalten, wenn die Operation die Übergabe von Tags in der Anforderung unterstützt.
+ **Datentyp** – [Zeichenfolge](reference_policies_elements_condition_operators.md#Conditions_String) (Liste)
+ **Werttyp** - Mehrwertig
Dieser Kontextschlüssel ist formatiert `"aws:TagKeys":"tag-key"` und enthält eine Liste von Tag-Schlüsseln ohne Werte (z. B.`["Dept","Cost-Center"]`). *tag-key*
Da Sie mehrere Tag-Schlüssel-Wert-Paare in eine Anforderung aufnehmen können, könnte der Anforderungsinhalt eine [mehrwertige](reference_policies_condition-single-vs-multi-valued-context-keys.md) Anforderung sein. In diesem Fall müssen Sie die Operatoren `ForAllValues` oder `ForAnyValue` verwenden. Weitere Informationen finden Sie unter [Operatoren für mehrwertige Kontextschlüssel festlegen](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys).
Einige Services unterstützen das Markieren mit Ressourcenoperationen, wie etwa das Erstellen, Ändern oder Löschen einer Ressource. Um das Markieren und Operationen als einzelnen Aufruf zu erlauben, müssen Sie eine Richtlinie erstellen, die die Aktionen Markieren und Ressourcenbearbeitung enthält. Anschließend können Sie den `aws:TagKeys`-Bedingungsschlüssel zum Erzwingen mit spezifischen Tag-Schlüssel in der Anforderung verwenden. Beispiel: Zum Einschränken von Tags, wenn jemand einen Amazon EC2-Snapshot erstellt, müssen Sie die Aktion zum Erstellen eines `ec2:CreateSnapshot` ***und*** die Aktion zum Markieren von `ec2:CreateTags` in die Richtlinie einbeziehen. Eine Richtlinie für dieses Szenario, das `aws:TagKeys` verwendet, finden Sie unter [Erstellen eines Snapshots mit Tags](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ExamplePolicies_EC2.html#iam-creating-snapshot-with-tags) im *Amazon-EC2-Benutzerhandbuch*.
### aws:SecureTransport
Mit diesem Schlüssel können Sie überprüfen, ob die Anfrage per TLS gesendet wurde. Der Anforderungskontext gibt `true` oder `false` zurück. In einer Richtlinie können Sie bestimmte Aktionen nur zulassen, wenn die Anforderung mit TLS gesendet wird.
+ -**Verfügbarkeit** – Dieser Schlüssel ist immer im Anforderungskontext enthalten.
+ **Datentyp** – [boolesch](reference_policies_elements_condition_operators.md#Conditions_Boolean)
+ **Werttyp** - Einzelwertig
**Anmerkung**
Wenn AWS-Services Sie in Ihrem Namen Anrufe AWS-Services an andere Personen tätigen (service-to-service Anrufe), wird ein bestimmter netzwerkspezifischer Autorisierungskontext unkenntlich gemacht. Wenn Ihre Richtlinie diesen Bedingungsschlüssel zusammen mit `Deny` Kontoauszügen verwendet, werden AWS-Service Principals möglicherweise unbeabsichtigt blockiert. Um die korrekte Funktion von AWS-Services unter Einhaltung Ihrer Sicherheitsanforderungen zu gewährleisten, schließen Sie Service-Prinzipale von Ihren `Deny`-Anweisungen aus, indem Sie den `aws:PrincipalIsAWSService`-Bedingungsschlüssel mit dem Wert `false` hinzufügen. Beispiel:
```
{
"Effect": "Deny",
"Action": "s3:*",
"Resource": "*",
"Condition": {
"Bool": {
"aws:SecureTransport": "false",
"aws:PrincipalIsAWSService": "false"
}
}
}
```
Diese Richtlinie verweigert den Zugriff auf Amazon S3 S3-Operationen, wenn HTTPS nicht verwendet `aws:SecureTransport` wird (ist falsch), sondern nur für AWS Nicht-Service-Principals. Dadurch wird sichergestellt, dass Ihre bedingten Einschränkungen für alle Prinzipale außer Principals gelten. AWS-Service
### aws:SourceAccount
Verwenden Sie diesen Schlüssel, um die Konto-ID der Ressource, die eine service-to-service Anfrage stellt, mit der Konto-ID zu vergleichen, die Sie in der Richtlinie angeben, aber nur, wenn die Anfrage von einem AWS Dienstprinzipal gestellt wird.
+ **Verfügbarkeit** — Dieser Schlüssel ist nur dann im Anforderungskontext enthalten, wenn der Aufruf Ihrer Ressource direkt von einem [AWS Service Principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html#principal-services) im Namen einer Ressource erfolgt, für die die Konfiguration die service-to-service Anfrage ausgelöst hat. Der aufrufende Service muss die Konto-ID der ursprünglichen Ressource an den aufgerufenen Service weitergeben.
**Anmerkung**
Dieser Schlüssel bietet einen einheitlichen Mechanismus zur Durchsetzung der serviceübergreifenden Verwechslungsgefahr über alle AWS-Services hinweg. Allerdings erfordern nicht alle Serviceintegrationen die Verwendung dieses globalen Bedingungsschlüssels. Weitere Informationen zu servicespezifischen Mechanismen zur Minderung der dienstübergreifenden Risiken, die sich durch verwirrte Stellvertreter ergeben, finden AWS-Services Sie in der von Ihnen verwendeten Dokumentation.
![\[aws: SourceAccount\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/images/sourceAccount.png)
+ **Datentyp** – [Zeichenfolge](reference_policies_elements_condition_operators.md#Conditions_String)
+ **Werttyp** - Einzelwertig
Durch die Nutzung dieses Bedingungsschlüssels können Sie sicherstellen, dass ein aufrufender Service nur dann Zugriff auf Ihre Ressource hat, wenn die Anfrage von einem bestimmten Konto stammt. Sie können beispielsweise die folgende Ressourcenkontrollrichtlinie (RCP) anhängen, um Anfragen von Service-Prinzipalen für Amazon-S3-Buckets abzulehnen, sofern diese nicht durch eine Ressource im angegebenen Konto ausgelöst wurden. Diese Richtlinie wendet die Steuerung nur auf Anfragen von Service-Prinzipalen (`"Bool": {"aws:PrincipalIsAWSService": "true"}`) an, bei denen der `aws:SourceAccount`-Schlüssel vorhanden ist (`"Null": {"aws:SourceAccount": "false"}`), sodass Serviceintegrationen, für die die Verwendung dieses Schlüssels nicht erforderlich ist, und Aufrufe Ihrer Prinzipale nicht betroffen sind. Wenn der Schlüssel `aws:SourceAccount` im Anfragekontext vorhanden ist, wird die `Null`-Bedingung als `true` ausgewertet, wodurch die Verwendung des Schlüssels `aws:SourceAccount` erzwungen wird.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "RCPEnforceConfusedDeputyProtection",
"Effect": "Deny",
"Principal": "*",
"Action": [
"s3:*"
],
"Resource": "*",
"Condition": {
"StringNotEqualsIfExists": {
"aws:SourceAccount": "111122223333"
},
"Null": {
"aws:SourceAccount": "false"
},
"Bool": {
"aws:PrincipalIsAWSService": "true"
}
}
}
]
}
```
------
Verwenden Sie in ressourcenbasierten Richtlinien, bei denen der Principal ein AWS-Service Principal ist, den Schlüssel, um die dem Service gewährten Berechtigungen einzuschränken. Wenn beispielsweise ein Amazon-S3-Bucket so konfiguriert ist, dass Benachrichtigungen an ein Amazon-SNS-Thema gesendet werden, ruft der Amazon-S3-Service die `sns:Publish`-API-Operation für alle konfigurierten Ereignisse auf. Setzen Sie in der Themenrichtlinie, die den Vorgang `sns:Publish` erlaubt, den Wert des Bedingungsschlüssels auf die Konto-ID des Amazon-S3-Buckets.
### aws:SourceArn
Verwenden Sie diesen Schlüssel, um den [Amazon-Ressourcennamen (ARN)](reference_identifiers.md#identifiers-arns) der Ressource, die eine service-to-service Anfrage stellt, mit dem ARN zu vergleichen, den Sie in der Richtlinie angeben, aber nur, wenn die Anfrage von einem AWS Service Principal gestellt wird. Wenn der ARN der Quelle die Konto-ID enthält, ist es nicht erforderlich, `aws:SourceAccount` mit `aws:SourceArn` zu verwenden.
Dieser Schlüssel funktioniert nicht mit dem ARN des Auftraggebers, der die Anforderung stellt. Nutzen Sie stattdessen `aws:PrincipalArn`.
+ **Verfügbarkeit** — Dieser Schlüssel ist nur dann im Anforderungskontext enthalten, wenn der Aufruf Ihrer Ressource direkt von einem [AWS Service Principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html#principal-services) im Namen einer Ressource erfolgt, für die die Konfiguration die service-to-service Anfrage ausgelöst hat. Der aufrufende Service muss den ARN der ursprünglichen Ressource an den aufgerufenen Service übergeben.
**Anmerkung**
Dieser Schlüssel bietet einen einheitlichen Mechanismus zur Durchsetzung der serviceübergreifenden Verwechslungsgefahr über alle AWS-Services hinweg. Allerdings erfordern nicht alle Serviceintegrationen die Verwendung dieses globalen Bedingungsschlüssels. Weitere Informationen zu servicespezifischen Mechanismen zur Minderung der dienstübergreifenden Risiken, die sich durch verwirrte Stellvertreter ergeben, finden AWS-Services Sie in der von Ihnen verwendeten Dokumentation.
![\[aws: SourceArn\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/images/sourceArn.png)
+ **Datentyp** – ARN
AWS empfiehlt, beim Vergleich [ARN-Operatoren](reference_policies_elements_condition_operators.md#Conditions_ARN) anstelle von [Zeichenkettenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String) zu verwenden ARNs.
+ **Werttyp** - Einzelwertig
Durch die Nutzung dieses Bedingungsschlüssels können Sie sicherstellen, dass ein aufrufender Service nur dann Zugriff auf Ihre Ressource hat, wenn die Anfrage von einer bestimmten Ressource stammt. Wenn Sie eine ressourcenbasierte Richtlinie mit einem AWS-Service Prinzipal als Hauptbenutzer verwenden`Principal`, legen Sie den Wert dieses Bedingungsschlüssels auf den ARN der Ressource fest, auf die Sie den Zugriff einschränken möchten. Wenn beispielsweise ein Amazon-S3-Bucket so konfiguriert ist, dass Benachrichtigungen an ein Amazon-SNS-Thema gesendet werden, ruft der Amazon-S3-Service die `sns:Publish`-API-Operation für alle konfigurierten Ereignisse auf. Setzen Sie in der Themenrichtlinie, die den Vorgang `sns:Publish` erlaubt, den Wert des Bedingungsschlüssels auf den ARN des Amazon-S3-Buckets. Empfehlungen zur Verwendung dieses Bedingungsschlüssels in ressourcenbasierten Richtlinien finden Sie in der Dokumentation der von Ihnen verwendeten AWS-Services .
### aws:SourceOrgID
Verwenden Sie diesen Schlüssel, um die [Organisations-ID](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_details.html) der Ressource, die eine service-to-service Anfrage stellt, mit der Organisations-ID zu vergleichen, die Sie in der Richtlinie angeben. Dies gilt jedoch nur, wenn die Anfrage von einem AWS Dienstprinzipal gestellt wird. Wenn Sie Konten in einer Organisation in AWS Organizations hinzufügen und entfernen, schließen Richtlinien, die den Schlüssel `aws:SourceOrgID` enthalten, automatisch die richtigen Konten ein und Sie müssen die Richtlinien nicht manuell aktualisieren.
+ **Verfügbarkeit** – Dieser Schlüssel ist nur dann im Anforderungskontext enthalten, wenn der Anruf an Ihre Ressource direkt von einem [AWS -Service-Prinzipal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html#principal-services) im Namen einer Ressource erfolgt, die einem Konto gehört, das Mitglied einer Organisation ist. Der aufrufende Service übergibt den ARN der ursprünglichen Ressource an den aufgerufenen Service.
**Anmerkung**
Dieser Schlüssel bietet einen einheitlichen Mechanismus zur Durchsetzung der serviceübergreifenden Verwechslungsgefahr über alle AWS-Services hinweg. Allerdings erfordern nicht alle Serviceintegrationen die Verwendung dieses globalen Bedingungsschlüssels. Weitere Informationen zu servicespezifischen Mechanismen zur Minderung der dienstübergreifenden Risiken für verwirrte Stellvertreter finden AWS-Services Sie in der von Ihnen verwendeten Dokumentation.
![\[aws: ID SourceOrg\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/images/sourceOrgID.png)
+ **Datentyp** – [Zeichenfolge](reference_policies_elements_condition_operators.md#Conditions_String)
+ **Werttyp** - Einzelwertig
Durch die Nutzung dieses Bedingungsschlüssels können Sie sicherstellen, dass ein aufrufender Service nur dann Zugriff auf Ihre Ressource hat, wenn die Anfrage von einer bestimmten Organisation stammt. Sie können beispielsweise die folgende Resource Control Policy (RCP) anhängen, um Anfragen von Service Principals für Amazon S3 S3-Buckets abzulehnen, sofern sie nicht durch eine Ressource in der angegebenen Organisation ausgelöst wurden. AWS Diese Richtlinie wendet die Steuerung nur auf Anfragen von Service-Prinzipalen (`"Bool": {"aws:PrincipalIsAWSService": "true"}`) an, bei denen der Schlüssel `aws:SourceAccount` vorhanden ist (`"Null": {"aws:SourceAccount": "false"}`), sodass Service-Integrationen, für die die Verwendung des Schlüssels nicht erforderlich ist, und Aufrufe Ihrer Prinzipale nicht betroffen sind. Wenn der Schlüssel `aws:SourceAccount` im Anfragekontext vorhanden ist, wird die `Null`-Bedingung als `true` ausgewertet, wodurch die Verwendung des Schlüssels `aws:SourceOrgID` erzwungen wird. Wir verwenden `aws:SourceAccount` anstelle von `aws:SourceOrgID` im Bedingungsoperator `Null`, sodass die Kontrolle auch dann gilt, wenn die Anfrage von einem Konto stammt, das keiner Organisation angehört.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "RCPEnforceConfusedDeputyProtection",
"Effect": "Deny",
"Principal": "*",
"Action": [
"s3:*"
],
"Resource": "*",
"Condition": {
"StringNotEqualsIfExists": {
"aws:SourceOrgID": "o-xxxxxxxxxx"
},
"Null": {
"aws:SourceAccount": "false"
},
"Bool": {
"aws:PrincipalIsAWSService": "true"
}
}
}
]
}
```
------
### aws:SourceOrgPaths
Verwenden Sie diesen Schlüssel, um den AWS Organizations Pfad der Ressource, die eine service-to-service Anfrage stellt, mit dem Organisationspfad zu vergleichen, den Sie in der Richtlinie angeben, aber nur, wenn die Anfrage von einem AWS Service Principal gestellt wird. Ein AWS Organizations Pfad ist eine Textdarstellung der Struktur einer AWS Organizations Entität. Weitere Informationen zu Pfaden und deren Verwendung finden Sie unter [Den AWS Organizations -Entitätspfad verstehen](access_policies_last-accessed-view-data-orgs.md#access_policies_last-accessed-viewing-orgs-entity-path).
+ **Verfügbarkeit** – Dieser Schlüssel ist nur dann im Anforderungskontext enthalten, wenn der Anruf an Ihre Ressource direkt von einem [AWS -Service-Prinzipal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html#principal-services) im Namen einer Ressource erfolgt, die einem Konto gehört, das Mitglied einer Organisation ist. Der aufrufende Service übergibt den Organisations-Pfad der ursprünglichen Ressource an den aufgerufenen Service.
**Anmerkung**
Dieser Schlüssel bietet einen einheitlichen Mechanismus zur Durchsetzung der serviceübergreifenden Verwechslungsgefahr über alle AWS-Services hinweg. Allerdings erfordern nicht alle Serviceintegrationen die Verwendung dieses globalen Bedingungsschlüssels. Weitere Informationen zu servicespezifischen Mechanismen zur Minderung der dienstübergreifenden Risiken für verwirrte Stellvertreter finden AWS-Services Sie in der von Ihnen verwendeten Dokumentation.
![\[aws: SourceOrgPaths\]](http://docs.aws.amazon.com/de_de/IAM/latest/UserGuide/images/sourceOrgPaths.png)
+ **Datentyp** – [Zeichenfolge](reference_policies_elements_condition_operators.md#Conditions_String) (Liste)
+ **Werttyp** - Mehrwertig
Verwenden Sie diesen Bedingungsschlüssel, um sicherzustellen, dass ein aufrufender Service nur dann auf Ihre Ressource zugreifen kann, wenn die Anfrage von einer bestimmten Organisationseinheit (OE) in AWS Organizations stammt.
Um Auswirkungen auf Service-Integrationen zu verhindern, die die Verwendung dieses Schlüssels nicht erfordern, verwenden Sie ähnlich wie bei `aws:SourceOrgID` den `Null`-Bedingungsoperator mit dem Bedingungsschlüssel `aws:SourceAccount`, sodass die Steuerung weiterhin gilt, wenn die Anforderung von einem Konto stammt, das nicht einer Organisation angehört.
```
{
"Condition": {
"ForAllValues:StringNotLikeIfExists": {
"aws:SourceOrgPaths": "o-a1b2c3d4e5/r-ab12/ou-ab12-11111111/ou-ab12-22222222/"
},
"Null": {
"aws:SourceAccount": "false"
},
"Bool": {
"aws:PrincipalIsAWSService": "true"
}
}
}
```
`aws:SourceOrgPaths` ist ein mehrwertiger Bedingungsschlüssel. Mehrwertige Bedingungsschlüssel können im Anforderungskontext mehrere Werte haben. Sie müssen die Set-Operatoren `ForAnyValue` oder `ForAllValues` zusammen mit [String-Bedingungsoperatoren](reference_policies_elements_condition_operators.md#Conditions_String) für diesen Schlüssel verwenden. Weitere Hinweise zu mehrwertigen Bedingungsschlüsseln finden Sie unter [Operatoren für mehrwertige Kontextschlüssel festlegen](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys).
### aws:UserAgent
Verwenden Sie diesen Schlüssel, um die Client-Anwendung des Anforderers mit der Anwendung zu vergleichen, die Sie in der Richtlinie angeben.
+ **Verfügbarkeit** – Dieser Schlüssel ist immer im Anforderungskontext enthalten.
+ **Datentyp** – [Zeichenfolge](reference_policies_elements_condition_operators.md#Conditions_String)
+ **Werttyp** - Einzelwertig
**Warnung**
Dieser Schlüssel sollte mit Vorsicht verwendet werden. Da der Wert `aws:UserAgent` vom Aufrufer in einem HTTP-Header bereitgestellt wird, können nicht autorisierte Parteien modifizierte oder benutzerdefinierte Browser verwenden, um beliebige `aws:UserAgent`-Werte bereitzustellen. Daher `aws:UserAgent` sollte es nicht dazu verwendet werden, Unbefugte daran zu hindern, direkte AWS Anfragen zu stellen. Sie können es verwenden, um nur bestimmte Client-Anwendungen zuzulassen, und zwar erst nach dem Testen Ihrer Richtlinie.
### aws:IsMcpServiceAction
Verwenden Sie diesen Schlüssel, um zu überprüfen, ob es sich bei der autorisierten Aktion um eine MCP-Serviceaktion handelt. Dieser Schlüssel bezieht sich nicht auf Aktionen, die der MCP-Dienst für andere AWS Dienste ausführt.
+ **Verfügbarkeit** — Dieser Schlüssel ist im Anforderungskontext enthalten und nur dann auf True gesetzt, wenn der MCP-Dienst eine MCP-Dienstaktion autorisiert.
+ **Datentyp** – [boolesch](reference_policies_elements_condition_operators.md#Conditions_Boolean)
+ **Werttyp** - Einzelwertig
## Andere dienstübergreifende Bedingungsschlüssel
AWS STS [unterstützt [SAML-basierte Verbundbedingungsschlüssel und dienstübergreifende Bedingungsschlüssel](reference_policies_iam-condition-keys.md#condition-keys-saml) für den OIDC-Verbund.](reference_policies_iam-condition-keys.md#condition-keys-wif) Diese Schlüssel sind verfügbar, wenn ein Benutzer, der mithilfe von OIDC oder SAML verbunden war, Operationen in anderen Diensten ausführt. AWS
# IAM- und AWS STS Bedingungskontextschlüssel
Sie können das `Condition` Element in einer JSON-Richtlinie verwenden, um den Wert von Schlüsseln zu testen, die im Anforderungskontext aller AWS Anfragen enthalten sind. Diese Schlüssel enthalten Informationen zu der Anforderung selbst oder zu den Ressourcen, die die Anforderung referenziert. Sie können die Schlüssel auf bestimmte Werte überprüfen, bevor Sie die angeforderte Aktion zulassen. So können Sie genau steuern, wann Ihre JSON-Richtlinienanweisungen mit einer eingehenden Anforderung übereinstimmen. Weitere Informationen zur Verwendung des Elements `Condition` in JSON-Richtlinien finden Sie unter [IAM-JSON-Richtlinienelemente: Condition](reference_policies_elements_condition.md).
In diesem Thema werden die Schlüssel beschrieben, die vom IAM-Dienst (mit einem `iam:` Präfix) und dem Dienst () AWS -Security-Token-Service (mit einem `sts:` Präfix AWS STS) definiert und bereitgestellt werden. Verschiedene andere AWS Dienste stellen auch dienstspezifische Schlüssel bereit, die für die von diesem Dienst definierten Aktionen und Ressourcen relevant sind. Weitere Informationen finden Sie unter [Aktionen, Ressourcen und Bedingungsschlüssel für AWS Dienste](reference_policies_actions-resources-contextkeys.html). Weitere Informationen zu den unterstützten Bedingungsschlüsseln können Sie meist der Dokumentation des jeweiligen Service entnehmen. Weitere Informationen zu Schlüsseln, die Sie in Richtlinien für Amazon-S3-Ressourcen verwenden können, finden Sie beispielsweise unter [Amazon-S3-Richtlinienschlüssel](https://docs.aws.amazon.com/AmazonS3/latest/userguide/amazon-s3-policy-keys.html#AvailableKeys-iamV2) im *Benutzerhandbuch für Amazon Simple Storage Service*.
**Topics**
+ [Verfügbare Schlüssel für IAM](#available-keys-for-iam)
+ [Verfügbare Schlüssel für den AWS OIDC-Verbund](#condition-keys-wif)
+ [Verfügbare Schlüssel für den SAML-basierten AWS STS Verbund](#condition-keys-saml)
+ [Dienstübergreifende SAML-basierte Verbundkontextschlüssel AWS STS](#cross-condition-keys-saml)
+ [Verfügbare Schlüssel für AWS STS](#condition-keys-sts)
## Verfügbare Schlüssel für IAM
Sie können die folgenden Bedingungsschlüssel in Richtlinien verwenden, die zur Zugriffssteuerung auf IAM-Ressourcen genutzt werden:
**Ich bin: AssociatedResourceArn**
Funktioniert mit [ARN-Operatoren](reference_policies_elements_condition_operators.md#Conditions_ARN).
Gibt den ARN der Ressource an, der diese Rolle beim Zielservice zugeordnet wird. Die Ressource gehört normalerweise zu dem Service, an den der Auftraggeber die Rolle übergibt. Manchmal kann die Ressource zu einem dritten Service gehören. Sie können beispielsweise eine Rolle an Amazon EC2 Auto Scaling übergeben, die sie auf einer Amazon EC2-Instance verwenden. In diesem Fall würde die Bedingung mit dem ARN der Amazon EC2-Instance übereinstimmen.
Dieser Bedingungsschlüssel gilt nur für die [PassRole](id_roles_use_passrole.md)Aktion in einer Richtlinie. Er kann nicht verwendet werden, um eine andere Aktion zu beschränken.
Wenn die `iam:AssociatedResourceArn` Bedingung in einer Richtlinie verwendet wird, um die [PassRole](id_roles_use_passrole.md)Aktion einzuschränken, gelten besondere Überlegungen, wenn die Richtlinie den Zugriff für die [AddRoleToInstanceProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddRoleToInstanceProfile.html)Aktion definieren soll. In diesem Fall können Sie in der EC2-Instancr-ARN keine Region oder Instance-ID angeben. Der ARN -Wert muss `arn:aws:ec2:*:CallerAccountId:instance/*` lauten. Die Verwendung eines anderen ARN-Wertes kann zu unerwarteten Auswertungsergebnissen führen.
Verwenden Sie diesen Bedingungsschlüssel in einer identitätsbasierten Richtlinie, um einer Entität die Übergabe einer Rolle zu gestatten, jedoch nur, wenn diese Rolle der angegebenen Ressource zugeordnet ist. Beispielsweise können Sie einem IAM-Benutzer oder einer IAM-Rolle erlauben, jede Rolle an den Amazon-EC2-Service zu übergeben, um sie mit Instances im AWS-Konto zu verwenden. Der IAM-Benutzer oder die IAM-Rolle wäre nicht berechtigt, Rollen an andere Services zu übergeben.
```
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:PassedToService": "ec2.amazonaws.com"
},
"ArnLike": {
"iam:AssociatedResourceARN": [
"arn:aws:ec2:*:111122223333:instance/*"
]
}
}
}
```
AWS Dienste, die [iam:](#ck_PassedToService) unterstützen PassedToService auch diesen Bedingungsschlüssel.
**iam: Name AWSService**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Gibt den AWS Dienst an, dem diese Rolle zugewiesen ist.
Dieser Bedingungsschlüssel wird von der [https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateServiceLinkedRole.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateServiceLinkedRole.html)-API-Operation unterstützt.
Informationen darüber, welche Services die Verwendung von serviceverknüpften Rollen unterstützen, finden Sie unter [AWS Dienste, die mit IAM funktionieren](reference_aws-services-that-work-with-iam.md). Suchen Sie nach den Services, für die **Ja** in der Spalte **Serviceverknüpfte Rolle** angegeben ist. Wählen Sie über einen Link **Ja** aus, um die Dokumentation zu einer serviceverknüpften Rolle für diesen Service anzuzeigen.
In diesem Beispiel erlauben Sie einer Entität das Erstellen einer serviceverknüpften Rolle mithilfe der [https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateServiceLinkedRole.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateServiceLinkedRole.html)-API-Operation, wenn der Servicename *access-analyzer.amazonaws.com* lautet.
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "*",
"Condition": {
"StringLike": {
"iam:AWSServiceName": "access-analyzer.amazonaws.com"
}
}
}]
}
```
**iam:FIDO-certification**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Überprüft die FIDO-Zertifizierungsstufe des MFA-Geräts zum Zeitpunkt der Registrierung eines FIDO-Sicherheitsschlüssels. Die Gerätezertifizierung wird vom [FIDO Alliance Metadata Service (MDS)](https://fidoalliance.org/metadata/) abgerufen. Wenn sich der Zertifizierungsstatus oder die Stufe Ihres FIDO-Sicherheitsschlüssels ändert, wird dieser nicht aktualisiert, es sei denn, das Gerät wird deregistriert und erneut registriert, um die aktualisierten Zertifizierungsinformationen abzurufen.
Mögliche Werte von L1, L1plus, L2, L2plus, L3, L3plus
In diesem Beispiel registrieren Sie einen Sicherheitsschlüssel und erhalten die FIDO Level 1 Plus-Zertifizierung für Ihr Gerät.
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "iam:EnableMFADevice",
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:RegisterSecurityKey" : "Create"
}
}
},
{
"Effect": "Allow",
"Action": "iam:EnableMFADevice",
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:RegisterSecurityKey" : "Activate",
"iam:FIDO-certification": "L1plus"
}
}
}
]
}
```
**iam:FIDO-FIPS-140-2-certification**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Überprüft die FIPS-140-2-Validierungszertifizierungsstufe des MFA-Geräts zum Zeitpunkt der Registrierung eines FIDO-Sicherheitsschlüssels. Die Gerätezertifizierung wird vom [FIDO Alliance Metadata Service (MDS)](https://fidoalliance.org/metadata/) abgerufen. Wenn sich der Zertifizierungsstatus oder die Stufe Ihres FIDO-Sicherheitsschlüssels ändert, wird dieser nicht aktualisiert, es sei denn, das Gerät wird deregistriert und erneut registriert, um die aktualisierten Zertifizierungsinformationen abzurufen.
Mögliche Werte von L1, L2, L3, L4
In diesem Beispiel registrieren Sie einen Sicherheitsschlüssel und erhalten die Zertifizierung FIPS-140-2 Level 2 für Ihr Gerät.
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "iam:EnableMFADevice",
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:RegisterSecurityKey" : "Create"
}
}
},
{
"Effect": "Allow",
"Action": "iam:EnableMFADevice",
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:RegisterSecurityKey" : "Activate",
"iam:FIDO-FIPS-140-2-certification": "L2"
}
}
}
]
}
```
**iam:FIDO-FIPS-140-3-certification**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Überprüft die FIPS-140-3-Validierungszertifizierungsstufe des MFA-Geräts zum Zeitpunkt der Registrierung eines FIDO-Sicherheitsschlüssels. Die Gerätezertifizierung wird vom [FIDO Alliance Metadata Service (MDS)](https://fidoalliance.org/metadata/) abgerufen. Wenn sich der Zertifizierungsstatus oder die Stufe Ihres FIDO-Sicherheitsschlüssels ändert, wird dieser nicht aktualisiert, es sei denn, das Gerät wird deregistriert und erneut registriert, um die aktualisierten Zertifizierungsinformationen abzurufen.
Mögliche Werte von L1, L2, L3, L4
In diesem Beispiel registrieren Sie einen Sicherheitsschlüssel und erhalten die Zertifizierung FIPS-140-3 Level 3 für Ihr Gerät.
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "iam:EnableMFADevice",
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:RegisterSecurityKey" : "Create"
}
}
},
{
"Effect": "Allow",
"Action": "iam:EnableMFADevice",
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:RegisterSecurityKey" : "Activate",
"iam:FIDO-FIPS-140-3-certification": "L3"
}
}
}
]
}
```
**ich bin: OrganizationsPolicyId**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Überprüft, ob die Richtlinie mit der angegebenen AWS Organizations ID mit der in der Anfrage verwendeten Richtlinie übereinstimmt. Informationen zum Anzeigen einer IAM-Beispielrichtlinie, die diesen Bedingungsschlüssel verwendet, finden Sie unter [IAM: Informationen über den Dienst, auf den zuletzt zugegriffen wurde, für eine AWS Organizations Richtlinie anzeigen](reference_policies_examples_iam_service-accessed-data-orgs.md).
**ich bin: PassedToService**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Gibt den ServiceAuftraggeber des Services an, an den eine Rolle übergeben werden kann. Dieser Bedingungsschlüssel gilt nur für die [PassRole](id_roles_use_passrole.md)Aktion in einer Richtlinie. Er kann nicht verwendet werden, um eine andere Aktion zu beschränken.
Wenn Sie diesen Bedingungsschlüssel in einer Richtlinie verwenden, geben Sie den Service über einen Dienstauftraggeber an. Ein ServiceAuftraggeber ist der Name eines Services, der im Element `Principal` einer Richtlinie angegeben werden kann. Standardformat: `SERVICE_NAME_URL.amazonaws.com`.
Sie können `iam:PassedToService` verwenden, um die Benutzer einzuschränken, damit sie Rollen nur an bestimmte Services übergeben können. Beispielsweise könnte ein Benutzer eine [Servicerolle](id_roles.md#iam-term-service-role) erstellen, die CloudWatch darauf vertraut, in seinem Namen Protokolldaten in einen Amazon S3 S3-Bucket zu schreiben. Der Benutzer muss dann eine Berechtigungsrichtlinie und eine Vertrauensrichtlinie an die neue Servicerolle anfügen. In diesem Fall muss die Vertrauensrichtlinie `cloudwatch.amazonaws.com` im Element `Principal` angeben. Eine Richtlinie, an die der Benutzer die Rolle übergeben kann CloudWatch, finden Sie unter[IAM: Übergeben Sie eine IAM-Rolle an einen bestimmten Dienst AWS](reference_policies_examples_iam-passrole-service.md).
Mit diesem Bedingungsschlüssel können Sie sicherstellen, dass Benutzer Servicerollen nur für die von Ihnen angegebenen Services erstellen. Wenn beispielsweise ein Benutzer mit der vorherigen Richtlinie versucht, eine Servicerolle für Amazon EC2 zu erstellen, schlägt der Vorgang fehl. Der Fehlschlag tritt auf, weil der Benutzer nicht über die Berechtigung verfügt, die Rolle an Amazon EC2 zu übergeben.
Manchmal übergeben Sie eine Rolle an einen Service, der die Rolle dann an einen anderen Service übergibt. `iam:PassedToService` enthält nur den endgültigen Dienst, der die Rolle übernimmt, nicht den Zwischendienst, der die Rolle übergibt.
Einige Services unterstützen diesen Bedingungsschlüssel nicht.
**ich bin: PermissionsBoundary**
Funktioniert mit [ARN-Operatoren](reference_policies_elements_condition_operators.md#Conditions_ARN).
Überprüft, ob die angegebene Richtlinie als Berechtigungsgrenze an die IAM-Auftraggeber-Ressource angefügt. Weitere Informationen finden Sie unter [Berechtigungsgrenzen für IAM-Entitäten](access_policies_boundaries.md)
**iam:PolicyARN**
Funktioniert mit [ARN-Operatoren](reference_policies_elements_condition_operators.md#Conditions_ARN).
Prüft den Amazon-Ressourcennamen (ARN) einer verwalteten Richtlinie in Anforderungen mit Beteiligung einer verwalteten Richtlinie. Weitere Informationen finden Sie unter [Steuern des Zugriffs auf Richtlinien](access_controlling.md#access_controlling-policies).
**ich bin: RegisterSecurityKey**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Prüft den aktuellen Status der MFA-Geräteaktivierung.
Mögliche Werte von `Create` oder `Activate`.
In diesem Beispiel registrieren Sie einen Sicherheitsschlüssel und erhalten die Zertifizierung FIPS-140-3 Level 1 für Ihr Gerät.
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "iam:EnableMFADevice",
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:RegisterSecurityKey" : "Create"
}
}
},
{
"Effect": "Allow",
"Action": "iam:EnableMFADevice",
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:RegisterSecurityKey" : "Activate",
"iam:FIDO-FIPS-140-3-certification": "L1"
}
}
}
]
}
```
**ich bin:/ResourceTag*key-name***
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Überprüft, ob das an die Identitätsressource (Benutzer oder Rolle) angefügte Tag mit dem angegebenen Schlüsselnamen und Wert übereinstimmt.
IAM und AWS STS unterstützen sowohl den `iam:ResourceTag` IAM-Bedingungsschlüssel als auch den `aws:ResourceTag` globalen Bedingungsschlüssel.
Sie können IAM-Ressourcen benutzerdefinierte Attribute in Form eines Schlüssel-Wert-Paares hinzufügen. Weitere Informationen zum Markieren von IAM-Ressourcen finden Sie unter [Tags für AWS Identity and Access Management Ressourcen](id_tags.md). Sie können `ResourceTag` verwenden, um den [Zugriff](access_tags.md#access_tags_control-resources) auf AWS -Ressourcen, einschließlich IAM-Ressourcen, zu steuern. IAM unterstützt jedoch keine Tags für Gruppen. Daher können Sie Tags nicht verwenden, um den Zugriff auf Gruppen zu steuern.
Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen könnten, die das Löschen von Benutzern mit dem **status=terminated**-Tag erlaubt. Um diese Richtlinie zu verwenden, ersetzen Sie die Richtlinie *italicized placeholder text* im Beispiel durch Ihre eigenen Informationen. Befolgen Sie dann die Anweisungen unter [Erstellen einer Richtlinie](access_policies_create.md) oder [Bearbeiten einer Richtlinie](access_policies_manage-edit.md).
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "iam:DeleteUser",
"Resource": "*",
"Condition": {"StringEquals": {"iam:ResourceTag/status": "terminated"}}
}]
}
```
**Ich bin: ServiceSpecificCredentialAgeDays**
Funktioniert mit [nummerischen Operatoren](reference_policies_elements_condition_operators.md#Conditions_Numeric).
Dieser Bedingungsschlüssel schränkt die Erstellung von servicespezifischen Anmeldeinformationen auf der Grundlage ihrer Ablaufeinstellungen ein. Damit können Sie das maximale Alter in Tagen für servicespezifische Anmeldeinformationen festlegen, die erstellt werden können.
Der gültige Bereich für Tage liegt zwischen 1 und 36 600 (mindestens 1 Tag, maximal 36 600 Tage).
Dieser Bedingungsschlüssel wird von der [https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateServiceSpecificCredential.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateServiceSpecificCredential.html)-API-Operation unterstützt.
In diesem Beispiel erlauben Sie einem Benutzer, servicespezifische Anmeldeinformationen für den Amazon Bedrock-Service nur zu erstellen, wenn diese innerhalb von 90 Tagen ablaufen.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:CreateServiceSpecificCredential",
"Resource": "arn:aws:iam::111122223333:user/username",
"Condition": {
"StringEquals": {
"iam:ServiceSpecificCredentialServiceName": "bedrock.amazonaws.com"
},
"NumericLessThanEquals": {
"iam:ServiceSpecificCredentialAgeDays": "90"
}
}
}
]
}
```
**ich bin: ServiceSpecificCredentialServiceName**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Gibt an, welche AWS Dienste bei der Verwaltung dienstspezifischer Anmeldeinformationen verwendet werden können. Mit diesem Bedingungsschlüssel können Sie einschränken, welche AWS Dienste bei der Verwaltung dienstspezifischer Anmeldeinformationen zulässig sind.
Dieser Bedingungsschlüssel wird von folgenden API-Operationen unterstützt.
+ [https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateServiceSpecificCredential.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateServiceSpecificCredential.html)
+ [https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteServiceSpecificCredential.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteServiceSpecificCredential.html)
+ [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ResetServiceSpecificCredential.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ResetServiceSpecificCredential.html)
+ [https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateServiceSpecificCredential.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateServiceSpecificCredential.html)
Die folgenden Services werden für servicespezifische Anmeldeinformationen mit ihrer genauen Wertformatierung unterstützt:
+ `bedrock.amazonaws.com`
+ `cassandra.amazonaws.com`
+ `codecommit.amazonaws.com`
In diesem Beispiel ermöglichen Sie einem Benutzer, servicespezifische Anmeldeinformationen mithilfe der [https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateServiceSpecificCredential.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateServiceSpecificCredential.html)-API-Operation nur für den Amazon-Bedrock-Service zu erstellen.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:CreateServiceSpecificCredential",
"Resource": "arn:aws:iam::111122223333:user/username",
"Condition": {
"StringEquals": {
"iam:ServiceSpecificCredentialServiceName": "bedrock.amazonaws.com"
}
}
}
]
}
```
**ich bin: DelegationDuration**
Funktioniert mit [nummerischen Operatoren](reference_policies_elements_condition_operators.md#Conditions_Numeric).
Filtert den Zugriff auf der Grundlage der Dauer des temporären Zugriffs, der in einer Delegierungsanfrage angefordert wurde.
Produktanbieter können diesen Bedingungsschlüssel verwenden, um die maximale Dauer zu kontrollieren, die sie für Delegierungsanfragen an Kunden zulassen. Die Dauer wird in Sekunden angegeben und bestimmt, wie lange temporäre Anmeldeinformationen gültig bleiben, nachdem der Kunde das Exchange-Token freigegeben hat. Auf diese Weise können Produktanbieter interne Richtlinien zur Begrenzung der Zugriffsdauer je nach Anwendungsfall durchsetzen.
Dieser Bedingungsschlüssel wird von der `CreateDelegationRequest`-API-Operation unterstützt.
In diesem Beispiel erlauben Sie das Erstellen von Delegierungsanfragen nur, wenn die angeforderte Dauer 7200 Sekunden (2 Stunden) oder weniger beträgt.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:CreateDelegationRequest",
"Resource": "*",
"Condition": {
"NumericLessThanEquals": {
"iam:DelegationDuration": "7200"
}
}
}
]
}
```
**Ich bin: NotificationChannel**
Funktioniert mit [ARN-Operatoren](reference_policies_elements_condition_operators.md#Conditions_ARN).
Filtert den Zugriff auf der Grundlage des Amazon SNS SNS-Themen-ARN, der für den Empfang von Benachrichtigungen über Delegierungsanfragen angegeben ist.
Produktanbieter können diesen Bedingungsschlüssel verwenden, um einzuschränken, welche SNS-Themen für Benachrichtigungen über Delegierungsanfragen im CreateDelegationRequest API-Aufruf verwendet werden können. Produktanbieter müssen ein SNS-Thema angeben, um Benachrichtigungen über Statusänderungen zu erhalten und Tokens auszutauschen. Dadurch wird sichergestellt, dass Benachrichtigungen nur an zugelassene Kanäle innerhalb der Organisation des Produktanbieters gesendet werden.
Dieser Bedingungsschlüssel wird von der `CreateDelegationRequest`-API-Operation unterstützt.
In diesem Beispiel erlauben Sie die Erstellung von Delegierungsanfragen nur, wenn sie ein bestimmtes SNS-Thema für Benachrichtigungen verwenden.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:CreateDelegationRequest",
"Resource": "*",
"Condition": {
"ArnEquals": {
"iam:NotificationChannel": "arn:aws:sns:us-east-1:123456789012:delegation-notifications"
}
}
}
]
}
```
**Ich bin: TemplateArn**
Funktioniert mit [ARN-Operatoren](reference_policies_elements_condition_operators.md#Conditions_ARN).
Filtert den Zugriff auf der Grundlage des ARN der Richtlinienvorlage, der zur Definition von Berechtigungen in einer Delegierungsanfrage verwendet wird.
Produktanbieter können diesen Bedingungsschlüssel verwenden, um zu steuern, welche Richtlinienvorlagen im CreateDelegationRequest API-Aufruf verwendet werden können. Richtlinienvorlagen definieren die temporären Berechtigungen, die Produktanbieter in Kundenkonten anfordern. Auf diese Weise können Produktanbieter einschränken, welche registrierten Richtlinienvorlagen bei der Erstellung von Delegierungsanfragen verwendet werden können.
Dieser Bedingungsschlüssel wird von der `CreateDelegationRequest`-API-Operation unterstützt.
In diesem Beispiel erlauben Sie die Erstellung von Delegierungsanfragen nur, wenn sie eine Richtlinienvorlage aus einer bestimmten Partnerdomäne verwenden.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:CreateDelegationRequest",
"Resource": "*",
"Condition": {
"ArnLike": {
"iam:TemplateArn": "arn:aws:iam:::delegation-template/partner_*"
}
}
}
]
}
```
**Ich bin: DelegationRequestOwner**
Funktioniert mit [ARN-Operatoren](reference_policies_elements_condition_operators.md#Conditions_ARN).
Filtert den Zugriff auf der Grundlage der AWS Identität oder des Prinzipals, dem die Delegierungsanfrage gehört.
Kunden können diesen Bedingungsschlüssel verwenden, um zu kontrollieren, wer je nach Eigentümerschaft Aktionen für Delegierungsanfragen ausführen kann. Der Eigentümer einer Delegierungsanfrage ist die AWS Identität oder der Hauptbenutzer in dem Kundenkonto, das die Delegierungsanfrage initiiert oder empfangen hat.
Dieser Bedingungsschlüssel wird von folgenden API-Operationen unterstützt.
+ `GetDelegationRequest`
+ `AcceptDelegationRequest`
+ `RejectDelegationRequest`
+ `SendDelegatedToken`
+ `ListDelegationRequests`
+ `UpdateDelegationRequest`
In diesem Beispiel ermöglichen Sie Benutzern, nur Delegierungsanfragen zu verwalten, deren Eigentümer sie sind.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:GetDelegationRequest",
"iam:AcceptDelegationRequest",
"iam:RejectDelegationRequest",
"iam:SendDelegatedToken",
"iam:UpdateDelegationRequest",
"iam:ListDelegationRequests"
],
"Resource": "*",
"Condition": {
"ArnEquals": {
"iam:DelegationRequestOwner": "${aws:PrincipalArn}"
}
}
}
]
}
```
## Verfügbare Schlüssel für den AWS OIDC-Verbund
Sie können den OIDC-Verbund verwenden, um Benutzern, die über einen OpenID Connect-kompatiblen Identitätsanbieter (IdP) authentifiziert wurden, temporäre Sicherheitsanmeldedaten für einen IAM OpenID Connect (OIDC) -Identitätsanbieter in Ihrem Konto zuzuweisen. AWS Beispiele für solche Anbieter sind GitHub Amazon Cognito, Login with Amazon und Google. Es können Identitäts- und Zugriffstokens von Ihrem eigenen IdP sowie [Servicekonto-Tokens](https://docs.aws.amazon.com/eks/latest/userguide/service-accounts.html#service-account-tokens) verwendet werden, die Service-Workloads von Amazon Elastic Kubernetes gewährt werden.
Sie können AWS OIDC-Bedingungskontextschlüssel verwenden, um Richtlinien zu schreiben, die den Zugriff von Verbundprinzipalen auf Ressourcen beschränken, die einem bestimmten Anbieter, einer bestimmten App oder einem bestimmten Benutzer zugeordnet sind. Diese Schlüssel werden in der Regel in der Vertrauensrichtlinie für eine Rolle verwendet. Definieren Sie Bedingungsschlüssel mit dem Namen des OIDC-Anbieters (`token.actions.githubusercontent.com`), gefolgt von einem Antrag (`:aud`): `token.actions.githubusercontent.com:aud`.
Einige Bedingungsschlüssel für den OIDC-Verbund können in der Rollensitzung verwendet werden, um den Ressourcenzugriff zu autorisieren. Wenn der Wert in der Spalte **In Sitzung verfügbar** auf **Ja** steht, können Sie diese Bedingungsschlüssel in Richtlinien verwenden, um zu definieren, auf welche Benutzer in anderen Diensten zugreifen dürfen. AWS Wenn ein Anspruch in einer Sitzung nicht verfügbar ist, kann der OIDC-Bedingungskontextschlüssel nur in einer Rollenvertrauensrichtlinie für die [AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)Erstauthentifizierung verwendet werden.
Wählen Sie Ihren IdP aus, um zu sehen, wie Anträge von Ihrem IdP den IAM-Bedingungskontextschlüsseln in AWS zugeordnet werden. Weitere Informationen zu Schlüsseln für GitHub und Google finden Sie auf der Registerkarte **Standard**.
------
#### [ Default ]
In der Standardeinstellung werden die OIDC-Standardansprüche und ihre Zuordnung zu den AWS STS Bedingungskontextschlüsseln in aufgeführt. AWS Mit diesen Schlüsseln können Sie den Zugriff auf eine Rolle steuern. Vergleichen Sie dazu die **AWS STS -Bedingungsschlüssel** mit den Werten in der Spalte mit dem **IdP-JWT-Antrag**. Verwenden Sie diese Zuordnung, wenn Ihr IdP nicht in den Registerkartenoptionen aufgeführt ist.
GitHub Actions, Workflows und Google sind einige Beispiele dafür IdPs , die Standardimplementierung in ihrem OIDC-JWT-ID-Token verwenden.
| AWS STS Bedingungsschlüssel | IdP-JWT-Antrag | In der Sitzung verfügbar |
| --- | --- | --- |
| amr | amr | Ja |
| aud | azp Wenn für `azp` kein Wert festgelegt ist, wird der `aud`-Bedingungsschlüssel dem `aud`-Antrag zugeordnet. | Ja |
| E-Mail | E-Mail | Nein |
| oaud | aud | Nein |
| sub | sub | Ja |
Weitere Hinweise zur Verwendung von OIDC-Bedingungskontextschlüsseln mit GitHub finden Sie unter. [Konfiguration einer Rolle für den GitHub OIDC-Identitätsanbieter](id_roles_create_for-idp_oidc.md#idp_oidc_Create_GitHub) Weitere Informationen zu den Google-Feldern `aud` und `azp` finden Sie im [Google Identity Platform OpenID Connect](https://developers.google.com/identity/protocols/OpenIDConnect)-Leitfaden.
**amr**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String). Der Schlüssel enthält mehrere Werte, d. h. Sie überprüfen ihn in einer Richtlinie mithilfe von [Bedingungsmengenoperatoren](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys).
**Beispiel**: `token.actions.githubusercontent.com:amr`
Die Referenz zu Authentifizierungsmethoden enthält Anmeldeinformationen zum Benutzer. Der Schlüssel kann die folgenden Werte enthalten:
+ Wenn der Benutzer nicht authentifiziert wurde, enthält der Schlüssel nur `unauthenticated`.
+ Wenn der Benutzer authentifiziert wurde, enthält der Schlüssel den Wert `authenticated` sowie den Namen des Identitätsanbieters, der in dem Aufruf (`accounts.google.com`) verwendet wurde.
**aud**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
**Beispiele:**
+ `accounts.google.com:aud`
+ `token.actions.githubusercontent.com:aud`
Verwenden Sie den `aud`-Bedingungsschlüssel, um zu überprüfen, ob die Zielgruppe mit der in der Richtlinie angegebenen übereinstimmt. Sie können den aud-Schlüssel mit dem Sub-Schlüssel für denselben Identitätsanbieter verwenden.
Dieser Bedingungsschlüssel wird aus den folgenden Token-Feldern festgelegt:
+ `aud`für den Google-Client OAuth 2.0 IDs Ihrer Anwendung, wenn das `azp` Feld nicht festgelegt ist. Wenn das `azp`-Feld festgelegt ist, stimmt das `aud`-Feld mit dem Bedingungsschlüssel `accounts.google.com:oaud` überein.
+ `azp`, wenn das Feld `azp` festgelegt ist. Dies kann bei Hybrid-Apps der Fall sein, bei denen eine Webanwendung und eine Android-App eine unterschiedliche OAuth 2.0-Google-Client-ID haben, aber dasselbe APIs Google-Projekt verwenden.
Wenn Sie eine Richtlinie mit dem `accounts.google.com:aud`-Bedingungsschlüssel schreiben, müssen Sie wissen, ob die Anwendung eine Hybridanwendung ist, die das Feld `azp` festlegt.
`azp`-Feld nicht festgelegt
Die folgende Beispielrichtlinie funktioniert für nicht-hybride Anwendungen, die das Feld `azp` nicht festlegen. In diesem Fall stimmt der Wert des Google-ID-Token `aud`-Felds mit dem `accounts.google.com:aud`- und dem `accounts.google.com:oaud`-Bedingungsschlüsselwert überein.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {"Federated": "accounts.google.com"},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"accounts.google.com:aud": "aud-value",
"accounts.google.com:oaud": "aud-value",
"accounts.google.com:sub": "sub-value"
}
}
}
]
}
```
`azp`-Feld festgelegt
Die folgende Beispielrichtlinie funktioniert für hybride Anwendungen, die das Feld `azp` festlegen. In diesem Fall stimmt der Wert des Google-ID-Token `aud`-Felds nur mit dem Wert des Bedingungsschlüssels `accounts.google.com:oaud` überein. Der Wert des Feldes `azp` entspricht dem Wert des `accounts.google.com:aud`-Bedingungsschlüssels.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {"Federated": "accounts.google.com"},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"accounts.google.com:aud": "azp-value",
"accounts.google.com:oaud": "aud-value",
"accounts.google.com:sub": "sub-value"
}
}
}
]
}
```
**E-Mail**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
**Beispiel**: `accounts.google.com:email`
Dieser Bedingungsschlüssel validiert die E-Mail-Adresse des Benutzers. Der Wert dieses Antrags ist für dieses Konto möglicherweise nicht eindeutig und kann sich im Laufe der Zeit ändern. Daher sollten Sie diesen Wert nicht als primäre Kennung zur Überprüfung Ihres Benutzerdatensatzes verwenden.
**oaud**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
**Beispiel**: `accounts.google.com:oaud`
Dieser Schlüssel gibt die andere Zielgruppe (`aud`) an, für die dieses ID-Token bestimmt ist. Es muss sich um einen der OAuth 2.0-Clients IDs Ihrer Anwendung handeln.
**sub**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
**Beispiele:**
+ `accounts.google.com:sub`
+ token.actions.githubusercontent.com:sub
Verwenden Sie diese Schlüssel, um zu überprüfen, ob der Betreff mit dem übereinstimmt, den Sie in der Richtlinie angeben. Sie können den `sub`-Schlüssel mit dem `aud`-Schlüssel für denselben Identitätsanbieter verwenden.
In der folgenden Rollenvertrauensrichtlinie beschränkt der `sub` Bedingungsschlüssel die Rolle auf den GitHub angegebenen Zweig`demo`.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:oidc-provider/token.actions.githubusercontent.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
"token.actions.githubusercontent.com:sub": "repo:org-name/repo-name:ref:refs/heads/demo"
}
}
}
]
}
```
------
#### [ Amazon Cognito ]
Auf dieser Registerkarte wird erklärt, wie Amazon Cognito OIDC-Ansprüche den AWS STS Bedingungskontextschlüsseln zuordnet. AWS Mit diesen Schlüsseln können Sie den Zugriff auf eine Rolle steuern. Vergleichen Sie dazu die **AWS STS -Bedingungsschlüssel** mit den Werten in der Spalte mit dem **IdP-JWT-Antrag**.
Für Rollen, die von Amazon Cognito verwendet werden, werden Schlüssel definiert mit `cognito-identity.amazonaws.com`, gefolgt von der Forderung.
Weitere Informationen zur Zuordnung von Identitätspool-Anträgen finden Sie unter [Standardanbieter-Zuordnungen](https://docs.aws.amazon.com/cognito/latest/developerguide/provider-mappings.html) im *Amazon-Cognito-Entwicklerhandbuch*. Weitere Informationen zur Zuordnung von Benutzerpool-Anträgen finden Sie unter [Verwendung des ID-Tokens](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-the-id-token.html) im *Amazon-Cognito-Entwicklerhandbuch*.
| AWS STS Bedingungsschlüssel | IdP-JWT-Antrag | In der Sitzung verfügbar |
| --- | --- | --- |
| amr | amr | Ja |
| aud | aud | Ja |
| oaud | aud | Nein |
| sub | sub | Ja |
**amr**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String). Der Schlüssel enthält mehrere Werte, d. h. Sie überprüfen ihn in einer Richtlinie mithilfe von [Bedingungsmengenoperatoren](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys).
**Beispiel** – `cognito-identity.amazonaws.com:amr`
Die Referenz zu Authentifizierungsmethoden enthält Anmeldeinformationen zum Benutzer. Der Schlüssel kann die folgenden Werte enthalten:
+ Wenn der Benutzer nicht authentifiziert wurde, enthält der Schlüssel nur `unauthenticated`.
+ Wenn der Benutzer authentifiziert wurde, enthält der Schlüssel den Wert `authenticated` sowie den Namen des Identitätsanbieters, der in dem Aufruf (`cognito-identity.amazonaws.com`) verwendet wurde.
Beispielsweise testet die folgende Bedingung in der Vertrauensrichtlinie für eine Amazon Cognito-Rolle, ob der Benutzer nicht authentifiziert ist.
```
"Condition": {
"StringEquals":
{ "cognito-identity.amazonaws.com:aud": "us-east-2:identity-pool-id" },
"ForAnyValue:StringLike":
{ "cognito-identity.amazonaws.com:amr": "unauthenticated" }
}
```
**aud**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
**Beispiel** – `cognito-identity.amazonaws.com:aud`
Der Benutzerpool-App-Client, der Ihren Benutzer authentifiziert hat. Amazon Cognito gibt den gleichen Wert im Zugriffstoken-Anspruch `client_id` wieder.
**oaud**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
**Beispiel** – `cognito-identity.amazonaws.com:oaud`
Der Benutzerpool-App-Client, der Ihren Benutzer authentifiziert hat. Amazon Cognito gibt den gleichen Wert im Zugriffstoken-Anspruch `client_id` wieder.
**sub**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
**Beispiel** – `cognito-identity.amazonaws.com:sub`
Eine eindeutige ID (UUID) oder ein Betreff für den authentifizierten Benutzer. Möglicherweise ist der Benutzername in Ihrem Benutzerpool nicht eindeutig. Der sub-Antrag ist der beste Weg, um einen bestimmten Benutzer zu identifizieren. Sie können den `sub`-Schlüssel mit dem `aud`-Schlüssel für denselben Identitätsanbieter verwenden.
```
"Condition": {
"StringEquals": {
"cognito-identity.amazonaws.com:aud": "us-east-1:12345678-abcd-abcd-abcd-123456790ab",
"cognito-identity.amazonaws.com:sub": [
"us-east-1:12345678-1234-1234-1234-123456790ab",
"us-east-1:98765432-1234-1234-1243-123456790ab"
]
}
}
```
------
#### [ Login with Amazon ]
Auf dieser Registerkarte wird erklärt, wie Login with Amazon OIDC-Behauptungen zuordnet, um Kontextschlüssel zu AWS STS konditionieren. AWS Mit diesen Schlüsseln können Sie den Zugriff auf eine Rolle steuern. Vergleichen Sie dazu die **AWS STS -Bedingungsschlüssel** mit den Werten in der Spalte mit dem **IdP-JWT-Antrag**.
| AWS STS Bedingungsschlüssel | IdP-JWT-Antrag | In der Sitzung verfügbar |
| --- | --- | --- |
| app\$1id | Anwendungs-ID | Ja |
| sub | Benutzer-ID | Ja |
| user\$1id | Benutzer-ID | Ja |
**app\$1id**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
**Beispiel** – `www.amazon.com:app_id`
Dieser Schlüssel gibt den Zielgruppenkontext an, der mit dem von anderen Identitätsanbietern verwendeten `aud`-Feld übereinstimmt.
**sub**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
**Beispiel** – `www.amazon.com:sub`
Dieser Schlüssel überprüft, ob die Benutzer-ID mit der in der Richtlinie angegebenen übereinstimmt. Sie können den `sub `-Schlüssel mit dem `aud`-Schlüssel für denselben Identitätsanbieter verwenden.
**user\$1id**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
**Beispiel** – `www.amazon.com:user_id`
Dieser Schlüssel gibt den Zielgruppenkontext an, der dem von anderen Identitätsanbietern verwendeten `aud`-Feld entspricht. Sie können den `user_id`-Schlüssel mit dem `id`-Schlüssel für denselben Identitätsanbieter verwenden.
------
#### [ Facebook ]
Auf dieser Registerkarte wird erklärt, wie Facebook OIDC-Ansprüche den AWS STS Bedingungskontextschlüsseln zuordnet. AWS Mit diesen Schlüsseln können Sie den Zugriff auf eine Rolle steuern. Vergleichen Sie dazu die **AWS STS -Bedingungsschlüssel** mit den Werten in der Spalte mit dem **IdP-JWT-Antrag**.
| AWS STS Bedingungsschlüssel | IdP-JWT-Antrag | In der Sitzung verfügbar |
| --- | --- | --- |
| app\$1id | Anwendungs-ID | Ja |
| id | id | Ja |
**app\$1id**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
**Beispiel** – `graph.facebook.com:app_id`
Dieser Schlüssel überprüft, ob der Zielgruppenkontext mit dem von anderen Identitätsanbietern verwendeten `aud`-Feld übereinstimmt.
**id**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
**Beispiel** – `graph.facebook.com:id`
Dieser Schlüssel hat bestätigt, dass die ID der Anwendung (oder Website) mit der in der Richtlinie angegebenen übereinstimmt.
------
#### [ GitHub ]
Auf dieser Registerkarte wird erklärt, wie GitHub Actions OIDC-Ansprüche den AWS STS Bedingungskontextschlüsseln in zuordnet. AWS Mit diesen Schlüsseln können Sie den Zugriff auf eine Rolle steuern. Vergleichen Sie dazu die **AWS STS -Bedingungsschlüssel** mit den Werten in der Spalte mit dem **IdP-JWT-Antrag**.
| AWS STS Bedingungsschlüssel | IdP-JWT-Antrag | In der Sitzung verfügbar |
| --- | --- | --- |
| Akteur | Akteur | Nein |
| actor\$1id | actor\$1id | Nein |
| job\$1workflow\$1ref | job\$1workflow\$1ref | Nein |
| Repository | Repository | Nein |
| repository\$1id | repository\$1id | Nein |
| Workflow | Workflow | Nein |
| Schiedsrichter | Schiedsrichter | Nein |
| Umgebung | Umgebung | Nein |
| Unternehmens-ID | Unternehmens-ID | Nein |
**Akteur**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
**Beispiel** – `token.actions.githubusercontent.com:actor`
Dieser Schlüssel identifiziert das persönliche Konto, das die Workflow-Ausführung initiiert hat. Verwenden Sie dies, um den Zugriff auf bestimmte Akteure zu beschränken.
**actor\$1id**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
**Beispiel** – `token.actions.githubusercontent.com:actor_id`
Dieser Schlüssel verifiziert die ID des persönlichen Kontos, das die Workflow-Ausführung initiiert hat. Schauspieler IDs werden von generiert GitHub und sind unveränderlich.
**job\$1workflow\$1ref**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
**Beispiel** – `token.actions.githubusercontent.com:job_workflow_ref`
Dieser Schlüssel enthält den Referenzpfad zum wiederverwendbaren Workflow für Jobs, die einen wiederverwendbaren Workflow verwenden. Verwenden Sie dies, um den Zugriff auf bestimmte Workflows einzuschränken und sicherzustellen, dass nur genehmigte Workflows Rollen übernehmen können.
**Repository**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
**Beispiel** – `token.actions.githubusercontent.com:repository`
Dieser Schlüssel identifiziert das Repository, von dem aus der Workflow ausgeführt wird. Verwenden Sie dies, um den Zugriff auf bestimmte GitHub Repositorys zu beschränken.
**repository\$1id**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
**Beispiel** – `token.actions.githubusercontent.com:repository_id`
Dieser Schlüssel verifiziert die ID des Repositorys, von dem aus der Workflow ausgeführt wird. Repositorys IDs sind unveränderlich und ändern sich nicht, auch wenn das Repository umbenannt wird.
**Arbeitsablauf**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
**Beispiel** – `token.actions.githubusercontent.com:workflow`
Dieser Schlüssel enthält den Namen des Workflows. Verwenden Sie dies, um den Zugriff auf bestimmte Workflows in Ihren Repositorys einzuschränken.
**ref**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
**Beispiel** – `token.actions.githubusercontent.com:ref`
Dieser Schlüssel identifiziert die Git-Referenz (Branch oder Tag), die den Workflow-Lauf ausgelöst hat. Verwenden Sie diesen Wert, um den Zugriff auf bestimmte Branches zu beschränken, z. B. „Nur zulassen“ `main` oder „`production`Branches“.
**Umgebung**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
**Beispiel** – `token.actions.githubusercontent.com:environment`
Dieser Schlüssel enthält den Namen der Umgebung, die vom Job verwendet wird. Verwenden Sie dies, um umgebungsbasierte Zugriffskontrollen zu implementieren, z. B. separate Berechtigungen für Entwicklungs-, Staging- und Produktionsumgebungen.
Wenn der Umweltanspruch in Ihrer Vertrauensrichtlinie enthalten ist, muss eine Umgebung konfiguriert und im GitHub Workflow bereitgestellt werden.
**enterprise\$1id**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
**Beispiel** – `token.actions.githubusercontent.com:enterprise_id`
Dieser Schlüssel verifiziert die ID des Unternehmens, das das Repository enthält, von dem aus der Workflow ausgeführt wird. Verwenden Sie diesen Wert, um sicherzustellen, dass der Zugriff auf Repositorys innerhalb Ihrer GitHub Unternehmensorganisation beschränkt ist.
Das folgende Beispiel für eine Vertrauensrichtlinie verwendet benutzerdefinierte Ansprüche im GitHub OIDC-Token, um den Zugriff auf eine Rolle zu beschränken.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::AWS_ACCOUNT_ID:oidc-provider/token.actions.githubusercontent.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringLike": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
"token.actions.githubusercontent.com:job_workflow_ref": "octo-org/octo-automation/.github/workflows/oidc.yml@refs/heads/main",
"token.actions.githubusercontent.com:repository": "octo-org/octo-repo",
"token.actions.githubusercontent.com:actor": "octocat",
"token.actions.githubusercontent.com:ref": "refs/heads/main",
"token.actions.githubusercontent.com:enterprise_id": "345"
}
}
}
]
}
```
------
#### [ Google ]
Auf dieser Registerkarte wird erklärt, wie Google Maps OIDC behauptet, Kontextschlüssel zu AWS STS konditionieren. AWS Mit diesen Schlüsseln können Sie den Zugriff auf eine Rolle steuern. Vergleichen Sie dazu die **AWS STS -Bedingungsschlüssel** mit den Werten in der Spalte mit dem **IdP-JWT-Antrag**.
| AWS STS Bedingungsschlüssel | IdP-JWT-Antrag | In der Sitzung verfügbar |
| --- | --- | --- |
| Google/Organisationsnummer | google:Organisationsnummer | Nein |
**google/organisationsnummer**
Funktioniert mit [nummerischen Operatoren](reference_policies_elements_condition_operators.md#Conditions_Numeric).
**Beispiel** – `accounts.google.com:google/organization_number`
Dieser Schlüssel bestätigt, dass ein Token eine Google-Identität darstellt, die zu einer bestimmten Google Cloud- oder Google Workspace-Organisation gehört. Verwenden Sie dies, um den Zugriff auf Nutzer aus bestimmten Organisationen zu beschränken und sicherzustellen, dass nur Identitäten aus Ihrer Organisation die Rolle übernehmen können.
Das folgende Beispiel für eine Vertrauensrichtlinie verwendet den `google/organization_number` Anspruch, um den Zugriff auf eine Rolle zu beschränken.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "accounts.google.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"NumericEquals": {
"accounts.google.com:google/organization_number": "123456"
}
}
}
]
}
```
------
#### [ CircleCI ]
Auf dieser Registerkarte wird erklärt, wie CircleCI OIDC-Ansprüche den AWS STS Bedingungskontextschlüsseln zuordnet. AWS Mit diesen Schlüsseln können Sie den Zugriff auf eine Rolle steuern. Vergleichen Sie dazu die **AWS STS -Bedingungsschlüssel** mit den Werten in der Spalte mit dem **IdP-JWT-Antrag**.
| AWS STS Bedingungsschlüssel | IdP-JWT-Antrag | In der Sitzung verfügbar |
| --- | --- | --- |
| oidc.circleci.com/project-id | oidc.circleci.com/project-id | Nein |
**oidc.circleci.com/project-id**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
**Beispiel** – `circleci-issuer-url:oidc.circleci.com/project-id`
Dieser Schlüssel identifiziert das CircleCI-Projekt, in dem der Job ausgeführt wird. Sein Wert ist eine Zeichenfolge, die eine UUID enthält, die das CircleCI-Projekt eindeutig identifiziert. Verwenden Sie dies, um den Zugriff auf bestimmte CircleCI-Projekte einzuschränken.
Das folgende Beispiel für eine Vertrauensrichtlinie verwendet den `oidc.circleci.com/project-id` Anspruch, um den Zugriff auf eine Rolle zu beschränken.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::123456789012:oidc-provider/oidc.circleci.com/org/12345"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"oidc.circleci.com/org/12345:aud": "sts.amazonaws.com",
"oidc.circleci.com/org/12345:oidc.circleci.com/project-id": "76543210-ba98-fedc-3210-edcba0987654"
}
}
}
]
}
```
------
#### [ Oracle Cloud Infrastructure (OCI) ]
Auf dieser Registerkarte wird erklärt, wie Oracle Cloud Infrastructure OIDC-Ansprüche den AWS STS Bedingungskontextschlüsseln in zuordnet. AWS Mit diesen Schlüsseln können Sie den Zugriff auf eine Rolle steuern. Vergleichen Sie dazu die **AWS STS -Bedingungsschlüssel** mit den Werten in der Spalte mit dem **IdP-JWT-Antrag**.
| AWS STS Bedingungsschlüssel | IdP-JWT-Antrag | In der Sitzung verfügbar |
| --- | --- | --- |
| rpst\$1id | rpst\$1id | Nein |
**rpst\$1id**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
**Beispiel** – `oci-issuer-url:rpst_id`
Dieser Schlüssel identifiziert den Ressourcenprinzipal in OCI eindeutig. Verwenden Sie dies, um den Zugriff auf bestimmte OCI-Ressourcenprinzipale einzuschränken. Die rpst\$1id (Resource Principal Session Token ID) bietet eine stabile Kennung für die ressourcenbasierte OCI-Authentifizierung.
Das folgende Beispiel für eine Vertrauensrichtlinie verwendet den `rpst_id` Anspruch, um den Zugriff auf eine Rolle zu beschränken.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::123456789012:oidc-provider/idcs-abc123ef5678901234abcd.identity.oraclecloud.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"idcs-abc123ef5678901234abcd.identity.oraclecloud.com:aud": "sts.amazonaws.com",
"idcs-abc123ef5678901234abcd.identity.oraclecloud.com:rpst_id": "your-rpst-id"
}
}
}
]
}
```
------
### Weitere Informationen zum OIDC-Verbund
+ [Amazon-Cognito-Benutzerhandbuch](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-identity.html)
+ [OIDC-Verbund](id_roles_providers_oidc.md)
## Verfügbare Schlüssel für den SAML-basierten AWS STS Verbund
Wenn Sie mit einem [SAML-basierten Verbund](https://docs.aws.amazon.com/STS/latest/UsingSTS/CreatingSAML.html) mithilfe von AWS -Security-Token-Service (AWS STS) arbeiten, können Sie zusätzliche Bedingungsschlüssel in die Richtlinie aufnehmen.
### Vertrauensrichtlinien der SAML-Rolle
Sie können in der Vertrauensrichtlinie einer Rolle die folgenden Schlüssel verwenden, um festzustellen, ob der Aufrufer die Rolle übernehmen darf. Abgesehen von `saml:doc` werden alle Werte aus der SAML-Zusicherung abgeleitet. Alle Elemente in der Liste sind im visuellen Editor der IAM-Konsole verfügbar, wenn Sie eine Richtlinie mit Bedingungen erstellen oder bearbeiten. Elemente, die mit `[]` gekennzeichnet sind, *können* einen Wert enthalten, der eine Liste des angegebenen Typs ist.
**saml:aud**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Eine Endpunkt-URL, für die SAML-Zusicherungen bereitgestellt werden. Der Wert dieses Schlüssels stammt aus dem Feld `SAML Recipient` der Zusicherung, *nicht* aus dem Feld `Audience`.
**saml:commonName[]**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Dies ist ein `commonName`-Attribut.
**saml:cn[]**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Hierbei handelt es sich um ein `eduOrg`-Attribut.
**saml:doc**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Dieser Schlüssel steht für den Auftraggeber, der zum Übernehmen der Rolle verwendet wurde. Das Format ist*account-ID*/*provider-friendly-name*, z. B. `123456789012/SAMLProviderName` Der Wert *Konto-ID* bezieht sich auf das Konto, zu dem der [SAML-Anbieter](id_roles_providers_create_saml.md) gehört.
**saml:edupersonaffiliation[]**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Hierbei handelt es sich um ein `eduPerson`-Attribut.
**saml:edupersonassurance[]**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Hierbei handelt es sich um ein `eduPerson`-Attribut.
**saml:edupersonentitlement[]**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Hierbei handelt es sich um ein `eduPerson`-Attribut.
**saml:edupersonnickname[]**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Hierbei handelt es sich um ein `eduPerson`-Attribut.
**saml:edupersonorgdn**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Hierbei handelt es sich um ein `eduPerson`-Attribut.
**saml:edupersonorgunitdn[]**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Hierbei handelt es sich um ein `eduPerson`-Attribut.
**saml:edupersonprimaryaffiliation**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Hierbei handelt es sich um ein `eduPerson`-Attribut.
**saml:edupersonprimaryorgunitdn**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Hierbei handelt es sich um ein `eduPerson`-Attribut.
**saml:edupersonprincipalname**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Hierbei handelt es sich um ein `eduPerson`-Attribut.
**saml:edupersonscopedaffiliation[]**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Hierbei handelt es sich um ein `eduPerson`-Attribut.
**saml:edupersontargetedid[]**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Hierbei handelt es sich um ein `eduPerson`-Attribut.
**saml:eduorghomepageuri[]**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Hierbei handelt es sich um ein `eduOrg`-Attribut.
**saml:eduorgidentityauthnpolicyuri[]**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Hierbei handelt es sich um ein `eduOrg`-Attribut.
**saml:eduorglegalname[]**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Hierbei handelt es sich um ein `eduOrg`-Attribut.
**saml:eduorgsuperioruri[]**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Hierbei handelt es sich um ein `eduOrg`-Attribut.
**saml:eduorgwhitepagesuri[]**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Hierbei handelt es sich um ein `eduOrg`-Attribut.
**saml:givenName[]**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Dies ist ein `givenName`-Attribut.
**saml:iss**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Der Aussteller in Form eines URN
**saml:mail[]**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Dies ist ein `mail`-Attribut.
**saml:name[]**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Dies ist ein `name`-Attribut.
**saml:namequalifier**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Ein Hash-Wert basierend auf dem Anzeigenamen des SAML-Anbieters. Der Wert ist die Verkettung der folgenden Werte in der angegebenen Reihenfolge und getrennt durch das Zeichen „/“:
1. Der `Issuer` Antwortwert (`saml:iss`)
1. Die `AWS`-Konto-ID.
1. Der Anzeigename (der letzte Teil des ARN) des SAML-Anbieters in IAM
Die Verkettung der Konto-ID und des Anzeigenamens des SAML-Anbieters steht als der Schlüssel `saml:doc` für IAM-Richtlinien zur Verfügung. Weitere Informationen finden Sie unter [Eindeutige Identifizierung von Benutzern im SAML-basierten Verbund](id_roles_providers_saml.md#CreatingSAML-userid).
**saml:organizationStatus[]**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Hierbei handelt es sich um ein `organizationStatus`-Attribut.
**saml:primaryGroupSID[]**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Dies ist ein `primaryGroupSID`-Attribut.
**saml:sub**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Dies ist der Betreff des Antrags, der einen Wert enthält, der einen einzelnen Benutzer innerhalb einer Organisation eindeutig identifiziert (zum Beispiel `_cbb88bf52c2510eabe00c1642d4643f41430fe25e3`).
**saml:sub\$1type**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Dieser Schlüssel kann den Wert `persistent` oder `transient` oder die vollständige `Format`-URI aus den in der SAML-Zusicherung verwendeten Elementen `Subject` und `NameID` enthalten. Der Wert `persistent` gibt an, dass der Wert in `saml:sub` für einen Benutzer für alle Sitzungen identisch ist. Wenn der Wert `transient` lautet, hat der Benutzer einen anderen `saml:sub`-Wert für jede Sitzung. Weitere Informationen zum `NameID`-Attribut des `Format`-Elements finden Sie unter [Konfigurieren von SAML-Assertionen für die Authentifizierungsreaktion](id_roles_providers_create_saml_assertions.md).
**saml:surname[]**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Dies ist ein `surnameuid`-Attribut.
**saml:uid[]**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Dies ist ein `uid`-Attribut.
**saml:x500 [] UniqueIdentifier**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Hierbei handelt es sich um ein `x500UniqueIdentifier`-Attribut.
Allgemeine Informationen zu den Attributen `eduPerson` und `eduOrg` finden Sie auf der [Wiki-Website von REFEDS](https://wiki.refeds.org/display/STAN/eduPerson). Eine Liste der `eduPerson`-Attribute finden Sie unter [eduPerson Object Class Specification (201602)](https://software.internet2.edu/eduperson/internet2-mace-dir-eduperson-201602.html).
Bedingungsschlüssel mit dem Typ „Liste“ können mehrere Werte enthalten. Um in einer Richtlinie Bedingungen für Listenwerte zu erstellen, können Sie [Mengenoperatoren](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys) (`ForAllValues`, `ForAnyValue`) verwenden. Um beispielsweise jeden Benutzer zuzulassen, dessen Zugehörigkeit „Lehrkörper“ oder „Personal“ (aber nicht „Student“) ist, können Sie eine Bedingung wie die folgende verwenden:
```
"Condition": {
"ForAllValues:StringLike": {
"saml:edupersonaffiliation":[ "faculty", "staff"]
}
}
```
## Dienstübergreifende SAML-basierte Verbundkontextschlüssel AWS STS
Einige SAML-basierte Verbundbedingungsschlüssel können in nachfolgenden Anfragen verwendet werden, um AWS Operationen in anderen Diensten und Aufrufen zu autorisieren. `AssumeRole` Dies sind die folgenden Bedingungsschlüssel, die in Rollenvertrauensrichtlinien verwendet werden können, wenn föderierte Prinzipale eine andere Rolle übernehmen, und in Ressourcenrichtlinien anderer AWS Dienste, um den Ressourcenzugriff von Verbundprinzipalen zu autorisieren. Weitere Informationen über die Verwendung dieser Schlüssel finden Sie unter [Informationen zum SAML-2.0-basierten Verbund](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml.html#CreatingSAML-userid).
Wählen Sie einen Bedingungsschlüssel aus, um die Beschreibung zu sehen.
+ [saml:namequalifier](#ck_saml-namequalifier)
+ [saml:sub](#ck_saml-sub)
+ [saml:sub_type](#ck_saml-subtype)
**Anmerkung**
Nach der ersten Authentifizierungsantwort des externen Identitätsanbieters (IDP) stehen keine anderen SAML-basierten Verbundbedingungsschlüssel zur Verfügung.
## Verfügbare Schlüssel für AWS STS
Sie können die folgenden Bedingungsschlüssel in IAM-Rollenvertrauensrichtlinien für Rollen verwenden, von denen angenommen wird, dass sie AWS -Security-Token-Service (AWS STS) -Operationen verwenden.
**saml:sub**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Dies ist der Betreff des Antrags, der einen Wert enthält, der einen einzelnen Benutzer innerhalb einer Organisation eindeutig identifiziert (zum Beispiel `_cbb88bf52c2510eabe00c1642d4643f41430fe25e3`).
**sts: Name AWSService**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Verwenden Sie diesen Schlüssel, um einen Service anzugeben, in dem ein Bearertoken verwendet werden kann. Wenn Sie diesen Bedingungsschlüssel in einer Richtlinie verwenden, geben Sie den Service über einen Dienstauftraggeber an. Ein ServiceAuftraggeber ist der Name eines Services, der im Element `Principal` einer Richtlinie angegeben werden kann. `codeartifact.amazonaws.com`Ist zum Beispiel der AWS CodeArtifact Service Principal.
**Verfügbarkeit** – Dieser Schlüssel ist in Anforderungen vorhanden, die ein Bearer-Token erhalten. Sie können nicht direkt anrufen, AWS STS um ein Bearer-Token zu erhalten. Wenn Sie einige Operationen in anderen Services ausführen, fordert der Service das Bearer-Token in Ihrem Namen an.
Für einige AWS Dienste benötigen Sie die Erlaubnis, ein AWS STS Dienstträgertoken abzurufen, bevor Sie programmgesteuert auf ihre Ressourcen zugreifen können. AWS CodeArtifact erfordert beispielsweise, dass Prinzipale Bearer-Tokens verwenden, um einige Vorgänge auszuführen. Der Befehl `aws codeartifact get-authorization-token` gibt ein Bearertoken zurück. Anschließend können Sie das Bearer-Token verwenden, um Operationen auszuführen. AWS CodeArtifact Weitere Hinweise zu Bearer-Tokens finden Sie unter [Service-Inhaber-Token](id_credentials_bearer.md).
Sie können diesen Bedingungsschlüssel verwenden, um es Auftraggeber zu ermöglichen, ein Bearer-Token für die Verwendung mit einem bestimmten Service zu erhalten.
**sts: DurationSeconds**
Funktioniert mit [nummerischen Operatoren](reference_policies_elements_condition_operators.md#Conditions_Numeric).
Verwenden Sie diesen Schlüssel, um die Dauer (in Sekunden) anzugeben, die ein Principal verwenden kann, wenn er ein AWS AWS STS Bearer-Token oder ein JSON-Web-Token von der [GetWebIdentityToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetWebIdentityToken.html)API abruft.
**Verfügbarkeit** — Dieser Schlüssel ist in Anfragen enthalten, die ein Bearer-Token oder ein JSON-Web-Token von der GetWebIdentityToken API abrufen. Sie können nicht direkt anrufen, AWS STS um ein Bearer-Token zu erhalten. Wenn Sie einige Operationen in anderen Services ausführen, fordert der Service das Bearer-Token in Ihrem Namen an. Der Schlüssel gilt nicht für Operationen mit AWS STS Rollenübernahme.
Für einige AWS Dienste benötigen Sie die Erlaubnis, ein AWS STS Dienstträgertoken abzurufen, bevor Sie programmgesteuert auf ihre Ressourcen zugreifen können. AWS CodeArtifact erfordert beispielsweise, dass Prinzipale Bearer-Tokens verwenden, um einige Vorgänge auszuführen. Der Befehl `aws codeartifact get-authorization-token` gibt ein Bearertoken zurück. Anschließend können Sie das Bearer-Token verwenden, um Operationen auszuführen. AWS CodeArtifact Weitere Hinweise zu Bearer-Tokens finden Sie unter [Service-Inhaber-Token](id_credentials_bearer.md).
**sts: IdentityTokenAudience**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Verwenden Sie diesen Schlüssel, um die Zielgruppe anzugeben, für die ein IAM-Principal JSON-Web-Tokens (JWTs) mithilfe der [GetWebIdentityToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetWebIdentityToken.html)API anfordern kann. Wenn dieser Bedingungsschlüssel in einer IAM-Richtlinie enthalten ist, können IAM-Prinzipale nur Token für die in der Richtlinie angegebenen Zielgruppen anfordern. Externe Dienste validieren den Zielgruppenanspruch („aud“) im JSON-Web-Token, um sicherzustellen, dass das Token für sie bestimmt war.
**Verfügbarkeit** — Dieser Schlüssel ist in Anfragen an die GetWebIdentityToken API enthalten, die zum Abrufen von JSON-Web-Tokens (JWTs) für die Authentifizierung bei externen Diensten verwendet werden.
Wenn Sie diesen Bedingungsschlüssel in einer Richtlinie verwenden, geben Sie den Zielgruppenwert an, der der ID des beabsichtigten Empfängers entspricht (z. B. https://api.example.com).
Die folgende Beispielrichtlinie ermöglicht es einem Principal, Token für die angegebenen externen Dienste anzufordern:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:GetWebIdentityToken",
"Resource": "*",
"Condition": {
"ForAnyValue:StringEquals": {
"sts:IdentityTokenAudience": [
"https://api2.example.com",
"https://api1.example.com"
]
}
}
}
]
}
```
**sts: SigningAlgorithm**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Verwenden Sie diesen Schlüssel, um den kryptografischen Algorithmus anzugeben, der zum Signieren von JSON-Web-Tokens (JWTs) AWS AWS STS verwendet wird, die von der [GetWebIdentityToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetWebIdentityToken.html)API generiert werden. Wenn Sie diesen Bedingungsschlüssel in einer Richtlinie verwenden, geben Sie entweder ES384 (ECDSA mit P-384-Kurve und SHA-384) oder RS256 (RSA mit SHA-256) an.
**Verfügbarkeit** — Dieser Schlüssel ist in Anfragen an die GetWebIdentityToken API enthalten, die zum Abrufen von JSON-Web-Tokens () für die Authentifizierung bei externen Diensten verwendet wird. JWTs
Sie können diesen Bedingungsschlüssel verwenden, um zu erzwingen, dass IAM-Prinzipale Token mithilfe von Signaturalgorithmen anfordern, die mit Ihren Sicherheitsanforderungen oder den externen Diensten, in die Sie integriert sind, kompatibel sind. ES384 bietet optimale Sicherheit und Leistung und RS256 bietet gleichzeitig eine umfassendere Kompatibilität mit Systemen, die ECDSA nicht unterstützen.
Die folgende Beispielrichtlinie verlangt, dass Prinzipale den Signaturalgorithmus verwenden: ES384
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:GetWebIdentityToken",
"Resource": "*",
"Condition": {
"StringEquals": {
"sts:SigningAlgorithm": "ES384"
}
}
}
]
}
```
**sts: ExternalId**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Verwenden Sie diesen Schlüssel, um zu verlangen, dass ein Auftraggeber bei der Übernahme einer IAM-Rolle einen bestimmten Bezeichner bereitstellt.
**Verfügbarkeit** — Dieser Schlüssel ist in der Anfrage enthalten, wenn der Principal eine externe ID bereitstellt und gleichzeitig mithilfe der AWS CLI AWS OR-API eine Rolle übernimmt.
Eine eindeutige Kennung, die erforderlich sein kann, wenn Sie eine Rolle in einem anderen Konto übernehmen. Wenn Ihnen der Administrator des Kontos, zu dem die Rolle gehört, eine externe ID zur Verfügung gestellt hat, geben Sie diesen Wert im Parameter `ExternalId` an. Dieser Wert kann eine beliebige Zeichenfolge sein, wie eine Passphrase oder Kontonummer. Die Hauptfunktion des externen Ausweises besteht darin, das Problem des verwirrten Stellvertreters zu lösen und zu verhindern. Weitere Informationen über die externe ID und das Confused-Deputy-Problem finden Sie unter [Zugriff auf AWS-Konten Eigentum Dritter](id_roles_common-scenarios_third-party.md).
Der Wert `ExternalId` muss mindestens 2 Zeichen und darf höchstens 1.224 Zeichen lang sein. Der Wert muss alphanumerisch sein ohne Leerzeichen. Er kann auch die folgenden Zeichen enthalten: Pluszeichen (\$1), Gleichheitszeichen (=), Komma (,), Punkt (.), At-Zeichen (@), Doppelpunkt (:), Schrägstrich (/) und Bindestrich (-).
**sts:RequestContext/*Kontextschlüssel***
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Verwenden Sie diesen Schlüssel, um die Schlüssel-Wert-Paare aus dem Sitzungskontext, die in die signierte Kontext-Assertion des vertrauenswürdigen Token-Emittenten eingebettet sind, die in der Anfrage übergeben wurde, mit den in der Rollen-Vertrauensrichtlinie angegebenen Kontext-Schlüsselwerten zu vergleichen.
**Verfügbarkeit** — Dieser Schlüssel ist in der Anfrage enthalten, wenn eine Kontext-Assertion im `ProvidedContexts` Anforderungsparameter angegeben wird, während eine Rolle mithilfe der AWS STS [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)API-Operation übernommen wird.
Dieser Kontextschlüssel ist formatiert als `"sts:RequestContext/context-key":"context-value"`, wobei `context-key` und `context-value` ein Kontext-Schlüssel-Wert-Paar sind. Wenn mehrere Kontextschlüssel in die in der Anforderung übergebene signierte Kontext-Assertion eingebettet sind, gibt es einen Kontextschlüssel für jedes Schlüssel-Wert-Paar. Sie müssen in der Rollen-Vertrauensrichtlinie die Erlaubnis für die `sts:SetContext`-Aktion erteilen, damit ein Prinzipal Kontextschlüssel innerhalb des resultierenden Sitzungs-Token festlegen kann. Weitere Informationen zu den unterstützten Kontextschlüsseln für IAM Identity Center, die mit diesem Schlüssel verwendet werden können, finden Sie unter [AWS STS -Bedingungsschlüssel für IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/condition-context-keys-sts-idc.html) im *AWS IAM Identity Center -Benutzerhandbuch*.
Sie können diesen Schlüssel in einer Rollen-Vertrauensrichtlinie verwenden, um eine detaillierte Zugriffskontrolle zu erzwingen, die auf dem Benutzer oder seinen Attributen basiert, wenn er eine Rolle übernimmt. Nachdem die Rolle übernommen wurde, erscheint die Aktivität in den AWS CloudTrail Protokollen innerhalb des `AdditionalEventData` Attributs, die die Schlüssel-Wert-Paare für den Sitzungskontext enthalten, die vom Kontextanbieter in der Anfrage „Rolle annehmen“ festgelegt wurden. Dies erleichtert Administratoren die Unterscheidung zwischen Rollensitzungen, wenn eine Rolle von verschiedenen Auftraggeber verwendet wird. Die Schlüssel-Wert-Paare werden vom angegebenen Kontextanbieter festgelegt, nicht von oder. AWS CloudTrail AWS STS Dadurch hat der Kontextanbieter die Kontrolle darüber, welcher Kontext in den CloudTrail Protokollen und Sitzungsinformationen enthalten ist.
**sts: RequestContextProviders**
Funktioniert mit [ARN-Operatoren](reference_policies_elements_condition_operators.md#Conditions_ARN).
Verwenden Sie diesen Schlüssel, um den Kontextanbieter-ARN in der Anfrage mit dem Kontextanbieter-ARN zu vergleichen, der in der Rollen-Vertrauensrichtlinie angegeben ist.
**Verfügbarkeit** — Dieser Schlüssel ist in der Anfrage vorhanden, wenn eine Kontext-Assertion im `ProvidedContexts` Anforderungsparameter angegeben wird, während eine Rolle mithilfe der AWS STS [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)API-Operation übernommen wird.
Die folgende Beispielbedingung überprüft, ob der in der Anforderung übergebene Kontextanbieter-ARN mit dem in der Rollen-Vertrauensrichtlinien-Bedingung angegebenen ARN übereinstimmt. Wir empfehlen Ihnen, eine Nullprüfung mit `ForAllValues` hinzuzufügen, um zu verhindern, dass fehlende Kontextschlüssel oder Kontextschlüssel mit leeren Werten als „true“ ausgewertet werden. Details hierzu finden Sie unter [Bedingungsoperator zur Prüfung der Existenz von Bedingungsoperatoren](reference_policies_elements_condition_operators.md#Conditions_Null).
****
```
{
"Version":"2012-10-17",
"Statement": {
"Action": "sts:SetContext",
"Effect": "Allow",
"Resource": "*",
"Condition": {
"ForAllValues:ArnEquals": {
"sts:RequestContextProviders": [
"arn:aws:iam::aws:contextProvider/IdentityCenter"
]
},
"Null": {
"sts:RequestContextProviders": "false"
}
}
}
}
```
**sts: RoleSessionName**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Verwenden Sie diesen Schlüssel, um den Sitzungsnamen zu vergleichen, den ein Auftraggeber angibt, wenn er eine Rolle mit dem Wert annimmt, der in der Richtlinie angegeben ist.
**Verfügbarkeit** — Dieser Schlüssel ist in der Anfrage enthalten, wenn der Principal die Rolle mithilfe eines beliebigen Assume-Role-CLI-Befehls oder einer AWS STS `AssumeRole` API-Operation übernimmt. AWS-Managementkonsole
Sie können diesen Schlüssel in einer Rollenvertrauensrichtlinie verwenden, um zu verlangen, dass Ihre Benutzer einen bestimmten Sitzungsnamen angeben, wenn sie eine Rolle übernehmen. Sie können beispielsweise verlangen, dass IAM-Benutzer ihren eigenen Benutzernamen als Sitzungsnamen angeben. Nachdem der IAM-Benutzer die Rolle übernommen hat, wird die Aktivität in [AWS CloudTrail -Protokollen](cloudtrail-integration.md#cloudtrail-integration_signin-tempcreds) mit dem Sitzungsnamen angezeigt, der dem Benutzernamen entspricht. Dies erleichtert Administratoren die Unterscheidung zwischen Rollensitzungen, wenn eine Rolle von verschiedenen Auftraggeber verwendet wird.
Die folgende Rollenvertrauensrichtlinie erfordert, dass IAM-Benutzer im Konto `111122223333` ihren IAM-Benutzernamen als Sitzungsnamen angeben, wenn sie die Rolle übernehmen. Diese Anforderung wird mit der [Bedingungsvariablen](reference_policies_variables.md) `aws:username` im Bedingungsschlüssel erzwungen. Mit dieser Richtlinie können IAM-Benutzer die Rolle übernehmen, an die die Richtlinie angefügt ist. Diese Richtlinie erlaubt niemandem, der temporäre Anmeldeinformationen verwendet, die Rolle zu übernehmen, da die `username`-Variable nur für IAM-Benutzer vorhanden ist.
Sie können jeden einwertigen Bedingungsschlüssel als [Variable](reference_policies_variables.md) verwenden. Sie können einen mehrwertigen Bedingungsschlüssel nicht als Variable verwenden.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "RoleTrustPolicyRequireUsernameForSessionName",
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Principal": {"AWS": "arn:aws:iam::111122223333:root"},
"Condition": {
"StringLike": {"sts:RoleSessionName": "prefix-${aws:username}"}
}
}
]
}
```
Wenn ein Administrator das AWS CloudTrail Protokoll einer Aktion einsieht, kann er den Sitzungsnamen mit den Benutzernamen in seinem Konto vergleichen. Im folgenden Beispiel führte der Benutzer `matjac` den Vorgang mit der Rolle namens `MateoRole`. Der Administrator kann sich dann an Mateo Jackson wenden, den der Benutzer als `matjac` benannt hat.
```
"assumedRoleUser": {
"assumedRoleId": "AROACQRSTUVWRAOEXAMPLE:matjac",
"arn": "arn:aws:sts::111122223333:assumed-role/MateoRole/matjac"
}
```
Wenn Sie [kontenübergreifenden Zugriff mithilfe von Rollen](id_roles_common-scenarios_aws-accounts.md) zulassen, können Benutzer in einem Konto eine Rolle in einem anderen Konto übernehmen. Der ARN des in CloudTrail aufgeführten übernommenen Rollenbenutzers enthält das Konto, *in dem die Rolle vorhanden ist*. Darin ist nicht das Konto des Benutzers enthalten, der die Rolle übernommen hat. Benutzer sind nur innerhalb eines Kontos eindeutig. Daher empfehlen wir, dass Sie diese Methode verwenden, um CloudTrail Protokolle nur für Rollen zu überprüfen, die von Benutzern in Konten übernommen werden, die Sie verwalten. Ihre Benutzer verwenden möglicherweise denselben Benutzernamen in mehreren Konten.
**sts: SourceIdentity**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Verwenden Sie diesen Schlüssel, um den Sitzungsnamen zu vergleichen, den ein Auftraggeber angibt, wenn er eine Rolle mit dem Wert annimmt, der in der Richtlinie angegeben ist.
**Verfügbarkeit** — Dieser Schlüssel ist in der Anfrage enthalten, wenn der Principal eine Quellidentität bereitstellt und gleichzeitig eine Rolle mithilfe eines AWS STS Assume-Role-CLI-Befehls oder einer AWS STS `AssumeRole` API-Operation annimmt.
Sie können diesen Schlüssel in einer Rollenvertrauensrichtlinie verwenden, um zu verlangen, dass Ihre Benutzer eine bestimmte Ursprungsidentität festlegen, wenn sie eine Rolle übernehmen. Beispielsweise können Sie verlangen, dass Ihre Mitarbeiter oder Verbundidentitäten einen Wert für die Quellidentität angeben. Sie können Ihren Identity Provider (IdP) so konfigurieren, dass eines der Attribute verwendet wird, die Ihren Benutzern zugeordnet sind, z. B. ein Benutzername oder eine E-Mail als Quellidentität. Der IdP übergibt dann die Quellidentität als Attribut in den Assertions oder Claims, an die er sendet. AWS Der Wert des Quellidentitätsattributs identifiziert den Benutzer oder die Anwendung, der die Rolle übernimmt.
Nachdem der Benutzer die Rolle übernommen hat, erscheint die Aktivität in den [AWS CloudTrail -Protokollen](cloudtrail-integration.md#cloudtrail-integration_signin-tempcreds) mit dem eingestellten Wert der Quellidentität. Auf diese Weise können Administratoren leichter feststellen, wer oder was Aktionen mit einer Rolle in ausgeführt hat. AWS Sie müssen für die Aktion `sts:SetSourceIdentity` die Berechtigung erteilen, dass eine Identität eine Quellidentität festlegen kann.
Im Gegensatz zu [`sts:RoleSessionName`](#ck_rolesessionname), nachdem die Quellidentität festgelegt wurde, kann der Wert nicht geändert werden. Es ist im Anforderungskontext für alle Aktionen vorhanden, die mit der Rolle von der Quellidentität durchgeführt werden. Wenn Sie die Sitzungsanmeldeinformationen verwenden, bleibt der Wert in nachfolgenden Rollensitzungen bestehen, um eine andere Rolle anzunehmen. Die Annahme einer Rolle von einer anderen wird als [Rollenverkettung](id_roles.md#iam-term-role-chaining) bezeichnet.
Sie können den [`aws:SourceIdentity`](reference_policies_condition-keys.md#condition-keys-sourceidentity)globalen Bedingungsschlüssel verwenden, um den Zugriff auf AWS Ressourcen anhand des Werts der Quellidentität in nachfolgenden Anfragen weiter zu steuern.
Die folgende Rollenvertrauensrichtlinie erlaubt dem IAM-Benutzer `AdminUser`, eine Rolle im Konto `111122223333` zu übernehmen. Sie erteilt dem `AdminUser` auch die Erlaubnis, eine Quellidentität zu setzen, solange die gesetzte Quellidentität `DiegoRamirez` ist.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowAdminUserAssumeRole",
"Effect": "Allow",
"Principal": {"AWS": " arn:aws:iam::111122223333:user/AdminUser"},
"Action": [
"sts:AssumeRole",
"sts:SetSourceIdentity"
],
"Condition": {
"StringEquals": {"sts:SourceIdentity": "DiegoRamirez"}
}
}
]
}
```
Weitere Informationen zur Verwendung von Quellidentitätsinformationen finden Sie unter [Überwachen und Steuern von Aktionen mit übernommenen Rollen](id_credentials_temp_control-access_monitor.md).
**sts: TaskPolicyArn**
Funktioniert mit [ARN-Operatoren](reference_policies_elements_condition_operators.md#Conditions_ARN).
Verwenden Sie diesen Schlüssel, um den Richtlinien-ARN in einer [STS: AssumeRoot](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoot.html) -Anforderung mit dem in der Richtlinie angegebenen Richtlinien-ARN zu vergleichen.
**Verfügbarkeit** — Dieser Schlüssel ist in der Anfrage enthalten, wenn Sie eine Anfrage mit [sts stellen: AssumeRoot](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoot.html).
Administratoren können diesen Bedingungsschlüssel in IAM-Richtlinien verwenden, um bestimmte Rollen oder Benutzer innerhalb des Verwaltungskontos oder des delegierten Administratorkontos daran zu hindern, bestimmte Aktionen auszuführen, wenn sie Root-Anmeldeinformationen annehmen. Weitere Informationen finden Sie unter [Führen Sie eine privilegierte Aufgabe auf einem AWS Organizations Mitgliedskonto aus](id_root-user-privileged-task.md).
**sts: TransitiveTagKeys**
Funktioniert mit [Zeichenfolgenoperatoren](reference_policies_elements_condition_operators.md#Conditions_String).
Verwenden Sie diesen Schlüssel, um die transitiven Sitzungstag-Schlüssel in der Anforderung mit den in der Richtlinie angegebenen Schlüsseln zu vergleichen.
**Verfügbarkeit** – Dieser Schlüssel ist in der Anforderung vorhanden, wenn Sie eine Anforderung mit temporären Sicherheitsanmeldeinformationen stellen. Dazu gehören Anmeldeinformationen, die mit einer beliebigen assume-role-Operation oder der `GetFederationToken`-Operation erstellt wurden.
Wenn Sie eine Anforderung mit temporären Sicherheitsanmeldeinformationen erstellen, enthält der [Anforderungskontext](reference_policies_elements_condition.md#AccessPolicyLanguage_RequestContext) den `aws:PrincipalTag`-Kontextschlüssel. Dieser Schlüssel enthält eine Liste von [Sitzungs-Tags](id_session-tags.md), [transitiven Sitzungs-Tags](id_session-tags.md#id_session-tags_role-chaining) und Rollentags. Transitive Sitzungs-Tags sind Tags, die in allen nachfolgenden Sitzungen bestehen, wenn Sie die Sitzungsanmeldeinformationen verwenden, um eine andere Rolle anzunehmen. Die Annahme einer Rolle von einer anderen wird als [Rollenverkettung](id_roles.md#iam-term-role-chaining) bezeichnet.
Sie können diesen Bedingungsschlüssel in einer Richtlinie verwenden, um bestimmte Sitzungs-Tags als transitiv festzulegen, wenn Sie eine Rolle übernehmen oder einen Benutzer föderieren.
# Aktionen, Ressourcen und Bedingungsschlüssel für AWS Dienste
Jeder AWS Dienst kann Aktionen, Ressourcen und Bedingungskontextschlüssel für die Verwendung in IAM-Richtlinien definieren. Eine Liste der AWS Dienste und ihrer Aktionen, Ressourcen und Bedingungskontextschlüssel finden Sie unter [Aktionen, Ressourcen und Bedingungsschlüssel](https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html) in der *Service Authorization Reference.*