Déclaration de confidentialité Entra : URL et invités

Ce qu’apporte une déclaration de confidentialité Entra

Une déclaration de confidentialité Entra est un lien, au niveau de l’organisation, vers le document qui explique comment votre organisation traite les données des personnes. Configurez-la avec un contact chargé de la confidentialité et tenu à jour, afin que les employés et les invités externes trouvent les informations qui leur sont destinées. Le résultat utile est un document lisible et pertinent, ainsi qu’un responsable joignable, plutôt qu’un champ rempli que personne n’a testé.

Le guide Microsoft de configuration des informations de confidentialité couvre à la fois le contact global chargé de la confidentialité et l’URL de la déclaration. Il décrit leur utilisation pour les employés internes et les invités externes, notamment dans le parcours d’invitation B2B. Lorsque ni l’un ni l’autre n’est renseigné, Learn illustre un message Review Permissions indiquant que l’organisation n’a pas fourni de liens à consulter. Considérez cet affichage comme une raison d’inspecter le parcours réel de l’invité, sans en déduire que les invitations sont bloquées.

Décidez qui est responsable du document avant de modifier le tenant. Un partenaire qui reçoit une invitation peut avoir besoin d’informations différentes du manuel interne destiné aux employés. Demandez aux responsables des revues juridiques et de confidentialité de confirmer le périmètre et la langue du document. L’absence d’URL dans le tenant est un constat de configuration ; elle ne démontre pas une violation juridique universelle et ne détermine pas les obligations applicables à votre organisation.

En quoi les informations de confidentialité diffèrent de l’acceptation d’un document

La ressource Graph privacyProfile distingue contactEmail de statementUrl. Les deux propriétés sont optionnelles dans le schéma. L’adresse électronique désigne le contact de la déclaration de confidentialité, tandis que l’URL pointe vers la déclaration de l’organisation. Un champ API optionnel peut néanmoins répondre à vos besoins opérationnels ; son caractère optionnel ne détermine pas si votre organisation a besoin de ces informations.

Learn définit une URL de déclaration commençant par HTTP ou HTTPS. Pour un nouveau déploiement, choisissez une destination HTTPS stable et testez-la auprès des populations qui la consulteront. Un document accessible uniquement après authentification d’un employé peut ne pas convenir à un collaborateur externe nouvellement invité. Ne supposez pas que la capacité d’un administrateur à ouvrir la page prouve qu’un invité peut y accéder.

Publier ce lien fournit des informations. Cela ne configure pas un contrôle d’octroi Conditional Access exigeant une acceptation, ne crée pas de preuve d’acceptation et ne démontre pas qu’une personne a lu le texte. Le guide des conditions d’utilisation Entra et de leur acceptation avec Conditional Access traite de cette exigence distincte : un accord approuvé et une stratégie qui l’impose doivent être reliés lorsque l’acceptation est la condition d’accès recherchée.

Détection : vérifier la configuration, la destination et l’affichage pour les invités

Lire le profil de l’organisation avec les accès Graph appropriés

Confirmez d’abord le tenant que vous examinez. Dans le centre d’administration Entra, inspectez Entra ID > Overview > Properties, notamment le contact global chargé de la confidentialité et l’URL de la déclaration. Conservez l’heure du constat et les valeurs exactes pour comparer le portail à une lecture indépendante par API.

La documentation Microsoft List organization prend en charge GET /organization et le paramètre de requête $select. Utilisez cette requête pour récupérer le profil :

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

Il s’agit d’un modèle de requête pour votre client autorisé, et non d’une requête exécutée sur le tenant d’un client pour cet article. Inspectez à la fois privacyProfile.contactEmail et privacyProfile.statementUrl dans l’organisation renvoyée. Conservez la réponse et les erreurs de collecte dans le dossier de revue ; ne remplacez pas un résultat API par une capture du portail lorsque vous analysez le comportement de la collecte.

La documentation de lecture de l’organisation indique Organization.Read.All pour les accès applicatifs et le prend en charge pour les accès délégués avec un compte professionnel ou scolaire. Elle avertit expressément que User.Read n’expose que id, displayName et verifiedDomains, les autres propriétés renvoyant null. Utilisez au minimum Organization.Read.All pour lire le profil de confidentialité et vérifiez les exigences de rôle prises en charge pour un client délégué. Une réponse réussie avec une visibilité insuffisante sur les propriétés ne doit pas devenir une preuve d’absence.

Tester la destination indépendamment de la collecte Graph

Une requête d’organisation terminée et un document de confidentialité disponible sont deux constats différents. Relevez l’URL exacte renvoyée, puis envoyez une requête HTTP indépendante vers cette destination. Pour une déclaration publique autorisée, une requête de diagnostic peut prendre cette forme :

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

Remplacez l’exemple par la destination approuvée. Examinez la réponse finale et le corps enregistré, sans vous contenter du code de statut. Une réponse réussie peut contenir une page d’accueil générique, un formulaire de connexion ou un document sans rapport. Vérifiez les redirections, l’organisation nommée dans le texte et si la page explique le traitement des données prévu. Inspectez-la également dans un navigateur, notamment sa navigation et sa lisibilité.

Testez l’accès dans un contexte employé et un contexte externe représentatif du parcours d’invitation. Si la destination exige une authentification, déterminez si cette exigence est intentionnelle et utilisable avant que l’invité ne rejoigne l’organisation. Consignez une page indisponible, une redirection inattendue, un document obsolète ou une langue inadaptée comme un problème de destination, même si le champ du tenant est renseigné. Confirmez séparément que le contact indiqué est suivi et attribué à un responsable.

Effectuer une invitation B2B représentative

Utilisez une invitation de test approuvée et observez l’expérience réelle de l’invité. Vérifiez l’organisation affichée, les informations de confidentialité proposées, la destination atteinte en suivant le lien et le contact présenté. Consignez le contexte de l’invité et le parcours utilisé : un invité existant qui revient dans une application ne reproduit pas une nouvelle invitation.

La revue de Conditional Access pour les invités et de la collaboration externe aide à définir la population externe visée et ses paramètres d’accès. Conservez cette revue des accès avec ce contrôle des informations. Un lien de confidentialité fonctionnel ne démontre pas que les invitations, les affectations de stratégies, les accès aux applications ou les paramètres de cycle de vie des invités répondent à vos exigences.

Constat	Éléments à conserver	Ce qu’il établit
Lecture Graph autorisée	Contexte du tenant, réponse, heure, erreurs	Valeurs du profil de confidentialité collectées
Requête indépendante vers la destination	Statut, URL finale, corps examiné	Ce que la destination a renvoyé dans ce contexte de test
Revue dans le navigateur et du parcours d’invitation	Contexte, informations affichées, navigation observée	Présentation et facilité d’utilisation pour le parcours testé
Responsabilité du contact et du document	Responsables et décision de maintenance	Qui traitera les questions et les modifications

Remédiation : publier et maintenir une URL de tenant utilisable (Remediation)

1. Désigner les responsables du document et du contact

Identifiez le responsable de la revue de la déclaration et l’équipe chargée de répondre aux questions de confidentialité. Accordez-vous sur les publics employés et invités visés, les langues et l’emplacement de publication. Fournissez à l’administrateur du tenant des valeurs approuvées à saisir. Ne laissez pas l’administrateur inventer le texte de confidentialité simplement pour supprimer un constat d’audit.

Utilisez une adresse de contact avec un processus de passation explicite lors des changements de personnel. Décidez qui vérifie les messages entrants et qui prend en charge un lien de document défectueux. Consignez où le document approuvé est maintenu et comment les modifications de son périmètre sont revues. Ce sont des décisions opérationnelles à prendre localement, et non des conclusions juridiques tirées du paramètre du tenant.

2. Valider la destination avant de configurer Entra

Publiez la déclaration approuvée à une URL stable. Vérifiez que les lecteurs internes et externes visés peuvent accéder au contenu pertinent et que les langues prises en charge restent accessibles depuis cette destination. Gardez une page compréhensible sans obliger un invité à parcourir une bibliothèque documentaire réservée aux employés.

Consignez le test de destination séparément de la modification du tenant. Si votre système de publication redirige le lien, examinez la cible finale et veillez à ce que les futures redirections restent sous le contrôle du responsable du document. Une URL permanente de l’organisation est plus facile à maintenir qu’un lien lié à une campagne temporaire, à un espace personnel ou à un jeton de partage qui expire.

3. Saisir les valeurs dans Properties

Suivez la procédure Properties de Learn : connectez-vous avec au minimum le rôle Billing Administrator, accédez à Entra ID > Overview > Properties, renseignez Global privacy contact et Privacy statement URL, puis sélectionnez Accept comme indiqué. Cette action dans le portail enregistre les informations de l’organisation ; elle ne constitue pas l’acceptation de votre document par un invité.

Si votre processus de changement approuvé utilise Graph, Update organization documente PATCH /organization/{id} avec Organization.ReadWrite.All pour les accès délégués avec un compte professionnel ou scolaire et les accès applicatifs. Utilisez l’identifiant d’organisation vérifié et inspectez les exigences de rôle délégué avant d’écrire. Envoyez les valeurs du profil prévues sans modifier les autres propriétés de l’organisation :

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’exemple est un modèle de requête documenté avec des valeurs de substitution, et non une modification exécutée sur un tenant. Séparez les permissions d’écriture de celles du client de revue en lecture seule. Une réponse de mise à jour réussie est le point de départ de la vérification, pas la preuve finale que les personnes peuvent utiliser le document.

4. Relire le profil et répéter le test invité

Répétez la requête GET d’organisation avec la sélection indiquée et comparez les deux propriétés aux valeurs approuvées. Revérifiez indépendamment la destination, puis répétez la revue de l’invitation représentative. Conservez les échecs aussi bien que les constats réussis. Si le profil diffère, analysez le contexte du tenant et le résultat de la mise à jour avant de répéter une écriture.

Si les informations sont configurées mais que le parcours invité testé ne les affiche pas comme prévu, conservez les preuves API et l’affichage observé comme deux faits distincts. Analysez ce parcours au lieu de remplacer plusieurs fois une URL correcte. Évitez d’ajouter une exigence de conditions d’utilisation comme correction improvisée à des informations de confidentialité manquantes ; l’acceptation doit avoir sa propre finalité et son propre périmètre approuvés.

5. Maintenir les langues, les liens et les responsabilités

Revoyez la déclaration lorsque le traitement des données, l’hébergement du document, les populations d’invités ou la responsabilité du contact changent. Mettez à jour les traductions avec le document source approuvé. Après une migration d’hébergement, répétez les contrôles HTTP et navigateur, même si l’URL du tenant reste inchangée. Après une passation du contact, vérifiez que l’adresse atteint toujours l’équipe responsable.

Conservez ensemble les valeurs approuvées, la relecture Graph, les contrôles de destination, les observations des invités et les décisions des responsables. Cela permet de distinguer une dérive de configuration d’une panne de publication ou d’un changement du parcours d’invitation. Définissez une fréquence de revue adaptée à votre organisation au lieu de traiter le premier enregistrement réussi comme une preuve permanente.

Comment EtcSec détecte cette configuration

Le détecteur AZ_NO_PRIVACY_STATEMENT d’etc-collector lit AzurePrivacyStatementProbed et AzurePrivacyStatementURL. Son implémentation Detect() comporte trois branches :

État collecté	Résultat réel du détecteur	Interprétation
`AzurePrivacyStatementProbed` est false	Constat Info, Count 1	Non déterminable : cet audit n’a pas sondé le profil ; inspectez `audit.warnings` et les prérequis de collecte.
Profil sondé et `AzurePrivacyStatementURL != ""`	`nil`, aucun constat	La chaîne collectée n’est pas vide.
Profil sondé et URL vide	Constat Low, Count 1	La collecte terminée n’a fourni aucune URL de déclaration.

Count 1 est le nombre de constats, pas le nombre d’invités affectés. Non sondé ne signifie pas absent, et la branche Info n’est pas un verdict de conformité. Résolvez les échecs de collecte avant de tirer une conclusion sur la configuration.

Le fournisseur exécute GET /organization?$select=privacyProfile, lit statementUrl dans la première organisation et renvoie une chaîne vide sans erreur lorsque la liste d’organisations est vide ou que le profil est absent. Les erreurs de requête et de décodage sont renvoyées séparément. Un inventaire vide inattendu mérite donc une investigation, conjointement avec les permissions et le contexte du tenant.

Ni le fournisseur ni ce détecteur ne suppriment les espaces de la chaîne : une chaîne composée d’espaces n’est pas vide et satisfait la comparaison. Aucun des deux n’interroge l’URL de la déclaration, ne vérifie le contact ni n’examine le contenu ou les langues du document. Le fournisseur ne collecte pas contactEmail pour ce contrôle. Une URL non vide peut supprimer ce constat alors que la destination est indisponible ou inadaptée. Associez ce résultat limité à la configuration aux tests indépendants de destination et d’invitation décrits plus haut, et conservez la décision du responsable sur l’adéquation du document.