In vielen Tenants, die ich betreue, nimmt man das Risiko, dass ausscheidende Mitarbeitende Daten mitnehmen, nicht ernst genug. Das ändert sich meist erst mit dem ersten echten Vorfall. Fehlen grundlegende Schutzmechanismen oder haben die Prozesse Lücken, lassen sich Daten erstaunlich leicht abziehen. Microsoft Purview Insider Risk Management geht dieses Risiko praxisnah an, und zwar technisch wie organisatorisch, sofern man die passenden Bausteine und Richtlinien einsetzt. Ein guter Einstieg ist die vordefinierte Richtlinienvorlage „Datendiebstahl durch ausscheidende Benutzer“, die viele Unternehmen zu selten oder zu spät nutzen.

Ohne passende Lizenz und angebundene Datenquellen bleibt das Modul wirkungslos

Bevor man mit Microsoft Purview Insider Risk Management startet, sollte man Voraussetzungen und Lizenzen klären. Das vollständige Insider-Risk-Modul gibt es ab Microsoft 365 E5 oder als Add-on (E5 Compliance bzw. Insider Risk). Fehlen diese Lizenzen, lässt sich die Funktion produktiv nicht nutzen. Ich prüfe außerdem immer gleich zu Beginn, ob die wichtigsten Datenquellen angebunden sind. Für die Dateiaktivitäten sind das SharePoint, OneDrive und Microsoft Teams, für lokale und cloudbasierte Exfiltration zusätzlich die Endgeräte mit Microsoft Purview Endpoint DLP. Erst dann sieht man alle Aktivitäten, auf die es in der Austrittsphase ankommt.

HR-Konnektor und Entra ID liefern die Auslöser für Austrittsfälle

Am besten arbeitet die Vorlage „Datendiebstahl durch ausscheidende Benutzer“, wenn sie sauber an die HR-Systeme angebunden ist. Das geht direkt über den offiziellen HR-Datenkonnektor (Dokumentation) oder indirekt, indem man das Austrittsdatum regelmäßig synchronisiert. Auch das Löschen oder Deaktivieren eines Kontos in Entra ID kann als Auslöser dienen, kommt aber häufig etwas zu spät. Gerade in den letzten Tagen vor dem Ausscheiden passiert oft noch Auffälliges: Jemand lädt massenhaft Dateien aus SharePoint herunter, kopiert Ordner auf USB-Medien oder versucht, sensible Unterlagen von einem in Endpoint DLP eingebundenen Rechner in einen privaten Cloudspeicher wie Dropbox zu verschieben. Genau solche Muster kann man in der Richtlinienvorlage als Indikatoren hinterlegen und gewichten.

Vereinfacht läuft das meist so ab:

flowchart TD
    HR["HR-Datenquelle"] --> Trigger["Austritts-Trigger"]
    Entra["Entra ID (Konto gelöscht/deaktiviert)"] --> Trigger
    Trigger --> Policy["Insider Risk Policy"]
    Policy --> Indicators["Aktivitätsindikatoren"]
    Indicators --> Case["Fall erstellt"]
    Case --> Triage["Triage: HR, Legal, InfoSec"]

Abbildung: So läuft eine Austrittsrichtlinie mit HR-Daten und Entra ID typischerweise ab.

Erst mehrere Indikatoren zusammen ergeben ein belastbares Bild

Auf einen einzelnen Indikator sollte man sich in der Praxis nicht verlassen. Die Richtlinienvorlage verknüpft deshalb mehrere verdächtige Aktionen. Dazu gehören ungewöhnliche Downloads aus SharePoint oder OneDrive, das Kopieren auf USB-Sticks (mit Endpoint DLP sichtbar) und Versuche, Dateien in nicht geschäftliche Cloud-Dienste zu übertragen. Damit die lokale Komponente überhaupt etwas sieht, müssen die Geräte in Endpoint DLP eingebunden (onboarded) sein. Bei hybriden Arbeitsplätzen stelle ich regelmäßig fest, dass nicht alle Geräte durchgängig verwaltet werden, und daran scheitert dann einiges. Ist die Richtlinie gut konfiguriert, erkennt sie auch zusammenhängende Aktivitäten, etwa wenn jemand in kurzer Zeit viele sensible Dokumente verschiebt.

Praxis-Tipp: Die Schwellenwerte für ungewöhnliche Aktivitäten lassen sich in der Insider-Risk-Management-Richtlinie feiner einstellen, als viele zunächst annehmen. Testet das in der Pilotphase mit vorübergehend niedrigeren Schwellenwerten, sprecht das aber vorher mit HR und Betriebsrat ab.

Pseudonymisierung und frühe Abstimmung mit dem Betriebsrat schaffen Akzeptanz

In Deutschland hat der Datenschutz bei diesem Thema großes Gewicht. Microsoft Purview zeigt die betroffenen Benutzer in Insider-Risk-Management-Fällen standardmäßig pseudonymisiert an. Security-Analysten und Admins sehen also zunächst nur eine anonymisierte ID. Die Identität wird erst offengelegt, wenn es nötig ist und HR oder Legal beteiligt sind, was die Rechtskonformität deutlich verbessert. Die Datenschutzeinstellungen lassen sich zudem fein abstufen: Wer darf welche Fälle sehen, wann ist eine Offenlegung erlaubt, und wie werden die Audit-Logs geführt? Um eine frühe Abstimmung mit dem Betriebsrat kommt man praktisch nicht herum. In meinen letzten Projekten hing die Akzeptanz vor allem davon ab, wie offen und transparent wir vorgegangen sind. Mehr zu den Datenschutzeinstellungen und zur Zusammenarbeit mit dem Betriebsrat steht auch in der offiziellen Microsoft-Dokumentation (Insider Risk Management).

HR, Rechtsabteilung und Security bewerten jeden Fall gemeinsam

Zum Prozess gehört die Triage, also die fachliche Bewertung eines Falls. Besteht sofortiger Handlungsbedarf, handelt es sich um einen Fehlalarm, oder muss man weiter recherchieren? An dieser Stelle zeigt sich, ob Security, HR und Rechtsabteilung gut zusammenarbeiten. Im Idealfall ist der Ablauf von der ersten Meldung bis zur Eskalation klar geregelt. HR prüft beispielsweise zuerst, ob tatsächlich ein Austritt bevorsteht, und Legal klärt, ob eine Offenlegung rechtlich zulässig ist. Soll die Pseudonymisierung aufgehoben und eine Person „enttarnt“ werden, muss das sauber dokumentiert und abgestimmt sein.

Adaptive Protection und DSPM erweitern den Schutz bis in KI-Szenarien

Wer weitergehen möchte, kombiniert Insider-Risk-Richtlinien mit Purview Adaptive Protection. Steigt das Risiko, werden dann beispielsweise DLP-Richtlinien automatisch verschärft. Darüber habe ich bereits im Beitrag Adaptive Protection: Risk-driven DLP und Access in Purview geschrieben. Für KI-Modelle und Copilot ist außerdem relevant, dass Data Security Posture Management (DSPM) in Purview mittlerweile auch Datenklassifizierung und Zugriffe in KI-Szenarien absichern kann. Wie das in der Praxis aussieht, lest ihr in DSPM for AI: Copilot und KI-Modelle im Blick.

Ein Pilot mit offener Kommunikation ebnet den Weg zum Rollout

Ich betrachte Insider Risk Management nicht als reines Security-Werkzeug, sondern als Teil des Compliance- und HR-Prozesses. Wer HR, Legal und Betriebsrat früh einbindet, stößt später auf deutlich weniger Widerstand. Ich empfehle, mit einer kleinen Pilotgruppe zu beginnen und Datenschutzeinstellungen, Schwellenwerte und Eskalationswege unter realen Bedingungen zu testen. Erst danach sollte man die Richtlinie auf das ganze Unternehmen ausweiten. Auf diese Weise umgeht man die üblichen Stolpersteine, und der Schutz vor Datendiebstahl beim Austritt bringt dem Unternehmen tatsächlich etwas.