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. # Überwachen und Steuern von Aktionen mit übernommenen Rollen Eine [IAM-Rolle](id_roles.md) ist ein Objekt in IAM, dem [Berechtigungen](access_policies.md) zugewiesen sind. Wenn Sie [diese Rolle mit einer IAM-Identität oder einer Identität von außerhalb übernehmen](id_roles_manage-assume.md) AWS, erhalten Sie eine Sitzung mit den Berechtigungen, die der Rolle zugewiesen sind. Wenn Sie Aktionen in ausführen AWS, können die Informationen über Ihre Sitzung protokolliert werden, AWS CloudTrail sodass Ihr Kontoadministrator sie überwachen kann. Administratoren können Rollen so konfigurieren, dass Identitäten eine benutzerdefinierte Zeichenfolge übergeben müssen, die die Person oder Anwendung identifiziert, die Aktionen in AWS durchführt. Diese Identitätsinformation wird als *Quellidentität* in AWS CloudTrail gespeichert. Wenn der Administrator die Aktivitäten in überprüft CloudTrail, kann er anhand der Informationen zur Quellenidentität feststellen, wer oder was Aktionen in Sitzungen mit angenommenen Rollen ausgeführt hat. Nachdem eine Quellidentität festgelegt wurde, ist sie in Anfragen für alle AWS Aktionen enthalten, die während der Rollensitzung ausgeführt wurden. Der festgelegte Wert bleibt bestehen, wenn eine Rolle verwendet wird, um über die AWS CLI AWS OR-API eine andere Rolle anzunehmen, was als [Rollenverkettung](id_roles.md#iam-term-role-chaining) bezeichnet wird. Der festgelegte Wert kann während der Rollensitzung nicht geändert werden. Administratoren können detaillierte Berechtigungen auf der Grundlage des Vorhandenseins oder des Werts der Quellidentität konfigurieren, um die AWS Aktionen, die mit gemeinsam genutzten Rollen ausgeführt werden, weiter zu kontrollieren. Sie können entscheiden, ob das Quellidentitätsattribut verwendet werden kann, ob es erforderlich ist und welcher Wert verwendet werden kann. Die Art und Weise, wie Sie die Quellidentität verwenden, unterscheidet sich von Rollensitzungsnamen und Sitzungs-Tags auf wichtige Weise. Der Quellidentitätswert kann nicht geändert werden, nachdem er festgelegt wurde, und er bleibt für alle zusätzlichen Aktionen bestehen, die mit der Rollensitzung ausgeführt werden. So können Sie Sitzungs-Tags und Rollensitzungsnamen verwenden: + **Sitzungs-Tags** – Sie können Sitzungs-Tags übergeben, wenn Sie eine Rolle übernehmen oder einen Benutzer föderieren. Sitzungs-Tags sind vorhanden, wenn eine Rolle angenommen wird. Sie können Richtlinien definieren, die Tag-Bedingungsschlüssel verwenden, um Ihren Auftraggeber basierend auf ihren Tags Berechtigungen zu erteilen. Anschließend können Sie die Anfragen CloudTrail zur Übernahme von Rollen oder zur Zusammenführung von Benutzern anzeigen. Weitere Informationen zu Sitzungs-Tags finden Sie unter [Sitzungs-Tags übergeben AWS STS](id_session-tags.md). + **Rollensitzungsname** – Sie können den `sts:RoleSessionName`-Bedingungsschlüssel in einer Rollenvertrauensrichtlinie verwenden, um zu verlangen, dass Ihre Benutzer einen bestimmten Sitzungsnamen angeben, wenn sie eine Rolle übernehmen. Rollensitzungsname kann verwendet werden, um Rollensitzungen zu unterscheiden, wenn eine Rolle von verschiedenen Auftraggeber verwendet wird. Weitere Informationen zum Namen der Rollensitzung finden Sie unter [sts: RoleSessionName](reference_policies_iam-condition-keys.md#ck_rolesessionname). Es wird empfohlen, die Quellidentität zu verwenden, wenn Sie die Identität steuern möchten, die eine Rolle übernimmt. Die Quellenidentität ist auch nützlich für das CloudTrail Miningprotokoll, um festzustellen, wer die Rolle zur Ausführung von Aktionen verwendet hat. **Topics** + [Einrichten für die Verwendung der Quellidentität](#id_credentials_temp_control-access_monitor-setup) + [Wissenswertes über die Quellidentität](#id_credentials_temp_control-access_monitor-know) + [Zum Festlegen der Quellidentität erforderliche Berechtigungen](#id_credentials_temp_control-access_monitor-perms) + [Angeben einer Quellidentität bei der Übernahme einer Rolle](#id_credentials_temp_control-access_monitor-specify-sourceid) + [Verwenden Sie die Quellidentität mit AssumeRole](#id_credentials_temp_control-access_monitor-assume-role) + [Verwendung der Quellidentität mit AssumeRoleWith SAML](#id_credentials_temp_control-access_monitor-assume-role-saml) + [Verwenden Sie die Quellidentität mit AssumeRoleWithWebIdentity](#id_credentials_temp_control-access_monitor-assume-role-web-id) + [Steuern des Zugriffs mithilfe von Informationen zur Quell](#id_credentials_temp_control-access_monitor-control-access) + [Quellenidentität anzeigen in CloudTrail](#id_credentials_temp_control-access_monitor-ct) ## Einrichten für die Verwendung der Quellidentität Die Art und Weise, wie Sie die Quellidentität verwenden, hängt von der Methode ab, die verwendet wird, wenn Ihre Rollen angenommen werden. Beispielsweise können Ihre IAM-Benutzer Rollen direkt übernehmen, indem sie die `AssumeRole` verwenden. Wenn Sie über Unternehmensidentitäten verfügen, die auch als Personalidentitäten bezeichnet werden, greifen diese möglicherweise mithilfe von auf Ihre AWS Ressourcen zu. `AssumeRoleWithSAML` Wenn Endbenutzer auf Ihre mobilen oder Webanwendungen zugreifen, tun sie dies möglicherweise über `AssumeRoleWithWebIdentity`. Im Folgenden finden Sie einen Überblick über den Workflow auf hoher Ebene, mit dem Sie verstehen, wie Sie die Verwendung von Quellidentitätsinformationen in Ihrer vorhandenen Umgebung einrichten können. 1. **Konfigurieren von Testbenutzern und -rollen** – Konfigurieren Sie mithilfe einer Vorproduktionsumgebung Testbenutzer und -rollen und konfigurieren Sie ihre Richtlinien so, dass eine Quellidentität festgelegt werden kann. Wenn Sie einen Identitätsanbieter (IdP) für Ihre Verbundidentitäten verwenden, konfigurieren Sie Ihren IdP so, dass ein Benutzerattribut Ihrer Wahl für die Quellidentität in der Assertion oder Token übergeben wird. 1. **Nehmen Sie die Rolle an.** – Testen Sie das Annehmen von Rollen und Übergeben einer Quellidentität mit den Benutzern und Rollen, die Sie zum Testen eingerichtet haben. 1. **Überprüfung CloudTrail** — Überprüfen Sie die Quellidentitätsinformationen für Ihre Testrollen in Ihren CloudTrail Protokollen. 1. **Trainieren von Benutzern** – Stellen Sie nach dem Test in Ihrer Vorproduktionsumgebung sicher, dass Ihre Benutzer wissen, wie sie die Quellidentitätsinformationen eingeben, falls erforderlich. Legen Sie einen Stichtag fest, an dem Ihre Benutzer eine Quellidentität in Ihrer Produktionsumgebung angeben müssen. 1. **Konfigurieren von Produktionsrichtlinien** – Konfigurieren Sie Ihre Richtlinien für Ihre Produktionsumgebung und fügen Sie sie dann Ihren Produktionsbenutzern und -rollen hinzu. 1. **Aktivität überwachen** — Überwachen Sie die Aktivitäten Ihrer Produktionsrollen mithilfe von CloudTrail Protokollen. ## Wissenswertes über die Quellidentität Beachten Sie bei der Arbeit mit der Quellenidentität folgende Punkte. + Bei der Verwendung von Sitzungs-Tags müssen die Rollenvertrauensrichtlinien für alle Rollen, die mit einem Identitätsanbieter (IdP) verbunden sind, über die `sts:SetSourceIdentity`-Berechtigung verfügen. Bei Rollen, die diese Berechtigung in der Vertrauensrichtlinie nicht haben, schlägt der `AssumeRole*`-Vorgang fehl. Wenn Sie die Vertrauensrichtlinie für Rollen nicht für jede Rolle aktualisieren möchten, können Sie eine separate IdP-Instance zum Übergeben von Sitzungs-Tags verwenden. Fügen Sie dann die `sts:SetSourceIdentity`-Berechtigung nur den Rollen hinzu, die mit dem separaten IdP verbunden sind. + Wenn eine Identität eine Quellidentität festlegt, wird die `sts:SourceIdentity`-Schlüssel in der Anforderung. Für nachfolgende Aktionen, die während der Rollensitzung ausgeführt werden, ist der Schlüssel `aws:SourceIdentity` in der Anfrage vorhanden. AWS kontrolliert den Wert der Quellidentität weder in den Schlüsseln `sts:SourceIdentity` noch `aws:SourceIdentity`. Wenn Sie eine Quellidentität benötigen, müssen Sie ein Attribut auswählen, das Ihre Benutzer oder IdP bereitstellen sollen. Aus Sicherheitsgründen müssen Sie sicherstellen, dass Sie steuern können, wie diese Werte bereitgestellt werden. + Der Wert der Quell-Identität muss zwischen 2 und 64 Zeichen lang sein und darf nur alphanumerische Zeichen, Unterstriche und die folgenden Zeichen enthalten:**., \$1 = @ -**(Bindestrich). Sie können keinen Tag-Schlüssel oder -Wert erstellen, der mit dem Text **aws:** beginnt. Dieses Präfix ist für den AWS internen Gebrauch reserviert. + Die Quellidentitätsinformationen werden nicht erfasst, CloudTrail wenn ein AWS Dienst oder eine dienstbezogene Rolle eine Aktion im Namen einer föderierten Identität oder einer Belegschaftsidentität ausführt. **Wichtig** Sie können nicht zu einer Rolle in der wechseln, für AWS-Managementkonsole die eine Quellidentität festgelegt werden muss, wenn die Rolle übernommen wird. Um eine solche Rolle anzunehmen, können Sie die AWS CLI AWS OR-API verwenden, um den `AssumeRole` Vorgang aufzurufen und den Quellidentitätsparameter anzugeben. ## Zum Festlegen der Quellidentität erforderliche Berechtigungen Zusätzlich zu der Aktion, die der API-Operation entspricht, muss in Ihrer Richtlinie die folgende reine Berechtigungsaktion enthalten sein: ``` sts:SetSourceIdentity ``` + Um eine Quellidentität anzugeben, müssen Auftraggeber (IAM-Benutzer und IAM-Rollen) über Berechtigungen für `sts:SetSourceIdentity` haben. Als Administrator können Sie dies in der Rollenvertrauensrichtlinie und in der Berechtigungsrichtlinie des Auftraggebers konfigurieren. + Wenn Sie eine Rolle mit einer anderen Rolle übernehmen, was als [Rollenverkettung](id_roles.md#iam-term-role-chaining) bezeichnet wird, sind Berechtigungen für `sts:SetSourceIdentity` sowohl in der Berechtigungsrichtlinie des Auftraggebers, der die Rolle übernimmt, als auch in der Rollenvertrauensrichtlinie der Zielrolle erforderlich. Andernfalls schlägt die Operation fehl. + Bei der Verwendung von Sitzungs-Tags müssen die Rollenvertrauensrichtlinien für alle Rollen, die mit einem Identitätsanbieter (IdP) verbunden sind, über die `sts:SetSourceIdentity`-Berechtigung verfügen. Der `AssumeRole*`-Vorgang schlägt für jede Rolle fehl, die mit einem IdP verbunden ist, der Sitzungs-Tags ohne diese Berechtigung übergibt. Wenn Sie die Vertrauensrichtlinie für Rollen nicht für jede Rolle aktualisieren möchten, können Sie eine separate IdP Instance zum Übergeben der Quell-Identität verwenden und die `sts:SetSourceIdentity`-Berechtigung nur die Rollen, die mit dem separaten IdP verbunden sind. + Um eine Quellidentität über Kontogrenzen hinweg festzulegen, müssen Sie die Berechtigung `sts:SetSourceIdentity` an zwei Stellen einfügen. Sie muss sich in der Berechtigungsrichtlinie des Auftraggebers im Ursprungskonto und in der Rollenvertrauensrichtlinie der Rolle im Zielkonto befinden. Dies kann z. B. erforderlich sein, wenn eine Rolle verwendet wird, um eine Rolle in einem anderen Konto mit [Rollenverkettung](id_roles.md#iam-term-role-chaining) zu übernehmen. Stellen Sie sich als Kontoadministrator vor, Sie möchten den IAM-Benutzer `DevUser` in Ihrem Konto, um die `Developer_Role` auf demselben Konto zu übernehmen. Sie möchten diese Aktion jedoch nur zulassen, wenn der Benutzer die Quellidentität auf seinen IAM-Benutzernamen festgelegt hat. Sie können dazu diesem Benutzer die folgende IAM-Richtlinie zuweisen. **Example Beispiel für eine identitätsbasierte Richtlinie, die angehängt ist DevUser** **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AssumeRole", "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::123456789012:role/Developer_Role" }, { "Sid": "SetAwsUserNameAsSourceIdentity", "Effect": "Allow", "Action": "sts:SetSourceIdentity", "Resource": "arn:aws:iam::123456789012:role/Developer_Role", "Condition": { "StringLike": { "sts:SourceIdentity": "${aws:username}" } } } ] } ``` Um die zulässigen Werte für die Quellidentität zu erzwingen, können Sie die folgende Rollenvertrauensrichtlinie konfigurieren. Die Richtlinie gibt dem IAM-Benutzer `DevUser` die Berechtigung, die Rolle zu übernehmen und eine Quellidentität festzulegen. Der `sts:SourceIdentity`-Bedingungsschlüssel definiert den zulässigen Wert der Quellenidentität. **Example Beispiel einer Rollenvertrauensrichtlinie für Quellidentität** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowDevUserAssumeRole", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:user/DevUser" }, "Action": [ "sts:AssumeRole", "sts:SetSourceIdentity" ], "Condition": { "StringEquals": { "sts:SourceIdentity": "DevUser" } } } ] } ``` ------ Unter Verwendung der Anmeldeinformationen für den IAM-Benutzer versucht der Benutzer anzunehmen`DevUser`, dass er die folgende Anfrage `DeveloperRole` verwendet. AWS CLI **Example Beispiel für eine AssumeRole CLI-Anfrage** ``` aws sts assume-role \ --role-arn arn:aws:iam::123456789012:role/Developer_Role \ --role-session-name Dev-project \ --source-identity DevUser \ ``` Bei der AWS Auswertung der Anfrage enthält der Anforderungskontext das `sts:SourceIdentity` of`DevUser`. ## Angeben einer Quellidentität bei der Übernahme einer Rolle Sie können eine Quellidentität angeben, wenn Sie eine der AWS STS `AssumeRole*` API-Operationen verwenden, um temporäre Sicherheitsanmeldeinformationen für eine Rolle abzurufen. Die API-Operation, die Sie verwenden, unterscheidet sich je nach Anwendungsfall. Wenn Sie beispielsweise IAM-Rollen verwenden, um IAM-Benutzern Zugriff auf AWS Ressourcen zu gewähren, auf die sie normalerweise keinen Zugriff haben, können Sie den `AssumeRole` Vorgang verwenden. Wenn Sie zur Verwaltung Ihrer Mitarbeiter den Identitätsverbund verwenden, können Sie den Vorgang `AssumeRoleWithSAML` verwenden. Wenn Sie den OIDC-Verbund verwenden, um Endbenutzern den Zugriff auf Ihre Mobil- oder Webanwendungen zu ermöglichen, können Sie diese `AssumeRoleWithWebIdentity`-Operation verwenden. In den folgenden Abschnitten wird die Verwendung von Quellidentitäten bei jedem Vorgang erläutert. Weitere Informationen über häufige Szenarien für temporäre Berechtigungsnachweise finden Sie unter [Gängige Szenarien für temporäre Anmeldeinformationen](id_credentials_temp.md#sts-introduction). ## Verwenden Sie die Quellidentität mit AssumeRole Der `AssumeRole` Vorgang gibt einen Satz temporärer Anmeldeinformationen zurück, mit denen Sie auf AWS Ressourcen zugreifen können. Sie können IAM-Benutzer- oder Rollenanmeldeinformationen verwenden, um `AssumeRole` aufzurufen. Verwenden Sie die `-–source-identity` AWS CLI Option oder den `SourceIdentity` AWS API-Parameter, um bei der Übernahme einer Rolle die Quellenidentität zu übergeben. Das folgende Beispiel zeigt, wie die Quellidentität mit der AWS CLI angegeben werden kann. **Example Beispiel für eine AssumeRole CLI-Anfrage** ``` aws sts assume-role \ --role-arn arn:aws:iam::123456789012:role/developer \ --role-session-name Audit \ --source-identity Admin \ ``` ## Verwendung der Quellidentität mit AssumeRoleWith SAML Die `AssumeRoleWithSAML`-Operation wird mit dem SAML-basierten Verbund authentifiziert. Dieser Vorgang gibt einen Satz temporärer Anmeldeinformationen zurück, mit denen Sie auf AWS Ressourcen zugreifen können. Weitere Informationen zur Verwendung eines SAML-basierten Verbunds für den AWS-Managementkonsole Zugriff finden Sie unter. [Aktivieren des Zugriffs von SAML 2.0-Verbundprinzipalen auf AWS-Managementkonsole](id_roles_providers_enable-console-saml.md) Einzelheiten zu AWS CLI unserem AWS API-Zugriff finden Sie unter. [SAML 2.0-Föderation](id_roles_providers_saml.md) Eine Anleitung zur Einrichtung eines SAML-Verbunds für Ihre Active Directory-Benutzer finden Sie unter [AWS Verbundauthentifizierung mit Active Directory Federation Services (ADFS) im AWS Sicherheitsblog](https://aws.amazon.com/blogs/security/aws-federated-authentication-with-active-directory-federation-services-ad-fs/). Als Administrator können Sie es Mitgliedern Ihres Unternehmensverzeichnisses ermöglichen, den Vorgang gemeinsam zu AWS nutzen. AWS STS `AssumeRoleWithSAML` Hierfür müssen Sie die folgenden Aufgaben ausführen: 1. [Konfigurieren Sie einen SAML-Anbieter in Ihrer Organisation.](id_roles_providers_saml_3rd-party.md) 1. [Erstellen eines SAML-Anbieters in IAM](id_roles_providers_create_saml.md). 1. [Konfigurieren Sie eine Rolle und ihre Berechtigungen AWS für Ihre SAML-Verbundprinzipale](id_roles_create_for-idp_saml.md). 1. [Abschließen der Konfiguration des SAML-Identitätsanbieters und Erstellen von Zusicherungen für die SAML-Authentifizierungsantwort](id_roles_providers_create_saml_assertions.md). Um ein SAML-Attribut für die Quellidentität festzulegen, schließen Sie das `Attribute`-Element mit dem `Name`-Attribut gesetzt auf `https://aws.amazon.com/SAML/Attributes/SourceIdentity`. Verwenden Sie das `AttributeValue`-Element, um den Wert der Quellidentität anzugeben. Angenommen, Sie möchten die folgenden Identitätsattribute als Sitzungs-Tags übergeben. `SourceIdentity:DiegoRamirez` Um diese Attribute zu übergeben, schließen Sie die folgenden Elemente in Ihre SAML-Zusicherung ein. **Example Beispielausschnitt einer SAML-Zusicherung** ``` DiegoRamirez ``` ## Verwenden Sie die Quellidentität mit AssumeRoleWithWebIdentity Der Aufruf der `AssumeRoleWithWebIdentity`-Operation durch den Prinzipal wird mithilfe eines OpenID Connect (OIDC)-konformen Verbunds authentifiziert. Diese Operation gibt einen Satz temporärer Anmeldeinformationen zurück, die Sie für den Zugriff auf AWS -Ressourcen verwenden können. Weitere Informationen zur Verwendung des OIDC-Verbundes für den AWS-Managementkonsole -Zugriff finden Sie unter [OIDC-Verbund](id_roles_providers_oidc.md). Um die Quellidentität von OpenID Connect (OIDC) zu übergeben, müssen Sie die Quellidentität in das JSON Web Token (JWT) einbeziehen. Fügen Sie Sitzungs-Tags in den `[https://aws.amazon.com/](https://aws.amazon.com/)source_identity`-Namespace in dem Token ein, wenn Sie die `AssumeRoleWithWebIdentity`-Anforderung senden. Weitere Informationen zu OIDC-Token und Ansprüchen finden Sie unter [Verwenden von Token mit Benutzerpools](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html) im *Amazon Cognito Developer Guide*. Der folgende entschlüsselte JWT ist beispielsweise ein Token, das zum Aufrufen von `AssumeRoleWithWebIdentity` mit der Quellidentität `Admin` verwendet wird. **Example Beispiel für ein dekodiertes JSON-Web-Token** ``` { "sub": "john", "aud": "ac_oic_client", "jti": "ZYUCeRMQVtqHypVPWAN3VB", "iss": "https://xyz.com", "iat": 1566583294, "exp": 1566583354, "auth_time": 1566583292, "https://aws.amazon.com/source_identity":"Admin" } ``` ## Steuern des Zugriffs mithilfe von Informationen zur Quell Wenn eine Quellidentität anfänglich festgelegt wird, ist der SourceIdentity Schlüssel [sts:](reference_policies_iam-condition-keys.md#ck_sourceidentity) in der Anfrage enthalten. Nachdem eine Quellidentität festgelegt wurde, ist der SourceIdentity Schlüssel [aws:](reference_policies_condition-keys.md#condition-keys-sourceidentity) in allen nachfolgenden Anfragen vorhanden, die während der Rollensitzung gestellt wurden. Als Administrator können Sie Richtlinien schreiben, die eine bedingte Autorisierung zur Ausführung von AWS Aktionen gewähren, die auf der Existenz oder dem Wert des Quellidentitätsattributs basieren. Stellen Sie sich vor, Sie möchten von Ihren Entwicklern verlangen, dass sie eine Quellidentität festlegen, damit sie eine wichtige Rolle übernehmen können, die über Schreibberechtigungen für eine produktionskritische AWS Ressource verfügt. Stellen Sie sich außerdem vor, Sie gewähren AWS Zugriff auf die Identitäten Ihrer Belegschaft mithilfe von`AssumeRoleWithSAML`. Sie möchten nur, dass ältere Entwickler Saanvi und Diego Zugriff auf die Rolle haben. Daher erstellen Sie die folgende Vertrauensrichtlinie für die Rolle. **Example Beispiel einer Rollenvetrauensichtlinie für Quellidentität (SAML)** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "SAMLProviderAssumeRoleWithSAML", "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::111122223333:saml-provider/name-of-identity-provider" }, "Action": [ "sts:AssumeRoleWithSAML" ], "Condition": { "StringEquals": { "SAML:aud": "https://signin.aws.amazon.com/saml" } } }, { "Sid": "SetSourceIdentitySrEngs", "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::111122223333:saml-provider/name-of-identity-provider" }, "Action": [ "sts:SetSourceIdentity" ], "Condition": { "StringLike": { "sts:SourceIdentity": [ "Saanvi", "Diego" ] } } } ] } ``` ------ Die Vertrauensrichtlinie enthält eine Bedingung für `sts:SourceIdentity`, die eine Quellidentität erfordert, die auf Saanvi oder Diego eingestellt ist, um die kritische Rolle anzunehmen. Wenn Sie jedoch einen OIDC-Anbieter für den Verbund verwenden und Benutzer mit `AssumeRoleWithWebIdentity` authentifiziert werden, könnte Ihre Rollenvertrauensrichtlinie wie folgt aussehen. **Example Beispiel einer Rollenvetrauensichtlinie für Quellidentität (OIDC-Anbieter)** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::111122223333:oidc-provider/server.example.com" }, "Action": [ "sts:AssumeRoleWithWebIdentity", "sts:SetSourceIdentity" ], "Condition": { "StringEquals": { "server.example.com:aud": "oidc-audience-id" }, "StringLike": { "sts:SourceIdentity": [ "Saanvi", "Diego" ] } } } ] } ``` ------ ### Rollenverkettung und kontenübergreifende Anforderungen Stellen Sie sich vor, Sie möchten Benutzern, die `CriticalRole` angenommen haben, erlauben, ein `CriticalRole_2` in einem anderen Konto anzunehmen. Die Anmeldeinformationen für die Rollensitzung, die für die Annahme von `CriticalRole` erlangt wurden, werden für die [Rollenkette](id_roles.md#iam-term-role-chaining) einer zweiten Rolle, `CriticalRole_2`, in einem anderen Konto verwendet. Die Rolle wird über eine Kontengrenze hinweg übernommen. Daher muss die Berechtigung `sts:SetSourceIdentity` sowohl in der Berechtigungsrichtlinie für `CriticalRole` als auch in der Rollenvertrauensrichtlinie für `CriticalRole_2` erteilt werden. **Example Beispiel für eine Berechtigungsrichtlinie für CriticalRole** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AssumeRoleAndSetSourceIdentity", "Effect": "Allow", "Action": [ "sts:AssumeRole", "sts:SetSourceIdentity" ], "Resource": "arn:aws:iam::222222222222:role/CriticalRole_2" } ] } ``` ------ Um das Festlegen der Quellidentität über die Kontengrenze hinweg zu sichern, vertraut die folgende Rollenvertrauensrichtlinie nur dem Rollenauftraggeber für`CriticalRole`, um die Quellidentität festzulegen. **Example Beispiel für eine Vertrauensrichtlinie für eine Rolle auf CriticalRole \$12** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111111111111:role/CriticalRole" }, "Action": [ "sts:AssumeRole", "sts:SetSourceIdentity" ], "Condition": { "StringLike": { "aws:SourceIdentity": ["Saanvi","Diego"] } } } ] } ``` ------ Der Benutzer führt den folgenden Aufruf mit den Anmeldeinformationen für die Rollensitzung durch, die er bei der Annahme abgerufen hat CriticalRole. Die Quellidentität wurde während der Annahme von festgelegt CriticalRole, sodass sie nicht erneut explizit festgelegt werden muss. Wenn der Benutzer versucht, eine Quellidentität festzulegen, die sich von dem Wert unterscheidet, der bei der Übernahme von `CriticalRole` festgelegt wurde, wird die Anforderung der Rollenübernahme abgelehnt. **Example Beispiel für eine AssumeRole CLI-Anfrage** ``` aws sts assume-role \ --role-arn arn:aws:iam::222222222222:role/CriticalRole_2 \ --role-session-name Audit \ ``` Wenn der aufrufende Auftraggeber die Rolle übernimmt, bleibt die Quellidentität in der Anforderung ab der ersten angenommenen Rollensitzung bestehen. Daher sind sowohl der `aws:SourceIdentity`- als auch der `sts:SourceIdentity`-Schlüssel im Anfragekontext vorhanden. ## Quellenidentität anzeigen in CloudTrail Hier können Sie die Anfragen CloudTrail zur Übernahme von Rollen oder zur Zusammenführung von Benutzern anzeigen. Sie können auch die Rolle oder die Benutzeranfragen zur Durchführung von Aktionen in AWS einsehen. Die CloudTrail Protokolldatei enthält Informationen über die Quellidentität, die für die Sitzung mit übernommener Rolle oder Verbundbenutzer festgelegt wurde. Weitere Informationen finden Sie unter [Protokollierung von IAM- und AWS STS API-Aufrufen mit AWS CloudTrail](cloudtrail-integration.md). Gehen Sie beispielsweise davon aus, dass ein Benutzer eine AWS STS `AssumeRole` Anfrage stellt und eine Quellidentität festlegt. Sie finden die `sourceIdentity` Informationen im `requestParameters` Schlüssel in Ihrem CloudTrail Protokoll. **Example Beispiel für einen RequestParameter-Abschnitt in einem Protokoll AWS CloudTrail** ``` "eventVersion": "1.05", "userIdentity": { "type": "AWSAccount", "principalId": "AIDAJ45Q7YFFAREXAMPLE", "accountId": "111122223333" }, "eventTime": "2020-04-02T18:20:53Z", "eventSource": "sts.amazonaws.com", "eventName": "AssumeRole", "awsRegion": "us-east-1", "sourceIPAddress": "203.0.113.64", "userAgent": "aws-cli/1.16.96 Python/3.6.0 Windows/10 botocore/1.12.86", "requestParameters": { "roleArn": "arn:aws:iam::123456789012:role/DevRole", "roleSessionName": "Dev1", "sourceIdentity": "source-identity-value-set" } ``` Wenn der Benutzer die angenommene Rollensitzung verwendet, um eine Aktion auszuführen, sind die Informationen zur Quellidentität im `userIdentity` Schlüssel im CloudTrail Protokoll enthalten. **Example Beispiel für einen UserIdentity-Schlüssel in einem Protokoll AWS CloudTrail** ``` { "eventVersion": "1.08", "userIdentity": { "type": "AssumedRole", "principalId": "AROAJ45Q7YFFAREXAMPLE:Dev1", "arn": "arn:aws:sts::123456789012:assumed-role/DevRole/Dev1", "accountId": "123456789012", "accessKeyId": "ASIAIOSFODNN7EXAMPLE", "sessionContext": { "sessionIssuer": { "type": "Role", "principalId": "AROAJ45Q7YFFAREXAMPLE", "arn": "arn:aws:iam::123456789012:role/DevRole", "accountId": "123456789012", "userName": "DevRole" }, "webIdFederationData": {}, "attributes": { "mfaAuthenticated": "false", "creationDate": "2021-02-21T23:46:28Z" }, "sourceIdentity": "source-identity-value-present" } } } ``` Beispiele für AWS STS API-Ereignisse in CloudTrail Protokollen finden Sie unter. [Beispiel für IAM-API-Ereignisse im Protokoll CloudTrail](cloudtrail-integration.md#cloudtrail-integration_examples-iam-api) Weitere Informationen zu den in CloudTrail Protokolldateien enthaltenen Informationen finden Sie unter [CloudTrail Event Reference](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/eventreference.html) im *AWS CloudTrail Benutzerhandbuch*.