Microsoft Intune : Politiques de Conformité et : Guide

{
 "displayName": "ZT-Compliance-Android-Enterprise",
 "platform": "androidForWork",
 "settings": {
 "devicePropertySettings": {
 "osMinimumVersion": "13.0",
 "securityPatchMinimumLevel": "2026-01-01"
 },
 "systemSecuritySettings": {
 "passwordRequired": true,
 "passwordMinimumLength": 6,
 "passwordRequiredType": "atLeastAlphanumeric",
 "storageRequireEncryption": true,
 "requireDeviceLock": true
 },
 "deviceHealthSettings": {
 "rootedDevicesBlocked": true,
 "googlePlayServicesVerified": true,
 "safetyNetDeviceAttestation": "certifiedDevice",
 "requireCompanyPortalAppIntegrity": true
 }
 }
}

3.3 Grace period et actions de non-conformite

Intune permet de definir un grace period (delai de grace) qui donne a l'utilisateur le temps de corriger les problèmes de conformité avant que des actions ne soient declenchees. Cette approche est essentielle pour equilibrer sécurité et expérience utilisateur. Un appareil qui perd temporairement sa conformité (par exemple, apres une mise a jour système qui nécessite un redemarrage) ne devrait pas immédiatement bloquer l'acces aux ressources. Guide complet Microsoft Intune : politiques de conformité, configuration profiles, App Protection, Autopilot, Conditional Access et stratégie Zero.

Les actions echelonnees recommandees pour un déploiement Zero Trust :

# Script PowerShell - Configuration des actions de non-conformite via Graph API
$params = @{
 scheduledActionConfigurations = @(
 @{
 actionType = "notification"
 gracePeriodHours = 0
 notificationTemplateId = "default"
 },
 @{
 actionType = "markNonCompliant"
 gracePeriodHours = 24
 },
 @{
 actionType = "pushNotification"
 gracePeriodHours = 72
 },
 @{
 actionType = "remoteLock"
 gracePeriodHours = 168
 },
 @{
 actionType = "retire"
 gracePeriodHours = 720
 }
 )
}

# Application via Microsoft Graph PowerShell SDK
Import-Module Microsoft.Graph.DeviceManagement
Connect-MgGraph -Scopes "DeviceManagementConfiguration.ReadWrite.All"

$policyId = "votre-policy-id"
Update-MgDeviceManagementDeviceCompliancePolicyScheduledAction `
 -DeviceCompliancePolicyId $policyId `
 -BodyParameter $params

Les regles ASR (Attack Surface Reduction) constituent une couche de defense proactive deployable via Intune. Elles bloquent les comportements malveillants courants utilises par les attaquants, notamment les techniques de Living-off-the-Land et les vecteurs d'initial access. Voici les regles ASR essentielles a activer :

# Configuration ASR via Intune - Profil Endpoint Security
# Les regles sont identifiées par leur GUID

$asrRules = @{
 # Bloquer le contenu executable des clients email
 "BE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550" = "Block"
 
 # Bloquer les processus non approuves depuis USB
 "B2B3F03D-6A65-4F7B-A9C7-1C7EF74A9BA4" = "Block"
 
 # Bloquer les appels API Win32 depuis les macros Office
 "92E97FA1-2EDF-4476-BDD6-9DD0B4DDDC7B" = "Block"
 
 # Bloquer la creation de processus enfants par les apps Office
 "D4F940AB-401B-4EFC-AADC-AD5F3C50688A" = "Block"
 
 # Bloquer les injections de code dans les processus
 "75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84" = "Block"
 
 # Bloquer le vol de credentials depuis LSASS
 "9E6C4E1F-7D60-472F-BA1A-A39EF669E4B2" = "Block"
 
 # Bloquer les processus PSExec et WMI
 "D1E49AAC-8F56-4280-B9BA-993A6D77406C" = "Audit"
 
 # Bloquer les scripts offusques
 "5BEB7EFE-FD9A-4556-801D-275E5FFC04CC" = "Block"
 
 # Bloquer l'abus de drivers signes vulnerables
 "56A863A9-875E-4185-98A7-B882C64B5CE5" = "Block"
 
 # Bloquer la persistence via WMI event subscription
 "E6DB77E5-3DF2-4CF1-B95A-636979351E5B" = "Block"
}

# Note: Commencer en mode "Audit" pendant 30 jours 
# avant de passer en mode "Block" en production

4.4 Custom OMA-URI et Settings Catalog

Pour les paramètres non couverts par les templates natifs, Intune offre deux mécanismes : les profils Custom OMA-URI (pour Windows, utilisant le CSP - Configuration Service Provider) et le Settings Catalog (interface graphique unifiant plus de 5 000 paramètres). Le Settings Catalog est la méthode recommandee car il offre une interface plus accessible et un suivi de version des paramètres.

<!-- Exemple OMA-URI : Desactiver le protocole LLMNR (anti-NTLM relay) -->
<!-- OMA-URI: ./Device/Vendor/MSFT/Policy/Config/ADMX_DnsClient/Turn_Off_Multicast -->
<!-- Type: String -->
<!-- Value: <enabled/> -->

<!-- Desactiver NetBIOS over TCP/IP -->
<!-- OMA-URI: ./Device/Vendor/MSFT/Policy/Config/MSSLegacy/IPSourceRoutingProtectionLevel -->
<!-- Type: Integer -->
<!-- Value: 2 (Highest protection) -->

<!-- Forcer SMB signing -->
<!-- OMA-URI: ./Device/Vendor/MSFT/Policy/Config/MSSecurityGuide/ConfigureSMBV1ClientDriver -->
<!-- Type: Integer -->
<!-- Value: 4 (Disable driver) -->

Pre-Provisioning (White Glove) : permet a l'équipe IT ou au partenaire de demarrer le processus de provisionnement avant la livraison a l'utilisateur. La phase technique (jointure Azure AD, installation apps, application baselines) est completee en avance, et l'utilisateur n'a plus qu'a se connecter pour finaliser la personnalisation.

# Enregistrement d'un appareil Autopilot et creation du profil

# 1. Recuperer le hardware hash de l'appareil
Install-Script -Name Get-WindowsAutopilotInfo
Get-WindowsAutopilotInfo -OutputFile C:\hwid.csv

# 2. Importer dans Intune via Graph API
Import-Module Microsoft.Graph.DeviceManagement.Enrollment
Connect-MgGraph -Scopes "DeviceManagementServiceConfig.ReadWrite.All"

$importData = @{
 serialNumber = "SN-12345-ABCDE"
 hardwareIdentifier = (Get-Content C:\hwid.csv | 
 ConvertFrom-Csv).HardwareHash
 groupTag = "ZeroTrust-Corporate"
}

New-MgDeviceManagementImportedWindowsAutopilotDeviceIdentity `
 -BodyParameter $importData

# 3. Creer le profil Autopilot
$autopilotProfile = @{
 displayName = "ZT-Autopilot-UserDriven"
 description = "Profil Autopilot Zero Trust - Corporate"
 language = "fr-FR"
 extractHardwareHash = $true
 deviceNameTemplate = "ZT-%SERIAL%"
 outOfBoxExperienceSettings = @{
 hidePrivacySettings = $true
 hideEULA = $true
 userType = "standard"
 skipKeyboardSelectionPage = $true
 hideEscapeLink = $true
 }
 enrollmentStatusScreenSettings = @{
 hideInstallationProgress = $false
 allowDeviceUseBeforeProfileAndAppInstallComplete = $false
 blockDeviceSetupRetryByUser = $false
 allowLogCollectionOnInstallFailure = $true
 installProgressTimeoutInMinutes = 60
 }
}

New-MgDeviceManagementWindowsAutopilotDeploymentProfile `
 -BodyParameter $autopilotProfile

6.3 Enrollment Status Page (ESP)

L'Enrollment Status Page (page d'etat d'enrollment) est un composant critique du déploiement Zero Trust via Autopilot. Elle bloque l'acces au bureau Windows tant que les politiques de sécurité essentielles ne sont pas appliquees. Sans ESP, un utilisateur pourrait commencer a travailler sur un appareil qui n'a pas encore recu ses baselines de sécurité, son antivirus ou son chiffrement BitLocker - une violation directe du principe Zero Trust.

Configuration recommandee de l'ESP pour un déploiement Zero Trust : bloquer l'utilisation de l'appareil jusqu'a ce que tous les profils et applications critiques soient installes, definir un timeout de 60 minutes (permettant le déploiement complet y compris les mises a jour Windows), autoriser la collecte de logs en cas d'echec pour le diagnostic, et configurer les applications critiques qui doivent etre installees avant l'acces (Company Portal, Defender for Endpoint, VPN client, navigateur Edge).

Pour une visibilite complete dans un SOC, les logs Intune doivent etre integres dans Microsoft Sentinel via le connecteur natif. Les tables suivantes sont particulierement pertinentes pour le monitoring Zero Trust : IntuneDeviceComplianceOrg (etat de conformite), IntuneOperationalLogs (operations administratives), IntuneDevices (inventaire appareils), et SigninLogs (contexte Conditional Access).

// KQL - Detection d'appareils qui deviennent non conformes
// Utile pour détecter des tentatives d'evasion de la conformite

IntuneDeviceComplianceOrg
| where TimeGenerated > ago(24h)
| where ComplianceState == "noncompliant"
| summarize 
 NonCompliantCount = count(),
 Platforms = make_set(OS),
 FirstSeen = min(TimeGenerated)
 by DeviceName, UserName
| where NonCompliantCount > 1
| sort by NonCompliantCount desc

// Detection de patterns suspects - appareil qui alterne 
// entre conforme et non conforme (possible evasion)
IntuneDeviceComplianceOrg
| where TimeGenerated > ago(7d)
| summarize 
 StateChanges = dcount(ComplianceState),
 States = make_set(ComplianceState)
 by DeviceName, UserName
| where StateChanges > 3
| sort by StateChanges desc

9.3 KPIs et metriques Zero Trust

Pour mesurer l'efficacite de votre déploiement Zero Trust via Intune, suivez ces indicateurs cles de performance (KPIs) :

Cet article vous a ete utile ? Partagez-le avec votre réseau professionnel !

Ayi NEDJIMI

Expert en Cybersécurité & Intelligence Artificielle

Consultant senior avec plus de 15 ans d'experience en sécurité offensive, audit d'infrastructure et developpement de solutions IA. Certifie OSCP, CISSP, ISO 27001 Lead Auditor et ISO 42001 Lead Implementer. Intervient sur des missions de pentest Active Directory, sécurité Cloud et conformité reglementaire pour des grands comptes et ETI.

LinkedIn Profil complet Tous ses articles

Sources et références : Microsoft Security Docs · CERT-FR

FAQ

Qu'est-ce que Microsoft Intune ?

Microsoft Intune désigne l'ensemble des concepts, techniques et méthodologies abordés dans cet article. Les fondamentaux sont détaillés dans les premières sections du guide.

Pourquoi intune politiques conformité zero trust est-il important ?

La maîtrise de intune politiques conformité zero trust est devenue essentielle pour les équipes de sécurité. Les enjeux et le contexte opérationnel sont développés tout au long de l'article.

Comment appliquer ces recommandations en entreprise ?

Chaque section de cet article propose des méthodologies et des outils directement utilisables. Les recommandations tiennent compte des contraintes d'environnements de production réels.

Conclusion

Face à l'évolution constante des menaces, une posture de sécurité proactive est indispensable. Les techniques et recommandations présentées dans cet article constituent des fondations solides pour renforcer la résilience de votre infrastructure.

Analyse des impacts et recommandations

L'analyse des risques associés à cette problématique révèle des impacts potentiels significatifs sur la confidentialité, l'intégrité et la disponibilité des systèmes d'information. Les recommandations présentées s'appuient sur les référentiels de l'ANSSI et du NIST pour garantir une approche structurée de la remédiation.

Mise en œuvre opérationnelle

La mise en œuvre des mesures de sécurité décrites dans cet article nécessite une approche progressive, en commençant par les actions à gain rapide avant de déployer les contrôles plus complexes. Un plan d'action priorisé permet de maximiser la réduction du risque tout en respectant les contraintes opérationnelles de l'organisation.

Perspectives et évolutions

Le paysage des menaces évolue continuellement, rendant nécessaire une veille permanente et une adaptation régulière des stratégies de défense. Les tendances actuelles indiquent une sophistication croissante des techniques d'attaque et une nécessité d'automatisation accrue des processus de détection et de réponse.

Synthèse et recommandations clés

Les éléments présentés dans cette analyse mettent en lumière la nécessité d'une approche structurée face aux défis de cybersécurité actuels. La combinaison de mesures techniques, organisationnelles et humaines constitue le socle d'une posture de sécurité robuste capable de résister aux menaces les plus sophistiquées.

Synthèse et points clés

Les éléments présentés dans cet article mettent en évidence l'importance d'une approche structurée et méthodique. La combinaison de contrôles techniques, de processus organisationnels et de formation continue constitue le socle d'une posture de sécurité mature et résiliente face aux menaces actuelles.

Votre tenant M365 est-il sécurisé ?

Audit Entra ID, Exchange, SharePoint, Teams — Secure Score, conditional access, DLP.

Audit M365 — Devis gratuit [email protected]

Déploiement des politiques Intune en environnement hybride Azure AD

Le déploiement des politiques de conformité Microsoft Intune dans un environnement hybride Azure Active Directory présente des spécificités que les équipes IT doivent impérativement maîtriser pour garantir une couverture complète et cohérente de l'ensemble des appareils du parc. Les postes joints à un domaine Active Directory on-premises peuvent être co-gérés via Configuration Manager et Intune simultanément, ce qu'on appelle la co-gestion ou co-management. Cette architecture hybride permet une transition progressive et sécurisée vers le cloud sans rupture de service pour les utilisateurs, en définissant précisément quelles workloads de gestion sont traitées par l'un ou l'autre outil selon les capacités de chacun. La planification rigoureuse de cette répartition conditionne directement l'efficacité des politiques de conformité déployées et la cohérence de l'expérience utilisateur dans l'ensemble de l'organisation.

Dans un scénario hybride, les objets de stratégie de groupe Active Directory peuvent entrer en conflit avec les politiques MDM d'Intune appliquées aux mêmes appareils et générer des comportements inattendus. Microsoft recommande d'éviter ces conflits en migrant progressivement les GPO existantes vers des profils de configuration Intune équivalents ou supérieurs en fonctionnalité. L'outil ADMX d'Intune permet d'importer et de gérer les modèles d'administration personnalisés, offrant une parité fonctionnelle croissante avec les GPO traditionnelles héritées. La cohérence des paramètres effectivement appliqués aux appareils est vérifiable en temps réel via le rapport de conformité Intune, accessible depuis le portail Microsoft Endpoint Manager, qui détaille appareil par appareil l'état de chaque politique déployée et expose les causes d'échec éventuelles rencontrées lors du déploiement pour permettre une résolution rapide.

L'enrôlement des appareils dans Intune constitue la première étape critique de tout déploiement réussi. Windows Autopilot simplifie considérablement ce processus pour les nouveaux appareils en permettant une configuration automatisée et reproductible dès la première connexion de l'utilisateur final, sans intervention manuelle du service informatique. Pour les appareils existants déjà en production, plusieurs méthodes d'enrôlement coexistent selon les besoins : l'enrôlement en libre-service via les paramètres Windows, le déploiement automatisé via des scripts PowerShell ou l'enrôlement en masse avec des jetons d'inscription provisionnels générés depuis le portail Intune. Chaque méthode présente des avantages spécifiques selon le contexte organisationnel, la taille du parc informatique à gérer et le niveau d'automatisation souhaité par les équipes opérationnelles responsables du cycle de vie complet des appareils.

Accès conditionnel et application des politiques Zero Trust dans Microsoft 365

L'accès conditionnel Azure AD représente le moteur d'application concrète des politiques Zero Trust au sein de l'écosystème Microsoft 365 des organisations modernes. Chaque tentative d'accès à une ressource protégée déclenche une évaluation en temps réel de multiples signaux contextuels : identité et rôle de l'utilisateur, état de conformité de l'appareil selon Intune, localisation géographique de la connexion, application cible demandée et niveau de risque calculé dynamiquement par Microsoft Entra ID Protection à partir de l'analyse comportementale et des renseignements sur les menaces. Sur la base de cette évaluation multicritère, l'accès peut être accordé directement, accordé sous réserve d'une validation MFA renforcée, conditionné à l'utilisation d'un appareil conforme et géré, ou totalement bloqué. Cette granularité fine permet d'adapter précisément le niveau de friction sécuritaire à la sensibilité réelle de chaque ressource et au profil de risque de chaque utilisateur dans le tenant.

L'intégration des scores de conformité Intune dans les politiques d'accès conditionnel matérialise concrètement l'architecture Zero Trust au niveau des appareils dans l'organisation. Un appareil marqué non conforme par Intune — parce que son antivirus est désactivé, que son chiffrement BitLocker n'est pas activé sur le disque système, que son système d'exploitation n'a pas été mis à jour vers la version minimale requise par politique, ou que des applications non autorisées y sont installées — se voit automatiquement refuser l'accès aux ressources sensibles de l'organisation, et ce même si l'utilisateur dispose par ailleurs de tous les droits nécessaires dans l'annuaire. Cette automatisation rigoureuse supprime la dépendance aux vérifications manuelles intermittentes réalisées par les équipes IT et garantit que la posture de sécurité réelle du parc est continuellement évaluée, mesurée et appliquée sans délai ni exception.

La surveillance continue du fonctionnement des politiques d'accès conditionnel est assurée par les journaux de connexion Azure AD enrichis et Microsoft Sentinel lorsqu'il est déployé en SIEM dans l'organisation. Ces logs détaillés enregistrent chaque évaluation de politique avec l'intégralité de ses paramètres d'entrée et la décision finale prise par le moteur d'accès conditionnel, permettant d'auditer le fonctionnement des règles configurées et d'identifier rapidement les utilisateurs ou appareils posant des problèmes récurrents de conformité. L'analyse régulière et structurée de ces données alimente les tableaux de bord opérationnels que les équipes SOC utilisent pour surveiller l'état de sécurité global du tenant Microsoft 365 et prioriser leurs actions correctives quotidiennes selon l'exposition réelle aux risques identifiés et leur impact potentiel sur la continuité des activités métier de l'organisation.