Funções entre Contas e Políticas de Recursos

As arquiteturas reais abrangem várias contas: uma conta de produção, uma conta de registros e uma conta de serviços compartilhados. Cargas de trabalho e pessoas frequentemente precisam acessar recursos entre esses limites.

A maneira segura nunca é copiar credenciais entre contas. Em vez disso, conceda acesso com escopo definido usando funções entre contas ou políticas baseadas em recursos.

O padrão mais comum é uma função na conta de destino que um principal da conta de origem assume.

• A política de confiança da função nomeia a conta ou o principal de origem.
• O principal de origem chama AssumeRole e recebe credenciais temporárias.
• Em seguida, ele atua na conta de destino dentro das permissões da função.

A assunção de uma função entre contas exige que ambos os lados a permitam:

• A política de confiança da função de destino permite o principal de origem.
• A política de identidade do principal de origem permite sts:AssumeRole nessa função.

Se qualquer uma delas estiver ausente, a assunção falhará. Essa verificação dupla é um ponto frequente em exames.

Alguns serviços são compatíveis com políticas baseadas em recursos anexadas diretamente ao recurso, como uma política de bucket do S3, uma política de chave do KMS ou uma política de fila do SQS.

Essas políticas podem conceder acesso a um principal de outra conta sem que esse principal assuma uma função. A conta externa usa a própria identidade, e a política do recurso autoriza o acesso.

Escolha o mecanismo de acordo com o serviço:

• Para serviços sem política de recursos (EC2 e a maioria das APIs), use uma função entre contas.
• Para S3, KMS, SNS, SQS, Lambda e outros, uma política de recursos pode conceder acesso direto entre contas.

As políticas de recursos evitam um salto adicional de AssumeRole.

Ao conceder acesso entre contas a um terceiro (como um fornecedor de SaaS), adicione uma condição de ID externo à política de confiança.

O fornecedor deve passar um valor secreto exclusivo ao assumir a função. Isso bloqueia o problema do delegado confuso, no qual um invasor induz o fornecedor a acessar a conta do cliente errado.

As funções entre contas devem conceder o mínimo necessário, com escopo limitado a recursos e ações específicos.

Um erro comum é estabelecer uma confiança ampla em uma conta externa inteira e combiná-la com permissões de administrador. Restrinja a confiança a uma função ou usuário específico e as permissões à tarefa exata.

Um design frequente centraliza uma função em uma conta que é acessada por outras por meio de funções; por exemplo, uma conta de segurança assumindo funções somente leitura em todas as contas de cargas de trabalho.

Cada conta de carga de trabalho hospeda uma função com o mesmo nome, que confia na conta de segurança, para que as ferramentas possam verificar todas as contas uniformemente.

O AWS Resource Access Manager (RAM) compartilha recursos específicos, como sub-redes ou Transit Gateways, entre contas de uma organização.

O RAM serve para compartilhar o próprio recurso, e não para conceder permissões de API para atuar nele. Ele complementa funções e políticas de recursos no compartilhamento de redes e infraestrutura.

O acesso entre contas amplia sua superfície de confiança, portanto, audite-o regularmente.

• O CloudTrail registra cada chamada de AssumeRole e de API entre contas.
• O IAM Access Analyzer sinaliza políticas de recursos que concedem acesso fora da sua conta.

Analise esses registros para detectar compartilhamentos não intencionais logo no início.

Para conectar contas com segurança: prefira funções para computação e APIs, políticas de recursos para serviços de armazenamento e mensagens e sempre aplique o privilégio mínimo, usando um ID externo para terceiros.

Nunca compartilhe chaves de longo prazo entre contas.

Analise o acesso entre contas.

Você aprendeu a conectar contas com segurança.

• As funções entre contas precisam de uma política de confiança e de uma política de identidade de origem.
• As políticas baseadas em recursos concedem acesso direto para serviços como S3 e KMS.
• Use um ID externo para terceiros e faça auditorias com o Access Analyzer e o CloudTrail.