As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
IAMrecursos
Influencie o futuro da Arquitetura de Referência de AWS Segurança (AWS SRA) 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 AWS organização, das AWS contas e dos AWS serviços. Você não pode implantar nenhum AWS serviço sem primeiro criar IAM entidades e conceder permissões. Uma explicação completa 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 IAM melhores práticas, consulte as melhores práticas de segurança IAM na AWS documentação, nos IAMartigos
no blog de AWS segurança e nas apresentações do AWSre:Invent . -
O pilar de segurança 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 as permissões continuamente e estabelecer um processo de acesso de emergência.
-
A tabela a seguir e as notas que a acompanham fornecem uma visão geral de alto nível das orientações recomendadas sobre os tipos de políticas de IAM permissão 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. IAM
Caso de uso ou política |
Efeito |
Gerenciado por |
Finalidade |
Pertence a |
Afeta |
Implantado em |
Políticas de controle de serviços (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 IAM funções usadas pela plataforma para operar uma conta) |
Conceder e restringir |
Equipe central, como plataforma, segurança ou IAM equipe [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 IAM funções que concedem aos usuários permissões para realizar seu trabalho) |
Conceder e restringir |
Equipe central, como plataforma, segurança ou IAM equipe [1] |
Permissões para funções humanas [5] |
Conta única [4] |
Diretores federados [5] e IAM usuários [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 IAM equipe [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:
-
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.
-
Para usarSCPs, você deve habilitar todos os recursos dentro do AWS Organizations.
-
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 AWS Lambda e AWS Config) e outras permissões. Essa configuração geralmente é fornecida quando a conta é provisionada.
-
Embora pertençam 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. AWS CloudFormation StackSets
-
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 IAM equipe e as equipes de auditoria de segurança.
-
Use federação de identidades (em vez de IAM usuários locais) sempre que possível.
-
Os limites de permissões são usados por administradores delegados. Essa IAM política 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 impor a anexação do limite de permissões. -
Isso pressupõe que grades de proteção suficientes (por exemplo, SCPs e limites de permissões) tenham sido implantadas.
-
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.
-
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).
-
Uma IAM política baseada em recursos pode se referir a qualquer diretor 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 IAM as identidades 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 os limites de permissões para delegar a IAM administração de forma mais segura.
-
Certifique-se de que os administradores delegados anexem a política de IAM limites 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 baseadas em recursos para negar amplo IAM acesso aos recursos.
-
Use o IAM consultor de AWS IAM acesso AWS CloudTrail, o 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 IAM de políticas com base nas solicitações.