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 IAMRolle ist ein ObjektIAM, dem Berechtigungen zugewiesen wurden. Wenn Sie diese Rolle mithilfe einer IAM Identität oder einer Identität von außerhalb übernehmen 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 eine andere Rolle über das AWS CLI oder anzunehmen AWS API, was als Rollenverkettung 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.
-
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.
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.
Themen
- Einrichten für die Verwendung der Quellidentität
- Wissenswertes über die Quellidentität
- Zum Festlegen der Quellidentität erforderliche Berechtigungen
- Angeben einer Quellidentität bei der Übernahme einer Rolle
- Verwenden Sie die Quellidentität mit AssumeRole
- Verwendung der Quellidentität mit AssumeRoleWith SAML
- Quellidentität verwenden mit AssumeRoleWithWebIdentity
- Steuern des Zugriffs mithilfe von Informationen zur Quell
- Quellenidentität anzeigen in CloudTrail
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önnten Ihre IAM Benutzer mithilfe des AssumeRole
Vorgangs direkt Rollen übernehmen. Wenn Sie über Unternehmensidentitäten, auch Personalidentitäten genannt, verfügen, 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.
-
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.
-
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.
-
Überprüfung CloudTrail — Überprüfen Sie die Quellidentitätsinformationen für Ihre Testrollen in Ihren CloudTrail Protokollen.
-
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.
-
Konfigurieren von Produktionsrichtlinien – Konfigurieren Sie Ihre Richtlinien für Ihre Produktionsumgebung und fügen Sie sie dann Ihren Produktionsbenutzern und -rollen hinzu.
-
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 derAssumeRole*
-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 diests: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üsselaws:SourceIdentity
in der Anfrage vorhanden. AWS kontrolliert den Wert der Quellidentität weder in den Schlüsselnsts:SourceIdentity
nochaws: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:., + = @ -(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 Management Console die eine Quellidentität festgelegt werden muss, wenn die Rolle übernommen wird. Um eine solche Rolle anzunehmen, können Sie den AssumeRole
Vorgang mit AWS CLI oder AWS
API aufrufen und den Quellidentitätsparameter angeben.
Zum Festlegen der Quellidentität erforderliche Berechtigungen
Zusätzlich zu der Aktion, die dem API Vorgang entspricht, muss in Ihrer Richtlinie die folgende Aktion nur für Berechtigungen vorgesehen sein:
sts:SetSourceIdentity
-
Um eine Quellidentität angeben zu können, müssen Prinzipale (IAMBenutzer und Rollen) über die entsprechenden Berechtigungen verfügen.
sts:SetSourceIdentity
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 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. DerAssumeRole*
-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 diests: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 zu übernehmen.
Stellen Sie sich als Kontoadministrator vor, dass der IAM Benutzer DevUser
in Ihrem Konto davon ausgehen kann, dass es sich um dasselbe Konto handelt. Developer_Role
Sie möchten diese Aktion jedoch nur zulassen, wenn der Benutzer die Quellidentität auf seinen IAM Benutzernamen festgelegt hat. Sie können dem IAM Benutzer die folgende Richtlinie zuordnen.
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 die DevUser
Erlaubnis, die Rolle zu übernehmen und eine Quellidentität festzulegen. Der sts:SourceIdentity
-Bedingungsschlüssel definiert den zulässigen Wert der Quellenidentität.
Beispiel einer Rollenvertrauensrichtlinie für Quellidentität
{ "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 BenutzerDevUser
, DeveloperRole
mithilfe der folgenden AWS CLI Anfrage, dies anzunehmen.
Beispiel für AssumeRole CLI eine 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
vonDevUser
.
Angeben einer Quellidentität bei der Übernahme einer Rolle
Sie können eine Quellidentität angeben, wenn Sie einen der AWS STS
AssumeRole*
API Vorgänge verwenden, um temporäre Sicherheitsanmeldeinformationen für eine Rolle abzurufen. Der von Ihnen verwendete API Vorgang 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 den AssumeRoleWithWebIdentity
Vorgang 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.
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 Rollenanmeldedaten verwenden, um anzurufenAssumeRole
. 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.
Beispiel für AssumeRole CLI eine 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
Der Principal, der den AssumeRoleWithSAML
Vorgang aufruft, wird mithilfe eines SAML basierten Verbunds authentifiziert. Dieser Vorgang gibt einen Satz temporärer Anmeldeinformationen zurück, mit denen Sie auf AWS Ressourcen zugreifen können. Weitere Hinweise zur Verwendung eines SAML basierten Verbunds für den AWS Management Console Zugriff finden Sie unterAktivieren des Zugriffs von SAML 2.0-Verbundbenutzern auf AWS Management Console. Einzelheiten zu unserem AWS CLI AWS API Zugriff finden Sie unterSAML2.0-Föderation. Eine Anleitung zum Einrichten eines SAML Verbunds für Ihre Active Directory-Benutzer finden Sie unter AWS Verbundauthentifizierung mit Active Directory-Verbunddiensten (ADFS)
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:
Um ein SAML Attribut für die Quellenidentität festzulegen, schließen Sie das Attribute
Element ein, für das das Name
Attribut auf gesetzt ist. 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 dieses Attribut zu übergeben, nehmen Sie das folgende Element in Ihre SAML Assertion auf.
Beispielausschnitt einer Assertion SAML
<Attribute Name="https://aws.amazon.com/SAML/Attributes/SourceIdentity"> <AttributeValue>DiegoRamirez</AttributeValue> </Attribute>
Quellidentität verwenden mit AssumeRoleWithWebIdentity
Der Principal, der den AssumeRoleWithWebIdentity
Vorgang aufruft, wird mithilfe eines OpenID Connect (OIDC) -kompatiblen 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 Hinweise zur Verwendung eines OIDC Verbunds für den AWS Management Console
Zugriff finden Sie unter. OIDCföderation
Um die Quellidentität von OpenID Connect (OIDC) zu übergeben, müssen Sie die Quellidentität in das JSON Web-Token (JWT) aufnehmen. Fügen Sie Sitzungs-Tags in den https://aws.amazon.com/
-Namespace in dem Token ein, wenn Sie die AssumeRoleWithWebIdentity
-Anforderung senden. Weitere Informationen zu OIDC Token und Ansprüchen finden Sie unter Using Tokens with User Pools im Amazon Cognito
Developer Guide.
Bei dem folgenden dekodierten Token JWT handelt es sich beispielsweise um ein Token, das für Aufrufe AssumeRoleWithWebIdentity
mit der Admin
Quellidentität verwendet wird.
Beispiel für ein dekodiertes Web-Token JSON
{ "sub": "johndoe", "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: in der Anfrage enthalten. Nachdem eine Quellidentität festgelegt wurde, ist der SourceIdentity Schlüssel aws: 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 vonAssumeRoleWithSAML
. 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.
Beispiel für eine Rollenvertrauensrichtlinie für die Quellidentität () SAML
{ "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 einen OIDC Anbieter für den Verbund verwenden und Benutzer mit diesem authentifiziert sindAssumeRoleWithWebIdentity
, könnte Ihre Rollenvertrauensrichtlinie alternativ wie folgt aussehen.
Beispiel für eine Rollenvertrauensrichtlinie für die Quellidentität (OIDCAnbieter)
{ "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 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.
Beispiel für eine Berechtigungsrichtlinie für CriticalRole
{ "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ürCriticalRole
, um die Quellidentität festzulegen.
Beispiel für eine Vertrauensrichtlinie für eine Rolle auf CriticalRole _2
{ "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.
Beispiel für AssumeRole CLI eine 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 IAM und AWS STS API Anrufe mit AWS CloudTrail
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.
Beispiel requestParameters Beispielabschnitt in einem AWS CloudTrail Protokoll
"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.
Beispiel userIdentity für einen Schlüssel in einem AWS CloudTrail Protokoll
{ "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" } } }
AWS STS APIBeispielereignisse in CloudTrail Protokollen finden Sie unterIAMAPIBeispielereignisse im CloudTrail Protokoll. Weitere Informationen zu den in CloudTrail Protokolldateien enthaltenen Informationen finden Sie unter CloudTrail Event Reference im AWS CloudTrail Benutzerhandbuch.