Continuidade de negócio com AWS Backup

Por Wembley Carvalho, Sr. Solutions Architect, AWS e;

Hugo Chimello, Enterprise Solutions Architect, AWS.

Prevenindo perda de dados após incidentes, usando uma estratégia de backup em múltiplas contas e múltiplas regiões

Com o crescimento dos ambientes em nuvem AWS, as cargas de trabalho passaram a ser compostas de várias contas AWS, trazendo mais complexidade no gerenciamento dos ambientes, mas também um melhor isolamento entre elas, possibilitando estratégias de backup/restore mais sofisticadas e seguras.

O intuito deste blog é pensarmos fora da caixa no que diz respeito a backup. Como os ataques cibernéticos e suas técnicas cada dia mais arrojadas, podemos ter uma estratégia de backup/restore utilizando múltiplas regiões e múltiplas contas através do serviço AWS Backup. Essa estratégia tem como objetivo prevenir possíveis ataques às suas contas AWS, onde o atacante possa obter um acesso privilegiado de maneira ilegal, comprometendo seus recursos e seus backup locais. Além de criar uma estratégia de mitigação de possíveis grandes falhas em regiões da AWS, permitindo recuperar o ambiente em uma outra região.

O AWS Backup permite centralizar e automatizar a proteção de dados em serviços da AWS e workloads híbridos. Ele oferece um serviço econômico, totalmente gerenciado e baseado em políticas que simplificam ainda mais a proteção de dados em grande escala. O AWS Backup também ajuda a garantir a conformidade regulatória ou as políticas de negócios para a proteção de dados.

O serviço do AWS Backup pode ser utilizado de forma isolada em cada conta ou centralizado a nível de AWS Organizations. Criaremos a seguir uma estratégia centralizada resiliente via AWS Organizations.

Para facilitar o entendimento, usaremos 3 tipos de contas distintas:

• Conta de gerenciamento do AWS Organizations
• A conta de backup, onde ficará o cofre com os backups
• As contas membro da organização e as contas de origem do backup

No primeiro momento, temos que nos certificar que o serviço AWS Backup está ativo e operacional no AWS Organizations, estando com acesso administrativo no console do AWS Organizations e habilitando a confiança no AWS Backup. Para isso, entre no serviço AWS Organizations → Services e depois AWS Backup.

Certifique-se de deixar habilitado a confiança de acesso ao serviço.

Em seguida, habilitar o gerenciamento entre contas dentro do serviço AWS Backup (deixe todas as políticas de gerenciamento cross-account habilitadas):

A partir deste momento, temos duas opções: 

A – Criar políticas individuais nas contas filhas apontando como destino a conta de backup, garantindo políticas personalizadas e específicas para cada conta, tendo maior flexibilidade de configuração.

B – Criar políticas na conta da Organization, trabalhando com uma política centralizada e aplicada a nível de Organizational Units ou contas da Organization.

Opção A: Políticas individuais nas contas filhas

Uma recomendação neste caso é sempre ter um “vault” de destino numa região diferente dos recursos na origem, neste caso, criaremos um “vault” na região Oregon (us-west-2). Antes disso, precisaremos criar uma chave de AWS KMS Custom para ser utilizada na conta de Backup.

Criando a chave custom do AWS KMS para ser utilizada pelo Backup vault na conta de backup

• Acesse o serviço AWS KMS → customer-managed keys →  Create Key
• Selecione o tipo de chave Simétrica → uso da chave para Encrypt and decrypt → clique em Next
• No campo Alias, dê um nome para a chave.
• No passo de permissão administrativa, deixe em branco e clique em Next
• No passo de permissão de uso, selecione a Role “AWSServiceRoleForBackup“
• Revise as configurações e clique em Finish

Criar o Backup vault com a chave custom do AWS KMS que criamos anteriormente

• Acessar o console → AWS Backup → Backup vault
• Clique em Create New Vault
• Informe um nome para o Vault e selecione a chame KMS criada no passo anterior.
• Além disso, precisamos dar permissão no Vault para que a conta de origem possa copiar os backups para o Vault na conta de backup. Sendo assim, ainda dentro das configurações do Vault, na parte de Access Policy, clique em “Add permission” → “Allow Account Level access to Backup Level” e abrirá uma página para a edição do JSON.

No editor de Json, altere o [AccountID] para o ID da conta membro (origem do backup), utilizando apenas números e salve as alterações da política.

Uma última informação que precisaremos, ainda na conta de backup, é o ARN (Amazon Resource Name) do vault. Copie e guarde para uso futuro.

Criando a política de Backup

Após dadas as permissões, precisamos criar as configurações na conta membro onde estará o recurso a ser realizado o backup. Dentro da conta membro agora, acesse o serviço AWS Backup, em Backup Plan, crie um novo.

Neste exemplo, não vamos utilizar nenhum template e sim criar um plano do princípio.

Em Backup Rule Configurations, vamos configurar a frequência e os destinos do backup, além de uma possível transição para storage de baixo custo (no caso de S3, EFS, Dynamo ou algum outro serviço que suporte, veja a lista aqui).

Nas configurações ao lado, alguns campos foram deixados com o padrão, já os campos à seguir foram alterados:

Backup rule name: Insira um nome para a regra.

Retention period: insira o tempo de retenção em dias, semanas, meses, anos ou sempre (neste caso o backup será mantido para sempre, ou até que seja deletado).

Copy to destination: selecione a região de destino e neste caso, recomenda-se que a região de destino seja uma região diferente da região de origem. Habilite a opção de “Copy to another account’s vault”

External vault ARN: nesse campo, insira o ARN do Vault que foi copiado nos passos anteriores

Assim que digitado o ARN do Vault de destino, aparecerá uma janela para dar permissão no vault de origem para a conta de destino, clique em Allow e em seguida clique em Create Plan

Neste próximo passo, precisa informar quais recursos serão feitos os backups:

Temos as seguintes opções:

• Todos os recursos
• Todos os recursos e filtrar com TAGs específicas (Ex.: TAG chamada Backup com o valor true)
• Apenas os recursos selecionados na lista (Ex.: Aurora, DynamoDB, EBS, etc..)
• Recursos específicos com TAGs específicas.

Obs.: Ao selecionar o tipo de recursos específico, podemos ter uma lista de exceções para excluir algum recurso

Feito isso, basta aguardar a janela de backup selecionada na Rule e verificar se o backup está sendo copiado para a Vault da conta de backup. Para isso, acesse o Backup Vault na conta de backup. Além do mais, as operações de restore e copiar o backup para outras contas e regiões deverão ser realizadas no Backup Vault da conta de backup.

Opção B: Políticas criadas na conta do AWS Organizations

Nesta opção aplicaremos políticas a nível das contas atrelados à organization configurada. Isso significa que, ao invés de aplicarmos políticas individuais, iremos aplicar políticas a nível organizacional e todas as contas contempladas abaixo da organização serão afetadas pelas políticas configuradas.

A fim de criarmos essa opção B precisaremos seguir os seguintes passos:

• Coletar o ARN do Backup vault que será utilizado na conta de backup. Neste caso, o vault utilizado precisa estar em uma região diferente dos recursos.
• Ainda na conta de backup e dentro da vault, dar permissão para a organization acessar o vault escolhido. Repetir o mesmo processo de permissão para as contas que estão os recursos a serem feitos os Backups, já que toda vez que é feito o backup, por via de regra é feito uma cópia local antes da cópia em outra conta, vault e região.
• Na conta que foi criada a AWS Organization, criar uma Backup policy que será responsável pela configuração do backup dos serviços perante o Backup vault na conta de backup, assim como a periodicidade da janela de backup.

Para começar, assim como na opção A precisaremos acessar a conta de backup, escolher uma região diferente das que estão os recursos e criar uma chave KMS e um Backup vault.

1- Criando a chave custom do AWS KMS para ser utilizada pelo Backup vault na conta de backup

• Acesse o serviço AWS KMS → customer-managed keys →  Create Key.
• Selecione o tipo de chave Simétrica →  uso da chave para Encrypt and decrypt →  clique em Next
• No campo Alias, dê um nome para a chave
• No passo de permissão administrativa, pode deixar em branco e clique em Next
• No passo de permissão de uso, selecione a Role “AWSServiceRoleForBackup“
• Revise as configurações e clique em Finish

2- Criar o Backup vault com a chave custom do AWS KMS que criamos anteriormente

• Acessar o console → AWS Backup → Backup vault
• Clique em Create New Vault
• Informe um nome para o Vault e selecione a chame KMS criada no passo anterior
• Além disso, precisamos dar permissão no Vault para que a conta de origem possa copiar os backups para o Vault na conta de backup. Sendo assim, ainda dentro das configurações do Vault, na parte de Access Policy, clique em “Add permission” → “Allow access to a Backup vault from organization” e abrirá uma página para a edição do JSON
• Ao selecionar Allow access to a Backup vault from organization, você será redirecionado para uma página em que poderá editar a política de acesso ao vault. Nesta página o nosso objetivo é verificar se a variável aws: PrincipalOrgID está com o ID da organization que será utilizada
• Lembrando que é necessário realizar o mesmo processo de permissão nas vaults locais das contas em que estão os seus recursos AWS que irão ser feitos os backups

Agora que já temos a chave KMS e o vault que utilizaremos, precisamos copiar o ARN do vault que será utilizado nos próximos passos. Ainda na conta de backup, acesse: AWS Backup → Backup vaults → Backup vault name: vault que foi criado → copie e guarde o ARN.

3- Acessar a conta da organization e criar uma Backup policy, responsável pela configuração das TAGS dos recursos que serão feitos os “backups”

Na conta que foi criada a organization, entraremos no serviço AWS Backup para criarmos uma política global de backup que usará o vault da conta de backup. Para isso, vamos em AWS Backup no console → Na aba lateral esquerda, Backup policies → Create Backup policy.

Dentro de Create policy, selecione um nome a sua escolha em Policy name e coloque uma descrição em Policy description.

O próximo passo é definir o plano de backup, no caso, foi definido o nome como BackupPlanBlogpost e a região em que esse plano se aplicará como US East (N. Virginia) – us-east-1. Vale salientar que a região escolhida precisa ser a mesma em que estão os recursos a serem realizados os “backups”.

Voltando na página do Backup policy, vá para Targets e clique em Attach.

Nesta etapa podemos escolher se a política se aplicará a toda a AWS Organization (em preto), às organizational units (em azul) ou às contas específicas (em vermelho). Neste caso, aplicaremos em uma das organizational units (em azul) e todas as contas abaixo dela serão afetadas.

No passo Resource Assignment, vamos definir quais recursos terão acesso a essa política. Neste caso, todos os recursos que possuírem a TAG Backup e com o valor true, estarão cobertos pelo plano de backup.

Após toda a configuração, salve as mudanças e clique em Create backup policy.

Em Add Backup rule, é obrigatório colocar o Backup vault destino primário. Porém, como o nosso objetivo é ter uma cópia do nosso vault em outra conta/região centralizadora, em Generate copy, iremos colocar a região e o ARN que criamos no passo 2.

Agora que já temos o Backup Vault criado na conta de backup e a Backup policy criada na conta da organization, vamos para uma das contas abaixo da organization para verificarmos se o recurso criado, neste caso uma instância EC2, possui a tag que predefinimos: Tag name: Backup Value:true.

Na conta filho entraremos no serviço EC2 e iremos em instâncias. Uma vez selecionada a instancia desejada, vamos verificar se possui a tag correta para garantir que esse recurso seja feito o backup.

Para verificar se o backup foi feito, assim como a sua cópia para a conta backup em outra conta e região, é necessário acessar na conta filho o serviço AWS Backup → Jobs → Backup jobs. Conforme a imagem abaixo, é possível verificar todos os processos de backup realizados naquela conta e ao acessarmos Copy Jobs, conseguimos verificar todos os processos de cópia desse backup para o vault da conta de backup.

Também é possível verificar acessando diretamente a conta de backup → AWS Backup → Backup vault → Acessar o vault criado no passo 2. Acessando o vault, podemos verificar todos os dados dos backups criados nas contas filhas e copiados para a conta de backup.

Considerações:

Recursos usando chaves do AWS KMS poderão ser feitos os backups normalmente, entretanto a operação de copiar o backup para outra conta e para outra região existem alguns detalhes:

• Chave default do AWS KMS não pode ser compartilhada com outra conta, sendo assim, o recurso na origem precisa usar uma chave custom do AWS KMS.

Conclusão:

Neste blog, mostramos como implementar políticas de backup para ajudá-lo a dimensionar sua estratégia de proteção de dados e gerenciar políticas de backup em toda a AWS Organization ou de forma individual.

O backup de dados é uma parte essencial da maioria das estratégias de gerenciamento de dados, e os requisitos de backup geralmente são orientados por requisitos organizacionais ou regulamentares. Com backups seguros e confiáveis, você pode estar pronto em caso de perda inesperada de dados para restaurá-los. A solução abordada nesta postagem demonstra como isso é possível, de duas maneiras distintas, automatizando e gerenciando facilmente seus planos de backup ao mesmo tempo podendo escolher fazê-lo de forma individual ou utilizando a própria estrutura do serviço AWS Organizations para isso.

Para começar a usar a AWS ou saber mais sobre o serviço AWS Backup, visite as páginas da Amazon Web Services e do AWS Backup para mais informações.

Obrigado por ler este blog. Se você tiver quaisquer comentários ou perguntas, por favor, deixe-os na seção de comentários.

Sobre os autores

Wembley Carvalho é Sr. Solutions Architect na AWS desde de 2019. Trabalhando em diversas áreas de TI a mais de 20 anos e certificado AWS desde 2016, vem se especializado nos últimos anos em de Segurança em nuvem e transformação digital.

Hugo Chimello é Enterprise Solutions Architect na AWS desde 2020 atuando na indústria de Telecomunicações e se especializando em Analytics.