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

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

Cosas que debe saber sobre la identidad de origen

Tenga en cuenta lo siguiente cuando trabaje con 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

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.

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

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

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 identidad federada 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.

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.

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

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

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 AWS Management Console, consulte Federación OIDC.

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

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

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

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

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

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

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

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.

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

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