Active Directory in einer Air-Gapped-Umgebung auditieren

Active Directory in einer Air-Gapped-Umgebung auditieren, ohne falsche Sicherheit anzunehmen

Wenn Sie wissen muessen, wie man Active Directory in einer Air-Gapped-Umgebung auditieren kann, beginnen Sie mit einer Scope-Frage und nicht mit einer Tool-Frage. Viele Teams sagen « air-gapped », wenn sie in Wirklichkeit « kein direkter Internetzugang », « logisch isoliert » oder « stark segmentiert » meinen. Diese Unterscheidung ist wichtig, weil sich Audit-Methode, Nachweiskette und akzeptable Kontrollen je nach realem Konnektivitaetsmodell aendern.

Die Umsetzungsleitlinie der CISA zu BOD 23-01 zieht hier eine nuetzliche Grenze: Viele Umgebungen, die als air-gapped beschrieben werden, sind in Wahrheit nur logisch isoliert, und jedes System, das direkt mit der Betriebsumgebung verbunden ist oder ueber ein anderes verbundenes System Zugang dorthin hat, gilt in dieser Leitlinie nicht als physisch air-gapped. Fuer ein Active-Directory-Audit ist das eine brauchbare Betriebsregel: Gehen Sie nicht allein deshalb von Isolation aus, weil ein Netz keinen direkten Webzugang hat.

Dieser Artikel verwendet praktische Audit-Begriffe, statt eine angeblich universelle Hersteller-Taxonomie zu behaupten:

Es geht nicht um Semantik. Es geht darum, falsche Sicherheit zu vermeiden. Eine isolierte Active-Directory-Forest kann weiterhin Privilege Drift, unsichere Delegation, schwache Protokolleinstellungen, veraltete privilegierte Konten, beschreibbare GPO-Pfade, exponierte Zertifikatvorlagen oder eine schwache Audit-Policy enthalten. Wenn sich das Verzeichnis aendert, muss es weiterhin gemessen werden.

Warum Isolation das AD-Risiko nicht entfernt

Isolation reduziert einige externe Angriffspfade, beseitigt aber nicht das Identitaetsrisiko innerhalb der Grenze, die Sie weiterhin verteidigen muessen. Active Directory enthaelt weiterhin privilegierte Gruppen, Kerberos-Einstellungen, Vertrauensstellungen, Delegation, ACLs, Group Policy und oft auch Zertifikatsdienste. Diese Control Planes bleiben sicherheitskritisch, selbst wenn die Umgebung nie mit einem oeffentlichen SaaS-Dienst spricht.

Deshalb braucht auch eine isolierte Umgebung dieselbe grundlegende Review-Disziplin wie in Active Directory sicher auditieren: praktische Checkliste. Privilegierte Gruppen sammeln weiterhin Ausnahmen an, alte Servicekonten ueberleben Migrationen und Verzeichnisberechtigungen driften zwischen zwei Bereinigungen weiter. Wenn Sie bereits periodische Reviews fahren, gilt dieselbe Lehre wie in Wiederkehrendes Active Directory Audit: Warum jaehrliche Audits schnell veralten und wie kontinuierliches Posture Monitoring funktioniert in isolierten Netzen sogar noch staerker: Ein einmaliges Cleanup bleibt nicht von selbst korrekt.

Die ANSSI-Leitlinie von 2023 zur sicheren Administration von Systemen auf Basis von Active Directory ist hier nuetzlich, weil sie AD nicht als statisches Verzeichnis behandelt. Sie behandelt es als Administrationsplane, die mit Disziplin segmentiert, ueberwacht und gesteuert werden muss. Praktisch bedeutet das: Ein air-gapped oder isoliertes AD sollte weiterhin als lebendige Control Plane bewertet werden und nicht als Legacy-Insel, die automatisch sicherer waere, nur weil sie vom Internet schwerer erreichbar ist.

Was sich ohne Internetzugang auditieren laesst

Ein sauber abgegrenztes Offline-Review kann den groessten Teil der wirklich relevanten Control Surface in einer AD-Umgebung abdecken:

• Identitaets- und Privilegstruktur: privilegierte Gruppen, verschachtelte Gruppen, delegierte Rechte, DCSync-faehige Principals, veraltete Administratoren, Servicekonten und Ownership-Anomalien.
• Verzeichnissicherheits-Einstellungen: LDAP signing, channel binding, NTLM-Exposure, SMB signing, SMBv1, cached logons, Kerberos-Policy, LAPS-Rollout und Trust-Konfiguration.
• Group-Policy- und SYSVOL-Integritaet: GPO-Links, security filtering, Permission-Vererbung, Passwort-Exposure in SYSVOL und hardened UNC paths.
• Change Visibility: Ob Audit-Policy, Event-Forwarding-Design und Retention-Modell wirklich ausreichen, um kritische AD-Aenderungen lokal zu erkennen.
• AD CS, falls vorhanden: Exponierung der CA-Rolle, Risiko durch certificate templates, Enrollment-Flaechen und Probleme mit strong certificate binding.

Genau deshalb ist ein Offline-AD-Audit nicht nur moeglich; es ist oft belastbarer, als viele Teams erwarten. Microsoft dokumentiert, dass AD-Daten ueber Verzeichnisprotokolle zugreifbar sind und dass Group Policy zwischen Verzeichnis-Metadaten und dateibasierten Inhalten in SYSVOL aufgeteilt ist. Das bedeutet, dass ein ernsthaftes Offline-Audit nicht auf Screenshots oder punktuelle Admin-Interviews beschraenkt ist. Es kann Evidenz direkt aus dem Verzeichnis und den dazugehoerigen Dateifreigaben erheben.

Welche lokalen Datenquellen Sie erfassen sollten

Das verlaesslichste Offline-Audit nutzt mehrere lokale Datenquellen, weil keine einzelne Quelle jede Frage beantwortet.

Zwei Details werden leicht uebersehen.

Erstens ist die Microsoft-Dokumentation zu Group Policy wichtig, weil jede GPO sowohl Verzeichnisdaten als auch eine Dateisystem-Komponente in SYSVOL hat. Wenn Sie nur LDAP abfragen, verpassen Sie einen Teil der Policy-Oberflaeche. Das ist ein Grund, warum Offline-Audits Risiken rund um Skripte, Preferences-Dateien oder die Integritaet von Policy-Pfaden oft zu niedrig einschaetzen.

Zweitens sollten Sie LDAPS nutzen, statt davon auszugehen, dass unverschluesseltes LDAP akzeptabel sei, nur weil die Umgebung intern ist. Die aktuelle EtcSec-Collector-Dokumentation ist im Standalone-Modus an dieser Stelle eindeutig: ldaps:// ist der unterstuetzte und empfohlene Pfad fuer AD-Erfassung, waehrend unverschluesseltes LDAP keine unterstuetzte Produktionsbasis darstellt.

Einen belastbaren Offline-Audit-Workflow aufbauen

Ein belastbarer Offline-Workflow haengt vor allem an Wiederholbarkeit.

1. Die Vertrauensgrenze exakt festlegen

Dokumentieren Sie, ob die Umgebung physisch air-gapped, logisch isoliert oder lediglich vom oeffentlichen Internet getrennt ist. Wenn ein Datenexport ueber Jump Host, Broker oder einen manuellen Transferprozess moeglich ist, muss das festgehalten werden. Der Audit-Bericht sollte das Konnektivitaetsmodell erklaeren, weil davon die Review-Annahmen abhaengen.

2. Von einem vertrauenswuerdigen lokalen Host sammeln

Fuehren Sie die Audit-Engine auf einem Host innerhalb derselben Vertrauensgrenze aus wie das Verzeichnis, das Sie pruefen. Vermeiden Sie ad hoc genutzte Admin-Laptops. Nutzen Sie wenn moeglich einen dedizierten Review-Host und halten Sie Collector-Konfiguration und Outputs unter Change Control.

3. Verzeichnis- und SYSVOL-Evidenz gemeinsam sammeln

Trennen Sie Identitaets-Review nicht von GPO-Review. In isolierten AD-Umgebungen lebt ein Teil des betrieblich gefaehrlichsten Drifts in der Beziehung zwischen Verzeichnisobjekten und dateibasierten Policy-Inhalten. Deshalb bleiben Artikel wie NTLM-Relay-Angriffe: Erkennung und Praevention und SMB Signing Disabled: Why It Still Enables NTLM Relay auch in « offline »-Umgebungen relevant: Die zugrunde liegende Protokoll- und Dateipfad-Exposure ist lokal und nicht vom Internet abhaengig.

4. Einen vergleichbaren Snapshot erhalten

Speichern Sie Audit-Datum, erreichte Domain Controller, ob alle erwarteten Domaenen enthalten waren und ob AD CS oder Trusts im Scope lagen. Ein Bericht ohne Sammelkontext ist spaeter schwer vergleichbar. Wenn Remediations wirklich halten sollen, brauchen Sie eine saubere Vorher-Nachher-Baseline und nicht nur ein einzelnes exportiertes PDF ohne Sammlungsmetadaten.

5. Nach dem Cleanup erneut messen

Sobald Findings behoben wurden, fahren Sie denselben Scope erneut und vergleichen dieselben Evidenzklassen. Nur so laesst sich verlaesslich nachweisen, dass Privilege Drift, Protocol Hardening oder Policy-Cleanup die Change Window tatsaechlich ueberstanden haben.

Event Logging und Detection in isoliertem AD

Offline bedeutet nicht unsichtbar. Es bedeutet, dass die Sichtbarkeit lokal entworfen werden muss.

Die Microsoft-Dokumentation zu Windows Event Forwarding ist hier nuetzlich, weil sie klar beschreibt, was WEF tut und was nicht. WEF kann Events von Quellen zu einem Collector weiterleiten, bleibt aber in Bezug auf die Event-Generierung passiv. Es aktiviert nicht fuer Sie die richtigen Audit-Subkategorien, und es vergroessert nicht fuer Sie die Logs. Wenn Domain Controller die falschen Events protokollieren, zentralisiert ein lokaler Windows Event Collector unvollstaendige Evidenz nur schneller.

Deshalb muss Advanced Audit Policy Configuration selbst Teil des Reviews sein. Microsoft empfiehlt ausserdem Planung und Pilotvalidierung vor breiter Ausrollung, weil die entscheidenden Fragen Event-Volumen, operative Nutzbarkeit und das Verstaendnis der Teams fuer die gesammelten Events sind.

Fuer ein isoliertes AD-Review sollten Sie mit einer engen lokalen Detection-Baseline starten:

Das sind keine Einzel-Event-Detektionen. Es sind Evidenzklassen, die Sie mit Ihrem Inventar und Ihrer erwarteten Baseline korrelieren. Wenn Ihre Policy sagt, dass niemand DCSync-aehnliche Rechte erhalten darf und dass keine privilegierte Gruppe ausserhalb kontrollierter Fenster veraendert werden darf, muessen Ihre Logs diese Aussage lokal unterstuetzen.

Wenn Sie eine tiefere Event-fuer-Event-Kartierung brauchen, geht AD-Sicherheitsueberwachung: Event IDs mit echtem Nutzen auf die Windows-Sicherheitslogging-Seite deutlich tiefer ein.

Findings, die in Air-Gapped-AD priorisiert werden sollten

Eine isolierte Umgebung sollte Ihre Prioritaeten kaum aendern. Sie sollte Ihre Erfassungsmethode aendern.

Privilege Drift und veraltete Admin-Pfade

Beginnen Sie mit denselben Fragen wie in Privileged Access Drift in Active Directory: Warum Adminrechte nach Audits zurueckkehren und Veraltete und ueberprivilegierte Konten in AD: Wer ist heute effektiv privilegiert, wie ist dieser Zugriff entstanden, und wuerde er heute noch genehmigt werden?

Dazu gehoert:

• direkte und verschachtelte Mitgliedschaft in privilegierten Gruppen
• DCSync-faehige Konten
• delegierte Rechte, die GenericAll, WriteDACL, WriteOwner oder gleichwertige Eskalationspfade gewaehrleisten
• AdminSDHolder-bezogener Drift
• deaktivierte oder brachliegende Konten, die weiterhin privilegierte Gruppenmitgliedschaften halten

Protocol Hardening und Relay Surface

Als Naechstes priorisieren Sie Protokolleinstellungen, die auch innerhalb isolierter Netze gefaehrlich bleiben:

• LDAP signing und channel binding
• SMB signing
• SMBv1-Exposure
• NTLM-Einstellungen und unnoetiger Fallback
• weak certificate mapping oder unsichere Zertifikatsausstellung, falls AD CS vorhanden ist

Offline-Umgebungen behalten Legacy-Einstellungen oft laenger bei, weil Change Windows schwieriger und Interoperabilitaetstests langsamer sind. Das macht die Exposure nicht weniger real.

Hygiene lokaler Administratorpasswoerter

Gemeinsam genutzte lokale Administratorpasswoerter bleiben auch in isolierten Windows-Umgebungen ein Lateral-Movement-Problem. Windows LAPS nicht bereitgestellt: Warum gemeinsam genutzte lokale Admin-Passwoerter weiter zaehlen bleibt hier relevant, weil das Risiko in lokaler Credential-Wiederverwendung zwischen Systemen liegt und nicht in Internet-Konnektivitaet.

Kerberos, Servicekonten und Delegation

Servicekonten, alte SPNs, constrained oder unconstrained delegation und eine schwache Verschluesselungs-Posture bleiben ebenfalls hochpriorisierte Pruefpunkte in isoliertem AD. Wenn die Umgebung Legacy-Fachanwendungsserver enthaelt, ist die Wahrscheinlichkeit fuer alte Servicekonto-Muster oft hoeher und nicht geringer.

Remediation und Validierung ohne Cloud-Abhaengigkeit

Remediation in einem air-gapped AD sollte genauso gestaffelt ablaufen wie jede andere risikoreiche Windows-Identity-Aenderung: die gefaehrliche Bedingung korrigieren, dieselbe Evidenz erneut erheben und das Ergebnis innerhalb derselben Grenze nachweisen.

⚠️ Warnung: Behandeln Sie exportierbare Reports nicht als Beweis an sich. Ein Report ist nur dann belastbar, wenn Sammlungsscope, Sammlungsrechte und Rerun-Methode stabil genug sind, um ueber die Zeit verglichen zu werden.

Eine praktische Reihenfolge sieht so aus:

1. Entfernen oder reduzieren Sie zuerst die hoechstriskanten Privilegpfade: veraltete privilegierte Konten, unsichere ACLs, unnoetige DCSync-Rechte, unsichere Delegation und schwache Protokolleinstellungen.
2. Pruefen Sie GPO- und SYSVOL-Integritaet nach jeder Protokoll- oder Policy-Haertung erneut, insbesondere wenn Sie SMB, hardened UNC paths oder administrative templates angefasst haben.
3. Validieren Sie, dass die lokale Audit-Policy weiterhin die fuer Sie relevanten Aenderungen abdeckt und dass Ihr WEF/WEC-Design sie weiterhin erfasst, wo es eingesetzt wird.
4. Fuehren Sie denselben Audit-Scope erneut aus und vergleichen Sie Vorher-Nachher-Findings, statt manuellen Spot Checks zu vertrauen.
5. Dokumentieren Sie, was aufgrund betrieblicher Einschraenkungen bewusst akzeptiert bleibt, insbesondere in isolierten Legacy-Umgebungen, in denen Kompatibilitaetsarbeiten laenger dauern.

Gerade der letzte Punkt ist wichtig. In isolierten Umgebungen werden Ausnahmen oft als temporaer begruendet. Wenn sie nicht mit Owner und Review-Datum dokumentiert werden, werden sie zur dauerhaften Architektur.

Wie EtcSec Air-Gapped-AD-Audits unterstuetzt

Fuer diesen Use Case ist die wichtige Produktgrenze einfach: Der Standalone-Modus des EtcSec-Collectors braucht keine SaaS-Abhaengigkeit. Die lokale Dokumentation beschreibt einen Standalone-Servermodus, in dem der Collector innerhalb Ihrer Umgebung laeuft und lokal mit Active Directory kommuniziert, einschliesslich LDAP oder LDAPS fuer Verzeichnisdaten und SMB-Zugriff auf SYSVOL fuer Group-Policy-Review.

Das ist in isolierten Umgebungen wichtig, weil das Audit innerhalb derselben Vertrauensgrenze wie das zu pruefende Verzeichnis bleiben kann. Fuer ein reines AD-Assessment koennen Sie den Scope lokal halten, ohne ausgehenden Zugriff auf Cloud-Dienste vorauszusetzen.

Sobald die Umgebung fuer eine Posture-Messung bereit ist, sind in diesem Kontext vor allem jene EtcSec-Checks sinnvoll, die lokale Control Health belegen und nicht generische Internet-Exposure. Beispiele sind LDAP_SIGNING_DISABLED, SMB_SIGNING_DISABLED, LAPS_NOT_DEPLOYED, DCSYNC_CAPABLE, ACL_GENERICALL, KERBEROASTING_RISK und ADMIN_SD_HOLDER_MODIFIED.

Der Kernpunkt ist nicht, dass ein air-gapped AD einen anderen Review-Standard braeuchte. Der Kernpunkt ist, dass Erfassungs- und Validierungsworkflow lokal laufen, lokal erneut laufen und lokal verglichen werden koennen.

Verwandte Kontrollen

• dedizierte Administrationspfade und Hygiene privilegierter Arbeitsstationen
• Durchsetzung von LDAP signing, channel binding und SMB signing
• Rollout von Windows LAPS und Rotation lokaler Administratorpasswoerter
• Review privilegierter Zugriffe und Entfernung veralteter Admin-Pfade
• WEF/WEC-Design plus validierte Advanced Audit Policy auf DCs
• Review von GPO- und SYSVOL-Integritaet
• AD-CS-Review, wenn Zertifikatsdienste vorhanden sind
• wiederkehrende Neumessung statt einmaligem Cleanup

Primaerquellen

• 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