Continuidade do negócio: demonstre o percurso de recuperação

Um plano de recuperação torna-se credível quando a equipa consegue mostrar como um serviço crítico será reposto, por que ordem e com que recursos. Uma cópia de segurança é um dos elementos desse plano; não estabelece, por si só, toda a capacidade de recuperação.

Para um CTO, a questão prática é saber se a recuperação continua a funcionar quando os pressupostos normais de funcionamento falham. Outro engenheiro consegue executar o procedimento? A equipa consegue obter credenciais sem o serviço de identidade de produção? Os utilizadores de negócio conseguem concluir uma transação depois de a infraestrutura ter sido reposta?

Trate a continuidade como uma capacidade de engenharia: defina resultados aceitáveis, identifique dependências, construa procedimentos de recuperação, exercite-os e conserve evidências do que aconteceu. O resultado é um percurso de recuperação demonstrado, com as suas limitações compreendidas e as suas fragilidades atribuídas para correção.

Estabeleça a obrigação e a fronteira operacional

O artigo 21.º da NIS2 inclui, entre as medidas de gestão dos riscos de cibersegurança, a continuidade das atividades, como a gestão de cópias de segurança e a recuperação de desastres, e a gestão de crises. Aborda também as políticas e os procedimentos para avaliar a eficácia dessas medidas. O artigo 20.º trata da aprovação e supervisão pelos órgãos de gestão.

A NIS2 é uma diretiva transposta através da legislação nacional. A aplicabilidade depende do setor, da dimensão, do serviço e das regras de inclusão; os requisitos nacionais e setoriais aplicáveis determinam as obrigações específicas. Não trate um modelo genérico de continuidade como uma avaliação jurídica completa.

Do ponto de vista operacional, distinga quatro atividades interligadas:

• Continuidade do negócio: manter as funções de negócio importantes em funcionamento, eventualmente com capacidade reduzida.
• Gestão de cópias de segurança: manter cópias protegidas e recuperáveis dos dados e da configuração necessária.
• Recuperação de desastres: repor os sistemas técnicos e validar o serviço que suportam.
• Gestão de crises: coordenar decisões, recursos, comunicações e escalamento.

Um serviço pode continuar através de trabalho manual enquanto os seus sistemas permanecem indisponíveis. Inversamente, os servidores podem estar a funcionar enquanto a função de negócio continua inutilizável. Defina critérios de aceitação técnicos e de negócio.

Comece com um serviço crítico e uma fronteira de cenário explícita. Recuperar de uma eliminação acidental é diferente de recuperar depois de as credenciais administrativas terem sido comprometidas. Registe que situações o plano cobre, quais precisam de procedimentos separados e quem aceita qualquer lacuna remanescente.

Trabalhe a partir do serviço de negócio

Uma análise de impacto no negócio, ou BIA, estabelece o que significa uma perturbação antes de a engenharia selecionar um desenho de recuperação. Entreviste o responsável pelo serviço e as pessoas que efetivamente executam o trabalho. Pergunte o que acontece ao fim de uma hora, de um dia útil e de uma interrupção mais longa: transações perdidas, operações inseguras, incumprimentos contratuais, danos para clientes ou acumulação de trabalho pendente.

Documente o nível mínimo aceitável de funcionamento. Um portal de clientes pode precisar de submissão de encomendas e de consulta do estado das encomendas antes do regresso das funcionalidades de relatórios. Uma operação de produção pode precisar de planeamento e de informação de segurança antes das funções administrativas.

Três medidas orientam o desenho:

Estão relacionadas, mas são diferentes. O RTO deve deixar margem, dentro da perturbação tolerável, para a validação pelo negócio e a recuperação operacional. O RPO descreve a perda de dados aceitável; não é outro objetivo de indisponibilidade.

Acorde explicitamente o ponto de partida da contagem. Se uma equipa medir o RTO a partir da declaração do incidente e outra a partir da interrupção do serviço, os resultados reportados serão enganadores. Registe separadamente as horas de deteção e de ativação, mesmo quando a métrica de recuperação acordada começa mais tarde.

Os responsáveis de negócio aprovam o resultado exigido; a engenharia demonstra se o desenho o consegue cumprir. Quando limitações de custo, pessoal ou fornecedores tornam um objetivo irrealista, apresente as opções: investir numa recuperação mais rápida, introduzir operações reduzidas, alterar o objetivo com aprovação responsável ou aceitar o risco. Não substitua silenciosamente um requisito de negócio por aquilo que o sistema de cópias de segurança atual por acaso consegue.

Mapeie as dependências que podem impedir a recuperação

Num portal de clientes, repor a base de dados pode ainda deixar o serviço inutilizável se a identidade, o DNS ou as credenciais de implementação estiverem indisponíveis. Construa um mapa de dependências a partir da transação de negócio para fora, e não a partir do inventário de servidores para dentro.

Inclua aplicações e bases de dados, mas também redes, fornecedores de identidade, serviços de certificados, segredos, chaves de cifragem, artefactos de implementação, monitorização, integrações externas, pessoas e suporte de fornecedores. Registe onde cada dependência é operada, quem a consegue recuperar e o que tem de existir antes de a recuperação começar.

Procure em particular dependências circulares. O cofre de palavras-passe pode exigir a plataforma de identidade, enquanto a reposição dessa plataforma exige credenciais guardadas no cofre. O guia de recuperação pode estar no serviço de colaboração que está ele próprio indisponível. Resolva estes ciclos através de acesso de emergência controlado e de instruções acessíveis de forma independente; teste ambos, em vez de presumir que funcionam.

A ordem de recuperação é um grafo de dependências, não necessariamente uma sequência universal de rede, base de dados e aplicação. Algumas tarefas podem decorrer em paralelo. Outras têm pontos de controlo, como confirmar que existe um ambiente administrativo limpo antes de lhe expor cargas de trabalho repostas.

Quanto aos fornecedores, distinga promessas de acordos operacionais. Estabeleça contactos de suporte, vias de escalamento, responsabilidades do lado do cliente, opções de exportação, compromissos de recuperação e a forma como receberá atualizações durante a perturbação. O objetivo de recuperação de um fornecedor não estabelece automaticamente o seu objetivo de serviço de ponta a ponta. Modele o que acontece se o fornecedor estiver indisponível durante mais tempo do que o esperado.

Desenhe as cópias de segurança em função da recuperação, e não da conclusão das tarefas

Uma tarefa de backup bem-sucedida mostra que um processo terminou. Não prova que os dados certos foram capturados, que as chaves continuam disponíveis nem que a aplicação consegue utilizar o estado reposto.

Crie uma especificação de cópias de segurança para cada sistema crítico:

• Conjuntos de dados, configuração e artefactos incluídos e exclusões explícitas.
• Método de backup, calendário, antiguidade esperada do ponto de recuperação e conservação.
• Locais de armazenamento e dependências de contas, regiões ou instalações.
• Acesso administrativo, cifragem, recuperação de chaves e controlos de eliminação.
• Responsabilidades de monitorização, escalamento de falhas e instruções de reposição.
• Âmbito dos testes de reposição, critérios de aceitação e resultados conservados.

A abordagem 3-2-1, frequentemente utilizada e por vezes alargada com uma cópia offline ou imutável e verificação, é uma heurística prática de desenho, não uma fórmula universal da NIS2. Avalie se as cópias têm modos de falha realmente diferentes. Várias cópias geridas através de uma única conta de administrador comprometida podem oferecer pouca proteção contra a eliminação deliberada.

As cópias offline e imutáveis também são diferentes. O armazenamento offline está desligado; o armazenamento imutável restringe a modificação ou eliminação segundo controlos definidos. Examine quem pode alterar a conservação, destruir chaves, encerrar a conta ou alterar políticas de acesso. Evite tratar o rótulo, por si só, como prova de proteção.

Adeque o mecanismo aos dados

Numa base de dados transacional, a frequência dos instantâneos, por si só, pode não cumprir o RPO. Pode ser necessária a captura de registos de transações, cópias de segurança consistentes ao nível da aplicação e recuperação para um momento específico. Valide se as transações distribuídas por vários sistemas podem ser recuperadas para um estado coerente.

A replicação pode reduzir a interrupção, mas também pode replicar corrupção ou alterações maliciosas. Não substitui pontos de recuperação conservados. Do mesmo modo, um compromisso de disponibilidade de um SaaS pode não cobrir a recuperação de uma eliminação pelo cliente ou do comprometimento de uma conta; verifique os acordos reais de recuperação e exportação.

Inclua as chaves de cifragem e a configuração necessárias para interpretar os dados repostos. Proteja separadamente o material de recuperação quando adequado, com acesso controlado e uma via de obtenção testada. A cifragem e gestão de chaves deve cobrir a recuperação, além do funcionamento normal.

A conservação tem de ter em conta a descoberta tardia: a cópia mais recente pode já conter o problema. Selecionar um ponto limpo mais antigo pode aumentar a perda de dados para além do RPO. Documente esse compromisso e o trabalho de reconciliação necessário, em vez de considerar um êxito qualquer reposição concluída.

Escreva runbooks que outro engenheiro consiga executar

Um runbook de recuperação útil identifica pré-requisitos, ações, resultados esperados, ramos de falha e verificações de aceitação. Deve ser suficientemente específico para que um substituto autorizado o consiga seguir sem ter de reconstruir a arquitetura sob pressão.

Comece pelas condições de ativação e pelos limites de segurança. Quem autoriza a recuperação? Onde vai decorrer? Que redes têm de permanecer isoladas? Que alterações em produção são proibidas durante o exercício? Se houver suspeita de atividade maliciosa, preserve as evidências relevantes e coordene a contenção antes de voltar a ligar os sistemas recuperados.

Cada passo deve conter:

Remeta para procedimentos controlados no caso de comandos específicos de cada ambiente. Mantenha os segredos fora do próprio runbook, mas explique como os intervenientes autorizados os obtêm durante uma indisponibilidade.

Meça separadamente a preparação, a transferência, a reposição, a configuração, a validação e a passagem de testemunho. Uma reposição rápida dos dados pode, mesmo assim, falhar o RTO porque o aprovisionamento da infraestrutura ou as verificações de negócio demoram mais do que o previsto.

Na recuperação de ciberataques, reconstruir a partir de artefactos de confiança pode ser mais seguro do que repor máquinas inteiras. Valide as contas privilegiadas, renove as credenciais expostas conforme adequado e verifique a existência de mecanismos de persistência antes da libertação. Estas decisões devem ser ramos explícitos do procedimento.

Termine com verificações ao nível do serviço: autenticação, uma transação representativa, comportamento das integrações, monitorização e reconciliação. O responsável técnico regista a conclusão; o responsável de negócio aceita o nível de funcionamento acordado. Inclua um regresso controlado dos acordos temporários, com responsabilidade pela resolução do trabalho em fila e dos registos duplicados.

Mantenha o negócio a funcionar enquanto a recuperação decorre

As operações alternativas precisam dos seus próprios limites de capacidade e de segurança. “Usar uma folha de cálculo” não é um plano, a menos que alguém tenha estabelecido o acesso, os campos, a autorização, a proteção do armazenamento e a reconciliação posterior.

Num serviço de encomendas perturbado, um processo temporário pode aceitar uma classe limitada de encomendas através de um canal aprovado, emitir referências únicas e adiar o processamento de pagamentos. Registe quem autoriza as encomendas, como se evitam duplicados, como se protege a informação dos clientes e quando o processo alternativo tem de terminar.

Avalie se as operações reduzidas permitem de facto ganhar tempo suficiente. O processamento manual pode sustentar um volume pequeno, mas colapsar com a carga de trabalho normal. Teste uma procura representativa e identifique os clientes ou transações prioritários segundo critérios de negócio acordados.

Planeie também para as pessoas e os locais de trabalho. A recuperação pode falhar porque o único operador qualificado está indisponível, o local alternativo não tem conectividade ou os intervenientes não conseguem trabalhar em segurança durante um incidente prolongado. Atribua substitutos, requisitos de passagem de testemunho e escalas de pessoal, em vez de contar com a resistência individual.

Dê à equipa de crise direitos de decisão claros

Separe a coordenação do incidente da recuperação prática, para que o responsável técnico não esteja ao mesmo tempo a repor sistemas, a aprovar despesas e a responder a todas as partes interessadas.

Atribua funções principais e substitutas para a coordenação da crise, a recuperação técnica, as operações de negócio, as decisões executivas, as comunicações e a avaliação jurídica ou de conformidade. Registe os limiares de ativação, os meios de contacto, a autoridade de decisão e as condições de escalamento. As pré-autorizações práticas podem abranger compras de suporte de emergência, infraestrutura alternativa e a suspensão de serviços inseguros, dentro de limites aprovados pela gestão.

Prepare modelos de comunicação para colaboradores, clientes, fornecedores e autoridades. Cada um deve distinguir os factos conhecidos das estimativas, descrever os serviços afetados, dar instruções atuais e indicar a hora da próxima atualização. Teste um canal alternativo para quando o e-mail e o chat da empresa estiverem indisponíveis. Assegure que os intervenientes conseguem aceder à informação de contacto de forma segura fora dos sistemas normais.

A avaliação das notificações tem de decorrer em paralelo com a recuperação. No caso de incidentes significativos dentro do âmbito, o artigo 23.º da NIS2 estabelece um alerta precoce em 24 horas, uma notificação do incidente em 72 horas e, em geral, um relatório final no prazo de um mês após a notificação. Verifique as regras, limiares, destinatários e procedimentos nacionais e setoriais aplicáveis. Nem todas as indisponibilidades são automaticamente de notificação obrigatória.

Designe alguém para acompanhar o momento de conhecimento e as decisões de notificação; não espere pela reposição completa para avaliar as obrigações. Quando estiverem envolvidos dados pessoais, avalie os requisitos de notificação de violações do RGPD, que são distintos, em função do papel da organização e do risco para as pessoas.

Teste afirmações diferentes com exercícios diferentes

Escolha o tipo de exercício em função do que precisa de provar:

Defina a frequência como uma decisão prática e baseada no risco, informada pelos requisitos aplicáveis, pela criticidade do serviço, pelo ritmo de alterações e pelas conclusões anteriores. Não presuma que um intervalo universal trimestral ou anual satisfaz todas as obrigações. Desencadeie testes adicionais após alterações materiais na arquitetura, nos fornecedores, nos acessos ou no pessoal.

Antes de testar, aprove o cenário, os objetivos, os controlos de segurança, os participantes, as condições de paragem e os critérios de êxito. Prefira ambientes isolados sempre que possível. Impeça que mensagens, pagamentos ou notificações a clientes de teste cheguem às operações reais.

Utilize restrições realistas: um especialista ausente, serviços de identidade indisponíveis, uma cópia de segurança limpa mais antiga ou suporte de fornecedor atrasado. Evite fornecer discretamente credenciais e infraestrutura que não existiriam durante o incidente.

Registe o cenário, os participantes, as horas de início e de fim, os tempos de cada passo, os resultados reais e os desvios. Registe a assistência e os atalhos. Se o teste omitiu alterações de DNS, dados com volume de produção ou integrações externas, diga-o. Um resultado delimitado é mais útil do que uma aprovação exagerada.

Exemplo prático: demonstrar o percurso de recuperação de um portal de clientes

Considere um portal ilustrativo que suporta a submissão de encomendas. Os objetivos e tempos seguintes são pressupostos, não referenciais do setor nem promessas de produto.

O negócio acorda um RTO de quatro horas e um RPO de 15 minutos. Recuperar significa que os clientes se conseguem autenticar, submeter uma encomenda e ver o seu estado; os relatórios podem regressar mais tarde. O cenário pressupõe que a infraestrutura de produção e as credenciais habituais de administrador estão indisponíveis, mas que uma cópia de segurança controlada separadamente continua acessível.

A equipa orçamenta o percurso da seguinte forma:

Isto deixa apenas 20 minutos de margem face ao objetivo de quatro horas. Como várias tarefas dependem de um único engenheiro de recuperação, a equipa não presume que possam decorrer em simultâneo.

Durante o exercício, a obtenção das credenciais de implementação demora mais 55 minutos: a via de acesso documentada depende do fornecedor de identidade indisponível. O serviço passa nas verificações funcionais ao fim de 275 minutos e falha o RTO. A sua última transação recuperável é de 12 minutos antes da interrupção, cumprindo o RPO pressuposto para este cenário.

O resultado não é uma aprovação geral. O responsável pelos acessos estabelece uma via de obtenção independente e controlada, o runbook é atualizado e um engenheiro substituto volta a testá-lo. O próximo exercício integrado tem de verificar novamente o tempo decorrido total. O responsável de negócio avalia também se a margem de tempo restante é suficiente para condições menos favoráveis.

Conserve as evidências e corrija as fragilidades

Mantenha um conjunto coerente de evidências: a BIA aprovada, a fronteira e as dependências do serviço, a especificação das cópias de segurança, os runbooks de recuperação, as funções e os contactos de crise, os procedimentos de operação alternativa e os registos dos exercícios. Preserve as versões, para que os revisores possam ver que plano foi efetivamente testado.

Para cada fragilidade material, registe o serviço afetado, o resultado observado, a consequência para o negócio, o responsável, a data-limite, a correção e o método de verificação. Concluir uma tarefa não é o mesmo que provar a correção. Volte a testar o passo afetado e, se as dependências mudaram, o percurso de recuperação mais amplo. Escale as ações em atraso e as lacunas face aos objetivos para o decisor responsável.

Na Secani, modele o serviço crítico e os sistemas e fornecedores que o suportam, ligue as evidências dos exercícios aos requisitos ou controlos que sustentam e transforme as lacunas em tarefas com responsável. Mantenha os comentários dos revisores e as aprovações humanas associados às decisões. O fluxo de trabalho documentado suporta esse contexto de evidências; a recuperação técnica continua a ter de ser executada e validada pela equipa responsável.

Comece com um serviço crítico. Acorde o que significa recuperar, percorra o seu caminho de dependências com um operador substituto e agende um exercício de reposição delimitado. Utilize o resultado medido para atualizar o plano, e não apenas para assinalar o exercício como concluído.