Journalisation des appels d'API AWS STS et IAM avec AWS CloudTrail - AWS Identity and Access Management

Journalisation des appels d'API AWS STS et IAM avec AWS CloudTrail

IAM et AWS STS sont intégrés à AWS CloudTrail, un service qui enregistre les actions effectuées par un utilisateur, un rôle ou un service IAM. CloudTrail capture tous les appels d'API pour IAM et AWS STS en tant qu'événements, y compris les appels depuis la console et à partir d'appels d'API. Si vous créez un journal d'activité, vous pouvez activer la livraison continue d'événements CloudTrail à un compartiment Amazon S3, y compris des événements pour Amazon S3. Si vous ne configurez pas de journal d'activité, vous pouvez toujours afficher les événements les plus récents dans la console CloudTrail dans Event history (Historique des événements). Vous pouvez utiliser CloudTrail pour obtenir des informations sur la demande qui a été envoyée à IAM ou AWS STS. Par exemple, vous pouvez afficher l'adresse IP à partir de laquelle la demande a été effectuée, qui a effectué la demande et quand, ainsi que des détails supplémentaires.

Pour en savoir plus sur CloudTrail, consultez le Guide de l'utilisateur AWS CloudTrail.

Informations IAM et AWS STS dans CloudTrail

CloudTrail est activé dans votre compte AWS lors de la création de ce dernier. Quand une activité a lieu dans IAM ou AWS STS, l'activité est enregistrée dans un événement CloudTrail avec d'autres événements de service AWS dans l'historique des événements. Vous pouvez afficher, rechercher et télécharger les événements récents dans votre compte AWS. Pour plus d'informations, consultez Affichage des événements avec l'historique des événements CloudTrail.

Pour obtenir un enregistrement continu des événements dans votre compte AWS, y compris les événements pour IAM et AWS STS, créez un journal d'activité. Un journal d'activité permet à CloudTrail de distribuer les fichiers journaux vers Amazon S3 bucket. Par défaut, lorsque vous créez un journal de suivi dans la console, il s'applique à toutes les Régions. Le journal d'activité consigne les événements de toutes les Régions dans la partition AWS et livre les fichiers journaux dans le compartiment Amazon S3 de votre choix. En outre, vous pouvez configurer d'autres services AWS pour analyser plus en profondeur les données d'événement collectées dans les journaux CloudTrail et agir sur celles-ci. Pour plus d'informations, consultez :

Toutes les actions IAM et AWS STS sont consignées par CloudTrail et documentées dans la Référence d'API IAM et la Référence d'API AWS Security Token Service.

Journalisation des demandes IAM et d'API AWS STS

CloudTrail journalise toutes les demandes d'API authentifiées (effectuées avec des informations d'identification) dans les opérations IAM et d'API AWS STS. CloudTrail journalise également les demandes non authentifiées dans les actions AWS STS, AssumeRoleWithSAML et AssumeRoleWithWebIdentity, et journalise les informations fournies par le fournisseur d'identité. Vous pouvez utiliser ces informations pour remapper les appels effectués par un utilisateur fédéré avec un rôle présumé à l'appelant fédéré externe d'origine. Dans le cas de AssumeRole, vous pouvez remapper les appels au service AWS d'origine ou au compte de l'utilisateur d'origine. La section userIdentity des données JSON de l'entrée de journal CloudTrail contient les informations dont vous avez besoin pour mapper la demande AssumeRole* à un utilisateur fédéré spécifique. Pour en savoir plus, consultez Élément userIdentity CloudTrail dans le Guide de l’utilisateur AWS CloudTrail.

Par exemple, les appels aux éléments IAM CreateUser, DeleteRole, ListGroups, et aux autres opérations d'API, sont tous consignés par CloudTrail.

Des exemples de ce type d'entrée de journal sont présentés ultérieurement dans cette rubrique.

Important

Si vous activez des points de terminaison AWS STS dans des régions autres que celles du point de terminaison global par défaut, vous devez également activer la journalisation CloudTrail dans ces régions. Cette opération est nécessaire pour enregistrer tous les appels d'API AWS STS qui sont effectués dans ces régions. Pour de plus amples informations, veuillez consulter Activation de CloudTrail dans des régions supplémentaires dans le Guide de l'utilisateur AWS CloudTrail.

Journalisation des demandes d'API vers d'autres services AWS

Les demandes authentifiées vers d'autres opérations d'API de service AWS sont consignées par CloudTrail et ces entrées de journal contiennent des informations sur celui qui a généré la demande.

Par exemple, supposons que vous ayez effectué une demande de liste des instances Amazon EC2 ou de création d'un groupe de déploiement AWS CodeDeploy. Les détails sur la personne ou le service qui a émis la demande sont enregistrés dans l'entrée de journal de cette demande. Ces informations vous aident à déterminer si la demande a été effectuée par l'utilisateur racine Compte AWS, par un utilisateur IAM, un rôle ou un autre service AWS.

Pour plus d'informations sur les informations d'identité utilisateur dans les entrées de journal CloudTrail, consultez Élément userIdentity dans le Guide de l'utilisateur AWS CloudTrail.

Journalisation des événements de connexion régionaux

Si vous activez CloudTrail de façon à consigner les événements de connexion dans vos journaux, vous devez savoir comment CloudTrail choisit l'emplacement de consignation des événements.

  • Si les utilisateurs se connectent directement à une console, ils sont redirigés vers un point de terminaison de connexion global ou régional. Le point de terminaison dépend de la prise en charge des régions par la console de service sélectionnée. Par exemple, la page d'accueil de la console principale prend en charge les régions. Si vous vous connectez à https://alias.signin.aws.amazon.com/console, vous êtes redirigé vers un point de terminaison de connexion régional tel que https://us-east-2.signin.aws.amazon.com. Cette redirection crée une entrée de journal CloudTrail régionale dans le journal associé à la région de l'utilisateur.

    Par contre, la console Amazon S3 ne prend pas en charge les régions. Par conséquent, si vous vous connectez à https://alias.signin.aws.amazon.com/console/s3, AWS vous redirige vers le point de terminaison de connexion international à l'adresse https://signin.aws.amazon.com. Cette redirection crée une entrée de journal CloudTrail globale.

  • Vous pouvez demander manuellement un point de terminaison de connexion régional spécifique en vous connectant à la page d'accueil régionale de la console principale à l'aide d'une URL similaire à ce qui suit : https://alias.signin.aws.amazon.com/console?region=ap-southeast-1. Dans ce cas, AWS vous redirige vers le point de terminaison de connexion régional ap-southeast-1, ce qui crée un événement de journal CloudTrail régional.

L'événement de connexion est considéré comme régional ou global selon la console à laquelle l'utilisateur se connecte et la construction de l'URL de connexion.

  • La console de service est-elle régionalisée ? Le cas échéant, la demande de connexion est redirigée automatiquement vers un point de terminaison de connexion régional et l'événement est consigné dans le journal CloudTrail de la région. Par exemple, si vous vous connectez à https://alias.signin.aws.amazon.com/console, qui est régionalisé, vous êtes redirigé vers un point de terminaison de connexion de votre région, tel que https://us-east-2.signin.aws.amazon.com. L'événement est consigné dans le journal de cette région.

    Toutefois, certains services n'ont pas encore été régionalisés. Par exemple, le service Amazon S3 n'est pas actuellement régionalisé. Si vous vous connectez à https://alias.signin.aws.amazon.com/console/s3, vous êtes redirigé vers le point de terminaison de connexion global à l'adresse https://signin.aws.amazon.com. Cette redirection crée un événement dans votre journal global.

  • Vous pouvez également demander manuellement un point de terminaison de connexion régional spécifique à l'aide d'une URL telle que https://alias.signin.aws.amazon.com/console?region=ap-southeast-1. L'URL vous redirige alors vers le point de terminaison de connexion régional ap-southeast-1. Cette redirection entraîne un événement dans le journal régional.

Empêcher les entrées de journaux régionales en double

CloudTrail crée des journaux de suivi distincts dans chaque région. Ces journaux de suivi comprennent des informations sur les événements qui se produisent dans ces régions, ainsi que des événements globaux et des événements qui ne sont pas spécifiques à la région. Les exemples incluent les appels d'API IAM, les appels AWS STS vers le point de terminaison global et les événements de connexion AWS. Par exemple, supposons que vous ayez deux pistes, chacune dans une région différente. Si vous créez ensuite un nouvel utilisateur IAM, l'événement CreateUser est ajouté aux fichiers journaux dans les deux régions, en créant une entrée de journal en double.

AWS Security Token Service (STS) est un service global avec un point de terminaison global unique à l'adresse https://sts.amazonaws.com. Les appels vers ce point de terminaison sont consignés en tant qu'appels à un service global. Cependant, comme ce point de terminaison se trouve physiquement dans la région USA Est (Virginie du Nord), vos journaux répertorient us-east-1 comme la région d'événement. CloudTrail n'écrit pas ces journaux dans la région USA Est (Ohio), sauf si vous choisissez d'inclure les journaux de services globaux dans cette région. AWS STS autorise également les appels vers des points de terminaison régionaux, tels que sts.eu-central-1.amazonaws.com. CloudTrail écrit des appels à tous les points de terminaison régionaux vers leurs régions respectives. Par exemple, les appels vers sts.us-east-2.amazonaws.com sont publiés dans la région USA Est (Ohio). Les appels à sts.eu-central-1.amazonaws.com sont publiés dans les journaux de la région Europe (Francfort).

Pour de plus amples informations sur les régions multiples et AWS STS veuillez consulter Gestion de AWS STS dans une AWS Région.

Le tableau suivant répertorie les régions et la manière dont CloudTrail consigne les demandes AWS STS dans chaque région. La colonne « Location » (Emplacement) indique les journaux dans lesquels CloudTrail écrit. « Global » signifie que l'événement est consigné dans toute région dans laquelle vous choisissez d'inclure les journaux de services globaux. « Région » signifie que l'événement est enregistré uniquement dans la région où se trouve le point de terminaison. La dernière colonne indique comment la région de la demande est identifiée dans l'entrée de journal.

Nom de la région Identité de la région dans le journal CloudTrail Point de terminaison Emplacement des journaux CloudTrail
n/a - global us-east-1 sts.amazonaws.com International
USA Est (Ohio) us-east-2 sts.us-east-2.amazonaws.com Région
US East (Virginie du Nord) us-east-1 sts.us-east-1.amazonaws.com Région
USA Ouest (Californie du Nord) us-west-1 sts.us-west-1.amazonaws.com Région
USA Ouest (Oregon) us-west-2 sts.us-west-2.amazonaws.com Région
Canada (Centre) ca-central-1 sts.ca-central-1.amazonaws.com Région
Europe (Francfort) eu-central-1 sts.eu-central-1.amazonaws.com Région
Europe (Irlande) eu-west-1 sts.eu-west-1.amazonaws.com Région
Europe (Londres) eu-west-2 sts.eu-west-2.amazonaws.com Région
Asie-Pacifique (Tokyo) ap-northeast-1 sts.ap-northeast-1.amazonaws.com Région
Asie-Pacifique (Séoul) ap-northeast-2 sts.ap-northeast-2.amazonaws.com Région
Asie-Pacifique (Mumbai) ap-south-1 sts.ap-south-1.amazonaws.com Région
Asie-Pacifique (Singapore) ap-southeast-1 sts.ap-southeast-1.amazonaws.com Région
Asie-Pacifique (Sydney) ap-southeast-2 sts.ap-southeast-2.amazonaws.com Région
Amérique du Sud (São Paulo) sa-east-1 sts.sa-east-1.amazonaws.com Région

Lorsque vous configurez CloudTrail pour regrouper les informations de suivi de plusieurs régions de votre compte dans un seul compartiment Amazon S3, les événements IAM sont dupliqués dans les journaux. En d'autres termes, le journal de suivi de chaque région écrit le même événement IAM dans le journal agrégé. Pour éviter cette duplication, vous pouvez inclure les événements globaux de manière sélective. Une approche typique consiste à autoriser des événements globaux dans un seul journal de suivi. Désactivez ensuite les événements globaux dans tous les autres journaux de suivi qui écrivent dans le même compartiment Amazon S3. De cette façon, un seul ensemble d'événements globaux est écrit.

Pour de plus amples informations, veuillez consulter Aggregating Logs (Agrégation de journaux) dans le Guide de l'utilisateur AWS CloudTrail.

Journalisation des événements de connexion utilisateur

CloudTrail journalise les événements de connexion dans la AWS Management Console, le forums de discussion AWS, et AWS Marketplace. CloudTrail journalise les tentatives de connexion réussies ou infructueuses, pour les utilisateurs IAM et les utilisateurs fédérés.

Pour afficher des exemples d'événements CloudTrail pour des connexions utilisateur racine réussies ou infructueuses, veuillez consulter Example event records for root users (Exemples d'enregistrements d'événements pour les utilisateurs racine) dans le Guide de l'utilisateur AWS CloudTrail.

Dans le cadre des bonnes pratiques de sécurité, AWS ne consigne pas le texte du nom utilisateur IAM saisi lorsque l'échec de la connexion est provoqué par un nom d'utilisateur incorrect. Le texte du nom utilisateur est masqué par la valeur HIDDEN_DUE_TO_SECURITY_REASONS. Pour en obtenir un exemple, consultez Exemple d'événement d'échec de connexion provoqué par un nom d'utilisateur incorrect, plus loin dans cette rubrique. Le texte du nom d'utilisateur est obscurci car de tels échecs peuvent être causés par des erreurs d'utilisateur. La consignation de ces erreurs pourrait exposer des informations potentiellement sensibles. Par exemple :

  • Vous tapez par erreur votre mot de passe dans le champ de nom d'utilisateur.

  • Vous cliquez sur le lien d'une page de connexion d'un compte AWS, mais vous saisissez le numéro d'un autre compte.

  • Vous oubliez sur quel compte vous vous connectez et vous tapez par erreur le nom de compte de votre compte de messagerie personnelle, votre identificateur de connexion bancaire ou un autre ID privé.

Journalisation des événements de connexion pour les informations d'identification temporaires

Lorsqu'un principal demande des informations d'identification temporaires, le type de principal détermine comment CloudTrail consigne l'événement. Cela peut être compliqué lorsqu'un principal endosse un rôle dans un autre compte. Il existe plusieurs appels d'API pour effectuer des opérations liées aux opérations inter-comptes de rôle. Tout d'abord, le principal appelle une API AWS STS pour récupérer les informations d'identification temporaires. Cette opération est enregistrée dans le compte appelant et le compte où l'opération AWS STS est effectuée. Ensuite, le principal utilise le rôle pour effectuer d'autres appels d'API dans le compte du rôle endossé.

Vous pouvez utiliser la clé de condition sts:SourceIdentity dans la politique d'approbation de rôle pour exiger des utilisateurs qu'ils spécifient une identité lorsqu'ils endossent un rôle. Par exemple, vous pouvez exiger que les utilisateurs IAM spécifient leur propre nom d'utilisateur comme identité de source. Cela peut vous aider à déterminer quel utilisateur a effectué une action spécifique dans AWS. Pour plus d'informations, consultez sts:SourceIdentity. Vous pouvez utiliser sts:RoleSessionName pour exiger des utilisateurs qu'ils spécifient un nom de session lorsqu'ils endossent un rôle. Cela peut vous aider à faire la différence entre les sessions de rôle pour un rôle utilisé par différents principaux lorsque vous consultez les journaux AWS CloudTrail.

Le tableau suivant montre comment CloudTrail consigne des informations différentes pour chacun des appels d'API qui génèrent des informations d'identification temporaires.

Type de principal API STS Identité de l'utilisateur dans le journal CloudTrail pour un compte de principal Identité de l'utilisateur dans le journal CloudTrail pour le compte du rôle endossé Identité de l'utilisateur dans le journal CloudTrail pour les appels d'API suivants du rôle
Informations d'identification d'utilisateur racine de Compte AWS GetSessionToken Identité de l'utilisateur racine Le compte du propriétaire de rôle est le même que le compte appelant Identité de l'utilisateur racine
Utilisateur IAM GetSessionToken Identité d'utilisateur IAM Le compte du propriétaire de rôle est le même que le compte appelant Identité d'utilisateur IAM
Utilisateur IAM GetFederationToken Identité d'utilisateur IAM Le compte du propriétaire de rôle est le même que le compte appelant Identité d'utilisateur IAM
Utilisateur IAM AssumeRole Identité d'utilisateur IAM Numéro de compte et ID principal (s'il s'agit d'un utilisateur) ou principal du service AWS Identité de rôle uniquement (aucun utilisateur)
Utilisateur authentifié en externe AssumeRoleWithSAML N/A Identité d'utilisateur SAML Identité de rôle uniquement (aucun utilisateur)
Utilisateur authentifié en externe AssumeRoleWithWebIdentity N/A Identité d'utilisateur OIDC/web Identité de rôle uniquement (aucun utilisateur)

Exemple d'événements d'API IAM dans un journal CloudTrail

Les fichiers journaux CloudTrail contiennent des événements qui sont formatés à l'aide de JSON. Un événement d'API représente une demande d'API unique et inclut des informations sur l'action principale demandée, sur tous les paramètres, et sur la date et l'heure de l'action.

Exemple d'événement 'API IAM dans un fichier journal CloudTrail

L'exemple suivant montre une entrée de journal CloudTrail pour une demande exécutée par l'action GetUserPolicy IAM.

{ "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" }

À partir de ces informations d'événement, vous pouvez déterminer que la demande a été effectuée pour obtenir une politique utilisateur nommée ReadOnlyAccess-JaneDoe-201407151307 pour l'utilisateur JaneDoe, comme indiqué dans l'élément requestParameters. Vous pouvez également voir que la demande a été effectuée par une utilisatrice IAM nommée JaneDoe le 15 juillet 2014 à 21:40 (UTC). Dans ce cas, la demande provenait de l'AWS Management Console, comme vous pouvez le voir à partir de l'élément userAgent.

Exemple d'événements d'API AWS STS dans un journal CloudTrail

Les fichiers journaux CloudTrail contiennent des événements qui sont formatés à l'aide de JSON. Un événement d'API représente une demande d'API unique et inclut des informations sur l'action principale demandée, sur tous les paramètres, et sur la date et l'heure de l'action.

Exemple d'événements d'API inter-comptes AWS STS dans les fichiers journaux CloudTrail

L'utilisateur IAM nommé JohnDoe dans le compte 777788889999 appelle l'action AssumeRole AWS STS pour endosser le rôle EC2-dev dans le compte 111122223333. L'administrateur de compte exige des utilisateurs qu'ils définissent une identité source équivalente à leur nom d'utilisateur lorsqu'ils endossent le rôle. L'utilisateur transmet la valeur d'identité source de JohnDoe.

{ "eventVersion": "1.05", "userIdentity": { "type": "IAMUser", "principalId": "AIDAQRSTUVWXYZEXAMPLE", "arn": "arn:aws:iam::777788889999:user/JohnDoe", "accountId": "777788889999", "accessKeyId": "AKIAQRSTUVWXYZEXAMPLE", "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": "AKIAQRSTUVWXYZEXAMPLE", "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" }, "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" }

Le deuxième exemple illustre l'entrée du journal CloudTrail du compte du propriétaire de rôle endossé (111122223333) pour la même demande.

{ "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": "AKIAQRSTUVWXYZEXAMPLE", "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" }

Exemple d'événement d'API de chaînage de rôles AWS STS dans le fichier journal CloudTrail

L'exemple suivant montre une entrée de journal CloudTrail pour une demande faite par John Doe dans le compte 111111111111. John a précédemment utilisé son utilisateur JohnDoe pour endosser le rôle JohnRole1. Pour cette demande, il utilise les informations d'identification de ce rôle pour endosser le rôle JohnRole2. Ceci est connu sous le nom de chaînage de rôles. L'identité source qu'il a définie lorsqu'il a endossé le rôle JohnDoe1 persiste dans la demande d'endosser le JohnRole2. Si John tente de définir une identité source différente lorsqu'il endosse le rôle, la demande est refusée. John transmet deux balises de session dans la demande. Il définit ces deux balises comme transitives. La demande hérite de la balise Department comme transitive car John l'a définie comme transitive lorsqu'il a endossé JohnRole1. Pour plus d'informations sur l'identité source, consultez Surveiller et contrôler les actions prises avec les rôles endossés. Pour de plus amples informations sur les clés transitives dans les chaînes de rôles, veuillez consulter Chaînage des rôles avec des balises de session.

{ "eventVersion": "1.05", "userIdentity": { "type": "AssumedRole", "principalId": "AROAIN5ATK5U7KEXAMPLE:JohnRole1", "arn": "arn:aws:sts::111111111111:assumed-role/JohnDoe/JohnRole1", "accountId": "111111111111", "accessKeyId": "AKIAI44QH8DHBEXAMPLE", "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": "ASIAWHOJDLGPOEXAMPLE", "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" }

Exemple d'événement d'API AWS STS de service AWS dans le fichier journal CloudTrail

L'exemple suivant montre une entrée de journal CloudTrail pour une demande faite par un service AWS qui appelle une autre API de service à l'aide d'autorisations d'un rôle de service. Il affiche l'entrée du journal CloudTrail pour la demande faite dans le compte 777788889999.

{ "eventVersion": "1.04", "userIdentity": { "type": "AssumedRole", "principalId": "AIDAQRSTUVWXYZEXAMPLE:devdsk", "arn": "arn:aws:sts::777788889999:assumed-role/AssumeNothing/devdsk", "accountId": "777788889999", "accessKeyId": "AKIAQRSTUVWXYZEXAMPLE", "sessionContext": { "attributes": { "mfaAuthenticated": "false", "creationDate": "2016-11-14T17:25:26Z" }, "sessionIssuer": { "type": "Role", "principalId": "AIDAQRSTUVWXYZEXAMPLE", "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" }

Exemple d'événement d'API AWS STS SAML dans le fichier journal CloudTrail

L'exemple suivant montre une entrée de journal CloudTrail pour une demande exécutée par l'action AWS STS AssumeRoleWithSAML. La demande inclut les attributs SAML CostCenter et Project qui sont transmis par l'assertion SAML en tant que balises de session. Ces balises sont définies comme transitives afin qu'elles persistent dans les scénarios de chaînage des rôles. La demande inclut l'attribut SAML sourceIdentity, qui est transmise dans l'assertion SAML. Si quelqu'un utilise les informations d'identification de session de rôle résultantes pour endosser un autre rôle, cette identité source persiste.

{ "eventVersion": "1.05", "userIdentity": { "type": "SAMLUser", "principalId": "SampleUkh1i4+ExamplexL/jEvs=:SamlExample", "userName": "SamlExample", "identityProvider": "bdGOnTesti4+ExamplexL/jEvs=" }, "eventTime": "2019-11-01T19:14:36Z", "eventSource": "sts.amazonaws.com", "eventName": "AssumeRoleWithSAML", "awsRegion": "us-east-2", "sourceIPAddress": "192.0.2.101", "userAgent": "aws-cli/1.16.263 Python/3.4.7 Linux/4.9.184-0.1.ac.235.83.329.metal1.x86_64 botocore/1.12.253", "requestParameters": { "sAMLAssertionID": "_c0046cEXAMPLEb9d4b8eEXAMPLE2619aEXAMPLE", "roleSessionName": "MyAssignedRoleSessionName", "sourceIdentity": "MySAMLUser", "principalTags": { "CostCenter": "987654", "Project": "Unicorn", "Department": "Engineering" }, "transitiveTagKeys": [ "CostCenter", "Project" ], "durationSeconds": 3600, "roleArn": "arn:aws:iam::444455556666:role/SAMLTestRoleShibboleth", "principalArn": "arn:aws:iam::444455556666:saml-provider/Shibboleth" }, "responseElements": { "subjectType": "transient", "issuer": "https://server.example.com/idp/shibboleth", "sourceIdentity": "MySAMLUser" "credentials": { "accessKeyId": "AKIAIOSFODNN7EXAMPLE", "expiration": "Mar 23, 2016 2:39:57 AM", "sessionToken": "<encoded session token blob>" }, "nameQualifier": "bdGOnTesti4+ExamplexL/jEvs=", "assumedRoleUser": { "assumedRoleId": "AROAD35QRSTUVWEXAMPLE:MyAssignedRoleSessionName", "arn": "arn:aws:sts::444455556666:assumed-role/SAMLTestRoleShibboleth/MyAssignedRoleSessionName" }, "subject": "SamlExample", "audience": "https://signin.aws.amazon.com/saml" }, "resources": [ { "ARN": "arn:aws:iam::444455556666:role/SAMLTestRoleShibboleth", "accountId": "444455556666", "type": "AWS::IAM::Role" }, { "ARN": "arn:aws:iam::444455556666:saml-provider/test-saml-provider", "accountId": "444455556666", "type": "AWS::IAM::SAMLProvider" } ], "requestID": "6EXAMPLE-e595-11e5-b2c7-c974fEXAMPLE", "eventID": "dEXAMPLE-265a-41e0-9352-4401bEXAMPLE", "eventType": "AwsApiCall", "recipientAccountId": "444455556666" }

Exemple d'événement d'API AWS STS Web Identity dans le fichier journal CloudTrail

L'exemple suivant montre une entrée de journal CloudTrail pour une demande exécutée par l'action AWS STS AssumeRoleWithWebIdentity. La demande inclut les attributs CostCenter et Project qui sont transmis par le jeton du fournisseur d'identité en tant que balises de session. Ces balises sont définies comme transitives afin qu'elles persistent dans le chaînage des rôles. La demande inclut l'attribut sourceIdentity du jeton du fournisseur d'identité. Si quelqu'un utilise les informations d'identification de session de rôle résultantes pour endosser un autre rôle, cette identité source persiste.

{ "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": "ASIACQRSTUVWRAOEXAMPLE", "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" }

Exemple d'événements de connexion dans le journal CloudTrail

Les fichiers journaux CloudTrail contiennent des événements qui sont formatés à l'aide de JSON. Un événement de connexion représente une seule demande de connexion et inclut des informations sur le principal de connexion, la région, ainsi que la date et l'heure de l'action.

Exemple d'événement de connexion réussi dans le fichier journal CloudTrail

L'exemple suivant montre une entrée de journal CloudTrail pour un événement de connexion réussie.

{ "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" }

Pour davantage de détails sur les informations contenues dans les fichiers journaux CloudTrail, veuillez consulter Référence des événements CloudTrail dans le Guide de l'utilisateur AWS CloudTrail.

Exemple d'événement d'échec de connexion dans le fichier journal CloudTrail

L'exemple suivant montre une entrée de journal CloudTrail pour un événement d'échec de connexion.

{ "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" }

À partir de ces informations, vous pouvez déterminer que la tentative de connexion a été effectuée par une utilisatrice IAM nommée JaneDoe, comme illustré dans l'élément userIdentity. Vous pouvez également voir que la tentative de connexion a échoué, comme montré dans l'élément responseElements. Vous pouvez voir que JaneDoe a essayé de se connecter à la console Amazon SNS à 17:35 (UTC) le 8 juillet 2014.

Exemple d'événement d'échec de connexion provoqué par un nom d'utilisateur incorrect

L'exemple suivant montre une entrée de journal CloudTrail pour un événement d'échec de connexion dû au fait que l'utilisateur a entré un nom d'utilisateur incorrect. AWS masque le texte userName avec HIDDEN_DUE_TO_SECURITY_REASONS afin d'éviter d'exposer des informations potentiellement sensibles.

{ "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" }