Que camada de cópias de segurança deve gerir as chaves de encriptação: o cliente, o repositório ou o destino externo?

Para a maioria das cópias de segurança de servidores domésticos, a aplicação de cópia de segurança ou o cliente deve controlar a encriptação necessária para ler a cópia de segurança, enquanto a encriptação do fornecedor de armazenamento externo deve ser tratada como uma camada adicional. Assim, o comprometimento do armazenamento na cloud ou remoto não expõe automaticamente o conteúdo das cópias de segurança, preservando simultaneamente um formato de cópia de segurança que continua a permitir deduplicar, verificar e restaurar os dados de forma eficiente.

A distinção importante não é simplesmente “encriptação no cliente versus encriptação no servidor”. É necessário decidir qual o domínio de falha que detém o segredo de desencriptação. Se a única chave existir no servidor de origem, uma origem avariada ou encriptada por ransomware pode destruir a capacidade de recuperação. Se o destino externo detiver a única chave relevante, o operador do destino ou uma conta de destino comprometida pode continuar dentro do limite de confiança. A melhor arquitetura separa os dados de cópia de segurança, as credenciais do repositório e as chaves de recuperação.

Existem três locais diferentes onde a encriptação pode residir

A expressão “cópia de segurança encriptada” oculta várias arquiteturas. Os ficheiros de origem podem ser encriptados antes de o software de cópia de segurança os processar. O software de cópia de segurança pode encriptar o formato do seu repositório antes de enviar os objetos para armazenamento local ou remoto. Ou o sistema de armazenamento de destino pode receber os dados e encriptá-los em repouso, utilizando a sua própria camada de gestão de chaves.

A encriptação ao nível do repositório é, geralmente, a melhor predefinição

As ferramentas modernas de cópia de segurança foram concebidas para encriptar os dados como parte do formato do repositório. A documentação de encriptação do restic trata a encriptação como uma funcionalidade essencial do repositório e suporta várias chaves de acesso/palavras-passe. O Kopia descreve igualmente os seus repositórios como adicionando encriptação e deduplicação sobre backends de armazenamento como sistemas de ficheiros, S3 e armazenamentos de objetos na nuvem.

O Borg torna o modelo de confiança especialmente explícito. A sua documentação de segurança parte do princípio de que o ambiente do cliente é fiável e que o repositório pode ser hostil. O Borg encripta localmente, para que um repositório remoto não receba os ficheiros em texto simples nem a chave de cópia de segurança não encriptada.

Este padrão é particularmente apelativo para um NAS doméstico, porque a aplicação de cópia de segurança continua a conseguir ver os ficheiros originais enquanto cria a cópia de segurança. Pode executar a fragmentação, a deduplicação, a compressão, o tratamento de metadados de instantâneos, a verificação e as restaurações seletivas antes ou em simultâneo com a encriptação. O destino de armazenamento recebe objetos de repositório encriptados, em vez de ficheiros comuns legíveis.

Não confunda a chave do repositório com a credencial de armazenamento

Uma chave de acesso a um bucket na nuvem, uma chave privada SFTP, uma palavra-passe de um NAS remoto e uma chave de desencriptação da cópia de segurança são segredos diferentes, mesmo quando um script de automatização precisa de todos eles. A credencial de armazenamento responde à pergunta «este cliente pode ler ou escrever objetos do repositório?». A chave do repositório responde à pergunta «é possível desencriptar estes objetos para obter os dados da cópia de segurança?».

Separar estes dois elementos é importante durante um incidente. Um atacante que roube uma credencial de um bucket com permissões de escrita não deve obter automaticamente o segredo de desencriptação do repositório. Do mesmo modo, possuir a palavra-passe da cópia de segurança não deve necessariamente conceder acesso administrativo à conta de armazenamento externo.

O guia da ZimaSpace sobre a verificação de todas as chaves necessárias para uma restauração encriptada é um complemento útil, pois apresenta o acesso ao repositório, a encriptação da cópia de segurança, o armazenamento de destino, os segredos dos contentores e os segredos ao nível das aplicações como dependências de recuperação distintas.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

A pré-encriptação no cliente é a melhor opção para dados restritos de elevada sensibilidade

Encriptar ficheiros antes de a aplicação de cópias de segurança os ler pode ser útil quando um conjunto de dados específico tem de permanecer opaco até para as ferramentas de cópias de segurança ou os administradores habituais. Os exemplos incluem um pequeno arquivo jurídico, uma base de dados de palavras-passe exportada, um conjunto de chaves privadas ou um contentor encriptado controlado pelo cliente.

A desvantagem é que a encriptação realizada demasiado cedo pode ocultar estruturas que o sistema de cópias de segurança exploraria de outro modo. Se cada ficheiro alterado se transformar num resultado encriptado completamente diferente, a compressão e a deduplicação podem tornar-se menos eficazes. A navegação granular pelos ficheiros também pode transformar o restauro num processo em duas etapas: recuperar primeiro o objeto encriptado e, em seguida, desbloqueá-lo com outra ferramenta.

Por esse motivo, a pré-encriptação do conjunto de dados completo é normalmente uma arquitetura de cópias de segurança domésticas predefinida mais fraca do que utilizar uma ferramenta de cópias de segurança com encriptação nativa e autenticada do repositório. Utilize-a quando precisar deliberadamente de um segundo limite de confiança em torno de um subconjunto de dados.

A encriptação do lado do servidor fora do local protege o armazenamento, não todo o modelo de confiança da cópia de segurança

Os armazenamentos de objetos na cloud encriptam normalmente os dados em repouso. O Amazon S3, por exemplo, aplica encriptação do lado do servidor por predefinição e suporta chaves KMS geridas pela AWS ou pelo cliente. A sua documentação SSE-KMS descreve como o S3 realiza a encriptação no destino, enquanto o AWS KMS controla as chaves e as permissões.

O Backblaze B2 também suporta SSE-B2 gerida pelo fornecedor e SSE-C gerida pelo cliente. A sua documentação sobre encriptação do lado do servidor indica que a SSE protege os dados dos ficheiros em repouso e que a perda de uma chave SSE-C gerida pelo cliente torna os dados irrecuperáveis.

A encriptação do lado do servidor é valiosa. Ajuda a proteger suportes físicos e a infraestrutura de armazenamento, e as políticas KMS geridas pelo cliente podem criar controlos organizacionais sólidos. Mas, se o serviço de destino conseguir desencriptar os dados sempre que chega um pedido de armazenamento autorizado, o destino continua dentro do limite de confidencialidade. Isto é diferente de carregar um repositório Borg, restic ou Kopia que já tenha sido encriptado antes de chegar ao fornecedor.

Utilize a encriptação externa como defesa em profundidade

A resposta prática é frequentemente «ambas». Deixe a aplicação de cópia de segurança encriptar o conteúdo do repositório antes do carregamento e, em seguida, mantenha ativada a encriptação normal do destino em repouso como outro controlo. As duas camadas protegem contra eventos diferentes.

A chave tem de sobreviver à máquina que protege

A regra mais importante para a localização das chaves é simples: não mantenha no servidor de que está a fazer cópia de segurança a única cópia de recuperação do segredo de encriptação. O guia atual de inicialização de repositórios do Borg recomenda explicitamente manter uma cópia de segurança da chave do Borg fora do repositório e do sistema que cria as cópias de segurança.

A mesma lógica aplica-se às palavras-passe do restic, às palavras-passe dos repositórios do Kopia, às chaves age, ao material de recuperação do LUKS, à administração do KMS da cloud e às chaves mestras das aplicações. Um repositório encriptado na perfeição é inútil se o único segredo de desencriptação desaparecer juntamente com a unidade de arranque avariada.

Numa casa ou num pequeno laboratório, mantenha pelo menos uma cópia de recuperação offline ou num sistema de credenciais separado que não dependa de o NAS estar operacional. Depois, teste um restauro numa máquina limpa. Uma palavra-passe escrita que nunca tenha sido utilizada para abrir o repositório é prova de documentação, não de recuperabilidade.

Que camada deve ser responsável pela chave em arquiteturas comuns de servidores domésticos?

NAS doméstico a fazer cópia de segurança para armazenamento de objetos

Utilize a encriptação nativa do repositório no restic, Borg, Kopia ou numa ferramenta de cópia de segurança comparável antes de os dados saírem do NAS. Mantenha a chave ou palavra-passe do repositório fora do NAS. Mantenha a encriptação do bucket ativada como defesa em profundidade. Assim, o destino na cloud não é o único controlo de confidencialidade.

NAS doméstico a fazer cópia de segurança para o servidor remoto de um amigo

Prefira a encriptação do cliente/repositório cuja chave dos dados em texto simples não esteja no servidor do seu amigo. O anfitrião remoto pode armazenar objetos opacos do repositório e aplicar permissões de escrita limitadas. Isto é especialmente valioso porque o controlo físico e administrativo da máquina remota pertence a outro domínio de falha.

Disco de cópias de segurança local guardado na mesma casa

A encriptação do repositório continua a proteger a confidencialidade se o disco for perdido ou roubado. A encriptação de disco completo no disco de cópias de segurança pode ser uma segunda camada útil, mas não permita que a chave de desbloqueio do disco se torne a única forma de aceder ao repositório de cópias de segurança.

Cópia de segurança na cloud gerida com funcionalidades de recuperação do fornecedor

A encriptação gerida pelo fornecedor pode ser uma opção razoável quando a simplicidade e a recuperação assistida pelo fornecedor são mais importantes do que manter o fornecedor fora do perímetro de confiança dos dados em texto simples. Tenha presente que esta é uma decisão de segurança diferente da encriptação do lado do cliente ao estilo de conhecimento zero.

Não coloque todos os segredos da cópia de segurança num único ficheiro de automatização

Um trabalho de cópia de segurança não supervisionado precisa de credenciais, mas a conveniência pode eliminar os seus limites de segurança. As orientações de automatização do restic alertam para o facto de a forma como as palavras-passe são fornecidas poder expor credenciais e recomendam proteger cuidadosamente os ficheiros de palavras-passe.

Num servidor doméstico, separe, pelo menos, estas funções sempre que for prático:

• Uma credencial com permissões estritamente limitadas que possa aceder ao destino da cópia de segurança.
• A palavra-passe ou chave de desencriptação do repositório.
• Uma cópia de recuperação offline dessa palavra-passe/chave.
• Credenciais administrativas que podem eliminar políticas de retenção, buckets ou contas remotas.

Esta separação é mais importante do que decidir se um segredo específico é armazenado num ficheiro, numa variável de ambiente, num gestor de palavras-passe, num token de hardware ou num KMS. A arquitetura deve impedir que uma única credencial de automatização roubada permita simultaneamente ler dados em texto simples, eliminar o repositório e destruir a única chave de recuperação.

A encriptação não substitui a imutabilidade nem os testes de restauro

A confidencialidade, a integridade, a resistência à eliminação e a capacidade de recuperação são objetivos distintos. Um repositório encriptado pode, ainda assim, ser eliminado. Um bucket imutável pode, ainda assim, conter cópias de segurança cuja chave de desencriptação se perdeu. Um trabalho de cópia de segurança concluído com êxito pode, ainda assim, falhar durante o restauro.

A comparação da ZimaSpace entre um servidor de cópia de segurança remoto e o armazenamento de objetos na cloud para cópias de segurança de VMs chega à mesma conclusão operacional: o rótulo do destino importa menos do que testar uma recuperação real.

Matriz de decisão

Veredito final

Na maioria dos sistemas de cópia de segurança autoalojados, deixe o cliente de cópia de segurança ou o formato do repositório controlar o limite de encriptação do conteúdo, e deixe o destino externo encriptar novamente os dados em repouso. Isto mantém funcionalidades da cópia de segurança, como a deduplicação e a verificação, reduzindo simultaneamente o nível de confiança que tem de depositar no sistema de armazenamento remoto relativamente ao acesso a dados em texto simples.

O plano de gestão de chaves só está completo quando o segredo de desencriptação sobrevive à perda do servidor de origem, do destino de armazenamento e da estação de trabalho normal do administrador. Teste essa premissa a partir de uma máquina limpa antes de considerar que a cópia de segurança pode ser recuperada.

Perguntas frequentes

A encriptação do lado do servidor na cloud é suficiente para cópias de segurança domésticas?

Protege os dados em repouso, mas normalmente mantém o serviço de armazenamento dentro do limite de confiança da desencriptação. Utilize também encriptação nativa da cópia de segurança quando não quiser que o fornecedor ou uma credencial de armazenamento roubada sejam suficientes para aceder aos dados em texto simples.

A chave do repositório deve ser armazenada dentro do repositório?

Alguns formatos de cópia de segurança armazenam um objeto de chave encriptado no repositório, mas a recuperação continua a depender de outro segredo, como uma frase-passe forte. Mantenha material de recuperação independente fora do repositório e do sistema de origem.

Encriptar ficheiros antes da cópia de segurança melhora a segurança?

Pode criar um limite de confiança adicional para subconjuntos sensíveis, mas encriptar tudo antes de a ferramenta de cópia de segurança o processar pode reduzir a deduplicação, a compressão, a visibilidade dos metadados e a conveniência do restauro.

Qual é o teste mais importante de gestão de chaves?

Restaure a partir de uma máquina limpa, depois de assumir que o NAS original está completamente indisponível. Se não conseguir localizar todas as credenciais e desencriptar dados representativos, o plano de chaves está incompleto.