La protezione delle identità è il cuore della sicurezza moderna: se un attaccante compromette un account, aggira gran parte delle difese perimetrali. Microsoft Entra ID Protection e il role-based access control (RBAC) sono i due pilastri che permettono, rispettivamente, di rilevare identità compromesse e di limitare ciò che ogni identità può fare.

Microsoft Entra ID Protection

Microsoft Entra ID Protection è il servizio che usa segnali e machine learning per individuare identità potenzialmente compromesse. Analizza miliardi di segnali (login anomali, indirizzi IP malevoli, credenziali trapelate) e assegna un livello di rischio.

Rischio utente e rischio di sign-in

Entra ID Protection distingue due tipi di rischio:

  • Rischio di sign-in (sign-in risk): valuta la probabilità che un singolo tentativo di accesso non sia legittimo. Esempi di detection: viaggio impossibile (atypical travel), indirizzo IP anonimo (Tor/VPN sospette), proprietà di sign-in sconosciute.
  • Rischio utente (user risk): valuta la probabilità che l’account nel suo complesso sia compromesso. Il segnale tipico sono le leaked credentials, ovvero credenziali trovate nel dark web.

Policy basate sul rischio e remediation

Il valore di Entra ID Protection sta nell’automatizzare la risposta tramite policy (idealmente implementate come policy di Conditional Access risk-based):

  • User risk policy: se il rischio utente è alto, obbliga l’utente a un secure password change (con MFA), che risolve automaticamente il rischio.
  • Sign-in risk policy: se il rischio del login è elevato, richiede MFA o blocca l’accesso.

Questa è la remediation automatica: l’utente si “auto-guarisce” dimostrando la propria identità, senza intervento manuale dell’amministratore. L’admin può comunque analizzare i report (utenti rischiosi, accessi rischiosi, detection) e dismettere o confermare manualmente un rischio.

RBAC e il principio del least privilege

Il role-based access control (RBAC) assegna i permessi non ai singoli, ma tramite ruoli: a un utente (o gruppo/service principal) si assegna un ruolo, e il ruolo porta con sé un set di permessi. Questo abilita il principio del least privilege: dare a ciascuno solo i permessi necessari, per il tempo necessario. Meno privilegi in giro significa minore superficie d’attacco.

Ruoli di Entra ID vs ruoli RBAC di Azure

Questo è uno dei punti più insidiosi dell’esame. Esistono due sistemi di ruoli distinti:

Ruoli di Entra ID (directory roles)

Governano ciò che puoi fare dentro la directory / il tenant: gestire utenti, gruppi, applicazioni, policy, licenze. Esempi:

  • Global Administrator — controllo completo del tenant (da assegnare a pochissime persone).
  • User Administrator, Helpdesk Administrator, Security Administrator, Global Reader (sola lettura).

Ruoli RBAC di Azure (Azure roles)

Governano l’accesso alle risorse Azure (VM, storage account, database, reti) e si applicano a uno scope gerarchico: management group → subscription → resource group → singola risorsa. Ruoli fondamentali:

  • Owner — gestione completa + gestione degli accessi.
  • Contributor — gestione delle risorse, ma non può assegnare accessi.
  • Reader — sola lettura.
  • User Access Administrator — gestisce solo gli accessi.

In sintesi: i ruoli di Entra ID gestiscono la directory (identità e configurazione del tenant); i ruoli RBAC di Azure gestiscono le risorse cloud. Sono catalogati separatamente e assegnati in portali/contesti diversi.

Concetto correlato spesso citato insieme: Privileged Identity Management (PIM) consente l’accesso just-in-time ai ruoli privilegiati (sia Entra ID sia Azure), rafforzando ulteriormente il least privilege.

Trappole tipiche d’esame

  • Scenario: rilevate delle leaked credentials per alcuni account e volete forzarli automaticamente a cambiare password. → Configura una user risk policy in Microsoft Entra ID Protection (non una sign-in risk policy: le credenziali trapelate sono rischio utente).

  • Scenario: volete bloccare o richiedere MFA quando un login proviene da una posizione impossibile o da un IP anonimo. → È sign-in risk (rischio del singolo accesso), gestito da una sign-in risk policy.

  • Scenario: dovete dare a un tecnico il permesso di creare e gestire macchine virtuali in un resource group, senza però poter assegnare permessi ad altri. → Ruolo RBAC di Azure Contributor sullo scope del resource group (non un ruolo di Entra ID, che riguarda la directory).

  • Scenario: dovete permettere a un collega di reimpostare le password e gestire gli account utente del tenant. → Ruolo di Entra ID (es. User Administrator), non un Azure role.

  • Scenario: volete dare accesso amministrativo a un ruolo privilegiato solo al momento del bisogno e a tempo limitato. → Privileged Identity Management (PIM) con attivazione just-in-time.