Comment auditer Active Directory dans un environnement air-gapped

Comment auditer Active Directory dans un environnement air-gapped sans faux sentiment de securite

Si vous cherchez comment auditer Active Directory dans un environnement air-gapped, commencez par une question de perimetre, pas par une question d'outil. Beaucoup d'equipes disent « air-gapped » alors qu'elles veulent en realite dire « sans acces Internet direct », « isole logiquement » ou « fortement segmente ». Cette distinction compte, car votre methode d'audit, votre chaine de preuve et les controles acceptables changent selon le vrai modele de connectivite.

Le guide de mise en oeuvre de la CISA pour la directive BOD 23-01 pose une limite utile : de nombreux environnements presentes comme air-gapped ne sont en realite qu'isoles logiquement, et tout systeme directement connecte a l'environnement operationnel, ou connecte a un autre systeme qui lui-meme y est connecte, n'est pas traite comme physiquement air-gapped dans ce cadre. Pour un audit Active Directory, c'est une regle pratique valable : ne supposez pas l'isolement simplement parce qu'un reseau n'a pas de sortie web directe.

Cet article emploie des termes d'audit pratiques plutot que de pretendre qu'il existe une taxonomie universelle imposée par un editeur :

Le sujet n'est pas semantique. Le sujet est d'eviter un faux sentiment de securite. Une foret Active Directory isolee peut toujours accumuler de la derive de privileges, une delegation dangereuse, des reglages de protocole faibles, des comptes privilegies obsoletes, des chemins GPO modifiables, des templates de certificats exposes ou une politique d'audit insuffisante. Si l'annuaire change, il doit toujours etre mesure.

Pourquoi l'isolement ne supprime pas le risque AD

L'isolement reduit certains chemins d'attaque externes, mais il ne supprime pas le risque identite a l'interieur de la frontiere que vous devez toujours defendre. Active Directory continue de porter les groupes privilegies, les reglages Kerberos, les relations d'approbation, la delegation, les ACL, la Group Policy et souvent les services de certificats. Ces plans de controle restent critiques pour la securite, meme si l'environnement ne touche jamais un service SaaS public.

C'est pour cela qu'un environnement isole a toujours besoin de la meme discipline de revue que celle decrite dans Audit de securite Active Directory : checklist pratique. Les groupes privilegies continuent d'accumuler des exceptions, les anciens comptes de service survivent encore aux migrations, et les permissions annuaire derivent toujours entre deux nettoyages. Si vous faites deja des revues periodiques, la meme lecon que dans Audit Active Directory recurrent : pourquoi les audits annuels deviennent obsoletes et comment surveiller la posture en continu s'applique encore plus fortement dans les reseaux isoles : un nettoyage ponctuel ne reste pas correct tout seul.

Le guide ANSSI 2023 sur l'administration securisee des SI reposant sur AD est utile ici, parce qu'il ne traite pas Active Directory comme un annuaire statique. Il le traite comme un plan d'administration qui doit etre cloisonne, supervise et gouverne avec rigueur. En pratique, cela signifie qu'un AD air-gapped ou isole doit toujours etre evalue comme un plan de controle vivant, pas comme un ilot legacy qui serait soudainement plus sur simplement parce qu'il est plus difficile a atteindre depuis Internet.

Ce que vous pouvez auditer sans acces Internet

Une revue hors ligne bien cadree peut couvrir la majeure partie de la surface de controle qui compte vraiment dans un environnement AD :

• Structure d'identite et de privilege : groupes privilegies, groupes imbriques, droits delegues, principals capables de faire DCSync, administrateurs obsoletes, comptes de service et anomalies de proprietaire.
• Reglages de securite annuaire : LDAP signing, channel binding, exposition NTLM, SMB signing, SMBv1, cached logons, politique Kerberos, deploiement de LAPS et configuration des trusts.
• Integrite Group Policy et SYSVOL : liaisons GPO, security filtering, heritage de permissions, exposition de mots de passe dans SYSVOL et hardened UNC paths.
• Visibilite des changements : verification que la politique d'audit, l'architecture de collecte d'evenements et le modele de retention sont reellement suffisants pour detecter localement les changements critiques AD.
• AD CS, s'il existe : exposition du role CA, risque sur les certificate templates, surfaces d'enrollment et problemes de strong certificate binding.

C'est pour cela que l'audit offline d'Active Directory n'est pas seulement possible ; il est souvent plus concret que ce que les equipes imaginent. Microsoft documente que les donnees AD sont accessibles via les protocoles annuaire et que Group Policy est partagee entre des metadonnees dans l'annuaire et un contenu fichier dans SYSVOL. Cela signifie qu'un audit offline serieux ne se limite pas a des captures d'ecran ou a des entretiens ponctuels avec des administrateurs. Il peut collecter des preuves directement depuis l'annuaire et les partages de fichiers associes.

Sources de donnees a collecter localement

L'audit hors ligne le plus fiable s'appuie sur plusieurs sources de donnees locales, car aucune source unique ne repond a toutes les questions.

Deux details sont faciles a manquer.

Premier point : la documentation Microsoft sur Group Policy est importante, car chaque GPO possede a la fois des donnees dans l'annuaire et un composant fichier dans SYSVOL. Si vous interrogez uniquement LDAP, vous perdez une partie de la surface de policy. C'est l'une des raisons pour lesquelles les audits offline sous-estiment souvent le risque autour des scripts, des fichiers de preferences ou de l'integrite des chemins de policy.

Deuxieme point : utilisez LDAPS plutot que de supposer que le LDAP en clair est acceptable parce que l'environnement est interne. La documentation actuelle du collector EtcSec est explicite sur ce point en mode standalone : ldaps:// est le chemin supporte et recommande pour la collecte AD, alors que le LDAP non chiffre n'est pas la base supportee en production.

Construire un workflow d'audit offline robuste

Un workflow hors ligne defensible repose surtout sur la repetabilite.

1. Definir exactement la frontiere de confiance

Documentez si l'environnement est physiquement air-gapped, isole logiquement ou simplement deconnecte de l'Internet public. Si l'export de donnees est possible via un jump host, un broker ou un processus de transfert manuel, notez-le. Le rapport d'audit doit expliquer le modele de connectivite, car les hypotheses de revue en dependent.

2. Collecter depuis un hote local de confiance

Executez le moteur d'audit depuis un hote situe dans la meme frontiere de confiance que l'annuaire revu. Evitez les laptops d'administration improvises. Utilisez si possible un hote de revue dedie et gardez la configuration du collector ainsi que les sorties sous controle de changement.

3. Collecter ensemble les preuves annuaire et SYSVOL

Ne separez pas la revue identite de la revue GPO. Dans un AD isole, certaines derives les plus dangereuses operationnellement vivent dans la relation entre objets annuaire et contenu de policy stocke sous forme de fichiers. C'est pour cela que des articles comme Attaques NTLM relay : detection et prevention et SMB signing desactive : pourquoi cela permet encore le NTLM relay restent pertinents dans les environnements « offline » : l'exposition sous-jacente aux protocoles et aux chemins de fichiers est locale, pas dependante d'Internet.

4. Preserver un snapshot comparable

Conservez la date d'audit, la liste des domain controllers atteints, l'information indiquant si tous les domaines attendus etaient inclus et si AD CS ou les trusts etaient dans le scope. Un rapport sans contexte de collecte est difficile a comparer plus tard. Si vous voulez que les remediations tiennent, il vous faut une baseline propre avant/apres, pas un PDF exporte une seule fois sans metadonnees de collecte.

5. Re-mesurer apres nettoyage

Une fois les findings corriges, relancez exactement le meme perimetre et comparez les memes classes de preuves. C'est la seule maniere fiable de prouver que la derive de privileges, le durcissement des protocoles ou le nettoyage des policies ont reellement tenu apres la fenetre de changement.

Journalisation et detection dans un AD isole

Offline ne veut pas dire invisible. Cela veut dire que votre visibilite doit etre pensee localement.

La documentation Microsoft sur Windows Event Forwarding est utile ici parce qu'elle precise ce que WEF fait reellement et ce qu'il ne fait pas. WEF peut transferer des evenements de sources vers un collecteur, mais il reste passif vis-a-vis de la generation d'evenements. Il n'active pas a votre place les bonnes sous-categories d'audit, et il ne redimensionne pas les journaux pour vous. Si les domain controllers ne journalisent pas les bons evenements, un Windows Event Collector local ne fera que centraliser plus vite des preuves incompletes.

C'est pour cela que la configuration des advanced audit policies doit faire partie de la revue elle-meme. Microsoft recommande aussi une planification et une validation pilote avant un deploiement large, car les vraies questions sont le volume d'evenements, l'utilite operationnelle et la capacite des equipes a comprendre les evenements qu'elles collectent.

Pour une revue AD isolee, demarrez avec une baseline locale de detection volontairement resserree :

Il ne s'agit pas de detections basees sur un seul event. Ce sont des classes de preuves a correler avec votre inventaire et votre baseline attendue. Si votre policy dit que personne ne doit obtenir des droits equivalents a DCSync et qu'aucun groupe privilegie ne doit changer hors fenetre controlee, vos logs doivent etre capables de soutenir cette affirmation localement.

Si vous avez besoin d'une cartographie plus detaillee des evenements, Supervision securite AD : evenements cle a surveiller va beaucoup plus loin cote journalisation de securite Windows.

Findings a prioriser dans un AD air-gapped

Un environnement isole ne devrait pas vraiment changer votre ordre de priorite. Il devrait changer votre methode de collecte.

Derive de privileges et chemins d'admin obsoletes

Commencez par les memes questions que dans Derive des acces privilegies Active Directory : comment les droits admin reviennent apres les audits et Comptes obsoletes et sur-privilegies dans AD : qui est effectivement privilegie aujourd'hui, comment cet acces a ete obtenu et est-ce que cet acces serait encore approuve s'il etait revu maintenant ?

Cela inclut :

• l'appartenance directe et imbriquee aux groupes privilegies
• les comptes capables de faire DCSync
• les droits delegues donnant GenericAll, WriteDACL, WriteOwner ou des chemins d'escalade equivalents
• la derive liee a AdminSDHolder
• les comptes desactives ou dormants qui conservent encore une appartenance a des groupes privilegies

Durcissement des protocoles et surface de relay

Ensuite, priorisez les reglages de protocole qui restent dangereux meme dans des reseaux isoles :

• LDAP signing et channel binding
• SMB signing
• exposition SMBv1
• reglages NTLM et fallback inutile
• weak certificate mapping ou issuance de certificats dangereuse si AD CS existe

Les environnements offline conservent souvent des reglages legacy plus longtemps parce que les fenetres de changement sont plus difficiles et que les tests d'interoperabilite sont plus lents. Cela ne rend pas l'exposition moins reelle.

Hygiene des mots de passe des administrateurs locaux

Les mots de passe d'administrateurs locaux partages restent un probleme de mouvement lateral dans des estates Windows isoles. Windows LAPS non deploye : pourquoi les mots de passe admin locaux partages restent dangereux reste pertinent ici parce que le risque porte sur la reutilisation locale d'identifiants entre systemes, pas sur la connectivite Internet.

Kerberos, comptes de service et delegation

Les comptes de service, les anciens SPN, la delegation contrainte ou non contrainte et une posture de chiffrement faible restent aussi des verifications prioritaires dans un AD isole. Si l'environnement contient des serveurs legacy metier, la probabilite de retrouver d'anciens patterns de comptes de service est souvent plus elevee, pas plus faible.

Remediation et validation sans dependance cloud

Dans un AD air-gapped, la remediation doit etre mise en oeuvre comme n'importe quel autre changement d'identite Windows a haut risque : corriger la condition dangereuse, relancer la meme collecte de preuves et prouver le resultat dans la meme frontiere.

⚠️ Avertissement : ne traitez pas les rapports exportables comme une preuve en eux-memes. Un rapport n'est defensible que si le perimetre de collecte, les droits de collecte et la methode de rerun sont assez stables pour etre compares dans le temps.

Une sequence pratique ressemble a ceci :

1. Supprimer ou reduire d'abord les chemins de privilege les plus risqués : comptes privilegies obsoletes, ACL dangereuses, droits DCSync inutiles, delegation dangereuse et reglages de protocole faibles.
2. Reverifier l'integrite GPO et SYSVOL apres chaque changement de protocole ou de policy, surtout si vous avez touche SMB, hardened UNC paths ou des administrative templates.
3. Valider que la politique d'audit locale couvre toujours les changements qui vous interessent et que votre architecture WEF/WEC les capture toujours lorsqu'elle est utilisee.
4. Relancer exactement le meme perimetre d'audit et comparer les findings avant/apres plutot que de faire confiance a des controles manuels ponctuels.
5. Documenter ce qui reste volontairement accepte pour des raisons operationnelles, surtout dans les environnements isoles legacy ou les travaux de compatibilite prennent plus de temps.

Ce dernier point compte. Dans les environnements isoles, les exceptions sont souvent justifiees comme temporaires. Si vous ne les documentez pas avec un owner et une date de revue, elles deviennent de l'architecture permanente.

Comment EtcSec prend en charge les audits AD air-gapped

Pour ce cas d'usage, la frontiere produit importante est simple : le mode standalone du collector EtcSec ne depend pas d'un service SaaS. La documentation locale decrit un mode serveur standalone dans lequel le collector tourne dans votre environnement et communique localement avec Active Directory, y compris via LDAP ou LDAPS pour les donnees annuaire et via SMB vers SYSVOL pour la revue Group Policy.

C'est important dans les environnements isoles, car l'audit peut rester dans la meme frontiere de confiance que l'annuaire qui est revu. Pour une evaluation AD uniquement, vous pouvez garder le perimetre local sans supposer un acces sortant vers des services cloud.

Quand l'environnement est pret pour une mesure de posture, les checks EtcSec les plus utiles dans ce contexte sont ceux qui prouvent la sante des controles locaux, pas une exposition Internet generique. On peut citer par exemple LDAP_SIGNING_DISABLED, SMB_SIGNING_DISABLED, LAPS_NOT_DEPLOYED, DCSYNC_CAPABLE, ACL_GENERICALL, KERBEROASTING_RISK et ADMIN_SD_HOLDER_MODIFIED.

Le point cle n'est pas qu'un AD air-gapped aurait besoin d'un standard de revue different. Le point cle est que le workflow de collecte et de validation doit pouvoir s'executer localement, etre rejoue localement et etre compare localement.

Controles associes

• chemins d'administration dedies et hygiene des postes d'administration privilegiee
• enforcement de LDAP signing, channel binding et SMB signing
• deploiement de Windows LAPS et rotation des mots de passe admin locaux
• revue des acces privilegies et suppression des chemins d'admin obsoletes
• architecture WEF/WEC plus advanced audit policy validee sur les DC
• revue de l'integrite GPO et SYSVOL
• revue AD CS lorsque les services de certificats existent
• re-mesure recurrente plutot que nettoyage ponctuel

References primaires

• CISA: BOD 23-01 Implementation Guidance
• Microsoft Open Specifications: MS-ADOD
• Microsoft Open Specifications: MS-GPOD
• Microsoft Learn: Use Windows Event Forwarding to Assist in Intrusion Detection
• Microsoft Learn: Planning and Deploying Advanced Security Audit Policies
• Microsoft Learn: Advanced Audit Policy Configuration Settings
• Microsoft Learn: 4719 System Audit Policy Was Changed
• Microsoft Learn: 5136 A Directory Service Object Was Modified
• Microsoft Learn: 4662 An Operation Was Performed on an Object
• Microsoft Learn: Active Directory Domain Services LDAP Signing Requirements
• ANSSI: Recommandations pour l'administration securisee des SI reposant sur AD
• NIST SP 800-53 Rev. 5