Um plano de recuperação de TI descreve como repor um serviço após uma interrupção grave, com dados suficientemente atuais e condições de segurança verificadas. A existência de cópias não demonstra que a organização consegue autenticar administradores, obter as chaves, reconstruir dependências e permitir novamente o trabalho dos utilizadores.
O resultado deste guia é um procedimento de recuperação acompanhado de um exercício preenchido. O exemplo utiliza um portal fictício de pedidos e distingue objetivos aprovados de resultados observados. Os tempos e frequências apresentados são escolhas ilustrativas, não prazos gerais impostos a todas as organizações.
Ligar a recuperação técnica à continuidade da atividade
O plano de continuidade da atividade determina que funções devem continuar, com que prioridades e que soluções temporárias existem. O plano de recuperação de TI concretiza a reposição dos sistemas necessários a essas funções. A ordem técnica deve refletir a necessidade operacional, incluindo pessoas, locais, comunicações e dependências externas.
O artigo 32.º do RGPD contempla a capacidade de restabelecer disponibilidade e acesso a dados pessoais em tempo oportuno após um incidente físico ou técnico. A forma adequada depende do risco. Requisitos setoriais ou contratuais devem ser analisados separadamente, sem converter uma recomendação de recuperação num prazo legal universal.
O NIST SP 800-34 rev.1, publicado em 2010, é uma referência metodológica para planeamento de contingência de sistemas. Use a estrutura de preparação e exercício com documentação atual dos serviços concretos. Um procedimento que depende de interfaces descontinuadas pode estar bem organizado e continuar inexequível.
Aprovar RTO e RPO com os responsáveis pela atividade
O RTO é o objetivo de tempo para recuperar o serviço no cenário definido. O RPO exprime a perda de dados tolerável em termos temporais: até que ponto anterior ao incidente se admite recuperar. Ambos precisam de uma definição de medição e de validação com quem utiliza o serviço.
Um RTO de quatro horas e um RPO de uma hora não significam que qualquer cópia feita diariamente serve. Também não garantem recuperação apenas porque foram escritos num contrato. A arquitetura, o volume, a rede, as chaves, a disponibilidade de pessoal e os procedimentos têm de suportar esses objetivos.
Defina o início e o fim da medição. No exemplo, o tempo começa com a interrupção do serviço e termina quando os percursos essenciais são validados pelo responsável operacional. Registe separadamente deteção, decisão de ativação, restauro e validação. Medir apenas a cópia dos ficheiros pode ocultar várias horas de espera antes ou depois dessa operação.
Inventariar a cadeia que precisa de voltar a funcionar
A cartografia de sistemas e fluxos deve identificar identidade, rede, resolução de nomes, certificados, bases, armazenamento, aplicações e integrações. Indique quais precisam de estar disponíveis primeiro. Um portal restaurado não atende utilizadores se o serviço de autenticação ou a ligação ao armazenamento continuar indisponível.
Inclua componentes menos visíveis: licenças, segredos, imagens de instalação, configurações, contactos de prestadores e permissões de emergência. Verifique se a documentação de recuperação depende do próprio sistema afetado. Uma cópia controlada, acessível no cenário de falha previsto, pode ser necessária para não ficar bloqueado no primeiro passo.
Registe responsáveis e substitutos. A pessoa de prevenção deve conseguir executar o procedimento com as competências e acessos previstos, sem depender de conhecimento que só um especialista ausente possui. Quando uma etapa exige o fornecedor, combine o percurso de contacto e confirme que existe capacidade contratada compatível com o objetivo.
Escolher cópias e isolamento para o cenário
Diferencie replicação, cópias históricas e capacidade de reconstrução. A replicação pode manter disponibilidade perante uma falha de equipamento e também propagar uma eliminação indevida. Uma cópia histórica permite voltar atrás, mas precisa de integridade, acesso e proteção contra alteração ou destruição.
Avalie separação administrativa, isolamento e mecanismos de imutabilidade quando pertinentes. Não conte como independentes duas cópias controladas pela mesma credencial comprometida. Verifique também como se recupera o acesso quando o diretório principal está indisponível e quem pode alterar as regras de conservação das cópias.
O plano de cifragem e gestão de chaves integra esta análise. Uma cópia cifrada sem chave recuperável não repõe os dados. Por outro lado, colocar a chave ao lado de todas as cópias sem restrições enfraquece a proteção. O procedimento deve equilibrar recuperação autorizada e limitação de acessos.
Exemplo preenchido de exercício de restauro
Uma empresa fictícia escolhe o portal PEDIDOS para um exercício em ambiente isolado. O objetivo aprovado é recuperar em quatro horas, admitindo perda máxima de uma hora de alterações. O cenário simula indisponibilidade da aplicação e do armazenamento principal; não pressupõe acesso normal aos componentes afetados.
| Etapa observada | Resultado fictício |
|---|---|
| Interrupção simulada | 09:00, início da medição |
| Deteção e ativação | 09:20, responsável autoriza o procedimento |
| Ambiente preparado | 10:00, rede e identidade de recuperação disponíveis |
| Cópia selecionada | Estado consistente das 08:30, validado antes do restauro |
| Dados e aplicação repostos | 11:40, verificações técnicas concluídas |
| Validação operacional | 12:10, criar pedido, consultar histórico e receber confirmação funcionam |
| Resultado RTO | 3 horas e 10 minutos, dentro do objetivo deste exercício |
| Resultado RPO | 30 minutos de alterações potencialmente perdidas, dentro do objetivo definido |
O resultado só vale para o cenário ensaiado. Se a cópia das 08:30 estiver comprometida, pode ser necessário regressar a um ponto anterior e o RPO deixar de ser cumprido. O relatório deve identificar o que foi pressuposto, que componentes não foram testados e que conclusões podem efetivamente ser retiradas.
Validar dados, permissões e operações
A validação deve incluir percursos do utilizador e coerência dos dados, não apenas serviços com estado «ativo». No exemplo, confirme que um cliente consulta os seus pedidos e não os de outro, que novos pedidos são guardados e que as notificações vão para os destinatários corretos.
Compare uma amostra controlada de registos, documentos e relações. Uma base pode abrir e ter anexos ausentes. Uma integração pode reenviar operações já executadas, criando duplicados ou comunicações indevidas. Defina como reconciliar trabalho realizado por meios temporários durante a interrupção.
Verifique também que a reposição não reativa contas revogadas ou elimina restrições posteriores à cópia. O procedimento deve reaplicar decisões relevantes, como retirada de acessos e oposição ao marketing, antes da reabertura dos respetivos percursos. Uma recuperação técnica não deve desfazer silenciosamente decisões de proteção de dados já executadas.
Preparar a recuperação após comprometimento
Quando exista suspeita de intrusão, a escolha do ponto de restauro exige análise adicional. Repor rapidamente uma imagem que conserva a causa do incidente pode levar a novo comprometimento. Coordene contenção, investigação, preservação de evidência e reconstrução segura, com responsabilidades claras.
A equipa deve identificar credenciais e configurações que precisam de substituição ou correção. Use as configurações seguras de Windows e Linux como referência operacional para reconstruir componentes, adaptando a base aos sistemas efetivamente utilizados. Não ligue automaticamente o ambiente recuperado a sistemas ainda suspeitos.
Os registos de eventos de segurança ajudam a reconstruir a sequência, mas também podem estar incompletos ou indisponíveis. Documente a incerteza. A decisão de regressar a produção deve considerar integridade e risco de recorrência, além do relógio do RTO.
Definir o regresso ao ambiente normal
A transição de um ambiente temporário para o habitual exige um procedimento próprio. Indique qual sistema é a fonte válida durante a recuperação, como serão transferidas alterações e quando se impede escrita simultânea. Duas versões independentes da base podem gerar divergências difíceis de corrigir.
Programe uma validação antes e depois da transição e um critério de interrupção caso surjam erros. Confirme comunicações aos utilizadores, capacidade de apoio e eliminação dos acessos temporários. O exercício deve revelar se o regresso necessita de uma janela ou aprovação que ainda não foi prevista.
Desative recursos de emergência apenas depois de confirmar estabilidade e conservar os elementos necessários à análise. Cópias temporárias, contas e permissões abertas para o exercício precisam de encerramento controlado. Inclua esse trabalho no custo e no calendário da recuperação.
Fechar o exercício com ações verificáveis
O relatório deve comparar objetivos e resultados, explicar desvios e atribuir correções. Se demorou uma hora a obter uma chave porque o contacto estava desatualizado, a ação é corrigir o circuito e voltar a verificar a etapa. Escrever «melhorar comunicação» não permite confirmar que a dependência foi resolvida.
Escolha a frequência e a profundidade dos exercícios segundo o risco e as mudanças relevantes. Uma alteração de fornecedor, identidade ou arquitetura pode justificar nova verificação antes do ciclo periódico. Não existe uma periodicidade única do RGPD que valide todos os planos de recuperação.
Acompanhe tempo total observado, ponto de dados recuperado, percursos validados e ações ainda abertas. Estas medidas permitem decidir se o serviço pode cumprir os objetivos aprovados ou se precisa de outra arquitetura, capacidade ou solução de continuidade. Um plano útil termina numa recuperação demonstrada e em limitações conhecidas que a gestão consegue tratar.