Conformité AD & Azure : NIS2, ISO 27001, CIS

Qu'est-ce que la conformité AD et Azure ?

La conformité AD et Azure ne devient utile que lorsque les exigences des référentiels sont traduites en preuves de production. Dans les environnements construits sur Active Directory et Microsoft Entra ID, cela signifie prouver comment la politique de mot de passe, l'accès privilégié, le MFA, la journalisation d'audit, la gouvernance du cycle de vie et les contrôles d'accès tiers sont réellement appliqués.

La difficulté réside dans la traduction. Le texte des référentiels est volontairement de haut niveau, alors que les preuves techniques dont un auditeur ou un responsable sécurité a réellement besoin sont précises : quelle politique de mot de passe est active, quels comptes administrateurs détiennent encore un privilège permanent, quelles protections de connexion sont appliquées, quels journaux sont conservés, et quels chemins d'accès invité ou inter-tenant restent ouverts.

Cet article met en correspondance les exigences de conformité courantes avec des contrôles d'identité techniques qui peuvent être vérifiés dans AD et Azure, sans transformer l'exercice en un audit purement basé sur un tableur.

Comment cela fonctionne

Les revues de conformité centrées sur l'identité examinent généralement cinq domaines :

• La politique d'authentification, telle que la longueur des mots de passe, la complexité, le MFA et l'exposition aux protocoles hérités
• Le contrôle d'accès privilégié, tel que la portée des rôles d'administration, l'accès juste-à-temps et la gouvernance des comptes de secours (break-glass)
• L'audit et la surveillance, tels que la stratégie d'audit avancée sur les contrôleurs de domaine, les journaux d'audit Entra et la cadence de revue
• Le cycle de vie des accès, tel que le provisionnement, le nettoyage des comptes obsolètes et le déprovisionnement
• L'accès externe et applicatif, tel que la gouvernance des invités, le consentement applicatif et la confiance inter-tenant

Chaque domaine peut être traduit en un ensemble de contrôles techniques et de preuves associées.

Cartographie des référentiels de conformité AD et Azure

Directive NIS2

L'article 21(1) de NIS2 impose aux États membres de veiller à ce que les entités essentielles et importantes prennent des « mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées » pour gérer leurs risques de cybersécurité. Pour l'identité, cela se traduit généralement par les contrôles suivants :

CIS Controls v8.1

Les CIS Controls transforment le durcissement de l'identité en actions défensives priorisées. La numérotation suit les CIS Controls v8.1, la version actuelle, et reste inchangée par rapport à la v8 :

ISO 27001:2022

Les contrôles de l'Annexe A d'ISO 27001 les plus souvent mis en correspondance avec la sécurité de l'annuaire incluent :

Attentes de durcissement de l'annuaire de style ANSSI

Pour les organisations qui s'alignent sur les recommandations de style ANSSI, les thèmes pratiques liés à l'identité restent cohérents — voir le Guide ANSSI Active Directory : appliquer les recommandations de sécurité en pratique pour l'ensemble complet des recommandations :

• réduire l'authentification héritée et la cryptographie héritée là où la compatibilité applicative le permet
• isoler ou durcir les comptes privilégiés plutôt que de laisser les identités d'usage quotidien conserver un privilège permanent
• documenter les exceptions pour les systèmes hérités au lieu de les reconduire silencieusement de manière indéfinie
• valider que la surveillance, l'accès privilégié et les contrôles de mot de passe sont appliqués en production et non simplement déclarés dans une politique

L'évaluation des écarts de conformité

Étape 1 - Établir l'état de référence actuel

# Référence de la politique de mot de passe
Get-ADDefaultDomainPasswordPolicy |
  Select-Object MinPasswordLength, ComplexityEnabled, MaxPasswordAge

# Référence de l'accès conditionnel Entra
Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgIdentityConditionalAccessPolicy -All |
  Where-Object {$_.State -eq "enabled"} |
  Select-Object DisplayName, State

# Référence de la politique d'audit sur un contrôleur de domaine
auditpol /get /category:"Account Logon","DS Access","Account Management" |
  Select-String "Success|Failure"

Étape 2 - Cartographier les écarts vers des contrôles nommés

$policy = Get-ADDefaultDomainPasswordPolicy

# L'expiration du mot de passe n'est délibérément PAS notée comme un contrôle. Microsoft a retiré
# les politiques d'expiration de mot de passe de ses bases de référence de sécurité Windows en 2019 et qualifie
# l'expiration périodique de « mitigation ancienne et obsolète de très faible valeur ». Capturez MaxPasswordAge
# comme preuve, et ne le notez que lorsqu'un référentiel ou une politique interne impose encore la rotation.
$policy.MaxPasswordAge

$checks = @{
    "Min password length >= 14"   = $policy.MinPasswordLength -ge 14
    "Password complexity enabled" = $policy.ComplexityEnabled
    "DS Changes audit enabled"    = (auditpol /get /subcategory:"Directory Service Changes") -match "Success"
    "Kerberos audit enabled"      = (auditpol /get /subcategory:"Kerberos Authentication Service") -match "Success"
}

$checks.GetEnumerator() | ForEach-Object {
    [PSCustomObject]@{
        Control = $_.Key
        Status  = if ($_.Value) { "PASS" } else { "FAIL" }
    }
} | Format-Table -AutoSize

Étape 3 - Prioriser par exposition, pas par nombre de cases cochées

1. Critique : Pas de MFA pour les identités privilégiées, aucun contrôle sur les attributions de rôles à haut risque, délégation sans contrainte, principaux capables de DCSync
2. Élevé : Politique de mot de passe faible, couverture d'audit manquante, trop d'administrateurs permanents, gouvernance des invités faible
3. Moyen : Comptes obsolètes, LAPS manquant, processus de revue des rôles incomplet, contrôles granulaires manquants là où nécessaire
4. Faible : Lacunes de documentation, incohérences de nommage, problèmes de présentation non significatifs

Détection

Les preuves de conformité sont faibles si elles n'existent qu'au moment de l'audit. Les contrôles qui comptent doivent pouvoir être revus en continu.

Vérifications de conformité continues

# Dérive des groupes privilégiés au cours des 7 derniers jours, vérifiée sur chaque contrôleur de domaine.
# whenChanged n'est PAS répliqué - chaque DC conserve sa propre valeur - donc interroger un seul DC passe
# silencieusement à côté d'un changement écrit ailleurs.
$cutoff = (Get-Date).AddDays(-7)
foreach ($dc in (Get-ADDomainController -Filter *).HostName) {
    Get-ADGroup "Domain Admins" -Properties whenChanged -Server $dc |
      Where-Object {$_.whenChanged -gt $cutoff} |
      Select-Object @{Name="DC";Expression={$dc}}, Name, whenChanged
}

# Comptes activés inactifs depuis 90 jours ou plus.
# -Filter n'est pas un bloc de script PowerShell : il n'accepte que <attr> <opérateur> <valeur>, donc le
# seuil doit être calculé au préalable. LastLogonDate ne fait pas non plus partie du jeu de propriétés par
# défaut, il doit donc être demandé explicitement, sinon la colonne revient vide.
$inactive = (Get-Date).AddDays(-90)
Get-ADUser -Filter 'Enabled -eq $true -and LastLogonDate -lt $inactive' -Properties LastLogonDate |
  Select-Object SamAccountName, LastLogonDate

Remédiation

Séquence de remédiation prioritaire

1. Appliquer le MFA pour les comptes privilégiés et l'accès cloud sensible
2. Réduire le privilège permanent en revoyant les attributions de rôles et en utilisant l'élévation juste-à-temps lorsqu'elle est disponible
3. Activer la couverture d'audit sur les contrôleurs de domaine et dans Entra afin que les échecs de contrôle soient revus
4. Corriger l'hygiène des mots de passe, y compris la longueur, la complexité, les listes de mots de passe interdits et la prolifération des exceptions
5. Nettoyer les identités obsolètes et orphelines dans AD et Azure
6. Revoir l'accès invité et inter-tenant afin que l'accès des tiers soit gouverné
7. Documenter les exceptions justifiées avec propriétaire, motif et date de revue

Comment EtcSec détecte cela

EtcSec met en correspondance les résultats techniques avec les familles de contrôles les plus souvent référencées dans les travaux de conformité.

Chaque résultat pertinent aide à répondre à trois questions pratiques :

• quel contrôle d'identité est manquant ou faible
• quels comptes, rôles ou objets sont concernés
• quelles preuves l'équipe sécurité doit collecter pour prouver que l'écart est comblé

La catégorie Conformité est utile lorsque vous souhaitez transformer des résultats techniques bruts en un backlog de remédiation actionnable plutôt qu'en un tableur générique de référentiel.

Le dossier de preuves de conformité AD et Azure

Une revue de conformité solide échoue généralement pour deux raisons : le contrôle n'a jamais été implémenté en production, ou l'équipe ne peut pas prouver qu'il l'a été. Constituez un dossier de preuves qui résiste à la fois à une contestation interne et à un audit externe :

• la sortie actuelle de la politique de mot de passe et toute exception granulaire approuvée
• les exports des rôles privilégiés et des appartenances aux groupes privilégiés, y compris les attributions permanentes
• l'état de l'accès conditionnel ou des paramètres de sécurité par défaut pour le tenant concerné
• la sortie de la politique d'audit du contrôleur de domaine pour les sous-catégories sur lesquelles repose la détection
• les paramètres d'accès invité, inter-tenant et applicatif pour les populations couvertes par la revue
• le propriétaire, le motif d'exception et la date de revue pour tout ce qui ne peut toujours pas atteindre l'état cible

Ce dossier de preuves est ce qui transforme la conformité AD et Azure d'un exercice de présentation en une revue de contrôle reproductible.

Mener une seule revue au lieu de trois

Les organisations confrontées simultanément à NIS2, ISO 27001 et aux CIS Controls ont rarement besoin de trois cycles de revue distincts. Les trois référentiels convergent vers la même poignée de primitives d'identité — MFA, gouvernance des accès privilégiés, hygiène des mots de passe et couverture d'audit — de sorte qu'une seule revue technique peut produire des preuves qui satisfont les trois cartographies à la fois.

Une approche de séquencement pratique :

1. Construisez d'abord un socle de contrôle unique. Capturez une fois la politique de mot de passe, l'état de l'accès conditionnel, la sortie de la politique d'audit et l'appartenance aux groupes privilégiés. Chaque cartographie de référentiel ci-dessus s'appuie sur la même poignée de points de données.
2. Étiquetez les résultats par rapport à chaque référentiel qu'ils satisfont, pas seulement un seul. Un unique écart de MFA sur un compte d'administrateur global constitue simultanément un écart NIS2 article 21(2)(j), un écart CIS Control 6 et un écart ISO 27001 A.8.5. L'enregistrer une seule fois avec plusieurs étiquettes évite de recollecter trois fois la même preuve.
3. Priorisez par valeur pour l'attaquant, puis complétez la paperasse. Corriger d'abord les écarts à plus forte exposition — délégation sans contrainte, comptes capables de DCSync, accès Administrateur Global permanent sans MFA — referme des constats sur les trois référentiels avant même qu'une seule case de conformité soit cochée.
4. Conservez la documentation des exceptions à un seul endroit. Une application héritée incapable de prendre en charge le MFA est une seule fiche d'exception avec un seul propriétaire et une seule date de revue, pas trois justifications distinctes déposées auprès de trois référentiels différents.

Ce séquencement compte surtout pour les équipes qui ont hérité du travail de conformité comme effet secondaire d'une revue de sécurité, plutôt que pour les équipes partant d'un document de référentiel vierge. Les preuves techniques sous-jacentes — politique de mot de passe, couverture d'audit, état des accès privilégiés — ne changent pas selon le référentiel qui les demande.

Les écarts récurrents qui reviennent chaque trimestre

Même les équipes matures ont tendance à rouvrir les mêmes écarts de conformité liés à l'identité :

• des exceptions d'applications héritées qui préservent silencieusement une authentification faible
• des identités privilégiées obsolètes qui n'ont jamais été retirées après un projet ou un changement de personnel
• des exclusions d'accès conditionnel ajoutées pendant un incident et jamais revues
• des chemins d'accès invité qui restent plus larges que ce que la politique écrite autorise
• des contrôles de surveillance qui ont été documentés une fois mais qui ne sont plus validés sur les contrôleurs de domaine actuels ou le périmètre actuel du tenant

Si ces écarts ne sont pas suivis comme une dette opérationnelle avec un propriétaire désigné, la cartographie du référentiel paraîtra saine alors que la surface d'attaque reste largement inchangée.

Pour aller plus loin

Pour l'aspect technique de ces mêmes familles de contrôles, consultez Acces Privilegie Azure : Trop d'Admins Globaux, Azure Identity Protection : Bloquer les Identifiants Divulgués, Audit de sécurité Active Directory : quoi vérifier d'abord et comment prouver la remediation, et Applications Azure Sur-Privilegiees dans Votre Tenant. Ces articles aident à transformer le langage des référentiels en étapes concrètes de durcissement et de validation.