Protokollieren von IAM- und AWS STS API-Aufrufen mit AWS CloudTrail - AWS Identitäts- und Zugriffsverwaltung

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.

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

IAM und AWS STS sind in integriert AWS CloudTrail, einen Service, der die Aktionen eines IAM-Benutzers oder einer IAM-Rolle aufzeichnet. 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. Auch wenn Sie keinen Trail konfigurieren, können Sie die neuesten Ereignisse in der CloudTrail-Konsole in Event history (Ereignisverlauf) anzeigen. Sie können verwenden CloudTrail , um Informationen über die an IAM oder gestellte Anfrage 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 CloudTrailfinden Sie im AWS CloudTrail -Benutzerhandbuch.

IAM und AWS STS Informationen in CloudTrail

CloudTrail wird beim Erstellen des Kontos AWS-Konto auf Ihrem aktiviert. Wenn eine Aktivität in IAM oder auftritt AWS STS, wird diese Aktivität in einem - CloudTrail Ereignis zusammen mit anderen - AWS Serviceereignissen im Ereignisverlauf aufgezeichnet. Sie können aktuelle Ereignisse in Ihrem anzeigen, suchen und herunterladen AWS-Konto. Weitere Informationen finden Sie unter Anzeigen von Ereignissen mit dem CloudTrail Ereignisverlauf.

Erstellen Sie für eine fortlaufende Aufzeichnung der Ereignisse in Ihrem AWS-Konto, einschließlich Ereignissen für IAM und AWS STS, einen Trail. Ein Trail ermöglicht CloudTrail die Bereitstellung von Protokolldateien an einen Amazon S3-Bucket. Wenn Sie ein 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 hier:

Alle IAM- und - AWS STS Aktionen werden von protokolliert CloudTrail 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-Anforderungen (mit -Anmeldeinformationen) an IAM und - AWS STS API-Operationen. protokolliert CloudTrail auch nicht authentifizierte Anforderungen an die AWS STS Aktionen AssumeRoleWithSAML und und protokolliert InformationenAssumeRoleWithWebIdentity, die vom Identitätsanbieter bereitgestellt werden. Anhand dieser Informationen können Sie die Aufrufe eines Verbundbenutzers mit einer ihm zugewiesenen Rolle dem ursprünglichen externen Verbundaufrufer zuordnen. Im Fall von können AssumeRoleSie Aufrufe dem ursprünglichen AWS Service oder dem Konto des ursprünglichen Benutzers zuordnen. Der userIdentity Abschnitt der JSON-Daten im CloudTrail Protokolleintrag enthält die Informationen, die Sie benötigen, um die AssumeRole*-Anforderung einem bestimmten Verbundbenutzer zuzuordnen. Weitere Informationen finden Sie unter CloudTrail userIdentity Element im AWS CloudTrail -Benutzerhandbuch.

Aufrufe der -CreateUser, -ListGroups, DeleteRole- und anderen -API-Operationen werden beispielsweise alle von protokolliert CloudTrail.

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

Protokollieren von API-Anforderungen an andere AWS -Services

Authentifizierte Anfragen an andere - AWS Service-API-Operationen werden von protokolliert CloudTrail, und diese Protokolleinträge enthalten Informationen darüber, wer die Anfrage 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. Anhand dieser Informationen können Sie feststellen, ob die Anforderung von der Root-Benutzer des AWS-Kontos, einem IAM-Benutzer, einer Rolle oder einem anderen - AWS Service gestellt wurde.

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

Protokollieren von Benutzeranmeldeereignissen

CloudTrail protokolliert Anmeldeereignisse in der AWS Management Console, den - AWS Diskussionsforen und AWS Marketplace. CloudTrail protokolliert erfolgreiche und fehlgeschlagene Anmeldeversuche für IAM-Benutzer und Verbundbenutzer.

CloudTrail Beispielereignisse für erfolgreiche und erfolglose Stammbenutzeranmeldungen finden Sie unter Beispielereignisdatensätze für Stammbenutzer im AWS CloudTrail -Benutzerhandbuch.

Als bewährte Sicherheitsmethode protokolliert den AWS eingegebenen IAM-Benutzernamentext nicht, wenn der Anmeldefehler durch einen falschen Benutzernamen verursacht wird. 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 ein AWS-Konto.

  • 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 Prinzipal temporäre Anmeldeinformationen anfordert, bestimmt der Prinzipaltyp, 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 Prinzipal eine AWS STS API auf, um die temporären Anmeldeinformationen abzurufen. Dieser Vorgang wird im aufrufenden Konto und im Konto protokolliert, in dem der AWS STS Vorgang 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 AWS ausgeführt hat. 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 Prinzipalen verwendet wird, wenn Sie AWS CloudTrail Protokolle überprüfen.

Die folgende Tabelle zeigt, wie verschiedene Benutzeridentitätsinformationen für jede der AWS STS APIs CloudTrail 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
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 Prinzipal-ID (falls ein Benutzer) oder AWS Service-Prinzipal 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 mutierenden Auswirkungen auf eine Ressource hat. Wenn Sie ein schreibgeschütztes Ereignis protokollieren, CloudTrail reduziert die responseElements Informationen im Protokoll. Wenn ein Ereignis CloudTrail protokolliert, das nicht schreibgeschützt ist, responseElements wird der vollständige im Protokolleintrag angezeigt. Für die AWS STS APIs , AssumeRole AssumeRoleWithSAMLund AssumeRoleWithWebIdentity, obwohl sie als schreibgeschützt protokolliert werden, CloudTrail wird jedoch das vollständige responseElements im Protokoll für diese APIs enthalten.

Die folgende Tabelle zeigt, wie CloudTrail Protokolle responseElements und readOnly Informationen für jede der AWS STS APIs protokolliert und bereitstellt, die temporäre Anmeldeinformationen generieren.

STS-API Informationen zu Antwortelementen Read-only
AssumeRole Enthalten true
AssumeRoleWithSAML Enthalten true
AssumeRoleWithWebIdentity Enthalten true
GetFederationToken Enthalten false
GetSessionToken Enthalten false

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

CloudTrail -Protokolldateien enthalten Ereignisse, die mit JSON formatiert sind. 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-GetUserPolicyAktion.

{ "eventVersion": "1.05", "userIdentity": { "type": "IAMUser", "principalId": "AIDACKCEVSQ6C2EXAMPLE", "arn": "arn:aws:iam::444455556666:user/JaneDoe", "accountId": "444455556666", "accessKeyId": "AKIAI44QH8DHBEXAMPLE", "userName": "JaneDoe", "sessionContext": { "attributes": { "mfaAuthenticated": "false", "creationDate": "2014-07-15T21:39:40Z" } }, "invokedBy": "signin.amazonaws.com" }, "eventTime": "2014-07-15T21:40:14Z", "eventSource": "iam.amazonaws.com", "eventName": "GetUserPolicy", "awsRegion": "us-east-2", "sourceIPAddress": "signin.amazonaws.com", "userAgent": "signin.amazonaws.com", "requestParameters": { "userName": "JaneDoe", "policyName": "ReadOnlyAccess-JaneDoe-201407151307" }, "responseElements": null, "requestID": "9EXAMPLE-0c68-11e4-a24e-d5e16EXAMPLE", "eventID": "cEXAMPLE-127e-4632-980d-505a4EXAMPLE" }

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 stammt die Anforderung aus der AWS Management Console, wie Sie aus dem -userAgentElement erkennen können.

Beispiel für AWS STS API-Ereignisse im CloudTrail -Protokoll

CloudTrail -Protokolldateien enthalten Ereignisse, die mit JSON formatiert sind. 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 JohnDoe im Konto 777788889999 ruft die AWS STS AssumeRole Aktion 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 JohnDoe.

{ "eventVersion": "1.05", "userIdentity": { "type": "IAMUser", "principalId": "AIDAQRSTUVWXYZEXAMPLE", "arn": "arn:aws:iam::777788889999:user/JohnDoe", "accountId": "777788889999", "accessKeyId": "AKIAIOSFODNN7EXAMPLE", "userName": "JohnDoe" }, "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": "JohnDoe-EC2-dev", "sourceIdentity": "JohnDoe", "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:JohnDoe-EC2-dev", "arn": "arn:aws:sts::111122223333:assumed-role/EC2-dev/JohnDoe-EC2-dev" }, "sourceIdentity": "JohnDoe" }, "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 (111122223333)- CloudTrail Protokolleintrag des übernommenen Rollenkontos 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": "JohnDoe-EC2-dev", "sourceIdentity": "JohnDoe", "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:JohnDoe-EC2-dev", "arn": "arn:aws:sts::111122223333:assumed-role/EC2-dev/JohnDoe-EC2-dev" }, "sourceIdentity": "JohnDoe" }, "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 von John Doe im Konto 111111111111. John verwendete zuvor seinen JohnDoe-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 JohnDoe1-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/JohnDoe/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": "JohnDoe" }, "sourceIdentity": "JohnDoe" } }, "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": "JohnDoe", "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": "JohnDoe" }, "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, die von einem - AWS Service gestellt wird, der eine andere Service-API mithilfe von Berechtigungen einer Servicerolle aufruft. Es zeigt den CloudTrail Protokolleintrag für die Anforderung, die im 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": "my-test-bucket-cross-account" }, "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 Anforderung für die AWS STS AssumeRoleWithSAML Aktion . 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 enthält den optionalen API-Parameter DurationSeconds, dargestellt als durationSeconds im CloudTrail Protokoll, und ist auf 1800 Sekunden festgelegt. 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 Anforderung für die AWS STS AssumeRoleWithWebIdentity Aktion . Die Anforderung enthält die Attribute CostCenter und Project, die durch das Identitätsanbietertoken als Sitzungs-Tags ü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.

{ "eventVersion": "1.05", "userIdentity": { "type": "WebIdentityUser", "principalId": "accounts.google.com:<id-of-application>.apps.googleusercontent.com:<id-of-user>", "userName": "<id of user>", "identityProvider": "accounts.google.com" }, "eventTime": "2016-03-23T01:39:51Z", "eventSource": "sts.amazonaws.com", "eventName": "AssumeRoleWithWebIdentity", "awsRegion": "us-east-2", "sourceIPAddress": "192.0.2.101", "userAgent": "aws-cli/1.3.23 Python/2.7.6 Linux/2.6.18-164.el5", "requestParameters": { "sourceIdentity": "MyWebIdentityUser", "durationSeconds": 3600, "roleArn": "arn:aws:iam::444455556666:role/FederatedWebIdentityRole", "roleSessionName": "MyAssignedRoleSessionName" "principalTags": { "CostCenter": "24680", "Project": "Pegasus" }, "transitiveTagKeys": [ "CostCenter", "Project" ], }, "responseElements": { "provider": "accounts.google.com", "subjectFromWebIdentityToken": "<id of user>", "sourceIdentity": "MyWebIdentityUser", "audience": "<id of application>.apps.googleusercontent.com", "credentials": { "accessKeyId": "ASIAIOSFODNN7EXAMPLE", "expiration": "Mar 23, 2016, 2:39:51 AM", "sessionToken": "<encoded session token blob>" }, "assumedRoleUser": { "assumedRoleId": "AROACQRSTUVWRAOEXAMPLE:MyAssignedRoleSessionName", "arn": "arn:aws:sts::444455556666:assumed-role/FederatedWebIdentityRole/MyAssignedRoleSessionName" } }, "resources": [ { "ARN": "arn:aws:iam::444455556666:role/FederatedWebIdentityRole", "accountId": "444455556666", "type": "AWS::IAM::Role" } ], "requestID": "6EXAMPLE-e595-11e5-b2c7-c974fEXAMPLE", "eventID": "bEXAMPLE-0b30-4246-b28c-e3da3EXAMPLE", "eventType": "AwsApiCall", "recipientAccountId": "444455556666" }

Beispiel für Anmeldeereignisse im CloudTrail-Protokoll

CloudTrail -Protokolldateien enthalten Ereignisse, die mit JSON formatiert sind. 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 einen - CloudTrail Protokolleintrag für ein erfolgreiches Anmeldeereignis.

{ "eventVersion": "1.05", "userIdentity": { "type": "IAMUser", "principalId": "AIDACKCEVSQ6C2EXAMPLE", "arn":"arn:aws:iam::111122223333:user/JohnDoe", "accountId": "111122223333", "userName": "JohnDoe" }, "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 CloudTrail -Benutzerhandbuch.

Beispiel für eine Anmeldefehlerereignis in einer CloudTrail -Protokolldatei

Das folgende Beispiel zeigt einen - 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 userName Text mit , HIDDEN_DUE_TO_SECURITY_REASONS um zu verhindern, dass potenziell sensible Informationen offengelegt 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 Vertrauensrichtlinie für IAM-Rollen

Am 21. September 2022 wurden Änderungen am Verhalten der Vertrauensrichtlinie von IAM-Rollen AWS vorgenommen, um explizite Berechtigungen in einer Rollenvertrauensrichtlinie zu verlangen, wenn eine Rolle sich selbst annimmt. IAM-Rollen in der Zulassungsliste für Legacy-Verhaltensweisen haben ein - additionalEventData Feld für explicitTrustGrant für -AssumeRoleEreignisse. Der Wert von explicitTrustGrant ist „false“, wenn eine Rolle in der Legacy-Zulassungsliste sich selbst unter Verwendung des Legacy-Verhaltens annimmt. Wenn eine Rolle in der Legacy-Zulassungsliste sich selbst annimmt, aber das Verhalten der Rollenvertrauensrichtlinie aktualisiert wurde, um der Rolle explizit zu erlauben, sich selbst anzunehmen, explicitTrustGrant ist der Wert von wahr.

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