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 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.