Externe Zusammenarbeit in SharePoint: Gastbenutzer, B2B-Portale und sichere Freigaben

Wie können Kunden, Lieferanten oder Projektpartner auf SharePoint-Inhalte zugreifen, ohne interne Bereiche offenzulegen? Externe Zusammenarbeit in SharePoint ist für wiederkehrende Szenarien meist über eine eigenständige, klar abgegrenzte Site mit Microsoft-Entra-B2B-Gastkonten besser kontrollierbar als über viele einzelne Dateifreigaben. Tenant- und Site-Freigabeeinstellungen begrenzen, welche Freigabearten überhaupt möglich sind. Gruppenbasierte Berechtigungen, zeitlich begrenzte Zugriffe, Access Reviews und Audit-Protokolle ergänzen das technische Modell.

SharePoint externe Zusammenarbeit ist jedoch kein öffentlicher Webauftritt. Ein B2B-Portal richtet sich an bekannte externe Identitäten, die sich authentifizieren und nur definierte Inhalte sehen. Anonyme Jeder-Links können in geeigneten Einzelfällen praktisch sein, bieten aber weniger Identitätsbezug und sollten nicht mit einem kontrollierten Gastzugang verwechselt werden.

Wann externe Zusammenarbeit in SharePoint sinnvoll ist

SharePoint eignet sich, wenn interne und externe Beteiligte Dokumente, Listen oder Projektinformationen gemeinsam bearbeiten sollen und die Organisation bereits Microsoft 365 betreibt. Typische Szenarien sind:

  • Projektunterlagen mit einem Umsetzungspartner,
  • Lieferantendokumente und Freigaben,
  • Kundenübergaben,
  • Ausschreibungsunterlagen,
  • gemeinsame Qualitäts- oder Wartungsdokumentation,
  • zeitlich begrenzte Arbeitsräume für Berater.

Ungeeignet ist SharePoint als Ersatz für einen anonym erreichbaren Kundenbereich mit hoher öffentlicher Last, komplexem Self-Service, Bezahlfunktionen oder frei registrierbaren Konten. Dafür sind spezialisierte Portal- oder Webanwendungen meist geeigneter.

Drei Freigabemuster unterscheiden

Muster: B2B-Gast in Site/Gruppe

Identität: authentifizierter externer Benutzer

Typischer Einsatz: laufende Zusammenarbeit

Kontrollniveau: hoch, wenn sauber verwaltet

Muster: Link für bestimmte Personen

Identität: authentifizierte benannte Empfänger

Typischer Einsatz: einzelne Datei oder Ordner

Kontrollniveau: mittel bis hoch

Muster: Jeder-Link

Identität: kein dauerhaftes Gastkonto erforderlich

Typischer Einsatz: bewusst anonyme Weitergabe

Kontrollniveau: geringer Identitätsnachweis

Die verfügbaren Optionen hängen von den Einstellungen auf Organisations- und Site-Ebene ab. Eine Site kann nicht offener teilen als der Tenant erlaubt.

Architektur eines B2B-Portals

Externe Inhalte in eigener Site trennen

Ein externer Arbeitsraum sollte nicht einfach eine Unterstruktur einer internen Team-Site sein. Eine eigenständige Site schafft eine klare Sicherheitsgrenze, eigene Owner, eigene Freigabeeinstellungen und einen separaten Lebenszyklus.

Empfehlenswerte Trennung:

  • interne Arbeits-Site für Entwürfe, Kalkulationen und interne Kommentare,
  • externe Projekt-Site für freigegebene gemeinsame Inhalte,
  • kontrollierter Übergabeprozess zwischen beiden Bereichen.

So müssen interne Dokumente nicht über komplizierte Ordnerberechtigungen versteckt werden. Die Trennung reduziert auch das Risiko, dass ein neuer interner Inhalt versehentlich in einem bereits extern freigegebenen Ordner landet.

Portalstruktur klein halten

Eine typische externe Site benötigt nur wenige Bausteine:

  • Startseite mit Zweck, Ansprechpartnern und Nutzungsregeln,
  • Dokumentbibliothek für gemeinsame Dateien,
  • optional separate Bibliotheken für unterschiedliche Vertraulichkeitsstufen,
  • Liste für Aufgaben, Fragen oder Übergaben,
  • Seite mit Zugriffs- und Supporthinweisen.

Zu viele Bibliotheken und verschachtelte Ordner erschweren externen Nutzern die Orientierung und erhöhen den Berechtigungsaufwand.

Gastbenutzer in Entra ID: Einladung und Authentifizierung

Microsoft Entra External ID beziehungsweise B2B Collaboration ermöglicht, externe Personen als Gastobjekte im eigenen Verzeichnis zu führen. Der Gast authentifiziert sich mit einer unterstützten Identität oder – abhängig von der Konfiguration – einem Einmalcode. Das eigene Unternehmen verwaltet, auf welche Ressourcen dieses Gastobjekt zugreifen darf.

Einladungsvorgang

  1. Ein berechtigter interner Benutzer oder Administrator lädt die externe Adresse ein.
  2. Entra legt ein Gastobjekt an beziehungsweise bereitet die Einlösung vor.
  3. Der Empfänger öffnet die Einladung und authentifiziert sich.
  4. Nach erfolgreicher Einlösung gelten die zugewiesenen Gruppen- und Site-Berechtigungen.
  5. Sign-in- und Audit-Ereignisse können für Kontrollen ausgewertet werden.

Die konkrete Benutzererfahrung hängt unter anderem von Heimmandant, Identitätsanbieter, Cross-Tenant-Einstellungen, Conditional Access und Einladungsstatus ab.

Ein Gastkonto ist keine automatische Berechtigung

Ein Gastobjekt im Verzeichnis gewährt noch keinen Zugriff auf SharePoint. Erst die Mitgliedschaft in einer Gruppe oder eine direkte Freigabe verleiht Rechte. Umgekehrt kann ein Gastobjekt nach Projektende im Verzeichnis verbleiben, obwohl die Site-Berechtigung entfernt wurde. Deshalb müssen Ressourcenberechtigung und Identitätslebenszyklus gemeinsam kontrolliert werden.

Lizenzfragen vorab prüfen

Externe Identitäten und Microsoft-365-Dienste unterliegen produktspezifischen Lizenz- und Abrechnungsregeln, die sich ändern können. Zusätzlich können Funktionen wie Conditional Access, Identity Governance oder Access Reviews bestimmte Entra-Lizenzen erfordern. Die aktuelle Microsoft-Produktdokumentation und der konkrete Vertrag sind vor der Einführung maßgeblich.

Freigabeebenen: Site, Bibliothek, Ordner oder Datei

Site-Freigabe

Geeignet für Personen, die regelmäßig im gesamten externen Arbeitsraum mitarbeiten. Berechtigungen sollten über eine klar benannte Gruppe erfolgen, zum Beispiel Projekt Alpha – Externe Mitglieder.

Vorteil: verständliche Mitgliedschaft und einfacher Entzug.

Risiko: Neue Inhalte der Site sind für diese Gruppe sichtbar, sofern keine getrennten Bereiche bestehen.

Bibliotheksfreigabe

Geeignet, wenn externe Nutzer nur einen definierten Dokumentbereich benötigen. Die Bibliothek erhält einen eigenen Berechtigungsbereich.

Vorteil: klare inhaltliche Grenze.

Risiko: Mehrere abweichend berechtigte Bibliotheken erhöhen Verwaltungsaufwand.

Ordnerfreigabe

Kann für begrenzte Übergaben praktisch sein, sollte aber nicht zur Standardarchitektur werden. Viele einzeln freigegebene Ordner erzeugen schwer prüfbare Berechtigungsinseln.

Dateifreigabe

Geeignet für eine einzelne, klar benannte Datei. Für dauerhafte Zusammenarbeit ist sie unübersichtlich, weil sich Zugriffe über viele Dokumente verteilen.

Grundsatz der geringsten Rechte

Externe erhalten nur die Rechte, die für ihre Aufgabe nötig sind. In vielen Fällen reicht Lesen oder Bearbeiten ohne Löschen und ohne Freigaberecht. Prüfen Sie, ob Mitglieder andere Personen einladen dürfen und ob Site Owner Freigaben kontrollieren müssen.

Berechtigungen für externe Nutzer sauber modellieren

Gruppen statt Direktzugriff

Nutzen Sie pro Rolle Gruppen, beispielsweise:

  • Externe Leser,
  • Externe Bearbeiter,
  • Interne Projektmitglieder,
  • Portal-Owner.

Das vereinfacht Onboarding, Offboarding und Access Reviews. Direkte Berechtigungen sind nur für begründete Ausnahmen geeignet.

Interne und externe Gruppen nicht vermischen

Eine gemeinsame Gruppe kann technisch funktionieren, erschwert aber die Kontrolle. Separate Gruppen machen sichtbar, wie viele Gäste beteiligt sind und welche Rechte sie besitzen. Sie ermöglichen zudem strengere Richtlinien oder kürzere Prüfintervalle für Externe.

Keine vertraulichen Inhalte auf derselben Berechtigungsebene

Wenn eine Bibliothek externe Bearbeiter enthält, dürfen dort keine internen Unterlagen liegen, die lediglich durch Navigation „versteckt“ werden. Sicherheit beruht auf Berechtigungen, nicht auf unsichtbaren Links.

Hub-Zuordnung bewusst prüfen

Ein externes Portal kann technisch mit einer Hub-Architektur verbunden werden, sollte aber nicht automatisch in unternehmensweite Navigation und Inhaltsaggregation aufgenommen werden. SharePoint Hub Sites: Intranet-Navigation, Site-Hierarchie und Berechtigungskonzept erläutert, warum Hub-Zuordnung und Berechtigung getrennte Konzepte sind.

Datenschutz und Protokollierung

Die DSGVO verlangt unter anderem Zweckbindung, Datenminimierung, angemessene Sicherheit und eine begrenzte Speicherung personenbezogener Daten. Für ein externes SharePoint-Portal bedeutet das technisch und organisatorisch:

  • Zweck und zulässige Inhalte dokumentieren,
  • nur notwendige Gastdaten und Protokolle verarbeiten,
  • Auftragsverarbeitung und internationale Datenübermittlungen rechtlich prüfen,
  • Zugriffe rollenbasiert beschränken,
  • Aufbewahrungs- und Löschregeln definieren,
  • Betroffenen- und Auskunftsprozesse berücksichtigen,
  • Sicherheitsvorfälle erkennen und bearbeiten.

Dieser Artikel ersetzt keine Rechtsberatung. Die konkrete Rechtsgrundlage, Informationspflichten und Aufbewahrungsdauer müssen für Organisation, Land und Szenario geprüft werden.

Audit- und Anmeldeprotokolle

Microsoft Purview Audit und Entra-Sign-in-Protokolle können Aktivitäten wie Freigaben, Dateioperationen und Anmeldungen dokumentieren. Welche Ereignisse wie lange verfügbar sind, hängt von Lizenz, Audit-Konfiguration und Datenquelle ab. Prüfen Sie vorab:

  • welche Ereignisse für den Nachweis benötigt werden,
  • wer Protokolle einsehen darf,
  • wie lange sie aufbewahrt werden,
  • wie Exporte geschützt werden,
  • wie schnell ein Ereignis nach einer Aktion suchbar ist.

Ein Audit-Protokoll verhindert keinen unzulässigen Zugriff; es unterstützt Erkennung und Untersuchung.

Zugänge zeitlich begrenzen und regelmäßig prüfen

Ablaufdatum

Für Projekte mit Enddatum sollte ein Zugriff nicht unbegrenzt bestehen. Mögliche Mechanismen sind:

  • Ablaufdatum im Gast- oder Projektregister,
  • geplanter Power-Automate-Reminder an Owner,
  • Entra Access Reviews,
  • automatisierte Gruppenabläufe,
  • periodische manuelle Bestätigung.

Automatisches Entfernen sollte einen dokumentierten Ausnahmeprozess haben, damit laufende Vertrags- oder Supportfälle nicht versehentlich unterbrochen werden.

Access Reviews

Entra Identity Governance kann Access Reviews für Gruppen, Anwendungen und Gäste bereitstellen. Reviewer bestätigen, entfernen oder begründen Zugriffe. Verfügbarkeit und Automatisierungsumfang hängen von den eingesetzten Lizenzen ab.

Projektende

Ein kontrollierter Abschluss umfasst:

  1. letzte Übergabe und offene Aufgaben prüfen,
  2. externe Bearbeitungsrechte beenden,
  3. erforderliche Inhalte archivieren oder in internes System überführen,
  4. Freigabelinks widerrufen,
  5. Gruppenmitgliedschaften entfernen,
  6. Gastobjekte nach organisationsweiter Prüfung löschen oder sperren,
  7. Aufbewahrungsregeln anwenden,
  8. Abschluss dokumentieren.

Typische Risiken, Tests und Rückfallwege

Zu breite Tenant- oder Site-Freigabe

Symptom: Nutzer können anonyme Links oder neue Gäste erstellen, obwohl nur benannte Partner vorgesehen sind.

Test: Mit einem normalen Mitglied verschiedene Freigabearten ausprobieren; Admin-Einstellungen auf Tenant- und Site-Ebene vergleichen.

Rückfall: Site-Freigabestufe einschränken, vorhandene Links inventarisieren und unzulässige Links widerrufen.

Vergessene Gastzugänge

Symptom: Ehemalige Projektpartner bleiben in Gruppen oder im Verzeichnis.

Test: Gruppen und Gäste nach letzter Aktivität, Projekt und Owner auswerten.

Rückfall: Zugriff zunächst sperren, fachliche Bestätigung einholen und danach Gruppenmitgliedschaft beziehungsweise Gastobjekt kontrolliert entfernen.

Externer sieht mehr als erwartet

Ursachen: Mitgliedschaft in mehreren Gruppen, direkte Freigabe, vererbte Rechte oder falsch abgegrenzte Bibliothek.

Test: Zugriffsüberprüfung mit dem konkreten Gast und Suchtests durchführen.

Rückfall: Rechte auf die definierte Gruppe zurückführen; betroffene Inhalte und Audit-Ereignisse prüfen; Sicherheitsprozess auslösen, falls ein tatsächlicher Datenzugriff möglich war.

Einladung lässt sich nicht einlösen

Ursachen: falsches Konto, Cross-Tenant-Beschränkung, Conditional Access, bereits bestehendes Gastobjekt oder blockierter Identitätsanbieter.

Test: Einladungsstatus, Anmeldeprotokoll und verwendete Identität prüfen.

Rückfall: Gastobjekt nicht blind mehrfach anlegen. Bestehende Identität bereinigen oder Einladung kontrolliert erneut senden.

Datei ist nach Entzug weiterhin lokal vorhanden

SharePoint kann den künftigen Cloud-Zugriff entziehen, aber bereits heruntergeladene Kopien nicht automatisch zurückholen. Sensitivity Labels, Nutzungsbedingungen und organisatorische Vorgaben können das Risiko reduzieren. Für besonders schützenswerte Daten muss geprüft werden, ob Download überhaupt erlaubt sein soll.

Abnahmetest für eine externe SharePoint-Site

  • Gast kann Einladung mit vorgesehener Identität einlösen.
  • Gast sieht nur die vorgesehene Site oder Bibliothek.
  • Interne Entwürfe sind weder über Navigation noch Suche erreichbar.
  • Gast kann nur erlaubte Aktionen ausführen.
  • Gast kann keine weiteren Personen einladen, sofern nicht vorgesehen.
  • Anonyme Links sind blockiert oder ausdrücklich begründet.
  • Ablauf- und Access-Review-Prozess funktioniert.
  • Audit- und Sign-in-Ereignisse sind für berechtigte Prüfer auffindbar.
  • Offboarding entfernt Gruppen-, Site- und Linkzugriffe.
  • Rückfall bei gesperrter Identität und abgelaufener Einladung wurde getestet.

Ein separates Daten- und Site-Modell für Projektunterlagen wird im Beitrag Zentrale Projektablage in SharePoint statt Papierplänen vertieft.

So bleibt externer Zugriff auf SharePoint sicher, nachvollziehbar und wartbar

Sichere externe Zusammenarbeit beginnt mit einer separaten Site und bekannten B2B-Identitäten, nicht mit verstreuten Einzelfreigaben. Gruppenbasierte Rollen, restriktive Freigabeeinstellungen, Ablaufdaten, Access Reviews und getestete Offboarding-Schritte halten den Zugriff beherrschbar. Audit und Sign-in-Protokolle ergänzen den Nachweis, ersetzen aber weder das Prinzip der geringsten Rechte noch eine klare fachliche Verantwortung.

Wenn externe Zugänge in SharePoint sicher und nachvollziehbar sein sollen
Dann hilft ein Blick auf Gastkonten, Berechtigungsebenen und Protokollierungskonzept. Externe Freigaben einordnen

Categories: , , , ,