# Monitorear y controlar las acciones realizadas con roles asumidos Un [rol de IAM](id_roles.md) es un objeto en IAM que está asignado a [permisos](access_policies.md). Cuando usted [asume ese rol](id_roles_manage-assume.md) utilizando una identidad de IAM o una identidad de fuera de AWS, recibirá una sesión con los permisos que se asignan al rol. Cuando lleva a cabo acciones en AWS, la información sobre su sesión se puede registrar en AWS CloudTrail para que el administrador de la cuenta la supervise. Los administradores pueden configurar roles para requerir que las identidades pasen una cadena personalizada que identifique a la persona o aplicación que está realizando acciones en AWS. Esta información de identidad se almacena como *Identidad de origen* en AWS CloudTrail. Cuando el administrador revisa la actividad en CloudTrail, puede ver la información de la identidad de origen para determinar quién o qué realizó acciones con las sesiones de rol asumidas. Después de establecer una identidad de origen, está presente en las solicitudes de cualquier acción de AWS realizada durante la sesión de rol. El valor que se establece persiste cuando se utiliza un rol para asumir otro rol a través de AWS CLI o API de AWS, conocida como [encadenamiento de roles](id_roles.md#iam-term-role-chaining). El valor que se establece no se puede cambiar durante la sesión de rol. Los administradores pueden configurar permisos pormenorizados basados en la presencia o el valor de la identidad de origen para controlar aún más las acciones de AWS que se realizan con roles compartidos. Puede decidir si se puede utilizar el atributo de identidad de origen, si es necesario y qué valor se puede utilizar. La forma en que utiliza la identidad de origen difiere del nombre de sesión de rol y las etiquetas de sesión de forma importante. El valor de identidad de origen no se puede cambiar una vez establecido y persiste para cualquier acción adicional que se realice con la sesión de rol. A continuación se muestra cómo puede utilizar las etiquetas de sesión y el nombre de la sesión de rol: + **Etiquetas de sesión** - Puede pasar etiquetas de sesión al asumir un rol o federar un usuario. Las etiquetas de sesión están presentes cuando se asume un rol. Puede definir políticas que utilicen claves de condición de etiqueta para conceder permisos a sus entidades principales en función de sus etiquetas. Luego puede utilizar CloudTrail para ver las solicitudes realizadas para asumir roles o federar usuarios. Para obtener más información sobre las etiquetas de sesión, consulte [Transferencia de etiquetas de sesión en AWS STS](id_session-tags.md). + **Nombre de la sesión de rol** – Puede utilizar la clave de condición `sts:RoleSessionName` en una política de confianza de rol para exigir que los usuarios proporcionen un nombre de sesión específico cuando asuman un rol. El nombre de sesión de rol se puede utilizar para diferenciar sesiones de rol cuando un rol es utilizado por diferentes entidades principales. Para obtener más información sobre el nombre de la sesión de rol, consulte [sts:RoleSessionName](reference_policies_iam-condition-keys.md#ck_rolesessionname). Le recomendamos que utilice la identidad de origen cuando desee controlar la identidad que asume un rol. La identidad de origen también es útil para extraer registros de CloudTrail para determinar quién utilizó el rol para realizar acciones. **Topics** + [Configuración para utilizar la identidad de origen](#id_credentials_temp_control-access_monitor-setup) + [Cosas que debe saber sobre la identidad de origen](#id_credentials_temp_control-access_monitor-know) + [Permisos necesarios para establecer la identidad de origen](#id_credentials_temp_control-access_monitor-perms) + [Especificar una identidad de origen al asumir un rol](#id_credentials_temp_control-access_monitor-specify-sourceid) + [Utilizar la identidad de origen con AssumeRole](#id_credentials_temp_control-access_monitor-assume-role) + [Utilizar la identidad de origen con AssumeRoleWithSAML](#id_credentials_temp_control-access_monitor-assume-role-saml) + [Utilizar la identidad de origen con AssumeRoleWithWebIdentity](#id_credentials_temp_control-access_monitor-assume-role-web-id) + [Controlar el acceso mediante información de identidad de origen](#id_credentials_temp_control-access_monitor-control-access) + [Visualización de identidad de origen en CloudTrail](#id_credentials_temp_control-access_monitor-ct) ## Configuración para utilizar la identidad de origen La forma en que se configura para utilizar la identidad de origen depende del método utilizado cuando se asumen los roles. Por ejemplo, los usuarios de IAM pueden asumir roles directamente mediante la operación `AssumeRole`. Si tiene identidades empresariales, también conocidas como identidades de personal, es posible que accedan a sus recursos de AWS utilizando `AssumeRoleWithSAML`. Si los usuarios finales acceden a sus aplicaciones móviles o web, es posible que lo hagan mediante `AssumeRoleWithWebIdentity`. A continuación se ofrece información general del flujo de trabajo de alto nivel para poder comprender cómo puede configurar la utilización de la información de identidad de origen en su entorno existente. 1. **Configurar usuarios y roles de prueba** - Mediante un entorno de preproducción, configure los usuarios y roles de prueba y configure sus políticas para permitir establecer una identidad de origen. Si utiliza un proveedor de identidades (IdP) para sus identidades federadas, configure su IdP para que pase un atributo de usuario de su elección para la identidad de origen en la aserción o el token. 1. **Asuma el rol** — Pruebe asumir roles y pasar una identidad de origen con los usuarios y roles que configuró para la prueba. 1. **Revisión de CloudTrail** – Revise la información de identidad de origen para sus roles de prueba en los registros de CloudTrail. 1. **Forme a sus usuarios** – Después de haber probado en su entorno de preproducción, asegúrese de que sus usuarios sepan cómo transmitir la información de identidad de origen, si es necesario. Establezca una fecha límite para cuándo requerirá a los usuarios que proporcionen una identidad de origen en su entorno de producción. 1. **Configuración de políticas de producción** – Configure las políticas para su entorno de producción y, a continuación, agréguelas a los usuarios y roles de producción. 1. **Monitoreo de actividad** – Monitoree la actividad de su rol de producción mediante los registros de CloudTrail. ## Cosas que debe saber sobre la identidad de origen Tenga en cuenta lo siguiente cuando trabaje con identidad de origen. + Las políticas de confianza de roles para todos los roles conectados a un proveedor de identidades (IdP) deben tener el permiso `sts:SetSourceIdentity`. En el caso de los roles que no tienen este permiso en la política de confianza de rol, la operación `AssumeRole*` producirá un error. Si no desea actualizar la política de confianza de rol para cada rol, puede utilizar una instancia de proveedor de identidades independiente para pasar la identidad de origen. A continuación, agregue el permiso `sts:SetSourceIdentity` solo a los roles que están conectados al proveedor de identidades independiente. + Cuando una identidad establece una identidad de origen, la clave `sts:SourceIdentity` está presente en la solicitud. Para las acciones posteriores realizadas durante la sesión de rol, la clave `aws:SourceIdentity` está presente en la solicitud. AWS no controla el valor de la identidad de origen en claves `sts:SourceIdentity` o `aws:SourceIdentity`. Si decide requerir una identidad de origen, debe elegir un atributo que desea que proporcionen sus usuarios o IdP. Por motivos de seguridad, debe asegurarse de que puede controlar cómo se proporcionan esos valores. + El valor de la identidad de origen debe tener entre 2 y 64 caracteres, solo puede contener caracteres alfanuméricos, guiones bajos y los siguientes caracteres: **. , \$1 = @ -** (guion). No puede utilizar un valor que comience con el texto **aws:**. Este prefijo se reserva para uso interno de AWS. + La información de la identidad de origen no es capturada por CloudTrail cuando un servicio o rol vinculado a un servicio de AWS realiza una acción en nombre de una identidad federada o del personal. **importante** No puede cambiar a un rol en Consola de administración de AWS que requiera que se establezca una identidad de origen cuando se asume el rol. Para asumir tal rol, puede utilizar el AWS CLI o API de AWS para llamar a la operación `AssumeRole` y especifique el parámetro de identidad de origen. ## Permisos necesarios para establecer la identidad de origen Además de la acción que coincide con la operación de la API, debe tener la siguiente acción de solo permisos en la política: ``` sts:SetSourceIdentity ``` + Para especificar una identidad de origen, las entidades principales (usuarios y roles de IAM) deben tener permisos para `sts:SetSourceIdentity`. Como administrador, puede configurarlo en la política de confianza de rol y en la política de permisos de seguridad de la entidad principal. + Cuando asume un rol con otro rol, llamado [encadenamiento de roles](id_roles.md#iam-term-role-chaining), se requieren permisos para `sts:SetSourceIdentity` tanto en la política de permisos de la entidad principal que está asumiendo el rol como en la política de confianza de rol del rol de destino. De lo contrario, la operación de rol asumido no se llevará a cabo correctamente. + Cuando se utiliza la identidad de origen, las políticas de confianza de roles para todos los roles conectados a un proveedor de identidades (IdP) deben tener el permiso `sts:SetSourceIdentity`. La operación `AssumeRole*` producirá un error para cualquier rol conectado a un IdP sin este permiso. Si no desea actualizar la política de confianza de rol para cada rol, puede utilizar una instancia de proveedor de identidades independiente para pasar la identidad de origen y agregar el permiso de `sts:SetSourceIdentity` solamente a los roles que están conectados al IdP separado. + Para establecer una identidad de origen a través de los límites de la cuenta, debe incluir el permiso de `sts:SetSourceIdentity` en dos lugares. Debe estar en la política de permisos de la entidad principal en la cuenta de origen y en la política de confianza de rol del rol en la cuenta de destino. Es posible que tenga que hacer esto, por ejemplo, cuando se usa un rol para asumir un rol en otra cuenta con [encadenamiento de roles](id_roles.md#iam-term-role-chaining). Como administrador de la cuenta, imagine que desea permitir que el usuario de IAM `DevUser` en su cuenta para que asuma el `Developer_Role` en la misma cuenta. Pero desea permitir esta acción solo si el usuario ha establecido la identidad de origen en su nombre de usuario de IAM. Puede asignar la siguiente política al usuario IAM. **Example Ejemplos de política basada en identidades adjunta a DevUser** **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AssumeRole", "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::123456789012:role/Developer_Role" }, { "Sid": "SetAwsUserNameAsSourceIdentity", "Effect": "Allow", "Action": "sts:SetSourceIdentity", "Resource": "arn:aws:iam::123456789012:role/Developer_Role", "Condition": { "StringLike": { "sts:SourceIdentity": "${aws:username}" } } } ] } ``` Para aplicar los valores de identidad de origen aceptables, puede configurar la siguiente política de confianza de rol. La política proporciona al usuario de IAM permisos de `DevUser` para asumir el rol y establecer una identidad de origen. La clave de condición `sts:SourceIdentity` define el valor de identidad de origen aceptable. **Example Ejemplo de política de confianza de rol para identidad de origen** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowDevUserAssumeRole", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:user/DevUser" }, "Action": [ "sts:AssumeRole", "sts:SetSourceIdentity" ], "Condition": { "StringEquals": { "sts:SourceIdentity": "DevUser" } } } ] } ``` ------ Al utilizar las credenciales para el usuario de IAM de `DevUser`, el usuario intenta asumir el `DeveloperRole` utilizando la siguiente solicitud AWS CLI. **Example Ejemplo de solicitud de la CLI de AssumeRole** ``` aws sts assume-role \ --role-arn arn:aws:iam::123456789012:role/Developer_Role \ --role-session-name Dev-project \ --source-identity DevUser \ ``` Cuando AWS evalúa la solicitud, el contexto de la solicitud contiene el `sts:SourceIdentity` de `DevUser`. ## Especificar una identidad de origen al asumir un rol Puede especificar una identidad de origen cuando utilice uno de las operaciones AWS STS API de `AssumeRole*` para obtener credenciales de seguridad temporales de un rol. La operación API que utilice difiere en función de su caso de uso. Por ejemplo, si utiliza roles de IAM para dar a los usuarios de IAM acceso a los recursos AWS que normalmente no tienen acceso, puede utilizar la operación de `AssumeRole`. Si utiliza la federación de identidades de empresa para administrar los usuarios del personal, puede utilizar la operación de `AssumeRoleWithSAML`. Si utiliza la federación de OIDC para permitir que los usuarios finales accedan a sus aplicaciones móviles o Web, puede utilizar la operación de `AssumeRoleWithWebIdentity`. En las secciones siguientes se explica cómo utilizar la identidad de origen con cada operación. Para obtener más información sobre los escenarios comunes de las credenciales temporales, consulte [Escenarios habituales en las credenciales temporales](id_credentials_temp.md#sts-introduction). ## Utilizar la identidad de origen con AssumeRole La operación `AssumeRole` devuelve un conjunto de credenciales temporales que puede utilizar para tener acceso a los recursos de AWS. Puede utilizar credenciales de usuario de IAM o credenciales de rol para llamar a `AssumeRole`. Para pasar identidad de origen mientras asume un rol, utilice la opción `-–source-identity` de AWS CLI o el parámetro `SourceIdentity` de la API de AWS. En el siguiente ejemplo, se muestra cómo especificar la identidad de origen con la herramienta de AWS CLI. **Example Ejemplo de solicitud de la CLI de AssumeRole** ``` aws sts assume-role \ --role-arn arn:aws:iam::123456789012:role/developer \ --role-session-name Audit \ --source-identity Admin \ ``` ## Utilizar la identidad de origen con AssumeRoleWithSAML La entidad principal de llamada a la operación `AssumeRoleWithSAML` se autentica mediante la federación basada en SAML. Esta operación devuelve un conjunto de credenciales temporales que puede utilizar para tener acceso a los recursos de AWS. Para obtener más información acerca del uso de la federación basada en SAML para el acceso a la Consola de administración de AWS, consulte [Concesión de acceso a la Consola de administración de AWS a las entidades principales federadas de SAML 2.0](id_roles_providers_enable-console-saml.md). Para obtener información detallada sobre el acceso a la API de AWS CLI o AWS, consulte [Federación SAML 2.0](id_roles_providers_saml.md). Para obtener un tutorial sobre cómo configurar la federación de SAML para los usuarios de Active Directory, consulte [autenticación federada Active Directory Federation Services (ADFS) de AWS](https://aws.amazon.com/blogs/security/aws-federated-authentication-with-active-directory-federation-services-ad-fs/) en el blog de seguridad de AWS. Como administrador, puede permitir que los miembros del directorio de su empresa se federen en AWS mediante la operación AWS STS `AssumeRoleWithSAML`. Para ello, debe completar las siguientes tareas: 1. [Configurar un proveedor SAML en su organización](id_roles_providers_saml_3rd-party.md). 1. [Crear un proveedor SAML en IAM](id_roles_providers_create_saml.md). 1. [Configure un rol y sus permisos en AWS para las entidades principales federadas de SAML](id_roles_create_for-idp_saml.md). 1. [Finalice la configuración del proveedor de identidad SAML y cree aserciones para la respuesta de autenticación SAML](id_roles_providers_create_saml_assertions.md). Para establecer un atributo SAML para la identidad de origen, incluya el elemento `Attribute` con el atributo `Name` establecido en `https://aws.amazon.com/SAML/Attributes/SourceIdentity`. Utilice el elemento `AttributeValue` para especificar el valor de la identidad de origen. Por ejemplo, suponga que desea pasar los siguientes atributos de identidad como la identidad de origen. `SourceIdentity:DiegoRamirez` Para pasar este atributo, incluya el siguiente elemento en su aserción de SAML. **Example Ejemplo de fragmento de una aserción de SAML** ``` DiegoRamirez ``` ## Utilizar la identidad de origen con AssumeRoleWithWebIdentity La entidad principal que llama a la operación `AssumeRoleWithWebIdentity` se autentica mediante la federación compatible con OpenID Connect (OIDC). Esta operación devuelve un conjunto de credenciales temporales que puede utilizar para tener acceso a los recursos de AWS. Para obtener más información acerca del uso de la federación de OIDC para el acceso a la Consola de administración de AWS, consulte [Federación OIDC](id_roles_providers_oidc.md). Para pasar la identidad de origen desde OpenID Connect (OIDC), debe incluir la identidad de origen en el Token Web JSON (JWT). Incluya identidad de origen en el espacio de nombres `[https://aws.amazon.com/](https://aws.amazon.com/)source_identity` en el token cuando envíe la solicitud `AssumeRoleWithWebIdentity`. Para obtener más información sobre los tokens y las notificaciones de OIDC, consulte [Uso de tokens con grupos de usuarios](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html) en la *Guía para desarrolladores de Amazon Cognito*. Por ejemplo, el siguiente JWT descodificado es un token que se utiliza para llamar a `AssumeRoleWithWebIdentity` con la identidad de origen de `Admin`. **Example Ejemplo de token web JSON decodificado** ``` { "sub": "john", "aud": "ac_oic_client", "jti": "ZYUCeRMQVtqHypVPWAN3VB", "iss": "https://xyz.com", "iat": 1566583294, "exp": 1566583354, "auth_time": 1566583292, "https://aws.amazon.com/source_identity":"Admin" } ``` ## Controlar el acceso mediante información de identidad de origen Cuando se establece inicialmente una identidad de origen, la clave [sts:SourceIdentity](reference_policies_iam-condition-keys.md#ck_sourceidentity) está presente en la solicitud. Después de establecer una identidad de origen, la clave [AWS:SourceIdentity](reference_policies_condition-keys.md#condition-keys-sourceidentity) está presente en todas las solicitudes posteriores realizadas durante la sesión de rol. Como administrador, puede escribir políticas que otorguen autorización condicional para realizar acciones de AWS basadas en la existencia o el valor del atributo de identidad de origen. Imagine que desea exigirle a sus desarrolladores que establezcan una identidad de origen para que asuman un rol crítico que tenga permiso para escribir en un recurso de producción crítico de AWS. Imagínese también que concede acceso de AWS a las identidades de su personal mediante `AssumeRoleWithSAML`. Solo desea que los desarrolladores sénior Saanvi y Diego tengan acceso al rol, de modo que cree la siguiente política de confianza para el rol. **Example Ejemplo de política de confianza de rol para identidad de origen (SAML)** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "SAMLProviderAssumeRoleWithSAML", "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::111122223333:saml-provider/name-of-identity-provider" }, "Action": [ "sts:AssumeRoleWithSAML" ], "Condition": { "StringEquals": { "SAML:aud": "https://signin.aws.amazon.com/saml" } } }, { "Sid": "SetSourceIdentitySrEngs", "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::111122223333:saml-provider/name-of-identity-provider" }, "Action": [ "sts:SetSourceIdentity" ], "Condition": { "StringLike": { "sts:SourceIdentity": [ "Saanvi", "Diego" ] } } } ] } ``` ------ La política de confianza contiene una condición para `sts:SourceIdentity` que requiere una identidad de origen de Saanvi o Diego a fin de asumir el rol crítico. Alternativamente, si utiliza un proveedor OIDC para la federación y los usuarios se autentican con `AssumeRoleWithWebIdentity`, su política de confianza de rol podría tener el siguiente aspecto. **Example Ejemplo de política de confianza de rol para identidad de origen (proveedor OIDC)** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::111122223333:oidc-provider/server.example.com" }, "Action": [ "sts:AssumeRoleWithWebIdentity", "sts:SetSourceIdentity" ], "Condition": { "StringEquals": { "server.example.com:aud": "oidc-audience-id" }, "StringLike": { "sts:SourceIdentity": [ "Saanvi", "Diego" ] } } } ] } ``` ------ ### Encadenamiento de funciones y requisitos de cuentas cruzadas Imagine que desea permitir a los usuarios que han asumido `CriticalRole` que asuman una `CriticalRole_2` en otra cuenta. Las credenciales de sesión de rol que se obtuvieron para asumir `CriticalRole` se utilizan para [encadenamiento de roles](id_roles.md#iam-term-role-chaining) a un segundo rol, `CriticalRole_2`, en una cuenta de diferente. El rol se asume a través de un límite de cuenta. Por lo tanto, el permio `sts:SetSourceIdentity` debe concederse tanto en la política de permisos en `CriticalRole` como en la política de confianza de rol en `CriticalRole_2`. **Example Ejemplo de política de permisos en CriticalRole** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AssumeRoleAndSetSourceIdentity", "Effect": "Allow", "Action": [ "sts:AssumeRole", "sts:SetSourceIdentity" ], "Resource": "arn:aws:iam::222222222222:role/CriticalRole_2" } ] } ``` ------ Para proteger la identidad de origen de configuración a través del límite de la cuenta, la siguiente política de confianza de rol confía solo en la entidad principal de rol de `CriticalRole` para establecer la identidad de origen. **Example Ejemplo de política de confianza de rol en CriticalRole\$12** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111111111111:role/CriticalRole" }, "Action": [ "sts:AssumeRole", "sts:SetSourceIdentity" ], "Condition": { "StringLike": { "aws:SourceIdentity": ["Saanvi","Diego"] } } } ] } ``` ------ El usuario realiza la siguiente llamada utilizando las credenciales de sesión de rol obtenidas al asumir CriticalRole. La identidad de origen se estableció durante el supuesto de CriticalRole, por lo que no necesita configurarse explícitamente de nuevo. Si el usuario intenta establecer una identidad de origen diferente del valor establecido cuando se asumió `CriticalRole`, se denegará la solicitud de rol de asunción. **Example Ejemplo de solicitud de la CLI de AssumeRole** ``` aws sts assume-role \ --role-arn arn:aws:iam::222222222222:role/CriticalRole_2 \ --role-session-name Audit \ ``` Cuando la entidad principal de llamada asume el rol, la identidad de origen en la solicitud persiste desde la primera sesión de rol asumida. En consecuencia, tanto `aws:SourceIdentity` como `sts:SourceIdentity` están presentes en el contexto de la solicitud. ## Visualización de identidad de origen en CloudTrail Usted puede utilizar CloudTrail para ver las solicitudes realizadas para asumir roles o federar usuarios. También puede ver las solicitudes de rol o usuario para realizar acciones en AWS. El archivo de registro de CloudTrail incluye información sobre la configuración de identidad de origen para la sesión de usuario federado o de rol asumido. Para obtener más información, consulte [Registro de llamadas a IAM y a la API de AWS STS con AWS CloudTrail](cloudtrail-integration.md) Por ejemplo, suponga que un usuario hace una solicitud AWS STS `AssumeRole`, y configura una identidad de origen. Puede encontrar la información `sourceIdentity` en la clave `requestParameters` de su sesión de CloudTrail. **Example Ejemplo de sección requestParameters en una sesión AWS CloudTrail** ``` "eventVersion": "1.05", "userIdentity": { "type": "AWSAccount", "principalId": "AIDAJ45Q7YFFAREXAMPLE", "accountId": "111122223333" }, "eventTime": "2020-04-02T18:20:53Z", "eventSource": "sts.amazonaws.com", "eventName": "AssumeRole", "awsRegion": "us-east-1", "sourceIPAddress": "203.0.113.64", "userAgent": "aws-cli/1.16.96 Python/3.6.0 Windows/10 botocore/1.12.86", "requestParameters": { "roleArn": "arn:aws:iam::123456789012:role/DevRole", "roleSessionName": "Dev1", "sourceIdentity": "source-identity-value-set" } ``` Si el usuario utiliza la sesión de rol asumida para realizar una acción, la información de identidad de origen está presente en la clave `userIdentity` en la sesión de CloudTrail. **Example Ejemplo de clave userIdentity en una sesión AWS CloudTrail** ``` { "eventVersion": "1.08", "userIdentity": { "type": "AssumedRole", "principalId": "AROAJ45Q7YFFAREXAMPLE:Dev1", "arn": "arn:aws:sts::123456789012:assumed-role/DevRole/Dev1", "accountId": "123456789012", "accessKeyId": "ASIAIOSFODNN7EXAMPLE", "sessionContext": { "sessionIssuer": { "type": "Role", "principalId": "AROAJ45Q7YFFAREXAMPLE", "arn": "arn:aws:iam::123456789012:role/DevRole", "accountId": "123456789012", "userName": "DevRole" }, "webIdFederationData": {}, "attributes": { "mfaAuthenticated": "false", "creationDate": "2021-02-21T23:46:28Z" }, "sourceIdentity": "source-identity-value-present" } } } ``` Para ver el ejemplo de eventos de API AWS STS en las sesiones de CloudTrail, consulte [Ejemplo de eventos API de IAM en el registro de CloudTrail](cloudtrail-integration.md#cloudtrail-integration_examples-iam-api). Para obtener más información sobre la información incluida en los archivos de sesión de CloudTrail, consulte [Referencia de eventos de CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/eventreference.html) en la *Guía del usuario de AWS CloudTrail*.