SharePoint-Berechtigungen richtig strukturieren

Stell in einem beliebigen Unternehmen eine einzige Frage: „Wer kann diese Inhalte sehen — und warum?“ Wenn die Antwort mit „eigentlich“ beginnt oder länger als eine Minute dauert, willkommen im Club: Berechtigungen sind das Dauerbrenner-Schmerzthema jeder SharePoint-Umgebung. Nicht weil die Technik kompliziert wäre — sondern weil jahrelang jeder mal schnell etwas freigegeben, einen Ordner „extra berechtigt“ und einen Externen eingeladen hat. Dieser Artikel legt die drei Schichten frei, aus denen die Berechtigungswahrheit wirklich besteht, zeigt das Zielmodell, das man in zwei Sätzen erklären kann — und den Fahrplan, mit dem du einen gewachsenen Flickenteppich zurückbaust.

Warum Berechtigungen immer entgleisen

Der Kardinalirrtum beim Thema Berechtigungen: der Glaube, die Gruppenübersicht zeige die Wahrheit. Tut sie nicht — sie zeigt ein Drittel davon. Die tatsächliche Zugriffslage besteht aus drei Schichten: den Gruppen (sichtbar und gewollt), den Vererbungsbrüchen und Einzelrechten (halb sichtbar, meist vergessen) und den Freigabelinks (im Gruppenbild komplett unsichtbar). Jede Schicht für sich ist harmlos. Zusammen ergeben sie nach ein paar Jahren einen Zustand, den niemand mehr beschreiben kann — bis Suche oder Copilot ihn schonungslos vorführen:

Skizze 1: Die drei Schichten der Berechtigungswahrheit — was gilt, ist die Summe aus Gruppen, Brüchen und Freigabelinks. Wer nur Schicht 1 kennt, kennt ein Drittel.

Das Tückische ist die Entstehungsgeschichte: Keine dieser Altlasten war je böswillig. Der extra berechtigte Ordner löste vor drei Jahren ein echtes Problem, das Einzelrecht half einer Kollegin über eine Projektphase, der Organisations-Link beschleunigte eine Abstimmung. Nur hat niemand je etwas davon zurückgebaut — denn Wegnehmen fühlt sich riskant an, Dazugeben nicht. Berechtigungen kennen deshalb nur eine natürliche Richtung: mehr. Gegen diese Physik hilft kein Appell, sondern nur ein Modell mit eingebautem Rückbau.

Das Zielmodell: einfach genug, um es zu erklären

Die Website ist die Grenze — und drei Rollen reichen

Das tragfähige Modell ist unspektakulär: Wer unterschiedliche Rechte braucht, bekommt unterschiedliche Websites — nicht unterschiedliche Ordner. Innerhalb der Website reichen fast immer die drei Standardrollen: Besitzer verwalten (zwei, drei Personen, nicht die halbe Abteilung), Mitglieder arbeiten, Besucher lesen. Vertrauliches bekommt eine eigene Website statt eines extra berechtigten Ordners im Gemeinschaftsraum — das kostet einen Klick mehr beim Anlegen und spart Jahre beim Verwalten.

Gruppen rein, Personen raus

Die zweite Regel kennst du aus dem Workflow-Artikel dieses Clusters, und sie gilt hier genauso: Berechtigt werden Gruppen und Rollen, niemals einzelne Personen. Einzelrechte überleben jeden Abteilungswechsel und jede Kündigung — Gruppenmitgliedschaften werden dagegen zentral im Entra ID gepflegt, idealerweise entlang der Organisationsprozesse: Wer die Abteilung wechselt, wechselt die Gruppen, und die SharePoint-Rechte folgen automatisch. Der schöne Nebeneffekt: Onboarding und Offboarding werden von der Berechtigungsfrage entkoppelt.

Ausnahmen als bewusste Entscheidung

Und weil das Leben Ausnahmen produziert, braucht das Modell einen geregelten Umgang damit statt eines Verbots: Ein Vererbungsbruch ist erlaubt — als dokumentierte Einzelentscheidung mit Grund, Eigner und Ablaufdatum. Was diese drei Angaben nicht hat, wird beim nächsten Review zurückgebaut. So bleibt die Zahl der Ausnahmen zweistellig statt vierstellig, und jede einzelne kann jemand erklären. Der Lackmustest fürs ganze Modell bleibt die Eingangsfrage: Wer kann das sehen, und warum — beantwortbar in einer Minute, ohne „eigentlich“.

Freigabelinks zähmen — die unsichtbare dritte Schicht

Die gefährlichste Schicht ist die bequemste: der Teilen-Button. Jeder Link erzeugt einen eigenen Berechtigungseintrag, den die Gruppenübersicht nicht zeigt — und „Personen in <Organisation>“-Links sind dabei die Klassiker der ungewollten Öffentlichkeit: für eine Abstimmung erstellt, nie zurückgebaut, und plötzlich steht die Ablage dem ganzen Haus offen. Die Suche findet das gnadenlos, wie der Such-Artikel dieses Clusters mit seiner Gehaltslisten-Geschichte zeigt. Die Gegenmittel sind Konfiguration, nicht Erziehung: Standardlinktyp auf „Bestimmte Personen“ stellen, Ablaufdaten für Links erzwingen, „Jeder“-Links nur dort erlauben, wo Externes wirklich gewollt ist — und die Freigabeberichte je Website regelmäßig sichten. Wer teilen will, soll teilen können; nur eben sichtbar und endlich.

Aufräumen im Bestand: der Fahrplan

Bleibt der Bestand — und für den gilt: erst messen, dann bewerten, dann bauen. Die Inventur erhebt per Bericht und Skript alle Brüche, Einzelrechte, Links und Gastkonten; die Klassifizierung trennt Gewolltes von Altlasten, priorisiert nach Schutzbedarf; das Zielmodell entscheidet, was in eigene Websites ausgegliedert wird. Und dann kommt der Schritt, den die IT nicht allein gehen kann: die Rezertifizierung. Ob jemand Zugriff braucht, weiß nicht der Admin, sondern der fachliche Eigner — er bestätigt je Website, wer wirklich was braucht. Erst danach wird umgebaut, dokumentiert, und der Quartalsreview übernimmt:

Skizze 2: Der Aufräum-Fahrplan in fünf Schritten mit Rezertifizierung durch den Fachbereich — und dem Quartalsreview als Dauerbetrieb statt Fünf-Jahres-Großprojekt.

FAQ zu SharePoint-Berechtigungen

Wie finde ich heraus, wer wirklich Zugriff auf eine Website hat?

Nicht über die Gruppenübersicht allein — die zeigt nur Schicht eins. Für das vollständige Bild brauchst du je Website die Websiteberechtigungen inklusive Einzelrechten, den Bericht über Vererbungsbrüche in Bibliotheken und Ordnern sowie die Freigabeberichte für Links und Gäste. Bei größeren Umgebungen läuft das per Skript oder Werkzeug — von Hand geklickt ist die Inventur nach der dritten Website tot.

Sollte ich Berechtigungen auf Ordner-Ebene vergeben?

Als Regelfall nein. Jeder Vererbungsbruch ist ein Pflegefall auf Lebenszeit, die Limits setzen harte Grenzen, und nach ein paar Jahren durchschaut niemand mehr das Geflecht. Die saubere Antwort auf „nicht jeder darf das sehen“ ist eine eigene Website — Ordnerrechte bleiben die dokumentierte Ausnahme mit Eigner und Ablaufdatum, nicht das Konstruktionsprinzip.

Was ist der Unterschied zwischen SharePoint-Gruppen und Microsoft-365-Gruppen?

Die drei SharePoint-Gruppen (Besitzer, Mitglieder, Besucher) gehören zur einzelnen Website und steuern nur dort. Die Microsoft-365-Gruppe hinter einer Teamwebsite ist breiter: Sie steuert auch Teams, Planner und Postfach — wer dort Mitglied wird, bekommt das Gesamtpaket. Praktisch heißt das: Teamzugehörigkeit über die M365-Gruppe regeln, reine Lese- oder Sonderrechte über die SharePoint-Gruppen der Website.

Wie gehe ich mit externen Gästen um?

Einladen ja — aber nach Regeln: jede Einladung mit fachlichem Paten und Ablaufdatum, Gastzugriff nur auf die konkrete Projektwebsite statt auf Gemeinschaftsbereiche, und ein Quartalsreview, der jedem Gastkonto die Existenzfrage stellt. Technisch flankieren das die Freigabeeinstellungen je Website und Zugriffsüberprüfungen im Entra ID. Ein Gast ohne Ablaufdatum ist ein Mitarbeiter ohne Vertrag.

Was bedeutet das 50.000er-Limit für eindeutige Berechtigungen praktisch?

Es ist die technische Quittung für den Ordner-Flickenteppich: Maximal 50.000 eindeutig berechtigte Elemente je Liste oder Bibliothek, empfohlen höchstens 5.000 — und oberhalb von 100.000 Elementen lässt sich Vererbung gar nicht mehr unterbrechen. Wer sich diesen Grenzen nähert, hat kein Limit-Problem, sondern ein Architekturproblem: Die Inhalte gehören in mehrere Websites mit heiler Vererbung.

Warum sind Berechtigungen vor einer Copilot-Einführung so wichtig?

Weil Copilot die ehrlichste Berechtigungsprüfung ist, die je gebaut wurde: Er beantwortet Fragen aus allem, worauf der Fragende Zugriff hat — inklusive der vergessenen Freigaben und Alt-Links. Was bisher nur theoretisch offen stand, wird damit praktisch auffindbar. Die Berechtigungsinventur gehört deshalb vor jedes Copilot-Projekt; mehr dazu im Copilot-Artikel dieses Clusters.