SEC03-BP09 Compartilhar recursos com segurança com terceiros

A segurança de seu ambiente de nuvem não é interrompida em sua organização. Sua organização pode contar com terceiros para gerenciar uma parte de seus dados. O gerenciamento de permissões para o sistema gerenciado por terceiros deve seguir a prática de acesso just-in-time utilizando o princípio de privilégio mínimo com credenciais temporárias. A trabalhar em parceria com terceiros, é possível reduzir o escopo do impacto e o risco de acesso acidental.

Resultado desejado: credenciais do AWS Identity and Access Management (IAM) de longo prazo, chaves de acesso do IAM e chaves secretas associadas a um usuário podem ser usadas por qualquer pessoa desde que as credenciais sejam válidas e ativas. O uso de um perfil do IAM e credenciais temporárias ajuda você a melhorar seu procedimento de segurança geral reduzindo o esforço para manter credenciais de longo prazo, inclusive o gerenciamento e a sobrecarga operacional dessas informações sigilosas. Ao utilizar um identificador universalmente exclusivo (UUID) para o ID externo na política de confiança do IAM e manter as políticas do IAM anexadas ao perfil do IAM sob seu controle, é possível fazer auditoria e garantir que o acesso concedido a terceiros não seja permissivo demais. Para ter orientações prescritivas sobre como analisar recursos compartilhados externamente, consulte SEC03-BP07 Analisar o acesso público e entre contas.

Antipadrões comuns:

• Utilizar a política de confiança do IAM padrão sem condições.

• Utilizar credenciais e chaves de acesso de longo prazo do IAM.

• Reutilizar IDs externos.

Nível de risco exposto se esta prática recomendada não é estabelecida: médio

Orientação de implementação

Talvez você deseje permitir o compartilhamento de recursos fora do AWS Organizations ou conceder a terceiros acesso à sua conta. Por exemplo, um parceiro (terceiros) pode oferecer uma solução de monitoramento que precise acessar recursos em sua conta. Nesses casos, crie um perfil entre contas do IAM somente com os privilégios necessários para o parceiro. Além disso, defina uma política de segurança com o uso da condição de ID externo. Ao utilizar um ID externo, você ou o parceiro pode gerar um ID exclusivo para cada cliente, terceiros ou locação. O ID exclusivo não deve ser controlado por ninguém, exceto por você, depois de criado. O parceiro deve implementar um processo para relacionar o ID externo ao cliente de forma segura, auditável e reproduzível.

Também é possível usar o IAM Roles Anywhere para gerenciar perfis do IAM para aplicações fora do AWS que utilizam APIs da AWS.

Se o parceiro não precisar mais de acesso ao seu ambiente, remova o perfil. Evite fornecer credenciais de longo prazo para terceiros. Esteja ciente de outros serviços da AWS compatíveis com o compartilhamento. Por exemplo, o AWS Well-Architected Tool possibilita o compartilhamento de uma workload com outras Contas da AWS, e o AWS Resource Access Manager ajuda você a compartilhar com segurança um recurso da AWS que você possua com outras contas.

Etapas da implementação

1. Utilize perfis entre contas para fornecer acesso a contas externas.

   Os perfis entre contas reduzem a quantidade de informações sigilosas armazenadas por contas externas e terceiros para atender aos clientes. Os perfis entre contas possibilitam a você conceder acesso a recursos da AWS em sua conta de forma segura a terceiros, como AWS Partners ou outras contas em sua organização e, ao mesmo tempo, manter a capacidade de gerenciar e auditar esse acesso.

   O parceiro pode oferecer serviço a você a partir de uma infraestrutura híbrida ou, como alternativa, extrair dados de um local externo. O IAM Roles Anywhere ajuda você a possibilitar que workloads de terceiros interajam com segurança com suas workloads da AWS e reduzir ainda mais a necessidade de credenciais de longo prazo.

   Você não deve usar credenciais ou chaves de acesso de longo prazo associadas a usuários para conceder acesso a contas externas. Em vez disso, utilize perfis entre contas para conceder acesso entre contas.

2. Utilize um ID externo com terceiros.

   O uso de um ID externo possibilita designar quem pode assumir um perfil em uma política de confiança do IAM. A política de confiança pode exigir que o usuário que assume o perfil imponha a condição e o destino no qual ele está operando. Ele também fornece uma maneira para que o proprietário da conta permita que a função seja assumida somente em circunstâncias específicas. A função principal do ID externo é resolver e evitar o problema de substituto confuso.

   Utilize um ID externo se você for proprietário de uma Conta da AWS e tiver configurado um perfil para terceiros que acesse outras Contas da AWS além da sua, ou quando você pode assumir perfis em nome de clientes diferentes. Trabalhe com terceiros ou a AWS Partner para estabelecer uma condição de ID externo a ser incluída na política de confiança do IAM.

3. Utilize IDs externos universalmente exclusivos.

   Implemente um processo que gere um valor exclusivo aleatório para um ID externo, como um identificador universalmente exclusivo (UUID). Um parceiro que reutilize IDs externos entre diferentes clientes não resolve o problema de substituto confuso porque o cliente A pode ser capaz de visualizar dados do cliente B utilizando o ARN do perfil do cliente B junto com o ID externo duplicado. Em um ambiente de vários locatários, em que um parceiro atende a vários clientes com diferentes Contas da AWS, o parceiro deve usar um ID exclusivo diferente como o ID externo de cada Conta da AWS. O parceiro é responsável por detectar IDs externos duplicados e mapear de forma segura cada cliente ao seu respectivo ID externo. O parceiro deve testar para verificar se ele pode assumir o perfil somente ao especificar o ID externo. O parceiro deve evitar armazenar o ARN do perfil do cliente e o ID externo até que este seja necessário.

   O ID externo não é tratado como segredo, mas ele não pode ser um valor facilmente dedutível, como um número de telefone, um nome ou o ID da conta. Torne o ID externo um campo somente leitura de forma que o ID externo não possa ser alterado com o fim de representar a configuração.

   Você ou o parceiro podem gerar o ID externo. Defina um processo para determinar quem é responsável pela geração do ID. Seja qual for a entidade que crie o ID externo, o parceiro impõe a exclusividade e os formatos de forma consistente entre os clientes.

4. Deprecie credenciais de longo prazo fornecidas pelo cliente.

   Deprecie o uso de credenciais de longo prazo e use perfis entre clientes ou o IAM Roles Anywhere. Se você precisar utilizar credenciais de longo prazo, estabeleça um plano para migrar para um acesso baseado em perfil. Para obter detalhes sobre como gerenciar chaves, consulte Gerenciamento de identidades. Trabalhe também com a equipe de sua Conta da AWS e o parceiro para estabelecer um runbook de mitigação de riscos. Para ter orientações prescritivas sobre como responder e mitigar o impacto em potencial do incidente de segurança, consulte Resposta a incidentes.

5. Verifique se a configuração tem orientações prescritivas ou é automatizada.

   A política criada para acesso entre contas em suas contas deve seguir o princípio de privilégio mínimo. O parceiro deve fornecer um documento de política de perfil ou um mecanismo de configuração automatizada que utilize um modelo do AWS CloudFormation ou um equivalente para você. Isso reduz a chance de erros associados à criação manual de políticas e oferece uma trilha auditável. Para ter mais informações sobre como usar um modelo do AWS CloudFormation para criar perfis entre contas, consulte Perfis entre contas.

   O parceiro deve fornecer um mecanismo de configuração automatizado e auditável. No entanto, ao utilizar o documento de política de perfis que descreve o acesso necessário, você deve automatizar a configuração do perfil. Com um modelo do AWS CloudFormation ou equivalente, você deve monitorar alterações com detecção de desvios como parte da prática de auditoria.

6. Considere alterações.

   Sua estrutura de contas, sua necessidade de terceiros ou a oferta de serviço pode ser alterada. Você deve antecipar alterações e falhas e planejar adequadamente com as pessoas, o processo e a tecnologia corretos. Audite o nível de acesso que você concede periodicamente e implemente métodos de detecção para alertar você de alterações inesperadas. Monitore e audite o uso do perfil e o datastore dos IDs externos. Você deve estar preparado para revogar o acesso de terceiros, seja de forma temporária ou permanente, como resultado de alterações ou padrões de acesso inesperados. Além disso, meça o impacto de sua operação de revogação, inclusive o tempo para realizá-la, as pessoas envolvidas, o custo e o impacto de outros recursos.

   Para ter orientações prescritivas sobre métodos de detecção, consulte as Práticas recomendadas de detecção.

Recursos

Práticas recomendadas relacionadas:

• SEC02-BP02 Usar credenciais temporárias

• SEC03-BP05 Definir barreiras de proteção de permissões para sua organização

• SEC03-BP06 Gerenciar o acesso com base no ciclo de vida

• SEC03-BP07 Analisar o acesso público e entre contas

• SEC04 Detecção

Documentos relacionados:

• Proprietário do bucket concede permissão entre contas a objetos que não possui

• Como usar políticas de confiança com os perfis do IAM

• Delegar acesso entre Contas da AWS usando funções do IAM

• Como acesso recursos em outra Conta da AWS usando o IAM?

• Práticas recomendadas de segurança no IAM

• Lógica de avaliação de política entre contas

• Como usar um ID externo ao conceder acesso a seus recursos da AWS a terceiros

• Coletar informações de recursos do AWS CloudFormation criados em contas externas com recursos personalizados

• Usar ID externo com segurança para acessar contas da AWS pertencentes a outros

• Estender perfis do IAM fora do IAM com IAM Roles Anywhere)

Vídeos relacionados:

• Como permito que usuários ou perfis em uma Conta da AWS separada acessem minha Conta da AWS?

• AWS re:Invent 2018: Torne-se um mestre em políticas do IAM em 60 minutos ou menos

• AWSPráticas recomendadas do IAM e decisões de design

Exemplos relacionados:

• Well-Architected Lab: Assumir perfil do IAM entre contas do Lambda (Nível 300)

• Configurar o acesso entre contas ao Amazon DynamoDB

• AWS STS Network Query Tool