Journalisation IAM et AWS STS APIappels avec AWS CloudTrail - AWS Identity and Access Management
IAMet AWS STS informations dans CloudTrailJournalisation IAM et AWS STS APIdemandesJournalisation API des demandes adressées à d'autres AWS servicesJournalisation des événements de connexion utilisateurJournalisation des événements de connexion pour les informations d'identification temporairesExemples d'IAMAPIévénements dans le CloudTrail journalExemple AWS STS APIévénements dans le CloudTrail journalExemple d'événements de connexion dans le journal CloudTrailIAMcomportement en matière de politique de confiance

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Journalisation IAM et AWS STS APIappels avec AWS CloudTrail

IAMet AWS STS sont intégrés à AWS CloudTrail, un service qui fournit un enregistrement des actions entreprises par un IAM utilisateur ou un rôle. CloudTrail capture tous les API appels pour IAM et AWS STS sous forme d'événements, y compris des appels depuis la console et depuis des API appels. Si vous créez un suivi, vous pouvez activer la diffusion continue des CloudTrail événements vers un compartiment Amazon S3. Si vous ne configurez pas de suivi, vous pouvez toujours consulter les événements les plus récents dans la CloudTrail console dans Historique des événements. Vous pouvez l'utiliser CloudTrail pour obtenir des informations sur la demande qui a été faite à IAM ou AWS STS. Par exemple, vous pouvez consulter l'adresse IP à partir de laquelle la demande a été faite, l'auteur de la demande, la date à laquelle elle a été faite, ainsi que des informations supplémentaires.

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

IAMet AWS STS informations dans CloudTrail

CloudTrail est activé sur votre Compte AWS lorsque vous créez le compte. Lorsque l'activité se produit dans IAM ou AWS STS, cette activité est enregistrée dans un CloudTrail événement avec d'autres AWS événements de service dans l'historique des événements. Vous pouvez consulter, rechercher et télécharger les événements récents dans votre Compte AWS. Pour plus d'informations, consultez la section Affichage des événements à l'aide de l'historique des CloudTrail événements.

Pour un enregistrement continu des événements survenus dans votre Compte AWS, y compris des événements pour IAM et AWS STS, créez un parcours. Un suivi permet CloudTrail de fournir des fichiers journaux à un compartiment Amazon S3. Par défaut, lorsque vous créez un journal de suivi dans la console, il s’applique à toutes les régions . Le sentier enregistre les événements de toutes les régions du AWS partitionnez et transmettez les fichiers journaux au compartiment Amazon S3 que vous spécifiez. De plus, vous pouvez configurer d'autres AWS des services permettant d'analyser plus en profondeur et d'agir sur les données d'événements collectées dans CloudTrail les journaux. Pour plus d’informations, consultez :

Tout IAM et AWS STS les actions sont enregistrées CloudTrail et documentées dans la IAMAPIréférence et le AWS Security Token Service APIRéférence.

Journalisation IAM et AWS STS APIdemandes

CloudTrail enregistre toutes les API demandes authentifiées auprès de et IAM AWS STS APIopérations. CloudTrail enregistre également les demandes non authentifiées auprès du AWS STS actionsAssumeRoleWithWebIdentity, AssumeRoleWithSAML et enregistre les informations fournies par le fournisseur d'identité. Cependant, certains ne sont pas authentifiés AWS STS les demandes peuvent ne pas être enregistrées car elles ne répondent pas à l'attente minimale d'être suffisamment valides pour être considérées comme des demandes légitimes.

Vous pouvez utiliser les informations enregistrées pour mapper les appels passés par un utilisateur fédéré ayant un rôle assumé vers l'appelant fédéré externe d'origine. Dans le cas deAssumeRole, vous pouvez mapper les appels vers le point d'origine AWS service ou sur le compte de l'utilisateur d'origine. La userIdentity section des JSON données de l'entrée du CloudTrail journal contient les informations dont vous avez besoin pour cartographier AssumeRole* demande auprès d'un utilisateur fédéré spécifique. Pour plus d'informations, consultez la section CloudTrail userIdentityElément dans le AWS CloudTrail Guide de l'utilisateur.

Par exemple, les appels aux API opérations IAM CreateUser DeleteRoleListGroups,, et autres sont tous enregistrés par CloudTrail.

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

Journalisation API des demandes adressées à d'autres AWS services

Demandes authentifiées adressées à d'autres AWS les API opérations de service sont enregistrées par CloudTrail, et ces entrées de journal contiennent des informations sur l'auteur de la demande.

Supposons, par exemple, que vous ayez demandé de répertorier des EC2 instances Amazon ou de créer un AWS CodeDeploy groupe de déploiement. 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é faite par Utilisateur racine d'un compte AWS, un IAM utilisateur, un rôle ou un autre AWS service.

Pour plus de détails sur les informations d'identité de l'utilisateur figurant dans les entrées du CloudTrail journal, voir userIdentity Elément dans le AWS CloudTrail Guide de l'utilisateur.

Journalisation des événements de connexion utilisateur

CloudTrail enregistre les événements de connexion au AWS Management Console, le AWS des forums de discussion, et AWS Marketplace. CloudTrailenregistre les tentatives de connexion réussies et infructueuses pour les IAM utilisateurs et les utilisateurs fédérés.

Pour consulter CloudTrail des exemples d'événements relatifs à des connexions d'utilisateurs root réussies ou non, consultez la section Exemples d'enregistrements d'événements pour les utilisateurs root dans AWS CloudTrail Guide de l'utilisateur.

En tant que meilleure pratique en matière de sécurité, AWS n'enregistre pas le texte du nom IAM d'utilisateur saisi lorsque l'échec de connexion est dû à 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 choisissez le lien vers la page de connexion de l'un d'entre eux Compte AWS, mais saisissez ensuite le numéro de compte d'un autre Compte AWS.

  • 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 principal détermine la manière dont CloudTrail l'événement est enregistré. Cela peut être compliqué lorsqu'un principal endosse un rôle dans un autre compte. Il existe plusieurs API appels pour effectuer des opérations liées aux opérations entre comptes de rôles. Tout d'abord, le directeur appelle un AWS STS APIpour récupérer les informations d'identification temporaires. Cette opération est enregistrée dans le compte d'appel et dans le compte où AWS STS l'opération est effectuée. Le principal utilise ensuite le rôle pour effectuer d'autres API appels dans le compte du rôle assumé.

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 demander aux IAM utilisateurs de spécifier leur propre nom d'utilisateur comme identité 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 à différencier les sessions de rôle pour un rôle utilisé par différents principaux lorsque vous passez en revue AWS CloudTrail journaux.

Le tableau suivant montre comment CloudTrail enregistre les différentes informations d'identité utilisateur pour chacun des AWS STS APIsqui génèrent des informations d'identification temporaires.

Type de principal STS API Identité de l'utilisateur dans le CloudTrail journal du compte de l'appelant Identité de l'utilisateur dans le CloudTrail journal pour le compte du rôle assumé Identité de l'utilisateur dans le CloudTrail journal pour les API appels suivants du rôle
Utilisateur racine d'un compte AWS informations d'identification 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
IAMutilisateur 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
IAMutilisateur 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
IAMutilisateur AssumeRole Identité d'utilisateur IAM Numéro de compte et identifiant principal (s'il s'agit d'un utilisateur), ou AWS service principal 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 OIDC/Identité de l'utilisateur Web Identité de rôle uniquement (aucun utilisateur)

CloudTrail considère une action en lecture seule si elle n'a aucun effet mutant sur une ressource. Lorsque vous enregistrez un événement en lecture seule, CloudTrail supprimez les responseElements informations du journal. Lorsque vous CloudTrail enregistrez un événement qui n'est pas en lecture seule, l'intégralité responseElements est affichée dans l'entrée du journal. Toutefois, pour AWS STS APIsAssumeRole, et AssumeRoleWithSAMLAssumeRoleWithWebIdentity, même s'ils sont enregistrés en lecture seule, ils CloudTrail seront inclus dans leur intégralité responseElements dans le journal correspondant. APIs

Le tableau suivant indique le mode de CloudTrail journalisation responseElements et les readOnly informations relatives à chacun des AWS STS APIsqui génèrent des informations d'identification temporaires.

STS API Informations sur les éléments de réponse Lecture seule
AssumeRole Inclus true
AssumeRoleWithSAML Inclus true
AssumeRoleWithWebIdentity Inclus true
GetFederationToken Inclus false
GetSessionToken Inclus false

Exemples d'IAMAPIévénements dans le CloudTrail journal

CloudTrail les fichiers journaux contiennent des événements formatés à l'aide JSON de. Un API événement représente une API demande unique et inclut des informations sur le principal, l'action demandée, les paramètres éventuels, ainsi que la date et l'heure de l'action.

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

L'exemple suivant montre une entrée de CloudTrail journal pour une demande faite pour l'IAMGetUserPolicyaction. 

{
  "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é faite par un IAM utilisateur nommé JaneDoe le 15 juillet 2014 à 21h40 (UTC). Dans ce cas, la demande provient du AWS Management Console, comme vous pouvez le constater à partir de l'userAgentélément.

Exemple AWS STS APIévénements dans le CloudTrail journal

CloudTrail les fichiers journaux contiennent des événements formatés à l'aide JSON de. Un API événement représente une API demande unique et inclut des informations sur le principal, l'action demandée, les paramètres éventuels, ainsi que la date et l'heure de l'action.

Exemple de compte croisé AWS STS APIévénements dans les fichiers CloudTrail journaux

L'IAMutilisateur nommé JohnDoe dans le compte 777788889999 appelle AWS STS AssumeRoleaction pour assumer 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": "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"
}

Le deuxième exemple montre l'entrée de CloudTrail journal du compte de rôle supposé (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": "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"
}

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

L'exemple suivant montre une entrée de CloudTrail journal 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": "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"
}

Exemple AWS web AWS STS APIévénement dans le fichier CloudTrail journal

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

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

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

L'exemple suivant montre une entrée de CloudTrail journal pour une demande faite pour AWS STS AssumeRoleWithSAMLaction. La demande inclut les SAML attributs CostCenter Project qui sont transmis via l'SAMLassertion sous forme de 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 le API paramètre facultatifDurationSeconds, représenté comme durationSeconds dans le CloudTrail journal, et est définie sur 1800 secondes. La demande inclut également l'SAMLattributsourceIdentity, qui est transmis dans l'SAMLassertion. 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.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"
    }
}

Exemple OIDC AWS STS APIévénement dans le fichier CloudTrail journal

L'exemple suivant montre une entrée de CloudTrail journal pour une demande faite pour AWS STS AssumeRoleWithWebIdentityaction. La demande inclut les attributs CostCenterProject qui sont transmis via le jeton du fournisseur d'identité (IdPOIDC) OpenID Connect () sous forme de 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.

L'entrée du CloudTrail journal contient également un additionalEventData champ avec un identityProviderConnectionVerificationMethod attribut. Cet attribut indique la méthode AWS utilisé pour vérifier la connexion avec le OIDC fournisseur. La valeur de l'attribut sera IAMTrustStore soitThumbprint. La IAMTrustStore valeur indique que AWS a vérifié avec succès la connexion avec l'OIDCIdP à l'aide de notre bibliothèque d'autorités de certification racine fiables ()CAs. La Thumbprint valeur indique que AWS a utilisé une empreinte numérique de certificat définie dans la configuration de l'IdP pour vérifier le certificat du serveur OIDC IdP.

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

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

CloudTrail les fichiers journaux contiennent des événements formatés à l'aide JSON de. 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 réussite de connexion dans le fichier CloudTrail journal

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

{
  "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 plus de détails sur les informations contenues dans les fichiers CloudTrail journaux, consultez la section Référence des CloudTrail événements dans le AWS CloudTrail Guide de l'utilisateur.

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

L'exemple suivant montre une entrée de CloudTrail journal pour un é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 un IAM utilisateur nomméJaneDoe, comme indiqué dans l'userIdentityélément. Vous pouvez également voir que la tentative de connexion a échoué, comme montré dans l'élément responseElements. Vous pouvez voir que JaneDoe j'ai essayé de me connecter à la SNS console Amazon à 17 h 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 CloudTrail journal concernant un échec de connexion dû à la saisie d'un nom d'utilisateur incorrect par l'utilisateur. AWS masque le userName texte HIDDEN_DUE_TO_SECURITY_REASONS pour é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"
}

IAMcomportement en matière de politique de confiance

Le 21 septembre 2022, AWS a apporté des modifications au comportement de la politique de confiance des IAM rôles afin d'exiger des autorisations explicites dans une politique de confiance des rôles lorsqu'un rôle assume lui-même. IAMles rôles figurant dans l'ancienne liste d'autorisation des comportements comportent un additionalEventData champ explicitTrustGrant destiné aux AssumeRole événements. La valeur de explicitTrustGrant est fausse lorsqu'un rôle figurant dans l'ancienne liste d'autorisation suppose qu'il utilise le comportement existant. Lorsqu'un rôle figurant dans l'ancienne liste d'autorisation assume lui-même son rôle mais que le comportement de la politique d'approbation des rôles a été mis à jour pour autoriser explicitement le rôle à s'assumer lui-même, la valeur de explicitTrustGrant est vraie.

Seul un très petit nombre de IAM rôles figurent sur la liste des rôles autorisés en raison de l'ancien comportement, et ce champ n'est présent dans les CloudTrail journaux de ces rôles que lorsqu'ils se reprennent eux-mêmes. Dans la plupart des cas, il n'est pas nécessaire qu'un IAM rôle s'assume de lui-même. AWS recommande de mettre à jour vos processus, votre code ou vos configurations pour supprimer ce comportement ou de mettre à jour vos politiques d'approbation des rôles pour autoriser explicitement ce comportement. Pour plus d'informations, voir Annonce d'une mise à jour du comportement en matière de politique de confiance IAM dans les rôles.