Fluxo de recuperação de conjuntos de dados encriptados: chaves, montagens, instantâneos e testes de restauro

A abordagem segura consiste em tratar um fluxo de recuperação que protege o material de chaves, importa com segurança, carrega a raiz de encriptação correta e comprova um restauro separado como uma sequência de etapas observáveis, não como um único comando.

Num conjunto de dados ZFS encriptado num NAS doméstico, o risco prático é que um conjunto de dados encriptado não seja montado ou que os respetivos instantâneos ainda não possam ser considerados dados recuperáveis. Registe a identidade atual e o ponto de recuperação, comece pelo diagnóstico menos invasivo, interprete os resultados positivos e negativos antes de alterar outra variável e pare quando o armazenamento se tornar instável ou quando a única cópia recuperável ficar exposta. O fluxo abaixo só termina quando a carga de trabalho original funciona ou quando as evidências atingem um limite de escalamento.

Proteja as chaves e registe o estado da falha

Pare as importações automáticas, a replicação, as verificações e as escritas das aplicações até compreender a falha. Registe o pool, a hierarquia de conjuntos de dados, a raiz de encriptação, o formato e a localização da chave, o último ponto de montagem conhecido, o erro exato e se a chave alguma vez foi testada noutro anfitrião de recuperação.

A encriptação nativa do ZFS separa o carregamento da chave da montagem do conjunto de dados. O comportamento das raízes de encriptação e das chaves do ZFS descreve as raízes de encriptação e as chaves herdadas, razão pela qual fornecer uma chave válida ao filho errado ou presumir que todos os conjuntos de dados encriptados têm uma chave independente pode gerar tentativas de recuperação enganadoras.

Crie cópias protegidas dos ficheiros de chaves e das notas de recuperação sem imprimir segredos no histórico do terminal ou nos registos de suporte. Pare imediatamente se não existir uma chave verificada ou uma cópia de segurança, se os dispositivos do pool estiverem instáveis ou se um comando propuser uma reparação destrutiva.

Importe o pool sem expor caminhos de produção

No anfitrião de recuperação, confirme a identidade dos dispositivos e importe o pool com uma raiz alternativa ou sem montar conjuntos de dados sobre caminhos ativos. Inspecione o estado do pool e as propriedades dos conjuntos de dados antes de carregar as chaves. Uma importação bem-sucedida do pool prova apenas que os metadados do pool são legíveis, não que os conteúdos encriptados possam ser desencriptados.

Verifique recursivamente encryptionroot, keystatus, keylocation, canmount e mountpoint. Carregue a chave apenas para a raiz de encriptação pretendida e, em seguida, confirme que o respetivo estado muda para disponível antes de tentar uma montagem controlada sob um caminho isolado.

Se o carregamento da chave falhar, distinga entre material de chave incorreto, localização inacessível da chave e metadados encriptados danificados, por um lado, e um conflito comum de pontos de montagem, por outro. Preserve o erro exato e tente novamente apenas depois de alterar uma causa conhecida; tentativas repetidas podem impedir os operadores de obter evidências fiáveis.

Inspecione os instantâneos sem alterar a origem

Apresente a lista de instantâneos e confirme que o ponto de recuperação esperado existe. Se o pool de origem estiver suficientemente saudável, clone o instantâneo selecionado ou replique-o para armazenamento separado, em vez de montar o conjunto de dados de produção com permissões de leitura e escrita. Mantenha o instantâneo original imutável durante a investigação.

A replicação encriptada em bruto pode preservar o texto cifrado e as propriedades de encriptação, mas o lado de receção continua a precisar da hierarquia de chaves correspondente. Uma replicação ZFS encriptada em bruto independente ilustra a diferença entre um envio encriptado em bruto e um fluxo normal; por isso, escolha deliberadamente, em vez de presumir que todos os conjuntos de dados recebidos serão desbloqueados da mesma forma.

Utilize o fluxo de trabalho adjacente da ZimaSpace para restaurar um instantâneo para um sistema de ficheiros mais pequeno quando a capacidade do destino for diferente da origem. Aqui, a etapa é mais simples: o instantâneo escolhido tem de ser endereçável, a chave tem de ser carregada e a cópia de teste não pode substituir uma montagem existente.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Restaure para um destino isolado e comprove a legibilidade

Restaure ou clone o ponto selecionado para um conjunto de dados separado com um ponto de montagem temporário. Compare hashes de ficheiros representativos, ACLs, atributos estendidos, proprietários, ficheiros esparsos e dados das aplicações. No caso de uma base de dados, restaure a respetiva cópia de segurança nativa ou inicie uma instância copiada em portas isoladas, em vez de abrir os ficheiros de produção no local.

Reinicie ou exporte e importe novamente o ambiente de recuperação, carregue de novo a chave a partir da localização documentada e repita a montagem. Isto comprova que o sucesso não dependeu de uma chave em cache, de um estado pontual da shell ou de uma montagem acidental herdada da produção.

A recuperação só está concluída quando outro operador consegue seguir o procedimento da chave, montar o conjunto de dados pretendido e restaurar dados verificados sem o anfitrião original. Escale a situação quando as chaves não estiverem disponíveis, a desencriptação falhar em todas as cópias protegidas ou surgirem erros nos dispositivos; nenhuma reparação do sistema de ficheiros consegue reconstruir chaves de encriptação em falta.