Protokollieren von IAM- und AWS STS-API-Aufrufen mit AWS CloudTrail - AWS Identity and Access Management

Protokollieren von IAM- und AWS STS-API-Aufrufen mit AWS CloudTrail

IAM und AWS STS sind mit AWS CloudTrail integriert, einem Dienst, der eine Aufzeichnung der von einem IAM-Benutzer oder einer IAM-Rolle durchgeführten Aktionen liefert. CloudTrail erfasst alle API-Aufrufe für IAM und AWS STS als Ereignisse, einschließlich Aufrufen von der Konsole und von API-Aufrufen. Wenn Sie einen Trail erstellen, können Sie die kontinuierliche Bereitstellung von CloudTrail-Ereignissen an einen Amazon S3-Bucket aktivieren. Wenn Sie keinen Trail konfigurieren, können Sie die neuesten Ereignisse in der CloudTrail-Konsole trotzdem in Ereignisverlauf anzeigen. Sie können CloudTrail verwenden, um Informationen über die Anforderung an IAM oder zu erhalten AWS STS. So können Sie beispielsweise die IP-Adresse, von der aus die Anforderung gestellt wurde, wer die Anforderung gestellt hat, wann sie gestellt wurde und weitere Details einsehen.

Weitere Informationen zu CloudTrail finden Sie im AWS CloudTrail-Leitfaden.

IAM- und AWS STS-Informationen in CloudTrail

CloudTrail wird beim Erstellen Ihres AWS-Konto für Sie aktiviert. Wenn eine Aktivität in IAM oder AWS STS auftritt, wird diese Aktivität in einem CloudTrail-Ereignis zusammen mit anderen AWS-Service-Ereignissen im Ereignisverlauf aufgezeichnet. Sie können in Ihrem AWS-Konto die neusten Ereignisse anzeigen, suchen und herunterladen. Weitere Informationen finden Sie unter Anzeigen von Ereignissen mit dem CloudTrail-Ereignisverlauf.

Für eine fortlaufende Aufzeichnung der Ereignisse in Ihrem AWS-Konto, einschließlich der Ereignisse für IAM und AWS STS, erstellen Sie einen Trail. Ein Trail ermöglicht es CloudTrail, Protokolldateien in einem Amazon-S3-Bucket bereitzustellen. Wenn Sie einen Trail in der Konsole anlegen, gilt dieser für alle Regionen. Der Trail protokolliert Ereignisse aus allen Regionen in der AWS-Partition und stellt die Protokolldateien in dem von Ihnen angegebenen Amazon-S3-Bucket bereit. Darüber hinaus können Sie andere AWS-Services konfigurieren, um die in den CloudTrail-Protokollen erfassten Ereignisdaten weiter zu analysieren und entsprechend zu agieren. Weitere Informationen finden Sie unter:

Alle IAM- und AWS STS-Aktionen werden von CloudTrail protokolliert und sind in der IAM-API-Referenz und der AWS Security Token Service-API-Referenz dokumentiert.

Protokollieren von IAM- und AWS STS-API-Anforderungen

CloudTrail protokolliert alle authentifizierten API-Anfragen an IAM und AWS STS-API-Operationen. Außerdem protokolliert CloudTrail nicht authentifizierte Anforderungen für die AWS STS-Aktionen AssumeRoleWithSAML und AssumeRoleWithWebIdentity und speichert die vom Identitätsanbieter bereitgestellten Informationen. Allerdings werden einige nicht authentifizierte AWS STS-Anfragen möglicherweise nicht protokolliert, da sie nicht die Mindestanforderungen erfüllen und nicht ausreichend gültig sind, um als legitime Anfrage eingestuft zu werden. Bei kontoübergreifenden Anfragen zu Rollenübernahmen protokolliert CloudTrail abgelehnte AWS STS-Anfragen nicht im CloudTrail des Zielkontos.

Sie können die protokollierten Informationen verwenden, um Anrufe, die von einem OIDC- oder SAML-Verbundprinzipal mit einer angenommenen Rolle getätigt wurden, dem ursprünglichen externen Verbundanrufer zuzuordnen. Für die Aktion AssumeRole können Sie Aufrufe dem ursprünglichen AWS-Service oder dem Konto des Ursprungsbenutzers zuordnen. Der userIdentity-Abschnitt der JSON-Daten im CloudTrail-Protokolleintrag enthält die Informationen, die Sie benötigen, um die AssumeRole*-Anfrage einem bestimmten Sitzungsprinzipal zuzuordnen. Weitere Informationen finden Sie unter CloudTrail-userIdentity-Element im AWS CloudTrail-Benutzerhandbuch.

AWS CloudTrail-Protokolle enthalten MFA-Informationen, wenn sich der IAM-Benutzer mit MFA anmeldet. Wenn der IAM-Benutzer eine IAM-Rolle annimmt, protokolliert CloudTrail auch mfaAuthenticated: true in den sessionContext-Attributen für Aktionen, die mit der angenommenen Rolle ausgeführt wurden. Die CloudTrail-Protokollierung unterscheidet sich jedoch von den Anforderungen von IAM, wenn API-Aufrufe mit den Anmeldeinformationen der angenommenen Rolle getätigt werden. Weitere Informationen finden Sie unter CloudTrail „userIdentity“-Element.

Aufrufe der IAM-API-Operationen CreateUser, DeleteRole, ListGroups und andere API-Vorgänge werden alle von CloudTrail protokolliert.

Beispiele für solche Protokolleinträge finden Sie weiter hinten in diesem Thema.

Protokollieren von API-Anforderungen an andere AWS-Services

Authentifizierte Anforderungen an andere API-Vorgänge des AWS-Dienstes werden von CloudTrail protokolliert, und diese Protokolleinträge enthalten Informationen darüber, wer die Anforderung generiert hat.

Angenommen, Sie haben eine Anforderung gestellt, um Amazon Amazon EC2-Instances aufzulisten oder eine AWS CodeDeploy-Bereitstellungsgruppe zu erstellen. Details über die Person oder Dienstleistung, die die Anforderung gestellt hat, sind im Protokolleintrag dieser Anforderung enthalten. Diese Informationen helfen Ihnen festzustellen, ob die Anforderung vom Root-Benutzer des AWS-Kontos, einem IAM-Benutzer, einer Rolle oder einem anderen AWS-Service gestellt wurde.

Weitere Einzelheiten zu den Benutzeridentitätsinformationen in CloudTrail-Protokolleinträgen finden Sie unter userIdentity-Element im AWS CloudTrailBenutzerhandbuch.

Protokollieren von Benutzeranmeldeereignissen

CloudTrail protokolliert Anmeldeereignisse für die AWS-Managementkonsole, die AWS-Diskussionsforen und AWS Marketplace. CloudTrail protokolliert erfolgreiche und fehlgeschlagene Anmeldeversuche von IAM-Benutzern, SAML- und OIDC-Verbundprinzipalen und AWS STS-Verbundbenutzerprinzipalen.

Informationen zum Anzeigen von CloudTrail-Beispielereignissen für erfolgreiche und erfolglose Stammbenutzeranmeldungen finden Sie unter Beispiel für Ereignisdatensätze für Stammbenutzer im AWS CloudTrail-Leitfaden.

Aus Sicherheitsgründen protokolliert AWS den eingegebenen IAM-Benutzernamen nicht, wenn die Anmeldung aufgrund eines falschen Benutzernamens fehlschlägt. Der Benutzername wird durch den Wert HIDDEN_DUE_TO_SECURITY_REASONS maskiert. Ein Beispiel hierzu finden Sie unter Beispiel für eine Anmeldung, die aufgrund eines falschen Benutzernamens fehlgeschlagen ist. an späterer Stelle in diesem Thema. Der Benutzername ist verdeckt, da solche Fehler oftmals von Benutzern begangen werden. Durch die Protokollierung dieser Fehler könnten potenziell sensible Informationen offengelegt werden. Zum Beispiel:

  • Sie haben versehentlich Ihr Passwort in das Feld „Benutzername“ eingegeben.

  • Sie wählen den Link für die Anmeldeseite eines AWS-Konto, geben dann aber die Kontonummer für ein anderes AWS-Konto ein.

  • Ein Benutzer hat vergessen, bei welchem Konto er sich gerade anmeldet, und gibt versehentlich den Kontonamen seines privaten E-Mail-Kontos, seine Bankkontonummer oder eine andere private ID ein.

Protokollieren von Anmeldeereignissen bei temporären Anmeldeinformationen

Wenn ein Auftraggeber temporäre Anmeldeinformationen anfordert, bestimmt der Auftraggebertyp, wie das Ereignis von CloudTrail protokolliert wird. Dies kann kompliziert sein, wenn ein Auftraggeber eine Rolle in einem anderen Konto annimmt. Es gibt mehrere API-Aufrufe, durch die Operationen im Zusammenhang mit kontoübergreifenden Rollenoperationen durchgeführt werden. Zuerst ruft der Auftraggeber eine AWS STS-API auf, um die temporären Anmeldeinformationen abzurufen. Diese Operation wird im aufrufenden Konto und in dem Konto protokolliert, in dem die AWS STS-Operation ausgeführt wird. Anschließend verwendet der Auftraggeber die Rolle, um andere API-Aufrufe im Konto der übernommenen Rolle auszuführen.

Sie können den sts:SourceIdentity-Bedingungsschlüssel in der Rollenvertrauensrichtlinie verwenden, damit Benutzer einen Sitzungsnamen angeben müssen, wenn sie eine Rolle übernehmen. Sie können beispielsweise verlangen, dass IAM-Benutzer ihren eigenen Benutzernamen als Sitzungsnamen angeben. Auf diese Weise können Sie feststellen, welcher Benutzer eine bestimmte Aktion in ausgeführt hat AWS. Weitere Informationen finden Sie unter sts:SourceIdentity. Sie können auch sts:RoleSessionName verwenden, um von den Benutzern zu verlangen, dass sie einen Sitzungsnamen angeben, wenn sie eine Rolle übernehmen. Dies kann Ihnen helfen, zwischen Rollensitzungen für eine Rolle zu unterscheiden, die von verschiedenen Auftraggebern verwendet wird, wenn Sie AWS CloudTrail-Protokolle überprüfen.

In der folgenden Tabelle wird gezeigt, wie CloudTrail unterschiedliche Informationen zu den Benutzeridentitäten für jede der AWS STS-APIs protokolliert, die temporäre Anmeldeinformationen generieren.

Auftraggebertyp STS-API Benutzeridentität im CloudTrail-Protokoll für das Konto des Aufrufers Benutzeridentität im CloudTrail-Protokoll für das Konto der übernommenen Rolle Benutzeridentität im CloudTrail-Protokoll für die nachfolgenden API-Aufrufe der Rolle
Root-Benutzer des AWS-Kontos-Anmeldeinformationen GetSessionToken Stammbenutzeridentität Die Rolle beinhaltendes Konto ist mit aufrufendem Konto identisch Stammbenutzeridentität
Root-Benutzer des AWS-Kontos-Anmeldeinformationen AssumeRoot Root-Benutzer-Sitzung Kontonummer und Prinzipal-ID (bei Benutzern) Root-Benutzer-Sitzung
IAM-Benutzer GetSessionToken IAM-Benutzeridentität Die Rolle beinhaltendes Konto ist mit aufrufendem Konto identisch IAM-Benutzeridentität
IAM-Benutzer GetFederationToken IAM-Benutzeridentität Die Rolle beinhaltendes Konto ist mit aufrufendem Konto identisch IAM-Benutzeridentität
IAM-Benutzer AssumeRole IAM-Benutzeridentität Kontonummer und Auftraggeber-ID (falls ein Benutzer) oder AWS-Dienstauftraggeber Nur Rollenidentität (kein Benutzer)
Extern authentifizierter Benutzer AssumeRoleWithSAML SAML-Benutzeridentität Nur Rollenidentität (kein Benutzer)
Extern authentifizierter Benutzer AssumeRoleWithWebIdentity OIDC/Web-Benutzeridentität Nur Rollenidentität (kein Benutzer)

CloudTrail betrachtet eine Aktion als schreibgeschützt, wenn sie keine verändernde Auswirkung auf eine Ressource hat. Beim Protokollieren eines schreibgeschützten Ereignisses redigiert CloudTrail die responseElements-Informationen im Protokoll. Wenn CloudTrail ein Ereignis protokolliert, das nicht schreibgeschützt ist, wird das vollständige responseElements im Protokolleintrag angezeigt. Für die AWS STS-APIs AssumeRole, AssumeRoleWithSAML und AssumeRoleWithWebIdentity gilt: Obwohl sie als schreibgeschützt protokolliert werden, nimmt CloudTrail das vollständige responseElements mit Ausnahme von secretAccessKey in das Protokoll für diese APIs auf.

In der folgenden Tabelle wird gezeigt, wie CloudTrail responseElements- und readOnly-Informationen für jede der AWS STS-APIs protokolliert, die temporäre Anmeldeinformationen generieren.

STS-API Informationen zu Antwortelementen Schreibgeschützt
AssumeRole Enthalten true
AssumeRoleWithSAML Enthalten true
AssumeRoleWithWebIdentity Enthalten true
AssumeRoot Enthalten false
GetFederationToken Enthalten false
GetSessionToken Enthalten false

Beispiel für IAM-API-Ereignisse im CloudTrail-Protokoll

CloudTrail-Protokolldateien enthalten Ereignisse im JSON-Format. Ein API-Ereignis stellt eine einzelne API-Anforderung dar und enthält Informationen zum Auftraggeber, der angeforderten Aktion, etwaigen Parametern und dem Datum und der Uhrzeit der Aktion.

Beispiel für ein IAM-API-Ereignis in der CloudTrail-Protokolldatei

Das folgende Beispiel zeigt einen CloudTrail-Protokolleintrag für eine Anforderung für die IAM GetUserPolicy--Aktion.

{ "eventVersion": "1.09", "userIdentity": { "type": "AssumedRole", "principalId": "AIDACKCEVSQ6C2EXAMPLE:Role-Session-Name", "arn": "arn:aws:sts::111122223333:assumed-role/Role-Name/Role-Session-Name", "accountId": "111122223333", "accessKeyId": "AKIAIOSFODNN7EXAMPLE", "sessionContext": { "sessionIssuer": { "type": "Role", "principalId": "AIDACKCEVSQ6C2EXAMPLE", "arn": "arn:aws:iam::111122223333:role/Admin", "accountId": "111122223333", "userName": "Admin" }, "attributes": { "creationDate": "2024-09-09T17:50:16Z", "mfaAuthenticated": "false" } } }, "eventTime": "2024-09-09T17:51:44Z", "eventSource": "iam.amazonaws.com", "eventName": "GetUserPolicy", "awsRegion": "us-east-1", "sourceIPAddress": "192.0.2.101", "userAgent": "aws-cli/1.16.96 Python/2.7.8 Linux/10 botocore/1.12.86", "requestParameters": { "userName": "ExampleIAMUserName", "policyName": "ExamplePoliccyName" }, "responseElements": null, "requestID": "9EXAMPLE-0c68-11e4-a24e-d5e16EXAMPLE", "eventID": "cEXAMPLE-127e-4632-980d-505a4EXAMPLE", "readOnly": true, "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "111122223333", "eventCategory": "Management", "tlsDetails": { "tlsVersion": "TLSv1.3", "cipherSuite": "TLS_AES_128_GCM_SHA256", "clientProvidedHostHeader": "iam.amazonaws.com" } }

Diesen Ereignisinformationen können Sie im Element ReadOnlyAccess-JaneDoe-201407151307 entnehmen, dass hier die Benutzerrichtlinie JaneDoe für den Benutzer requestParameters angefordert wurde. Außerdem können Sie sehen, dass die Anforderung von dem IAM-Benutzer JaneDoe am 15. Juli 2014 um 21:40 Uhr (UTC) gemacht wurde. In diesem Fall wurde die Anforderung von der AWS-Managementkonsole aus gesendet, wie Sie dem Element userAgent entnehmen können.

Beispiel–AWS STSAPI-Ereignisse im CloudTrail -Protokoll

CloudTrail-Protokolldateien enthalten Ereignisse im JSON-Format. Ein API-Ereignis stellt eine einzelne API-Anforderung dar und enthält Informationen zum Auftraggeber, der angeforderten Aktion, etwaigen Parametern und dem Datum und der Uhrzeit der Aktion.

Beispiel für kontoübergreifende AWS STS-API-Ereignisse in CloudTrail-Protokolldateien

Der IAM-Benutzer mit dem Namen John im Konto 777788889999 ruft die AWS STS-Aktion AssumeRole auf, um die Rolle EC2-dev im Konto 111122223333 zu übernehmen. Der Kontoadministrator verlangt, dass Benutzer eine Quellidentität festlegen, die ihrem Benutzernamen entspricht, wenn sie die Rolle übernehmen. Der Benutzer gibt den Wert der Quellidentität von John.

{ "eventVersion": "1.05", "userIdentity": { "type": "IAMUser", "principalId": "AIDAQRSTUVWXYZEXAMPLE", "arn": "arn:aws:iam::777788889999:user/John", "accountId": "777788889999", "accessKeyId": "AKIAIOSFODNN7EXAMPLE", "userName": "John" }, "eventTime": "2014-07-18T15:07:39Z", "eventSource": "sts.amazonaws.com", "eventName": "AssumeRole", "awsRegion": "us-east-2", "sourceIPAddress": "192.0.2.101", "userAgent": "aws-cli/1.11.10 Python/2.7.8 Linux/3.2.45-0.6.wd.865.49.315.metal1.x86_64 botocore/1.4.67", "requestParameters": { "roleArn": "arn:aws:iam::111122223333:role/EC2-dev", "roleSessionName": "John-EC2-dev", "sourceIdentity": "John", "serialNumber": "arn:aws:iam::777788889999:mfa" }, "responseElements": { "credentials": { "sessionToken": "<encoded session token blob>", "accessKeyId": "ASIAI44QH8DHBEXAMPLE", "expiration": "Jul 18, 2023, 4:07:39 PM" }, "assumedRoleUser": { "assumedRoleId": "AIDAQRSTUVWXYZEXAMPLE:John-EC2-dev", "arn": "arn:aws:sts::111122223333:assumed-role/EC2-dev/John-EC2-dev" }, "sourceIdentity": "John" }, "resources": [ { "ARN": "arn:aws:iam::111122223333:role/EC2-dev", "accountId": "111122223333", "type": "AWS::IAM::Role" } ], "requestID": "4EXAMPLE-0e8d-11e4-96e4-e55c0EXAMPLE", "sharedEventID": "bEXAMPLE-efea-4a70-b951-19a88EXAMPLE", "eventID": "dEXAMPLE-ac7f-466c-a608-4ac8dEXAMPLE", "eventType": "AwsApiCall", "recipientAccountId": "111122223333" }

Das zweite Beispiel zeigt den CloudTrail-Protokolleintrag des Kontos mit der angenommenen Rolle (111122223333) für dieselbe Anforderung.

{ "eventVersion": "1.05", "userIdentity": { "type": "AWSAccount", "principalId": "AIDAQRSTUVWXYZEXAMPLE", "accountId": "777788889999" }, "eventTime": "2014-07-18T15:07:39Z", "eventSource": "sts.amazonaws.com", "eventName": "AssumeRole", "awsRegion": "us-east-2", "sourceIPAddress": "192.0.2.101", "userAgent": "aws-cli/1.11.10 Python/2.7.8 Linux/3.2.45-0.6.wd.865.49.315.metal1.x86_64 botocore/1.4.67", "requestParameters": { "roleArn": "arn:aws:iam::111122223333:role/EC2-dev", "roleSessionName": "John-EC2-dev", "sourceIdentity": "John", "serialNumber": "arn:aws:iam::777788889999:mfa" }, "responseElements": { "credentials": { "sessionToken": "<encoded session token blob>", "accessKeyId": "ASIAI44QH8DHBEXAMPLE", "expiration": "Jul 18, 2014, 4:07:39 PM" }, "assumedRoleUser": { "assumedRoleId": "AIDAQRSTUVWXYZEXAMPLE:John-EC2-dev", "arn": "arn:aws:sts::111122223333:assumed-role/EC2-dev/John-EC2-dev" }, "sourceIdentity": "John" }, "requestID": "4EXAMPLE-0e8d-11e4-96e4-e55c0EXAMPLE", "sharedEventID": "bEXAMPLE-efea-4a70-b951-19a88EXAMPLE", "eventID": "dEXAMPLE-ac7f-466c-a608-4ac8dEXAMPLE" }

Beispiel für ein AWS STS-Rollenverkettungs-API-Ereignis in der CloudTrail-Protokolldatei

Das folgende Beispiel zeigt einen CloudTrail-Protokolleintrag für eine Anforderung, die von John Doe im Konto 111111111111 gestellt wurde. John verwendete zuvor seinen John-Benutzer, um die JohnRole1-Rolle zu übernehmen. Für diese Anforderung verwendet er die Anmeldeinformationen dieser Rolle, um die JohnRole2-Rolle zu übernehmen. Dies wird als Rollenverkettung bezeichnet. Die Quellidentität, die er bei der Übernahme der John1-Rolle festgelegt hat, bleibt bei der Anforderung, JohnRole2 zu übernehmen, bestehen. Wenn John versucht, bei der Übernahme der Rolle eine andere Quellidentität festzulegen, wird die Anforderung abgelehnt. John übergibt zwei Sitzungs-Tags in die Anforderung. Er setzt diese beiden Tags als transitiv fest. Die Anforderung übernimmt das Department-Tag als transitiv, weil John es als transitiv festgelegt hat, als JohnRole1 übernommen hat. Weitere Informationen zu Quellidentität finden Sie unter Überwachen und Steuern von Aktionen mit übernommenen Rollen. Weitere Hinweise zu transitiven Schlüsseln in Rollenketten finden Sie unter Verkettung von Rollen mit Sitzungs-Tags.

{ "eventVersion": "1.05", "userIdentity": { "type": "AssumedRole", "principalId": "AROAIN5ATK5U7KEXAMPLE:JohnRole1", "arn": "arn:aws:sts::111111111111:assumed-role/John/JohnRole1", "accountId": "111111111111", "accessKeyId": "ASIAIOSFODNN7EXAMPLE", "sessionContext": { "attributes": { "mfaAuthenticated": "false", "creationDate": "2019-10-02T21:50:54Z" }, "sessionIssuer": { "type": "Role", "principalId": "AROAIN5ATK5U7KEXAMPLE", "arn": "arn:aws:iam::111111111111:role/JohnRole1", "accountId": "111111111111", "userName": "John" }, "sourceIdentity": "John" } }, "eventTime": "2019-10-02T22:12:29Z", "eventSource": "sts.amazonaws.com", "eventName": "AssumeRole", "awsRegion": "us-east-2", "sourceIPAddress": "123.145.67.89", "userAgent": "aws-cli/1.16.248 Python/3.4.7 Linux/4.9.184-0.1.ac.235.83.329.metal1.x86_64 botocore/1.12.239", "requestParameters": { "incomingTransitiveTags": { "Department": "Engineering" }, "tags": [ { "value": "johndoe@example.com", "key": "Email" }, { "value": "12345", "key": "CostCenter" } ], "roleArn": "arn:aws:iam::111111111111:role/JohnRole2", "roleSessionName": "Role2WithTags", "sourceIdentity": "John", "transitiveTagKeys": [ "Email", "CostCenter" ], "durationSeconds": 3600 }, "responseElements": { "credentials": { "accessKeyId": "ASIAI44QH8DHBEXAMPLE", "expiration": "Oct 2, 2019, 11:12:29 PM", "sessionToken": "AgoJb3JpZ2luX2VjEB4aCXVzLXdlc3QtMSJHMEXAMPLETOKEN+//rJb8Lo30mFc5MlhFCEbubZvEj0wHB/mDMwIgSEe9gk/Zjr09tZV7F1HDTMhmEXAMPLETOKEN/iEJ/rkqngII9///////////ARABGgw0MjgzMDc4NjM5NjYiDLZjZFKwP4qxQG5sFCryASO4UPz5qE97wPPH1eLMvs7CgSDBSWfonmRTCfokm2FN1+hWUdQQH6adjbbrVLFL8c3jSsBhQ383AvxpwK5YRuDE1AI/+C+WKFZb701eiv9J5La2EXAMPLETOKEN/c7S5Iro1WUJ0q3Cxuo/8HUoSxVhQHM7zF7mWWLhXLEQ52ivL+F6q5dpXu4aTFedpMfnJa8JtkWwG9x1Axj0Ypy2ok8v5unpQGWych1vwdvj6ez1Dm8Xg1+qIzXILiEXAMPLETOKEN/vQGqu8H+nxp3kabcrtOvTFTvxX6vsc8OGwUfHhzAfYGEXAMPLETOKEN/L6v1yMM3B1OwFOrQBno1HEjf1oNI8RnQiMNFdUOtwYj7HUZIOCZmjfN8PPHq77N7GJl9lzvIZKQA0Owcjg+mc78zHCj8y0siY8C96paEXAMPLETOKEN/E3cpksxWdgs91HRzJWScjN2+r2LTGjYhyPqcmFzzo2mCE7mBNEXAMPLETOKEN/oJy+2o83YNW5tOiDmczgDzJZ4UKR84yGYOMfSnF4XcEJrDgAJ3OJFwmTcTQICAlSwLEXAMPLETOKEN" }, "assumedRoleUser": { "assumedRoleId": "AROAIFR7WHDTSOYQYHFUE:Role2WithTags", "arn": "arn:aws:sts::111111111111:assumed-role/test-role/Role2WithTags" }, "sourceIdentity": "John" }, "requestID": "b96b0e4e-e561-11e9-8b3f-7b396EXAMPLE", "eventID": "1917948f-3042-46ec-98e2-62865EXAMPLE", "resources": [ { "ARN": "arn:aws:iam::111111111111:role/JohnRole2", "accountId": "111111111111", "type": "AWS::IAM::Role" } ], "eventType": "AwsApiCall", "recipientAccountId": "111111111111" }

Beispiel für ein AWS-Service-AWS STS-API-Ereignis in der CloudTrail-Protokolldatei

Das folgende Beispiel zeigt einen CloudTrail-Protokolleintrag für eine Anforderung eines AWS-Dienstes, der eine andere Dienst-API unter Verwendung von Berechtigungen aus einer Servicerolle aufruft. Es zeigt den CloudTrail-Protokolleintrag für die Anforderung, die über das Konto 777788889999 gestellt wurde.

{ "eventVersion": "1.04", "userIdentity": { "type": "AssumedRole", "principalId": "AROAQRSTUVWXYZEXAMPLE:devdsk", "arn": "arn:aws:sts::777788889999:assumed-role/AssumeNothing/devdsk", "accountId": "777788889999", "accessKeyId": "ASIAI44QH8DHBEXAMPLE", "sessionContext": { "attributes": { "mfaAuthenticated": "false", "creationDate": "2016-11-14T17:25:26Z" }, "sessionIssuer": { "type": "Role", "principalId": "AROAQRSTUVWXYZEXAMPLE", "arn": "arn:aws:iam::777788889999:role/AssumeNothing", "accountId": "777788889999", "userName": "AssumeNothing" } } }, "eventTime": "2016-11-14T17:25:45Z", "eventSource": "s3.amazonaws.com", "eventName": "DeleteBucket", "awsRegion": "us-east-2", "sourceIPAddress": "192.0.2.1", "userAgent": "[aws-cli/1.11.10 Python/2.7.8 Linux/3.2.45-0.6.wd.865.49.315.metal1.x86_64 botocore/1.4.67]", "requestParameters": { "bucketName": "amzn-s3-demo-bucket" }, "responseElements": null, "requestID": "EXAMPLE463D56D4C", "eventID": "dEXAMPLE-265a-41e0-9352-4401bEXAMPLE", "eventType": "AwsApiCall", "recipientAccountId": "777788889999" }

Beispiel für ein SAML-AWS STS-API-Ereignis in der CloudTrail-Protokolldatei

Das folgende Beispiel zeigt einen CloudTrail-Protokolleintrag für eine Anfrage, die für die Aktion AWS STS AssumeRoleWithSAML gestellt wurde. Die Anforderung enthält die SAML-Attribute CostCenter und Project, die durch die SAML-Assertion als Sitzungs-Tags übergeben werden. Diese Tags werden als transitiv festgelegt, so dass sie in Rollenverkettungsszenarien bestehen bleiben. Die Anforderung umfasst den optionalen API-Parameter DurationSeconds, der im CloudTrail-Protokoll als durationSeconds dargestellt wird und auf 1800 Sekunden festgelegt wurde. Die Anforderung enthält außerdem das SAML-Attribut sourceIdentity, das in der SAML-Assertion übergeben wird. Wenn jemand die resultierenden Anmeldeinformationen für die Rollensitzung verwendet, um eine andere Rolle zu übernehmen, bleibt diese Quellidentität bestehen.

{ "eventVersion": "1.08", "userIdentity": { "type": "SAMLUser", "principalId": "SampleUkh1i4+ExamplexL/jEvs=:SamlExample", "userName": "SamlExample", "identityProvider": "bdGOnTesti4+ExamplexL/jEvs=" }, "eventTime": "2023-08-28T18:30:58Z", "eventSource": "sts.amazonaws.com", "eventName": "AssumeRoleWithSAML", "awsRegion": "us-east-2", "sourceIPAddress": "AWS Internal", "userAgent": "aws-internal/3 aws-sdk-java/1.12.479 Linux/5.10.186-157.751.amzn2int.x86_64 OpenJDK_64-Bit_Server_VM/17.0.7+11 java/17.0.7 kotlin/1.3.72 vendor/Amazon.com_Inc. cfg/retry-mode/standard", "requestParameters": { "sAMLAssertionID": "_c0046cEXAMPLEb9d4b8eEXAMPLE2619aEXAMPLE", "roleSessionName": "MyAssignedRoleSessionName", "sourceIdentity": "MySAMLUser", "principalTags": { "CostCenter": "987654", "Project": "Unicorn", "Department": "Engineering" }, "transitiveTagKeys": [ "CostCenter", "Project" ], "roleArn": "arn:aws:iam::444455556666:role/SAMLTestRoleShibboleth", "principalArn": "arn:aws:iam::444455556666:saml-provider/Shibboleth", "durationSeconds": 1800 }, "responseElements": { "credentials": { "accessKeyId": "ASIAIOSFODNN7EXAMPLE", "sessionToken": "<encoded session token blob>", "expiration": "Aug 28, 2023, 7:00:58 PM" }, "assumedRoleUser": { "assumedRoleId": "AROAD35QRSTUVWEXAMPLE:MyAssignedRoleSessionName", "arn": "arn:aws:sts::444455556666:assumed-role/SAMLTestRoleShibboleth/MyAssignedRoleSessionName" }, "packedPolicySize": 1, "subject": "SamlExample", "subjectType": "transient", "issuer": "https://server.example.com/idp/shibboleth", "audience": "https://signin.aws.amazon.com/saml", "nameQualifier": "bdGOnTesti4+ExamplexL/jEvs=", "sourceIdentity": "MySAMLUser" }, "requestID": "6EXAMPLE-e595-11e5-b2c7-c974fEXAMPLE", "eventID": "dEXAMPLE-265a-41e0-9352-4401bEXAMPLE", "readOnly": true, "resources": [ { "accountId": "444455556666", "type": "AWS::IAM::Role", "ARN": "arn:aws:iam::444455556666:role/SAMLTestRoleShibboleth" }, { "accountId": "444455556666", "type": "AWS::IAM::SAMLProvider", "ARN": "arn:aws:iam::444455556666:saml-provider/test-saml-provider" } ], "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "444455556666", "eventCategory": "Management", "tlsDetails": { "tlsVersion": "TLSv1.2", "cipherSuite": "ECDHE-RSA-AES128-GCM-SHA256", "clientProvidedHostHeader": "sts.us-east-2.amazonaws.com" } }

Beispiel für ein OIDC-AWS STS-API-Ereignis in der CloudTrail-Protokolldatei

Das folgende Beispiel zeigt einen CloudTrail-Protokolleintrag für eine Anfrage, die für die Aktion AWS STS AssumeRoleWithWebIdentity gestellt wurde. Die Anfrage enthält die Attribute CostCenter und Project, die als Sitzungs-Tags über das Identitätsanbieter-Token (IdP) von OpenID Connect (OIDC) übergeben werden. Diese Tags werden als transitiv festgelegt, so dass sie in Rollenverkettungsszenarien bestehen bleiben. Die Anforderung enthält das sourceIdentity-Attribut aus dem Token des Identitätsanbieters. Wenn jemand die resultierenden Anmeldeinformationen für die Rollensitzung verwendet, um eine andere Rolle zu übernehmen, bleibt diese Quellidentität bestehen.

Der CloudTrail-Protokolleintrag enthält auch ein additionalEventData-Feld mit einem identityProviderConnectionVerificationMethod-Attribut. Dieses Attribut gibt die Methode AWS an, die zum Überprüfen der Verbindung mit dem OIDC-Anbieter verwendet wird. Der Attributwert ist entweder IAMTrustStore oder Thumbprint. Der IAMTrustStore-Wert gibt an, dass AWS die Verbindung mit dem OIDC-IdP unter Verwendung unserer Bibliothek vertrauenswürdiger Stammzertifizierungsstellen (CAs) erfolgreich überprüft hat. Der Thumbprint-Wert gibt an, dass AWS einen in der IdP-Konfiguration festgelegten Zertifikatfingerabdruck verwendet hat, um das OIDC-IdP-Serverzertifikat zu überprüfen.

{ "eventVersion": "1.08", "userIdentity": { "type": "WebIdentityUser", "principalId": "arn:aws:iam::444455556666:oidc-provider/<issuer url of OIDC provider>:<id of application>:<id of user>", "userName": "<id of user>", "identityProvider": "arn:aws:iam::444455556666:oidc-provider/<issuer url of OIDC provider>" }, "eventTime": "2024-07-09T15:41:37Z", "eventSource": "sts.amazonaws.com", "eventName": "AssumeRoleWithWebIdentity", "awsRegion": "us-east-2", "sourceIPAddress": "192.0.2.101", "userAgent": "aws-cli/2.13.29 Python/3.11.6 Windows/10 exe/AMD64 prompt/off command/sts.assume-role-with-web-identity", "requestParameters": { "roleArn": "arn:aws:iam::444455556666:role/FederatedWebIdentityRole", "roleSessionName": "<assigned role session name>", "sourceIdentity": "MyWebIdentityUser", "durationSeconds": 3600, "principalTags": { "CostCenter": "24680", "Project": "Pegasus" }, "transitiveTagKeys": [ "CostCenter", "Project" ] }, "responseElements": { "credentials": { "accessKeyId": "ASIAIOSFODNN7EXAMPLE", "sessionToken": "<encoded session token blob>", "expiration": "Jul 9, 2024, 4:41:37 PM" }, "subjectFromWebIdentityToken": "<id of user>", "sourceIdentity": "MyWebIdentityUser", "assumedRoleUser": { "assumedRoleId": "AROA123456789EXAMPLE:<assigned role session name>", "arn": "arn:aws:sts::444455556666:assumed-role/FederatedWebIdentityRole/<assigned role session name>" }, "provider": "arn:aws:iam::444455556666:oidc-provider/<issuer url of OIDC provider>", "audience": "<id of application>" }, "additionalEventData": { "identityProviderConnectionVerificationMethod": "IAMTrustStore" }, "requestID": "aEXAMPLE-0b26-40df-8973-c7012EXAMPLE", "eventID": "aEXAMPLE-ee29-4ac0-a0ed-3f5c5EXAMPLE", "readOnly": true, "resources": [ { "accountId": "444455556666", "type": "AWS::IAM::Role", "ARN": "arn:aws:iam::444455556666:role/FederatedWebIdentityRole" } ], "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "444455556666", "eventCategory": "Management", "tlsDetails": { "tlsVersion": "TLSv1.3", "cipherSuite": "TLS_AES_128_GCM_SHA256", "clientProvidedHostHeader": "sts.us-east-2.amazonaws.com" } }

Beispiel für ein AWS STS-API-Ereignis, das den globalen Endpunkt in der CloudTrail-Protokolldatei verwendet

Für Anfragen an den AWS Security Token Service (AWS STS) globalen Endpunkt (https://sts.amazonaws.com) enthält AWS STS zusätzliche AWS CloudTrail-Protokollfelder: endpointType und awsServingRegion. Diese Felder werden unter dem addtionalEventData RequestDetails-Element angezeigt, damit der bereitgestellte AWS-Region und der aufgerufene Endpoint-Typ protokolliert werden. Das endpointType-Feld kann den Wert global oder regional aufweisen, um den Typ des globalen Endpunkts anzugeben, der die Anfrage verarbeitet hat. Weitere Informationen zu den Änderungen der AWS STS globalen Endpunkte finden Sie unter AWS STSRegionen und Endpunkte von .

Anmerkung

Protokolle von AWS CloudTrail für Anfragen an den globalen Endpunkt von AWS STS werden an die Region USA Ost (Nord-Virginia) gesendet. CloudTrail-Protokolle für Anfragen, die von regionalen Endpunkten von AWS STS bearbeitet werden, werden weiterhin in der jeweiligen CloudTrail-Region protokolliert.

Das folgende Beispiel zeigt einen CloudTrail-Protokolleintrag für eine AWS STS-Anfrage an den globalen Endpunkt (https://sts.amazonaws.com) aus der Region Europa (Stockholm) – eu-north-1. Der endpointType-Feldwert von global gibt an, dass die AWS STS-Anfrage vom globalen Endpunkt in der Region Europa (Stockholm) verarbeitet wurde.

{ "eventVersion": "1.08", "userIdentity": { "type": "AssumedRole", "principalId": "AROA123456789EXAMPLE:developer", "arn": "arn:aws:sts::777788889999:assumed-role/Admin/developer", "accountId": "777788889999", "accessKeyId": "ASIAIOSFODNN7EXAMPLE", "sessionContext": { "sessionIssuer": { "type": "Role", "principalId": "AROA123456789EXAMPLE", "arn": "arn:aws:iam::777788889999:role/Admin", "accountId": "777788889999", "userName": "Admin" }, "webIdFederationData": {}, "attributes": { "creationDate": "2025-02-12T21:44:28Z", "mfaAuthenticated": "false" } } }, "eventTime": "2025-02-12T22:16:48Z", "eventSource": "sts.amazonaws.com", "eventName": "AssumeRole", "awsRegion": "us-east-1", "sourceIPAddress": "192.0.2.0", "userAgent": "aws-cli/2.15.33 Python/3.11.8 Linux/5.10.233-204.894.amzn2int.x86_64 exe/x86_64.amzn.2 prompt/off command/sts.assume-role", "requestParameters": { "roleArn": "arn:aws:iam::777788889999:role/test-role", "roleSessionName": "test-global-assume-role" }, "responseElements": { "credentials": { "accessKeyId": "ASIAIOSFODNN7EXAMPLE", "sessionToken": "<encoded session token blob>", "expiration": "Feb 12, 2025, 11:16:48 PM" }, "assumedRoleUser": { "assumedRoleId": "AROA987654321EXAMPLE:test-global-assume-role", "arn": "arn:aws:sts::777788889999:assumed-role/test-role/test-global-assume-role" } }, "additionalEventData": { "RequestDetails": { "awsServingRegion": "eu-north-1", "endpointType": "global" } }, "requestID": "EXAMPLE7-2497-457a-9586-f21feEXAMPLE", "eventID": "EXAMPLEc-3d26-4c3a-9c94-722a9EXAMPLE", "readOnly": true, "resources": [ { "accountId": "777788889999", "type": "AWS::IAM::Role", "ARN": "arn:aws:iam::777788889999:role/test-role" } ], "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "777788889999", "eventCategory": "Management", "tlsDetails": { "tlsVersion": "TLSv1.3", "cipherSuite": "TLS_AES_128_GCM_SHA256", "clientProvidedHostHeader": "sts-global.eu-north-1.amazonaws.com" } }

Zum Vergleich zeigt das folgende Beispiel einen CloudTrail-Protokolleintrag für eine AWS STS-Anfrage an den regionalen Endpunkt (https://sts.us-west-2.amazonaws.com), die vom regionalen Endpunkt in der Region Europa (Stockholm) – eu-north-1 verarbeitet wurde. Der endpointType-Feldwert von regional gibt an, dass die AWS STS-Anfrage vom globalen Endpunkt in der Region Europa (Stockholm) verarbeitet wurde.

{ "eventVersion": "1.08", "userIdentity": { "type": "AssumedRole", "principalId": "AROA123456789EXAMPLE:developer", "arn": "arn:aws:sts::777788889999:assumed-role/Admin/developer", "accountId": "777788889999", "accessKeyId": "ASIAIOSFODNN7EXAMPLE", "sessionContext": { "sessionIssuer": { "type": "Role", "principalId": "AROA123456789EXAMPLE", "arn": "arn:aws:iam::777788889999:role/Admin", "accountId": "777788889999", "userName": "Admin" }, "webIdFederationData": {}, "attributes": { "creationDate": "2025-02-12T21:44:28Z", "mfaAuthenticated": "false" } } }, "eventTime": "2025-02-12T22:16:30Z", "eventSource": "sts.amazonaws.com", "eventName": "AssumeRole", "awsRegion": "eu-north-1", "sourceIPAddress": "192.0.2.0", "userAgent": "aws-cli/2.15.33 Python/3.11.8 Linux/5.10.233-204.894.amzn2int.x86_64 exe/x86_64.amzn.2 prompt/off command/sts.assume-role", "requestParameters": { "roleArn": "arn:aws:iam::777788889999:role/test-role", "roleSessionName": "test-global-assume-role" }, "responseElements": { "credentials": { "accessKeyId": "ASIAIOSFODNN7EXAMPLE", "sessionToken": "<encoded session token blob>", "expiration": "Feb 12, 2025, 11:16:30 PM" }, "assumedRoleUser": { "assumedRoleId": "AROA987654321EXAMPLE:test-global-assume-role", "arn": "arn:aws:sts::777788889999:assumed-role/test-role/test-global-assume-role" } }, "additionalEventData": { "RequestDetails": { "endpointType": "regional", "awsServingRegion": "eu-north-1" } }, "requestID": "EXAMPLEd-2116-4cd7-bd72-9f72fEXAMPLE", "eventID": "EXAMPLEd-219a-48ed-bc54-00e3cEXAMPLE", "readOnly": true, "resources": [ { "accountId": "777788889999", "type": "AWS::IAM::Role", "ARN": "arn:aws:iam::777788889999:role/test-role" } ], "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "777788889999", "eventCategory": "Management", "tlsDetails": { "tlsVersion": "TLSv1.3", "cipherSuite": "TLS_AES_128_GCM_SHA256", "clientProvidedHostHeader": "sts.eu-north-1.amazonaws.com" } }

Beispiel für Anmeldeereignisse im CloudTrail-Protokoll

CloudTrail-Protokolldateien enthalten Ereignisse im JSON-Format. Ein Anmeldeereignis stellt eine einzelne Anmeldeanforderung dar und enthält Informationen über den Anmelde-Auftraggeber, die Region sowie das Datum und die Uhrzeit der Aktion.

Beispiel eines erfolgreichen Anmeldeereignisses in einer CloudTrail-Protokolldatei

Das folgende Beispiel zeigt den CloudTrail-Protokolleintrag für ein erfolgreiches Anmeldeereignis.

{ "eventVersion": "1.05", "userIdentity": { "type": "IAMUser", "principalId": "AIDACKCEVSQ6C2EXAMPLE", "arn":"arn:aws:iam::111122223333:user/John", "accountId": "111122223333", "userName": "John" }, "eventTime": "2014-07-16T15:49:27Z", "eventSource": "signin.amazonaws.com", "eventName": "ConsoleLogin", "awsRegion": "us-east-2", "sourceIPAddress": "192.0.2.110", "userAgent": "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0", "requestParameters": null, "responseElements": { "ConsoleLogin": "Success" }, "additionalEventData": { "MobileVersion": "No", "LoginTo": "https://console.aws.amazon.com/s3/", "MFAUsed": "No" }, "eventID": "3fcfb182-98f8-4744-bd45-10a395ab61cb" }

Weitere Informationen zu den Informationen in CloudTrail-Protokolldateien finden Sie in der CloudTrail-Ereignisreferenz im AWS CloudTrailLeitfaden.

Beispiel für eine Anmeldefehlerereignis in einer CloudTrail-Protokolldatei

Das folgende Beispiel zeigt den CloudTrail-Protokolleintrag für ein Anmeldefehlerereignis.

{ "eventVersion": "1.05", "userIdentity": { "type": "IAMUser", "principalId": "AIDACKCEVSQ6C2EXAMPLE", "arn":"arn:aws:iam::111122223333:user/JaneDoe", "accountId": "111122223333", "userName": "JaneDoe" }, "eventTime": "2014-07-08T17:35:27Z", "eventSource": "signin.amazonaws.com", "eventName": "ConsoleLogin", "awsRegion": "us-east-2", "sourceIPAddress": "192.0.2.100", "userAgent": "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0", "errorMessage": "Failed authentication", "requestParameters": null, "responseElements": { "ConsoleLogin": "Failure" }, "additionalEventData": { "MobileVersion": "No", "LoginTo": "https://console.aws.amazon.com/sns", "MFAUsed": "No" }, "eventID": "11ea990b-4678-4bcd-8fbe-62509088b7cf" }

Anhand dieser Informationen können Sie feststellen, dass der Anmeldeversuch von einer IAM-Benutzerin namens JaneDoe unternommen wurde, wie auch im userIdentity-Element zu sehen ist. Außerdem können Sie dem Element responseElements entnehmen, dass die Anmeldung fehlgeschlagen ist. Den Informationen zufolge hat JaneDoe am 8. Juli 2014 um 17:35 Uhr (UTC) versucht, sich bei der Amazon SNS-Konsole anzumelden.

Beispiel für eine Anmeldung, die aufgrund eines falschen Benutzernamens fehlgeschlagen ist.

Das folgende Beispiel zeigt einen CloudTrail-Protokolleintrag für ein erfolgloses Anmeldeereignis, das durch die Eingabe eines falschen Benutzernamens verursacht wird. AWS maskiert den Text des userName mit HIDDEN_DUE_TO_SECURITY_REASONS, um zu verhindern, dass potenziell vertrauliche Informationen preisgegeben werden.

{ "eventVersion": "1.05", "userIdentity": { "type": "IAMUser", "accountId": "123456789012", "accessKeyId": "", "userName": "HIDDEN_DUE_TO_SECURITY_REASONS" }, "eventTime": "2015-03-31T22:20:42Z", "eventSource": "signin.amazonaws.com", "eventName": "ConsoleLogin", "awsRegion": "us-east-2", "sourceIPAddress": "192.0.2.101", "userAgent": "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0", "errorMessage": "No username found in supplied account", "requestParameters": null, "responseElements": { "ConsoleLogin": "Failure" }, "additionalEventData": { "LoginTo": "https://console.aws.amazon.com/console/home?state=hashArgs%23&isauthcode=true", "MobileVersion": "No", "MFAUsed": "No" }, "eventID": "a7654656-0417-45c6-9386-ea8231385051", "eventType": "AwsConsoleSignin", "recipientAccountId": "123456789012" }

Verhalten der IAM-Rollen-Vertrauensrichtlinie

Am 21. September 2022 nahm AWS Änderungen am Verhalten der IAM-Rollenvertrauensrichtlinie vor, um explizite Zulassungen in einer Rollenvertrauensrichtlinie zu erfordern, wenn eine Rolle sich selbst annimmt. IAM-Rollen in der Zulassungsliste für Legacy-Verhalten verfügen über ein zusätzliches EventData-Feld für „explicitTrustGrant“ für AssumeRole-Ereignisse. Der Wert von explicitTrustGrant ist falsch, wenn eine Rolle auf der Legacy-Zulassungsliste das Legacy-Verhalten verwendet. Wenn eine Rolle auf der Legacy-Zulassungsliste sich selbst annimmt, das Verhalten der Rollenvertrauensrichtlinie jedoch aktualisiert wurde, um der Rolle ausdrücklich zu erlauben, sich selbst anzunehmen, ist der Wert von explicitTrustGrant wahr.

Nur eine sehr kleine Anzahl von IAM-Rollen steht auf der Zulassungsliste für das Legacy-Verhalten und dieses Feld ist in CloudTrail-Protokollen für diese Rollen nur vorhanden, wenn sie sich selbst annehmen. In den meisten Fällen ist es nicht erforderlich, dass eine IAM-Rolle sich selbst annimmt. AWS empfiehlt, Ihre Prozesse, Ihren Code oder Ihre Konfigurationen zu aktualisieren, um dieses Verhalten zu entfernen, oder Ihre Rollenvertrauensrichtlinien zu aktualisieren, um dieses Verhalten ausdrücklich zuzulassen. Weitere Informationen finden Sie unter Ankündigung einer Aktualisierung des Verhaltens der IAM-Rollenvertrauensrichtlinie.