# Credenciales de seguridad temporales en IAM Puede utilizar AWS Security Token Service (AWS STS) para crear credenciales de seguridad temporales que pueden controlar el acceso a sus recursos de AWS y proporcionárselas a usuarios de confianza. Las credenciales de seguridad temporales funcionan prácticamente igual que las credenciales de clave de acceso a largo plazo, con las siguientes diferencias: + Las credenciales de seguridad temporales son *a corto plazo*, tal como su nombre indica. Se pueden configurar para durar entre unos cuantos minutos y varias horas. Cuando las credenciales caduquen, AWS dejará de reconocerlas o permitirá todo tipo de acceso a las solicitudes realizadas desde API que las utilicen. + Las credenciales de seguridad temporales no se guardan con el usuario, sino que se generan de forma dinámica y se proporcionan al usuario cuando se solicitan. Cuando las credenciales de seguridad temporales caducan (o incluso antes), el usuario puede solicitar nuevas credenciales, siempre y cuando el usuario que las solicite tenga permiso para hacerlo. Como resultado, las credenciales temporales tienen las siguientes ventajas con respecto a las credenciales a largo plazo: + No tiene que distribuir ni incrustar credenciales de seguridad de AWS a largo plazo con una aplicación. + Puede proporcionar acceso a sus recursos de AWS a usuarios, sin necesidad de definir una identidad de AWS para ellos. Las credenciales temporales son la base de los [roles](id_roles.md) y la [federación de identidades](id_roles_providers.md). + Las credenciales de seguridad temporales tienen un ciclo de vida limitado, por lo que no tiene que actualizarlas ni revocarlas de forma explícita cuando ya no las necesite. Cuando las credenciales de seguridad temporales caducan, ya no se pueden volver a utilizar. Puede especificar el tiempo de validez de las credenciales, hasta un límite máximo. ## Regiones de AWS STS y AWS genera las credenciales de seguridad temporales; AWS STS. De forma predeterminada, AWS STS es un servicio global con un único punto de enlace en `https://sts.amazonaws.com`. Sin embargo, también puede optar por realizar llamadas de API de AWS STS a puntos de enlace de cualquier otra región compatible. Esto puede reducir la latencia de servidor (retraso del servidor) enviando las solicitudes a servidores de una región que está más cerca de usted. No importa de qué región vienen sus credenciales, funcionan en todo el mundo. Para obtener más información, consulte [Administración de AWS STS en una Región de AWS](id_credentials_temp_enable-regions.md). ## Escenarios habituales en las credenciales temporales Las credenciales temporales son útiles en escenarios en los que entren en juego las identidades federadas, la delegación, el acceso entre cuentas y los roles de IAM. ### Identidad federada Puede administrar sus identidades de usuario en un sistema externo situado fuera de AWS y conceder a los usuarios que inician sesión desde dichos sistemas acceso para realizar tareas de AWS y obtener acceso a sus recursos de AWS. IAM admite dos tipos de identidades federadas. En ambos casos, las identidades se almacenan fuera de AWS. La diferencia radica dónde reside el sistema externo, en su centro de datos o un tercero externo en la web. Para comparar las características de las credenciales de seguridad temporales para la federación de identidades, consulte [Comparación de credenciales AWS STS](id_credentials_sts-comparison.md). Para obtener más información acerca de proveedores de identidades externos, consulte [Proveedores de identidades y federación en AWS](id_roles_providers.md). + **Federación de OpenID Connect (OIDC)**: puede dejar que los usuarios inicien sesión con un proveedor de identidades de terceros conocido, como Inicio de sesión con Amazon, Facebook, Google o cualquier proveedor compatible con OIDC 2.0 para su aplicación móvil o Web, no necesita crear un código de inicio de sesión personalizado ni administrar sus propias identidades de usuario. La federación de OIDC le permite tener una Cuenta de AWS más segura, ya que no tiene que distribuir credenciales de seguridad a largo plazo, como claves de acceso de usuario de IAM, con su aplicación. Para obtener más información, consulte [Federación OIDC](id_roles_providers_oidc.md). La federación de OIDC AWS STS admite Inicio de sesión con Amazon, Facebook, Google o cualquier proveedor de identidad compatible con OpenID Connect (OIDC). **nota** Para aplicaciones móviles, le recomendamos que utilice Amazon Cognito. Puede utilizar el servicio con los AWS SDK para desarrollo móvil para crear identidades únicas para usuarios y autenticarlos para proteger el acceso a los recursos de AWS. Amazon Cognito es compatible con los mismos proveedores de identidades que AWS STS y con el acceso sin autenticar (invitado), y le permite migrar datos de usuario cuando un usuario inicia sesión. Amazon Cognito también ofrece operaciones de API para sincronizar los datos del usuario de modo que se preserven cuando cambia de un dispositivo a otro. Para obtener más información, consulte [Autenticación con Amplify](https://docs.amplify.aws/lib/auth/getting-started/q/platform/js/#authentication-with-amplify) en la *documentación de Amplify*. + **Federación de SAML**: Puede autenticar usuarios de la red de su organización y, a continuación, dar a dichos usuarios acceso a AWS sin tener que crearles nuevas identidades de AWS ni exigirles que inicien sesión con credenciales diferentes. Este procedimiento se denomina *inicio de sesión único* para el acceso temporal. AWS STS es compatible con estándares abiertos como Security Assertion Markup Language (SAML) 2.0, con el que puede utilizar Microsoft AD FS para aprovechar su Microsoft Active Directory. También puede utilizar SAML 2.0 para administrar su propia solución de identidades federadas de usuarios. Para obtener más información, consulte [Federación SAML 2.0](id_roles_providers_saml.md). + **Agente de federación personalizado** AWS Puede utilizar el sistema de autenticación de su organización para conceder acceso a los recursos de . Si desea ver un escenario de ejemplo, consulte [Permitir el acceso del agente de identidades personalizadas a la consola de AWS](id_roles_providers_enable-console-custom-url.md). + **Federación con SAML 2.0** Puede utilizar el sistema de autenticación de su organización y SAML para conceder acceso a los recursos de AWS. Para obtener más información y ver un escenario de ejemplo, consulte [Federación SAML 2.0](id_roles_providers_saml.md). ### Roles para el acceso entre cuentas Muchas organizaciones mantienen más de una Cuenta de AWS. Con los roles y el acceso entre cuentas, puede definir identidades de usuarios en una cuenta y utilizar esas mismas identidades para obtener acceso a recursos de AWS de otras cuentas que pertenezcan a su organización. Este procedimiento se denomina *delegación* del acceso temporal. Para obtener más información sobre la creación de roles entre cuentas, consulte [Creación de un rol para delegar permisos a un usuario de IAM](id_roles_create_for-user.md). Consulte [¿Qué es IAM Access Analyzer?](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) para saber si las entidades principales de las cuentas fuera de su zona de confianza (cuenta u organización de confianza) tienen acceso para asumir sus roles. ### Roles para Amazon EC2 Si ejecuta aplicaciones en instancias de Amazon EC2 y dichas aplicaciones necesitan obtener acceso a recursos de AWS, puede proporcionar credenciales de seguridad temporales a las instancias cuando las lanza. Dichas credenciales de seguridad temporales están disponibles para todas las aplicaciones que se ejecutan en la instancia, por lo que no es necesario almacenar credenciales a largo plazo en ella. Para obtener más información, consulte [Utilizar un rol de IAM para conceder permisos a aplicaciones que se ejecutan en instancias de Amazon EC2](id_roles_use_switch-role-ec2.md). Para obtener más información sobre las credenciales de los roles de Amazon EC2 de IAM, consulte los [Roles de IAM para Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html) en la *Guía del usuario de Amazon Elastic Compute Cloud*. ### Otros servicios de AWS Puede utilizar credenciales de seguridad temporales para obtener acceso a la mayoría de los servicios de AWS. Para obtener una lista de los servicios que aceptan credenciales de seguridad temporales, consulte [Servicios de AWS que funcionan con IAM](reference_aws-services-that-work-with-iam.md). ## Aplicaciones de ejemplo que utilizan credenciales temporales Puede utilizar AWS Security Token Service (AWS STS) para crear credenciales de seguridad temporales que pueden controlar el acceso a sus recursos de AWS y proporcionárselas a usuarios de confianza. Para obtener más información acerca de AWS STS, consulte [Credenciales de seguridad temporales en IAM](#id_credentials_temp). Para ver cómo puede utilizar AWS STS para administrar credenciales de seguridad temporales, puede descargar las siguientes aplicaciones de ejemplo que implementan escenarios de ejemplo completos: + [Habilitar la federación a AWS para utilizar Windows Active Directory, ADFS y SAML 2.0](https://aws.amazon.com/blogs/security/enabling-federation-to-aws-using-windows-active-directory-adfs-and-saml-2-0/). Demuestra cómo delegar el acceso mediante la federación empresarial a AWS mediante Windows Active Directory (AD), Active Directory Federation Services (ADFS) 2.0 y SAML (Security Assertion Markup Language) 2.0. + [Permitir el acceso del agente de identidades personalizadas a la consola de AWS](id_roles_providers_enable-console-custom-url.md). Muestra cómo crear un proxy de federación personalizada que permite el inicio de sesión único (SSO), de modo que los usuarios de Active Directory puedan iniciar sesión en Consola de administración de AWS. + [Cómo utilizar Shibboleth para el inicio de sesión único en Consola de administración de AWS.](https://aws.amazon.com/blogs/security/how-to-use-shibboleth-for-single-sign-on-to-the-aws-management-console/). En esta página se muestra cómo utilizar [Shibboleth](http://shibboleth.net/) y [SAML](id_roles_providers_saml.md) para proporcionar a los usuarios un acceso de inicio de sesión único (SSO) a la Consola de administración de AWS. ### Muestras para la federación OIDC Las siguientes aplicaciones de muestra ilustran cómo utilizar la federación OIDC con proveedores como Inicio de sesión con Amazon, Amazon Cognito, Facebook, o Google. Puede intercambiar la autenticación de estos proveedores por credenciales de seguridad de AWS temporales para obtener acceso a los servicios de AWS. + [Tutoriales de Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/tutorials.html): le recomendamos que utilice Amazon Cognito con las SDK de AWS para el desarrollo móvil. Amazon Cognito es la forma más sencilla de administrar la identidad en aplicaciones móviles y ofrece características adicionales, como la sincronización y la identidad en todos los dispositivos. Para obtener más información acerca de Amazon Cognito, consulte [Autenticación con Amplify](https://docs.amplify.aws/lib/auth/getting-started/q/platform/js/#authentication-with-amplify) en la *documentación de Amplify*. ## Recursos adicionales para las credenciales de seguridad temporales Los escenarios y aplicaciones siguientes pueden orientarlo sobre el uso de credenciales de seguridad temporales: + [Cómo integrar AWS STS SourceIdentity con su proveedor de identidades](https://aws.amazon.com/blogs/security/how-to-integrate-aws-sts-sourceidentity-with-your-identity-provider/). Esta publicación muestra cómo configurar el atributo AWS STS `SourceIdentity` al usar Okta, Ping o OneLogin como su IdP. + [Federación OIDC](id_roles_providers_oidc.md). En esta sección se explica cómo configurar roles de IAM cuando utiliza las federaciones OIDC y la API `AssumeRoleWithWebIdentity`. + [Acceso seguro a la API con MFA](id_credentials_mfa_configure-api-require.md). En este tema se explica cómo utilizar roles para exigir una autenticación multifactor (MFA) para proteger acciones de API confidenciales en su cuenta. Para obtener más información sobre las políticas y permisos de AWS, consulte los temas siguientes: + [Recursos de AWS para administración de acceso](access.md) + [Lógica de evaluación de políticas](reference_policies_evaluation-logic.md). + [Administración de los permisos de acceso a los recursos de Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-access-control.html) en la *Guía del usuario de Amazon Simple Storage Service*. + Consulte [¿Qué es IAM Access Analyzer?](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) para saber si las entidades principales de las cuentas fuera de su zona de confianza (cuenta u organización de confianza) tienen acceso para asumir sus roles. # Comparación de credenciales AWS STS La siguiente tabla compara las características de las operaciones de la API de AWS STS que devuelven credenciales de seguridad temporales. Para obtener más información sobre los distintos métodos que puede utilizar para solicitar credenciales de seguridad temporales asumiendo un rol, consulte [Métodos para asumir un rol](id_roles_manage-assume.md). Para obtener información sobre las diferentes operaciones de API de AWS STS que le permiten pasar etiquetas de sesión, consulte [Transferencia de etiquetas de sesión en AWS STS](id_session-tags.md). **nota** Puede enviar llamadas a la API de AWS STS tanto a un punto de enlace global como a uno de los puntos de enlace regionales. Si elige el punto de enlace más cercano, puede reducir la latencia y mejorar el rendimiento de las llamadas a la API. También puede elegir enviar sus llamadas a un punto de enlace regional alternativo si ya no puede comunicarse con el punto de enlace original. Si utiliza uno de los distintos SDK de AWS, utilice el método del SDK para especificar una región antes de realizar la llamada a la API. Si va realiza manualmente solicitudes de API HTTP, debe enviar usted mismo la solicitud al punto de conexión correcto. Para obtener más información, consulte la [AWS STS sección de *Regiones y puntos de enlace*](https://docs.aws.amazon.com/general/latest/gr/rande.html#sts_region) y [Administración de AWS STS en una Región de AWS](id_credentials_temp_enable-regions.md). | **API de AWS STS** | **Quién puede llamar** | **Duración de las credenciales (mín \$1 máx \$1 predeterminada)** | **Soporte de MFA**¹ | **Compatibilidad con políticas de sesión**² | **Restricciones aplicables a las credenciales temporales obtenidas** | | --- | --- | --- | --- | --- | --- | | [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) | Usuario de IAM o rol de IAM con credenciales de seguridad temporales existentes | 15 min \$1 configuración de la duración máxima de la sesión³ \$1 1 h | Sí | Sí | No se puede llamar a `GetFederationToken` ni a `GetSessionToken`. | | [AssumeRoleWithSAML](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html) | Cualquier usuario: el intermediario debe transmitir una respuesta de autenticación de SAML que indique la autenticación de un proveedor de identidad conocido | 15 min \$1 configuración de la duración máxima de la sesión³ \$1 1 h | No | Sí | No se puede llamar a `GetFederationToken` ni a `GetSessionToken`. | | [AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) | Cualquier usuario; la persona que llama debe pasar un token JWT compatible con OIDC que indique la autenticación de un proveedor de identidad conocido | 15 min \$1 configuración de la duración máxima de la sesión³ \$1 1 h | No | Sí | No se puede llamar a `GetFederationToken` ni a `GetSessionToken`. | | [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) | Usuario de IAM o Usuario raíz de la cuenta de AWS | Usuario de IAM: 15 m \$1 36 h \$1 12 h Usuario raíz: 15 m \$1 1 h \$1 1 h | No | Sí | No se puede llamar a operaciones de IAM mediante AWS CLI o la API de AWS. Esta limitación no se aplica a las sesiones de consola. No se puede llamar a operaciones de AWS STS excepto `GetCallerIdentity`.⁴ Se permite el inicio de sesión único (SSO) en la consola.⁵ | | [GetSessionToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html) | Usuario de IAM o Usuario raíz de la cuenta de AWS | Usuario de IAM: 15 m \$1 36 h \$1 12 h Usuario raíz: 15 m \$1 1 h \$1 1 h | Sí | No | No se puede llamar a las operaciones de API de IAM, a no ser que se incluya en la solicitud la información de MFA. No se puede llamar a las operaciones de API de AWS STS excepto `AssumeRole` o `GetCallerIdentity`. No se permite el inicio de sesión único (SSO) en la consola.⁶ | ¹ **Compatibilidad con MFA**. Puede incluir información acerca del dispositivo de autenticación multifactor (MFA) cuando llama a las operaciones de API AssumeRole y GetSessionToken. De este modo, se garantiza que las credenciales de seguridad temporales que se derivan de la llamada a la API solo las puedan utilizar los usuarios que se autentiquen con un dispositivo MFA. Para obtener más información, consulte [Acceso seguro a la API con MFA](id_credentials_mfa_configure-api-require.md). ² **Soporte con políticas de sesión**. Las políticas de sesión son políticas que se pasan como parámetro al crear mediante programación una sesión temporal para un rol o una sesión de usuario federado de AWS STS. Esta política limita los permisos de la política basada en identidad del rol o usuario que se asignan a la sesión. Los permisos de la sesión resultantes son la intersección de las políticas basadas en identidades de la entidad y las políticas de la sesión. Las políticas de sesión no se pueden utilizar para conceder más permisos que los permitidos por la política basada en identidades del rol que se asume. Para obtener más información sobre los permisos de sesión de un rol, consulte [Políticas de sesión](access_policies.md#policies_session). ³ **Configuración de la duración máxima de la sesión**. Use el parámetro `DurationSeconds` para especificar la duración de la sesión de rol, que puede oscilar entre 900 segundos (15 minutos) y el valor de la duración máxima de la sesión especificado para el rol. Para obtener información sobre cómo ver el valor máximo para el rol, consulte [Actualizar la duración máxima de la sesión para un rol](id_roles_update-role-settings.md#id_roles_update-session-duration). ⁴ **GetCallerIdentity**. No se requieren permisos para realizar esta operación. Si un administrador añade una política a su usuario o rol de IAM que deniega explícitamente el acceso a la acción `sts:GetCallerIdentity`, puede realizar esta operación. Los permisos no son necesarios porque se devuelve la misma información cuando se deniega el acceso a un usuario o rol de IAM. Para ver un ejemplo de respuesta, consulte [No tengo autorización para realizar la operación iam:DeleteVirtualMFADevice](troubleshoot.md#troubleshoot_general_access-denied-delete-mfa). ⁵ **.⁶**. Para facilitar el inicio de sesión único (SSO), AWS le permite llamar a un punto de enlace de federación (`https://signin.aws.amazon.com/federation`) y transmitir las credenciales de seguridad temporales. El punto de enlace devuelve un token que puede utilizar para crear una dirección URL con la que un usuario inicia sesión directamente en la consola sin necesidad de una contraseña. Para obtener más información, 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) y [ How to Enable Cross-Account Access to the AWS Management Console](https://aws.amazon.com/blogs/security/how-to-enable-cross-account-access-to-the-aws-management-console) en el blog de seguridad de AWS. ⁶ Tras recuperar las credenciales temporales, no puede acceder a la Consola de administración de AWS transmitiendo las credenciales al punto de enlace de inicio de sesión único de la federación. Para obtener más información, consulte [Permitir el acceso del agente de identidades personalizadas a la consola de AWS](id_roles_providers_enable-console-custom-url.md). # Tokens de portador del servicio Algunos servicios de AWS requieren que tenga permiso para obtener un token al portador del servicio AWS STS para poder acceder a sus recursos mediante programación. Estos servicios admiten un protocolo que requiere que utilice un token de portador, en lugar de un tradicional [AWS Signature Version 4 para solicitudes de API](reference_sigv.md). Cuando realiza operaciones de la API de AWS CLI o AWS que requieren tokens al portador, el servicio de AWS solicita un token al portador en su nombre. El servicio le proporciona el token, que puede utilizar más adelante para realizar futuras operaciones en ese servicio. AWS STSLos tokens al portador del servicio incluyen información original de su entidad principal que podría afectar a sus permisos. Esta información puede incluir etiquetas de entidad principal, etiquetas de sesión y políticas de sesión. El ID de clave de acceso del token comienza con el prefijo `ABIA`. Esto le ayuda a identificar las operaciones que se realizaron mediante tokens al portador del servicio en sus registros de CloudTrail. **importante** El token al portador solo se puede utilizar para hacer llamadas al servicio que lo genera y en la región en que se generó. No puede utilizar el token al portador para realizar operaciones en otros servicios o regiones. Un ejemplo de un servicio que admite tokens al portador es AWS CodeArtifact. Para poder interactuar con AWS CodeArtifact a través de un administrador de paquetes como NPM, Maven o PIP, primero debe llamar a la operación `aws codeartifact get-authorization-token`. Esta operación devuelve un token al portador que puede utilizar para realizar operaciones de AWS CodeArtifact. De forma alternativa, puede utilizar el comando `aws codeartifact login`, que completa la misma operación y luego configura su cliente automáticamente. Si realiza una acción en un servicio de AWS que genera un token al portador para usted, debe tener los siguientes permisos en su política de IAM: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowServiceBearerToken", "Effect": "Allow", "Action": "sts:GetServiceBearerToken", "Resource": "*" } ] } ``` ------ Para ver un ejemplo de token de portador de servicio, consulte [Uso de políticas basadas en identidades para AWS CodeArtifact](https://docs.aws.amazon.com/codeartifact/latest/ug/auth-and-access-control-iam-identity-based-access-control.html) en la *Guía del usuario de AWS CodeArtifact *. # Solicitud de credenciales de seguridad temporales Para solicitar credenciales de seguridad temporales, puede utilizar las operaciones AWS Security Token Service (AWS STS) en la API de AWS. Esto incluye operaciones para crear credenciales de seguridad temporales que pueden controlar el acceso a sus recursos de AWS y proporcionárselas a usuarios de confianza. Para obtener más información acerca de AWS STS, consulte [Credenciales de seguridad temporales en IAM](id_credentials_temp.md). Para obtener más información sobre los distintos métodos que puede utilizar para solicitar credenciales de seguridad temporales asumiendo un rol, consulte [Métodos para asumir un rol](id_roles_manage-assume.md). Para llamar a las operaciones de la API, puede utilizar uno de los [SDK de AWS](https://aws.amazon.com/tools/). Los SDK están disponibles para una gran variedad de entornos y lenguajes de programación, tales como Java, .NET, Python, Ruby, Android e iOS. Los SDK se encargan de tareas como firmar solicitudes criptográficamente, reintentar solicitudes si fuera necesario y administrar respuestas a errores. También puede utilizar la API de consulta de AWS STS, que se describe en [Referencia de API de AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/). Por último, dos herramientas de línea de comandos admiten los comandos de AWS STS: [AWS Command Line Interface](https://aws.amazon.com/documentation/cli) y [AWS Tools for Windows PowerShell](https://aws.amazon.com/documentation/powershell). Las operaciones de API de AWS STS crean una nueva sesión con credenciales de seguridad temporales formadas por un par de claves de acceso y un token de sesión. El par de claves de acceso consta de un ID de clave de acceso y una clave secreta. Los usuarios (o una aplicación que el usuario ejecute) pueden utilizar estas credenciales para obtener acceso a los recursos. Puede crear una sesión de rol y pasar políticas de sesión y etiquetas de sesión con programación mediante las operaciones de la API de AWS STS. Los permisos de la sesión resultantes son la intersección de las políticas basadas en identidades del rol y las políticas de la sesión. Para obtener más información acerca de las políticas de sesión, consulte [Políticas de sesión](access_policies.md#policies_session). Para obtener más información acerca de las etiquetas de sesión, consulte [Transferencia de etiquetas de sesión en AWS STS](id_session-tags.md). **nota** El tamaño del token de seguridad que devuelven las operaciones de la API de AWS STS no es fijo. Recomendamos encarecidamente que no realice suposiciones sobre el tamaño máximo. El tamaño típico del token es inferior a 4096 bytes, pero puede variar. ## Uso de AWS STS con regiones de AWS Puede enviar llamadas a la API de AWS STS tanto a un punto de enlace global como a uno de los puntos de enlace regionales. Si elige el punto de enlace más cercano, puede reducir la latencia y mejorar el rendimiento de las llamadas a la API. También puede elegir enviar sus llamadas a un punto de enlace regional alternativo si ya no puede comunicarse con el punto de enlace original. Si utiliza uno de los distintos SDK de AWS, utilice el método del SDK para especificar una región antes de realizar la llamada a la API. Si va realiza manualmente solicitudes de API HTTP, debe enviar usted mismo la solicitud al punto de conexión correcto. Para obtener más información, consulte la [AWS STS sección de *Regiones y puntos de enlace*](https://docs.aws.amazon.com/general/latest/gr/rande.html#sts_region) y [Administración de AWS STS en una Región de AWS](id_credentials_temp_enable-regions.md). Las siguientes son operaciones de API que puede utilizar para obtener credenciales temporales para su uso en aplicaciones y entornos de AWS. ## Solicitud de credenciales para la federación y delegación entre cuentas a través de un agente de identidades personalizado La operación de API [https://docs.aws.amazon.com//STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com//STS/latest/APIReference/API_AssumeRole.html) es útil para permitir a los usuarios existentes de IAM el acceso a recursos de AWS a los que todavía no tienen acceso. Por ejemplo, el usuario puede necesitar acceso a los recursos de otra Cuenta de AWS. También es útil para obtener temporalmente acceso privilegiado por ejemplo, para proporcionar autenticación multifactor (MFA). Debe llamar a esta API con las credenciales de usuario activas. Para saber quién puede llamar a esta operación, consulte [Comparación de credenciales AWS STS](id_credentials_sts-comparison.md). Para obtener más información, consulte [Creación de un rol para delegar permisos a un usuario de IAM](id_roles_create_for-user.md) y [Acceso seguro a la API con MFA](id_credentials_mfa_configure-api-require.md). **Para solicitar credenciales de seguridad temporales para la federación y delegación entre cuentas mediante un agente de identidades personalizado** 1. Autentíquese con sus credenciales de seguridad de AWS. Esta llamada debe realizarse con credenciales de seguridad de AWS válidas. 1. Llame a la operación [https://docs.aws.amazon.com//STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com//STS/latest/APIReference/API_AssumeRole.html). En el siguiente ejemplo se muestra una solicitud y respuesta de muestra que utiliza `AssumeRole`. Esta solicitud de ejemplo asume el rol `demo` durante la duración especificada con la [política de sesión](access_policies.md#policies_session) incluida, las [etiquetas de sesión](id_session-tags.md), el [ID externo](id_roles_common-scenarios_third-party.md) y la [identidad de origen](id_credentials_temp_control-access_monitor.md). La sesión resultante se denomina `John-session`. **Example Ejemplo de solicitud** ``` https://sts.amazonaws.com/ ?Version=2011-06-15 &Action=AssumeRole &RoleSessionName=John-session &RoleArn=arn:aws::iam::123456789012:role/demo &Policy=%7B%22Version%22%3A%222012-10-17 %22%2C%22Statement%22%3A%5B%7B%22Sid%22%3A%20%22Stmt1%22%2C%22Effect%22%3A%20%22Allow%22%2C%22Action%22%3A%20%22s3%3A*%22%2C%22Resource%22%3A%20%22*%22%7D%5D%7D &DurationSeconds=1800 &Tags.member.1.Key=Project &Tags.member.1.Value=Pegasus &Tags.member.2.Key=Cost-Center &Tags.member.2.Value=12345 &ExternalId=123ABC &SourceIdentity=DevUser123 &AUTHPARAMS ``` El valor de política que se muestra en el ejemplo anterior es la versión codificada como URL de la siguiente política: ------ #### [ JSON ] **** ``` {"Version":"2012-10-17", "Statement":[{"Sid":"Stmt1","Effect":"Allow","Action":"s3:*","Resource":"*"}]} ``` ------ El parámetro `AUTHPARAMS` en el ejemplo es un marcador de posición para su *firma*. Una firma es la información de autenticación que debe incluir en las solicitudes de la API HTTP de AWS. Recomendamos utilizar los [SDK de AWS](https://aws.amazon.com/tools/) para crear solicitudes de API; un beneficio de esto es que los SDK gestionan la firma de solicitudes en su nombre. Si debe crear y firmar manualmente solicitudes de API, diríjase a [Firma de solicitudes de AWS con Signature Version 4](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html) en la *Referencia general de Amazon Web Services* para averiguar cómo firmar una solicitud. Además de las credenciales de seguridad temporales, la respuesta incluye el Nombre de recurso de Amazon (ARN) para el usuario federado y el plazo de vencimiento de las credenciales. **Example Respuesta de ejemplo** ``` DevUser123 AQoDYXdzEPT//////////wEXAMPLEtc764bNrC9SAPBSM22wDOk4x4HIZ8j4FZTwdQW LWsKWHGBuFqwAeMicRXmxfpSPfIeoIYRqTflfKD8YUuwthAx7mSEI/qkPpKPi/kMcGd QrmGdeehM4IC1NtBmUpp2wUE8phUZampKsburEDy0KPkyQDYwT7WZ0wq5VSXDvp75YU 9HFvlRd8Tx6q6fE8YQcHNVXAkiY9q6d+xo0rKwT38xVqr7ZD0u0iPPkUL64lIZbqBAz +scqKmlzm8FDrypNC9Yjc8fPOLn9FX9KSYvKTr4rvx3iSIlTJabIQwj2ICCR/oLxBA== wJalrXUtnFEMI/K7MDENG/bPxRfiCYzEXAMPLEKEY 2019-07-15T23:28:33.359Z AKIAIOSFODNN7EXAMPLE arn:aws:sts::123456789012:assumed-role/demo/John ARO123EXAMPLE123:John 8 c6104cbe-af31-11e0-8154-cbc7ccf896c7 ``` **nota** Una conversión de AWS comprime las políticas de sesión pasadas y las etiquetas de sesión en un formato binario empaquetado que tiene un límite separado. Su solicitud puede fallar para este límite incluso si el texto sin formato cumple con los demás requisitos. El elemento de respuesta `PackedPolicySize` indica por porcentaje lo cerca que están las políticas y etiquetas de su solicitud al límite de tamaño superior. ## Solicitud de credenciales mediante un proveedor de OIDC La operación de la API de [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) devuelve un conjunto de credenciales de seguridad de AWS temporales a cambio de un token web JSON (JWT). Esto incluye a los proveedores de identidades públicos, como Login with Amazon, Facebook, Google y los proveedores que emiten JWT compatibles con la detección de OpenID Connect (OIDC), como GitHub Actions o Azure DevOps. Para obtener más información, consulte [Federación OIDC](id_roles_providers_oidc.md). **nota** Las solicitudes de `AssumeRoleWithWebIdentity` no se firman con credenciales de AWS ni las requieren. **Solicitud de credenciales mediante un proveedor de OIDC** 1. Llame a la operación [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html). Cuando llama a `AssumeRoleWithWebIdentity`, AWS valida el token presentado mediante la verificación de la firma digital con las claves públicas disponibles a través del conjunto de claves web JSON (JWKS) de su IdP. Si el token es válido y se cumplen todas las condiciones establecidas en la política de confianza del rol de IAM, AWS devuelve la siguiente información: + Un conjunto de credenciales de seguridad temporales. Estas incluyen un ID de clave de acceso, una clave de acceso secreta y un token de sesión. + El ID de rol y el ARN del rol asumido. + Un valor `SubjectFromWebIdentityToken` que incluye el ID de usuario único. 1. Su aplicación puede usar las credenciales de seguridad temporales que se devolvieron en la respuesta para realizar llamadas a la API de AWS. Se trata del mismo proceso que para hacer una llamada a la API de AWS con credenciales de seguridad a largo plazo. La diferencia es que debe incluir el token de sesión, que permite a AWS verificar que las credenciales de seguridad temporales son válidas. La aplicación debe almacenar en caché las credenciales devueltas por AWS STS y actualizarlas según sea necesario. Si la aplicación se creó con un SDK de AWS, el SDK tiene proveedores de credenciales que pueden gestionar las llamadas a `AssumeRoleWithWebIdentity` y actualizar las credenciales de AWS antes de que caduquen. Para obtener más información, consulte los [proveedores de credenciales estandarizados de herramientas y SDK deAWS](https://docs.aws.amazon.com/sdkref/latest/guide/standardized-credentials.html) en la *Guía de referencia de herramientas y SDK de AWS*. ## Solicitud de credenciales a través de un proveedor de identidades de SAML 2.0 La operación de API [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html) devuelve un conjunto de credenciales de seguridad temporales para entidades principales federadas de SAML que han sido autenticadas por el sistema de identidades existente de la organización. Los usuarios también deben utilizar [SAML](https://www.oasis-open.org/standards#samlv2.0) 2.0 (lenguaje de marcado para confirmaciones de seguridad) para transmitir la información de autenticación y autorización a AWS. Esta operación de la API es útil en organizaciones que han integrado sus sistemas de identidad (como Windows Active Directory u OpenLDAP) con software que puede producir aserciones SAML. Esta integración proporciona información sobre los permisos e identidad del usuario (como Active Directory Federation Services o Shibboleth). Para obtener más información, consulte [Federación SAML 2.0](id_roles_providers_saml.md). 1. Llame a la operación [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html). Se trata de una llamada sin firmar, lo que significa que no es necesario autenticar las credenciales de seguridad de AWS antes de realizar la solicitud. **nota** Una llamada a `AssumeRoleWithSAML` no se firma (cifrada). Por lo tanto, solo debe incluir estas políticas de sesión opcionales si la solicitud se transmite a través de un intermediario de confianza. En este caso, alguien podría modificar la política para eliminar las restricciones. 1. Si llama a `AssumeRoleWithSAML`, AWS verifica la autenticidad de la aserción SAML. Suponiendo que el proveedor de identidad valida la aserción, AWS le devuelve la siguiente información: + Un conjunto de credenciales de seguridad temporales. Estas incluyen un ID de clave de acceso, una clave de acceso secreta y un token de sesión. + El ID de rol y el ARN del rol asumido. + Un valor `Audience` que incluye el valor del atributo `Recipient` del elemento `SubjectConfirmationData` de la aserción SAML. + Un valor `Issuer` que incluye el valor del elemento `Issuer` de la aserción SAML. + Un elemento `NameQualifier` que incluye un valor hash creado a partir del valor `Issuer`, el ID de la Cuenta de AWS y el nombre fácil de recordar del proveedor SAML. Cuando se combinan con el elemento `Subject`, pueden identificar de forma única a la entidad principal federada de SAML. + Un elemento `Subject` que incluye el valor del elemento `NameID` en el elemento `Subject` de la aserción SAML. + Un elemento `SubjectType` que indica el formato del elemento `Subject`. El valor puede ser `persistent`, `transient` o la URI completa `Format` de los elementos `Subject` y `NameID` utilizados en su aserción SAML. Para obtener información sobre el atributo `NameID` del elemento `Format`, consulte [Configure aserciones SAML para la respuesta de autenticación](id_roles_providers_create_saml_assertions.md). 1. Utiliza las credenciales de seguridad temporales que se devolvieron en la respuesta para realizar llamadas a la API de AWS. Se trata del mismo proceso que para hacer una llamada a la API de AWS con credenciales de seguridad a largo plazo. La diferencia es que debe incluir el token de sesión, que permite a AWS verificar que las credenciales de seguridad temporales son válidas. La aplicación debe almacenar en caché las credenciales. Las credenciales caducan después de una hora de forma predeterminada. Si no utiliza la acción [AmazonSTSCredentialsProvider](https://aws.amazon.com/blogs/mobile/using-the-amazoncredentialsprovider-protocol-in-the-aws-sdk-for-ios) en el SDK de AWS, depende de usted y de su aplicación volver a llamar a `AssumeRoleWithSAML`. Llame a esta operación para obtener un nuevo conjunto de credenciales de seguridad temporales antes de que caduquen las antiguas. ## Solicitud de credenciales a través de un agente de identidades personalizado La operación de API [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) devuelve un conjunto de credenciales de seguridad temporales para entidades principales de usuario federado de AWS STS. Esta API difiere de `AssumeRole` en que el periodo de vencimiento predeterminado es bastante mayor (12 horas en lugar de una hora). Además, puede utilizar el parámetro `DurationSeconds` para especificar una duración de validez para las credenciales de seguridad temporales. Las credenciales resultantes son válidas durante el tiempo especificado, entre 900 segundos (15 minutos) y 129 600 segundos (36 horas). Un periodo de vencimiento mayor puede ayudar a reducir el número de llamadas a AWS, ya que no es necesario obtener credenciales nuevas con tanta frecuencia. 1. Autentíquese con las credenciales de seguridad de AWS de su usuario de IAM específico. Esta llamada debe realizarse con credenciales de seguridad de AWS válidas. 1. Llame a la operación [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html). La llamada `GetFederationToken` devuelve credenciales de seguridad temporales que incluyen el token de seguridad, la clave de acceso, la clave secreta y el vencimiento. Puede utilizar `GetFederationToken` si desea administrar los permisos de su organización (por ejemplo, la utilización de la aplicación de proxy para asignar permisos). El siguiente ejemplo muestra una solicitud y respuesta de muestra que utiliza `GetFederationToken`. En este ejemplo de solicitud se federa al usuario que llama durante la duración especificada con el ARN de la [póliza de sesión](access_policies.md#policies_session) y las [etiquetas de sesión](id_session-tags.md). La sesión resultante se denomina `Jane-session`. **Example Ejemplo de solicitud** ``` https://sts.amazonaws.com/ ?Version=2011-06-15 &Action=GetFederationToken &Name=Jane-session &PolicyArns.member.1.arn==arn%3Aaws%3Aiam%3A%3A123456789012%3Apolicy%2FRole1policy &DurationSeconds=1800 &Tags.member.1.Key=Project &Tags.member.1.Value=Pegasus &Tags.member.2.Key=Cost-Center &Tags.member.2.Value=12345 &AUTHPARAMS ``` El ARN de la política que se muestra en el ejemplo anterior incluye el siguiente ARN codificado en URL: `arn:aws:iam::123456789012:policy/Role1policy` Además, tenga en cuenta que el parámetro `&AUTHPARAMS` del ejemplo se entiende como marcador de posición para la información de autenticación. Esta es la *firma*, que debe incluir con las solicitudes API de HTTP de AWS. Recomendamos utilizar los [SDK de AWS](https://aws.amazon.com/tools/) para crear solicitudes de API; un beneficio de esto es que los SDK gestionan la firma de solicitudes en su nombre. Si debe crear y firmar manualmente solicitudes de API, diríjase a [Firma de solicitudes de AWS con Signature Version 4](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html) en la *Referencia general de Amazon Web Services* para averiguar cómo firmar una solicitud. Además de las credenciales de seguridad temporales, la respuesta incluye el Nombre de recurso de Amazon (ARN) para el usuario federado y el plazo de vencimiento de las credenciales. **Example Respuesta de ejemplo** ``` AQoDYXdzEPT//////////wEXAMPLEtc764bNrC9SAPBSM22wDOk4x4HIZ8j4FZTwdQW LWsKWHGBuFqwAeMicRXmxfpSPfIeoIYRqTflfKD8YUuwthAx7mSEI/qkPpKPi/kMcGd QrmGdeehM4IC1NtBmUpp2wUE8phUZampKsburEDy0KPkyQDYwT7WZ0wq5VSXDvp75YU 9HFvlRd8Tx6q6fE8YQcHNVXAkiY9q6d+xo0rKwT38xVqr7ZD0u0iPPkUL64lIZbqBAz +scqKmlzm8FDrypNC9Yjc8fPOLn9FX9KSYvKTr4rvx3iSIlTJabIQwj2ICCEXAMPLE== wJalrXUtnFEMI/K7MDENG/bPxRfiCYzEXAMPLEKEY 2019-04-15T23:28:33.359Z AKIAIOSFODNN7EXAMPLE; arn:aws:sts::123456789012:federated-user/Jean 123456789012:Jean 4 c6104cbe-af31-11e0-8154-cbc7ccf896c7 ``` **nota** Una conversión de AWS comprime las políticas de sesión pasadas y las etiquetas de sesión en un formato binario empaquetado que tiene un límite separado. Su solicitud puede fallar para este límite incluso si el texto sin formato cumple con los demás requisitos. El elemento de respuesta `PackedPolicySize` indica por porcentaje lo cerca que están las políticas y etiquetas de su solicitud al límite de tamaño superior. AWS recomienda conceder permisos en el nivel de recursos (por ejemplo, adjuntar una política basada en recursos a un bucket de Amazon S3), puede omitir el parámetro `Policy`. Sin embargo, si no se incluye una política para la entidad principal de usuario federado de AWS STS, las credenciales de seguridad temporales no otorgarán ningún permiso. En este caso, *debe* utilizar las políticas de recursos para conceder acceso a sus recursos de AWS al usuario federado. Por ejemplo, supongamos que el número de Cuenta de AWS es 111122223333 y que dispone de un bucket de Amazon S3 al que desea que Susan obtenga acceso. Las credenciales de seguridad temporales de Susan no incluyen una política para el bucket. En ese caso, tendría que asegurarse de que el bucket tiene una política con un ARN que coincida con el ARN de Susan, como `arn:aws:sts::111122223333:federated-user/Susan`. ## Solicitud de credenciales para usuarios de entornos que no son de confianza La operación de API [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html) devuelve un conjunto de credenciales de seguridad temporales para un usuario de IAM existente. Es útil para proporcionar mayor seguridad, por ejemplo, para permitir las solicitudes de AWS únicamente cuando la función MFA está habilitada para el usuario de IAM. Dado que las credenciales son temporales, proporcionan mayor seguridad cuando se dispone de un usuario de IAM que tiene acceso a los recursos a través de un entorno menos seguro. Algunos ejemplos de entornos menos seguros son un dispositivo móvil o un navegador web. 1. Autentíquese con las credenciales de seguridad de AWS de su usuario de IAM específico. Esta llamada debe realizarse con credenciales de seguridad de AWS válidas. 1. Llame a la operación [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html). 1. `GetSessionToken` devuelve credenciales de seguridad temporales que incluyen un token de sesión, un ID de clave de acceso y una clave de acceso secreta. De forma predeterminada, las credenciales de seguridad temporales de un usuario de IAM son válidas durante un máximo de 12 horas. Sin embargo, puede solicitar una duración mínima de 15 minutos o una duración máxima de 36 horas mediante el parámetro `DurationSeconds`. Por motivos de seguridad, un token para un usuario Usuario raíz de la cuenta de AWS está limitado a una hora. En el siguiente ejemplo se muestra una solicitud y respuesta de muestra que utiliza `GetSessionToken`. La respuesta también incluye el plazo de vencimiento de las credenciales de seguridad temporales. **Example Ejemplo de solicitud** ``` https://sts.amazonaws.com/ ?Version=2011-06-15 &Action=GetSessionToken &DurationSeconds=1800 &AUTHPARAMS ``` El parámetro `AUTHPARAMS` en el ejemplo es un marcador de posición para su *firma*. Una firma es la información de autenticación que debe incluir en las solicitudes de la API HTTP de AWS. Recomendamos utilizar los [SDK de AWS](https://aws.amazon.com/tools/) para crear solicitudes de API; un beneficio de esto es que los SDK gestionan la firma de solicitudes en su nombre. Si debe crear y firmar manualmente solicitudes de API, diríjase a [Firma de solicitudes de AWS con Signature Version 4](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html) en la *Referencia general de Amazon Web Services* para averiguar cómo firmar una solicitud. **Example Respuesta de ejemplo** ``` AQoEXAMPLEH4aoAH0gNCAPyJxz4BlCFFxWNE1OPTgk5TthT+FvwqnKwRcOIfrRh3c/L To6UDdyJwOOvEVPvLXCrrrUtdnniCEXAMPLE/IvU1dYUg2RVAJBanLiHb4IgRmpRV3z rkuWJOgQs8IZZaIv2BXIa2R4OlgkBN9bkUDNCJiBeb/AXlzBBko7b15fjrBs2+cTQtp Z3CYWFXG8C5zqx37wnOE49mRl/+OtkIKGO7fAE wJalrXUtnFEMI/K7MDENG/bPxRfiCYzEXAMPLEKEY 2011-07-11T19:55:29.611Z AKIAIOSFODNN7EXAMPLE 58c5dbae-abef-11e0-8cfe-09039844ac7d ``` De forma opcional, la solicitud `GetSessionToken` puede incluir los valores `SerialNumber` y `TokenCode` para la verificación con autenticación multifactor (MFA) de AWS. Si los valores facilitados son válidos, AWS STS proporciona credenciales de seguridad temporales que incluyen el estado de la autenticación MFA. A continuación, las credenciales de seguridad temporales pueden utilizarse para obtener acceso a las acciones de la API protegidas por MFA o a los sitios web de AWS durante el periodo en que la autenticación MFA sea válida. El siguiente ejemplo muestra una solicitud `GetSessionToken` que incluye un código de verificación de MFA y un número de serie del dispositivo. ``` https://sts.amazonaws.com/ ?Version=2011-06-15 &Action=GetSessionToken &DurationSeconds=7200 &SerialNumber=YourMFADeviceSerialNumber &TokenCode=123456 &AUTHPARAMS ``` **nota** La llamada a AWS STS se puede realizar al punto de conexión global o a cualquiera de los puntos de conexión regionales que active en su Cuenta de AWS. Para obtener más información, consulte la [sección de AWS STS de *Regiones y puntos de enlace*](https://docs.aws.amazon.com/general/latest/gr/rande.html#sts_region). El parámetro `AUTHPARAMS` en el ejemplo es un marcador de posición para su *firma*. Una firma es la información de autenticación que debe incluir en las solicitudes de la API HTTP de AWS. Recomendamos utilizar los [SDK de AWS](https://aws.amazon.com/tools/) para crear solicitudes de API; un beneficio de esto es que los SDK gestionan la firma de solicitudes en su nombre. Si debe crear y firmar manualmente solicitudes de API, diríjase a [Firma de solicitudes de AWS con Signature Version 4](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html) en la *Referencia general de Amazon Web Services* para averiguar cómo firmar una solicitud. # Uso de credenciales temporales con recursos de AWS Puede utilizar credenciales de seguridad temporales para realizar solicitudes programáticas de recursos de AWS mediante AWS CLI o la API de AWS o (mediante los[SDK de AWS](https://aws.amazon.com/tools/)). Las credenciales temporales proporcionan los mismos permisos que las credenciales de seguridad a largo plazo, como las credenciales de usuario de IAM. Sin embargo, hay algunas diferencias: + Cuando realice una llamada utilizando las credenciales de seguridad temporales, la llamada debe incluir un token de sesión, que se devuelve junto con las credenciales temporales en cuestión. AWS utiliza el token de sesión para validar las credenciales de seguridad temporales. + Las credenciales temporales vencen después de un intervalo especificado. Después de que las credenciales temporales venzan, cualquier llamada que hagas con esas credenciales fallará, por lo que deberás generar un nuevo conjunto de credenciales temporales. Las credenciales temporales no pueden extenderse o actualizarse más allá del intervalo original especificado. + Cuando utiliza credenciales temporales para realizar una solicitud, la entidad principal puede incluir un conjunto de etiquetas. Estas etiquetas provienen de etiquetas de sesión y etiquetas asociadas al rol que asume. Para obtener más información acerca de las etiquetas de sesión, consulte [Transferencia de etiquetas de sesión en AWS STS](id_session-tags.md). Si está utilizando los [SDK de AWS](https://aws.amazon.com/tools), [AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/) (AWS CLI) o [Tools for Windows PowerShell](https://aws.amazon.com/powershell), la forma de obtener y usar credenciales de seguridad temporales difiere según el contexto. Si ejecuta código o comandos de la AWS CLI o las Tools for Windows PowerShell en una instancia EC2, puede sacar partido de los roles de Amazon EC2. De lo contrario, puede llamar a una [API de AWS STS](https://docs.aws.amazon.com/STS/latest/APIReference/) para obtener las credenciales temporales y, a continuación, utilizarlas de forma explícita para realizar llamadas a los servicios de AWS. **nota** Puede utilizar AWS Security Token Service (AWS STS) para crear credenciales de seguridad temporales que pueden controlar el acceso a sus recursos de AWS y proporcionárselas a usuarios de confianza. Para obtener más información sobre AWS STS, consulte [Credenciales de seguridad temporales en IAM](id_credentials_temp.md). AWS STS es un servicio global que tiene un punto de enlace predeterminado en `https://sts.amazonaws.com`. Este punto de conexión se encuentra en la región Este de EE. UU. (Norte de Virginia), aunque las credenciales que obtiene de este y otros puntos de conexión son válidas a nivel global. Estas credenciales funcionan con servicios y recursos de cualquier región. También puede optar por realizar llamadas a API de AWS STS a los puntos de enlace de cualquier región compatible. Esto puede reducir la latencia realizando las solicitudes desde servidores de una región que está más cerca de usted. No importa de qué región vienen sus credenciales, funcionan en todo el mundo. Para obtener más información, consulte [Administración de AWS STS en una Región de AWS](id_credentials_temp_enable-regions.md). **Contents** + [Uso de credenciales temporales en instancias Amazon EC2](#using-temp-creds-sdk-ec2-instances) + [Uso de credenciales de seguridad temporales con los SDK de AWS](#using-temp-creds-sdk) + [Uso de credenciales de seguridad temporales con AWS CLI](#using-temp-creds-sdk-cli) + [Uso de credenciales de seguridad temporales con operaciones de API](#RequestWithSTS) + [Más información](#using-temp-creds-more-info) ## Uso de credenciales temporales en instancias Amazon EC2 Si desea ejecutar código o comandos de AWS CLI en una instancia EC2, la forma recomendada de obtener credenciales es utilizar [roles para Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html). Cree un rol de IAM que especifique los permisos que desea conceder a las aplicaciones que se ejecutan en las instancias EC2. Al lanzar la instancia, asocie el rol con la instancia. Las aplicaciones y los comandos de la AWS CLI y las Tools for Windows PowerShell que se ejecutan en la instancia pueden obtener credenciales de seguridad temporales automáticas desde los metadatos de la instancia. No es necesario obtener explícitamente las credenciales de seguridad temporales. Los SDK de AWS, AWS CLI y Tools for Windows PowerShell obtienen automáticamente las credenciales del servicio de metadatos de instancia de EC2 y las utilizan. Las credenciales temporales tienen los permisos que usted defina para el rol asociado a la instancia. Para obtener más información y ejemplos, consulte lo siguiente: + [Uso de roles de IAM para conceder acceso a recursos de AWS en Amazon Elastic Compute Cloud (EC2)](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/java-dg-roles.html) — AWS SDK para Java + [Granting Access Using an IAM Role](https://docs.aws.amazon.com/sdk-for-net/latest/developer-guide/net-dg-hosm.html) — AWS SDK para .NET + [Crear un rol](https://docs.aws.amazon.com/sdk-for-ruby/latest/developer-guide/iam-example-create-role.html): AWS SDK para Ruby ## Uso de credenciales de seguridad temporales con los SDK de AWS Para utilizar credenciales de seguridad temporales en el código, se llama mediante programación a una API AWS STS similar a `AssumeRole` y se extraen las credenciales y el token de sesión resultantes. A continuación, utilice esos valores como credenciales para las llamadas posteriores a AWS. En el siguiente ejemplo se muestra un pseudocódigo en el que se indica cómo utilizar credenciales de seguridad temporales si utiliza un SDK de AWS: ``` assumeRoleResult = AssumeRole(role-arn); tempCredentials = new SessionAWSCredentials( assumeRoleResult.AccessKeyId, assumeRoleResult.SecretAccessKey, assumeRoleResult.SessionToken); s3Request = CreateAmazonS3Client(tempCredentials); ``` Para ver un ejemplo escrito en Python (usando [AWS SDK para Python (Boto)](https://aws.amazon.com/sdk-for-python/)), consulte [Cambiar a un rol de IAM (API de AWS)](id_roles_use_switch-role-api.md). En este ejemplo se muestra cómo llamar a `AssumeRole` para obtener credenciales de seguridad temporales y, a continuación, utilizar esas credenciales para realizar una llamada a Amazon S3. Para obtener más información sobre cómo llamar a `AssumeRole`, `GetFederationToken` y otras operaciones de API, consulte la [Referencia de la API de AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/). Para obtener información sobre cómo obtener las credenciales de seguridad temporales y el token de sesión a partir del resultado, consulte la documentación para el SDK con el que esté trabajando. Encontrará la documentación para todos los SDK de AWS en la [página de documentación de AWS](https://aws.amazon.com/documentation) principal, en la sección **SDK y conjuntos de herramientas**. Debe asegurarse de que obtiene un nuevo conjunto de credenciales antes de que caduquen las antiguas. En algunos SDK, puede utilizar un proveedor que administre en su nombre el proceso de actualización de credenciales; compruebe la documentación del SDK que esté utilizando. ## Uso de credenciales de seguridad temporales con AWS CLI Puede utilizar las de credenciales de seguridad temporales con AWS CLI. Esto puede resultar útil para probar políticas. Mediante la [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/), puede llamar a una [API de AWS STS](https://docs.aws.amazon.com/STS/latest/APIReference/) como `AssumeRole` o `GetFederationToken` y, a continuación, capturar la salida resultante. En el siguiente ejemplo se muestra una llamada a `AssumeRole` que envía la salida a un archivo. En el ejemplo, se supone que el parámetro `profile` es un perfil en el archivo de configuración de AWS CLI. También se supone que hace referencia a las credenciales de un usuario de IAM que tiene permisos para asumir el rol. ``` aws sts assume-role --role-arn arn:aws:iam::123456789012:role/role-name --role-session-name "RoleSession1" --profile IAM-user-name > assume-role-output.txt ``` Cuando el comando está terminado, puede extraer el ID de clave de acceso, clave de acceso secreta y token de sesión del lugar en el que lo haya enrutado. Puede hacerlo manualmente o mediante un script. A continuación, puede asignar estos valores a las variables de entorno. Cuando ejecuta comandos AWS CLI, AWS CLI buscará credenciales en un orden determinado, primero en las variables de entorno y, a continuación, en el archivo de configuración. Por lo tanto, cuando haya colocado las credenciales temporales en las variables de entorno, AWS CLI utilizará dicha credenciales de forma predeterminada (Si especifica un parámetro `profile` en el comando, la AWS CLI omite las variables de entorno. En lugar de eso, el AWS CLI busca en el archivo de configuración, que le permite anular las credenciales en las variables de entorno, en el caso de ser necesario). En el siguiente ejemplo se muestra cómo puede establecer las variables de entorno para las credenciales de seguridad temporales y, a continuación, llamar a un comando de AWS CLI. Dado que no se incluye el parámetro `profile` en el comando de AWS CLI, AWS CLI busca primero credenciales en las variables de entorno y, de este modo, utiliza las credenciales temporales. **Linux** ``` $ export AWS_ACCESS_KEY_ID=ASIAIOSFODNN7EXAMPLE $ export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY $ export AWS_SESSION_TOKEN=AQoDYXdzEJr... $ aws ec2 describe-instances --region us-west-1 ``` **Windows** ``` C:\> SET AWS_ACCESS_KEY_ID=ASIAIOSFODNN7EXAMPLE C:\> SET AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY C:\> SET AWS_SESSION_TOKEN=AQoDYXdzEJr... C:\> aws ec2 describe-instances --region us-west-1 ``` ## Uso de credenciales de seguridad temporales con operaciones de API Si está realizando solicitudes directas de la API HTTPS a AWS, puede firmar dichas solicitudes con las credenciales de seguridad temporales que obtiene del AWS Security Token Service (AWS STS). Para ello, utilice el ID de clave de acceso y la clave de acceso secreta que recibe de AWS STS. Utilice el ID de clave de acceso y la clave de acceso secreta de la misma forma que utilizaría las credenciales a largo plazo para firmar una solicitud. También puede añadir a su solicitud de la API el token de sesión que reciba de AWS STS. Puede añadir el token de sesión a un encabezado HTTP o a un parámetro de cadena de consulta denominado `X-Amz-Security-Token`. Añada el token de sesión al encabezado HTTP *o* al parámetro de cadena de consulta, pero no a ambos. Para obtener más información sobre la firma de las solicitudes de la API HTTPS, consulte [Firma de solicitudes de la API de AWS](https://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html) en la *Referencia general de AWS*. ## Más información Para obtener más información acerca de AWS STS con otros servicios de AWS, consulte los siguientes vínculos: + **Amazon S3**. Consulte [Realización de solicitudes con las credenciales temporales de usuario de IAM](https://docs.aws.amazon.com/AmazonS3/latest/userguide/AuthUsingTempSessionToken.html) o [Realización de solicitudes con credenciales temporales de usuario federado](https://docs.aws.amazon.com/AmazonS3/latest/userguide/AuthUsingTempFederationToken.html) en la *Guía del usuario de Amazon Simple Storage Service*. + **de Amazon SNS**. Consulte [Uso de políticas basadas en identidades con Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/UsingIAMwithSNS.html#UsingTemporarySecurityCredentials_SNS) en la *Guía para desarrolladores de Amazon Simple Queue Service*. + **Amazon SQS**. Consulte [Administración de identidades y acceso en Amazon SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/UsingIAM.html#UsingTemporarySecurityCredentials_SQS) en la *Guía para desarrolladores de Amazon Simple Queue Service*. + **Amazon SimpleDB**. Consulte [Utilizar credenciales de seguridad temporales](https://docs.aws.amazon.com/AmazonSimpleDB/latest/DeveloperGuide/index.html?UsingTemporarySecurityCredentials_SDB.html) en la *Guía para desarrolladores de Amazon SimpleDB*. # Permisos para credenciales de seguridad temporales Puede utilizar AWS Security Token Service (AWS STS) para crear credenciales de seguridad temporales que pueden controlar el acceso a sus recursos de AWS y proporcionárselas a usuarios de confianza. Para obtener más información acerca de AWS STS, consulte [Credenciales de seguridad temporales en IAM](id_credentials_temp.md). Las credenciales de seguridad temporales que emite AWS STS son válidas durante el periodo de vencimiento y no se pueden revocar. Sin embargo, los permisos asignados a credenciales de seguridad temporales se evalúan cada vez que una solicitud utiliza las credenciales, por lo que puede conseguir el efecto de revocar las credenciales cambiando sus permisos de acceso incluso después de que se hayan emitido. En los siguientes temas se presupone que tiene experiencia trabajando con permisos y políticas de AWS. Para obtener más información sobre estos temas, consulte [Recursos de AWS para administración de acceso](access.md). **Topics** + [Permisos de AssumeRole, AssumeRoleWithSAML y AssumeRoleWithWebIdentity](id_credentials_temp_control-access_assumerole.md) + [Monitorear y controlar las acciones realizadas con roles asumidos](id_credentials_temp_control-access_monitor.md) + [Permisos para GetFederationToken](id_credentials_temp_control-access_getfederationtoken.md) + [Permisos para GetSessionToken](id_credentials_temp_control-access_getsessiontoken.md) + [Deshabilitar permisos para credenciales de seguridad temporales](id_credentials_temp_control-access_disable-perms.md) + [Concesión de permisos para crear credenciales de seguridad temporales](id_credentials_temp_control-access_enable-create.md) + [Concesión de permisos para usar sesiones de consola con identidad mejorada](id_credentials_temp_control-access_sts-setcontext.md) # Permisos de AssumeRole, AssumeRoleWithSAML y AssumeRoleWithWebIdentity La política de permisos del rol que se asume determina los permisos de las credenciales de seguridad temporales devueltas por `AssumeRole`, `AssumeRoleWithSAML` y `AssumeRoleWithWebIdentity`. Defina estos permisos al crear o actualizar el rol. De forma opcional, puede pasar [políticas de sesión](access_policies.md#policies_session) administradas o insertadas como parámetros de las operaciones de API `AssumeRole`, `AssumeRoleWithSAML` o `AssumeRoleWithWebIdentity`. Las políticas de sesión limitan los permisos para la sesión de credenciales temporales de la función. Los permisos de la sesión resultantes son la intersección de las políticas basadas en identidades de la función y las políticas de la sesión. Puede utilizar las credenciales temporales del rol en llamadas posteriores a la API de AWS para tener acceso a los recursos de la cuenta propietaria del rol. No puede utilizar las políticas de sesión para conceder más permisos que los permitidos por la política basada en identidades de la función que se asume. Para obtener más información sobre cómo determina AWS los permisos efectivos de un rol, consulte [Lógica de evaluación de políticas](reference_policies_evaluation-logic.md). ![\[PermissionsWhenPassingRoles_Diagram\]](http://docs.aws.amazon.com/es_es/IAM/latest/UserGuide/images/role_passed_policy_permissions.png) `AssumeRole` no evalúa las políticas asociadas a las credenciales con las que se hizo la llamada original a AWS para tomar la decisión de autorización "permitir" o "denegar". El usuario abandona temporalmente sus permisos originales en favor de los permisos asignados al rol asumido. En el caso de las operaciones de API `AssumeRoleWithSAML` y `AssumeRoleWithWebIdentity`, no existen políticas que evaluar, porque el intermediario de la API no es una identidad de AWS. ## Ejemplo: asignación de permisos utilizando AssumeRole Puede utilizar la operación de API `AssumeRole` con diferentes tipos de políticas. A continuación se ofrecen algunos ejemplos. ### Política de permisos del rol En este ejemplo, se llama a la operación de API `AssumeRole` sin especificar la política de sesión en el parámetro opcional `Policy`. Los permisos asignados a las credenciales temporales vienen determinados por la política de permisos del rol que se asume. En el ejemplo siguiente, la política de permisos concede el permiso de rol para enumerar todos los objetos contenidos en un bucket de S3 denominado `productionapp`. También permite al rol obtener, agregar y eliminar objetos en ese bucket. **Example Ejemplo de política de permisos del rol** **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::productionapp" }, { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:DeleteObject" ], "Resource": "arn:aws:s3:::productionapp/*" } ] } ``` ### Política de sesión pasada como parámetro Imagine que desea permitir a un usuario asumir el mismo rol que en el ejemplo anterior. Sin embargo, en este caso desea que la sesión del rol solo tenga permiso para obtener y colocar objetos en el bucket de S3 `productionapp`. No desea permitirle eliminar objetos. Una forma de conseguirlo es crear un nuevo rol y especificar los permisos deseados en su política de permisos. Otra forma de conseguirlo consiste en llamar a la API `AssumeRole` e incluir políticas de sesión en el parámetro opcional `Policy` como parte de la llamada a la operación de API. Los permisos de la sesión resultantes son la intersección de las políticas basadas en identidades del rol y las políticas de la sesión. Las políticas de sesión no se pueden utilizar para conceder más permisos que los permitidos por la política basada en identidades del rol que se asume. Para obtener más información sobre los permisos de sesión de un rol, consulte [Políticas de sesión](access_policies.md#policies_session). Después de recuperar las credenciales temporales de la nueva sesión, puede pasarlas al usuario que desea que tenga esos permisos. Por ejemplo, imagine que las siguientes políticas se transfieren como parámetro de la llamada a la API. La persona que ha iniciado la sesión solo tiene permisos para ejecutar las acciones siguientes: + Realizar una lista de todos los objetos del bucket `productionapp`. + Obtener y colocar objetos en el bucket `productionapp`. Con la política de sesión siguiente, el permiso `s3:DeleteObject` se descarta y en la sesión no se concede el permiso `s3:DeleteObject`. La política establece los permisos máximos para la sesión del rol, anulando todas las políticas de permisos que tuviera el rol. **Example Ejemplo de política de sesión pasada con la llamada a la API `AssumeRole`** **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::productionapp" }, { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject" ], "Resource": "arn:aws:s3:::productionapp/*" } ] } ``` ### Política basada en recursos Algunos recursos de AWS admiten políticas basadas en recursos y dichas políticas proporcionan otro mecanismo para definir los permisos que afectan directamente a las credenciales de seguridad temporales. Solo unos pocos recursos, como buckets de Amazon S3, temas de Amazon SNS y colas de Amazon SQS admiten políticas basadas en recursos. El siguiente ejemplo amplía los ejemplos anteriores y utiliza un bucket de S3 denominado `productionapp`. La política siguiente se asocia al bucket. Al adjuntar la siguiente política basada en recursos al bucket `productionapp`, se deniega a *todos* los usuarios el permiso para eliminar objetos del bucket. (Consulte el elemento `Principal` en la política). Esto incluye todos los usuarios con el rol asumido, aunque la política de permisos de rol conceda el permiso `DeleteObject`. Una instrucción `Deny` explícita siempre prevalece sobre una instrucción `Allow`. **Example Ejemplo de política de bucket** **** ``` { "Version":"2012-10-17", "Statement": { "Principal": {"AWS": "*"}, "Effect": "Deny", "Action": "s3:DeleteObject", "Resource": "arn:aws:s3:::productionapp/*" } } ``` Para obtener más información sobre el modo en que AWS combina y evalúa varios tipos de políticas, consulte [Lógica de evaluación de políticas](reference_policies_evaluation-logic.md). # 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*. # Permisos para GetFederationToken Un usuario de IAM llama a la operación `GetFederationToken` y devuelve credenciales temporales para ese usuario. Esta operación *federa* al usuario. Los permisos asignados a una sesión de usuario federado de AWS STS se definen en uno de los siguientes dos lugares: + Las políticas de sesión que se pasan como parámetro en la llamada a la API `GetFederationToken`. (Este es el caso más frecuente). + Una política basada en recursos que nombra explícitamente la sesión de usuario federado de AWS STS en el elemento `Principal` de la política. (Este es el caso menos frecuente). Las políticas de sesión son políticas avanzadas que se pasan como parámetros cuando se crea una sesión temporal mediante programación. Al crear una sesión de usuario federado de AWS STS y transmitir políticas de sesión, los permisos de la sesión resultante son la intersección entre la política basada en identidades del usuario y las políticas de sesión. No puede utilizar la política de sesión para conceder más permisos que los permitidos por la política basada en identidades del usuario que se federa. En la mayoría de los casos, si no transfiere una política con la llamada a la API `GetFederationToken`, las credenciales de seguridad temporales obtenidas no tendrán permisos. Sin embargo, una política basada en recursos puede proporcionar permisos adicionales para la sesión. Puede acceder a un recurso con una política basada en recursos que especifica la sesión como el principal permitido. Las figuras siguientes muestran una representación visual de cómo las políticas interactúan para determinar los permisos de las credenciales de seguridad temporales devueltos por una llamada a `GetFederationToken`. ![\[Usuario de IAM: las siguientes ilustraciones muestran marcas de verificación para indicar que los permisos de sesión son la intersección entre la política basada en identidades del usuario y las políticas de sesión. Los permisos de sesión también pueden ser la intersección de las políticas basadas en identidades del usuario y las políticas basadas en recursos.\]](http://docs.aws.amazon.com/es_es/IAM/latest/UserGuide/images/getfederationtoken-permissions.diagram.png) ## Ejemplo: asignación de permisos con GetFederationToken Puede utilizar la acción de la API `GetFederationToken` con diferentes tipos de políticas. A continuación se ofrecen algunos ejemplos. ### Política asociada al usuario de IAM En este ejemplo, tiene una aplicación cliente basada en navegador que se utiliza dos servicios web de backend. Un servicio de backend es su propio servidor de autenticación, que utiliza su propio sistema de identidad para autenticar la aplicación de cliente. El otro servicio de backend es un servicio de AWS que proporciona algunas de las funcionalidades de la aplicación cliente. Su servidor autentica la aplicación cliente y crea o recupera la política de permisos correspondiente. A continuación, llama a la API `GetFederationToken` para obtener credenciales de seguridad temporales y devuelve dichas credenciales a la aplicación cliente. Esta puede realizar solicitudes directamente al servicio de AWS con las credenciales de seguridad temporales. Esta arquitectura permite a la aplicación cliente realizar solicitudes de AWS sin integrar credenciales de AWS a largo plazo. El servidor de autenticación llama a la API de `GetFederationToken` con las credenciales de seguridad a largo plazo de un usuario IAM llamado `token-app`. Sin embargo, las credenciales de usuario de IAM a largo plazo permanecen en el servidor y nunca se distribuyen al cliente. La siguiente política de ejemplo se asocia al usuario de IAM `token-app` y define el conjunto más amplio de permisos que necesitarán los usuarios federados de AWS STS (clientes). Tenga en cuenta que se requiere el permiso `sts:GetFederationToken` para que el servicio de autenticación obtenga credenciales de seguridad temporales para los usuarios federados de AWS STS. **Example Ejemplo de política asociada al usuario de IAM `token-app` que llama a `GetFederationToken`** **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:GetFederationToken", "Resource": "*" }, { "Effect": "Allow", "Action": "dynamodb:ListTables", "Resource": "*" }, { "Effect": "Allow", "Action": "sqs:ReceiveMessage", "Resource": "*" }, { "Effect": "Allow", "Action": "s3:ListBucket", "Resource": "*" }, { "Effect": "Allow", "Action": "sns:ListSubscriptions", "Resource": "*" } ] } ``` La política anterior concede varios permisos al usuario de IAM. Sin embargo, esta política por sí sola no concede ningún permiso al usuario federado de AWS STS. Si este usuario de IAM llama a `GetFederationToken` y no transfiere una política como parámetro de la llamada a la API, el usuario federado de AWS STS obtenido no tendrá permisos efectivos. ### Política de sesión pasada como parámetro La manera más habitual de asegurarse de que al usuario federado de AWS STS se le asignen los permisos adecuados es incluir políticas de sesión en la llamada a la API `GetFederationToken`. Profundizando en el ejemplo anterior, supongamos que `GetFederationToken` se llama con las credenciales del usuario de IAM `token-app`. Entonces, imagine que las siguientes políticas de sesión se transfieren como parámetro de la llamada a la API. El usuario federado de AWS STS resultante tiene permiso para enumerar el contenido del bucket de Amazon S3 denominado `productionapp`. El usuario no puede realizar las acciones de Amazon S3 `GetObject`, `PutObject`, y `DeleteObject` en elementos del bucket `productionapp`. Estos permisos se asignan al usuario federado porque son la intersección de las políticas del usuario de IAM y las políticas de la sesión que transfiere. El usuario federado de AWS STS no pudo realizar acciones en Amazon SNS, Amazon SQS, Amazon DynamoDB ni en ningún bucket de S3, excepto en `productionapp`. Estas acciones se deniegan a pesar de que el usuario de IAM asociado a la llamada a `GetFederationToken` cuenta con los permisos correspondientes. **Example Ejemplo de política de sesión transferida como parámetro de la llamada a la API `GetFederationToken`.** **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["s3:ListBucket"], "Resource": ["arn:aws:s3:::productionapp"] }, { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:DeleteObject" ], "Resource": ["arn:aws:s3:::productionapp/*"] } ] } ``` ### Políticas basadas en recursos Algunos recursos de AWS permiten el uso de políticas basadas en recursos, las cuales ofrecen un mecanismo adicional para conceder permisos directamente a un usuario federado de AWS STS. Solo algunos servicios de AWS admiten políticas basadas en recursos. Por ejemplo, Amazon S3 tiene buckets, Amazon SNS tiene temas y Amazon SQS tiene colas a las que puede asociar políticas. Para obtener una lista de todos los servicios que admiten políticas basadas en recursos, consulte [Servicios de AWS que funcionan con IAM](reference_aws-services-that-work-with-iam.md) y observe la columna de políticas basadas en recursos de las tablas. Puede utilizar políticas basadas en recursos para asignar permisos directamente a un usuario federado de AWS STS. Para ello, debe especificar el Nombre de recurso de Amazon (ARN) del usuario federado de AWS STS en el elemento `Principal` de la política basada en recursos. El siguiente ejemplo ilustra esto y amplía los ejemplos anteriores, utilizando un bucket de S3 denominado `productionapp`. La política basada en recursos siguiente se asocia al bucket. Esta política del bucket permite a una usuaria federada de AWS STS llamada Carol obtener acceso al bucket. Cuando la política de ejemplo descrita anteriormente se asocia al usuario de IAM `token-app`, la usuaria federada de AWS STS, llamada Carol, tiene permiso para realizar las acciones `s3:GetObject`, `s3:PutObject` y `s3:DeleteObject` en el bucket denominado `productionapp`. Esto es válido incluso cuando no se pasa ninguna política de sesión como parámetro en la llamada a la API `GetFederationToken`. En este caso, la explicación radica en que la siguiente política basada en recursos ha concedido permisos explícitos a la usuaria federada de AWS STS denominada Carol. Recuerde, solo se conceden permisos a un usuario federado de AWS STS cuando estos se conceden de forma explícita tanto al usuario de IAM ***como*** al usuario federado de AWS STS. También se pueden conceder (dentro de la cuenta) mediante una política basada en recursos que nombre explícitamente al usuario federado de AWS STS en el elemento `Principal` de la política, como en el siguiente ejemplo. **Example Ejemplo de política de bucket que permite el acceso a un usuario federado** **** ``` { "Version":"2012-10-17", "Statement": { "Principal": { "AWS": "arn:aws:sts::111122223333:federated-user/Carol" }, "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:DeleteObject" ], "Resource": [ "arn:aws:s3:::productionapp/*" ] } } ``` Para obtener más información sobre cómo se evalúan las políticas, consulte [Policy evaluation logic](reference_policies_evaluation-logic.md) (Lógica de evaluación de las políticas). # Permisos para GetSessionToken La ocasión principal para llamar a la operación de API `GetSessionToken` o al comando `get-session-token` de la CLI es cuando un usuario debe autenticarse con la autenticación multifactor (MFA). Se puede escribir una política que permite determinadas acciones solo cuando dichas acciones las solicita un usuario autenticado con MFA. Para transferir correctamente la comprobación de autorización MFA, el usuario debe llamar primero a `GetSessionToken` e incluir los parámetros adicionales `SerialNumber` y `TokenCode`. Si el usuario se ha autenticado correctamente con un dispositivo MFA, las credenciales devueltas por la operación de API `GetSessionToken` incluyen el contexto de MFA. Este contexto indica que el usuario se ha autenticado con MFA y está autorizado a realizar operaciones de API que requieren la autenticación MFA. ## Permisos requeridos para GetSessionToken No se requiere ningún permiso para que un usuario obtenga un token de sesión. La finalidad de la operación `GetSessionToken` es autenticar al usuario mediante MFA. No se pueden utilizar políticas para controlar las operaciones de autenticación. Para conceder permisos para realizar la mayoría de las operaciones de AWS, es preciso agregar la acción del mismo nombre a una política. Por ejemplo, para crear un usuario, debe utilizar la operación API `CreateUser`, el comando `create-user` de la CLI o la Consola de administración de AWS. Para realizar estas operaciones, debe disponer de una política que le permita obtener acceso a la acción `CreateUser`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "iam:CreateUser", "Resource": "*" } ] } ``` ------ Puede incluir la acción `GetSessionToken` en sus políticas, pero no tiene efecto en la capacidad de un usuario para realizar la operación `GetSessionToken`. ## Permisos concedidos por GetSessionToken Si se llama a `GetSessionToken` con las credenciales de un usuario de IAM, las credenciales de seguridad temporales tienen los mismos permisos que el usuario de IAM. Del mismo modo, si se llama a `GetSessionToken` con credenciales de Usuario raíz de la cuenta de AWS, las credenciales de seguridad temporales tienen permisos de usuario raíz. **nota** Se recomienda evitar el uso de las credenciales de usuario raíz para llamar a `GetSessionToken`. En lugar de esto, siga nuestras [prácticas recomendadas](best-practices-use-cases.md) y cree uno o más usuarios de IAM con los permisos que necesitan. A continuación, utilice estos usuarios de IAM para la interacción diaria con AWS. Las credenciales temporales que obtiene si llama a `GetSessionToken` tienen las siguientes funciones y limitaciones: + Puede utilizar las credenciales para acceder a la Consola de administración de AWS transmitiendo las credenciales al punto de enlace de inicio de sesión único de la federación en `https://signin.aws.amazon.com/federation`. Para obtener más información, consulte [Permitir el acceso del agente de identidades personalizadas a la consola de AWS](id_roles_providers_enable-console-custom-url.md). + Las credenciales **no** se pueden utilizar para llamar a las operaciones de API de AWS STS o IAM. **Puede** utilizarlas para llamar a las operaciones de API de otros servicios de AWS. Compare esta operación de API y sus limitaciones y posibilidades con las demás operaciones de API que crean credenciales de seguridad temporales en . [Comparación de credenciales AWS STS](id_credentials_sts-comparison.md) Para obtener más información sobre el acceso mediante API protegidas por MFA utilizando `GetSessionToken`, consulte [Acceso seguro a la API con MFA](id_credentials_mfa_configure-api-require.md). # Deshabilitar permisos para credenciales de seguridad temporales Las credenciales de seguridad temporales son válidas hasta que caducan. Estas credenciales son válidas durante el tiempo especificado, desde 900 segundos (15 minutos) hasta un máximo de 129 600 segundos (36 horas). La duración predeterminada de una sesión es de 43 200 segundos (12 horas). Puede revocar estas credenciales, pero también debe cambiar los permisos del usuario o rol de IAM para evitar que se utilicen credenciales comprometidas para actividades maliciosas en la cuenta. Los permisos asignados a las credenciales de seguridad temporales se evalúan cada vez que se utilizan para realizar una solicitud de AWS. Una vez que haya eliminado todos los permisos de las credenciales, las solicitudes de AWS que las utilizan fallarán. Es posible que las actualizaciones de la política tarden unos minutos en hacerse efectivas. Para sesiones de rol de IAM, puede revocar las credenciales de seguridad temporales del rol para forzar a todos los usuarios que lo asumieron a volver a autenticarse y solicitar nuevas credenciales. Para obtener más información, consulte [Revocar las credenciales de seguridad temporales del rol](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html). No puede cambiar los permisos para un usuario Usuario raíz de la cuenta de AWS. Del mismo modo, no puede cambiar los permisos de las credenciales de seguridad temporales que se han creado llamando a `GetFederationToken` o `GetSessionToken` al iniciar sesión como usuario raíz. Por este motivo, le recomendamos que no llame a `GetFederationToken` ni a `GetSessionToken` como usuario raíz. Para conocer los procedimientos sobre cómo cambiar los permisos de un usuario de IAM, consulte [Cambio de los permisos de un usuario de IAM](id_users_change-permissions.md). Para conocer los procedimientos sobre cómo cambiar los permisos de un rol de IAM, consulte [Actualización de los permisos de un rol](id_roles_update-role-permissions.md). **importante** No puede editar los roles en IAM que se hayan creado a partir de conjuntos de permisos del IAM Identity Center. Debe revocar la sesión del conjunto de permisos activo para un usuario en el IAM Identity Center. Para obtener más información, consulte [Revocar sesiones de rol de IAM creadas por conjuntos de permisos](https://docs.aws.amazon.com/singlesignon/latest/userguide/useraccess.html#revoke-user-permissions) en la *Guía del usuario de IAM Identity Center*. **Topics** + [Denegar el acceso a todas las sesiones de rol de IAM asociadas a un rol](#deny-access-to-all-sessions) + [Denegar el acceso a una sesión específica de rol de IAM](#deny-access-to-specific-session) + [Denegar el acceso a sesiones de credenciales de seguridad temporales con claves de contexto de condiciones](#deny-access-to-specific-session-condition-key) + [Denegar el acceso a una entidad principal específica con políticas basadas en recursos](#deny-access-with-resource-based) ## Denegar el acceso a todas las sesiones de rol de IAM asociadas a un rol Este procedimiento deniega permisos a **todas** las sesiones de rol de IAM asociadas a un rol. Utilice este enfoque cuando le preocupe el acceso sospechoso por parte de: + Entidades principales de otra cuenta que utilizan el acceso entre cuentas + Identidades de usuarios externos con permisos para acceder a recursos de AWS en su cuenta + Usuarios que se han autenticado en una aplicación Web o móvil con un proveedor de OIDC A fin de cambiar o eliminar los permisos asignados a las credenciales de seguridad temporales que se obtienen al llamar a `AssumeRole`, `AssumeRoleWithSAML`, `AssumeRoleWithWebIdentity`, `GetFederationToken` o `GetSessionToken`, puede editar o eliminar la política basada en identidades que define los permisos para el rol. **importante** Si hay una política basada en recursos que permite el acceso de una entidad principal, también debe agregar una denegación explícita para ese recurso. Para obtener más información, consulte [Denegar el acceso a una entidad principal específica con políticas basadas en recursos](#deny-access-with-resource-based). **Para denegar el acceso a **todas** las sesiones de rol de IAM asociadas a un rol** 1. Inicie sesión en la Consola de administración de AWS y abra la consola de IAM. 1. Seleccione **Roles** en el panel de navegación. 1. Elija el nombre del rol que desea editar. Puede utilizar el cuadro de búsqueda para filtrar la lista. 1. Elija la pestaña **Permisos**. 1. Seleccione la política correspondiente que desea editar. Antes de editar una política administrada por el cliente, revise la pestaña **Entidades asociadas** para evitar interrumpir el acceso a otras identidades que puedan tener la misma política asociada. 1. Elija la pestaña **JSON** y actualice la política para denegar todos los recursos y acciones. **nota** Estos permisos son los mismos que los de la política administrada por AWS [AWSDenyAll](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSDenyAll.html). Puede asociar esta política administrada por AWS a cualquier usuario o rol de IAM al que desee denegar todo acceso. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DenyAll", "Effect": "Deny", "Action": [ "*" ], "Resource": "*" } ] } ``` ------ 1. En la página **Review (Revisar)**, revise el **Summary (Resumen)** de la política y seleccione **Save changes (Guardar cambios)** para guardar su trabajo. Al editar la política, los cambios afectan a los permisos de todas las credenciales de seguridad temporales asociadas al rol, incluidas las credenciales que se han emitido antes de cambiar la política de permisos del rol. Después de actualizar la política, puede [revocar las credenciales de seguridad temporales del rol](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html) para revocar de inmediato todos los permisos de las credenciales que ha emitido el rol. ## Denegar el acceso a una sesión específica de rol de IAM Cuando se actualizan los roles de IAM con una política de denegar todo o se elimina el rol por completo, todos los usuarios que tienen acceso al rol se verán afectados. Puede denegar el acceso sin que esto afecte a los permisos de todas las demás sesiones asociadas al rol. Se pueden denegar permisos a `Principal` mediante [claves de contexto de condición](#deny-access-to-specific-session-condition-key) o [políticas basadas en recursos](#deny-access-with-resource-based). **sugerencia** Puede encontrar los ARN de los usuarios federados mediante los registros de AWS CloudTrail. Para obtener más información, consulte [Cómo identificar con facilidad a sus usuarios federados mediante AWS CloudTrail](https://aws.amazon.com/blogs/security/how-to-easily-identify-your-federated-users-by-using-aws-cloudtrail/). ## Denegar el acceso a sesiones de credenciales de seguridad temporales con claves de contexto de condiciones Puede utilizar claves de contexto de condición en políticas basadas en identidades en casos en los que desee denegar el acceso a sesiones de credenciales de seguridad temporales específicas sin afectar a los permisos del usuario o rol de IAM que creó las credenciales. En el caso de los roles de IAM, después de actualizar la política, también podrá [revocar las sesiones de credenciales de seguridad temporales](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html) del rol para revocar inmediatamente todas las credenciales emitidas. Para obtener más información sobre las claves de contexto de condición, consulte [Claves de contexto de condición globales de AWS](reference_policies_condition-keys.md). ### aws:PrincipalArn Puede utilizar la clave de contexto de condición [aws:PrincipalArn](reference_policies_condition-keys.md#condition-keys-principalarn) en una política basada en identidades para denegar el acceso a una entidad principal específica por su nombre de recurso de Amazon (ARN). Para ello, especifique el ARN de la sesión de usuario federado AWS STS, rol o usuario de IAM al que se encuentran asociadas las credenciales de seguridad temporales en el elemento Condición de una política. **Para denegar el acceso a una entidad principal específica por su ARN** 1. En el panel de navegación de la consola de IAM, elija **Usuarios** o **Roles**. 1. Elija el nombre del usuario o rol de IAM que desea editar. Puede utilizar el cuadro de búsqueda para filtrar la lista. 1. Elija la pestaña **Permisos**. 1. Seleccione la política correspondiente que desea editar. Antes de editar una política administrada por el cliente, revise la pestaña **Entidades asociadas** para evitar interrumpir el acceso a otras identidades que puedan tener la misma política asociada. 1. Elija la pestaña **JSON** y agregue una instrucción de denegación para el ARN de la entidad principal, como se muestra en el siguiente ejemplo. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "*", "Resource": "*", "Condition": { "ArnEquals": { "aws:PrincipalArn": [ "arn:aws:iam::222222222222:role/ROLENAME", "arn:aws:iam::222222222222:user/USERNAME", "arn:aws:iam::222222222222:federated-user/USERNAME" ] } } } ] } ``` ------ 1. En la página **Review (Revisar)**, revise el **Summary (Resumen)** de la política y seleccione **Save changes (Guardar cambios)** para guardar su trabajo. ### aws:SourceIdentity Puede utilizar la clave de contexto de condición [aws:SourceIdentity](reference_policies_condition-keys.md#condition-keys-sourceidentity) en una política basada en identidades para denegar el acceso a una identidad de origen específica asociada a una sesión de rol de IAM. Esto se aplica siempre que la sesión de rol se haya emitido al configurar el parámetro de solicitud `SourceIdentity` cuando la entidad principal asumió un rol mediante cualquier comando de la CLI AWS STS `assume-role`\$1 u operación de la API AWS STS `AssumeRole`\$1. Para ello, especifique la identidad de origen a la que se encuentran asociadas las credenciales de seguridad temporales en el elemento `Condition` de una política. A diferencia de la clave de contexto [sts:RoleSessionName](reference_policies_iam-condition-keys.md#ck_rolesessionname), después de establecer la identidad de origen, el valor no se puede cambiar. La clave `aws:SourceIdentity` se encuentra presente en el contexto de la solicitud de todas las acciones tomadas por el rol. La identidad de origen persiste en sesiones de rol posteriores cuando se utilizan las credenciales de sesión para asumir otro rol. Asumir un rol de otro se llama [encadenamiento de roles](id_roles.md#iam-term-role-chaining). En la siguiente política se muestra un ejemplo de cómo puede denegar el acceso a las sesiones de credenciales de seguridad temporales mediante la clave de contexto de condición `aws:SourceIdentity`. Si especifica la identidad de origen asociada con una sesión de rol, se denegarán las sesiones de rol con la identidad de origen mencionada sin afectar los permisos del rol que creó las credenciales. Para este ejemplo, la identidad de origen que estableció la entidad principal cuando se emitió la sesión de rol es `nikki_wolf@example.com`. Cualquier solicitud realizada por una sesión de rol con la identidad de origen `nikki_wolf@example.com` será rechazada porque la identidad de origen está incluida en la condición de la política y la política Effect se estableció en `Deny`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "*", "Resource": "*", "Condition": { "StringLike": { "aws:SourceIdentity": [ "nikki_wolf@example.com", "" ] } } } ] } ``` ------ ### aws:userid Puede utilizar la clave de contexto de condición [aws:userid](reference_policies_condition-keys.md#condition-keys-userid) en una política basada en identidades para denegar el acceso a todas las sesiones de credenciales de seguridad temporales o a sesiones específicas asociadas con el usuario o rol de IAM. Para ello, especifique el identificador único (ID) de la sesión de usuario federado AWS STS, rol o usuario de IAM al que se encuentran asociadas las credenciales de seguridad temporales en el elemento `Condition` de una política. En la siguiente política se muestra un ejemplo de cómo puede denegar el acceso a las sesiones de credenciales de seguridad temporales mediante la clave de contexto de condición `aws:userid`. + `AIDAXUSER1` representa el ID único para un usuario de IAM. Especificar el ID único de un usuario de IAM como valor para la clave de contexto `aws:userid` denegará acceso al usuario de IAM. Esto incluye todas las sesiones de credenciales de seguridad temporales que se crearon al llamar a la API `GetSessionToken`. + `AROAXROLE1:*` representa el ID único para todas las sesiones asociadas al rol de IAM. Si se especifica el ID único de un rol de IAM y un carácter comodín (\$1) en la parte del nombre de la sesión del rol especificado por quien llama como valor de la clave de contexto `aws:userid`, se denegarán todas las sesiones asociadas al rol. + `AROAXROLE2:` representa el ID único para una sesión de rol asumido. En la parte del nombre de sesión del rol especificado por el autor de la llamada del ID único del rol asumido, puede especificar un nombre de sesión de rol o un carácter comodín si se utiliza el operador de condición StringLike. Si especifica el nombre de la sesión del rol, denegará la sesión del rol nombrada sin afectar a los permisos del rol que creó las credenciales. Si especifica un carácter comodín para el nombre de la sesión del rol, denegará todas las sesiones asociadas al rol. **nota** El nombre de la sesión del rol especificado por la persona que llama, que forma parte del identificador único de una sesión del rol asumido, puede cambiar durante el encadenamiento de roles. El encadenamiento de roles se produce cuando un rol asume otro rol. El nombre de la sesión del rol se establece mediante el parámetro de solicitud `RoleSessionName` cuando la entidad principal asume un rol mediante la operación de la API de AWS STS `AssumeRole`. + `account-id:` representa el ID único para una sesión de usuario federado AWS STS. Para crear la sesión, un usuario de IAM llama a la API `GetFederationToken`. Especificar el ID único de una sesión de usuario federado de AWS STS deniega la sesión federada indicada sin afectar los permisos del usuario de IAM que creó las credenciales. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "*", "Resource": "*", "Condition": { "StringLike": { "aws:userId": [ "AIDAXUSER1", "AROAXROLE1:*", "AROAXROLE2:", "123456789012:" ] } } } ] } ``` ------ Para ver ejemplos específicos de valores de clave de una entidad principal, consulte [Valores clave principales](reference_policies_variables.md#principaltable). Para obtener información sobre los identificadores únicos de IAM y cómo obtenerlos, consulte [Identificadores únicos](reference_identifiers.md#identifiers-unique-ids). ## Denegar el acceso a una entidad principal específica con políticas basadas en recursos Para restringir el acceso a una entidad principal específica con una política basada en recursos, puede utilizar claves de contexto de condición [aws:PrincipalArn](reference_policies_condition-keys.md#condition-keys-principalarn) o [aws:SourceIdentity](reference_policies_condition-keys.md#condition-keys-sourceidentity) en el elemento `Condition`. Una política basada en recursos es una política de permisos asociada a un recurso y controla quién puede acceder al recurso y qué acciones puede realizar en este. Cuando se utiliza la clave de contexto `aws:PrincipalARN`, especifique el ARN de la sesión de usuario federado de AWS STS, rol o usuario de IAM asociado a las credenciales de seguridad temporales en el elemento Condición de una política. El siguiente ejemplo de política muestra cómo se utiliza la clave de contexto `aws:PrincipalARN` en una política basada en recursos: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Principal": "*", "Effect": "Deny", "Action": "s3:*", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket", "Condition": { "ArnEquals": { "aws:PrincipalArn": [ "arn:aws:iam::222222222222:role/ROLENAME", "arn:aws:iam::222222222222:user/USERNAME", "arn:aws:sts::222222222222:federated-user/USERNAME" ] } } } } ``` ------ Cuando utilice la clave de contexto `aws:SourceIdentity`, especifique el valor de identidad de origen asociado a las credenciales de seguridad temporales del rol en el elemento `Condition` de una política. Esto se aplica siempre que la sesión de rol se haya emitido al configurar el parámetro de solicitud `SourceIdentity` cuando la entidad principal asumió un rol mediante cualquier comando de la CLI AWS STS `assume-role`\$1 u operación de la API AWS STS `AssumeRole`\$1. El siguiente ejemplo muestra cómo se utiliza la clave de contexto `aws:SourceIdentity` en una política basada en recursos: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Principal": "*", "Effect": "Deny", "Action": "s3:*", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket", "Condition": { "StringLike": { "aws:SourceIdentity": [ "nikki_wolf@example.com", "" ] } } } } ``` ------ Si solo actualiza la política basada en identidades para una entidad principal, esta aún podrá realizar acciones permitidas en la política basada en recursos, excepto cuando dichas acciones se denieguen explícitamente en la política basada en identidades. **Para denegar el acceso a una entidad principal específica en una política basada en recursos** 1. Consulte [Servicios de AWS que funcionan con IAM](reference_aws-services-that-work-with-iam.md) para comprobar si el servicio admite políticas basadas en recursos. 1. Inicie sesión en la Consola de administración de AWS y abra la consola del servicio. Cada servicio tiene una ubicación diferente en la consola para adjuntar políticas. 1. Edite la política basada en recursos. Agregue una instrucción de política de denegación para especificar la información de identificación de la credencial: 1. En el elemento `Principal`, ingrese un comodín (\$1). La entidad principal estará restringida en el elemento `Condition`. 1. En el elemento `Effect`, ingrese “Denegar”. 1. En `Action`, ingrese el espacio de nombres del servicio y el nombre de la acción que se denegará. Para denegar todas las acciones, utilice el carácter comodín (\$1). Por ejemplo: `"s3:*"`. 1. En el elemento `Resource`, ingrese el ARN del recurso de destino. Por ejemplo: `"arn:aws:s3:::amzn-s3-demo-bucket"`. 1. En el elemento `Condition`, especifique la clave de contexto de `aws:PrincipalARN` o `aws:SourceIdentity`. Si utiliza la clave de contexto `aws:PrincipalARN`, ingrese el ARN de la entidad principal a la que desea denegar el acceso. Si utiliza la clave de contexto `aws:SourceIdentity`, ingrese el valor de identidad de origen establecido en la sesión de rol a la que se denegará el acceso. 1. Guarde su trabajo. # Concesión de permisos para crear credenciales de seguridad temporales De forma predeterminada, los usuarios de IAM no tienen permisos para crear credenciales de seguridad temporales para sesiones de usuario federado de AWS STS y roles. Debe utilizar una política para proporcionar estos permisos a los usuarios. Aunque pueda conceder permisos directamente a un usuario, le recomendamos encarecidamente que conceda permisos a los grupos. Esto facilita en gran medida la administración de los permisos. Cuando alguien ya no tenga que realizar las tareas asociadas a los permisos, solo tiene que retirarlo del grupo. Si otra persona necesita realizar dicha tarea, añádala al grupo para concederle los permisos. Para otorgar a un grupo de IAM permiso para crear credenciales de seguridad temporales para sesiones de usuario federado de AWS STS o roles, debe asociar una política que conceda uno o ambos de los siguientes privilegios: + Para que las entidades principales federadas de OIDC y SAML accedan a un rol de IAM, otorgue acceso a AWS STS `AssumeRole`. + Para los usuarios federados de AWS STS que no necesitan un rol, otorgue acceso a AWS STS `GetFederationToken`. Para obtener información sobre las diferencias entre las operaciones de API `AssumeRole` y `GetFederationToken`, consulte [Solicitud de credenciales de seguridad temporales](id_credentials_temp_request.md). Los usuarios de IAM también pueden llamar a [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html) para crear credenciales de seguridad temporales. No se requieren permisos para que un usuario llame a `GetSessionToken`. La finalidad de esta operación es autenticar al usuario mediante MFA. No se pueden utilizar políticas para controlar la autenticación. Esto significa que no se puede impedir que los usuarios de IAM llamen a `GetSessionToken` para crear credenciales temporales. **Example Ejemplo de política que concede permiso para asumir un rol** La siguiente política de ejemplo concede permiso para llamar a `AssumeRole` para el rol `UpdateApp` en la Cuenta de AWS `123123123123`. Cuando se usa `AssumeRole`, el usuario (o la aplicación) que crea las credenciales de seguridad en nombre de un usuario federado no puede delegar ningún permiso que no se haya especificado ya en la política de permisos de la función. **** ``` { "Version":"2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::123123123123:role/UpdateAPP" }] } ``` **Example Ejemplo de política que concede permiso para crear credenciales de seguridad temporales para un usuario federado** La siguiente política de ejemplo concede permiso para obtener acceso a `GetFederationToken`. **** ``` { "Version":"2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "sts:GetFederationToken", "Resource": "*" }] } ``` **importante** Al otorgar a los usuarios de IAM permiso para crear credenciales de seguridad temporales para usuarios federados de AWS STS con `GetFederationToken`, tenga en cuenta que esto les permite delegar sus propios permisos. Para obtener más información sobre cómo delegar permisos entre usuarios de IAM y Cuentas de AWS, consulte [Ejemplos de políticas para delegar el acceso](id_roles_create_policy-examples.md). Para obtener más información sobre cómo controlar los permisos en las credenciales de seguridad temporales, consulte [Permisos para credenciales de seguridad temporales](id_credentials_temp_control-access.md). **Example Ejemplo de política que concede a un usuario un permiso limitado para crear credenciales de seguridad temporales para usuarios federados** Cuando se permite que un usuario de IAM llame a `GetFederationToken`, la práctica recomendada es restringir los permisos que el usuario de IAM puede delegar. Por ejemplo, la siguiente política muestra cómo permitir que un usuario de IAM cree credenciales de seguridad temporales solo para usuarios federados de AWS STS cuyos nombres comienzan con *Manager*. **** ``` { "Version":"2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "sts:GetFederationToken", "Resource": ["arn:aws:sts::123456789012:federated-user/Manager*"] }] } ``` # Concesión de permisos para usar sesiones de consola con identidad mejorada Las sesiones de consola con identidad mejorada permiten incluir los ID de usuario y de sesión de AWS IAM Identity Center en las sesiones de la consola de AWS de los usuarios cuando inician sesión. Por ejemplo, Amazon Q Developer Pro usa sesiones de consola con identidad mejorada para personalizar la experiencia de servicio. Para obtener más información sobre las sesiones de consola con identidad mejorada, consulte [Habilitación de sesiones de consola con identidad mejorada](https://docs.aws.amazon.com/singlesignon/latest/userguide/identity-enhanced-sessions.html) en la *Guía del usuario de AWS IAM Identity Center*. Para obtener información sobre la configuración de Amazon Q Developer, consulte [Setting up Amazon Q Developer](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/setting-up.html) en la *Guía del usuario de Amazon Q Developer*. Para que las sesiones de consola con identidad mejorada estén disponibles para un usuario, debe utilizar una política basada en la identidad para conceder a la entidad principal de IAM el permiso `sts:SetContext` para utilizar el recurso que representa su propia sesión de consola. **importante** De forma predeterminada, los usuarios no tienen permiso para establecer el contexto de sus sesiones de consola con identidad mejorada. Para permitirlo, debe conceder el permiso `sts:SetContext` a la entidad principal de IAM en una política basada en la identidad, como se muestra en el ejemplo de política que aparece a continuación. El siguiente ejemplo de política basada en la identidad otorga el permiso `sts:SetContext` a una entidad principal de IAM, lo que le permite establecer un contexto de sesión de consola con identidad mejorada para sus propias sesiones de consola de AWS. El recurso de política, `arn:aws:sts::account-id:self`, representa la sesión de AWS de la persona que llama. El segmento de ARN `account-id` se puede sustituir por un carácter comodín `*` en los casos en que se implemente la misma política de permisos en varias cuentas, como cuando esta política se implementa mediante conjuntos de permisos de IAM Identity Center. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:SetContext", "Resource": "arn:aws:sts::111122223333:self" } ] } ``` ------ # Administración de AWS STS en una Región de AWS Un punto de conexión regional es la URL del punto de entrada dentro de una región concreta para un servicio web de AWS. AWS recomienda utilizar puntos de conexión regionales de AWS Security Token Service (AWS STS) en lugar del punto de conexión global para reducir la latencia, crear redundancia y aumentar la validez de los tokens de sesión. Aunque el punto de conexión global (heredado) de AWS STS `https://sts.amazonaws.com` es de alta disponibilidad, está alojado en una única región de AWS, EE. UU. Este (Norte de Virginia), y al igual que otros puntos de conexión, no dispone de conmutación por error automática a puntos de conexión de otras regiones. + **Reducir la latencia** - Al realizar las llamadas a AWS STS a un punto de enlace que esté geográficamente más cerca de sus servicios y aplicaciones, puede obtener acceso a los servicios de AWS STS con una latencia menor y tiempos de respuesta mejores. + **Redundancia incorporada**: puede limitar los efectos de una falla dentro de una carga de trabajo a una cantidad limitada de componentes con un alcance predecible de contención de impacto. El uso de puntos de conexión de AWS STS regionales le permite alinear el alcance de sus componentes con el alcance de sus identificadores de sesión. Para obtener más información sobre este pilar de fiabilidad, consulte [Usar el aislamiento de errores para proteger su carga de trabajo](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html) en *AWS Well-Architected Framework*. + **Aumentar la validez del token de sesión**: los tokens de sesión de puntos de enlace de AWS STS regionales son válidos en todas las Regiones de AWS. Los tokens de sesión del punto de conexión de STS global son válidos únicamente en las Regiones de AWS que están habilitadas de forma predeterminada. Si va a habilitar una nueva región en su cuenta, puede utilizar tokens de sesión de los puntos enlace de AWS STS regionales. Si decide utilizar el punto de conexión global, debe cambiar la compatibilidad de la región de tokens de sesión de AWS STS para el punto de enlace global. De esta forma, se garantiza que los tokens sean válidos en todas las Regiones de AWS. Para obtener una lista de las regiones de AWS STS y sus puntos de conexión, consulte [AWS STSRegiones y puntos de conexión de](id_credentials_temp_region-endpoints.md). **nota** AWS ha realizado cambios en el punto de conexión global del AWS Security Token Service (AWS STS) (`https://sts.amazonaws.com`) en las regiones [activadas de forma predeterminada](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html) para mejorar su resiliencia y rendimiento. Las solicitudes del AWS STS al punto de conexión global se atienden automáticamente en la misma Región de AWS que sus cargas de trabajo. Estos cambios no se implementarán en las regiones registradas. Le recomendamos que utilice los puntos de conexión regionales de AWS STS apropiados. Para obtener más información, consulte [Cambios en el punto de conexión global de AWS STS](id_credentials_temp_region-endpoints.md#reference_sts_global_endpoint_changes). **Topics** + [Activación y desactivación de AWS STS en una Región de AWS](#sts-regions-activate-deactivate) + [Código de escritura para utilizar en regiones de AWS STS](#id_credentials_temp_enable-regions_writing_code) + [Administración de tokens de sesión de punto de enlace global](#sts-regions-manage-tokens) ## Activación y desactivación de AWS STS en una Región de AWS Al activar puntos de conexión de AWS STS para una región, AWS STS puede emitir credenciales temporales para los usuarios y roles de dicha cuenta que realizan una solicitud de AWS STS. Esas credenciales se pueden utilizar en cualquier región que esté habilitada de forma predeterminada o habilitada manualmente. En el caso de las regiones habilitadas de forma predeterminada, debe activar el punto de conexión regional de AWS STS en la cuenta en la que se generan las credenciales temporales. No importa si el usuario ha iniciado sesión en la misma cuenta o en una cuenta diferente al realizar la solicitud. Al solicitar credenciales temporales para un rol en otra Cuenta de AWS mediante una región que está habilitada de manera manual, la cuenta de destino (la cuenta que contiene el rol) debe habilitar dicha región para las operaciones de AWS STS. Esto garantiza que la generación de las credenciales de seguridad temporales se realice de manera correcta. Por ejemplo, imagínese que un usuario de la cuenta A quiere enviar una solicitud de API `sts:AssumeRole` al [punto de conexión regional de AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_region-endpoints.html) en `https://sts.ap-southeast-3.amazonaws.com`. La solicitud se realiza para las credenciales temporales del rol denominado `Developer` de la cuenta B. Dado que la solicitud se hace para crear credenciales para una entidad de la cuenta B, esta cuenta debe tener habilitada la región `ap-southeast-3`. Los usuarios de la cuenta A (o cualquier otra cuenta) pueden llamar al punto de conexión AWS STS de `ap-southeast-3` para solicitar credenciales para la cuenta B, independientemente de si la región está activada en sus cuentas. Para obtener más información, consulte [Habilitar o deshabilitar Regiones de AWS en su cuenta](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html). **nota** Las regiones activas están a disposición de todos los usuarios que utilizan las credenciales temporales de esa cuenta. Para controlar qué usuarios o roles de IAM pueden acceder a la región, utilice la clave de condición `aws:RequestedRegion` en sus políticas de permisos. **Para activar o desactivar AWS STS en una región que está activada de forma predeterminada (consola)** 1. Inicie sesión como usuario raíz o usuario con permisos para realizar tareas de administración de IAM. 1. Abra la [consola de IAM](https://console.aws.amazon.com/iam/home?#home) y en el panel de navegación elija [https://console.aws.amazon.com/iam/home?#account_settings](https://console.aws.amazon.com/iam/home?#account_settings). 1. En la sección **Puntos de conexión** de **Security Token Service (STS)**, busque la región que quiere configurar y, a continuación, elija **Activa** o **Inactiva** en la columna **Estado de STS**. 1. En el cuadro de diálogo que se abre, elija **Activar** o **Desactivar**. En las regiones que deben estar activadas, activamos AWS STS automáticamente cuando se activa la región. Después de activar una región, AWS STS siempre estará activa en la región y no se podrá desactivar. Para obtener información sobre cómo habilitar regiones que están deshabilitadas de forma predeterminada, consulte [Especificar qué Regiones de AWS puede usar su cuenta](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html) en la *Guía de referencia de AWS Account Management*. ## Código de escritura para utilizar en regiones de AWS STS Después de activar una región, podrá dirigir las llamadas a la API de AWS STS a esa región. El siguiente fragmento de código Java demuestra cómo configurar un objeto `AWSSecurityTokenService` para realizar solicitudes desde la región Europa (Milán) (eu-south-1). ``` EndpointConfiguration regionEndpointConfig = new EndpointConfiguration("https://sts.eu-south-1.amazonaws.com", "eu-south-1"); AWSSecurityTokenService stsRegionalClient = AWSSecurityTokenServiceClientBuilder.standard() .withCredentials(credentials) .withEndpointConfiguration(regionEndpointConfig) .build(); ``` AWS STS recomienda realizar llamadas a un punto de enlace regional. Para aprender cómo habilitar una región de forma manual, consulte [Especificar qué Regiones de AWS puede utilizar su cuenta](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html) en la *Guía de referencia de AWS Account Management*. En el ejemplo, la primera línea crea una instancia de un objeto `EndpointConfiguration` llamado `regionEndpointConfig`, que incluye la URL del punto de conexión y la Región de AWS como parámetros. Para obtener información acerca de cómo configurar puntos de conexión regionales de AWS STS con una variable de entorno para AWS SDK, consulte [Puntos de conexión regionalizados de AWS STS](https://docs.aws.amazon.com/sdkref/latest/guide/feature-sts-regionalized-endpoints.html) en la *Guía de referencia de herramientas y AWS SDK*. Si desea obtener información sobre el resto de combinaciones de entornos de programación y lenguajes, consulte la [documentación del correspondiente SDK](https://aws.amazon.com/tools/). ## Administración de tokens de sesión de punto de enlace global La mayoría de las Regiones de AWS están habilitadas para llevar a cabo operaciones en todos los Servicios de AWS de forma predeterminada. Estas regiones se activan automáticamente para su uso con AWS STS. Algunas regiones, como, por ejemplo, Asia Pacífico (Hong Kong), se deben habilitar manualmente. Para obtener más información sobre cómo habilitar y deshabilitar Regiones de AWS, consulte [Especificar qué Regiones de AWS puede usar su cuenta](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html) en la *Guía de referencia de AWS Account Management*. Cuando habilita estos regiones de AWS, se activan automáticamente para su uso con AWS STS. No puede activar el punto de conexión de AWS STS para una región que está deshabilitada. Los tokens de sesión que son válidos en todas las Regiones de AWS incluyen más caracteres que los tokens que son válidos en regiones que están habilitadas de forma predeterminada. Cambiar esta configuración podría afectar a los sistemas existentes en los que almacena tokens temporalmente. Puede cambiar esta configuración mediante laConsola de administración de AWS, la AWS CLI o la API de AWS. **Para cambiar la compatibilidad de la región de los tokens de sesión para el punto de enlace global (consola)** 1. Inicie sesión como usuario raíz o usuario con permisos para realizar tareas de administración de IAM. Para cambiar la compatibilidad de los tokens de sesión, debe tener una política que permita la acción `iam:SetSecurityTokenServicePreferences`. 1. Abra la [consola de IAM](https://console.aws.amazon.com/iam/home?#home). En el panel de navegación, elija **Configuración de cuenta**. 1. En la sección **Tokens de sesión de los puntos de conexión de STS** de **Security Token Service (STS)**. El **punto de conexión global** indica `Valid only in Regiones de AWS enabled by default`. Elija **Change**. 1. En el cuadro de diálogo **Cambiar compatibilidad de región**, seleccione **Todas las Regiones de AWS**. A continuación, elija **Guardar cambios**. **nota** Los tokens de sesión que son válidos en todas las Región de AWS incluyen más caracteres que los tokens que son válidos en regiones que están habilitadas de forma predeterminada. Cambiar esta configuración podría afectar a los sistemas existentes en los que almacena tokens temporalmente. **Para cambiar la compatibilidad de la región de los tokens de sesión para el punto de enlace global (AWS CLI)** Establezca la versión del token de sesión. Los tokens de la versión 1 son válidos únicamente en las Regiones de AWS que están disponibles de forma predeterminada. Estos tokens no funcionan en regiones habilitadas manualmente, como, por ejemplo, Asia Pacífico (Hong Kong). Los tokens de la versión 2 son válidos en todas las regiones. Sin embargo, los tokens de versión 2 incluyen más caracteres y podrían afectar a los sistemas en los que almacena tokens temporalmente. + [https://docs.aws.amazon.com/cli/latest/reference/iam/set-security-token-service-preferences.html](https://docs.aws.amazon.com/cli/latest/reference/iam/set-security-token-service-preferences.html) **Para cambiar la compatibilidad de la región de los tokens de sesión para el punto de enlace global (API de AWS)** Establezca la versión del token de sesión. Los tokens de la versión 1 son válidos únicamente en las Regiones de AWS que están disponibles de forma predeterminada. Estos tokens no funcionan en regiones habilitadas manualmente, como, por ejemplo, Asia Pacífico (Hong Kong). Los tokens de la versión 2 son válidos en todas las regiones. Sin embargo, los tokens de versión 2 incluyen más caracteres y podrían afectar a los sistemas en los que almacena tokens temporalmente. + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_SetSecurityTokenServicePreferences.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_SetSecurityTokenServicePreferences.html) # AWS STSRegiones y puntos de conexión de **nota** AWS ha realizado cambios en el punto de conexión global del AWS Security Token Service (AWS STS) (`https://sts.amazonaws.com`) en las regiones [activadas de forma predeterminada](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html) para mejorar su resiliencia y rendimiento. Las solicitudes del AWS STS al punto de conexión global se atienden automáticamente en la misma Región de AWS que sus cargas de trabajo. Estos cambios no se implementarán en las regiones registradas. Le recomendamos que utilice los puntos de conexión regionales de AWS STS apropiados. Para obtener más información, consulte [Cambios en el punto de conexión global de AWS STS](#reference_sts_global_endpoint_changes). En la siguiente tabla se muestran las regiones y sus puntos de enlace. Indica cuáles están activadas de forma predeterminada y cuáles puede activar o desactivar. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/IAM/latest/UserGuide/id_credentials_temp_region-endpoints.html) ¹Debe [habilitar la región](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html) para utilizarla. Esto activa automáticamente AWS STS. No puede activar o desactivar manualmente AWS STS en estas regiones. ²Para usar AWS en China, necesita una cuenta y unas credenciales específicas para AWS en China. ## Cambios en el punto de conexión global de AWS STS AWS ha realizado cambios en el punto de conexión global del AWS Security Token Service (AWS STS) (`https://sts.amazonaws.com`) en las regiones [activadas de forma predeterminada](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html) para mejorar su resiliencia y rendimiento. Anteriormente, todas las solicitudes al punto de conexión global de AWS STS eran atendidas por una única Región de AWS, Este de EE. UU. (Norte de Virginia). Ahora, en las regiones [activadas de forma predeterminada](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html), las solicitudes al punto de conexión global del AWS STS se atienden de manera automática en la misma región en la que se origina la solicitud, en lugar de en la región Este de EE. UU. (Norte de Virginia). Estos cambios no se implementarán en las regiones registradas. Con este cambio, AWS STS procesará su solicitud en función de la región de origen y del solucionador de DNS utilizado. Las solicitudes al punto de conexión global del AWS STS se atenderán en la misma región que la carga de trabajo de AWS implementada si la solicitud de DNS para el punto de conexión global del AWS STS es administrada por el servidor DNS de Amazon en las regiones que están activadas de forma predeterminada. Las solicitudes al punto de conexión global del AWS STS se seguirán atendiendo en la región Este de EE. UU. (Norte de Virginia) si su solicitud se originó en regiones de participación voluntaria o si su solicitud se resolvió mediante un solucionador de DNS distinto del servidor de DNS de Amazon. Para obtener más información acerca del servidor DNS de Amazon, consulte [Servidor DNS de Amazon](https://docs.aws.amazon.com/vpc/latest/userguide/AmazonDNS-concepts.html#AmazonDNS) en la *Guía del usuario de Amazon Virtual Private Cloud*. En la siguiente tabla, se muestra cómo se enrutan las solicitudes al punto de conexión global del AWS STS en función de su proveedor de DNS. | Solucionador de DNS | ¿Las solicitudes al punto de conexión global AWS STS global se enrutan a la Región de AWS local? | | --- | --- | | Solucionador de DNS de Amazon en una Amazon VPC en una región activada de forma predeterminada | Sí | | Solucionador de DNS de Amazon en una Amazon VPC en una región registrada | No, la solicitud se enrutará a la región Este de EE. UU. (Norte de Virginia) | | Solucionador de DNS proporcionado por su ISP, un proveedor de DNS público o cualquier otro proveedor de DNS | No, la solicitud se enrutará a la región Este de EE. UU. (Norte de Virginia) | Para garantizar una interrupción mínima de sus procesos actuales, AWS ha implementado las siguientes medidas: + Los registros de AWS CloudTrail para las solicitudes realizadas al punto de conexión global del AWS STS se envían a la región Este de EE. UU. (Norte de Virginia). Los registros de CloudTrail de las solicitudes atendidas por los puntos de conexión regionales de AWS STS seguirán registrándose en sus respectivas regiones en CloudTrail. + Los registros de CloudTrail para las operaciones realizadas por el punto de conexión global del AWS STS y los puntos de conexión regionales tienen los campos adicionales `endpointType` y `awsServingRegion` para indicar qué punto de conexión y región atendieron la solicitud. Para ver ejemplos de registros de CloudTrail, consulte [Ejemplo de evento de API de AWS STS que utiliza el punto de conexión global en el archivo de registro de CloudTrail](cloudtrail-integration.md#stscloudtrailexample-assumerole-sts-global-endpoint). + Las solicitudes realizadas al punto de conexión global del AWS STS tienen un valor de `us-east-1` para la clave de condición `aws:RequestedRegion`, independientemente de la región que haya atendido la solicitud. + Las solicitudes gestionadas por el punto de conexión global del AWS STS no comparten una cuota de solicitudes por segundo con los puntos de conexión regionales del AWS STS. Si tiene cargas de trabajo en una región registrada y sigue utilizando el punto de conexión global de AWS STS, le recomendamos que migre a los puntos de conexión regionales de AWS STS para mejorar la resiliencia y el rendimiento. Para obtener más información sobre la configuración de puntos de conexión regionales de AWS STS, consulte [Puntos de conexión regionales de AWS STS](https://docs.aws.amazon.com/sdkref/latest/guide/feature-sts-regionalized-endpoints.html) en la *Guía de referencia de SDK y herramientas de AWS*. ## AWS CloudTrail y puntos de enlace regionales Las llamadas a puntos de conexión regionales y globales se registran en el campo `tlsDetails` en AWS CloudTrail. Las llamadas a puntos de conexión regionales, como por ejemplo `us-east-2.amazonaws.com`, se registran en CloudTrail en la región correspondiente. Las llamadas al punto de enlace global, `sts.amazonaws.com`, se registran como llamadas a un servicio global. Los eventos de los puntos de conexión globales AWS STS se registran en us-east-1. **nota** `tlsDetails` solo se puede ver para los servicios que admiten este campo. Consulte [Servicios que admiten detalles de TLS en CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-supported-tls-details.html) en la *Guía del usuario de AWS CloudTrail* 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). # Permitir el acceso del agente de identidades personalizadas a la consola de AWS Puede escribir y ejecutar código para crear una dirección URL que permita a los usuarios que inicien sesión en la red de su organización obtener acceso de forma segura a la Consola de administración de AWS. La dirección URL incluye un token de inicio de sesión que obtiene de AWS y que autentica al usuario en AWS. La sesión de la consola resultante puede incluir una función `AccessKeyId` distinta debido a la federación. Para rastrear el uso de la clave de acceso para el inicio de sesión de la federación a través de eventos de CloudTrail relacionados, consulte [Registro de llamadas a IAM y a la API de AWS STS con AWS CloudTrail](cloudtrail-integration.md) y [los eventos de inicio de sesión de Consola de administración de AWS](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-aws-console-sign-in-events.html). **nota** Si su organización usa un proveedor de identidad (IdP) que es compatible con SAML, puede configurar el acceso a la consola sin necesidad de escribir código. Funciona con proveedores como Active Directory Federation Services de Microsoft o Shibboleth de código abierto. Para obtener más información, 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 permitir que los usuarios de su organización tengan acceso a la Consola de administración de AWS, puede crear un *agente de identidades* que realice los pasos siguientes: 1. Comprobar que el sistema de identidad local autentique al usuario. 1. Llame a las operaciones de la API [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) (recomendado) o [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) de AWS Security Token Service (AWS STS) para obtener credenciales de seguridad temporales para el usuario. Para obtener más información sobre los distintos métodos que puede utilizar para asumir un rol, consulte [Métodos para asumir un rol](id_roles_manage-assume.md). Para obtener información sobre cómo pasar etiquetas de sesión opcionales al obtener las credenciales de seguridad, consulte [Transferencia de etiquetas de sesión en AWS STS](id_session-tags.md). + Si utiliza una de las operaciones `AssumeRole*` de la API para obtener las credenciales de seguridad temporales de un rol, puede incluir el parámetro `DurationSeconds` en la llamada. Este parámetro especifica la duración de la sesión de rol, que puede oscilar entre 900 segundos (15 minutos) y el valor de la duración máxima de la sesión especificado para el rol. Cuando se utiliza `DurationSeconds` en una operación `AssumeRole*`, debe llamarla como un usuario de IAM con credenciales a largo plazo. De lo contrario, la llamada al punto de enlace de federación en el paso 3 produce un error. Para obtener información sobre cómo ver o cambiar el valor máximo para un rol, consulte [Actualizar la duración máxima de la sesión para un rol](id_roles_update-role-settings.md#id_roles_update-session-duration). + Si utiliza la operación `GetFederationToken` de la API para obtener las credenciales, puede incluir el parámetro `DurationSeconds` en la llamada. Este parámetro especifica la duración de la sesión de rol. Este valor puede oscilar entre 900 segundos (15 minutos) y 129 600 segundos (36 horas). Solo podrá realizar esta llamada a la API utilizando las credenciales de seguridad de AWS a largo plazo de un usuario de IAM. También puede realizar estas llamadas con las credenciales de Usuario raíz de la cuenta de AWS, pero no lo recomendamos. Si realiza esta llamada como usuario raíz, la duración predeterminada de la sesión es de una hora. También puede especificar una sesión que dure entre 900 segundos (15 minutos) y 3 600 segundos (una hora). 1. Llame al punto de enlace de federación de AWS y proporcione las credenciales de seguridad temporales para solicitar un token de inicio de sesión. 1. Representar una URL de la consola que incluya el token: + Si utiliza una de las operaciones `AssumeRole*` de la API en la URL, puede incluir el parámetro HTTP `SessionDuration`. Este parámetro especifica la duración de la sesión de consola, que oscila entre 900 segundos (15 minutos) y 43 200 segundos (12 horas). + Si utiliza la operación `GetFederationToken` de la API en la URL, puede incluir el parámetro `DurationSeconds`. Este parámetro especifica la duración de la sesión de consola federada. Este valor puede oscilar entre 900 segundos (15 minutos) y 129 600 segundos (36 horas). **nota** Su `SessionDuration` no puede ser mayor o igual a la configuración de duración máxima de la sesión para el rol que está asumiendo. Por ejemplo, ha establecido en 5 horas la duración máxima de la sesión para el rol que desea asumir. Su parámetro `SessionDuration` puede ser de 16524 segundos o 4 horas y 59 segundos. No utilice el parámetro HTTP `SessionDuration` si obtiene las credenciales temporales con `GetFederationToken`. La operación producirá un error. Utilizar las credenciales de un rol para asumir otro rol se denomina [*encadenamiento de roles*](id_roles.md#iam-term-role-chaining). Cuando se utiliza el encadenamiento de roles, las nuevas credenciales tienen una duración máxima de una hora. Cuando utiliza roles para [conceder permisos a las aplicaciones que se ejecutan en instancias EC2](id_roles_use_switch-role-ec2.md), esas aplicaciones no están sujetas a esta limitación. No utilice el parámetro HTTP `SessionDuration` si obtiene las credenciales temporales mediante el encadenamiento de roles. La operación producirá un error. 1. Proporcione la dirección URL al usuario o invóquela en nombre del usuario. La dirección URL que el punto de enlace de federación proporciona es válida durante 15 minutos después de su creación. Esto difiere de la duración (en segundos) de la sesión de credenciales de seguridad temporales que está asociada a la URL. Esas credenciales son válidas durante el periodo que especificó al crearlas, a partir del momento en que se crearon. **importante** La dirección URL concede el acceso a sus recursos de AWS a través de la Consola de administración de AWS si ha habilitado los permisos en las credenciales de seguridad temporales asociadas. Por este motivo, debe tratar a la dirección URL como un secreto. Recomendamos devolver la dirección URL a través de un redireccionamiento seguro, por ejemplo, mediante la utilización de un código de estado de respuesta HTTP 302 a través de una conexión SSL. Para obtener más información sobre el código de estado de respuesta HTTP 302, diríjase a [RFC 2616, sección 10.3.3](https://datatracker.ietf.org/doc/html/rfc2616#section-10.3.3). Para finalizar estas tareas, puede utilizar la API de consulta [HTTPS para AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/APIReference/) y [AWS Security Token Service (AWS STS)](https://docs.aws.amazon.com/STS/latest/APIReference/). O bien, puede utilizar lenguajes de programación, tales como Java, Ruby o C\$1, junto con el [SDK de AWS](https://aws.amazon.com/tools/) apropiado. En las siguientes secciones, se describe cada uno de estos métodos. **Topics** + [Código de ejemplo con operaciones de API de consulta de IAM](#STSConsoleLink_manual) + [Ejemplo de código que utiliza Python](#STSConsoleLink_programPython) + [Ejemplo de código que utiliza Java](#STSConsoleLink_programJava) + [Ejemplo que muestra cómo crear la dirección URL (Ruby)](#STSConsoleLink_programRuby) ## Código de ejemplo con operaciones de API de consulta de IAM Puede crear una URL que otorgue acceso directo a la Consola de administración de AWS a roles y entidades principales federadas. Esta tarea usa IAM y la API de consulta HTTPS de AWS STS. Para obtener más información sobre cómo realizar solicitudes de consulta, consulte [Making Query Requests](https://docs.aws.amazon.com/IAM/latest/UserGuide/IAM_UsingQueryAPI.html). **nota** El siguiente procedimiento incluye ejemplos de cadenas de texto. Para mejorar la legibilidad, se han agregado saltos de línea a algunos de los ejemplos más largos. Al crear estas cadenas para su propio uso, debe omitir cualquier salto de línea. **Para otorgar a roles y entidades principales federadas acceso a los recursos desde la Consola de administración de AWS** 1. Autentique al usuario en su sistema de autorización e identidad. 1. Obtenga credenciales de seguridad temporales para el usuario. Las credenciales temporales incluyen un ID de clave de acceso, una clave de acceso secreta y un token de seguridad. Para obtener más información sobre la creación de instancias de contenedor, consulte [Credenciales de seguridad temporales en IAM](id_credentials_temp.md). Para obtener credenciales temporales, puede llamar a la API [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) de AWS STS (recomendado) o a la API [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html). Para obtener más información sobre las diferencias entre estas operaciones API, consulte [Descripción de las opciones de la API para delegar de forma segura el acceso a su cuenta deAWS](https://aws.amazon.com/blogs/security/understanding-the-api-options-for-securely-delegating-access-to-your-aws-account) en el blog de seguridad de AWS. **importante** Si utiliza la API [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) para crear credenciales de seguridad temporales, debe especificar los permisos que dichas credenciales conceden al usuario que asume el rol. Para cualquiera de las operaciones API que empiezan por `AssumeRole*`, utilice un rol de IAM para asignar permisos. Para el resto de las operaciones API, el mecanismo varía según la API. Para obtener más información, consulte [Permisos para credenciales de seguridad temporales](id_credentials_temp_control-access.md). Además, si utiliza las operaciones `AssumeRole*` de la API, debe llamarlas como usuario de IAM con credenciales a largo plazo. De lo contrario, la llamada al punto de enlace de federación en el paso 3 produce un error. 1. Después de obtener las credenciales de seguridad temporales, intégrelas en una cadena de sesión JSON para intercambiarlas por un token de inicio de sesión. El siguiente ejemplo muestra cómo codificar las credenciales. Sustituya el texto del marcador de posición con los valores adecuados de las credenciales que reciba en el paso anterior. ``` {"sessionId":"*** temporary access key ID ***", "sessionKey":"*** temporary secret access key ***", "sessionToken":"*** session token ***"} ``` 1. [Aplique el código URL](https://en.wikipedia.org/wiki/Percent-encoding) a la cadena de sesión del paso anterior. Dado que la información que está codificando es confidencial, recomendamos que evite utilizar un servicio web para esta codificación. En su lugar, utilice una función o característica instalada localmente en su conjunto de herramientas de desarrollo para codificar esta información de forma segura. Puede utilizar la función `urllib.quote_plus` en Python, la función `URLEncoder.encode` en Java o la función `CGI.escape` en Ruby. Consulte los ejemplos más adelante en este tema. 1. **nota** AWS admite solicitudes POST aquí. Envíe su solicitud al punto de conexión de federación de AWS: `https://region-code.signin.aws.amazon.com/federation` Para obtener una lista de los posibles valores de *region-code*, consulte la columna **Region** (Región) en [Puntos de conexión de inicio de sesión de AWS](https://docs.aws.amazon.com/general/latest/gr/signin-service.html). Opcionalmente, puede utilizar un punto de conexión de federación de inicio de sesión de AWS predeterminado: `https://signin.aws.amazon.com/federation` La solicitud debe incluir los parámetros `Action` y `Session` y (opcionalmente) si ha utilizado una operación [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) de la API, un parámetro HTTP `SessionDuration`, tal como se muestra en el siguiente ejemplo. ``` Action = getSigninToken SessionDuration = time in seconds Session = *** the URL encoded JSON string created in steps 3 & 4 *** ``` **nota** Las siguientes instrucciones de este paso solo funcionan con solicitudes GET. El parámetro HTTP `SessionDuration` especifica la duración de la sesión de consola. Esta es distinta de la duración de las credenciales temporales especificada mediante el parámetro `DurationSeconds`. Puede especificar un valor máximo de `SessionDuration` de 43 200 (12 horas). Si falta el parámetro `SessionDuration`, el valor predeterminado de la sesión será el correspondiente a la duración de las credenciales que ha recuperado de AWS STS en el paso 2 (que tienen el valor predeterminado de una hora). Consulte la [documentación de la API `AssumeRole`](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) para obtener más información sobre cómo especificar la duración mediante el parámetro `DurationSeconds`. La posibilidad de crear una sesión de consola con una duración superior a una hora es intrínseca a la operación `getSigninToken` del punto de enlace de federación. **nota** Su `SessionDuration` no puede ser mayor o igual a la configuración de duración máxima de la sesión para el rol que está asumiendo. Por ejemplo, ha establecido en 5 horas la duración máxima de la sesión para el rol que desea asumir. Su parámetro `SessionDuration` puede ser de 16524 segundos o 4 horas y 59 segundos. No utilice el parámetro HTTP `SessionDuration` si obtiene las credenciales temporales con `GetFederationToken`. La operación producirá un error. Utilizar las credenciales de un rol para asumir otro rol se denomina [*encadenamiento de roles*](id_roles.md#iam-term-role-chaining). Cuando se utiliza el encadenamiento de roles, las nuevas credenciales tienen una duración máxima de una hora. Cuando utiliza roles para [conceder permisos a las aplicaciones que se ejecutan en instancias EC2](id_roles_use_switch-role-ec2.md), esas aplicaciones no están sujetas a esta limitación. No utilice el parámetro HTTP `SessionDuration` si obtiene las credenciales temporales mediante el encadenamiento de roles. La operación producirá un error. Cuando habilita sesiones de consola con una duración prolongada, aumenta el riesgo de exposición de credenciales. Para ayudarle a mitigar este riesgo, puede deshabilitar inmediatamente las sesiones de consola activas para cualquier rol eligiendo **Revoke Sessions** (Revocar sesiones) en la página de la consola de IAM **Role Summary** (Resumen de roles). Para obtener más información, consulte [Revocación de las credenciales de seguridad temporales de un rol de IAM](id_roles_use_revoke-sessions.md). El siguiente es un ejemplo de lo que su solicitud podría parecer. Las líneas se ajustan aquí para facilitar su legibilidad, pero debe enviarla como una cadena de una sola línea. ``` https://signin.aws.amazon.com/federation ?Action=getSigninToken &SessionDuration=1800 &Session=%7B%22sessionId%22%3A+%22ASIAJUMHIZPTOKTBMK5A%22%2C+%22sessionKey%22 %3A+%22LSD7LWI%2FL%2FN%2BgYpan5QFz0XUpc8s7HYjRsgcsrsm%22%2C+%22sessionToken%2 2%3A+%22FQoDYXdzEBQaDLbj3VWv2u50NN%2F3yyLSASwYtWhPnGPMNmzZFfZsL0Qd3vtYHw5A5dW AjOsrkdPkghomIe3mJip5%2F0djDBbo7SmO%2FENDEiCdpsQKodTpleKA8xQq0CwFg6a69xdEBQT8 FipATnLbKoyS4b%2FebhnsTUjZZQWp0wXXqFF7gSm%2FMe2tXe0jzsdP0O12obez9lijPSdF1k2b5 PfGhiuyAR9aD5%2BubM0pY86fKex1qsytjvyTbZ9nXe6DvxVDcnCOhOGETJ7XFkSFdH0v%2FYR25C UAhJ3nXIkIbG7Ucv9cOEpCf%2Fg23ijRgILIBQ%3D%3D%22%7D ``` La respuesta del punto de enlace de federación es un documento JSON con un valor de `SigninToken`. Tendrá un aspecto similar al siguiente ejemplo. ``` {"SigninToken":"*** the SigninToken string ***"} ``` 1. **nota** AWS admite solicitudes POST aquí. Por último, cree la URL que los usuarios pueden usar para acceder a la Consola de administración de AWS. La dirección URL es el mismo punto de enlace URL de federación que usó en [Step 5](#STSConsoleLink_manual_step5), además de los siguientes parámetros: ``` ?Action = login &Issuer = *** the form-urlencoded URL for your internal sign-in page *** &Destination = *** the form-urlencoded URL to the desired AWS console page *** &SigninToken = *** the value of SigninToken received in the previous step *** ``` **nota** Las siguientes instrucciones de este paso solo funcionan con la API de GET. El siguiente ejemplo muestra lo que la dirección URL final podría parecer. La dirección URL es válida durante 15 minutos desde el momento en que se crea. Las credenciales de seguridad temporales y la sesión de consola integradas dentro de la dirección URL son válidas durante el periodo especificado en el parámetro HTTP `SessionDuration` al solicitarlas inicialmente. ``` https://signin.aws.amazon.com/federation ?Action=login &Issuer=https%3A%2F%2Fexample.com &Destination=https%3A%2F%2Fconsole.aws.amazon.com%2F &SigninToken=VCQgs5qZZt3Q6fn8Tr5EXAMPLEmLnwB7JjUc-SHwnUUWabcRdnWsi4DBn-dvC CZ85wrD0nmldUcZEXAMPLE-vXYH4Q__mleuF_W2BE5HYexbe9y4Of-kje53SsjNNecATfjIzpW1 WibbnH6YcYRiBoffZBGExbEXAMPLE5aiKX4THWjQKC6gg6alHu6JFrnOJoK3dtP6I9a6hi6yPgm iOkPZMmNGmhsvVxetKzr8mx3pxhHbMEXAMPLETv1pij0rok3IyCR2YVcIjqwfWv32HU2Xlj471u 3fU6uOfUComeKiqTGX974xzJOZbdmX_t_lLrhEXAMPLEDDIisSnyHGw2xaZZqudm4mo2uTDk9Pv 9l5K0ZCqIgEXAMPLEcA6tgLPykEWGUyH6BdSC6166n4M4JkXIQgac7_7821YqixsNxZ6rsrpzwf nQoS14O7R0eJCCJ684EXAMPLEZRdBNnuLbUYpz2Iw3vIN0tQgOujwnwydPscM9F7foaEK3jwMkg Apeb1-6L_OB12MZhuFxx55555EXAMPLEhyETEd4ZulKPdXHkgl6T9ZkIlHz2Uy1RUTUhhUxNtSQ nWc5xkbBoEcXqpoSIeK7yhje9Vzhd61AEXAMPLElbWeouACEMG6-Vd3dAgFYd6i5FYoyFrZLWvm 0LSG7RyYKeYN5VIzUk3YWQpyjP0RiT5KUrsUi-NEXAMPLExMOMdoODBEgKQsk-iu2ozh6r8bxwC RNhujg ``` ## Ejemplo de código que utiliza Python En los siguientes ejemplos se muestra cómo utilizar Python para crear mediante programación una dirección URL que ofrezca a los usuarios acceso directo a la Consola de administración de AWS. Se incluyen dos ejemplos: + Federación mediante solicitudes GET para AWS + Federación mediante solicitudes POST para AWS Ambos ejemplos usan la API [AWS SDK para Python (Boto3)](https://aws.amazon.com/tools/) y [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) para obtener credenciales de seguridad temporales. No incluya `SessionDuration` si sus credenciales de `AssumeRoleSession` provienen del encadenamiento de roles. Si incluye`SessionDuration`, la operación producirá un error. ### Uso de solicitudes GET ``` import urllib, json, sys import requests # 'pip install requests' import boto3 # AWS SDK for Python (Boto3) 'pip install boto3' # Step 1: Authenticate user in your own identity system. # Step 2: Using the access keys for an IAM user in your Cuenta de AWS, # call "AssumeRole" to get temporary access keys for the role or federated principal # Note: Calls to AWS STS AssumeRole must be signed using the access key ID # and secret access key of an IAM user or using existing temporary credentials. # The credentials can be in Amazon EC2 instance metadata, in environment variables, # or in a configuration file, and will be discovered automatically by the # client('sts') function. For more information, see the Python SDK docs: # http://boto3.readthedocs.io/en/latest/reference/services/sts.html # http://boto3.readthedocs.io/en/latest/reference/services/sts.html#STS.Client.assume_role sts_connection = boto3.client('sts') assumed_role_object = sts_connection.assume_role( RoleArn="arn:aws:iam::account-id:role/ROLE-NAME", RoleSessionName="AssumeRoleSession", ) # Step 3: Format resulting temporary credentials into JSON url_credentials = {} url_credentials['sessionId'] = assumed_role_object.get('Credentials').get('AccessKeyId') url_credentials['sessionKey'] = assumed_role_object.get('Credentials').get('SecretAccessKey') url_credentials['sessionToken'] = assumed_role_object.get('Credentials').get('SessionToken') json_string_with_temp_credentials = json.dumps(url_credentials) # Step 4. Make request to AWS federation endpoint to get sign-in token. Construct the parameter string with # the sign-in action request, a 12-hour session duration, and the JSON document with temporary credentials # as parameters. request_parameters = "?Action=getSigninToken" request_parameters += "&SessionDuration=43200" if sys.version_info[0] < 3: def quote_plus_function(s): return urllib.quote_plus(s) else: def quote_plus_function(s): return urllib.parse.quote_plus(s) request_parameters += "&Session=" + quote_plus_function(json_string_with_temp_credentials) request_url = "https://signin.aws.amazon.com/federation" + request_parameters r = requests.get(request_url) # Returns a JSON document with a single element named SigninToken. signin_token = json.loads(r.text) # Step 5: Create URL where users can use the sign-in token to sign in to # the console. This URL must be used within 15 minutes after the # sign-in token was issued. request_parameters = "?Action=login" request_parameters += "&Issuer=Example.org" request_parameters += "&Destination=" + quote_plus_function("https://console.aws.amazon.com/") request_parameters += "&SigninToken=" + signin_token["SigninToken"] request_url = "https://signin.aws.amazon.com/federation" + request_parameters # Send final URL to stdout print (request_url) ``` ### Uso de solicitudes POST ``` import urllib, json, sys import requests # 'pip install requests' import boto3 # AWS SDK for Python (Boto3) 'pip install boto3' import os from selenium import webdriver # 'pip install selenium', 'brew install chromedriver' # Step 1: Authenticate user in your own identity system. # Step 2: Using the access keys for an IAM user in your ACuenta de AWS, # call "AssumeRole" to get temporary access keys for the role or federated principal # Note: Calls to AWS STS AssumeRole must be signed using the access key ID # and secret access key of an IAM user or using existing temporary credentials. # The credentials can be in Amazon EC2 instance metadata, in environment variables, # or in a configuration file, and will be discovered automatically by the # client('sts') function. For more information, see the Python SDK docs: # http://boto3.readthedocs.io/en/latest/reference/services/sts.html # http://boto3.readthedocs.io/en/latest/reference/services/sts.html#STS.Client.assume_role if sys.version_info[0] < 3: def quote_plus_function(s): return urllib.quote_plus(s) else: def quote_plus_function(s): return urllib.parse.quote_plus(s) sts_connection = boto3.client('sts') assumed_role_object = sts_connection.assume_role( RoleArn="arn:aws:iam::account-id:role/ROLE-NAME", RoleSessionName="AssumeRoleDemoSession", ) # Step 3: Format resulting temporary credentials into JSON url_credentials = {} url_credentials['sessionId'] = assumed_role_object.get('Credentials').get('AccessKeyId') url_credentials['sessionKey'] = assumed_role_object.get('Credentials').get('SecretAccessKey') url_credentials['sessionToken'] = assumed_role_object.get('Credentials').get('SessionToken') json_string_with_temp_credentials = json.dumps(url_credentials) # Step 4. Make request to AWS federation endpoint to get sign-in token. Construct the parameter string with # the sign-in action request, a 12-hour session duration, and the JSON document with temporary credentials # as parameters. request_parameters = {} request_parameters['Action'] = 'getSigninToken' request_parameters['SessionDuration'] = '43200' request_parameters['Session'] = json_string_with_temp_credentials request_url = "https://signin.aws.amazon.com/federation" r = requests.post( request_url, data=request_parameters) # Returns a JSON document with a single element named SigninToken. signin_token = json.loads(r.text) # Step 5: Create a POST request where users can use the sign-in token to sign in to # the console. The POST request must be made within 15 minutes after the # sign-in token was issued. request_parameters = {} request_parameters['Action'] = 'login' request_parameters['Issuer']='Example.org' request_parameters['Destination'] = 'https://console.aws.amazon.com/' request_parameters['SigninToken'] =signin_token['SigninToken'] jsrequest = ''' var form = document.createElement('form'); form.method = 'POST'; form.action = '{request_url}'; request_parameters = {request_parameters} for (var param in request_parameters) {{ if (request_parameters.hasOwnProperty(param)) {{ const hiddenField = document.createElement('input'); hiddenField.type = 'hidden'; hiddenField.name = param; hiddenField.value = request_parameters[param]; form.appendChild(hiddenField); }} }} document.body.appendChild(form); form.submit(); '''.format(request_url=request_url, request_parameters=request_parameters) driver = webdriver.Chrome() driver.execute_script(jsrequest) input("Press Enter to close the browser window...") ``` ## Ejemplo de código que utiliza Java El siguiente ejemplo muestra cómo utilizar Java para crear de forma programada una dirección URL que ofrezca a los usuarios acceso directo a la Consola de administración de AWS. El siguiente fragmento de código usa [AWS SDK para Java](https://aws.amazon.com/documentation/sdkforjava/). ``` import java.net.URLEncoder; import java.net.URL; import java.net.URLConnection; import java.io.BufferedReader; import java.io.InputStreamReader; // Available at http://www.json.org/java/index.html import org.json.JSONObject; import com.amazonaws.auth.AWSCredentials; import com.amazonaws.auth.BasicAWSCredentials; import com.amazonaws.services.securitytoken.AWSSecurityTokenServiceClient; import com.amazonaws.services.securitytoken.model.Credentials; import com.amazonaws.services.securitytoken.model.GetFederationTokenRequest; import com.amazonaws.services.securitytoken.model.GetFederationTokenResult; /* Calls to AWS STS API operations must be signed using the access key ID and secret access key of an IAM user or using existing temporary credentials. The credentials should not be embedded in code. For this example, the code looks for the credentials in a standard configuration file. */ AWSCredentials credentials = new PropertiesCredentials( AwsConsoleApp.class.getResourceAsStream("AwsCredentials.properties")); AWSSecurityTokenServiceClient stsClient = new AWSSecurityTokenServiceClient(credentials); GetFederationTokenRequest getFederationTokenRequest = new GetFederationTokenRequest(); getFederationTokenRequest.setDurationSeconds(1800); getFederationTokenRequest.setName("UserName"); // A sample policy for accessing Amazon Simple Notification Service (Amazon SNS) in the console. String policy = "{\"Version\":\"2012-10-17\", \"Statement\":[{\"Action\":\"sns:*\"," + "\"Effect\":\"Allow\",\"Resource\":\"*\"}]}"; getFederationTokenRequest.setPolicy(policy); GetFederationTokenResult federationTokenResult = stsClient.getFederationToken(getFederationTokenRequest); Credentials federatedCredentials = federationTokenResult.getCredentials(); // The issuer parameter specifies your internal sign-in // page, for example https://mysignin.internal.mycompany.com/. // The console parameter specifies the URL to the destination console of the // AWS Management Console. This example goes to Amazon SNS. // The signin parameter is the URL to send the request to. String issuerURL = "https://mysignin.internal.mycompany.com/"; String consoleURL = "https://console.aws.amazon.com/sns"; String signInURL = "https://signin.aws.amazon.com/federation"; // Create the sign-in token using temporary credentials, // including the access key ID, secret access key, and session token. String sessionJson = String.format( "{\"%1$s\":\"%2$s\",\"%3$s\":\"%4$s\",\"%5$s\":\"%6$s\"}", "sessionId", federatedCredentials.getAccessKeyId(), "sessionKey", federatedCredentials.getSecretAccessKey(), "sessionToken", federatedCredentials.getSessionToken()); // Construct the sign-in request with the request sign-in token action, a // 12-hour console session duration, and the JSON document with temporary // credentials as parameters. String getSigninTokenURL = signInURL + "?Action=getSigninToken" + "&DurationSeconds=43200" + "&SessionType=json&Session=" + URLEncoder.encode(sessionJson,"UTF-8"); URL url = new URL(getSigninTokenURL); // Send the request to the AWS federation endpoint to get the sign-in token URLConnection conn = url.openConnection (); BufferedReader bufferReader = new BufferedReader(new InputStreamReader(conn.getInputStream())); String returnContent = bufferReader.readLine(); String signinToken = new JSONObject(returnContent).getString("SigninToken"); String signinTokenParameter = "&SigninToken=" + URLEncoder.encode(signinToken,"UTF-8"); // The issuer parameter is optional, but recommended. Use it to direct users // to your sign-in page when their session expires. String issuerParameter = "&Issuer=" + URLEncoder.encode(issuerURL, "UTF-8"); // Finally, present the completed URL for the AWS console session to the user String destinationParameter = "&Destination=" + URLEncoder.encode(consoleURL,"UTF-8"); String loginURL = signInURL + "?Action=login" + signinTokenParameter + issuerParameter + destinationParameter; ``` ## Ejemplo que muestra cómo crear la dirección URL (Ruby) El siguiente ejemplo muestra cómo utilizar Ruby para crear de forma programada una dirección URL que ofrezca a los usuarios acceso directo a la Consola de administración de AWS. Este fragmento de código usa [AWS SDK para Ruby](https://aws.amazon.com/documentation/sdkforruby/). ``` require 'rubygems' require 'json' require 'open-uri' require 'cgi' require 'aws-sdk' # Create a new STS instance # # Note: Calls to AWS STS API operations must be signed using an access key ID # and secret access key. The credentials can be in EC2 instance metadata # or in environment variables and will be automatically discovered by # the default credentials provider in the AWS Ruby SDK. sts = Aws::STS::Client.new() # The following call creates a temporary session that returns # temporary security credentials and a session token. # The policy grants permissions to work # in the AWS SNS console. session = sts.get_federation_token({ duration_seconds: 1800, name: "UserName", policy: "{\"Version\":\"2012-10-17\", \"Statement\":{\"Effect\":\"Allow\",\"Action\":\"sns:*\",\"Resource\":\"*\"}}", }) # The issuer value is the URL where users are directed (such as # to your internal sign-in page) when their session expires. # # The console value specifies the URL to the destination console. # This example goes to the Amazon SNS console. # # The sign-in value is the URL of the AWS STS federation endpoint. issuer_url = "https://mysignin.internal.mycompany.com/" console_url = "https://console.aws.amazon.com/sns" signin_url = "https://signin.aws.amazon.com/federation" # Create a block of JSON that contains the temporary credentials # (including the access key ID, secret access key, and session token). session_json = { :sessionId => session.credentials[:access_key_id], :sessionKey => session.credentials[:secret_access_key], :sessionToken => session.credentials[:session_token] }.to_json # Call the federation endpoint, passing the parameters # created earlier and the session information as a JSON block. # The request returns a sign-in token that's valid for 15 minutes. # Signing in to the console with the token creates a session # that is valid for 12 hours. get_signin_token_url = signin_url + "?Action=getSigninToken" + "&SessionType=json&Session=" + CGI.escape(session_json) returned_content = URI.parse(get_signin_token_url).read # Extract the sign-in token from the information returned # by the federation endpoint. signin_token = JSON.parse(returned_content)['SigninToken'] signin_token_param = "&SigninToken=" + CGI.escape(signin_token) # Create the URL to give to the user, which includes the # sign-in token and the URL of the console to open. # The "issuer" parameter is optional but recommended. issuer_param = "&Issuer=" + CGI.escape(issuer_url) destination_param = "&Destination=" + CGI.escape(console_url) login_url = signin_url + "?Action=login" + signin_token_param + issuer_param + destination_param ```