Perché l’accesso privilegiato è il primo dominio da mettere in sicurezza

Nel modello di minaccia moderno, l’aggressore non “buca” più il perimetro: acquisisce credenziali e le eleva fino a controllare il piano che governa l’identità. Per questo un Cybersecurity Architect progetta la protezione dell’accesso privilegiato prima di rete, dati e workload. Il framework di riferimento è l’Enterprise Access Model di Microsoft, che sostituisce il vecchio tiering AD (Tier 0/1/2) con una separazione per piani di controllo.

I tre piani: control, management, data

  • Control plane — chi governa l’identità e la configurazione di sicurezza: Microsoft Entra ID (ruoli come Global Administrator, Privileged Role Administrator), le CA policy, i tenant di Azure, i domain controller. Compromettere qui significa compromettere tutto.
  • Management plane — chi amministra i workload ma non l’identità: operatori di subscription, gestori di Microsoft Sentinel, admin di Intune, pipeline DevOps.
  • Data/workload plane — le applicazioni e i dati serviti agli utenti.

Il principio di design è la non-transitività: un’identità del management plane non deve poter scalare al control plane, e nessuna sessione privilegiata deve originare da un dispositivo di produttività generica. Ogni volta che un percorso di escalation attraversa i piani, è un difetto architetturale.

Just-in-time con PIM: eliminare il privilegio permanente

Privileged Identity Management (PIM) in Entra ID implementa il pilastro Security del Azure Well-Architected Framework trasformando i ruoli da always-on a eligible: l’amministratore attiva il ruolo solo quando serve, per una finestra limitata, superando MFA, giustificazione e (se richiesto) approvazione.

Le leve di design principali:

  • Eligible vs Active assignment — la regola è: nessun assegnamento attivo permanente sui ruoli del control plane. Le uniche eccezioni sono i break-glass account.
  • Activation con approval workflow per i ruoli a impatto massimo (Global Admin, Privileged Role Admin).
  • Access reviews ricorrenti per certificare che gli eligible siano ancora necessari.
  • PIM for Groups per estendere il JIT anche ad accessi che non sono ruoli Entra nativi (es. gruppi che governano risorse Azure o app).

Il trade-off: JIT vs disponibilità operativa in emergenza

Il JIT introduce latenza e dipendenze: se un incidente colpisce proprio l’identità (Entra ID degradato, MFA non raggiungibile, approvatore irreperibile), un modello 100% just-in-time può bloccare la risposta. La raccomandazione architetturale è mantenere 2 break-glass account (cloud-only, escludibili dalle CA policy, con password lunghe custodite offline e monitorati con alert Sentinel su ogni sign-in), accettando consapevolmente un piccolo residuo di privilegio permanente in cambio di resilienza. È l’equilibrio classico tra i pilastri Security e Reliability.

PAW: la workstation come confine di fiducia

Le credenziali privilegiate valgono quanto il dispositivo da cui vengono usate. Una Privileged Access Workstation (PAW) è una postazione dedicata e hardenizzata — nessuna email, nessun browsing generico, application control (App Control for Business), attestazione dell’integrità — riservata esclusivamente alle attività del control/management plane.

Design consigliato: enforcement via Conditional Access che, per i ruoli privilegiati, richiede device compliant + hybrid/Entra joined + filtro su device attributi PAW. Così anche se la credenziale viene rubata, non è utilizzabile da un endpoint non attestato. Chi non può permettersi PAW fisiche dedicate adotta il modello Cloud PAW / SAW con sessioni isolate, ma il principio “clean source” resta invariato: il piano più sensibile si amministra dal dispositivo più protetto, mai il contrario.

L’angolo cieco: identità non-umane e cross-cloud

L’errore ricorrente è governare gli admin umani e dimenticare il resto:

  • Service principal con client secret longevi e credenziali non ruotate — preferire managed identity o workload identity federation (nessun segreto da custodire).
  • Managed identity con ruoli RBAC troppo ampi (spesso Contributor a scope subscription): applicare least privilege e monitorarle con Microsoft Defender for Cloud.
  • Privilegi cross-cloud: un utente Global Admin di Entra che è anche root in AWS o admin GCP crea un percorso di escalation invisibile ai controlli del singolo cloud. Serve una governance unificata delle identità privilegiate su tutti i cloud, con Purview per la classificazione/audit e Defender for Cloud per la postura multicloud.

Trappole tipiche d’esame

  • Requisito: eliminare gli standing admin su ruoli critici senza bloccare le emergenze → PIM eligible + activation con approval, più 2 break-glass account cloud-only esclusi dalle CA e monitorati in Sentinel. Non affidare il break-glass al solo JIT.
  • Requisito: impedire che credenziali privilegiate rubate siano usabili altrove → Conditional Access che richiede device PAW compliant/attestato per l’attivazione dei ruoli, non solo MFA.
  • Requisito: un’app deve accedere ad Azure senza segreti da gestire → managed identity (o workload identity federation), mai service principal con secret hardcoded o a lunga scadenza.
  • Requisito: certificare periodicamente chi ha accesso privilegiato → PIM Access Reviews ricorrenti, non uno script di export manuale una tantum.
  • Requisito: un operatore di workload non deve poter diventare Global Admin → separare i piani dell’Enterprise Access Model e verificare la non-transitività; attenzione ai ruoli che governano gruppi/CA come vie di escalation nascoste.