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á. # Políticas de controle de serviços (SCPs) As políticas de controle de serviço (SCPs) são um tipo de política organizacional que você pode usar para gerenciar permissões em sua organização. SCPs ofereça controle central sobre o máximo de permissões disponíveis para os usuários e funções do IAM em sua organização. SCPs ajudam você a garantir que suas contas permaneçam dentro das diretrizes de controle de acesso da sua organização. SCPsestão disponíveis somente em uma organização que tenha [todos os recursos habilitados](orgs_manage_org_support-all-features.md). SCPs não estão disponíveis se sua organização tiver ativado somente os recursos de cobrança consolidada. Para obter instruções sobre como habilitar SCPs, consulte[Habilitação de um tipo de política](enable-policy-type.md). SCPs não conceda permissões aos usuários do IAM e às funções do IAM em sua organização. Nenhuma permissão é concedida por um SCP. Uma SCP define uma barreira de proteção de permissões — ou define limites — nas ações que os usuários e perfis do IAM em sua organização podem realizar. Para conceder permissões, o administrador deve vincular políticas para controlar o acesso, como políticas baseadas em identidade que são anexadas a usuários e perfis do IAM, e políticas baseadas em recursos que estão vinculadas aos recursos em suas contas. Para obter mais informações, consulte [Políticas baseadas em identidade e em recurso](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html) no *Guia do usuário do IAM*. As [permissões efetivas](#scp-effects-on-permissions) são a interseção lógica entre o que é permitido pelo SCP e pelas [políticas de controle de recursos (RCPs)](orgs_manage_policies_rcps.md) e o que é permitido pelas políticas baseadas em identidade e recursos. **SCPs não afetam usuários ou funções na conta de gerenciamento** SCPs não afetam usuários ou funções na conta de gerenciamento. Elas afetam apenas as contas-membro de sua organização. Isso também significa que SCPs se aplicam às contas de membros designadas como administradores delegados. ****Tópicos nesta página**** + [Testando os efeitos do SCPs](#scp-warning-testing-effect) + [Tamanho máximo de SCPs](#scp-size-limit) + [Vinculando-se SCPs a diferentes níveis da organização](#scp-about-inheritance) + [Efeitos de SCP sobre permissões](#scp-effects-on-permissions) + [Usando dados de acesso para melhorar SCPs](#data-from-iam) + [Tarefas e entidades não restritas por SCPs](#not-restricted-by-scp) + [Avaliação do SCP](orgs_manage_policies_scps_evaluation.md) + [Sintaxe de SCP](orgs_manage_policies_scps_syntax.md) + [Exemplos de política de controle de serviço](orgs_manage_policies_scps_examples.md) + [Solução de problemas de políticas de controle de serviço (SCPs) com AWS Organizations](org_troubleshoot_policies.md) ## Testando os efeitos do SCPs AWS recomenda fortemente que você não se vincule SCPs à raiz da sua organização sem testar minuciosamente o impacto que a política tem nas contas. Em vez disso, crie uma UO para a qual você possa mover suas contas, uma por vez, ou pelo menos em pequenas quantidades, para garantir que não seja possível bloquear acidentalmente usuários nos serviços principais. Uma forma de determinar se um serviço é usado por uma conta é examinar os [últimos dados acessados pelo serviço no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html). Outra forma é [usar AWS CloudTrail para registrar o uso do serviço no nível da API](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/how-cloudtrail-works.html). **nota** Você não deve remover a AWSAccess política **completa**, a menos que a modifique ou substitua por uma política separada com ações permitidas, caso contrário, todas as AWS ações das contas dos membros falharão. ## Tamanho máximo de SCPs Todos os caracteres em sua conta de SCP contam em relação ao seu [tamanho máximo](orgs_reference_limits.md#min-max-values). Os exemplos deste guia mostram o SCPs formato com espaço em branco extra para melhorar sua legibilidade. No entanto, para economizar espaço quando o tamanho da política se aproximar do tamanho máximo, é possível excluir todos os espaços em branco, como caracteres de espaço e quebras de linhas, que estiverem fora das aspas. **dica** Use o editor visual para criar sua SCP. Ele remove automaticamente os espaços em branco. ## Vinculando-se SCPs a diferentes níveis da organização Para obter uma explicação detalhada de como SCPs funciona, consulte[Avaliação do SCP](orgs_manage_policies_scps_evaluation.md). ## Efeitos de SCP sobre permissões SCPs são semelhantes às políticas de AWS Identity and Access Management permissão e usam quase a mesma sintaxe. No entanto, uma SCP nunca concede permissões. Em vez disso, SCPs são controles de acesso que especificam o máximo de permissões disponíveis para os usuários e funções do IAM na sua organização. Para obter mais informações, consulte [Lógica da avaliação de políticas](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) no *Guia do usuário do IAM*. + SCPs ***afetam somente usuários e funções do IAM*** que são gerenciados por contas que fazem parte da organização. SCPs não afetam diretamente as políticas baseadas em recursos. Elas também não afetam usuários ou funções de contas de fora da organização. Por exemplo, considere um bucket do Amazon S3; que é de propriedade da conta A em uma organização. A política de bucket (uma política baseada em recursos) concede acesso a usuários da conta B fora da organização. A conta A tem uma SCP anexada. Essa SCP não se aplica aos usuários externos na conta B. A SCP se aplica somente aos usuários gerenciados pela conta A na organização. + Uma SCP restringe as permissões para usuários e funções do IAM em contas-membro, incluindo o usuário-raiz da conta-membro. Qualquer conta tem somente as permissões permitidas por ***cada*** pai acima dela. Se uma permissão for bloqueada em qualquer nível acima da conta, implicitamente (sem ser incluída em uma declaração de política `Allow`) ou explicitamente (estar incluída em uma declaração de política `Deny`), o usuário ou a função na conta afetada não poderá usar essa permissão, mesmo que o administrador da conta anexe a política do IAM `AdministratorAccess` com permissões \$1/\$1 ao usuário. + SCPs afetam somente as contas dos ***membros*** na organização. Eles não têm efeito sobre os usuários ou funções na conta gerencial. Isso também significa que SCPs se aplicam às contas de membros designadas como administradores delegados. Para obter mais informações, consulte [Práticas recomendadas para a conta gerencial](orgs_best-practices_mgmt-acct.md). + Os usuários e funções ainda devem receber permissões com as políticas de permissão do IAM apropriadas. Um usuário sem nenhuma política de permissão do IAM não tem acesso, mesmo que o aplicável SCPs permita todos os serviços e todas as ações. + Se um usuário ou função tiver uma política de permissão do IAM que concede acesso a uma ação que também é permitida pelo aplicável SCPs, o usuário ou função poderá realizar essa ação. + Se um usuário ou função tiver uma política de permissão do IAM que concede acesso a uma ação que não é permitida ou explicitamente negada pelo aplicável SCPs, o usuário ou a função não poderá realizar essa ação. + SCPs afetam todos os usuários e funções nas contas anexadas, ***incluindo o usuário root***. As únicas exceções são aquelas descritas em [Tarefas e entidades não restritas por SCPs](#not-restricted-by-scp). + SCPs ***não*** afetam nenhuma função vinculada ao serviço. As funções vinculadas ao serviço permitem que outras pessoas Serviços da AWS se integrem AWS Organizations e não possam ser restringidas por elas. SCPs + Quando você desativa o tipo de política SCP em uma raiz, todas SCPs são automaticamente separadas de todas as AWS Organizations entidades nessa raiz. AWS Organizations as entidades incluem unidades organizacionais, organizações e contas. Se você reativar SCPs em uma raiz, essa raiz será revertida somente para a `FullAWSAccess` política padrão anexada automaticamente a todas as entidades na raiz. Todos os anexos de AWS Organizations entidades anteriores SCPs à desativação são perdidos e não podem ser SCPs recuperados automaticamente, embora você possa reanexá-los manualmente. + Se um limite de permissões (um recurso avançado do IAM) e uma SCP estiverem presentes, o limite, a SCP e a política baseada em identidade deverão permitir a ação. ## Usando dados de acesso para melhorar SCPs Ao fazer login com as credenciais da conta de gerenciamento, você pode visualizar os [dados do último acesso ao serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html) para uma AWS Organizations entidade ou política na **AWS Organizations**seção do console do IAM. Você também pode usar o AWS Command Line Interface (AWS CLI) ou a AWS API no IAM para recuperar os últimos dados acessados do serviço. Esses dados incluem informações sobre quais serviços permitidos os usuários e funções do IAM em uma AWS Organizations conta tentaram acessar pela última vez e quando. Você pode usar essas informações para identificar permissões não utilizadas, a fim de refiná-las SCPs para melhor aderir ao princípio do privilégio [mínimo](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege). Por exemplo, você pode ter uma [SCP de lista de negações](orgs_manage_policies_scps_evaluation.md#how_scps_deny) que impede o acesso a três Serviços da AWS. Todos os serviços que não são listados na declaração `Deny` da SCP são permitidos. Os últimos dados acessados do serviço no IAM informam quais Serviços da AWS são permitidos pelo SCP, mas nunca são usados. Com essas informações, você pode atualizar a SCP para negar o acesso a serviços desnecessários. Para obter mais informações, consulte os seguintes tópicos no *Guia do usuário do IAM*: + [Visualizar dados de serviços da organização acessados pela última vez para organizações](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor-view-data-orgs.html) + [Usar dados para refinar permissões de uma unidade organizacional](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor-example-scenarios.html#access_policies_access-advisor-reduce-permissions-orgs) ## Tarefas e entidades não restritas por SCPs Você ***não pode*** usar SCPs para restringir as seguintes tarefas: + Qualquer ação executada pela conta gerencial + Qualquer ação executada usando permissões que são anexadas a uma função vinculada ao serviço + Registrar-se no plano Enterprise Support como o usuário raiz + Forneça funcionalidade de assinante confiável para conteúdo CloudFront privado + Configurar DNS reverso para um servidor de e-mail do Amazon Lightsail e uma instância do Amazon EC2 como o usuário-raiz + Tarefas em alguns serviços AWS relacionados: + Alexa Top Sites + Alexa Web Information Service + Amazon Mechanical Turk + API de marketing de produtos da Amazon # 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](orgs_manage_policies_inheritance_mgmt.md). 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. **Topics** + [Como SCPs trabalhar com o Allow](#how_scps_allow) + [Como SCPs trabalhar com Deny](#how_scps_deny) + [Estratégia para usar SCPs](#strategy_using_scps) ## 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](https://console.aws.amazon.com/organizations/v2/home/policies/service-control-policy/p-FullAWSAccess), AWSAccess que permite todos os serviços e ações. Se essa política for removida e não substituída em nenhum nível da organização, todas as contas OUs e contas desse nível serão impedidas de realizar qualquer ação. 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. ![\[Exemplo de estrutura organizacional com uma declaração Permitir anexada na Raiz, UO de Produção e Conta B\]](http://docs.aws.amazon.com/pt_br/organizations/latest/userguide/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* ![\[Exemplo de estrutura organizacional com uma declaração Permitir faltando na UO de Produção e seu impacto na Conta B\]](http://docs.aws.amazon.com/pt_br/organizations/latest/userguide/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** 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. ![\[Exemplo de estrutura organizacional com uma declaração Negar anexada na UO de Produção e seu impacto na Conta B\]](http://docs.aws.amazon.com/pt_br/organizations/latest/userguide/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 OU, elas afetam todas as contas sob ela. **dica** Você pode usar [os dados do último acesso do serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html) no [IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor-view-data-orgs.html) no *Guia do usuário do IAM.* AWS Organizations anexa um SCP AWS gerenciado chamado [https://console.aws.amazon.com/organizations/v2/home/policies/service-control-policy/p-FullAWSAccess](https://console.aws.amazon.com/organizations/v2/home/policies/service-control-policy/p-FullAWSAccess) a cada raiz, UO e conta quando ele é criado. Esta política permite todos os serviços e ações. Você pode AWSAccess substituir **Full** por uma política que permita somente um conjunto de serviços para que novos não Serviços da AWS sejam permitidos, a menos que sejam explicitamente permitidos pela atualização 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. Você pode optar por substituir o **Full AWSAccess** no nível raiz ou em todos os níveis. Se você anexar uma lista de permissões específica do serviço (SCP) na raiz, ela se aplicará automaticamente a todas as OUs 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. ------ #### [ JSON ] **** ``` { "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 AWSAccess política **completa** e, em vez disso, anexar esta. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:*", "cloudwatch:*", "organizations:*" ], "Resource": "*" }, { "Effect": "Deny", "Action":"organizations:LeaveOrganization", "Resource": "*" } ] } ``` ------ 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 acesso ao EC2”, o resultado é que a Conta B não pode acessar o S3 (da negação no nível da OU) e o 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 1: impacto das políticas de negação\]](http://docs.aws.amazon.com/pt_br/organizations/latest/userguide/images/scp_scenario_1.png) ### 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 2: as políticas de permissão devem existir em todos os níveis\]](http://docs.aws.amazon.com/pt_br/organizations/latest/userguide/images/scp_scenario_2.png) ### 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 3: impacto da falta de uma declaração de permissão no nível raiz\]](http://docs.aws.amazon.com/pt_br/organizations/latest/userguide/images/scp_scenario_3.png) ### 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 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 4: declarações de negação em camadas e permissões resultantes\]](http://docs.aws.amazon.com/pt_br/organizations/latest/userguide/images/scp_scenario_4.png) ### 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 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 no nível da UO, ao mesmo tempo, mantendo uma permissão mais ampla no nível raiz. ![\[Cenário 5: políticas de permissão no nível da UO para restringir o acesso ao serviço\]](http://docs.aws.amazon.com/pt_br/organizations/latest/userguide/images/scp_scenario_5.png) ### 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 6: negação no nível raiz afeta todas as contas, independentemente das permissões de nível inferior\]](http://docs.aws.amazon.com/pt_br/organizations/latest/userguide/images/scp_scenario_6.png) ### 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\$11 permite IAM e Amazon EC2, SCP\$12 permite Amazon 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 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, EC2, S3 e CloudWatch serviços, independentemente das permissões mais amplas concedidas nos níveis organizacionais mais baixos. ![\[Cenário 7: políticas personalizadas de permissão de nível raiz para restringir o acesso em nível de UO\]](http://docs.aws.amazon.com/pt_br/organizations/latest/userguide/images/scp_scenario_7.png) # Sintaxe de SCP As políticas de controle de serviço (SCPs) usam uma sintaxe semelhante à usada pelas políticas de permissão AWS Identity and Access Management (IAM) e políticas [baseadas em recursos (como as políticas](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_resource-based) de bucket do Amazon S3). Para obter mais informações sobre as políticas do IAM e sua sintaxe, consulte [Visão geral das políticas do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) no *Guia do usuário do IAM*. Uma SCP é um arquivo de texto sem formatação estruturado de acordo com as regras do [JSON](http://json.org). Ela usa os elementos que são descritos neste tópico. **nota** Todos os caracteres em sua conta de SCP contam em relação ao seu [tamanho máximo](orgs_reference_limits.md#min-max-values). Os exemplos deste guia mostram o SCPs formato com espaço em branco extra para melhorar sua legibilidade. No entanto, para economizar espaço quando o tamanho da política se aproximar do tamanho máximo, é possível excluir todos os espaços em branco, como caracteres de espaço e quebras de linhas, que estiverem fora das aspas. Para obter informações gerais sobre SCPs, consulte[Políticas de controle de serviços (SCPs)](orgs_manage_policies_scps.md). ## Resumo de elementos A tabela a seguir resume os elementos de política que você pode usar em SCPs. Alguns elementos da política estão disponíveis somente nas ações SCPs de negação. A coluna **Efeitos suportados** lista o tipo de efeito que você pode usar com cada elemento de política em SCPs. | Elemento | Finalidade | Efeitos com suporte | | --- | --- | --- | | [Ação](#scp-syntax-action) | Especifica o AWS serviço e as ações que o SCP permite ou nega. | `Allow`, `Deny` | | [Efeito](#scp-syntax-effect) | Define se a instrução da SCP [permite](orgs_manage_policies_scps_evaluation.md#how_scps_allow) ou [nega](orgs_manage_policies_scps_evaluation.md#how_scps_deny) o acesso principal a usuários e funções do IAM em uma conta. | `Allow`, `Deny` | | [Instrução](#scp-syntax-statement) | Serve como o contêiner para elementos de políticas. Você pode incluir várias declarações em SCPs. | `Allow`, `Deny` | | [ID da instrução (Sid)](#scp-syntax-sid) | (Opcional) Fornece um nome amigável para a instrução. | `Allow`, `Deny` | | [Versão](#scp-syntax-version) | Especifica as regras da sintaxe da linguagem a serem usadas para processar a política. | `Allow`, `Deny` | | [Condição](#scp-syntax-condition) | Especifica as condições em que a instrução está em vigor. | `Allow,``Deny` | | [NotAction](#scp-syntax-action) | Especifica AWS serviços e ações que estão isentos do SCP. Usado em vez do elemento `Action`. | `Allow,``Deny` | | [Recurso](#scp-syntax-resource) | Especifica os AWS recursos aos quais o SCP se aplica. | `Allow,``Deny` | | [NotResource](#scp-syntax-resource) | Especifica AWS os recursos que estão isentos do SCP. Usado em vez do elemento Resource. | `Allow`, `Deny` | As seções a seguir fornecem mais informações e exemplos de como os elementos da política são usados em SCPs. **Topics** + [Resumo de elementos](#scp-elements-table) + [Elementos `Action` e `NotAction`](#scp-syntax-action) + [Elemento `Condition`](#scp-syntax-condition) + [Elemento `Effect`](#scp-syntax-effect) + [`Resource`e `NotResource` elemento](#scp-syntax-resource) + [Elemento `Statement`](#scp-syntax-statement) + [Elemento ID da instrução (`Sid`)](#scp-syntax-sid) + [Elemento `Version`](#scp-syntax-version) + [Elementos sem suporte](#scp-syntax-unsupported) ## Elementos `Action` e `NotAction` O valor do `NotAction` elemento `Action` or é uma lista (uma matriz JSON) de cadeias de caracteres que identificam AWS serviços e ações que são permitidos ou negados pela instrução. Cada string consiste na abreviação do serviço (como "s3", "ec2", "iam" ou "organizations"), tudo em letras minúsculas, seguida por um ponto e vírgula e uma ação desse serviço. As ações e notações não diferenciam maiúsculas de minúsculas. Em geral, todas elas são inseridas com cada palavra começando com uma letra maiúscula e o restante em minúsculas. Por exemplo: `"s3:ListAllMyBuckets"`. Você também pode usar caracteres curinga, como asterisco (\$1) ou ponto de interrogação (?) em uma SCP: + Você também pode usar um asterisco como um curinga para corresponder a várias ações que compartilham parte de um nome. O valor `"s3:*"` significa todas as ações no serviço Amazon S3. O valor de `"ec2:Describe*"` corresponde apenas às ações do EC2 que começam com "Describe". + Use o curinga ponto de interrogação (?) para corresponder a um único caractere. Para obter uma lista de todos os serviços e as ações que eles suportam nas AWS Organizations SCPs políticas de permissão do IAM, consulte [Ações, recursos e chaves de condição para AWS serviços](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_actionsconditions.html) no *Guia do usuário do IAM*. Para obter mais informações, consulte Elementos de [política JSON do IAM: ação e Elementos](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_action.html) da [política JSON do IAM: NotAction](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_notaction.html) no Guia do *usuário do IAM*. ### Exemplo do elemento `Action` O seguinte exemplo mostra uma SCP com uma instrução que permite que os administradores de contas deleguem permissões para descrever, iniciar, interromper e encerrar a instâncias do EC2 na conta. Este é um exemplo de uma [lista de permissões](orgs_manage_policies_scps_evaluation.md#how_scps_allow) e é útil quando as políticas `Allow *` padrão ***não*** são anexadas, para que, por padrão, as permissões sejam implicitamente negadas. Se a política `Allow *` padrão ainda estiver anexada à raiz, à UO ou à conta à qual a política a seguir está anexada, a política não terá efeito. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "ec2:DescribeInstances", "ec2:DescribeImages", "ec2:DescribeKeyPairs", "ec2:DescribeSecurityGroups", "ec2:DescribeAvailabilityZones", "ec2:RunInstances", "ec2:TerminateInstances", "ec2:StopInstances", "ec2:StartInstances" ], "Resource": "*" } } ``` ------ O exemplo a seguir mostra como é possível [negar o acesso](orgs_manage_policies_scps_evaluation.md#how_scps_deny) a serviços que você não deseja que sejam usados em contas anexadas. Ele pressupõe que as SCPs `"Allow *"` padrão ainda estejam anexadas a todas as UOs e à raiz. Esse exemplo de política impede que os administradores de contas anexadas deleguem permissões para os serviços IAM, Amazon EC2 e Amazon RDS . Qualquer ação de outros serviços pode ser delegada, desde que não haja outra política anexada que a negue. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Deny", "Action": [ "iam:*", "ec2:*", "rds:*" ], "Resource": "*" } } ``` ------ ### Exemplo do elemento `NotAction` O exemplo a seguir mostra como você pode usar um `NotAction` elemento para excluir AWS serviços do efeito da política. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "LimitActionsInRegion", "Effect": "Deny", "NotAction": "iam:*", "Resource": "*", "Condition": { "StringNotEquals": { "aws:RequestedRegion": "us-west-1" } } } ] } ``` ------ Com essa declaração, as contas afetadas estão limitadas a realizar ações no especificado Região da AWS, exceto ao usar ações do IAM. ## Elemento `Condition` Você pode especificar um elemento `Condition` em instruções de permissão e negação em uma SCP. O exemplo a seguir mostra como usar um elemento condicional com uma instrução de permissão em um SCP para permitir que diretores específicos AWS acessem serviços. ``` { "Version":"2012-10-17", "Statement":[ { "Sid":"AllowServicesForSpecificPrincipal", "Effect":"Allow", "Action":[ "ec2:*", "s3:*", "rds:*", "lambda:*", "cloudformation:*", "iam:*", "cloudwatch:*" ], "Resource":"*", "Condition":{ "StringEquals":{ "aws:PrincipalArn":[ "arn:aws:iam::123456789012:role/specific-role" ] } } } ] } ``` O exemplo a seguir mostra como usar um elemento condicional com uma declaração de negação em uma SCP para restringir o acesso a qualquer operação fora das regiões `eu-central-1` e `eu-west-1`, exceto as ações nos serviços especificados. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DenyAllOutsideEU", "Effect": "Deny", "NotAction": [ "cloudfront:*", "iam:*", "route53:*", "support:*" ], "Resource": "*", "Condition": { "StringNotEquals": { "aws:RequestedRegion": [ "eu-central-1", "eu-west-1" ] } } } ] } ``` ------ Para obter mais informações, consulte [IAM JSON Policy Elements: Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) (Elementos da política JSON do IAM: Condição) no *Guia do usuário do IAM*. ## Elemento `Effect` Cada instrução deve conter um elemento `Effect`. O valor pode ser `Allow` ou `Deny`. Isso afeta todas as ações listadas na mesma instrução. Para obter mais informações, consulte [Elementos de política JSON do IAM: efeito](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_effect.html) no *Guia do usuário do IAM*. ### `"Effect": "Allow"` O seguinte exemplo mostra uma SCP com uma instrução que contém um elemento `Effect` com um valor de `Allow` que permite que os usuários da conta executem ações para o serviço Amazon S3. Esse exemplo é útil em uma organização que usa a [estratégia de lista de permissões](orgs_manage_policies_scps_evaluation.md#how_scps_allow) (em que todas as políticas de `FullAWSAccess` padrão são desvinculadas para que as permissões sejam implicitamente negadas por padrão). O resultado é que a instrução [permite](orgs_manage_policies_scps_evaluation.md#how_scps_allow) as permissões do Amazon S3 para todas as contas anexadas: ``` { "Statement": { "Effect": "Allow", "Action": "s3:*", "Resource": "*" } } ``` Embora ele use a mesma palavra-chave de valor `Allow` como uma política de permissões do IAM, em uma SCP, ele na realidade não concede permissões a um usuário para fazer alguma coisa. Em vez disso, SCPs atue como filtros que especificam as permissões máximas para as contas em uma organização, unidade organizacional (OU) ou conta. No exemplo anterior, mesmo que um usuário na conta tivesse a política gerenciada `AdministratorAccess` anexada, a SCP limitaria ***todos*** os usuários na conta para apenas ações do Amazon S3. ### `"Effect": "Deny"` Em uma declaração em que o `Effect` elemento tem um valor de`Deny`, você também pode restringir o acesso a recursos específicos ou definir condições para quando SCPs estão em vigor. A seguinte tabela mostra um exemplo de como usar uma chave de condição em uma instrução de negação. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Deny", "Action": "ec2:RunInstances", "Resource": "arn:aws:ec2:*:*:instance/*", "Condition": { "StringNotEquals": { "ec2:InstanceType": "t2.micro" } } } } ``` ------ Essa instrução em uma SCP define uma proteção para impedir que as contas afetadas (em que a SCP é anexada à própria conta ou à raiz ou UO da organização que contém a conta) executem instâncias do Amazon EC2 se a instância do Amazon EC2 não estiver definida como `t2.micro`. Mesmo que uma política do IAM que permite essa ação seja anexada à conta, a proteção criada pela SCP impedirá isso. ## `Resource`e `NotResource` elemento Em instruções em que o elemento `Effect` tem um valor de `Allow`, você pode especificar apenas "\$1" no elemento `Resource` de uma SCP. Você não pode especificar um recurso individual Amazon Resource Names (ARNs). Você pode usar caracteres curinga, como asterisco (\$1) ou ponto de interrogação (?) no elemento de recurso: + Você também pode usar um asterisco como um curinga para corresponder a várias ações que compartilham parte de um nome. + Use o curinga ponto de interrogação (?) para corresponder a um único caractere. Nas declarações em que o `Effect` elemento tem um valor de`Deny`, você *pode* especificar individual ARNs, conforme mostrado no exemplo a seguir. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DenyAccessToAdminRole", "Effect": "Deny", "Action": [ "iam:AttachRolePolicy", "iam:DeleteRole", "iam:DeleteRolePermissionsBoundary", "iam:DeleteRolePolicy", "iam:DetachRolePolicy", "iam:PutRolePermissionsBoundary", "iam:PutRolePolicy", "iam:UpdateAssumeRolePolicy", "iam:UpdateRole", "iam:UpdateRoleDescription" ], "Resource": [ "arn:aws:iam::*:role/role-to-deny" ] } ] } ``` ------ Esta SCP restringe que as entidades principais do IAM em contas façam alterações em uma função administrativa comum do IAM criada em todas as contas em sua organização. O exemplo a seguir mostra como usar um elemento `NotResource` para excluir modelos específicos do Amazon Bedrock do efeito da política. ``` { "Version":"2012-10-17", "Statement":[ { "Sid":"Statement1", "Effect":"Deny", "Action":[ "bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream" ], "NotResource":[ "arn:aws:bedrock:*::foundation-model/model-to-permit" ] } ] } ``` Para obter mais informações, consulte [Elementos da política JSON do IAM: recurso](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_resource.html) no *Guia do usuário do IAM*. ## Elemento `Statement` Uma SCP consiste em um ou mais elementos `Statement`. Você pode ter apenas uma palavra-chave `Statement` em uma política, mas o valor pode ser uma matriz JSON de instruções (entre os caracteres []). O exemplo a seguir mostra uma única instrução que consiste em elementos `Effect`, `Action` e `Resource` únicos. ``` "Statement": { "Effect": "Allow", "Action": "*", "Resource": "*" } ``` O exemplo a seguir inclui duas instruções como uma lista de matrizes dentro de um elemento `Statement`. A primeira instrução permite todas as ações, enquanto a segunda nega todas as ações do EC2. O resultado é que um administrador da conta pode delegar qualquer permissão, *exceto* as do Amazon Elastic Compute Cloud (Amazon EC2). ``` "Statement": [ { "Effect": "Allow", "Action": "*", "Resource": "*" }, { "Effect": "Deny", "Action": "ec2:*", "Resource": "*" } ] ``` Para obter mais informações, consulte [Elementos de política JSON do IAM: instrução](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_statement.html) no *Guia do usuário do IAM*. ## Elemento ID da instrução (`Sid`) O `Sid` é um identificador opcional que você fornece para a instrução da política. Você pode atribuir um valor `Sid` a cada instrução em uma matriz de instruções. A seguinte SCP de exemplo mostra uma instrução `Sid`. ``` { "Statement": { "Sid": "AllowsAllActions", "Effect": "Allow", "Action": "*", "Resource": "*" } } ``` Para obter mais informações, consulte [Elementos de política JSON do IAM: Id](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_id.html) no *Guia do usuário do IAM*. ## Elemento `Version` Cada SCP deve incluir um elemento `Version` com o valor `"2012-10-17"`. Este é o mesmo valor da versão mais recente das políticas de permissão do IAM. Para obter mais informações, consulte [Elementos de política JSON do IAM: versão](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_version.html) no *Guia do usuário do IAM*. ## Elementos sem suporte Os seguintes elementos não são compatíveis com SCPs: + `NotPrincipal` + `Principal` # Exemplos de política de controle de serviço O exemplo [de políticas de controle de serviço (SCPs)](orgs_manage_policies_scps.md) exibido neste tópico serve apenas para fins informativos. **Antes de usar esses exemplos** Antes de usar esses exemplos SCPs em sua organização, considere o seguinte: [As políticas de controle de serviço (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) devem ser usadas como grades de proteção grosseiras e não concedem acesso diretamente. O administrador ainda precisa anexar [políticas baseadas em identidade ou recursos](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html) aos diretores ou recursos do IAM em suas contas para realmente conceder permissões. As permissões efetivas são a interseção lógica entre a política de policy/Resource controle de serviços e uma política de identidade ou a política de policy/Resource controle de serviços e uma política de recursos. Você pode obter mais detalhes sobre os efeitos do SCP nas permissões [aqui](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html#scp-effects-on-permissions). Uma [política de controle de serviços (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html), quando vinculada a uma organização, unidade organizacional ou conta, oferece um controle central sobre o máximo de permissões disponíveis para todas as contas em sua organização, unidade organizacional ou conta. Como um SCP pode ser aplicado em vários níveis em uma organização, entender como [SCPs são avaliados](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_evaluation.html) pode ajudá-lo SCPs a escrever o resultado certo. As políticas de controle de serviço nesse repositório são mostradas como exemplos. Você não deve anexar SCPs sem testar minuciosamente o impacto que a política tem nas contas. Depois de ter uma política pronta que você gostaria de implementar, recomendamos testar em uma organização ou OU separada que possa representar seu ambiente de produção. Depois de testado, você deve implantar alterações mais específicas OUs e, em seguida, implantar lentamente as alterações de forma cada vez mais ampla OUs ao longo do tempo. Os exemplos de SCP neste repositório usam uma [estratégia de lista de negação](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_evaluation.html#strategy_using_scps), o que significa que você também precisa de uma AWSAccess política [completa](https://console.aws.amazon.com/organizations/?#/policies/p-FullAWSAccess) ou de outra política que permita o acesso anexado às entidades da sua organização para permitir ações. Você ainda precisa conceder as permissões apropriadas aos seus diretores usando políticas baseadas em identidade ou recursos. **dica** Você pode usar [os dados do último acesso do serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html) no [IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor-view-data-orgs.html) no *Guia do usuário do IAM.* ## GitHub repositório + [Exemplos de políticas de controle de serviços](https://github.com/aws-samples/service-control-policy-examples) - Este GitHub repositório contém exemplos de políticas para começar ou amadurecer seu uso do AWS SCPs # Solução de problemas de políticas de controle de serviço (SCPs) com AWS Organizations Use as informações aqui para ajudá-lo a diagnosticar e corrigir erros comuns encontrados nas políticas de controle de serviço (SCPs). As políticas de controle de serviço (SCPs) em AWS Organizations são semelhantes às políticas do IAM e compartilham uma sintaxe comum. Essa sintaxe começa com as regras da [Notação de JavaScript Objetos](http://www.json.org) (JSON). JSON descreve um *objeto* com pares de nome e valor que compõem o objeto. A [gramática da política do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/policies-grammar.html) aproveita isso, definindo os nomes e valores, que têm significado e são compreendidos pelos Serviços da AWS que usam políticas para conceder permissões. AWS Organizations usa um subconjunto da sintaxe e gramática do IAM. Para obter detalhes, consulte [Sintaxe de SCP](orgs_manage_policies_scps_syntax.md). **Topics** + [Mais de um objeto de política](#morethanonepolicyblock) + [Mais de um elemento de declaração](#morethanonestatement) + [O documento da política excedeu o tamanho máximo](#scptoolong) ## Mais de um objeto de política Uma SCP deve conter apenas um único objeto JSON. Você denota um objeto colocando chaves \$1 \$1 em torno. Embora você possa aninhar outros objetos dentro de um objeto JSON incorporando \$1 \$1 adicionais dentro do par de chaves externas, uma política pode conter apenas um par mais externo de \$1 \$1 chaves. O exemplo a seguir está ***incorreto*** porque contém dois objetos no nível superior (indicados em*red*): ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "ec2:Describe*", "Resource": "*" }, { "Effect": "Deny", "Action": "s3:*", "Resource": "*" } ] } ``` ------ No entanto, você pode atender a intenção do exemplo anterior com o uso de gramática correta da política. Em vez de incluir dois objetos de política completos, cada um com seu próprio elemento `Statement`, você pode combinar dois blocos em um único elemento `Statement`. O elemento `Statement` tem um conjunto de dois objetos como seu valor, como mostrado no exemplo a seguir: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "ec2:Describe*", "Resource": "*" }, { "Effect": "Deny", "Action": "s3:*", "Resource": "*" } ] } ``` Esse exemplo não pode ser mais compactado em um `Statement` com um elemento, porque os dois elementos têm diferentes efeitos. Em geral, você pode combinar instruções apenas quando os elementos `Effect` e `Resource` em cada instrução forem idênticos. ## Mais de um elemento de declaração À primeira vista, esse erro pode parecer uma variação do erro na seção anterior. No entanto, sintaticamente é um tipo diferente de erro. No exemplo a seguir, há somente um objeto de política, como indicado por um único par de \$1 \$1 chaves no nível superior. No entanto, esse objeto contém dois elementos `Statement` dentro de si. Uma SCP deve conter apenas um elemento `Statement`, que inclui o nome (`Statement`) que aparece à esquerda do sinal de dois pontos, seguido pelo valor à direita. O valor de um elemento `Statement` deve ser um objeto, denotado por chaves \$1 \$1, contendo um elemento `Effect`, um elemento `Action` e um elemento `Resource`. O exemplo a seguir é ***incorreto***, pois contém dois elementos `Statement` no objeto da política: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "ec2:Describe*", "Resource": "*" }, { "Effect": "Deny", "Action": "s3:*", "Resource": "*" } ] } ``` ------ Como um objeto de valor pode ser um conjunto de vários objetos de valor, você pode resolver esse problema combinando os dois elementos `Statement` em um único elemento com uma matriz de objetos, como mostrado no exemplo a seguir: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "ec2:Describe*", "Resource":"*" }, { "Effect": "Deny", "Action": "s3:*", "Resource": "*" } ] } ``` ------ O valor do elemento `Statement` é uma matriz de objetos. A matriz no exemplo consiste em dois objetos, sendo que cada um deles é um valor correto para um elemento `Statement`. Cada objeto na matriz é separado por vírgulas. ## O documento da política excedeu o tamanho máximo O tamanho máximo de um documento de SCP é de 5.120 caracteres. Este tamanho máximo inclui todos os caracteres, também os espaços em branco. Para reduzir o tamanho da SCP, você poderá remover todos os caracteres de espaço em branco (como espaços e quebras de linha) que estão fora das aspas. **nota** Se você salvar a política usando o Console de gerenciamento da AWS, o espaço em branco extra entre os elementos JSON e fora das aspas será removido e não contado. Se você salvar a política usando uma operação do SDK ou a AWS CLI, a política será salva exatamente como você forneceu e nenhuma remoção automática de caracteres ocorrerá.