Um ataque de ransomware moderno não se limita a cifrar dados — destrói primeiro os backups. Shadow Copies eliminadas, agentes de backup desactivados, credenciais de administrador comprometidas usadas para apagar os dados de backup antes do payload final. É a razão pela qual a estratégia de backup tem de ser concebida assumindo que as credenciais de administrador já estão nas mãos do atacante.

O Azure Backup (Recovery Services Vault) disponibiliza três mecanismos específicos para este cenário: Soft Delete (recuperação após eliminação maliciosa), Immutable Vault (backups que não podem ser apagados nem mesmo com credenciais de administrador comprometidas) e Multi-User Authorization / Resource Guard (aprovação de segundo administrador para operações críticas de backup). Este artigo configura os três de forma prática.

1. Arquitectura recomendada de backup Azure para PME

A arquitectura abaixo segue a regra 3-2-1-1 adaptada ao contexto Azure e ao requisito NIS2 de backup isolado e testado:

Camada Tecnologia Retenção Protecção ransomware
Snapshot local Azure VM Snapshots / Shadow Copies 1–7 dias Baixa — apagável pelo ransomware
Recovery Services Vault Azure Backup com Soft Delete activado 30–90 dias Média — Soft Delete 14–180 dias
Vault Imutável Recovery Services Vault com Immutability Locked 90 dias–10 anos Máxima — WORM, inviolável
Retenção de longo prazo Azure Backup com política semanal/mensal/anual 1–10 anos Alta — separado das operações diárias

ℹ Separação de subscrição recomendada

Para protecção máxima, cria o Recovery Services Vault numa subscrição Azure separada da produção, com administradores diferentes. Assim, mesmo que as credenciais da subscrição de produção sejam comprometidas, o atacante não tem acesso directo ao vault de backup. O Azure Backup suporta backup cross-subscription.

2. Criar o Recovery Services Vault

Caminho: portal.azure.com → Recovery Services vaults → + Create

Campo Valor recomendado
Subscription Subscrição dedicada de backup (recomendado) ou subscrição de produção
Resource Group rg-backup-prod
Vault name rsv-empresa-westeurope-001
Region West Europe (Amsterdam) — região mais próxima com todos os recursos disponíveis
Storage Redundancy Geo-Redundant Storage (GRS) — replica para região secundária (North Europe). Apenas mudar para LRS se o custo for determinante e não houver requisito de DR geográfico

⚠ Storage Redundancy — configurar antes do primeiro backup: Após configurar o primeiro item de backup no vault, o tipo de redundância de armazenamento não pode ser alterado. Definir GRS ou LRS antes de fazer qualquer configuração de backup.

3. Soft Delete — configurar e estender a retenção

O Soft Delete garante que mesmo que um atacante com credenciais de administrador apague os dados de backup, esses dados ficam em estado soft-deleted durante o período configurado — recuperáveis até ao último dia. Por defeito, o Azure activa Soft Delete com 14 dias em todos os novos vaults. O máximo configurável é 180 dias.

Caminho: Recovery Services vault → Properties → Security Settings → Soft delete

Definição Valor recomendado
Soft delete state Enabled (Always-on) — irreversível, máxima protecção
Soft delete retention 30 dias mínimo recomendado. Para entidades NIS2: 90 dias. Máximo: 180 dias (cobrado além dos primeiros 14 dias)
Cross Region Restore Enable — permite restauro para a região secundária em caso de falha da região primária (requer GRS)

Como recuperar dados em estado Soft-Deleted

  1. Aceder ao vault → Backup Items
  2. Filtrar por Soft Deleted — os itens em estado soft-deleted aparecem com ícone vermelho
  3. Seleccionar o item → Undelete
  4. Após undelete, o item regressa ao estado Stop protection with retain data
  5. Retomar a protecção ou restaurar a partir dos recovery points disponíveis

4. Immutable Vault — protecção máxima anti-ransomware

O Immutable Vault usa armazenamento WORM (Write Once, Read Many) — uma vez criado um recovery point, não pode ser eliminado nem ter a sua retenção reduzida antes do prazo configurado na política. Nem pelo administrador. Nem com credenciais globais comprometidas. É a resposta definitiva à destruição de backups por ransomware.

Estado de Imutabilidade O que significa Reversível?
Disabled Sem imutabilidade — comportamento padrão Sim
Unlocked Imutabilidade activa mas pode ser desactivada — usar para testar antes de bloquear definitivamente Sim
Locked Imutabilidade permanente — nenhum recovery point pode ser eliminado antes do prazo de política. WORM activo NÃO — irreversível

Caminho: Recovery Services vault → Properties → Vault settings → Immutability

⚠ Processo obrigatório antes de Locked: Começa sempre em estado Unlocked. Testa todos os fluxos de backup e restauro durante pelo menos 2 semanas antes de passar para Locked. Uma vez no estado Locked, nunca poderás reduzir a retenção, alterar a política ou eliminar recovery points antes do prazo — mesmo em caso de erro de configuração.

Configurar via Azure CLI

# Passo 1: Activar imutabilidade em estado Unlocked (reversível)
az backup vault backup-properties set \
  --resource-group rg-backup-prod \
  --name rsv-empresa-westeurope-001 \
  --immutability-state Unlocked

# Passo 2: Após testes (mínimo 2 semanas), bloquear definitivamente
# ATENÇÃO: Esta operação é IRREVERSÍVEL
az backup vault backup-properties set \
  --resource-group rg-backup-prod \
  --name rsv-empresa-westeurope-001 \
  --immutability-state Locked

5. Políticas de backup — frequência e retenção

O Azure Backup usa políticas para definir quando fazer backup e por quanto tempo reter cada recovery point. Para contexto PME com requisitos NIS2, a política abaixo é a referência recomendada:

Tipo de backup Frequência Retenção Objectivo
Diário 1x/dia (ex: 23:00) 30 dias Restauro de erros recentes, ransomware detectado rapidamente
Semanal Domingo, 02:00 12 semanas Ransomware com dwell time longo (semanas de persistência)
Mensal 1º domingo do mês 12 meses Conformidade, auditorias, recuperação de dados históricos
Anual 1º de janeiro, 03:00 5 anos Requisitos legais, NIS2, retenção de longo prazo

ℹ RPO e RTO — definir antes de configurar a política

RPO (Recovery Point Objective) — máximo de dados que a organização aceita perder. Se o RPO é 4 horas, o backup diário às 23h não é suficiente para um sistema transaccional. Considera backups múltiplos por dia ou replicação contínua para dados críticos.
RTO (Recovery Time Objective) — tempo máximo aceitável para restaurar e retomar operação. Define que tipo de restore é necessário (ficheiro, VM completa, Azure Site Recovery).

6. O que proteger com Azure Backup

Workload Suportado pelo Azure Backup? Caminho de configuração
VMs Azure (Windows/Linux) ✓ Sim Vault → Backup → Azure Virtual Machine
Azure Files (partilhas de ficheiros) ✓ Sim Vault → Backup → Azure Files
SQL Server em VM Azure ✓ Sim (com agente) Vault → Backup → SQL in Azure VM
Servidor on-premises (Windows Server) ✓ Via MARS agent Vault → Backup → On-premises → MARS agent download
VMware / Hyper-V on-premises ✓ Via MABS ou DPM Microsoft Azure Backup Server (MABS) no-premises
SharePoint Online / OneDrive △ Via Microsoft 365 Backup Microsoft 365 Admin Center → Microsoft 365 Backup (licença adicional)

Configurar backup de VM Azure — passo a passo

  1. No vault, clicar em + Backup
  2. Where is your workload running? → Azure
  3. What do you want to backup? → Virtual machine
  4. Seleccionar a política de backup (ou criar nova com os parâmetros da Secção 5)
  5. Seleccionar as VMs a proteger → clicar Enable Backup
  6. O primeiro backup completo é agendado — pode ser disparado manualmente: Backup Items → VM → Backup now

7. Restauro — procedimentos e tipos

O Azure Backup oferece vários tipos de restauro para VMs e ficheiros. Conhecer as opções antes de um incidente evita perder tempo precioso numa crise:

Tipo de Restauro Quando usar Tempo estimado
Restore VM (Create new) VM completamente comprometida — cria nova VM paralela ao lado da afectada 30–90 min (dependendo do tamanho do disco)
Replace existing VM Substituir a VM actual pelo recovery point — a VM actual é destruída 30–60 min
Restore Disk Restaurar apenas o disco para um storage account — mais controlo sobre o processo 15–45 min (transferência de disco)
File Recovery Recuperar ficheiros ou pastas específicas sem restaurar a VM completa 5–15 min (mount do snapshot)
Cross Region Restore Falha total da região primária — restauro para região secundária (requer GRS e Cross Region Restore activado) 60–180 min

Procedimento de File Recovery — recuperar ficheiros específicos

  1. Vault → Backup Items → seleccionar a VM
  2. Clicar em File Recovery
  3. Seleccionar o recovery point desejado
  4. Fazer download do script de montagem (PowerShell para Windows, bash para Linux)
  5. Executar o script na máquina onde queres montar os volumes — o disco do backup é montado como drive local
  6. Copiar os ficheiros necessários
  7. Clicar Unmount Disks no portal (ou aguardar — a sessão expira após 12 horas)

8. Teste de restauro — obrigatório e documentado

⚠ Um backup nunca testado não é um backup. A NIS2 exige que os planos de recuperação sejam testados periodicamente. Um teste de restauro documentado e com data é a evidência mais directa de conformidade neste requisito.

Plano de teste de restauro trimestral

Elemento a testar Procedimento Documentar
VM crítica (ex: DC, servidor de ficheiros) Restore VM para grupo de recursos isolado de teste → verificar arranque e serviços → destruir VM de teste Data, recovery point usado, tempo de restauro, resultado
Ficheiros de utilizador File Recovery de pasta de utilizador — verificar integridade dos ficheiros restaurados Pasta testada, número de ficheiros, integridade OK/NOK
Base de dados SQL Restore para SQL Server de teste → verificar consistência com DBCC CHECKDB → destruir DB de teste Recovery point, resultado DBCC, tempo de restauro
Servidor on-premises (MARS agent) Restauro de pasta de ficheiros para local alternativo → verificar integridade Data, ficheiros restaurados, tempo, resultado

9. Monitorizar e alertar falhas de backup

Uma falha de backup silenciosa pode passar semanas sem ser detectada — e ser descoberta exactamente no pior momento: durante um incidente de ransomware. Configurar alertas é obrigatório.

Configurar alertas de backup

Caminho: Recovery Services vault → Monitoring → Alerts → Configure notifications

  • Job failures — alertar por email imediatamente quando um job de backup falha
  • Soft delete operations — alertar quando qualquer item de backup entra em estado soft-deleted (sinal de possível ataque)
  • Security alerts — activar todos os alertas de segurança do vault (tentativas de desactivar soft delete, etc.)

Usar o Azure Monitor para alertas centralizados

# Criar action group para enviar email em falhas de backup
az monitor action-group create \
  --resource-group rg-backup-prod \
  --name ag-backup-alerts \
  --short-name backupalert \
  --email-receivers name=IT [email protected]

# Criar regra de alerta para falhas de backup
az monitor alert create \
  --resource-group rg-backup-prod \
  --name "Backup Job Failed" \
  --description "Alerta quando job de Azure Backup falha" \
  --condition "category=Backup and status=Failed" \
  --action-group ag-backup-alerts

10. Comandos PowerShell / Azure CLI úteis

Verificar estado de todos os jobs de backup nas últimas 24 horas

Connect-AzAccount

$vault = Get-AzRecoveryServicesVault -Name "rsv-empresa-westeurope-001" -ResourceGroupName "rg-backup-prod"
Set-AzRecoveryServicesVaultContext -Vault $vault

# Jobs das últimas 24 horas
Get-AzRecoveryServicesBackupJob -From (Get-Date).AddDays(-1) -VaultId $vault.Id |
    Select-Object WorkloadName, Operation, Status, StartTime, EndTime |
    Format-Table -AutoSize

# Filtrar apenas os que falharam
Get-AzRecoveryServicesBackupJob -From (Get-Date).AddDays(-1) -Status Failed -VaultId $vault.Id

Listar todos os recovery points disponíveis para uma VM

$backupItem = Get-AzRecoveryServicesBackupItem \
    -BackupManagementType AzureVM \
    -WorkloadType AzureVM \
    -VaultId $vault.Id \
    -Name "NomeDaVM"

Get-AzRecoveryServicesBackupRecoveryPoint \
    -Item $backupItem \
    -VaultId $vault.Id | \
    Select-Object RecoveryPointId, RecoveryPointTime, RecoveryPointType | \
    Format-Table -AutoSize

Disparar backup imediato de uma VM (fora do agendamento)

# Disparar backup imediato (útil antes de uma manutenção de risco)
Backup-AzRecoveryServicesBackupItem \
    -Item $backupItem \
    -VaultId $vault.Id \
    -ExpiryDateTimeUTC (Get-Date).AddDays(30).ToUniversalTime()

Este artigo foi útil?

Duarte Spínola

Deixe um Comentário