AD & Azure Compliance: NIS2, ISO 27001, CIS

Was ist AD- und Azure-Compliance?

AD- und Azure-Compliance wird erst dann nützlich, wenn Framework-Anforderungen in produktionsreife Nachweise übersetzt werden. In Umgebungen, die auf Active Directory und Microsoft Entra ID aufbauen, bedeutet das: nachzuweisen, wie Passwortrichtlinien, privilegierter Zugriff, MFA, Audit-Protokollierung, Lifecycle-Governance und Kontrollen für den Zugriff Dritter tatsächlich durchgesetzt werden.

Der schwierige Teil ist diese Übersetzung. Framework-Texte sind bewusst abstrakt gehalten, während die technischen Nachweise, die ein Auditor oder Sicherheitsverantwortlicher tatsächlich benötigt, konkret sind: welche Passwortrichtlinie aktiv ist, welche Admin-Konten noch dauerhafte Berechtigungen besitzen, welche Anmeldeschutzmaßnahmen durchgesetzt werden, welche Protokolle aufbewahrt werden und welche Gast- oder Cross-Tenant-Zugänge weiterhin offen sind.

Dieser Artikel ordnet gängige Compliance-Anforderungen technischen Identitätskontrollen zu, die sich in AD und Azure prüfen lassen, ohne dass daraus ein reines Tabellenkalkulations-Audit wird.

So funktioniert es

Identitätsfokussierte Compliance-Reviews betrachten in der Regel fünf Bereiche:

• Authentifizierungsrichtlinie wie Passwortlänge, Komplexität, MFA und die Exposition durch veraltete Protokolle
• Kontrolle privilegierten Zugriffs wie Umfang von Admin-Rollen, Just-in-Time-Zugriff und Break-Glass-Governance
• Audit und Monitoring wie erweiterte Audit-Richtlinien auf Domain Controllern, Entra-Audit-Protokolle und Prüfrhythmus
• Zugriffs-Lifecycle wie Provisionierung, Bereinigung veralteter Konten und Deprovisionierung
• Externer Zugriff und Anwendungszugriff wie Gast-Governance, App-Consent und Cross-Tenant-Vertrauensstellungen

Jeder Bereich lässt sich in eine Reihe technischer Prüfungen und unterstützender Nachweise übersetzen.

Zuordnung des AD- und Azure-Compliance-Frameworks

NIS2-Richtlinie

NIS2 Artikel 21(1) verpflichtet die Mitgliedstaaten sicherzustellen, dass wesentliche und wichtige Einrichtungen „geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen" ergreifen, um ihre Cybersicherheitsrisiken zu managen. Für den Identitätsbereich lässt sich das in der Regel den folgenden Kontrollen zuordnen:

CIS Controls v8.1

Die CIS Controls übersetzen Identitäts-Hardening in priorisierte Abwehrmaßnahmen. Die Nummerierung folgt CIS Controls v8.1, der aktuellen Version, und ist gegenüber v8 unverändert:

ISO 27001:2022

Die Annex-A-Kontrollen von ISO 27001, die am häufigsten der Directory-Sicherheit zugeordnet werden, umfassen:

ANSSI-orientierte Erwartungen an das Directory-Hardening

Für Organisationen, die sich an ANSSI-orientierten Empfehlungen ausrichten, sind die praktischen Identitätsthemen durchgängig dieselben — die vollständige Empfehlungsliste finden Sie im ANSSI Active Directory Leitfaden: So setzen Sie die Sicherheitsempfehlungen praktisch um:

• veraltete Authentifizierung und veraltete Kryptografie reduzieren, soweit die Anwendungskompatibilität dies zulässt
• privilegierte Konten isolieren oder härten, statt täglich genutzten Identitäten dauerhafte Berechtigungen zu belassen
• Ausnahmen für Altsysteme dokumentieren, statt sie stillschweigend unbegrenzt fortzuführen
• überprüfen, dass Monitoring, privilegierter Zugriff und Passwortkontrollen in der Produktion tatsächlich durchgesetzt werden und nicht nur in der Richtlinie festgehalten sind

Die Compliance-Lückenanalyse

Schritt 1 – Ihren aktuellen Status als Baseline erfassen

# Baseline der Passwortrichtlinie
Get-ADDefaultDomainPasswordPolicy |
  Select-Object MinPasswordLength, ComplexityEnabled, MaxPasswordAge

# Baseline der Entra Conditional Access
Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgIdentityConditionalAccessPolicy -All |
  Where-Object {$_.State -eq "enabled"} |
  Select-Object DisplayName, State

# Baseline der Audit-Richtlinie auf einem Domain Controller
auditpol /get /category:"Account Logon","DS Access","Account Management" |
  Select-String "Success|Failure"

Schritt 2 – Lücken benannten Kontrollen zuordnen

$policy = Get-ADDefaultDomainPasswordPolicy

# Der Passwortablauf wird bewusst NICHT als Kontrolle bewertet. Microsoft hat die
# Passwortablauf-Richtlinien 2019 aus seinen Windows-Sicherheitsbaselines entfernt und bezeichnet
# den periodischen Ablauf als „eine veraltete und überholte Maßnahme von sehr geringem Nutzen".
# Erfassen Sie MaxPasswordAge als Nachweis und bewerten Sie es nur dort, wo ein Framework oder
# eine interne Richtlinie weiterhin eine Rotation vorschreibt.
$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

Schritt 3 – Nach Exposition priorisieren, nicht nach Anzahl der Checkboxen

1. Kritisch: Keine MFA für privilegierte Identitäten, keine Kontrolle über hochriskante Rollenzuweisungen, uneingeschränkte Delegation, DCSync-fähige Principals
2. Hoch: Schwache Passwortrichtlinie, fehlende Audit-Abdeckung, zu viele dauerhafte Admins, schwache Gast-Governance
3. Mittel: Veraltete Konten, fehlendes LAPS, unvollständiger Rollenüberprüfungsprozess, fehlende feingranulare Kontrollen, wo erforderlich
4. Niedrig: Dokumentationslücken, uneinheitliche Namensgebung, unwesentliche Darstellungsprobleme

Erkennung

Compliance-Nachweise sind schwach, wenn sie nur zum Prüfungszeitpunkt existieren. Die relevanten Kontrollen sollten kontinuierlich überprüfbar sein.

Kontinuierliche Compliance-Prüfungen

# Drift in privilegierten Gruppen der letzten 7 Tage, geprüft auf jedem Domain Controller.
# whenChanged wird NICHT repliziert – jeder DC führt seinen eigenen Wert – daher übersieht eine
# Abfrage nur eines einzelnen DC stillschweigend eine Änderung, die anderswo geschrieben wurde.
$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
}

# Aktivierte Konten, die seit 90+ Tagen inaktiv sind.
# -Filter ist kein PowerShell-Scriptblock: Es akzeptiert nur <attr> <operator> <value>, daher muss
# der Cutoff zuerst berechnet werden. LastLogonDate gehört zudem nicht zum Standard-Property-Set
# und muss explizit angefordert werden, sonst bleibt die Spalte leer.
$inactive = (Get-Date).AddDays(-90)
Get-ADUser -Filter 'Enabled -eq $true -and LastLogonDate -lt $inactive' -Properties LastLogonDate |
  Select-Object SamAccountName, LastLogonDate

Remediation

Priorisierte Remediation-Reihenfolge

1. MFA erzwingen für privilegierte Konten und sensiblen Cloud-Zugriff
2. Dauerhafte Berechtigungen reduzieren, indem Rollenzuweisungen überprüft und, wo verfügbar, Just-in-Time-Erhöhung genutzt wird
3. Audit-Abdeckung aktivieren auf Domain Controllern und in Entra, damit Kontrollausfälle überprüfbar sind
4. Passworthygiene korrigieren, einschließlich Länge, Komplexität, Listen verbotener Passwörter und ausufernder Ausnahmen
5. Veraltete und verwaiste Identitäten bereinigen in AD und Azure
6. Gast- und Cross-Tenant-Zugriff überprüfen, damit der Zugriff Dritter gesteuert ist
7. Begründete Ausnahmen dokumentieren mit Verantwortlichem, Begründung und Überprüfungsdatum

Wie EtcSec dies erkennt

EtcSec ordnet technische Befunde den Kontrollfamilien zu, auf die in Compliance-Arbeit am häufigsten Bezug genommen wird.

Jeder relevante Befund hilft, drei praktische Fragen zu beantworten:

• welche Identitätskontrolle fehlt oder schwach ist
• welche Konten, Rollen oder Objekte betroffen sind
• welche Nachweise das Sicherheitsteam sammeln sollte, um zu belegen, dass die Lücke geschlossen ist

Die Kategorie Compliance ist nützlich, wenn Sie rohe technische Befunde in einen umsetzbaren Remediation-Backlog verwandeln wollen statt in eine generische Framework-Tabelle.

AD- und Azure-Compliance-Evidenzpaket

Ein solides Compliance-Review scheitert meist aus zwei Gründen: Die Kontrolle wurde nie in der Produktion umgesetzt, oder das Team kann das nicht nachweisen. Bauen Sie ein Evidenzpaket auf, das sowohl einer internen Prüfung als auch einem externen Audit standhält:

• aktuelle Ausgabe der Passwortrichtlinie und alle genehmigten feingranularen Ausnahmen
• Exporte privilegierter Rollen und privilegierter Gruppenmitgliedschaften, einschließlich permanenter Zuweisungen
• Zustand von Conditional Access oder Security Defaults für den betrachteten Tenant
• Ausgabe der Domain-Controller-Audit-Richtlinie für die Subkategorien, auf die Sie sich bei der Erkennung verlassen
• Einstellungen für Gast-, Cross-Tenant- und Anwendungszugriff für die vom Review erfassten Populationen
• Verantwortlicher, Ausnahmebegründung und Überprüfungsdatum für alles, was den Zielzustand noch nicht erreicht

Dieses Evidenzpaket macht aus AD- und Azure-Compliance keine bloße Präsentationsübung, sondern ein wiederholbares Kontroll-Review.

Ein Review statt drei durchführen

Organisationen, die gleichzeitig mit NIS2, ISO 27001 und CIS Controls konfrontiert sind, benötigen selten drei separate Review-Zyklen. Die drei Frameworks laufen auf dieselbe Handvoll Identitäts-Grundbausteine zusammen — MFA, Governance des privilegierten Zugriffs, Passworthygiene und Audit-Abdeckung —, sodass ein einziges technisches Review Nachweise liefern kann, die alle drei Zuordnungen gleichzeitig erfüllen.

Ein praktischer Ansatz für die Reihenfolge:

1. Zuerst eine einzige Kontroll-Baseline aufbauen. Erfassen Sie Passwortrichtlinie, Conditional-Access-Zustand, Ausgabe der Audit-Richtlinie und privilegierte Gruppenmitgliedschaften einmalig. Jede der oben genannten Framework-Zuordnungen greift auf dieselbe Handvoll Datenpunkte zurück.
2. Befunde jedem Framework zuordnen, das sie betreffen, nicht nur einem. Eine einzelne MFA-Lücke bei einem Global-Administrator-Konto ist gleichzeitig eine Lücke nach NIS2 Artikel 21(2)(j), eine Lücke nach CIS Control 6 und eine Lücke nach ISO 27001 A.8.5. Wird sie einmal mit mehreren Tags erfasst, muss dasselbe Beweismaterial nicht dreimal neu gesammelt werden.
3. Nach Angreifernutzen priorisieren und die Dokumentation danach nachziehen. Wer zuerst die Lücken mit der höchsten Exposition schließt — uneingeschränkte Delegation, DCSync-fähige Konten, dauerhafter Global-Admin-Zugriff ohne MFA —, schließt Befunde über alle drei Frameworks hinweg, bevor auch nur eine einzige Compliance-Checkbox abgehakt ist.
4. Ausnahmedokumentation an einem Ort führen. Eine Legacy-Anwendung, die MFA nicht unterstützt, ist ein einziger Ausnahmeeintrag mit einem Verantwortlichen und einem Überprüfungsdatum – nicht drei separate Begründungen für drei unterschiedliche Frameworks.

Diese Reihenfolge ist besonders wichtig für Teams, die Compliance-Arbeit als Nebenprodukt eines Sicherheits-Reviews geerbt haben, statt bei einem leeren Framework-Dokument zu beginnen. Die zugrunde liegenden technischen Nachweise — Passwortrichtlinie, Audit-Abdeckung, Zustand des privilegierten Zugriffs — ändern sich nicht danach, welches Framework gerade danach fragt.

Häufige Lücken, die jedes Quartal wiederkehren

Selbst erfahrene Teams öffnen tendenziell dieselben Identitäts-Compliance-Lücken erneut:

• Legacy-Anwendungsausnahmen, die stillschweigend schwache Authentifizierung aufrechterhalten
• veraltete privilegierte Identitäten, die nach einem Projekt- oder Personalwechsel nie entfernt wurden
• Conditional-Access-Ausschlüsse, die während eines Vorfalls hinzugefügt und nie überprüft wurden
• Gastzugriffspfade, die breiter bleiben, als die schriftliche Richtlinie erlaubt
• Monitoring-Kontrollen, die einmal dokumentiert wurden, aber auf aktuellen Domain Controllern oder im aktuellen Tenant-Umfang nicht mehr validiert werden

Werden diese Lücken nicht als operative Schuld mit klarer Verantwortlichkeit nachverfolgt, wirkt die Framework-Zuordnung gesund, während die Angriffsfläche weitgehend unverändert bleibt.

Verwandte Beiträge

Für die technische Seite derselben Kontrollfamilien lohnt sich ein Blick auf Azure Privilegierter Zugriff: Zu Viele Globale Admins, Azure Identity Protection: Geleakte Zugangsdaten Blockieren, Active Directory-Sicherheit auditieren: Was zuerst zu prüfen ist und wie sich Remediation nachweisen lässt und Azure App-Registrierungen: Sicherheitsrisiken. Diese Beiträge helfen dabei, Framework-Sprache in konkrete Härtungs- und Validierungsschritte zu übersetzen.