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.
Neste artigo
- Arquitectura recomendada de backup Azure para PME
- Criar o Recovery Services Vault
- Soft Delete — configurar e estender a retenção
- Immutable Vault — protecção máxima anti-ransomware
- Políticas de backup — frequência e retenção
- O que proteger com Azure Backup
- Restauro — procedimentos e tipos
- Teste de restauro — obrigatório e documentado
- Monitorizar e alertar falhas de backup
- Comandos PowerShell / Azure CLI úteis
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
- Aceder ao vault → Backup Items
- Filtrar por Soft Deleted — os itens em estado soft-deleted aparecem com ícone vermelho
- Seleccionar o item → Undelete
- Após undelete, o item regressa ao estado Stop protection with retain data
- 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
- No vault, clicar em + Backup
- Where is your workload running? → Azure
- What do you want to backup? → Virtual machine
- Seleccionar a política de backup (ou criar nova com os parâmetros da Secção 5)
- Seleccionar as VMs a proteger → clicar Enable Backup
- 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
- Vault → Backup Items → seleccionar a VM
- Clicar em File Recovery
- Seleccionar o recovery point desejado
- Fazer download do script de montagem (PowerShell para Windows, bash para Linux)
- Executar o script na máquina onde queres montar os volumes — o disco do backup é montado como drive local
- Copiar os ficheiros necessários
- 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()
Artigos relacionados no kbase.pt
- Plano de Resposta a Ransomware: Guia para Empresas Portuguesas
- Acronis Cyber Protect: configurar anti-ransomware em ambiente PME
- Isolamento de workstation comprometida: procedimento step-by-step
- NIS2 em Portugal: Checklist Técnica para Sysadmins
- Relatório de Incidente de Cibersegurança: template para CNPD/NIS2
