Microsoft Intune : Politiques de Conformite et Deploiement Zero Trust

1. Introduction : pourquoi Intune est au coeur du Zero Trust

Le modele Zero Trust repose sur un principe fondamental : ne jamais faire confiance, toujours verifier. Dans cette philosophie, chaque tentative d'acces a une ressource d'entreprise doit etre validee en fonction de l'identite de l'utilisateur, de l'etat de sante du terminal et du contexte de la connexion. Microsoft Intune, composant central de la suite Microsoft Endpoint Manager, constitue le pilier technique qui permet d'evaluer en temps reel la posture de securite de chaque appareil avant d'autoriser l'acces aux donnees de l'organisation.

Depuis la consolidation de Microsoft Endpoint Manager sous la marque Microsoft Intune Suite en 2024, la plateforme a considerablement evolue. Elle integre desormais des capacites avancees de gestion unifiee des endpoints (UEM), englobant Windows, macOS, iOS, iPadOS, Android et Linux. L'ajout de fonctionnalites comme Intune Advanced Analytics, Remote Help, Endpoint Privilege Management et Tunnel for Mobile Application Management renforce sa position comme solution de reference pour le deploiement Zero Trust.

Dans un contexte ou le travail hybride s'est generalise, les organisations font face a un defi majeur : comment garantir que chaque terminal accedant aux ressources de l'entreprise respecte les exigences de securite, qu'il soit gere (corporate-owned) ou personnel (BYOD) ? Intune repond a cette question en fournissant un systeme de politiques de conformite granulaires, des profils de configuration de securite, et une integration native avec Conditional Access et MFA de Microsoft Entra ID.

Cet article propose un guide complet et operationnel pour deployer Intune dans une logique Zero Trust. Nous examinerons l'architecture de la plateforme, les politiques de conformite par plateforme, les profils de configuration de securite, la protection des applications (MAM), le deploiement zero-touch avec Autopilot, l'integration avec Microsoft Defender for Endpoint, et les strategies de monitoring. Chaque section fournit des configurations concretes, des scripts PowerShell et des recommandations issues de deployments en production.

2. Architecture Microsoft Intune et ecosysteme Zero Trust

2.1 Composants de l'architecture

L'architecture d'Intune repose sur plusieurs composants interconnectes qui forment un ecosysteme complet de gestion des endpoints. Le service cloud Intune constitue le plan de controle central, heberge dans Azure et accessible via le portail Microsoft Intune admin center (intune.microsoft.com). Ce service communique avec les appareils via des protocoles specifiques a chaque plateforme : MDM protocol pour Windows (basee sur OMA-DM), APNs (Apple Push Notification service) pour iOS/macOS, et FCM (Firebase Cloud Messaging) pour Android.

Le Microsoft Intune Connector assure la liaison avec l'infrastructure on-premises, notamment Active Directory pour le deploiement Hybrid Azure AD Join et les serveurs NDES (Network Device Enrollment Service) pour la distribution de certificats. Le Company Portal (Portail d'entreprise) est l'application installee sur les terminaux qui permet l'enrollment, l'acces au catalogue d'applications et la consultation du statut de conformite.

2.2 Modes d'enrollment et niveaux de gestion

Intune propose plusieurs modes d'enrollment qui determinent le niveau de controle exerce sur l'appareil. Le choix du mode d'enrollment est une decision architecturale critique qui impacte directement la surface de gestion et l'experience utilisateur :

Mode	Plateforme	Controle	Cas d'usage
MDM Full Enrollment	Windows, macOS	Complet	Appareils corporate
Autopilot	Windows	Complet + zero-touch	Deploiement neuf
DEP (ADE)	iOS, macOS	Supervise	Flotte Apple corporate
Android Enterprise	Android	Work Profile / Fully Managed	Corporate ou COPE
MAM-only (sans MDM)	iOS, Android	Applications uniquement	BYOD
Co-management	Windows	Partage SCCM + Intune	Migration progressive

2.3 Licencing et prerequis

Le deploiement d'Intune dans une logique Zero Trust complete necessite des licences specifiques. La licence Microsoft Intune Plan 1 (incluse dans Microsoft 365 E3/E5, EMS E3/E5) couvre les fonctionnalites MDM/MAM de base. Le Microsoft Intune Plan 2 (add-on ou inclus dans Intune Suite) ajoute Microsoft Tunnel, Endpoint Privilege Management et les fonctionnalites avancees. Pour l'integration Conditional Access, une licence Microsoft Entra ID P1 minimum est requise (incluse dans Microsoft 365 E3). La license Microsoft Defender for Endpoint Plan 2 (incluse dans Microsoft 365 E5 Security) est necessaire pour le signal de risque machine dans les politiques de conformite.

3. Politiques de Conformite : le coeur du signal Zero Trust

3.1 Principe et fonctionnement

Les politiques de conformite (Compliance Policies) constituent le mecanisme central par lequel Intune evalue la posture de securite d'un appareil. Chaque politique definit un ensemble de regles que l'appareil doit respecter pour etre considere comme "conforme". Ce statut de conformite est ensuite transmis a Microsoft Entra ID sous forme de signal (claim), qui peut etre utilise par les politiques Conditional Access pour autoriser ou bloquer l'acces aux ressources.

Le processus d'evaluation de la conformite suit un cycle precis : (1) Intune deploie la politique vers l'appareil, (2) l'appareil rapporte son etat au service Intune selon un intervalle defini (toutes les 8 heures par defaut, ou manuellement via le Company Portal), (3) le moteur de conformite compare l'etat rapporte aux regles definies, (4) le statut de conformite est mis a jour dans Entra ID. Il est crucial de comprendre que ce cycle introduit une latence inherente : un appareil peut ne plus etre conforme pendant plusieurs heures avant que le statut ne soit mis a jour.

3.2 Regles de conformite par plateforme

Windows 10/11

La plateforme Windows offre le jeu de regles de conformite le plus complet. Voici les regles essentielles pour un deploiement Zero Trust :

{
  "displayName": "ZT-Compliance-Windows-Corporate",
  "description": "Politique de conformite Zero Trust - Windows Corporate",
  "platform": "windows10AndLater",
  "settings": {
    "deviceHealthSettings": {
      "bitLockerEnabled": true,
      "secureBootEnabled": true,
      "codeIntegrityEnabled": true,
      "requireHealthyDeviceReport": true
    },
    "devicePropertySettings": {
      "osMinimumVersion": "10.0.22631.0",
      "osMaximumVersion": null,
      "mobileOsMinimumVersion": null
    },
    "systemSecuritySettings": {
      "passwordRequired": true,
      "passwordMinimumLength": 12,
      "passwordRequiredType": "alphanumeric",
      "passwordMinutesOfInactivityBeforeLock": 5,
      "passwordExpirationDays": null,
      "storageRequireEncryption": true,
      "requireAntivirusActive": true,
      "requireAntiSpywareActive": true,
      "requireFirewallEnabled": true,
      "tpmRequired": true,
      "defenderEnabled": true,
      "defenderVersion": null
    },
    "defenderForEndpointSettings": {
      "requireMachineRiskScore": "low"
    }
  }
}

macOS

Pour macOS, les regles de conformite couvrent FileVault (chiffrement), le pare-feu, la protection d'integrite du systeme (SIP), et la version minimale du systeme :

{
  "displayName": "ZT-Compliance-macOS",
  "platform": "macOS",
  "settings": {
    "systemSecuritySettings": {
      "passwordRequired": true,
      "passwordMinimumLength": 12,
      "passwordBlockSimple": true,
      "firewallEnabled": true,
      "firewallBlockIncomingConnections": true,
      "systemIntegrityProtectionEnabled": true,
      "storageRequireEncryption": true,
      "gatekeeperAllowedAppSource": "macAppStoreAndIdentifiedDevelopers"
    },
    "devicePropertySettings": {
      "osMinimumVersion": "14.0"
    }
  }
}

Sur macOS, la verification de l'integrite systeme (SIP) est particulierement importante. Les techniques de persistence sur macOS et Linux exploitent regulierement des failles dans les mecanismes de protection natifs. Exiger SIP active via la politique de conformite constitue un controle preventif essentiel.

iOS / iPadOS

{
  "displayName": "ZT-Compliance-iOS",
  "platform": "iOS",
  "settings": {
    "devicePropertySettings": {
      "osMinimumVersion": "17.0",
      "jailbrokenDevice": "blocked"
    },
    "systemSecuritySettings": {
      "passcodeRequired": true,
      "passcodeMinimumLength": 6,
      "passcodeBlockSimple": true,
      "passcodeMinutesOfInactivityBeforeLock": 5
    }
  }
}

La detection du jailbreak est un parametre critique sur iOS. Les appareils jailbreakes representent un risque majeur car ils contournent les protections sandboxing d'Apple, exposant les donnees d'entreprise aux malwares et aux techniques d'attaque mobile offensive. Intune utilise plusieurs mecanismes de detection, mais il faut savoir que les techniques de jailbreak modernes (checkm8, palera1n) peuvent parfois echapper a la detection basique.

Android Enterprise

{
  "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 problemes de conformite avant que des actions ne soient declenchees. Cette approche est essentielle pour equilibrer securite et experience utilisateur. Un appareil qui perd temporairement sa conformite (par exemple, apres une mise a jour systeme qui necessite un redemarrage) ne devrait pas immediatement bloquer l'acces aux ressources.

Les actions echelonnees recommandees pour un deploiement Zero Trust :

Delai	Action	Impact
Immediat (J+0)	Notification utilisateur + push email	Information seulement
J+1	Marquage "Non conforme" dans Entra ID	Blocage Conditional Access
J+3	Notification d'escalade (manager + helpdesk)	Visibilite management
J+7	Verrouillage distant de l'appareil	Blocage total
J+30	Retrait (retire) de l'appareil	Suppression profil corporate

# 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

4. Profils de Configuration : Security Baselines et Durcissement

4.1 Security Baselines

Les Security Baselines d'Intune sont des ensembles preconfigures de parametres de securite recommandes par Microsoft. Ils representent la transposition des guides de durcissement CIS et DISA STIG en profils deployables via Intune. Trois baselines principales sont disponibles : la Windows Security Baseline (mise a jour a chaque version majeure de Windows), la Microsoft Defender for Endpoint Baseline, et la Microsoft Edge Baseline.

L'approche recommandee consiste a deployer la baseline par defaut, puis a creer des profils de configuration supplementaires pour les parametres specifiques a votre organisation. Ne modifiez jamais directement la baseline : creez plutot un profil personnalise qui ecrase les parametres necessaires. Cette methode facilite la mise a jour lorsqu'une nouvelle version de la baseline est publiee.

4.2 BitLocker et chiffrement

Le chiffrement des disques est un prerequis non negociable dans une architecture Zero Trust. Intune permet de deployer BitLocker avec des configurations avancees via les profils Endpoint Protection ou Disk Encryption :

{
  "displayName": "ZT-BitLocker-Corporate",
  "profileType": "endpointProtection",
  "bitLockerSettings": {
    "encryptionMethod": "xtsAes256",
    "startupAuthenticationRequired": true,
    "startupAuthenticationTpmUsage": "required",
    "prebootRecoveryEnableMessageAndUrl": true,
    "fixedDrivePolicy": {
      "encryptionMethod": "xtsAes256",
      "requireEncryption": true,
      "recoveryOptions": {
        "enableRecoveryInformationSaveToStore": true,
        "recoveryInformationType": "passwordAndKey",
        "hideRecoveryOptions": false,
        "enableBitLockerAfterRecoveryInformationToStore": true
      }
    },
    "removableDrivePolicy": {
      "requireEncryption": true,
      "encryptionMethod": "aes128",
      "blockCrossOrganizationWriteAccess": true
    },
    "systemDrivePolicy": {
      "encryptionMethod": "xtsAes256",
      "startupAuthentication": {
        "blockIfNoneTpm": true,
        "tpmStartupKeyUsage": "optional",
        "tpmPinUsage": "optional",
        "tpmUsage": "required"
      }
    }
  }
}

Les cles de recuperation BitLocker sont automatiquement stockees dans Microsoft Entra ID, permettant au helpdesk de les retrouver via le portail Intune. Pour les appareils Windows 10/11 Pro, utilisez le parametre silentBitLockerEncryption pour chiffrer sans interaction utilisateur lors de l'Autopilot enrollment.

4.3 Attack Surface Reduction (ASR)

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 identifiees 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 parametres non couverts par les templates natifs, Intune offre deux mecanismes : les profils Custom OMA-URI (pour Windows, utilisant le CSP - Configuration Service Provider) et le Settings Catalog (interface graphique unifiant plus de 5 000 parametres). Le Settings Catalog est la methode recommandee car il offre une interface plus accessible et un suivi de version des parametres.

<!-- 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) -->

5. App Protection Policies (MAM) : securiser le BYOD

5.1 MAM sans enrollment MDM

L'une des forces majeures d'Intune est sa capacite a proteger les donnees d'entreprise sur des appareils personnels (BYOD) sans necessiter d'enrollment MDM. Les App Protection Policies (APP), aussi appelees politiques MAM (Mobile Application Management), creent un conteneur securise au niveau applicatif. Les donnees d'entreprise dans les applications gerees (Outlook, Teams, OneDrive, Edge, etc.) sont isolees des donnees personnelles et soumises a des controles de securite specifiques.

Cette approche est particulierement pertinente dans une strategie Zero Trust car elle permet de proteger les donnees independamment de l'etat de l'appareil. Meme sur un appareil non gere, les donnees d'entreprise restent chiffrees, les operations copier-coller entre applications gerees et non gerees sont controlees, et un wipe selectif peut etre declenche sans affecter les donnees personnelles.

5.2 Configuration des App Protection Policies

Microsoft recommande trois niveaux de protection MAM, alignes sur les niveaux de securite Zero Trust :

Niveau 1 - Protection minimale (Enterprise Basic) : PIN requis pour l'acces aux applications gerees, chiffrement des donnees d'application, bloquer les captures d'ecran. Ce niveau convient aux organisations qui commencent leur parcours Zero Trust.

Niveau 2 - Protection renforcee (Enterprise Enhanced) : ajout de la detection de jailbreak/root, version minimale de l'OS, blocage du copier-coller vers les applications non gerees, blocage de la sauvegarde vers des services tiers. Ce niveau est recommande pour la plupart des scenarios BYOD en entreprise.

Niveau 3 - Protection haute securite (Enterprise High) : longueur minimale du PIN complexe (8 caracteres, alphanumerique), blocage complet du transfert de donnees, effacement apres un nombre limite de tentatives de PIN, verification des menaces au niveau de l'appareil. Ce niveau est destine aux secteurs sensibles (finance, sante, defense) et aux utilisateurs manipulant des donnees classifiees.

{
  "displayName": "ZT-MAM-iOS-Level2-Enhanced",
  "platform": "iOS",
  "targetedAppManagementLevel": "unmanaged",
  "settings": {
    "dataProtection": {
      "orgDataSharingType": "managedAppsWithPasteIn",
      "dataBackupBlocked": true,
      "deviceComplianceRequired": false,
      "managedBrowserRequired": true,
      "encryptAppData": true,
      "contactSyncBlocked": false,
      "printingBlocked": true,
      "screenCaptureBlocked": true,
      "thirdPartyKeyboardsBlocked": true,
      "saveAsBlocked": true,
      "allowedOutboundDataTransferDestinations": "managedApps"
    },
    "accessRequirements": {
      "pinRequired": true,
      "pinCharacterType": "numeric",
      "minimumPinLength": 6,
      "simplePinBlocked": true,
      "biometricRequired": false,
      "allowPinAfterBiometric": true,
      "periodBeforePinReset": 60,
      "periodOfflineBeforeAccessCheck": 720,
      "periodOfflineBeforeWipeIsEnforced": 90
    },
    "conditionalLaunch": {
      "jailbreakBlocked": true,
      "minimumOsVersion": "17.0",
      "maximumPinRetries": 5,
      "offlineGracePeriod": 720,
      "minimumAppVersion": null
    }
  }
}

5.3 Selective Wipe et cycle de vie des donnees

Le selective wipe (effacement selectif) est une fonctionnalite cruciale des politiques MAM. Contrairement au full wipe MDM qui reinitialise l'appareil complet, le selective wipe supprime uniquement les donnees d'entreprise des applications gerees, preservant les donnees personnelles de l'utilisateur. Cette capacite est declenchee automatiquement dans plusieurs scenarios : (1) depart de l'employe (desactivation du compte Entra ID), (2) detection de jailbreak/root, (3) periode offline depassee, (4) action manuelle de l'administrateur.

# Selective Wipe via Microsoft Graph PowerShell
# Effacer les donnees corporate d'un utilisateur sur tous ses appareils

Import-Module Microsoft.Graph.Devices.CorporateManagement
Connect-MgGraph -Scopes "DeviceManagementApps.ReadWrite.All"

# Recuperer l'utilisateur
$user = Get-MgUser -Filter "userPrincipalName eq 'jean.dupont@contoso.fr'"

# Declenchement du selective wipe
New-MgUserManagedAppRegistrationWipeOperation -UserId $user.Id

# Verification du statut
Get-MgUserManagedAppRegistration -UserId $user.Id | 
    Select-Object AppIdentifier, DeviceName, LastSyncDateTime

6. Windows Autopilot : deploiement Zero-Touch

6.1 Architecture Autopilot

Windows Autopilot est le mecanisme de deploiement zero-touch de Microsoft qui permet de preconfigurer de nouveaux appareils Windows directement depuis le cloud, sans intervention de l'equipe IT sur le materiel physique. Dans une strategie Zero Trust, Autopilot garantit que chaque appareil est provisionne avec les politiques de securite des le premier demarrage, eliminant la fenetre de vulnerabilite qui existe entre la reception du materiel et la configuration manuelle.

Le processus Autopilot se deroule en plusieurs phases : (1) le fabricant OEM enregistre le hardware hash de l'appareil dans le tenant Intune, (2) un profil Autopilot est assigne a l'appareil (via groupe dynamique base sur l'identifiant), (3) au premier demarrage, l'appareil contacte le service Autopilot, telecharge son profil, (4) l'utilisateur se connecte avec ses credentials Entra ID, (5) les politiques de conformite, les profils de configuration, les applications et les baselines de securite sont automatiquement deployes.

6.2 Modes de deploiement Autopilot

Autopilot propose plusieurs modes adaptes a differents scenarios :

User-Driven Mode (Azure AD Join) : le mode le plus courant pour les appareils corporate. L'utilisateur se connecte avec son compte Entra ID lors de l'OOBE (Out-of-Box Experience). L'appareil rejoint Azure AD et Intune automatiquement. Ce mode est recommande pour les laptops deployes en mode hybride/remote.

Self-Deploying Mode : deploiement entierement automatise sans interaction utilisateur, ideal pour les kiosques, les salles de reunion et les appareils partages. Necessite TPM 2.0 pour l'attestation matérielle.

Pre-Provisioning (White Glove) : permet a l'equipe 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 deploiement Zero Trust via Autopilot. Elle bloque l'acces au bureau Windows tant que les politiques de securite 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 securite, son antivirus ou son chiffrement BitLocker - une violation directe du principe Zero Trust.

Configuration recommandee de l'ESP pour un deploiement 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 deploiement 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).

7. Endpoint Security : ASR, Defender et integration avancee

7.1 Integration Microsoft Defender for Endpoint

L'integration entre Intune et Microsoft Defender for Endpoint (MDE) est un pilier du deploiement Zero Trust. Cette integration fournit un signal de risque machine en temps reel qui enrichit les decisions de conformite. Lorsque MDE detecte une menace sur un appareil (malware, exploitation, comportement suspect), il attribue un niveau de risque machine (Low, Medium, High, Clear) qui est automatiquement consomme par la politique de conformite Intune.

Le flux d'integration suit ce processus : (1) MDE detecte un indicateur de compromission (IoC) ou un comportement malveillant, (2) le niveau de risque de la machine est mis a jour dans le portail MDE, (3) Intune recupere ce signal via le connecteur service-to-service, (4) la politique de conformite evalue le nouveau niveau de risque, (5) si le risque depasse le seuil defini, l'appareil est marque non conforme, (6) Conditional Access bloque l'acces aux ressources cloud.

# Configuration du connecteur Intune-Defender

# 1. Activer le connecteur dans Intune Admin Center
# Endpoint Security > Microsoft Defender for Endpoint > Connection Status

# 2. Verifier via Graph API
$connectorStatus = Get-MgDeviceManagementMobileThreatDefenseConnector
$connectorStatus | Select-Object DisplayName, State, 
    LastHeartbeatDateTime, PartnerUnresponsivenessPeriodInDays

# 3. Configurer la politique de conformite avec signal MDE
$compliancePolicy = @{
    displayName = "ZT-Compliance-MDE-Risk"
    platform = "windows10AndLater"
    scheduledActionsForRule = @(
        @{
            ruleName = "PasswordRequired"
            scheduledActionConfigurations = @(
                @{
                    actionType = "markNonCompliant"
                    gracePeriodHours = 0
                }
            )
        }
    )
    defenderForEndpointSettings = @{
        requireMachineRiskScore = "low"
        # Options: clear, low, medium, high
        # "low" = l'appareil doit avoir un score de risque 
        # "Low" ou "Clear" pour etre conforme
    }
}

7.2 Endpoint Privilege Management (EPM)

Endpoint Privilege Management (EPM), disponible avec Intune Suite, permet de gerer les elevations de privileges sur les postes Windows sans accorder de droits administrateurs permanents. Dans une logique Zero Trust, le principe du moindre privilege est fondamental : aucun utilisateur ne devrait disposer de droits administrateurs au quotidien. EPM permet de definir des regles d'elevation specifiques pour des applications ou des taches identifiees, avec approbation automatique ou manuelle.

EPM est particulierement pertinent face aux techniques d'escalade de privileges Windows qui exploitent les comptes administrateurs locaux. En eliminant les privileges administrateurs permanents et en controlant les elevations, on reduit considerablement la surface d'attaque disponible pour un attaquant qui aurait compromis un compte utilisateur standard.

{
  "displayName": "ZT-EPM-Standard-Users",
  "description": "Regles d'elevation pour utilisateurs standard",
  "elevationRules": [
    {
      "displayName": "Autoriser installation imprimante",
      "type": "automaticApproval",
      "filePath": "C:\\Windows\\System32\\rundll32.exe",
      "fileHash": "sha256:a1b2c3d4...",
      "elevationType": "automatic",
      "childProcess": "deny"
    },
    {
      "displayName": "Installation logiciel approuve",
      "type": "supportApproved",
      "fileDescription": "*.msi files from approved publishers",
      "certificatePayload": {
        "publisherName": "CN=Contoso Software",
        "issuerName": "CN=Contoso CA"
      },
      "elevationType": "userAuthentication",
      "justificationRequired": true,
      "childProcess": "deny"
    }
  ]
}

7.3 Microsoft Tunnel et acces reseau

Microsoft Tunnel est la solution VPN gateway d'Intune qui fournit un acces securise aux ressources on-premises depuis les appareils mobiles geres. Deploye sous forme de conteneur Docker/Podman sur un serveur Linux, Tunnel supporte le split tunneling et le per-app VPN, permettant de limiter l'acces VPN aux seules applications qui necessitent une connexion aux ressources internes.

Dans une architecture Zero Trust, Tunnel s'integre avec Conditional Access pour exiger la conformite de l'appareil avant d'etablir la connexion VPN. Le Tunnel for MAM (disponible avec Intune Plan 2) etend cette capacite aux appareils non enrolles (BYOD), permettant aux applications gerees d'acceder aux ressources internes via un tunnel securise sans necessiter l'enrollment MDM complet de l'appareil.

8. Conditional Access : orchestration des decisions Zero Trust

8.1 Politiques Conditional Access essentielles

Conditional Access (acces conditionnel) est le moteur de decision Zero Trust de Microsoft Entra ID. Il evalue les signaux provenant d'Intune (conformite de l'appareil), de Entra ID Protection (risque utilisateur), de la localisation (Named Locations), et du type d'application client pour prendre une decision d'acces : Grant (autoriser), Block (bloquer), ou Grant with conditions (autoriser sous conditions). Les politiques suivantes constituent le socle minimal d'un deploiement Zero Trust :

[
  {
    "displayName": "ZT-CA-001 : Exiger appareil conforme pour M365",
    "conditions": {
      "applications": { "includeApplications": ["Office365"] },
      "users": { "includeGroups": ["All-Corporate-Users"] },
      "platforms": { "includePlatforms": ["windows", "macOS", "iOS", "android"] },
      "clientAppTypes": ["browser", "mobileAppsAndDesktopClients"]
    },
    "grantControls": {
      "operator": "AND",
      "builtInControls": [
        "compliantDevice",
        "mfa"
      ]
    },
    "sessionControls": {
      "signInFrequency": { "value": 12, "type": "hours" },
      "persistentBrowser": { "mode": "never" }
    }
  },
  {
    "displayName": "ZT-CA-002 : Bloquer legacy auth",
    "conditions": {
      "applications": { "includeApplications": ["All"] },
      "users": { "includeGroups": ["All-Users"] },
      "clientAppTypes": ["exchangeActiveSync", "other"]
    },
    "grantControls": {
      "builtInControls": ["block"]
    }
  },
  {
    "displayName": "ZT-CA-003 : MAM requis pour BYOD",
    "conditions": {
      "applications": { "includeApplications": ["Office365"] },
      "users": { "includeGroups": ["BYOD-Users"] },
      "platforms": { "includePlatforms": ["iOS", "android"] },
      "deviceState": {
        "excludeDeviceStates": ["compliant", "domainJoined"]
      }
    },
    "grantControls": {
      "operator": "OR",
      "builtInControls": [
        "approvedClientApp",
        "compliantApplication"
      ]
    }
  },
  {
    "displayName": "ZT-CA-004 : Bloquer high risk sign-in",
    "conditions": {
      "applications": { "includeApplications": ["All"] },
      "users": { "includeGroups": ["All-Users"] },
      "signInRiskLevels": ["high"]
    },
    "grantControls": {
      "builtInControls": ["block"]
    }
  },
  {
    "displayName": "ZT-CA-005 : Re-auth pour acces sensible",
    "conditions": {
      "applications": { 
        "includeApplications": ["Azure-Portal", "Graph-Explorer", "Intune-Admin"]
      },
      "users": { "includeGroups": ["IT-Admins"] }
    },
    "grantControls": {
      "builtInControls": ["mfa", "compliantDevice"],
      "operator": "AND"
    },
    "sessionControls": {
      "signInFrequency": { "value": 1, "type": "hours" }
    }
  }
]

9. Monitoring, Reporting et amelioration continue

9.1 Tableaux de bord de conformite

Le monitoring continu est un pilier du modele Zero Trust. Intune fournit plusieurs mecanismes de reporting pour suivre la posture de securite de l'ensemble de la flotte :

Device compliance dashboard : vue d'ensemble du taux de conformite global, par plateforme, par politique. Ce tableau de bord doit etre consulte quotidiennement par l'equipe SecOps. Un taux de conformite inferieur a 95% doit declencher une investigation.

Noncompliant devices report : liste detaillee des appareils non conformes avec les regles violees. Exportable en CSV pour analyse et suivi avec les equipes support.

Policy assignment failures : identification des politiques qui echouent a se deployer, souvent liee a des conflits de profils ou des problemes de connectivite.

# Script de reporting automatise - Conformite Zero Trust
# A executer quotidiennement via Azure Automation

Import-Module Microsoft.Graph.DeviceManagement
Connect-MgGraph -Scopes "DeviceManagementManagedDevices.Read.All"

# Rapport de conformite global
$allDevices = Get-MgDeviceManagementManagedDevice -All
$complianceStats = $allDevices | Group-Object ComplianceState

$report = @{
    Date = Get-Date -Format "yyyy-MM-dd"
    TotalDevices = $allDevices.Count
    Compliant = ($complianceStats | 
        Where-Object Name -eq "compliant").Count
    NonCompliant = ($complianceStats | 
        Where-Object Name -eq "noncompliant").Count
    InGracePeriod = ($complianceStats | 
        Where-Object Name -eq "inGracePeriod").Count
    Unknown = ($complianceStats | 
        Where-Object Name -eq "unknown").Count
    ComplianceRate = [math]::Round(
        (($complianceStats | Where-Object Name -eq "compliant").Count / 
        $allDevices.Count) * 100, 2
    )
}

# Alerter si le taux de conformite tombe sous 95%
if ($report.ComplianceRate -lt 95) {
    $alertBody = @"
ALERTE ZERO TRUST - Taux de conformite critique
Date: $($report.Date)
Taux: $($report.ComplianceRate)%
Appareils non conformes: $($report.NonCompliant)
"@
    
    # Envoi via Logic App ou Teams Webhook
    $webhookUrl = "https://contoso.webhook.office.com/..."
    $payload = @{
        text = $alertBody
    } | ConvertTo-Json
    
    Invoke-RestMethod -Uri $webhookUrl -Method Post `
        -Body $payload -ContentType "application/json"
}

# Rapport detaille des appareils non conformes
$nonCompliantDevices = $allDevices | 
    Where-Object ComplianceState -eq "noncompliant" |
    Select-Object DeviceName, UserPrincipalName, 
        OperatingSystem, OsVersion, 
        ComplianceState, LastSyncDateTime,
        @{N="DaysSinceSync"; E={
            (New-TimeSpan -Start $_.LastSyncDateTime -End (Get-Date)).Days
        }}

$nonCompliantDevices | Export-Csv `
    -Path "C:\Reports\NonCompliant-$(Get-Date -f 'yyyyMMdd').csv" `
    -NoTypeInformation -Encoding UTF8

9.2 Integration avec Microsoft Sentinel

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 detecter 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 deploiement Zero Trust via Intune, suivez ces indicateurs cles de performance (KPIs) :

KPI	Cible	Frequence	Source
Taux de conformite global	> 95%	Quotidien	Intune Dashboard
Chiffrement BitLocker/FileVault	100%	Hebdomadaire	Encryption Report
Appareils avec OS a jour	> 90%	Mensuel	Software Updates
Defender for Endpoint actif	100%	Quotidien	MDE Dashboard
Legacy auth bloquee	100%	Hebdomadaire	CA Report-Only
Baseline coverage	> 98%	Mensuel	Profile Assignment
Delai moyen de remediation	< 24h	Mensuel	Compliance Trends
Appareils avec admins locaux	0%	Mensuel	EPM Reports

10. Conclusion : feuille de route Zero Trust avec Intune

Le deploiement de Microsoft Intune dans une strategie Zero Trust n'est pas un projet ponctuel mais un processus iteratif d'amelioration continue. La maturite Zero Trust se construit par paliers, en commencant par les fondamentaux (enrollment, conformite de base, Conditional Access) avant d'evoluer vers des capacites avancees (EPM, Tunnel for MAM, integration Sentinel).

Voici la feuille de route recommandee en quatre phases :

Phase 1 - Fondations (Mois 1-2) : deploiement Intune pour tous les appareils Windows corporate, creation des politiques de conformite de base (chiffrement, antivirus, version OS), activation de Conditional Access avec exigence de conformite pour Microsoft 365, blocage de l'authentification legacy.

Phase 2 - Extension (Mois 3-4) : extension aux plateformes macOS, iOS et Android, deploiement des Security Baselines, configuration des politiques MAM pour le BYOD, mise en place d'Autopilot pour les nouveaux appareils, deploiement des regles ASR en mode Audit.

Phase 3 - Durcissement (Mois 5-6) : activation des regles ASR en mode Block, integration de Defender for Endpoint avec le signal de risque machine, deploiement d'Endpoint Privilege Management, configuration de Microsoft Tunnel, passage des politiques Conditional Access en mode strict.

Phase 4 - Excellence operationnelle (Mois 7+) : integration Sentinel pour la detection avancee, automatisation du reporting et des alertes, mise en place d'exercices de simulation (que se passe-t-il si un appareil est compromis ?), revue trimestrielle des politiques et ajustement des seuils, extension aux scenarios IoT et appareils specialises.

La securite des endpoints est un maillon essentiel de la chaine Zero Trust, mais elle ne fonctionne pas de maniere isolee. L'integration avec la protection de l'identite (Entra ID Protection), la securite des donnees (Microsoft Purview), la detection des menaces (Microsoft Defender XDR), et la conformite reglementaire forme un ecosysteme coherent ou chaque composant renforce les autres. Intune, en tant que gardien de la posture des endpoints, fournit le signal critique qui permet a l'ensemble de l'ecosysteme de prendre des decisions d'acces eclairees.

Articles connexes recommandes

Partagez cet Article

Cet article vous a ete utile ? Partagez-le avec votre reseau professionnel !

Partager sur X Partager sur LinkedIn Copier le Lien

Ressources & References Officielles

Documentations officielles Microsoft et ressources de reference

Microsoft Intune Documentation

learn.microsoft.com

Microsoft Zero Trust Framework

learn.microsoft.com

Conditional Access Documentation

learn.microsoft.com