← Microsoft 365 Collaboration Administration

Überfreigabe untersuchen: Ereignispaare und ihre Grenzen

Ein internes Angebot taucht bei einem Wettbewerber auf. Wer hat es freigegeben, mit wem, wann — und wer hat darauf zugegriffen? Das Überwachungsprotokoll beantwortet die ersten drei Fragen zuverlässig; die vierte hängt davon ab, wie geteilt wurde. In diesem Modul lernst du das SharePoint-Freigabeschema kennen, das als einziges zwei Beteiligte erfasst: die handelnde Person und die Zielperson. Du lernst, warum SecureLinkCreated den Empfänger nicht nennt und erst das fast zeitgleiche AddedToSecureLink es tut, warum eine Suche nach SharingSet allein genau die externen Fälle übersieht, wie zwei Microsoft-Dokumente sich beim anonymen Link scheinbar widersprechen und was daraus tatsächlich folgt — und warum eine Verlängerung der Aufbewahrungsfrist mitten in einer Untersuchung nichts mehr rettet.

Lehrtext · 12 Abschnitte · zuletzt geprüft: 2026-09-12

Wer hat das geteilt — und mit wem?

Ein internes Dokument taucht bei einem Dritten auf. Die Fragen sind immer dieselben und immer in dieser Reihenfolge: Wer hat es freigegeben, mit wem, wann, und wer hat darauf zugegriffen? Das Überwachungsprotokoll beantwortet drei davon zuverlässig. Die vierte — wer zugegriffen hat — hängt davon ab, wie geteilt wurde.

Der Grund liegt im Aufbau der Ereignisse. Freigabeereignisse unterscheiden sich laut Dokumentation von Datei- und Ordnerereignissen in einem Punkt grundlegend: Eine Person handelt, und die Wirkung trifft eine andere. Wer eine Datei öffnet, erzeugt ein Ereignis mit genau einem Beteiligten. Wer sie teilt, erzeugt eines mit zweien — und dafür gibt es ein eigenes Schema.

LernzielDu kannst aus den Freigabeereignissen rekonstruieren, wer was mit wem geteilt hat, du kennst die Ereignispaare, bei denen die eine Hälfte den Empfänger nennt und die andere nicht, und du kannst vorher sagen, welche Fragen die Protokolle nicht beantworten werden.

Handelnde und Zielperson — Bei einem Freigabeereignis gibt es die handelnde Person, die teilt, und die Zielperson, mit der geteilt wird. Das SharePoint-Freigabeschema erfasst beide — im Unterschied zum Dateischema, in dem nur die handelnde Person vorkommt.

Zwei Felder, die die Untersuchung tragen

Das Freigabeschema ergänzt jeden Datensatz um zwei Felder. Sie sind der Grund, warum eine Freigabeuntersuchung überhaupt möglich ist — und sie sind die Felder, auf die jede Auswertung am Ende filtert.

TargetUserOrGroupType: Gibt an, ob die Zielperson oder -gruppe vom Typ Member, Guest, SharePointGroup, SecurityGroup oder Partner ist.
TargetUserOrGroupName: Enthält den Benutzerprinzipalnamen oder den Namen der Zielperson beziehungsweise -gruppe, mit der geteilt wurde.

Zusammen mit den üblichen Eigenschaften — handelnde Person, Vorgang, Zeitpunkt — ergeben diese beiden laut Dokumentation die vollständige Auskunft darüber, welcher Nutzer welche Ressource mit wem und wann geteilt hat. Das ist mehr, als die meisten Protokolle liefern, und es ist die Grundlage jeder Liste extern geteilter Inhalte.

Wo die Ressource stehtWelches Objekt betroffen ist, steht in der Spalte ObjectId — als vollständige URL bis zur Datei. Für eine Auskunft ist das die entscheidende Angabe: Sie identifiziert nicht nur die Site, sondern das konkrete Dokument.

Die Ereignisse und was sie einzeln sagen

Sechs Ereignisse tragen die Untersuchung externer Freigaben. Jedes belegt etwas anderes, und keines belegt allein den vollständigen Vorgang.

SharingInvitationCreated: Jemand versucht, eine Ressource — meist eine Site — mit einer externen Person zu teilen. Es geht eine Einladung raus. Zugriff entsteht dadurch noch nicht.
SharingInvitationAccepted: Die externe Person nimmt die Einladung an und hat ab jetzt Zugriff.
AnonymousLinkCreated: Für eine Ressource wurde ein anonymer Link — ein Anyone-Link — erzeugt.
AnonymousLinkUsed: Ein anonymer Link wurde zum Zugriff auf eine Ressource verwendet.
SecureLinkCreated: Jemand hat einen Link für bestimmte Personen erzeugt. Wer diese Personen sind, steht nicht in diesem Ereignis.
AddedToSecureLink: Eine Person wurde einem solchen Link hinzugefügt. Hier steht der Empfänger — im Feld TargetUserOrGroupName.

Die letzten beiden Zeilen sind das wichtigste Ereignispaar dieses Moduls. SecureLinkCreated sagt, dass geteilt wurde; erst AddedToSecureLink sagt, mit wem. Die Zeitstempel beider Ereignisse liegen laut Dokumentation nahezu gleich — wer nur nach dem ersten filtert, bekommt die Vorgänge ohne die Empfänger und hält das Ergebnis womöglich für vollständig.

Zwei Wege, je nach Verzeichnis

Welche Ereignisse überhaupt entstehen, hängt davon ab, ob die Zielperson bereits im Verzeichnis steht. SharePoint prüft das zuerst — und verzweigt dann.

Adresse der Zielperson wird gegen das Verzeichnis geprüft↓Steht sie dort: sofortige Berechtigung über eine SharePoint-Gruppe, Ereignis AddedToGroup, dazu SharingSet und eine Benachrichtigung↓Steht sie nicht dort: je nach Freigabeart AnonymousLinkCreated, SecureLinkCreated, AddedToSecureLink oder SharingInvitationCreated↓Bei Annahme der Einladung: SharingInvitationAccepted und Berechtigung; bei anonymem Link stattdessen AnonymousLinkUsed; bei sicherem Link ein FileAccessed beim Zugriff

Aus dieser Verzweigung folgt eine praktische Regel für die Suche: Wer nur nach SharingSet sucht — dem Ereignis mit dem freundlichen Namen für geteilte Dateien, Ordner und Sites —, findet ausschließlich die Fälle, in denen der Empfänger schon im Verzeichnis stand. Genau die interessanten Fälle, bei denen jemand nach außen geteilt hat, entstehen im anderen Zweig.

Eine Einladung ist noch kein ZugriffSharingInvitationCreated ohne zugehöriges SharingInvitationAccepted bedeutet: Es wurde eingeladen, aber nicht angenommen. Für eine Meldung über tatsächlichen Zugriff taugt das erste Ereignis allein nicht — und für eine Meldung über die Absicht ist es das einzige, was es gibt.

Zwischenstand

Kurzcheck

Eine Auswertung filtert auf SecureLinkCreated und liefert 140 Vorgänge. Die Empfängerspalte ist bei allen leer. Woran liegt das?

Der Empfänger steht im zugehörigen AddedToSecureLink-Ereignis, nicht in diesem.
Die Empfänger waren extern und werden aus Datenschutzgründen nicht protokolliert.
Die Aufbewahrungsfrist ist abgelaufen, und es sind nur noch Teildatensätze vorhanden.

Treffer. Richtig. Die Dokumentation weist ausdrücklich darauf hin, dass die Person im Ereignis AddedToSecureLink über TargetUserOrGroupName identifiziert wird; die Zeitstempel beider Ereignisse sind nahezu identisch.

Die Grenze der Zuordenbarkeit

An einer Stelle lohnt es, zwei Aussagen der Dokumentation nebeneinanderzulegen, weil sie sich auf den ersten Blick widersprechen und zusammengenommen die eigentliche Grenze beschreiben.

Die Freigabedokumentation hält fest, dass Personen, die einen Anyone-Link benutzen, sich nicht anmelden müssen und ihr Zugriff nicht überprüfbar ist.
Die Überwachungsdokumentation führt das Ereignis AnonymousLinkUsed, das protokolliert wird, wenn ein anonymer Link zum Zugriff verwendet wurde.

Beides trifft zu, und der Unterschied ist der zwischen Vorgang und Person: Dass der Link benutzt wurde, ist protokolliert. Wer ihn benutzt hat, ist es nicht — es gibt keine Anmeldung, an der eine Identität hängen könnte. Für eine Untersuchung heißt das: Die Zahl der Zugriffe ist ermittelbar, die Liste der Zugreifenden nicht.

Die Annahme, die daraus folgtDie Dokumentation zieht selbst den Schluss, den man in einer Untersuchung ziehen muss: Weil ein anonymer Link erzeugt und anschließend kopiert werden kann, ist bei jedem Dokument mit einem solchen Link vernünftigerweise anzunehmen, dass es mit einer Zielperson geteilt wurde. Das Fehlen von AnonymousLinkUsed belegt daher keine Nichtverbreitung.

Was noch da ist: die Aufbewahrungsfristen

Jede Untersuchung endet dort, wo die Datensätze enden. Die Fristen unterscheiden sich nach Lizenzstufe und nach betroffenem Dienst — und sie zu kennen, entscheidet darüber, ob eine Frage überhaupt gestellt werden kann.

Audit (Standard): Standardmäßig aktiv. Datensätze werden 180 Tage aufbewahrt — die Suche reicht damit ein halbes Jahr zurück. Ältere Datensätze können einer früheren, kürzeren Vorgabe unterliegen.
Audit (Premium): Datensätze aus Microsoft Entra, Exchange, OneDrive und SharePoint werden über eine vorgegebene Richtlinie ein Jahr aufbewahrt. Alle übrigen Aktivitäten weiterhin 180 Tage, sofern keine eigene Richtlinie greift.
Zehn Jahre: Möglich über eine zusätzliche Lizenz je Person und eine passende Aufbewahrungsrichtlinie.
Nicht-Benutzer-Vorgänge: Datensätze von Dienstprinzipalen, Systemereignissen und Anwendungsaktivitäten werden fest ein Jahr aufbewahrt. Diese Frist ist nicht konfigurierbar, und eigene Richtlinien greifen dort nicht.

Die Falle bei jeder FristverlängerungDie Lebensdauer eines Datensatzes wird laut Dokumentation bei seiner Aufnahme in die Pipeline festgelegt. Änderungen an Lizenzen oder Aufbewahrungsrichtlinien wirken auf künftige Datensätze — bereits festgeschriebene Einträge sind davon nicht betroffen. Eine Verlängerung mitten in einer Untersuchung rettet also nichts, was ohnehin schon abläuft. Dasselbe gilt für die Zehnjahresrichtlinie: Sie wirkt ausdrücklich nicht rückwirkend.

Wenn nicht die Freigabe das Thema ist

Nicht jede Untersuchung dreht sich um einen Freigabelink. Für die Fälle daneben liefert die Premium-Stufe zusätzliche Ereignisse und Eigenschaften, die der Standardstufe fehlen — und zwar nicht als Komfort, sondern als Voraussetzung dafür, den Umfang eines Vorfalls überhaupt eingrenzen zu können.

Zugriff auf Postfachelemente: Das Ereignis MailItemsAccessed mit der Eigenschaft SensitivityLabel zeigt, welche Einstufung die aufgerufenen Elemente trugen.
Teams-Nachrichtenzugriffe: Ereignisse wie MessageRead, MessagesListed oder MessageHostedContentRead mit der Eigenschaft AppAccessContext — sie unterscheidet, ob eine Anwendung im Namen eines Nutzers zugegriffen hat.
Teilnehmerangaben: MessageSent und MessageUpdated mit ParticipantInfo beziehungsweise ParticipatingDomainInformation — für die Frage, welche Organisationen an einer Unterhaltung beteiligt waren.
Besprechungsdetails: MeetingParticipantDetail mit IsJoinedFromLobby und ArtifactShared.

Dazu kommen die sogenannten intelligenten Einblicke: Sie machen laut Dokumentation unter anderem sichtbar, wonach eine Person in Exchange Online und SharePoint Online gesucht hat. Für die Frage, ob jemand gezielt nach etwas gesucht oder es zufällig gefunden hat, gibt es sonst keine Quelle.

Die Bedingung, die leicht übersehen wirdDiese Ereignisse entstehen nur, wenn den betreffenden Personen eine passende Premium-Lizenz zugewiesen ist. Die Protokollierung wird also nicht organisationsweit eingeschaltet, sondern je Person lizenziert — und wer erst im Vorfall feststellt, dass die betroffene Person keine hatte, findet die Ereignisse auch rückwirkend nicht.

Der Auswertungsweg

Die Suche selbst ist der kleinere Teil. Der Aufwand liegt darin, aus den Ergebnissen eine Liste zu machen, die jemand lesen kann.

Im Purview-Portal unter Audit die Aktivitätengruppe für Freigabe- und Zugriffsanfragen wählen und einen Zeitraum setzen.
Die Ergebnisse als CSV exportieren — vollständig, nicht nur die angezeigte Seite.
Die Spalte AuditData mit der JSON-Transformation im Power-Query-Editor in Excel in einzelne Spalten zerlegen. Ohne diesen Schritt liegen die entscheidenden Felder als ein Textblock vor.
Auf die Vorgangsarten filtern und zusätzlich auf TargetUserOrGroupType mit dem Wert Guest — das sind die Freigaben nach außen.

Für wiederkehrende Auswertungen führt der Weg über Search-UnifiedAuditLog in der Exchange-Online-PowerShell — dasselbe Werkzeug, das auch hinter dem Suchfeld des Portals steht. Für die Anbindung an ein SIEM oder für Aufbewahrung über die Standardfrist hinaus gibt es die Management-Activity-API; sie ist laut Dokumentation ausdrücklich der Weg, um Protokolldaten länger zu behalten, als die Vorgabe es vorsieht.

Was die API begrenztJede Organisation beginnt bei einer Grundlast von 2.000 Anfragen je Minute; der Wert steigt mit Platzzahl und Abonnement. Wer eine vollständige Historie abziehen will, plant das als Dauerlauf ein — nicht als einmaligen Export unter Zeitdruck.

Nach der Feststellung: die Rücknahme

Steht fest, wer was geteilt hat, folgt die Rücknahme — und sie muss an denselben Stellen ansetzen, an denen der Zugriff entstanden ist. Die Untersuchung liefert dafür die Landkarte.

Freigabe an eine Person im Verzeichnis: Sichtbar über SharingSet und AddedToGroup. Zurückzunehmen an der Gruppe oder am Objekt — dort, wo die Berechtigung eingetragen wurde.
Link für bestimmte Personen: Sichtbar über SecureLinkCreated und AddedToSecureLink. Der Link ist ein eigenes Objekt; das Entfernen der Person aus der Site beendet ihn nicht.
Anonymer Link: Sichtbar über AnonymousLinkCreated. Es gibt kein Konto, das man entfernen könnte — nur den Link selbst.
Gastkonto: Sichtbar über SharingInvitationAccepted. Das Löschen des Gastkontos beendet alle daran hängenden Zugriffe auf einmal.

Die Reihenfolge folgt der Dringlichkeit und nicht der Bequemlichkeit: Anonyme Links zuerst, weil bei ihnen weder Empfänger noch Zugreifende bekannt sind; danach die personengebundenen Freigaben, bei denen man weiß, wem man was nimmt.

Und die organisationsweite NotbremseExterne Freigabe organisationsweit abzuschalten wirkt breit und ist kein Ersatz für die gezielte Rücknahme: Der Entzug greift erst innerhalb einer Stunde, und beim Wiedereinschalten erhalten Gäste ihren Zugriff zurück. Wer bestimmte Zugriffe dauerhaft beenden will, muss sie einzeln entfernen — vor dem Wiedereinschalten.

Durchgerechnet: ein Dokument, das nicht draußen sein sollte

Von der Meldung zur belegten Liste

Szenario

Ein Angebot aus einer Projekt-Site ist bei einem Wettbewerber aufgetaucht. Bekannt sind der Dateiname und ungefähr der Zeitraum. Der Tenant hat Audit (Standard); die Datei liegt seit vierzehn Monaten in der Site.

Anforderungen

Feststellen, wer die Datei mit wem geteilt hat
Sagen können, ob und wie oft zugegriffen wurde
Die Grenzen der Aussage benennen, bevor jemand sie überinterpretiert

Schritte

Zuerst die Frist prüfen, nicht die Suche starten: Audit (Standard) reicht 180 Tage zurück. Ist die Freigabe älter, gibt es dazu keine Datensätze mehr — und das ist das Ergebnis, nicht ein Fehlschlag.
Im erreichbaren Zeitraum die Freigabe- und Zugriffsanfrage-Aktivitäten suchen und die Ergebnisse vollständig als CSV exportieren.
Die Spalte AuditData über die JSON-Transformation zerlegen — ohne diesen Schritt sind TargetUserOrGroupType und TargetUserOrGroupName nicht filterbar.
Über ObjectId auf die betroffene Datei filtern; die Spalte enthält die vollständige URL bis zum Dokument.
Die Vorgangsarten trennen: SharingSet für Empfänger aus dem Verzeichnis, SecureLinkCreated zusammen mit AddedToSecureLink für benannte Empfänger, AnonymousLinkCreated für anonyme Links.
Auf TargetUserOrGroupType mit dem Wert Guest filtern, um die Freigaben nach außen zu isolieren.
Für anonyme Links AnonymousLinkUsed auswerten — und dabei festhalten, dass daraus die Zahl der Zugriffe folgt, nicht die Liste der Zugreifenden.
Die Grenzen in den Bericht schreiben: der nicht erfasste Zeitraum vor der Frist, die fehlende Zuordenbarkeit anonymer Zugriffe, und dass ein fehlendes Nutzungsereignis keine Nichtverbreitung belegt.

Merksatz: Die Untersuchung liefert eine belegte Liste von Freigaben und eine begründete Aussage über Zugriffe — aber nur für den Zeitraum, den die Frist hergibt, und nur für die Wege, bei denen eine Identität entstanden ist. Beide Grenzen gehören in den Bericht, nicht in die Fußnote.

Der Preis und die Route

Diese Untersuchung ist möglich, weil das Freigabeschema zwei Personen erfasst statt einer — das ist mehr, als viele Systeme liefern. Der Preis ist, dass die Auswertung Handarbeit bleibt: Export, JSON-Zerlegung, Filterung über mehrere Vorgangsarten. Wer sie regelmäßig braucht, baut sie über PowerShell oder die API nach; wer sie einmal im Jahr braucht, verbringt einen Tag damit.

Der zweite Preis ist grundsätzlicher und lässt sich nicht mit Aufwand beheben. Ein Anyone-Link erzeugt keine Identität, und eine abgelaufene Frist erzeugt keine Datensätze nach. Beides sind Entscheidungen, die lange vor dem Vorfall getroffen wurden — bei der Wahl der Linktypen und bei der Wahl der Aufbewahrungsstufe. Eine Untersuchung kann sie sichtbar machen, aber nicht nachholen.

Praktisch heißt das: Die wirksamsten Maßnahmen für eine künftige Untersuchung sind keine Untersuchungsmaßnahmen. Ein voreingestellter Linktyp, der eine Identität erzeugt, macht jede spätere Frage nach dem Empfänger beantwortbar. Eine Aufbewahrungsstufe, die ein Jahr statt eines halben hält, verdoppelt das Zeitfenster, in dem überhaupt etwas zu finden ist. Beide Entscheidungen kosten wenig und fallen in ruhigen Zeiten — und beide lassen sich im Ernstfall nicht nachholen. Das ist der eigentliche Ertrag dieses Moduls: zu wissen, welche Fragen man sich heute für morgen beantwortbar macht.

Frist prüfen, bevor die Suche beginnt→Vollständig exportieren und AuditData zerlegen→Ereignispaare zusammenführen, nicht einzeln lesen→Auf Guest filtern für die Freigaben nach außen→Grenzen der Aussage in den Bericht schreiben

Ereignispaare, nicht Einzelereignisse

Das nächste Modul wendet sich dem Fall zu, in dem Inhalte planmäßig den Ort wechseln: Migration und Koexistenz — und der Frage, was dabei außer den Dateien noch mitwandern muss.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität4 Primärquellen · zuletzt geprüft: 2026-09-12