Dichiarazione di privacy Entra: un URL del tenant utilizzabile

Cosa offre una dichiarazione di privacy Entra

Una dichiarazione di privacy Entra è un collegamento, a livello di organizzazione, al documento che spiega come la vostra organizzazione tratta i dati delle persone. Configuratela insieme a un contatto per la privacy mantenuto aggiornato, affinché dipendenti e ospiti esterni possano trovare le informazioni destinate a loro. Il risultato utile è un documento leggibile e pertinente e un responsabile raggiungibile, anziché un campo compilato che nessuno ha verificato.

La guida Microsoft alla configurazione delle informazioni sulla privacy riguarda sia il contatto globale per la privacy sia l’URL della dichiarazione. Ne descrive l’utilizzo per dipendenti interni e ospiti esterni, compresa l’esperienza di invito B2B. Quando non viene fornito nessuno dei due, Learn illustra un messaggio Review Permissions che indica che l’organizzazione non ha fornito collegamenti da consultare. Considerate quella presentazione un motivo per esaminare il percorso effettivo dell’ospite, senza dedurne che gli inviti siano bloccati.

Decidete chi è responsabile del documento prima di modificare il tenant. Un partner che riceve un invito potrebbe aver bisogno di informazioni diverse dal manuale interno dei dipendenti. Chiedete ai responsabili delle revisioni legali e della privacy di confermare l’ambito e la lingua del documento. L’assenza di un URL nel tenant è un’osservazione sulla configurazione; non dimostra una violazione giuridica universale né determina quali obblighi si applichino alla vostra organizzazione.

Come le informazioni sulla privacy differiscono dall’accettazione di un documento

La risorsa Graph privacyProfile distingue contactEmail da statementUrl. Entrambe le proprietà sono facoltative nello schema. L’indirizzo email identifica il contatto della dichiarazione di privacy, mentre l’URL rimanda alla dichiarazione dell’organizzazione. Un campo API facoltativo può comunque essere utile per i vostri requisiti operativi; il suo carattere facoltativo non stabilisce se la vostra organizzazione abbia bisogno di quelle informazioni.

Learn definisce un URL della dichiarazione che inizia con HTTP o HTTPS. Per una nuova distribuzione, scegliete una destinazione HTTPS stabile e verificatela dai contesti delle persone che la leggeranno. Un documento disponibile solo dopo l’autenticazione di un dipendente potrebbe non essere adatto a un collaboratore esterno appena invitato. Non presumete che la capacità di un amministratore di aprire la pagina dimostri che un ospite possa raggiungerla.

Pubblicare questo collegamento fornisce informazioni. Non configura un controllo di concessione Conditional Access che richieda l’accettazione, non crea una registrazione di accettazione né dimostra che qualcuno abbia letto il testo. La guida alle condizioni di utilizzo Entra e all’accettazione con Conditional Access tratta quel requisito separato: un accordo approvato e un criterio che lo imponga devono essere collegati quando l’accettazione è la condizione di accesso desiderata.

Rilevamento: verificare configurazione, destinazione e presentazione agli ospiti

Leggere il profilo dell’organizzazione con gli accessi Graph appropriati

Confermate innanzitutto il tenant che state esaminando. Nell’interfaccia di amministrazione Entra, controllate Entra ID > Overview > Properties, inclusi il contatto globale per la privacy e l’URL della dichiarazione. Conservate l’orario dell’osservazione e i valori esatti per confrontare il portale con una lettura API indipendente.

La documentazione Microsoft List organization supporta GET /organization e il parametro di query $select. Utilizzate questa richiesta per recuperare il profilo:

GET https://graph.microsoft.com/v1.0/organization?$select=privacyProfile
Authorization: Bearer {token}

È un modello di richiesta per il vostro client autorizzato, non una query eseguita sul tenant di un cliente per questo articolo. Esaminate sia privacyProfile.contactEmail sia privacyProfile.statementUrl nell’organizzazione restituita. Conservate la risposta e gli errori di raccolta nel fascicolo di revisione; non sostituite un risultato API con una schermata del portale quando indagate sul comportamento della raccolta.

La documentazione per la lettura dell’organizzazione elenca Organization.Read.All per l’accesso delle applicazioni e lo supporta per l’accesso delegato con account aziendali o dell’istituto di istruzione. Avverte espressamente che User.Read espone solo id, displayName e verifiedDomains, mentre le altre proprietà restituiscono null. Utilizzate almeno Organization.Read.All per leggere il profilo sulla privacy e controllate i requisiti dei ruoli supportati per un client delegato. Una risposta riuscita con visibilità insufficiente sulle proprietà non deve diventare una prova di assenza.

Verificare la destinazione indipendentemente dalla query Graph

Una query dell’organizzazione completata e un documento sulla privacy disponibile sono osservazioni diverse. Registrate l’URL esatto restituito, quindi inviate una richiesta HTTP indipendente a quella destinazione. Per una dichiarazione pubblica autorizzata, una richiesta diagnostica può avere questa forma:

curl --location --silent --show-error --output privacy-statement.html --write-out 'HTTP %{http_code}\nFinal URL %{url_effective}\n' 'https://example.org/privacy'

Sostituite l’esempio con la destinazione approvata. Esaminate la risposta finale e il corpo salvato, senza accettare il solo codice di stato. Una risposta riuscita potrebbe contenere una pagina iniziale generica, un modulo di accesso o un documento non pertinente. Controllate i reindirizzamenti, l’organizzazione indicata nel testo e se la pagina spiega il trattamento dei dati previsto. Esaminatela anche in un browser, inclusi navigazione e leggibilità.

Verificate l’accesso da un contesto di dipendente e da un contesto esterno rappresentativo del flusso di invito. Se la destinazione richiede autenticazione, stabilite se il requisito è intenzionale e praticabile prima che l’ospite si unisca all’organizzazione. Registrate una pagina non disponibile, un reindirizzamento inatteso, un documento obsoleto o una lingua inadatta come un problema della destinazione, anche quando il campo del tenant è compilato. Confermate separatamente che il contatto indicato sia monitorato e assegnato a un responsabile.

Eseguire un invito B2B rappresentativo

Utilizzate un invito di prova approvato e osservate l’esperienza effettiva dell’ospite. Verificate l’organizzazione visualizzata, le informazioni sulla privacy offerte, la destinazione raggiunta seguendo il collegamento e il contatto presentato. Registrate il contesto dell’ospite e il percorso utilizzato, perché un ospite esistente che torna a un’applicazione non riproduce l’esperienza di un nuovo invito.

La revisione di Conditional Access per gli ospiti e della collaborazione esterna aiuta a definire la popolazione esterna prevista e le relative impostazioni di accesso. Conservate quella revisione degli accessi insieme a questo controllo delle informazioni. Un collegamento sulla privacy funzionante non dimostra che gli inviti, le assegnazioni dei criteri, gli accessi alle applicazioni o le impostazioni del ciclo di vita degli ospiti soddisfino i vostri requisiti.

Correzione: pubblicare e mantenere un URL del tenant utilizzabile (Remediation)

1. Assegnare i responsabili del documento e del contatto

Identificate il revisore responsabile della dichiarazione e il team incaricato di rispondere alle domande sulla privacy. Concordate i destinatari previsti tra dipendenti e ospiti, le lingue e il luogo di pubblicazione. Fornite all’amministratore del tenant valori approvati da inserire. Non lasciate che l’amministratore inventi il testo sulla privacy solo per eliminare un rilievo di audit.

Utilizzate un indirizzo di contatto con un processo esplicito di passaggio di consegne quando cambia il personale. Decidete chi controlla i messaggi in arrivo e chi gestisce un collegamento al documento non funzionante. Registrate dove viene mantenuto il documento approvato e come vengono revisionate le modifiche al suo ambito. Sono decisioni operative da prendere localmente, non conclusioni giuridiche ricavate dall’impostazione del tenant.

2. Validare la destinazione prima di configurare Entra

Pubblicate la dichiarazione approvata a un URL stabile. Verificate che i lettori interni ed esterni previsti possano raggiungere il contenuto pertinente e che le lingue supportate restino accessibili da quella destinazione. Mantenete la pagina comprensibile senza richiedere a un ospite di navigare in una raccolta di documenti riservata ai dipendenti.

Registrate la prova della destinazione separatamente dalla modifica del tenant. Se il sistema di pubblicazione reindirizza il collegamento, esaminate la destinazione finale e assicuratevi che i reindirizzamenti futuri rimangano sotto il controllo del responsabile del documento. Un URL permanente dell’organizzazione è più facile da mantenere rispetto a un collegamento legato a una campagna temporanea, a uno spazio personale o a un token di condivisione in scadenza.

3. Inserire i valori in Properties

Seguite la procedura Properties di Learn: accedete almeno con il ruolo Billing Administrator, aprite Entra ID > Overview > Properties, inserite Global privacy contact e Privacy statement URL, quindi selezionate Accept come documentato. Quell’azione nel portale salva le informazioni dell’organizzazione; non rappresenta l’accettazione del documento da parte di un ospite.

Se il processo di modifica approvato utilizza Graph, Update organization documenta PATCH /organization/{id} con Organization.ReadWrite.All per l’accesso delegato con account aziendali o dell’istituto di istruzione e per l’accesso delle applicazioni. Utilizzate l’identificativo verificato dell’organizzazione ed esaminate i requisiti dei ruoli delegati prima di scrivere. Inviate i valori previsti del profilo senza modificare altre proprietà dell’organizzazione:

PATCH https://graph.microsoft.com/v1.0/organization/{organization-id}
Authorization: Bearer {token}
Content-Type: application/json

{
  "privacyProfile": {
    "contactEmail": "[email protected]",
    "statementUrl": "https://example.org/privacy"
  }
}

L’esempio è un modello di richiesta documentato con valori segnaposto, non una modifica eseguita su un tenant. Tenete le autorizzazioni di scrittura separate dal client di revisione in sola lettura. Una risposta di aggiornamento riuscita è un punto di partenza per la verifica, non la prova finale che le persone possano utilizzare il documento.

4. Rileggere il profilo e ripetere la prova dell’ospite

Ripetete il GET dell’organizzazione con la selezione indicata e confrontate entrambe le proprietà con i valori approvati. Ricontrollate la destinazione in modo indipendente, quindi ripetete la revisione dell’invito rappresentativo. Conservate i fallimenti e le osservazioni riuscite. Se il profilo differisce, indagate sul contesto del tenant e sul risultato dell’aggiornamento prima di ripetere una scrittura.

Se le informazioni sono configurate ma il percorso dell’ospite verificato non le mostra come previsto, conservate le prove API e la presentazione osservata come fatti separati. Indagate su quel percorso anziché sostituire ripetutamente un URL corretto. Evitate di aggiungere un requisito di condizioni di utilizzo come rimedio improvvisato alla mancanza di informazioni sulla privacy; l’accettazione richiede una finalità e un ambito approvati propri.

5. Mantenere lingue, collegamenti e responsabilità

Revisionate la dichiarazione quando cambiano il trattamento dei dati, l’hosting del documento, le popolazioni di ospiti o la responsabilità del contatto. Aggiornate le traduzioni insieme al documento sorgente approvato. Dopo una migrazione dell’hosting, ripetete i controlli HTTP e nel browser anche se l’URL del tenant rimane invariato. Dopo un passaggio di consegne del contatto, verificate che l’indirizzo raggiunga ancora il team responsabile.

Conservate insieme i valori approvati, la rilettura Graph, i controlli della destinazione, le osservazioni degli ospiti e le decisioni dei responsabili. Questo consente di distinguere una deriva di configurazione da un’interruzione della pubblicazione o da una modifica dell’esperienza di invito. Definite una cadenza di revisione adatta alla vostra organizzazione anziché considerare il primo salvataggio riuscito una prova permanente.

Come EtcSec rileva questa configurazione

Il rilevatore AZ_NO_PRIVACY_STATEMENT di etc-collector legge AzurePrivacyStatementProbed e AzurePrivacyStatementURL. La sua implementazione Detect() ha tre rami:

Count 1 è il numero di rilievi, non il numero di ospiti interessati. Non interrogato non significa assente e il ramo Info non è un verdetto di conformità. Risolvete i problemi di raccolta prima di trarre una conclusione sulla configurazione.

Il provider invia GET /organization?$select=privacyProfile, legge statementUrl della prima organizzazione e restituisce una stringa vuota senza errore quando l’elenco delle organizzazioni è vuoto o il profilo è assente. Gli errori di richiesta e di decodifica vengono restituiti separatamente. Un inventario inaspettatamente vuoto merita quindi un’indagine insieme alle autorizzazioni e al contesto del tenant.

Né il provider né questo rilevatore rimuovono gli spazi dalla stringa: una stringa composta da spazi non è vuota e supera il confronto. Nessuno dei due richiede l’URL della dichiarazione, verifica il contatto o esamina il contenuto o le lingue del documento. Il provider non raccoglie contactEmail per questo controllo. Un URL non vuoto può eliminare questo rilievo mentre la destinazione è indisponibile o inadatta. Abbinate questo risultato limitato di configurazione alle prove indipendenti della destinazione e dell’invito descritte sopra e conservate la decisione del responsabile sull’idoneità del documento.