Il problema di design: resilienza, non prevenzione

Un architetto SC-100 non progetta l’anti-ransomware come “più firewall e più antivirus”. Il ransomware moderno è human-operated: l’attaccante compromette identità, si muove lateralmente, esfiltra dati (doppia estorsione) e cerca esplicitamente i backup prima di cifrare. La domanda di design non è “come blocco l’ingresso?” ma “quando l’ingresso avverrà, quanto sarà limitato il danno e quanto velocemente posso ripristinare senza pagare?”. Questo sposta il baricentro dal pilastro Security verso Reliability dell’Azure Well-Architected Framework: RTO/RPO e integrità del recovery diventano requisiti di prim’ordine.

Le tre priorità del Rapid Modernization Plan (RaMP)

Il RaMP ordina gli investimenti per impatto decrescente sul rischio, non per facilità implementativa. L’ordine è deliberato: prima garantisci la capacità di rialzarti, poi contieni, infine previeni.

1. Prepare — garantire il recovery senza pagare

Priorità massima perché è l’unica leva che azzera il potere negoziale dell’attaccante. Richiede: piano di business continuity/disaster recovery testato, backup immutabili protetti da WORM, e un inventario dei sistemi critici con RTO/RPO definiti. Se questa fase è solida, un attacco andato a segno diventa un incidente di ripristino, non una crisi esistenziale.

2. Limit scope — proteggere l’accesso privilegiato

Il ransomware scala privilegi per raggiungere Domain Admin / Global Administrator e disabilitare i backup. Design raccomandato: Enterprise Access Model (tiering), Privileged Identity Management in Microsoft Entra ID per accesso JIT, Conditional Access con MFA phishing-resistant (FIDO2/passkey), e PAW per gli account amministrativi. Obiettivo: rendere il percorso dalla workstation compromessa al piano di controllo il più lungo e presidiato possibile.

3. Prevent — ridurre la superficie d’attacco

Ultimo per priorità (non per importanza): patch/vulnerability management via Microsoft Defender for Cloud, riduzione superfici RDP/VPN esposte, ASR rules, e detection con Microsoft Defender XDR + Microsoft Sentinel per intercettare il movimento laterale prima della cifratura.

Trade-off centrale: immutable storage tra costo e RTO

Qui si gioca la vera decisione architetturale. L’immutabilità (Azure Backup immutable vault, o Blob Storage con time-based retention policy WORM) impedisce cancellazione/alterazione anche a un admin compromesso, ma il tier di storage determina il compromesso costo/RTO:

  • Hot immutabile → RTO minuti/ore, costo GB elevato. Raccomandato per i sistemi tier-0 (identity, domain controller, sistemi che bloccano l’intera ripartenza).
  • Cool immutabile → costo intermedio, restore più lento. Adatto a workload importanti ma non critici al minuto.
  • Archive immutabile / air-gapped → costo minimo ma rehydration di ore prima di poter ripristinare: RTO nell’ordine di 8–15 ore. Accettabile solo per dati la cui indisponibilità prolungata non blocca l’operatività.

Regola di design: non applicare un unico tier a tutto. Classifica i workload per criticità e allinea il tier di immutabilità all’RTO richiesto da ciascuno — è l’incrocio tra Reliability e Cost Optimization. Aggiungi cross-region restore (GRS) per proteggerti da un attacco region-wide, accettandone il costo aggiuntivo per i tier-0.

Isolamento della recovery e separazione dell’identità

L’immutabilità da sola non basta: se l’admin di backup usa le stesse credenziali del dominio compromesso, l’attaccante può ridurre le retention o eliminare i vault. Contromisure architetturali:

  • Multi-User Authorization (MUA) con Resource Guard su vault Azure Backup: le operazioni distruttive richiedono l’approvazione di un secondo principal residente in un tenant/subscription separato.
  • Piano di identità del backup separato dal piano di produzione (break-glass account dedicati, non federati con l’AD compromettibile).
  • Recovery environment isolato: ambiente di ripristino pulito, separato di rete, dove ricostruire prima di riconnettere alla produzione.

Trappole tipiche d’esame

  • Requisito: “backup che sopravvivano a un admin compromesso” → immutable vault + soft delete always-on + Multi-User Authorization con Resource Guard in una subscription separata. La sola replica GRS o la sola immutabilità senza MUA non è sufficiente.
  • Requisito: “ridurre il costo dei backup a lungo termine mantenendo la resilienza, con ripristino non urgente” → tier Archive immutabile, accettando il rehydration multi-ora; NON usare Archive per i sistemi tier-0 con RTO stringente.
  • Requisito: “l’azienda ha subito un attacco perché i backup erano raggiungibili con le stesse credenziali” → separare il piano di identità del backup, applicare PIM/JIT e MUA; il vero difetto è l’identità condivisa, non l’assenza di backup.
  • Requisito: “priorità con budget limitato” → seguire l’ordine RaMP: prima Prepare (recovery), poi Limit (privileged access), infine Prevent. Chi risponde partendo dalla prevenzione (patch/firewall) sbaglia priorità.
  • Requisito: “garantire che il ripristino funzioni davvero” → test di restore periodici e verificati in ambiente isolato; un backup mai testato è considerato inesistente ai fini della resilienza (pilastro Reliability WAF).