Cópias de segurança e recuperação no fornecimento de serviços TIC: quando foi a última vez que testou?
A pergunta "tem uma cópia de segurança" não é a pergunta que importa. A pergunta que importa é: quando foi que alguém tentou pela última vez restaurar um sistema a partir dessa cópia de segurança e quanto tempo levou? Uma cópia de segurança que é feita mas nunca restaurada é, na prática, uma suposição. Autoridades de supervisão e clientes que se baseiam nas medidas de segurança obrigatória da Diretiva NIS2 portanto não olham apenas para a existência de uma política de cópia de segurança, mas para a prova de que a recuperação funciona realmente.
Para um fornecedor de serviços TIC, isto não é uma questão secundária. Muitas vezes não gere apenas o seu próprio ambiente, mas também sistemas de clientes, remotamente, por vezes com a ajuda de um subcontratado. Se algo correr mal, não importa quem cometeu o erro, mas se a recuperação funcionou num prazo que o cliente podia justificar. Isso torna o teste de recuperação uma das poucas medidas que não pode confirmar apenas com um documento.
Por que uma cópia de segurança não testada não conta
Uma cópia de segurança pode não ser utilizável por várias razões: um ficheiro corrompido, uma configuração incorreta, uma palavra-passe que ninguém mais tem, ou um procedimento de recuperação que funcionava no papel mas que na prática leva três dias em vez de três horas. Nenhum desses problemas se torna visível até alguém usar efetivamente a cópia de segurança. O artigo 21 da Diretiva NIS2 menciona explicitamente a política de cópia de segurança e recuperação como parte das medidas de segurança obrigatória que uma organização considera com os seus fornecedores. Na prática, isto significa que um cliente que está sujeito às medidas de segurança obrigatória pergunta ao seu fornecedor TIC como está organizada a recuperação e, cada vez mais frequentemente, quando foi testada pela última vez.
O que uma autoridade de supervisão ou um cliente entende por "testada" não está uniformemente definido, mas a questão fundamental aparece sempre: houve um momento em que um sistema ou um conjunto de dados foi efetivamente restaurado, separado do ambiente de produção, e o resultado foi registado? Um relatório de teste com uma data e um resultado é diferente de uma comunicação interna que diz "as cópias de segurança estão a funcionar".
Gestão remota: de quem é a cópia de segurança afinal
Na gestão remota, a cópia de segurança de um sistema de cliente muitas vezes não está fisicamente junto do cliente, mas junto do fornecedor de serviços, ou junto de um serviço em nuvem que o fornecedor configurou em nome do cliente. Isso desloca uma questão que à primeira vista parece técnica para uma questão de responsabilidade: quem testa, quem conserva o resultado do teste e quem pode provar que a recuperação funciona quando o cliente pergunta? Um questionário de segurança de um cliente pergunta cada vez mais concretamente sobre isto, e "o nosso parceiro de alojamento trata disso" não é uma resposta para uma autoridade de supervisão ou um auditor — é um encaminhamento que exige uma verificação própria.
Por isso é sensato documentar, para cada sistema de cliente, quem tem acesso à cópia de segurança, como esse acesso está protegido e quem é responsável pelo último teste de recuperação. as medidas de segurança obrigatória por tema examinadas mostra como a cópia de segurança e recuperação se relacionam com as outras medidas das medidas de segurança obrigatória, como controlo de acesso e registo de incidentes.
Subcontratados: quem testa o quê
Muitos fornecedores de serviços TIC trabalham com subcontratados para partes específicas: um prestador de alojamento, uma entidade que gere a firewall, um freelancer que implementa patches. Se um deles também gere a cópia de segurança, o teste de recuperação desaparece facilmente entre duas partes: o fornecedor de serviços pensa que o subcontratado testa, o subcontratado pensa que isso não faz parte da sua tarefa. Para o cliente não faz diferença — pergunta à entidade com quem tem um contrato.
Por isso, é aconselhável especificar claramente nos acordos com um subcontratante quem realiza o teste de restauração, com que frequência, e quem mantém a prova. Essa prova não precisa ser um relatório extenso; uma data, uma descrição do que foi restaurado e o resultado geralmente são suficientes para demonstrar a um cliente que a restauração não é uma suposição.
O que você documenta e o que não
Um teste de restauração é trabalho humano: alguém restaura um sistema, mede quanto tempo isso leva e verifica se os dados estão corretos. Você realiza esse trabalho ou o deixa a cargo da sua equipa de gestão; uma plataforma não pode fazer isso por você, assim como não pode substituir um teste de penetração ou uma auditoria. O que é útil é um local onde o resultado de cada teste fica junto com as outras medidas de conformidade, para que na próxima lista de verificação você não precise procurar quando foi a última vez que isso aconteceu.
Se ainda não sabe se a sua organização está sujeita à obrigação de conformidade por si mesma, ou apenas vai lidar com essas questões através de um cliente, vê em cinco perguntas onde se encontra isso dá uma primeira indicação. Se quiser saber como lidamos com os dados que regista num tal dossier, como lidamos com os seus dados explica isso. E se tiver dúvidas sobre se a sua situação se enquadra exatamente aqui, consulte respostas a perguntas frequentes ou contacte a autoridade de supervisão do seu setor.
A verificação gratuita de NIS2 e a base de conhecimento em secria.eu mostram onde cópias de segurança e restauração ficam exatamente na sua situação, sem necessidade de conta.