Monitorear y controlar las acciones realizadas con roles asumidos - AWS Identity and Access Management

Monitorear y controlar las acciones realizadas con roles asumidos

Un rol de IAM es un objeto en IAM que está asignado a permisos. Cuando usted asume ese rol usando una identidad de IAM o una identidad de fuera de AWS, recibirá una sesión con los permisos que se asignan al rol.

Cuando realiza acciones en AWS, la información sobre su sesión se puede registrar en AWS CloudTrail para su administrador de la cuenta a monitorear. 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. 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.

  • 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.

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.

Configuración para usar 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 usando 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 ayudarle a 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.

  2. Asuma el rol — Pruebe asumir roles y pasar una identidad de origen con los usuarios y roles que configuró para la prueba.

  3. Revisión de CloudTrail – Revise la información de identidad de origen para sus roles de prueba en los registros de CloudTrail.

  4. 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.

  5. 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.

  6. 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: . , + = @ - (guion). No puede usar 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 AWS Management Console que requiera que se establezca una identidad de origen cuando se asume el rol. Para asumir tal rol, puede usar 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, 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.

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.

ejemplo 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.

ejemplo Ejemplo de política de confianza de rol para identidad de origen

{ "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 usar las credenciales para el usuario de IAM de DevUser, el usuario intenta asumir el DeveloperRole utilizando la siguiente solicitud AWS CLI.

ejemplo 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 usar la operación de AssumeRole. Si utiliza la identidad federada de empresa para administrar los usuarios del personal, puede usar la operación de AssumeRoleWithSAML. Si utiliza la identidad federada web para permitir que los usuarios finales accedan a sus aplicaciones móviles o web, puede usar 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.

Usar 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 usar 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.

ejemplo 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 \

Usar 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 AWS Management Console, consulte Concesión de acceso a la a los usuarios federados SAML 2.0 AWS Management Console. Para obtener información detallada sobre el acceso a la API de AWS CLI o AWS, consulte Acerca de la federación basada en SAML 2.0. 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 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:

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.

ejemplo Ejemplo de fragmento de una aserción de SAML

<Attribute Name="https://aws.amazon.com/SAML/Attributes/SourceIdentity"> <AttributeValue>DiegoRamirez</AttributeValue> </Attribute>

Usar la identidad de origen con AssumeRoleWithWebIdentity

La entidad principal que llama a la operación AssumeRoleWithWebIdentity se autentica mediante la federación de identidad web 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 identidades web para el acceso a la AWS Management Console, consulte Acerca de identidades web federadas.

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 http://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 Using Tokens with User Pools 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.

ejemplo Ejemplo de token web JSON decodificado

{ "sub": "johndoe", "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 está presente en la solicitud. Después de establecer una identidad de origen, la clave AWS: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.

ejemplo Ejemplo de política de confianza de rol para identidad de origen (SAML)

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AssumeRoleAndSetSourceIdentity", "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::111111111111:saml-provider/name-of-identity-provider" }, "Action": [ "sts:AssumeRoleWithSAML", "sts:SetSourceIdentity" ], "Condition": { "StringEquals": { "SAML:aud": "https://signin.aws.amazon.com/saml" }, "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 de identidades web y los usuarios se autentican con AssumeRoleWithWebIdentity, su política de confianza de rol podría tener el siguiente aspecto.

ejemplo Ejemplo de política de confianza de rol para identidad de origen (proveedor OIDC)

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::111111111111: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 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.

ejemplo Ejemplo de política de permisos en CriticalRole

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

ejemplo Ejemplo de política de confianza de rol en CriticalRole_2

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

ejemplo 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

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.

ejemplo Ejemplo de sección requestParameters en una sesión AWS CloudTrail

"eventVersion": "1.05", "userIdentity": { "type": "AWSAccount", "principalId": "AIDAJ45Q7YFFAREXAMPLE", "accountId": "123456789012" }, "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/Assumed_Role", "roleSessionName": "Test1", "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.

ejemplo 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. 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 en la Guía del usuario de AWS CloudTrail.