Atlas · Dateiablage
Berechtigungsarchitektur: Wer darf was – und lässt sich das erklären?
Gute Berechtigungen erkennt man daran, dass sich jede Frage „Warum darf sie das?“ mit einem Satz beantworten lässt. Dafür braucht es Gruppen statt Einzelrechte, wenige bewusste Ausnahmen und eine regelmäßige Überprüfung. Und es braucht das Wissen, dass ein Windows-Dateiserver anders rechnet als SharePoint.
Worum es geht
Berechtigungen wachsen von selbst. Aufräumen muss man sie bewusst – und dafür muss man vorher festgelegt haben, wie sie aussehen sollen.
Diese Seite erklärt die technische Architektur. Wer welche personenbezogenen Daten sehen darf, legt Ihr Unternehmen im Zugriffskonzept fest – mehr unter Berechtigungs- und Zugriffskonzepte.
Grundsätze
Acht Grundsätze, die auf jeder Plattform gelten
Die Grundsätze stammen aus dem Identitäts- und Berechtigungsmanagement des BSI IT-Grundschutz (Baustein ORP.4, Edition 2023) und der Herstellerdokumentation. Sie sind plattformneutral – die Umsetzung ist es nicht.
Gruppen statt Personen
Rechte gehen an Gruppen, Personen werden Mitglied. Microsoft empfiehlt für Dateifreigaben ausdrücklich, Sicherheitsgruppen statt einzelnen Benutzern zu berechtigen; in SharePoint, den Zugriff über die Gruppe bzw. das Team zu steuern.
Rollen bündeln Rechte
Eine Rolle („Sachbearbeitung Buchhaltung“) bringt die Gruppen mit, die sie braucht. Wer die Rolle wechselt, wechselt die Gruppen. Der IT-Grundschutz nennt dafür Standard-Rechteprofile (ORP.4.A16).
So wenig wie nötig
Least Privilege: Rechte nur in dem Umfang, der für die Aufgabe gebraucht wird; mehr nur mit Begründung (ORP.4.A2). Need-to-know: Vertrauliches nur für die, die es kennen müssen.
Aufgaben trennen
Wer bestellt, gibt nicht selbst frei; wer administriert, arbeitet im Alltag mit einem normalen Konto. Funktionstrennung verlangt auch der IT-Grundschutz (ORP.4.A4).
Ausnahmen bewusst und dokumentiert
Jede unterbrochene Vererbung, jedes Direktrecht, jeder Link ist eine Ausnahme, die getrennt gepflegt werden muss. Wo sie nötig ist, steht dabei warum und bis wann.
Nach Schutzbedarf schneiden
Bereiche mit hohem Schutzbedarf – Personal, Gesundheit, Verträge – bekommen eigene Bereiche mit eigenem Personenkreis, statt Unterordner mit Sonderrechten.
Eintritt, Wechsel, Austritt
Rechte folgen dem Lebenszyklus der Person. Beim Wechsel kommen neue Rechte hinzu – und alte müssen gehen. Beim Austritt endet der Zugang zuverlässig.
Regelmäßig bestätigen
Verantwortliche bestätigen in festen Abständen, wer Zugriff hat. Die Dokumentation wird mit dem Ist abgeglichen (ORP.4.A3).
NTFS
Windows-Dateiserver: Freigabe × NTFS, Verweigern zuerst
Auf einem Windows-Dateiserver entscheiden zwei getrennte Rechte über den Zugriff: die Freigabeberechtigung am freigegebenen Ordner und die NTFS-Berechtigung an Ordnern und Dateien. Greift jemand über das Netzwerk auf die Freigabe zu, werden beide geprüft, und es gilt das restriktivere – so beschreibt Microsoft es aktuell für SMB-Dateifreigaben in Azure Files. Die Freigabeberechtigung wirkt nur beim Zugriff über die Freigabe; direkt am Server bzw. auf einem Terminalserver gilt nur NTFS (Microsoft-Dokumentation zu Windows Server 2008, archiviert). Verbreitet ist deshalb, die Freigabe offen zu lassen und allein über NTFS zu steuern.
NTFS kennt Zulassen und Verweigern. Windows prüft die Einträge einer Zugriffsliste der Reihe nach: explizite vor geerbten, je Ebene Verweigern vor Zulassen, geerbte vom Elternordner zuerst. Der erste Eintrag, der ein angefordertes Recht verweigert, beendet die Prüfung; ist am Ende nicht alles erlaubt, ist der Zugriff implizit verweigert. Daraus folgt: Ein explizites Zulassen an einem Ordner wirkt vor einem geerbten Verweigern.
Die Vererbung lässt sich je Ordner deaktivieren. Dann zählen dort nur die eigenen Einträge – Änderungen am übergeordneten Ordner kommen nicht mehr an. Zugriffsbasierte Aufzählung blendet Ordner ohne Recht aus; laut Microsoft ist das Sichtbarkeit, kein Zugriffsschutz.
Den Zusammenhang von Freigabe- und NTFS-Recht können Sie am Beispiel unter Benutzer und Berechtigungen durchspielen.
Vergleich
NTFS und SharePoint im Vergleich
Beide Modelle lassen sich nicht eins zu eins ineinander übersetzen. Deshalb werden Rechte vor einer Migration für die Zielplattform neu entworfen, nicht kopiert.
- VerweigernNTFS: ja, explizit oder geerbt · SharePoint: keine Verweigern-Stufe; bei der Migration nicht übernommen
- Zwei EbenenNTFS: Freigabe- und NTFS-Recht, das restriktivere gilt übers Netz · SharePoint: Organisation und Website für externe Freigabe, Rechte am Inhalt
- VererbungNTFS: je Ordner deaktivierbar · SharePoint: wird durch eigene Berechtigungen oder Teilen unterbrochen
- TeilrechteNTFS: Lesen, Schreiben, Ändern, Vollzugriff und besondere Rechte · SharePoint: Berechtigungsstufen wie Lesen, Mitwirken, Bearbeiten, Vollzugriff
- LinksNTFS: keine – Zugriff nur über Konten · SharePoint: Freigabelinks bis hin zu „Jeder“
- ExterneNTFS: nur mit eigenem Konto im Verzeichnis · SharePoint: Gastkonten und Links, je nach Einstellung
- Zuordnung beim UmzugRestriktivere Freigabe-/NTFS-Stufe wird einer SharePoint-Stufe zugeordnet, etwa Ändern → Mitwirken
Ausprobieren
Wer darf was – und warum? Im Beispielunternehmen nachrechnen
Wählen Sie eine Person und einen Ablageort im fiktiven Beispielunternehmen. Der Explorer zeigt die wirksame Berechtigung, bei Netzlaufwerken getrennt nach Freigabe und NTFS, die Einträge in der Reihenfolge, in der Windows sie auswertet, und wer sonst noch Zugriff hat. Probieren Sie Paula (Auszubildende) auf den Preislisten: Ein geerbtes Verweigern nimmt ihr das Schreiben, das Lesen bleibt.
Dateiserver (NTFS)
SharePoint / Teams
Paula Praxis (Azubi Vertrieb) · Vertrieb\Preislisten
Lesen
- Freigabe
- Vollzugriff
- NTFS
- Lesen
- wirksam
- Lesen
- Verweigert: Schreiben – NTFS „Schreiben“ über „GG Auszubildende“ (Rolle Auszubildende), geerbt von „Abteilungen\Vertrieb“.
- Erlaubt: Lesen, Löschen – NTFS „Ändern“ über „GG Auszubildende“ (Rolle Auszubildende), geerbt von „Abteilungen\Vertrieb“.
- Erlaubt: Lesen, Schreiben, Löschen, Berechtigungen ändern – Freigabeberechtigung „Vollzugriff“ über „Alle Mitarbeitenden (berechnet)“, Freigabe „\\dateiserver\Abteilungen“.
- Über das Netz gilt die restriktivere Kombination: Freigabe Vollzugriff × NTFS Lesen → Lesen.
| # | Gruppe/Person | Art | Stufe | festgelegt an | für diese Person |
|---|---|---|---|---|---|
| 1 | GG Auszubildende | Verweigern | Schreiben | Abteilungen\Vertrieb (geerbt) | entscheidet: W |
| 2 | GG Vertrieb | Zulassen | Ändern | Abteilungen\Vertrieb (geerbt) | – |
| 3 | GG GF | Zulassen | Lesen | Abteilungen\Vertrieb (geerbt) | – |
| 4 | GG Auszubildende | Zulassen | Ändern | Abteilungen\Vertrieb (geerbt) | entscheidet: R, D |
| 5 | GG IT-Administration | Zulassen | Vollzugriff | \\dateiserver\Abteilungen (geerbt) | – |
R = Lesen · W = Schreiben · D = Löschen · P = Berechtigungen ändern (Modellvereinfachung).
Wer hat Zugriff? 14 von 33 Personen
- Greta Geschäftsführung: Lesen
- Gustav Geschäftsführung: Lesen
- Anna Assistenz: Lesen
- Viktor Vertriebsleitung: Schreiben · Ändern
- Vera Vertrieb: Schreiben · Ändern
- Valentin Vertrieb: Schreiben · Ändern
- Vincent Vertrieb: Schreiben · Ändern
- Vanessa Vertrieb: Schreiben · Ändern
- Volker Vertrieb: Schreiben · Ändern
- Paula Praxis (Azubi Vertrieb): Lesen
- Tobias Technik (Azubi): Lesen
- Ida IT: Vollzugriff
- Ingo IT-Organisation: Vollzugriff
- IT-Dienstleister Techniker (extern, fiktiv): Vollzugriff
Was entfällt mit der alten Rolle, was kommt neu hinzu – und was bleibt, weil es nicht an der Rolle hängt (Direktrechte, Projektgruppen, Freigabelinks)?
Modellannahmen in diesem Bereich
- NTFS-/Freigabestufen als Bündel aus Lesen (R), Schreiben (W), Löschen (D), Berechtigungen ändern (P); Spezialberechtigungen nicht modelliert
Lehrbeispiel auf einem fiktiven Atlas-Modell. Die Ergebnisse rechnet der Atlas-Modellkern nach vereinfachten, dokumentierten Regeln; sie ersetzen keine Prüfung Ihrer Umgebung. Fiktives Beispielunternehmen. Alle Namen, Rollen, Gruppen und Strukturen sind erfunden und dienen nur der Veranschaulichung; keine echten Kunden- oder Personendaten.
Alle Berechtigungen als Tabelle
| Person | \\dateiserver\Abteilungen | Abteilungen\Vertrieb | Vertrieb\Preislisten | Vertrieb\Schulungsunterlagen | Abteilungen\Buchhaltung | Buchhaltung\Lohn | Abteilungen\Technik | \\dateiserver\Projekte | Projekte\Alpha | Teams-Website „Projekt Alpha“ | Dokumente | Vertrag & Kalkulation | Planstand.pdf | Angebot-Entwurf.docx |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Paula Praxis (Azubi Vertrieb) | kein Zugriff | Lesen | Lesen | Ändern | kein Zugriff | kein Zugriff | kein Zugriff | kein Zugriff | kein Zugriff | kein Zugriff | kein Zugriff | kein Zugriff | kein Zugriff | kein Zugriff |
| Valentin Vertrieb | kein Zugriff | Ändern | Ändern | Ändern | kein Zugriff | kein Zugriff | Ändern | kein Zugriff | Ändern | Bearbeiten | Bearbeiten | kein Zugriff | Bearbeiten | Bearbeiten |
| Viktor Vertriebsleitung | kein Zugriff | Ändern | Ändern | Ändern | kein Zugriff | kein Zugriff | kein Zugriff | Lesen | Ändern | Bearbeiten | Bearbeiten | Bearbeiten | Bearbeiten | Bearbeiten |
| Berta Buchhaltung | kein Zugriff | kein Zugriff | kein Zugriff | kein Zugriff | Ändern | Ändern | kein Zugriff | kein Zugriff | kein Zugriff | kein Zugriff | kein Zugriff | kein Zugriff | kein Zugriff | kein Zugriff |
| Greta Geschäftsführung | kein Zugriff | Lesen | Lesen | Lesen | Ändern | Lesen | kein Zugriff | Lesen | Lesen | Vollzugriff | Vollzugriff | Vollzugriff | Vollzugriff | Vollzugriff |
| Ida IT | Vollzugriff | Vollzugriff | Vollzugriff | Vollzugriff | Vollzugriff | nur Löschen über den übergeordneten Ordner | Vollzugriff | Ändern | Ändern | Vollzugriff | Vollzugriff | Vollzugriff | Vollzugriff | Vollzugriff |
| Planungsbüro Kontakt 1 (extern, fiktiv) | kein Zugriff | kein Zugriff | kein Zugriff | kein Zugriff | kein Zugriff | kein Zugriff | kein Zugriff | kein Zugriff | kein Zugriff | Bearbeiten | Bearbeiten | kein Zugriff | Bearbeiten | kein Zugriff |
| IT-Dienstleister Techniker (extern, fiktiv) | Vollzugriff | Vollzugriff | Vollzugriff | Vollzugriff | Vollzugriff | nur Löschen über den übergeordneten Ordner | Vollzugriff | Ändern | Ändern | kein Zugriff | kein Zugriff | kein Zugriff | kein Zugriff | kein Zugriff |
- Microsoft Learn: Order of ACEs in a DACL (abgerufen 2026-11-02)
- Microsoft Learn: How AccessCheck Works (How DACLs Control Access to an Object) (abgerufen 2026-11-02)
- Microsoft Learn (archiviert, Windows Server 2008): Share and NTFS Permissions on a File Server (abgerufen 2026-11-02)
- Microsoft Learn: Configure Directory and File-Level Permissions for Azure Files (Abschnitt „How Azure RBAC and Windows ACLs work together“) (abgerufen 2026-11-02)
- Modellvereinfachung: NTFS-/Freigabestufen als Bündel aus Lesen (R), Schreiben (W), Löschen (D), Berechtigungen ändern (P); Spezialberechtigungen nicht modelliert
- Microsoft Learn: Understanding permission levels in SharePoint (abgerufen 2026-11-02)
- Modellannahme: SharePoint-Berechtigungsstufen gewähren Rechte; Verweigerungsrichtlinien auf Mandantenebene sind nicht modelliert
- Modellannahme: Geteilte Elemente bleiben im Modell mit den geerbten Berechtigungen verbunden; in SharePoint beendet das Teilen die Vererbung (Kopie der Berechtigungen) – spätere Änderungen an Berechtigungen oberhalb wirken im Modell weiter, in SharePoint nicht
- Modellannahme: Gruppen werden über beliebig viele Ebenen transitiv aufgelöst (vereinfachend, NTFS und SharePoint gleich); ob und wie Gruppen verschachtelt werden können, hängt vom Gruppentyp ab – das Modell unterscheidet die Typen nicht
- Microsoft Learn: Freigabelinks (Jeder, bestimmte Personen, Organisation) (abgerufen 2026-11-02)
- Modellvereinfachung SharePoint: Externe Freigabe „Gäste“ fasst „neue und vorhandene Gäste“ und „nur vorhandene Gäste“ zusammen; Links für bestimmte Personen gehen im Modell nur an Personen (nicht an Sicherheitsgruppen); ob ein Organisationslink eingelöst ist, regelt allein die Angabe im Modell
- Microsoft Open Specifications [MS-FSA]: Algorithm to Check Access to an Existing File (DELETE wird gewährt, wenn das Elternobjekt FILE_DELETE_CHILD erlaubt) (abgerufen 2026-11-02)
- Microsoft Learn: DeleteFileA (Löschen mit Delete-Recht an der Datei oder „delete child“ am übergeordneten Verzeichnis) (abgerufen 2026-11-02)
- Microsoft Learn: File Access Rights Constants (FILE_DELETE_CHILD) (abgerufen 2026-11-02)
- Microsoft Learn (archiviert, Windows Server 2003): File and Folder Permissions („Unterordner und Dateien löschen“, „Berechtigungen ändern“, „Besitz übernehmen“ nur in Vollzugriff) (abgerufen 2026-11-02)
- Modellannahme Konten: Gäste haben kein Konto im lokalen Verzeichnis und gehören zu keiner Verzeichnisgruppe; Dienstleister haben ein internes Konto und zählen zu „Alle Mitarbeitenden“ bzw. „Jeder außer externen Benutzern“; deaktiviertes Konto → keine Anmeldung, kein Zugriff
Rollenwechsel
Beispiel: Wechsel vom Vertrieb in die Buchhaltung
Ein Abteilungswechsel zeigt, ob eine Berechtigungsarchitektur trägt: Mit Rollen und Gruppen ist er eine Änderung an einer Stelle, mit gewachsenen Einzelrechten eine Suche.
Neue Rolle zuweisen
Die Rolle „Buchhaltung“ bringt die Gruppe mit den Rechten auf Belege, Rechnungen und die Teamwebsite der Buchhaltung.
Alte Rolle entziehen
Die Gruppe „Vertrieb“ entfällt – und mit ihr Kundenordner und Preislisten. Ohne diesen Schritt wächst der Zugriff mit jedem Wechsel.
Ausnahmen prüfen
Direktrechte an Ordnern, Mitgliedschaften in Projektteams, Freigabelinks, die die Person erstellt oder erhalten hat, gehen nicht mit der Rolle. Sie müssen einzeln geprüft werden.
Funktionstrennung beachten
Wer Bestellungen auslöst, soll sie nicht selbst buchen. Überschneidungen zwischen alter und neuer Rolle während einer Übergangszeit werden befristet und dokumentiert.
Bestätigen lassen
Die neue Führungskraft bestätigt die Rechte. Wie Rechte beim Wechsel wachsen und wie nicht, zeigt die Simulation unter Rollenwechsel.
Überprüfung
Überprüfung: Rezertifizierung und Externe
Rechte werden in festen Abständen von den Verantwortlichen bestätigt – nicht von der IT, die nur sieht, dass ein Recht besteht, nicht, ob es gebraucht wird. Je höher der Schutzbedarf, desto kürzer der Abstand. Auf einem Dateiserver helfen Berichte über Gruppenmitgliedschaften und Ordnerrechte; in Microsoft 365 gibt es dafür Zugriffsüberprüfungen in Microsoft Entra.
Externe brauchen besondere Aufmerksamkeit: Sie haben keinen Austrittstermin im Personalsystem. Jeder externe Zugang braucht einen Zweck, eine verantwortliche Person und ein Ende – mehr unter Gastkonten und Identity Governance.
Änderungen an Zugriffsrechten sollten protokolliert werden; für Fileserver nennt der IT-Grundschutz das ausdrücklich (APP.3.3.A9). Wie lange solche Protokolle aufbewahrt werden, legt Ihr Datenschutz fest.
Angebot
Unterstützung durch ENTDECKE
Berechtigungs- und Zugriffskonzepte
Rollen, Berechtigungsmatrix und Überprüfung – im technischen Datenschutz.
Benutzer und Berechtigungen im Betrieb
Konten und Gruppen in Active Directory und Microsoft Entra ID pflegen; Umfang individuell abgestimmt.
Eintritt, Wechsel, Austritt
Identity Lifecycle mit Rollen und Automatisierung.
Berechtigungen für eine Zielplattform entwerfen
NTFS-Bestand inventarisieren und für SharePoint neu schneiden – als Teil von Einführung und Migration.
Häufige Fragen
Können wir unsere NTFS-Rechte einfach mitnehmen?
Technisch übernehmen Migrationswerkzeuge Rechte auf Benutzerebene und ordnen sie SharePoint-Stufen zu. Explizite Verweigerungen gehen dabei verloren, und gewachsene Ausnahmen werden zu unterbrochener Vererbung in SharePoint. Deshalb empfehlen wir, Rechte für die Zielstruktur neu zu entwerfen und nur bewusst zu übernehmen.
Warum nicht einfach „Verweigern“ setzen?
Weil Verweigern schwer nachvollziehbar ist: Es wirkt je nach Reihenfolge und Herkunft der Einträge unterschiedlich und überlagert Gruppenrechte. Besser ist eine Struktur, in der vertrauliche Inhalte in eigenen Bereichen liegen, zu denen nur die Berechtigten Zugang haben.
Wie oft sollen Rechte überprüft werden?
Eine feste Vorgabe gibt es nicht; der Abstand richtet sich nach dem Schutzbedarf. Wichtig ist, dass die Überprüfung stattfindet, dokumentiert wird und Konsequenzen hat.
Was hat das mit Copilot zu tun?
Microsoft 365 Copilot zeigt nur Inhalte, die die Person mindestens lesen darf. Zu weite Rechte werden dadurch sichtbarer. Eine aufgeräumte Berechtigungsarchitektur ist deshalb eine Voraussetzung für den Einsatz – mehr unter Microsoft 365 Copilot.
Ihre Berechtigungen nachvollziehbar machen
Wir sehen uns mit Ihnen an, wie Rechte heute vergeben sind, und entwickeln eine Architektur, die sich erklären und prüfen lässt. Telefon 07131-618726-0.