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 a tipos de política de gerenciamento, incluindo políticas de exclusão de serviços de IA, políticas de backup, políticas de tag ou políticas de aplicativos de chat. Para obter mais informações, consulte Entendendo a herança da política de gerenciamento.
Como você pode anexar várias políticas de controle de serviço (SCPs) em diferentes níveis AWS Organizations, entender como SCPs são avaliadas pode ajudá-lo SCPs a escrever o resultado certo.
Como SCPs trabalhar 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, quando você ativa SCPs, AWS Organizations anexa uma política SCP AWS gerenciada chamada Full
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 do SCP segue um deny-by-default modelo, o que significa que todas as permissões não permitidas explicitamente no SCPs são negadas. Se uma instrução de permissão não estiver presente SCPs em nenhum dos níveis, como Raiz, OU 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 SCPs trabalhar com Deny
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 contas OUs e 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égia para usar SCPs
Ao escrever, SCPs você pode usar uma combinação de Allow Deny declarações 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 verdadeiras para uma parte mais ampla de sua organização ou OUs porque, quando aplicadas na raiz ou no nível da OU, elas afetam todas as contas sob ela.
Por exemplo, você pode implementar uma política usando instruções de Deny para Impedir que a conta membro saia da organização no nível raiz, que será efetiva para todas as contas da organização. As instruções de negação também suportam o elemento de condição que pode ser útil para criar exceções.
dica
Você pode usar os dados do último acesso do serviço no IAM para atualizar seus SCPs dados e restringir o acesso somente ao Serviços da AWS que você precisa. 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 Full AWSAccessAllow para permitir apenas serviços específicos. Você pode optar por substituir o Full AWSAccess no nível raiz ou em cada nível. Se você anexar uma lista de permissões específica do serviço (SCP) na raiz, ela se aplicará automaticamente a todas OUs e às contas abaixo dela, o que significa que uma única política de nível raiz determina a lista efetiva de permissões de serviço em toda a organização, conforme mostrado no cenário 7. Como alternativa, você pode remover e substituir o Full AWSAccess em cada UO e conta, permitindo que você implemente listas de permissões de serviço mais granulares que diferem entre unidades organizacionais ou contas individuais.
Observação: confiar apenas nas instruções de permissão e no deny-by-default modelo implícito 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 separar a AWSAccess política completa e, em vez disso, anexar esta.
Para demonstrar como várias políticas de controle de serviços (SCPs) podem ser aplicadas em uma AWS organização, 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 Sandbox OU tem políticas de “ AWS Acesso total” e “Negar acesso ao S3”, e a Conta B tem uma política de “Negar EC2 acesso”, o resultado é que a Conta B não pode acessar o S3 (da negação no nível da OU) e EC2 (da negação no nível da conta). A Conta A não tem acesso ao S3 (a partir da negação no nível da UO).
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 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 Sandbox OU tem uma política de “Permitir EC2 acesso”, que só permite explicitamente o acesso ao EC2 serviço, as Contas A e B só terão EC2 acesso.
Cenário 3: impacto da falta de uma declaração de permissão no nível raiz
A falta de uma declaração de “Permitir” no nível raiz em um SCP é uma configuração incorreta crítica que bloqueará efetivamente todo o acesso aos AWS serviços e ações de todas as contas membros em sua organização.
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 UO raiz quanto a de cargas de trabalho têm “ AWS acesso total”, a OU de teste tem “ AWS acesso total” com “Negar EC2 acesso” e a OU de produção tem “ AWS acesso total”. Como resultado, a Conta D tem todo o acesso aos serviços, exceto as Contas EC2 E e F têm acesso a todos os serviços.
Cenário 5: políticas de permissão no nível da UO 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 OU de teste tem uma política de “Permitir EC2 acesso”, o que significa que somente EC2 serviços são permitidos para a Conta D. A OU de produção mantém o “ AWS acesso total”, 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 no nível da UO, ao mesmo tempo, mantendo uma permissão mais ampla no nível raiz.
Cenário 6: negação no nível raiz 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 personalizadas de permissão de nível raiz para restringir o acesso em nível de UO
Esse cenário demonstra como, SCPs com serviços explícitos, as listas de permissões funcionam quando aplicadas no nível raiz em um. AWS Organizations No nível raiz da organização, SCPs são anexadas duas “Permissões de Serviço” personalizadas que permitem explicitamente o acesso a um conjunto limitado de AWS serviços — SCP_1 permite IAM e Amazon, SCP_2 permite Amazon EC2 S3 e Amazon. CloudWatch No nível da unidade organizacional (OU), a AWSAccess política completa padrão permanece anexada. No entanto, devido ao comportamento de interseção, as contas A e B abaixo delas só OUs 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 S3 e aos CloudWatch serviços EC2, independentemente das permissões mais amplas concedidas nos níveis organizacionais mais baixos.
