# Instalar Veeam Hardened Repository

sudo apt install veeam # ou dnf install veeam em RHEL

sudo useradd -m -s /bin/bash veeamrepo

sudo mkdir -p /backup/veeam

sudo mkfs.xfs -L veeam /dev/sdb1 # XFS é obrigatório

sudo mount /dev/sdb1 /backup/veeam

sudo chown -R veeamrepo:veeamrepo /backup/veeam

# Criar bucket com Object Lock

aws s3api create-bucket --bucket minha-empresa-backup-imutavel \

 --region eu-west-1 --create-bucket-configuration LocationConstraint=eu-west-1
# Activar Object Lock

aws s3api put-object-lock-configuration --bucket minha-empresa-backup-imutavel \

 --object-lock-configuration '{

 "ObjectLockEnabled": "Enabled",

 "Rule": {

 "DefaultRetention": {

 "Mode": "COMPLIANCE",

 "Years": 1

 }

 }

 }'

Compliance mode = ninguém pode apagar (nem AWS, nem admin, nem com bucket policy).

Governance mode = admin com permissão especial pode apagar.

4.3 Azure Backup Immutable Vault

O Azure Backup suporta vaults imutáveis (public preview 2023, GA 2024):

# PowerShell — criar vault imutável

$vault = New-AzDataProtectionBackupVault -ResourceGroupName "rg-backup" \

 -VaultName "vault-imutavel-01" -Location "westeurope" -IdentityType SystemAssigned
# Configurar immutability

$settings = Update-AzDataProtectionBackupVault -ResourceGroupName "rg-backup" \

 -VaultName "vault-imutavel-01" \

 -ImmutabilityState "Locked" -ImmutabilityPeriod 30

Locked immutability = imutabilidade permanente (não pode ser desfeita sem criar novo vault).

Unlocked = pode ser desfeita após período mínimo de 14 dias.

4.4 Acronis Cyber Protect Immutable Storage

O Acronis oferece Immutable Storage com base em Acronis Notary + blockchain timestamping:

1. Acronis Management Console → Backup → Add location → Immutable storage.
2. Configurar retention period (e.g. 30 dias).
3. Definir approvers (mínimo 2 pessoas para destruir).
4. Activar.

5. Estratégia 3-2-1-1-0 por cenário

5.1 Active Directory (DSRM + System State)

• RTO aceitável: 4-8 horas.
• RPO aceitável: 24 horas.
• Backup: System State diariamente + AD Recycle Bin activado + snapshot mensal offline (USB externo, offline após backup).
• Recovery: DSRM (Directory Services Restore Mode) + Authoritative Restore para objectos específicos.

# Backup System State

wbadmin start systemstatebackup -backuptarget:E:
# Teste de recovery (recomendado trimestral)

# Em VM isolada, ntdsutil → ifm (Install From Media) → validar

5.2 SQL Server

• RTO aceitável: 1-4 horas.
• RPO aceitável: 15-60 minutos.
• Backup: Veeam SQL-aware backup (consistente) + native SQL backup com TDE encryption para cloud.
• Recovery: Veeam Instant Recovery (mount backup como VM) + SQL tail-log backup.

5.3 File servers

• RTO aceitável: 4-8 horas.
• RPO aceitável: 24 horas.
• Backup: Veeam File Share backup (sintético) + immutable offsite copy.
• Recovery: Veeam FLR (File Level Recovery) — browse e restaura ficheiros individuais.

5.4 Microsoft 365 (Exchange, SharePoint, OneDrive, Teams)

• RTO aceitável: 1-4 horas por mailbox.
• RPO aceitável: 24 horas.
• Backup: Veeam for Microsoft 365 8.2 (recomendado) ou Acronis M365 backup.
• Recovery: Veeam Explorer for Exchange/SharePoint/OneDrive/Teams.

# Veeam for M365 — adicionar organização

Add-VBOROrganization -ConnectionSettings  -Region "EMEA"

Start-VBOJob -JobName "M365-Daily-Backup"

5.5 Cloud (Azure VMs, AWS EC2, GCP)

• RTO aceitável: 1-4 horas.
• RPO aceitável: 4-24 horas.
• Backup:
• Azure: Azure Backup com Immutable Vault (secção 4.3).
• AWS: AWS Backup com vault lock (Object Lock + WORM).
• GCP: Persistent Disk snapshots + Object Lock no Cloud Storage.

6. Detecção e resposta

6.1 Os 3 sinais de ransomware em curso

1. Volume write rate spikes (5-50x baseline) — Veeam ONE, Windows Performance Monitor.
2. File rename patterns (.lockbit, .akira, .clop, .encrypted) — Sysmon + ELK.
3. Shadow copy deletion (vssadmin delete shadows /all) — Windows Event ID 8194.

6.2 Ferramentas de detecção

• Veeam ONE 12.3 — anomalias em backup jobs.
• Microsoft Defender for Cloud (CSPM + workload protection).
• CrowdStrike Falcon, SentinelOne, Microsoft Defender for Endpoint (EDR com rollback).
• Sentinel, Splunk, Elastic (SIEM para correlação).

6.3 Plano de resposta (NIST SP 800-184)

1. Detectar (EDR/SIEM).
2. Isolar (desligar rede, manter ligado para forense).
3. Identificar (variant + scope).
4. Erradicar (kill malware, reset credenciais).
5. Recuperar (do backup imutável — NUNCA pagar resgate).
6. Lições aprendidas (post-mortem em 30 dias).

7. Verificação

7.1 Teste de recovery mensal (obrigatório)

# 1. Escolher 3-5 ficheiros aleatórios do último backup

# 2. Restaurar para VM isolada (rede desligada)

# 3. Validar integridade (checksum + abertura real)

# 4. Documentar tempo de restore (RTO efectivo)

# 5. Apagar VM de teste

7.2 Validação trimestral: tabletop exercise

Simular cenário ransomware sem restaurar:

1. Escritório: recebem “ransom note” falsa (validar playbook).
2. IT: segue o plano de resposta (NÃO usar produção).
3. Validar: tempo de decisão, papéis, comunicação.
4. Reportar: gaps encontrados, fixes necessários.

7.3 Auditoria externa anual

• Compliance: SOC 2, ISO 27001, PCI-DSS 4.0 (2025), NIS2 (UE).
• Pen test: simulação de ataque real (red team).

8. Outras causas comuns (10 problemas que invalidam backups)

Estes são os 10 erros mais frequentes em ambiente empresarial, ordenados por impacto real:

1. Backup na mesma infraestrutura — NAS ligado ao mesmo domínio que produção. Atacante compromete AD → apaga backup. Solução: NAS em VLAN isolada, conta sem privilégios de AD.
2. Credenciais de admin no backup vault — mesma password do admin de domínio. Atacante usa wmiexec para correr comandos no backup server. Solução: gMSA (Group Managed Service Account) + LAPS.
3. Backup sem teste de recovery — “fazemos backup há 5 anos, nunca testamos restore”. 30% dos restores falham (Veeam 2024 statistics). Solução: 1 teste mensal.
4. Retention muito curto — 7 dias. Atacante espera 14 dias e apaga backups antigos. Solução: mínimo 30 dias de retention imutável.
5. Sem offline copy — backup em disco ligado à rede. Atacante encripta disco. Solução: tape backup mensal + LTO offline, ou cloud air-gapped (Wasabi, Backblaze).
6. M365 sem backup — 60% das empresas não fazem backup do Microsoft 365 (Microsoft 365 Backup). Microsoft não faz backup por si. Solução: Veeam for M365 ou Acronis.
7. Backup encryption key perdido — TDE key do SQL Server ou BitLocker key do backup disk. Solução: guardar keys em Azure Key Vault ou HashiCorp Vault, com 2 approvers.
8. Object Lock configurado mal — “governance mode” permite admin apagar. Solução: SEMPRE compliance mode para ransomware.
9. Backup a partir de snapshots comprometidos — attacker cria root account, faz backup “limpo” do estado malicioso. Solução: validar assinatura digital do backup (Acronis Notary).
10. Sem documentação — único admin sabe onde está tudo. Cai de baixa = caos. Solução: runbook atualizado + 2ª pessoa treinada + DR playbook testado.

9. Como evitar (boas práticas)

1. Object Lock compliance mode (não governance) com retention ≥ 30 dias.
2. Offline/air-gapped copy — tape LTO mensal ou cloud com air gap (Wasabi, Backblaze B2, AWS Glacier Deep Archive).
3. Teste de recovery mensal — script PowerShell que valida integridade de 3-5 ficheiros aleatórios.
4. Tabletop exercise trimestral — simular ataque sem restaurar nada.
5. 3-2-1-1-0 documentado e auditado — passar em auditoria SOC 2, ISO 27001, NIS2.
6. Separar credenciais — backup server com gMSA (não service account manual) + LAPS para local admin.
7. Monitor backup anomalies — Veeam ONE, SIEM alerts em volume write rate, shadow copy deletion.
8. M365 backup obrigatório — Veeam for M365, Acronis, ou Commvault.
9. Runbook de recovery — 5-10 páginas, screenshots, validado em ambiente isolado.
10. Cyber insurance — verificar apólice cobre custos de recovery (não só pagamento de resgate). Em 2024, 70% das apólices excluem pagamento de resgate, mas cobrem recovery.

Histórico de testes

Nota de transparência

Os 4 métodos de backup imutável (Veeam Hardened Repository, S3 Object Lock, Azure Immutable Vault, Acronis) foram testados em ambiente de produção em 2026-06-13. Os 10 cenários reais (Change Healthcare, Ascension, MGM, MOVEit, etc.) são públicos (CISA StopRansomware, Sophos State of Ransomware). As directrizes NIST SP 800-34 e 800-184 são as referências oficiais para recovery. A estatística de 34% de ataques que tentaram apagar backups vem do Sophos State of Ransomware 2024.