Quando um sistema essencial da sua empresa cai, as partes mais difíceis são saber o que restaurar primeiro, quem tem acesso para fazer isso, qual backup é de confiança e por quanto tempo sua empresa consegue continuar funcionando sem esse sistema.
É aí que muitas pequenas e médias empresas (PMEs) descobrem a diferença entre ter backups e ter um plano de recuperação real. Um backup pode conter os dados de que você precisa, mas ele não decide a ordem de recuperação, não atribui responsabilidades, não valida se a restauração funciona nem resolve o problema de falta de credenciais de administrador durante uma interrupção.
Um plano de recuperação de desastres de TI estrutura esse processo antes que ocorra uma interrupção. Ele define quais sistemas são mais importantes, com que rapidez eles precisam ser restaurados, quanta perda de dados a empresa pode tolerar, quais estratégias de prevenção de perda de dados devem ser implementadas, quem é o responsável por cada etapa de recuperação e como as credenciais críticas são protegidas. Essa clareza pode evitar que um incidente de TI se transforme em um tempo de inatividade prolongado, perda de receita ou uma crise operacional mais ampla.
O que é um plano de recuperação de desastres de TI?
Continuidade de negócios vs. recuperação de desastres de TI
O que o seu plano de recuperação de desastres de TI deve cobrir
O que o seu plano de recuperação de desastres de TI precisa definir
Recuperação de credenciais: o cenário de recuperação de desastres negligenciado
Modelo de plano de recuperação de desastres
Como testar o seu plano de recuperação de desastres de TI
Crie 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 de tecnologia após uma interrupção. Ele se concentra na camada de TI da empresa: dados, aplicativos, dispositivos, infraestrutura, serviços em nuvem, acesso de administrador, backups e as pessoas responsáveis pela recuperação.
Um plano prático de recuperação de TI deve responder a perguntas como:
- Quais sistemas devem ser restabelecidos primeiro?
- Quanto tempo de inatividade a empresa pode tolerar?
- Quanta perda de dados é aceitável?
- Onde os backups estão armazenados?
- Quem pode restaurar os sistemas?
- Quais credenciais de administrador são necessárias?
- Como a equipe vai confirmar se os sistemas restaurados estão seguros e utilizáveis?
- Como a empresa se comunicará com a equipe e com os clientes se os canais principais estiverem inativos?
Um plano de recuperação de desastres deve ir além de lidar com ataques cibernéticos: ele precisa cobrir problemas cotidianos, como falhas de hardware, perda de credenciais e exclusão acidental. Ele também precisa cobrir interrupções de serviços externos, como falhas em plataformas de nuvem ou ferramentas SaaS, erros de configuração e a saída de funcionários essenciais sem a transferência de acessos críticos.
A recuperação não é algo para se planejar durante uma interrupção. Ela precisa ser planejada, ter responsáveis definidos, ser comunicada e testada antes que a sua empresa precise depender dela.
Continuidade de negócios vs. recuperação de desastres de TI
A continuidade de negócios e a recuperação de desastres de TI geralmente são tratadas como a mesma coisa, mas resolvem problemas diferentes.
Continuidade de negócios consiste em manter a empresa funcionando durante uma interrupção. Ela abrange a comunicação com clientes, fluxos de trabalho temporários, responsabilidades da equipe, coordenação com fornecedores e decisões sobre quais serviços precisam continuar mesmo que os sistemas normais estejam indisponíveis.
A recuperação de desastres de TI se concentra na tecnologia por trás desse trabalho. Ela define como sistemas, dados, aplicativos, backups e acessos de administrador serão restaurados para que a empresa possa retornar às operações normais com segurança.
Como exemplo, pense em uma queda no CRM. Um plano de continuidade de negócios pode explicar como as equipes de vendas ou de suporte continuam atendendo aos clientes enquanto o CRM está fora do ar. O plano de recuperação de TI explica quem entra em contato com o fornecedor, quais dados precisam ser restaurados, qual backup ou exportação está disponível, quais credenciais são necessárias e como a equipe confirma se o sistema está seguro para uso novamente.
Para muitas PMEs, a lacuna só aparece durante um incidente. As pessoas sabem quem entraria em contato com os clientes, mas não quem pode restaurar o sistema de faturamento. Sabem que os backups existem, mas não se a restauração já foi testada alguma vez. Sabem que um funcionário costuma cuidar do TI, mas não o que acontece se essa pessoa não estiver disponível ou onde as senhas de administrador estão armazenadas caso ela esteja fora de contato.
O que o seu plano de recuperação de desastres de TI deve cobrir
Um bom plano de recuperação de desastres de TI não precisa ser excessivamente longo, mas deve ser específico o suficiente para ser executado durante uma situação estressante.
Objetivo de tempo de recuperação
O objetivo de tempo de recuperação, ou RTO, define a rapidez com que um sistema precisa ser restaurado. Um sistema de pagamento pode precisar retornar em poucas horas, enquanto um painel de controle de relatórios internos pode tolerar uma interrupção mais longa.
Defina os RTOs com base no impacto comercial, e não por preferência técnica, porque o custo do tempo de inatividade é um problema tanto comercial quanto técnico. Pergunte quais sistemas afetam a receita, 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 corretas de prevenção de perda de dados (DLP). Se um sistema tiver um RPO de uma hora, os backups ou a replicação precisam dar suporte à recuperação até aproximadamente esse ponto.
Se o RPO for de um dia, a empresa estará aceitando uma lacuna maior. O RPO também ajuda a determinar a frequência dos backups, pois quanto menor for o seu RPO, mais frequentes precisarão ser os seus backups. Portanto, sistemas críticos precisam de backups mais frequentes do que sistemas de baixa prioridade.
Níveis de prioridade do sistema
Nem todo sistema deve ser restaurado 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 essenciais, segurança, comunicação ou receita.
- Nível 2: sistemas importantes que podem tolerar um curto período de inatividade.
- Nível 3: sistemas de menor prioridade que podem ser restaurados após a estabilização dos negócios.
Os sistemas típicos de nível 1 podem incluir e-mail, provedor de identidade, gerenciador de senhas, sistemas financeiros, banco de dados de clientes, armazenamento em nuvem e plataformas de comunicação.
Estratégia de backup
Sua estratégia de backup deve definir:
- Do que é feito backup e com que frequência
- Onde os backups estão armazenados
- Quem pode acessá-los
- Como a restauração é testada
O NCSC também publicou(nova janela) princípios de backup resistentes a ransomware para soluções de backup em nuvem e locais, observando que os dados com backup não são resistentes a ransomware por padrão e devem ser avaliados em relação à ameaça de ransomware.
Uma estratégia de backup sólida geralmente inclui backups off-line ou imutáveis para dados críticos, testes regulares, etapas de restauração documentadas e credenciais separadas para a administração do backup.
Funções e responsabilidades
Um plano de recuperação de desastres deve nomear responsáveis, não apenas tarefas. Se uma única pessoa detém todo o conhecimento de recuperação, a empresa corre um risco de pessoal, além do risco de TI. Defina quem:
- Lidera a recuperação
- Restaura os sistemas
- Entra em contato com os fornecedores
- Aprova o acesso de emergência
- Comunica-se internamente
- Documenta as decisões
O que o seu plano de recuperação de desastres de TI precisa definir
| Componente | O que ele responde |
| RTO | Com que rapidez cada sistema precisa ser restaurado? |
| RPO | Quanto de dados a empresa pode se dar ao luxo de perder? |
| Níveis de prioridade | Quais sistemas devem ser restabelecidos primeiro e quais podem esperar? |
| Estratégia de backup | Do que é feito backup, onde está armazenado e se a restauração já foi testada? |
| Funções e responsabilidades | Quem lidera a recuperação, restaura os sistemas, entra em contato com os fornecedores e aprova mudanças de emergência? |
Recuperação de credenciais: o cenário de recuperação de desastres negligenciado
A recuperação de desastres frequentemente se concentra em dados, servidores e backups. Mas, na prática, ela pode falhar porque a equipe não consegue acessar os sistemas necessários para restaurar as operações.
A recuperação de credenciais questiona:
- Quem tem acesso às contas de administrador?
- Onde as credenciais de backup estão armazenadas?
- Quais contas podem restaurar os sistemas críticos?
- O que acontece se uma senha for perdida, comprometida ou estiver com alguém indisponível?
- As credenciais de emergência estão protegidas e são revisadas?
- O acesso pode ser revogado e reatribuído rapidamente?
Se as credenciais de backup estiverem armazenadas no navegador de um funcionário, os códigos de recuperação forem mantidos em uma nota privada ou senhas de administrador compartilhadas circularem por chats, a empresa poderá não conseguir se recuperar de forma limpa durante um incidente.
Um gerenciador de senhas empresarial ajuda a reduzir esse risco centralizando credenciais críticas em cofres criptografados, atribuindo acesso por função 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 equipes a gerar senhas fortes, armazenar credenciais com segurança, usar o compartilhamento seguro e manter acessos confidenciais fora de chats e planilhas.
Como um gerenciador de senhas para equipes de TI, o Proton Pass oferece suporte ao gerenciamento de credenciais centralizado, políticas de senha, compartilhamento seguro, relatórios e registros, provisionamento SCIM e integrações de SSO. Isso torna a recuperação de credenciais mais gerenciável porque o acesso a sistemas críticos não depende de uma única pessoa, de um perfil de navegador ou de uma senha não documentada.
Modelo de plano de recuperação de desastres
Um plano de recuperação de desastres funciona melhor quando é específico o suficiente para orientar ações durante uma interrupção, mas simples o bastante para a equipe usar sob pressão. Para PMEs, o modelo deve se concentrar no essencial: o que precisa ser restaurado, com que rapidez, a partir de qual backup, por quem e com quais credenciais.
1. Escopo
Defina quais sistemas, serviços, localizações, dispositivos e dados o plano cobre.
Cópia do modelo: Este plano de recuperação de desastres de TI cobre os sistemas, dados, serviços, credenciais e fornecedores necessários para restaurar as operações críticas da [Nome da empresa] após uma interrupção tecnológica.
2. Inventário de sistemas críticos
Liste os sistemas de que sua empresa depende e atribua níveis de prioridade.
Cópia do modelo: Os sistemas críticos serão agrupados em Nível 1, Nível 2 e Nível 3 com base no impacto comercial, 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. Essas metas devem ser revisadas pelo menos anualmente e após grandes alterações no sistema.
4. Processo de backup e restauração
Documente onde os backups estão armazenados, com que frequência são executados, quem pode acessá-los e como funciona o teste de restauração.
Cópia do modelo: Os backups devem ser protegidos contra acesso não autorizado, armazenados separadamente dos sistemas principais, quando apropriado, e testados de forma regular. Os procedimentos de restauração devem ser documentados para os sistemas de Nível 1.
5. Recuperação de credenciais e acesso
Defina onde as credenciais críticas estão armazenadas e quem pode acessá-las durante a recuperação.
Cópia do modelo: As credenciais de administrador, credenciais de backup, códigos de recuperação e acessos de fornecedores necessários para a recuperação de desastres devem ser armazenados em um cofre criptografado aprovado. O acesso deve ser limitado a funções autorizadas e revisado após mudanças de função, desligamento e exercícios de recuperação.
6. Funções e escalonamento
Defina os responsáveis pela recuperação, substitutos e caminhos de escalonamento.
Cópia do modelo: Cada função de recuperação deve ter um proprietário principal e um proprietário de backup. O plano deve identificar quem lidera a recuperação, quem restaura os sistemas, quem entra em contato com 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 se 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 compartilhadas por meio do [canal aprovado]. As comunicações externas para clientes, fornecedores, seguradoras ou órgãos reguladores devem ser aprovadas por [função/equipe].
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 revisado após grandes incidentes, alterações no sistema, mudanças de fornecedores ou falhas nos exercícios de recuperação.
Como testar o seu plano de recuperação de desastres de TI
Um plano de recuperação de desastres só se torna útil depois de testado em condições que se assemelham a uma interrupção real. Um backup que existe, mas nunca foi restaurado, ainda é apenas uma suposição. Uma função de recuperação que apenas uma pessoa entende ainda é uma dependência. Uma credencial de administrador que ninguém consegue encontrar durante uma interrupção ainda é um obstáculo.
Os testes não precisam ser complexos no início. Para a maioria das PMEs, o objetivo é provar que a empresa pode restaurar os sistemas certos, com as pessoas certas, usando as credenciais corretas, dentro de um prazo realista.
1. Exercício de simulação teórica
Escolha um cenário provável, como um ransomware afetando arquivos compartilhados, uma queda no armazenamento em nuvem, exclusão acidental de dados de clientes ou a perda repentina de acesso a uma conta de administrador. Faça um passo a passo do que a equipe faria na primeira hora, quem lideraria, quais fornecedores seriam contatados, quais sistemas teriam prioridade e quais informações estariam faltando.
2. Teste de restauração
Selecione um arquivo, banco de dados, caixa de correio ou exportação de sistema crítico e confirme se ele pode ser restaurado para um estado utilizável. Verifique se os dados restaurados são recentes o suficiente, se as permissões ainda funcionam e se a equipe sabe onde o backup fica.
3. Teste regularmente
Como uma linha de base prática, as PMEs devem testar o plano pelo menos uma vez por ano, de acordo com as orientações do NIST na Special Publication 800-34 Revision 1(nova janela), e com mais frequência após grandes alterações de sistemas ou fornecedores.
4. Teste a recuperação de credenciais
Confirme se as pessoas autorizadas conseguem acessar contas de administrador de backup, contas de administrador em nuvem, portais de fornecedores, códigos de recuperação e credenciais de emergência sem depender do navegador, de notas privadas ou da memória de um único funcionário. O objetivo não é expor senhas confidenciais desnecessariamente, mas sim confirmar se o modelo de acesso ainda funciona quando a empresa está sob pressão.
Após cada teste, documente o que falhou, o que demorou muito e defina uma pessoa responsável e um prazo para cada correção. Um bom teste não é aquele em que tudo corre perfeitamente, mas sim o que revela as lacunas enquanto a empresa ainda tem tempo de corrigi-las.
Crie a recuperação em torno de sistemas, dados e acessos
Um plano de recuperação de desastres de TI útil oferece à empresa uma ordem de recuperação, um conjunto de responsáveis, uma visão realista do tempo de inatividade aceitável e uma maneira de manter a continuidade dos negócios e recuperar o acesso aos sistemas que mantêm o trabalho em andamento.
Para as PMEs, isso pode fazer a diferença entre uma interrupção curta e uma queda prolongada. Se o e-mail, o software financeiro, o armazenamento em nuvem, os sistemas de clientes ou as contas de administrador estiverem indisponíveis, a equipe precisará saber o que vem primeiro, quem pode agir e quais credenciais são necessárias para restaurar o acesso com segurança.
É por isso que o planejamento de recuperação deve abranger sistemas, dados e acessos juntos. Os backups podem restaurar arquivos, mas são as credenciais que permitem à equipe recuperar o controle dos sistemas necessários para a recuperação. Inícios de sessão de administrador, portais de fornecedores, contas de backup, códigos de recuperação e credenciais operacionais compartilhadas precisam ser protegidos, organizados e estar disponíveis para as pessoas certas quando algo der errado.
Um gerenciador de senhas empresarial ajuda a fortalecer essa parte do plano. Com credenciais críticas armazenadas em cofres de senhas criptografados e compartilhadas apenas com pessoas autorizadas, a empresa fica menos dependente do navegador, de notas privadas ou da memória de um único funcionário durante um evento de recuperação.
