Backup empresarial e cibersegurança: como o NIST CSF coloca o Recover no centro

Por que backup deixou de ser tarefa de TI e virou pilar de cibersegurança

Durante anos, backup foi tratado como uma rotina operacional: agendar a janela noturna, mover fitas para um cofre, confirmar que o job rodou. A conversa ficava limitada à equipe de infraestrutura, fora do radar de CISOs e da diretoria. Essa visão hoje é insuficiente. A ascensão de ataques de ransomware sofisticados, a regulamentação crescente sobre continuidade de serviços críticos e a expectativa de tempo de recuperação medido em horas (não em dias) elevaram o backup à categoria de controle estratégico de cibersegurança.

A Sophos, em seu State of Ransomware 2024, mostra que 59% das organizações pesquisadas sofreram um ataque de ransomware no último ano e que o tempo médio para recuperação completa foi de mais de um mês quando o backup não estava preparado. A Veeam, no Data Protection Trends Report, complementa: 76% das empresas atacadas pagaram o resgate, e mesmo assim apenas 8% recuperaram todos os dados. Ou seja, pagar nem sequer garante recuperação. Backup adequado, sim.

Esse novo cenário é a razão pela qual o NIST Cybersecurity Framework (CSF) 2.0, publicado em fevereiro de 2024, trata a função Recover com a mesma seriedade das demais funções operacionais, e adiciona a função Govern no centro do framework para garantir que toda a estratégia, inclusive backup, esteja apoiada em decisões formais de governança. Backup, antes commodity de TI, virou o ativo defensivo final. Esta análise mostra como estruturar uma estratégia de backup empresarial alinhada ao NIST CSF 2.0, com foco prático em governança, recovery planning, métricas de RTO/RPO, backup imutável e auditoria de restauração.

Leia também: Ransomware: o que é, como funciona e 10 medidas para proteger sua empresa

As 6 funções do NIST CSF 2.0 e onde o backup se encaixa

O NIST CSF 2.0 organiza a cibersegurança em seis funções centrais que descrevem o ciclo completo de gestão de risco. A novidade em relação à versão 1.1 (de 2014) é a função Govern, posicionada visualmente no núcleo do framework para indicar que ela atravessa e orienta todas as outras. Backup empresarial não é tópico isolado: ele aparece em todas as funções, com peso decisivo nas duas que ancoram esse novo desenho, Govern e Recover.

Govern (governar): é a função central do CSF 2.0. Define o contexto organizacional, a estratégia de gestão de risco, papéis e responsabilidades, políticas formais e supervisão executiva. Para backup, Govern é onde a alta direção define a tolerância de risco que vira RTO e RPO, formaliza a política de backup e retenção, atribui responsabilidades claras (quem aciona, aprova, comunica) e supervisiona o programa por métricas. As subcategorias mais relevantes são:

• GV.RM (Risk Management Strategy): apetite de risco que orienta janelas de proteção e investimento em imutabilidade
• GV.PO (Policy): política formal de backup, retenção, criptografia e classificação
• GV.RR (Roles, Responsibilities, and Authorities): donos do programa de backup, responsável por aprovação de restauração e por comunicação
• GV.OV (Oversight): comitê de risco e board acompanham KPIs de backup como parte da governança de cibersegurança
• GV.SC (Cybersecurity Supply Chain Risk Management): trata risco do fornecedor de backup como terceiro crítico (auditoria, SLA, cláusulas contratuais)

Sem Govern, backup vira iniciativa técnica órfã. Com Govern, ele é controle formal com patrocínio executivo e métricas reportadas, o que é justamente o que reguladores e auditores hoje esperam.

Identify (identificar): mapeia ativos críticos, dependências de negócio e classificação de dados. Sem esse passo, backup vira tarefa cega: copia tudo igual, sem priorizar o que importa. Aplicações que sustentam receita ou compliance (ERP, CRM, banco de dados de clientes) exigem janelas de proteção diferentes de servidores de arquivos genéricos.

Protect (proteger): define os controles que blindam tanto os dados primários quanto as cópias de backup. Inclui criptografia em repouso e em trânsito, segregação de credenciais e princípio do menor privilégio sobre os repositórios de backup. Atacantes modernos miram propositalmente os backups antes de cifrar a produção, justamente porque sabem que esse é o único caminho de recuperação sem pagar.

Detect (detectar): monitora indicadores de comprometimento que possam afetar a integridade das cópias. Mudanças anômalas em volumes de backup, deleções em massa, alterações em políticas de retenção: tudo isso são sinais que precisam disparar alertas.

Respond (responder): ativa o plano de resposta a incidentes quando um ataque é confirmado. A decisão de iniciar a restauração depende de validar que o backup escolhido está limpo (não foi cifrado ou adulterado pelo atacante antes da detecção).

Recover (recuperar): é onde o backup deixa de ser preparação e vira execução. Toda a engenharia anterior (políticas, testes, imutabilidade, automação) é provada nesta hora. Empresas que tratam backup como controle de Recover, e não apenas como tarefa de Protect, têm taxas de sucesso de restauração significativamente maiores.

A função Recover é detalhada em duas subcategorias principais que orientam a estratégia: RC.RP (Recovery Planning) e RC.CO (Communications). No CSF 2.0, ambas operam sob orientação de Govern: a política aprovada em GV.PO define o que deve ser recuperado, GV.RR define quem executa e quem comunica, e GV.RM define os parâmetros de RTO e RPO que serão exigidos do plano de recuperação. Vamos detalhar cada uma.

A função Recover na prática: RC.RP e RC.CO

RC.RP: Recovery Planning

A subcategoria RC.RP exige que a organização tenha um plano formal de recuperação executado e mantido. Não basta documentar: o plano precisa ser exercitado periodicamente para validar tempos, dependências e responsabilidades. Os controles que materializam RC.RP incluem:

• RC.RP-01: o plano de recuperação é executado durante ou após um incidente. Isso implica que existe um runbook claro, com critérios de acionamento, papéis e ordem de operações.
• RC.RP-02: atividades de recuperação são selecionadas, escopadas e priorizadas com base em risco e na criticidade dos ativos. Recuperar tudo ao mesmo tempo é receita para sobrecarregar o time. Recuperar primeiro o que sustenta receita ou conformidade legal é o caminho operacional correto.
• RC.RP-03: a integridade dos backups e fontes de restauração é verificada antes da execução. Esse controle é a defesa contra restauração de cópias já comprometidas, problema crescente em ataques de ransomware mais lentos, que dormem semanas antes de detonar.
• RC.RP-06: o fim da recuperação é declarado de forma explícita, com base em critérios mensuráveis. Encerrar prematuramente o incidente, com sistemas ainda instáveis ou parcialmente restaurados, é um erro comum que volta a custar caro.

RC.CO: Communications

A função Recover não é puramente técnica. RC.CO exige que a organização comunique o estado da recuperação a stakeholders internos e externos: liderança executiva, clientes afetados, reguladores, parceiros de negócio e, dependendo do setor, autoridades como a ANPD (no caso da LGPD) ou o Banco Central (no caso de instituições financeiras sob Resolução 4.658).

A comunicação eficaz durante a recuperação reduz especulação, preserva confiança e cumpre obrigações legais. Empresas que falham nessa etapa frequentemente sofrem dano reputacional desproporcional ao incidente técnico em si.

Leia também: Plano de resposta a incidentes: como criar, testar e manter atualizado

Backup como controle primário da função Recover

Dentro de RC.RP, o backup é o controle operacional que viabiliza a restauração. Mas backup empresarial moderno vai muito além de cópia de arquivos. As práticas consolidadas seguem regras geracionais que evoluíram conforme as ameaças cresceram em sofisticação.

A regra 3-2-1 clássica

A regra original, popularizada pelo fotógrafo Peter Krogh nos anos 2000, é simples e ainda válida como ponto de partida:

• 3 cópias dos dados (produção + 2 backups)
• 2 mídias diferentes (disco + fita, ou disco + nuvem)
• 1 cópia offsite (fora do datacenter principal)

Essa regra protege contra falhas de hardware, desastres físicos e erros humanos. Mas ela não foi pensada para a era do ransomware, em que o atacante consegue acessar e cifrar todas as cópias online ao mesmo tempo.

A evolução 3-2-1-1-0

A versão moderna da regra acrescenta dois dígitos:

• 3 cópias dos dados
• 2 mídias diferentes
• 1 cópia offsite
• 1 cópia imutável (ou air-gap)
• 0 erros após teste de restauração

A cópia imutável (ou air-gap) é a defesa fundamental contra ransomware: mesmo que o atacante comprometa credenciais administrativas, essa cópia permanece intocável durante seu período de retenção. O "zero erros" reforça que backup não testado não conta como backup. Apenas restauração validada prova que a estratégia funciona.

Backup imutável: WORM e Object Lock

Tecnicamente, a imutabilidade é implementada por mecanismos WORM (Write Once, Read Many). Nos principais provedores de nuvem isso aparece como:

• Amazon S3 Object Lock: retenção legal (legal hold) ou retenção compliance, com mode "compliance" impedindo até o root account de deletar.
• Azure Blob immutable storage: policies de tempo-baseado ou legal hold.
• Google Cloud Storage Bucket Lock: retenção por bucket, exigível até por administradores.

Para appliances on-premise, fabricantes como Dell, NetApp, Pure Storage e Veeam oferecem variantes de imutabilidade nativa, geralmente combinadas com snapshots imutáveis em camada de storage.

Air-gap físico versus lógico

Air-gap físico é a separação real, sem qualquer rota de rede entre a cópia e o ambiente principal. Cópia em fita guardada offline em cofre é o exemplo canônico. Funciona, mas com RTO alto (recuperar pode levar dias).

Air-gap lógico oferece o mesmo princípio com automação. Repositórios isolados em VLAN separada, com regras de firewall que permitem apenas o software de backup escrever (e nunca o ambiente de produção ler ou modificar), entregam a maior parte do benefício com agilidade operacional muito maior.

RTO, RPO e SLA de negócio

Toda estratégia de backup empresarial precisa começar pela definição de duas métricas que traduzem requisitos de negócio em parâmetros técnicos: RTO e RPO.

RTO (Recovery Time Objective)

RTO é o tempo máximo aceitável entre a indisponibilidade do sistema e seu retorno operacional. Se o ERP da empresa tem RTO de 4 horas, significa que após uma falha catastrófica o negócio aceita ficar até 4 horas sem o sistema (qualquer tempo adicional gera prejuízo crítico).

RTO baixo (minutos) exige alta disponibilidade, replicação síncrona e backup com restore rápido. RTO alto (dias) permite estratégias mais econômicas, como restore de fita offline.

RPO (Recovery Point Objective)

RPO é o volume máximo de dados que o negócio aceita perder em caso de incidente. Se o banco de dados de pedidos tem RPO de 15 minutos, isso significa que o backup mais recente não pode estar mais que 15 minutos defasado em relação à produção.

RPO baixo exige replicação contínua ou snapshots de alta frequência. RPO alto (24 horas, por exemplo) permite backup diário simples.

Matriz por aplicação crítica

A boa prática é construir uma matriz de aplicações classificadas por criticidade, com RTO e RPO definidos para cada uma:

Esse mapeamento exige conversas entre TI, segurança e donos das aplicações. Não é decisão puramente técnica: é uma decisão de risco que precisa ser apropriada pelo negócio.

Leia também: Gestão de riscos cibernéticos: do técnico ao financeiro em uma plataforma

Auditoria, teste de restauração e métricas

A máxima entre profissionais de continuidade é clara: backup que não foi testado não existe. Cópias podem estar corrompidas, mídias podem ter falhado silenciosamente, jobs podem ter rodado parcialmente sem alerta. A única forma de confirmar que a estratégia funciona é restaurar regularmente.

Frequência mínima de teste

A frequência depende da criticidade da aplicação:

• Aplicações críticas: teste mensal, com restauração completa em ambiente isolado.
• Aplicações alta criticidade: teste trimestral.
• Aplicações média criticidade: teste semestral.
• Aplicações baixa criticidade: teste anual.

KPIs operacionais de backup

Algumas métricas devem ser monitoradas e reportadas ao comitê de risco ou ao C-level:

• Taxa de sucesso dos jobs de backup: alvo > 99%.
• Tempo médio de restauração (MTTR de restore): comparar com o RTO definido.
• % de testes de restauração bem-sucedidos: alvo > 95%.
• Volume de dados protegidos vs total inventariado: detecta ativos fora da política.
• Idade média da cópia mais recente por aplicação: verifica aderência ao RPO.

Auditoria periódica desses KPIs é o que separa empresas com programa maduro de cibersegurança de empresas que apenas dizem ter backup. O NIST CSF 2.0, na subcategoria PR.DS-11 (Data Security), exige explicitamente que backups sejam criados, protegidos, mantidos e testados. A combinação de PR.DS-11 (controle técnico) com GV.PO (política formal) e GV.OV (supervisão executiva) é o desenho completo: governança define o que precisa ser feito, controle técnico executa, e KPIs comprovam.

Backup no plano de resposta a incidentes

Backup só cumpre sua função se estiver integrado ao plano de resposta a incidentes. A decisão de iniciar uma restauração não é técnica isolada: envolve a equipe de resposta, o jurídico, o financeiro e, dependendo do caso, a alta direção.

Durante um ataque de ransomware, o time de resposta passa por fases que tipicamente seguem a ordem Containment → Eradication → Recovery (contenção, erradicação, recuperação). O backup entra na fase de Recovery, mas só após:

1. Contenção do ataque: o atacante foi expulso do ambiente, credenciais foram revogadas e propagação foi interrompida.
2. Erradicação: todos os componentes maliciosos foram identificados e removidos.
3. Validação da cópia escolhida: o backup a ser restaurado é anterior à invasão e está íntegro.

A pressão para "voltar rápido" frequentemente leva a restaurações prematuras que reintroduzem o malware no ambiente. Esse é um padrão tão recorrente que o FBI publicou alertas específicos sobre o assunto.

Decisão de pagamento de resgate versus restauração

Esta é uma das decisões mais complexas em um incidente. Envolve trade-offs entre custo direto (resgate), custo indireto (tempo de indisponibilidade) e riscos legais (alguns países proíbem pagamento). Organizações maduras quantificam esse trade-off antes do incidente, em exercícios de gestão de riscos cibernéticos, e chegam ao momento crítico com critérios pré-aprovados pela alta direção.

Pagar o resgate sem capacidade de recuperação por backup é a pior posição possível: a Sophos mostra que apenas uma minoria das vítimas que pagaram conseguiu recuperar todos os dados, e muitas foram atacadas novamente em menos de um ano.

Perguntas Frequentes

O que é a regra 3-2-1-1-0 de backup?

A regra 3-2-1-1-0 é a evolução moderna do conceito clássico 3-2-1, adaptada para a era do ransomware. Ela exige 3 cópias dos dados, em 2 mídias diferentes, com 1 cópia offsite, 1 cópia imutável (ou air-gap) e 0 erros após teste de restauração. A cópia imutável é a principal defesa contra ataques que tentam comprometer também os backups, e o "zero erros" reforça que apenas backups testados periodicamente contam como controle efetivo.

Backup na nuvem é seguro contra ransomware?

Backup na nuvem é seguro se configurado corretamente. As principais defesas são: ativar imutabilidade (Object Lock no S3, immutable blobs no Azure, Bucket Lock no GCP), usar contas dedicadas com credenciais separadas das contas de produção, aplicar princípio do menor privilégio e ativar autenticação multifator. Configurações ruins, como buckets sem versionamento ou com credenciais expostas, tornam o backup na nuvem tão vulnerável quanto qualquer outro ativo.

Qual a diferença entre RTO e RPO?

RTO (Recovery Time Objective) é o tempo máximo aceitável entre a falha e o retorno do sistema. RPO (Recovery Point Objective) é o volume máximo de dados que o negócio aceita perder, medido em tempo. Uma aplicação com RTO de 4 horas e RPO de 15 minutos precisa voltar em até 4 horas, e quando voltar não pode estar mais que 15 minutos defasada em relação ao momento da falha. As duas métricas combinadas definem o desenho da estratégia de backup e replicação.

Com que frequência devo testar a restauração?

A frequência ideal varia pela criticidade da aplicação. Aplicações críticas (que sustentam receita ou compliance) devem ser testadas mensalmente, com restauração completa em ambiente isolado. Aplicações de alta criticidade, trimestralmente. Média criticidade, semestralmente. Baixa criticidade, anualmente. O importante é tratar o teste como exercício formal, com critérios de sucesso claros e medição de tempo (que deve bater com o RTO comprometido).

Backup imutável substitui antivírus ou EDR?

Não. Backup imutável é controle da função Recover do NIST CSF, voltado a garantir restauração após incidente. Antivírus e EDR são controles das funções Protect e Detect, voltados a impedir e identificar a invasão. Os três controles atuam em camadas diferentes do ciclo de defesa e são complementares. Empresas que dependem apenas de backup correm risco de incidentes prolongados (cada ataque vira evento de restauração). Empresas que dependem apenas de EDR ficam vulneráveis quando o controle preventivo falha.

Backup é responsabilidade de TI ou de segurança?

Backup empresarial moderno é responsabilidade compartilhada. A operação técnica continua no time de TI, mas as decisões estratégicas (RTO, RPO, política de retenção, frequência de teste) precisam ser aprovadas pelo time de segurança e ratificadas pela liderança executiva. Essa governança é o que diferencia backup como tarefa operacional de backup como controle de cibersegurança. No NIST CSF 2.0, a função Govern formaliza exatamente esse desenho: GV.RR define donos, GV.PO formaliza política e GV.OV exige supervisão executiva.

O que mudou no NIST CSF 2.0 em relação à versão anterior?

A mudança mais visível é a adição da função Govern como sexta função, posicionada no centro do framework para indicar que ela orienta as outras cinco. O CSF 1.1 (2014) tinha cinco funções (Identify, Protect, Detect, Respond, Recover) e tratava governança implicitamente. O CSF 2.0 (fevereiro 2024) torna a governança explícita, exigindo política formal, atribuição de papéis, supervisão executiva e gestão de risco da cadeia de suprimentos. Para backup, isso significa que a estratégia precisa ter patrocínio da alta direção e KPIs reportados ao board, não apenas execução técnica bem-feita.

Conclusão: backup é a última linha de defesa e o primeiro indicador de maturidade

A função Recover do NIST CSF deixa explícito o que muitas organizações ainda relutam em aceitar: backup empresarial é cibersegurança. Não é uma rotina secundária da equipe de infraestrutura, nem um item de checklist resolvido com a compra de uma solução. É um programa contínuo que envolve definição de criticidade, métricas de RTO e RPO, imutabilidade, teste regular de restauração, governança e integração ao plano de resposta a incidentes.

Empresas que tratam backup com esse rigor recuperam-se de incidentes em dias, não em semanas, e não dependem de pagar resgate para retomar operações. Empresas que ainda enxergam backup como tarefa operacional descobrem, no pior momento possível, que a estratégia que pareciam ter no papel não existia na prática. O NIST CSF oferece um caminho claro para sair do segundo grupo e entrar no primeiro.

---

Referências

• NIST, "Cybersecurity Framework 2.0", National Institute of Standards and Technology, 2024. nist.gov/cyberframework
• Sophos, "State of Ransomware 2024", Sophos Group, 2024. sophos.com
• Veeam, "Data Protection Trends Report 2024", Veeam Software, 2024. veeam.com
• IBM Security, "Cost of a Data Breach Report 2024", IBM Corporation, 2024. ibm.com/reports/data-breach