Deprovisioning Best Practice

Strategiepapier: Best Practice User-Deprovisioning

Thema: Compliance-Exzellenz und Resilienz gegen Advanced Persistent Threats (APT)

Hinweis:
Dieses Strategiepapier fokussiert auf Prozess-, Sicherheits- und Compliance-Aspekte des Deprovisionings. Die technischen Ausführungen dienen dem Verständnis der Risiken und der Fundierung der strategischen Empfehlungen. Operative Umsetzungsdetails (Skriptbeispiele, manuelle Bereinigung) werden in diesem Beitrag nicht abgehandelt sondern bleiben separaten technischen Dokumentationen vorbehalten.

1. Einleitung und Management Summary

In der IT-Infrastruktur gilt das Identitäts- und Berechtigungsmanagement (Identity & Access Management – IAM) als der neue Perimeterschutz. Das Ausscheiden von Mitarbeitern (Offboarding) ist dabei ein kritischer Prozess, der weit über das bloße Deaktivieren eines Kontos hinausgeht. Ein unvollständiges Deprovisioning hinterlässt digitale Rückstände, sogenannte verwaiste SIDs,, die nicht nur gegen regulatorische Vorgaben (ISO 27001, BSI IT-Grundschutz) verstoßen, sondern professionellen Angreifern (APTs) als Tarnung und Brückenkopf dienen.

Dieses Dokument analysiert die regulatorischen Grundlagen, die technischen Risiken verwaister Sicherheitskennungen und definiert einen Best-Practice-Workflow, der Sicherheit und Effizienz vereint.

2. Regulatorischer Rahmen: ISO 27001 und BSI IT-Grundschutz

Weder die ISO-Normen noch die BSI-Standards schreiben technische Befehle vor, definieren jedoch klare Schutzziele.

2.1 ISO/IEC 27001:2022 (Annex A)

Die ISO-Norm betrachtet den Entzug von Rechten als Teil des Risikomanagements:

• Maßnahme A.6.5 (Verantwortlichkeiten nach Beendigung oder Änderung der Beschäftigung): Regelt, dass Informationssicherheits Verantwortlichkeiten auch nach Austritt oder Rollenwechsel klar definiert und umgesetzt werden müssen (z. B. Rückgabe von Assets, Vertraulichkeit).
• Maßnahme A.5.18 (Zugriffsrechte): Fordert, dass Zugriffsrechte formal vergeben, regelmäßig überprüft und insbesondere bei Austritt oder Rollenwechsel unverzüglich entzogen werden.

Audit-Fokus: Nachweisbarkeit. Wer hat wann den Entzug veranlasst und wer hat ihn technisch bestätigt? Dies schließt die Überprüfung ein, ob Verantwortlichkeiten gemäß A.6.5 wahrgenommen wurden und der Entzug gemäß A.5.18 zeitnah erfolgte.

2.2 BSI IT-Grundschutz (Baustein ORP.4)

Der Grundschutz fordert eine strikte Prozessdisziplin und klare Regelungen für Identitäts-Lebenszyklen:

• ORP.4.A1 (Regelung für Einrichtung und Löschung): Es MUSS geregelt werden, wie Benutzendenkennungen und -gruppen eingerichtet und gelöscht werden; dazu gehört insbesondere der unverzügliche Entzug nicht mehr benötigter Berechtigungen.
• ORP.4.A2 Einrichtung, Änderung und Entzug von Berechtigungen
• ORP.4.A15 (Zuweisung und Überprüfung von Berechtigungen): In angemessenen Zeitabständen MUSS überprüft werden, ob die zugewiesenen Berechtigungen noch erforderlich sind; dies fördert eine Kultur des kontinuierlichen Berechtigungs-Reviews statt einmaliger „Kosmetik Aktionen“.

3. Technische Tiefenanalyse: Die SID-Problematik

Das fundamentale Problem beim Löschen von Benutzern liegt in der Architektur des Windows-Sicherheitssystems (NTFS und AD).

3.1 Der Security Identifier (SID)

Jedes Objekt im AD besitzt eine eindeutige Kennung, die SID (z. B. S-1-5-21-3623811015-3361044348-30300820-1013). Das Dateisystem (NTFS) speichert in den Access Control Lists (ACLs) eines Ordners nicht den Namen des Users, sondern ausschließlich diese SID.

3.2 Entstehung verwaister SIDs (Orphaned SIDs)

Wird ein User mittels Remove-ADUser gelöscht, ohne vorher die ACLs der Fileserver zu bereinigen, geschieht Folgendes:

• Die SID in der ACL verliert ihre Verknüpfung zum Namen im AD.
• In den Sicherheitseinstellungen erscheint nur noch die rohe Zahlenfolge (S-1-5-21-…).
• Diese „Leichen“ bleiben physisch auf dem Datenträger stehen, bis sie manuell oder per Skript entfernt werden.

3.3 Das „Kosmetik-Paradoxon“

Oft wird die Bereinigung von ACLs als bloße Kosmetik abgetan, da die SID „tot“ sei. Dies ist ein Trugschluss. Eine unsaubere ACL-Struktur ist ein Symptom für mangelnde Governance und führt zu technischen Schulden, die bei Audits als „mangelnde Beherrschung der IT-Landschaft“ gewertet werden können. Das widerspricht aber nicht nur Compliance, sondern auch der klaren Empfehlung von Microsoft.

Die Empfehlungen aus diesem Papier sind an Microsoft’s Empfehlungen angelehnt.

Genau das setzt unser 4-Stufen-Workflow um:

Stufe 1 (Sperrung) verhindert weiteren Zugriff.
Stufe 2 (Entkoppelung) entfernt aus Gruppen.
Stufe 3 (Prüfung) stellt sicher, dass kein „residual access“ bleibt.
Stufe 4 (Löschung) schließt den Lebenszyklus ab.

Quellen (englisch)
MS Standard für die Skalierung von Berechtigungen
Microsoft Learn: Active Directory Security Groups – Best Practices
Das Risiko: SID History Injection & Persistenz
Microsoft Defender for Identity: Unsecure SID History assessment

4. Die APT-Perspektive: Risiken für die IT-Sicherheit

Ein „vermülltes“ Berechtigungssystem ist ein ideales Schlachtfeld für Advanced Persistent Threats (APTs). Keine Direktberechtigungen für User in Dateisystemen, sondern, wie MS empfiehlt:
User → Global Groups → Domain Local Groups → Permissions.
(Dazu mehr in Abschnitt 5.1)

4.1 Reconnaissance (Aufklärung)

Angreifer suchen gezielt nach verwaisten SIDs in ACLs. Diese fungieren als „Fußabdrücke im Staub“:

• Sie zeigen auf sensible Datenbereiche (z. B. Vorstandsordner), in denen früher Spezialberechtigungen vergeben wurden.
• Sie verraten administrative Strukturen der Vergangenheit, die oft noch in der aktuellen Architektur nachwirken.

4.2 Persistenz und Tarnung

In einem System mit tausenden verwaisten SIDs fällt ein neuer, bösartiger Eintrag nicht auf. Ein Angreifer kann eine eigene SID so tarnen, dass sie wie eine „Altlast von Müller aus dem Jahr 2019“ wirkt. Administratoren sind an den Anblick von S-1-5-21-Einträgen gewöhnt und hinterfragen diese nicht mehr.

4.3 SID History Injection

Bei Migrationen wird das Attribut sIDHistory genutzt. Wenn eine SID in einer ACL verbleibt, kann ein Angreifer mit Admin-Rechten versuchen, diese alte SID in seinen eigenen Token zu injizieren. Der Fileserver erkennt die injizierte SID und gewährt Zugriff, obwohl der ursprüngliche User längst gelöscht wurde.

4.4 RID Hijacking

In extremen Szenarien können Angreifer versuchen, die Relative ID (RID) eines gelöschten, aber mächtigen Users für ein neues Konto zu kapern. Verbleiben mächtige SIDs in ACLs, erbt der neue Account sofort deren Rechte.

4.5 Exkurs: Mimikatz – Das Skalpell der APT-Akteure

Mimikatz zählt zu den wirkungsvollsten Werkzeugen in der Angriffs­praxis, um Schwachstellen im Windows‑Authentifizierungs­system gezielt zu erkennen und auszunutzen. Im Kontext verwaister SIDs ist Mimikatz besonders gefährlich, da es die „Wiederbelebung“ gelöschter Identitäten ermöglicht.

Mimikatz wurde ursprünglich nicht als Angriffs-Tool, sondern als Forschungs- und Demonstrationswerkzeug entwickelt.

Der Entwickler ist der französische Sicherheitsforscher Benjamin Delpy.

Er veröffentlichte Mimikatz etwa 2007/2008, um ein grundlegendes Problem in Windows zu demonstrieren.

Der ursprüngliche Zweck von Mimikatz war:

Nachzuweisen, dass Windows Anmeldeinformationen im Speicher speichert und auslesbar sind.

Konkret wollte Delpy zeigen, dass der Windows-Dienst LSASS (Local Security Authority Subsystem Service) sensible Informationen im Arbeitsspeicher hält, darunter:

• Klartextpasswörter (bei bestimmten Authentifizierungsarten)
• NTLM-Hashes
• Kerberos-Tickets
• Session-Tokens

Das Tool wurde also entwickelt, um zu zeigen:

Ein lokaler Administrator kann Anmeldeinformationen anderer Benutzer aus dem Speicher extrahieren.

• Der Mechanismus: Mimikatz erlaubt es einem Angreifer, der bereits lokale Administratorrechte auf einem kompromittierten System besitzt, das Sicherheits-Token seines aktuellen Prozesses zu manipulieren.
• SID History Manipulation: Mit Befehlen wie sid::add oder sid::patch kann ein Angreifer die SID eines ehemaligen, hochberechtigten (aber nun gelöschten) Benutzers in das Feld sIDHistory seines eigenen Benutzer-Tokens injizieren.
• Das Angriffsszenario: Wenn die IT-Abteilung den „Super-Admin“ zwar im Active Directory gelöscht, aber dessen SID in den ACLs eines kritischen Fileservers (z. B. Backups oder Datenbank-Configs) vergessen hat, kann der Angreifer mittels Mimikatz diese Identität „simulieren“.
  Eine Ausführliche Argumentation für das Szenario:
  Wenn ein hoch privilegiertes Konto, etwa ein ehemaliger „Super-Admin“, im Active Directory gelöscht wird, dessen Security Identifier (SID) jedoch weiterhin in den Access Control Lists (ACLs) eines kritischen Fileservers verbleibt, zum Beispiel in Backup-Verzeichnissen oder Konfigurationspfaden von Datenbanken, entsteht ein potenzielles Sicherheitsrisiko.
  Verwaiste SID stellen einen Angriffsvektor dar,, etwa durch Manipulation des sIDHistory-Attributs oder vergleichbare Methoden der Token-Manipulation. Wird eine solche SID vom Zielsystem akzeptiert, interpretiert der Fileserver den Zugriff so, als stamme er von der ursprünglichen Identität.
  Besonders kritisch ist dies im Zusammenhang mit Backup-Systemen. Backups konservieren nicht nur Datenbestände, sondern auch die zugehörigen Berechtigungsstrukturen. Dadurch besteht die Gefahr, dass ein kompromittierter Berechtigungszustand über lange Zeit fortbesteht und sich über mehrere Backup-Generationen hinweg repliziert.
  Aus diesem Grund sollte sichergestellt werden, dass verwaiste SIDs regelmäßig aus ACLs entfernt werden und privilegierte Konten grundsätzlich nicht direkt in Zugriffskontrolllisten eingetragen sind, sondern ausschließlich über Gruppenstrukturen verwaltet werden.
• Bypass von Monitoring: Das Fileserver prüft die Zugriffsberechtigung lokal anhand der SID-History. Da die Prüfung erfolgreich ist, wird der Zugriff gewährt. In den Logs erscheint oft nur der Name des Angreifer-Accounts, während der Zugriff technisch durch die verwaiste SID legitimiert wurde.

Dies verdeutlicht: Wer SIDs in ACLs stehen lässt, bietet Mimikatz-Nutzern eine persistente Hintertür.

5. Strategische Lösung: Governance und Prozessdesign

Um den Scan-Aufwand von Terabytes an Daten zu vermeiden, muss die Organisation das Problem an der Wurzel packen.

5.1 Das AGDLP-Prinzip (Prävention)

Die effektivste Methode gegen verwaiste SIDs ist das Verbot von Direktberechtigungen:

• User werden in Globale Gruppen aufgenommen.
• Globale Gruppen werden in Lokale Gruppen geschachtelt.
• Lokale Gruppen erhalten Rechte in der ACL.
• Vorteil: Beim Austritt wird der User nur aus der Gruppe entfernt. In der ACL der Datei steht nur die Gruppen-SID, die weiterhin gültig bleibt. Es entstehen keine verwaisten User-SIDs.

User → Global Groups → Domain Local Groups → Permissions.

Architekturdiagramm, Split: Identitätssystem | Ressourcensystem

Ein Benutzer wird zunächst einer Global Group zugeordnet, die seine organisatorische Rolle abbildet. Diese Global Group wird anschließend einer Domain Local Group zugewiesen, die als Ressourcengruppe fungiert. Die Domain Local Group erhält schließlich die Berechtigungen auf der jeweiligen Ressource.

Dieses als AGDLP (Account, Global Group, Domain Local Group, Permission) bekannte Prinzip stellt den von Microsoft empfohlenen De-facto-Standard für die Berechtigungsverwaltung in Windows-Umgebungen dar. Die moderne Variante AGUDLP (mit Universal Groups in Multi-Domain-Umgebungen) folgt derselben Logik. Die Empfehlung von Microsoft basiert exakt auf den in diesem Papier dargelegten Gründen: Vermeidung verwaister SIDs in ACLs, Reduzierung des Administrationsaufwands bei Änderungen und Schaffung einer auditierbaren Berechtigungsstruktur.

Berechtigungsfluss


5.2 Projekt- und Datenlebenszyklus

Berechtigungen sollten an den Lebenszyklus von Projekten gekoppelt sein:

1. Projektstart: Erstellung einer dedizierten AD-Gruppe.
2. Abschluss: Archivierung des Ordners und Löschung der Gruppe.
3. Effekt: Die Bereinigung erfolgt auf Datenbank-Ebene (AD), nicht durch zeitintensive Dateisystem-Scans.

6. Revisionssicherer Deprovisioning-Workflow (4 Stufen)

Für eine lückenlose Compliance und maximale Sicherheit empfiehlt sich folgender Ablauf:

Detaillierte Prozess-Matrix

Stufe	Aktion	Technischer Beleg	Primäres Ziel
1. Sperrung	Account deaktivieren (Enabled: False)	Event ID: 4725	Unverzüglicher Zugriffsschutz & Perimeter-Härtung.
2. Entkoppelung	Entfernung aus allen AD-Gruppen	Event ID: 4729	Trennung des Users von der Berechtigungsstruktur (Governance).
3. Prüfung	Scan auf Direkt-ACLs & verwaiste SIDs	Skript-Log / Audit	Sicherstellung der ACL-Hygiene & Forensikfähigkeit.
4. Löschung	Endgültige Löschung des AD-Objekts	Event ID: 4726	Abschluss der Identitäts-Lebenszyklus (180 Tage Frist).

6.1 Strategie-Impuls: Die 180-Tage-Frist im Deprovisionierungsprozess

Die Festlegung einer Haltefrist vor der endgültigen Löschung ist eine prozessuale Antwort auf regulatorische und operative Anforderungen.

6.1.1 Der regulatorische Spielraum (ISO 27001 & BSI)

Weder die ISO 27001 noch der BSI IT-Grundschutz diktieren starre Löschfristen. Stattdessen fordern sie Schutzziele: Während Zugriffsrechte „unverzüglich“ entzogen werden müssen (ISO A.6.5 bzw. A.5.18, BSI ORP.4.A1), verlangen die Normen für die endgültige Löschung von Identitäten eine „angemessene Prüffrist“ (BSI ORP.4.A15/A2), die auf einer eigenen, dokumentierten Risikoanalyse basiert. Die 180-Tage-Frist ist somit die prozessuale Antwort auf diesen Gestaltungsauftrag.

6.1.2 Die 180 Tage als risikobasierter „Sweet Spot“

Die Festlegung auf ca. sechs Monate ist keine Willkür, sondern das Ergebnis einer Abwägung zwischen vier Dimensionen:

• Recht & Compliance: 180 Tage wahren den Grundsatz der Datenminimierung (DSGVO), decken aber gleichzeitig arbeitsrechtliche Klagefristen und die initiale Phase juristischer Nachspiele sicher ab.
• Forensik & Chain of Custody: APTs werden oft erst Monate nach dem Austritt entdeckt. Die Frist sichert ein Zeitfenster für Untersuchungen und die lückenlose Beweisführung.
• Sicherheitsarchitektur (APT-Abwehr): Verwaiste SIDs in Zugriffslisten (ACLs) sind Einfallstore (Mimikatz/SID-History-Injection). 180 Tage begrenzen dieses Risiko effektiv.
• Operative Kontinuität: Erfahrungswerte zeigen, dass verspätete Zugriffsbedarfe (z. B. in laufenden Projektzyklen oder für Übergaben) fast ausschließlich innerhalb des ersten halben Jahres auftreten.

6.1.3 Fazit für die Revisionssicherheit

Die 180-Tage-Frist dient als dokumentierter Default-Wert. Sie belegt gegenüber Auditoren, dass das Unternehmen das Deprovisioning nicht dem Zufall überlässt, sondern einen gesteuerten Prozess verfolgt.

Damit wird den in Abschnitt 2 dargelegten Anforderungen an Nachweisbarkeit (ISO 27001, insb. Maßnahme A.5.18) und Prozessdisziplin (BSI IT-Grundschutz, insb. Baustein ORP.4.A1) umfassend Genüge getan. Die 180-Tage-Frist ist kein Selbstzweck, sondern der dokumentierte Ausdruck eines beherrschten Identitätslebenszyklus.

7. Fazit für die Geschäftsführung

Sauberes Deprovisioning ist kein „Nice-to-have“ für Ästheten, sondern eine notwendige Verteidigungsmaßnahme. Wer die „Kosmetik“ seiner ACLs vernachlässigt, spart Sekunden bei der Administration und riskiert Tage der Forensik nach einem APT-Vorfall.

Deprovisioning muss dabei als gelebte Governance-Kultur verstanden werden – mit kontinuierlicher Überprüfung und Bereinigung von Berechtigungen – und nicht als einmalige Technikmaßnahme.

Empfehlung: Implementierung eines strikten Gruppenkonzepts und Automatisierung der Offboarding-Workflows zur Vermeidung manueller Fehler und zur Sicherstellung der Revisionsfähigkeit. Strikter und zeitnaher Entzug der Berechtigungen, vor Löschung des Users reduziert das Risiko kontaminierter Backups.