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á.
# Proteção de dados em AWS Backup
AWS Backup está em conformidade com o [modelo de responsabilidade AWS compartilhada](https://aws.amazon.com/compliance/shared-responsibility-model/), que inclui regulamentos e diretrizes para proteção de dados. AWS é responsável por proteger a infraestrutura global que executa todos os AWS serviços. AWS mantém o controle sobre os dados hospedados nessa infraestrutura, incluindo os controles de configuração de segurança para lidar com o conteúdo do cliente e os dados pessoais. AWS clientes e AWS parceiros da Partner Network (APN), atuando como controladores ou processadores de dados, são responsáveis por quaisquer dados pessoais que coloquem no. Nuvem AWS
Para fins de proteção de dados, recomendamos que você proteja Conta da AWS as credenciais e configure contas de usuário individuais com AWS Identity and Access Management (IAM). Isto ajuda a garantir que cada usuário receberá apenas as permissões necessárias para cumprir suas obrigações de trabalho. Recomendamos também que você proteja seus dados das seguintes formas:
+ Use uma autenticação multifator (MFA) com cada conta.
+ Use o Secure Sockets Layer (SSL)/Transport Layer Security (TLS) para se comunicar com os recursos da AWS .
+ Use soluções AWS de criptografia, juntamente com todos os controles de segurança padrão nos AWS serviços.
É altamente recomendável que você nunca coloque informações de identificação confidenciais, como números de conta dos seus clientes, em campos de formato livre, como um campo **Nome**. Isso inclui quando você trabalha com AWS Backup ou outros AWS serviços usando o console, a API ou AWS SDKs. AWS CLI Todos os dados inseridos por você no AWS Backup ou em outros serviços podem ser separados para inclusão em logs de diagnóstico. Ao fornecer um URL para um servidor externo, não inclua informações de credenciais no URL para validar a solicitação a esse servidor.
Para mais informações sobre proteção de dados, consulte a publicação [Modelo de responsabilidade compartilhada da AWS e do GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) no *Blog de segurança da AWS *.
# Criptografia para backups em AWS Backup
## Criptografia independente do
AWS Backup oferece criptografia independente para [tipos de recursos que oferecem suporte ao AWS Backup gerenciamento completo](backup-feature-availability.md#features-by-resource). Criptografia independente significa que os pontos de recuperação (backups) criados por você AWS Backup podem ter um método de criptografia diferente daquele determinado pela criptografia do recurso de origem. Por exemplo, o backup de um bucket do Amazon S3 pode ter um método de criptografia diferente daquele do bucket de origem que você criptografou com a criptografia do Amazon S3. Essa criptografia é controlada por meio da configuração da AWS KMS chave no cofre de backup onde seu backup está armazenado.
Os backups de tipos de recursos que não são totalmente gerenciados por AWS Backup normalmente herdam as configurações de criptografia do recurso de origem. É possível definir essas configurações de criptografia de acordo com as instruções desse serviço, como a [criptografia do Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-encryption.html) no *Guia do usuário do Amazon EBS*.
Sua perfil do IAM deve ter acesso à chave do KMS que está sendo usada para fazer backup e restaurar o objeto. Caso contrário, o trabalho será bem-sucedido, mas os objetos não serão copiados nem restaurados. As permissões na política do IAM e na política de chave do KMS devem ser consistentes. Para obter mais informações, consulte [Especificação de chaves do KMS nas declarações de política do IAM](https://docs.aws.amazon.com/kms/latest/developerguide/cmks-in-iam-policies.html) no *Guia do desenvolvedor do *AWS Key Management Service .
A tabela a seguir lista cada tipo de recurso com suporte, como a criptografia é configurada para backups e se a criptografia independente para backups é compatível. Quando o AWS Backup criptografa um backup de forma independente, ele usa o algoritmo de criptografia AES-256 padrão do setor. Para obter mais informações sobre criptografia em AWS Backup, consulte Backup [entre regiões](cross-region-backup.md) e [entre contas](create-cross-account-backup.md).
| Tipo de atributo | Como configurar a criptografia | AWS Backup Criptografia independente |
| --- | --- | --- |
| Amazon Simple Storage Service (Amazon S3) | Os backups do Amazon S3 são criptografados usando uma chave AWS KMS (AWS Key Management Service) associada ao cofre de backup. A chave AWS KMS pode ser uma chave gerenciada pelo cliente ou uma chave AWS gerenciada associada ao serviço. AWS Backup AWS Backup criptografa todos os backups, mesmo que os buckets de origem do Amazon S3 não estejam criptografados. | Compatível |
| VMware máquinas virtuais | Os backups de VM sempre são criptografados. A chave de AWS KMS criptografia para backups de máquinas virtuais é configurada no AWS Backup cofre no qual os backups da máquina virtual são armazenados. | Compatível |
| Amazon DynamoDB após a habilitar [Backup avançado do DynamoDB](advanced-ddb-backup.md) | Os backups do DynamoDB sempre são criptografados. A chave AWS KMS de criptografia para backups do DynamoDB é configurada no cofre em que os backups AWS Backup do DynamoDB são armazenados. | Compatível |
| Amazon DynamoDB sem habilitar [Backup avançado do DynamoDB](advanced-ddb-backup.md) | Os backups do DynamoDB são criptografados automaticamente com a mesma chave de criptografia que foi usada para criptografar a tabela de origem do DynamoDB. Os snapshots das tabelas não criptografadas do DynamoDB também não são criptografados. AWS Backup Para criar um backup de uma tabela criptografada do DynamoDB, você deve adicionar `kms:Decrypt` as permissões `kms:GenerateDataKey` e a função do IAM usada para backup. Como alternativa, você pode usar a função de serviço AWS Backup padrão. | Não compatível |
| Amazon Elastic File System (Amazon EFS) | Os backups do Amazon EFS sempre são criptografados. A chave de AWS KMS criptografia para backups do Amazon EFS é configurada no AWS Backup cofre em que os backups do Amazon EFS são armazenados. | Compatível |
| Amazon Elastic Block Store (Amazon EBS) | Por padrão, os backups do Amazon EBS são criptografados usando a chave usada para criptografar o volume de origem ou não são criptografados. Durante a restauração, é possível optar por substituir o método de criptografia padrão especificando uma chave do KMS. | Não compatível |
| Amazon Elastic Compute Cloud (Amazon EC2) AMIs | AMIs não são criptografados. Os snapshots do EBS são criptografados pelas regras de criptografia padrão para backups do EBS (consulte a entrada do EBS). Os snapshots de volumes raiz e de dados podem ser criptografados e anexados a uma AMI. | Não compatível |
| Amazon Relational Database Service (Amazon RDS) | Os snapshots do Amazon RDS são criptografados automaticamente com a mesma chave de criptografia que foi usada para criptografar banco de dados de origem do Amazon RDS. Os snapshots de bancos de dados do Amazon RDS não criptografados também não são criptografados. | Não compatível |
| Amazon Aurora | Os snapshots do cluster do Aurora são criptografados automaticamente com a mesma chave de criptografia que foi usada para criptografar o cluster de origem do Amazon Aurora. Os snapshots de clusters não criptografados do Aurora também não são criptografados. | Não compatível |
| AWS Storage Gateway | Os snapshots do Storage Gateway são criptografados automaticamente com a mesma chave de criptografia que foi usada para criptografar o volume de origem do Storage Gateway. Os snapshots de volumes não criptografados do Storage Gateway também não são criptografados. Não é necessário usar uma chave gerenciada pelo do cliente em todos os serviços para habilitar o Storage Gateway. Só é necessário copiar o backup do Storage Gateway em um cofre que configurou uma chave do KMS. Isso ocorre porque o Storage Gateway não tem uma chave AWS KMS gerenciada específica do serviço. | Não compatível |
| Amazon FSx | Os recursos de criptografia dos sistemas de FSx arquivos da Amazon diferem com base no sistema de arquivos subjacente. Para saber mais sobre seu sistema de FSx arquivos específico da Amazon, consulte o [Guia FSx do usuário](https://docs.aws.amazon.com/fsx/) apropriado. | Não compatível |
| Amazon DocumentDB | Os snapshots do cluster do Amazon DocumentDB são criptografados automaticamente com a mesma chave de criptografia que foi usada para criptografar o cluster de origem do Amazon DocumentDB. Os snapshots de clusters não criptografados do Amazon DocumentDB também não são criptografados. | Não compatível |
| Amazon Neptune | Os snapshots do cluster do Neptune são criptografados automaticamente com a mesma chave de criptografia que foi usada para criptografar o cluster de origem do Neptune. Os snapshots de clusters não criptografados do Neptune também não são criptografados. | Não compatível |
| Amazon Timestream | Os backups de snapshots de tabelas do Timestream são sempre criptografados. A chave de AWS KMS criptografia para backups do Timestream é configurada no cofre de backup no qual os backups do Timestream são armazenados. | Compatível |
| banco de dados de origem | Os snapshots do cluster do Amazon Redshift são criptografados automaticamente com a mesma chave de criptografia que foi usada para criptografar o cluster de origem do Amazon Redshift. Os snapshots de clusters não criptografados do Amazon Redshift também não são criptografados. | Não compatível |
| Amazon Redshift Sem Servidor | Os snapshots do Redshift sem servidor são criptografados automaticamente com a mesma chave de criptografia que foi usada para criptografar a origem. | Não compatível |
| CloudFormation | CloudFormation os backups são sempre criptografados. A chave de CloudFormation criptografia para CloudFormation backups é configurada no CloudFormation cofre no qual os CloudFormation backups são armazenados. | Compatível |
| Backup de bancos de dados SAP HANA em instâncias do Amazon EC2 | Os backups do banco de dados SAP HANA são sempre criptografados. A chave de AWS KMS criptografia para backups do banco de dados SAP HANA é configurada no AWS Backup cofre no qual os backups do banco de dados são armazenados. | Compatível |
**dica**
AWS Backup O [Audit Manager](https://docs.aws.amazon.com/aws-backup/latest/devguide/aws-backup-audit-manager.html) ajuda você a detectar automaticamente backups não criptografados.
## Criptografia para cópias de um backup em uma conta diferente ou Região da AWS
Quando você copia seus backups entre contas ou regiões, criptografa AWS Backup automaticamente essas cópias para a maioria dos tipos de recursos, mesmo que o backup original não esteja criptografado. AWS Backup criptografa a cópia usando a chave KMS do cofre de destino.
Antes de copiar um backup de uma conta para outra (trabalho de cópia entre contas) ou copiar um backup de uma região para outra (trabalho de cópia entre regiões), observe as seguintes condições, muitas das quais dependem do tipo de recurso no backup (ponto de recuperação) ser [totalmente gerenciado AWS Backup ou não](backup-feature-availability.md#features-by-resource).
+ Uma cópia de um backup para outro Região da AWS é criptografada usando a chave do cofre de destino.
+ Para obter uma cópia de um ponto de recuperação (backup) de um recurso **totalmente gerenciado pelo AWS Backup**, você pode optar por criptografá-lo com uma [chave gerenciada pelo cliente (CMK)](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) ou uma chave AWS Backup gerenciada (`aws/backup`).
Para uma cópia de um ponto de recuperação de um recurso que **não é totalmente gerenciado** pelo AWS Backup, a chave associada ao cofre de destino deve ser uma CMK ou a chave gerenciada do serviço que possui o recurso subjacente. Por exemplo, se você estiver copiando uma instância do EC2, uma chave gerenciada pelo Backup não poderá ser usada. Em vez disso, uma CMK ou uma chave do KMS para o Amazon EBS KMS (`aws/ebs`) deve ser usada para evitar falhas no trabalho de cópia.
+ A cópia entre contas com chaves AWS gerenciadas não é compatível com recursos que não são totalmente gerenciados pelo AWS Backup. A [política de chaves](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) de uma chave gerenciada pela AWS é imutável, o que impede a cópia da chave entre contas. Se seus recursos estiverem criptografados com chaves AWS gerenciadas e você quiser realizar uma cópia entre contas, você poderá [alterar as chaves de criptografia](https://repost.aws/knowledge-center/update-encryption-key-rds) para uma chave gerenciada pelo cliente, que pode ser usada para cópia entre contas. Ou você pode seguir as instruções em [Proteção de instâncias criptografadas do Amazon RDS com backups entre contas e regiões para continuar usando AWS chaves gerenciadas](https://aws.amazon.com/blogs/storage/protecting-encrypted-amazon-rds-instances-with-cross-account-and-cross-region-backups/).
+ As cópias de clusters não criptografados do Amazon Aurora, do Amazon DocumentDB e do Amazon Neptune também não são criptografadas.
## AWS Backup declarações de permissões, concessões e negação
Para ajudar a evitar trabalhos malsucedidos, você pode examinar a política AWS KMS principal para garantir que ela tenha as permissões necessárias e não tenha nenhuma declaração de negação que impeça operações bem-sucedidas.
Podem ocorrer falhas nos trabalhos devido a uma ou mais declarações de negação aplicadas à chave do KMS ou devido a uma [concessão](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html) revogada para a chave.
Em uma política de acesso AWS gerenciado [https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupFullAccess.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBackupFullAccess.html), como a de Permitir, ações que permitem AWS Backup a interface com AWS KMS a criação de uma concessão de uma chave KMS em nome do cliente, como parte das operações de backup, cópia e armazenamento.
A política de chave exige, no mínimo, as seguintes permissões:
+ `kms:createGrant`
+ `kms:generateDataKey`
+ `kms:decrypt`
Se as políticas de negação forem necessárias, você precisará permitir os perfis exigidos para operações de backup e restauração.
Esses elementos podem ser semelhantes a:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "KmsPermissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Action": [
"kms:ListKeys",
"kms:DescribeKey",
"kms:GenerateDataKey",
"kms:ListAliases"
],
"Resource": "*"
},
{
"Sid": "KmsCreateGrantPermissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Action": [
"kms:CreateGrant"
],
"Resource": "*",
"Condition": {
"ForAnyValue:StringEquals": {
"kms:EncryptionContextKeys": "aws:backup:backup-vault"
},
"Bool": {
"kms:GrantIsForAWSResource": true
},
"StringLike": {
"kms:ViaService": "backup.*.amazonaws.com"
}
}
}
]
}
```
------
Essas permissões devem fazer parte da chave, seja ela AWS gerenciada ou gerenciada pelo cliente.
1. Certifique-se de que as permissões exigidas façam parte da política de chave do KMS
1. Execute a CLI `get-key-policy` do KMS ([https://docs.aws.amazon.com/kms/latest/APIReference/API_GetKeyPolicy.html](https://docs.aws.amazon.com/kms/latest/APIReference/API_GetKeyPolicy.html)) para visualizar a política de chave anexada à chave do KMS especificada.
1. Revise as permissões retornadas.
1. Certifique-se de que não haja declarações de negação que afetem as operações
1. Execute (ou execute novamente) a CLI `get-key-policy` do KMS ([https://docs.aws.amazon.com/kms/latest/APIReference/API_GetKeyPolicy.html](https://docs.aws.amazon.com/kms/latest/APIReference/API_GetKeyPolicy.html)) para visualizar a política de chave anexada à chave do KMS especificada.
1. Revise a política.
1. Remova as declarações de negação relevantes da política de chave do KMS.
1. Se necessário, execute [https://docs.aws.amazon.com/kms/latest/APIReference/API_PutKeyPolicy.html](https://docs.aws.amazon.com/kms/latest/APIReference/API_PutKeyPolicy.html) para substituir ou atualizar a política de chave com permissões revisadas e declarações de negação removidas.
Além disso, a chave associada ao perfil que inicia um trabalho de cópia entre regiões deve ter `"kms:ResourcesAliases": "alias/aws/backup"` na permissão `DescribeKey`.
# Criptografia de credenciais de hipervisor de máquina virtual
As máquinas virtuais [gerenciadas por um hipervisor](https://docs.aws.amazon.com//aws-backup/latest/devguide/working-with-hypervisors.html) usam o [AWS Backup Gateway](https://docs.aws.amazon.com/aws-backup/latest/devguide/working-with-gateways.html) para conectar sistemas on-premises ao AWS Backup. É importante que os hipervisores tenham a mesma segurança robusta e confiável. Essa segurança pode ser obtida criptografando o hipervisor, seja por chaves AWS próprias ou por chaves gerenciadas pelo cliente.
## AWS chaves próprias e gerenciadas pelo cliente
AWS Backup fornece criptografia para as credenciais do hipervisor para proteger as informações confidenciais de login do cliente usando chaves de **criptografia AWS próprias**. Em vez disso, você tem a opção de usar **chaves gerenciadas pelo cliente**.
**Por padrão, as chaves usadas para criptografar as credenciais em seu hipervisor são AWS chaves próprias.** AWS Backup usa essas chaves para criptografar automaticamente as credenciais do hipervisor. Você não pode visualizar, gerenciar ou usar chaves AWS próprias, nem auditar seu uso. No entanto, não é necessário realizar nenhuma ação nem alterar qualquer programa para proteger as chaves que criptografam seus dados. Para obter mais informações, consulte chaves AWS próprias no [https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#key-mgmt](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#key-mgmt).
Como alternativa, as credenciais podem ser criptografadas usando *chaves gerenciadas pelo cliente*. O AWS Backup é compatível com o uso de chaves simétricas gerenciadas pelo cliente que você cria, tem a propriedade e gerencia para executar a criptografia. Como você tem controle total dessa criptografia, é possível realizar tarefas como:
+ Estabelecer e manter as políticas de chave
+ Estabelecer e manter subsídios e IAM policies
+ Habilitar e desabilitar políticas de chaves
+ Alternar os materiais de criptografia de chave
+ Adicionar etiquetas
+ Criar réplicas de chaves
+ Chaves de agendamento para exclusão
Ao usar uma chave gerenciada pelo cliente, AWS Backup valida se sua função tem permissão para descriptografar usando essa chave (antes da execução de um trabalho de backup ou restauração). Você deve adicionar a ação `kms:Decrypt` à função usada para iniciar um trabalho de backup ou de restauração.
Como não é possível adicionar a ação `kms:Decrypt` à função de backup padrão, você deve usar uma função diferente da função de backup padrão para usar as chaves gerenciadas pelo cliente.
Para obter mais informações, consulte [chaves gerenciadas pelo cliente](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) no *Guia do desenvolvedor do AWS Key Management Service *.
## Concessão necessária ao usar chaves gerenciadas pelo cliente
AWS KMS exige uma [concessão](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html) para usar sua chave gerenciada pelo cliente. Quando você importa uma [configuração de hipervisor](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_BGW_ImportHypervisorConfiguration.html) criptografada com uma chave gerenciada pelo cliente, AWS Backup cria uma concessão em seu nome enviando uma [https://docs.aws.amazon.com/kms/latest/APIReference/API_CreateGrant.html](https://docs.aws.amazon.com/kms/latest/APIReference/API_CreateGrant.html)solicitação para AWS KMS. AWS Backup usa concessões para acessar uma chave KMS em uma conta de cliente.
Você pode revogar o acesso à concessão ou remover AWS Backup o acesso à chave gerenciada pelo cliente a qualquer momento. Se você fizer isso, todos os seus gateways associados ao seu hipervisor não poderão mais acessar o nome de usuário e a senha do hipervisor criptografados pela chave gerenciada pelo cliente, o que afetará os trabalhos de backup e de restauração. Especificamente, haverá falha nos trabalhos de backup e de restauração que você executa nas máquinas virtuais desse hipervisor.
O gateway de backup usa a operação `RetireGrant` para remover uma concessão quando você exclui um hipervisor.
## Monitorar as chaves de criptografia
Ao usar uma chave gerenciada pelo AWS KMS cliente com seus AWS Backup recursos, você pode usar [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)o [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) para rastrear solicitações AWS Backup enviadas para AWS KMS.
Procure AWS CloudTrail eventos com os seguintes `"eventName"` campos para monitorar AWS KMS as operações chamadas por AWS Backup para acessar dados criptografados pela chave gerenciada pelo cliente:
+ `"eventName": "CreateGrant"`
+ `"eventName": "Decrypt"`
+ `"eventName": "Encrypt"`
+ `"eventName": "DescribeKey"`