Acceso a recursos entre cuentas en IAM
Para algunos servicios de AWS, puede conceder acceso entre cuentas a los recursos mediante el uso de IAM. Para hacerlo, puede asociar una política de recursos directamente al recurso que desea compartir o utilizar un rol como proxy.
Para compartir el recurso directamente, el recurso que desea compartir debe admitir políticas basadas en recursos. A diferencia de una política basada en identidad para un rol, una política basada en recursos especifica quién (qué entidad principal) puede acceder a ese recurso.
Utilice un rol como proxy cuando desee acceder a los recursos en otra cuenta que no admiten políticas basadas en recursos.
Para obtener más información sobre las diferencias entre estos tipos de políticas, consulte Políticas basadas en identidad y políticas basadas en recursos.
nota
Los roles de IAM y las políticas basadas en recursos delegan el acceso entre cuentas solo dentro de una única partición. Por ejemplo, tiene una cuenta en Oeste de EE. UU. (Norte de California) en la partición estándar aws. También tiene una cuenta en China en la partición aws-cn. No puede usar una política basada en recursos en su cuenta en China para permitir el acceso a los usuarios en su cuenta estándar de AWS.
Acceso entre cuentas mediante roles
No todos los servicios de AWS admiten políticas basadas en recursos. Para estos servicios, puede utilizar roles de IAM entre cuentas para centralizar la administración de permisos al proporcionar acceso entre cuentas a varios servicios. Un rol de IAM entre cuentas es un rol de IAM que incluye una política de confianza que permite a las entidades principales de IAM en otra cuenta de AWS asumir el rol. En pocas palabras, puede crear un rol en una cuenta de AWS que delega permisos específicos a otra cuenta de AWS.
Para obtener información sobre cómo asociar una política a una identidad de IAM, consulte Administración de políticas de IAM.
nota
Cuando una entidad principal cambia a un rol para usar temporalmente los permisos del rol, renuncia a sus permisos originales y asume los permisos asignados al rol que ha asumido.
Analicemos el proceso general en lo que respecta al software de socios de APN que necesita acceder a una cuenta de cliente.
-
El cliente crea un rol de IAM en su propia cuenta con una política que permite acceder a los recursos de Amazon S3 que necesita el socio de APN. En este ejemplo, el nombre del rol es
APNPartner.{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:*", "Resource": [ "arn:aws:s3:::bucket-name" ] } ] } -
A continuación, el cliente especifica que la cuenta de AWS del socio puede asumir el rol mediante el ID de la Cuenta de AWS del socio de APN en la política de confianza para el rol de
APNPartner.{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::APN-account-ID:role/APN-user-name" }, "Action": "sts:AssumeRole" } ] } -
El cliente proporciona el Nombre de recurso de Amazon (ARN) del rol al socio de APN. El ARN es el nombre completo del rol.
arn:aws:iam::APN-ACCOUNT-ID:role/APNPartnernota
Se recomienda utilizar un identificador externo en situaciones con varios inquilinos. Para obtener más información, consulte Acceder a las Cuentas de AWS que le pertenezcan a terceros.
-
Cuando el software de socios de APN necesita acceder a la cuenta del cliente, el software llama a la API AssumeRole en AWS Security Token Service junto con el ARN del rol en la cuenta del cliente. STS devuelve una credencial de AWS temporal que permite que el software haga su trabajo.
Para ver otro ejemplo de cómo conceder acceso entre cuentas mediante roles, consulte Acceso para un usuario de IAM en otra Cuenta de AWS propia. También puede consultar Tutorial de IAM: delegación del acceso entre cuentas de AWS mediante roles de IAM.
Concesión de acceso entre cuentas con políticas de recursos
Cuando una cuenta accede a un recurose a través de otra cuenta mediante una política basada en recursos, la entidad principal sigue trabajando en la cuenta de confianza y no tiene que renunciar a sus permisos para recibir los permisos de rol. Dicho de otro modo, la entidad principal sigue teniendo acceso a los recursos en la cuenta de confianza y también al recurso en la cuenta que confía. Esto es útil para tareas como copiar información en o desde el recurso compartido en la otra cuenta.
Los principales que puede especificar en una política basada en recursos incluyen cuentas, usuarios de IAM, usuarios federados, roles de IAM, sesiones de rol asumido o servicios de AWS. Para obtener más información, consulte Especificación de una entidad principal.
Para obtener información sobre si las entidades principales en las cuentas que no se encuentran en su zona de confianza (cuenta u organización de confianza) tienen acceso para asumir sus roles, consulte Identifying resources shared with an external entity.
La lista siguiente incluye algunos de los servicios de AWS que admiten políticas basadas en recursos. Para obtener una lista completa del número creciente de servicios de AWS que admiten la asociación de políticas de permisos a recursos en lugar de asociarlas a elementos principales, consulte Servicios de AWS que funcionan con IAM y busque los servicios que tengan Sí en la columna basadas en recursos.
-
Buckets de Amazon S3: la política se asocia al bucket, pero la política controla el acceso tanto al bucket como a los objetos que hay en él. A fin de obtener más información, consulte Políticas de bucket para Amazon S3 en la Guía del usuario de Amazon Simple Storage Service. En algunos casos, puede ser mejor utilizar roles para el acceso entre cuentas a Amazon S3. Para obtener más información, consulte la explicación de ejemplo en la Guía del usuario de Amazon Simple Storage Service.
-
Temas de Amazon Simple Notification Service (Amazon SNS): para obtener más información, consulte Ejemplos de casos de contol de acceso con Amazon SNS en la Guía para desarrolladores de Amazon Simple Notification Service.
-
Colas de Amazon Simple Queue Service (Amazon SQS) - Para obtener más información, consulte Apéndice: El lenguaje de la política de acceso en la Guía para desarrolladores de Amazon Simple Queue Service (Amazon SQS).
Políticas basadas en recursos para delegar permisos de AWS
Si un recurso concede permisos a los principales de la cuenta, puede delegar esos permisos a identidades de IAM específicas. Las identidades son usuarios, grupos de usuarios o roles de la cuenta. Para delegar permisos debe asociar una política a la identidad. Puede otorgar el número máximo de permisos permitidos por la cuenta propietaria de los recursos.
importante
En el acceso entre cuentas, una entidad principal necesita una Allow en la política de identidad y en la política basada en recursos.
Suponga que una política basada en recursos permite a todos los principales de la cuenta acceso administrativo completo a un recurso. A continuación, puede delegar acceso completo, acceso de solo lectura o cualquier otro acceso parcial a entidades principales de la cuenta de AWS. Alternativamente, si la política basada en recursos solo permite permisos de lista, entonces solo podrá delegar el acceso a la lista. Si intenta delegar más permisos que los que tiene la cuenta, los principales seguirán teniendo acceso únicamente a las listas.
Para obtener más información sobre cómo se toman estas decisiones, consulte Cómo determinar si una solicitud se permite o se deniega dentro de una cuenta.
nota
Los roles de IAM y las políticas basadas en recursos delegan el acceso entre cuentas solo dentro de una única partición. Por ejemplo, no puede añadir acceso entre cuentas entre una cuenta en la partición aws estándar y una cuenta en la partición aws-cn.
Por ejemplo, suponga que administra AccountA y AccountB. En AccountA, hay un bucket de Amazon S3 denominado BucketA.
-
Se asocia una política basada en recursos a
BucketAque les permite a todas las entidades principales en AccountB acceder de manera completa a los objetos en el bucket. De este modo podrán crear, leer o eliminar cualquier objeto de ese bucket.{ "Version": "2012-10-17", "Statement": [ { "Sid": "PrincipalAccess", "Effect": "Allow", "Principal": {"AWS": "arn:aws:iam::AccountB:root"}, "Action": "s3:*", "Resource": "arn:aws:s3:::BucketA/*" } ] }AccountA otorga a AccountB acceso completo a BucketA al designar a AccountB como entidad principal en la política basada en recursos. Como resultado, AccountB está autorizada a realizar cualquier acción en BucketA, y el administrador de AccountB puede delegar el acceso a los usuarios en AccountB.
El usuario raíz de AccountB tiene todos los permisos que se conceden a la cuenta. Por lo tanto, el usuario raíz tiene acceso completo a BucketA.
-
En AccountB, asocie una política al usuario de IAM llamado User2. Esa política le permite al usuario acceso de solo lectura a los objetos en BucketA. Esto significa que User2 puede ver los objetos, pero no crearlos, editarlos ni eliminarlos.
{ "Version": "2012-10-17", "Statement": [ { "Effect" : "Allow", "Action" : [ "s3:Get*", "s3:List*" ], "Resource" : "arn:aws:s3:::BucketA/*" } ] }El nivel máximo de acceso que AccountB puede delegar es el nivel de acceso que se concede a la cuenta. En este caso, la política basada en recursos ha concedido acceso completo a AccountB, pero User2 solo tiene acceso de solo lectura.
El administrador de AccountB no concede acceso a User1. De forma predeterminada, los usuarios no tienen permisos, salvo aquellos que se concedan de forma explícita, por lo que User1 no tiene acceso a BucketA.
IAM evalúa los permisos del principal en el momento en que el principal realiza una solicitud. Si utiliza comodines (*) para darles a los usuarios acceso completo a los recursos, las entidades principales pueden acceder a todos los recursos a los que tenga acceso la cuenta de AWS. Esto es cierto incluso para los recursos a los que agrega o para los que obtiene acceso después de crear la política del usuario.
En el ejemplo anterior, si AccountB le hubiera asociado una política a User2 que le permita acceso completo a todos los recursos en todas las cuentas, User2 tendría acceso de manera automática a todos los recursos que AccountB tiene acceso. Esto incluye el acceso a BucketA y el acceso a cualquier otro recurso otorgado por las políticas basadas en recursos en AccountA.
Para obtener más información sobre los usos complejos de los roles, como la concesión de acceso a aplicaciones y servicios, consulte Escenarios habituales en los roles de IAM.
importante
Conceda acceso únicamente a las entidades en las que confíe y conceda el nivel mínimo de acceso necesario. Siempre que la entidad de confianza sea otra cuenta de AWS, se le puede conceder acceso a su recurso a cualquier entidad principal de IAM. La cuenta de confianza de AWS puede delegar acceso únicamente en la medida en que se ha concedido acceso a dicha cuenta; no puede delegar más acceso que el que la propia cuenta tiene.
Para obtener información sobre los permisos, las políticas y el lenguaje de la política de permisos que debe utilizar para escribir políticas, consulte Recursos de AWS para administración de acceso.
