Usando o AWS Organizations para fins de segurança - AWSOrientação prescritiva

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á.

Usando o AWS Organizations para fins de segurança

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

AWS Organizations Account Account Account Account Account Account Account Account Ao usar o AWS Organizations, você pode criar programaticamente novas contas da AWS, alocar recursos, agrupar contas para organizar suas cargas de trabalho e aplicar políticas a contas ou grupos de contas para governança. Uma organização da AWS Account para que você possa administrá-las como uma só unidade. Ele tem uma AWS e zero ou mais contas-membro. A maioria de suas cargas de trabalho reside em contas de membros, exceto por alguns processos gerenciados centralmente que devem residir na conta de gerenciamento ou em contas designadas como administradores delegados para serviços específicos da AWS. Você pode fornecer ferramentas e acesso de um local central para que sua equipe de segurança gerencie as necessidades de segurança em nome de uma organização da AWS. Você pode reduzir a duplicação de recursos compartilhando recursos essenciais em sua organização da AWS. Você pode agrupar contas em unidades organizacionais (OUs) da AWS, que podem representar diferentes ambientes com base nos requisitos e na finalidade da carga de trabalho.

Com o AWS Organizations, você pode usar políticas de controle de serviços (SCPs) para aplicar barreiras de permissão no nível da organização, UO ou da conta da AWS. Essas barreiras de proteção se aplicam aos diretores da conta de uma organização, com exceção da conta de gerenciamento (que é um dos motivos para não executar cargas de trabalho nessa conta). Quando você vincula um SCP a uma OU, ele é herdado pelas OUs secundárias e pelas contas da OU. Os SCPs não concedem nenhuma permissão. Em vez disso, os SCPs especificam as permissões máximas para uma organização, UO ou conta da AWS. Você ainda precisa anexar políticas baseadas em identidade ou em recurso para diretores ou recursos em suas contas da AWS para conceder permissões a eles. Por exemplo, se um SCP negar acesso a todo o Amazon S3, um administrador afetado pelo SCP não terá acesso ao Amazon S3, mesmo que lhe seja explicitamente concedido acesso por meio de uma política do IAM. Para obter informações detalhadas sobre como as políticas do IAM são avaliadas, o papel dos SCPs e como o acesso é finalmente concedido ou negado, consulte a lógica de avaliação de políticas na documentação do IAM. 

O AWS Control Tower oferece uma forma simplificada de configurar e controlar várias contas. Ele automatiza a configuração de contas em sua organização da AWS, automatiza o provisionamento, aplica barreiras de proteção (que incluem controles preventivos e de detetive) e fornece um painel para visibilidade. Uma política de gerenciamento do IAM, um limite de permissões, é anexada a entidades do IAM (usuários ou funções) e define as permissões máximas que uma política baseada em identidade pode conceder a uma entidade do IAM.

O AWS Organizations ajuda você a configurar os serviços da AWS que se aplicam a todas as suas contas. Por exemplo, você pode configurar o registro central de todas as ações realizadas em sua organização da AWS usando a AWSCloudTrail e impedir que as contas dos membros desabilitem o registro. Você também pode agregar centralmente os dados das regras que você definiu usando o AWS Config, para que você possa auditar suas cargas de trabalho quanto à conformidade e reagir rapidamente às mudanças. Você pode usarCloudFormationStackSets a AWS para gerenciar centralmenteCloudFormation as pilhas da AWS em todas as contas e OUs em sua organização da AWS, para que você possa provisionar automaticamente uma nova conta para atender aos seus requisitos de segurança. 

A configuração padrão do AWS Organizations suporta o uso de SCPs como listas de negação. Usando uma estratégia de lista de negação, os administradores de contas de membros podem delegar todos os serviços e ações até que você crie e anexe um SCP que negue um serviço específico ou conjunto de ações. As declarações de negação exigem menos manutenção do que uma lista de permissões, porque você não precisa atualizá-las quando a AWS adiciona novos serviços. As declarações de negação geralmente têm menos caracteres, então é mais fácil ficar dentro do tamanho máximo para SCPs. Em uma declaração em que o elemento Effect tem um valor de Deny, você também pode restringir o acesso a recursos específicos ou definir condições para quando as SCPs estão em vigor. Por outro lado, uma instrução Allow em um SCP se aplica a todos os recursos ("*") e não pode ser restringida por condições. Para obter mais informações e exemplos, consulte Estratégias para usar SCPs na documentação do AWS Organizations.

Considerações sobre design
  • Como alternativa, para usar SCPs como uma lista de permissões, você deve substituir oFullAWSAccess SCP gerenciado pela AWS por um SCP que permita explicitamente somente os serviços e ações que você deseja permitir. Para que uma permissão seja habilitada para uma conta específica, cada SCP (da raiz até cada OU no caminho direto até a conta e até mesmo anexado à própria conta) deve permitir essa permissão. Esse modelo é mais restritivo por natureza e pode ser adequado para cargas de trabalho altamente regulamentadas e confidenciais. Essa abordagem exige que você permita explicitamente cada serviço ou ação do IAM no caminho da conta da AWS até a OU.

  • Idealmente, você usaria uma combinação de estratégias de lista de negação e lista de permissão. Use a lista de permissões para definir a lista de serviços permitidos da AWS aprovados para uso em uma organização da AWS e anexe esse SCP à raiz da sua organização da AWS. Se você tiver um conjunto diferente de serviços permitidos por seu ambiente de desenvolvimento, você anexaria os respectivos SCPs em cada UO. Em seguida, você pode usar a lista de negação para definir barreiras corporativas negando explicitamente ações específicas do IAM.