A cosa serve una compliance policy

Una compliance policy in Microsoft Intune definisce lo stato di “salute” che un dispositivo deve rispettare per essere considerato compliant. Non applica configurazioni (quello è compito delle configuration profile), ma valuta il device e ne pubblica lo stato, che diventa la moneta di scambio verso Conditional Access di Microsoft Entra ID: se un dispositivo risulta not compliant, una policy di Conditional Access che richiede “device compliant” ne blocca l’accesso alle risorse (Exchange Online, SharePoint, app SaaS).

Le policy sono multipiattaforma: si crea una policy distinta per Windows, iOS/iPadOS, Android (con profili separati per Android Enterprise, personally owned work profile, ecc.) e macOS. I requisiti disponibili variano per piattaforma, quindi la scelta corretta dipende sempre dal sistema operativo target.

Requisiti tipici da configurare

I settings ricorrenti (e più chiesti all’esame) sono:

  • Minimum/maximum OS version: forza un range di build. Utile per escludere OS end-of-life.
  • Encryption / BitLocker: su Windows richiede BitLocker e Secure Boot (parte dei Device Health); su mobile richiede la cifratura dello storage.
  • Secure Boot e Code integrity: attestati tramite il Windows Health Attestation Service.
  • Antivirus / antispyware / firewall: richiede che Microsoft Defender Antivirus (o soluzioni registrate in Windows Security Center) sia attivo.
  • Jailbroken/rooted devices: su iOS/Android blocca i dispositivi manomessi. È una delle poche valutazioni “lato client” che rende not compliant immediatamente.
  • Defender for Endpoint machine risk score: con l’integrazione Microsoft Defender for Endpoint, si imposta un livello massimo di rischio consentito (es. “Medium”). Se Defender for Endpoint classifica il device sopra la soglia, la policy lo marca not compliant, chiudendo l’accesso finché la minaccia non è rimediata. Questo è lo scenario tipico “compliance basata sul rischio”.

Custom compliance

Per requisiti non coperti nativamente (chiavi di registro, versioni di applicazioni specifiche) su Windows si usano le custom compliance policies, basate su uno script PowerShell più un JSON con le regole di valutazione.

Actions for noncompliance

Ogni policy include almeno un’action for noncompliance. Il default è “Mark device noncompliant” con grace period pari a zero (immediato), ma è configurabile:

  • Grace period: giorni concessi all’utente per rientrare in compliance prima che lo stato diventi effettivamente not compliant. Durante il periodo di grazia il device resta compliant e l’accesso non viene bloccato: serve a non tagliar fuori gli utenti al primo scostamento.
  • Send email to end user: notifica via email (con template e branding personalizzabili) che avvisa l’utente dello stato e delle azioni da compiere. Richiede che l’utente abbia una identità Entra ID valida.
  • Remotely lock il dispositivo (mobile).
  • Retire the noncompliant device: rimuove i dati aziendali gestiti (azione drastica, di solito ultima nella sequenza).

Le azioni si possono scaglionare nel tempo (es. email al giorno 0, seconda email al giorno 5, retire al giorno 30), costruendo un percorso di rimedio progressivo.

Impostazione tenant-level per i device non valutati

Nelle Compliance policy settings a livello di tenant esiste “Mark devices with no compliance policy assigned as”, con due valori: Compliant (default storico) o Not compliant. Questa impostazione decide lo stato dei dispositivi a cui non è assegnata alcuna compliance policy.

La scelta è architetturalmente critica in combinazione con Conditional Access:

  • Se impostata su Not compliant (best practice di sicurezza), qualsiasi device senza policy assegnata viene bloccato da CA che richiede compliance: postura zero-trust, ma può bloccare utenti legittimi se dimentichi di assegnare la policy.
  • Se resta su Compliant, un device senza policy passa i controlli CA anche se non è mai stato valutato: comodo in fase di rollout, ma apre una falla.

Trappole tipiche d’esame

  • Nessuna policy assegnata + tenant setting su “Compliant” → il device è considerato compliant per default e supera Conditional Access anche senza mai essere valutato: accesso concesso in modo imprevisto. Se lo scenario chiede di bloccarlo, imposta il tenant setting su Not compliant.
  • Serve bloccare i device con malware/rischio elevato → integra Defender for Endpoint e imposta il machine risk score massimo nella compliance policy, poi collega Conditional Access. La sola configuration profile non basta.
  • Gli utenti vengono bloccati appena scade una password o cambia una versione → aggiungi un grace period alle actions for noncompliance invece di lasciare lo stato immediato.
  • Occorre avvisare l’utente prima di bloccarlo → configura l’action “Send email to end user” con anticipo rispetto al blocco, non affidarti solo alla marcatura not compliant.
  • Requisito non presente tra i settings nativi (es. specifica versione di un’app Win32) → usa una custom compliance policy con script PowerShell + JSON, non una configuration profile.