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 AWS Organizations para segurança
| Influencie o futuro da Arquitetura de Referência de AWS Segurança (AWS SRA) respondendo a uma breve pesquisa |
AWS Organizations
Com AWS Organizations, você pode usar SCPse RCPsaplicar proteções de permissão no nível da AWS organização, da OU ou da conta. SCPs são proteções que se aplicam aos diretores na 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ê anexa um SCP a uma OU, a SCP é herdada pela criança OUs e pelas contas dessa OU. SCPs não conceda nenhuma permissão. Em vez disso, eles especificam as permissões máximas disponíveis para seus diretores em uma AWS organização, OU ou conta. Você ainda precisa anexar políticas baseadas em identidade ou em recursos aos diretores ou recursos em sua conta para realmente conceder permissões Contas da AWS a eles. Por exemplo, se um SCP negar acesso a todo o Amazon S3, um principal afetado pelo SCP não terá acesso ao Amazon S3, mesmo que tenha acesso explícito por meio de uma política do IAM. Para obter mais informações sobre como as políticas do IAM são avaliadas, a função e como o acesso é finalmente concedido ou negado, consulte Lógica de avaliação de políticas na documentação do IAM. SCPs
RCPs são barreiras que se aplicam aos recursos nas contas de uma organização, independentemente de os recursos pertencerem à mesma organização. Por exemplo SCPs, RCPs não afete os recursos na conta de gerenciamento e não conceda nenhuma permissão. Quando você anexa um RCP a uma OU, o RCP é herdado pelo filho OUs e pelas contas da OU. RCPs forneça controle central sobre o máximo de permissões disponíveis para recursos em sua organização e, atualmente, ofereça suporte a um subconjunto de Serviços da AWS. Ao projetar SCPs para o seu OUs, recomendamos que você avalie as alterações usando o simulador de políticas do IAM. Você também deve analisar os últimos dados acessados no IAM e usar AWS CloudTrail para registrar o uso do serviço no nível da API para entender o impacto potencial das alterações do SCP.
SCPs e RCPs são controles independentes. Você pode optar por habilitar somente SCPs ou RCPs usar os dois tipos de política juntos com base nos controles de acesso que você deseja aplicar. Por exemplo, se você quiser impedir que os diretores da sua organização acessem recursos fora da sua organização, aplique esse controle usando. SCPs Se você quiser restringir ou impedir que identidades externas acessem seus recursos, aplique esse controle usando. RCPs Para obter mais informações e casos de uso de RCPs e SCPs, consulte Usando SCPs e RCPs na AWS Organizations documentação.
Você pode usar políticas AWS Organizations declarativas para declarar e aplicar centralmente a configuração desejada para uma determinada empresa AWS service (Serviço da AWS) em grande escala em toda a organização. Por exemplo, você pode bloquear o acesso público à internet para recursos do Amazon VPC em toda a sua organização. Diferentemente das políticas de autorização, como SCPs e RCPs, as políticas declarativas são aplicadas no plano de controle AWS de um serviço. As políticas de autorização regulam o acesso ao APIs, enquanto as políticas declarativas são aplicadas diretamente no nível do serviço para impor uma intenção duradoura. Essas políticas ajudam a garantir que a configuração básica de an AWS service (Serviço da AWS) seja sempre mantida, mesmo quando o serviço introduz novos recursos ou. APIs A configuração básica também é mantida quando novas contas são adicionadas a uma organização ou quando novas entidades principais e recursos são criados. As políticas declarativas podem ser aplicadas a uma organização inteira ou a contas específicas OUs .
Cada um Conta da AWS tem um único usuário raiz que tem permissões completas para todos os AWS recursos por padrão. Como prática recomendada de segurança, recomendamos que você não use o usuário root, exceto para algumas tarefas que exigem explicitamente um usuário root. Se você gerencia vários Contas da AWS AWS Organizations, pode desabilitar centralmente o login root e, em seguida, realizar ações com privilégios root em nome de todas as contas dos membros. Depois de gerenciar centralmente o acesso raiz às contas dos membros, você pode excluir a senha do usuário raiz, as chaves de acesso e os certificados de assinatura, além de desativar a autenticação multifator (MFA) das contas dos membros. Novas contas criadas com acesso raiz gerenciado centralmente não têm credenciais de usuário raiz por padrão. As contas dos membros não podem fazer login com o usuário raiz nem realizar a recuperação da senha do usuário raiz.
AWS Control Tower
AWS Organizations ajuda você a configurar Serviços da AWSque se aplicam a todas as suas contas. Por exemplo, você pode configurar o registro central de todas as ações realizadas em sua AWS organização usando CloudTrail e impedir que as contas dos membros desativem o registro.
A configuração padrão dos AWS Organizations suportes usados 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 um 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 ao AWS adicionar novos serviços. As declarações de negação geralmente têm caracteres mais curtos, então é mais fácil permanecer dentro do tamanho máximo SCPs. Em uma declaração em que o Effect elemento tem um valor deDeny, você também pode restringir o acesso a recursos específicos ou definir condições para quando SCPs estão em vigor. Por outro lado, uma Allow declaração 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 uso SCPs na AWS Organizations documentação.
Considerações sobre design
-
Como alternativa, para usar SCPs como uma lista de permissões, você deve substituir o
FullAWSAccessSCP 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 para 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 sensíveis. Essa abordagem exige que você permita explicitamente cada serviço ou ação do IAM no caminho de Conta da AWS até a OU. -
Idealmente, você usaria uma combinação de estratégias de lista de negação e lista de permissões. Use a lista de permissões para definir a lista de Serviços da AWS aprovados permitidos para uso em uma AWS organização e anexe esse SCP na raiz da sua AWS organização. Se você tiver um conjunto diferente de serviços permitidos de acordo com seu ambiente de desenvolvimento, anexará os respectivos SCPs em cada UO. Em seguida, você pode usar a lista de negação para definir proteções corporativas negando explicitamente ações específicas do IAM.
-
RCPs aplicam-se aos recursos de um subconjunto de. Serviços da AWS Para obter mais informações, consulte Lista Serviços da AWS desse suporte RCPs na AWS Organizations documentação. A configuração padrão dos AWS Organizations suportes usados RCPs como listas de negação. Quando você habilita RCPs em sua organização, uma política AWS gerenciada chamada
RCPFullAWSAccessé automaticamente anexada à raiz da organização, a cada UO e a cada conta em sua organização. Você não pode desanexar essa política. Esse RCP padrão permite que todos os diretores e ações acessem a avaliação do RCP. Isso significa que, até você começar a criar e anexar RCPs, todas as suas permissões atuais do IAM continuarão funcionando da mesma forma. Essa política AWS gerenciada não concede acesso. Em seguida, você pode criar uma nova RCPs como uma lista de declarações de negação para bloquear o acesso aos recursos em sua organização.