Datenschutz in Microsoft SharePoint Online

SharePoint Online und OneDrive for Business sind zentrale Bausteine für die Zusammenarbeit in Microsoft 365. Ab Werk sind viele Tenants aber auf maximale Offenheit konfiguriert, damit das Teilen von Inhalten so einfach wie möglich ist. Aus Sicht der DSGVO und der Unternehmenssicherheit ist das oft ein Problem.

Als Administrator hältst du die Waage: Die Daten müssen geschützt und DSGVO-konform verwaltet werden, ohne dass zu restriktive Hürden die Produktivität bremsen. Die folgenden Einstellungen im SharePoint Admin Center sichern deine Umgebung ab.

Alle Befehle laufen über das Modul Microsoft.Online.SharePoint.PowerShell. Modul installieren und mit dem SharePoint Admin Center verbinden.

Einige Bereiche haben kein eigenes Cmdlet. Sie werden über die Admin-Center-UI, Entra ID oder den AIPService gesteuert. Das ist an der jeweiligen Stelle vermerkt, damit du nicht nach einem Parameter suchst, den es nicht gibt.

Der wichtigste Hebel für die Sicherheit ist die globale Freigabe-Einstellung. Hier entscheidest du, wie offen dein Tenant grundsätzlich sein darf. SharePoint kennt vier Stufen: nur Personen in der Organisation, vorhandene Gäste, neue und vorhandene Gäste sowie "Jeder" (anonyme Links).

Pfad: SharePoint Admin Center > Richtlinien > Teilen (Sharing)

Stelle die Regler für SharePoint und OneDrive auf "Neue und vorhandene Gäste". Damit deaktivierst du anonyme Links, externe Nutzer müssen sich authentifizieren (per Code oder Microsoft-Konto). So erhalten nur verifizierte Personen Zugriff auf deine sensiblen Informationen. Beachte dabei: OneDrive kann nie offener sein als SharePoint Online, die SharePoint-Stufe bildet also die Obergrenze.

Warum sich durch das Admin Center klicken, wenn es mit PowerShell viel schneller geht:

Werte: Disabled (nur intern), ExistingExternalUserSharingOnly (vorhandene Gäste), ExternalUserSharingOnly (neue und vorhandene Gäste, keine anonymen Links), ExternalUserAndGuestSharing (Jeder, inklusive anonyme Links).

Unterhalb der Schieberegler findest du die weiteren Einstellungen für externes Teilen. Hier verfeinerst du die Kontrolle. Arbeitest du nur mit bestimmten Partnern zusammen, begrenzt du die Freigabe gezielt auf deren Domänen (Allow-List) oder schließt einzelne Domänen aus (Block-List). So verhinderst du, dass Dateien an beliebige externe Adressen wandern.

Außerdem solltest du den Ablauf von Gastzugriffen erzwingen. Bleiben externe Rechte unbegrenzt bestehen, sammeln sich über die Zeit verwaiste Gastzugriffe an, die niemand mehr überblickt. Mit einem Ablauf nach 30 Tagen muss der Zugriff aktiv verlängert werden, sonst erlischt er automatisch.

Per PowerShell setzt du die Domänenliste und den Gast-Ablauf so:

Optional als zusätzliche Härtung: Gäste dürfen nur mit dem eingeladenen Konto annehmen, und Externe dürfen nicht weiterteilen.

Benutzer übernehmen meist die Standardeinstellung. Also sollte diese so sicher wie möglich und nur so offen wie nötig sein.

Pfad: Abschnitt Datei- und Ordnerlinks

Wähle "Bestimmte Personen" als Standard-Linktyp. Das verhindert, dass Links versehentlich an die ganze Organisation oder nach extern weitergereicht werden. Setze die Standardberechtigung auf "Anzeigen" statt "Bearbeiten". Schreibrechte vergibst du nur dann explizit, wenn die Zusammenarbeit sie wirklich braucht. Das senkt das Risiko unautorisierter Änderungen oder Löschungen.

Den Standard-Link legst du nicht nur per Dropdown fest, sondern auch per PowerShell:

Direct entspricht dem UI-Wert "Bestimmte Personen". DefaultLinkPermission View setzt die Standardberechtigung auf Anzeigen.

Hinweis: In neueren Tenants verschiebt Microsoft die Berechtigung auf CoreDefaultShareLinkRole (Werte View, Edit, Review). Funktioniert beides, DefaultLinkPermission wird weiterhin akzeptiert.

Die Konfiguration endet nicht bei den Freigabelinks. Für einen dauerhaft sicheren Betrieb brauchst du organisatorische und übergreifende Maßnahmen. Stelle sicher, dass für alle Administratoren und idealerweise auch für Gastnutzer (über die Entra ID Einstellungen) MFA aktiv ist.

Prüfe außerdem regelmäßig die Freigabeberichte und Audit-Logs im Microsoft Purview Portal, nur so erkennst du ungewöhnliche Zugriffsmuster rechtzeitig.

MFA für Admins und Gäste steuerst du über Conditional Access in Entra ID, die Freigabeberichte und Audit-Logs liegen im Microsoft Purview Portal. Dafür gibt es kein SharePoint-Cmdlet. Das Blockieren von Apps ohne moderne Authentifizierung deckt das SharePoint-Modul dagegen mit einem einzigen Befehl ab:

Im Menüpunkt Einstellungen findest du eine Liste von Einzeloptionen. Viele stehen standardmäßig auf "Offen" oder "Automatisch". Diese Liste gehst du durch, um Wildwuchs zu vermeiden und die Sicherheit zu erhöhen.

Empfehlung: zulassen (Standard). Das erlaubt Push-Benachrichtigungen in den mobilen Apps. Aus Security-Sicht ist das positiv, weil Nutzer ungewöhnliche Aktivitäten an ihren Dateien schneller bemerken.

Die Push-Benachrichtigungen schaltest du auch ohne UI per PowerShell:

Empfehlung: Stelle den Versionsverlauf auf "Automatisch". Das ist seit August 2024 allgemein verfügbar und die von Microsoft empfohlene Vorgabe. Der Algorithmus behält die jüngsten Versionen lückenlos und dünnt ältere nach Alter aus, gedeckelt auf maximal 500 Versionen über alle Zeiträume. So bleibt der Speicherverbrauch planbar, ohne dass du eine feste Zahl festlegen musst.

Brauchst du aus Compliance-Gründen eine feste, dokumentierbare Anzahl, wählst du "Manuell" und setzt ein Limit. Der zulässige Bereich liegt zwischen 100 und 50.000 Versionen, 500 ist ein gesunder Mittelwert. Deaktiviere die Versionierung nie. Verschlüsselt Ransomware eine Datei, landet das meist als neue Version, und du stellst die saubere Vorversion wieder her.

Tenantweit stellst du das per PowerShell ein, wahlweise automatisch oder mit festem Limit:

Die Tenant-Einstellung greift nur für neu angelegte Bibliotheken. Bestehende Bibliotheken laufen weiter mit ihrem alten Wert, oft den vollen 500 Versionen ohne Ablauf. Für eine bestehende Site wendest du die Begrenzung direkt auf vorhandene Bibliotheken an und stößt die Bereinigung an:

Manuelle Bereiche: MajorVersionLimit 1 bis 50000, ExpireVersionsAfterDays 0 (nie) oder >= 30.

Empfehlung: deaktivieren. Erlaubst du Benutzern das Erstellen moderner Seiten, publizieren sie selbstständig News- oder Inhaltsseiten. In strukturierten Intranets führt das schnell zu Unübersichtlichkeit. Beschränke das Publizieren auf geschulte Redakteure.

Über PowerShell kann man nur die Seitenkommentare abschalten:

Empfehlung: zwingend auf "Manuell" stellen. Im Standard steht das auf "Automatisch", wodurch eine einzelne Site theoretisch fast den gesamten Tenant-Speicher belegen kann. Mit "Manuell" setzt du ein Standardlimit, etwa 250 GB pro Site. Wer mehr braucht, meldet sich. Das verhindert unkontrollierte Datengräber.

Nur das Limit einer Site lässt sich per PowerShell setzen (Angabe in MB, also 256000 für 250 GB):

Optional, nach Bedarf. Hier verknüpfst du deine SharePoint-Intranet-Startseite mit Viva Connections in Teams. Das ist weniger eine Sicherheits- als eine UX-Frage, um Mitarbeiter zentral zu erreichen.

Organisations-Startseite kannst du auch über PowerShell verknüpfen:

Empfehlung: deaktivieren. Das ist einer der wichtigsten Schalter gegen Wildwuchs. Dürfen Nutzer selbstständig Sites anlegen, entstehen im Hintergrund auch M365-Gruppen und Teams, und du verlierst die Kontrolle über Berechtigungen und Speicherorte. Richte stattdessen einen genehmigten Prozess ein, etwa über Microsoft Forms oder Power Automate, damit neue Arbeitsräume kontrolliert und mit den richtigen Datenschutzeinstellungen angelegt werden.

Die Websiteerstellung deaktivierst du mit einem einzigen Befehl:

Die Erstellung von Microsoft-365-Gruppen, die im Hintergrund mitlaufen, steuerst du zusätzlich in Entra ID (Group.Unified-Einstellung), nicht über das SharePoint-Modul.

Standard belassen. Das regelt nur die Verlinkung im App-Launcher und ist sicherheitstechnisch unkritisch.

Empfehlung: beim Standard von 30 Tagen bleiben. Hier legst du fest, wie lange der OneDrive-Inhalt eines gelöschten Nutzers (etwa nach einer Kündigung) noch aufbewahrt wird, bevor er endgültig vernichtet wird. Wichtig: 30 Tage sind das technische Minimum, du kannst den Wert nur nach oben anpassen (bis 3650 Tage), nicht darunter. Im Sinne der Datensparsamkeit lässt du es daher beim 30-Tage-Standard, sofern keine gesetzliche Aufbewahrungspflicht eine längere Frist verlangt. Nach Ablauf wandert der Inhalt für weitere 93 Tage in den Papierkorb der Websitesammlung, aus dem ihn nur ein Administrator wiederherstellen kann.

Die Aufbewahrungsfrist gelöschter Konten setzt du direkt per PowerShell:

Empfehlung: zulassen. Nutzer erhalten eine E-Mail, wenn viele Dateien auf einmal gelöscht werden. Das ist ein gutes Frühwarnsystem bei böswilligen Angriffen oder versehentlichen Massenlöschungen.

Die OneDrive-Benachrichtigungen aktivierst du gebündelt, inklusive Owner-Info bei anonymen Links und beim Weiterteilen:

Empfehlung: 1024 GB oder weniger, je nach Bedarf. 1 TB ist der Standard. Frag dich, ob wirklich jeder Nutzer 1 TB für persönliche Arbeitsdateien braucht. Ein kleineres Limit, etwa 100 GB oder 500 GB, verringert das Risiko, dass OneDrive als privates Backup-Archiv zweckentfremdet wird.

Das Standard-Speicherlimit pro OneDrive kannst du auch über PowerShell steuern:

Wert in MB. 1 TB = 1048576, 500 GB = 512000, 100 GB = 102400.

Empfehlung: auf Domänen beschränken. Die Synchronisation auf lokale Festplatten ist ein klassisches Einfallstor für Data Leakage. Klicke auf "Synchronisieren" und aktiviere "Synchronisierung nur auf Computern zulassen, die in bestimmte Domänen eingebunden sind", und trage die GUID deiner Domäne ein. Das funktioniert primär für klassische Active-Directory-Umgebungen. In reinen Cloud-Umgebungen (Entra ID und Intune) steuerst du das wirksamer über Conditional Access. Schließe hier zusätzlich gefährliche Dateitypen wie .exe oder .vbs von der Synchronisation aus.

Diese Beschränkung läuft nicht über das normale Tenant-Cmdlet, sondern über die Sync-Restriction. Die Domänen-GUID liest du per dsregcmd /status (AzureAdJoined) oder direkt im AD aus:

Die Domänen-GUID-Methode greift bei klassisch oder hybrid eingebundenen Geräten. In reinen Cloud-Umgebungen steuerst du den Zugriff wirksamer über Conditional Access und Intune-Compliance.

Im modernen Admin Center finden sich ganz unten oft Verweise auf die klassische Einstellungsseite. Lass dich vom alten Design nicht täuschen, hier werden fundamentale Weichen für Architektur und Sicherheit deines Tenants gestellt.

IRM verschlüsselt Dateien auf Dokumentebene, sodass sie selbst nach einem Download nur von berechtigten Personen geöffnet werden können. Wähle "Den in der Konfiguration angegebenen IRM-Dienst verwenden" (Voraussetzung: Azure Rights Management ist aktiviert). Das ist die letzte Verteidigungslinie: Fließt eine Datei doch einmal ab, etwa auf einen USB-Stick, bleibt sie ohne die passende Identität unlesbar.

IRM selbst hat keinen Set-SPOTenant-Schalter. Du aktivierst zuerst das zugrundeliegende Azure Rights Management, aktualisierst danach die IRM-Einstellungen im Admin Center und setzt die Verschlüsselung pro Bibliothek in den Bibliothekseinstellungen. Das Azure Rights Management aktivierst du über das AIPService-Modul:

Das ist die wichtigste Einstellung, um Sprawl im Keim zu ersticken. Wähle "Den Befehl Website erstellen ausblenden". Ist der Befehl sichtbar, legt jeder Nutzer auf der SharePoint-Startseite eine neue Site und damit oft eine M365-Gruppe an. Deaktiviere den Self-Service und leite Nutzer auf ein benutzerdefiniertes Formular um (Option "Verwenden Sie das Formular unter dieser URL"). Dort fragst du über ein Microsoft Form oder eine Power App Zweck, Owner und Klassifizierung ab, bevor die Site genehmigt und erstellt wird.

Den Self-Service deckt bereits SelfServiceSiteCreationDisabled aus Schritt 5 ab. Zusätzlich blockierst du die zum 2. April 2026 abgekündigten SharePoint Add-ins mit einem Befehl:

SharePoint hat sich von tief verschachtelten Strukturen hin zu einer flachen Hierarchie gewandelt. Wähle "Erstellung von Unterwebsites für alle Websites deaktivieren". Unterwebsites machen das Berechtigungsmanagement zum Albtraum und erschweren spätere Migrationen oder Archivierungen. Die moderne Alternative sind Hub-Sites, mit denen du flache Websitesammlungen logisch verknüpfst, statt sie physisch ineinander zu verschachteln.

Kein PowerShell Befehl vorhanden. Das Anlegen von Unterwebsites ist ein Site-Feature und wird über die Site-Einstellungen oder die Berechtigungsstufen gesteuert.

Um Sicherheitslücken zu schließen und die Bedienung zu vereinheitlichen, schneidest du alte Zöpfe ab. Die SharePoint-2013-Workflows sind dabei kein Thema mehr für die Zukunft, sondern bereits Vergangenheit: Microsoft hat sie zum 2. April 2026 vollständig aus den Tenants entfernt, eine Verlängerung gibt es nicht. Am selben Tag sind auch die klassischen SharePoint Add-ins ausgelaufen. Prüfe mit dem Microsoft 365 Assessment Tool, ob in deinem Tenant noch Reste laufen, und überführe verbliebene Prozesse nach Power Automate.

Stelle außerdem sicher, dass überall die neue Erfahrung (New Experience) erzwungen wird und das Erstellen klassischer Websitesammlungen blockiert ist. Einen Grund, die klassische Erfahrung freiwillig zu nutzen, gibt es nicht mehr.

Den Zugriff auf den SharePoint Store sperrst du tenantweit per PowerShell:

Zulassen, für SharePoint und OneDrive. Das entspricht den Einstellungen aus dem modernen Menü. Treten Diskrepanzen auf, gewinnt oft die restriktivere Einstellung. Das Zulassen erhöht die Transparenz für den Endanwender durch schnelle Info bei Dateiänderungen.

PowerShell Befehle sind Identisch zu Schritt 5: NotificationsInSharePointEnabled und NotificationsInOneDriveForBusinessEnabled.

Der Menüpunkt Weitere Funktionen ist die Brücke zu den klassischen Verwaltungsseiten. Auch wenn Microsoft sie nach und nach modernisiert, liegen hier noch einige der wichtigsten Hebel für Governance und Compliance.

Das ist der wohl wichtigste Bereich unter Weitere Funktionen für die tägliche Administration. Verlässt ein Mitarbeiter das Unternehmen oder fällt krankheitsbedingt aus, bestimmst du hier (Benutzerprofile verwalten) einen Administrator für dessen OneDrive. Das ist der einzige DSGVO-konforme Weg, um Daten zu sichern, ohne Passwörter zurückzusetzen oder sich als der Nutzer anzumelden. Unter Benutzerberechtigungen verwalten legst du fest, wer überhaupt einen OneDrive for Business erstellen darf. Entziehe Funktions-Accounts, Admin-Accounts oder Kiosk-Usern dieses Recht. Das minimiert die Angriffsfläche und verhindert Datenablage an falschen Orten.

Diesen Admin-Zugriff vergibst du über PowerShell, statt dich am fremden Konto anzumelden:

Wer überhaupt ein OneDrive bereitgestellt bekommt, hängt an der Lizenz und am OneDrive-Provisioning, nicht an einem einzelnen Cmdlet.

Hier steuerst du, welche Drittanbieter-Erweiterungen in deinem Tenant landen. Konfiguriere die Einstellungen so, dass Nutzer Apps aus dem SharePoint Store nicht einfach installieren, sondern beantragen müssen. Apps haben oft weitreichende Zugriffsrechte auf deine Daten. Ein Genehmigungsprozess stellt sicher, dass du Vertrauenswürdigkeit und Datenschutzkonformität prüfst, bevor eine App Daten verarbeitet.

PowerShell: DisableSharePointStoreAccess aus Schritt 6 sperrt den Store komplett. Der Genehmigungs-Workflow für einzelne App-Anfragen wird im Admin Center unter Weitere Funktionen, Apps gesteuert, dafür gibt es kein dediziertes Cmdlet.

Während die moderne Microsoft Search vieles automatisch erledigt, passt du hier das Suchschema (Managed Properties) an. Die Suche respektiert zwar Berechtigungen (Security Trimming), prüfe aber gelegentlich, ob sensible Metadaten versehentlich als durchsuchbar konfiguriert wurden, die in der Vorschau nicht auftauchen sollten.

PowerShell: Suchschema und die Managed Properties pflegst du über die Such-Verwaltungsseite im Admin Center. Es gibt kein praktikables Set-SPOTenant-Cmdlet für das Schema.

Viele Punkte hier sind Relikte aus alten SharePoint-Versionen. Die Datensatzverwaltung (Records Management) bezieht sich auf das klassische Records Center. Starte hier keine neue Archivierung. Die moderne, revisionssichere Aufbewahrung über Aufbewahrungslabels läuft heute zentral im Microsoft Purview Portal. Nutze diesen Menüpunkt nur, wenn du noch alte Archiv-Sites migrieren musst.

Bei InfoPath erübrigt sich die Frage nach dem Deaktivieren: InfoPath Forms Services in SharePoint Online wird zum 14. Juli 2026 vollständig entfernt. Das Veröffentlichen neuer oder geänderter Formulare ist bereits seit dem 18. Mai 2026 tenantübergreifend blockiert. Hast du noch InfoPath-Formulare im Einsatz, prüfst du mit dem Microsoft 365 Assessment Tool, wo sie liegen, und baust sie vor dem Stichtag in Power Apps, Power Automate oder Microsoft Forms nach. Einen automatischen Migrationspfad stellt Microsoft nicht bereit.

PowerShell: kein Cmdlet vorhanden. Records Center ist Legacy, die neue Aufbewahrung läuft über Purview.

Dieser Punkt ist für reine Cloud-Administratoren oft verwirrend, aber für klassische IT-Infrastrukturen entscheidend. Der Assistent automatisiert die Verbindung zwischen deinem lokalen SharePoint Server und SharePoint Online, etwa für eine gemeinsame Suche oder synchronisierte Profile. Arbeitet dein Unternehmen Cloud Only, ignorierst du den Punkt komplett. Betreibst du tatsächlich eine Hybrid-Umgebung, nutzt du zwingend diesen Assistenten statt manueller Eingriffe. Er richtet die komplexen Vertrauensstellungen (Server-to-Server Trust, OAuth) standardisiert und sicher ein. Manuelle Konfigurationen sind hier fehleranfällig und können ungewollte Sicherheitslücken in deine On-Premises-Umgebung reißen.

Wenn du dir das schrittweise Zusammenkopieren sparen und direkt Nägel mit Köpfen machen willst, habe ich hier die komplette Baseline am Stück für dich zusammengefasst. Dieses Skript bündelt alle Best Practices für externes Teilen, sichere Standard-Links, moderne Authentifizierung, OneDrive-Limits und Sync-Beschränkungen in einem Rutsch.

Wichtig vor dem Ausführen: Bevor du das Skript auf deinen Tenant loslässt, musst du noch kurz deine spezifischen Umgebungsvariablen anpassen. Achte besonders auf diese drei Platzhalter:

Mit dieser Vorlage hast du eine solide und gehärtete Grundkonfiguration für deine SharePoint- und OneDrive-Umgebung geschaffen. Du kannst die einzelnen Parameter natürlich jederzeit als Basis nehmen und an deine spezifischen Compliance- und Security-Vorgaben anpassen.

Technische Einstellungen sind nur die halbe Miete. Eine wirksame Compliance-Strategie stützt sich auf vier weitere Säulen. Lege in einer Datenschutzrichtlinie schriftlich fest, wie mit sensiblen Daten umzugehen ist, denn das ist die Basis für deine technische Konfiguration. Halte regelmäßige Awareness-Trainings ab, damit Mitarbeitende wissen, warum sie bestimmte Dateien nicht extern teilen dürfen.

Für Organisationen mit sehr hohen Compliance-Anforderungen (Banken, Gesundheitswesen) bietet Microsoft die Service Encryption mit Customer Key an, um die volle Kontrolle über die Verschlüsselungsschlüssel zu behalten. Führe schließlich regelmäßige Datenschutz-Folgenabschätzungen (DSFA) durch, um Risiken früh zu erkennen und deine Konfiguration anzupassen.

Sicherheit in SharePoint und OneDrive ist kein einmaliges Projekt, sondern ein fortlaufender Prozess. Neben den technischen Härtungen wie der Deaktivierung anonymer Links und der Einschränkung der Synchronisation entscheiden eine klare Strategie und die gezielte Vergabe von Rollen über das Ergebnis.