Quando um sistema fundamental na sua empresa falha, as partes mais difíceis são saber o que restaurar primeiro, quem tem o acesso para o fazer, qual é a cópia de segurança de confiança e quanto tempo a sua empresa consegue continuar a funcionar sem esse sistema.
É aí que muitas pequenas e médias empresas (PMEs) descobrem a diferença entre ter cópias de segurança e ter um plano de recuperação real. Uma cópia de segurança pode conter os dados de que precisa, mas não decide a ordem de recuperação, não atribui responsabilidades, não valida se é possível restaurar nem resolve o problema de falta de credenciais de administrador durante uma interrupção.
Um plano de recuperação de desastres de TI dá estrutura a este processo antes que ocorra uma interrupção. Define quais os sistemas que mais importam, com que rapidez precisam de ser restaurados, que volume de perda de dados a empresa pode tolerar, que estratégias de prevenção de perda de dados deve implementar, quem é o responsável por cada etapa de recuperação e como as credenciais críticas são protegidas. Esta clareza pode evitar que um incidente de TI se transforme num período de inatividade prolongado, perda de receitas ou numa crise operacional mais ampla.
O que é um plano de recuperação de desastres de TI?
Continuidade de negócio vs. recuperação de desastres de TI
O que o seu plano de recuperação de desastres de TI deve abranger
O que o seu plano de recuperação de desastres de TI precisa de definir
Recuperação de credenciais: o cenário de recuperação de desastres esquecido
Modelo de plano de recuperação de desastres
Como testar o seu plano de recuperação de desastres de TI
Criar a recuperação em torno de sistemas, dados e acessos
O que é um plano de recuperação de desastres de TI?
Um plano de recuperação de desastres de TI é um processo documentado para restaurar sistemas tecnológicos após uma interrupção. Centra-se na camada de TI da empresa: dados, aplicações, dispositivos, infraestrutura, serviços na nuvem, acesso de administrador, cópias de segurança e as pessoas responsáveis pela recuperação.
Um plano de recuperação de TI prático deve responder a perguntas como:
- Quais são os sistemas que devem ser repostos primeiro?
- Quanto tempo de inatividade pode a empresa tolerar?
- Quanta perda de dados é aceitável?
- Onde estão armazenadas as cópias de segurança?
- Quem pode restaurar os sistemas?
- De que credenciais de administrador se necessita?
- Como irá a equipa confirmar que os sistemas restaurados estão seguros e utilizáveis?
- Como irá a empresa comunicar com os funcionários e clientes se os canais principais estiverem inativos?
Um plano de recuperação de desastres deve ir além do combate a ciberataques: precisa de abranger problemas quotidianos como falhas de hardware, perda de credenciais e eliminação acidental. Também necessita de abranger interrupções de serviços externos, tais como falhas na plataforma na nuvem ou nas ferramentas SaaS, configurações incorretas e a saída de colaboradores essenciais sem a transferência de acessos críticos.
A recuperação não é algo que se deva desenhar durante uma interrupção. Precisa de ser planeada, assumida, comunicada e testada antes que a sua empresa precise de depender dela.
Continuidade de negócio vs. recuperação de desastres de TI
A continuidade de negócio e a recuperação de desastres de TI são frequentemente tratadas como a mesma coisa, mas resolvem problemas diferentes.
A continuidade de negócio consiste em manter a empresa em funcionamento durante uma interrupção. Abrange a comunicação com os clientes, fluxos de trabalho temporários, responsabilidades dos funcionários, coordenação de fornecedores e decisões sobre quais os serviços que devem continuar a funcionar, mesmo que os sistemas normais estejam indisponíveis.
A recuperação de desastres de TI foca-se na tecnologia por trás desse trabalho. Define como os sistemas, dados, aplicações, cópias de segurança e acessos de administrador serão restaurados para que a empresa possa regressar às operações normais em segurança.
Como exemplo, considere uma interrupção do CRM. Um plano de continuidade de negócio pode explicar como as equipas de vendas ou de apoio ao cliente continuam a atender os clientes enquanto o CRM está inativo. O plano de recuperação de TI explica quem contacta o fornecedor, quais os dados que precisam de ser restaurados, que cópia de segurança ou exportação está disponível, quais as credenciais necessárias e como a equipa confirma que o sistema está seguro para voltar a ser utilizado.
Para muitas PMEs, a lacuna só surge durante um incidente. As pessoas sabem quem contactaria os clientes, mas não quem pode restaurar o sistema de faturação. Sabem que existem cópias de segurança, mas não se algum teste de restauro já foi realizado. Sabem que um funcionário costuma tratar da TI, mas não o que acontece se essa pessoa estiver indisponível ou onde estão armazenadas as palavras-passe de administrador caso essa pessoa esteja incontactável.
O que o seu plano de recuperação de desastres de TI deve abranger
Um plano de recuperação de desastres de TI robusto não tem de ser excessivamente longo, mas deve ser suficientemente específico para ser executado durante uma situação de stress.
Objetivo de tempo de recuperação
O objetivo de tempo de recuperação, ou RTO, define a rapidez com que um sistema precisa de ser restaurado. Um sistema de pagamentos pode ter de ser reposto em poucas horas, enquanto um painel de controlo de relatórios internos pode tolerar uma interrupção mais longa.
Defina os RTOs pelo impacto no negócio, e não por preferência técnica, porque o custo da inatividade é tanto um problema empresarial como técnico. Pergunte quais os sistemas que afetam as receitas, os compromissos com os clientes, as obrigações legais, a segurança e a produtividade dos funcionários.
Objetivo de ponto de recuperação
O objetivo de ponto de recuperação, ou RPO, define quanta perda de dados é aceitável, o que ajuda a definir as estratégias adequadas de prevenção de perda de dados (DLP). Se um sistema tiver um RPO de uma hora, as cópias de segurança ou a replicação precisam de permitir a recuperação até aproximadamente esse momento.
Se o RPO for de um dia, a empresa está a aceitar uma lacuna maior. O RPO também ajuda a determinar a frequência das cópias de segurança, porque quanto menor for o seu RPO, mais frequentes devem ser as suas cópias de segurança. Por conseguinte, os sistemas críticos necessitam de cópias de segurança mais frequentes do que os sistemas de baixa prioridade.
Níveis de prioridade dos sistemas
Nem todos os sistemas devem ser restaurados ao mesmo tempo. Um plano de recuperação de desastres para pequenas empresas deve dividir os sistemas em níveis de prioridade.
- Nível 1: sistemas necessários para operações fundamentais, segurança, comunicação ou receitas.
- Nível 2: sistemas importantes que podem tolerar curtos períodos de inatividade.
- Nível 3: sistemas de prioridade mais baixa que podem ser restaurados após a empresa estar estável.
Os sistemas típicos do nível 1 podem incluir e-mail, fornecedor de identidade, gestor de palavras-passe, sistemas financeiros, base de dados de clientes, armazenamento na nuvem e plataformas de comunicação.
Estratégia de cópias de segurança
A sua estratégia de cópias de segurança deve definir:
- Do que é feita cópia de segurança e com que frequência
- Onde as cópias de segurança são armazenadas
- Quem lhes pode aceder
- Como o restauro é testado
O NCSC também publicou(nova janela) princípios de cópias de segurança resistentes a ransomware para soluções na nuvem e locais, salientando que os dados com cópia de segurança não são resistentes a ransomware por predefinição e devem ser avaliados face a esta ameaça.
Uma estratégia de cópias de segurança robusta inclui normalmente cópias de segurança offline ou imutáveis para dados críticos, testes regulares, passos de restauro documentados e credenciais separadas para a administração das cópias de segurança.
Cargos e responsabilidades
Um plano de recuperação de desastres deve nomear responsáveis, e não apenas tarefas. Se uma única pessoa detém todo o conhecimento sobre a recuperação, a empresa corre um risco de pessoal, bem como um risco de TI. Defina quem:
- Lidera a recuperação
- Restaura os sistemas
- Contacta os fornecedores
- Aprova o acesso de emergência
- Comunica internamente
- Documenta as decisões
O que o seu plano de recuperação de desastres de TI precisa de definir
| Componente | O que responde |
| RTO | Com que rapidez cada sistema precisa de ser restaurado? |
| RPO | Quanta perda de dados pode a empresa suportar? |
| Níveis de prioridade | Quais os sistemas que devem ser repostos primeiro e quais os que podem esperar? |
| Estratégia de cópias de segurança | De que é feita cópia de segurança, onde está armazenada e se o restauro já foi testado? |
| Cargos e responsabilidades | Quem lidera a recuperação, restaura os sistemas, contacta os fornecedores e aprova as alterações de emergência? |
Recuperação de credenciais: o cenário de recuperação de desastres esquecido
A recuperação de desastres foca-se frequentemente em dados, servidores e cópias de segurança. Mas, na prática, a recuperação pode falhar porque a equipa não consegue aceder aos sistemas necessários para restaurar as operações.
A recuperação de credenciais questiona:
- Quem tem acesso a contas de administrador?
- Onde estão armazenadas as credenciais das cópias de segurança?
- Que contas podem restaurar sistemas críticos?
- O que acontece se uma palavra-passe for perdida, comprometida ou estiver na posse de alguém indisponível?
- As credenciais de emergência estão protegidas e são revistas?
- O acesso pode ser revogado e reatribuído rapidamente?
Se as credenciais das cópias de segurança estiverem armazenadas no navegador de um funcionário, os códigos de recuperação forem mantidos numa nota privada ou se as palavras-passe de administrador partilhadas circularem por chat, a empresa poderá não conseguir recuperar adequadamente durante um incidente.
Um gestor de palavras-passe empresarial ajuda a reduzir esse risco ao centralizar as credenciais críticas em cofres encriptados, atribuindo acessos por cargo e facilitando a revogação ou reatribuição de acessos quando alguém sai ou as responsabilidades mudam. O Proton Pass for Business ajuda as equipas a gerar palavras-passe fortes, a armazenar credenciais de forma segura, a utilizar a partilha segura e a manter os acessos confidenciais fora de chats e folhas de cálculo.
Como gestor de palavras-passe para equipas de TI, o Proton Pass suporta a gestão centralizada de credenciais, políticas de palavras-passe, partilha segura, relatórios e registos, aprovisionamento SCIM e integrações de SSO. Isto torna a recuperação de credenciais mais simples, uma vez que o acesso a sistemas críticos não depende de uma única pessoa, de um perfil de navegador ou de uma palavra-passe não documentada.
Modelo de plano de recuperação de desastres
Um plano de recuperação de desastres funciona melhor quando é suficientemente específico para orientar a ação durante uma interrupção, mas simples o suficiente para ser utilizado pela equipa sob pressão. Para as PMEs, o modelo deve focar-se no essencial: o que precisa de ser restaurado, com que rapidez, a partir de que cópia de segurança, por quem e com que credenciais.
1. Âmbito
Defina quais os sistemas, serviços, localizações, dispositivos e dados que o plano abrange.
Cópia do modelo: Este plano de recuperação de desastres de TI abrange os sistemas, dados, serviços, credenciais e fornecedores necessários para restaurar as operações críticas da [Company Name] após uma interrupção tecnológica.
2. Inventário de sistemas críticos
Liste os sistemas de que a sua empresa depende e atribua níveis de prioridade.
Cópia do modelo: Os sistemas críticos serão agrupados no Nível 1, Nível 2 e Nível 3 com base no impacto no negócio, no objetivo de tempo de recuperação, no objetivo de ponto de recuperação e na dependência de outros sistemas.
3. Objetivos de recuperação
Defina o RTO e o RPO para cada sistema prioritário.
Cópia do modelo: Cada sistema deve ter um objetivo de tempo de recuperação e um objetivo de ponto de recuperação documentados. Estas metas devem ser revistas pelo menos anualmente e após alterações importantes no sistema.
4. Processo de cópia de segurança e restauro
Documente onde as cópias de segurança são armazenadas, com que frequência são executadas, quem lhes pode aceder e como funcionam os testes de restauro.
Cópia do modelo: As cópias de segurança devem ser protegidas contra acessos não autorizados, armazenadas separadamente dos sistemas principais quando apropriado e testadas regularmente. Os procedimentos de restauro devem ser documentados para os sistemas do Nível 1.
5. Recuperação de credenciais e acessos
Defina onde as credenciais críticas estão armazenadas e quem lhes pode aceder durante a recuperação.
Cópia do modelo: As credenciais de administrador, as credenciais de cópias de segurança, os códigos de recuperação e os acessos de fornecedores necessários para a recuperação de desastres devem ser armazenados num cofre encriptado aprovado. O acesso deve ser limitado a cargos autorizados e revisto após alterações de cargos, processos de desvinculação e exercícios de recuperação.
6. Cargos e escalonamento
Defina os responsáveis pela recuperação, suplentes e caminhos de escalonamento.
Cópia do modelo: Cada cargo de recuperação deve ter um responsável principal e um responsável suplente. O plano deve identificar quem lidera a recuperação, quem restaura os sistemas, quem contacta os fornecedores, quem comunica as atualizações e quem aprova as alterações de emergência.
7. Plano de comunicação
Defina como a empresa comunica interna e externamente durante uma interrupção de TI.
Cópia do modelo: Durante um evento de recuperação, as atualizações internas serão partilhadas através do [canal aprovado]. As comunicações externas para clientes, fornecedores, seguradoras ou entidades reguladoras devem ser aprovadas por [cargo/equipa].
8. Cadência de testes e revisão
Defina com que frequência o plano é testado e atualizado.
Cópia do modelo: Este plano de recuperação de desastres será testado pelo menos [anualmente/duas vezes por ano] e revisto após incidentes graves, alterações de sistemas, alterações de fornecedores ou exercícios de recuperação mal sucedidos.
Como testar o seu plano de recuperação de desastres de TI
Um plano de recuperação de desastres só se torna útil quando é testado sob condições que se assemelham a uma interrupção real. Uma cópia de segurança que existe, mas que nunca foi restaurada, é apenas uma suposição. Um cargo de recuperação que apenas uma pessoa compreende é apenas uma dependência. Uma credencial de administrador que ninguém consegue encontrar durante uma interrupção é um obstáculo.
Os testes não precisam de ser complexos no início. Para a maioria das PMEs, o objetivo é provar que a empresa consegue restaurar os sistemas corretos, com as pessoas certas, utilizando as credenciais corretas, num prazo realista.
1. Exercício teórico
Escolha um cenário provável, como ransomware que afete ficheiros partilhados, uma interrupção do armazenamento na nuvem, a eliminação acidental de dados de clientes ou a perda súbita de acesso a uma conta de administrador. Analise o que a equipa faria na primeira hora, quem lideraria, quais os fornecedores que seriam contactados, quais os sistemas que teriam prioridade e que informações estariam em falta.
2. Testar o restauro
Selecione um ficheiro, base de dados, caixa de correio ou exportação de sistema crítico e confirme que pode ser restaurado para um estado utilizável. Verifique se os dados restaurados são suficientemente recentes, se as permissões continuam a funcionar e se a equipa sabe onde está a cópia de segurança.
3. Testar regularmente
Como ponto de partida prático, as PMEs devem testar o plano pelo menos uma vez por ano, em linha com a orientação do NIST na Special Publication 800-34 Revision 1(nova janela), e com maior frequência após alterações importantes de sistemas ou fornecedores.
4. Testar a recuperação de credenciais
Confirme que as pessoas autorizadas podem aceder a contas de administrador de cópias de segurança, contas de administrador na nuvem, portais de fornecedores, códigos de recuperação e credenciais de emergência sem depender do navegador de um único funcionário, de notas privadas ou da memória. O objetivo não é expor palavras-passe confidenciais desnecessariamente, mas sim confirmar que o modelo de acesso continua a funcionar quando a empresa está sob pressão.
Após cada teste, documente o que falhou, o que demorou demasiado tempo e atribua uma pessoa responsável específica e um prazo para cada correção. Um bom teste não é aquele em que tudo corre na perfeição, mas sim aquele que revela as lacunas enquanto a empresa ainda tem tempo para as corrigir.
Criar a recuperação em torno de sistemas, dados e acessos
Um plano de recuperação de desastres de TI útil dá à empresa uma ordem de recuperação, um conjunto de responsáveis, uma visão realista do tempo de inatividade aceitável e uma forma de manter a continuidade de negócio e recuperar o acesso aos sistemas que mantêm o trabalho em movimento.
Para as PMEs, isto pode fazer a diferença entre uma interrupção curta e uma paragem prolongada. Se o e-mail, o software financeiro, o armazenamento na nuvem, os sistemas de clientes ou as contas de administrador estiverem indisponíveis, a equipa precisa de saber o que vem primeiro, quem pode agir e quais as credenciais necessárias para restaurar o acesso em segurança.
É por isso que o planeamento da recuperação deve abranger sistemas, dados e acessos em conjunto. As cópias de segurança podem restaurar ficheiros, mas as credenciais são o que permite à equipa recuperar o controlo dos sistemas necessários para a recuperação. Os inícios de sessão de administrador, os portais de fornecedores, as contas de cópias de segurança, os códigos de recuperação e as credenciais operacionais partilhadas precisam de ser protegidos, organizados e estar disponíveis para as pessoas certas quando algo corre mal.
Um gestor de palavras-passe empresarial ajuda a reforçar essa parte do plano. Com as credenciais críticas armazenadas em cofres de palavras-passe encriptados e partilhadas apenas com pessoas autorizadas, a empresa fica menos dependente do navegador, das notas privadas ou da memória de um único funcionário durante um evento de recuperação.
