Backup e Recuperação contra Ransomware: proteção de credenciais e hardening do ambiente de backup

Como atacantes miram o ambiente de backup (e por quê)

Em ataques de ransomware, o objetivo não é apenas criptografar servidores e estações: é impedir a recuperação. Por isso, o ambiente de backup vira alvo prioritário. Na prática, atacantes buscam “chaves” que permitam apagar, corromper, reduzir retenção, desativar imutabilidade ou sequestrar a infraestrutura de backup.

Principais alvos dentro do sistema de backup

• Credenciais de console (admin do software de backup, console web, appliance, vCenter/hipervisor integrado).
• Contas de serviço usadas por agentes, proxies, repositórios, jobs e integrações.
• Chaves de API e tokens (integrações com storage, nuvem, SIEM, ITSM, automações).
• Credenciais de repositório (SMB/NFS, object storage, buckets, chaves KMS, credenciais de storage).
• Credenciais de domínio reutilizadas (admin de AD usado também no backup) e movimento lateral via máquinas que executam componentes de backup.
• Infra de gerenciamento (jump servers, bastion, ferramentas RMM, scripts de automação).

Vetores comuns de comprometimento

• Phishing e roubo de credenciais com acesso ao console.
• Dump de credenciais em servidores onde rodam serviços de backup (LSASS, arquivos de configuração, variáveis de ambiente).
• Exposição de console na rede corporativa sem segmentação, ou publicado na internet.
• APIs com chaves long-lived sem rotação e sem escopo mínimo.
• Protocolos inseguros habilitados (SMBv1, TLS antigo, SSH fraco, HTTP sem TLS).
• Falhas de patching no software de backup, SO, hipervisor, storage e dependências.

Reduzindo a superfície de ataque: princípios essenciais

1) Menor privilégio (Least Privilege) aplicado ao backup

Menor privilégio significa conceder apenas as permissões necessárias para executar uma tarefa específica, pelo menor tempo possível. Em backup, isso evita que o comprometimento de uma conta operacional permita apagar repositórios, alterar retenção ou desativar proteções.

Exemplo prático: a conta que executa jobs de backup precisa ler dados das VMs/servidores e gravar no repositório, mas não precisa ter permissão para excluir backups, alterar políticas de retenção ou administrar usuários do console.

2) Contas separadas e segregação de funções

Separe papéis para reduzir impacto de credenciais vazadas e para criar barreiras operacionais.

• Backup Operator: executa e monitora jobs, reprocessa falhas, inicia restores aprovados.
• Backup Admin: altera políticas, cria repositórios, configura integrações, gerencia usuários.
• Security/Auditor: acesso somente leitura a logs, configurações e relatórios.
• Storage Admin: administra storage/buckets/KMS, sem acesso ao console de backup (quando possível).

3) MFA e autenticação forte

Habilite MFA para todo acesso interativo ao console e a jump servers. Para contas não interativas (serviços/APIs), use credenciais de curta duração e escopo mínimo.

Continue em nosso aplicativo e ...

• Ouça o áudio com a tela desligada
• Ganhe Certificado após a conclusão
• + de 5000 cursos para você explorar!

ou continue lendo abaixo...

Baixar o aplicativo

• MFA obrigatório para Backup Admin e para qualquer ação sensível (ex.: “step-up MFA” para exclusão/alteração de retenção).
• SSO com políticas de acesso condicional (origem de rede, dispositivo gerenciado, risco).

4) Cofre de senhas, rotação e chaves temporárias

Evite credenciais em planilhas, scripts e arquivos de configuração. Centralize em um cofre (vault) com auditoria e rotação.

• Rotação programada (ex.: 30/60/90 dias conforme criticidade) e imediata após incidentes.
• Credenciais temporárias (tokens com TTL) para automações e integrações.
• Just-in-Time (JIT): elevação de privilégio por tempo curto, com aprovação.

Passo a passo prático: endurecendo credenciais e acessos

Passo 1 — Mapear identidades e segredos do ecossistema de backup

Crie uma lista única (inventário) de todas as identidades e segredos usados pelo backup.

• Usuários do console (locais e federados).
• Contas de serviço (SO, banco, agentes, proxies).
• Credenciais de acesso a hipervisor, storage, buckets, KMS.
• Chaves de API/tokens de automação.
• Credenciais usadas em scripts (PowerShell, Bash, pipelines).

Dica operacional: para cada item, registre: dono, finalidade, escopo, onde é usado, como é rotacionado, e como revogar rapidamente.

Passo 2 — Definir papéis e separar contas (humano vs. serviço)

• Conta pessoal (nomeada) para acesso interativo com MFA.
• Conta de serviço sem login interativo (quando suportado), com permissões mínimas e rotação controlada.
• Conta “break-glass” (emergência) com controles específicos: armazenada em cofre, uso raríssimo, auditoria reforçada, MFA físico quando possível.

Checklist rápido:

• Proibir reutilização de senha entre console de backup, AD e storage.
• Desabilitar login interativo em contas de serviço.
• Remover contas genéricas compartilhadas; se inevitável, exigir check-out no cofre com trilha de auditoria.

Passo 3 — Aplicar menor privilégio por tarefa

Quebre permissões em “fatias” alinhadas a tarefas reais.

• Operação: ver status, reexecutar job, pausar/retomar, iniciar restore aprovado.
• Administração: criar/alterar políticas, repositórios, credenciais, integrações.
• Segurança: ver logs, exportar relatórios, configurar alertas (sem poder alterar retenção).

Exemplo de regra: somente Backup Admin pode alterar retenção/imutabilidade e somente via jump server em rede de administração, com MFA e registro de sessão.

Passo 4 — Implementar cofre de segredos e rotação

• Armazenar senhas/chaves no cofre e integrar o software de backup (quando suportado) para buscar segredos em tempo de execução.
• Configurar rotação automática para contas de serviço e chaves de API.
• Definir processo de revogação imediata (kill switch) para tokens comprometidos.

Modelo de rotação (exemplo):

Passo 5 — Restringir onde e como o console pode ser acessado

• Publicar console somente em rede de administração (VLAN/VRF de gestão) ou via VPN com postura de dispositivo.
• Exigir jump server/bastion com MFA e gravação de sessão para ações administrativas.
• Bloquear acesso ao console a partir de sub-redes de usuário final.

Hardening do ambiente de backup (práticas objetivas)

Atualização e gestão de vulnerabilidades

• Manter software de backup, plugins, agentes, proxies e componentes web atualizados.
• Aplicar patches do sistema operacional e dependências (runtime, bibliotecas, banco de dados).
• Tratar o servidor/console de backup como ativo crítico: janela de patch menor e varredura frequente.

Passo a passo:

• Defina um calendário de patch (ex.: semanal para críticos, mensal para demais).
• Monitore CVEs do fornecedor e crie gatilho de atualização emergencial.
• Valide em ambiente de homologação quando possível, mas com SLA curto para produção.

Restrição de acesso por rede (segmentação)

O objetivo é reduzir movimento lateral e impedir que uma máquina comprometida na rede corporativa alcance o console, repositórios e storage.

• Colocar console, servidores de gerenciamento e repositórios em segmento de rede dedicado.
• Permitir apenas fluxos necessários (origem/destino/porta) entre: console ↔ proxies ↔ repositórios ↔ fontes.
• Bloquear tráfego de entrada no repositório a partir de redes de usuário.

Exemplo de regra de firewall (conceitual):

ALLOW: Backup-Proxy -> Repo (porta do protocolo necessário) ONLY
ALLOW: Backup-Console -> Proxies/Repo (admin/controle) ONLY
DENY: User-Network -> Backup-Console/Repo (ALL)
ALLOW: JumpServer -> Backup-Console (HTTPS) ONLY

Registro, auditoria e trilhas de alteração

• Habilitar logs detalhados de autenticação, criação/alteração de jobs, mudanças de retenção, exclusões e falhas de backup.
• Enviar logs para um repositório central (SIEM/syslog) com retenção protegida.
• Alertas para eventos críticos: login admin fora de horário, falhas de MFA, alteração de repositório, desativação de proteções, exclusões em massa.

Prática recomendada: separar quem pode alterar configurações de quem pode apagar logs. Idealmente, ninguém do time de backup deve ter permissão para apagar logs centralizados.

Desativação de protocolos e configurações inseguras

• Desabilitar SMBv1, NTLM legado (quando aplicável), TLS antigos e cifras fracas.
• Forçar TLS moderno no console e APIs.
• Restringir SSH: chaves fortes, sem senha, sem root login, e allowlist de IPs.
• Remover serviços não utilizados no SO (hardening do host).

Endurecimento do host (servidores de backup e repositórios)

• EDR/antimalware com exceções bem definidas (para não corromper performance), mas sem “cegueira” em diretórios críticos.
• Controle de aplicação (allowlist) para impedir execução de binários não autorizados.
• Bloqueio de PowerShell/Bash não assinado para contas operacionais, quando viável.
• Criptografia de disco e proteção de chaves (TPM/HSM quando aplicável).

Modelo de política de acesso (template adaptável)

Use o modelo abaixo como base e ajuste aos seus sistemas e requisitos regulatórios.

Política de Acesso ao Ambiente de Backup — Versão modelo

• Objetivo: proteger a infraestrutura de backup contra uso indevido e comprometimento por ransomware.
• Escopo: console de backup, servidores/proxies, repositórios, storage/buckets, chaves/API, contas de serviço e jump servers.
• Princípios: menor privilégio, segregação de funções, autenticação forte, auditoria completa, acesso por rede restrita.
• Regras de autenticação:
  • MFA obrigatório para todo acesso interativo.
  • SSO preferencial; contas locais apenas quando necessário.
  • Contas de serviço sem login interativo e com rotação.
• Regras de autorização:
  • Operadores não podem alterar retenção, repositórios, credenciais ou integrações.
  • Alterações críticas exigem aprovação (change) e, quando possível, dupla autorização (4-olhos).
  • Exclusão de backups e redução de retenção: permitido apenas a Backup Admin, com step-up MFA e via jump server.
• Regras de rede:
  • Console acessível apenas pela rede de administração/jump server.
  • Repositórios não expostos a redes de usuário.
• Gestão de segredos:
  • Todos os segredos devem residir em cofre com auditoria.
  • Rotação conforme criticidade; revogação imediata em suspeita de incidente.
• Auditoria e logs:
  • Logs enviados para sistema central com retenção protegida.
  • Alertas para ações sensíveis e anomalias de autenticação.
• Exceções: qualquer exceção deve ter justificativa, prazo e aprovação de Segurança.

Matriz de permissões (exemplo prático)

A matriz abaixo é um ponto de partida. Ajuste os nomes de funções e recursos ao seu ambiente.

Checklist de implementação rápida (30–60 minutos para iniciar)

• Habilitar MFA no console e bloquear acesso fora da rede de administração.
• Criar papéis separados (Operator/Admin/Auditor) e remover privilégios excessivos.
• Inventariar contas de serviço e desabilitar login interativo.
• Colocar segredos em cofre e definir rotação mínima para contas críticas.
• Ativar logs/auditoria e alertas para alterações de retenção, exclusões e falhas de autenticação.
• Desabilitar protocolos inseguros e revisar portas expostas no segmento de backup.