Recursos do IAM

Influencie o futuro da Arquitetura de Referência de AWS Segurança (AWSSRA) respondendo a uma breve pesquisa.

Embora o AWS Identity and Access Management (IAM) não seja um serviço incluído em um diagrama de arquitetura tradicional, ele abrange todos os aspectos da organização, das contas e dos serviços da AWS. Você não pode implantar nenhum serviço da AWS sem primeiro criar entidades do IAM e conceder permissões. Uma explicação completa do IAM está além do escopo deste documento, mas esta seção fornece resumos importantes das recomendações de melhores práticas e dicas para recursos adicionais.

• Para obter as melhores práticas do IAM, consulte as melhores práticas de segurança no IAM na documentação da AWS, os artigos do IAM no blog de segurança da AWS e as apresentações do AWS re:Invent.

• O pilar de segurança do AWS Well-Architected descreve as principais etapas do processo de gerenciamento de permissões: definir barreiras de permissões, conceder acesso com privilégios mínimos, analisar o acesso público e entre contas, compartilhar recursos com segurança, reduzir permissões continuamente e estabelecer um processo de acesso de emergência.

• A tabela a seguir e as notas anexas fornecem uma visão geral de alto nível das orientações recomendadas sobre os tipos de políticas de permissão do IAM disponíveis e como usá-las em sua arquitetura de segurança. Para saber mais, assista ao vídeo do AWS re:Invent 2020 sobre como escolher a combinação certa de políticas do IAM.

 

Caso de uso ou política	Efeito	Gerenciado por	Finalidade	Pertence a	Afeta	Implantado em
Políticas de controle de serviço (SCPs)	Restrict	Equipe central, como plataforma ou equipe de segurança [1]	Guardrails, governança	Organização, OU, conta	Todos os diretores em organização, OU e contas	Conta de gerenciamento da organização [2]
Políticas básicas de automação de contas (as funções do IAM usadas pela plataforma para operar uma conta)	Conceder e restringir	Equipe central, como plataforma, segurança ou equipe do IAM [1]	Permissões para funções (básicas) que não sejam de automação de carga de trabalho [3]	Conta única [4]	Princípios usados pela automação em uma conta de membro	Contas-membro
Políticas humanas básicas (as funções do IAM que concedem aos usuários permissões para realizar seu trabalho)	Conceder e restringir	Equipe central, como plataforma, segurança ou equipe do IAM [1]	Permissões para funções humanas [5]	Conta única [4]	Diretores federados [5] e usuários do IAM [6]	Contas-membro
Limites de permissões (permissões máximas que um desenvolvedor capacitado pode atribuir a outro diretor)	Restrict	Equipe central, como plataforma, segurança ou equipe do IAM [1]	Guardrails para funções de candidatura (devem ser aplicados)	Conta única [4]	Funções individuais para um aplicativo ou carga de trabalho nessa conta [7]	Contas-membro
Políticas de função de máquina para aplicativos (função associada à infraestrutura implantada por desenvolvedores)	Conceder e restringir	Delegado aos desenvolvedores [8]	Permissão para o aplicativo ou carga de trabalho [9]	Conta única	Um principal nesta conta	Contas-membro
Políticas de recursos	Conceder e restringir	Delegado aos desenvolvedores [8,10]	Permissões para recursos	Conta única	Um principal em uma conta [11]	Contas-membro

  

Notas da tabela:

1. As empresas têm muitas equipes centralizadas (como plataforma em nuvem, operações de segurança ou equipes de gerenciamento de identidade e acesso) que dividem as responsabilidades desses controles independentes e revisam as políticas umas das outras. Os exemplos na tabela são espaços reservados. Você precisará determinar a separação de tarefas mais eficaz para sua empresa.

2. Para usar SCPs, você deve habilitar todos os recursos dentro do AWS Organizations.

3. Geralmente, são necessárias funções e políticas básicas comuns para permitir a automação, como permissões para o pipeline, ferramentas de implantação, ferramentas de monitoramento (por exemplo, regras do AWS Lambda e do AWS Config) e outras permissões. Essa configuração geralmente é fornecida quando a conta é provisionada.

4. Embora estejam relacionados a um recurso (como uma função ou política) em uma única conta, eles podem ser replicados ou implantados em várias contas usando a AWS. CloudFormation StackSets

5. Defina um conjunto básico de funções e políticas humanas básicas que são implantadas em todas as contas dos membros por uma equipe central (geralmente durante o provisionamento da conta). Os exemplos incluem os desenvolvedores da equipe da plataforma, a equipe do IAM e as equipes de auditoria de segurança.

6. Use a federação de identidades (em vez de usuários locais do IAM) sempre que possível.

7. Os limites de permissões são usados por administradores delegados. Essa política do IAM define as permissões máximas e substitui outras políticas (incluindo “*:*” políticas que permitem todas as ações nos recursos). Os limites de permissões devem ser exigidos nas políticas humanas básicas como condição para criar funções (como funções de desempenho da carga de trabalho) e anexar políticas. Configurações adicionais, como SCPs, impõem a anexação do limite de permissões.

8. Isso pressupõe que grades de proteção suficientes (por exemplo, SCPs e limites de permissões) tenham sido implantadas.

9. Essas políticas opcionais podem ser fornecidas durante o provisionamento da conta ou como parte do processo de desenvolvimento do aplicativo. A permissão para criar e anexar essas políticas será regida pelas próprias permissões do desenvolvedor do aplicativo.

10. Além das permissões da conta local, uma equipe centralizada (como a equipe da plataforma em nuvem ou a equipe de operações de segurança) geralmente gerencia algumas políticas baseadas em recursos para permitir o acesso entre contas para operar as contas (por exemplo, para fornecer acesso aos buckets do S3 para registro).

11. Uma política de IAM baseada em recursos pode se referir a qualquer principal em qualquer conta para permitir ou negar acesso a seus recursos. Pode até se referir a diretores anônimos para permitir o acesso público.

 Garantir que as identidades do IAM tenham apenas as permissões necessárias para um conjunto bem delineado de tarefas é fundamental para reduzir o risco de abuso malicioso ou não intencional de permissões. Estabelecer e manter um modelo de privilégio mínimo exige um plano deliberado para atualizar, avaliar e mitigar continuamente o excesso de privilégios. Aqui estão algumas recomendações adicionais para esse plano:

• Use o modelo de governança da sua organização e o apetite estabelecido pelo risco para estabelecer barreiras e limites de permissões específicos.

• Implemente o menor privilégio por meio de um processo continuamente iterativo. Este não é um exercício único.

• Use SCPs para reduzir o risco acionável. Pretende-se que sejam amplas barreiras de proteção, não controles restritos.

• Use limites de permissões para delegar a administração do IAM de forma mais segura.

  • Certifique-se de que os administradores delegados anexem a política de limite do IAM apropriada às funções e aos usuários que eles criam.

• Como defense-in-depth abordagem (em conjunto com políticas baseadas em identidade), use políticas de IAM baseadas em recursos para negar amplo acesso aos recursos.

• Use o consultor de acesso do IAM CloudTrail, a AWS, o AWS IAM Access Analyzer e as ferramentas relacionadas para analisar regularmente o uso histórico e as permissões concedidas. Corrija imediatamente as permissões excessivas óbvias.

• Defina ações amplas para recursos específicos, quando aplicável, em vez de usar um asterisco como curinga para indicar todos os recursos.

• Implemente um mecanismo para identificar, analisar e aprovar rapidamente as exceções da política do IAM com base nas solicitações.