IAM- und AWS STS-Bedingungskontextschlüssel - AWS Identity and Access Management

IAM- und AWS STS-Bedingungskontextschlüssel

Sie können das Condition-Element in einer JSON-Richtlinie verwenden, um den Wert von Schlüsseln zu testen, die im Anforderungskontext aller AWS-Anforderungen enthalten sind. Diese Schlüssel enthalten Informationen zu der Anforderung selbst oder zu den Ressourcen, die die Anforderung referenziert. Sie können die Schlüssel auf bestimmte Werte überprüfen, bevor Sie die angeforderte Aktion zulassen. So können Sie genau steuern, wann Ihre JSON-Richtlinienanweisungen mit einer eingehenden Anforderung übereinstimmen. Weitere Informationen zur Verwendung des Elements Condition in JSON-Richtlinien finden Sie unter IAM-JSON-Richtlinienelemente: Condition.

Dieses Thema beschreibt die vom IAM-Service definierten und bereitgestellten Schlüssel (mit einem Präfix iam:) und den Service AWS Security Token Service (AWS STS) (mit einem sts:-Präfix). Es gibt noch andere AWS-Services, die servicespezifische Schlüssel bereitstellen, die für die von diesem Service bereitgestellten Aktionen und Ressourcen relevant sind. Weitere Informationen finden Sie unter Aktionen, Ressourcen und Bedingungsschlüssel für AWS-Services. Weitere Informationen zu den unterstützten Bedingungsschlüsseln können Sie meist der Dokumentation des jeweiligen Service entnehmen. Weitere Informationen zu Schlüsseln, die Sie in Richtlinien für Amazon-S3-Ressourcen verwenden können, finden Sie beispielsweise unter Amazon-S3-Richtlinienschlüssel im Benutzerhandbuch für Amazon Simple Storage Service.

Verfügbare Schlüssel für IAM

Sie können die folgenden Bedingungsschlüssel in Richtlinien verwenden, die zur Zugriffssteuerung auf IAM-Ressourcen genutzt werden:

iam:AssociatedResourceArn

Funktioniert mit ARN-Operatoren.

Gibt den ARN der Ressource an, der diese Rolle beim Zielservice zugeordnet wird. Die Ressource gehört normalerweise zu dem Service, an den der Auftraggeber die Rolle übergibt. Manchmal kann die Ressource zu einem dritten Service gehören. Sie können beispielsweise eine Rolle an Amazon EC2 Auto Scaling übergeben, die sie auf einer Amazon EC2-Instance verwenden. In diesem Fall würde die Bedingung mit dem ARN der Amazon EC2-Instance übereinstimmen.

Dieser Bedingungsschlüssel gilt nur für die Aktion PassRole in einer Richtlinie. Er kann nicht verwendet werden, um eine andere Aktion zu beschränken.

Wichtig

Bei Verwendung der Bedingung iam:AssociatedResourceArn in einer Richtlinie zum Einschränken der PassRole-Aktion gelten besondere Überlegungen, wenn die Richtlinie den Zugriff für die Aktion AddRoleToInstanceProfile definieren soll. In diesem Fall können Sie in der EC2-Instancr-ARN keine Region oder Instance-ID angeben. Der ARN -Wert muss arn:aws:ec2:*:CallerAccountId:instance/* lauten. Die Verwendung eines anderen ARN-Wertes kann zu unerwarteten Auswertungsergebnissen führen.

Verwenden Sie diesen Bedingungsschlüssel in einer identitätsbasierten Richtlinie, um einer Entität die Übergabe einer Rolle zu gestatten, jedoch nur, wenn diese Rolle der angegebenen Ressource zugeordnet ist. Beispielsweise können Sie einem IAM-Benutzer oder einer IAM-Rolle erlauben, jede Rolle an den Amazon-EC2-Service zu übergeben, um sie mit Instances im AWS-Konto zu verwenden. Der IAM-Benutzer oder die IAM-Rolle wäre nicht berechtigt, Rollen an andere Services zu übergeben.

{ "Effect": "Allow", "Action": "iam:PassRole", "Resource": "*", "Condition": { "StringEquals": { "iam:PassedToService": "ec2.amazonaws.com" }, "ArnLike": { "iam:AssociatedResourceARN": [ "arn:aws:ec2:*:111122223333:instance/*" ] } } }
Anmerkung

AWS-Services, die IAM:PassedToService unterstützen, unterstützen auch diesen Bedingungsschlüssel.

iam:AWSServiceName

Funktioniert mit Zeichenfolgenoperatoren.

Gibt den AWS-Service an, dem diese Rolle zugeordnet ist.

Dieser Bedingungsschlüssel wird von der CreateServiceLinkedRole-API-Operation unterstützt.

Tipp

Informationen darüber, welche Services die Verwendung von serviceverknüpften Rollen unterstützen, finden Sie unter AWS-Services, die mit IAM funktionieren. Suchen Sie nach den Services, für die Ja in der Spalte Serviceverknüpfte Rolle angegeben ist. Wählen Sie über einen Link Ja aus, um die Dokumentation zu einer serviceverknüpften Rolle für diesen Service anzuzeigen.

In diesem Beispiel erlauben Sie einer Entität das Erstellen einer serviceverknüpften Rolle mithilfe der CreateServiceLinkedRole-API-Operation, wenn der Servicename access-analyzer.amazonaws.com lautet.

JSON
{ "Version":"2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "iam:CreateServiceLinkedRole", "Resource": "*", "Condition": { "StringLike": { "iam:AWSServiceName": "access-analyzer.amazonaws.com" } } }] }
iam:FIDO-certification

Funktioniert mit Zeichenfolgenoperatoren.

Überprüft die FIDO-Zertifizierungsstufe des MFA-Geräts zum Zeitpunkt der Registrierung eines FIDO-Sicherheitsschlüssels. Die Gerätezertifizierung wird vom FIDO Alliance Metadata Service (MDS) abgerufen. Wenn sich der Zertifizierungsstatus oder die Stufe Ihres FIDO-Sicherheitsschlüssels ändert, wird dieser nicht aktualisiert, es sei denn, das Gerät wird deregistriert und erneut registriert, um die aktualisierten Zertifizierungsinformationen abzurufen.

Mögliche Werte von L1, L1plus, L2, L2plus, L3, L3plus

In diesem Beispiel registrieren Sie einen Sicherheitsschlüssel und erhalten die FIDO Level 1 Plus-Zertifizierung für Ihr Gerät.

JSON
{ "Version":"2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "iam:EnableMFADevice", "Resource": "*", "Condition": { "StringEquals": { "iam:RegisterSecurityKey" : "Create" } } }, { "Effect": "Allow", "Action": "iam:EnableMFADevice", "Resource": "*", "Condition": { "StringEquals": { "iam:RegisterSecurityKey" : "Activate", "iam:FIDO-certification": "L1plus" } } } ] }
iam:FIDO-FIPS-140-2-certification

Funktioniert mit Zeichenfolgenoperatoren.

Überprüft die FIPS-140-2-Validierungszertifizierungsstufe des MFA-Geräts zum Zeitpunkt der Registrierung eines FIDO-Sicherheitsschlüssels. Die Gerätezertifizierung wird vom FIDO Alliance Metadata Service (MDS) abgerufen. Wenn sich der Zertifizierungsstatus oder die Stufe Ihres FIDO-Sicherheitsschlüssels ändert, wird dieser nicht aktualisiert, es sei denn, das Gerät wird deregistriert und erneut registriert, um die aktualisierten Zertifizierungsinformationen abzurufen.

Mögliche Werte von L1, L2, L3, L4

In diesem Beispiel registrieren Sie einen Sicherheitsschlüssel und erhalten die Zertifizierung FIPS-140-2 Level 2 für Ihr Gerät.

JSON
{ "Version":"2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "iam:EnableMFADevice", "Resource": "*", "Condition": { "StringEquals": { "iam:RegisterSecurityKey" : "Create" } } }, { "Effect": "Allow", "Action": "iam:EnableMFADevice", "Resource": "*", "Condition": { "StringEquals": { "iam:RegisterSecurityKey" : "Activate", "iam:FIDO-FIPS-140-2-certification": "L2" } } } ] }
iam:FIDO-FIPS-140-3-certification

Funktioniert mit Zeichenfolgenoperatoren.

Überprüft die FIPS-140-3-Validierungszertifizierungsstufe des MFA-Geräts zum Zeitpunkt der Registrierung eines FIDO-Sicherheitsschlüssels. Die Gerätezertifizierung wird vom FIDO Alliance Metadata Service (MDS) abgerufen. Wenn sich der Zertifizierungsstatus oder die Stufe Ihres FIDO-Sicherheitsschlüssels ändert, wird dieser nicht aktualisiert, es sei denn, das Gerät wird deregistriert und erneut registriert, um die aktualisierten Zertifizierungsinformationen abzurufen.

Mögliche Werte von L1, L2, L3, L4

In diesem Beispiel registrieren Sie einen Sicherheitsschlüssel und erhalten die Zertifizierung FIPS-140-3 Level 3 für Ihr Gerät.

JSON
{ "Version":"2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "iam:EnableMFADevice", "Resource": "*", "Condition": { "StringEquals": { "iam:RegisterSecurityKey" : "Create" } } }, { "Effect": "Allow", "Action": "iam:EnableMFADevice", "Resource": "*", "Condition": { "StringEquals": { "iam:RegisterSecurityKey" : "Activate", "iam:FIDO-FIPS-140-3-certification": "L3" } } } ] }
iam:OrganizationsPolicyId

Funktioniert mit Zeichenfolgenoperatoren.

Prüft, ob die Richtlinie mit der angegebenen AWS Organizations-ID mit der in der Anforderung verwendeten Richtlinie übereinstimmt. Informationen zum Anzeigen einer IAM-Beispielrichtlinie, die diesen Bedingungsschlüssel verwendet, finden Sie unter IAM: Anzeigen von Informationen zum letzten Zugriff auf einen Service für eine AWS Organizations-Richtlinie.

iam:PassedToService

Funktioniert mit Zeichenfolgenoperatoren.

Gibt den ServiceAuftraggeber des Services an, an den eine Rolle übergeben werden kann. Dieser Bedingungsschlüssel gilt nur für die Aktion PassRole in einer Richtlinie. Er kann nicht verwendet werden, um eine andere Aktion zu beschränken.

Wenn Sie diesen Bedingungsschlüssel in einer Richtlinie verwenden, geben Sie den Service über einen Dienstauftraggeber an. Ein Serviceprinzipal ist der Name eines Service, der im Element Principal einer Richtlinie angegeben werden kann. Standardformat: SERVICE_NAME_URL.amazonaws.com.

Sie können iam:PassedToService verwenden, um die Benutzer einzuschränken, damit sie Rollen nur an bestimmte Services übergeben können. Ein Benutzer kann beispielsweise eine Servicerolle erstellen, die CloudWatch-Protokolldaten in seinem Namen in einen Amazon S3-Bucket schreiben lässt. Der Benutzer muss dann eine Berechtigungsrichtlinie und eine Vertrauensrichtlinie an die neue Servicerolle anfügen. In diesem Fall muss die Vertrauensrichtlinie cloudwatch.amazonaws.com im Element Principal angeben. Um eine Richtlinie anzuzeigen, die es dem Benutzer erlaubt, die Rolle an CloudWatch zu übergeben, siehe IAM: Übergeben einer IAM-Rolle an einen bestimmten AWS-Service.

Mit diesem Bedingungsschlüssel können Sie sicherstellen, dass Benutzer Servicerollen nur für die von Ihnen angegebenen Services erstellen. Wenn beispielsweise ein Benutzer mit der vorherigen Richtlinie versucht, eine Servicerolle für Amazon EC2 zu erstellen, schlägt der Vorgang fehl. Der Fehlschlag tritt auf, weil der Benutzer nicht über die Berechtigung verfügt, die Rolle an Amazon EC2 zu übergeben.

Manchmal übergeben Sie eine Rolle an einen Service, der die Rolle dann an einen anderen Service übergibt. iam:PassedToService enthält nur den endgültigen Dienst, der die Rolle übernimmt, nicht den Zwischendienst, der die Rolle übergibt.

Anmerkung

Einige Services unterstützen diesen Bedingungsschlüssel nicht.

iam:PermissionsBoundary

Funktioniert mit ARN-Operatoren.

Überprüft, ob die angegebene Richtlinie als Berechtigungsgrenze an die IAM-Auftraggeber-Ressource angefügt. Weitere Informationen finden Sie unter Berechtigungsgrenzen für IAM-Entitäten

iam:PolicyARN

Funktioniert mit ARN-Operatoren.

Prüft den Amazon-Ressourcennamen (ARN) einer verwalteten Richtlinie in Anforderungen mit Beteiligung einer verwalteten Richtlinie. Weitere Informationen finden Sie unter Steuern des Zugriffs auf Richtlinien.

iam:RegisterSecurityKey

Funktioniert mit Zeichenfolgenoperatoren.

Prüft den aktuellen Status der MFA-Geräteaktivierung.

Mögliche Werte von Create oder Activate.

In diesem Beispiel registrieren Sie einen Sicherheitsschlüssel und erhalten die Zertifizierung FIPS-140-3 Level 1 für Ihr Gerät.

JSON
{ "Version":"2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "iam:EnableMFADevice", "Resource": "*", "Condition": { "StringEquals": { "iam:RegisterSecurityKey" : "Create" } } }, { "Effect": "Allow", "Action": "iam:EnableMFADevice", "Resource": "*", "Condition": { "StringEquals": { "iam:RegisterSecurityKey" : "Activate", "iam:FIDO-FIPS-140-3-certification": "L1" } } } ] }
iam:ResourceTag/key-name

Funktioniert mit Zeichenfolgenoperatoren.

Überprüft, ob das an die Identitätsressource (Benutzer oder Rolle) angefügte Tag mit dem angegebenen Schlüsselnamen und Wert übereinstimmt.

Anmerkung

IAM und AWS STS unterstützen sowohl den iam:ResourceTag-IAM-Bedingungsschlüssel als auch den aws:ResourceTag-globalen Bedingungsschlüssel.

Sie können IAM-Ressourcen benutzerdefinierte Attribute in Form eines Schlüssel-Wert-Paares hinzufügen. Weitere Informationen zum Markieren von IAM-Ressourcen finden Sie unter Tags für AWS Identity and Access Management-Ressourcen. Sie können ResourceTag verwenden, um den Zugriff auf AWS-Ressourcen, einschließlich IAM-Ressourcen, zu steuern. IAM unterstützt jedoch keine Tags für Gruppen. Daher können Sie Tags nicht verwenden, um den Zugriff auf Gruppen zu steuern.

Dieses Beispiel zeigt, wie Sie eine identitätsbasierte Richtlinie erstellen könnten, die das Löschen von Benutzern mit dem status=terminated-Tag erlaubt. Um diese Richtlinie zu verwenden, ersetzen Sie den kursiv gedruckten Platzhaltertext in der Beispielrichtlinie durch Ihre eigenen Informationen. Befolgen Sie dann die Anweisungen unter Erstellen einer Richtlinie oder Bearbeiten einer Richtlinie.

JSON
{ "Version":"2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "iam:DeleteUser", "Resource": "*", "Condition": {"StringEquals": {"iam:ResourceTag/status": "terminated"}} }] }
iam:ServiceSpecificCredentialAgeDays

Funktioniert mit nummerischen Operatoren.

Dieser Bedingungsschlüssel schränkt die Erstellung von servicespezifischen Anmeldeinformationen auf der Grundlage ihrer Ablaufeinstellungen ein. Damit können Sie das maximale Alter in Tagen für servicespezifische Anmeldeinformationen festlegen, die erstellt werden können.

Der gültige Bereich für Tage liegt zwischen 1 und 36 600 (mindestens 1 Tag, maximal 36 600 Tage).

Dieser Bedingungsschlüssel wird von der CreateServiceSpecificCredential-API-Operation unterstützt.

In diesem Beispiel erlauben Sie einem Benutzer, servicespezifische Anmeldeinformationen für den Amazon Bedrock-Service nur zu erstellen, wenn diese innerhalb von 90 Tagen ablaufen.

JSON
{ "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "iam:CreateServiceSpecificCredential", "Resource": "arn:aws:iam::111122223333:user/username", "Condition": { "StringEquals": { "iam:ServiceSpecificCredentialServiceName": "bedrock.amazonaws.com" }, "NumericLessThanEquals": { "iam:ServiceSpecificCredentialAgeDays": "90" } } } ] }
iam:ServiceSpecificCredentialServiceName

Funktioniert mit Zeichenfolgenoperatoren.

Gibt an, welche AWS-Services bei der Verwaltung servicespezifischer Anmeldeinformationen verwendet werden können. Mit diesem Bedingungsschlüssel können Sie einschränken, welche AWS-Services bei der Verwaltung servicespezifischer Anmeldeinformationen zulässig sind.

Dieser Bedingungsschlüssel wird von folgenden API-Operationen unterstützt.

Die folgenden Services werden für servicespezifische Anmeldeinformationen mit ihrer genauen Wertformatierung unterstützt:

  • bedrock.amazonaws.com

  • cassandra.amazonaws.com

  • codecommit.amazonaws.com

In diesem Beispiel ermöglichen Sie einem Benutzer, servicespezifische Anmeldeinformationen mithilfe der CreateServiceSpecificCredential-API-Operation nur für den Amazon-Bedrock-Service zu erstellen.

JSON
{ "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "iam:CreateServiceSpecificCredential", "Resource": "arn:aws:iam::111122223333:user/username", "Condition": { "StringEquals": { "iam:ServiceSpecificCredentialServiceName": "bedrock.amazonaws.com" } } } ] }

Verfügbare Schlüssel für AWS-OIDC-Verbund

Sie können den OIDC-Verbund verwenden, um Benutzern, die über einen mit OpenID Connect kompatiblen Identitätsanbieter (IdP) bei einem IAM OpenID Connect (OIDC)-Identitätsanbieter in Ihrem AWS-Konto authentifiziert wurden, temporäre Sicherheits-Anmeldeinformationen zu gewähren. Beispiele für solche Anbieter sind GitHub, Amazon Cognito, Login mit Amazon und Google. Es können Identitäts- und Zugriffstokens von Ihrem eigenen IdP sowie Servicekonto-Tokens verwendet werden, die Service-Workloads von Amazon Elastic Kubernetes gewährt werden.

Sie können AWS-OIDC-Bedingungskontextschlüssel verwenden, um Richtlinien zu schreiben, die den Zugriff von Verbundprinzipalen auf Ressourcen beschränken, die einem bestimmten Anbieter, einer bestimmten App oder einem bestimmten Benutzer zugeordnet sind. Diese Schlüssel werden in der Regel in der Vertrauensrichtlinie für eine Rolle verwendet. Definieren Sie Bedingungsschlüssel mit dem Namen des OIDC-Anbieters (token.actions.githubusercontent.com), gefolgt von einem Antrag (:aud): token.actions.githubusercontent.com:aud.

Einige Bedingungsschlüssel für den OIDC-Verbund können in der Rollensitzung verwendet werden, um den Ressourcenzugriff zu autorisieren. Wenn in der Spalte In Sitzung verfügbar der Wert Ja lautet, können Sie diese Bedingungsschlüssel in Richtlinien verwenden, um zu definieren, worauf Benutzer in anderen AWS-Services zugreifen dürfen. Wenn ein Antrag in der Sitzung nicht verfügbar ist, kann der OIDC-Bedingungskontextschlüssel nur in einer Rollenvertrauensrichtlinie für die anfängliche Authentifizierung mit AssumeRoleWithWebIdentity verwendet werden.

Wählen Sie Ihren IdP aus, um zu sehen, wie Anträge von Ihrem IdP den IAM-Bedingungskontextschlüsseln in AWS zugeordnet werden. Weitere Informationen zu Schlüsseln für GitHub und Google finden Sie auf der Registerkarte Standard.

Default

Standardmäßig werden die standardmäßigen OIDC-Anträge und deren Zuordnung zu Bedingungskontextschlüsseln AWS STS in AWS aufgelistet. Mit diesen Schlüsseln können Sie den Zugriff auf eine Rolle steuern. Vergleichen Sie dazu die AWS STS-Bedingungsschlüssel mit den Werten in der Spalte mit dem IdP-JWT-Antrag. Verwenden Sie diese Zuordnung, wenn Ihr IdP nicht in den Registerkartenoptionen aufgeführt ist.

GitHub-Aktions-Workflows und Google sind einige Beispiele für IDPs, die die Standardimplementierung in ihrem OIDC-JWT-ID-Token verwenden.

AWS STS-Bedingungsschlüssel IdP-JWT-Antrag In der Sitzung verfügbar

amr

amr

Ja

aud

azp

Wenn für azp kein Wert festgelegt ist, wird der aud-Bedingungsschlüssel dem aud-Antrag zugeordnet.

Ja

E-Mail

E-Mail

Nein

oaud

aud

Nein

sub

sub

Ja

Weitere Informationen zur Verwendung von OIDC-Bedingungskontextschlüsseln mit GitHub finden Sie unter Konfigurieren einer Rolle für den GitHub-OIDC-Identitätsanbieter. Weitere Informationen zu den Google-Feldern aud und azp finden Sie im Google Identity Platform OpenID Connect-Leitfaden.

amr

Funktioniert mit Zeichenfolgenoperatoren. Der Schlüssel enthält mehrere Werte, d. h. Sie überprüfen ihn in einer Richtlinie mithilfe von Bedingungsmengenoperatoren.

Beispiel: token.actions.githubusercontent.com:amr

Die Referenz zu Authentifizierungsmethoden enthält Anmeldeinformationen zum Benutzer. Der Schlüssel kann die folgenden Werte enthalten:

  • Wenn der Benutzer nicht authentifiziert wurde, enthält der Schlüssel nur unauthenticated.

  • Wenn der Benutzer authentifiziert wurde, enthält der Schlüssel den Wert authenticated sowie den Namen des Identitätsanbieters, der in dem Aufruf (accounts.google.com) verwendet wurde.

aud

Funktioniert mit Zeichenfolgenoperatoren.

Beispiele:

  • accounts.google.com:aud

  • token.actions.githubusercontent.com:aud

Verwenden Sie den aud-Bedingungsschlüssel, um zu überprüfen, ob die Zielgruppe mit der in der Richtlinie angegebenen übereinstimmt. Sie können den aud-Schlüssel mit dem Sub-Schlüssel für denselben Identitätsanbieter verwenden.

Dieser Bedingungsschlüssel wird aus den folgenden Token-Feldern festgelegt:

  • aud for OAuth 2.0-Google-Client-IDs Ihrer Anwendung, wenn das Feld azp nicht festgelegt ist. Wenn das azp-Feld festgelegt ist, stimmt das aud-Feld mit dem Bedingungsschlüssel accounts.google.com:oaud überein.

  • azp, wenn das Feld azp festgelegt ist. Dies kann bei hybriden Anwendungen passieren, bei denen eine Webanwendung und eine Android-Anwendung eine unterschiedliche OAuth 2.0 Google-Client-ID haben, aber dasselbe Google-APIs-Projekt verwenden.

Wenn Sie eine Richtlinie mit dem accounts.google.com:aud-Bedingungsschlüssel schreiben, müssen Sie wissen, ob die Anwendung eine Hybridanwendung ist, die das Feld azp festlegt.

azp-Feld nicht festgelegt

Die folgende Beispielrichtlinie funktioniert für nicht-hybride Anwendungen, die das Feld azp nicht festlegen. In diesem Fall stimmt der Wert des Google-ID-Token aud-Felds mit dem accounts.google.com:aud- und dem accounts.google.com:oaud-Bedingungsschlüsselwert überein.

JSON
JSON
{ "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": {"Federated": "accounts.google.com"}, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "accounts.google.com:aud": "aud-value", "accounts.google.com:oaud": "aud-value", "accounts.google.com:sub": "sub-value" } } } ] }

azp-Feld festgelegt

Die folgende Beispielrichtlinie funktioniert für hybride Anwendungen, die das Feld azp festlegen. In diesem Fall stimmt der Wert des Google-ID-Token aud-Felds nur mit dem Wert des Bedingungsschlüssels accounts.google.com:oaud überein. Der Wert des Feldes azp entspricht dem Wert des accounts.google.com:aud-Bedingungsschlüssels.

JSON
JSON
{ "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": {"Federated": "accounts.google.com"}, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "accounts.google.com:aud": "azp-value", "accounts.google.com:oaud": "aud-value", "accounts.google.com:sub": "sub-value" } } } ] }
E-Mail

Funktioniert mit Zeichenfolgenoperatoren.

Beispiel: accounts.google.com:email

Dieser Bedingungsschlüssel validiert die E-Mail-Adresse des Benutzers. Der Wert dieses Antrags ist für dieses Konto möglicherweise nicht eindeutig und kann sich im Laufe der Zeit ändern. Daher sollten Sie diesen Wert nicht als primäre Kennung zur Überprüfung Ihres Benutzerdatensatzes verwenden.

oaud

Funktioniert mit Zeichenfolgenoperatoren.

Beispiel: accounts.google.com:oaud

Dieser Schlüssel gibt die andere Zielgruppe (aud) an, für die dieses ID-Token bestimmt ist. Es muss eine der OAuth 2.0-Client-IDs Ihrer Anwendung sein.

sub

Funktioniert mit Zeichenfolgenoperatoren.

Beispiele:

  • accounts.google.com:sub

  • token.actions.githubusercontent.com:sub

Verwenden Sie diese Schlüssel, um zu überprüfen, ob der Betreff mit dem übereinstimmt, den Sie in der Richtlinie angeben. Sie können den sub-Schlüssel mit dem aud-Schlüssel für denselben Identitätsanbieter verwenden.

In der folgenden Rollenvertrauensrichtlinie beschränkt der Bedingungsschlüssel sub die Rolle auf die GitHub-Verzweigung mit dem Namen demo.

JSON
JSON
{ "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::111122223333:oidc-provider/token.actions.githubusercontent.com" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "token.actions.githubusercontent.com:aud": "sts.amazonaws.com", "token.actions.githubusercontent.com:sub": "repo:org-name/repo-name:ref:refs/heads/demo" } } } ] }
Amazon Cognito

Auf dieser Registerkarte wird erläutert, wie Amazon Cognito OIDC-Anträge den Bedingungskontextschlüsseln AWS STS in AWS zuordnet. Mit diesen Schlüsseln können Sie den Zugriff auf eine Rolle steuern. Vergleichen Sie dazu die AWS STS-Bedingungsschlüssel mit den Werten in der Spalte mit dem IdP-JWT-Antrag.

Für Rollen, die von Amazon Cognito verwendet werden, werden Schlüssel definiert mit cognito-identity.amazonaws.com, gefolgt von der Forderung.

Weitere Informationen zur Zuordnung von Identitätspool-Anträgen finden Sie unter Standardanbieter-Zuordnungen im Amazon-Cognito-Entwicklerhandbuch. Weitere Informationen zur Zuordnung von Benutzerpool-Anträgen finden Sie unter Verwendung des ID-Tokens im Amazon-Cognito-Entwicklerhandbuch.

AWS STS-Bedingungsschlüssel IdP-JWT-Antrag In der Sitzung verfügbar

amr

amr

Ja

aud

aud

Ja

oaud

aud

Nein

sub

sub

Ja

amr

Funktioniert mit Zeichenfolgenoperatoren. Der Schlüssel enthält mehrere Werte, d. h. Sie überprüfen ihn in einer Richtlinie mithilfe von Bedingungsmengenoperatoren.

Beispielcognito-identity.amazonaws.com:amr

Die Referenz zu Authentifizierungsmethoden enthält Anmeldeinformationen zum Benutzer. Der Schlüssel kann die folgenden Werte enthalten:

  • Wenn der Benutzer nicht authentifiziert wurde, enthält der Schlüssel nur unauthenticated.

  • Wenn der Benutzer authentifiziert wurde, enthält der Schlüssel den Wert authenticated sowie den Namen des Identitätsanbieters, der in dem Aufruf (cognito-identity.amazonaws.com) verwendet wurde.

Beispielsweise testet die folgende Bedingung in der Vertrauensrichtlinie für eine Amazon Cognito-Rolle, ob der Benutzer nicht authentifiziert ist.

"Condition": { "StringEquals": { "cognito-identity.amazonaws.com:aud": "us-east-2:identity-pool-id" }, "ForAnyValue:StringLike": { "cognito-identity.amazonaws.com:amr": "unauthenticated" } }
aud

Funktioniert mit Zeichenfolgenoperatoren.

Beispielcognito-identity.amazonaws.com:aud

Der Benutzerpool-App-Client, der Ihren Benutzer authentifiziert hat. Amazon Cognito gibt den gleichen Wert im Zugriffstoken-Anspruch client_id wieder.

oaud

Funktioniert mit Zeichenfolgenoperatoren.

Beispielcognito-identity.amazonaws.com:oaud

Der Benutzerpool-App-Client, der Ihren Benutzer authentifiziert hat. Amazon Cognito gibt den gleichen Wert im Zugriffstoken-Anspruch client_id wieder.

sub

Funktioniert mit Zeichenfolgenoperatoren.

Beispielcognito-identity.amazonaws.com:sub

Eine eindeutige ID (UUID) oder ein Betreff für den authentifizierten Benutzer. Möglicherweise ist der Benutzername in Ihrem Benutzerpool nicht eindeutig. Der sub-Antrag ist der beste Weg, um einen bestimmten Benutzer zu identifizieren. Sie können den sub-Schlüssel mit dem aud-Schlüssel für denselben Identitätsanbieter verwenden.

"Condition": { "StringEquals": { "cognito-identity.amazonaws.com:aud": "us-east-1:12345678-abcd-abcd-abcd-123456790ab", "cognito-identity.amazonaws.com:sub": [ "us-east-1:12345678-1234-1234-1234-123456790ab", "us-east-1:98765432-1234-1234-1243-123456790ab" ] } }
Login with Amazon

Auf dieser Registerkarte wird erläutert, wie Login mit Amazon-OIDC-Anträge den AWS STS-Bedingungskontextschlüsseln in AWS zuordnet. Mit diesen Schlüsseln können Sie den Zugriff auf eine Rolle steuern. Vergleichen Sie dazu die AWS STS-Bedingungsschlüssel mit den Werten in der Spalte mit dem IdP-JWT-Antrag.

AWS STS-Bedingungsschlüssel IdP-JWT-Antrag In der Sitzung verfügbar

app_id

Anwendungs-ID

Ja

sub

Benutzer-ID

Ja

user_id

Benutzer-ID

Ja

app_id

Funktioniert mit Zeichenfolgenoperatoren.

Beispielwww.amazon.com:app_id

Dieser Schlüssel gibt den Zielgruppenkontext an, der mit dem von anderen Identitätsanbietern verwendeten aud-Feld übereinstimmt.

sub

Funktioniert mit Zeichenfolgenoperatoren.

Beispielwww.amazon.com:sub

Dieser Schlüssel überprüft, ob die Benutzer-ID mit der in der Richtlinie angegebenen übereinstimmt. Sie können den sub -Schlüssel mit dem aud-Schlüssel für denselben Identitätsanbieter verwenden.

user_id

Funktioniert mit Zeichenfolgenoperatoren.

Beispielwww.amazon.com:user_id

Dieser Schlüssel gibt den Zielgruppenkontext an, der dem von anderen Identitätsanbietern verwendeten aud-Feld entspricht. Sie können den user_id-Schlüssel mit dem id-Schlüssel für denselben Identitätsanbieter verwenden.

Facebook

Auf dieser Registerkarte wird erläutert, wie Facebook OIDC-Anträge den AWS STS-Bedingungskontextschlüsseln in AWS zuordnet. Mit diesen Schlüsseln können Sie den Zugriff auf eine Rolle steuern. Vergleichen Sie dazu die AWS STS-Bedingungsschlüssel mit den Werten in der Spalte mit dem IdP-JWT-Antrag.

AWS STS-Bedingungsschlüssel IdP-JWT-Antrag In der Sitzung verfügbar

app_id

Anwendungs-ID

Ja

id

id

Ja

app_id

Funktioniert mit Zeichenfolgenoperatoren.

Beispielgraph.facebook.com:app_id

Dieser Schlüssel überprüft, ob der Zielgruppenkontext mit dem von anderen Identitätsanbietern verwendeten aud-Feld übereinstimmt.

id

Funktioniert mit Zeichenfolgenoperatoren.

Beispielgraph.facebook.com:id

Dieser Schlüssel hat bestätigt, dass die ID der Anwendung (oder Website) mit der in der Richtlinie angegebenen übereinstimmt.

Weitere Informationen zum OIDC-Verbund

Verfügbare Schlüssel für SAML-basierten AWS STS-Verbund

Wenn Sie mit einem SAML-basierten Verbund mit AWS Security Token Service (AWS STS) arbeiten, können Sie in der Richtlinie weitere Bedingungsschlüssel verwenden.

Vertrauensrichtlinien der SAML-Rolle

Sie können in der Vertrauensrichtlinie einer Rolle die folgenden Schlüssel verwenden, um festzustellen, ob der Aufrufer die Rolle übernehmen darf. Abgesehen von saml:doc werden alle Werte aus der SAML-Zusicherung abgeleitet. Alle Elemente in der Liste sind im visuellen Editor der IAM-Konsole verfügbar, wenn Sie eine Richtlinie mit Bedingungen erstellen oder bearbeiten. Elemente, die mit [] gekennzeichnet sind, können einen Wert enthalten, der eine Liste des angegebenen Typs ist.

saml:aud

Funktioniert mit Zeichenfolgenoperatoren.

Eine Endpunkt-URL, für die SAML-Zusicherungen bereitgestellt werden. Der Wert dieses Schlüssels stammt aus dem Feld SAML Recipient der Zusicherung, nicht aus dem Feld Audience.

saml:commonName[]

Funktioniert mit Zeichenfolgenoperatoren.

Dies ist ein commonName-Attribut.

saml:cn[]

Funktioniert mit Zeichenfolgenoperatoren.

Hierbei handelt es sich um ein eduOrg-Attribut.

saml:doc

Funktioniert mit Zeichenfolgenoperatoren.

Dieser Schlüssel steht für den Auftraggeber, der zum Übernehmen der Rolle verwendet wurde. Das Format ist Konto-ID/Anzeigename des Anbieters, z. B. 123456789012/SAMLProviderName. Der Wert Konto-ID bezieht sich auf das Konto, zu dem der SAML-Anbieter gehört.

saml:edupersonaffiliation[]

Funktioniert mit Zeichenfolgenoperatoren.

Hierbei handelt es sich um ein eduPerson-Attribut.

saml:edupersonassurance[]

Funktioniert mit Zeichenfolgenoperatoren.

Hierbei handelt es sich um ein eduPerson-Attribut.

saml:edupersonentitlement[]

Funktioniert mit Zeichenfolgenoperatoren.

Hierbei handelt es sich um ein eduPerson-Attribut.

saml:edupersonnickname[]

Funktioniert mit Zeichenfolgenoperatoren.

Hierbei handelt es sich um ein eduPerson-Attribut.

saml:edupersonorgdn

Funktioniert mit Zeichenfolgenoperatoren.

Hierbei handelt es sich um ein eduPerson-Attribut.

saml:edupersonorgunitdn[]

Funktioniert mit Zeichenfolgenoperatoren.

Hierbei handelt es sich um ein eduPerson-Attribut.

saml:edupersonprimaryaffiliation

Funktioniert mit Zeichenfolgenoperatoren.

Hierbei handelt es sich um ein eduPerson-Attribut.

saml:edupersonprimaryorgunitdn

Funktioniert mit Zeichenfolgenoperatoren.

Hierbei handelt es sich um ein eduPerson-Attribut.

saml:edupersonprincipalname

Funktioniert mit Zeichenfolgenoperatoren.

Hierbei handelt es sich um ein eduPerson-Attribut.

saml:edupersonscopedaffiliation[]

Funktioniert mit Zeichenfolgenoperatoren.

Hierbei handelt es sich um ein eduPerson-Attribut.

saml:edupersontargetedid[]

Funktioniert mit Zeichenfolgenoperatoren.

Hierbei handelt es sich um ein eduPerson-Attribut.

saml:eduorghomepageuri[]

Funktioniert mit Zeichenfolgenoperatoren.

Hierbei handelt es sich um ein eduOrg-Attribut.

saml:eduorgidentityauthnpolicyuri[]

Funktioniert mit Zeichenfolgenoperatoren.

Hierbei handelt es sich um ein eduOrg-Attribut.

saml:eduorglegalname[]

Funktioniert mit Zeichenfolgenoperatoren.

Hierbei handelt es sich um ein eduOrg-Attribut.

saml:eduorgsuperioruri[]

Funktioniert mit Zeichenfolgenoperatoren.

Hierbei handelt es sich um ein eduOrg-Attribut.

saml:eduorgwhitepagesuri[]

Funktioniert mit Zeichenfolgenoperatoren.

Hierbei handelt es sich um ein eduOrg-Attribut.

saml:givenName[]

Funktioniert mit Zeichenfolgenoperatoren.

Dies ist ein givenName-Attribut.

saml:iss

Funktioniert mit Zeichenfolgenoperatoren.

Der Aussteller in Form eines URN

saml:mail[]

Funktioniert mit Zeichenfolgenoperatoren.

Dies ist ein mail-Attribut.

saml:name[]

Funktioniert mit Zeichenfolgenoperatoren.

Dies ist ein name-Attribut.

saml:namequalifier

Funktioniert mit Zeichenfolgenoperatoren.

Ein Hash-Wert basierend auf dem Anzeigenamen des SAML-Anbieters. Der Wert ist die Verkettung der folgenden Werte in der angegebenen Reihenfolge und getrennt durch das Zeichen „/“:

  1. Der Issuer Antwortwert (saml:iss)

  2. Die AWS-Konto-ID.

  3. Der Anzeigename (der letzte Teil des ARN) des SAML-Anbieters in IAM

Die Verkettung der Konto-ID und des Anzeigenamens des SAML-Anbieters steht als der Schlüssel für IAM-Richtlinien zur Verfügung saml:doc. Weitere Informationen finden Sie unter Eindeutige Identifizierung von Benutzern im SAML-basierten Verbund.

saml:organizationStatus[]

Funktioniert mit Zeichenfolgenoperatoren.

Hierbei handelt es sich um ein organizationStatus-Attribut.

saml:primaryGroupSID[]

Funktioniert mit Zeichenfolgenoperatoren.

Dies ist ein primaryGroupSID-Attribut.

saml:sub

Funktioniert mit Zeichenfolgenoperatoren.

Dies ist der Betreff des Antrags, der einen Wert enthält, der einen einzelnen Benutzer innerhalb einer Organisation eindeutig identifiziert (zum Beispiel )., _cbb88bf52c2510eabe00c1642d4643f41430fe25e3).

saml:sub_type

Funktioniert mit Zeichenfolgenoperatoren.

Dieser Schlüssel kann den Wert persistent oder transient oder die vollständige Format-URI aus den in der SAML-Zusicherung verwendeten Elementen Subject und NameID enthalten. Der Wert persistent gibt an, dass der Wert in saml:sub für einen Benutzer für alle Sitzungen identisch ist. Wenn der Wert transient lautet, hat der Benutzer einen anderen saml:sub-Wert für jede Sitzung. Weitere Informationen zum NameID-Attribut des Format-Elements finden Sie unter Konfigurieren von SAML-Assertionen für die Authentifizierungsreaktion.

saml:surname[]

Funktioniert mit Zeichenfolgenoperatoren.

Dies ist ein surnameuid-Attribut.

saml:uid[]

Funktioniert mit Zeichenfolgenoperatoren.

Dies ist ein uid-Attribut.

saml:x500UniqueIdentifier[]

Funktioniert mit Zeichenfolgenoperatoren.

Hierbei handelt es sich um ein x500UniqueIdentifier-Attribut.

Allgemeine Informationen zu den Attributen eduPerson und eduOrg finden Sie auf der Wiki-Website von REFEDS. Eine Liste der eduPerson-Attribute finden Sie unter eduPerson Object Class Specification (201602).

Bedingungsschlüssel mit dem Typ „Liste“ können mehrere Werte enthalten. Um in einer Richtlinie Bedingungen für Listenwerte zu erstellen, können Sie Mengenoperatoren (ForAllValues, ForAnyValue) verwenden. Um beispielsweise jeden Benutzer zuzulassen, dessen Zugehörigkeit „Lehrkörper“ oder „Personal“ (aber nicht „Student“) ist, können Sie eine Bedingung wie die folgende verwenden:

"Condition": { "ForAllValues:StringLike": { "saml:edupersonaffiliation":[ "faculty", "staff"] } }

Serviceübergreifende SAML-basierte AWS STS-Verbundkontextschlüssel

Einige SAML-basierte Verbundbedingungsschlüssel können in nachfolgenden Anfragen verwendet werden, um AWS-Vorgänge in anderen Services und AssumeRole-Aufrufen zu autorisieren. Dies sind die folgenden Bedingungsschlüssel, die in Rollenvertrauensrichtlinien verwendet werden können, wenn Verbundprinzipale eine andere Rolle übernehmen, und in Ressourcenrichtlinien anderer AWS-Services, um den Ressourcenzugriff durch Verbundprinzipale zu autorisieren. Weitere Informationen über die Verwendung dieser Schlüssel finden Sie unter Informationen zum SAML-2.0-basierten Verbund.

Wählen Sie einen Bedingungsschlüssel aus, um die Beschreibung zu sehen.

Anmerkung

Nach der ersten Authentifizierungsantwort des externen Identitätsanbieters (IDP) stehen keine anderen SAML-basierten Verbundbedingungsschlüssel zur Verfügung.

Verfügbare Schlüssel für AWS STS

Sie können die folgenden Bedingungsschlüssel in IAM-Rollenvertrauensrichtlinien für Rollen verwenden, die mit AWS Security Token Service (AWS STS)-Operationen angenommen werden.

saml:sub

Funktioniert mit Zeichenfolgenoperatoren.

Dies ist der Betreff des Antrags, der einen Wert enthält, der einen einzelnen Benutzer innerhalb einer Organisation eindeutig identifiziert (zum Beispiel )., _cbb88bf52c2510eabe00c1642d4643f41430fe25e3).

sts:AWSServiceName

Funktioniert mit Zeichenfolgenoperatoren.

Verwenden Sie diesen Schlüssel, um einen Service anzugeben, in dem ein Bearertoken verwendet werden kann. Wenn Sie diesen Bedingungsschlüssel in einer Richtlinie verwenden, geben Sie den Service über einen Dienstauftraggeber an. Ein Serviceprinzipal ist der Name eines Service, der im Element Principal einer Richtlinie angegeben werden kann. Beispielsweise ist codeartifact.amazonaws.com der Serviceprinzipal für AWS CodeArtifact.

Verfügbarkeit – Dieser Schlüssel ist in Anforderungen vorhanden, die ein Bearer-Token erhalten. Sie können keinen direkten Aufruf an AWS STS tätigen, um ein Bearer-Token zu erhalten. Wenn Sie einige Operationen in anderen Services ausführen, fordert der Service das Bearer-Token in Ihrem Namen an.

Einige AWS-Services erfordern, dass Sie über die Berechtigung zum Anfordern eines AWS STS-Service-Bearer-Tokens verfügen, bevor Sie programmgesteuert auf ihre Ressourcen zugreifen können. AWS CodeArtifact erfordert beispielsweise, dass Prinzipale Bearer-Tokens verwenden, um einige Vorgänge auszuführen. Der Befehl aws codeartifact get-authorization-token gibt ein Bearer-Token zurück. Sie können dann das Bearer-Token verwenden, um AWS CodeArtifact-Vorgänge auszuführen. Weitere Hinweise zu Bearer-Tokens finden Sie unter Service-Inhaber-Token.

Sie können diesen Bedingungsschlüssel verwenden, um es Auftraggeber zu ermöglichen, ein Bearer-Token für die Verwendung mit einem bestimmten Service zu erhalten.

sts:DurationSeconds

Funktioniert mit nummerischen Operatoren.

Verwenden Sie diesen Schlüssel, um die Dauer (in Sekunden) anzugeben, die ein Auftraggeber beim Abrufen eines AWS STS-Bearer-Tokens verwenden kann.

Verfügbarkeit – Dieser Schlüssel ist in Anforderungen vorhanden, die ein Bearer-Token erhalten. Sie können keinen direkten Aufruf an AWS STS tätigen, um ein Bearer-Token zu erhalten. Wenn Sie einige Operationen in anderen Services ausführen, fordert der Service das Bearer-Token in Ihrem Namen an. Der Schlüssel ist für AWS STS-assume-role-Operationen nicht vorhanden.

Einige AWS-Services erfordern, dass Sie über die Berechtigung zum Anfordern eines AWS STS-Service-Bearer-Tokens verfügen, bevor Sie programmgesteuert auf ihre Ressourcen zugreifen können. AWS CodeArtifact erfordert beispielsweise, dass Prinzipale Bearer-Tokens verwenden, um einige Vorgänge auszuführen. Der Befehl aws codeartifact get-authorization-token gibt ein Bearer-Token zurück. Sie können dann das Bearer-Token verwenden, um AWS CodeArtifact-Vorgänge auszuführen. Weitere Hinweise zu Bearer-Tokens finden Sie unter Service-Inhaber-Token.

sts:ExternalId

Funktioniert mit Zeichenfolgenoperatoren.

Verwenden Sie diesen Schlüssel, um zu verlangen, dass ein Auftraggeber bei der Übernahme einer IAM-Rolle einen bestimmten Bezeichner bereitstellt.

Verfügbarkeit – Dieser Schlüssel ist in der Anforderung vorhanden, wenn der Auftraggeber eine externe ID bereitstellt, während er eine Rolle mit der AWS CLI- oder AWS-API übernimmt.

Eine eindeutige Kennung, die erforderlich sein kann, wenn Sie eine Rolle in einem anderen Konto übernehmen. Wenn Ihnen der Administrator des Kontos, zu dem die Rolle gehört, eine externe ID zur Verfügung gestellt hat, geben Sie diesen Wert im Parameter ExternalId an. Dieser Wert kann eine beliebige Zeichenfolge sein, wie eine Passphrase oder Kontonummer. Die Hauptfunktion des externen Ausweises besteht darin, das Problem des verwirrten Stellvertreters zu lösen und zu verhindern. Weitere Informationen über die externe ID und das Confused-Deputy-Problem finden Sie unter Zugriffs auf im Besitz von Drittanbietern befindlichen AWS-Konten.

Der Wert ExternalId muss mindestens 2 Zeichen und darf höchstens 1.224 Zeichen lang sein. Der Wert muss alphanumerisch sein ohne Leerzeichen. Er kann auch die folgenden Zeichen enthalten: Pluszeichen (+), Gleichheitszeichen (=), Komma (,), Punkt (.), At-Zeichen (@), Doppelpunkt (:), Schrägstrich (/) und Bindestrich (-).

sts:RequestContext/context-key

Funktioniert mit Zeichenfolgenoperatoren.

Verwenden Sie diesen Schlüssel, um die Schlüssel-Wert-Paare aus dem Sitzungskontext, die in die signierte Kontext-Assertion des vertrauenswürdigen Token-Emittenten eingebettet sind, die in der Anfrage übergeben wurde, mit den in der Rollen-Vertrauensrichtlinie angegebenen Kontext-Schlüsselwerten zu vergleichen.

Verfügbarkeit – Dieser Schlüssel ist in der Anforderung vorhanden, wenn eine Kontext-Assertion im Anforderungsparameter ProvidedContexts bereitgestellt wird, während eine Rolle mit der API-Operation AWS STS AssumeRole übernommen wird.

Dieser Kontextschlüssel ist formatiert als "sts:RequestContext/context-key":"context-value", wobei context-key und context-value ein Kontext-Schlüssel-Wert-Paar sind. Wenn mehrere Kontextschlüssel in die in der Anforderung übergebene signierte Kontext-Assertion eingebettet sind, gibt es einen Kontextschlüssel für jedes Schlüssel-Wert-Paar. Sie müssen in der Rollen-Vertrauensrichtlinie die Erlaubnis für die sts:SetContext-Aktion erteilen, damit ein Prinzipal Kontextschlüssel innerhalb des resultierenden Sitzungs-Token festlegen kann. Weitere Informationen zu den unterstützten Kontextschlüsseln für IAM Identity Center, die mit diesem Schlüssel verwendet werden können, finden Sie unter AWS STS-Bedingungsschlüssel für IAM Identity Center im AWS IAM Identity Center-Benutzerhandbuch.

Sie können diesen Schlüssel in einer Rollen-Vertrauensrichtlinie verwenden, um eine detaillierte Zugriffskontrolle zu erzwingen, die auf dem Benutzer oder seinen Attributen basiert, wenn er eine Rolle übernimmt. Nachdem die Rolle übernommen wurde, erscheint die Aktivität in den AWS CloudTrail-Protokollen innerhalb des AdditionalEventData-Elements, die die Schlüssel-Wert-Paare für den Sitzungskontext enthalten, die vom Kontextanbieter in der Anfrage zur Rollenübernahme festgelegt wurden. Dies erleichtert Administratoren die Unterscheidung zwischen Rollensitzungen, wenn eine Rolle von verschiedenen Auftraggeber verwendet wird. Die Schlüssel-Wert-Paare werden vom angegebenen Kontextanbieter festgelegt, nicht von AWS CloudTrail oder AWS STS. Dadurch hat der Kontextanbieter die Kontrolle darüber, welcher Kontext in den CloudTrail-Protokollen und Sitzungsinformationen enthalten ist.

sts:RequestContextProviders

Funktioniert mit ARN-Operatoren.

Verwenden Sie diesen Schlüssel, um den Kontextanbieter-ARN in der Anfrage mit dem Kontextanbieter-ARN zu vergleichen, der in der Rollen-Vertrauensrichtlinie angegeben ist.

Verfügbarkeit – Dieser Schlüssel ist in der Anforderung vorhanden, wenn eine Kontext-Assertion im Anforderungsparameter ProvidedContexts bereitgestellt wird, während eine Rolle mit der API-Operation AWS STS AssumeRole übernommen wird.

Die folgende Beispielbedingung überprüft, ob der in der Anforderung übergebene Kontextanbieter-ARN mit dem in der Rollen-Vertrauensrichtlinien-Bedingung angegebenen ARN übereinstimmt. Wir empfehlen Ihnen, eine Nullprüfung mit ForAllValues hinzuzufügen, um zu verhindern, dass fehlende Kontextschlüssel oder Kontextschlüssel mit leeren Werten als „true“ ausgewertet werden. Details hierzu finden Sie unter Bedingungsoperator zur Prüfung der Existenz von Bedingungsoperatoren .

JSON
{ "Version":"2012-10-17", "Statement": { "Action": "sts:SetContext", "Effect": "Allow", "Resource": "*", "Condition": { "ForAllValues:ArnEquals": { "sts:RequestContextProviders": [ "arn:aws:iam::aws:contextProvider/IdentityCenter" ] }, "Null": { "sts:RequestContextProviders": "false" } } } }
sts:RoleSessionName

Funktioniert mit Zeichenfolgenoperatoren.

Verwenden Sie diesen Schlüssel, um den Sitzungsnamen zu vergleichen, den ein Auftraggeber angibt, wenn er eine Rolle mit dem Wert annimmt, der in der Richtlinie angegeben ist.

Verfügbarkeit – Dieser Schlüssel ist in der Anforderung vorhanden, wenn der Auftraggeber die Rolle mithilfe der AWS-Managementkonsole, des assume-role-CLI-Befehls oder der AWS STS AssumeRole AssumeRole-API-Operation übernimmt.

Sie können diesen Schlüssel in einer Rollenvertrauensrichtlinie verwenden, um zu verlangen, dass Ihre Benutzer einen bestimmten Sitzungsnamen angeben, wenn sie eine Rolle übernehmen. Sie können beispielsweise verlangen, dass IAM-Benutzer ihren eigenen Benutzernamen als Sitzungsnamen angeben. Nachdem der IAM-Benutzer die Rolle übernommen hat, wird die Aktivität in AWS CloudTrail-Protokollen mit dem Sitzungsnamen angezeigt, der dem Benutzernamen entspricht. Dies erleichtert Administratoren die Unterscheidung zwischen Rollensitzungen, wenn eine Rolle von verschiedenen Auftraggeber verwendet wird.

Die folgende Rollenvertrauensrichtlinie erfordert, dass IAM-Benutzer im Konto 111122223333 ihren IAM-Benutzernamen als Sitzungsnamen angeben, wenn sie die Rolle übernehmen. Diese Anforderung wird mit der Bedingungsvariablen aws:username im Bedingungsschlüssel erzwungen. Mit dieser Richtlinie können IAM-Benutzer die Rolle übernehmen, an die die Richtlinie angefügt ist. Diese Richtlinie erlaubt niemandem, der temporäre Anmeldeinformationen verwendet, die Rolle zu übernehmen, da die username-Variable nur für IAM-Benutzer vorhanden ist.

Wichtig

Sie können jeden einwertigen Bedingungsschlüssel als Variable verwenden. Sie können einen mehrwertigen Bedingungsschlüssel nicht als Variable verwenden.

JSON
{ "Version":"2012-10-17", "Statement": [ { "Sid": "RoleTrustPolicyRequireUsernameForSessionName", "Effect": "Allow", "Action": "sts:AssumeRole", "Principal": {"AWS": "arn:aws:iam::111122223333:root"}, "Condition": { "StringLike": {"sts:RoleSessionName": "prefix-${aws:username}"} } } ] }

Wenn ein Administrator das AWS CloudTrail-Protokoll für eine Aktion einsieht, kann er den Sitzungsnamen mit den Benutzernamen in seinem Konto vergleichen. Im folgenden Beispiel führte der Benutzer matjac den Vorgang mit der Rolle namens MateoRole. Der Administrator kann sich dann an Mateo Jackson wenden, den der Benutzer als matjac benannt hat.

"assumedRoleUser": { "assumedRoleId": "AROACQRSTUVWRAOEXAMPLE:matjac", "arn": "arn:aws:sts::111122223333:assumed-role/MateoRole/matjac" }

Wenn Sie kontenübergreifenden Zugriff mithilfe von Rollen zulassen, können Benutzer in einem Konto eine Rolle in einem anderen Konto übernehmen. Der ARN des in CloudTrail aufgeführten übernommenen Rollenbenutzers enthält das Konto, in dem die Rolle vorhanden ist. Darin ist nicht das Konto des Benutzers enthalten, der die Rolle übernommen hat. Benutzer sind nur innerhalb eines Kontos eindeutig. Daher wird empfohlen, dass Sie mit dieser Methode nur CloudTrail-Protokolle für Rollen überprüfen, die von Benutzern in Konten angenommen werden, die von Ihnen verwaltet werden. Ihre Benutzer verwenden möglicherweise denselben Benutzernamen in mehreren Konten.

STS:SourceIdentity

Funktioniert mit Zeichenfolgenoperatoren.

Verwenden Sie diesen Schlüssel, um den Sitzungsnamen zu vergleichen, den ein Auftraggeber angibt, wenn er eine Rolle mit dem Wert annimmt, der in der Richtlinie angegeben ist.

Verfügbarkeit – Dieser Schlüssel ist in der Anforderung vorhanden, wenn der Auftraggeber eine Quellidentität bereitstellt, während er eine Rolle mit einem AWS STS assume-role CLI-Befehl oder einer AWS STS AssumeRole-API-Operation

Sie können diesen Schlüssel in einer Rollenvertrauensrichtlinie verwenden, um zu verlangen, dass Ihre Benutzer eine bestimmte Ursprungsidentität festlegen, wenn sie eine Rolle übernehmen. Beispielsweise können Sie verlangen, dass Ihre Mitarbeiter oder Verbundidentitäten einen Wert für die Quellidentität angeben. Sie können Ihren Identity Provider (IdP) so konfigurieren, dass eines der Attribute verwendet wird, die Ihren Benutzern zugeordnet sind, z. B. ein Benutzername oder eine E-Mail als Quellidentität. Der IdP übergibt dann die Quellenidentität als Attribut in den Assertions oder Claims, die er an sendet AWS. Der Wert des Quellidentitätsattributs identifiziert den Benutzer oder die Anwendung, der die Rolle übernimmt.

Nachdem der Benutzer die Rolle übernommen hat, erscheint die Aktivität in den AWS CloudTrail-Protokollen mit dem eingestellten Wert der Quellidentität. Auf diese Weise können Administratoren leichter feststellen, welcher Benutzer eine bestimmte Aktion in ausgeführt hat AWS. Sie müssen für die Aktion sts:SetSourceIdentity die Berechtigung erteilen, dass eine Identität eine Quellidentität festlegen kann.

Im Gegensatz zu sts:RoleSessionName, nachdem die Quellidentität festgelegt wurde, kann der Wert nicht geändert werden. Es ist im Anforderungskontext für alle Aktionen vorhanden, die mit der Rolle von der Quellidentität durchgeführt werden. Wenn Sie die Sitzungsanmeldeinformationen verwenden, bleibt der Wert in nachfolgenden Rollensitzungen bestehen, um eine andere Rolle anzunehmen. Die Annahme einer Rolle von einer anderen wird als Rollenverkettung bezeichnet.

Sie können den globalen Bedingungsschlüssel aws:SourceIdentity verwenden, um den Zugriff auf AWS-Ressourcen auf der Grundlage des Werts der Quellidentität in nachfolgenden Anforderungen weiter zu kontrollieren.

Die folgende Rollenvertrauensrichtlinie erlaubt dem IAM-Benutzer AdminUser, eine Rolle im Konto 111122223333 zu übernehmen. Sie erteilt dem AdminUser auch die Erlaubnis, eine Quellidentität zu setzen, solange die gesetzte Quellidentität DiegoRamirez ist.

JSON
{ "Version":"2012-10-17", "Statement": [ { "Sid": "AllowAdminUserAssumeRole", "Effect": "Allow", "Principal": {"AWS": " arn:aws:iam::111122223333:user/AdminUser"}, "Action": [ "sts:AssumeRole", "sts:SetSourceIdentity" ], "Condition": { "StringEquals": {"sts:SourceIdentity": "DiegoRamirez"} } } ] }

Weitere Informationen zur Verwendung von Quellidentitätsinformationen finden Sie unter Überwachen und Steuern von Aktionen mit übernommenen Rollen.

sts:TaskPolicyArn

Funktioniert mit ARN-Operatoren.

Verwenden Sie diesen Schlüssel, um die Richtlinien-ARN in einer Anfrage für sts:AssumeRoot mit der in der Richtlinie angegebenen Richtlinien-ARN zu vergleichen.

Verfügbarkeit – Dieser Schlüssel ist in der Anfrage vorhanden, wenn Sie eine Anfrage mit sts:AssumeRoot stellen.

Administratoren können diesen Bedingungsschlüssel in IAM-Richtlinien verwenden, um bestimmte Rollen oder Benutzer innerhalb des Verwaltungskontos oder des delegierten Administratorkontos daran zu hindern, bestimmte Aktionen auszuführen, wenn sie Root-Anmeldeinformationen annehmen. Weitere Informationen finden Sie unter Privilegierte Aufgabe in einem AWS Organizations-Mitgliedskonto ausführen.

sts:TransitiveTagKeys

Funktioniert mit Zeichenfolgenoperatoren.

Verwenden Sie diesen Schlüssel, um die transitiven Sitzungstag-Schlüssel in der Anforderung mit den in der Richtlinie angegebenen Schlüsseln zu vergleichen.

Verfügbarkeit – Dieser Schlüssel ist in der Anforderung vorhanden, wenn Sie eine Anforderung mit temporären Sicherheitsanmeldeinformationen stellen. Dazu gehören Anmeldeinformationen, die mit einer beliebigen assume-role-Operation oder der GetFederationToken-Operation erstellt wurden.

Wenn Sie eine Anforderung mit temporären Sicherheitsanmeldeinformationen erstellen, enthält der Anforderungskontext den aws:PrincipalTag-Kontextschlüssel. Dieser Schlüssel enthält eine Liste von Sitzungs-Tags, transitiven Sitzungs-Tags und Rollentags. Transitive Sitzungs-Tags sind Tags, die in allen nachfolgenden Sitzungen bestehen, wenn Sie die Sitzungsanmeldeinformationen verwenden, um eine andere Rolle anzunehmen. Die Annahme einer Rolle von einer anderen wird als Rollenverkettung bezeichnet.

Sie können diesen Bedingungsschlüssel in einer Richtlinie verwenden, um bestimmte Sitzungs-Tags als transitiv festzulegen, wenn Sie eine Rolle übernehmen oder einen Benutzer föderieren.