NTFS-Rechte auditieren: Get-Acl und icacls im Vergleich

„Können Sie uns bis Freitag eine Liste aller Berechtigungen auf dem Projektlaufwerk liefern?" Diese Anfrage – vom Auditor, vom Datenschutzbeauftragten oder aus der eigenen Geschäftsleitung – trifft viele Admin-Teams unvorbereitet. Der Windows Explorer zeigt Rechte nur Ordner für Ordner, eine konsolidierte Übersicht über hunderte Freigaben und verschachtelte AD-Gruppen fehlt. Wer NTFS-Berechtigungen regelmäßig auditieren muss, kommt an PowerShell nicht vorbei. Die Frage ist nicht ob, sondern wie man Get-Acl und icacls sinnvoll kombiniert, ohne sich in unvollständigen oder falsch interpretierten Reports zu verlieren.

Das Problem: Sichtbare Rechte sind nicht die effektiven Rechte

Die Eigenschaften-Dialoge in Windows zeigen die Access Control List (ACL) eines einzelnen Objekts. Was sie nicht liefern: einen Überblick über mehrere hundert Unterordner gleichzeitig, eine Trennung zwischen vererbten und explizit gesetzten Einträgen und schon gar keine Auflösung verschachtelter Gruppenmitgliedschaften. Genau diese drei Punkte sind für ein Audit relevant – und genau hier scheitert die grafische Oberfläche.

PowerShell schließt die erste Lücke: Das Cmdlet Get-Acl liefert das Security-Descriptor-Objekt einer Ressource inklusive der kompletten DACL (Discretionary Access Control List), also aller Einträge, wer welchen Zugriff auf eine Datei oder einen Ordner hat¹. Kombiniert mit Get-ChildItem -Recurse lässt sich daraus ein rekursiver Bericht über einen ganzen Freigabebaum erzeugen.

Ursache: Gewachsene ACLs und verschachtelte Gruppen

In der Praxis entstehen unübersichtliche Berechtigungsstrukturen selten durch einen einzelnen Fehler, sondern durch Jahre gewachsener Ad-hoc-Änderungen: direkte Benutzerrechte statt Gruppenrechte, deaktivierte Vererbung auf einzelnen Unterordnern, „temporäre" Freigaben für ausgeschiedene Projektmitarbeiter. Das BSI beschreibt im Baustein ORP.4 „Identitäts- und Berechtigungsmanagement" genau dieses Risiko: Ohne geregelte Prozesse für Vergabe, Änderung und Entzug von Rechten sammeln sich über die Zeit Berechtigungen an, die niemand mehr zuordnen kann.

Ein zweiter Faktor ist die AD-Gruppenverschachtelung selbst. Eine Datei kann formal nur zwei oder drei Gruppen in der ACL stehen haben – de facto aber Hunderten von Benutzern zugänglich sein, wenn diese Gruppen wiederum verschachtelt sind. Get-Acl löst diese Verschachtelung nicht auf; es zeigt nur die direkten ACL-Einträge, nicht die daraus resultierenden effektiven Rechte einzelner Personen. Für eine vollständige Auflösung braucht es zusätzlich AD-Gruppenmitgliedschaften (Get-ADGroupMember -Recursive) oder spezialisierte Tools.

Lösung: Get-Acl und icacls gezielt kombinieren

Get-Acl und icacls lösen unterschiedliche Teilprobleme. Get-Acl ist ein natives PowerShell-Objekt und eignet sich hervorragend für strukturierte Reports und CSV-Exporte. icacls ist ein Kommandozeilentool, das laut Microsoft-Dokumentation DACLs anzeigt, ändert, sichert und wiederherstellt² – und eignet sich besonders für Stichprobenprüfung, Backup vor Änderungen und das Auffinden aller Objekte mit einer bestimmten SID (/findsid).

Schritt 1: Rekursiver ACL-Export als Audit-Grundlage

$Root = "D:\Freigaben\Projekte"
Get-ChildItem -Path $Root -Recurse -Directory |
  ForEach-Object {
    $acl = Get-Acl -Path $_.FullName
    foreach ($entry in $acl.Access) {
      [PSCustomObject]@{
        Pfad             = $_.FullName
        Identität        = $entry.IdentityReference
        Recht            = $entry.FileSystemRights
        Typ              = $entry.AccessControlType
        Vererbt          = $entry.IsInherited
        VererbungsFlags  = $entry.InheritanceFlags
      }
    }
  } | Export-Csv -Path "C:\Audit\ntfs-rechte.csv" -NoTypeInformation -Encoding UTF8

Schritt 2: Explizite (nicht vererbte) Rechte isolieren

Für ein Audit sind vor allem die Einträge relevant, die von der Standardvererbung abweichen – sie markieren Sonderfälle, die dokumentiert oder bereinigt werden sollten:

Import-Csv "C:\Audit\ntfs-rechte.csv" |
  Where-Object { $_.Vererbt -eq "False" } |
  Sort-Object Pfad |
  Export-Csv "C:\Audit\ntfs-rechte-explizit.csv" -NoTypeInformation -Encoding UTF8

Schritt 3: Stichprobenverifikation mit icacls

Für Einzelprüfungen und als Backup vor Änderungen ergänzt icacls den PowerShell-Export sinnvoll:

REM Rechte eines Ordners inkl. Unterordner sichern (vor Änderungen)
icacls "D:\Freigaben\Projekte" /save D:\Audit\projekte.aclbak /T /C

REM Alle Objekte finden, in denen eine bestimmte SID/Gruppe explizit vorkommt
icacls "D:\Freigaben\Projekte" /findsid *S-1-5-21-XXXXXXXXXX-1234 /T

Der Parameter /save sichert die DACLs in eine Datei, die sich später mit /restore wiederherstellen lässt – praktisch als Rollback-Absicherung vor größeren Bereinigungen. /findsid beantwortet gezielt die Auditor-Frage „Wo genau hat diese Gruppe noch Zugriff?", ohne den kompletten Baum manuell zu durchsuchen.

Praxis: Checkliste fürs nächste Fileserver-Audit

• Rekursiven ACL-Export für alle Freigaben planen (nachts, außerhalb der Kernarbeitszeit bei großen Volumina)
• Explizite (nicht vererbte) Einträge separat auswerten und einzeln begründen
• Direkte Benutzerrechte statt Gruppenrechte identifizieren und in AGDLP-Struktur überführen
• Verschachtelte Gruppen mit Get-ADGroupMember -Recursive auflösen, bevor „effektive Rechte" kommuniziert werden
• Vor jeder Bereinigung ein icacls /save-Backup der betroffenen Pfade anlegen
• Reports revisionssicher ablegen (Datum, Verantwortlicher, Freigabe-Scope) als Nachweis für Rezertifizierung
• Wiederholung terminieren – ein einmaliger Export ersetzt keinen laufenden Prozess

Einordnung: Was das für Compliance-Nachweise bedeutet

Ein PowerShell-Report ersetzt kein vollständiges Berechtigungskonzept, liefert aber die Rohdaten, die ein Nachweis braucht. ISO/IEC 27002:2022 verlangt in Control 8.3 „Information Access Restriction", dass Zugriff auf Informationen gemäß einer themenspezifischen Zugriffsrichtlinie eingeschränkt wird – ein regelmäßiger, dokumentierter ACL-Export ist ein naheliegender Beleg dafür, dass diese Einschränkung tatsächlich gelebt wird und nicht nur auf dem Papier existiert. NIST SP 800-53 verlangt in AC-2 vergleichbar wiederkehrende Kontoprüfungen, deren Frequenz sich am Risiko der Systeme orientiert – bei privilegierten Zugriffen typischerweise quartalsweise. Für beide Rahmenwerke gilt: Ohne exportierbare, versionierte Berichte bleibt jede Aussage zur Rechtevergabe unbelegte Behauptung.

Fazit

Get-Acl und icacls sind keine Konkurrenten, sondern ergänzen sich: Get-Acl liefert strukturierte, auswertbare Massendaten für laufende Reports und CSV-Exporte, icacls liefert gezielte Einzelprüfung, SID-Suche und ein einfaches Backup-/Restore-Verfahren für DACLs. Wer beide Werkzeuge in einen wiederkehrenden Prozess einbettet – inklusive Filterung auf explizite Rechte und Auflösung verschachtelter Gruppen – hat die technische Grundlage für Rezertifizierung und Auditnachweis geschaffen. Die eigentliche Arbeit beginnt danach: die gefundenen Abweichungen zu bewerten und zu bereinigen.

---

Quellen: Microsoft Learn – Get-Acl (Microsoft.PowerShell.Security)¹; Microsoft Learn – icacls-Befehlsreferenz²; BSI IT-Grundschutz-Kompendium, Baustein ORP.4 „Identitäts- und Berechtigungsmanagement"; ISO/IEC 27002:2022, Control 8.3 „Information Access Restriction"; NIST SP 800-53 Rev. 5, Control AC-2 „Account Management".
Hinweis: KI-gestützt erstellt, redaktionell geprüft.