Proporcionar acceso a un usuario de IAM a otra cuenta de AWS de la que es propietario - AWS Identity and Access Management

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Proporcionar acceso a un usuario de IAM a otra cuenta de AWS de la que es propietario

Puede conceder a los usuarios de IAM permiso para cambiar de roles en su cuenta de AWS o a los roles definidos en otras cuentas de AWS de las que es propietario.

nota

Si desea conceder acceso a una cuenta de la que no es propietario o no tiene control, consulte Proporcionar acceso a las cuentas de AWS propiedad de terceros más adelante en este tema.

Imagine que dispone de instancias de Amazon EC2 que son de vital importancia para su organización. En lugar de conceder directamente permiso a los usuarios para finalizar las instancias, puede crear un rol con estos privilegios. A continuación, permita que los administradores cambien de rol cuando necesiten terminar una instancia. Al hacer esto, se añaden las siguientes capas de protección a las instancias:

  • Debe conceder explícitamente permiso a los usuarios para asumir el rol.

  • Los usuarios deben cambiar de rol de forma activa con la Consola de administración de AWS o asumir el rol utilizando la AWS CLI o la API de AWS.

  • Puede añadir una protección Multi-Factor Authentication (MFA) al rol para que únicamente los usuarios que inicien sesión con un dispositivo MFA puedan asumir el rol. Para obtener información sobre cómo configurar un rol para que los usuarios que lo asuman deban primero autenticarse mediante la autenticación multifactor (MFA), consulte Configuración del acceso a una API protegida por MFA.

Recomendamos utilizar este enfoque para aplicar el principio de privilegio mínimo. Esto significa limitar el uso de permisos elevados únicamente cuando sean necesarios para realizar tareas específicas. Con los roles puede ayudar a impedir cambios accidentales en entornos confidenciales, especialmente si los combina con un proceso de auditoría con el fin de garantizar que los roles solo se utilizan cuando sean necesarios.

Al crear un rol con este fin, debe especificar las cuentas mediante el ID cuyos usuarios necesitan obtener acceso en el elemento Principal de la política de confianza del rol. Puede conceder permisos a usuarios específicos de estas otras cuentas para cambiar de rol. Para obtener información sobre si las entidades principales de las cuentas que no se encuentran en su zona de confianza (cuenta u organización de confianza) tienen acceso para asumir sus roles, consulte ¿Qué es IAM Access Analyzer?.

Un usuario de una cuenta puede cambiar de rol en la misma cuenta o en una cuenta diferente. Al utilizar el rol, el usuario solo puede realizar las acciones y obtener acceso únicamente a los recursos permitidos por el rol; sus permisos originales de usuario se suspenden. Si el usuario deja de utilizar el rol, sus permisos originales se restablecen.

Situación de ejemplo en la que se usan cuentas de desarrollo y producción separadas

Imagine que la organización tiene varias cuentas de AWS para aislar su entorno de desarrollo del de producción. Los usuarios de la cuenta de desarrollo podrían necesitar ocasionalmente acceder a los recursos en la cuenta de producción. Por ejemplo, es posible que necesite el acceso entre cuentas al promocionar una actualización desde el entorno de desarrollo al entorno de producción. Aunque podría crear identidades distintas (y contraseñas) para los usuarios que trabajan en las dos cuentas, la administración de credenciales de varias cuentas dificulta la administración de las identidades. En la siguiente figura, todos los usuarios se administran en la cuenta de desarrollo, pero algunos desarrolladores exigen acceso limitado a la cuenta de producción. La cuenta de desarrollo tiene dos grupos: Evaluadores y Desarrolladores, y cada grupo tiene su propia política.


        Utilice un rol para delegar permisos a un usuario en otra cuenta
  1. En la cuenta de producción, un administrador utiliza IAM para crear el rol UpdateApp en dicha cuenta. En el rol, el administrador define una política de confianza que especifica la cuenta de desarrollo como Principal, lo que significa que los usuarios autorizados de la cuenta de desarrollo pueden utilizar el rol UpdateApp. El administrador también define una política de permisos para el rol que especifica los permisos de lectura y escritura del bucket de Amazon S3 denominado productionapp.

    El administrador comparte entonces la información pertinente con cualquier usuario que necesite asumir el rol. Dicha información es el número de cuenta y el nombre del rol (para usuarios de la consola de AWS) o el Nombre de recurso de Amazon (ARN) (para acceso de API de AWS o AWS CLI). El ARN del rol podría parecerse a arn:aws:iam::123456789012:role/UpdateApp, donde el rol se denomina UpdateApp y el rol se creó en el número de cuenta 123456789012.

    nota

    El administrador puede configurar de forma opcional el rol para que los usuarios que lo asuman deban primero autenticarse mediante la opción Multi-Factor Authentication (MFA). Para obtener más información, consulte Configuración del acceso a una API protegida por MFA.

  2. En la cuenta de desarrollo un administrador concede a los miembros del grupo Desarrolladores permiso para cambiar de rol. Esto se realiza mediante la concesión de permiso al grupo Desarrolladores para llamar a la API AssumeRole de AWS Security Token Service (AWS STS) para el rol UpdateApp. Cualquier usuario de IAM que pertenezca al grupo Desarrolladores de la cuenta de desarrollo, ahora puede cambiar al rol UpdateApp en la cuenta de producción. Otros usuarios que no están en el grupo Desarrolladores no tienen permiso para cambiar de rol y, por lo tanto, no pueden obtener acceso al bucket de S3 en la cuenta de producción.

  3. El usuario solicita cambios de rol:

    • Consola de AWS: el usuario selecciona el nombre de la cuenta en la barra de navegación y elige Switch Role (Cambiar rol). El usuario especifica el ID de la cuenta (o alias) y el nombre del rol. O bien, el usuario puede hacer clic en un enlace enviado por correo electrónico enviado por el administrador. Este enlace redirigirá al usuario a la página Switch Role (Cambiar rol) con los detalles ya completados.

    • API de AWS/AWS CLI: un usuario del grupo Desarrolladores de la cuenta de desarrollo llama a la función AssumeRole para obtener las credenciales para el rol UpdateApp. El usuario especifica el ARN del rol UpdateApp como parte de la llamada. Si un usuario del grupo Evaluadores realiza la misma solicitud, esta no podrá llevarse a cabo, ya que los evaluadores no tienen permiso para llamar a AssumeRole para solicitar el ARN del rol UpdateApp.

  4. AWS STS devuelve credenciales temporales:

    • Consola de AWS: AWS STS verifica la solicitud con la política de confianza del rol para garantizar que la solicitud procede de una entidad de confianza (es decir, la cuenta de desarrollo). Tras realizar la verificación, AWS STS devuelve credenciales de seguridad temporales a la consola de AWS.

    • API/CLI: AWS STS verifica la solicitud con la política de confianza del rol para garantizar que la solicitud procede de una entidad de confianza (es decir, la cuenta de desarrollo). Tras realizar la verificación, AWS STS devuelve credenciales de seguridad temporales a la aplicación.

  5. Las credenciales temporales permiten el acceso a los recursos de AWS:

    • Consola de AWS: la consola de AWS utiliza las credenciales temporales en nombre del usuario para todas las acciones de consola posteriores, en este caso, para leer y escribir en el bucket productionapp. La consola no puede obtener acceso a cualquier otro recurso en la cuenta de producción. Si el usuario deja de utilizar el rol, los permisos del usuario vuelven a los permisos originales antes de cambiar de rol.

    • API/CLI: la aplicación utiliza las credenciales de seguridad temporales para actualizar el bucket de productionapp. Con las credenciales de seguridad temporales, la aplicación solo puede leer y escribir en el bucket de productionapp y no puede obtener acceso a cualquier otro recurso en la cuenta de producción. La aplicación no tiene que dejar de utilizar el rol, sino que, en cambio, deja de utilizar las credenciales temporales y utiliza las credenciales originales en las llamadas API posteriores.