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.
# 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 |