Condizioni di utilizzo Entra: accettazione con Conditional Access

Che cosa impongono realmente le condizioni di utilizzo Entra

Le condizioni di utilizzo Entra presentano un documento durante un accesso interattivo e possono rendere l’accettazione una condizione di accesso. La domanda utile è se le persone previste debbano accettare il documento approvato prima di raggiungere l’applicazione prevista. Trovare un PDF nel tenant risponde solo a una parte di questa domanda.

Partite da un’esigenza aziendale: chi deve prendere atto di quali regole, per quali risorse e chi è responsabile del testo? Chiedete ai revisori aziendali e legali competenti di approvare il documento prima di configurarne l’applicazione. L’assenza di un accordo è un segnale di configurazione da approfondire, non la prova di una violazione normativa universale. Alcuni tenant potrebbero non avere un caso d’uso giustificato per questa funzionalità; registrate questa decisione anziché creare un accordo vuoto per eliminare un rilievo.

Un progetto pilota concreto potrebbe riguardare uno spazio di lavoro di un partner il cui responsabile vuole che i collaboratori esterni prendano atto delle regole di trattamento dei dati. Definite esplicitamente la popolazione e l’applicazione. Non presumete che ogni percorso di condivisione esterna crei un account guest Entra o segua lo stesso percorso di accesso. Usate la revisione di Conditional Access per i guest e della collaborazione esterna per definire questa popolazione e le sue esclusioni prima di aggiungere l’accettazione del documento.

La distribuzione deve produrre evidenze per tre domande distinte: l’accordo esiste, un criterio che lo applica lo richiede per la popolazione e la risorsa scelte, e le risposte degli utenti mostrano che il documento previsto è stato accettato o rifiutato? Mantenete separate queste risposte nella documentazione della modifica.

Come si collegano l’accordo e Conditional Access

La guida alla configurazione delle condizioni di utilizzo di Microsoft richiede una licenza Entra ID P1 e un PDF. Indica Security Reader come ruolo minimo per leggere la configurazione e Conditional Access Administrator per crearla o modificarla. Confermate la sottoscrizione e l’assegnazione del ruolo all’amministratore prima di pianificare il progetto pilota.

L’accordo contiene le impostazioni del documento; un controllo di concessione di Conditional Access lo collega alle decisioni di accesso. Anche le scelte di lingua e versione fanno parte della progettazione. Un accordo esistente ma non collegato al criterio previsto può soddisfare un controllo di esistenza lasciando insoddisfatta l’esigenza aziendale.

La risorsa agreement di Graph espone un identificatore, requisiti di visualizzazione e per dispositivo, una pianificazione della scadenza e una durata di nuova accettazione per utente. La relazione file identifica il PDF predefinito; files è documentata come in fase di deprecazione a favore di file. La relazione acceptances è una raccolta separata di risposte degli utenti.

Usate queste distinzioni quando pianificate le evidenze. Conservate insieme l’ID dell’accordo e la versione approvata del PDF, quindi registrate il criterio che richiede quell’accordo. Un nome visualizzato è comodo per le persone, ma l’identificatore è una chiave di correlazione più sicura per i record di configurazione e risposta. Assegnate un responsabile della manutenzione del documento e delle traduzioni e un responsabile del criterio che ne mantenga l’ambito. Se uno cambia, riesaminate l’altro lato del collegamento.

Rilevamento: controllare separatamente esistenza, collegamento e risposte

Inventariare gli accordi senza confondere una lettura fallita con l’assenza

Nel centro di amministrazione Entra, aprite Entra ID > Conditional Access > Terms of use. Identificate l’accordo previsto per lo scenario aziendale, le lingue del documento e la cronologia delle versioni. Se la pagina è vuota, verificate di esaminare il tenant corretto con un ruolo di lettura appropriato prima di registrare un’assenza.

Per un inventario indipendente tramite API, Microsoft documenta questa richiesta in List agreements:

GET https://graph.microsoft.com/v1.0/identityGovernance/termsOfUse/agreements
Authorization: Bearer {token}

Si tratta di un modello di richiesta documentato, non di una query eseguita sul tenant di un cliente per questo articolo. La pagina indica l’autorizzazione delegata Agreement.Read.All per gli account aziendali o dell’istituto di istruzione, con Security Reader come ruolo supportato con i privilegi minimi. Indica che le autorizzazioni dell’applicazione non sono supportate per questa operazione. Controllate il modello di autorizzazione attuale del client utilizzato anziché presumere che un token dell’applicazione e un token delegato offrano una copertura equivalente.

Trattate un errore di autorizzazione, una raccolta interrotta o una risposta illeggibile come un’osservazione non risolta. Solo un inventario riuscito e completo consente di concludere che non sono stati restituiti accordi. Conservate con il risultato il contesto del tenant, l’ora della raccolta e gli eventuali errori.

Esaminare il criterio che deve richiedere l’accordo

Aprite il criterio di Conditional Access pertinente ed esaminate il suo stato, gli utenti o gruppi inclusi, le esclusioni, le risorse di destinazione e i controlli di concessione. Confermate che l’accordo previsto sia selezionato in Grant access, con il requisito Require terms of use. Controllate la combinazione dei controlli di concessione affinché la decisione di accesso prevista richieda effettivamente l’accettazione.

Un nome di criterio che menziona le condizioni di utilizzo non è un’evidenza sufficiente. La configurazione Report-only è utile per valutare l’impatto, ma il test di applicazione deve usare un criterio pilota abilitato. Seguite un utente di test previsto attraverso le assegnazioni e le esclusioni, poi provate l’accesso alla risorsa. Se l’inventario contiene accordi ma nessun criterio previsto li seleziona, registrate una lacuna di collegamento separatamente dall’assenza di accordi.

Esaminare le evidenze di accettazione della versione prevista

Il portale espone le risposte di accettazione e rifiuto e la cronologia delle versioni. Per le evidenze tramite API, List acceptances documenta:

GET https://graph.microsoft.com/v1.0/identityGovernance/termsOfUse/agreements/{agreementsId}/acceptances
Authorization: Bearer {token}

Gli oggetti restituiti sono record agreementAcceptance, comunemente chiamati accettazioni degli accordi. Il riferimento della risorsa descrive agreementId, agreementFileId, userId, state, recordedDateTime e expirationDateTime. Gli stati di risposta documentati sono accepted e declined. Correlate l’utente, l’accordo e il file anziché considerare qualsiasi accettazione storica come evidenza per il documento attuale.

Per questo endpoint circoscritto a un accordo, l’operazione di elenco documenta l’autorizzazione delegata AgreementAcceptance.Read e l’autorizzazione superiore AgreementAcceptance.Read.All, con Security Reader come ruolo supportato con i privilegi minimi. Indica che le autorizzazioni dell’applicazione non sono supportate. Trattate le esportazioni delle accettazioni come dati utente, limitate l’accesso ai revisori che ne hanno bisogno e seguite le regole di conservazione della vostra organizzazione. L’esportazione serve a documentare il progetto pilota, non a creare una copia senza restrizioni dell’attività degli utenti.

Correzione: distribuire un accordo approvato con un progetto pilota circoscritto (Remediation)

1. Approvare il testo e definire il requisito di accettazione

Annotate il responsabile della risorsa, il responsabile del documento, gli utenti previsti, le lingue necessarie, le eccezioni e il comportamento atteso della nuova accettazione. Stabilite se una versione aggiornata richiede una nuova risposta. Fornite al personale di supporto un contatto per le domande sulle condizioni e un contatto distinto per i problemi di accesso. Fatelo prima di caricare il PDF, affinché una modifica dell’autenticazione non diventi un esercizio improvvisato di redazione delle regole.

2. Creare l’accordo e verificarne la presentazione

Usate Conditional Access > Terms of use > New terms. Caricate il PDF definitivo, scegliete la lingua e il titolo mostrato agli utenti e configurate Require users to expand the terms of use quando l’esperienza approvata richiede l’apertura del documento prima dell’accettazione. Aggiungete le varianti linguistiche approvate ed esaminate ciò che vede un utente previsto. Registrate l’ID dell’accordo e quale PDF è stato caricato per ogni lingua.

Decidete le opzioni di scadenza e per dispositivo in base al caso d’uso anziché abilitarle automaticamente. In particolare, Learn esclude gli utenti B2B dal supporto delle condizioni di utilizzo per dispositivo. Per un progetto pilota destinato a utenti esterni, mantenete distinto il requisito ordinario dell’accordo da questa opzione per dispositivo e validate il percorso effettivo di collaborazione.

3. Collegare l’accordo al controllo di concessione di Conditional Access previsto

Il criterio di esempio di Microsoft seleziona le condizioni create in Access controls > Grant > Grant access, inizia in Report-only e passa a On dopo la valutazione dell’impatto. Il suo esempio è rivolto a Microsoft Admin Portals; adattate l’assegnazione delle risorse al vostro scenario approvato anziché copiare quella destinazione in un progetto pilota per uno spazio di lavoro non correlato.

Iniziate con il gruppo pilota e la risorsa previsti. Preservate l’accesso di ripristino di emergenza e documentate le esclusioni. Learn avverte inoltre che gli account di servizio non possono soddisfare questo requisito di accettazione interattiva; identificate tali dipendenze prima di abilitarne l’applicazione. Esaminate prima l’impatto in Report-only, poi abilitate il progetto pilota per i test interattivi. Una valutazione dell’impatto e un test dell’accettazione obbligatoria rispondono a domande diverse, quindi conservate entrambi.

4. Testare accettazione, rifiuto e percorso di ripristino escluso

Usate identità di test rappresentative della popolazione prevista. Per il percorso di accettazione, entrate nella risorsa di destinazione tramite il normale percorso di accesso, controllate il PDF e la lingua mostrati, espandetelo se richiesto, accettatelo e verificate l’accesso alla risorsa. Per il percorso di rifiuto, usate un’identità senza accettazione precedente e verificate che il rifiuto impedisca l’accesso. Mantenete questi risultati come esiti attesi dei test finché non li avete osservati e registrati.

Controllate i record di accettazione rispetto all’utente di test e all’ID del file. Verificate anche che l’account di ripristino previsto rimanga fuori dal criterio pilota. Se un utente previsto non riceve alcuna richiesta, indagate sull’accettazione esistente, sullo stato della sessione, sulle assegnazioni, sulle esclusioni e sulla risorsa selezionata nel criterio. Non concludete subito che l’accordo non funzioni o che l’utente sia coperto correttamente.

5. Mantenere le versioni e testare quando avviene la nuova accettazione

Esaminate Edit terms, aggiornate il PDF per la lingua pertinente e prendete una decisione esplicita su Require reaccept. Preservate le evidenze precedenti prima di modificare il documento, poi verificate il record di risposta per il nuovo file. Trattate i PDF localizzati come versioni gestite dello stesso messaggio approvato; la revisione di un documento inglese deve comportare una revisione delle altre varianti linguistiche.

Require reaccept non interrompe immediatamente una sessione attiva. Learn afferma che le sessioni esistenti devono scadere prima che venga presentato il nuovo requisito di accettazione. Pianificate la verifica in funzione del successivo accesso o della valutazione di sessione pertinente e registrate quel contesto insieme alla richiesta osservata. La guida ai controlli di sessione e alla frequenza di accesso spiega perché un criterio di accesso e il momento in cui viene valutata una sessione devono essere considerati insieme. Non promettete una scadenza immediata di nuova accettazione per tutto il tenant solo perché è stato aggiornato un PDF.

6. Registrare le evidenze e trasferire la manutenzione

Conservate nella documentazione della modifica il riferimento al testo approvato, gli identificatori dell’accordo e del criterio, l’ambito, le esclusioni, le versioni PDF e i risultati osservati del progetto pilota. Registrate gli errori e i percorsi non risolti oltre ai successi. Ampliate il criterio solo dopo che i responsabili hanno accettato le evidenze e le implicazioni per il supporto. Organizzate una revisione quando cambiano il documento, la popolazione dell’applicazione o il modello di collaborazione; il solo inventario degli accordi non rivelerà le deviazioni in queste relazioni.

Come EtcSec rileva questa configurazione

Il detector AZ_NO_TERMS_OF_USE di etc-collector legge AzureTermsOfUseProbed e AzureTermsOfUseCount. La sua implementazione Detect() ha tre rami:

Count 1 è il conteggio del rilievo; non è il numero di utenti che non hanno accettato. Il ramo non sondato non è né un risultato di assenza né un verdetto di conformità. Una raccolta fallita deve rimanere visibile finché non può essere approfondita.

Questo controllo stabilisce solo l’esistenza degli accordi. Non convalida il collegamento a Conditional Access, lo stato abilitato del criterio, i destinatari, le eccezioni, la qualità del PDF, la copertura linguistica o le accettazioni degli utenti. Creare un accordo inutilizzato può eliminare questo rilievo specifico senza imporre l’esigenza aziendale. Abbinate il risultato del collector all’esame del criterio e alle evidenze di accettazione precedenti e conservate una decisione esplicita di adeguatezza quando le condizioni di utilizzo non sono necessarie per il tenant.