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 dos serviços de IA, políticas de backup ou políticas de tag. Para obter mais informações, consulte Entendendo a herança da política de gerenciamento.

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.

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, quando você habilita SCPs, AWS Organizations anexa uma política de SCP AWS gerenciada chamada FullawsAccess que permite todos os serviços e ações. Se esta política for removida e não substituída em qualquer nível da organização, todas as UOs e contas nesse nível serão impedidas de realizar quaisquer ações.

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.

Observações

• Uma instrução Allow em um SCP permite que o elemento Resource tenha apenas uma entrada "*".

• Uma instrução Allow em uma SCP não pode ter um elemento Condition.

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 Allow Deny declarações para permitir ações e serviços pretendidos em sua organização. As declarações Deny são uma forma poderosa de implementar restrições que devem ser verdadeiras para uma parte mais ampla de sua organização ou UOs porque, quando aplicadas na raiz ou no nível da UO, elas afetam todas as contas abaixo dela.

Por exemplo, você pode implementar uma política usando 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 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 dados de serviço da organização acessados mais recentemente da organização no Guia do usuário do IAM.

O AWS Organizations anexa um SCP gerenciado pelo AWS chamado FullAWSAccess a cada raiz, UO e conta quando ele é criado. Esta política permite todos os serviços e ações. Você pode substituir FullAWSAccess por uma política que permita apenas um conjunto de serviços para que novos serviços AWS não sejam permitidos, a menos que sejam explicitamente permitidos pela atualização de SCPs. Por exemplo, se a sua organização quiser permitir apenas o uso de um subconjunto de serviços no seu ambiente, você poderá usar uma declaração Allow 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 desanexar a política FullAWSAccess e anexar essa no lugar.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:*",
                "cloudwatch:*",
                "organizations:*"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Deny", 
            "Action":"organizations:LeaveOrganization",
            "Resource": "*" 
        }
    ]
}

Agora, considere o seguinte exemplo de estrutura organizacional para entender como você pode aplicar vários SCPs em diferentes níveis em uma organização.

A tabela a seguir mostra as políticas efetivas na UO de Sandbox.

Cenário	SCP na Raiz	SCP na UO de Sandbox	SCP na Conta A	Política resultante na Conta A	Política resultante na Conta B e na Conta C
1	Acesso total AWS	Acesso AWS total + negar acesso ao S3	Acesso AWS total + negar acesso ao EC2	Sem acesso ao S3 e EC2	Sem acesso ao S3
2	Acesso total AWS	Permitir acesso ao Amazon Elastic Compute Cloud (Amazon EC2)	Permitir acesso ao EC2	Permite acesso somente ao EC2	Permite acesso somente ao EC2
3	Negar acesso ao S3	Permitir acesso ao S3	Acesso total AWS	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	SCP na Raiz	SCP na UO de Workloads	SCP na UO de Teste	Política resultante na Conta D	Políticas resultantes na OU de Produção, na Conta E e Conta F
1	Acesso total AWS	Acesso total AWS	Acesso AWS total + negar acesso ao EC2	Sem acesso ao EC2	Acesso total AWS
2	Acesso total AWS	Acesso total AWS	Permitir acesso ao EC2	Permitir acesso ao EC2	Acesso total AWS
3	Negar acesso ao S3	Acesso total AWS	Permitir acesso ao S3	Sem acesso ao serviço	Sem acesso ao serviço