Kurzer Kopfschmerz, langes Risiko: Wer in chaotisch gewachsenen Dateiserver-Strukturen endlich wissen will, wer wo was darf – und warum.

„Wer darf eigentlich da drauf?“ – Transparenz für den Dateiserver, die endlich beantwortet, was niemand mehr wusste

Ein Blogbeitrag über das Projekt fs-acl – eine Web-Anwendung, die die oft undurchschaubaren Zugriffsberechtigungen auf Windows-Dateiservern sichtbar macht. Für Admins, die den Überblick verloren haben, und für User, die lange genug vor verschlossenen Ordnern stehen mussten – und nicht mehr wissen, warum, für Vorgesetze die sehen wollen wer Zugriff auf ihre Abteilungsdaten hat.

Warum wir überhaupt ein Problem haben

Jedes Unternehmen kennt es: Der Dateiserver wächst seit fünfzehn Jahren. Ordnung wird am Anfang gemacht, dann wird es hektisch, irgendwann ist da einfach ein Ordner, auf dem irgendwer Rechte hat. Neue Mitarbeiter bekommen Zugriff „zur Sicherheit“, ausscheidende Kollegen werden selten sauber entfernt. Teams werden umgebaut, Gruppen umbenannt – aber die alten ACL-Einträge wandern leise mit, von Ordner zu Ordner, von Vererbung zu Vererbung.

Das Ergebnis: Niemand hat mehr einen echten Überblick.

Der Admin fragt sich: Wer hat eigentlich Zugriff auf den Finanzordner? Sind die Domänen-Admins wirklich auf allen dreißig Shares nötig?
Der User fragt sich: Warum kann ich diesen Ordner nicht öffnen? Und wer kann eigentlich all meine Daten sehen?

Beides ist gefährlich. Undurchsichtige Berechtigungen sind ein Compliance- und Datenschutzrisiko – und gleichzeitig ein täglicher Reibungspunkt für produktive Arbeit. Windows selbst zeigt einzelne ACL-Einträge an, aber es ist ein Flickenteppich aus Dialogen, Vererbungsketten und Gruppenzugehörigkeiten, die irgendwo im Active Directory versteckt sind. Niemand sieht das große Bild.

Genau hier setzt fs-acl an.

screenshot

Die Idee: ein einziges Fenster auf die Berechtigungswelt

Das Projekt ist als öffentlich veröffentlichbare Demo konzipiert. Alle Daten sind frei erfunden (Domain BEISPIEL, Server \\fileserver01), damit das Prinzip – und die Technik dahinter – transparent gemacht werden kann, ohne echte Unternehmensdaten zu berühren. Der Aufbau kommt aber direkt aus der Realität: Die Rohdaten, mit denen wir arbeiten, sehen genauso aus wie die Exporte eines echten Windows-Domain-Controllers.

Die Kernidee ist bewusst einfach gehalten, aber sie beantwortet die zwei Fragen, die uns alle interessieren:

Für einen User: Welche Zugriffe habe ich auf welche Ressourcen – und warum? Über welche Gruppe wurde mir das Recht eigentlich vererbt?
Für eine Ressource: Welche Gruppen und User haben hier Zugriff, mit welcher genauen Berechtigung – und woher stammt sie?

Dazu kommen Filter in beide Richtungen: nach Berechtigung oder nach Ressource. Ein Klick auf einen Nutzer zeigt dessen effektiven Zugriff. Ein Klick auf einen Ordner zeigt alle Beteiligten. Das ist die Übersichtlichkeit, die in Windows selbst so schmerzhaft fehlt.

screenshot

Die Rohdaten: Woher die Informationen kommen

Die Grundlage sind time-based Exporte vom Windows-Domain-Controller. Zwei CSV-Dateien bilden das Fundament:

1. acl_department_level.csv – die eigentlichen Berechtigungen pro Ordner/Share. Jede Zeile beschreibt ein Zugriffsrecht: auf welchen Ordner, für wen (Gruppe oder User), mit welcher Berechtigungsart (Lesen, Schreiben, Ändern, Löschen, Vollzugriff), ob es vererbt wurde und – entscheidend – über welchen Principal es ererbt wurde.

2. AD_group_members.csv – die Active-Directory-Gruppenmitgliedschaften. Hier steht, welcher User in welcher Gruppe steckt.

Der springende Punkt ist die Kombination beider Quellen. Ein einzelner ACL-Eintrag nennt oft eine Gruppe (BEISPIEL\Finanzen-RW-L) und nicht direkt einen Menschen – einen Principal. Erst wenn ich die Gruppenmitgliedschaften auflöse, weiß ich, welcher konkrete User dahinter steckt. Genau diese Auflösung von „Gruppe → Menschen“ macht den Unterschied zwischen roher Export-Datei und echter Einsicht aus.

Interessant ist auch der Zeit-Charakter: Die Exports sind time-based. Die beiden CSVs können zu unterschiedlichen Zeitpunkten generiert worden sein und unterschiedlichen Stand haben. Das muss die Verarbeitung verkraften – keine der beiden Dateien ist die „eine Wahrheit“, sondern ein Snapshot aus dem Domain-Controller.

Ein Detail, das zeigt, wie viel Sorgfalt hier drin steckt

Die Exports kommen typischerweise im Windows-1252-Encoding – schließlich enthalten sie deutsche Umlaute (ä, ö, ü, ß) und kommen aus einer Windows-Welt. Manche Tools erzeugen aber UTF-8. Das Backend löst das elegant: Es probiert zuerst striktes UTF-8 (inklusive Behandlung einer UTF-8-BOM), und wenn das scheitert – also typische Windows-1252-Umlaut-Bytes auftauchen – fällt es automatisch auf Windows-1252 zurück. Das ist unscheinbar, aber genau so ein Detail bewahrt eine Anwendung davor, mitten in der Produktion auf „Ãœber” statt „Über” zu verenden.

Das Backend: Deno, aufgeräumt in Clean Architecture

Das Rückgrat ist ein **Deno-**Webdienst, der die CSVs liest, verarbeitet und als REST-API verfügbar macht. Erfreulich daran ist die saubere Architektur: Das Projekt folgt Clean Architecture mit Konstruktor-Injektion – der Composition Root in main.ts verdrahtet Repositories und Services, ohne dass die Domänenlogik von der Infrastruktur abhängig ist.

backend/src
  domain/          # Entitäten + Repository-Schnittstellen
  application/     # Services (die eigentliche Business-Logik)
  infrastructure/  # CSV-Reader (Encoding-Auto-Detect), CSV-Repositories
  interfaces/      # HTTP-Routen
  main.ts          # Composition Root / Einstiegspunkt

Die Bedeutung dahinter: Man kann später den CSV-Reader durch eine echte Datenbank oder ein Live-AD abhängend hinter denselben Services austauschen, ohne auch nur eine Zeile der Business-Logik anzufassen. Die Domain kennt nicht einmal die CSV-Welt.

Die API bietet Endpunkte wie:

GET /api/folders – alle Shares/Ordner
GET /api/users/:q/access – effektiver Zugriff eines Users
GET /api/folders/:f/access – wer hat auf einen Ordner Zugriff
GET /api/access/overview – die große Übersicht
sowie Suggest-Endpunkte (/api/users, /api/groups), damit die UI benutzerfreundlich automatisch vervollständigen kann

Dass Ordner- und Userpfade \ und $ enthalten können, wird dabei über korrektes URL-Encoding gehandhabt – auch das eine dieser „unsichtbaren” Sorgfaltspunkte.

Das Frontend: SvelteKit mit Carbon-Design

Auf der Nutzerseite steht eine SvelteKit-Web-App (Svelte 5) im IBM Carbon Style – einem Designsystem, das in Enterprise-Umgebungen zu Hause ist. Das Frontend spricht ausschließlich mit dem eigenen Origin: /api-Anfragen werden server-seitig an das Deno-Backend weitergeleitet (über hooks.server.ts und die BACKEND_URL). Der Browser sieht also nie direkt das Backend – ein sauberes, sicheres Muster, das auch späteres Umsortieren der Infrastruktur erlaubt.

Die zwei zentralen Sichten ergeben sich direkt aus den Kernfragen:

User-Sicht: Suchfeld für einen Mitarbeiter → zeigt dessen effektiven Zugriff pro Ressource, samt Quelle der Berechtigung.
Ordner-Sicht: Auswahl eines Shares/Ordners → zeigt Gruppen und User, die dort Zugriff haben, inklusive aller Rechte-Flags.

Die UI lädt alles live über die API – keine statisch generierten Seiten zum Exportzeitpunkt, sondern Interaktion gegen den aktuellen Datenbestand.

Deployment: Docker, damit es überall läuft

Das Ganze ist als Docker-Compose-Setup aufgesetzt (Linux), das Backend und Frontend als eigene Container startet. Die CSV-Dateien werden schreibgeschützt in das Backend gemountet – sauber für den Kontext „time-based Export, der periodisch neu hereinkommt”. Das Frontend publiziert dabei bewusst den Host-Port 3002, sodass die Demo parallel zur ursprünglichen Produktion (Port 3001) laufen kann, ohne dass sich Container oder Ports streiten.

Was können wir noch bauen? – Ideen für die nächsten Schritte

Das hier arbeitet schon heute – aber es ist erst der Anfang. Das Spannendste an einem solchen Fundament ist, wohin man damit wachsen kann. Meine Ideen, grob nach Wucht sortiert:

Auf der Daten-Ebene

Historische Snapshots & Zeitreise. Die Daten sind time-based – warum nicht mehrere Exporte speichern und zeigen, wie sich Berechtigungen über die Zeit entwickelt haben? „Wer hat letzte Woche Zugriff auf den Finanzordner bekommen?” Das wäre Gold für Audits und die berüchtigte Frage nach „Drift”.
Drift-Detection / Warnungen. Automatisch erkennen, wenn ein Ordner wieder vom erwarteten Schema abweicht – etwa wenn ein Einzel-User plötzlich Vollzugriff erbt, oder wenn eine Gruppe aufviele Ordner erweitert wurde.
Weitere Datenquellen verbinden. Der große Aufhänger aus dem Projekt: Auch Rollen und Berechtigungen aus Anwendungen einbinden – etwa Datenbanken, SharePoint-Listen oder die Berechtigungsmodelle einzelner Fachanwendungen. Das „Wer kann was“ ist ja nicht nur eine Dateiserver-Frage. Ein zusammengeführtes, konzernweites Berechtigungsbild wäre ein echtes Alleinstellungsmerkmal.

Auf der Analyse-Ebene

Risiko-Scores & Dashboards. Berechtigungen gewichten (z.B. Vollzugriff
- geerbt + nur über eine Administratorengruppe), daraus ein Risiko-Ranking pro User, Gruppe und Ordner ableiten – und die „heißen“ Stellen im Dashboard hervorheben.
Berechtigungshistorie & „redundante” Rechte erkennen. Wer hat Rechte, die er gar nicht braucht, weil er sie doppelt (über mehrere Gruppen) erbt? Was kann bereinigt werden ohne Risiko?

Auf der Prozess-Ebene

Self-Service-Anträge. Direkt aus der UI einen Berechtigungsantrag samt Begründung stellen – idealerweise mit Freigabe-Workflow (Vorgesetzter / Datenverantwortlicher genehmigt) und automatischer Provisionierung zurück ins Active Directory. Aus „Information zeigen” wird „Änderung anstoßen”.
Recertification-Kampagnen. „Alle Berechtigungen von Gruppe X durch Verantwortliche wieder bestätigen lassen” – periodisch, mit Frist und Erinnerung. Ein Klassiker der Identity-Governance, der hier direkt andocken kann.
Notifications & PII-Checks. Benachrichtigung, wenn sich kritische Rechte ändern, oder automatisierte Prüfung, ob personenbezogene Ordner nur von berechtigten Personen lesbar sind (DSGVO!).

Der wichtigste Rat: Baut die API als Fundament – nicht als Nebenprodukt

Wenn aus diesem Projekt eine dauerhafte Lösung werden soll, ist das Wichtigste, das zu tun, was hier schon angelegt ist: eine ehrliche, saubere, gut dokumentierte API aufzubauen.

Warum? Weil die einzige Konstante in der Berechtigungswelt der ständige Wandel ist – und jede der oben genannten Ideen (Dashboard, Risk-Scores, Workflows, Recertification, Anwendungs-Rollen) sich am Ende in die gleichen, stabilen API-Schnittstellen einhängt. Wer zu früh nur auf eine einbalsamierte Oberfläche baut, erkennt morgen, dass die nächste Use-Case-Iteration von vorn beginnt. Wer eine gute API hat, kombiniert Use Cases, statt sie neu zu bauen.

Die Clean Architecture des Backends und die saubere Trennung von UI (nur über /api) und Logik sind genau dieser Gedanke in die Praxis übersetzt. Genau daran anknüpfen heißt: Endpunkte als stabile Verträge behandeln, Versionieren, und jeden neuen Use Case als Erweiterung der API denken – nicht als Umweg. Dann wird aus einem netten Tool ein dauerhafter Baustein der Identity-Governance im Unternehmen.

Fazit

Auf den ersten Blick ist fs-acl eine übersichtliche Web-App für Dateiserver-Berechtigungen. Genau das richtige Maß an Ehrgeiz dahinter ist die Kombination aus durchdachter Architektur, robuster Datenverarbeitung (inklusive Encoding-Nebenpfaden) und einer klaren Produktidee: Transparenz schaffen, wo chaotisch gewachsene Strukturen niemanden mehr durchblicken lassen.

Der Weg von hier zur vollwertigen Governance-Plattform (Anwendungsrollen, Workflows, Risk-Scores, Recertification) ist kurz – wenn man sich an den wichtigsten Grundsatz hält: Die API ist das Fundament, und alles andere hängt sich daran. Dann bleibt dieser Überblick nicht nur heute nützlich – er wird mit dem Unternehmen mitwachsen.

Möchtest du wissen, welche der Erweiterungsideen realistisch als Nächstes umzusetzen sind – und wie konkret die API dafür aussehen müsste? Sprich uns an. Transparenz gewinnt.

Rollen&Berechtigungen - transparent und für jeden zugänglich