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 gestão em AWS Organizations
As políticas de gerenciamento permitem que você configure e Serviços da AWS gerencie centralmente seus recursos. A forma como essas políticas afetam OUs as contas que as herdam depende do tipo de política de gerenciamento à qual você se aplica. AWS Organizations Revise os tópicos desta seção para compreender termos e conceitos relevantes sobre políticas de gerenciamento.
**Topics**
+ [Pré-requisitos e permissões](orgs_manage_policies_prereqs.md)
+ [Noções básicas sobre herança das políticas](orgs_manage_policies_inheritance_mgmt.md)
+ [Como visualizar políticas em vigor](orgs_manage_policies_effective.md)
+ [Alertas de política inválida](invalid-policy-alerts.md)
+ [Políticas declarativas](orgs_manage_policies_declarative.md)
+ [Políticas de backup](orgs_manage_policies_backup.md)
+ [Políticas de tag](orgs_manage_policies_tag-policies.md)
+ [Políticas de aplicativos de chat](orgs_manage_policies_chatbot.md)
+ [Políticas de recusa de serviços de IA](orgs_manage_policies_ai-opt-out.md)
+ [Políticas do Security Hub](orgs_manage_policies_security_hub.md)
+ [Políticas do Amazon Bedrock](orgs_manage_policies_bedrock.md)
+ [Políticas do Amazon Inspector](orgs_manage_policies_inspector.md)
+ [Políticas de implantação de atualizações](orgs_manage_policies_upgrade_rollout.md)
+ [Políticas do Amazon S3](orgs_manage_policies_s3.md)
+ [AWS Shield Políticas do Network Security Director](orgs_manage_policies_network_security_director.md)
# Pré-requisitos e permissões para políticas de gerenciamento para AWS Organizations
Esta página descreve os pré-requisitos e as permissões necessárias para políticas de gerenciamento no AWS Organizations.
**Topics**
+ [Pré-requisitos para as políticas de gerenciamento](#manage-policies-prereqs-overview)
+ [Permissões para políticas de gerenciamento](#manage-policies-permissions)
## Pré-requisitos para as políticas de gerenciamento
Para usar políticas de gerenciamento em uma organização, é necessário o seguinte:
+ A organização deve ter [todos os recursos habilitados](orgs_manage_org_support-all-features.md).
+ É necessário estar conectado à conta gerencial da organização ou ser um administrador delegado.
+ Seu usuário ou função AWS Identity and Access Management (IAM) deve ter as permissões listadas na seção a seguir.
## Permissões para políticas de gerenciamento
O exemplo de política do IAM a seguir fornece permissões para usar todos os aspectos das políticas de gerenciamento em uma organização.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "OrganizationPolicies",
"Effect": "Allow",
"Action": [
"organizations:AttachPolicy",
"organizations:CreatePolicy",
"organizations:DeletePolicy",
"organizations:DescribeAccount",
"organizations:DescribeCreateAccountStatus",
"organizations:DescribeEffectivePolicy",
"organizations:DescribeOrganization",
"organizations:DescribeOrganizationalUnit",
"organizations:DescribePolicy",
"organizations:DetachPolicy",
"organizations:DisableAWSServiceAccess",
"organizations:DisablePolicyType",
"organizations:EnableAWSServiceAccess",
"organizations:EnablePolicyType",
"organizations:ListAccounts",
"organizations:ListAccountsForParent",
"organizations:ListAWSServiceAccessForOrganization",
"organizations:ListCreateAccountStatus",
"organizations:ListOrganizationalUnitsForParent",
"organizations:ListParents",
"organizations:ListPolicies",
"organizations:ListPoliciesForTarget",
"organizations:ListRoots",
"organizations:ListTargetsForPolicy",
"organizations:UpdatePolicy"
],
"Resource": "*"
}
]
}
```
------
Para obter mais informações sobre as políticas e as permissões do IAM, consulte o [Guia do usuário do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/).
# Entendendo a herança da política de gerenciamento
**Importante**
As informações nesta seção ***não*** se aplicam às políticas de autorização: políticas de controle de serviços (SCPs) e políticas de controle de recursos (RCPs). Para obter mais informações sobre como SCPs e RCPs trabalhar em uma AWS Organizations hierarquia, consulte [Avaliação do SCP](orgs_manage_policies_scps_evaluation.md) e. [Avaliação da RCP](orgs_manage_policies_rcps_evaluation.md)
Você pode anexar políticas de gerenciamento a entidades da organização (raiz da organização, unidade organizacional (UO) ou conta) na sua organização:
+ Quando você anexa uma política de gerenciamento à raiz da organização, todas OUs as contas da organização herdam essa política.
+ Quando você anexa uma política de gerenciamento a uma UO específica, as contas que estão diretamente sob essa UO ou qualquer UO filho herdam a política.
+ Quando você anexa uma política de gerenciamento a uma conta específica, ela afeta apenas essa conta.
Como você pode anexar políticas de gerenciamento a vários níveis na organização, as contas podem herdar várias políticas.
Os tópicos a seguir explicam como as políticas pai e as políticas filho são processadas na política em vigor de uma conta.
**Topics**
+ [Terminologia](inheritance-terminology.md)
+ [Tipos de políticas de gerenciamento](syntax-inheritance.md)
+ [Operadores de herança](policy-operators.md)
+ [Exemplos de herança](inheritance-examples.md)
# Terminologia de herança
Este tópico usa os seguintes termos ao discutir herança de política de gerenciamento.
**Herança de política**
A interação de políticas em diferentes níveis de uma organização se move da raiz de nível superior da organização passando pela hierarquia de unidade organizacional (UO) para contas individuais.
Você pode anexar políticas à raiz da organização OUs, às contas individuais e a qualquer combinação dessas entidades da organização. Herança de política de gerenciamento se refere a políticas anexadas à raiz da organização ou a uma UO. Todas as contas que são membros da raiz da organização ou UO em que uma política de gerenciamento está anexada *herdam* essa política.
Por exemplo, quando as políticas de gerenciamento são anexadas à raiz da organização, todas as contas na organização herdam essa política. Isso ocorre porque todas as contas em uma organização estão sempre sob a raiz da organização. Quando você anexa uma política a uma UO específica, as contas que estão diretamente sob essa UO ou qualquer UO filho herdam essa política. Como você pode anexar políticas a vários níveis na organização, as contas podem herdar vários documentos de política para um único tipo de política.
**Políticas principais**
As políticas anexadas em um nível superior na árvore organizacional em relação à políticas anexadas a entidades inferiores na árvore.
Por exemplo, se você anexar a política de gerenciamento A à raiz da organização, ela será apenas uma política. Se também anexar a política B a uma UO nessa raiz, a política A será a política pai da política B. A política B será a política filho da política A. As políticas A e B serão mescladas para criar a política de tag efetiva para contas na UO.
**Políticas secundárias**
As políticas anexadas em um nível inferior na árvore organizacional em relação à política pai.
**Políticas efetivas**
Um documento de política único e definitivo que especifica as regras de atribuição que se aplicam a uma conta. A política efetiva é a agregação de todas as políticas herdadas pela conta, além de qualquer política diretamente anexada à conta. Para obter mais informações, consulte [Como visualizar políticas de gerenciamento em vigor](orgs_manage_policies_effective.md).
**Operadores de herança**
Operadores que controlam como as políticas herdadas se mesclam em uma única política efetiva. Esses operadores são considerados um recurso avançado. Os autores experientes de política podem usá-los para limitar as alterações que uma política filho pode fazer e como as configurações nas políticas são mescladas. Para obter mais informações, consulte [Operadores de herança](policy-operators.md).
# Sintaxe de política e herança para tipos de política de gerenciamento
A forma exata como as políticas afetam OUs as contas que as herdam depende do tipo de política de gerenciamento que você escolher. Os tipos de políticas de gerenciamento incluem:
+ [Políticas declarativas](orgs_manage_policies_declarative.md)
+ [Políticas de backup](orgs_manage_policies_backup.md)
+ [Políticas de tag](orgs_manage_policies_tag-policies.md)
+ [Políticas de aplicativos de chat](orgs_manage_policies_chatbot.md)
+ [Políticas de recusa de serviços de IA](orgs_manage_policies_ai-opt-out.md)
+ [Políticas do Security Hub](orgs_manage_policies_security_hub.md)
+ [Políticas fundamentais](orgs_manage_policies_bedrock.md)
+ [Políticas do Inspector](orgs_manage_policies_inspector.md)
+ [Políticas de implantação de atualizações](orgs_manage_policies_upgrade_rollout.md)
+ [Políticas do S3](orgs_manage_policies_s3.md)
+ [AWS Shield Políticas do Network Security Director](orgs_manage_policies_network_security_director.md)
A sintaxe dos tipos de política de gerenciamento inclui *[Operadores de herança](policy-operators.md)*, que permite especificar com grande granularidade quais elementos das políticas principais são aplicados e quais elementos podem ser substituídos ou modificados quando herdados por filhos e contas. OUs
A *política efetiva* é o conjunto de regras que são herdadas da raiz da organização e OUs junto com aquelas diretamente vinculadas à conta. A política em vigor especifica as regras que se aplicam à conta. É possível visualizar a política efetiva para uma conta que inclui o efeito de todos os operadores de herança nas políticas aplicadas. Para obter mais informações, consulte [Como visualizar políticas de gerenciamento em vigor](orgs_manage_policies_effective.md).
# Operadores de herança
Operadores de herança controlam como as políticas herdadas e as políticas de conta se fundem na política efetiva da conta. Esses operadores incluem operadores de definição de valor e operadores de controle filho.
Ao usar o editor visual no AWS Organizations console, você pode usar somente o `@@assign` operador. Outros operadores são considerados um recurso avançado. Para usar os outros operadores, você deve criar manualmente a política JSON. Os autores experientes de política podem usar os operadores de herança para controlar quais valores são aplicados à política efetiva e limitar as alterações que as políticas filho podem fazer.
Para obter informações sobre como a herança de políticas funciona em uma organização, consulte. [Exemplos de herança](inheritance-examples.md).
## Operadores de definição de valor
Você pode usar os seguintes operadores de definição de valor para controlar como a política interage com suas políticas pai:
+ `@@assign` – **Substitui** quaisquer configurações de política herdadas pelas configurações especificadas. Se a configuração especificada não for herdada, esse operador a adicionará à política efetiva. Esse operador pode se aplicar a qualquer configuração de política de qualquer tipo.
+ Para configurações de valor único, esse operador substitui o valor herdado pelo valor especificado.
+ Para configurações de valores múltiplos (matrizes JSON), esse operador remove quaisquer valores herdados e os substitui pelos valores especificados por esta política.
+ `@@append` – **Adiciona** as configurações especificadas às herdadas (sem remover nenhuma). Se a configuração especificada não for herdada, esse operador a adicionará à política efetiva. Você pode usar esse operador apenas com configurações de vários valores.
+ Este operador adiciona os valores especificados a quaisquer valores na matriz herdada.
+ `@@remove` – **Remove** as configurações herdadas especificadas da política em vigor, se houver. Você pode usar esse operador apenas com configurações de vários valores.
+ Esse operador remove somente os valores especificados da matriz de valores herdados das políticas pai. Outros valores podem continuar a existir na matriz e podem ser herdados por políticas filho.
## Operadores de controle filho
O uso de operadores de controle filho é opcional. Você pode usar o operador `@@operators_allowed_for_child_policies` para controlar quais operadores de definição de valor as políticas filho podem usar. Você pode permitir todos os operadores, alguns operadores específicos ou nenhum operador. Por padrão, todos os operadores (`@@all`) são permitidos.
+ `"@@operators_allowed_for_child_policies"`: `["@@all"]` — Crianças OUs e contas podem usar qualquer operador nas políticas. Por padrão, todos os operadores são permitidos em políticas filho.
+ `"@@operators_allowed_for_child_policies"`: `["@@assign", "@@append", "@@remove"]` — A criança OUs e as contas podem usar somente os operadores especificados nas políticas secundárias. Você pode especificar um ou mais operadores de definição de valor neste operador de controle filho.
+ `"@@operators_allowed_for_child_policies"`: `["@@none"]` — Crianças OUs e contas não podem usar operadores nas políticas. Você pode usar este operador para bloquear efetivamente valores definidos em uma política pai de modo que as políticas filho não possam adicionar, acrescentar ou remover tais valores.
**nota**
Se um operador de controle filho herdado limitar o uso de um operador, você não poderá reverter essa regra em uma política filho. Se você incluir operadores de controle filho em uma política pai, eles limitarão os operadores de definição de valor em todas as políticas filho.
# Exemplos de herança
Estes exemplos mostram como a herança de política funciona ao exibir como as políticas de tag pai e filho são mescladas em uma política de tag efetiva para uma conta.
Os exemplos assumem que você tem a estrutura de organização exibida no diagrama a seguir.
![\[Uma organização com uma conta raiz OUs, duas e várias contas.\]](http://docs.aws.amazon.com/pt_br/organizations/latest/userguide/images/org-structure-inheritance.png)
**Topics**
+ [Exemplo 1: permitir que políticas filho substituam *apenas* valores de tag](#example-assign-operator)
+ [Exemplo 2: anexar novos valores a tags herdadas](#example-append-operator)
+ [Exemplo 3: remover valores de tags herdadas](#example-remove-operator)
+ [Exemplo 4: restringir alterações às políticas filho](#example-restrict-child)
+ [Exemplo 5: conflitos com operadores de controle filho](#multiple-same-node-operators)
+ [Exemplo 6: conflitos com a anexação de valores no mesmo nível de hierarquia](#multiple-same-node-values)
## Exemplo 1: permitir que políticas filho substituam *apenas* valores de tag
A política de tags a seguir define a chave de tag `CostCenter` e dois valores aceitáveis, `Development` e `Support`. Se você anexá-la à raiz da organização, a política de tag estará em vigor para todas as contas na organização.
**Política A — Política de tag da raiz da organização**
```
{
"tags": {
"costcenter": {
"tag_key": {
"@@assign": "CostCenter"
},
"tag_value": {
"@@assign": [
"Development",
"Support"
]
}
}
}
}
```
Suponha que você queira que os usuários usem OU1 um valor de tag diferente para uma chave e imponha a política de tags para tipos de recursos específicos. Como a política A não especifica quais operadores de controle filho são permitidos, todos os operadores são permitidos. Você pode usar o `@@assign` operador e criar uma política de tag como a seguinte para anexar OU1.
**Política B — política de OU1 tags**
```
{
"tags": {
"costcenter": {
"tag_key": {
"@@assign": "CostCenter"
},
"tag_value": {
"@@assign": [
"Sandbox"
]
},
"enforced_for": {
"@@assign": [
"redshift:*",
"dynamodb:table"
]
}
}
}
}
```
Isto é o que acontece ao especificar o operador `@@assign` para a tag quando a política A e a política B são mescladas para formar a *política de tag efetiva* para uma conta:
+ A política B substitui os dois valores de tag que foram especificados na política pai, a política A. O resultado é que `Sandbox` é apenas o valor compatível para a chave de tag `CostCenter`.
+ A adição de `enforced_for` especifica que a tag `CostCenter` *deve* ser o valor de tag especificado em todos os recursos do Amazon RedShift e tabelas do Amazon DynamoDB.
Conforme mostrado no diagrama, OU1 inclui duas contas: 111111111111 e 2222222222.
**Política de tags efetiva resultante para contas 111111111111 e 222222222222**
**nota**
Você não pode usar diretamente o conteúdo de uma política em vigor exibida como o conteúdo de uma nova política. A sintaxe não inclui os operadores necessários para controlar a mesclagem com outras políticas superiores e subordinadas. A exibição de uma política em vigor destina-se apenas à compreensão dos resultados da fusão.
```
{
"tags": {
"costcenter": {
"tag_key": "CostCenter",
"tag_value": [
"Sandbox"
],
"enforced_for": [
"redshift:*",
"dynamodb:table"
]
}
}
}
```
## Exemplo 2: anexar novos valores a tags herdadas
Pode haver casos em que você deseja que todas as contas da organização especifiquem uma chave de tag com uma pequena lista de valores aceitáveis. Para contas em uma UO, convém permitir um valor adicional que somente essas contas possam especificar ao criar recursos. Este exemplo especifica como fazer isso usando o operador `@@append`. O operador `@@append` é um recurso avançado.
Como o exemplo 1, este exemplo começa com a política A para a política de tag da raiz da organização.
**Política A — Política de tag da raiz da organização**
```
{
"tags": {
"costcenter": {
"tag_key": {
"@@assign": "CostCenter"
},
"tag_value": {
"@@assign": [
"Development",
"Support"
]
}
}
}
}
```
Neste exemplo, anexe a política C OU2 a. A diferença neste exemplo é que o uso do operador `@@append` na política C *adiciona*, em vez de substituir, a lista de valores aceitáveis e a regra `enforced_for`.
**Política C — política de OU2 tags para anexar valores**
```
{
"tags": {
"costcenter": {
"tag_key": {
"@@assign": "CostCenter"
},
"tag_value": {
"@@append": [
"Marketing"
]
},
"enforced_for": {
"@@append": [
"redshift:*",
"dynamodb:table"
]
}
}
}
}
```
Anexar a política C à OU2 tem os seguintes efeitos quando a política A e a política C se fundem para formar a política de tags efetiva para uma conta:
+ Como a política C inclui o operador `@@append`, ela permite *adicionar*, e não substituir, a lista de valores de tag aceitáveis especificados na Política A.
+ Como na política B, a adição de `enforced_for` especifica que a tag `CostCenter` deve ser usada como valor de tag especificado em todos os recursos do Amazon RedShift e tabelas do Amazon DynamoDB. Substituir (`@@assign`) e adicionar (`@@append`) terão o mesmo efeito se a política pai não incluir um operador de controle filho que restrinja o que uma política filho pode especificar.
Conforme mostrado no diagrama, OU2 inclui uma conta: 999999999999. A política A e a política C são mescladas para criar a política de tag efetiva para a conta 999999999999.
**Política de tag efetiva para a conta 999999999999**
**nota**
Você não pode usar diretamente o conteúdo de uma política em vigor exibida como o conteúdo de uma nova política. A sintaxe não inclui os operadores necessários para controlar a mesclagem com outras políticas superiores e subordinadas. A exibição de uma política em vigor destina-se apenas à compreensão dos resultados da fusão.
```
{
"tags": {
"costcenter": {
"tag_key": "CostCenter",
"tag_value": [
"Development",
"Support",
"Marketing"
],
"enforced_for": [
"redshift:*",
"dynamodb:table"
]
}
}
}
```
## Exemplo 3: remover valores de tags herdadas
Pode haver casos em que a política de tag anexada à organização defina mais valores de tag do que aqueles você deseja que uma conta use. Este exemplo explica como revisar uma política de tag usando o operador `@@remove`. O `@@remove` é um recurso avançado.
Como os outros exemplos, este exemplo começa com a política A para a política de tag da raiz da organização.
**Política A — Política de tag da raiz da organização**
```
{
"tags": {
"costcenter": {
"tag_key": {
"@@assign": "CostCenter"
},
"tag_value": {
"@@assign": [
"Development",
"Support"
]
}
}
}
}
```
Para este exemplo, anexe a política D à conta 999999999999.
**Política D — Política de tag da conta 999999999999 para remoção de valores**
```
{
"tags": {
"costcenter": {
"tag_key": {
"@@assign": "CostCenter"
},
"tag_value": {
"@@remove": [
"Development",
"Marketing"
],
"enforced_for": {
"@@remove": [
"redshift:*",
"dynamodb:table"
]
}
}
}
}
}
```
A anexação da política D à conta 999999999999 tem os efeitos a seguir quando as políticas A, C e D se mesclam para formar a política de tags efetiva:
+ Supondo que você tenha executado todos os exemplos anteriores, as políticas B, C e C são políticas secundárias de A. A política B está apenas vinculada OU1, portanto, não tem efeito na conta 9999999999999.
+ Para a conta 9999999999999, o único valor aceitável para a chave de tag `CostCenter` é `Support`.
+ A conformidade não é imposta para a chave de tag `CostCenter`.
**Nova política de tag eficaz para a conta 999999999999**
**nota**
Você não pode usar diretamente o conteúdo de uma política em vigor exibida como o conteúdo de uma nova política. A sintaxe não inclui os operadores necessários para controlar a mesclagem com outras políticas superiores e subordinadas. A exibição de uma política em vigor destina-se apenas à compreensão dos resultados da fusão.
```
{
"tags": {
"costcenter": {
"tag_key": "CostCenter",
"tag_value": [
"Support"
]
}
}
}
```
Se você adicionar mais contas posteriormente OU2, suas políticas de tags efetivas serão diferentes das da conta 999999999999. Isso ocorre porque a política mais restritiva D é anexada apenas no nível da conta, e não à UO.
## Exemplo 4: restringir alterações às políticas filho
Pode haver casos em que você queira restringir as alterações nas políticas filho. Este exemplo explica como fazer isso usando operadores de controle filho.
Este exemplo começa com uma nova política de tag da raiz da organização e assume que as políticas de tag ainda não estão anexadas a entidades da organização.
**Política E: política de tag da raiz da organização para restringir alterações em políticas subordinadas**
```
{
"tags": {
"project": {
"tag_key": {
"@@operators_allowed_for_child_policies": ["@@none"],
"@@assign": "Project"
},
"tag_value": {
"@@operators_allowed_for_child_policies": ["@@append"],
"@@assign": [
"Maintenance",
"Escalations"
]
}
}
}
}
```
Quando você anexa a política E à raiz da organização, ela impede que as políticas filho alterem a chave de tag `Project`. No entanto, as políticas filho podem substituir ou anexar valores de tag.
Vamos supor que depois você anexe a seguinte política F a uma UO.
**Política F — Política de tag da UO**
```
{
"tags": {
"project": {
"tag_key": {
"@@assign": "PROJECT"
},
"tag_value": {
"@@append": [
"Escalations - research"
]
}
}
}
}
```
Mesclar as políticas E e F tem os seguintes efeitos nas contas da UO:
+ A política F é uma política filho da Política E.
+ A política F tenta mudar o tratamento do caso, apesar de não ser possível. Isso ocorre porque a política E inclui o operador `"@@operators_allowed_for_child_policies": ["@@none"]` para a chave de tag.
+ No entanto, a política F pode anexar valores de tag para a chave. Isso ocorre porque a política E inclui `"@@operators_allowed_for_child_policies": ["@@append"]` para o valor da tag.
**Política efetiva para contas na UO**
**nota**
Você não pode usar diretamente o conteúdo de uma política em vigor exibida como o conteúdo de uma nova política. A sintaxe não inclui os operadores necessários para controlar a mesclagem com outras políticas superiores e subordinadas. A exibição de uma política em vigor destina-se apenas à compreensão dos resultados da fusão.
```
{
"tags": {
"project": {
"tag_key": "Project",
"tag_value": [
"Maintenance",
"Escalations",
"Escalations - research"
]
}
}
}
```
## Exemplo 5: conflitos com operadores de controle filho
Os operadores de controle filho podem existir em políticas de tag anexadas no mesmo nível na hierarquia da organização. Quando isso acontece, a interseção dos operadores permitidos é usada quando as políticas se mesclam para formar a política efetiva das contas.
Suponha que as políticas G e H estão anexadas à raiz da organização.
**Política G — Política de tag da raiz da organização 1**
```
{
"tags": {
"project": {
"tag_value": {
"@@operators_allowed_for_child_policies": ["@@append"],
"@@assign": [
"Maintenance"
]
}
}
}
}
```
**Política H — Política de tag da raiz da organização 2**
```
{
"tags": {
"project": {
"tag_value": {
"@@operators_allowed_for_child_policies": ["@@append", "@@remove"]
}
}
}
}
```
Neste exemplo, uma política na raiz da organização define que os valores da chave de tag só podem ser anexados. A outra política anexada à raiz da organização permite que as políticas filho anexem e removam valores. A interseção dessas duas permissões é usada para políticas filho. O resultado é que as políticas filho podem anexar valores, mas não remover valores. Portanto, a política filho pode anexar um valor à lista de valores de tag, mas não pode remover o valor `Maintenance`.
## Exemplo 6: conflitos com a anexação de valores no mesmo nível de hierarquia
Você pode anexar várias políticas de tag a cada entidade da organização. Quando você fizer isso, as políticas de tag anexadas à mesma entidade da organização podem incluir informações conflitantes. As políticas são avaliadas com base na ordem em que foram anexadas à entidade da organização. Para alterar qual política é avaliada primeiro, você pode desanexar uma política e reanexá-la.
Suponha que a política J tenha sido a primeira a ser anexada à raiz da organização, e a política K tenha sido a segunda.
**Política J — Primeira política de tag anexada à raiz da organização**
```
{
"tags": {
"project": {
"tag_key": {
"@@assign": "PROJECT"
},
"tag_value": {
"@@append": ["Maintenance"]
}
}
}
}
```
**Política K — Segunda política de tag anexada à raiz da organização**
```
{
"tags": {
"project": {
"tag_key": {
"@@assign": "project"
}
}
}
}
```
Neste exemplo, a chave de tag `PROJECT` é usada na política de tag efetiva porque a política que a definiu foi anexada à raiz da organização primeiro.
**Política JK — Política de tag em vigor para a conta**
A política efetiva para a conta é a seguinte.
**nota**
Você não pode usar diretamente o conteúdo de uma política em vigor exibida como o conteúdo de uma nova política. A sintaxe não inclui os operadores necessários para controlar a mesclagem com outras políticas superiores e subordinadas. A exibição de uma política em vigor destina-se apenas à compreensão dos resultados da fusão.
```
{
"tags": {
"project": {
"tag_key": "PROJECT",
"tag_value": [
"Maintenance"
]
}
}
}
```
# Como visualizar políticas de gerenciamento em vigor
Determine a política de gerenciamento em vigor para uma conta em sua organização.
## O que é uma política de gerenciamento em vigor?
A *política em vigor* especifica as regras finais que se aplicam a uma Conta da AWS para um tipo de política de gerenciamento. É a agregação de uma política de gerenciamento que a conta herda, além de quaisquer políticas para esse tipo de política de gerenciamento que estejam diretamente anexadas à conta. Quando você anexa uma política de gerenciamento à raiz da organização, ela se aplica a todas as contas da organização. Quando você anexa uma política de gerenciamento a uma unidade organizacional (OU), ela se aplica a todas as contas OUs que pertencem à OU. Quando você anexa uma política de gerenciamento diretamente a uma conta, ela se aplica somente a essa conta Conta da AWS.
Para obter informações sobre como as políticas de exclusão dos serviços de IA são combinadas na política final em vigor, consulte [Entendendo a herança da política de gerenciamento](orgs_manage_policies_inheritance_mgmt.md).
**Exemplo de políticas de backup**
A política de backup anexada à raiz da organização pode especificar que todas as contas na organização façam backup de todas as tabelas do Amazon DynamoDB com uma frequência de backup padrão de uma vez por semana. Uma política de backup separada anexada diretamente a uma conta-membro com informações críticas em uma tabela pode substituir a frequência por um valor de uma vez por dia. A combinação dessas políticas de backup compreende a política de backup efetiva. Essa política de backup em vigor é determinada para cada conta da organização individualmente. O resultado, neste exemplo, é que todas as contas na organização fazem backup de suas tabelas do DynamoDB uma vez por semana, com exceção de uma conta que faz backup de suas tabelas diariamente.
**Exemplo da política de tags**
A política de tag vinculada à raiz da organização pode definir uma tag `CostCenter` com quatro valores compatíveis. Uma política de tag separada anexada à conta pode restringir a chave `CostCenter` a apenas dois dos quatro valores compatíveis. A combinação dessas políticas de tag inclui a política de tag efetiva. O resultado é que apenas dois dos quatro valores de tag compatíveis, definidos na política de tag da raiz da organização, são compatíveis com a conta.
**Exemplo de política de aplicativos de chat**
O Amazon Q Developer em aplicativos de chat reavaliará quaisquer configurações do Amazon Q Developer criadas anteriormente em aplicativos de chat em relação às políticas de aplicativos de chat vigentes e negará quaisquer ações anteriormente permitidas se elas forem consistentes com as configurações permitidas e as diretrizes na política vigente. A política em vigor para uma conta-membro define as configurações e barreiras de proteção permitidas. Por exemplo, se uma política de aplicativos de chat que negue o acesso a canais públicos do Slack for aplicada a uma conta de membro, a configuração existente do Amazon Q Developer em aplicativos de chat para canais públicos do Slack na conta do membro será desativada. O Amazon Q Developer em aplicativos de chat não entregará notificações e os membros do canal não poderão executar nenhuma tarefa no canal bloqueado. O console do Amazon Q Developer em aplicativos de chat marcará os canais afetados como desabilitados com uma mensagem de erro apropriada ao lado.
**Exemplo de recusa dos serviços de IA**
A política de exclusão de serviços de IA anexada à raiz da organização pode especificar que todas as contas da organização optem por não usar o conteúdo por todos os serviços de aprendizado AWS de máquina. Uma política de exclusão dos serviços de IA separada, anexada diretamente a uma conta-membro especifica que opta por ter seu conteúdo usado apenas para o Amazon Rekognition. A combinação dessas políticas de exclusão dos serviços de IA constitui a política de exclusão dos serviços de IA em vigor. O resultado é que todas as contas da organização são excluídas de todas Serviços da AWS, com exceção de uma conta que opta pelo Amazon Rekognition.
## Como ver a política de gerenciamento em vigor
Você pode visualizar a política efetiva de um tipo de política de gerenciamento para uma conta na AWS API Console de gerenciamento da AWS, ou AWS Command Line Interface.
**Permissões mínimas**
Para ver a política em vigor de um tipo de política de gerenciamento para uma conta, você deve ter permissão para executar as seguintes ações:
`organizations:DescribeEffectivePolicy`
`organizations:DescribeOrganization` – necessária somente ao usar o console do Organizations
------
#### [ Console de gerenciamento da AWS ]
**Para ver a política em vigor de um tipo de política de gerenciamento para uma conta**
1. Faça login no [console do AWS Organizations](https://console.aws.amazon.com/organizations/v2). Você deve fazer login como um usuário do IAM, assumir um perfil do IAM ou fazer login como usuário-raiz ([não recomendado](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)) na conta gerencial da organização.
1. Na página **[Contas da AWS](https://console.aws.amazon.com/organizations/v2/home/accounts)**, escolha o nome da conta para a qual você deseja visualizar a política em vigor. Talvez seja necessário expandir OUs (escolher a![\[Gray cloud icon representing cloud computing or storage services.\]](http://docs.aws.amazon.com/pt_br/organizations/latest/userguide/images/console-expand.png)) para encontrar a conta que você deseja.
1. Na guia **Políticas**, escolha o tipo de política de gerenciamento para o qual você deseja visualizar a política em vigor.
1. Escolha **View the effective policy for this Conta da AWS**.
O console exibe a política em vigor aplicada à conta especificada.
**nota**
Não é possível copiar e colar uma política em vigor e usá-la como JSON para outra política sem alterações significativas. Documentos de política devem incluir os [operadores de herança](policy-operators.md) que especificam como cada configuração é mesclada na política em vigor final.
------
#### [ AWS CLI & AWS SDKs ]
**Para ver a política em vigor de um tipo de política de gerenciamento para uma conta**
Você pode usar uma das seguintes opções para visualizar a política em vigor:
+ AWS CLI: [describe-effective-policy](https://docs.aws.amazon.com/cli/latest/reference/organizations/describe-effective-policy.html)
O exemplo a seguir mostra a política de exclusão dos serviços de IA em vigor para uma conta.
```
$ aws organizations describe-effective-policy \
--policy-type AISERVICES_OPT_OUT_POLICY \
--target-id 123456789012
{
"EffectivePolicy": {
"PolicyContent": "{\"services\":{\"comprehend\":{\"opt_out_policy\":\"optOut\"}, ....TRUNCATED FOR BREVITY.... "opt_out_policy\":\"optIn\"}}}",
"LastUpdatedTimestamp": "2020-12-09T12:58:53.548000-08:00",
"TargetId": "123456789012",
"PolicyType": "AISERVICES_OPT_OUT_POLICY"
}
}
```
+ AWS SDKs: [DescribeEffectivePolicy](https://docs.aws.amazon.com/organizations/latest/APIReference/API_DescribeEffectivePolicy.html)
------
Para obter informações sobre situações em que uma política efetiva pode se tornar inválida, consulte [Visualizar alertas de políticas inválidas](https://docs.aws.amazon.com//organizations/latest/userguide/invalid-policy-alerts.html).
# Sobre alertas de políticas efetivas inválidas
*Os alertas de política inválidos informam* sobre políticas efetivas inválidas e fornecem mecanismos (APIs) para identificar contas com políticas inválidas. AWS Organizations notifica você de forma assíncrona quando uma de suas contas tem uma política efetiva inválida. A notificação aparece como um banner na página do AWS Organizations console e é registrada como um AWS CloudTrail evento.
## Detectar políticas de gerenciamento efetivas inválidas em sua organização
Há várias maneiras pelas quais você pode visualizar políticas de gerenciamento efetivas inválidas em sua organização: no AWS Management Console, na AWS API, na Interface de Linha de AWS Comando (CLI) ou como AWS CloudTrail um evento.
**Permissões mínimas**
Para encontrar informações relacionadas a políticas efetivas inválidas de um tipo de política de gerenciamento em sua organização, você precisa ter permissão para executar as seguintes ações:
`organizations:ListAccountsWithInvalidEffectivePolicy`
`organizations:ListEffectivePolicyValidationErrors`
`organizations:ListRoots` – necessária somente ao usar o console do Organizations
------
#### [ Console de gerenciamento da AWS ]
**Visualizar políticas de gerenciamento efetivo inválidas no console**
1. Faça login no [console do AWS Organizations](https://console.aws.amazon.com/organizations/v2). Você deve fazer login como um usuário do IAM, assumir uma função do IAM ou fazer login como usuário-raiz ([não recomendado](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)) na conta gerencial da organização.
1. Na página **[Contas da AWS](https://console.aws.amazon.com/organizations/v2/home/accounts)**, se sua organização tiver políticas efetivas inválidas, um banner de aviso será exibido na parte superior da página.
1. No banner, clique em **Exibir problemas detectados** para visualizar a lista de todas as contas em sua organização que têm políticas efetivas inválidas.
1. Para cada conta na lista, selecione **Exibir problemas** para obter mais informações sobre os erros de cada conta mostrados nas seções **Problemas de política efetiva** desta página.
------
#### [ AWS CLI & AWS SDKs ]
**Para ver a política em vigor de um tipo de política de gerenciamento para uma conta**
Os comandos a seguir ajudam você a visualizar contas com políticas efetivas inválidas
+ AWS CLI: [list-accounts-with-invalid-política eficaz](https://docs.aws.amazon.com/cli/latest/reference/organizations/list-accounts-with-invalid-effective-policy.html)
+ AWS SDKs: [ListAccountsWithInvalidEffectivePolicy](https://docs.aws.amazon.com/organizations/latest/APIReference/API_ListAccountsWithInvalidEffectivePolicy.html)
**Os comandos a seguir ajudam você a visualizar erros de política efetivos em uma conta**
+ AWS CLI: [list-effective-policy-validation-erros](https://docs.aws.amazon.com/cli/latest/reference/organizations/list-effective-policy-validation-errors.html)
+ AWS SDKs: [ListEffectivePolicyValidationErrors](https://docs.aws.amazon.com/organizations/latest/APIReference/API_ListEffectivePolicyValidationErrors.html)
------
**AWS CloudTrail**
Você pode usar AWS CloudTrail eventos para monitorar quando as contas em suas organizações têm políticas de gerenciamento efetivas inválidas e quando as políticas são corrigidas. Para obter mais informações, consulte *Exemplos de políticas eficazes* em [Entendendo as entradas do arquivo de AWS Organizations log](https://docs.aws.amazon.com//organizations/latest/userguide/orgs_cloudtrail-integration.html#understanding-service-name-entries).
Se você receber uma notificação de política efetiva inválida, poderá navegar pelo AWS Organizations console ou ligar para eles APIs da sua conta de gerenciamento ou de administrador delegado para obter mais detalhes sobre o status de contas e políticas específicas:
+ `ListAccountsWithInvalidEffectivePolicy` – retorna uma lista de contas na organização que possuem políticas efetivas inválidas de um tipo especificado.
+ `ListEffectivePolicyValidationErrors` – retorna uma lista de erros de validação para uma conta e um tipo de política de gerenciamento especificados. Os erros de validação contêm detalhes, incluindo o código do erro, a descrição do erro e as políticas de contribuição que tornaram a política efetiva inválida.
## Quando uma política de gerenciamento efetiva pode ser considerada inválida
Políticas efetivas em uma conta podem se tornar inválidas se violarem as restrições definidas para o tipo específico de política. Por exemplo, uma política pode não ter um parâmetro obrigatório na política efetiva final ou exceder determinadas cotas definidas para o tipo de política.
**Exemplo de políticas de backup**
Suponha que você crie uma política de backup com nove regras de backup e a anexe à raiz da sua organização. Posteriormente, você cria outra política de backup para o mesmo plano de backup, com mais duas regras, e a anexa a qualquer conta na organização. Nessa situação, há uma política efetiva inválida na conta. Ela é inválida porque a agregação das duas políticas define 11 regras para o plano de backup. O limite é de 10 regras de backup em um plano.
**Atenção**
Se alguma conta na organização tiver uma política efetiva inválida, essa conta não receberá atualizações de política efetivas para o tipo específico de política. Ela continuará com a última política efetiva válida aplicada à conta, a menos que todos os erros sejam corrigidos.
**Exemplos de possíveis erros para políticas efetivas**
+ `ELEMENTS_TOO_MANY` – ocorre quando um atributo específico em uma política efetiva excede o limite permitido, como quando mais de 10 regras são fornecidas para um plano de backup.
+ `ELEMENTS_TOO_FEW` – ocorre quando um atributo específico em uma política efetiva não atinge o limite mínimo, como quando nenhuma região é definida para um plano de backup.
+ `KEY_REQUIRED` – ocorre quando falta uma configuração necessária na política efetiva, como quando falta uma regra de backup em um plano de backup.
AWS Organizations valida as políticas efetivas antes de aplicá-las às contas da sua organização. Esse processo de auditoria é especialmente benéfico se você tiver uma grande estrutura organizacional e se as políticas da sua organização forem gerenciadas por mais de uma equipe.
# Políticas declarativas
As políticas declarativas permitem que você declare e aplique centralmente a configuração desejada para uma determinada empresa AWS service (Serviço da AWS) em grande escala em toda a organização. Uma vez conectada, a configuração é sempre mantida quando o serviço adiciona novos recursos ou APIs. Use políticas declarativas para evitar ações não conformes. Por exemplo, você pode bloquear o acesso público à internet para recursos do Amazon VPC em toda a sua organização.
Os principais benefícios do uso de políticas declarativas são:
+ **Facilidade de uso**: você pode aplicar a configuração básica para um AWS service (Serviço da AWS) com algumas seleções nos AWS Control Tower consoles AWS Organizations e ou com alguns comandos usando o &. AWS CLI AWS SDKs
+ **Defina uma vez e esqueça**: a configuração básica de um AWS service (Serviço da AWS) é sempre mantida, mesmo quando o serviço introduz novos recursos ou. APIs A configuração básica também é mantida quando novas contas são adicionadas a uma organização ou quando novas entidades principais e recursos são criados.
+ **Transparência**: o relatório de status da conta permite que você revise o status atual de todos os atributos compatíveis com as políticas declarativas das contas no escopo. Você também pode criar mensagens de erro personalizáveis, que podem ajudar os administradores a redirecionar os usuários finais para páginas wiki internas ou fornecer uma mensagem descritiva que pode ajudar esses usuários a entender por que uma ação falhou.
Para obter uma lista completa de atributos Serviços da AWS e compatíveis, consulte[Suporte Serviços da AWS e atributos](#orgs_manage_policies_declarative-supported-controls).
**Topics**
+ [Como as políticas declarativas funcionam](#orgs_manage_policies_declarative-how-work)
+ [Mensagens de erro personalizadas](#orgs_manage_policies_declarative-custom-message)
+ [Relatório de status da conta](#orgs_manage_policies_declarative-account-status-report)
+ [Serviços com suporte](#orgs_manage_policies_declarative-supported-controls)
+ [Introdução](orgs_manage_policies-declarative_getting-started.md)
+ [Práticas recomendadas](orgs_manage_policies_declarative_best-practices.md)
+ [Gerar o relatório de status da conta](orgs_manage_policies_declarative_status-report.md)
+ [Sintaxe e exemplos de políticas declarativas](orgs_manage_policies_declarative_syntax.md)
## Como as políticas declarativas funcionam
As políticas declarativas são aplicadas no plano de controle do serviço, o que é uma distinção importante das políticas de [autorização, como políticas de controle de serviço (SCPs) e políticas de controle de recursos (RCPs](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_authorization_policies.html)). Embora as políticas de autorização regulem o acesso ao APIs, as políticas declarativas são aplicadas diretamente no nível do serviço para impor uma intenção duradoura. Isso garante que a configuração básica seja sempre aplicada, mesmo quando novos recursos ou APIs são introduzidos pelo serviço.
A tabela a seguir ajuda a ilustrar essa distinção e fornece alguns casos de uso.
****
| | Políticas de controle de serviço | Políticas de controle de recursos | Políticas declarativas |
| --- | --- | --- | --- |
| Por quê? | Definir e aplicar centralmente controles de acesso consistentes sobre entidades principais (como usuários do IAM e perfis do IAM) em grande escala. | Definir e aplicar centralmente controles de acesso consistentes sobre recursos em grande escala | Definir e aplicar centralmente a configuração básica para serviços AWS em grande escala. |
| Como? | Controlando o máximo de permissões de acesso disponíveis das entidades principais no nível da API. | Controlando o máximo de permissões de acesso disponíveis para recursos no nível da API. | Ao aplicar a configuração desejada de um AWS service (Serviço da AWS) sem usar ações de API. |
| Governa funções vinculadas ao serviço? | Não | Não | Sim |
| Mecanismo de feedback | Erro de SCP de acesso negado não personalizável. | Erro de RCP de acesso negado não personalizável. | Mensagem de erro personalizável. Para obter mais informações, consulte [Mensagens de erro personalizadas para políticas declarativas](#orgs_manage_policies_declarative-custom-message). |
| Exemplo de política | [Impeça que contas de membros saiam da organização](https://github.com/aws-samples/service-control-policy-examples/blob/main/Privileged-access-controls/Deny-member-accounts-from-leaving-your-AWS-organization.json) | [Restrinja o acesso somente a conexões HTTPS aos seus recursos](https://github.com/aws-samples/resource-control-policy-examples/blob/main/Restrict-resource-access-patterns/Restrict-access-to-only-HTTPS-connections-to-your-resources.json) | [Configurações de imagens permitidas](orgs_manage_policies_declarative_syntax.md#declarative-policy-ec2-ami-allowed-images) |
Depois de [criar](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_policies_create.html#create-declarative-policy-procedure) e [anexar](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_policies_attach.html) uma política declarativa, ela é aplicada e aplicada em toda a organização. As políticas declarativas podem ser aplicadas a uma organização inteira, unidades organizacionais (OUs) ou contas. As contas que ingressam em uma organização herdarão automaticamente a política declarativa na organização. Para obter mais informações, consulte [Entendendo a herança da política de gerenciamento](orgs_manage_policies_inheritance_mgmt.md).
A *política efetiva* é o conjunto de regras que são herdadas da raiz da organização e OUs junto com aquelas diretamente vinculadas à conta. A política em vigor especifica as regras que se aplicam à conta. Para obter mais informações, consulte [Como visualizar políticas de gerenciamento em vigor](orgs_manage_policies_effective.md).
Se uma política declarativa for [desanexada](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_policies_detach.html), o estado do atributo voltará ao estado anterior antes da anexação da política declarativa.
## Mensagens de erro personalizadas para políticas declarativas
As políticas declarativas permitem que você crie mensagens de erro personalizadas. Por exemplo, se uma operação de API falhar devido a uma política declarativa, você pode definir a mensagem de erro ou fornecer um URL personalizado, como um link para um wiki interno ou um link para uma mensagem que descreva a falha. Se você não especificar uma mensagem de erro personalizada, AWS Organizations fornece a seguinte mensagem de erro padrão:`Example: This action is denied due to an organizational policy in effect`.
Você também pode auditar o processo de criação de políticas declarativas, atualização de políticas declarativas e exclusão de políticas declarativas com. AWS CloudTrail CloudTrail pode sinalizar falhas na operação da API devido a políticas declarativas. Para obter mais informações, consulte [Registro em log e monitoramento](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_security_incident-response.html).
**Importante**
Não inclua *informações de identificação pessoal (PII)* nem outras informações confidenciais em uma mensagem de erro personalizada. As PII incluem informações gerais que podem ser usadas para identificar ou localizar um indivíduo. Elas abrangem registros financeiros, médicos, educacionais ou trabalhistas. Exemplos de PII incluem endereços, números de contas bancárias e números de telefone.
## Relatório de status da conta para políticas declarativas
O *relatório de status da conta* permite que você revise o status atual de todos os atributos compatíveis com as políticas declarativas das contas no escopo. Você pode escolher as contas e as unidades organizacionais (OUs) a serem incluídas no escopo do relatório ou escolher uma organização inteira selecionando a raiz.
Esse relatório ajuda você a avaliar a prontidão fornecendo um detalhamento por região e se o estado atual de um atributo é *uniforme em todas as contas* (por meio de `numberOfMatchedAccounts`) ou *inconsistente* (por meio de `numberOfUnmatchedAccounts`). Você também pode ver o *valor mais frequente*, que é o valor de configuração observado com mais frequência para o atributo.
Na Figura 1, há um relatório de status da conta gerado, que mostra a uniformidade entre as contas para os seguintes atributos: VPC Block Public Access e Image Block Public Access. Isso significa que, para cada atributo, todas as contas no escopo têm a mesma configuração para esse atributo.
O relatório de status da conta gerado mostra inconsistências nas seguintes contas para os seguintes atributos: configurações de imagens permitidas, metadados padrão da instância, acesso ao console de série e acesso público a snapshots. Neste exemplo, cada atributo com uma conta inconsistente se deve ao fato de haver uma conta com um valor de configuração diferente.
Se houver um valor mais frequente, ele será exibido em sua respectiva coluna. Para obter informações mais detalhadas sobre o que cada atributo controla, consulte [Sintaxe de política declarativa e exemplos de políticas](orgs_manage_policies_declarative_syntax.md).
Você também pode expandir um atributo para ver um detalhamento da região. Neste exemplo, o Bloqueio de Acesso Público de Imagens é expandido e, em cada região, você pode ver que também há uniformidade entre as contas.
A opção de anexar uma política declarativa para impor uma configuração básica depende do seu caso de uso específico. Use o relatório de status da conta para ajudá-lo a avaliar sua prontidão antes de anexar uma política declarativa.
Para obter mais informações, consulte [Geração do relatório de status da conta](orgs_manage_policies_declarative_status-report.md).
![\[Exemplo de relatório de status da conta com uniformidade entre as contas para Acesso Público ao Bloco VPC e Acesso Público ao Bloco de Imagens.\]](http://docs.aws.amazon.com/pt_br/organizations/latest/userguide/images/declarative-status-report.png)
*Figura 1: exemplo de relatório de status da conta com uniformidade entre as contas para Acesso Público ao Bloco VPC e Acesso Público ao Bloco de Imagens.*
## Suporte Serviços da AWS e atributos
### Atributos compatíveis com políticas declarativas para EC2
A tabela a seguir mostra os atributos compatíveis com os serviços relacionados ao Amazon EC2.
**Políticas declarativas para EC2**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/organizations/latest/userguide/orgs_manage_policies_declarative.html)
# Conceitos básicos de políticas declarativas
Siga estas etapas para começar a usar as políticas declarativas.
1. [Saiba mais sobre as permissões que você deve ter para executar tarefas de política declarativa](orgs_manage_policies_prereqs.md).
1. [Habilite as políticas declarativas para a organização.](enable-policy-type.md)
**nota**
**É necessário habilitar o acesso confiável**
Você deve habilitar o acesso confiável para o serviço onde a política declarativa imporá uma configuração básica. Isso cria uma função vinculada ao serviço com permissão somente leitura, que é usada para gerar o relatório de status da conta, mostrando qual é a configuração atual das contas em toda a sua organização.
**Como usar o console**
Se você usa o console do Organizations, essa etapa faz parte do processo para habilitar políticas declarativas.
**Usando o AWS CLI**
Se você usar o AWS CLI, há dois separados APIs:
[EnablePolicyType](https://docs.aws.amazon.com/organizations/latest/APIReference/API_EnablePolicyType.html), que você usa para habilitar políticas declarativas.
[Habilite o AWSService Access](https://docs.aws.amazon.com/organizations/latest/APIReference/API_EnableAWSServiceAccess.html), que você usa para habilitar o acesso confiável.
Para obter mais informações sobre como habilitar o acesso confiável para um serviço específico com o AWS CLI consulte, [Serviços da AWS que você pode usar com AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html).
1. [Execute o relatório de status da conta](orgs_manage_policies_declarative_status-report.md).
1. [Crie uma política declarativa](orgs_policies_create.md).
1. [Anexe a política declarativa à raiz, UO ou conta da sua organização](orgs_policies_attach.md).
1. [Exiba a política declarativa efetiva combinada que se aplica a uma conta](orgs_manage_policies_effective.md).
Para todas essas etapas, você faz login como usuário do IAM, assume uma função do IAM ou faz login como usuário-raiz ([não recomendado](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)) na conta gerencial da organização.
**Outras informações**
+ [Aprenda sobre a sintaxe da política declarativa e veja as políticas de exemplo](orgs_manage_policies_declarative_syntax.md)
# Práticas recomendadas para o uso de políticas declarativas
AWS recomenda as seguintes melhores práticas para o uso de políticas declarativas.
## Aproveite as avaliações de prontidão
Use o *relatório de status da conta* de política declarativa para avaliar o status atual de todos os atributos compatíveis com políticas declarativas para as contas em escopo. Você pode escolher as contas e as unidades organizacionais (OUs) a serem incluídas no escopo do relatório ou escolher uma organização inteira selecionando a raiz.
Esse relatório ajuda você a avaliar a prontidão fornecendo um detalhamento por região e se o estado atual de um atributo é *uniforme em todas as contas* (por meio de `numberOfMatchedAccounts`) ou *inconsistente* (por meio de `numberOfUnmatchedAccounts`). Você também pode ver o *valor mais frequente*, que é o valor de configuração observado com mais frequência para o atributo.
A opção de anexar uma política declarativa para impor uma configuração básica depende do seu caso de uso específico.
Para obter mais informações e um exemplo ilustrativo, consulte [Relatório de status da conta para políticas declarativas](orgs_manage_policies_declarative.md#orgs_manage_policies_declarative-account-status-report).
## Comece pequeno e depois escale
Para simplificar a depuração, comece com uma política de teste. Valide o comportamento e o impacto de cada alteração antes de fazer a próxima alteração. Essa abordagem reduz o número de variáveis que você tem que considerar quando um erro ou resultado inesperado ocorre.
Por exemplo, você pode começar com uma política de teste anexada a uma única conta em um ambiente de teste não crítico. Depois de confirmar que ela funciona de acordo com suas especificações, você pode mover incrementalmente a política na estrutura organizacional para mais contas e mais unidades organizacionais (OUs).
## Estabeleça processos de revisão
Implemente processos para monitorar novos atributos declarativos, avaliar exceções de políticas e fazer ajustes para manter o alinhamento com seus requisitos operacionais e de segurança organizacional.
## Validar alterações usando `DescribeEffectivePolicy`
Depois de fazer uma alteração em uma política declarativa, verifique as políticas efetivas para contas representativas abaixo do nível em que você fez a alteração. Você pode [visualizar a política efetiva usando a Console de gerenciamento da AWS](orgs_manage_policies_effective.md), ou usando a operação da [DescribeEffectivePolicy](https://docs.aws.amazon.com/organizations/latest/APIReference/API_DescribeEffectivePolicy.html)API ou uma de suas variantes AWS CLI ou do AWS SDK. Certifique-se de que a alteração feita tenha o impacto pretendido na política efetiva.
## Comunicar e treinar
Garanta que suas organizações entendam o propósito e o impacto de suas políticas declarativas. Forneça orientações claras sobre os comportamentos esperados e como lidar com falhas devido à aplicação de políticas.
# Gerar o relatório de status da conta para políticas declarativas
O *relatório de status da conta* permite que você revise o status atual de todos os atributos compatíveis com as políticas declarativas das contas no escopo. Você pode escolher as contas e as unidades organizacionais (OUs) a serem incluídas no escopo do relatório ou escolher uma organização inteira selecionando a raiz.
Esse relatório ajuda você a avaliar a prontidão fornecendo um detalhamento por região e se o estado atual de um atributo é *uniforme em todas as contas* (por meio de `numberOfMatchedAccounts`) ou *inconsistente* (por meio de `numberOfUnmatchedAccounts`). Você também pode ver o *valor mais frequente*, que é o valor de configuração observado com mais frequência para o atributo.
A opção de anexar uma política declarativa para impor uma configuração básica depende do seu caso de uso específico.
Para obter mais informações e um exemplo ilustrativo, consulte [Relatório de status da conta para políticas declarativas](orgs_manage_policies_declarative.md#orgs_manage_policies_declarative-account-status-report).
## Pré-requisitos
Antes de gerar um relatório de status da conta, você deve executar as seguintes etapas
1. A API `StartDeclarativePoliciesReport` só pode ser chamada pela conta gerencial ou pelos administradores delegados de uma organização.
1. Você deve ter um bucket do S3 antes de gerar o relatório (criar um novo ou usar um existente), ele deve estar na mesma região em que a solicitação é feita e deve ter uma política de bucket do S3 apropriada. Para obter um exemplo de política do S3, consulte *Exemplo de política do Amazon S3* em [Exemplos ](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_StartDeclarativePoliciesReport.html#API_StartDeclarativePoliciesReport_Examples) na *Referência da API do Amazon EC2*
1. Você deve habilitar o acesso confiável para o serviço onde a política declarativa imporá uma configuração básica. Isso cria uma função vinculada ao serviço com permissão somente leitura, que é usada para gerar o relatório de status da conta, mostrando qual é a configuração atual das contas em toda a sua organização.
**Como usar o console**
Para o console do Organizations, essa etapa faz parte do processo de habilitação de políticas declarativas.
**Usando o AWS CLI**
Para o AWS CLI, use a API [Enable AWSService Access](https://docs.aws.amazon.com/organizations/latest/APIReference/API_EnableAWSServiceAccess.html).
Para obter mais informações sobre como habilitar o acesso confiável para um serviço específico com o AWS CLI consulte, [Serviços da AWS que você pode usar com AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html).
1. Somente um relatório por organização pode ser gerado por vez. Uma tentativa de gerar um relatório enquanto outro estiver em andamento resultará em um erro.
## Acessar o relatório de status de conformidade
**Permissões mínimas**
Para gerar um relatório de status de conformidade, você precisa de permissão para executar as seguintes ações:
`ec2:StartDeclarativePoliciesReport`
`ec2:DescribeDeclarativePoliciesReports`
`ec2:GetDeclarativePoliciesReportSummary`
`ec2:CancelDeclarativePoliciesReport`
`organizations:DescribeAccount`
`organizations:DescribeOrganization`
`organizations:DescribeOrganizationalUnit`
`organizations:ListAccounts`
`organizations:ListDelegatedAdministrators`
`organizations:ListAWSServiceAccessForOrganization`
`s3:PutObject`
**nota**
Se o bucket do Amazon S3 usa criptografia SSE-KMS, você também deve incluir a permissão `kms:GenerateDataKey` na política.
------
#### [ Console de gerenciamento da AWS ]
Use o procedimento a seguir para gerar um relatório do status da conta.
**Para gerar um relatório de status da conta**
1. Faça login no [console do AWS Organizations](https://console.aws.amazon.com/organizations/v2). Você deve fazer login como um usuário do IAM, assumir uma função do IAM ou fazer login como usuário-raiz ([não recomendado](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)) na conta gerencial da organização.
1. Na página **Políticas**, escolha **Políticas declarativas para EC2**.
1. Na página **Políticas declarativas para EC2**, escolha **Exibir relatório de status da conta** no menu suspenso **Ações**.
1. Na página **Exibir relatório de status da conta**, escolha **Gerar relatório de status**.
1. No widget **Estrutura organizacional**, especifique quais unidades organizacionais (OUs) você deseja incluir no relatório.
1. Selecione **Enviar**.
------
#### [ AWS CLI & AWS SDKs ]
**Para gerar um relatório de status da conta**
Os campos disponíveis para este atributo são os seguintes: Utilize as seguintes operações para gerar um relatório de conformidade, verificar o status e visualizar o relatório:
+ `ec2:start-declarative-policies-report`: gera um relatório de status da conta. O relatório é gerado de forma assíncrona, e pode levar várias horas para ser concluído. Para obter mais informações, consulte [StartDeclarativePoliciesReport](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_StartDeclarativePoliciesReport.html) na *Referência de API do Amazon EC2*.
+ `ec2:describe-declarative-policies-report`: descreve os metadados de um relatório de status da conta, incluindo o estado do relatório. Para obter mais informações, consulte [DescribeDeclarativePoliciesReports](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeDeclarativePoliciesReports.html) na *Referência de API do Amazon EC2*.
+ `ec2:get-declarative-policies-report-summary`: recupera um resumo do relatório de status da conta. Para obter mais informações, consulte [GetDeclarativePoliciesReportSummary](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_GetDeclarativePoliciesReportSummary.html) na *Referência de API do Amazon EC2*.
+ `ec2:cancel-declarative-policies-report`: cancela a geração de um relatório de status da conta. Para obter mais informações, consulte [CancelDeclarativePoliciesReport](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CancelDeclarativePoliciesReport.html) na *Referência de API do Amazon EC2*.
Antes de gerar um relatório, conceda à entidade principal das políticas declarativas do EC2 acesso ao bucket do Amazon S3 onde o relatório será armazenado. Para isso, associe a seguinte política ao bucket. Substitua `amzn-s3-demo-bucket` pelo nome real do bucket do Amazon S3, e `identity_ARN` pela identidade do IAM usada para chamar a API `StartDeclarativePoliciesReport`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DeclarativePoliciesReportDelivery",
"Effect": "Allow",
"Principal": {
"AWS": "identity_ARN"
},
"Action": [
"s3:PutObject"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
"Condition": {
"StringEquals": {
"aws:CalledViaLast": "organizations.amazonaws.com"
}
}
}
]
}
```
------
------
# Sintaxe e exemplos de políticas declarativas
Esta página fornece sintaxe e exemplos das políticas declarativas.
## Considerações
+ Quando você configura um atributo de serviço usando uma política declarativa, isso pode afetar vários APIs. Qualquer ação não compatível falhará.
+ Os administradores da conta não poderão modificar o valor do atributo de serviço no nível da conta individual.
## Sintaxe para políticas declarativas
Uma política declarativa é um arquivo de texto sem formatação estruturado de acordo com as regras do [JSON](http://json.org). A sintaxe para políticas declarativas segue a sintaxe para todos os tipos de política de gerenciamento. Para obter uma discussão completa sobre essa sintaxe, consulte [Sintaxe de política e herança para tipos de política de gerenciamento](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_inheritance_mgmt.html). Este tópico se concentra na aplicação dessa sintaxe geral aos requisitos específicos do tipo de política declarativa.
O exemplo a seguir mostra a sintaxe básica para uma política declarativa:
```
{
"ec2_attributes": {
"exception_message": {
"@@assign": "Your custom error message.https://myURL"
}
}
}
```
+ O nome da chave de campo `ec2_attributes`. As políticas declarativas sempre começam com um nome de chave fixo para o determinado AWS service (Serviço da AWS). É a linha superior na política de exemplo acima. Atualmente, as políticas declarativas só oferecem suporte a serviços relacionados ao Amazon EC2.
+ Em `ec2_attributes`, você pode usar `exception_message` para definir uma mensagem de erro personalizada. Para obter mais informações, consulte [Mensagens de erro personalizadas para políticas declarativas](orgs_manage_policies_declarative.md#orgs_manage_policies_declarative-custom-message).
+ Em `ec2_attributes`, você pode inserir uma ou mais das políticas declarativas compatíveis. Para esses esquemas, consulte [Políticas declarativas compatíveis](#declarative-policy-examples).
## Políticas declarativas compatíveis
A seguir estão os atributos Serviços da AWS e que as políticas declarativas suportam. Em alguns dos exemplos a seguir, a formatação de espaço em branco JSON pode ser compactada para economizar espaço.
+ Bloqueio de acesso público a VPC
+ Acesso ao console de série
+ Bloqueio de acesso público a imagens
+ Configurações de imagens permitidas
+ Metadados da instância
+ Bloqueio do acesso público a snapshots
------
#### [ VPC Block Public Access ]
**Efeito da política**
Controla se os recursos na Amazon VPCs e nas sub-redes podem acessar a Internet por meio de gateways da Internet (). IGWs Para obter mais informações, consulte [Configuração para acesso à Internet](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-igw-internet-access.html) no *Guia do usuário da Amazon Virtual Private Cloud*.
**Conteúdo da política**
```
{
"ec2_attributes": {
"vpc_block_public_access": {
"internet_gateway_block": {
"mode": {
"@@assign": "block_ingress"
},
"exclusions_allowed": {
"@@assign": "enabled"
}
}
}
}
}
```
Os campos disponíveis para este atributo são os seguintes:
+ `"internet_gateway"`:
+ `"mode"`:
+ `"off"`: o bloqueio de acesso público a VPC não está habilitado.
+ `"block_ingress"`: Todo o tráfego da Internet para o VPCs (exceto para VPCs as sub-redes que estão excluídas) está bloqueado. Apenas o tráfego de e para gateways NAT e gateways da Internet somente de saída é permitido porque esses gateways só permitem o estabelecimento de conexões de saída.
+ `"block_bidirectional"`: todo o tráfego de e para gateways de internet e gateways de internet somente de saída (exceto excluídos VPCs e sub-redes) está bloqueado.
+ `"exclusions_allowed"`: uma exclusão é um modo que pode ser aplicado a uma única VPC ou sub-rede, isentando-a do modo BPA da VPC da conta e permitindo acesso bidirecional ou somente de saída.
+ `"enabled"`: as exclusões podem ser criadas pela conta.
+ `"disabled"`: as exclusões não podem ser criadas pela conta.
**nota**
É possível usar o atributo para configurar se as exclusões são permitidas, mas não é possível criar exclusões com o próprio atributo. Para criar exclusões, você deve criá-las na conta proprietária da VPC. Para obter mais informações sobre como criar exclusões de BPA na VPC, consulte [Criar e excluir exclusões](https://docs.aws.amazon.com//vpc/latest/userguide/security-vpc-bpa.html#security-vpc-bpa-exclusions) no *Manual do usuário da Amazon VPC*.
**Considerações**
Se você usar esse atributo em uma política declarativa, não poderá usar as operações a seguir para modificar a configuração imposta para as contas no escopo. Essa lista não é exaustiva:
+ `ModifyVpcBlockPublicAccessOptions`
+ `CreateVpcBlockPublicAccessExclusion`
+ `ModifyVpcBlockPublicAccessExclusion`
------
#### [ Serial Console Access ]
**Efeito da política**
Controla se o console de série do EC2 está acessível. Para obter mais informações sobre o console de série do EC2, consulte [Console de série do EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-serial-console.html) no *Guia do usuário do Amazon Elastic Compute Cloud*.
**Conteúdo da política**
```
{
"ec2_attributes": {
"serial_console_access": {
"status": {
"@@assign": "enabled"
}
}
}
}
```
Os campos disponíveis para este atributo são os seguintes:
+ `"status"`:
+ `"enabled"`: o acesso ao console de série do EC2 é permitido.
+ `"disabled"`: o acesso ao console de série do EC2 está bloqueado.
**Considerações**
Se você usar esse atributo em uma política declarativa, não poderá usar as operações a seguir para modificar a configuração imposta para as contas no escopo. Essa lista não é exaustiva:
+ `EnableSerialConsoleAccess`
+ `DisableSerialConsoleAccess`
------
#### [ Image Block Public Access ]
**Efeito da política**
Controla se as Amazon Machine Images (AMIs) podem ser compartilhadas publicamente. Para obter mais informações sobre AMIs, consulte [Amazon Machine Images (AMIs)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) no *Guia do usuário do Amazon Elastic Compute Cloud*.
**Conteúdo da política**
```
{
"ec2_attributes": {
"image_block_public_access": {
"state": {
"@@assign": "block_new_sharing"
}
}
}
}
```
Os campos disponíveis para este atributo são os seguintes:
+ `"state"`:
+ `"unblocked"`: Sem restrições ao compartilhamento público de AMIs.
+ `"block_new_sharing"`: Bloqueia o novo compartilhamento público de AMIs. AMIs que já foram compartilhados publicamente permanecem disponíveis publicamente.
**Considerações**
Se você usar esse atributo em uma política declarativa, não poderá usar as operações a seguir para modificar a configuração imposta para as contas no escopo. Essa lista não é exaustiva:
+ `EnableImageBlockPublicAccess`
+ `DisableImageBlockPublicAccess`
------
#### [ Allowed Images Settings ]
**Efeito da política**
Controla a descoberta e o uso de Amazon Machine Images (AMI) no Amazon EC2 com Allowed. AMIs Para obter mais informações sobre isso AMIs, consulte [Controle a descoberta e o uso de AMIs no Amazon EC2 com](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-allowed-amis.html) Allowed no Guia do AMIs usuário do *Amazon Elastic Compute Cloud.*
**Conteúdo da política**
Os campos disponíveis para este atributo são os seguintes:
```
{
"ec2_attributes": {
"allowed_images_settings": {
"state": {
"@@assign": "enabled"
},
"image_criteria": {
"criteria_1": {
"allowed_image_providers": {
"@@append": [
"amazon"
]
}
}
}
}
}
}
```
+ `"state"`:
+ `"enabled"`: o atributo está ativo e em vigor.
+ `"disabled"`: o atributo está inativo e não está em vigor.
+ `"audit_mode"`: o atributo está no modo de auditoria. Isso significa que o sistema identificará imagens não conformes, mas não bloqueará o uso delas.
+ `"image_criteria"`: uma lista de critérios. Suporte para até 10 critérios com nomes de criteria\$11 a criteria\$110.
+ `"allowed_image_providers"`: uma lista separada por vírgulas da conta de 12 dígitos IDs ou alias do proprietário da amazon, aws\$1marketplace, aws\$1backup\$1vault.
+ `"image_names"`: os nomes das imagens permitidas. Os nomes podem incluir curingas (? e \$1). Comprimento: 1–128 caracteres. Com o caractere ?, o mínimo é de 3 caracteres.
+ `"marketplace_product_codes"`: Os códigos de produto do AWS Marketplace para imagens permitidas. Comprimento: 1-25 caracteres Caracteres válidos: letras (A-Z, a-z) e números (0-9)
+ `"creation_date_condition"`: idade máxima permitida para as imagens.
+ `"maximum_days_since_created"`: o número máximo de dias que se passaram desde que a imagem foi criada. Intervalo válido: valor mínimo de 0. Valor máximo de 2147483647.
+ `"deprecation_time_condition"`: o período máximo desde a descontinuação para imagens permitidas.
+ `"maximum_days_since_deprecated"`: o número máximo de dias que se passaram desde que a imagem foi descontinuada. Intervalo válido: valor mínimo de 0. Valor máximo de 2147483647.
**Considerações**
Se você usar esse atributo em uma política declarativa, não poderá usar as operações a seguir para modificar a configuração imposta para as contas no escopo. Essa lista não é exaustiva:
+ `EnableAllowedImagesSettings`
+ `ReplaceImageCriteriaInAllowedImagesSettings`
+ `DisableAllowedImagesSettings`
------
#### [ Instance Metadata ]
**Efeito da política**
Controla os padrões do IMDS e a aplicação do IMDSv2 para todas as novas inicializações de instâncias do EC2. *Para obter mais informações sobre os padrões e a IMDSv2 aplicação do IMDS, consulte [Usar metadados de instância para gerenciar sua instância do EC2 no Guia do usuário do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html).*
**Conteúdo da política**
Os campos disponíveis para este atributo são os seguintes:
```
{
"ec2_attributes": {
"instance_metadata_defaults": {
"http_tokens": {
"@@assign": "required"
},
"http_put_response_hop_limit": {
"@@assign": "4"
},
"http_endpoint": {
"@@assign": "enabled"
},
"instance_metadata_tags": {
"@@assign": "enabled"
},
"http_tokens_enforced": {
"@@assign": "enabled"
}
}
}
}
```
+ `"http_tokens"`:
+ `"no_preference"`: outros padrões se aplicam. Por exemplo, a AMI usa como padrão, se aplicável.
+ `"required"`: IMDSv2 deve ser usado. IMDSv1 não é permitido.
+ `"optional"`: Ambos IMDSv1 IMDSv2 são permitidos.
**nota**
**Versão de metadados**
Antes de `http_tokens` configurar como `required` (IMDSv2 deve ser usado), certifique-se de que nenhuma das suas instâncias esteja fazendo IMDSv1 chamadas. Para obter mais informações, consulte [Etapa 1: Identificar instâncias com IMDSv2 =opcional e auditar o IMDSv1 uso](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-transition-to-version-2.html#path-step-1) no Guia do usuário do *Amazon EC2*.
+ `"http_put_response_hop_limit"`:
+ `"Integer"`: valor inteiro de -1 a 64, representando o número máximo de saltos que o token de metadados pode percorrer. Para indicar que não há preferência, especifique -1.
**nota**
**Limite de salto**
Se `http_tokens` estiver definido como `required`, é recomendável definir `http_put_response_hop_limit` para um mínimo de 2. Para obter mais informações, consulte [Considerações sobre o acesso aos metadados da instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html#imds-considerations) no *Guia do usuário do Amazon Elastic Compute Cloud*.
+ `"http_endpoint"`:
+ `"no_preference"`: outros padrões se aplicam. Por exemplo, a AMI usa como padrão, se aplicável.
+ `"enabled"`: o endpoint do serviço de metadados da instância está acessível.
+ `"disabled"`: o endpoint do serviço de metadados da instância não está acessível.
+ `"instance_metadata_tags"`:
+ `"no_preference"`: outros padrões se aplicam. Por exemplo, a AMI usa como padrão, se aplicável.
+ `"enabled"`: as tags de instância podem ser acessadas a partir dos metadados da instância.
+ `"disabled"`: as tags da instância não podem ser acessadas a partir dos metadados da instância.
+ `"http_tokens_enforced":`
+ `"no_preference"`: outros padrões se aplicam. Por exemplo, a AMI usa como padrão, se aplicável.
+ `"enabled"`: IMDSv2 deve ser usado. As tentativas de iniciar uma IMDSv1 instância ou ativá-la IMDSv1 em instâncias existentes falharão.
+ `"disabled"`: Ambos IMDSv1 IMDSv2 são permitidos.
**Atenção**
**IMDSv2 fiscalização**
Ativar a IMDSv2 fiscalização enquanto permite IMDSv1 e IMDSv2 (token opcional) causará falhas de inicialização, a menos que IMDSv1 seja explicitamente desativado, seja por meio de parâmetros de execução ou padrões da AMI. Para obter mais informações, consulte [Falha ao iniciar uma instância IMDSv1 habilitada](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/troubleshooting-launch.html#launching-an-imdsv1-enabled-instance-fails) no Guia do usuário do *Amazon EC2*.
------
#### [ Snapshot Block Public Access ]
**Efeito da política**
Controla se os snapshots do Amazon EBS estão acessíveis ao público. Consulte mais informações sobre snapshots do EBS, consulte [Snapshots do Amazon Elastic Block Store](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-snapshots.html) no *Guia do usuário do Amazon Elastic Block Store*.
**Conteúdo da política**
```
{
"ec2_attributes": {
"snapshot_block_public_access": {
"state": {
"@@assign": "block_new_sharing"
}
}
}
}
```
Os campos disponíveis para este atributo são os seguintes:
+ `"state"`:
+ `"block_all_sharing"`: bloqueia todos os compartilhamentos públicos dos snapshots. Os snapshots que já foram compartilhados publicamente são tratados como privados e não estão mais disponíveis publicamente.
+ `"block_new_sharing"`: bloqueia o novo compartilhamento público de snapshots. Os snapshots que já foram compartilhados publicamente permanecem disponíveis publicamente.
+ `"unblocked"`: sem restrições ao compartilhamento público de snapshots.
**Considerações**
Se você usar esse atributo em uma política declarativa, não poderá usar as operações a seguir para modificar a configuração imposta para as contas no escopo. Essa lista não é exaustiva:
+ `EnableSnapshotBlockPublicAccess`
+ `DisableSnapshotBlockPublicAccess`
------
# Políticas de backup
As políticas de backup permitem que você gerencie e aplique centralmente os planos de backup aos AWS recursos nas contas de uma organização.
[AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/)permite que você crie [planos de backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/about-backup-plans.html) que definam como fazer backup de seus AWS recursos. As regras do plano incluem uma variedade de configurações, como a frequência do backup, a janela de tempo durante a qual o backup ocorre, a Região da AWS contenção dos recursos para backup e o cofre no qual armazenar o backup. Em seguida, você pode aplicar um plano de backup a grupos de AWS recursos identificados usando tags. Você também deve identificar uma função AWS Identity and Access Management (IAM) que conceda AWS Backup permissão para realizar a operação de backup em seu nome.
As políticas de backup AWS Organizations combinam todas essas peças em documentos de texto [JSON](https://json.org). Você pode anexar uma política de backup a qualquer um dos elementos da estrutura da sua organização, como a raiz, as unidades organizacionais (OUs) e as contas individuais. Organizations aplica regras de herança para combinar as políticas na raiz da organização, em qualquer pai OUs ou vinculadas à conta. Isso resulta em uma [política de backup efetiva](orgs_manage_policies_effective.md) para cada conta. Essa política eficaz instrui AWS Backup como fazer backup automático de seus AWS recursos.
## Como as políticas de backup funcionam
As políticas de backup oferecem controle granular sobre o backup de seus recursos em qualquer nível que sua organização exija. Por exemplo, você pode especificar em uma política anexada à raiz da organização que ser feito backup de todas as tabelas do Amazon DynamoDB. Essa política pode incluir uma frequência de backup padrão. Em seguida, você pode anexar uma política de backup OUs que substitua a frequência de backup de acordo com os requisitos de cada OU. Por exemplo, a UO `Developers` pode especificar uma frequência de backup de uma vez por semana, enquanto a UO `Production` especifica uma vez por dia.
Você pode criar políticas de backup parciais que incluem individualmente apenas parte das informações necessárias para fazer backup de seus recursos com êxito. Você pode anexar essas políticas a diferentes partes da árvore organizacional, como a raiz ou a UO principal, com a intenção de que essas políticas parciais sejam herdadas por contas e níveis inferiores OUs . Quando o Organizations combina todas as políticas de uma conta usando regras de herança, a política em vigor resultante deve ter todos os elementos necessários. Caso contrário, AWS Backup considera que a política não é válida e não faz backup dos recursos afetados.
**Importante**
AWS Backup só pode realizar um backup bem-sucedido quando invocado por uma política *completa* e eficaz que tenha todos os elementos necessários.
Embora uma estratégia de política parcial, conforme descrito no parágrafo anterior, possa funcionar, se uma política em vigor de uma conta estiver incompleta, isso resultará em erros ou na impossibilidade de fazer backup de alguns recursos. Como estratégia alternativa, considere exigir que todas as políticas de backup sejam completas e válidas por si só. Use valores padrão fornecidos por políticas anexadas em níveis mais alto na hierarquia e substitua-os quando necessário em políticas filho, incluindo [operadores de controle de herança filho](policy-operators.md).
O plano de backup efetivo para cada um Conta da AWS na organização aparece no AWS Backup console como um plano imutável para essa conta. Você pode visualizá-lo, mas não alterá-lo. No entanto, você pode adicionar ou remover etiquetas do plano de backup usando [TagResource[UntagResource](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_UntagResource.html)](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_TagResource.html) APIse.
Quando AWS Backup inicia um backup com base em um plano de backup criado pela política, você pode ver o status da tarefa de backup no AWS Backup console. Um usuário em uma conta-membro pode ver o status e quaisquer erros para os trabalhos de backup nessa conta-membro. Se você também habilitar o acesso a serviços confiáveis com AWS Backup, um usuário na conta de gerenciamento da organização poderá ver o status e os erros de todas as tarefas de backup na organização. Para obter mais informações, consulte [Habilitação de o gerenciamento entre contas](https://docs.aws.amazon.com/aws-backup/latest/devguide/manage-cross-account.html#enable-cross-account) no *Guia do desenvolvedor do AWS Backup *.
# Conceitos básicos sobre políticas de backup
Siga estas etapas para começar a usar as políticas de backup.
1. [Saiba mais sobre as permissões que você deve ter para executar qualquer tarefas de política de backup](orgs_manage_policies_prereqs.md).
1. [Saiba mais sobre algumas das melhores práticas que recomendamos ao usar políticas de backup](orgs_manage_policies_backup_best-practices.md).
1. [Ative políticas de backup para sua organização](enable-policy-type.md).
1. [Crie uma política de backup](orgs_policies_create.md#create-backup-policy-procedure).
1. [Anexe a política de backup à raiz, UO ou conta da sua organização](orgs_policies_attach.md).
1. [Exiba a política de backup efetiva combinada que se aplica a uma conta](orgs_manage_policies_effective.md).
Para todas essas etapas, você faz login como usuário do IAM, assume um perfil do IAM ou faz login como usuário-raiz ([não recomendado](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)) na conta gerencial da organização.
**Outras informações**
+ [Aprenda sobre a sintaxe da política de backup e veja as políticas de exemplo](orgs_manage_policies_backup_syntax.md)
# Melhores práticas para usar políticas de backup
AWS recomenda as seguintes práticas recomendadas para o uso de políticas de backup.
## Decidir uma estratégia de política de backup
Você pode criar políticas de backup em partes incompletas que são herdadas e mescladas para criar uma política completa para cada conta-membro. Se você fizer isso, corre o risco de acabar com uma política efetiva que não esteja completa se fizer uma alteração em um nível sem considerar cuidadosamente o impacto da alteração em todas as contas abaixo desse nível. Para que isso seja evitado, recomendamos que, em vez disso, você verifique se as políticas de backup implementadas em todos os níveis são completas em si mesmas. Trate as políticas superiores políticas padrão que podem ser substituídos pelas configurações especificadas nas políticas subordinadas. Dessa forma, mesmo que uma política subordinada não exista, a política herdada fica completa e usa os valores padrão. Você pode controlar quais configurações podem ser adicionadas, alteradas ou removidas por políticas subordinadas usando os [operadores de herança de controle de subordinados](policy-operators.md#child-control-operators).
## Como validar alterações na verificação de políticas de backup usando `GetEffectivePolicy`
Depois de fazer uma alteração em uma política de backup, verifique as políticas efetivas para contas representativas abaixo do nível em que você fez a alteração. Você pode [visualizar a política efetiva usando a Console de gerenciamento da AWS](orgs_manage_policies_effective.md), ou usando a operação da [GetEffectivePolicy](https://docs.aws.amazon.com/organizations/latest/APIReference/API_GetEffectivePolicy.html)API ou uma de suas variantes AWS CLI ou do AWS SDK. Certifique-se de que a alteração feita tenha o impacto pretendido na política efetiva.
## Comece simples e faça pequenas alterações
Para simplificar a depuração, comece com políticas simples e faça alterações em um item de cada vez. Valide o comportamento e o impacto de cada alteração antes de fazer a próxima alteração. Essa abordagem reduz o número de variáveis que você tem que considerar quando um erro ou resultado inesperado acontece.
## Armazene cópias de seus backups em outras contas Regiões da AWS e em sua organização
Para melhorar sua posição na recuperação de desastres, você pode armazenar cópias de seus backups.
+ **Uma região diferente** — Se você armazenar cópias do backup em outros lugares Regiões da AWS, ajudará a proteger o backup contra corrupção ou exclusão acidental na região original. Use a seção `copy_actions` da política para especificar um cofre em uma ou mais regiões da mesma conta em que o plano de backup é executado. Para fazer isso, identifique a conta usando o a variável `$account` quando você especificar o ARN do cofre de backup no qual a cópia do backup será armazenada. A variável `$account ` é automaticamente substituída em tempo de execução pelo ID da conta em que a política de backup está sendo executada.
+ **Uma conta diferente** — Se você armazenar cópias do backup em adição Contas da AWS, você adiciona uma barreira de segurança que ajuda a proteger contra um agente mal-intencionado que compromete uma de suas contas. Use a seção `copy_actions` da política para especificar um cofre em uma ou mais contas de sua organização, separadas da conta em que o plano de backup é executado. Para fazer isso, identifique a conta usando o número do ID quando especificar o ARN do cofre de backup no qual a cópia do backup será armazenada.
## Limitar o número de planos por política
É mais complicado solucionar problemas em políticas que contêm vários planos devido ao maior número de saídas que devem ser validadas. Em vez disso, faça com que cada política contenha apenas um plano de backup para simplificar a depuração e a solução de problemas. Depois, você pode adicionar políticas extras com outros planos para atender a outros requisitos. Essa abordagem ajuda a manter quaisquer problemas com um plano isolados em uma política, além de impedir que esses problemas compliquem a solução de problemas com outras políticas e seus planos.
## Use conjuntos de pilhas para criar as funções de IAM e os cofres de backup necessários
Use a integração de conjuntos de AWS CloudFormation pilhas com Organizations para criar automaticamente os cofres de backup e as funções AWS Identity and Access Management (IAM) necessárias em cada uma das contas membros da sua organização. Você pode criar um conjunto de pilhas que inclua os recursos que você deseja disponibilizar automaticamente Conta da AWS em cada um de sua organização. Essa abordagem permite que você execute seus planos de backup com a garantia de que as dependências já foram atendidas. Para obter mais informações, consulte [Criação de um conjunto de pilhas com permissões autogerenciadas](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-getting-started-create.html#create-stack-set-service-managed-permissions) no *Manual do usuário do AWS CloudFormation *.
## Verifique seus resultados analisando o primeiro backup criado em cada conta
Ao fazer uma alteração em uma política, verifique o próximo backup criado após essa alteração para garantir que a alteração teve o impacto desejado. Essa etapa vai além de analisar a política efetiva e garante que ela AWS Backup interprete suas políticas e implemente os planos de backup da maneira pretendida.
# Usando AWS CloudTrail eventos para monitorar políticas de backup em sua organização
Você pode usar AWS CloudTrail eventos para monitorar quando as políticas de backup são criadas, atualizadas ou excluídas de qualquer conta em sua organização ou quando há um plano de backup organizacional inválido. Para obter mais informações, consulte [Registrar eventos de gerenciamento entre contas ](https://docs.aws.amazon.com/aws-backup/latest/devguide/logging-using-cloudtrail.html#logging-cam-events) no *AWS Backup Guia do desenvolvedor*.
# Sintaxe e exemplos de políticas de backup
Esta página descreve a sintaxe da política de backup e fornece exemplos.
## Sintaxe para políticas de backup
Uma política de backup é um arquivo de texto sem formatação estruturado de acordo com as regras do [JSON](http://json.org). A sintaxe para políticas de backup segue a sintaxe para todos os tipos de política de gerenciamento. Para obter mais informações, consulte [Sintaxe de política e herança para tipos de política de gerenciamento](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_inheritance_mgmt.html). Este tópico se concentra na aplicação dessa sintaxe geral aos requisitos específicos do tipo de política de backup.
Para obter mais informações sobre AWS Backup planos, consulte [CreateBackupPlan](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_CreateBackupPlan.html)o *Guia do AWS Backup desenvolvedor*.
## Considerações
**Sintaxe da política**
Nomes de chave duplicados serão rejeitados em JSON.
As políticas devem especificar os recursos Regiões da AWS e os recursos a serem copiados.
As políticas devem especificar a função do IAM que ela AWS Backup assume.
Usar o operador `@@assign` no mesmo nível pode sobrescrever as configurações existentes. Para obter mais informações, consulte [Uma política secundária substitui as configurações em uma política principal](#backup-policy-example-5).
Operadores de herança controlam como as políticas herdadas e as políticas de conta se fundem na política efetiva da conta. Esses operadores incluem operadores de definição de valor e operadores de controle filho.
Para obter mais informações, consulte [Operadores de herança](policy-operators.md) e [Exemplos de política de backup](#backup-policy-examples).
**Perfis do IAM**
O perfil do IAM deve existir ao criar um plano de backup pela primeira vez.
O perfil do IAM deve ter permissão para acessar recursos identificados pela consulta de tag.
O perfil do IAM deve ter permissão para executar o backup.
**Cofres de backup**
Os cofres devem existir em cada um deles para que um plano Regiões da AWS de backup possa ser executado.
Devem existir cofres para cada AWS conta que recebe a política efetiva. Para obter mais informações, consulte [Criar e excluir um cofre de backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/create-a-vault.html) no *Guia do desenvolvedor de AWS Backup *.
Recomendamos que você use conjuntos de AWS CloudFormation pilhas e sua integração com Organizations para criar e configurar automaticamente cofres de backup e funções do IAM para cada conta membro na organização. Para obter mais informações, consulte [Criar um conjunto de pilhas com permissões autogerenciadas](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-getting-started-create.html#create-stack-set-service-managed-permissions) no *Guia do usuário do AWS CloudFormation *.
**Cotas**
Para obter uma lista de cotas, consulte [Cotas de AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/aws-backup-limits.html#aws-backup-policies-quotas-table) no *Guia do desenvolvedor de AWS Backup *.
## Sintaxe de backup: visão geral
A sintaxe da política de backup inclui os seguintes componentes:
```
{
"plans": {
"PlanName": {
"rules": { ... },
"regions": { ... },
"selections": { ... },
"advanced_backup_settings": { ... },
"backup_plan_tags": { ... },
"scan_settings": { ... }
}
}
}
```
**Elementos de política de backup**
| Elemento | Description | Obrigatório |
| --- | --- | --- |
| [regras](#backup-policy-rules) | Lista de regras de backup. Cada regra define quando os backups começam e a janela de execução dos recursos especificados nos elementos regions e selections. | Sim |
| [regiões](#backup-plan-regions) | Lista de Regiões da AWS onde uma política de backup pode proteger os recursos. | Sim |
| [selections](#backup-plan-selections) | Um ou mais tipos de recursos dentro das regions especificadas que as rules de backup protegem. | Sim |
| [advanced\$1backup\$1settings](#advanced-backup-settings) | Opções de configuração para cenários de backup específicos. Atualmente, a única configuração de backup avançada compatível está habilitando os backups do Microsoft Volume Shadow Copy Service (VSS) para Windows ou SQL Server em execução em uma instância do Amazon EC2. | Não |
| [backup\$1plan\$1tags](#backup-plan-tags) | Tags que você deseja associar a um plano de backup. Cada tag é um rótulo que consiste em um valor e uma chave definida pelo usuário. As tags podem ajudar você a gerenciar, identificar, organizar, pesquisar e filtrar planos de backup. | Não |
| [configurações de digitalização](#scan-settings) | Opções de configuração para configurações de digitalização. Atualmente, a única configuração de escaneamento compatível é habilitar o Amazon GuardDuty Malware Protection para AWS Backup. | Não |
## Sintaxe de backup: regras
A chave de política `rules` especifica as tarefas de backup agendadas que AWS Backup executa nos recursos selecionados.
**Elementos de regra de backup**
| Elemento | Description | Obrigatório |
| --- | --- | --- |
| schedule\$1expression | Expressão Cron em UTC que especifica quando AWS Backup inicia uma tarefa de backup. Para obter informações sobre a expressão cron, consulte [Usando expressões cron e rate para programar regras](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-scheduled-rule-pattern.html) no *Amazon EventBridge User* Guide. | Sim |
| target\$1backup\$1vault\$1name | Cofre de backup em que backups são armazenados. Os cofres de backup são identificados por nomes exclusivos da conta usada para criá-los e do Região da AWS local em que foram criados. | Sim |
| target\$1logically\$1air\$1gapped\$1backup\$1vault\$1arn | ARN de cofre logicamente isolado onde os backups são armazenados. Se fornecidos, os recursos compatíveis totalmente gerenciados fazem backup diretamente para um cofre com espaço aéreo lógico, enquanto outros recursos compatíveis criam um instantâneo temporário (faturável) no cofre de backup e, em seguida, o copiam para um cofre com lacuna lógica. Recursos incompatíveis só fazem backup no cofre de backup especificado. O ARN deve usar os espaços reservados especiais e. `$region` `$account` Por exemplo, para um cofre chamado, `AirGappedVault` o valor correto é`arn:aws:backup:$region:$account:backup-vault:AirGappedVault`. | Não |
| start\$1backup\$1window\$1minutes | O número de minutos a aguardar antes de cancelar uma tarefa de backup será definido caso ela não seja iniciada com sucesso. Se esse valor for incluído, deve ser de pelo menos 60 minutos para evitar erros. | Não |
| complete\$1backup\$1window\$1minutes | Número de minutos após o início bem-sucedido de uma tarefa de backup antes que ela seja concluída ou cancelada pelo AWS Backup. | Não |
| enable\$1continuous\$1backup | Especifica se AWS Backup cria backups contínuos. `True`causa AWS Backup a criação de backups contínuos capazes de point-in-time restauração (PITR). `False`(ou não especificadas) causas AWS Backup para criar backups instantâneos. Para obter mais informações sobre backups contínuos, consulte [P oint-in-time recovery](https://docs.aws.amazon.com/aws-backup/latest/devguide/point-in-time-recovery.html) no *Guia do AWS Backup desenvolvedor*. **Observação:** os backups habilitados para PITR têm retenção máxima de 35 dias. | Não |
| lifecycle | Especifica quando é feita a AWS Backup transição de um backup para armazenamento frio e quando ele expira. Os tipos de recursos que podem ser transferidos para o armazenamento a frio estão listados na tabela [Disponibilidade de recursos por recurso](https://docs.aws.amazon.com/aws-backup/latest/devguide/backup-feature-availability.html#features-by-resource) no *Manual do desenvolvedor de *AWS Backup . Cada ciclo de vida contém os seguintes elementos: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/organizations/latest/userguide/orgs_manage_policies_backup_syntax.html) **Observação**: os backups transferidos para armazenamento “frio” devem ficar armazenados lá por no mínimo 90 dias. Isso significa que `delete_after_days` deve ser 90 dias maior que `move_to_cold_storage_after_days`. | Não |
| copy\$1actions | Especifica se AWS Backup copia um backup para um ou mais locais adicionais. Cada ação de cópia contém os seguintes elementos: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/organizations/latest/userguide/orgs_manage_policies_backup_syntax.html) **Observação**: os backups transferidos para armazenamento “frio” devem ficar armazenados lá por no mínimo 90 dias. Isso significa que `delete_after_days` deve ser 90 dias maior que `move_to_cold_storage_after_days`. | Não |
| recovery\$1point\$1tags | Tags que você deseja atribuir aos recursos restaurados a partir do backup. Cada tag contém os seguintes elementos: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/organizations/latest/userguide/orgs_manage_policies_backup_syntax.html) | Não |
| index\$1actions | Especifica se AWS Backup cria um índice de backup dos seus snapshots do Amazon EBS e backups do Amazon S3 and/or . Os índices de backup são criados para pesquisar os metadados de seus backups. Para obter mais informações sobre criação de índice de backup e pesquisa de backup, consulte [Pesquisa de backup](https://docs.aws.amazon.com//aws-backup/latest/devguide/backup-search.html#backup-search-overview). **Observação:** [permissões adicionais de perfil do IAM](https://docs.aws.amazon.com//aws-backup/latest/devguide/backup-search.html#backup-search-access) são necessárias para a criação do índice de backup de snapshots do Amazon EBS. Cada ação de índice contém o seguinte elemento: `resource_types` em que os tipos de recursos compatíveis com a indexação são Amazon EBS e Amazon S3. Esse parâmetro especifica qual tipo de recurso será incluído na indexação. | Não |
| scan\$1actions | Especifica se uma ação de varredura está habilitada para uma determinada regra. Você deve especificar um`ScanMode`. Você deve usar `scan_settings` os elementos da política de backup em conjunto com `scan_actions` para que os trabalhos de digitalização sejam iniciados com êxito. Certifique-se também de ter as [permissões corretas de função do IAM](https://docs.aws.amazon.com//aws-backup/latest/devguide/malware-protection.html#malware-access). [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/organizations/latest/userguide/orgs_manage_policies_backup_syntax.html) | Não |
## Sintaxe de backup: regiões
A chave `regions` de política especifica o Regiões da AWS que deve AWS Backup ser examinado para encontrar os recursos que correspondem às condições na `selections` chave.
**Elementos de regiões de backup**
| Elemento | Description | Obrigatório |
| --- | --- | --- |
| regions | Especifica os Região da AWS códigos. Por exemplo: `["us-east-1", "eu-north-1"]`. | Sim |
## Sintaxe de backup: seleções
A chave de política `selections` especifica os recursos que são protegidos pelas regras em uma política de backup.
Existem dois elementos mutuamente exclusivos: `tags` e `resources`. Uma política eficaz **deve estar** marcada `have` ou ter `resources` na seleção para ser válida.
Se você quiser uma seleção com condições de tag e condições de recursos, use as chaves `resources`.
**Elementos de seleção de backup: tags**
| Elemento | Description | Obrigatório |
| --- | --- | --- |
| iam\$1role\$1arn | Função do IAM que AWS Backup pressupõe consultar, descobrir e fazer backup de recursos nas regiões especificadas. A função deve ter permissões suficientes para consultar recursos com base nas condições da tag e realizar operações de backup nos recursos correspondentes. | Sim |
| tag\$1key | Nome da tag chave a ser pesquisada. | Sim |
| tag\$1value | Valor que deve ser associado à tag\$1key correspondente. AWS Backup inclui o recurso somente se tag\$1key e tag\$1value corresponderem (diferencia maiúsculas de minúsculas). | Sim |
| conditions | Marque chaves e valores que você deseja incluir ou excluir Use string\$1equals ou string\$1not\$1equals para incluir ou excluir tags de uma correspondência exata. Use string\$1like e string\$1not\$1like para incluir ou excluir tags que contenham ou não caracteres específicos **Nota:** limitado a 30 condições para cada seleção. | Não |
**Elementos de seleção de backup: Recursos**
| Elemento | Description | Obrigatório |
| --- | --- | --- |
| iam\$1role\$1arn | Função do IAM que AWS Backup pressupõe consultar, descobrir e fazer backup de recursos nas regiões especificadas. A função deve ter permissões suficientes para consultar recursos com base nas condições da tag e realizar operações de backup nos recursos correspondentes. **Nota:** Em AWS GovCloud (US) Regions, você deve adicionar o nome da partição ao ARN. Por exemplo, “`arn:aws:ec2:*:*:volume/*`” deve ser “`arn:aws-us-gov:ec2:*:*:volume/*`”. | Sim |
| resource\$1types | Tipos de recursos a serem incluídos em um plano de backup. | Sim |
| not\$1resource\$1types | Tipos de recursos a serem excluídos de um plano de backup. | Não |
| conditions | Marque chaves e valores que você deseja incluir ou excluir Use string\$1equals ou string\$1not\$1equals para incluir ou excluir tags de uma correspondência exata. Use string\$1like e string\$1not\$1like para incluir ou excluir tags que contenham ou não caracteres específicos **Nota:** limitado a 30 condições para cada seleção. | Não |
**Tipos de recursos compatíveis**
O Organizations oferece suporte aos seguintes tipos de recursos para os elementos `resource_types` e `not_resource_types`:
+ AWS Backup gateway máquinas virtuais: `"arn:aws:backup-gateway:*:*:vm/*"`
+ AWS CloudFormation pilhas: `"arn:aws:cloudformation:*:*:stack/*"`
+ Tabelas do Amazon DynamoDB: `"arn:aws:dynamodb:*:*:table/*"`
+ Instâncias do Amazon EC2: `"arn:aws:ec2:*:*:instance/*"`
+ Volumes do Amazon EBS: `"arn:aws:ec2:*:*:volume/*"`
+ Sistemas de arquivos do Amazon EFS: `"arn:aws:elasticfilesystem:*:*:file-system/*"`
+ Clusters Amazon Aurora/Amazon DocumentDB/Amazon Neptune: `"arn:aws:rds:*:*:cluster:*"`
+ Bancos de dados do Amazon RDS: `"arn:aws:rds:*:*:db:*"`
+ Clusters do Amazon Redshift: `"arn:aws:redshift:*:*:cluster:*"`
+ Amazon S3: `"arn:aws:s3:::*"`
+ AWS Systems Manager para SAP Bancos de dados HANA: `"arn:aws:ssm-sap:*:*:HANA/*"`
+ AWS Storage Gateway gateways: `"arn:aws:storagegateway:*:*:gateway/*"`
+ Banco de dados do Amazon Timestream: `"arn:aws:timestream:*:*:database/*"`
+ Sistemas de FSx arquivos da Amazon: `"arn:aws:fsx:*:*:file-system/*"`
+ FSx Volumes da Amazon: `"arn:aws:fsx:*:*:volume/*"`
+ Volumes do Amazon Elastic Kubernetes Service: `"arn:aws:eks:*:*:cluster/*"`
**Exemplos de código**
Para obter mais informações, consulte [Especificar recursos com o bloco de tags](#backup-policy-example-6) e [Especificar recursos com o bloco de recursos](#backup-policy-example-7).
## Sintaxe de backup: configurações de backup avançadas
A chave `advanced_backup_settings` especifica as opções de configuração para cenários de backup específicos. Cada configuração contém os seguintes elementos:
**Elementos de configurações avançadas de backup**
| Elemento | Description | Obrigatório |
| --- | --- | --- |
| advanced\$1backup\$1settings | Especifica configurações para cenários de backup específicos. Esta chave contém uma ou mais configurações. Cada configuração é uma sequência de objeto JSON com os seguintes elementos: Atualmente, a única configuração de backup avançada compatível habilita os backups do Microsoft Volume Shadow Copy Service (VSS) para Windows ou SQL Server em execução em uma instância do Amazon EC2. Cada configuração de backup avançado tem os seguintes elementos: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/organizations/latest/userguide/orgs_manage_policies_backup_syntax.html) | Não |
**Exemplo:**
```
"advanced_backup_settings": {
"ec2": {
"windows_vss": {
"@@assign": "enabled"
}
}
},
```
## Sintaxe de backup: tags do plano de backup
A chave de política `backup_plan_tags` especifica as tags anexadas ao plano de backup propriamente dito. Isso não afeta as tags especificadas para `rules` ou `selections`.
**Elementos de tag do plano de backup**
| Elemento | Description | Obrigatório |
| --- | --- | --- |
| backup\$1plan\$1tags | Cada tag é um rótulo que consiste em um valor e uma chave definida pelo usuário: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/organizations/latest/userguide/orgs_manage_policies_backup_syntax.html) | Não |
## Sintaxe de backup: configurações de digitalização
A chave `scan_settings` de política especifica a configuração para verificação de malware usando o Amazon GuardDuty Malware Protection for AWS Backup. Você deve usar `scan_settings` em conjunto com `scan_actions` as regras de backup para que os trabalhos de digitalização sejam iniciados com êxito.
**Elementos de configurações de digit**
| Elemento | Description | Obrigatório |
| --- | --- | --- |
| scan\$1settings | Opções de configuração para configurações de digitalização. Atualmente, a única configuração de escaneamento compatível é habilitar o Amazon GuardDuty Malware Protection para AWS Backup. Você deve especificar o `ResourceTypes` `ScannerRoleArn` e. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/organizations/latest/userguide/orgs_manage_policies_backup_syntax.html) | Não |
**Exemplo:**
A seguir, mostramos como configurar `scan_actions` em uma regra de backup e `scan_settings` no nível do plano para habilitar a verificação do Amazon GuardDuty Malware Protection.
`scan_actions`em uma regra:
```
"scan_actions": {
"GUARDDUTY": {
"scan_mode": {
"@@assign": "INCREMENTAL_SCAN"
}
}
}
```
`scan_settings`no nível do plano:
```
"scan_settings": {
"GUARDDUTY": {
"resource_types": {
"@@assign": ["EBS"]
},
"scanner_role_arn": {
"@@assign": "arn:aws:iam::$account:role/MyGuardDutyScannerRole"
}
}
}
```
## Exemplos de políticas de backup
As políticas de backup no exemplo a seguir são apenas para fins informativos. Em alguns dos exemplos a seguir, a formatação de espaço em branco JSON pode ser compactada para economizar espaço.
+ [Exemplo 1: Política atribuída a um nó principal](#backup-policy-example-1)
+ [Exemplo 2: uma política principal é mesclada com uma política secundária](#backup-policy-example-2)
+ [Exemplo 3: Uma política para pais impede qualquer alteração feita por uma política para crianças](#backup-policy-example-3)
+ [Exemplo 4: Uma política principal impede alterações em um plano de backup por uma política secundária](#backup-policy-example-4)
+ [Exemplo 5: uma política secundária substitui as configurações em uma política principal](#backup-policy-example-5)
+ [Exemplo 6: especificar recursos com o bloco de tags](#backup-policy-example-6)
+ [Exemplo 7: especificar recursos com o bloco de recursos](#backup-policy-example-7)
+ [Exemplo 8: Plano de backup com escaneamento do Amazon GuardDuty Malware Protection](#backup-policy-example-8)
### Exemplo 1: Política atribuída a um nó pai
O exemplo a seguir mostra uma política de backup atribuída a um dos nós pai de uma conta.
**Política superior** – Esta política pode ser anexada à raiz da organização ou a qualquer UO que seja superior a todas as contas pretendidas.
```
{
"plans": {
"PII_Backup_Plan": {
"regions": {
"@@assign": [
"ap-northeast-2",
"us-east-1",
"eu-north-1"
]
},
"rules": {
"Hourly": {
"schedule_expression": {
"@@assign": "cron(0 5/1 ? * * *)"
},
"start_backup_window_minutes": {
"@@assign": "480"
},
"complete_backup_window_minutes": {
"@@assign": "10080"
},
"lifecycle": {
"move_to_cold_storage_after_days": {
"@@assign": "180"
},
"delete_after_days": {
"@@assign": "270"
},
"opt_in_to_archive_for_supported_resources": {
"@@assign": "false"
}
},
"target_backup_vault_name": {
"@@assign": "FortKnox"
},
"target_logically_air_gapped_backup_vault_arn": {
"@@assign": "arn:aws:backup:$region:$account:backup-vault:AirGappedVault"
},
"index_actions": {
"resource_types": {
"@@assign": [
"EBS",
"S3"
]
}
},
"copy_actions": {
"arn:aws:backup:us-east-1:$account:backup-vault:secondary_vault": {
"target_backup_vault_arn": {
"@@assign": "arn:aws:backup:us-east-1:$account:backup-vault:secondary_vault"
},
"lifecycle": {
"move_to_cold_storage_after_days": {
"@@assign": "30"
},
"delete_after_days": {
"@@assign": "120"
},
"opt_in_to_archive_for_supported_resources": {
"@@assign": "false"
}
}
},
"arn:aws:backup:us-west-1:111111111111:backup-vault:tertiary_vault": {
"target_backup_vault_arn": {
"@@assign": "arn:aws:backup:us-west-1:111111111111:backup-vault:tertiary_vault"
},
"lifecycle": {
"move_to_cold_storage_after_days": {
"@@assign": "30"
},
"delete_after_days": {
"@@assign": "120"
},
"opt_in_to_archive_for_supported_resources": {
"@@assign": "false"
}
}
}
}
}
},
"selections": {
"tags": {
"datatype": {
"iam_role_arn": {
"@@assign": "arn:aws:iam::$account:role/MyIamRole"
},
"tag_key": {
"@@assign": "dataType"
},
"tag_value": {
"@@assign": [
"PII",
"RED"
]
}
}
}
},
"advanced_backup_settings": {
"ec2": {
"windows_vss": {
"@@assign": "enabled"
}
}
}
}
}
}
```
Se nenhuma outra política for herdada ou anexada às contas, a política efetiva renderizada em cada política aplicável será Conta da AWS semelhante ao exemplo a seguir. A expressão CRON faz com que o backup seja executado uma vez por hora. O ID da conta 123456789012 será o ID de conta real para cada conta.
```
{
"plans": {
"PII_Backup_Plan": {
"regions": [
"us-east-1",
"ap-northeast-3",
"eu-north-1"
],
"rules": {
"hourly": {
"schedule_expression": "cron(0 0/1 ? * * *)",
"start_backup_window_minutes": "60",
"target_backup_vault_name": "FortKnox",
"target_logically_air_gapped_backup_vault_arn": "arn:aws:backup:$region:$account:backup-vault:AirGappedVault",
"index_actions": {
"resource_types": {
"@@assign": [
"EBS",
"S3"
]
}
},
"lifecycle": {
"delete_after_days": "2",
"move_to_cold_storage_after_days": "180",
"opt_in_to_archive_for_supported_resources": "false"
},
"copy_actions": {
"arn:aws:backup:us-east-1:$account:backup-vault:secondary_vault": {
"target_backup_vault_arn": {
"@@assign": "arn:aws:backup:us-east-1:$account:backup-vault:secondary_vault"
},
"lifecycle": {
"delete_after_days": "28",
"move_to_cold_storage_after_days": "180",
"opt_in_to_archive_for_supported_resources": "false"
}
},
"arn:aws:backup:us-west-1:111111111111:backup-vault:tertiary_vault": {
"target_backup_vault_arn": {
"@@assign": "arn:aws:backup:us-west-1:111111111111:backup-vault:tertiary_vault"
},
"lifecycle": {
"delete_after_days": "28",
"move_to_cold_storage_after_days": "180",
"opt_in_to_archive_for_supported_resources": "false"
}
}
}
}
},
"selections": {
"tags": {
"datatype": {
"iam_role_arn": "arn:aws:iam::123456789012:role/MyIamRole",
"tag_key": "dataType",
"tag_value": [
"PII",
"RED"
]
}
}
},
"advanced_backup_settings": {
"ec2": {
"windows_vss": "enabled"
}
}
}
}
}
```
### Exemplo 2: Uma política pai é mesclada com uma política filho
No exemplo a seguir, uma política principal herdada e uma política secundária herdadas ou diretamente associadas a uma Conta da AWS fusão para formar a política efetiva.
**Política superior** – Esta política pode ser anexada à raiz da organização ou a qualquer UO superior.
```
{
"plans": {
"PII_Backup_Plan": {
"regions": { "@@append":[ "us-east-1", "ap-northeast-3", "eu-north-1" ] },
"rules": {
"Hourly": {
"schedule_expression": { "@@assign": "cron(0 0/1 ? * * *)" },
"start_backup_window_minutes": { "@@assign": "60" },
"target_backup_vault_name": { "@@assign": "FortKnox" },
"index_actions": {
"resource_types": {
"@@assign": [
"EBS",
"S3"
]
}
},
"lifecycle": {
"move_to_cold_storage_after_days": { "@@assign": "28" },
"delete_after_days": { "@@assign": "180" },
"opt_in_to_archive_for_supported_resources": { "@@assign": "false" }
},
"copy_actions": {
"arn:aws:backup:us-east-1:$account:backup-vault:secondary_vault" : {
"target_backup_vault_arn" : {
"@@assign" : "arn:aws:backup:us-east-1:$account:backup-vault:secondary_vault"
},
"lifecycle": {
"move_to_cold_storage_after_days": { "@@assign": "28" },
"delete_after_days": { "@@assign": "180" },
"opt_in_to_archive_for_supported_resources": { "@@assign": "false" }
}
}
}
}
},
"selections": {
"tags": {
"datatype": {
"iam_role_arn": { "@@assign": "arn:aws:iam::$account:role/MyIamRole" },
"tag_key": { "@@assign": "dataType" },
"tag_value": { "@@assign": [ "PII", "RED" ] }
}
}
}
}
}
}
```
**Política subordinada** – Esta política pode ser anexada diretamente à conta ou a uma UO em qualquer nível abaixo daquele ao qual a política superior está anexada.
```
{
"plans": {
"Monthly_Backup_Plan": {
"regions": {
"@@append":[ "us-east-1", "eu-central-1" ] },
"rules": {
"Monthly": {
"schedule_expression": { "@@assign": "cron(0 5 1 * ? *)" },
"start_backup_window_minutes": { "@@assign": "480" },
"target_backup_vault_name": { "@@assign": "Default" },
"lifecycle": {
"move_to_cold_storage_after_days": { "@@assign": "30" },
"delete_after_days": { "@@assign": "365" },
"opt_in_to_archive_for_supported_resources": { "@@assign": "false" }
},
"copy_actions": {
"arn:aws:backup:us-east-1:$account:backup-vault:Default" : {
"target_backup_vault_arn" : {
"@@assign" : "arn:aws:backup:us-east-1:$account:backup-vault:Default"
},
"lifecycle": {
"move_to_cold_storage_after_days": { "@@assign": "30" },
"delete_after_days": { "@@assign": "365" },
"opt_in_to_archive_for_supported_resources": { "@@assign": "false" }
}
}
}
}
},
"selections": {
"tags": {
"MonthlyDatatype": {
"iam_role_arn": { "@@assign": "arn:aws:iam::$account:role/MyMonthlyBackupIamRole" },
"tag_key": { "@@assign": "BackupType" },
"tag_value": { "@@assign": [ "MONTHLY", "RED" ] }
}
}
}
}
}
}
```
**Política em vigor resultante** – A política em vigor aplicada às contas contém dois planos, cada um com o seu próprio conjunto de regras e conjunto de recursos aos quais as regras devem ser aplicadas.
```
{
"plans": {
"PII_Backup_Plan": {
"regions": [ "us-east-1", "ap-northeast-3", "eu-north-1" ],
"rules": {
"hourly": {
"schedule_expression": "cron(0 0/1 ? * * *)",
"start_backup_window_minutes": "60",
"target_backup_vault_name": "FortKnox",
"index_actions": {
"resource_types": {
"@@assign": [
"EBS",
"S3"
]
}
},
"lifecycle": {
"delete_after_days": "2",
"move_to_cold_storage_after_days": "180",
"opt_in_to_archive_for_supported_resources": { "@@assign": "false" }
},
"copy_actions": {
"arn:aws:backup:us-east-1:$account:backup-vault:secondary_vault" : {
"target_backup_vault_arn" : {
"@@assign" : "arn:aws:backup:us-east-1:$account:backup-vault:secondary_vault"
},
"lifecycle": {
"move_to_cold_storage_after_days": "28",
"delete_after_days": "180",
"opt_in_to_archive_for_supported_resources": { "@@assign": "false" }
}
}
}
}
},
"selections": {
"tags": {
"datatype": {
"iam_role_arn": "arn:aws:iam::$account:role/MyIamRole",
"tag_key": "dataType",
"tag_value": [ "PII", "RED" ]
}
}
}
},
"Monthly_Backup_Plan": {
"regions": [ "us-east-1", "eu-central-1" ],
"rules": {
"monthly": {
"schedule_expression": "cron(0 5 1 * ? *)",
"start_backup_window_minutes": "480",
"target_backup_vault_name": "Default",
"lifecycle": {
"delete_after_days": "365",
"move_to_cold_storage_after_days": "30",
"opt_in_to_archive_for_supported_resources": { "@@assign": "false" }
},
"copy_actions": {
"arn:aws:backup:us-east-1:$account:backup-vault:Default" : {
"target_backup_vault_arn": {
"@@assign" : "arn:aws:backup:us-east-1:$account:backup-vault:Default"
},
"lifecycle": {
"move_to_cold_storage_after_days": "30",
"delete_after_days": "365",
"opt_in_to_archive_for_supported_resources": { "@@assign": "false" }
}
}
}
}
},
"selections": {
"tags": {
"monthlydatatype": {
"iam_role_arn": "arn:aws:iam::&ExampleAWSAccountNo3;:role/MyMonthlyBackupIamRole",
"tag_key": "BackupType",
"tag_value": [ "MONTHLY", "RED" ]
}
}
}
}
}
}
```
### Exemplo 3: Uma política pai impede quaisquer alterações por uma política filho
No exemplo a seguir, uma política pai herdada usa os [operadores de controle filho](policy-operators.md#child-control-operators) para impor todas as configurações e impede que elas sejam alteradas ou substituídas por uma política filho.
**Política superior** – Esta política pode ser anexada à raiz da organização ou a qualquer UO superior. A presença de `"@@operators_allowed_for_child_policies": ["@@none"]` em cada nó da política significa que uma política filho não pode fazer alterações de nenhum tipo no plano. Uma política filho também não pode adicionar planos extras à política efetiva. Essa política se torna a política efetiva para cada UO e conta sob a UO à qual ela está anexada.
```
{
"plans": {
"@@operators_allowed_for_child_policies": ["@@none"],
"PII_Backup_Plan": {
"@@operators_allowed_for_child_policies": ["@@none"],
"regions": {
"@@operators_allowed_for_child_policies": ["@@none"],
"@@append": [
"us-east-1",
"ap-northeast-3",
"eu-north-1"
]
},
"rules": {
"@@operators_allowed_for_child_policies": ["@@none"],
"Hourly": {
"@@operators_allowed_for_child_policies": ["@@none"],
"schedule_expression": {
"@@operators_allowed_for_child_policies": ["@@none"],
"@@assign": "cron(0 0/1 ? * * *)"
},
"start_backup_window_minutes": {
"@@operators_allowed_for_child_policies": ["@@none"],
"@@assign": "60"
},
"target_backup_vault_name": {
"@@operators_allowed_for_child_policies": ["@@none"],
"@@assign": "FortKnox"
},
"index_actions": {
"@@operators_allowed_for_child_policies": ["@@none"],
"resource_types": {
"@@assign": [
"EBS",
"S3"
]
}
},
"lifecycle": {
"@@operators_allowed_for_child_policies": ["@@none"],
"move_to_cold_storage_after_days": {
"@@operators_allowed_for_child_policies": ["@@none"],
"@@assign": "28"
},
"delete_after_days": {
"@@operators_allowed_for_child_policies": ["@@none"],
"@@assign": "180"
},
"opt_in_to_archive_for_supported_resources": {
"@@operators_allowed_for_child_policies": ["@@none"],
"@@assign": "false"
}
},
"copy_actions": {
"@@operators_allowed_for_child_policies": ["@@none"],
"arn:aws:backup:us-east-1:$account:backup-vault:secondary_vault": {
"@@operators_allowed_for_child_policies": ["@@none"],
"target_backup_vault_arn": {
"@@assign": "arn:aws:backup:us-east-1:$account:backup-vault:secondary_vault",
"@@operators_allowed_for_child_policies": ["@@none"]
},
"lifecycle": {
"@@operators_allowed_for_child_policies": ["@@none"],
"delete_after_days": {
"@@operators_allowed_for_child_policies": ["@@none"],
"@@assign": "28"
},
"move_to_cold_storage_after_days": {
"@@operators_allowed_for_child_policies": ["@@none"],
"@@assign": "180"
},
"opt_in_to_archive_for_supported_resources": {
"@@operators_allowed_for_child_policies": ["@@none"],
"@@assign": "false"
}
}
}
}
}
},
"selections": {
"@@operators_allowed_for_child_policies": ["@@none"],
"tags": {
"@@operators_allowed_for_child_policies": ["@@none"],
"datatype": {
"@@operators_allowed_for_child_policies": ["@@none"],
"iam_role_arn": {
"@@operators_allowed_for_child_policies": ["@@none"],
"@@assign": "arn:aws:iam::$account:role/MyIamRole"
},
"tag_key": {
"@@operators_allowed_for_child_policies": ["@@none"],
"@@assign": "dataType"
},
"tag_value": {
"@@operators_allowed_for_child_policies": ["@@none"],
"@@assign": [
"PII",
"RED"
]
}
}
}
},
"advanced_backup_settings": {
"@@operators_allowed_for_child_policies": ["@@none"],
"ec2": {
"@@operators_allowed_for_child_policies": ["@@none"],
"windows_vss": {
"@@assign": "enabled",
"@@operators_allowed_for_child_policies": ["@@none"]
}
}
}
}
}
}
```
**Política em vigor resultante** Se existirem políticas de backup subordinadas, elas serão ignoradas e a política superior se tornará a política em vigor.
```
{
"plans": {
"PII_Backup_Plan": {
"regions": [
"us-east-1",
"ap-northeast-3",
"eu-north-1"
],
"rules": {
"hourly": {
"schedule_expression": "cron(0 0/1 ? * * *)",
"start_backup_window_minutes": "60",
"target_backup_vault_name": "FortKnox",
"index_actions": {
"resource_types": {
"@@assign": [
"EBS",
"S3"
]
}
},
"lifecycle": {
"delete_after_days": "2",
"move_to_cold_storage_after_days": "180",
"opt_in_to_archive_for_supported_resources": "false"
},
"copy_actions": {
"target_backup_vault_arn": "arn:aws:backup:us-east-1:123456789012:backup-vault:secondary_vault",
"lifecycle": {
"move_to_cold_storage_after_days": "28",
"delete_after_days": "180",
"opt_in_to_archive_for_supported_resources": "false"
}
}
}
},
"selections": {
"tags": {
"datatype": {
"iam_role_arn": "arn:aws:iam::123456789012:role/MyIamRole",
"tag_key": "dataType",
"tag_value": [
"PII",
"RED"
]
}
}
},
"advanced_backup_settings": {
"ec2": {"windows_vss": "enabled"}
}
}
}
}
```
### Exemplo 4: Uma política pai impede alterações em um plano de backup por uma política filho
No exemplo a seguir, uma política pai herdada usa os [operadores de controle filho](policy-operators.md#child-control-operators) para impor as configurações para um único plano e impede que elas sejam alteradas ou substituídas por uma política filho. A política filho ainda pode adicionar planos extras.
**Política superior** – Esta política pode ser anexada à raiz da organização ou a qualquer UO superior. Este exemplo é semelhante ao exemplo anterior com todos os operadores de herança filho bloqueados, exceto no nível superior dos `plans`. A configuração `@@append` nesse nível permite que as políticas filho adicionem outros planos à coleção na política efetiva. Quaisquer alterações ao plano herdado ainda são bloqueadas.
As seções do plano estão truncadas para maior clareza.
```
{
"plans": {
"@@operators_allowed_for_child_policies": ["@@append"],
"PII_Backup_Plan": {
"@@operators_allowed_for_child_policies": ["@@none"],
"regions": { ... },
"rules": { ... },
"selections": { ... }
}
}
}
```
**Política subordinada** – Esta política pode ser anexada diretamente à conta ou a uma UO em qualquer nível abaixo daquele ao qual a política superior está anexada. Esta política filho define um novo plano.
As seções do plano estão truncadas para maior clareza.
```
{
"plans": {
"MonthlyBackupPlan": {
"regions": { ... },
"rules": { ... },
"selections": { … }
}
}
}
```
**Política em vigor resultante** – A política em vigor inclui ambos os planos.
```
{
"plans": {
"PII_Backup_Plan": {
"regions": { ... },
"rules": { ... },
"selections": { ... }
},
"MonthlyBackupPlan": {
"regions": { ... },
"rules": { ... },
"selections": { … }
}
}
}
```
### Exemplo 5: Uma política filho substitui as configurações numa política pai
No exemplo a seguir, uma política subordinada usa [operadores de definição de valor](policy-operators.md#value-setting-operators) para substituir algumas das configurações herdadas de uma política superior.
**Política superior** – Esta política pode ser anexada à raiz da organização ou a qualquer UO superior. Qualquer uma das configurações pode ser substituída por uma política filho porque o comportamento padrão, na ausência de um [operador de controle filho](policy-operators.md#child-control-operators) que o impede, é permitir a política filho para `@@assign`, `@@append`, ou `@@remove`. A política pai contém todos os elementos necessários para um plano de backup válido; portanto, ele faz backup de seus recursos com êxito se for herdado como está.
```
{
"plans": {
"PII_Backup_Plan": {
"regions": {
"@@append": [
"us-east-1",
"ap-northeast-3",
"eu-north-1"
]
},
"rules": {
"Hourly": {
"schedule_expression": {"@@assign": "cron(0 0/1 ? * * *)"},
"start_backup_window_minutes": {"@@assign": "60"},
"target_backup_vault_name": {"@@assign": "FortKnox"},
"index_actions": {
"resource_types": {
"@@assign": [
"EBS",
"S3"
]
}
},
"lifecycle": {
"delete_after_days": {"@@assign": "2"},
"move_to_cold_storage_after_days": {"@@assign": "180"},
"opt_in_to_archive_for_supported_resources": {"@@assign": false}
},
"copy_actions": {
"arn:aws:backup:us-east-1:$account:backup-vault:t2": {
"target_backup_vault_arn": {"@@assign": "arn:aws:backup:us-east-1:$account:backup-vault:t2"},
"lifecycle": {
"move_to_cold_storage_after_days": {"@@assign": "28"},
"delete_after_days": {"@@assign": "180"},
"opt_in_to_archive_for_supported_resources": {"@@assign": false}
}
}
}
}
},
"selections": {
"tags": {
"datatype": {
"iam_role_arn": {"@@assign": "arn:aws:iam::$account:role/MyIamRole"},
"tag_key": {"@@assign": "dataType"},
"tag_value": {
"@@assign": [
"PII",
"RED"
]
}
}
}
}
}
}
}
```
**Política subordinada** – A política subordinada inclui apenas as configurações que precisam ser diferentes da política superior herdada. Deve haver uma política superior herdada que forneça as outras configurações necessárias quando mescladas em uma política em vigor. Caso contrário, a política de backup em vigor contém um plano de backup inválido que não fará backup de seus recursos conforme o esperado.
```
{
"plans": {
"PII_Backup_Plan": {
"regions": {
"@@assign": [
"us-west-2",
"eu-central-1"
]
},
"rules": {
"Hourly": {
"schedule_expression": {"@@assign": "cron(0 0/2 ? * * *)"},
"start_backup_window_minutes": {"@@assign": "80"},
"target_backup_vault_name": {"@@assign": "Default"},
"lifecycle": {
"move_to_cold_storage_after_days": {"@@assign": "30"},
"delete_after_days": {"@@assign": "365"},
"opt_in_to_archive_for_supported_resources": {"@@assign": false}
}
}
}
}
}
}
```
**Política em vigor resultante** – A política em vigor inclui configurações de ambas as políticas, com as configurações fornecidas pela política subordinada substituindo as configurações herdadas da superior. Neste exemplo, ocorrem as seguintes alterações:
+ A lista de regiões é substituída por uma lista completamente diferente. Se você quiser adicionar uma região à lista herdada, consulte `@@append` em vez de `@@assign` na política subordinada.
+ AWS Backup executa a cada duas horas, em vez de a cada hora.
+ AWS Backup permite 80 minutos para que o backup seja iniciado em vez de 60 minutos.
+ AWS Backup usa o `Default` cofre em vez de. `FortKnox`
+ O ciclo de vida é estendido tanto para a transferência para o armazenamento frio quanto para a eventual exclusão do backup.
```
{
"plans": {
"PII_Backup_Plan": {
"regions": [
"us-west-2",
"eu-central-1"
],
"rules": {
"hourly": {
"schedule_expression": "cron(0 0/2 ? * * *)",
"start_backup_window_minutes": "80",
"target_backup_vault_name": "Default",
"index_actions": {
"resource_types": {
"@@assign": [
"EBS",
"S3"
]
}
},
"lifecycle": {
"delete_after_days": "365",
"move_to_cold_storage_after_days": "30",
"opt_in_to_archive_for_supported_resources": "false"
},
"copy_actions": {
"arn:aws:backup:us-east-1:$account:backup-vault:secondary_vault": {
"target_backup_vault_arn": {"@@assign": "arn:aws:backup:us-east-1:$account:backup-vault:secondary_vault"},
"lifecycle": {
"move_to_cold_storage_after_days": "28",
"delete_after_days": "180",
"opt_in_to_archive_for_supported_resources": "false"
}
}
}
}
},
"selections": {
"tags": {
"datatype": {
"iam_role_arn": "arn:aws:iam::$account:role/MyIamRole",
"tag_key": "dataType",
"tag_value": [
"PII",
"RED"
]
}
}
}
}
}
}
```
### Exemplo 6: especificar recursos com o bloco de `tags`
O exemplo a seguir inclui todos os recursos com `tag_key` = `“env”` e `tag_value` = `"prod"` ou`"gamma"`. Este exemplo exclui recursos com o `tag_key` = `"backup"` e o `tag_value` =`"false"`.
```
...
"selections":{
"tags":{
"selection_name":{
"iam_role_arn": {"@@assign": "arn:aws:iam::$account:role/IAMRole"},
"tag_key":{"@@assign": "env"},
"tag_value":{"@@assign": ["prod", "gamma"]},
"conditions":{
"string_not_equals":{
"condition_name1":{
"condition_key": { "@@assign": "aws:ResourceTag/backup" },
"condition_value": { "@@assign": "false" }
}
}
}
}
}
},
...
```
### Exemplo 7: especificar recursos com o bloco de `resources`
Veja a seguir exemplos do uso do bloco de `resources` para especificar recursos.
------
#### [ Example: Select all resources in my account ]
A lógica booleana é semelhante à que você pode usar nas políticas do IAM. O bloco de `"resource_types"` usa um booleano `AND` para combinar os tipos de recursos.
```
...
"resources":{
"resource_selection_name":{
"iam_role_arn":{"@@assign": "arn:aws:iam::$account:role/IAMRole"},
"resource_types":{
"@@assign": [
"*"
]
}
}
},
...
```
------
#### [ Example: Select all resources in my account, but exclude Amazon EBS volumes ]
A lógica booleana é semelhante à que você pode usar nas políticas do IAM. Os blocos `"resource_types"` e `"not_resource_types"` usam um booleano `AND` para combinar os tipos de recursos.
```
...
"resources":{
"resource_selection_name":{
"iam_role_arn":{"@@assign": "arn:aws:iam::$account:role/IAMRole"},
"resource_types":{
"@@assign": [
"*"
]
},
"not_resource_types":{
"@@assign": [
"arn:aws:ec2:*:*:volume/*"
]
}
}
},
...
```
------
#### [ Example: Select all resources tagged with "backup" : "true", but exclude Amazon EBS volumes ]
A lógica booleana é semelhante à que você pode usar nas políticas do IAM. Os blocos `"resource_types"` e `"not_resource_types"` usam um booleano `AND` para combinar os tipos de recursos. O bloco `"conditions"` usa um booleano `AND`.
```
...
"resources":{
"resource_selection_name":{
"iam_role_arn":{"@@assign": "arn:aws:iam::$account:role/IAMRole"},
"resource_types":{
"@@assign": [
"*"
]
},
"not_resource_types":{
"@@assign": [
"arn:aws:ec2:*:*:volume/*"
]
},
"conditions":{
"string_equals":{
"condition_name1":{
"condition_key": { "@@assign":"aws:ResourceTag/backup"},
"condition_value": { "@@assign":"true" }
}
}
}
}
},
...
```
------
#### [ Example: Select all Amazon EBS volumes and Amazon RDS DB instances tagged with both "backup" : "true" and "stage" : "prod" ]
A lógica booleana é semelhante à que você pode usar nas políticas do IAM. O bloco de `"resource_types"` usa um booleano `AND` para combinar os tipos de recursos. O bloco `"conditions"` usa um booleano `AND` para combinar tipos de recursos e condições de tag.
```
...
"resources":{
"resource_selection_name":{
"iam_role_arn":{"@@assign": "arn:aws:iam::$account:role/IAMRole"},
"resource_types":{
"@@assign": [
"arn:aws:ec2:*:*:volume/*",
"arn:aws:rds:*:*:db:*"
]
},
"conditions":{
"string_equals":{
"condition_name1":{
"condition_key":{"@@assign":"aws:ResourceTag/backup"},
"condition_value":{"@@assign":"true"}
},
"condition_name2":{
"condition_key":{"@@assign":"aws:ResourceTag/stage"},
"condition_value":{"@@assign":"prod"}
}
}
}
}
},
...
```
------
#### [ Example: Select all Amazon EBS volumes and Amazon RDS instances tagged with "backup" : "true" but not "stage" : "test" ]
A lógica booleana é semelhante à que você pode usar nas políticas do IAM. O bloco de `"resource_types"` usa um booleano `AND` para combinar os tipos de recursos. O bloco `"conditions"` usa um booleano `AND` para combinar tipos de recursos e condições de tag.
```
...
"resources":{
"resource_selection_name":{
"iam_role_arn":{"@@assign": "arn:aws:iam::$account:role/IAMRole"},
"resource_types":{
"@@assign": [
"arn:aws:ec2:*:*:volume/*",
"arn:aws:rds:*:*:db:*"
]
},
"conditions":{
"string_equals":{
"condition_name1":{
"condition_key":{"@@assign":"aws:ResourceTag/backup"},
"condition_value":{"@@assign":"true"}
}
},
"string_not_equals":{
"condition_name2":{
"condition_key":{"@@assign":"aws:ResourceTag/stage"},
"condition_value":{"@@assign":"test"}
}
}
}
}
},
...
```
------
#### [ Example: Select all resources tagged with "key1" and a value which begins with "include" but not with "key2" and value that contains the word "exclude" ]
A lógica booleana é semelhante à que você pode usar nas políticas do IAM. O bloco de `"resource_types"` usa um booleano `AND` para combinar os tipos de recursos. O bloco `"conditions"` usa um booleano `AND` para combinar tipos de recursos e condições de tag.
Neste exemplo, observe o uso do caractere curinga `(*)` em `include*`, `*exclude*` e `arn:aws:rds:*:*:db:*`. Você pode usar o caractere curinga `(*)` no início, no final e no meio de uma string.
```
...
"resources":{
"resource_selection_name":{
"iam_role_arn":{"@@assign": "arn:aws:iam::$account:role/IAMRole"},
"resource_types":{
"@@assign": [
"*"
]
},
"conditions":{
"string_like":{
"condition_name1":{
"condition_key":{"@@assign":"aws:ResourceTag/key1"},
"condition_value":{"@@assign":"include*"}
}
},
"string_not_like":{
"condition_name2":{
"condition_key":{"@@assign":"aws:ResourceTag/key2"},
"condition_value":{"@@assign":"*exclude*"}
}
}
}
}
},
...
```
------
#### [ Example: Select all resources tagged with "backup" : "true" except Amazon FSx file systems and Amazon RDS resources ]
A lógica booleana é semelhante à que você pode usar nas políticas do IAM. Os blocos `"resource_types"` e `"not_resource_types"` usam um booleano `AND` para combinar os tipos de recursos. O bloco `"conditions"` usa um booleano `AND` para combinar tipos de recursos e condições de tag.
```
...
"resources":{
"resource_selection_name":{
"iam_role_arn":{"@@assign": "arn:aws:iam::$account:role/IAMRole"},
"resource_types":{
"@@assign": [
"*"
]
},
"not_resource_types":{
"@@assign":[
"arn:aws:fsx:*:*:file-system/*",
"arn:aws:rds:*:*:db:*"
]
},
"conditions":{
"string_equals":{
"condition_name1":{
"condition_key":{"@@assign":"aws:ResourceTag/backup"},
"condition_value":{"@@assign":"true"}
}
}
}
}
},
...
```
------
### Exemplo 8: Plano de backup com escaneamento do Amazon GuardDuty Malware Protection
O exemplo a seguir mostra uma política de backup que permite que o Amazon GuardDuty Malware Protection escaneie pontos de recuperação de backup. A política é usada `scan_actions` na regra para habilitar a digitalização e`scan_settings`, no nível do plano, para configurar o scanner.
Para usar esse recurso, você precisa ter as permissões de função do IAM apropriadas. Para obter mais informações, consulte [Access](https://docs.aws.amazon.com//aws-backup/latest/devguide/malware-protection.html#malware-access) no *Guia do AWS Backup desenvolvedor*.
```
{
"plans": {
"Malware_Scan_Backup_Plan": {
"regions": {
"@@assign": [
"us-east-1",
"us-west-2"
]
},
"rules": {
"Daily_With_Incremental_Scan": {
"schedule_expression": {
"@@assign": "cron(0 5 ? * * *)"
},
"start_backup_window_minutes": {
"@@assign": "60"
},
"target_backup_vault_name": {
"@@assign": "Default"
},
"lifecycle": {
"delete_after_days": {
"@@assign": "35"
}
},
"scan_actions": {
"GUARDDUTY": {
"scan_mode": {
"@@assign": "INCREMENTAL_SCAN"
}
}
}
},
"Monthly_With_Full_Scan": {
"schedule_expression": {
"@@assign": "cron(0 5 1 * ? *)"
},
"start_backup_window_minutes": {
"@@assign": "60"
},
"target_backup_vault_name": {
"@@assign": "Default"
},
"lifecycle": {
"delete_after_days": {
"@@assign": "365"
}
},
"scan_actions": {
"GUARDDUTY": {
"scan_mode": {
"@@assign": "FULL_SCAN"
}
}
}
}
},
"selections": {
"tags": {
"scan_selection": {
"iam_role_arn": {
"@@assign": "arn:aws:iam::$account:role/MyBackupRole"
},
"tag_key": {
"@@assign": "backup"
},
"tag_value": {
"@@assign": [
"true"
]
}
}
}
},
"scan_settings": {
"GUARDDUTY": {
"resource_types": {
"@@assign": [
"EBS"
]
},
"scanner_role_arn": {
"@@assign": "arn:aws:iam::$account:role/MyGuardDutyScannerRole"
}
}
}
}
}
}
```
Os pontos-chave neste exemplo são:
+ `scan_actions`é especificado dentro de cada regra. O nome do scanner `GUARDDUTY` é usado como chave. Os usos da regra diária `INCREMENTAL_SCAN` e os usos da regra mensal`FULL_SCAN`.
+ `scan_settings`é especificado no nível do plano (não dentro de uma regra). Ele configura a função do scanner e os tipos de recursos a serem escaneados.
+ Eles `scanner_role_arn` devem referenciar uma função do IAM com a política `AWSBackupGuardDutyRolePolicyForScans` gerenciada anexada e uma política de confiança que permita que o diretor do `malware-protection.guardduty.amazonaws.com` serviço assuma a função.
# Políticas de tag
As políticas de tags permitem que você padronize as tags anexadas aos AWS recursos nas contas da sua organização.
Você pode usar políticas de tag para manter tags consistentes, incluindo o tratamento preferencial de maiúsculas e minúsculas de chaves e valores de tag.
## O que são tags?
As *tags* são rótulos de atributos personalizados que você atribui ou AWS atribui aos AWS recursos. Cada tag da tem duas partes:
+ Uma *chave de tag* (por exemplo `CostCenter`, `Environment` ou `Project`). Chaves de tag fazem distinção entre maiúsculas e minúsculas.
+ Um campo opcional conhecido como um *valor de tag* (por exemplo, `111122223333` ou `Production`). Omitir o valor da tag é o mesmo que usar uma string vazia. Assim como as chaves de tag, os valores de tag diferenciam maiúsculas de minúsculas.
O restante desta página descreve as políticas de tag. Para obter mais informações sobre tags, consulte os tópicos a seguir:
+ Para obter informações gerais sobre marcação, incluindo convenções de nomenclatura e uso, consulte o Guia do usuário de recursos de [https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html).
+ Para obter uma lista de serviços que oferecem suporte à atribuição de tags, consulte a [https://docs.aws.amazon.com/resourcegroupstagging/latest/APIReference/Welcome.html](https://docs.aws.amazon.com/resourcegroupstagging/latest/APIReference/Welcome.html).
+ Para obter informações sobre o uso de tags para categorizar recursos, consulte o whitepaper sobre [https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html).
+ Para obter informações sobre a atribuição de tags a recursos de Organizations, consulte [Recursos de marcação AWS OrganizationsConsiderações](orgs_tagging.md).
+ Para obter informações sobre como marcar recursos em outros Serviços da AWS, consulte a documentação desse serviço.
## O que são políticas de tag?
As*políticas de tag* são um tipo de política que pode ajuda você a padronizar tags entre recursos nas contas da organização. Em uma política de tags, você especifica regras de atribuição de tags aplicáveis aos recursos quando eles contêm tags.
Por exemplo, uma política de tag pode especificar que, quando a tag `CostCenter` é anexada a um recurso, ela deve usar o tratamento de maiúsculas e minúsculas e os valores de tag definidos pela política de tag. Uma política de tags também pode definir que operações de atribuição de tags não compatíveis em tipos de recursos especificados sejam *aplicadas*. Em outras palavras, solicitações de atribuição de tags não compatíveis em tipos de recursos especificados são impedidas de serem concluídas. Os recursos sem tag ou as tags que não são definidas na política de tags não são avaliados quanto à conformidade com a política de tags.
O uso de políticas de tags envolve trabalhar com vários Serviços da AWS:
+ Use o **AWS Organizations** para gerenciar as *políticas de tag*. Quando faz login na conta gerencial da organização, você pode usar o Organizations para habilitar o recurso de políticas de tag. Você deve fazer login como um usuário do IAM, assumir um perfil do IAM ou fazer login como usuário root ([não recomendado](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)) na conta gerencial da organização. Em seguida, você pode criar políticas de tag e anexá-las às entidades da organização a fim de colocar essas regras de atribuição de tags em vigor.
+ Use a **AWS Resource Groups** para gerenciar a *conformidade* com as políticas de tag. Quando faz login em uma conta de sua organização, você pode usar o Resource Groups para localizar tags não compatíveis nos recursos na conta. Você pode corrigir tags não compatíveis no AWS serviço em que criou o recurso. Você também pode usar o [Tag Editor](https://docs.aws.amazon.com/tag-editor/latest/userguide/tag-editor.html) e a API [Resource Groups Tagging](https://docs.aws.amazon.com/resourcegroupstagging/latest/APIReference/overview.html) para marcar e desmarcar recursos de vários serviços.
Se você fizer login na conta gerencial de sua organização, poderá exibir informações de compatibilidade para todas as contas da organização.
As políticas de tag estão disponíveis apenas em uma organização com [todos os recursos habilitados](orgs_manage_org_support-all-features.md). Para obter mais informações sobre o que é necessário para usar políticas de tag, consulte [Pré-requisitos e permissões para políticas de gerenciamento para AWS Organizations](orgs_manage_policies_prereqs.md).
**Importante**
Para começar com as políticas de tags, é AWS altamente recomendável que você siga o exemplo de fluxo de trabalho descrito em [Conceitos básicos das políticas de tag](orgs_manage_policies_tag-policies-getting-started.md) antes de passar para políticas de tags mais avançadas. É melhor entender os efeitos de anexar uma política de tags simples a uma única conta antes de expandir as políticas de tag para uma UO ou organização inteira. É especialmente importante compreender os efeitos de uma política de tag antes de *aplicar* a conformidade com qualquer política de tag. As tabelas na página [Conceitos básicos das políticas de tag](orgs_manage_policies_tag-policies-getting-started.md) também fornecem links para instruções sobre tarefas relacionadas a políticas mais avançadas.
# Práticas recomendadas para usar políticas de tag
AWS recomenda as seguintes práticas recomendadas para o uso de políticas de tags.
## Decida sobre uma estratégia de capitalização de tag
Determine como você deseja usar maiúsculas e minúsculas nas tags e implemente consistentemente essa estratégia em todos os tipos de recursos. Por exemplo, decida se deseja usar `Costcenter`, `costcenter` ou `CostCenter` e use a mesma convenção para todas as tags. Para obter resultados consistentes em relatórios de conformidade, evite usar tags semelhantes com tratamento inconsistente de maiúsculas e minúsculas. Essa estratégia ajudará você a definir as políticas de tag da organização.
## Use o fluxo de trabalho recomendado
Comece de baixo criando uma política de tags simples. Em seguida, anexe-a a uma conta-membro que você pode usar para fins de teste. Use os fluxos de trabalho descritos em [Conceitos básicos das políticas de tag](orgs_manage_policies_tag-policies-getting-started.md).
## Determine regras de marcação
Isso dependerá das necessidades da organização. Por exemplo, talvez você queira especificar que, quando uma `CostCenter` tag é anexada a AWS Secrets Manager segredos, ela deve usar o tratamento de caso especificado. Crie políticas de tag que definam tags compatíveis e as anexe às entidades da organização nas quais você deseja que essas regras de atribuição de tags estejam em vigor.
## Eduque os administradores de contas
Quando estiver pronto para expandir o uso das políticas de tag, instrua os administradores de contas da seguinte forma:
+ Comunique sua estratégia de atribuição de tags.
+ Enfatize que os administradores precisam usar tags em tipos de recursos específicos.
Isso é importante, pois os recursos sem tags não são mostrados como incompatíveis nos resultados de conformidade.
+ Fornecer orientações sobre como verificar a conformidade com as políticas de tag. *Instrua os administradores a encontrar e corrigir tags não compatíveis em recursos em suas contas usando o procedimento descrito em [Avaliação da conformidade de uma conta no Guia do usuário de](https://docs.aws.amazon.com/tag-editor/latest/userguide/tag-policies-orgs-finding-noncompliant-tags.html) recursos de marcação. AWS * Informe-os com que frequência você quer que eles verifiquem a conformidade.
## Esteja atento ao aplicar a conformidade.
A aplicação da conformidade pode impedir que os usuários nas contas da organização atribuam tags aos recursos necessários. Primeiramente, revise as informações em [Imponha a consistência da marcação](orgs_manage_policies_tag-policies-enforcement.md). Consulte também os fluxos de trabalho descritos em [Conceitos básicos das políticas de tag](orgs_manage_policies_tag-policies-getting-started.md).
## Esteja ciente dos limites de marcação
AWS os serviços geralmente têm um limite de 50 tags definidas pelo usuário que não podem ser modificadas. Ao usar recursos como Denunciar tags obrigatórias, garanta que as políticas efetivas de sua organização não excedam 50 tags obrigatórias para qualquer tipo de recurso. Exceder esse limite pode causar dois problemas: os recursos podem não conseguir atingir o status de conformidade nos resumos de conformidade e as plataformas de Infraestrutura como Código (IaC) podem falhar na criação de recursos quando mais de 50 tags são definidas conforme necessário.
## Considere a criação de um SCP para definir proteções em torno de solicitações de criação de recursos
Os recursos que nunca tiveram tags anexadas a eles não aparecem como incompatíveis nos relatórios. Os administradores de conta ainda podem criar recursos sem tags. Em alguns casos, você pode usar uma política de controle de serviço (SCP) para definir proteções em torno de solicitações de criação de recursos.
Para saber se um AWS serviço oferece suporte ao controle de acesso usando tags, consulte [Serviços da AWS That Work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) no *Guia do usuário do IAM*. Procure os serviços que têm **Sim **na coluna **ABAC (controle de acesso por atributo)**. Selecione o nome do serviço para visualizar a documentação de controle de acesso e a autorização desse serviço.
# Conceitos básicos das políticas de tag
O uso de políticas de tags envolve trabalhar com várias Serviços da AWS. Para começar, revise as páginas a seguir. Em seguida, siga os fluxos de trabalho nesta página para se familiarizar com as política de tag e seus efeitos.
+ [Pré-requisitos e permissões para políticas de gerenciamento para AWS Organizations](orgs_manage_policies_prereqs.md)
+ [Práticas recomendadas para usar políticas de tag](orgs_manage_policies_tag-policies-best-practices.md)
## Usar políticas de tag pela primeira vez
Siga estas etapas para começar a usar política de tag pela primeira vez.
| Tarefa | Conta para fazer login | AWS console de serviço a ser usado |
| --- | --- | --- |
| Etapa 1: [habilitar políticas de tag para a organização.](enable-policy-type.md) | A conta de gerenciamento da organização.¹ | [AWS Organizations](https://console.aws.amazon.com/organizations/) |
| Etapa 2: [criar uma política de tag](orgs_policies_create.md#create-tag-policy-procedure). Crie sua primeira política de tags de forma simples. Insira uma chave de tag no tratamento de maiúscula e minúscula que você deseja usar e deixe todas as outras opções com a configuração padrão. | A conta de gerenciamento da organização.¹ | [AWS Organizations](https://console.aws.amazon.com/organizations/) |
| Etapa 3: [anexar uma política de tag a uma única conta-membro que você pode usar para teste.](orgs_policies_attach.md) Será necessário fazer login nesta conta na próxima etapa. | A conta de gerenciamento da organização.¹ | [AWS Organizations](https://console.aws.amazon.com/organizations/) |
| Etapa 4: criar alguns recursos com tags compatíveis e alguns com tags incompatíveis. | A conta-membro que você está usando para fins de teste. | Qualquer AWS serviço com o qual você se sinta confortável. Por exemplo, é possível usar o [AWS Secrets Manager](https://console.aws.amazon.com/secretsmanager/) e seguir o procedimento em [Criar um segredo básico](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_create-basic-secret.html) para criar segredos compatíveis e não compatíveis. |
| Etapa 5: [ visualizar a política de tag efetiva e avaliar o status de conformidade da conta.](https://docs.aws.amazon.com/tag-editor/latest/userguide/tag-policies-orgs-finding-noncompliant-tags.html) | A conta-membro que você está usando para fins de teste. | [Resource Groups](https://console.aws.amazon.com/resource-groups/) e o AWS serviço em que o recurso foi criado. Se você criou recursos com tags compatíveis e não compatíveis, você verá as tags não compatíveis nos resultados. |
| Etapa 6: repetir o processo de localizar e corrigir problemas de conformidade até que os recursos na conta de teste estejam em conformidade com sua política de tag. | A conta-membro que você está usando para fins de teste. | [Resource Groups](https://console.aws.amazon.com/resource-groups/) e o AWS serviço em que o recurso foi criado. |
| A qualquer momento, você pode [ avaliar a conformidade em toda a organização](https://docs.aws.amazon.com/ARG/latest/userguide/tag-policies-orgs-evaluating-org-wide-compliance.html). | A conta de gerenciamento da organização.¹ | [Grupos de recursos](https://console.aws.amazon.com/resource-groups/) |
¹ Você deve fazer login como um usuário do IAM, assumir uma função do IAM ou fazer login como usuário root ([não recomendado](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)) na conta de gerenciamento da organização.
## Expandir o uso de políticas de tag
Você pode executar as seguintes tarefas em qualquer ordem para expandir o uso das políticas de tag.
| Tarefa avançada | Conta para fazer login | AWS console de serviço a ser usado |
| --- | --- | --- |
| [Crie políticas de tag mais avançadas](orgs_policies_create.md#create-tag-policy-procedure). Siga o mesmo processo definido para usuários iniciantes, mas tente outras tarefas. Por exemplo, defina chaves ou valores adicionais ou especifique um tratamento de maiúsculas e minúsculas diferente para uma chave de tag. Você pode usar as informações em [Entendendo a herança da política de gerenciamento](orgs_manage_policies_inheritance_mgmt.md) e [Sintaxe de política de tag](orgs_manage_policies_example-tag-policies.md#tag-policy-syntax-reference) para criar políticas de tag mais detalhadas. | A conta de gerenciamento da organização.¹ | [AWS Organizations](https://console.aws.amazon.com/organizations/) |
| [Anexe políticas de tags a contas adicionais ou OUs.](orgs_policies_attach.md) Verifique a [política de tag efetiva de uma conta](orgs_manage_policies_effective.md) depois de anexar mais políticas a ela ou a qualquer UO em que a conta seja membro. | A conta de gerenciamento da organização.¹ | [AWS Organizations](https://console.aws.amazon.com/organizations/) |
| Crie uma SCP para exigir o uso de tags quando alguém criar novos recursos. | A conta de gerenciamento da organização.¹ | [AWS Organizations](https://console.aws.amazon.com/organizations/) |
| [ Continue avaliando o status de compatibilidade da conta em relação à política de tag em vigor à medida que ela for alterada. Corrija tags fora de conformidade.](https://docs.aws.amazon.com/ARG/latest/userguide/tag-policies-orgs-finding-noncompliant-tags.html) | Uma conta-membro com uma política de tags efetiva. | [Resource Groups](https://console.aws.amazon.com/resource-groups/) e o AWS serviço em que o recurso foi criado. |
| [ Avalie a conformidade em toda a organização](https://docs.aws.amazon.com/ARG/latest/userguide/tag-policies-orgs-evaluating-org-wide-compliance.html). | A conta de gerenciamento da organização.¹ | [Grupos de recursos](https://console.aws.amazon.com/resource-groups/) |
¹ Você deve fazer login como um usuário do IAM, assumir uma função do IAM ou fazer login como usuário root ([não recomendado](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)) na conta de gerenciamento da organização.
## Aplicar política de tag pela primeira vez
Para aplicar políticas de tag pela primeira vez, siga um fluxo de trabalho semelhante ao primeiro uso de políticas de tag e use uma conta de teste.
**Atenção**
Esteja atento ao aplicar a conformidade. Certifique-se de que você entende os efeitos do uso de políticas de tag e siga o fluxo de trabalho recomendado. Teste como a aplicação funciona em uma conta de teste antes de expandi-la para mais contas. Caso contrário, você pode impedir que os usuários nas contas da organização atribuam tags aos recursos necessários. Para obter mais informações, consulte [Imponha a consistência da marcação](orgs_manage_policies_tag-policies-enforcement.md).
| Tarefas de aplicação | Conta para fazer login | AWS console de serviço a ser usado |
| --- | --- | --- |
| Etapa 1: [criar uma política de tag](orgs_policies_create.md#create-tag-policy-procedure). Mantenha a aplicação da sua primeira política de tag simples. Insira uma chave de tag no tratamento de maiúsculas e minúsculas que você deseja usar e escolha a opção **Prevent noncompliant operations for this tag (Impedir operações incompatíveis para esta tag)**. Em seguida, especifique um tipo de recurso no qual aplicá-la. Continuando o exemplo anterior, você pode optar por aplicá-la em senhas do Secrets Manager. | A conta de gerenciamento da organização.¹ | [AWS Organizations](https://console.aws.amazon.com/organizations/) |
| Etapa 2: [anexar uma política de tag a uma única conta de teste.](orgs_policies_attach.md) | A conta de gerenciamento da organização.¹ | [AWS Organizations](https://console.aws.amazon.com/organizations/) |
| Etapa 3: tente criar alguns recursos com tags compatíveis e alguns com tags incompatíveis. Você não deve ter permissão para criar uma tag em um recurso do tipo especificado na política de tag com uma tag fora de conformidade. | A conta-membro que você está usando para fins de teste. | Qualquer AWS serviço com o qual você se sinta confortável. Por exemplo, é possível usar o [AWS Secrets Manager](https://console.aws.amazon.com/secretsmanager/) e seguir o procedimento em [Criar um segredo básico](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_create-basic-secret.html) para criar segredos compatíveis e não compatíveis. |
| Etapa 4: [ avaliar o status de conformidade da conta em relação à política de tag efetiva e corrigir tags incompatíveis.](https://docs.aws.amazon.com/ARG/latest/userguide/tag-policies-orgs-finding-noncompliant-tags.html) | A conta-membro que você está usando para fins de teste. | [Resource Groups](https://console.aws.amazon.com/resource-groups/) e o AWS serviço em que o recurso foi criado. |
| Etapa 5: repetir o processo de localizar e corrigir problemas de conformidade até que os recursos na conta de teste estejam em conformidade com sua política de tag. | A conta-membro que você está usando para fins de teste. | [Resource Groups](https://console.aws.amazon.com/resource-groups/) e o AWS serviço em que o recurso foi criado. |
| A qualquer momento, você pode [ avaliar a conformidade em toda a organização](https://docs.aws.amazon.com/ARG/latest/userguide/tag-policies-orgs-evaluating-org-wide-compliance.html). | A conta de gerenciamento da organização.¹ | [Grupos de recursos](https://console.aws.amazon.com/resource-groups/) |
¹ Você deve fazer login como um usuário do IAM, assumir uma função do IAM ou fazer login como usuário root ([não recomendado](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)) na conta de gerenciamento da organização.
# Conformidade de marcação de relatórios
As políticas de tags fornecem um modo de relatório para “Regras básicas de conformidade” e “Chave de tag obrigatória”. Você pode usar esse modo para avaliar a conformidade de uma conta em sua organização com sua política de tags efetiva. O relatório gerado inclui somente recursos que tiveram pelo menos uma tag definida pelo usuário em qualquer momento do ciclo de vida.
**Importante**
Recursos não marcados não aparecem como incompatíveis nos resultados.
Para encontrar recursos não marcados em sua conta, use o AWS Resource Explorer com uma consulta que usa`tag:none`. Para obter mais informações, consulte [Pesquisar recursos não marcados](https://docs.aws.amazon.com/resource-explorer/latest/userguide/using-search-query-examples.html#example-1) no *Guia do usuário do AWS Resource Explorer*.
**Topics**
+ [Relatórios para “Regras básicas de conformidade”](#reporting-basic-compliance-rules)
+ [Relatórios para “Chave de tag obrigatória”](#reporting-required-tag-key)
+ [Gerar um relatório de conformidade em toda a organização](enforcement-report.md)
## Relatórios para “Regras básicas de conformidade”
Com relatórios para regras básicas de conformidade, você pode gerar um relatório de conformidade de marcação que verifica a conformidade em relação à capitalização e aos valores permitidos de etiquetas.
**Para denunciar,**
Na guia Editor visual, insira o valor da chave de tag com a qual você deseja relatar a conformidade. A captura de tela abaixo mostra um relatório de conformidade do cliente para a chave de tag CostCenter "”. Neste exemplo, o relatório destacará um recurso marcado como compatível se ele corresponder apenas a um valor minúsculo da chave de tag "CostCenter", o que significa que a string é igual a “costcenter”.
![\[Guia do editor visual mostrando a configuração da política de CostCenter tags para tags com valores legais e de RH\]](http://docs.aws.amazon.com/pt_br/organizations/latest/userguide/images/tag-policies-basic-compliance-reporting.png)
O JSON abaixo gera um relatório de conformidade para recursos em relação a um valor minúsculo da chave de tag CostCenter "”.
```
{
"tags": {
"CostCenter": {}
}
}
```
**Para relatar sobre capitalização,**
Na guia Editor visual, insira o valor da chave de tag com a qual você deseja relatar a conformidade e selecione a opção Capitalização. A captura de tela abaixo mostra um relatório de conformidade do cliente para a chave de tag "CostCenter" com letras maiúsculas. Neste exemplo, o relatório destacará um recurso marcado como compatível se for uma sequência de caracteres exata que corresponda à chave de tag CostCenter "”.
![\[Aba do editor visual mostrando a configuração da política de CostCenter tags para tag com capitalização\]](http://docs.aws.amazon.com/pt_br/organizations/latest/userguide/images/tag-policies-basic-compliance-capitalization.png)
O JSON abaixo gera um relatório de conformidade para recursos em relação à chave de tag "CostCenter" com letras maiúsculas.
```
{
"tags": {
"CostCenter": {
"tag_key": {
"@@assign": "CostCenter"
}
}
}
}
```
**Para relatar os valores de tag permitidos com letras maiúsculas,**
Na guia Editor visual, insira o valor da chave de tag com a qual você deseja relatar a conformidade, selecione a opção Valores permitidos e insira valores para os valores de tag permitidos. A captura de tela abaixo mostra um relatório de conformidade do cliente para a chave de tag "CostCenter" com letras maiúsculas e valores de tag permitidos. Neste exemplo, o relatório destacará um recurso marcado como compatível se for uma sequência de caracteres exata correspondente à chave da tag "CostCenter" e o valor da tag for “RH” ou “Legal”.
![\[Guia do editor visual mostrando a configuração da política de CostCenter tags para tags com letras maiúsculas e valores de tag permitidos HR e Legal\]](http://docs.aws.amazon.com/pt_br/organizations/latest/userguide/images/tag-policies-basic-compliance-allowed-tag-values-with-capitalization.png)
O JSON abaixo gera um relatório de conformidade para recursos em relação à chave de tag "CostCenter" com letras maiúsculas e valores de tag permitidos “HR” e “Legal”.
```
{
"tags": {
"CostCenter": {
"tag_key": {
"@@assign": "CostCenter"
},
"tag_value": {
"@@assign": [
"HR",
"Legal"
]
}
}
}
}
```
## Relatórios para “Chave de tag obrigatória”
**Atenção**
No momento, o console AWS Resource Groups não oferece suporte à geração de relatórios das chaves de tag necessárias ao avaliar a conformidade de uma conta. Recursos não compatíveis que não tenham uma chave de tag necessária não aparecerão na seção **Recursos com tags não compatíveis** e não marcarão a conta como não compatível. Em vez disso, use o relatório de conformidade de toda a organização para encontrar recursos não compatíveis que não tenham a chave de tag necessária.
Com os relatórios das chaves de tag necessárias, você pode avaliar se sua operação de criação de recursos não tem as chaves de tag obrigatórias ou obrigatórias. Execute o comando a seguir em sua CLI para listar as chaves de tag necessárias que estão definidas na política de tags efetiva da conta. Você pode usar essas informações para verificar manualmente se está criando um recurso com todas as tags necessárias, conforme definido pelo administrador da sua conta.
```
$ aws resourcegroupstaggingapi list-required-tags
```
**Para relatar as chaves de tag necessárias,**
Na guia Editor visual, insira o valor da chave de tag com a qual você deseja relatar a conformidade e selecione a opção **Marcar tag como necessária para emissão de relatórios**. A captura de tela abaixo mostra um relatório de conformidade do cliente para a chave de tag "CostCenter" com letras maiúsculas e relatórios para a chave de tag necessária. Neste exemplo, o relatório destacará um recurso marcado como compatível se ele contiver a string exata "CostCenter" como chave de tag.
**Importante**
Você precisa selecionar as tags Capitalização e Marcar conforme necessário para as opções de geração de relatórios para gerar um relatório dos tipos de recursos selecionados que não têm as tags exatas necessárias. Por exemplo, você usará essas duas opções ao tentar verificar uma correspondência exata com a chave de tag CostCenter "”.
Você pode selecionar somente a opção Marcar tags como necessárias para geração de relatórios para gerar um relatório dos tipos de recursos selecionados que não têm as tags necessárias. Nesse cenário, o relatório gerado marcará os recursos como compatíveis se eles tiverem "CostCenter“, “CostCenter”, “Costcenter”, “costcenter” ou qualquer variação similar. Esse recurso permite gerar relatórios de conformidade para tipos de recursos selecionados, em vez de todos os recursos marcados em sua conta.
Selecionar somente a capitalização gerará um relatório para TODOS os recursos marcados e marcará esses recursos como não compatíveis se a chave da tag não tiver uma correspondência de string exata.
![\[Guia do editor visual mostrando a configuração da política de tags para o relatório de tags necessário\]](http://docs.aws.amazon.com/pt_br/organizations/latest/userguide/images/tag-policies-basic-compliance-required-tag.png)
O JSON abaixo gera um relatório de conformidade para recursos em relação à chave de tag CostCenter "" com letras maiúsculas e marca a tag conforme necessário para relatórios.
```
{
"tags": {
"CostCenter": {
"tag_key": {
"@@assign": "CostCenter"
},
"report_required_tag_for": {
"@@assign": [
"ec2:ALL_SUPPORTED"
]
}
}
}
}
```
**Para impor,**
Você pode usar relatórios com ferramentas de IaC CloudFormation, como Terraform e Pulumi, para avisar seus desenvolvedores ou bloquear implantações sem as tags necessárias. Agora você pode usar uma política de tags eficaz que funciona no Terraform e no Pulumi. CloudFormation Consulte [Aplicar a “chave de tag necessária” com o IaC](enforce-required-tag-keys-iac.md) para obter mais detalhes.
# Gerar um relatório de conformidade em toda a organização
A qualquer momento, você pode gerar um relatório que lista todos os recursos marcados em Contas da AWS toda a sua organização. O relatório mostra se cada recurso está em conformidade com a política de tag efetiva. Observe que pode levar até 48 horas para que as alterações feitas em uma política de tag ou recursos sejam refletidas no relatório de conformidade de toda a organização. Por exemplo, se você tiver uma política de tags que define uma nova tag padronizada para um tipo de recurso, os recursos desse tipo que não têm essa tag são mostrados como compatíveis no relatório por até 48 horas.
Você pode gerar o relatório a partir da conta de gerenciamento da organização na região `us-east-1`, desde que ele tenha acesso a um bucket do Amazon S3. O bucket deve ter uma política de bucket anexada, conforme mostrado em [Política de bucket do Amazon S3 para relatório de armazenamento](https://docs.aws.amazon.com/ARG/latest/userguide/tag-policies-prereqs.html#bucket-policy). Para gerar o relatório, execute o seguinte comando:
```
$ aws resourcegroupstaggingapi start-report-creation --region us-east-1
```
Você pode gerar um relatório de cada vez.
Este relatório pode levar algum tempo para ser concluído. Você pode verificar o status executando o seguinte comando:
```
$ aws resourcegroupstaggingapi describe-report-creation --region us-east-1
{
"Status": "SUCCEEDED"
}
```
Depois que o comando acima retornar `SUCCEEDED`, você pode abrir o relatório no bucket do Amazon S3.
# Imponha a consistência da marcação
As políticas de tags fornecem dois recursos para ajudá-lo a impor a consistência da marcação em seus AWS ambientes: “Regras básicas de conformidade” e “Chave de tag obrigatória”. Você pode usar esses recursos com dois modos de política de tags: imposição e emissão de relatórios. Esta seção destaca o modo de fiscalização para ambos os recursos. Para obter detalhes sobre o modo de geração de relatórios para ambos os recursos, consulte “Conformidade de marcação de relatórios”.
**Topics**
+ [Aplique as “regras básicas de conformidade”](#basic-compliance-rules)
+ [Práticas recomendadas](#best-practices)
+ [Aplique a “chave de tag necessária” com o IaC](enforce-required-tag-keys-iac.md)
+ [Sintaxe e exemplos de políticas de tag](orgs_manage_policies_example-tag-policies.md)
## Aplique as “regras básicas de conformidade”
Com a aplicação das regras básicas de conformidade, você pode impedir a criação de recursos com valores de tag que não atendam aos requisitos especificados em sua política de tags. Por exemplo, você pode definir uma política que bloqueie as operações de EC2 criação da Amazon se a chave de tag CostCenter '' fornecida não tiver um valor de tag de “Comercial” ou “Legal”. As regras básicas de conformidade também permitem que você aplique a fiscalização com base na capitalização das chaves de tag. Ativar a capitalização garante que as chaves de tag correspondam exatamente à sequência de caracteres. A capitalização trata "CostCenter“, “CostCenter” e “Costcenter” como chaves de tag exclusivas, o que significa que a aplicação da chave de tag diferencia maiúsculas de minúsculas. A aplicação de letras maiúsculas impede que as equipes criem variações de tags acidentalmente. A consistência da marcação é fundamental tanto para a precisão do controle de custos quanto para as políticas de segurança de controle de acesso baseado em atributos (ABAC) que dependem da correspondência precisa de etiquetas para conceder ou negar acesso a recursos.
**Importante**
As regras básicas de conformidade não impõem a conformidade de tags em recursos criados sem tags. Esse recurso não impõe chaves de tag ausentes. Você não pode usar esse recurso para garantir que as chaves de tag necessárias ou obrigatórias sejam configuradas na criação do recurso. Use o modo de relatório em “Chaves de tag obrigatórias” para aplicar as chaves de tag necessárias para recursos criados por ferramentas de IaC CloudFormation, como Terraform e Pulumi. Use SCPs para impedir que usuários e funções do IAM nas contas de destino criem determinados tipos de recursos se a solicitação não incluir as tags especificadas.
Para impor regras básicas de conformidade com políticas de tags, faça o seguinte ao [criar uma política de tags:](orgs_policies_create.md)
+ Na guia **Editor visual**, selecione a opção **Evitar operações não compatíveis com essa tag**. Consulte a seção [Criar uma política de tags](orgs_policies_create.md) para ver as etapas sobre como criar e anexar uma política de tags.
+ Na guia **JSON**, use o campo `enforced_for`. Para obter informações sobre a sintaxe da política de tag, consulte [Sintaxe e exemplos de políticas de tag](orgs_manage_policies_example-tag-policies.md).
A imagem abaixo mostra a experiência de console da guia Editor visual. Neste exemplo, o cliente está definindo uma política de tags que aplicará a validação do valor da tag somente para os tipos de EC2 recursos da Amazon que são compatíveis com as políticas de tags. Essa política verificará se o valor da tag é “Legal” ou “HR” quando a chave de tag fornecida for "CostCenter" para os tipos de EC2 recursos da Amazon. Essa política também impõe a capitalização, o que significa que a política está procurando uma sequência de caracteres exata que corresponda à chave de tag CostCenter "”.
![\[Aba do editor visual mostrando a configuração da política de CostCenter tags para tags com valores legais e de RH\]](http://docs.aws.amazon.com/pt_br/organizations/latest/userguide/images/tag-policies-basic-compliance.png)
O JSON abaixo é a política de tags gerada a partir do exemplo CostCenter "” acima.
**Importante**
Recomendamos que você use o editor visual ao definir sua política de tags pela primeira vez. O editor visual garante que a sintaxe da política de tags seja válida, sem etapas adicionais, e oferece uma experiência simplificada e clicável para definir sua política de tags. Você pode usar o editor visual ou a guia JSON para definir sua política de tags.
```
{
"tags": {
"CostCenter": {
"tag_key": {
"@@assign": "CostCenter"
},
"tag_value": {
"@@assign": [
"HR",
"Legal"
]
},
"enforced_for": {
"@@assign": [
"ec2:ALL_SUPPORTED"
]
}
}
}
}
```
## Práticas recomendadas
Siga estas melhores práticas de fiscalização com “Regras básicas de conformidade” e “Chaves de tag necessárias para IaC” com políticas de tags:
+ **Tenha cuidado ao impor a conformidade** — certifique-se de compreender os efeitos do uso de políticas de tags e siga os fluxos de trabalho recomendados descritos em. [Conceitos básicos das políticas de tag](orgs_manage_policies_tag-policies-getting-started.md) Teste como a fiscalização funciona em uma conta de teste antes de expandi-la para mais contas ou unidades organizacionais. Caso contrário, você pode impedir que os usuários nas contas da organização criem os recursos necessários.
+ **Saiba quais tipos de recursos você pode aplicar** – você só pode impor a compatibilidade com as políticas de tag em [tipos de recursos suportados](orgs_manage_policies_supported-resources-enforcement.md). Os tipos de recursos que são compatíveis com a aplicação da conformidade são listados quando você usa o editor visual para criar uma política de tag.
+ **Entenda as interações com alguns serviços** — alguns Serviços da AWS têm agrupamentos de recursos semelhantes a contêineres que criam recursos automaticamente para você e propagam tags de um recurso em um serviço para outro. Por exemplo, tags em EC2 grupos da Amazon e clusters do Amazon EMR podem se propagar automaticamente para as instâncias da Amazon contidas. EC2 Você pode ter políticas de tags para a Amazon EC2 que sejam mais rígidas do que para grupos ou clusters do Amazon EMR. Se você habilitar a aplicação, a política de tag impede que os recursos sejam marcados e pode bloquear o dimensionamento dinâmico e o provisionamento.
As seções a seguir mostram como você pode encontrar recursos não compatíveis e corrigi-los para torná-los compatíveis.
**Topics**
+ [Identifique e corrija inconsistências de marcação](orgs_manage_policies_tag-policies-identify-remediate.md)
# Aplique a “chave de tag necessária” com o IaC
As políticas de tags ajudam você a manter a marcação consistente em suas implantações de infraestrutura como código (IaC). Com as “Chaves de tag obrigatórias”, você pode garantir que todos os recursos criados por meio de ferramentas de IaC CloudFormation, como Terraform e Pulumi, incluam as tags obrigatórias definidas pela sua organização.
Esse recurso verifica suas implantações de IaC em relação às políticas de tags da sua organização antes que os recursos sejam criados. Quando faltam as tags necessárias em uma implantação, você pode definir suas configurações de IaC para avisar suas equipes de desenvolvimento ou impedir totalmente a implantação. Essa abordagem proativa mantém a conformidade da marcação a partir do momento em que os recursos são criados, em vez de exigir uma correção manual posterior. A fiscalização funciona em várias ferramentas de IaC usando uma única definição de política de tag, eliminando a necessidade de configurar regras de marcação separadas para cada ferramenta que sua organização usa.
**Topics**
+ [Imponha com CloudFormation](#enforce-with-cloudformation)
+ [Aplique com o Terraform](#enforce-with-terraform)
+ [Imponha com Pulumi](#enforce-with-pulumi)
## Imponha com CloudFormation
**nota**
Para aplicar as chaves de tag necessárias com CloudFormation, você deve especificar as tags necessárias para seu tipo de recurso nas políticas de tags. Consulte a seção [Relatórios para “Chave de tag obrigatória”](orgs_manage_policies_tag-policies-report-tagging-compliance.md#reporting-required-tag-key) para obter mais detalhes.
**Função de execução de configuração para o AWS:TagPolicies:: TaggingComplianceValidator Hook**
Antes de ativar o `AWS::TagPolicies::TaggingComplianceValidator` gancho, você deve criar uma função de execução que o gancho use para acessar AWS os serviços. A função deve ter a seguinte Política de Confiança anexada:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"resources.cloudformation.amazonaws.com",
"hooks.cloudformation.amazonaws.com"
]
},
"Action": [
"sts:AssumeRole"
]
}
]
}
```
A função de execução também deve ter uma Política de Função com pelo menos as seguintes permissões:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"tag:ListRequiredTags"
],
"Resource": "*"
}
]
}
```
Para obter mais informações sobre como configurar funções de execução para extensões públicas, consulte [Configurar uma função de execução com permissões do IAM e uma política de confiança para acesso a extensões públicas](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/registry-public.html#registry-public-enable-execution-role) no Guia CloudFormation do usuário.
**Ative o AWS::TagPolicies: TaggingComplianceValidator Gancho**
**Importante**
Antes de continuar, verifique se você tem as permissões necessárias para trabalhar com Hooks e visualizar os controles proativos no CloudFormation console. Para obter mais informações, consulte [Conceder permissões do IAM para CloudFormation Hooks](https://docs.aws.amazon.com/cloudformation-cli/latest/hooks-userguide/grant-iam-permissions-for-hooks.html).
Depois de atualizar sua política de tags, você deve ativar o `AWS::TagPolicies::TaggingComplianceValidator` gancho em cada AWS conta e região em que deseja impor a conformidade de marcação exigida.
Esse AWS gancho gerenciado pode ser configurado em dois modos:
+ **Modo de aviso**: permite que as implantações continuem, mas gera avisos quando as tags necessárias estão ausentes
+ **Modo de falha**: bloqueia implantações sem as tags necessárias
Para ativar o gancho usando a AWS CLI:
```
aws cloudformation activate-type \
--type HOOK \
--type-name AWS::TagPolicies::TaggingComplianceValidator \
--execution-role-arn arn:aws:iam::123456789012:role/MyHookExecutionRole \
--publisher-id aws-hooks \
--region us-east-1
```
```
aws cloudformation set-type-configuration \
--configuration '{"CloudFormationConfiguration":{"HookConfiguration":{"HookInvocationStatus": "ENABLED", "FailureMode": "WARN", "TargetOperations": ["STACK"], "Properties":{}}}}' \
--type-arn "arn:aws:cloudformation:us-east-1:123456789012:type/hook/AWS-TagPolicies-TaggingComplianceValidator" \
--region us-east-1
```
`region`Substitua pela sua AWS região de destino e mude `"FailureMode":"FAIL"` para `"FailureMode":"WARN"` se preferir o modo de aviso.
**Ative o AWS::TagPolicies:: TaggingComplianceValidator Conecte-se em várias contas e regiões com CloudFormation StackSets**
Para organizações com várias AWS contas, você pode usar AWS CloudFormation StackSets para ativar o gancho de conformidade de marcação em todas as suas contas e regiões simultaneamente.
CloudFormation StackSets permitem que você implante o mesmo CloudFormation modelo em várias contas e regiões com uma única operação. Essa abordagem garante a aplicação consistente da marcação em toda a AWS organização sem exigir configuração manual em cada conta.
Para usar CloudFormation StackSets para essa finalidade:
1. Crie um CloudFormation modelo que ative o gancho de conformidade de marcação
1. Implante o modelo usando CloudFormation StackSets para segmentar suas unidades organizacionais ou contas específicas
1. Especifique todas as regiões em que você deseja que a fiscalização seja ativada
A CloudFormation StackSets implantação lidará automaticamente com o processo de ativação em todas as contas e regiões especificadas, garantindo conformidade uniforme de marcação em toda a organização. [Para saber como implantar CloudFormation Hooks em uma organização com gerenciamento de serviços CloudFormation StackSets, consulte este blog.AWS](https://aws.amazon.com/blogs/devops/deploy-cloudformation-hooks-to-an-organization-with-service-managed-stacksets/)
*Implante o CloudFormation modelo abaixo usando CloudFormation StackSets para ativar o AWS::TagPolicies:: TaggingComplianceValidator Hook para contas em sua organização.*
**Importante**
Este gancho funciona apenas como um StackHook. Não tem efeito quando usado como um gancho de recursos.
```
Resources:
# Activate the AWS-managed hook type
HookTypeActivation:
Type: AWS::CloudFormation::TypeActivation
Properties:
AutoUpdate: True
PublisherId: "AWS"
TypeName: "AWS::TagPolicies::TaggingComplianceValidator"
# Configure the hook
HookTypeConfiguration:
Type: AWS::CloudFormation::HookTypeConfig
DependsOn: HookTypeActivation
Properties:
TypeName: "AWS::TagPolicies::TaggingComplianceValidator"
TypeArn: !GetAtt HookTypeActivation.Arn
Configuration: !Sub |
{
"CloudFormationConfiguration": {
"HookConfiguration": {
"TargetStacks": "ALL",
"TargetOperations": ["STACK"],
"Properties": {},
"FailureMode": "Warn",
"TargetFilters": {
"Actions": [
"CREATE",
"UPDATE"
]}
}
}
}
```
**nota**
Para obter mais informações sobre como executar CloudFormation hooks, consulte [Ativar um Hook proativo baseado em controle em](https://docs.aws.amazon.com/cloudformation-cli/latest/hooks-userguide/proactive-controls-hooks-activate-hooks.html) sua conta.
## Aplique com o Terraform
Para aplicar as chaves de tag necessárias com o Terraform, você precisa atualizar seu Terraform AWS Provider para 6.22.0 ou superior e habilitar a validação da política de tags na configuração do seu provedor. Para obter detalhes de implementação e exemplos de configuração, consulte a [documentação do Terraform AWS Provider sobre a aplicação da política de tags](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/guides/tag-policy-compliance).
## Imponha com Pulumi
Para aplicar as chaves de tag necessárias com o Pulumi, você precisa habilitar o pacote de políticas de relatórios de políticas de tags no Pulumi Cloud e configurar sua função do IAM com as permissões de leitura da política de tags. Para obter detalhes de implementação e exemplos de configuração, consulte a [documentação do Pulumi sobre a aplicação da política de tags](https://www.pulumi.com/docs/insights/policy/integrations/aws-organizations-tag-policies/#aws-organizations-tag-policies).
# Sintaxe e exemplos de políticas de tag
Esta página fornece sintaxe e exemplos das políticas de tag.
**Topics**
+ [Sintaxe de política de tag](#tag-policy-syntax-reference)
+ [Exemplos da política de tags](#tag-policy-examples)
+ [Exemplo 1: definir maiúsculas e minúsculas de chave de tag em toda a organização](#tag-policy-example-key-case)
+ [Exemplo 2: impedir o uso de uma chave de tag](#tag-policy-example-prevent-key)
+ [Exemplo 3: especifique uma política de tags para todos os tipos de recursos compatíveis de um AWS serviço específico](#tag-policy-example-all-supported)
+ [Exemplo 4: imponha as chaves de tag necessárias para fins de conformidade](#tag-policy-example-required-tags)
## Sintaxe de política de tag
Uma política de tag é um arquivo de texto sem formatação estruturado de acordo com as regras do [JSON](http://json.org). A sintaxe para políticas de tag segue a sintaxe para os tipos de política de gerenciamento. Para ver uma discussão completa sobre essa sintaxe, consulte [Entendendo a herança da política de gerenciamento](orgs_manage_policies_inheritance_mgmt.md). Este tópico se concentra na aplicação dessa sintaxe geral aos requisitos específicos do tipo de política de tag.
A seguinte política de tag mostra a sintaxe básica da política de tag:
```
{
"tags": {
"costcenter": {
"tag_key": {
"@@assign": "CostCenter"
},
"tag_value": {
"@@assign": [
"100",
"200",
"300*"
]
},
"enforced_for": {
"@@assign": [
"secretsmanager:ALL_SUPPORTED"
]
}
}
}
}
```
A sintaxe da política de tag inclui os seguintes elementos:
+ O nome da chave de campo `tags`. As políticas de tag sempre começam com esse nome de chave fixo. É a linha superior na política de exemplo acima.
+ Uma *chave de política* que identifica exclusivamente a declaração da política. Ela deve corresponder ao valor da *chave de tag*, exceto para o tratamento de maiúsculas e minúsculas. O valor da política diferencia maiúsculas de minúsculas.
Neste exemplo, `costcenter` é a chave de política.
+ Pelo menos uma *chave de tag* que especifica a chave de tag permitida com o uso de maiúsculas e minúsculas com o qual você deseja que os recursos sejam compatíveis. Se o tratamento de maiúsculas e minúsculas não está definido, o uso de minúsculas é o tratamento padrão para as chaves de tag. O valor da chave de tag deve corresponder ao valor da chave de política. Mas como o valor da chave de política não diferencia o uso de maiúsculas e minúsculas, os valores podem ser definidos de modo diferente.
Neste exemplo, `CostCenter` é a chave de tag. Este é o tratamento de maiúsculas e minúsculas necessário para a conformidade com a política de tag. Os recursos com tratamento alternativo de maiúsculas e minúsculas para esta chave de tag não estão em conformidade com a política de tag.
Você pode definir várias chaves de tag em uma política de tag.
+ (Opcional) Uma lista de um ou mais *valores de tag* aceitáveis para a chave de tag. Se a política de tag não especificar um valor de tag para uma chave de tag, qualquer valor (incluindo nenhum valor) será considerado compatível.
Neste exemplo, os valores aceitáveis para a chave de tag `CostCenter` são `100`, `200` e `300*`.
+ (Opcional) Uma opção `enforced_for` que indica se deve impedir qualquer operação de atribuição de tags incompatível em serviços e recursos especificados. No console, trata-se da opção **Prevent noncompliant operations for this tag (Impedir operações incompatíveis para esta tag)** no editor visual para criar políticas de tag. A configuração padrão para esta opção é nula.
O exemplo de política de tags especifica que a `CostCenter` tag aplicada a todos os AWS Secrets Manager recursos deve estar em conformidade com essa política.
**Atenção**
Você só deve alterar essa opção com a configuração padrão se tem experiência em usar políticas de tag. Caso contrário, você pode impedir que os usuários nas contas da organização criem os recursos necessários.
+ Os *operadores* que especificam como a política de tag se mescla com outras políticas de tag dentro da árvore da organização para criar a [política de tag efetiva](orgs_manage_policies_effective.md) de uma conta. Neste exemplo, `@@assign` é usado para atribuir strings a `tag_key`, `tag_value`, e `enforced_for`. Para obter mais informações sobre operadores, consulte [Operadores de herança](policy-operators.md).
+ : você pode usar o caractere curinga `*` em valores de tag.
+ Você só pode usar um caractere curinga por valor de tag. Por exemplo, `*@example.com` é permitido, mas `*@*.com` não é.
+ Você pode usar o `ALL_SUPPORTED` caractere curinga no `enforced_for` campo com alguns serviços para permitir a aplicação de todos os recursos compatíveis com esse serviço. Para obter uma lista de serviços e tipos de recursos que são compatíveis com `enforced_for`, consulte [Serviços e tipos de recursos compatíveis com a aplicação](orgs_manage_policies_supported-resources-enforcement.md).
+ Não é possível usar um caractere curinga para especificar todos os serviços ou para especificar um recurso para todos os serviços.
## Exemplos da política de tags
As [políticas de tag](orgs_manage_policies_tag-policies.md) de exemplo a seguir são apenas para fins informativos.
**nota**
Antes de tentar usar essas políticas de tag de exemplo em sua organização, observe o seguinte:
Certifique-se de que seguiu o [fluxo de trabalho recomendado](orgs_manage_policies_tag-policies-getting-started.md) para começar a usar as políticas de tag.
Você deve revisar e personalizar cuidadosamente essas políticas de tag de acordo com seus requisitos exclusivos.
Todos os caracteres em sua política de tags estão sujeitos a um [tamanho máximo](orgs_reference_limits.md#min-max-values). Os exemplos deste guia mostram as políticas de tag formatadas com espaço em branco adicional para melhorar a legibilidade. No entanto, você pode excluir todos os espaços em branco para economizar espaço se o tamanho da política se aproximar ao tamanho máximo. Exemplos de espaço em branco incluem caracteres de espaço e quebras de linha que estão fora das aspas.
Os recursos sem tag não são exibidos como incompatíveis nos resultados.
## Exemplo 1: definir maiúsculas e minúsculas de chave de tag em toda a organização
O exemplo a seguir mostra uma política de tag que define apenas duas chaves de tag e o uso de maiúsculas e minúsculas que você deseja que as contas da organização usem como padrão.
**Política A — Política de tag da raiz da organização**
```
{
"tags": {
"CostCenter": {
"tag_key": {
"@@assign": "CostCenter",
"@@operators_allowed_for_child_policies": ["@@none"]
}
},
"Project": {
"tag_key": {
"@@assign": "Project",
"@@operators_allowed_for_child_policies": ["@@none"]
}
}
}
}
```
Esta política de tag define duas chaves de tag: `CostCenter` e `Project` Anexar essa política de tag à raiz da organização tem os seguintes efeitos:
+ Todas as contas em sua organização herdam essa política de tag.
+ Todas as contas em sua organização devem usar o tratamento de maiúsculas e minúsculas definido para a conformidade. Os recursos com as tags `Project` `CostCenter` e estão em conformidade. Os recursos com tratamento alternativo de maiúsculas e minúsculas para a chave de tag (por exemplo, `costcenter`, `Costcenter` ou `COSTCENTER`) não estão em conformidade.
+ As linhas `@@operators_allowed_for_child_policies": ["@@none"]` bloqueiam as chaves de tag. As políticas de tag anexadas mais abaixo na árvore da organização (políticas subordinadas) não podem usar operadores de definição de valor para alterar a chave de tag, incluindo o tratamento de maiúsculas e minúsculas.
+ Assim como acontece com todas as políticas de tag, os recursos sem tag ou as tags que não estejam definidas na política de tag não são avaliados quanto à conformidade com a política de tag.
AWS recomenda que você use esse exemplo como um guia para criar uma política de tag semelhante para as chaves de tag que você deseja usar. Anexe-a à raiz da organização. Em seguida, crie uma política de tag semelhante ao exemplo a seguir, que define apenas os valores aceitáveis para as chaves de tag definidas.
### Próxima etapa: definir valores
Suponha que anexou a política de tags anterior à raiz da organização. Em seguida, você pode criar uma política de tag como o exemplo a seguir e anexá-la a uma conta. Esta política define valores aceitáveis para as chaves de tag `CostCenter` e `Project`.
**Política B – Política de tag de conta**
```
{
"tags": {
"CostCenter": {
"tag_value": {
"@@assign": [
"Production",
"Test"
]
}
},
"Project": {
"tag_value": {
"@@assign": [
"A",
"B"
]
}
}
}
}
```
Se você anexar a Política A à raiz da organização e a Política B a uma conta, as políticas são combinadas para criar a seguinte política de tag efetiva para a conta:
**Política A \$1 Política B = política de tag efetiva para a conta**
```
{
"tags": {
"Project": {
"tag_value": [
"A",
"B"
],
"tag_key": "Project"
},
"CostCenter": {
"tag_value": [
"Production",
"Test"
],
"tag_key": "CostCenter"
}
}
}
```
Para obter mais informações sobre herança de política, incluindo exemplos de como os operadores de herança funcionam e exemplo de políticas de tag em vigor, consulte [Entendendo a herança da política de gerenciamento](orgs_manage_policies_inheritance_mgmt.md).
## Exemplo 2: impedir o uso de uma chave de tag
Para impedir o uso de uma chave de tag, você pode anexar uma política de tag como a seguinte a uma entidade da organização.
Esta política de exemplo especifica que nenhum valor é aceitável para a chave de tag `Color`. Ela também especifica que nenhum [operador](policy-operators.md) é permitido em políticas de tag filho. Portanto, qualquer tag `Color` nos recursos das contas afetadas é considerada não compatíveis. Porém, a opção `enforced_for` na verdade impede ***somente*** que as contas afetadas marquem as tabelas do Amazon DynamoDB com a tag `Color`.
```
{
"tags": {
"Color": {
"tag_key": {
"@@operators_allowed_for_child_policies": [
"@@none"
],
"@@assign": "Color"
},
"tag_value": {
"@@operators_allowed_for_child_policies": [
"@@none"
],
"@@assign": []
},
"enforced_for": {
"@@assign": [
"dynamodb:table"
]
}
}
}
}
```
## Exemplo 3: especifique uma política de tags para todos os tipos de recursos compatíveis de um AWS serviço específico
Para especificar uma política de tags para todos os tipos de recursos compatíveis de um AWS serviço específico, use o `ALL_SUPPORTED` caractere curinga.
Essa política usa o curinga `ALL_SUPPORTED` para especificar que todas as instâncias do Amazon EC2 com a chave de tag `Environment` só podem ter um valor de tag de `Prod` ou `Non-prod`. Este curinga oferece uma alternativa eficaz e concisa para listar cada instância do Amazon EC2 individualmente. Para obter uma lista de serviços e tipos de recursos que são compatíveis com o curinga `ALL_SUPPORTED`, consulte [Serviços e tipos de recursos compatíveis com a aplicação](orgs_manage_policies_supported-resources-enforcement.md).
```
{
"tags": {
"Environment": {
"tag_key": {
"@@assign": "Environment",
"@@operators_allowed_for_child_policies": ["@@none"]
},
"tag_value": {
"@@assign": [
"Prod",
"Non-prod"
],
"@@operators_allowed_for_child_policies": ["@@none"]
},
"enforced_for": {
"@@assign": [
"ec2:ALL_SUPPORTED"
]
}
}
}
}
```
## Exemplo 4: imponha as chaves de tag necessárias para fins de conformidade
Este exemplo demonstra como definir uma política de tags que exige que todos os recursos incluam etiquetas de conformidade obrigatórias. As organizações geralmente usam esse padrão para garantir a alocação adequada de custos, o controle de propriedade e a identificação do ambiente.
```
{
"tags": {
"CostCenter": {
"report_required_tag_for": {
"@@assign": [
"ec2:instance",
"s3:bucket",
"rds:db",
"lambda:function"
]
},
"tag_key": {
"@@assign": "CostCenter"
}
},
"Environment": {
"report_required_tag_for": {
"@@assign": [
"ec2:ALL_SUPPORTED",
"rds:ALL_SUPPORTED",
"s3:ALL_SUPPORTED"
]
},
"tag_key": {
"@@assign": "Environment"
},
"tag_value": {
"@@assign": [
"Production",
"Staging",
"Development",
"Test"
]
}
},
"Owner": {
"report_required_tag_for": {
"@@assign": [
"ec2:ALL_SUPPORTED"
]
},
"tag_key": {
"@@assign": "Owner"
}
}
}
}
```
Quando você aplica essa política e configura sua ferramenta de IaC com a aplicação da política de tags:
+ CostCenter: Necessário para instâncias EC2, buckets S3, bancos de dados RDS e funções Lambda
+ Ambiente: necessário para todos os recursos do EC2, RDS e S3, com valores permitidos restritos à produção, preparação, desenvolvimento ou teste
+ Proprietário: obrigatório para todos os recursos do EC2 em sua organização
Exemplo de código de infraestrutura que está em conformidade com esta política:
```
EC2Instance:
Type: AWS::EC2::Instance
Properties:
ImageId: ami-0c02fb55956c7d316
InstanceType: t2.micro
Tags:
- Key: CostCenter
Value: CC-12345
- Key: Environment
Value: Test
- Key: Owner
Value: john.doe@company.com
```
Se você tentar criar um recurso sem as tags necessárias, sua implantação do IaC falhará ou gerará um aviso durante a fase de planejamento, dependendo da sua configuração. Quando configurada no modo de falha, a implantação é bloqueada antes que qualquer recurso seja criado. Quando configurada no modo de aviso, a implantação prossegue, mas alerta sua equipe sobre as tags ausentes. A mensagem de erro de validação identifica exatamente quais tags necessárias estão faltando e quais recursos precisam delas.
Para obter instruções de configuração específicas para sua ferramenta IaC:
+ **CloudFormation**: Consulte [Imponha com CloudFormation](enforce-required-tag-keys-iac.md#enforce-with-cloudformation) para ativar o gancho de conformidade de marcação
+ **Terraform**: Consulte [Aplique com o Terraform](enforce-required-tag-keys-iac.md#enforce-with-terraform) para habilitar a validação da política de tags no provedor AWS
+ **Pulumi**: Consulte [Imponha com Pulumi](enforce-required-tag-keys-iac.md#enforce-with-pulumi) para habilitar o pacote de políticas do Tag Policy Reporting
# Identifique e corrija inconsistências de marcação
Depois de implementar políticas de tags em sua organização, você pode identificar recursos com tags não compatíveis e corrigi-los para garantir a consistência em todo o seu ambiente. AWS Esta seção fornece orientação sobre como encontrar e corrigir inconsistências de marcação.
**Topics**
+ [Encontrando recursos não marcados e incorretos para sua organização com o Resource Explorer](finding-untagged-mistagged-resources.md)
+ [Corrigir tags incompatíveis em recursos](enforcement-correcting.md)
+ [Usando EventBridge a Amazon para monitorar tags não compatíveis](orgs_manage_policies_tag-policies-cwe.md)
# Encontrando recursos não marcados e incorretos para sua organização com o Resource Explorer
Para encontrar recursos não marcados em sua conta, use Explorador de recursos da AWS com uma consulta que usa`tag:none`. O Resource Explorer fornece recursos de pesquisa abrangentes para identificar recursos que não têm marcação adequada ou têm valores de tag inconsistentes em sua organização.
*Para obter instruções detalhadas sobre como usar o Resource Explorer para encontrar recursos não marcados e com marcas incorretas, consulte [Pesquisar recursos não marcados no Guia do usuário](https://docs.aws.amazon.com/resource-explorer/latest/userguide/using-search-query-examples.html#example-1).Explorador de recursos da AWS *
# Corrigir tags incompatíveis em recursos
Depois de encontrar tags incompatíveis, faça correções usando qualquer um dos seguintes métodos. Você deve estar conectado à conta que tem o recurso com tags incompatíveis:
+ Use o console ou as operações de API de marcação do AWS serviço que criou os recursos não compatíveis.
+ Use as [UntagResources](https://docs.aws.amazon.com/resourcegroupstagging/latest/APIReference/API_UntagResources.html)operações AWS Resource Groups [TagResources](https://docs.aws.amazon.com/resourcegroupstagging/latest/APIReference/API_TagResources.html)e para adicionar tags que estejam em conformidade com a política efetiva ou para remover tags não compatíveis.
# Usando EventBridge a Amazon para monitorar tags não compatíveis
Você pode usar a Amazon EventBridge, antiga Amazon CloudWatch Events, para monitorar quando tags não compatíveis são introduzidas. No evento de exemplo a seguir, o valor `"false"` da `tag-policy-compliant` indica que uma nova tag não está em conformidade com a política de tag efetiva.
```
{
"detail-type": "Tag Change on Resource",
"region": "us-east-1",
"resources": [
"arn:aws:ec2:us-east-1:123456789012:instance/i-0000000aaaaaaaaaa"
],
"detail": {
"changed-tag-keys": [
"a-new-key"
],
"service": "ec2",
"resource-type": "instance",
"version": 3,
"tag-policy-compliant": "false",
"tags": {
"a-new-key": "tag-value-on-new-key-just-added"
}
}
}
```
Você pode se inscrever em eventos e especificar strings ou padrões a serem monitorados. Para obter mais informações sobre EventBridge, consulte o *[Guia EventBridge do usuário da Amazon](https://docs.aws.amazon.com/eventbridge/latest/userguide/)*.
# Serviços e tipos de recursos compatíveis com a aplicação
Os seguintes serviços e tipos de recursos são compatíveis com a aplicação de políticas de tag:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/organizations/latest/userguide/orgs_manage_policies_supported-resources-enforcement.html)
+ Consulte a [documentação do Terraform](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/guides/tag-policy-compliance) para obter suporte ao tipo de recurso no Terraform AWS Provider.
+ Consulte a [documentação do Pulumi para obter](https://www.pulumi.com/docs/insights/policy/integrations/aws-organizations-tag-policies/#aws-provider-types) suporte a tipos de recursos no Pulumi Cloud.
# Regiões aceitas
Os recursos de política de tags estão disponíveis nas seguintes regiões:
| Nome da região | Parâmetro da região |
| --- | --- |
| Região Leste dos EUA (N. da Virgínia)¹ | **`us-east-1`** |
| Região Leste dos EUA (Ohio) | `us-east-2` |
| Região Oeste dos EUA (N. da Califórnia) | `us-west-1` |
| Região Oeste dos EUA (Oregon) | `us-west-2` |
| Região África (Cidade do Cabo)² | `af-south-1` |
| Região Ásia-Pacífico (Hong Kong)² | `ap-east-1` |
| Ásia-Pacífico (Taipei) ² | `ap-east-2` |
| Região Ásia-Pacífico (Mumbai) | `ap-south-1` |
| Asia Pacific (Hyderabad)² | `ap-south-2` |
| Região Ásia-Pacífico (Tóquio) | `ap-northeast-1` |
| Região Ásia-Pacífico (Seul) | `ap-northeast-2` |
| Região Ásia-Pacífico (Osaka) | `ap-northeast-3` |
| Região Ásia-Pacífico (Singapura) | `ap-southeast-1` |
| Região Ásia-Pacífico (Sydney) | `ap-southeast-2` |
| Região Ásia-Pacífico (Jacarta)² | `ap-southeast-3` |
| Ásia-Pacífico (Melbourne)² | `ap-southeast-4` |
| Região Ásia-Pacífico (Malásia) | `ap-southeast-5` |
| Ásia-Pacífico (Nova Zelândia) ² | `ap-southeast-6` |
| Ásia-Pacífico (Tailândia) | `ap-southeast-7` |
| Região Canadá (Central) | `ca-central-1` |
| Oeste do Canadá (Calgary)² | `ca-west-1` |
| Região da China (Pequim) | `cn-north-1` |
| Região da China (Ningxia) | `cn-northwest-1` |
| Região Europa (Frankfurt) | `eu-central-1` |
| Região Europa (Zurique)² | `eu-central-2` |
| Região Europa (Milão) | `eu-south-1` |
| Europa (Espanha)² | `eu-south-2` |
| Região Europa (Irlanda) | `eu-west-1` |
| Região Europa (Londres) | `eu-west-2` |
| Região Europa (Paris) | `eu-west-3` |
| Região Europa (Estocolmo) | `eu-north-1` |
| Região México (Centro) | `mx-central-1` |
| Região do Oriente Médio (Emirados Árabes Unidos)² | `me-central-1` |
| Região Oriente Médio (Bahrein)² | `me-south-1` |
| Região América do Sul (São Paulo) | `sa-east-1` |
| Israel (Tel Aviv)² | `il-central-1` |
| AWS GovCloud (Leste dos EUA) | `us-gov-east-1` |
| AWS GovCloud (Oeste dos EUA) | `us-gov-west-1` |
**¹É preciso especificar a Região `us-east-1` ao chamar as seguintes operações do Organizations:**
+ [DeletePolicy](https://docs.aws.amazon.com/organizations/latest/APIReference/API_DeletePolicy.html)
+ [DisablePolicyType](https://docs.aws.amazon.com/organizations/latest/APIReference/API_DisablePolicyType.html)
+ [EnablePolicyType](https://docs.aws.amazon.com/organizations/latest/APIReference/API_EnablePolicyType.html)
+ Qualquer outra operação na raiz da organização, como [ListRoots](https://docs.aws.amazon.com/organizations/latest/APIReference/API_ListRoots.html).
**Você também deve especificar a Região `us-east-1` ao chamar as seguintes operações de API de atribuição de tags de grupos de recursos que fazem parte do recurso de políticas de tag:**
+ [DescribeReportCreation](https://docs.aws.amazon.com/resourcegroupstagging/latest/APIReference/API_DescribeReportCreation.html)
+ [GetComplianceSummary](https://docs.aws.amazon.com/resourcegroupstagging/latest/APIReference/API_GetComplianceSummary.html)
+ [StartReportCreation](https://docs.aws.amazon.com/resourcegroupstagging/latest/APIReference/API_StartReportCreation.html)
**nota**
Para avaliar a compatibilidade com políticas de tag em toda a organização, também é necessário ter acesso a um bucket do Amazon S3 na região Leste dos EUA (Norte da Virgínia) para armazenamento de relatórios. Para obter mais informações, consulte a [política de bucket do Amazon S3 para armazenamento de relatórios no Guia](https://docs.aws.amazon.com/ARG/latest/userguide/tag-policies-prereqs.html#bucket-policy) do usuário de * AWS recursos de marcação*.
Essas regiões devem ser habilitadas manualmente. Para saber como habilitar e desabilitar Regiões da AWS, consulte [Especificar qual Regiões da AWS sua conta pode usar](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html) no *Guia de referência de gerenciamento de conta da AWS *. O console do Resource Groups não está disponível nessas regiões.
# Políticas de aplicativos de chat
As políticas de aplicativos de bate-papo AWS Organizations permitem que você controle o acesso às contas da sua organização a partir de aplicativos de bate-papo, como Slack e Microsoft Teams.
[O Amazon Q Developer em aplicativos de bate-papo](https://docs.aws.amazon.com/chatbot/latest/adminguide/what-is.html) é um AWS serviço que permite DevOps que equipes de desenvolvimento de software usem salas de bate-papo de programas de mensagens para monitorar e responder a eventos operacionais em seus Nuvem AWS. O Amazon Q Developer em aplicativos de bate-papo processa AWS service (Serviço da AWS) notificações do Amazon Simple Notification Service (Amazon SNS) e as encaminha para salas de bate-papo para que as equipes possam analisá-las e agir imediatamente, independentemente da localização.
## Como as políticas de aplicativos de chat funcionam
Usando as políticas de aplicativos de chat, a conta gerencial ou o administrador delegado de uma organização pode fazer o seguinte em toda a organização:
+ Determinar quais aplicações de bate-papo compatíveis (Amazon Chime, Microsoft Teams e Slack) podem ser usadas.
+ Restringir o acesso do cliente de bate-papo a espaços de trabalho específicos (Slack) e equipes (Microsoft Teams).
+ Restringir a visibilidade do canal do Slack a canais públicos ou privados.
+ Definir e aplicar [configurações de função](https://docs.aws.amazon.com/chatbot/latest/adminguide/understanding-permissions.html#role-settings) específicas.
As políticas de aplicativos de chat restringem e têm precedência sobre as configurações no nível da conta, como [configurações de perfil](https://docs.aws.amazon.com/chatbot/latest/adminguide/understanding-permissions.html#role-settings) e [políticas de barreira de proteção do canal](https://docs.aws.amazon.com/chatbot/latest/adminguide/understanding-permissions.html#channel-guardrails). Você pode acessar e modificar as políticas de aplicativos de chat no Amazon Q Developer, nos próprios aplicativos de chat ou no console do Organizations.
Depois que as políticas forem anexadas às contas e unidades organizacionais (UO), todas as configurações do Amazon Q Developer em aplicativos de chat atuais e futuras das contas no escopo estarão automaticamente em conformidade com as configurações de governança e permissões. Para obter mais informações, consulte [Entendendo a herança da política de gerenciamento](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_inheritance_mgmt.html).
Se você tentar realizar uma ação restrita por uma política de aplicativos de chat, uma mensagem de erro o notificará de que a ação não é permitida devido à política de aplicativos de chat, com a recomendação de entrar em contato com a conta gerencial ou com o administrador delegado da sua organização.
**nota**
As políticas de aplicativos de chat são validadas no runtime. Isso significa que os recursos existentes são continuamente verificados quanto à conformidade. Não há sobreposição com as permissões existentes do IAM, pois as permissões do IAM baseadas em runtime para enviar notificações ou interagir com o Amazon Q Developer em aplicativos de chat não são aceitos atualmente.
# Introdução às políticas de aplicativos de chat
Siga estas etapas para começar a usar as políticas de aplicativos de chat.
1. [Saiba mais sobre as permissões que você deve ter para executar tarefas de política de aplicativos de chat](orgs_manage_policies_prereqs.md).
1. [Habilite as políticas de aplicativos de chat para sua organização](enable-policy-type.md).
1. [Crie uma política de aplicativos de chat](orgs_policies_create.md).
1. [Vincule a política de aplicativos de chat à raiz, UO ou conta da sua organização](orgs_policies_attach.md).
1. [Veja a política de aplicativos de chat em vigor combinada que se aplica a uma conta](orgs_manage_policies_effective.md).
Para todas essas etapas, você faz login como usuário do IAM, assume um perfil do IAM ou faz login como usuário-raiz ([não recomendado](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)) na conta gerencial da organização.
**Outras informações**
+ [Aprenda sobre a sintaxe da política de aplicativos de chat e veja as políticas de exemplo](orgs_manage_policies_chatbot_syntax.md)
# Sintaxe e exemplos de políticas de aplicativos de chat
Este tópico fornece sintaxe e exemplos das políticas de aplicativos de chat
## Sintaxe para políticas de aplicativos de chat
Uma política de aplicativos de chat é um arquivo de texto sem formatação estruturado de acordo com as regras do [JSON](http://json.org). A sintaxe para políticas de aplicativos de chat segue a sintaxe para os tipos de política de gerenciamento. Para ver uma discussão completa sobre essa sintaxe, consulte [Entendendo a herança da política de gerenciamento](orgs_manage_policies_inheritance_mgmt.md). Este tópico se concentra na aplicação dessa sintaxe geral aos requisitos específicos do tipo de política de aplicativos de chat.
O exemplo a seguir mostra a sintaxe básica para uma política de aplicativos de chat:
```
{
"chatbot":{
"platforms":{
"slack":{
"client":{
"@@assign":"enabled" // enabled | disabled
},
"workspaces": { // limit 255
"@@assign":[
"Slack-Workspace-Id"
]
},
"default":{
"supported_channel_types":{
"@@assign":[
"private" // public | private
]
},
"supported_role_settings":{
"@@assign":[
"user_role" // user_role | channel_role
]
}
},
"overrides":{ // limit 255
"Slack-Workspace-Id":{
"supported_channel_types":{
"@@assign":[
"public" // public | private
]
},
"supported_role_settings":{
"@@assign":[
"user_role" // user_role | channel_role
]
}
}
}
},
"microsoft_teams":{
"client":{
"@@assign":"enabled"
},
"tenants":{ // limit 36
"Microsoft-Teams-Tenant-Id":{ // limit 36
"@@assign":[
"Microsoft-Teams-Team-Id"
]
}
},
"default":{
"supported_role_settings":{
"@@assign":[
"user_role" // user_role | channel_role
]
}
},
"overrides":{ // limit 36
"Microsoft-Teams-Tenant-Id":{ // limit 36
"Microsoft-Teams-Team-Id":{
"supported_role_settings":{
"@@assign":[
"user_role" // user_role | channel_role
]
}
}
}
}
},
"chime":{
"client":{
"@@assign":"disabled" // enabled | disabled
}
}
},
"default":{
"client":{
"@@assign":"disabled" // enabled | disabled
}
}
}
}
```
Esta política de aplicativos de chat inclui os seguintes elementos:
+ O nome da chave de campo `chatbot`. As políticas de aplicativos de chat sempre começam com esse nome de chave fixo. É a linha superior nesta política de exemplo.
+ Abaixo de `chatbot`, há um bloco de `platforms` que contém a configuração das diferentes aplicações de bate-papo compatíveis: Slack, Microsoft Teams e Amazon Chime.
+ Para o Slack, os seguintes campos estão disponíveis:
+ `"client"`:
+ `"enabled"`: o cliente do Slack está habilitado. Integrações com o Slack são permitidas.
+ `"disabled"`: o cliente do Slack está desabilitado. Integrações com o Slack não são permitidas.
+ `"workspaces"`: lista separada por vírgula dos espaços de trabalho permitidos do Slack. Neste exemplo, os espaços de trabalho permitidos do Slack são e. *Slack-Workspace-Id1* *Slack-Workspace-Id2*
+ `"default"`: as configurações padrão dos espaços de trabalho do Slack.
+ `"supported_channel_types"`:
+ `"public"`: os espaços de trabalho do Slack no escopo permitem canais públicos do Slack por padrão.
+ `"private"`: os espaços de trabalho do Slack no escopo permitem canais privados do Slack por padrão.
+ `supported_role_settings`:
+ `"user_role"`: os espaços de trabalho do Slack no escopo permitem perfis do IAM em nível de usuário por padrão.
+ `"channel_role"`: os espaços de trabalho do Slack no escopo permitem perfis de IAM em nível de canal por padrão.
+ `"overrides"`: as configurações de substituição dos espaços de trabalho do Slack.
+ `Slack-Workspace-Id2`: lista separada por vírgula dos espaços de trabalho do Slack aos quais a configuração de substituição se aplica. Neste exemplo, o espaço de trabalho do Slack é. *Slack-Workspace-Id2*
+ `"supported_channel_types"`:
+ `"public"`: substituir a configuração se os espaços de trabalho do Slack no escopo permitirem canais públicos do Slack.
+ `"private"`: substituir a configuração se os espaços de trabalho do Slack no escopo permitirem canais privados do Slack.
+ `supported_role_settings`:
+ `"user_role"`: substituir a configuração se os espaços de trabalho do Slack no escopo permitirem perfis do IAM em nível de usuário.
+ `"channel_role"`: substituir a configuração se os espaços de trabalho do Slack no escopo permitirem perfis do IAM no nível do canal.
+ Para o Microsoft Teams, os seguintes campos estão disponíveis:
+ `"client"`:
+ `"enabled"`: o cliente do Microsoft Teams está habilitado. Integrações com o Microsoft Teams são permitidas.
+ `"disabled"`: o cliente do Microsoft Teams está desabilitado. Integrações com o Microsoft Teams não são permitidas.
+ `"tenants"`: lista separada por vírgula dos locatários permitidos do Microsoft Teams. Neste exemplo, o inquilino permitido é*Microsoft-Teams-Tenant-Id*.
+ `Microsoft-Teams-Tenant-Id`: lista separada por vírgulas de equipes dentro do locatário. Neste exemplo, a equipe permitida é*Microsoft-Teams-Team-Id*.
+ `"default"`: as configurações padrão para as equipes dentro do locatário.
+ `supported_role_settings`:
+ `"user_role"`: as equipes no escopo permitem perfis do IAM em nível de usuário por padrão.
+ `"channel_role"`: as equipes no escopo permitem perfis do IAM em nível de canal por padrão.
+ `"overrides"`: as configurações de substituição para os locatários do Microsoft Teams.
+ `Microsoft-Teams-Tenant-Id`: lista separada por vírgula dos locatários aos quais a configuração de substituição se aplica. Neste exemplo, o inquilino é*Microsoft-Teams-Tenant-Id*.
+ `Microsoft-Teams-Team-Id`: lista separada por vírgula das equipes do locatário. Neste exemplo, a equipe permitida é*Microsoft-Teams-Team-Id*.
+ `supported_role_settings`:
+ `"user_role"`: substituir a configuração se as equipes no escopo permitirem perfis do IAM em nível de usuário.
+ `"channel_role"`: substituir a configuração se as equipes no escopo permitirem perfis do IAM em nível de canal.
+ Para o Amazon Chime, os seguintes campos estão disponíveis:
+ `"client"`:
+ `"enabled"`: o cliente do Amazon Chime está habilitado. Integrações com o Amazon Chime são permitidas.
+ `"disabled"`: o cliente do Amazon Chime está desabilitado. Integrações com o Amazon Chime não são permitidas.
+ Abaixo de `chatbot`, há um bloco de `default` que desabilita o Amazon Q Developer em aplicativos de chat em toda a organização, a menos que seja substituído em um nível inferior. Esse padrão também desabilita qualquer novo aplicativo de chat que o Amazon Q Developer aceita em aplicativos de chat. Por exemplo, se o Amazon Q Developer em aplicativos de chat oferecer suporte a um novo aplicativo de chat, essa configuração padrão desativará também esse novo aplicativo de chat compatível.
**nota**
Para obter mais informações sobre os perfis do IAM no nível do canal e os perfis do IAM no nível do usuário, consulte [Entender as permissões do Amazon Q Developer em aplicativos de chat](https://docs.aws.amazon.com/chatbot/latest/adminguide/understanding-permissions.html) no *Guia do Administrador para Amazon Q Developer em aplicativos de chat*.
## Exemplos de políticas de aplicativos de chat
As políticas de exemplo a seguir são apenas para fins informativos.
### Exemplo 1: permitir somente canais privados do Slack em um espaço de trabalho específico, desabilitar o Microsoft Teams, todos os modos de autenticação são compatíveis
A política a seguir se concentra em controlar as configurações permitidas para as integrações de chatbots do Slack e do Microsoft Teams.
```
{
"chatbot": {
"platforms": {
"slack": {
"client": {
"@@assign": "enabled"
},
"workspaces": {
"@@assign": [
"Slack-Workspace-Id"
]
},
"default": {
"supported_channel_types": {
"@@assign": [
"private"
]
},
"supported_role_settings": {
"@@assign": [
"channel_role",
"user_role"
]
}
}
},
"microsoft_teams": {
"client": {
"@@assign": "disabled"
}
},
"chime":{
"client":{
"@@assign":"disabled"
}
},
"default":{
"client":{
"@@assign":"disabled"
}
}
}
}
}
```
**Para Slack**
+ O cliente do Slack está habilitado.
+ Somente o espaço de trabalho específico do Slack *Slack-Workspace-Id* é permitido.
+ As configurações padrão são permitir somente canais privados do Slack, perfis do IAM no nível do canal e perfis do IAM no nível do usuário.
**Para o Microsoft Teams**
+ O cliente do Microsoft Teams está desabilitado.
**Para o Amazon Chime**
+ O cliente do Amazon Chime está desabilitado.
**Outros detalhes**
+ O bloco de `default` na parte inferior define o cliente como desabilitado, o que desabilita o Amazon Q Developer em aplicativos de chat em toda a organização, a menos que seja substituído em um nível inferior. Esse padrão também desabilita qualquer novo aplicativo de chat que o Amazon Q Developer aceita em aplicativos de chat. Por exemplo, se o Amazon Q Developer em aplicativos de chat oferecer suporte a um novo aplicativo de chat, essa configuração padrão desativará também esse novo aplicativo de chat compatível.
### Exemplo 2: permitir apenas integrações do Slack com perfis do IAM de nível de usuário
A política a seguir adota uma abordagem mais permissiva ao Slack, permitindo todos os espaços de trabalho do Slack, mas restringindo o modo de autenticação somente aos perfis do IAM em nível de usuário.
```
{
"chatbot":{
"platforms":{
"slack":{
"client":{
"@@assign":"enabled"
},
"workspaces":
{
"@@assign":[
"*"
]
},
"default":{
"supported_role_settings":{
"@@assign":[
"user_role"
]
}
}
},
"microsoft_teams":{
"client":{
"@@assign":"disabled"
}
},
"chime":{
"client":{
"@@assign":"disabled"
}
}
},
"default":{
"client":{
"@@assign":"disabled"
}
}
}
}
```
**Para o Slack**
+ O cliente do Slack está habilitado.
+ Nenhum espaço de trabalho específico do Slack é definido usando o caractere curinga `"*"`; portanto, todos os espaços de trabalho são permitidos.
+ As configurações padrão são permitir somente perfis do IAM em nível de usuário.
**Para o Microsoft Teams**
+ O cliente do Microsoft Teams está desabilitado.
**Para o Amazon Chime**
+ O cliente do Amazon Chime está desabilitado.
**Outros detalhes**
+ O bloco de `default` na parte inferior define o cliente como desabilitado, o que desabilita o Amazon Q Developer em aplicativos de chat em toda a organização, a menos que seja substituído em um nível inferior. Esse padrão também desabilita qualquer novo aplicativo de chat que o Amazon Q Developer aceita em aplicativos de chat. Por exemplo, se o Amazon Q Developer em aplicativos de chat oferecer suporte a um novo aplicativo de chat, essa configuração padrão desativará também esse novo aplicativo de chat compatível.
### Exemplo 3: permitir somente integrações do Microsoft Teams em locatários específicos
O exemplo de política a seguir bloqueia a organização para permitir apenas integrações de chatbot do Microsoft Teams dentro do locatário especificado, enquanto bloqueia completamente as integrações do Slack.
```
{
"chatbot":{
"platforms":{
"slack":{
"client": {
"@@assign": "disabled"
},
},
"microsoft_teams":{
"client": {
"@@assign": "enabled"
},
"tenants":{
"Microsoft-Teams-Tenant-Id":{
"@@assign":[
"*"
]
}
}
},
"chime": {
"client":{
"@@assign": "disabled"
}
}
}
}
}
```
**Para o Slack**
+ O cliente do Slack está desabilitado.
**Para o Microsoft Teams**
+ Somente o inquilino específico *Microsoft-Teams-Tenant-Id* é permitido, usando o curinga `"*"` para permitir todas as equipes desse inquilino.
**Para o Amazon Chime**
+ O cliente do Amazon Chime está desabilitado.
**Outros detalhes**
+ O bloco de `default` na parte inferior define o cliente como desabilitado, o que desabilita o Amazon Q Developer em aplicativos de chat em toda a organização, a menos que seja substituído em um nível inferior. Esse padrão também desabilita qualquer novo aplicativo de chat que o Amazon Q Developer aceita em aplicativos de chat. Por exemplo, se o Amazon Q Developer em aplicativos de chat oferecer suporte a um novo aplicativo de chat, essa configuração padrão desativará também esse novo aplicativo de chat compatível.
### Exemplo 4: permite acesso restrito do Amazon Q Developer em aplicativos de chat aos espaços de trabalho do Slack e a um locatário do Microsoft Teams
A política a seguir permite acesso restrito do Amazon Q Developer em aplicativos de chat a espaços de trabalho específicos do Slack e a um locatário do Microsoft Teams.
```
{
"chatbot":{
"platforms":{
"slack":{
"client":{
"@@assign":"enabled"
},
"workspaces": {
"@@assign":[
"Slack-Workspace-Id1",
"Slack-Workspace-Id2"
]
},
"default":{
"supported_channel_types":{
"@@assign":[
"private"
]
},
"supported_role_settings":{
"@@assign":[
"user_role"
]
}
},
"overrides":{
"Slack-Workspace-Id2":{
"supported_channel_types":{
"@@assign":[
"public",
"private"
]
},
"supported_role_settings":{
"@@assign":[
"channel_role",
"user_role"
]
}
}
}
},
"microsoft_teams":{
"client":{
"@@assign":"enabled"
},
"tenants":{
"Microsoft-Teams-Tenant-Id":{
"@@assign":[
"Microsoft-Teams-Team-Id"
]
}
},
"default":{
"supported_role_settings":{
"@@assign":[
"user_role"
]
}
},
"overrides":{
"Microsoft-Teams-Tenant-Id":{
"Microsoft-Teams-Team-Id":{
"supported_role_settings":{
"@@assign":[
"channel_role",
"user_role"
]
}
}
}
}
}
},
"default":{
"client":{
"@@assign":"disabled"
}
}
}
}
```
**Para o Slack**
+ O cliente do Slack está habilitado.
+ Os espaços de trabalho permitidos do Slack são e. *Slack-Workspace-Id1* *Slack-Workspace-Id2*
+ As configurações padrão do Slack são permitir apenas canais privados e perfis do IAM em nível de usuário.
+ Há uma substituição para o espaço de trabalho *Slack-Workspace-Id2* que permite canais públicos e privados, bem como funções do IAM em nível de canal e funções de IAM em nível de usuário.
**Para o Microsoft Teams**
+ O Microsoft Teams está habilitado.
+ Os inquilinos permitidos do Teams estão *Microsoft-Teams-Tenant-Id* com a equipe*Microsoft-Teams-Team-Id*.
+ As configurações padrão são para permitir somente perfis do IAM em nível de usuário.
+ Há uma substituição para o locatário *Microsoft-Teams-Tenant-Id* que permite funções de IAM em nível de canal e funções de IAM em nível de usuário para a equipe. *Microsoft-Teams-Team-Id*
**Outros detalhes**
+ O bloco de `default` na parte inferior define o cliente como desabilitado, o que desabilita o Amazon Q Developer em aplicativos de chat em toda a organização, a menos que seja substituído em um nível inferior. Isso significa que o Amazon Chime está desabilitado neste exemplo. Esse padrão também desabilita qualquer novo aplicativo de chat que o Amazon Q Developer aceita em aplicativos de chat. Por exemplo, se o Amazon Q Developer em aplicativos de chat oferecer suporte a um novo aplicativo de chat, essa configuração padrão desativará também esse novo aplicativo de chat compatível.
# Políticas de recusa de serviços de IA
AWS Os serviços de IA podem usar e armazenar o conteúdo do cliente para melhorar o serviço, como corrigir problemas operacionais, avaliar o desempenho do serviço, depurar ou treinar modelos. Para esse fim, podemos armazenar esse conteúdo Região da AWS fora de Região da AWS onde você está usando o serviço. Você pode optar por não usar seu conteúdo para melhorar o serviço usando a política AWS Organizations de exclusão.
Você pode criar políticas de desativação para um serviço de IA individual ou para todos os serviços compatíveis com IA. Você também pode consultar a política aplicável em vigor para cada conta para ver os efeitos de suas escolhas de configuração.
Para obter informações mais detalhadas, consulte [Serviços AWS de Machine Learning e Inteligência Artificial](https://aws.amazon.com/service-terms) nos Termos AWS de Serviço. Para obter uma lista dos serviços compatíveis com as políticas de exclusão de serviços de IA, consulte a [Lista de serviços de IA compatíveis](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_ai-opt-out_all.html#ai-opt-out-all-list).
**Topics**
+ [Considerações](#orgs_manage_policies-ai-opt-out-considerations)
+ [Introdução](orgs_manage_policies-ai-opt-out_getting-started.md)
+ [Recusar todos os serviços de IA](orgs_manage_policies_ai-opt-out_all.md)
+ [Sintaxe e exemplos de política de exclusão dos serviços de IA](orgs_manage_policies_ai-opt-out_syntax.md)
## Considerações ao usar políticas de recusa de serviços de IA
**A recusa exclui todo o conteúdo histórico associado**
Quando você desativa o uso do conteúdo por um serviço de AWS IA, esse serviço exclui todo o conteúdo histórico associado com o qual foi compartilhado AWS antes de você definir a opção. Essa exclusão limita-se a conteúdo armazenado que não é necessário para fornecer funções de serviço.
Por exemplo, quando você usa um serviço enquanto está ativado, esse serviço pode armazenar cópias do seu conteúdo para melhorar o serviço. Ao optar por sair, todas as cópias armazenadas pelo serviço para essa finalidade serão excluídas, mas o conteúdo utilizado para fornecer o serviço a você permanecerá ativo.
# Introdução às políticas de exclusão dos serviços de IA
Siga estas etapas para começar a usar as políticas de exclusão dos serviços de inteligência artificial (IA).
1. [Saiba mais sobre as permissões que você deve ter para executar qualquer tarefas de política de backup](orgs_manage_policies_prereqs.md).
1. [Habilitar políticas de exclusão dos serviços de IA para sua organização](enable-policy-type.md).
1. [Criar uma política de exclusão dos serviços de IA](orgs_policies_create.md#create-ai-opt-out-policy-procedure).
1. [Anexe a política de exclusão dos serviços de IA à raiz, UO ou conta da sua organização](orgs_policies_attach.md).
1. [Visualize a política combinada de exclusão dos serviços de IA em vigor que se aplica a uma conta](orgs_manage_policies_effective.md).
Em todas essas etapas, você faz login como usuário AWS Identity and Access Management (IAM), assume uma função do IAM ou faz login como usuário raiz ([não recomendado](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)) na conta de gerenciamento da organização.
**Outras informações**
+ [Aprenda a sintaxe de política para as políticas de exclusão dos serviços de IA e veja exemplos de política](orgs_manage_policies_ai-opt-out_syntax.md)
# Opte por não receber todos os serviços de AWS IA compatíveis
**Neste tópico:**
+ Você pode optar por não participar com uma seleção de um botão no AWS Organizations console.
+ Você pode optar por não participar anexando o exemplo de política fornecido usando o AWS CLI & AWS SDKs.
+ Você pode ver uma lista dos serviços Serviços da AWS suportados pela política de exclusão de serviços de IA.
## Recusar todos os serviços de IA compatíveis
Você pode recusar que o conteúdo de sua organização seja usado para melhoria de serviços criando e vinculando uma política de recusa de serviços de IA. Essa política se aplica a todos os serviços de AWS IA suportados atuais e futuros. As contas-membro não podem atualizar a política.
------
#### [ Console de gerenciamento da AWS ]
**Para recusar todos os serviços de IA**
1. Faça login no [console do AWS Organizations](https://console.aws.amazon.com/organizations/v2). Você deve fazer login como um usuário do IAM, assumir uma função do IAM ou fazer login como usuário-raiz ([não recomendado](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)) na conta de gerenciamento da organização.
1. Na página **[AI services opt-out policies](https://console.aws.amazon.com/organizations/v2/home/policies/aiservices-opt-out-policy)**, selecione **Opt out from all services**.
1. Na página de confirmação **Opt out from all services**, selecione **Opt out from all services**.
------
#### [ AWS CLI & AWS SDKs ]
**Para recusar todos os serviços de IA**
1. Cópia do “exemplo 1: excluir todos os serviços de IA para todas as contas da organização” nos [exemplos de recusa de serviços de IA](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_ai-opt-out_syntax.html#ai-opt-out-policy-examples).
1. Siga as instruções em [Vinculação e desvinculação da recusa de serviços de IA](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_ai-opt-out_attach.html).
------
**nota**
Etapas adicionais são necessárias para optar por não usar o Amazon Monitron. Para obter mais informações, consulte os [Termos de Serviço da AWS](https://aws.amazon.com/service-terms/#81._Industrial_AI_Services).
## Lista dos serviços abrangidos pela política de recusa de serviços de IA
A seguir está uma lista dos serviços Serviços da AWS suportados pela política de exclusão de serviços de IA:
+ [Operações de IA da Amazon](https://aws.amazon.com/what-is/aiops)
+ [Analytics de voz do SDK do Amazon Chime](https://docs.aws.amazon.com/chime-sdk/latest/dg/voice-analytics.html)
+ [Amazon CloudWatch](https://docs.aws.amazon.com/cloudwatch)
+ [Amazon CodeGuru Profiler](https://docs.aws.amazon.com/codeguru)
+ [Amazon CodeWhisperer](https://docs.aws.amazon.com/codewhisperer) (agora parte do [Amazon Q Developer](https://docs.aws.amazon.com/amazonq))
+ [Amazon Comprehend](https://docs.aws.amazon.com/comprehend)
+ [Amazon Connect](https://docs.aws.amazon.com/connect)
+ [Otimização do Amazon Connect](https://docs.aws.amazon.com/connect)
+ [Amazon Connect Contact Lens](https://docs.aws.amazon.com/connect/latest/adminguide/contact-lens.html)
+ [AWS Database Migration Service](https://docs.aws.amazon.com/dms)
+ [Amazon DataZone](https://docs.aws.amazon.com/datazone) (e [Amazon SageMaker Data Agent](https://docs.aws.amazon.com/sagemaker-unified-studio/latest/userguide/sagemaker-data-agent.html))
+ [Agente do AWS DevOps](https://docs.aws.amazon.com/devopsagent/latest/userguide/about-aws-devops-agent.html)
+ [AWS Entity Resolution](https://docs.aws.amazon.com/entityresolution)
+ [Amazon Fraud Detector](https://docs.aws.amazon.com/frauddetector)
+ [AWS Glue](https://docs.aws.amazon.com/glue)
+ [Amazon GuardDuty](https://docs.aws.amazon.com/guardduty)
+ [Amazon Lex](https://docs.aws.amazon.com/lex)
+ [Amazon Polly](https://docs.aws.amazon.com/polly)
+ [Amazon Q](https://docs.aws.amazon.com/amazonq)
+ [Amazon Quick](https://docs.aws.amazon.com/quicksight)
+ [Amazon Rekognition](https://docs.aws.amazon.com/rekognition)
+ [Amazon Security Lake](https://docs.aws.amazon.com/security-lake/)
+ [Cadeia de Suprimentos AWS](https://docs.aws.amazon.com/aws-supply-chain)
+ [Amazon Textract](https://docs.aws.amazon.com/textract)
+ [Amazon Transcribe](https://docs.aws.amazon.com/transcribe)
+ [AWS Transform (Transformar)](https://docs.aws.amazon.com/transform/latest/userguide/what-is.html)
+ [Amazon Translate](https://docs.aws.amazon.com/translate)
+ [Amazon WorkSpaces](https://docs.aws.amazon.com/workspaces)
+ [AWS Security Hub](https://docs.aws.amazon.com/securityhub)
# Sintaxe e exemplos de política de exclusão dos serviços de IA
Este tópico descreve a sintaxe da política de exclusão de serviços de Inteligência Artificial (IA) e fornece exemplos.
## Sintaxe para políticas de exclusão dos serviços de IA
Uma política de exclusão dos serviços de IA é um arquivo de texto sem formatação estruturado de acordo com as regras de [JSON](http://json.org). A sintaxe para políticas de exclusão dos serviços de IA segue a sintaxe para os tipos de política de gerenciamento. Para ver uma discussão completa sobre essa sintaxe, consulte [Entendendo a herança da política de gerenciamento](orgs_manage_policies_inheritance_mgmt.md). Este tópico se concentra na aplicação dessa sintaxe geral aos requisitos específicos do tipo de política de exclusão dos serviços de IA.
**Importante**
O uso de maiúsculas e minúsculas nos valores discutidos nesta seção é importante. Insira os valores com letras maiúsculas e minúsculas, conforme mostrado neste tópico. As políticas não funcionam se você usar maiúsculas e minúsculas não previstas.
A política a seguir mostra a sintaxe básica de política de exclusão dos serviços de IA. Se este exemplo fosse anexado diretamente a uma conta, essa conta seria explicitamente excluída de um serviço e incluída em outro. Outros serviços podem ser incluídos ou excluídos por políticas herdadas de níveis mais altos (UO ou políticas-raiz).
```
{
"services": {
"rekognition": {
"opt_out_policy": {
"@@assign": "optOut"
}
},
"lex": {
"opt_out_policy": {
"@@assign": "optIn"
}
}
}
}
```
Imagine o seguinte exemplo de política anexada à raiz da organização. Ele define como padrão que a organização opte pela exclusão de todos os serviços de IA. Isso inclui automaticamente quaisquer serviços de IA que não sejam explicitamente definidos como exceções de algum outro modo, incluindo quaisquer serviços de IA que a AWS possa vir a implantar no futuro. Você pode anexar políticas secundárias às contas OUs ou diretamente a elas para substituir essa configuração em qualquer serviço de IA, exceto o Amazon Comprehend. A segunda entrada no exemplo a seguir usa `@@operators_allowed_for_child_policies` definido como `none` para evitar que seja substituído. A terceira entrada no exemplo faz uma exceção em toda a organização para o Amazon Rekognition. Ela opta por esse serviço para toda a organização, mas a política permite que políticas subordinadas prevaleçam quando apropriado.
```
{
"services": {
"default": {
"opt_out_policy": {
"@@assign": "optOut"
}
},
"comprehend": {
"opt_out_policy": {
"@@operators_allowed_for_child_policies": ["@@none"],
"@@assign": "optOut"
}
},
"rekognition": {
"opt_out_policy": {
"@@assign": "optIn"
}
}
}
}
```
A sintaxe da política de exclusão dos serviços de IA inclui os seguintes elementos:
+ O elemento `services`. Uma política de exclusão dos serviços de IA é identificada por esse nome fixo como o elemento mais externo que contém JSON.
Uma política de exclusão dos serviços de IA pode ter uma ou mais instruções sob o elemento `services`. Cada instrução contém os seguintes elementos:
+ Uma *chave de nome de serviço* que identifica um serviço de AWS IA. Estes são nomes de chave válidos para esse campo:
+ **`default`** – representa **todos** os serviços de IA disponíveis no momento e inclui implícita e automaticamente quaisquer serviços de IA que possam ser vir a ser adicionados no futuro.
+ `aiops`
+ `aidevops`
+ `awssupplychain`
+ `chimesdkvoiceanalytics`
+ `cloudwatch`
+ `codeguruprofiler`
+ `codewhisperer`
+ `comprehend`
+ `connect`
+ `connectamd`
+ `connectoptimization`
+ `contactlens`
+ `datazone`
+ `dms`
+ `entityresolution`
+ `frauddetector`
+ `glue`
+ `guardduty`
+ `lex`
+ `polly`
+ `q`
+ `quicksightq`
+ `rekognition`
+ `securitylake`
+ `textract`
+ `transcribe`
+ `transform`
+ `translate`
+ `workspaces`
+ `securityhub`
Cada instrução de política identificada por uma chave de nome de serviço pode conter os seguintes elementos:
+ A chave de `opt_out_policy`. Essa chave deve estar presente. Esta é a única chave que você pode colocar sob uma chave de nome de serviço.
A chave `opt_out_policy` pode conter ***apenas*** o operador `@@assign` com um dos seguintes valores:
+ `optOut` – você opta por não ter conteúdo utilizado para o serviço de IA especificado.
+ `optIn` – você opta por ter o conteúdo utilizado para o serviço de IA especificado.
**Observações**
Não é possível usar os operadores de herança `@@append` e `@@remove` em políticas de exclusão dos serviços de IA.
Não é possível usar o operador `@@enforced_for` em políticas de exclusão dos serviços de IA.
+ Em qualquer nível, você pode especificar o operador `@@operators_allowed_for_child_policies` para controlar o que as políticas subordinadas podem fazer para substituir as configurações impostas pelas políticas superiores. É possível especificar um dos seguintes valores:
+ `@@assign` – as políticas subordinadas desta política podem usar o operador `@@assign` para substituir o valor herdado por um valor diferente.
+ `@@none` – as políticas subordinadas desta política não podem alterar o valor.
O comportamento de `@@operators_allowed_for_child_policies` depende de onde você o coloca. Você pode usar os seguintes locais:
+ Sob a chave `services` – controla se uma política subordinada pode adicionar ou alterar a lista de serviços na política em vigor.
+ Sob a chave para um serviço de IA específico ou a chave `default` - controla se uma política subordinada pode adicionar ou alterar a lista de chaves sob esta entrada específica.
+ Sob a chave `opt_out_policies` para um serviço específico – controla se uma política subordinada pode alterar apenas a configuração para este serviço específico.
## Exemplos de política de exclusão dos serviços de IA
As políticas de exemplo a seguir são apenas para fins informativos.
### Exemplo 1: Excluir todos os serviços de IA para todas as contas da organização
O exemplo a seguir mostra uma política que você pode anexar à raiz de sua organização para excluir os serviços de IA para as contas de sua organização.
**dica**
Se você copiar o exemplo a seguir usando o botão copiar no canto superior direito do exemplo, a cópia não incluirá os números de linha. Ele está pronto para colar.
```
| {
| "services": {
[1] | "@@operators_allowed_for_child_policies": ["@@none"],
| "default": {
[2] | "@@operators_allowed_for_child_policies": ["@@none"],
| "opt_out_policy": {
[3] | "@@operators_allowed_for_child_policies": ["@@none"],
| "@@assign": "optOut"
| }
| }
| }
| }
```
+ [1] – O `"@@operators_allowed_for_child_policies": ["@@none"]` que está sob `services` impede que qualquer política subordinada adicione quaisquer novas secções para serviços individuais, exceto a seção `default` que já está lá. `Default` é o espaço reservado que representa "todos os serviços de IA".
+ [2] – O `"@@operators_allowed_for_child_policies": ["@@none"]` que está sob `default` impede que qualquer política subordinada adicione quaisquer novas secções, exceto a seção `opt_out_policy` que já está lá.
+ [3] – O `"@@operators_allowed_for_child_policies": ["@@none"]` que está sob `opt_out_policy` impede que as políticas subordinadas alterem o valor da configuração de `optOut` ou adicionem quaisquer configurações adicionais.
### Exemplo 2: Definir uma configuração padrão da organização para todos os serviços, mas permitir que políticas subordinadas substituam a configuração para serviços individuais
O exemplo de política a seguir define um padrão, que abrange toda a organização, para todos os serviços de IA. O valor de `default` impede que uma política subordinada altere o valor de `optOut` para o serviço `default`, o espaço reservado para todos os serviços de IA. Se esta política for aplicada como uma política superior anexando-a à raiz ou a uma UO, as políticas subordinadas ainda poderão alterar a definição de opção de exclusão para serviços individuais, como mostrado na segunda política.
+ Como não há `"@@operators_allowed_for_child_policies": ["@@none"]` sob a chave `services`, as políticas subordinadas podem adicionar novas secções para serviços individuais.
+ O `"@@operators_allowed_for_child_policies": ["@@none"]` que está sob `default` impede que qualquer política subordinada adicione quaisquer novas secções, exceto a seção `opt_out_policy` que já está lá.
+ O `"@@operators_allowed_for_child_policies": ["@@none"]` que está sob `opt_out_policy` impede que as políticas subordinadas alterem o valor da configuração de `optOut` ou adicionem quaisquer configurações adicionais.
**Política principal de exclusão dos serviços de IA da raiz da organização**
```
{
"services": {
"default": {
"@@operators_allowed_for_child_policies": ["@@none"],
"opt_out_policy": {
"@@operators_allowed_for_child_policies": ["@@none"],
"@@assign": "optOut"
}
}
}
}
```
A política do exemplo a seguir pressupõe que a política do exemplo anterior esteja anexada à raiz da organização ou a uma UO superior, e que você anexe esse exemplo a uma conta afetada pela política superior. Ela substitui a configuração padrão de opção por exclusão e opta explicitamente pela inclusão apenas para o serviço Amazon Lex.
**Política subordinada de exclusão dos serviços de IA**
```
{
"services": {
"lex": {
"opt_out_policy": {
"@@assign": "optIn"
}
}
}
}
```
A política efetiva resultante para o Conta da AWS é que a conta opte apenas pelo Amazon Lex e opte por não receber todos os outros serviços de AWS IA devido à configuração de `default` exclusão herdada da política principal.
### Exemplo 3: Definir uma política de exclusão dos serviços de IA em toda a organização para um único serviço
O exemplo a seguir mostra uma política de exclusão dos serviços de IA que define uma configuração de `optOut` para um único serviço de IA. Se esta política for anexada à raiz da organização, impedirá que qualquer política subordinada substitua a configuração de `optOut` para esse serviço específico. Outros serviços não são abordados por esta política, mas podem ser afetados por políticas para crianças em outras contas OUs ou contas.
```
{
"services": {
"rekognition": {
"opt_out_policy": {
"@@assign": "optOut",
"@@operators_allowed_for_child_policies": ["@@none"]
}
}
}
}
```
# Políticas do Security Hub
AWS Security Hub as políticas fornecem às equipes de segurança uma abordagem centralizada para gerenciar as configurações de segurança em todos os seus. AWS Organizations Ao aproveitar essas políticas, você pode estabelecer e manter controles de segurança consistentes por meio de um mecanismo de configuração central. Essa integração permite que você resolva as lacunas de cobertura de segurança criando políticas alinhadas aos requisitos de segurança da sua organização e aplicando-as centralmente em todas as contas e unidades organizacionais ()OUs.
As políticas do Security Hub são totalmente integradas AWS Organizations, permitindo que contas de gerenciamento ou administradores delegados definam e apliquem configurações de segurança. Quando as contas ingressam na sua organização, elas herdam automaticamente as políticas aplicáveis com base em sua localização na hierarquia organizacional. Isso garante que seus padrões de segurança sejam aplicados de forma consistente à medida que a organização cresce. As políticas respeitam as estruturas organizacionais existentes e oferecem flexibilidade na forma como as configurações de segurança são distribuídas, mantendo o controle central sobre as configurações críticas de segurança.
## Principais atributos e benefícios
As políticas do Security Hub fornecem um conjunto abrangente de recursos que ajudam você a gerenciar e aplicar configurações de segurança em toda a organização AWS . Esses recursos simplificam o gerenciamento de segurança e, ao mesmo tempo, garantem um controle consistente sobre seu ambiente de várias contas.
+ [Ativar centralmente o Security Hub](https://docs.aws.amazon.com/securityhub/latest/userguide/security-hub-adv-getting-started-enable.html#security-hub-adv-getting-started-enable-org-account) em todas as contas e regiões da sua organização
+ Crie políticas de segurança que definam sua configuração de segurança em todas as contas e OUs
+ Aplicar automaticamente as configurações de segurança às novas contas quando elas ingressarem na sua organização
+ Garantir configurações de segurança consistentes em toda a sua organização
+ Impedir que as contas dos membros modifiquem as configurações de segurança no nível da organização
## Quais são as políticas do Security Hub?
As políticas do Security Hub são AWS Organizations políticas que fornecem controle centralizado sobre as configurações de segurança nas contas da sua organização. Essas políticas funcionam perfeitamente com o AWS Organizations para ajudar você a estabelecer e manter padrões de segurança consistentes em todo o seu ambiente de várias contas.
Ao implementar as políticas do Security Hub, você ganha a capacidade de definir configurações de segurança específicas que se propagam automaticamente pela sua organização. Isso garante que todas as contas, inclusive as recém-criadas, estejam alinhadas aos requisitos de segurança e às melhores práticas da sua organização.
Essas políticas também ajudam a manter a conformidade, aplicando controles de segurança consistentes e impedindo que contas individuais modifiquem as configurações de segurança em nível organizacional. Essa abordagem centralizada reduz significativamente a sobrecarga administrativa do gerenciamento de configurações de segurança em ambientes grandes e complexos. AWS
## Como as políticas de grupo de segurança funcionam no Security Hub
Quando você anexa uma política do Security Hub à sua organização ou unidade organizacional, o AWS Organizations automaticamente avalia a política e a aplica com base no escopo definido. O processo de aplicação da política segue regras específicas de resolução de conflitos:
Quando as regiões aparecem nas listas de ativação e desativação, a configuração de desativação tem precedência. Por exemplo, se uma região estiver listada nas configurações de ativação e desativação, o Security Hub será desativado nessa região.
Quando `ALL_SUPPORTED` é especificado para ativação, o Security Hub é ativado em todas as regiões atuais e futuras, a menos que seja explicitamente desativado. Isso permite que você mantenha uma cobertura de segurança abrangente à medida que AWS se expande para novas regiões.
As políticas secundárias podem modificar as configurações da política principal usando operadores de herança, permitindo um controle granular em diferentes níveis organizacionais. Essa abordagem hierárquica garante que unidades organizacionais específicas possam personalizar suas configurações de segurança enquanto mantêm os controles básicos.
## Terminologia
Este tópico usa os seguintes termos ao discutir políticas do Security Hub.
**Terminologia da política do Security Hub**
| Prazo | Definição |
| --- | --- |
| Política eficaz | A política final que se aplica a uma conta após a combinação de todas as políticas herdadas. |
| Herança de política | O processo pelo qual as contas herdam políticas das unidades organizacionais principais. |
| Administrador delegado | Uma conta designada para gerenciar as políticas do Security Hub em nome da organização. |
| Perfil vinculado a serviço | Um perfil do IAM que permite que o Security Hub interaja com outros serviços da AWS . |
## Casos de uso das políticas do Security Hub
As políticas do Security Hub abordam desafios comuns de gerenciamento de segurança em ambientes com várias contas. Os casos de uso a seguir demonstram como as organizações geralmente implementam essas políticas para aprimorar sua postura de segurança.
### Exemplo de caso de uso: requisitos regionais de conformidade
Uma empresa multinacional precisa de diferentes configurações do Security Hub para diferentes regiões geográficas. Eles criam uma política principal que habilita o Security Hub em todas as regiões usando `ALL_SUPPORTED` e, em seguida, usam políticas secundárias para desabilitar regiões específicas onde diferentes controles de segurança são necessários. Isso permite que eles mantenham a conformidade com os regulamentos regionais e, ao mesmo tempo, garantam uma cobertura de segurança abrangente.
### Exemplo de caso de uso: padrões de segurança da equipe de desenvolvimento
Uma organização de desenvolvimento de software implementa políticas do Security Hub que permitem o monitoramento nas regiões de produção e, ao mesmo tempo, mantêm as regiões de desenvolvimento sem gerenciamento. Eles usam listas de regiões explícitas em suas políticas, em vez de `ALL_SUPPORTED` manter um controle preciso sobre a cobertura do monitoramento de segurança. Essa abordagem permite que eles apliquem controles de segurança mais rígidos em ambientes de produção e, ao mesmo tempo, mantenham a flexibilidade nas áreas de desenvolvimento.
## Herança e aplicação de política
Entender como as políticas são herdadas e aplicadas é crucial para o gerenciamento eficaz da segurança em toda a organização. O modelo de herança segue a hierarquia do AWS Organizations , garantindo uma aplicação previsível e consistente da política.
+ As políticas anexadas no nível raiz se aplicam a todas as contas
+ As contas herdam políticas de suas unidades organizacionais principais
+ Várias políticas podem ser aplicadas a uma única conta
+ Políticas mais específicas (mais próximas da conta na hierarquia) têm precedência
## Validação de políticas
Ao criar políticas do Security Hub, as seguintes validações ocorrem:
+ Os nomes das regiões devem ser identificadores de AWS região válidos
+ As regiões devem ser aceitas pelo Security Hub
+ A estrutura da política deve seguir as regras AWS Organizations de sintaxe da política
+ Ambas as listas `enable_in_regions` e `disable_in_regions` devem estar presentes, embora possam estar vazias
## Considerações regionais e regiões compatíveis
As políticas do Security Hub operam em várias regiões, exigindo uma análise cuidadosa de seus requisitos globais de segurança. Compreender o comportamento regional ajuda você a implementar controles de segurança eficazes em toda a presença global da sua organização.
+ A aplicação de política ocorre em cada região de maneira independente
+ Você pode especificar quais regiões incluir ou excluir em suas políticas
+ Novas regiões são incluídas automaticamente ao usar a opção `ALL_SUPPORTED`
+ As políticas se aplicam somente às regiões em que o Security Hub está disponível
## Próximas etapas
Conceitos básicos das políticas do Security Hub:
1. Analise os pré-requisitos em Conceitos básicos das políticas do Security Hub
1. Planeje sua estratégia política usando nosso guia de práticas recomendadas
1. Aprenda sobre a sintaxe de políticas e veja exemplos de políticas
# Conceitos básicos das políticas do Security Hub
Antes de configurar as políticas do Security Hub, certifique-se de compreender os pré-requisitos e os requisitos de implementação. Este tópico orienta você no processo de configuração e gerenciamento dessas políticas em sua organização.
## Antes de começar
Analise os seguintes requisitos antes de implementar as políticas do Security Hub:
+ Sua conta deve fazer parte de uma AWS Organizations organização
+ Você deve fazer login como:
+ A conta gerencial da organização
+ Uma conta de administrador delegado com permissões para gerenciar as políticas do Security Hub
+ Você deve habilitar o acesso confiável para o Security Hub em sua organização
+ Você deve habilitar o tipo de política do Security Hub na raiz da sua organização.
Além disso, verifique se:
+ O Security Hub tem suporte nas regiões em que você deseja aplicar políticas
+ Você tem a função `AWSServiceRoleForSecurityHubV2` vinculada ao serviço configurada em sua conta gerencial. Para verificar se essa função existe, execute `aws iam get-role --role-name AWSServiceRoleForSecurityHubV2`. Se precisar criar essa função, você pode executar `aws securityhub enable-security-hub-v2` em qualquer região a partir da sua conta gerencial ou criá-la diretamente executando `aws iam create-service-linked-role --aws-service-name securityhubv2.amazonaws.com`.
## Etapas de implementação
Para implementar as políticas do Security Hub de forma eficaz, siga estas etapas em sequência. Cada etapa garante a configuração adequada e ajuda a evitar problemas comuns durante a configuração. A conta de gerenciamento ou o administrador delegado pode executar essas etapas por meio do AWS Organizations console, da Interface de Linha de AWS Comando (AWS CLI) ou. AWS SDKs
1. [Habilite o acesso confiável para o Security Hub](orgs_integrate_services.md#orgs_how-to-enable-disable-trusted-access).
1. [Habilite as políticas do Security Hub para sua organização.](enable-policy-type.md)
1. [Crie uma política do Security Hub](orgs_policies_create.md#create-security-hub-policy-procedure).
1. [Anexe a política do Security Hub à raiz, UO ou conta da sua organização](orgs_policies_attach.md).
1. [Veja a política do Security Hub em vigor combinada que se aplica a uma conta](orgs_manage_policies_effective.md).
Em todas essas etapas, você faz login como usuário AWS Identity and Access Management (IAM), assume uma função do IAM ou faz login como usuário raiz ([não recomendado](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)) na conta de gerenciamento da organização.
**Outras informações**
+ [Aprenda a sintaxe de política para as políticas do Security Hub e veja exemplos de política](orgs_manage_policies_security_hub_syntax.md)
# Práticas recomendadas para políticas do Security Hub
Ao implementar políticas do Security Hub em sua organização, seguir as práticas recomendadas estabelecidas ajuda a garantir a implantação e a manutenção bem-sucedidas de suas configurações de segurança. Essas diretrizes abordam especificamente os aspectos exclusivos do gerenciamento e aplicação de políticas do Security Hub AWS Organizations.
## Princípios de design de política
Antes de criar políticas do Security Hub, estabeleça princípios claros para sua estrutura de políticas. Mantenha as políticas simples e evite regras complexas de atributos cruzados ou aninhadas que dificultam a determinação do resultado final. Comece com políticas amplas no nível raiz da organização e refine-as por meio de políticas secundárias, quando necessário.
Considere usar listas de regiões vazias de forma estratégica. Você pode deixar `enable_in_regions` em branco quando precisar apenas desativar o Security Hub em regiões específicas ou deixar `disable_in_regions` em branco para manter as regiões não gerenciadas pela política. Essa flexibilidade ajuda você a manter um controle preciso sobre sua cobertura de monitoramento de segurança.
## Estratégias de gerenciamento de região
Ao gerenciar regiões por meio de políticas do Security Hub, considere essas abordagens comprovadas. Use `ALL_SUPPORTED` quando quiser incluir automaticamente futuras regiões em sua cobertura de segurança. Para um controle mais preciso, liste explicitamente as regiões em vez de usar `ALL_SUPPORTED`, especialmente quando diferentes regiões exigem configurações de segurança diferentes.
Documente os requisitos específicos de sua região, especialmente para:
+ Regiões exigidas pela conformidade que exigem configurações específicas
+ Diferenças entre desenvolvimento e ambiente de produção
+ Regiões opcionais com considerações especiais
+ Regiões em que o Security Hub deve permanecer desativado
## Planejamento de herança de política
Planeje cuidadosamente sua estrutura de herança de políticas para manter um controle de segurança eficaz e, ao mesmo tempo, permitir a flexibilidade necessária. Documente quais unidades organizacionais podem modificar políticas herdadas e quais modificações são permitidas. Considere restringir os operadores de herança (@@assign, @@append, @@remove) nos níveis principais quando precisar aplicar controles de segurança rígidos.
## Monitoramento e validação
Implemente práticas regulares de monitoramento para garantir que suas políticas permaneçam efetivas. Revise os anexos da política periodicamente, especialmente após mudanças organizacionais. Valide se as configurações de região correspondem à cobertura de segurança pretendida, especialmente ao usar `ALL_SUPPORTED` ou ao gerenciar várias listas de regiões.
## Estratégias para solucionar problemas
Ao solucionar problemas de políticas do Security Hub, concentre-se primeiro na precedência e herança das políticas. Lembre-se de que as configurações de desativação têm precedência sobre as configurações de ativação quando as regiões aparecem nas duas listas. Verifique as cadeias de herança de políticas para entender como as políticas de pais e filhos se combinam para criar uma política eficaz para cada conta.
# Sintaxe e exemplos de política do Security Hub
As políticas do Security Hub seguem uma sintaxe JSON padronizada que define como o Security Hub é habilitado e configurado em toda a sua organização. Compreender a estrutura de políticas ajuda você a criar políticas eficazes para seus requisitos de segurança.
## Considerações
Antes de criar políticas do Security Hub, entenda estes pontos-chave sobre a sintaxe da política:
+ As listas `enable_in_regions` e `disable_in_regions` são obrigatórias na política, embora possam estar vazias
+ Ao processar políticas efetivas, `disable_in_regions` tem precedência sobre `enable_in_regions`
+ As políticas secundárias podem modificar as políticas principais usando operadores de herança, a menos que sejam explicitamente restritas
+ A designação `ALL_SUPPORTED` inclui regiões atuais e futuras
+ Os nomes das regiões devem ser válidos e estar disponíveis no Security Hub
## Estrutura básica da política
Uma política do Security Hub usa essa estrutura básica:
```
{
"securityhub": {
"enable_in_regions": {
"@@append": ["ALL_SUPPORTED"],
"@@operators_allowed_for_child_policies": ["@@all"]
},
"disable_in_regions": {
"@@append": [],
"@@operators_allowed_for_child_policies": ["@@all"]
}
}
}
```
## Componentes da política
As políticas do Security Hub contêm esses componentes principais:
`securityhub`
O contêiner de nível superior para configurações de política
Necessário para todas as políticas do Security Hub
`enable_in_regions`
Lista de regiões em que o Security Hub deve ser ativado
Pode conter nomes de regiões específicos ou `ALL_SUPPORTED`
Campo obrigatório, mas pode estar vazio
Ao usar `ALL_SUPPORTED`, inclui futuras regiões
`disable_in_regions`
Lista de regiões em que o Security Hub deve ser desativado
Pode conter nomes de regiões específicos ou `ALL_SUPPORTED`
Campo obrigatório, mas pode estar vazio
Tem precedência sobre `enable_in_regions` quando as regiões aparecem nas duas listas
Operadores de herança
@@assign: substitui valores herdados
@@append: adiciona novos valores aos existentes
@@remove: remove valores específicos das configurações herdadas
## Exemplos de política do Security Hub
Os exemplos a seguir demonstram configurações comuns de política do Security Hub.
O exemplo abaixo ativa o Security Hub em todas as regiões atuais e futuras. Ao usar `ALL_SUPPORTED` na lista `enable_in_regions` e deixar `disable_in_regions` em branco, essa política garante uma cobertura de segurança abrangente à medida que novas regiões se tornam disponíveis.
```
{
"securityhub":{
"enable_in_regions":{
"@@assign":[
"ALL_SUPPORTED"
]
},
"disable_in_regions":{
"@@assign":[
]
}
}
}
```
Este exemplo desativa o Security Hub em todas as regiões, incluindo qualquer região futura, já que a lista `disable_in_regions` tem precedência sobre `enable_in_regions`.
```
{
"securityhub":{
"enable_in_regions":{
"@@assign":[
"us-east-1",
"us-west-2"
]
},
"disable_in_regions":{
"@@assign":[
"ALL_SUPPORTED"
]
}
}
}
```
O exemplo a seguir demonstra como as políticas secundárias podem modificar as configurações da política principal usando operadores de herança. Essa abordagem permite um controle granular e, ao mesmo tempo, manter a estrutura geral da política. A política secundária adiciona uma nova região para `enable_in_regions` e remove uma região de `disable_in_regions`.
```
{
"securityhub":{
"enable_in_regions":{
"@@append":[
"eu-central-1"
]
},
"disable_in_regions":{
"@@remove":[
"us-west-2"
]
}
}
}
```
Este exemplo mostra como habilitar o Security Hub em várias regiões específicas sem usar `ALL_SUPPORTED`. Isso fornece controle preciso sobre quais regiões têm o Security Hub ativado, enquanto deixa regiões não especificadas não gerenciadas pela política.
```
{
"securityhub":{
"enable_in_regions":{
"@@assign":[
"us-east-1",
"us-west-2",
"eu-west-1",
"ap-southeast-1"
]
},
"disable_in_regions":{
"@@assign":[
]
}
}
}
```
O exemplo a seguir demonstra como lidar com os requisitos de conformidade regionais ativando o Security Hub na maioria das regiões e, ao mesmo tempo, desativando-o explicitamente em locais específicos. A lista `disable_in_regions` tem precedência, garantindo que o Security Hub permaneça desativado nessas regiões, independentemente de outras configurações de política.
```
{
"securityhub":{
"enable_in_regions":{
"@@assign":[
"ALL_SUPPORTED"
]
},
"disable_in_regions":{
"@@assign":[
"ap-east-1",
"me-south-1"
]
}
}
}
```
# Políticas do Amazon Bedrock
As políticas do Amazon Bedrock permitem que você aplique proteções configuradas no Amazon Bedrock Guardrails automaticamente em qualquer elemento da estrutura da sua organização para todas as chamadas de inferência de modelo para o Amazon Bedrock. Isso elimina a necessidade de configurar uma proteção individual para cada conta. O Amazon Bedrock Guardrails fornece proteções configuráveis para ajudar a criar com segurança aplicativos generativos de IA em grande escala, com uma abordagem padrão para uma ampla variedade de modelos básicos, incluindo: modelos compatíveis com o Amazon Bedrock, modelos ajustados e modelos hospedados fora do Amazon Bedrock.
As políticas do Amazon Bedrock em AWS Organizations permitem que você faça referência a uma grade de proteção criada em sua conta de gerenciamento em um formato JSON. Você pode anexar qualquer política ao elemento necessário da estrutura da sua organização, como a raiz, as unidades organizacionais (OUs) e as contas individuais. AWS As organizações aplicam regras de herança para combinar as políticas, o que resulta em uma política eficaz para cada conta que determina como as proteções são aplicadas ao seu aplicativo generativo de IA.
## Como funciona
As políticas do Amazon Bedrock oferecem controle sobre a aplicação automática de proteções dentro de grades de proteção em várias contas, permitindo que você aplique barreiras de proteção em todos ou em um subconjunto de modelos para chamadas de inferência para o Amazon Bedrock. Você precisa fazer referência a uma versão específica da proteção apropriada em sua política, aderindo aos requisitos de IA responsável da sua organização. Isso é específico para a AWS região em que sua grade de proteção existe, e você precisa ter grades de proteção diferentes para cada AWS região em que deseja aplicar os controles de segurança. Em seguida, você pode anexar essa política a qualquer nó da organização, e as contas abaixo desse nó herdarão automaticamente essas proteções e as aplicarão a cada invocação de modelo no Amazon Bedrock.
As políticas do Amazon Bedrock ajudam você a garantir controles de segurança consistentes em toda a sua organização e fornecem uma abordagem centralizada para criar com segurança aplicativos generativos de IA em grande escala.
# Introdução às políticas do Amazon Bedrock
Antes de configurar as políticas do Amazon Bedrock, certifique-se de compreender os pré-requisitos e os requisitos de implementação. Este tópico orienta você no processo de configuração e gerenciamento dessas políticas em sua organização.
## Antes de começar
Analise os seguintes requisitos antes de implementar as políticas do Amazon Bedrock:
+ Sua conta deve fazer parte de uma AWS organização
+ Você deve fazer login como:
+ A conta gerencial da organização
+ Uma conta de administrador delegado com permissões para gerenciar as políticas do Amazon Bedrock
+ Você deve habilitar o tipo de política Amazon Bedrock na raiz da sua organização
## Etapas de implementação
Para implementar as políticas do Amazon Bedrock de forma eficaz, siga estas etapas em sequência. Cada etapa garante a configuração adequada e ajuda a evitar problemas comuns durante a configuração. A conta de gerenciamento ou o administrador delegado pode executar essas etapas por meio do AWS Organizations console, da Interface de Linha de AWS Comando (AWS CLI) ou. AWS SDKs
1. [Ative as políticas do Amazon Bedrock para sua organização](enable-policy-type.md).
1. [Crie uma política do Amazon Bedrock](orgs_manage_policies_bedrock_syntax.md).
1. [Anexe a política do Amazon Bedrock à raiz, UO ou conta da sua organização](orgs_policies_attach.md).
1. [Veja a política combinada efetiva do Amazon Bedrock que se aplica a uma conta](orgs_manage_policies_effective.md).
# Melhores práticas para usar as políticas do Amazon Bedrock
## Use um identificador de guardrail válido
Um identificador incorreto ou malformado fará com que todas as chamadas de API do Amazon Bedrock na organização-alvo falhem. [Monitore CloudTrail alertas de políticas eficazes inválidos para detectar configurações incorretas rapidamente](https://docs.aws.amazon.com/organizations/latest/userguide/invalid-policy-alerts.html).
## Exclua políticas de raciocínio automatizado
As barreiras de proteção que incluem uma política de raciocínio automatizado não são suportadas para a fiscalização em nível organizacional. Verifique se o Amazon Bedrock Guardrail selecionado não contém um.
## Conceda as permissões necessárias do IAM
Use as [políticas baseadas em recursos do Amazon Bedrock Guardrails](https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-resource-based-policies.html) para conceder à organização e suas contas membros permissões para avaliar a proteção aplicada em tempo de execução.
## Analise os limites do serviço Amazon Bedrock para grades de proteção
As chamadas para contas de membros usando a Amazon Bedrock Policy contarão para as Cotas de Serviço do membro. Analise o Service Quotas Console e certifique-se de que os limites de tempo de execução do Guardrails sejam suficientes para o volume de chamadas.
## Comece pequeno e depois expanda
Vincule sua política a algumas contas para começar, certificando-se de que a política esteja sendo aplicada da maneira que você espera. Certifique-se de testar se as permissões do Guardrail estão configuradas para permitir o acesso entre contas.
## Valide as alterações em suas políticas do Amazon Bedrock usando DescribeEffectivePolicy
Depois de fazer uma alteração em uma política do Amazon Bedrock, verifique as políticas efetivas para contas representativas abaixo do nível em que você fez a alteração. Você pode visualizar a política efetiva usando o AWS Management Console ou usando a operação de `DescribeEffectivePolicy` API ou uma de suas variantes de AWS CLI ou AWS SDK. Certifique-se de que a alteração feita tenha o impacto pretendido na política efetiva.
## Comunicar e treinar
Garanta que suas organizações entendam o propósito e o impacto de suas políticas do Amazon Bedrock. Forneça orientações claras sobre o comportamento do Amazon Bedrock Guardrails e o que esperar.
# Sintaxe e exemplos de políticas do Amazon Bedrock
Uma política do Amazon Bedrock é um arquivo de texto simples estruturado de acordo com as regras do JSON. A sintaxe das políticas do Amazon Bedrock segue a sintaxe de todos os tipos de políticas de gerenciamento. Para obter mais informações, consulte [Sintaxe de política e herança para tipos de política de gerenciamento](orgs_manage_policies_inheritance_mgmt.md). Este tópico se concentra na aplicação dessa sintaxe geral aos requisitos específicos do tipo de política Amazon Bedrock.
O exemplo de política do Amazon Bedrock a seguir mostra a sintaxe básica da política do Amazon Bedrock:
```
{
"bedrock": {
"guardrail_inference": {
"us-east-1": {
"config_1": {
"identifier": {
"@@assign": "arn:aws:bedrock:us-east-1:123456789012:guardrail/hu1dlsv9wy1d:1"
},
"selective_content_guarding": {
"system": {
"@@assign": "selective"
},
"messages": {
"@@assign": "comprehensive"
}
},
"model_enforcement": {
"included_models": {
"@@assign": ["ALL"]
},
"excluded_models": {
"@@assign": ["amazon.titan-embed-text-v2:0", "cohere.embed-english-v3"]
}
}
}
}
}
}
}
```
## A sintaxe da política Amazon Bedrock inclui os seguintes elementos:
`"bedrock"`
A chave de nível superior para documentos de política do Amazon Bedrock.
`"guardrail_inference"`
Define a configuração de fiscalização do guardrail.
``
A região onde a política será aplicada. Por exemplo, .`"us-east-1"`
`"config_1"`
Identificador de configuração para as configurações do guarda-corpo.
`"identifier"` (Obrigatório)
ARN do Guardrail, seguido pela `:version` versão do Guardrail.
+ O Guardrail deve pertencer à conta de gerenciamento. Você não pode criar uma política usando um Guardrail de outra conta.
+ O Guardrail deve ter uma versão, e essa versão não pode ser RASCUNHO. Para criar uma versão da sua grade de proteção, consulte [Criar uma versão de uma grade de proteção no guia do usuário do Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-versions-create.html).
+ O Guardrail deve ter uma política baseada em recursos que permita que os membros da organização liguem. `ApplyGuardrail`
+ O Guardrail deve ser criado e usado na região especificada.
`"selective_content_guarding"` (Opcional)
O Amazon Bedrock APIs permite marcar conteúdo específico na entrada que o chamador deseja que as grades de proteção processem. Essas configurações permitem que os agentes controlem se devem ou não respeitar as decisões de marcação de conteúdo tomadas pelo chamador. Quando especificado, um dos `"system"` ou `"messages"` é obrigatório.
`"system"` (Opcional)
Escolha como as solicitações do sistema serão processadas por grades de proteção. O padrão é `comprehensive` quando não especificado.
+ `"comprehensive"`: avalie todo o conteúdo, independentemente das tags de proteção de conteúdo.
+ `"selective"`: avalie somente o conteúdo dentro das tags de proteção de conteúdo. Não avalia nenhum conteúdo quando nenhuma tag é especificada.
`"messages"` (Opcional)
Escolha como o conteúdo da mensagem com a conversa do usuário e do assistente será processado por grades de proteção. O padrão é `comprehensive` quando não especificado.
+ `"comprehensive"`: avalie todo o conteúdo, independentemente das tags de proteção de conteúdo.
+ `"selective"`: avalie somente o conteúdo dentro das tags de proteção de conteúdo. Avalia todo o conteúdo das mensagens quando nenhuma tag é especificada.
`"model_enforcement"` (Opcional)
Informações específicas do modelo para a configuração forçada do guarda-corpo. Se não estiver presente, a configuração é aplicada em todos os modelos.
`"included_models"` (Obrigatório)
Lista de modelos para aplicar a grade de proteção. Quando vazio, aplica a fiscalização a todos os modelos. Também aceita a palavra-chave “ALL” para incluir explicitamente todos os modelos.
`"excluded_models"` (Obrigatório)
Modelos a serem excluídos da aplicação da grade de proteção. Quando vazio, não exclui nenhum modelo da fiscalização. Se um modelo estiver presente nas listas de modelos incluídos e excluídos, ele será excluído.
# Políticas do Amazon Inspector
As políticas do Amazon Inspector permitem que você habilite e gerencie centralmente o Amazon Inspector em todas as contas da sua organização. AWS Com uma política do Amazon Inspector, você especifica quais entidades organizacionais (raiz ou contas) têm o Amazon Inspector habilitado automaticamente e vinculado à conta de administrador delegado do Amazon Inspector. OUs Você pode usar as políticas do Amazon Inspector para simplificar a integração de todo o serviço e garantir a ativação consistente do Amazon Inspector em todas as contas existentes e recém-criadas.
## Principais características e benefícios
As políticas do Amazon Inspector permitem que você defina quais tipos de escaneamento devem ser habilitados para sua organização ou subconjuntos dela, garantindo uma cobertura consistente e reduzindo o esforço manual. Quando implementados, eles ajudam você a integrar novas contas automaticamente e a manter sua linha de base de escaneamento à medida que sua organização cresce.
## Como funciona
Quando você anexa uma política do Amazon Inspector a uma entidade organizacional, a política habilita automaticamente o Amazon Inspector para todas as contas membros dentro desse escopo. Além disso, se você finalizou a configuração do Amazon Inspector registrando um administrador delegado para o Amazon Inspector, essa conta terá visibilidade de vulnerabilidade centralizada sobre contas na organização que têm o Amazon Inspector ativado.
As políticas do Amazon Inspector podem ser aplicadas a toda a organização, a unidades organizacionais específicas (OUs) ou a contas individuais. As contas que ingressam na organização — ou se mudam para uma OU com uma política anexada do Amazon Inspector — herdam automaticamente a política e têm o Amazon Inspector ativado e vinculado ao administrador delegado do Amazon Inspector. As políticas do Amazon Inspector permitem que você habilite o escaneamento da Amazon, o EC2 escaneamento do Amazon ECR ou o Lambda Standard e o escaneamento de código, bem como a segurança do código. Configurações específicas e regras de supressão podem ser gerenciadas por meio da conta de administrador delegado da organização.
Quando você anexa uma política do Amazon Inspector à sua organização ou unidade organizacional, o AWS Organizations avalia automaticamente a política e a aplica com base no escopo que você define. O processo de aplicação da política segue regras específicas de resolução de conflitos:
+ Quando as regiões aparecem nas listas de ativação e desativação, a configuração de desativação tem precedência. Por exemplo, se uma região estiver listada nas configurações de ativação e desativação, o Amazon Inspector será desativado nessa região.
+ Quando `ALL_SUPPORTED` é especificado para ativação, o Amazon Inspector é ativado em todas as regiões atuais e futuras, a menos que seja explicitamente desativado. Isso permite que você mantenha uma cobertura abrangente à medida que AWS se expande para novas regiões.
+ As políticas secundárias podem modificar as configurações da política principal usando operadores de herança, permitindo um controle granular em diferentes níveis organizacionais. Essa abordagem hierárquica garante que unidades organizacionais específicas possam personalizar suas configurações de segurança enquanto mantêm os controles básicos.
### Terminologia
Este tópico usa os seguintes termos ao discutir as políticas do Amazon Inspector.
| Prazo | Definição |
| --- | --- |
| Política eficaz | A política final que se aplica a uma conta após a combinação de todas as políticas herdadas. |
| Herança de política | O processo pelo qual as contas herdam políticas das unidades organizacionais principais. |
| Administrador delegado | Uma conta designada para gerenciar as políticas do Amazon Inspector em nome da organização. |
| Perfil vinculado a serviço | Uma função do IAM que permite ao Amazon Inspector interagir com outros AWS serviços. |
### Casos de uso das políticas do Amazon Inspector
Organizações que lançam cargas de trabalho em grande escala em várias contas podem usar essa política para garantir que todas as contas habilitem imediatamente os tipos de verificação corretos e evitem lacunas. Ambientes regulatórios ou orientados pela conformidade podem usar políticas secundárias para anular ou limitar os tipos de escaneamento por UO. Ambientes de rápido crescimento podem automatizar a capacitação de contas recém-criadas para que estejam sempre em conformidade com a linha de base.
### Herança e aplicação de política
Entender como as políticas são herdadas e aplicadas é crucial para o gerenciamento eficaz da segurança em toda a organização. O modelo de herança segue a hierarquia da AWS Organizations, garantindo uma aplicação previsível e consistente da política.
+ As políticas anexadas no nível raiz se aplicam a todas as contas
+ As contas herdam políticas de suas unidades organizacionais principais
+ Várias políticas podem ser aplicadas a uma única conta
+ Políticas mais específicas (mais próximas da conta na hierarquia) têm precedência
### Validação de políticas
Ao criar políticas do Amazon Inspector, as seguintes validações ocorrem:
+ Os nomes das regiões devem ser identificadores de AWS região válidos
+ As regiões devem ser suportadas pelo Amazon Inspector
+ A estrutura da política deve seguir as regras de sintaxe da política da AWS Organizations
+ Ambas as listas `enable_in_regions` e `disable_in_regions` devem estar presentes, embora possam estar vazias
### Considerações regionais e regiões compatíveis
As políticas do Amazon Inspector se aplicam somente em regiões onde o acesso confiável ao Amazon Inspector AWS e à Organizations estão disponíveis. Compreender o comportamento regional ajuda você a implementar controles de segurança eficazes em toda a presença global da sua organização.
+ A aplicação de política ocorre em cada região de maneira independente
+ Você pode especificar quais regiões incluir ou excluir em suas políticas
+ Novas regiões são incluídas automaticamente ao usar a opção `ALL_SUPPORTED`
+ As políticas só se aplicam às regiões onde o Amazon Inspector está disponível
### Comportamento de desapego
Se você separar uma política do Amazon Inspector, o Amazon Inspector permanecerá habilitado nas contas cobertas anteriormente. No entanto, futuras mudanças na estrutura organizacional (como a adesão de novas contas ou a migração de contas existentes para a OU) não habilitarão mais automaticamente o Amazon Inspector. Qualquer habilitação adicional deve ser realizada manualmente ou por meio da reanexação de uma política.
## Outros detalhes
### Administrador delegado
Somente um administrador delegado pode ser registrado no Amazon Inspector em uma organização. Você deve configurar isso no console do Amazon Inspector ou via APIs antes de anexar as políticas do Amazon Inspector.
### Pré-requisitos
Você deve habilitar o acesso confiável para AWS Organizations, ter um administrador delegado para o Amazon Inspector registrado e ter funções vinculadas a serviços disponíveis em todas as contas.
### Regiões aceitas
Todas as regiões em que o Amazon Inspector está disponível.
# Introdução às políticas do Amazon Inspector
Antes de configurar as políticas do Amazon Inspector, certifique-se de entender os pré-requisitos e os requisitos de implementação. Este tópico orienta você no processo de configuração e gerenciamento dessas políticas em sua organização.
## Saiba mais sobre as permissões necessárias
Para habilitar ou anexar políticas do Amazon Inspector, você deve ter as seguintes permissões na conta de gerenciamento:
+ `organizations:EnableAWSServiceAccess` para `inspector2.amazonaws.com`
+ `organizations:RegisterDelegatedAdministrator` para `inspector2.amazonaws.com`
+ `organizations:AttachPolicy`, `organizations:CreatePolicy`, `organizations:DescribeEffectivePolicy`
+ `inspector2:Enable`(para conta de gerenciamento e administrador delegado)
## Antes de começar
Analise os seguintes requisitos antes de implementar as políticas do Amazon Inspector:
+ Sua conta deve fazer parte de uma AWS organização
+ Você deve fazer login como:
+ A conta gerencial da organização
+ Um administrador delegado da AWS Organizations com permissões para gerenciar as políticas do Amazon Inspector
+ Você deve habilitar o acesso confiável para o Amazon Inspector em sua organização
+ Você deve habilitar o tipo de política do Amazon Inspector na raiz da sua organização
Além disso, verifique se:
+ O Amazon Inspector é suportado nas regiões em que você deseja aplicar políticas
+ Você tem a função `AWSServiceRoleForInspectorV2` vinculada ao serviço configurada em sua conta gerencial. Para verificar se essa função existe, execute `aws iam get-role --role-name AWSServiceRoleForInspectorV2`. Se precisar criar essa função, você pode executar `aws inspector2 enable` em qualquer região a partir da sua conta gerencial ou criá-la diretamente executando `aws iam create-service-linked-role --aws-service-name inspector2.amazonaws.com`.
## Etapas de implementação
Para implementar as políticas do Amazon Inspector de forma eficaz, siga estas etapas em sequência. Cada etapa garante a configuração adequada e ajuda a evitar problemas comuns durante a configuração. A conta de gerenciamento ou o administrador delegado pode executar essas etapas por meio do AWS Organizations console, da Interface de Linha de AWS Comando (AWS CLI) ou. AWS SDKs
1. [Habilite o acesso confiável para o Amazon Inspector](orgs_integrate_services.md#orgs_how-to-enable-disable-trusted-access).
1. [Ative as políticas do Amazon Inspector para sua organização](enable-policy-type.md).
1. [Crie uma política do Amazon Inspector](orgs_manage_policies_inspector_syntax.md).
1. [Anexe a política do Amazon Inspector à raiz, UO ou conta da sua organização](orgs_policies_attach.md).
1. [Veja a política combinada efetiva do Amazon Inspector que se aplica a uma](orgs_manage_policies_effective.md) conta.
## Crie uma política do Amazon Inspector
### Permissões mínimas
Para criar uma política do Amazon Inspector, você precisa da seguinte permissão:
+ `organizations:CreatePolicy`
### AWS Console de gerenciamento
**Para criar uma política do Amazon Inspector**
1. Faça login no [console do AWS Organizations](https://console.aws.amazon.com/organizations/v2). Você deve fazer login como um usuário do IAM, assumir uma função do IAM ou fazer login como usuário-raiz ([não recomendado](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)) na conta de gerenciamento da organização.
1. Defina um administrador delegado para o serviço em uso no console do Amazon Inspector.
1. Depois que o administrador delegado estiver configurado para o Amazon Inspector, AWS visite o console da organização para configurar as políticas. No console AWS da organização, visite a página Políticas do Amazon Inspector e escolha **Criar** política.
1. Na página **Criar nova política do Amazon Inspector**, insira um **nome da política** e uma descrição opcional **da política**.
1. (Opcional) você pode adicionar uma ou mais tags escolhendo **Add tag (Adicionar tag)** e inserindo uma chave e um valor opcional. Se deixar o valor em branco, ele é definido como uma sequência vazia, não `null`. É possível anexar até 50 tags a uma política. Para obter mais informações, consulte [Recursos de marcação AWS OrganizationsConsiderações](orgs_tagging.md).
1. Insira ou cole o texto da política na caixa de código JSON. Para obter informações sobre a sintaxe da política do Amazon Inspector e exemplos de políticas que você pode usar como ponto de partida, consulte. [Sintaxe e exemplos de políticas do Amazon Inspector](orgs_manage_policies_inspector_syntax.md)
1. Quando terminar de editar sua política, escolha **Create policy (Criar política)** no canto inferior direito da página.
# Melhores práticas para usar as políticas do Amazon Inspector
Ao implementar as políticas do Amazon Inspector em toda a sua organização, seguir as melhores práticas estabelecidas ajuda a garantir a implantação e a manutenção bem-sucedidas.
## Comece simples e faça pequenas alterações
Comece habilitando as políticas do Amazon Inspector em uma unidade organizacional limitada (por exemplo, “Security Pilot”) para validar o comportamento esperado antes de implementá-las em todas as contas. Essa abordagem incremental permite identificar e resolver possíveis problemas em um ambiente controlado antes de uma implantação mais ampla.
## Estabeleça processos de revisão
Monitore regularmente novas contas que ingressam na sua organização e confirme se elas herdam automaticamente a habilitação do Amazon Inspector. Analise os escopos dos anexos de apólices trimestralmente para garantir que sua cobertura de segurança permaneça alinhada à sua estrutura organizacional e aos requisitos de segurança.
## Valide as alterações usando DescribeEffectivePolicy
Depois de anexar ou modificar uma política, solicite contas representativas `DescribeEffectivePolicy` para garantir que a habilitação do Amazon Inspector seja refletida adequadamente. Essa etapa de validação ajuda você a confirmar se as alterações de política têm o efeito pretendido em toda a organização.
## Comunicar e treinar
Informe aos proprietários de contas que o Amazon Inspector será ativado automaticamente e que as descobertas poderão aparecer em seus painéis do Security Hub ou do Amazon Inspector quando estiverem vinculados ao administrador delegado do Amazon Inspector. A comunicação clara ajuda a garantir que os proprietários da conta entendam o monitoramento de segurança em vigor e possam responder adequadamente às descobertas.
## Planeje sua estratégia de administrador delegado
Designe uma conta de segurança ou conformidade como administrador delegado do Amazon Inspector. Defina o administrador delegado a partir do console do Amazon Inspector ou via AWS Organizations. APIs Essa abordagem permite monitoramento e gerenciamento de segurança consistentes em toda a organização.
## Lidar com considerações regionais
Habilite o Amazon Inspector nas regiões onde suas cargas de trabalho são executadas. Considere seus requisitos de conformidade e necessidades operacionais ao determinar quais regiões exigem a cobertura do Amazon Inspector. Documente os requisitos específicos de sua região para manter um monitoramento de segurança consistente em toda a sua infraestrutura.
# Sintaxe e exemplos de políticas do Amazon Inspector
As políticas do Amazon Inspector seguem uma sintaxe JSON padronizada que define como o Amazon Inspector está habilitado e configurado em toda a sua organização. Uma política do Amazon Inspector é um documento JSON estruturado de acordo com a sintaxe da política de gerenciamento da AWS Organizations. Ele define quais entidades organizacionais terão o Amazon Inspector ativado automaticamente.
## Estrutura básica da política
Uma política do Amazon Inspector usa essa estrutura básica:
```
{
"inspector": {
"enablement": {
"ec2_scanning": {
"enable_in_regions": {
"@@assign": ["us-east-1", "us-west-2"]
},
"disable_in_regions": {
"@@assign": ["eu-west-1"]
}
}
}
}
}
```
## Componentes da política
As políticas do Amazon Inspector contêm esses componentes principais:
`inspector`
A chave de nível superior para documentos de política do Amazon Inspector, que é necessária para todas as políticas do Amazon Inspector.
`enablement`
Define como o Amazon Inspector está habilitado em toda a organização e contém configurações de tipo de escaneamento.
`Regions (Array of Strings)`
Especifica as regiões em que o Amazon Inspector deve ser ativado automaticamente.
## Exemplos de políticas do Amazon Inspector
Os exemplos a seguir demonstram configurações comuns de políticas do Amazon Inspector.
### Exemplo 1 — Ativar o Amazon Inspector em toda a organização
O exemplo a seguir habilita o Amazon Inspector em `us-east-1` e `us-west-2` para todas as contas na raiz da organização.
Crie um arquivo `inspector-policy-enable.json`:
```
{
"inspector": {
"enablement": {
"lambda_standard_scanning": {
"enable_in_regions": {
"@@assign": [
"us-east-1",
"us-west-2"
]
},
"disable_in_regions": {
"@@assign": [
"eu-west-1"
]
},
"lambda_code_scanning": {
"enable_in_regions": {
"@@assign": [
"us-east-1",
"us-west-2"
]
},
"disable_in_regions": {
"@@assign": [
"eu-west-1"
]
}
}
},
"ec2_scanning": {
"enable_in_regions": {
"@@assign": [
"us-east-1",
"us-west-2"
]
},
"disable_in_regions": {
"@@assign": [
"eu-west-1"
]
}
},
"ecr_scanning": {
"enable_in_regions": {
"@@assign": [
"us-east-1",
"us-west-2"
]
},
"disable_in_regions": {
"@@assign": [
"eu-west-1"
]
}
},
"code_repository_scanning": {
"enable_in_regions": {
"@@assign": [
"us-east-1",
"us-west-2"
]
},
"disable_in_regions": {
"@@assign": [
"eu-west-1"
]
}
}
}
}
}
```
Quando anexadas à raiz, todas as contas na organização habilitam automaticamente o Amazon Inspector, e suas descobertas de escaneamento estão disponíveis para o administrador delegado do Amazon Inspector.
Crie e anexe a política:
```
POLICY_ID=$(aws organizations create-policy \
--content file://inspector-policy-enable.json \
--name InspectorOrgPolicy \
--type INSPECTOR_POLICY \
--description "Inspector organization policy to enable all resources in IAD and PDX." \
--query 'Policy.PolicySummary.Id' \
--output text)
aws organizations attach-policy --policy-id $POLICY_ID --target-id
```
Qualquer nova conta que ingresse na organização herda automaticamente a habilitação.
Se desanexadas, as contas existentes permanecem ativadas, mas as contas futuras não são ativadas automaticamente:
```
aws organizations detach-policy --policy-id $POLICY_ID --target-id
```
### Exemplo 2 — Ativar o Amazon Inspector para uma OU específica
Crie um arquivo `inspector-policy-eu-west-1.json`:
```
{
"inspector": {
"enablement": {
"lambda_standard_scanning": {
"enable_in_regions": {
"@@assign": [
"eu-west-1"
]
},
"disable_in_regions": {
"@@assign": [
"eu-west-2"
]
},
"lambda_code_scanning": {
"enable_in_regions": {
"@@assign": [
"eu-west-1"
]
},
"disable_in_regions": {
"@@assign": [
"eu-west-2"
]
}
}
},
"ec2_scanning": {
"enable_in_regions": {
"@@assign": [
"eu-west-1"
]
},
"disable_in_regions": {
"@@assign": [
"eu-west-2"
]
}
},
"ecr_scanning": {
"enable_in_regions": {
"@@assign": [
"eu-west-1"
]
},
"disable_in_regions": {
"@@assign": [
"eu-west-2"
]
}
},
"code_repository_scanning": {
"enable_in_regions": {
"@@assign": [
"eu-west-1"
]
},
"disable_in_regions": {
"@@assign": [
"eu-west-2"
]
}
}
}
}
}
```
Anexe isso a uma OU para garantir que todas as contas de produção `eu-west-1` tenham o Amazon Inspector habilitado e vinculado ao administrador delegado do Amazon Inspector:
```
aws organizations update-policy --policy-id $POLICY_ID --content file://inspector-policy-eu-west-1.json --description "Inspector organization policy - Enable all (eu-west-1)"
aws organizations attach-policy --policy-id $POLICY_ID --target-id ou-aaaa-12345678
```
As contas fora da OU não são afetadas.
# Políticas de implantação de atualizações
AWS Organizations as políticas de implantação de atualizações permitem que você gerencie e escalone centralmente as atualizações automáticas em vários AWS recursos e contas em sua organização. Com essas políticas, você pode definir a ordem na qual os recursos recebem atualizações, garantindo que as alterações sejam validadas em ambientes menos críticos antes de chegarem à produção.
Nos complexos ambientes de nuvem atuais, gerenciar atualizações em vários recursos e contas pode ser um desafio. As políticas de implantação de atualizações abordam esse desafio fornecendo uma abordagem sistemática para a implementação de atualizações. Ao usar essas políticas, você pode alinhar seu processo de atualização às práticas de gerenciamento de mudanças da sua organização, reduzindo riscos e melhorando a eficiência operacional.
As políticas de implantação de atualizações aproveitam a estrutura hierárquica AWS Organizations para aplicar políticas em toda a organização ou em unidades organizacionais específicas (). OUs Essa integração permite gerenciar atualizações em grande escala, eliminando a necessidade de coordenação manual ou scripts de automação personalizados.
## Principais atributos e benefícios
As políticas de implantação de atualizações fornecem recursos abrangentes para gerenciar atualizações e, ao mesmo tempo, oferecem vantagens significativas para organizações que gerenciam recursos em várias contas e ambientes. A tabela a seguir descreve os principais recursos e seus benefícios associados:
**Características e benefícios das políticas de implantação de upgrade**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/organizations/latest/userguide/orgs_manage_policies_upgrade_rollout.html)
Para obter mais informações sobre herança de políticas, consulte. [Entendendo a herança da política de gerenciamento](orgs_manage_policies_inheritance_mgmt.md)
## O que são políticas de implantação de upgrade?
As políticas de implantação de atualizações são um conjunto de regras que determinam como e quando as atualizações automáticas são aplicadas aos seus recursos. AWS Essas políticas permitem que você designe diferentes pedidos de atualização para seus recursos, normalmente alinhados aos seus ambientes de desenvolvimento, teste e produção. Ao fazer isso, você pode garantir que as atualizações sejam aplicadas primeiro a sistemas menos críticos, permitindo que você identifique e resolva quaisquer problemas antes que eles afetem suas cargas de trabalho de produção.
As políticas oferecem suporte a três pedidos de upgrade: primeiro, segundo e último. Esses pedidos criam uma abordagem gradual para atualizações, com recursos designados como “Primeiro” recebendo atualizações inicialmente, seguidos por “Segundo” após um período de espera e, finalmente, “Último” após outro período de espera. Essa abordagem escalonada oferece tempo para validar as atualizações em cada estágio antes que elas avancem para sistemas mais críticos.
As políticas de implantação de atualizações são particularmente valiosas para organizações com estruturas complexas de várias contas ou com requisitos rígidos de gerenciamento de mudanças. Eles fornecem um equilíbrio entre a manutenção de up-to-date sistemas e a minimização do risco de interrupções relacionadas à atualização em serviços essenciais.
## Como as políticas de implantação de atualizações funcionam
As políticas de implantação de atualizações se integram perfeitamente à sua AWS infraestrutura e processos existentes. Quando você cria e anexa uma política de distribuição de upgrade a uma unidade organizacional, ela se aplica a todas as contas dessa OU. Em seguida, você pode usar tags de recursos ou pedidos de patch para especificar quais recursos devem ser atualizados em qual ordem.
Quando um AWS serviço suportado lança uma atualização, ele consulta as políticas de implantação da atualização para determinar a ordem na qual os recursos devem receber a atualização. O serviço primeiro aplica a atualização aos recursos marcados como “Primeiros” durante as janelas de manutenção configuradas. Após um período de espera específico do serviço, normalmente em torno de uma semana, os recursos marcados como “Segundo” se tornam elegíveis para o upgrade. Finalmente, após outro período de espera, os recursos marcados como “Últimos” recebem o upgrade.
Esse processo garante que as atualizações sejam aplicadas de forma controlada e previsível em toda a organização. Ele permite que você monitore o impacto das atualizações em cada estágio e tome medidas corretivas, se necessário, antes que as mudanças cheguem aos ambientes mais críticos. A natureza automatizada desse processo reduz a sobrecarga operacional do gerenciamento de atualizações, ao mesmo tempo em que fornece o controle e a visibilidade necessários para manter a estabilidade e a segurança de seus AWS recursos.
## Terminologia
Aqui estão os principais termos que você deve entender ao trabalhar com políticas de implantação de upgrade:
**Termos da política de implantação de upgrade**
| Prazo | Definição |
| --- | --- |
| Data ativa | A data em que o AmVu se torna visível na API Descreve Pending Maintenance Actions e está disponível para aplicação. |
| AmVu (atualização automática da versão secundária) | O processo de atualização automática para versões secundárias dos mecanismos de banco de dados. |
| Política eficaz | O conjunto final de regras que se aplicam a uma conta ou recurso depois de considerar todas as políticas herdadas e diretamente vinculadas. |
| Janela de manutenção | Um período recorrente durante o qual atualizações automáticas podem ser aplicadas a um recurso. As políticas de implantação de atualizações funcionam dentro dessas janelas de manutenção configuradas. |
| Unidade organizacional (UO) | Um contêiner para AWS contas em sua organização. As políticas de implantação de atualizações podem ser anexadas no nível da OU para afetar todas as contas dentro dela. |
| Pedido de patch | A sequência na qual os recursos recebem atualizações (primeiro, segundo, último). |
| Meta política | O escopo ao qual se aplica uma política de implantação de upgrade, que pode ser uma organização inteira, contas específicas OUs ou individuais. |
| Tags de recursos | Pares de valores-chave que podem ser usados para identificar quais recursos devem seguir ordens de atualização específicas dentro de uma política. |
| Janela de agendamento | O período durante o qual os recursos de uma ordem de patch específica recebem atualizações. |
| Período de espera específico do serviço | O intervalo de tempo designado entre a atualização de recursos de diferentes ordens de atualização. Esse período varia de acordo com o tipo de AWS serviço e upgrade. |
| Ordem de atualização | Uma designação que determina quando um recurso recebe atualizações em relação a outros recursos. Pode ser definido como Primeiro, Segundo ou Último. |
| Política de implantação do upgrade | O tipo AWS Organizations de política usado para gerenciar os cronogramas de upgrade em todos os recursos. |
## Casos de uso para políticas de implantação de upgrade
Organizações de diferentes tamanhos e setores podem se beneficiar das políticas de implantação de atualizações. Os cenários fictícios a seguir demonstram desafios comuns de gerenciamento de atualizações e como as políticas de implantação de atualizações fornecem soluções eficientes. Esses exemplos são baseados em experiências típicas de clientes, mas foram simplificados para destacar os principais benefícios e padrões de implementação.
Muitas organizações enfrentam desafios semelhantes: elas precisam manter seus recursos up-to-date com as versões mais recentes e, ao mesmo tempo, minimizar os riscos em seus ambientes de produção. Sem uma abordagem centralizada baseada em políticas, as equipes geralmente recorrem a processos manuais ou scripts complexos de automação. Os exemplos a seguir demonstram como duas organizações diferentes podem resolver desafios semelhantes usando políticas de implantação de upgrade:
### Exemplo de caso de uso: Empresa global de serviços financeiros
Uma empresa de serviços financeiros opera centenas de bancos de dados Aurora PostgreSQL em várias contas. AWS Antes das políticas de implantação de atualizações, sua DevOps equipe passava vários dias por mês coordenando manualmente as atualizações do banco de dados, garantindo que as alterações fossem testadas nos ambientes de desenvolvimento antes de chegarem aos sistemas de produção. Ao implementar políticas de implantação de upgrade, eles:
+ Bancos de dados de desenvolvimento marcados com a ordem de atualização “Primeiro”
+ Bancos de dados de controle de qualidade atribuídos para atualizar o pedido “Segundo”
+ Bancos de dados de produção designados como “último” pedido de atualização
+ Redução da coordenação de atualizações de dias para minutos
+ Primeiro, validou automaticamente as alterações em ambientes inferiores
+ Manteve a conformidade com seus requisitos de gerenciamento de mudanças
### Exemplo de caso de uso: Provedor de plataforma de dispositivos de IoT
Uma empresa de IoT processa milhões de eventos de dispositivos diariamente usando vários bancos de dados do Amazon RDS. Eles precisavam garantir que atualizações automáticas de versões secundárias não interrompessem seus serviços de produção. Usando políticas de implantação de upgrade, eles:
+ Criou uma política que se aplica a toda a estrutura organizacional
+ Ambientes canários configurados para receber atualizações primeiro
+ Configure o monitoramento em ambientes de atualização antecipada
+ Ganhou tempo para detectar e responder a quaisquer problemas antes das atualizações de produção
+ Substituiu a automação complexa de atualizações personalizadas por uma política simples
+ Manteve a alta disponibilidade de suas cargas de trabalho de produção enquanto se mantinha atualizado com as versões do banco de dados
## AWS Serviços suportados
As políticas de implantação de atualizações se integram aos seguintes AWS serviços e, ao mesmo tempo, oferecem suporte a atualizações automáticas de versões secundárias:
**Serviços compatíveis para políticas de implantação de upgrade**
| Nome do serviço | Finalidade |
| --- | --- |
| Amazon Aurora Edição Compatível com PostgreSQL | [Atualizações automáticas de versões secundárias](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html#Aurora.Maintenance.AMVU) |
| Amazon Aurora Edição Compatível com MySQL | [Atualizações automáticas de versões secundárias](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html#Aurora.Maintenance.AMVU) |
| Amazon Relational Database Service para PostgreSQL | [Atualizações automáticas de versões secundárias](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.PostgreSQL.Minor.html) |
| Amazon Relational Database Service para SQL Server | [Atualizações automáticas de versões secundárias](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.SQLServer.html) |
| Amazon Relational Database Service para Oracle | [Atualizações automáticas de versões secundárias](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.Oracle.Minor.html#oracle-minor-version-upgrade-tuning-on) |
| Amazon Relational Database Service para MariaDB | [Atualizações automáticas de versões secundárias](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.MariaDB.Minor.html) |
| Amazon Relational Database Service para MySQL | [Atualizações automáticas de versões secundárias](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.MySQL.Minor.html) |
| Amazon Relational Database Service para Db2 | [Atualizações automáticas de versões secundárias](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Db2.Concepts.VersionMgmt.html) |
## Pré-requisitos
A seguir estão os pré-requisitos e as permissões necessárias para gerenciar as políticas de implantação de upgrade em: AWS Organizations
+ AWS Organizations conta de gerenciamento ou acesso de administrador delegado
+ Recursos em serviços suportados (atualmente mecanismos de banco de dados Amazon Aurora e Amazon Relational Database Service)
+ Permissões apropriadas do IAM para gerenciar políticas de implantação de upgrade
## Próximas etapas
Para começar a usar as políticas de implantação de upgrade:
1. [Introdução às políticas de implantação de atualizações](orgs_manage_policies_upgrade_getting_started.md)Revise o para saber como criar e gerenciar políticas
1. Explore [Práticas recomendadas para usar políticas de implantação de upgrade](orgs_manage_policies_upgrade_best_practices.md) para implementar políticas de implantação de upgrade
1. Entenda [Sintaxe e exemplos da política de implantação de atualização](orgs_manage_policies_upgrade_syntax.md)
# Introdução às políticas de implantação de atualizações
Siga estas etapas para implementar políticas de implantação de atualizações em sua organização. Cada etapa está vinculada a informações detalhadas para ajudá-lo a concluir a implementação com êxito.
## Antes de começar
Certifique-se de ter o seguinte:
+ Acesso administrativo ao AWS Organizations
+ Recursos em AWS serviços compatíveis (como Aurora ou Amazon Relational Database Service)
+ Permissões necessárias do IAM configuradas
## Etapas de implementação
1. [Habilite políticas de implantação de atualizações para sua organização.](enable-policy-type.md)
1. [Entenda como as políticas de implantação de atualizações funcionam.](orgs_manage_policies_upgrade_rollout.md#orgs_manage_policies_upgrade_rollout_how_work)
+ Identifique ambientes de desenvolvimento, teste e produção
+ Determine quais recursos devem ser atualizados primeiro, segundo e último
+ Documente sua estratégia de marcação para identificação de recursos
1. [Crie uma política de implantação de upgrade](orgs_policies_create.md#create-upgrade-rollout-policy-procedure):
+ Defina a ordem de distribuição padrão (unidade organizacional ou nível da conta)
+ Especifique a segmentação por recursos usando tags
+ Configure qualquer exclusão de política
1. [Anexe uma política de implementação de upgrade a uma única conta de membro que você pode usar para testar.](orgs_policies_attach.md) :
+ Comece com uma unidade organizacional de teste
+ Verifique a herança da política
+ Confirme o status do anexo da política
1. Marque seus recursos de acordo com sua estratégia de pedido de upgrade:
+ Aplique tags aos recursos de desenvolvimento para as primeiras atualizações
+ Recursos de teste de tags para atualizações de segundo pedido
+ Designe recursos de produção para atualizações de último pedido
1. Monitore e valide a política:
+ Revise as atribuições do pedido de upgrade
+ Verifique os efeitos da política nos recursos de teste
1. Teste o processo de atualização:
+ Aguarde até que uma atualização de serviço esteja disponível
+ Monitore a progressão do upgrade em seus ambientes
+ Verifique se os upgrades seguem seu pedido especificado
1. Habilite políticas de implantação de upgrade para unidades organizacionais adicionais, conforme necessário
**Outras informações**
+ [Aprenda a sintaxe da política de implantação de atualizações e veja exemplos de políticas](orgs_manage_policies_upgrade_syntax.md)
# Práticas recomendadas para usar políticas de implantação de upgrade
AWS recomenda as seguintes melhores práticas para o uso de políticas de implantação de upgrade.
**Topics**
+ [Comece pequeno e escale gradualmente](#orgs_manage_policies_upgrade_best_practices_scale)
+ [Estabeleça processos de revisão](#orgs_manage_policies_upgrade_best_practices_review)
+ [Valide as mudanças de políticas de forma eficaz](#orgs_manage_policies_upgrade_best_practices_validate)
+ [Monitore e comunique as mudanças](#orgs_manage_policies_upgrade_best_practices_monitor)
+ [Mantenha a conformidade e a segurança](#orgs_manage_policies_upgrade_best_practices_compliance)
+ [Otimize a eficiência operacional](#orgs_manage_policies_upgrade_best_practices_optimize)
## Comece pequeno e escale gradualmente
Comece sua implementação com uma política de teste vinculada a uma única conta em um ambiente não crítico. Essa abordagem permite validar o comportamento e o impacto das políticas de implantação de upgrade sem correr o risco de interromper cargas de trabalho críticas. Depois de confirmar que a política funciona conforme o esperado, mova-a gradualmente para cima em sua estrutura organizacional para incluir mais contas e unidades organizacionais.
Esse escalonamento gradual ajuda você a identificar e resolver quaisquer problemas no início do processo de implementação. Considere criar um grupo piloto de recursos que represente a diversidade do seu ambiente, mas tenha um risco operacional mínimo. Documente os resultados de cada fase de expansão para informar futuras implementações e ajustes de políticas.
## Estabeleça processos de revisão
Implemente processos de revisão regulares para monitorar os novos atributos da política de implantação de upgrade e avaliar as exceções da política. Essas análises devem estar alinhadas aos requisitos operacionais e de segurança da sua organização. Crie um cronograma para analisar a eficácia da política e mantenha a documentação de todos os ajustes feitos.
Seu processo de análise deve incluir avaliações regulares de quais recursos são regidos por políticas, verificação de que os pedidos de upgrade estão alinhados à estratégia pretendida e avaliação de quaisquer exceções de política. Considere estabelecer critérios para quando as políticas precisam ser atualizadas e manter um registro de alterações para acompanhar a evolução das políticas ao longo do tempo.
## Valide as mudanças de políticas de forma eficaz
Depois de fazer alterações em uma política de implantação de upgrade, verifique as políticas efetivas para contas representativas em cada nível da sua organização. Use o console AWS de gerenciamento ou a operação `DescribeEffectivePolicy` da API para verificar se suas alterações têm o impacto pretendido. Essa validação deve incluir a verificação de recursos em diferentes unidades organizacionais e a confirmação de que a herança funciona conforme o esperado.
Preste atenção especial aos recursos que têm pedidos de upgrade explícitos atribuídos versus aqueles que usam valores padrão. Estabeleça uma lista de verificação de validação que inclua a verificação da segmentação baseada em tags, a confirmação dos alinhamentos das janelas de manutenção e o teste da herança de políticas.
## Monitore e comunique as mudanças
Estabeleça um monitoramento abrangente para suas políticas de implantação de upgrade e crie canais de comunicação claros para compartilhar informações relacionadas ao upgrade. Documente procedimentos claros para lidar com falhas de atualização e crie planos de resposta para diferentes cenários.
Mantenha uma comunicação regular com as equipes que gerenciam os recursos afetados pelas políticas de atualização. Considere criar painéis que forneçam visibilidade das próximas atualizações e da progressão esperada em seus ambientes.
## Mantenha a conformidade e a segurança
Audite regularmente suas políticas de implantação de upgrade para garantir que elas estejam alinhadas com seus requisitos de conformidade. Documente todas as decisões políticas e mantenha registros claros dos padrões e exceções de atualização. Implemente controles de segurança sobre modificações de políticas e mantenha uma trilha de auditoria das mudanças de políticas usando AWS CloudTrail.
Revise regularmente as permissões de acesso às funções de gerenciamento de políticas e implemente o acesso com privilégios mínimos para administração de políticas. Crie procedimentos para modificações de políticas de emergência e mantenha a documentação dos requisitos de atualização relacionados à segurança.
## Otimize a eficiência operacional
Crie suas políticas para minimizar a sobrecarga operacional e, ao mesmo tempo, manter os controles necessários. Para evitar comportamentos não intencionais, não reutilize tags em diferentes casos de uso. Automatize a verificação de conformidade de políticas sempre que possível e crie procedimentos operacionais padrão para tarefas comuns de gerenciamento de políticas.
Considere criar modelos para diferentes tipos de cenários de atualização e manter a documentação dos padrões de políticas bem-sucedidos. A revisão regular das métricas operacionais pode ajudar a identificar oportunidades de otimização de políticas e melhoria de processos.
# Sintaxe e exemplos da política de implantação de atualização
Uma política de implantação de upgrade define como AWS os serviços aplicam atualizações automáticas em seus recursos. Compreender a sintaxe da política ajuda você a criar políticas eficazes que atendam aos requisitos de atualização da sua organização.
**Topics**
+ [Considerações](#orgs_manage_policies_upgrade_syntax_considerations)
+ [Estrutura básica da política](#orgs_manage_policies_upgrade_syntax_structure)
+ [Componentes da política](#orgs_manage_policies_upgrade_syntax_components)
+ [Exemplos de políticas de implantação de upgrade](#orgs_manage_policies_upgrade_syntax_examples)
## Considerações
Ao implementar políticas de implantação de upgrade, considere estes fatores importantes:
+ Os nomes das políticas devem ser exclusivos em sua organização e devem ser claros e descritivos. Escolha nomes que reflitam a finalidade e o escopo da política. Para obter mais informações, consulte [Otimize a eficiência operacional](orgs_manage_policies_upgrade_best_practices.md#orgs_manage_policies_upgrade_best_practices_optimize).
+ Os testes são cruciais antes de uma ampla implantação. Valide primeiro as novas políticas em ambientes que não sejam de produção e expanda gradualmente para garantir o comportamento desejado. Para obter mais informações, consulte [Comece pequeno e escale gradualmente](orgs_manage_policies_upgrade_best_practices.md#orgs_manage_policies_upgrade_best_practices_scale).
+ As mudanças nas políticas podem levar várias horas para se propagar em toda a organização. Planeje suas implementações adequadamente e garanta que o monitoramento adequado esteja em vigor. Para obter mais informações, consulte [Monitore e comunique as mudanças](orgs_manage_policies_upgrade_best_practices.md#orgs_manage_policies_upgrade_best_practices_monitor).
+ A formatação JSON deve ser válida e permanecer dentro do tamanho máximo da política de 5.120 bytes. Mantenha as estruturas de políticas o mais simples possível e, ao mesmo tempo, atenda às suas necessidades.
+ As revisões regulares das políticas ajudam a manter a eficácia. Agende avaliações periódicas de suas políticas para garantir que elas continuem atendendo às suas necessidades organizacionais. Para obter mais informações, consulte [Estabeleça processos de revisão](orgs_manage_policies_upgrade_best_practices.md#orgs_manage_policies_upgrade_best_practices_review).
+ Os recursos sem um pedido de upgrade atribuído assumem como padrão o pedido “Segundo”. Considere definir explicitamente pedidos de upgrade para recursos essenciais em vez de confiar em padrões. Para obter mais informações, consulte [Valide as mudanças de políticas de forma eficaz](orgs_manage_policies_upgrade_best_practices.md#orgs_manage_policies_upgrade_best_practices_validate).
+ Os upgrades manuais têm precedência sobre os pedidos de upgrade definidos pela política. Garanta que seus processos de gerenciamento de mudanças sejam responsáveis por cenários de atualização automática e manual. Para obter mais informações, consulte [Estabeleça processos de revisão](orgs_manage_policies_upgrade_best_practices.md#orgs_manage_policies_upgrade_best_practices_review).
**nota**
Ao implementar políticas de distribuição de upgrade com base em tags em sua conta de gerenciamento, esteja ciente de que a conta de gerenciamento não pode visualizar ou acessar diretamente as tags de nível de recurso nas contas dos membros. Recomendamos estabelecer um processo em que as contas dos membros apliquem tags de recursos consistentes e, em seguida, criar políticas em nível organizacional que façam referência a essas tags. Isso garante a coordenação adequada entre a marcação em nível de recursos e a aplicação da política organizacional. Você também pode usar [Políticas de tag](orgs_manage_policies_tag-policies.md) para ajudar a manter tags consistentes quando os recursos são marcados em toda a organização.
## Estrutura básica da política
As políticas de implantação de upgrade usam uma estrutura JSON que inclui os seguintes elementos principais:
+ Metadados da política (como informações da versão)
+ Regras de segmentação de recursos
+ Especificações do pedido de atualização
+ Mensagens de exceção opcionais
+ Atributos específicos do serviço
O exemplo a seguir mostra uma estrutura básica de política de implantação de upgrade:
```
{
"upgrade_rollout":{
"default":{
"patch_order":{
"@@assign":"last"
}
},
"tags":{
"devtag":{
"tag_values":{
"tag1":{
"patch_order":{
"@@assign":"first"
}
},
"tag2":{
"patch_order":{
"@@assign":"second"
}
},
"tag3":{
"patch_order":{
"@@assign":"last"
}
}
}
}
}
}
}
```
## Componentes da política
Uma política de implantação de upgrade consiste em dois componentes principais que trabalham juntos para controlar como os upgrades são aplicados em seus recursos. Esses componentes incluem opções de configuração para comportamentos padrão e substituições baseadas em tags. Entender como esses componentes interagem ajuda você a criar políticas eficazes que atendam às suas necessidades organizacionais.
### Configuração padrão do pedido de patch
Quando você cria uma política de distribuição de atualização sem especificar nenhuma substituição específica do recurso, todos os recursos usam como padrão uma ordem básica de atualização. Você pode definir esse padrão usando o campo “padrão” em sua política. Recursos sem atribuições explícitas de pedidos de upgrade por meio de tags seguirão essa ordem padrão.
**nota**
Atualmente, a experiência do console exige que uma ordem padrão seja especificada.
O exemplo a seguir mostra como configurar todos os recursos para receber atualizações por último por padrão, a menos que sejam substituídos por tags. Essa abordagem é útil quando você deseja garantir que a maioria dos recursos seja atualizada posteriormente no ciclo de atualização:
```
"upgrade_rollout": {
"default": {
"patch_order": "last"
}
}
```
### Substituição do nível de recurso por meio de tags
Você pode substituir a ordem de atualização padrão para recursos específicos usando tags. Isso permite que você crie um controle granular sobre quais recursos recebem atualizações e em qual ordem. Por exemplo, você pode atribuir diferentes pedidos de upgrade com base nos tipos de ambiente, nos estágios de desenvolvimento ou na criticidade da carga de trabalho.
O exemplo a seguir mostra como configurar os recursos de desenvolvimento para receber os upgrades primeiro e os recursos de produção para recebê-los por último. Essa configuração garante que seus ambientes de desenvolvimento possam validar as atualizações antes que elas cheguem à produção:
```
"upgrade_rollout": {
"tags": {
"environment": {
"tag_values": {
"development": {
"patch_order": "first"
},
"production": {
"patch_order": "last"
}
}
}
}
}
```
## Exemplos de políticas de implantação de upgrade
Aqui estão os cenários comuns da política de implantação de upgrades:
### Exemplo 1: ambiente de desenvolvimento em primeiro lugar
Este exemplo mostra como configurar recursos em seu ambiente de desenvolvimento para receber atualizações primeiro. Ao direcionar recursos com a tag de ambiente “desenvolvimento”, você garante que seus ambientes de desenvolvimento sejam os primeiros a receber e validar novas atualizações. Esse padrão ajuda a identificar possíveis problemas antes que os upgrades cheguem a ambientes mais críticos:
```
{
"tags": {
"environment": {
"tag_values": {
"development": {
"upgrade_order": "first"
}
}
}
}
}
```
### Exemplo 2: último ambiente de produção
Este exemplo demonstra como garantir que seus ambientes de produção recebam atualizações por último. Ao definir explicitamente os recursos marcados de produção para o último pedido de atualização, você mantém a estabilidade em seu ambiente de produção e, ao mesmo tempo, permite testes adequados em ambientes de pré-produção. Essa abordagem é particularmente útil para organizações com requisitos rígidos de gerenciamento de mudanças:
```
{
"tags": {
"environment": {
"tag_values": {
"production": {
"upgrade_order": "last"
}
}
}
}
}
```
### Exemplo 3: vários pedidos de upgrade usando tags
O exemplo a seguir demonstra como usar uma única chave de tag com valores diferentes para especificar todos os três pedidos de upgrade. Essa abordagem é útil quando você deseja gerenciar pedidos de upgrade por meio de um único esquema de marcação:
```
{
"upgrade_rollout":{
"default":{
"patch_order":{
"@@assign":"last"
}
},
"tags":{
"devtag":{
"tag_values":{
"tag1":{
"patch_order":{
"@@assign":"first"
}
},
"tag2":{
"patch_order":{
"@@assign":"second"
}
},
"tag3":{
"patch_order":{
"@@assign":"last"
}
}
}
}
}
}
}
```
# Políticas do Amazon S3
As políticas do Amazon S3 permitem que você gerencie centralmente as configurações dos recursos do Amazon S3 em escala em todas as contas de uma organização. Atualmente, as políticas do Amazon S3 oferecem suporte a configurações para bloquear o acesso público.
Você pode usar uma política do Amazon S3 para especificar se deseja ativar ou desativar todas as quatro configurações de bloqueio de acesso público, e essa especificação se aplicará a todos os recursos do Amazon S3 nas contas selecionadas. Você pode usar as configurações de Bloquear acesso público em uma política do Amazon S3 para impor uma postura de segurança consistente em toda a sua organização e eliminar a sobrecarga operacional do gerenciamento de configurações de contas individuais.
## Como funciona
Quando você anexa uma política do Amazon S3 a uma entidade organizacional, ela define configurações que se aplicam a todos os recursos do Amazon S3 dentro das contas desse escopo. Essas configurações substituem as configurações no nível da conta, permitindo que você gerencie centralmente as configurações do Amazon S3.
As políticas do Amazon S3 podem ser aplicadas a uma organização inteira, unidades organizacionais (OUs) ou contas individuais. As contas que ingressam em uma organização herdarão automaticamente todas as políticas do Amazon S3 com base em sua localização na hierarquia da organização.
Comportamento de desvinculação: se uma política do Amazon S3 for desanexada, as contas serão automaticamente revertidas para a configuração anterior em nível de conta. O Amazon S3 preserva as configurações originais no nível da conta para permitir uma restauração perfeita.
## Recursos principais do
+ Controle unificado: todas as quatro configurações do Block Public Access (BlockPublicAcls BlockPublicPolicy IgnorePublicAcls,,, RestrictPublicBuckets) são controladas juntas como uma única configuração
+ Herança automática: as novas contas herdam automaticamente as políticas com base em seu posicionamento organizacional
+ Proteção de substituição: impede modificações no nível da conta quando as políticas da organização estão ativas
+ Restauração perfeita: as configurações originais da conta são preservadas e restauradas quando as políticas são desanexadas
## Pré-requisitos
Antes de usar as políticas do Amazon S3, verifique se você tem:
+ Uma AWS organização no modo de todos os recursos
+ Permissões para gerenciar AWS políticas de Organizations (organizações:CreatePolicy, organizações:AttachPolicy, etc.)
+ O tipo de política do Amazon S3 habilitado para sua organização
# Melhores práticas para usar as políticas do Amazon S3
Ao implementar políticas do Amazon S3 em toda a sua organização, seguir as melhores práticas estabelecidas ajuda a garantir a implantação e a manutenção bem-sucedidas.
## Comece simples e faça pequenas alterações
Para simplificar a depuração, comece com políticas simples e faça alterações em um item de cada vez. Valide o comportamento e o impacto de cada alteração antes de fazer a próxima alteração. Essa abordagem reduz o número de variáveis que você tem que considerar quando um erro ou resultado inesperado acontece.
## Estabeleça processos de revisão
Implemente processos para monitorar novos atributos de políticas, avaliar exceções de políticas e fazer ajustes para manter o alinhamento com seus requisitos operacionais e de segurança organizacional.
## Valide as alterações em suas políticas do Amazon S3 usando DescribeEffectivePolicy
Depois de fazer uma alteração em uma política do Amazon S3, verifique as políticas efetivas para contas representativas abaixo do nível em que você fez a alteração. Você pode visualizar a política efetiva usando o AWS Management Console ou usando a operação de DescribeEffectivePolicy API ou uma de suas variantes de AWS CLI ou AWS SDK. Certifique-se de que a alteração feita tenha o impacto pretendido na política efetiva.
## Comunicar e treinar
Garanta que sua organização compreenda o propósito e o impacto de suas políticas. Forneça orientações claras sobre os comportamentos esperados e como lidar com falhas devido à aplicação de políticas.
## Plano para necessidades legítimas de acesso público
Antes de implementar políticas em nível organizacional, identifique contas que exigem buckets públicos do Amazon S3 para fins comerciais legítimos (como hospedagem estática de sites). Considere usar anexos de políticas em nível de UO ou em nível de conta para excluir essas contas ou consolidar as necessidades do bucket público em contas dedicadas.
## Monitore a aplicação de políticas
Use AWS CloudTrail para monitorar a anexação de políticas e as ações de fiscalização. Configure EventBridge regras para automatizar as respostas às violações ou mudanças nas políticas.
# Sintaxe e exemplos de políticas do Amazon S3
[Uma política do Amazon S3 é um arquivo de texto simples estruturado de acordo com as regras do JSON.](http://json.org) A sintaxe das políticas do Amazon S3 segue a sintaxe de todos os tipos de políticas de gerenciamento. Para obter mais informações, consulte [Entendendo a herança da política de gerenciamento](orgs_manage_policies_inheritance_mgmt.md). Este tópico se concentra na aplicação dessa sintaxe geral aos requisitos específicos das políticas do Amazon S3 e às configurações de bloqueio de acesso público que elas ajudam a gerenciar.
O exemplo de política do Amazon S3 a seguir mostra a sintaxe básica da política:
```
{
"s3_attributes": {
"public_access_block_configuration": {
"@@assign": "all"
}
}
}
```
## A sintaxe da política do Amazon S3 inclui os seguintes elementos
`s3_attributes`
A chave de nível superior para a configuração da política do Amazon S3.
`public_access_block_configuration`
Define o comportamento do Bloqueio de Acesso Público para a organização.
`@@assign`
O operador de atribuição que aceita um dos dois valores:
+ `"all"`- Ativa todas as quatro configurações do Amazon S3 Block Public Access no nível da organização
+ `"none"`- Desativa o controle em nível organizacional, permitindo que contas individuais gerenciem suas próprias configurações de bloqueio de acesso público
O Amazon S3 Block Public Access tem quatro configurações que controlam o acesso público:
1. **BlockPublicAcls**- O Amazon S3 bloqueará as permissões de acesso público aplicadas a buckets ou objetos recém-adicionados e impedirá a criação de novas listas de controle de acesso público (ACLs) para buckets e objetos existentes. Essa configuração não altera nenhuma permissão existente que permita o acesso público aos recursos do Amazon S3 usando. ACLs
1. **BlockPublicPolicy**- O Amazon S3 bloqueará novas políticas de bucket e ponto de acesso que concedam acesso público a buckets e objetos. Essa configuração não altera nenhuma política existente que permita acesso público aos recursos do Amazon S3.
1. **IgnorePublicAcls**- O Amazon S3 ignorará tudo o ACLs que concede acesso público a buckets e objetos.
1. **RestrictPublicBuckets**- O Amazon S3 ignorará o acesso público e entre contas para buckets ou pontos de acesso com políticas que concedam acesso público a buckets e objetos.
Quando você define `@@assign``"all"`, todas as quatro configurações são consolidadas e habilitadas no nível da organização, fornecendo proteção abrangente contra o acesso público em todas as contas da sua organização.
# AWS Shield Políticas do Network Security Director
AWS Shield O Network Security Director ajuda a proteger seu AWS ambiente descobrindo seus recursos de computação, rede e segurança de rede. O Network Security Director avalia a configuração de segurança de cada recurso analisando a topologia da rede e as configurações de segurança em relação às AWS melhores práticas e à inteligência de ameaças.
AWS Shield As políticas do Network Security Director permitem que você ative e gerencie centralmente o Network Security Director em todas as contas AWS da sua organização. Com uma política do Network Security Director, você especifica quais entidades organizacionais (raiz ou contas) têm o Network Security Director habilitado. OUs Quando as contas ingressam na sua organização, elas herdam automaticamente as políticas aplicáveis com base em sua localização na hierarquia organizacional. Isso garante que seus recursos sejam analisados em busca de lacunas na configuração de segurança de rede à medida que sua organização cresce. As políticas respeitam as estruturas organizacionais existentes e oferecem flexibilidade na determinação de quais contas são analisadas.
AWS Shield O Network Security Director está atualmente disponível em versão prévia.
## Como funciona
Quando você anexa uma política do AWS Shield Network Security Director a uma entidade organizacional, a política ativa automaticamente o Network Security Director para todas as contas membros dentro desse escopo. Além disso, se você tiver finalizado a configuração do AWS Shield Network Security Director registrando um administrador delegado, essa conta terá visibilidade centralizada sobre a postura de segurança de rede das contas na organização que têm AWS Shield o Network Security Director ativado.
AWS Shield As políticas do Network Security Director podem ser aplicadas a toda a organização, a unidades organizacionais específicas (OUs) ou a contas individuais. As contas que ingressam na organização — ou migram para uma OU com uma política anexada — herdam automaticamente a política e têm o AWS Shield Network Security Director ativado e vinculado ao administrador delegado do Network Security Director. As políticas do Network Security Director permitem que você habilite uma análise de rede, visualize a topologia da rede e as descobertas de segurança de rede de seus recursos e receba recomendações de remediação para resolver lacunas de configuração. As configurações específicas e a supressão de descobertas individuais podem ser gerenciadas por meio da conta de administrador delegado do Network Security Director da organização.
Quando você anexa uma política do AWS Shield Network Security Director à sua organização ou unidade organizacional, a AWS Organizations avalia automaticamente a política e a aplica com base no escopo definido. A lógica de aplicação da política segue regras específicas de resolução de conflitos:
+ Quando as regiões aparecem nas listas de ativação e desativação, a configuração de desativação tem precedência. Por exemplo, se uma região estiver listada nas configurações de ativação e desativação, o AWS Shield Network Security Director será desativado nessa região.
+ Quando `ALL_SUPPORTED` é especificado para ativação, o AWS Shield Network Security Director é ativado em todas as regiões atuais e futuras, a menos que seja explicitamente desativado. Isso permite que você mantenha uma cobertura abrangente à medida que AWS se expande para novas regiões.
# Introdução às políticas do AWS Shield Network Security Director
Antes de configurar as políticas do Network Security Director, certifique-se de compreender os pré-requisitos e os requisitos de implementação. Este tópico orienta você no processo de configuração e gerenciamento dessas políticas em sua organização.
## Antes de começar
Analise os seguintes requisitos antes de implementar as políticas do AWS Shield Network Security Director:
+ Sua conta deve fazer parte de uma AWS organização
+ Você deve fazer login como:
+ A conta gerencial da organização
+ Um administrador delegado da AWS Organizations com permissões para gerenciar as políticas do AWS Shield Network Security Director
+ Você deve habilitar o acesso confiável para o Network Security Director em sua organização.
+ Você deve habilitar o tipo de política do Network Security Director na raiz da sua organização.
Além disso, verifique se:
+ AWS Shield O Network Security Director é suportado nas regiões em que você deseja aplicar políticas
+ Você tem a função vinculada ao serviço AWS Shield Network Security Director configurada em sua conta de gerenciamento. Se precisar criar essa função, você pode criá-la diretamente executando`aws iam create-service-linked-role --aws-service-name network-director.amazonaws.com`.
## Etapas de implementação
Para implementar as políticas do Network Security Director de forma eficaz, siga estas etapas em sequência. Cada etapa garante a configuração adequada e ajuda a evitar problemas comuns durante a configuração. Essas etapas podem ser executadas por meio do AWS Organizations console, da Interface de Linha de AWS Comando (AWS CLI) ou. AWS SDKs
1. [Habilite o acesso confiável para o AWS Shield Network Security Director](orgs_integrate_services.md#orgs_how-to-enable-disable-trusted-access).
1. [Ative as políticas do AWS Shield Network Security Director para sua organização](enable-policy-type.md).
1. [Crie uma política do AWS Shield Network Security Director](orgs_manage_policies_network_security_director_syntax.md).
1. [Anexe a política à raiz, UO ou conta da sua organização](orgs_policies_attach.md).
1. [Veja a política combinada efetiva do Network Security Director que se aplica a uma conta](orgs_manage_policies_effective.md).
# AWS Shield Sintaxe e exemplos da política do Network Security Director
As políticas do Network Security Director seguem uma sintaxe JSON padronizada que define como o Network Security Director é habilitado e configurado em toda a organização. Uma política do AWS Shield Network Security Director é um documento JSON estruturado de acordo com a sintaxe da política de gerenciamento da AWS Organizations. Ele define quais entidades organizacionais terão o AWS Shield Network Security Director ativado automaticamente.
## Estrutura básica da política
Uma política do AWS Shield Network Security Director usa essa estrutura básica:
```
{
"network_security_director": {
"enablement": {
"network_security_scan": {
"enable_in_regions": {
"@@assign": ["us-east-1", "eu-west-1"]
},
"disable_in_regions": {
"@@assign": []
}
}
},
}
}
}
```
## Componentes da política
AWS Shield As políticas do Network Security Director contêm os seguintes componentes principais:
`network_security_director`
A chave de nível superior para documentos de política do Network Security Director, que é necessária para todas as políticas do Network Security Director.
`enablement`
Define como o Network Security Director é ativado em toda a organização e contém configurações de escaneamento.
`network_security_scan`
Define a configuração de fiscalização para verificação de segurança de rede.
`enable_in_regions`
Identificador de configuração para configurações de região. Define onde a verificação de segurança da rede deve ser ativada.
`disable_in_regions`
Identificador de configuração para configurações de região. Define onde a verificação de segurança da rede deve ser desativada.