Backup e Recuperação contra Ransomware: segmentação de rede e isolamento do tráfego de backup

Por que segmentar a rede especificamente para backups

Ransomware raramente “ataca só um servidor”. O padrão mais comum é: um endpoint é comprometido, o atacante ganha credenciais, faz movimentação lateral e tenta atingir os ativos que garantem a recuperação — especialmente o repositório de backup, o storage e os servidores de gerenciamento. Segmentação aplicada a backups tem um objetivo simples: impedir que máquinas de produção (ou endpoints) consigam falar diretamente com a infraestrutura de backup, reduzindo o raio de impacto mesmo quando há infecção na rede.

Na prática, isso significa criar zonas de rede (produção, gerenciamento e backup), controlar quem pode iniciar conexões, limitar portas e protocolos e reduzir a exposição do storage (evitar que ele apareça como “mais um servidor” acessível por qualquer sub-rede).

Modelo de zonas: produção, gerenciamento e backup

Zona de Produção (PROD)

• Onde estão endpoints, servidores de aplicação e bancos.
• Deve ter acesso mínimo à zona de backup.
• Idealmente, não inicia conexões para repositórios de backup.

Zona de Gerenciamento (MGMT)

• Onde ficam ferramentas administrativas, bastion/jump host, AD/IdP (quando aplicável), monitoramento e consoles.
• É a zona “de controle”: acessa servidores de backup e storage para administração.
• Deve ser pequena, com acesso restrito (MFA, allowlist de IPs, sem navegação geral).

Zona de Backup (BACKUP)

• Onde ficam servidor(es) de backup, proxies/media servers, repositórios, storage, appliances.
• Deve ser a zona mais restrita: poucos fluxos permitidos e preferencialmente sem acesso de saída amplo para PROD/Internet.
• Storage/repositório deve ser acessível apenas por componentes necessários (ex.: servidor de backup/proxy), e não por endpoints.

Princípios práticos de isolamento do tráfego de backup

1) “Deny by default” entre zonas

Comece assumindo que nenhuma zona fala com a outra. Depois, abra apenas os fluxos indispensáveis (allowlist). Isso reduz brechas como “qualquer host da rede pode montar o share do repositório”.

2) Direção do tráfego: quem inicia a conexão importa

Mesmo quando uma porta está “aberta”, você pode controlar quem inicia a sessão. Em backups, é comum que o servidor de backup/proxy inicie conexões para coletar dados (pull) ou que o cliente envie dados (push). Para reduzir risco:

• Prefira arquiteturas em que componentes controlados (proxy/servidor de backup) iniciem conexões para PROD, e não o contrário.
• Evite que endpoints/servidores de aplicação consigam iniciar conexões para o repositório.

3) Redução de exposição do storage/repositório

• Não exponha SMB/NFS/iSCSI do repositório para sub-redes de produção.
• Se houver necessidade de compartilhamento, limite por IP allowlist e por conta de serviço dedicada, sem permissões amplas.
• Evite que o repositório responda a varreduras comuns (ICMP, portas administrativas) fora da zona BACKUP.

4) Jump host (bastion) para administração

Administração da zona BACKUP deve ocorrer via jump host na zona MGMT, com regras explícitas:

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

• Somente o jump host pode acessar portas administrativas dos servidores de backup e storage.
• Admins não acessam diretamente a zona BACKUP a partir de endpoints comuns.
• Registre sessões (quando possível) e aplique allowlist de origem (VPN corporativa, IPs fixos).

Exemplo de diagrama lógico (zonas e fluxos)

                [ Internet / Usuários ] (sem acesso direto à BACKUP)   
                           |                                         
                        (VPN/MFA)                                     
                           |                                         
+--------------------------+---------------------------+              
|                      ZONA MGMT                        |              
|  Jump Host/Bastion  |  Monitoramento | Console Backup  |              
+----------+-----------+---------------+--------+--------+              
           | (admin only: RDP/SSH/HTTPS)        |                      
           |                                    | (control plane)      
           v                                    v                      
+-------------------------------+     +------------------------------+ 
|         ZONA BACKUP           |     |        ZONA PRODUÇÃO         | 
|  Servidor Backup / Proxies    |<--->|  Servidores/VMs/Endpoints    | 
|  Repositório/Storage          |     |  Apps/DBs                    | 
+---------------+---------------+     +---------------+--------------+ 
                ^                                     |                
                | (data plane: somente proxies/backup)|                
                |                                     v                
         (sem SMB/NFS exposto                      (sem acesso direto  
          para PROD)                                ao repositório)    

Leitura do diagrama: PROD não acessa diretamente o repositório. A administração entra por MGMT (jump host). O tráfego de dados de backup ocorre entre componentes específicos (ex.: proxy/servidor de backup) e os workloads em PROD, com portas estritamente necessárias.

Controle de portas e protocolos: o que liberar e o que bloquear

As portas variam por solução, mas o método é sempre o mesmo: mapear fluxos e aplicar allowlist mínima. Use esta abordagem:

Passo a passo para definir regras

• 1) Liste componentes: servidor de backup, proxies, repositório/storage, jump host, workloads (VMs/servidores), serviços de diretório (se aplicável).
• 2) Liste fluxos por direção: quem inicia e quem responde. Ex.: Proxy (BACKUP) → Servidor de aplicação (PROD) para coleta; Console (MGMT) → Servidor de backup (BACKUP) para administração.
• 3) Defina portas por fluxo: use documentação do fabricante e valide em ambiente de teste. Evite “liberar tudo entre sub-redes”.
• 4) Crie regras por zona: preferencialmente em firewall/ACL entre VLANs/sub-redes, não em regras “host a host” difíceis de manter.
• 5) Aplique allowlist de origem: por IP/sub-rede dos proxies e do jump host, nunca “any”.
• 6) Bloqueie explicitamente acesso ao repositório a partir de PROD (SMB/NFS/iSCSI/portas do appliance), exceto se um componente estritamente necessário estiver em PROD (o que deve ser evitado).

Matriz simples de política (exemplo genérico)

Adapte a matriz para o seu ambiente e substitua “portas necessárias” pelas portas reais do seu software/appliance.

Firewalling e allowlists: padrões recomendados

Regras entre PROD e BACKUP

• Negar por padrão qualquer tráfego de PROD para BACKUP.
• Permitir somente o que for indispensável para o fluxo de backup (idealmente iniciado por BACKUP → PROD).
• Bloquear protocolos de compartilhamento do repositório (SMB/NFS) vindos de PROD, mesmo que “pareça útil”. Esse é um dos caminhos mais explorados para criptografar backups.

Regras entre MGMT e BACKUP

• Permitir administração somente via jump host.
• Permitir acesso a consoles apenas a partir de sub-redes/hosts de gestão.
• Restringir portas administrativas do storage/appliance para MGMT (e não para PROD).

Regras de saída (egress) da zona BACKUP

• Evite que servidores de backup/repositórios tenham saída ampla para PROD e Internet.
• Permita apenas destinos necessários (ex.: DNS/NTP internos, repositórios internos de atualização, serviços essenciais).
• Bloqueie navegação geral e downloads diretos a partir de hosts críticos de BACKUP.

Validações para garantir que endpoints infectados não alcancem o repositório

Depois de aplicar segmentação, valide com testes objetivos. A meta é: um endpoint em PROD não consegue descobrir nem acessar o repositório.

Checklist de validação (testes práticos)

• Teste de conectividade: a partir de um endpoint em PROD, tente conectar nas portas do repositório (SMB/NFS/iSCSI/porta do appliance). O resultado esperado é bloqueio (timeout/deny).
• Teste de montagem: tente montar um compartilhamento do repositório (se existir). Deve falhar por rede (não apenas por credencial).
• Teste de varredura controlada: execute uma varredura limitada (somente portas relevantes) do endpoint para IPs da zona BACKUP. O esperado é nenhuma porta aberta visível a partir de PROD.
• Teste de caminho administrativo: confirme que a administração do BACKUP funciona apenas via jump host (MGMT). Tentar RDP/SSH/HTTPS direto do endpoint deve falhar.
• Teste de fluxo de backup: execute um job de backup e confirme que o tráfego ocorre apenas entre os componentes previstos (ex.: proxy ↔ workload; servidor backup ↔ repositório).

Comandos úteis (exemplos)

Use ferramentas padrão para validar portas (ajuste IP/porta conforme seu ambiente):

# Windows (PowerShell) - testar porta
Test-NetConnection -ComputerName 10.20.30.40 -Port 445

# Linux/macOS - testar porta
nc -vz 10.20.30.40 445

# Linux - verificar rotas e caminho
ip route
traceroute 10.20.30.40

Se o teste falhar apenas por “acesso negado” (credencial), mas a porta estiver aberta, ainda há risco: malware pode explorar credenciais roubadas ou falhas de protocolo. O ideal é falhar por bloqueio de rede.

Roteiro para revisar e endurecer regras de rede (auditoria rápida)

1) Mapear sub-redes e zonas

• Liste CIDRs/VLANs de PROD, MGMT e BACKUP.
• Confirme onde estão repositórios e interfaces de gerenciamento do storage.
• Identifique “atalhos” (rotas antigas, regras temporárias, VPNs que caem direto em BACKUP).

2) Inventariar regras existentes entre zonas

• Exporte regras do firewall/ACL (inter-VLAN, NGFW, security groups).
• Procure por padrões perigosos: any-any, ranges amplos, portas “todas”, regras sem expiração.
• Separe regras por finalidade: administração, dados de backup, serviços de infraestrutura (DNS/NTP).

3) Aplicar política mínima (allowlist)

• Para cada fluxo, defina: origem, destino, porta/protocolo, direção, justificativa, dono e data de revisão.
• Converta regras amplas em regras específicas (ex.: “PROD → BACKUP: any” vira “BACKUP proxy → PROD workloads: portas X/Y”).
• Crie objetos/grupos (ex.: BACKUP_PROXIES, BACKUP_REPO, MGMT_JUMPHOST) para facilitar manutenção.

4) Proteger o repositório como ativo crítico

• Garanta que o repositório/storage tenha interface de dados e interface de gerenciamento em redes separadas (quando possível).
• Permita acesso ao repositório apenas a partir de servidores/proxies de backup (zona BACKUP).
• Bloqueie acesso ao repositório a partir de PROD mesmo para administradores; administração deve ocorrer via MGMT/jump host.

5) Validar com evidências

• Registre resultados dos testes de conectividade (antes/depois).
• Capture logs do firewall mostrando bloqueios de PROD → BACKUP.
• Monitore tentativas de acesso anômalas ao repositório (picos de conexão, portas incomuns).

Padrões de arquitetura que reduzem movimentação lateral

Separar plano de controle e plano de dados

• Plano de controle: console/gerenciamento (MGMT ↔ BACKUP), com acesso restrito e auditável.
• Plano de dados: tráfego de backup (BACKUP proxies ↔ PROD workloads; BACKUP server ↔ repositório), com portas mínimas e sem exposição do repositório.

Microsegmentação (quando aplicável)

Além de segmentar por zona, você pode restringir por aplicação/host:

• Somente proxies específicos podem falar com workloads específicos.
• Somente o servidor de backup pode falar com o repositório em portas de escrita/leitura.
• Mesmo dentro da zona BACKUP, limite comunicação lateral entre servidores (evita que um componente comprometido alcance todos os outros).