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á.
Avaliação do SCP
nota
As informações nesta seção não se aplicam aos tipos de políticas declarativas, incluindo políticas de backup, políticas de tags, políticas de aplicativos de bate-papo ou políticas de exclusão de serviços de IA. Para obter mais informações, consulte Entendendo a herança declarativa de políticas.
Como você pode anexar diversas políticas de controle de serviço (SCPs) em diferentes níveis no AWS Organizations, entender como as SCPs são avaliadas pode ajudá-lo a escrever SCPs que produzam o resultado correto.
Tópicos
Como os SCPs funcionam com o Allow
Para que uma permissão seja concedida para uma conta específica, deve haver uma Allow declaração explícita em cada nível, desde a raiz até cada UO, no caminho direto até a conta (incluindo a própria conta de destino). É por isso que, ao habilitar SCPs, AWS Organizations anexa uma política AWS gerenciada de SCP chamada FullAwsAccess,
Por exemplo, vamos examinar o cenário mostrado nas figuras 1 e 2. Para que uma permissão ou serviço seja permitido na Conta B, um SCP que permite a permissão ou serviço deve ser anexado à Raiz, à UO de Produção e à própria Conta B.
A avaliação de SCP segue um modelo de negação por padrão, o que significa que quaisquer permissões não explicitamente permitidas nos SCPs são negadas. Se uma instrução de permissão não estiver presente nas SCPs em nenhum dos níveis, como Raiz, UO de Produção ou Conta B, o acesso será negado.
Figura 1: exemplo de estrutura organizacional com uma declaração Allow anexada na Raiz, UO de Produção e Conta B
Figura 2: exemplo de estrutura organizacional com uma declaração Allow faltando na UO de Produção e seu impacto na Conta B
Como os SCPs trabalham com negação
Para que uma permissão seja negada para uma conta específica, qualquer SCP da raiz até cada UO no caminho direto para a conta (incluindo a própria conta de destino) pode negar essa permissão.
Por exemplo, digamos que haja um SCP anexado à UO de Produção que tenha uma declaração Deny explícita especificada para um determinado serviço. Também há outro SCP conectado à raiz e à conta B que permite explicitamente o acesso ao mesmo serviço, conforme mostrado na Figura 3. Como resultado, tanto a Conta A quanto a Conta B terão acesso negado ao serviço, pois uma política de negação vinculada a qualquer nível da organização é avaliada para todas as UOs e contas de membros abaixo dela.
Figura 3: exemplo de estrutura organizacional com uma declaração Deny anexada na UO de Produção e seu impacto na Conta B
Estratégias de uso de SCPs
Ao escrever SCPs, você pode usar uma combinação de Deny declarações Allow e para permitir ações e serviços pretendidos em sua organização. Denyas declarações são uma forma poderosa de implementar restrições que devem ser válidas para uma parte mais ampla de sua organização ou OUs porque, quando aplicadas na raiz ou na raiz, OU-level afetam todas as contas incluídas nela.
dica
Você pode usar os dados de serviços acessados mais recentemente no IAM para atualizar suas SCPs para restringir o acesso a apenas os Serviços da AWS necessários. Para obter mais informações, consulte Visualizar os dados de serviço da organização acessados mais recentemente da organização no Guia do usuário do IAM.
AWS Organizations anexa um SCP AWS gerenciado chamado FullAwsAccess Allow para permitir apenas serviços específicos. Você pode optar por substituir o FullAwsAccess no nível raiz ou em todos os níveis. Se você anexar uma lista de permissões específica de serviço SCP na raiz, ela se aplica automaticamente a todas as OUs e contas abaixo dela, o que significa que uma única política de nível raiz determina a lista de permissões de serviço efetiva em toda a organização, conforme mostrado no cenário 7. Como alternativa, você pode remover e substituir o FullAwsAccess em cada OU e conta, permitindo que você implemente listas de permissões de serviços mais granulares que diferem entre unidades organizacionais ou contas individuais.
Observação: confiar apenas nas instruções de permissão e no modelo implícito de negação por padrão pode levar a um acesso não intencional, pois instruções de permissão mais amplas ou sobrepostas podem substituir as mais restritivas.
Uma política que combina as duas declarações pode ser semelhante ao exemplo a seguir, que impede que contas-membro deixem a organização e permite o uso dos serviços AWS desejados. O administrador da organização pode desanexar a política FullAWSAccess e anexar essa no lugar.
Para demonstrar como várias políticas de controle de serviços (SCPs) podem ser aplicadas em uma organização AWS , considere a estrutura organizacional e os cenários a seguir.
Cenário 1: Impacto das políticas de negação
Esse cenário demonstra como as políticas de negação em níveis mais altos da organização afetam todas as contas abaixo. Quando a OU Sandbox tem políticas de “ AWS Acesso total” e “Negar acesso ao S3”, e a Conta B tem uma política de “Negar acesso ao EC2", o resultado é que a Conta B não pode acessar o S3 (a partir da negação) e o EC2 (da OU-level negação no nível da conta). A conta A não tem acesso ao S3 (desde a OU-level negação).
Cenário 2: as políticas de permissão devem existir em todos os níveis
Esse cenário mostra como as políticas de permissão funcionam em SCPs. Para que um serviço seja acessível, deve haver uma permissão explícita em todos os níveis, desde a raiz até a conta. Aqui, como a UO de Sandbox tem uma política “Permitir acesso ao EC2”, que só permite explicitamente o acesso ao serviço EC2, as contas A e B só terão acesso ao EC2.
Cenário 3: impacto da falta de uma declaração de permissão no nível raiz
Quando o root tem apenas uma declaração de negação sem uma declaração de permissão de “ AWS acesso total”, todas as contas dos membros não têm acesso ao serviço. Os SCPs exigem uma Permissão explícita em cada nível do caminho. Portanto, um Deny-only SCP na raiz bloqueia todos os serviços, a menos que uma permissão explícita os cubra.
Cenário 4: declarações de negação em camadas e permissões resultantes
Esse cenário demonstra uma estrutura de UUO profunda em dois níveis. Tanto a OU raiz quanto a de cargas de trabalho têm “ AWS acesso total”, a OU de teste tem “ AWS acesso total” com “Negar acesso ao EC2" e a OU de produção tem “ AWS acesso total”. Como resultado, a Conta D tem acesso a todos os serviços, exceto EC2, e as Contas E e F têm acesso a todos os serviços.
Cenário 5: permitir políticas no OU-level para restringir o acesso ao serviço
Esse cenário mostra como as políticas de permissão podem ser usadas para restringir o acesso a serviços específicos. A UO de teste tem uma política de “Permitir acesso ao EC2”, o que significa que somente os serviços do EC2 são permitidos para a Conta D. A UO de Produção mantém o “Acesso da AWS completo”, portanto, as Contas E e F têm acesso a todos os serviços. Isso demonstra como políticas de permissão mais restritivas podem ser implementadas ao mesmo OU-level tempo em que se mantém uma permissão mais ampla no nível raiz.
Cenário 6: Root-level negar afeta todas as contas, independentemente das permissões de nível inferior
Esse cenário demonstra que uma política de negação no nível raiz afeta todas as contas na organização, independentemente das políticas de permissão nos níveis mais baixos. A raiz tem políticas de “ AWS Acesso total” e “Negar acesso ao S3”. Embora a UO de teste tenha uma política de “Permitir acesso ao S3”, a negação do S3 no nível raiz tem precedência. A conta D não tem acesso ao serviço porque a UO de teste só permite acesso ao S3, mas o S3 é negado no nível raiz. As contas E e F podem acessar outros serviços, exceto o S3, devido à negação explícita no nível raiz.
Cenário 7: políticas de permissão personalizadas de nível raiz para restringir o OU-level acesso
Esse cenário demonstra como os SCPs com listas de permissões de serviço explícito funcionam quando aplicados no nível raiz em um. AWS Organizations No nível raiz da organização, dois SCPs personalizados de “Permissão de Serviço” estão anexados, permitindo explicitamente o acesso a um conjunto limitado de AWS serviços — SCP_1 permite IAM e Amazon EC2, SCP_2 permite Amazon S3 e Amazon. CloudWatch No nível da unidade organizacional (OU), a política padrão FullAwsAccess permanece anexada. No entanto, devido ao comportamento de interseção, as contas A e B nessas OUs só podem acessar os serviços explicitamente permitidos pelo SCP de nível raiz. A política raiz mais restritiva tem precedência, limitando efetivamente o acesso somente ao IAM, ao EC2, ao S3 e aos CloudWatch serviços, independentemente das permissões mais amplas concedidas em níveis organizacionais mais baixos.
