Immagina di dover proteggere l’accesso alle risorse aziendali senza trasformare il login in un incubo per gli utenti legittimi. Conditional Access è il servizio di Microsoft Entra ID che risolve esattamente questo problema: è il punto in cui l’identità verificata incontra la decisione di accesso. Dopo che l’utente ha dimostrato chi è (autenticazione), Conditional Access decide se e come può effettivamente entrare, valutando il contesto in tempo reale.

Un motore di policy “if-then”

Il cuore di Conditional Access è una logica se-allora (if-then). Ogni policy dice, in sostanza: “SE si verifica questa condizione, ALLORA applica questo controllo”. La parte “SE” raccoglie i segnali; la parte “ALLORA” impone una decisione.

I segnali tipici che il motore analizza sono:

  • Utente o gruppo: chi sta accedendo (es. amministratori, ospiti, un reparto specifico).
  • Dispositivo: è gestito, conforme (compliant), registrato o completamente sconosciuto?
  • Posizione (location): da quale rete o area geografica arriva la richiesta (named location, IP fidati, Paesi).
  • Applicazione: quale app o risorsa cloud viene richiesta (es. Exchange Online, un’app critica).
  • Rischio (risk): il livello di rischio dell’utente o del sign-in calcolato da Microsoft Entra ID Protection.

In base a questi segnali, la decisione può essere: concedere l’accesso, bloccarlo, oppure concederlo solo a certe condizioni, la più comune delle quali è richiedere la Multi-Factor Authentication (MFA).

Scenari reali

  • Un utente accede a un’app finanziaria da un IP fuori dai Paesi previsti → la policy richiede MFA (o blocca).
  • Un dispositivo non conforme tenta di aprire SharePoint → l’accesso è consentito ma in sola lettura, senza possibilità di scaricare file.
  • Un sign-in classificato ad alto rischio da Entra ID Protection → l’utente deve cambiare la password prima di procedere.
  • Gli amministratori possono accedere al portale solo da dispositivi gestiti e conformi.

Grant control vs Session control

Questa distinzione è centrale per l’esame.

  • I grant control (controlli di concessione) decidono se l’accesso viene concesso. Rispondono alla domanda “puoi entrare?” e includono opzioni come bloccare l’accesso, richiedere MFA, richiedere un dispositivo compliant o richiedere un dispositivo Entra hybrid joined. Quando si combinano più requisiti, si sceglie se l’utente deve soddisfarli tutti o almeno uno.
  • I session control (controlli di sessione) intervengono dopo che l’accesso è stato concesso e limitano cosa l’utente può fare durante la sessione. Esempi: imporre restrizioni sull’uso delle app (download bloccati), forzare una frequenza di riautenticazione (sign-in frequency), o applicare limitazioni tramite app enforced restrictions.

In sintesi: grant = si entra o no; session = cosa si può fare una volta dentro.

Il legame con Zero Trust

Conditional Access è l’attuazione pratica dei principi Zero Trust, il cui motto è “never trust, always verify” (mai fidarsi, verificare sempre). Vediamo la corrispondenza:

  • Verificare esplicitamente: la decisione non si basa solo su username e password, ma su molteplici segnali (utente, dispositivo, posizione, rischio) valutati a ogni richiesta.
  • Usare l’accesso con privilegi minimi (least privilege): i session control limitano la sessione allo stretto necessario.
  • Presumere la violazione (assume breach): il segnale di rischio e la riautenticazione periodica trattano ogni sessione come potenzialmente compromessa.

Conditional Access non sostituisce l’identità: la estende, rendendo l’accesso adattivo al contesto anziché statico.

Trappole tipiche d’esame

  • Scenario: vuoi imporre l’MFA solo quando gli utenti accedono da fuori della rete aziendale. Quale strumento usi? → Conditional Access, con la posizione come condizione e “require MFA” come grant control (non attivare l’MFA in modo indiscriminato per tutti).
  • Scenario: devi impedire il download di file su dispositivi non gestiti pur consentendo la visualizzazione online. Grant o session control? → Session control (limita l’attività dentro la sessione, non l’ingresso).
  • Scenario: un accesso viene segnalato come “high risk”. Quale servizio fornisce questo segnale a Conditional Access? → Microsoft Entra ID Protection (Conditional Access consuma il rischio, non lo calcola).
  • Scenario: ti chiedono quale principio Zero Trust è rappresentato dal valutare dispositivo, posizione e rischio a ogni richiesta. → Verify explicitly (verificare esplicitamente).
  • Scenario: serve garantire che solo dispositivi conformi accedano a un’app. → Policy Conditional Access con grant control “require device to be marked as compliant” (la conformità è gestita insieme a Microsoft Intune).