Conditions d’utilisation Entra : acceptation via Conditional Access

Ce que les conditions d’utilisation Entra imposent réellement

Les conditions d’utilisation Entra présentent un document lors d’une connexion interactive et peuvent faire de son acceptation une condition d’accès. La question utile est de savoir si les personnes visées doivent accepter le document approuvé avant d’accéder à l’application prévue. Trouver un PDF dans le tenant ne répond qu’à une partie de cette question.

Partez d’un besoin métier : qui doit reconnaître quelles règles, pour quelles ressources, et qui est responsable du texte ? Faites approuver le document par les responsables métier et juridiques compétents avant de configurer son application. L’absence d’un accord est un signal de configuration à examiner, pas la preuve d’une violation réglementaire universelle. Certains tenants peuvent n’avoir aucun cas d’usage justifié pour cette fonctionnalité ; consignez cette décision plutôt que de créer un accord vide pour faire disparaître un constat.

Un pilote concret pourrait concerner un espace de travail partenaire dont le responsable souhaite que les collaborateurs externes reconnaissent les règles de traitement des données. Définissez explicitement la population et l’application. Ne supposez pas que chaque voie de partage externe crée un compte invité Entra ou suit le même parcours de connexion. Utilisez la revue de Conditional Access pour les invités et de la collaboration externe pour cadrer cette population et ses exclusions avant d’ajouter l’acceptation du document.

Le déploiement doit fournir des preuves pour trois questions distinctes : l’accord existe-t-il, une stratégie qui l’impose l’exige-t-elle pour la population et la ressource choisies, et les réponses des utilisateurs montrent-elles que le document attendu a été accepté ou refusé ? Gardez ces réponses séparées dans le dossier de changement.

Comment l’accord s’articule avec Conditional Access

Le guide de configuration des conditions d’utilisation de Microsoft exige une licence Entra ID P1 et un PDF. Il indique Security Reader comme rôle minimal pour lire la configuration et Conditional Access Administrator pour la créer ou la modifier. Confirmez l’abonnement et l’attribution du rôle à l’administrateur avant de planifier le pilote.

L’accord contient les paramètres du document ; un contrôle d’octroi Conditional Access le relie aux décisions d’accès. Les choix de langues et de versions font également partie de la conception. Un accord qui existe sans être rattaché à la stratégie prévue peut satisfaire un contrôle d’existence tout en laissant le besoin métier insatisfait.

La ressource agreement de Graph expose un identifiant, des exigences de consultation et par appareil, un calendrier d’expiration et une durée de réacceptation par utilisateur. Sa relation file identifie le PDF par défaut ; files est documentée comme étant en cours de dépréciation au profit de file. La relation acceptances est une collection distincte de réponses des utilisateurs.

Utilisez ces distinctions pour planifier les preuves. Conservez ensemble l’ID de l’accord et la version approuvée du PDF, puis consignez la stratégie qui exige cet accord. Un nom d’affichage est pratique pour les personnes, mais l’identifiant est une clé de rapprochement plus sûre pour les enregistrements de configuration et de réponse. Désignez un responsable de la maintenance du document et de ses traductions, ainsi qu’un responsable du périmètre de la stratégie. Si l’un change, réexaminez l’autre côté de cette relation.

Détection : vérifier séparément l’existence, le rattachement et les réponses

Inventorier les accords sans confondre échec de lecture et absence

Dans le centre d’administration Entra, ouvrez Entra ID > Conditional Access > Terms of use. Identifiez l’accord prévu pour le scénario métier, les langues du document et l’historique des versions. Si la page est vide, vérifiez que vous examinez le bon tenant avec un rôle de lecture approprié avant de consigner une absence.

Pour un inventaire indépendant par API, Microsoft documente cette requête dans List agreements :

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

Il s’agit d’un modèle de requête documenté, pas d’une requête exécutée sur un tenant client pour cet article. La page indique la permission déléguée Agreement.Read.All pour les comptes professionnels ou scolaires, avec Security Reader comme rôle pris en charge le moins privilégié. Elle indique que les permissions applicatives ne sont pas prises en charge pour cette opération. Vérifiez le modèle de permissions actuel du client utilisé plutôt que de supposer qu’un jeton applicatif et un jeton délégué offrent une couverture équivalente.

Traitez une erreur d’autorisation, une collecte interrompue ou une réponse illisible comme une observation non résolue. Seul un inventaire réussi et complet permet de conclure qu’aucun accord n’a été renvoyé. Conservez le contexte du tenant, l’heure de collecte et les éventuelles erreurs avec le résultat.

Examiner la stratégie qui doit exiger l’accord

Ouvrez la stratégie Conditional Access concernée et examinez son état, les utilisateurs ou groupes inclus, les exclusions, les ressources cibles et les contrôles d’octroi. Confirmez que l’accord prévu est sélectionné sous Grant access, avec l’exigence Require terms of use. Vérifiez la combinaison des contrôles d’octroi afin que la décision d’accès prévue exige réellement l’acceptation.

Un nom de stratégie qui mentionne les conditions d’utilisation ne constitue pas une preuve suffisante. La configuration Report-only sert à examiner l’impact, mais le test d’application doit utiliser une stratégie pilote activée. Suivez un utilisateur de test prévu à travers les affectations et exclusions, puis testez la connexion à la ressource. Si l’inventaire contient des accords mais qu’aucune stratégie prévue ne les sélectionne, consignez un défaut de rattachement séparément de l’absence d’accord.

Examiner les preuves d’acceptation de la version prévue

Le portail expose les réponses d’acceptation et de refus ainsi que l’historique des versions. Pour les preuves par API, List acceptances documente :

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

Les objets renvoyés sont des enregistrements agreementAcceptance, généralement appelés acceptations d’accords. La référence de la ressource décrit agreementId, agreementFileId, userId, state, recordedDateTime et expirationDateTime. Les états de réponse documentés sont accepted et declined. Rapprochez l’utilisateur, l’accord et le fichier au lieu de considérer toute acceptation historique comme une preuve pour le document actuel.

Pour cet endpoint limité à un accord, l’opération de liste documente la permission déléguée AgreementAcceptance.Read et la permission supérieure AgreementAcceptance.Read.All, avec Security Reader comme rôle pris en charge le moins privilégié. Elle indique que les permissions applicatives ne sont pas prises en charge. Traitez les exports d’acceptation comme des données utilisateur, limitez leur accès aux personnes chargées de la revue qui en ont besoin et suivez les règles de conservation de votre organisation. L’export sert à étayer le pilote, pas à créer une copie sans restriction de l’activité des utilisateurs.

Remédiation : déployer un accord approuvé avec un pilote ciblé (Remediation)

1. Approuver le texte et définir l’exigence d’acceptation

Consignez le responsable de la ressource, le responsable du document, les utilisateurs visés, les langues nécessaires, les exceptions et le comportement de réacceptation attendu. Déterminez si une version mise à jour exige une nouvelle réponse. Donnez au support un contact pour les questions sur les conditions et un contact distinct pour les problèmes de connexion. Faites-le avant de téléverser le PDF, afin qu’un changement d’authentification ne devienne pas un exercice improvisé de rédaction de règles.

2. Créer l’accord et vérifier sa présentation

Utilisez Conditional Access > Terms of use > New terms. Téléversez le PDF finalisé, choisissez sa langue et le titre présenté aux utilisateurs, puis configurez Require users to expand the terms of use lorsque l’expérience approuvée exige d’ouvrir le document avant l’acceptation. Ajoutez les variantes linguistiques approuvées et examinez ce qu’un utilisateur visé voit. Consignez l’ID de l’accord et le PDF téléversé pour chaque langue.

Décidez des options d’expiration et par appareil à partir du cas d’usage plutôt que de les activer automatiquement. En particulier, Learn exclut les utilisateurs B2B de la prise en charge des conditions d’utilisation par appareil. Pour un pilote destiné aux utilisateurs externes, distinguez l’exigence ordinaire d’accord de cette option par appareil et validez le parcours réel de collaboration.

3. Rattacher l’accord au contrôle d’octroi Conditional Access prévu

L’exemple de stratégie de Microsoft sélectionne les conditions créées sous Access controls > Grant > Grant access, commence en Report-only, puis passe à On après examen de l’impact. Son exemple cible Microsoft Admin Portals ; adaptez l’affectation des ressources à votre scénario approuvé plutôt que de recopier cette cible dans un pilote d’espace de travail sans rapport.

Commencez avec le groupe pilote et la ressource prévus. Préservez l’accès de récupération d’urgence et documentez les exclusions. Learn avertit également que les comptes de service ne peuvent pas satisfaire cette exigence d’acceptation interactive ; identifiez ces dépendances avant d’activer son application. Examinez d’abord l’impact en Report-only, puis activez le pilote pour les tests interactifs. Une revue d’impact et un test d’acceptation imposée répondent à des questions différentes : conservez les deux.

4. Tester l’acceptation, le refus et le parcours de récupération exclu

Utilisez des identités de test représentatives de la population visée. Pour le parcours d’acceptation, entrez dans la ressource cible par son parcours normal de connexion, vérifiez le PDF et la langue affichés, développez-le si nécessaire, acceptez-le et vérifiez l’accès à la ressource. Pour le parcours de refus, utilisez une identité sans acceptation préalable et vérifiez que le refus empêche l’accès. Gardez ces résultats comme des attentes de test tant que vous ne les avez pas observés et consignés.

Vérifiez les enregistrements d’acceptation par rapport à l’utilisateur de test et à l’ID du fichier. Vérifiez aussi que le compte de récupération prévu reste hors de la stratégie pilote. Si un utilisateur visé ne reçoit aucune invite, examinez l’acceptation existante, l’état de session, les affectations, les exclusions et la ressource sélectionnée dans la stratégie. Ne concluez pas immédiatement que l’accord est défectueux ou que l’utilisateur est correctement couvert.

5. Maintenir les versions et tester le moment de la réacceptation

Examinez Edit terms, mettez à jour le PDF pour la langue concernée et prenez une décision explicite concernant Require reaccept. Préservez les preuves précédentes avant de modifier le document, puis vérifiez l’enregistrement de réponse pour le nouveau fichier. Traitez les PDF localisés comme des versions gérées d’un même message approuvé ; la révision du document anglais doit déclencher une revue de ses autres variantes linguistiques.

Require reaccept n’interrompt pas instantanément une session active. Learn indique que les sessions existantes doivent expirer avant que la nouvelle exigence d’acceptation soit présentée. Planifiez la vérification autour de la prochaine connexion ou évaluation de session pertinente, et consignez ce contexte avec l’invite observée. Le guide des contrôles de session et de la fréquence de connexion explique pourquoi il faut considérer ensemble une stratégie d’accès et le moment où une session est évaluée. Ne promettez pas une échéance immédiate de réacceptation pour tout le tenant au seul motif qu’un PDF a été mis à jour.

6. Consigner les preuves et transmettre la maintenance

Conservez dans le dossier de changement la référence du texte approuvé, les identifiants de l’accord et de la stratégie, le périmètre, les exclusions, les versions PDF et les résultats observés du pilote. Consignez les échecs et les parcours non résolus autant que les réussites. Étendez la stratégie seulement après que les responsables ont accepté les preuves et les conséquences pour le support. Prévoyez une revue lorsque le document, la population de l’application ou le modèle de collaboration change ; le seul inventaire des accords ne révélera pas la dérive de ces relations.

Comment EtcSec détecte cette configuration

Le détecteur AZ_NO_TERMS_OF_USE d’etc-collector lit AzureTermsOfUseProbed et AzureTermsOfUseCount. Son implémentation Detect() comporte trois branches :

Count 1 est le nombre associé au constat ; ce n’est pas un nombre d’utilisateurs n’ayant pas accepté. La branche non sondée n’est ni un résultat d’absence, ni un verdict de conformité. Une collecte échouée doit rester visible jusqu’à ce qu’elle puisse être examinée.

Ce contrôle établit uniquement l’existence d’un accord. Il ne valide ni le rattachement à Conditional Access, ni l’état activé de la stratégie, le ciblage, les exceptions, la qualité du PDF, la couverture linguistique ou les acceptations des utilisateurs. Créer un accord inutilisé peut supprimer ce constat particulier sans imposer le besoin métier. Associez le résultat du collector à l’examen de la stratégie et aux preuves d’acceptation ci-dessus, et conservez une décision explicite d’adéquation lorsque les conditions d’utilisation sont inutiles pour le tenant.