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á.
SCPavaliação
nota
As informações nesta seção não se aplicam a tipos de política de gerenciamento, incluindo políticas de exclusão dos serviços de IA, políticas de backup ou políticas de tag. Para ter 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ê ativaSCPs, AWS Organizations anexa uma SCP política AWS gerenciada chamada F ullAWSAccess
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, uma SCP que permita a permissão ou o serviço deve ser anexada à Root, à UO de Produção e à própria Conta B.
SCPa avaliação 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.
Observações
-
Uma
Allow
declaração em an SCP permite que oResource
elemento tenha apenas uma"*"
entrada. -
Uma
Allow
declaração em an não SCP pode ter nenhumCondition
elemento.
![](images/scp_allow_1.png)
Figura 1: exemplo de estrutura organizacional com uma declaração Allow
anexada na Raiz, UO de Produção e Conta B
![](images/scp_allow_2.png)
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 pessoa da raiz até cada OU 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 anexo à OU de produção que tenha uma Deny
declaração explícita especificada para um determinado serviço. Também há outro SCP anexado à Root 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.
![](images/scp_deny_1.png)
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. Deny
as 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 UO, elas afetam todas as contas sob ela.
Por exemplo, você pode implementar uma política usando Deny
declarações Impedir que a conta membro saia da organização no nível raiz, o que será efetivo 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 IAMpara atualizar seus SCPs e restringir o acesso somente aos AWS serviços de que precisa. Para obter mais informações, consulte Exibindo os dados do último acesso do Organizations Service for Organizations no Guia IAM do usuário.
AWS Organizations anexa um AWS gerenciado SCP chamado F ullAWSAccessAllow
para permitir apenas serviços específicos.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:*", "cloudwatch:*", "organizations:*" ], "Resource": "*" } ] }
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 ullAWSAccess política F e, em vez disso, anexar esta.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:*", "cloudwatch:*", "organizations:*" ], "Resource": "*" }, { "Effect": "Deny", "Action":"organizations:LeaveOrganization", "Resource": "*" } ] }
Agora, considere o exemplo de estrutura organizacional a seguir para entender como você pode aplicar várias SCPs em diferentes níveis em uma organização.
![](images/scp_deny_2.png)
A tabela a seguir mostra as políticas efetivas na UO de Sandbox.
Cenário | SCPna Root | SCPna Sandbox OU | SCPna Conta A | Política resultante na Conta A | Política resultante na Conta B e na Conta C |
---|---|---|---|---|---|
1 | AWS Acesso total | AWS Acesso total + negar acesso ao S3 | AWS Acesso total + negar EC2 acesso | Sem S3, sem acesso EC2 | Sem acesso ao S3 |
2 | AWS Acesso total | Permitir EC2 acesso | Permitir EC2 acesso | Permitir EC2 acesso | Permitir EC2 acesso |
3 | Negar acesso ao S3 | Permitir acesso ao S3 | AWS Acesso total | Sem acesso ao serviço | Sem acesso ao serviço |
A tabela a seguir mostra as políticas efetivas na UO de Workloads.
Cenário | SCPna Root | SCPna Workloads OU | SCPna Test OU | Política resultante na Conta D | Políticas resultantes na OU de Produção, na Conta E e Conta F |
---|---|---|---|---|---|
1 | AWS Acesso total | AWS Acesso total | AWS Acesso total + negar EC2 acesso | Sem EC2 acesso | AWS Acesso total |
2 | AWS Acesso total | AWS Acesso total | Permitir EC2 acesso | Permitir EC2 acesso | AWS Acesso total |
3 | Negar acesso ao S3 | AWS Acesso total | Permitir acesso ao S3 | Sem acesso ao serviço | Sem acesso ao serviço |