Intune : éviter les conflits entre Security Baseline, ASR, Defender et pare-feu

Position recommandée

Les baselines contiennent des device configuration settings issus des CSP. Endpoint Security et Settings Catalog peuvent exposer les mêmes nœuds. Les conflits entre configuration policies demandent une résolution manuelle.

Pour ASR, les settings non conflictuels peuvent être fusionnés en superset tandis que les règles contradictoires sont retenues. Je ne compte pas sur cette fusion comme modèle de gouvernance.

Je recommande audit puis warn/block par règle ASR, policies Defender/Firewall dédiées, et baseline personnalisée uniquement sur les settings sans autre propriétaire. Chaque version de baseline passe par diff et pilote.

Les baselines contiennent des device configuration settings issus des CSP. Endpoint Security et Settings Catalog peuvent exposer les mêmes nœuds. Les conflits entre configuration policies demandent une résolution manuelle.

Besoin, cas d’usage et périmètre de la recommandation

Une baseline est un ensemble de profils et non une priorité supérieure. Ses valeurs doivent être comparées à celles d’Endpoint Security, Settings Catalog et GPO avant affectation.

Je construis une matrice setting/CSP/propriétaire/valeur/audience. Not configured signifie que cette policy ne possède pas le setting; cela ne désactive pas nécessairement une autre source.

ASR supporte un merge des règles non conflictuelles, mais une règle avec deux actions contradictoires n’est pas ajoutée au superset. Le reporting per-setting permet de la retrouver.

Critères de décision et options possibles

Pour Architecture des policies de sécurité Intune, je commence par trois résultats concrets: Exporter les settings existants, Attribuer un propriétaire par CSP et Passer ASR audit puis enforcement. Ils doivent être observables avant de comparer les méthodes disponibles.

L’architecture cible suit Baseline → Endpoint → CSP → Telemetry. Chaque composant a un propriétaire clair, un état vérifiable et une méthode de retour arrière; cette répartition évite qu’une seconde politique masque le résultat de la première.

Le pilote contrôle notamment Exporter les settings existants, Attribuer un propriétaire par CSP et Passer ASR audit puis enforcement. La généralisation ne commence qu’après une période stable et après vérification des exceptions propres aux populations visées.

La recommandation devient mesurable lorsqu’elle relie le besoin à une cible vérifiable. Les résultats attendus sont Exporter les settings existants, Attribuer un propriétaire par CSP et Passer ASR audit puis enforcement. Les responsabilités se répartissent ainsi: Baseline: Posture de référence versionnée. Endpoint: Policies dédiées AV, ASR et Firewall. CSP: Windows calcule les settings effectifs. Telemetry: Per-setting, Defender et événements. Cette répartition permet d’attribuer chaque écart au bon propriétaire et d’éviter qu’un second profil, une ancienne autorité ou une exception silencieuse ne produise un résultat apparemment correct mais impossible à exploiter dans la durée.

Les écarts « Conflict per-setting », « ASR ne bloque pas », « Application bloquée » et « DO/VPN cassé » servent de tests de décision. Pour chacun, la preuve indiquée dans la matrice doit permettre de choisir entre correction, exception temporaire et retour arrière. Le pilote surveille également les points suivants: preview baseline hors production, Not configured n’efface pas autre source, exclusions ASR minimales et tester VDI séparément. La valeur cible, le mode de distribution, les contrôles et la sortie de secours sont ainsi évalués ensemble.

Architecture cible et répartition des responsabilités

Une baseline est un ensemble de profils et non une priorité supérieure. Ses valeurs doivent être comparées à celles d’Endpoint Security, Settings Catalog et GPO avant affectation.

Je construis une matrice setting/CSP/propriétaire/valeur/audience. Not configured signifie que cette policy ne possède pas le setting; cela ne désactive pas nécessairement une autre source.

ASR supporte un merge des règles non conflictuelles, mais une règle avec deux actions contradictoires n’est pas ajoutée au superset. Le reporting per-setting permet de la retrouver.

Prérequis, gouvernance et préparation

La préparation de Architecture des policies de sécurité Intune couvre inventaire de toutes les policies sécurité, Defender onboarding/télémétrie, matrice de propriété, applications critiques et flux réseau, groupes pilote. Le propriétaire de chaque composant et la population pilote sont définis avant la création de la configuration.

L’état initial est mesuré avec Exporter les settings existants. Attribuer un propriétaire par CSP. Passer ASR audit puis enforcement. Tester les trois profils firewall. Il servira de point de comparaison pendant le pilote et lors d’un éventuel retour arrière.

• inventaire de toutes les policies sécurité
• Defender onboarding/télémétrie
• matrice de propriété
• applications critiques et flux réseau
• groupes pilote
• processus d’exclusion
• rollback version baseline

Fonctionnement détaillé et frontières de responsabilité

Une baseline est un ensemble de profils et non une priorité supérieure. Ses valeurs doivent être comparées à celles d’Endpoint Security, Settings Catalog et GPO avant affectation.

Je construis une matrice setting/CSP/propriétaire/valeur/audience. Not configured signifie que cette policy ne possède pas le setting; cela ne désactive pas nécessairement une autre source.

ASR supporte un merge des règles non conflictuelles, mais une règle avec deux actions contradictoires n’est pas ajoutée au superset. Le reporting per-setting permet de la retrouver.

• inventaire de toutes les policies sécurité
• Defender onboarding/télémétrie
• matrice de propriété
• applications critiques et flux réseau

Mise en œuvre, exploitation et cas limites

Les règles ASR commencent en Audit pour capturer les applications concernées, puis Warn lorsque pertinent et Block après traitement des exclusions. Les exclusions sont ciblées et datées.

Le firewall nécessite profils Domain/Private/Public, merge des règles locales et MDM, et tests Delivery Optimization, VPN, support et applications serveur. Une baseline stricte peut empêcher un merge attendu.

Lors d’une nouvelle baseline, je compare les versions, classe nouveaux/retirés/modifiés et migre un groupe pilote. Je ne clique pas Update sans mesurer les écarts.

• Comparer versions de baseline
• Analyser conflits per-setting
• Mesurer incidents et exceptions

Méthode de validation à l’échelle du parc

Pour architecture des policies de sécurité intune, je constitue un échantillon qui couvre au minimum deux modèles matériels, plusieurs profils utilisateur, un site réseau contraint et les exceptions métier connues. Un résultat homogène sur des machines de laboratoire identiques ne démontre pas la robustesse de la configuration.

Les mesures portent sur Exporter les settings existants. Attribuer un propriétaire par CSP. Passer ASR audit puis enforcement. Tester les trois profils firewall. Elles sont définies avant le pilote de Architecture des policies de sécurité Intune afin que les seuils ne soient pas déplacés après l’observation.

Les cas « Conflict per-setting », « ASR ne bloque pas », « Application bloquée », « DO/VPN cassé » servent de scénarios négatifs. Ils vérifient que l’échec reste visible, localisable et associé à une correction précise.

La généralisation de Architecture des policies de sécurité Intune tient compte de preview baseline hors production, Not configured n’efface pas autre source, exclusions ASR minimales, tester VDI séparément. Chaque vague se ferme après lecture de ces points et validation du retour à l’état connu.

Configuration recommandée et déploiement par étapes

La méthode retenue pour Architecture des policies de sécurité Intune se déploie par les étapes « Mesurer l’état initial », « Configurer le pilote », « Observer les indicateurs », « Décider la vague suivante ». Chaque passage produit un résultat vérifiable avant l’ouverture du suivant.

Paramètres, commandes et automatisation

Les commandes et valeurs de cette section servent à vérifier Exporter les settings existants. Attribuer un propriétaire par CSP. Passer ASR audit puis enforcement. Tester les trois profils firewall. Chaque exemple précise l’état attendu et les éléments à comparer dans le service.

Le contexte d’exécution, les permissions et les effets sur Baseline, Endpoint, CSP, Telemetry doivent rester explicites lorsque la configuration est automatisée.

# Collecte de diagnostic
$ErrorActionPreference = 'Stop'
try {
 Get-MpPreference | Select-Object AttackSurfaceReductionRules_Ids,AttackSurfaceReductionRules_Actions
 Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction,DefaultOutboundAction,AllowLocalFirewallRules
 Get-MpComputerStatus | Select-Object AMRunningMode,AntivirusEnabled,RealTimeProtectionEnabled
}
catch { Write-Error "Collecte sécurité impossible : $($_.Exception.Message)"; exit 1 }

Validation, indicateurs et critères GO / NO-GO

La décision repose sur Exporter les settings existants, Attribuer un propriétaire par CSP, Passer ASR audit puis enforcement et Tester les trois profils firewall. Ces indicateurs couvrent le résultat technique, l’état du service et l’effet réel sur la population pilote.

• Exporter les settings existants.
• Attribuer un propriétaire par CSP.
• Passer ASR audit puis enforcement.
• Tester les trois profils firewall.
• Comparer versions de baseline
• Analyser conflits per-setting
• Mesurer incidents et exceptions

Exploitation, journaux et contrôle continu

La chronologie de Architecture des policies de sécurité Intune relie Baseline, Endpoint, CSP, Telemetry. Les heures et identifiants communs indiquent si les informations décrivent la même tentative.

Les états sont lus à partir de Exporter les settings existants. Attribuer un propriétaire par CSP. Passer ASR audit puis enforcement. Tester les trois profils firewall. Cette séquence sépare une absence de configuration d’un traitement en attente ou d’un échec confirmé.

Les causes « Deux policies contradictoires », « Règle retenue par conflit », « Règle ASR légitime », « Firewall merge/règle » restent des hypothèses jusqu’à ce que la preuve indiquée dans la matrice les confirme.

• Exporter les settings existants.
• Attribuer un propriétaire par CSP.
• Passer ASR audit puis enforcement.
• Tester les trois profils firewall.
• Comparer versions de baseline
• Analyser conflits per-setting
• Mesurer incidents et exceptions

Exceptions, erreurs connues et traitement

Les exceptions à prévoir pour Architecture des policies de sécurité Intune apparaissent notamment sous la forme Conflict per-setting, ASR ne bloque pas, Application bloquée, DO/VPN cassé. La preuve associée indique s’il faut corriger la configuration ou conserver une exception documentée.

Coût de maintien des exceptions

Une exception à Architecture des policies de sécurité Intune crée une charge récurrente: elle doit être identifiée, surveillée et réévaluée jusqu’à sa suppression. Sans propriétaire ni date de revue, cette charge finit par devenir une configuration parallèle difficile à tester.

Rollback, gestion du changement et points de vigilance

Le rollback de Architecture des policies de sécurité Intune restaure explicitement l’affectation, la valeur ou l’autorité précédente. Les actions et points de vigilance ci-dessous précisent ce qui doit être contrôlé après ce retour.