Acesso a recursos entre contas no IAM

Para alguns serviços da AWS, você pode conceder acesso entre contas para os seus recursos usando o IAM. Para fazer isso, você pode anexar uma política de recurso diretamente ao recurso que você deseja compartilhar ou usar um perfil como um proxy.

Para compartilhar o recurso diretamente, ele deve ser compatível com políticas baseadas em recursos. Ao contrário de uma política baseada em identidade, uma política baseada em recursos especifica quem (qual entidade principal) pode acessar esse recurso.

Use um perfil como proxy quando quiser acessar recursos em outra conta que não sejam compatíveis com políticas baseadas em recursos.

Para obter detalhes sobre as diferenças entre esses tipos de política, consulte Políticas baseadas em identidade e em recurso.

nota

As funções do IAM e as políticas baseadas em recurso delegam o acesso entre contas em uma única partição. Por exemplo, você tem uma conta no Oeste dos EUA (Norte da Califórnia) na partição aws padrão. Você também tem uma conta na China na partição aws-cn. Você não pode usar uma política baseada em recursos na sua conta na China para permitir acesso a usuários na sua conta da AWS padrão.

Acesso entre contas usando perfis

Nem todos os serviços da AWS são compatíveis com políticas baseadas em recursos. Para esses serviços, você pode usar perfis do IAM entre contas para centralizar o gerenciamento de permissões ao fornecer acesso entre contas a vários serviços. Um perfil do IAM entre contas é um perfil do IAM que inclui uma política de confiança que permite que as entidades principais do IAM em outra conta da AWS assumam o perfil. Simplificando, você pode criar um perfil em uma conta da AWS que delega permissões específicas para outra conta da AWS.

Para obter informações sobre como anexar uma política a uma identidade do IAM, consulte Gerenciar políticas do IAM.

nota

Quando uma entidade principal muda para um perfil para usar temporariamente as permissões do perfil, ela abre mão de suas permissões originais e assume as permissões atribuídas ao perfil que assumiu.

Vamos dar uma olhada no processo geral aplicado ao software de parceiro da APN que precisa acessar uma conta de cliente.

1. O cliente cria um perfil do IAM na própria conta com uma política que permite acessar os recursos do Amazon S3 que o parceiro da APN exige. Neste exemplo, o nome do perfil é APNPartner.

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Effect": "Allow",
               "Action": "s3:*",
               "Resource": [
                   "arn:aws:s3:::bucket-name"
               ]
           }
       ]
   }

2. Em seguida, o cliente especifica que o perfil pode ser assumido pela conta da AWS do parceiro fornecendo o ID da Conta da AWS do parceiro da APN na política de confiança do perfil APNPartner.

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Effect": "Allow",
               "Principal": {
                   "AWS": "arn:aws:iam::APN-account-ID:role/APN-user-name"
               },
               "Action": "sts:AssumeRole"
           }
       ]
   }

3. O cliente fornece o nome do recurso da Amazon (ARN) do perfil ao parceiro da APN. O ARN é o nome totalmente qualificado do perfil.

   arn:aws:iam::APN-ACCOUNT-ID:role/APNPartner

   nota

   Recomendamos usar uma ID externa em situações multilocatárias. Para obter detalhes, consulte Acesso às Contas da AWS de propriedade de terceiros.

4. Quando o software do parceiro da APN precisa acessar a conta do cliente, o software chama a API AssumeRole no AWS Security Token Service com o ARN do perfil na conta do cliente. O STS retorna uma  credencial da AWS temporária que permite que o software faça seu trabalho.

Para ver outro exemplo de concessão de acesso entre contas usando perfis, consulte Acesso a um usuário do IAM em outra Conta da AWS de sua propriedade. Você também pode seguir o Tutorial do IAM: Delegar acesso entre contas da AWS usando funções do IAM.

Acesso entre contas usando políticas baseadas em recursos

Quando uma conta acessa um recurso por meio de outra conta usando uma política baseada em recursos, a entidade principal ainda trabalha na conta confiável e não precisa abrir mão de suas permissões para receber as permissões do perfil. Em outras palavras, a entidade principal continua a ter acesso aos recursos na conta confiável ao mesmo tempo em que tem acesso ao recurso na conta de confiança. Isso é útil para tarefas como cópia de informações de ou para o recurso compartilhado em outra conta.

As entidades de segurança que você pode especificar em uma política baseada em recurso incluem contas, usuários do IAM, usuários federados, funções do IAM, sessões de função assumida ou produtos da AWS. Para obter mais informações, consulte Especificar uma entidade principal.

Para saber se as entidades principais de contas fora de sua zona de confiança (organização ou conta confiável) têm acesso para assumir seus perfis, consulte Identificar recursos compartilhados com uma entidade principal externa.

A lista a seguir inclui alguns dos serviços da AWS que oferecem suporte às políticas baseadas em recursos. Para obter uma lista completa do número crescente de serviços da AWS que compatíveis com a anexação de políticas de permissão aos recursos em vez de nos principais, consulte Serviços da AWS que funcionam com o IAMe procure os serviços que têm Sim na coluna Baseadas em recursos.

• Buckets do Amazon S3: a política é anexada ao bucket, mas controla o acesso ao bucket e aos objetos nele. Para obter mais informações, consulte Bucket policies for Amazon S3 no Guia do usuário do Amazon Simple Storage Service. Em alguns casos, pode ser melhor usar funções para acesso entre contas ao Amazon S3. Para mais informações, consulte as demonstrações de exemplo no Guia do usuário do Amazon Simple Storage Service.

• Tópicos do Amazon Simple Notification Service (Amazon SNS): para obter mais informações, acesse Casos de exemplo para controle de acesso do Amazon SNS no Guia do desenvolvedor do Amazon Simple Notification Service.

• Filas do Amazon Simple Queue Service (Amazon SQS): para obter mais informações, acesse Apêndice: A linguagem da política de acesso no Guia do desenvolvedor do Amazon Simple Queue Service.

Políticas baseadas em recursos para delegar permissões da AWS

Se um recurso conceder permissões às entidades de segurança em sua conta, você poderá delegar essas permissões a identidades do IAM específicas. As identidades são usuários, grupos de usuários ou funções na conta. Você delega permissões anexando uma política à identidade. Você pode conceder até o máximo de permissões permitidas pela conta proprietária do recurso.

Importante

No acesso entre contas, uma entidade principal precisa de uma Allow na política de identidade e uma política baseada em recursos.

Suponha que uma política baseada em recursos permita acesso administrativo total a um recurso a todos os principais na conta. Em seguida, você pode delegar acesso total, acesso somente leitura ou qualquer outro acesso parcial aos principais na sua conta da AWS. Como alternativa, se a política baseada em recursos permitir somente permissões de lista, você só poderá delegar o acesso à lista. Se você tentar delegar mais permissões do que sua conta possui, os principais ainda terão apenas acesso de lista.

Para obter mais informações sobre como essas decisões são tomadas, consulte Determinar se uma solicitação é permitida ou negada em uma conta.

nota

As funções do IAM e as políticas baseadas em recurso delegam o acesso entre contas em uma única partição. Por exemplo, não é possível adicionar acesso entre contas entre uma conta na partição padrão aws e uma conta na partição aws-cn.

Por exemplo, presuma que você gerencie a AccountA e a AccountB. Na AccountA, você tem o bucket do Amazon S3 chamado BucketA.

1. Anexe uma política baseada em recursos ao BucketA que permite que todas as entidades principais na AccountB tenham acesso total aos objetos no bucket. Eles podem criar, ler ou excluir objetos nesse bucket.

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Sid": "PrincipalAccess",
               "Effect": "Allow",
               "Principal": {"AWS": "arn:aws:iam::AccountB:root"},
               "Action": "s3:*",
               "Resource": "arn:aws:s3:::BucketA/*"
               }
           ]
   }

   A AccountA fornece acesso total à AccountB para o BucketA nomeando a AccountB como uma entidade principal na política baseada em recursos. Como resultado, a AccountB é autorizada a realizar qualquer ação no BucketA, e o administrador da AccountB pode delegar acesso aos seus usuários na AccountB.

   O usuário raiz da AccountB tem todas as permissões concedidas à conta. Portanto, o usuário raiz tem acesso total ao BucketA.

2. Na AccountB, anexe uma política ao usuário do IAM denominado User2. Essa política permite que o usuário tenha acesso somente leitura aos objetos no BucketA. Isso significa que o User2 pode visualizar os objetos, mas não criá-los, editá-los ou excluí-los.

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Effect" : "Allow", 
               "Action" : [ 
                   "s3:Get*", 
                   "s3:List*" ], 
                   "Resource" : "arn:aws:s3:::BucketA/*" 
           } 
       ]
   }

   O nível máximo de acesso que a AccountB pode delegar é o nível de acesso concedido à conta. Nesse caso, a política baseada em recursos concedeu acesso total à AccountB, mas o User2 tem acesso somente leitura.

   O administrador da AccountB não concede acesso ao User1. Por padrão, os usuários não têm permissões, exceto aquelas explicitamente concedidas, então o User1 não tem acesso ao BucketA.

O IAM avalia as permissões de um principal no momento que este faz uma solicitação. Se você usar curingas (*) para fornecer aos usuários acesso total aos recursos, as entidades principais poderão acessar qualquer recurso ao qual a conta da AWS tenha acesso. Isso é verdadeiro mesmo para recursos que você adiciona ou aos quais obtém acesso após criar a política de usuário.

No exemplo anterior, se a AccountB tivesse anexado uma política ao User2 que permitisse acesso total aos recursos em todas as contas, o User2 teria acesso automaticamente a quaisquer recursos aos quais a AccountB tivesse acesso. Isso inclui o acesso ao BucketA e o acesso a quaisquer outros recursos concedido por políticas baseadas em recursos na AccountA.

Para obter mais informações sobre usos complexos de perfis, como conceder acesso a aplicações e serviços, consulte Cenários comuns para perfis do IAM.

Importante

Conceda acesso somente a entidades confiáveis e atribua o nível mínimo de acesso necessário. Sempre que a entidade confiável for outra conta da AWS, qualquer  entidade principal do IAM poderá ter acesso ao seu recurso. A conta confiável da AWS pode delegar acesso apenas na medida em que o acesso foi concedido; ela não pode delegar mais acessos do que o concedido para a própria conta.

Para obter informações sobre permissões, políticas e a linguagem de política de permissões usada para criar políticas, consulte Gerenciamento de acesso para recursos da AWS.