06 · Gérer le risque avec ID Protection et déployer Global Secure Access

Version : 1.1 · Date : 2026-10-21 · Domaine 2 de l'examen : Implement authentication and access management (25 à 30 %)

En une phrase : Microsoft Entra ID Protection calcule le risque de chaque utilisateur, connexion et service principal, et Conditional Access en fait une décision (MFA, changement de mot de passe, blocage) ; Global Secure Access capture le trafic des appareils et des agences pour lui appliquer les mêmes décisions, vers Microsoft 365, les applications privées et Internet.

Ce que l'examen demande#

Compétences mesurées au 28/10/2026, guide d'étude SC-300 :

Déjà vu dans SC-500 : les bases d'ID Protection (sign-in risk, user risk, Require risk remediation, retrait des anciennes risk policies, rôles, licences) sont dans SC-500 § 11.1, et Private Access côté sécurité réseau dans SC-500 § 6. Ce chapitre les reprend au niveau administrateur d'identité : configuration, enquête, détails que l'examen SC-300 teste en plus.

1. Les bases#

1.1 Deux briques, un même point de décision#

1.2 Les licences, à connaître par cœur#

Certaines détections de risque viennent de produits Defender (Defender for Cloud Apps, Defender for Office 365, Defender for Endpoint) et demandent aussi leur licence : Microsoft 365 E5 couvre ces signaux.

1.3 Les rôles#

2. User risk et sign-in risk#

2.1 Ce que mesurent les deux risques#

2.2 Real-time ou offline#

Détections à reconnaître à l'examen (extrait de la liste officielle) :

Sans P2, les détections premium apparaissent sous le nom Additional risk detected (riskEventType = generic), sans détail.

2.3 Les niveaux de risque#

• Low, Medium, High : niveau de confiance de Microsoft qu'un tiers connaît les identifiants.
• Leaked credentials et Verified threat actor IP sont toujours High (preuve trouvée).
• Les détections et utilisateurs Low disparaissent automatiquement après 6 mois ; Medium et High restent jusqu'à remédiation ou Dismiss.
• Une connexion depuis un trusted named location abaisse le sign-in risk calculé.

2.4 Configurer les risk policies (dans Conditional Access)#

Les anciennes user risk policy et sign-in risk policy d'ID Protection sont retirées : tout passe par Conditional Access (voir SC-500 § 11.1 pour la date et les détails). Recommandation Microsoft, à adapter au niveau de tolérance :

Marche à suivre : Entra ID > Conditional Access > Create new policy (ou depuis un template), d'abord en Report-only, puis analyse de l'impact, puis On. Pour les utilisateurs passwordless, la user risk policy utilise Require risk remediation (révocation des sessions au lieu d'un changement de mot de passe). Rappel : Require risk remediation n'est pas pris en charge pour les invités, et si plusieurs policies s'appliquent, Block l'emporte, puis Require risk remediation sur Require password change.

Prérequis de l'auto-remédiation : l'utilisateur doit être déjà inscrit à la MFA, sinon il est bloqué et un administrateur doit intervenir ; pour un compte synchronisé, le password writeback doit être activé. Le secure password change (MFA puis nouveau mot de passe) n'utilise pas le flux SSPR. Variante hybride : Allow on-premises password change to reset user risk (Identity Protection > Settings, exige la password hash synchronization). D'où la section 3.

3. Faire inscrire la MFA#

3.1 La MFA registration policy d'ID Protection#

• ID Protection > Dashboard > Multifactor authentication registration policy ; rôle minimal Security Administrator ; licence P2.
• À la prochaine connexion interactive, l'utilisateur doit s'inscrire ; il dispose de 14 jours pour reporter, puis l'inscription devient obligatoire. Elle se déclenche aussi pendant l'OOBE Windows d'un nouvel appareil.
• Elle n'exige pas la MFA à chaque connexion : elle vérifie seulement l'état d'inscription.
• Toujours exclure les comptes d'urgence.

3.2 La registration campaign (nudge)#

Entra ID > Authentication methods > Registration campaign (rôle Authentication Policy Administrator). Après une MFA réussie, l'utilisateur est invité à configurer une méthode plus forte.

Ce qu'il faut savoir :

• Une campagne Authenticator ne relance qu'après une MFA par SMS ou appel vocal (pas après un code TOTP), et pas sur mobile ; une campagne passkey relance après n'importe quelle MFA et fonctionne sur mobile (navigateur, applications iOS).
• Le nudge ne s'affiche pas si une Conditional Access policy bloque la page Register security information, si des terms of use s'affichent, ou si un custom control redirige la connexion.
• Les invités sont relancés pour Authenticator, pas pour les passkeys.

Pour sécuriser l'inscription elle-même : une Conditional Access policy sur la user action Register security information (par exemple exiger la MFA hors trusted locations, ou un Temporary Access Pass pour un nouvel arrivant).

4. Surveiller, enquêter et remédier#

4.1 Les rapports#

Également : le dashboard ID Protection, le workbook Identity Protection Risk Analysis (Monitoring & health > Workbooks) et l'Impact analysis workbook pour mesurer l'effet d'une risk policy avant de l'activer.

4.2 Les actions de l'administrateur#

Quand une remédiation est faite par une policy (MFA, mot de passe), l'état devient Remediated et le détail peut être AI confirmed sign-in safe.

flowchart TD
    A["Utilisateur dans Risky users"] --> B{"Activité légitime ?"}
    B -- "Oui, faux positif" --> C["Confirm safe"]
    B -- "Oui mais bénin, test d'intrusion" --> D["Dismiss user risk"]
    B -- "Non ou doute" --> E["Confirm user compromised : risque High"]
    E --> F{"Compte avec mot de passe ?"}
    F -- "Oui" --> G["Reset password : sessions révoquées"]
    F -- "Non, passwordless" --> H["Revoke sessions"]
    G --> I["Enquête dans Microsoft Defender, export vers Sentinel"]
    H --> I

Par Microsoft Graph PowerShell (module Microsoft.Graph.Identity.SignIns) :

Connect-MgGraph -Scopes "IdentityRiskyUser.ReadWrite.All"

# Utilisateurs à risque élevé
Get-MgRiskyUser -Filter "RiskLevel eq 'high'" | Select-Object UserPrincipalName, RiskState, RiskLastUpdatedDateTime

# Ignorer le risque des comptes High non mis à jour depuis plus de 90 jours (après vérification)
$anciens = Get-MgRiskyUser -Filter "RiskLevel eq 'high'" | Where-Object RiskLastUpdatedDateTime -lt (Get-Date).AddDays(-90)
Invoke-MgDismissRiskyUser -UserIds $anciens.Id

# Confirmer une compromission (le risque de l'utilisateur passe à High)
Confirm-MgRiskyUserCompromised -UserIds "<id-objet-utilisateur>"

En REST : POST /identityProtection/riskyUsers/confirmCompromised (et /dismiss) avec la liste userIds ; permission IdentityRiskyUser.ReadWrite.All.

4.3 Exporter et chasser#

• Diagnostic settings de Microsoft Entra ID (au moins Security Administrator, Monitoring & health > Diagnostic settings) : RiskyUsers, UserRiskEvents, RiskyServicePrincipals, ServicePrincipalRiskEvents, RiskyAgents, AgentRiskEvents, vers Log Analytics, un storage account, un event hub ou une solution partenaire ; les données arrivent en 15 minutes environ et seulement à partir de l'activation.
• Dans Log Analytics : tables AADRiskyUsers, AADUserRiskEvents, AADRiskyServicePrincipals, AADServicePrincipalRiskEvents, AADRiskyAgents, AADAgentRiskEvents.
• Microsoft Sentinel : connecteur Microsoft Entra ID Protection (voir SC-500 chapitre 11).

// Détections de risque utilisateur encore ouvertes sur 30 jours, par niveau
AADUserRiskEvents
| where DetectedDateTime > ago(30d)
| where RiskState == "atRisk"
| summarize Nombre = count() by RiskLevel, RiskEventType
| order by RiskLevel asc, Nombre desc

5. Risky workload identities#

Les workload identities (applications, service principals) ne font pas de MFA, n'ont souvent pas de cycle de vie et stockent des secrets : elles sont donc une cible privilégiée.

Remédiation recommandée :

1. Inventorier les credentials du service principal et de l'objet application.
2. Ajouter un nouveau credential (Microsoft recommande un certificat x509).
3. Supprimer les credentials compromis (tous, en cas de doute).
4. Faire tourner les secrets Key Vault auxquels le service principal avait accès.

Pour aller plus loin côté jetons : la CAE for workload identities donne aux identités compatibles des jetons de 24 heures réévalués en continu.

6. Global Secure Access : architecture et clients#

6.1 Activer et comprendre les profils#

1. Global Secure Access > Get started > Activate Global Secure Access in your tenant (Global Administrator).
2. Connect > Traffic forwarding : activer les profils et les affecter (utilisateurs, groupes, appareils, plateformes).

Ordre d'évaluation : Microsoft, puis Private, puis Internet ; le trafic qui ne correspond à rien part en direct. Si plusieurs profils activés pour le même type s'appliquent à un utilisateur et un appareil, seul celui de plus haute priorité est utilisé.

6.2 Les clients#

Le client Windows utilise un lightweight filter (LWF) driver et non une connexion VPN : il peut cohabiter avec d'autres solutions SSE ou VPN. Seul le trafic défini par les profils part vers le service.

6.3 Les remote networks (agences)#

Pour les sites sans client : Connect > Remote networks > Create remote network (nom, région), puis une device link par équipement :

• CPE compatible IPsec, IKEv2, BGP, chiffrement GCMAES en phase 2, VPN route-based avec traffic selectors any-to-any ; le CPE initie la connexion (Global Secure Access est en mode responder).
• Champs : device type (Fortinet, Palo Alto Networks, Cisco Meraki…), IP publique du CPE, BGP address et ASN différents de ceux de Microsoft (adresses locale et pair inversées entre les deux côtés), bande passante 250 à 1 000 Mbps, Zone redundancy possible, policy IKE Default ou Custom, pre-shared key.
• Résilience : zone redundancy (deux tunnels, deux zones) ou geographic redundancy (autre région).
• Un remote network peut porter le Microsoft traffic profile et l'Internet Access profile, pas Private Access ; le trafic d'un type non associé est abandonné par la passerelle : associer les deux profils si la licence le permet.

7. Microsoft Entra Private Access#

Le principe (ZTNA plutôt que VPN), les composants (Quick Access, per-app access, private network connector, connector groups), les licences, les rôles et la marche à suivre sont dans SC-500 § 6.

Ce que l'administrateur SC-300 doit savoir en plus :

8. Microsoft Entra Internet Access#

8.1 Le modèle : policy, security profile, Conditional Access#

1. Policies (Global Secure Access > Secure) : web content filtering (règles Allow ou Block par catégorie web, FQDN ou URL), TLS inspection, threat intelligence, cloud firewall (pour les remote networks).
2. Security profiles : conteneurs qui regroupent des policies, chacune avec une priorité (100 = la plus forte, 65 000 = la plus faible ; espacer de 100).
3. Conditional Access : la policy cible Target resources > All internet resources with Global Secure Access et applique, en Session, Use Global Secure Access security profile.

Règles de traitement :

• Si plusieurs Conditional Access policies correspondent, tous les security profiles correspondants sont appliqués, par ordre de priorité des profils.
• Le baseline profile (priorité 65 000) s'applique à tout le trafic Internet Access, sans Conditional Access, y compris les remote networks : c'est le filet de sécurité de l'organisation ; il s'exécute toujours, mais un profil de priorité plus forte l'emporte en cas de conflit.
• Délais : jusqu'à 90 minutes pour une nouvelle affectation, jusqu'à 20 minutes pour une modification.
• Sans TLS inspection, un site bloqué donne une simple connexion réinitialisée ; avec TLS inspection, une page de blocage personnalisable.

8.2 TLS inspection#

8.3 Déployer#

Créer les web content filtering policies, les regrouper en security profiles, lier les profils aux groupes par Conditional Access, affecter le Internet Access profile, déployer le client, vérifier dans Monitor > Traffic logs (filtre Action = Block), puis élargir par vagues avec un plan de retour arrière.

9. Le Microsoft traffic profile#

Activation : Connect > Traffic forwarding > Microsoft traffic profile, affectation à des utilisateurs et groupes (rôles Global Secure Access Administrator et Application Administrator), puis déploiement du client ou d'un remote network. Licence : Entra ID P1 ou P2 suffit.

Rappel sur TRv2 : inbound = comptes externes vers vos applications, outbound = vos comptes vers des applications externes, tenant restrictions = comptes externes vers des applications externes depuis vos appareils et réseaux.

Vérification d'un déploiement : sign-in logs avec Through Global Secure Access = Yes, pause du client puis tentative d'accès à SharePoint (le compliant network doit bloquer), tentative de connexion à un autre tenant (TRv2 doit bloquer), IP identique dans les sign-in logs avec et sans client (source IP restoration, compliant network désactivé pour le test).

10. Labs conseillés#

À faire dans un tenant de test (essais Entra ID P2 et Entra Suite), avec un compte d'urgence exclu de toutes les policies.

1. Risk policies en Report-only (30 min, sans coût hors licences d'essai)
   1. Créer la policy Sign-in risk Medium et High → authentication strength MFA, Every time en Report-only.
   2. Se connecter avec un utilisateur de test depuis un navigateur Tor (détection Anonymous IP address, real-time).
   3. Ouvrir Risky sign-ins puis le sign-in log, onglet Report-only : la policy aurait exigé la MFA.
   4. Résultat attendu : détection visible en 5 à 10 minutes ; aucun blocage réel. Supprimer la policy ou la passer à On.
2. Enquête et actions (20 min)
   1. Sur l'utilisateur de test : Confirm user compromised, constater le passage en High.
   2. Réinitialiser son mot de passe, vérifier l'état Remediated et la risk history.
   3. Lancer Get-MgRiskyUser puis Invoke-MgDismissRiskyUser sur un second compte.
3. MFA registration (20 min)
   1. Activer la MFA registration policy pour un groupe pilote, exclure le compte d'urgence.
   2. Activer une registration campaign Authenticator, snooze 1 jour, 3 snoozes ; se connecter avec un utilisateur qui fait la MFA par SMS.
   3. Résultat attendu : invitation à configurer Authenticator après la MFA, bouton Skip for now.
4. Global Secure Access, Microsoft traffic (45 min, un poste Windows 11 Entra joined)
   1. Activer Global Secure Access, le Microsoft traffic profile, l'affecter à l'utilisateur, installer le client.
   2. Vérifier Through Global Secure Access = Yes et l'IP restaurée dans les sign-in logs.
   3. Créer une Conditional Access policy Office 365 → Block sauf All Compliant Network locations, mettre le client en pause et constater le blocage. Désactiver la policy à la fin.
5. Internet Access (45 min, essai Internet Access ou Entra Suite)
   1. Créer une web content filtering policy Block Gambling et la lier au baseline profile.
   2. Créer un security profile Allow d'un FQDN de la catégorie, priorité plus forte, lié par Conditional Access à un groupe.
   3. Résultat attendu : blocage pour tous sauf le groupe (après jusqu'à 20 ou 90 minutes), visible dans Traffic logs.
   4. Nettoyage : désactiver les profils, désinstaller le client, laisser expirer les essais.

11. Pièges d'examen#

12. Scénarios corrigés#

1. Contoso (Entra ID P2) veut que les connexions à risque moyen ou élevé demandent une MFA et que les comptes à risque élevé changent leur mot de passe, sans bloquer les administrateurs de secours.

Deux Conditional Access policies, d'abord en Report-only : Sign-in risk High, Medium → Require authentication strength (MFA), Every time et User risk High → Require risk remediation. Exclure les comptes d'urgence. Vérifier que les utilisateurs sont inscrits à la MFA (et password writeback activé pour les comptes synchronisés).

2. Les détections Leaked credentials n'apparaissent jamais pour les comptes synchronisés depuis l'Active Directory local.

Il manque la password hash synchronization dans Microsoft Entra Connect (ou Cloud Sync) : la détection compare les identifiants trouvés avec les hash du tenant.

3. Un analyste veut ignorer en masse le risque des comptes signalés High il y a plus de 90 jours, déjà traités.

Get-MgRiskyUser -Filter "RiskLevel eq 'high'", filtre sur RiskLastUpdatedDateTime, puis Invoke-MgDismissRiskyUser (scope IdentityRiskyUser.ReadWrite.All, rôle Security Operator au minimum).

4. Le RSSI veut que les utilisateurs qui font la MFA par SMS passent à Microsoft Authenticator, avec trois reports au plus.

Registration campaign : State Enabled, méthode Microsoft Authenticator, Days allowed to snooze au choix, Limited number of snoozes = Enabled. Les utilisateurs déjà configurés en push ne sont pas relancés.

5. Une application métier single-tenant apparaît dans Risky workload identities avec la détection Leaked Credentials.

Confirmer la compromission, Disable service principal si nécessaire, inventorier les credentials, ajouter un certificat x509, supprimer les secrets, faire tourner les secrets Key Vault accessibles. Pour l'avenir : Conditional Access for workload identities (Workload ID Premium) qui bloque le service principal à risque.

6. Fabrikam veut que Microsoft 365 ne soit accessible qu'à travers son Global Secure Access, y compris contre le rejeu de jetons.

Activer le Microsoft traffic profile et la source IP restoration, déployer le client, puis une Conditional Access policy qui bloque Office 365 hors All Compliant Network locations.

7. Le service juridique interdit l'accès à d'autres tenants Microsoft 365 depuis les postes de l'entreprise, Mac compris.

Policy tenant restrictions v2 dans Cross-tenant access settings (bloquer par défaut, autoriser les partenaires), puis Universal tenant restrictions dans Global Secure Access (Global Secure Access Administrator + Security Administrator).

8. L'entreprise veut bloquer les sites de jeux d'argent pour tout le monde, mais autoriser un site précis à l'équipe marketing.

Web content filtering Block Gambling lié au baseline profile ; une policy Allow du FQDN dans un security profile de priorité plus forte, appliqué par Conditional Access (All internet resources with Global Secure Access, session Use Global Secure Access security profile) au groupe marketing.

9. Une agence de 200 postes sans client doit profiter du filtrage web et du Microsoft traffic profile.

Créer un remote network dans la région la plus proche, une device link IPsec IKEv2 + BGP (zone redundancy), associer le Microsoft traffic profile et l'Internet Access profile ; le filtrage passe par le baseline profile. Private Access n'est pas disponible par remote network.

10. Les utilisateurs mobiles iOS doivent accéder à une application interne en Private Access.

Déployer Microsoft Defender par Intune avec un profil VPN configuré pour Global Secure Access (iOS 16+, appareil Entra registered), affecter le Private Access profile et l'application Private Access aux utilisateurs.

13. Pour aller plus loin#

• ID Protection pour les agents (préversion) : onglet Agent detections et risque des identités d'agents Microsoft Entra Agent ID ; dans un flux on-behalf-of, le risque est attribué à l'utilisateur (voir SC-500 chapitre 07).
• Security Copilot : questions en langage naturel sur les risky workload identities et les utilisateurs à risque.
• CAE for workload identities : jetons de 24 heures réévalués en continu pour les identités compatibles.
• Generative AI insights de Global Secure Access : la capture des prompts et des charges MCP exige la TLS inspection.
• Défense en profondeur réseau : Global Secure Access complète Azure Firewall et les private endpoints (SC-500 chapitre 06) ; il protège l'utilisateur, pas le trafic entre workloads Azure.

14. Fiche à retenir#

• Sign-in risk = la connexion ; user risk = le compte ; niveaux Low, Medium, High ; Low expire après 6 mois.
• Real-time : 5 à 10 min ; offline : jusqu'à 48 h ; Leaked credentials et Verified threat actor IP toujours High.
• Risk policies dans Conditional Access : sign-in risk → MFA + Every time ; user risk High → Require risk remediation.
• Toujours exclure les comptes d'urgence ; Report-only d'abord ; Block > Require risk remediation > Require password change.
• Leaked credentials sur compte synchronisé : password hash synchronization obligatoire.
• MFA registration policy : P2, 14 jours ; registration campaign : Authenticator ou passkey, snooze 0 à 14 jours, 3 reports.
• Actions : Reset password, Confirm compromised (→ High), Confirm safe (faux positif), Dismiss (bénin), Block.
• Rapports : Risky users, Risky sign-ins, Risk detections (90 jours) ; export par diagnostic settings, tables AADRisk.
• Risky workload identities : pas les managed identities ; Workload ID Premium pour le détail et le blocage ; certificat x509.
• Profils GSA : Microsoft → Private → Internet ; Microsoft Entra traffic système toujours actif.
• Client Windows : joined ou hybrid joined (registered = Private Access seulement), pas AVD multi-session ; iOS / Android via Defender.
• Remote network : IPsec IKEv2 + BGP, CPE initiateur, Microsoft + Internet seulement.
• Internet Access : policies → security profiles (100 fort, 65 000 faible) → Conditional Access ; baseline sans Conditional Access.
• TLS inspection : CSR signé par votre CA, CA déployée sur les postes, désactiver QUIC.
• Microsoft traffic (P1) : source IP restoration, compliant network check, universal tenant restrictions (TRv2).

Références#

Lues le 21/10/2026 sur Microsoft Learn :

• Study guide for Exam SC-300
• What is Microsoft Entra ID Protection?
• What are risk detections?
• Risk detection types and levels
• Configure and enable risk policies
• Configure the multifactor authentication registration policy
• Self-remediation experience with ID Protection and Conditional Access
• Microsoft Entra ID Protection risk reports
• Investigate risk
• Remediate risks and unblock users
• Microsoft Graph PowerShell for ID Protection
• Securing workload identities
• Run a registration campaign to set up a passkey or Microsoft Authenticator
• What is Global Secure Access?
• Global Secure Access traffic forwarding profiles
• Global Secure Access client overview
• Install the Global Secure Access client for Windows
• Install the Global Secure Access client for macOS
• Install the Global Secure Access client for iOS
• Install the Global Secure Access client for Android
• How to create a remote network with Global Secure Access
• Add and delete remote network device links
• Learn about Microsoft Entra Internet Access for all apps
• Tutorial: Configure web content filtering with the baseline profile
• What is Transport Layer Security inspection?
• Configure TLS inspection with your own certificate
• Operate Microsoft Entra Internet Access
• Tutorial: Enable the Microsoft traffic profile
• Source IP restoration
• Tutorial: Enable the compliant network check
• Turn on Universal Tenant Restrictions
• Set up tenant restrictions v2