O armazenamento de backup externo deve ser uma parte crítica do plano de recuperação de desastres de qualquer organização. A capacidade de armazenar dados em um local físico separado, onde podem sobreviver a um evento catastrófico que destrói todos os dados em seu data center principal, garante a sobrevivência dos dados e a continuidade de sua organização. Um serviço de armazenamento em nuvem é um bom método para armazenar backups externos. Não importa se você está usando um provedor de nuvem ou se está apenas copiando dados para um data center externo, a criptografia de backup é obrigatória nesses casos. Em um de nossos blogs anteriores, discutimos vários métodos de criptografar seus backups. Hoje vamos nos concentrar em algumas práticas recomendadas em torno da criptografia de backup.
Certifique-se de que seus segredos estão seguros
Para criptografar e descriptografar seus dados, você precisa usar algum tipo de senha ou chave. Dependendo do método de criptografia (simétrico ou assimétrico), pode ser um segredo para criptografia e descriptografia ou pode ser uma chave pública para criptografia e uma chave privada para descriptografia. O que é importante, você deve mantê-los seguros. Se acontecer de você usar criptografia assimétrica, você deve se concentrar na chave privada, aquela que você usará para descriptografar backups.
Você pode armazenar chaves em um sistema de gerenciamento de chaves ou em um cofre - existem inúmeras opções no mercado para escolher, como o KMS da Amazon ou o Cofre da Hashicorp. Mesmo que você decida não usar essas soluções, você ainda deve aplicar práticas de segurança genéricas, como garantir que apenas os usuários corretos possam acessar suas chaves e senhas. Você também deve considerar preparar seus scripts de backup de forma que não exponha chaves ou senhas na lista de processos em execução. O ideal é colocá-los no arquivo em vez de passá-los como argumento para alguns comandos.
Considere a criptografia assimétrica
A principal diferença entre criptografia simétrica e assimétrica é que, ao usar a criptografia simétrica para criptografia e descriptografia, você usa uma única chave ou senha. Isso requer padrões de segurança mais altos em ambas as extremidades do processo. Você precisa garantir que o host no qual você criptografa os dados seja muito seguro, pois um vazamento da chave de criptografia simétrica permitirá o acesso a todos os seus backups criptografados.
Por outro lado, se você usar criptografia assimétrica, terá duas chaves:a chave pública para criptografar os dados e a chave privada para descriptografia. Isso torna as coisas muito mais fáceis - você realmente não precisa se preocupar com a chave pública. Mesmo que seja comprometido, ainda não permitirá nenhum tipo de acesso aos dados dos backups. Você deve se concentrar apenas na segurança da chave privada. É mais fácil - você provavelmente está criptografando backups diariamente (se não com mais frequência) enquanto a restauração acontece de tempos em tempos, tornando viável o armazenamento da chave privada em um local mais seguro (mesmo em um dispositivo físico dedicado). Abaixo está um exemplo muito rápido de como você pode usar o gpg para gerar um par de chaves e usá-lo para criptografar dados.
Primeiro, você deve gerar as chaves:
[email protected]:~# gpg --gen-key
gpg (GnuPG) 1.4.20; Copyright (C) 2015 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
gpg: directory `/root/.gnupg' created
gpg: new configuration file `/root/.gnupg/gpg.conf' created
gpg: WARNING: options in `/root/.gnupg/gpg.conf' are not yet active during this run
gpg: keyring `/root/.gnupg/secring.gpg' created
gpg: keyring `/root/.gnupg/pubring.gpg' created
Please select what kind of key you want:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
Your selection?
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096
Requested keysize is 4096 bits
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0)
Key does not expire at all
Is this correct? (y/N) y
You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:
"Heinrich Heine (Der Dichter) <[email protected]>"
Real name: Krzysztof Ksiazek
Email address: [email protected]
Comment: Backup key
You selected this USER-ID:
"Krzysztof Ksiazek (Backup key) <[email protected]>"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
You need a Passphrase to protect your secret key.Isso criou chaves públicas e privadas. Em seguida, você deseja exportar sua chave pública para usar para criptografar os dados:
gpg --armor --export [email protected] > mybackupkey.ascEm seguida, você pode usá-lo para criptografar seu backup.
[email protected]:~# xtrabackup --backup --stream=xbstream | gzip | gpg -e --armor -r [email protected] -o /backup/pgp_encrypted.backupPor fim, um exemplo de como você pode usar sua chave primária (neste caso, ela está armazenada no chaveiro local) para descriptografar seus backups:
[email protected]:/backup# gpg -d /backup/pgp_encrypted.backup | gunzip | xbstream -x
encryption: using gcrypt 1.6.5
You need a passphrase to unlock the secret key for
user: "Krzysztof Ksiazek (Backup key) <[email protected]>"
4096-bit RSA key, ID E047CD69, created 2018-11-19 (main key ID BC341551)
gpg: gpg-agent is not available in this session
gpg: encrypted with 4096-bit RSA key, ID E047CD69, created 2018-11-19
"Krzysztof Ksiazek (Backup key) <[email protected]>"Girar suas chaves de criptografia
Não importa que tipo de criptografia você implementou, simétrica ou assimétrica, você deve pensar na rotação de chaves. Em primeiro lugar, é muito importante ter um mecanismo para girar as chaves. Isso pode ser útil em caso de violação de segurança e você teria que alterar rapidamente as chaves que usa para criptografia e descriptografia de backup. Obviamente, em caso de violação de segurança, você precisa considerar o que acontecerá com os backups antigos que foram criptografados usando chaves comprometidas. Eles foram comprometidos, embora ainda possam ser úteis e necessários de acordo com o Objetivo do Ponto de Recuperação. Existem algumas opções, incluindo criptografá-los novamente ou movê-los para uma localização não comprometida.
Acelere o processo de criptografia paralelizando-o
Se você tiver a opção de implementar a paralelização do processo de criptografia, considere-a. O desempenho da criptografia depende principalmente da potência da CPU, portanto, permitir que mais núcleos da CPU trabalhem em paralelo para criptografar o arquivo deve resultar em tempos de criptografia muito menores. Algumas das ferramentas de criptografia oferecem essa opção. Um deles é o xtrabackup que tem a opção de usar criptografia embutida e paralelizar o processo.
O que você está procurando são as opções “--encrypt-key” ou “--encrypt-key-file” que habilitam a criptografia incorporada. Ao fazer isso, você também pode definir “--encrypt-threads” e “--encrypt-chunk-size”. Segundo aumenta um buffer de trabalho para criptografia, primeiro define quantos threads devem ser usados para criptografia.
Claro, esta é apenas uma das soluções que você pode implementar. Você pode conseguir isso usando ferramentas de shell. Um exemplo abaixo:
[email protected]:~# files=2 ; mariabackup --user=root --backup --pass=pass --stream=xbstream |split -b 60M - backup ; ls backup* | parallel -j ${files} --workdir "$(pwd)" 'echo "encrypting {}" ; openssl enc -aes-256-cbc -salt -in "{}" -k mypass > "111{}"'Esta não é de forma alguma uma solução perfeita, pois você precisa saber com antecedência o tamanho, mais ou menos, do backup para dividi-lo em um número predefinido de arquivos que correspondam ao nível de paralelização que você deseja alcançar (se você quiser usar 2 CPU núcleos, você deve ter dois arquivos, se quiser usar 4 núcleos, 4 arquivos etc). Também requer espaço em disco com o dobro do tamanho do backup, pois inicialmente gera vários arquivos usando a divisão e, em seguida, a criptografia cria outro conjunto de arquivos criptografados. Por outro lado, se o tamanho do seu conjunto de dados for aceitável e você quiser melhorar o desempenho da criptografia, essa é uma opção que você pode considerar. Para descriptografar o backup, você terá que descriptografar cada um dos arquivos individuais e usar 'cat' para juntá-los.
Teste seus backups
Não importa como você vai implementar a criptografia de backup, você precisa testá-la. Em primeiro lugar, todos os backups devem ser testados, criptografados ou não. Os backups podem não estar completos ou podem sofrer algum tipo de corrupção. Você não pode ter certeza de que seu backup pode ser restaurado até que você realmente execute a restauração. É por isso que a verificação de backup regular é obrigatória. A criptografia adiciona mais complexidade ao processo de backup. Problemas podem aparecer no momento da criptografia, novamente - bugs ou falhas podem corromper os arquivos criptografados. Uma vez criptografado, a questão é se é possível descriptografá-lo e restaurá-lo?
Você deve ter um processo de teste de restauração em vigor. Idealmente, o teste de restauração seria executado após cada backup. No mínimo, você deve testar seus backups algumas vezes por ano. Definitivamente, você deve testá-lo assim que uma alteração no processo de backup for introduzida. Você adicionou compactação ao backup? Você alterou o método de criptografia? Você rodou a chave de criptografia? Todas essas ações podem ter algum impacto em sua capacidade de restaurar seu backup. Portanto, certifique-se de testar todo o processo após cada alteração.
O ClusterControl pode automatizar o processo de verificação, sob demanda ou agendado após cada backup.
Para verificar um backup existente, basta escolher o da lista, clicar na opção “Restaurar” e depois passar pelo assistente de restauração. Primeiro, você precisa verificar qual backup deseja restaurar.
Então, na próxima etapa, você deve escolher a opção restaurar e verificar.
Você precisa passar algumas informações sobre o host no qual deseja testar a restauração. Ele deve ser acessível via SSH a partir da instância ClusterControl. Você pode decidir manter o servidor de teste de restauração funcionando (e, em seguida, despejar alguns dados parciais dele se quiser fazer uma restauração parcial) ou desligá-lo.
A etapa final é verificar se você fez as escolhas corretas. Se sim, você pode iniciar o trabalho de verificação de backup.
Se a verificação for concluída com sucesso, você verá que o backup está marcado como verificado na lista de backups.
Se você deseja automatizar esse processo, também é possível com o ClusterControl. Ao agendar o backup, você pode habilitar a verificação de backup:
Isso adiciona outra etapa no assistente de agendamento de backup.
Aqui você deve definir novamente o host que deseja usar para os testes de restauração de backup, decidir se deseja instalar o software nele (ou talvez já o tenha feito), se deseja manter o servidor de restauração ativo e se deseja deseja testar o backup imediatamente após a conclusão ou talvez queira esperar um pouco.
