Microsoft Purview DLP | Teams, SharePoint & OneDrive ohne E5-Lizenz absichern

Du hast deine Mail DLP-Strategie im letzten Guide „Exchange Online: Blockieren, Verschlüsseln & Genehmigen“ definiert und das Grundfundament deiner Regelwerke steht. Jetzt richten wir den Fokus auf die zentralen Datenspeicher in modernen Arbeitsumgebungen: Microsoft SharePoint Online und OneDrive for Business.

Warum dieser Fokus auf den Speicher-Backend? Weil diese beiden Dienste das technische Rückgrat für fast die gesamte Kollaboration in Microsoft 365 bilden! Auch Microsoft Teams setzt technisch darauf.

Teams ist für Dateien oft nur die Benutzeroberfläche. Physisch landen Dokumente aus Kanälen in SharePoint und Dateien aus privaten Chats in OneDrive. Indem wir uns in diesem Artikel darauf konzentrieren, robuste DLP-Regeln für SharePoint und OneDrive zu bauen, schlagen wir zwei Fliegen mit einer Klappe: Wir sichern die klassische Dateiablage und schützen gleichzeitig jeden Dokumenten-Upload in Teams.

Wie genau du diese Architektur nutzt und wie du Regeln baust, die im Hintergrund für Sicherheit sorgen, schauen wir uns jetzt an.

• Voraussetzungen:
  • Lizenz: mindestens Microsoft 365 Business Premium
  • Rolle: Compliance Administrator oder Global Admin

Architektur: Dateien vs. Chat

Bevor du den ersten Haken setzt, musst du verstehen, wo die Daten physisch liegen. Microsoft Teams ist technisch gesehen nur ein „Aggregator“, der verschiedene Dienste in einer UI bündelt. Für deine DLP-Strategie mit einer Business Premium Lizenz ist diese Unterscheidung kriegsentscheidend:

• Dateien (Files): Jede Datei, die in einem Teams-Kanal gepostet wird, landet in einer SharePoint Online Document Library. Jede Datei im privaten 1:1-Chat landet im OneDrive for Business des Absenders. Da Business Premium volle DLP-Unterstützung für SharePoint und OneDrive bietet, kannst du Dateien in Teams exzellent schützen.
  
• Nachrichten (Messages): Der geschriebene Text im Chat (z.B. „Hier ist die Kreditkartennummer: 1234…“) wird im Cosmos DB Backend von Teams verarbeitet. Echte Teams Chat DLP (das Blockieren von Textnachrichten) ist oft ein Feature der E5-Compliance oder spezifischer Add-ons.

Tipp: Wenn du im Purview Portal Regeln baust, wähle als Speicherort SharePoint-Websites (für Teams Kanäle) und OneDrive-Konten (für Private Chats). Lasse den expliziten Haken bei „Teams-Chat- und Kanalnachrichten“ weg, sofern du keine E5-Lizenz hast, da die Policy sonst oft gar nicht speichert oder Fehler wirft. Wir schützen Teams hier „indirekt“ über den Speicher-Layer!

Latenz & User Experience

Anders als eine Firewall, die Pakete in Echtzeit verwirft, arbeitet DLP in SharePoint/OneDrive (und damit in Teams) asynchron. Wenn ein Nutzer eine sensible Datei in einen Teams-Kanal hochlädt, passiert Folgendes:

1. Der Upload wird zunächst zugelassen. Die Datei ist für Sekundenbruchteile sichtbar.
2. Der SharePoint-Indexer greift die Datei, extrahiert den Text und gleicht ihn mit deinen Sensitive Information Types ab.
3. Wird ein Treffer (Match) gefunden, ändert sich der Status der Datei nachträglich.
4. In Teams erscheint statt der Datei ein rotes Blockiersymbol und der Zugriff wird für alle (außer dem Besitzer) entzogen.

Erwarte also keine synchrone Blockade beim Upload-Dialog („Access Denied“), sondern eine nachträgliche Quarantäne („Item was blocked“). Das ist wichtig für deine Kommunikation an die Endanwender: Sie werden die Datei kurz sehen, bevor sie „verschwindet“ oder markiert wird. Je nach Systemlast bei Microsoft kann dieser Scan zwischen wenigen Sekunden und einigen Minuten dauern.

DLP-Regeln Schritt für Schritt

Szenario 1: Der Klassiker – Blockierung von Finanzdaten in Dateien

Das häufigste Sicherheitsrisiko in Teams ist nicht der böswillige Hacker, sondern der gestresste Buchhalter, der „mal eben“ eine Excel-Liste mit IBANs oder Kreditkartendaten in den falschen Projektkanal zieht. Da wir uns in der Business-Premium-Welt bewegen, greifen wir hier nicht in den Chat-Strom ein, sondern fangen die Datei dort ab, wo sie landet: Im SharePoint-Backend.

Das technische Fundament (SITs): Microsoft liefert für dieses Szenario extrem robuste Mustererkennungen, sogenannte Sensitive Information Types (SIT). Du musst keine RegEx-Ausdrücke basteln. Wir nutzen die vordefinierten Typen Credit Card Number und EU Debit Card Number. Diese prüfen nicht nur auf das Format, sondern validieren auch die Prüfsumme (Luhn-Algorithmus), was False-Positives drastisch reduziert.

1. Richtlinie erstellen: Starte im Purview Compliance Portal unter Data Loss Prevention > Richtlinien. Wähle nicht „Benutzerdefiniert“, sondern die Kategorie „Finanzwesen“. Das spart dir Zeit, da Microsoft hier bereits relevante SITs bündelt.

2. Speicherorte (Der entscheidende Schritt): Hier trennt sich die Spreu vom Weizen.
   • Aktiviere SharePoint-Websites (schützt Dateien in Teams-Kanälen).
   • Aktiviere OneDrive-Konten (schützt Dateien in privaten 1:1- und Gruppenchats).
     
   • Tipp: Wähle ‚Alle Websites‘, um sicherzustellen, dass auch die separaten Site Collections von Privaten und Geteilten Kanälen abgedeckt sind.
     
   • WICHTIG: Deaktiviere „Teams-Chat- und Kanalnachrichten“. Dieser Haken prüft den geschriebenen Text im Chatfenster, das erfordert E5-Lizenzen oder spezielle Add-ons. Lässt du ihn aktiv, wirst du Warnmeldungen erhalten und die Policy lässt sich nicht speichern. Wir schützen die Datei, nicht das Wort.

3. Regel-Feinjustierung: Im Standard blockiert die Vorlage erst ab 10 Instanzen (z.B. 10 Kreditkartennummern in einer Datei). Für echte Compliance setze diesen Wert auf 1. Eine einzige Kreditkartennummer in einem öffentlichen Kanal ist bereits ein Verstoß.
   
   • Erweitere den Schutz auf IBANs (mit Vorsicht!) Kreditkarten sind wichtig, aber in Europa ist die IBAN das häufigste Ziel für Datendiebstahl. Füge daher den „Typen vertraulicher Informationen“ International Banking Account Number (IBAN) zu deiner Regel hinzu.
     
   • ⚠️ Die „Briefpapier-Falle“ (WICHTIG): Hier musst du als Architekt aufpassen: Deine eigene Firmen-IBAN steht vermutlich auf jedem offiziellen Briefbogen, in jeder Rechnungs-Fußzeile und in vielen Signaturen. Wenn du die Regel so einstellst, dass sie schon bei einer (1) gefundenen IBAN blockiert, wirst du den Versand von legitimen Angeboten und Rechnungen unmöglich machen.
     
   • Arbeite mit Schwellenwerten (Instance Counts). und stelle die Anzahl der Instanzen auf min. 10.
     • Warum? Damit ignorierst du das einzelne Vorkommen in der Fußzeile eines Dokuments.
     • Was fängst du damit ab? Du blockierst das wirkliche Risiko: Den Export von Kundenlisten (Excel-Tabellen mit vielen IBANs) oder Gehaltslisten. Wir wollen den Massenabfluss verhindern, nicht den einzelnen Geschäftsbrief.

4. Schutzmaßnahmen konfigurieren: Im Schritt „Schutzmaßnahmen“ definierst du die Reaktion des Systems. Hier verknüpfen wir die Technik mit der Nutzerpsychologie. Gehe die Haken von oben nach unten durch:
   • Richtlinientipps & Benachrichtigungen: Setze den ersten Haken bei „Wenn Inhalt… übereinstimmt, den Benutzern Richtlinientipps anzeigen…“. Das ist essenziell für den Lerneffekt (siehe Szenario 3).
     
   • Mengen-Schwellenwert (Die „Briefpapier-Falle“): Aktiviere den Haken bei „Erkennen, wenn eine bestimmte Menge… geteilt wird“. Im Screenshot siehst du den Standardwert 10.
     
   • Tipp: Wenn du IBANs scannst, lass diesen Wert auf 10 (oder mindestens 5) stehen!
     • Der Grund: Deine eigene Firmen-IBAN steht vermutlich auf jedem Briefbogen und in jeder Rechnungs-Fußzeile. Würdest du hier „1“ eintragen, würde SharePoint jedes einzelne legitime Angebot blockieren, nur weil deine Fußzeile erkannt wird. Durch den Schwellenwert „10“ ignorierst du das Briefpapier, blockierst aber zuverlässig die Excel-Liste mit den Kundendaten.
     • (Nur wenn du ausschließlich Kreditkarten scannst, kannst du diesen Wert auf 1 senken, da Kreditkartennummern nichts in Fußzeilen zu suchen haben.)
       
   • Incident Reports: Die Haken für „Schadensberichte“ und „Benachrichtigungen“ sorgen dafür, dass du als Admin informiert wirst. Am Anfang wichtig, später oft „Noise“ – entscheide nach Bedarf.
     
   • Der „Kill Switch“ (WICHTIG): Ganz unten findest du den Punkt „Zugriff einschränken oder den Inhalt… verschlüsseln“. Dieser Haken ist im Standard oft leer (siehe Screenshot). Du musst ihn aktiv setzen, damit die Datei tatsächlich blockiert wird. Ohne diesen Haken ist die Regel nur ein „stiller Alarm“ ohne Schutzwirkung. Wähle im Untermenü dann „Blockieren“.

5. Zugriff anpassen (Wer wird blockiert?): Im nächsten Schritt „Zugriff anpassen und Einstellungen überschreiben“ definierst du die Härte der Blockade. Standardmäßig ist hier oft „Alle blockieren“ vorausgewählt. Das ist für interne Dokumente meist zu strikt.
   • Die Blockade-Logik: Aktiviere den Haken bei „Zugriff einschränken oder den Inhalt… verschlüsseln“.
     
   • Die Zielgruppe: Wähle hier „Nur Personen außerhalb Ihrer Organisation blockieren“.
     • Das Szenario: Ein Mitarbeiter lädt eine Excel-Liste mit IBANs in einen Teams-Kanal, in dem auch externe Gäste sind.
     • Der Effekt: Deine internen Kollegen können weiterhin arbeiten. Der externe Gast jedoch verliert den Zugriff. Das ist der Sweetspot zwischen Sicherheit und Produktivität.
       
   • Der Notausgang (User Override): Nichts frustriert mehr als eine fehlerhafte Blockade ohne Lösungsweg. Im gleichen Fenster unten findest du die Option „Personen, die den Tipp lesen, das Überschreiben der Richtlinie erlauben“.
     • Best Practice: Setze diesen Haken!
     • Zwang zur Begründung: Aktiviere unbedingt die Unteroption „Für die Außerkraftsetzung eine geschäftliche Begründung vorschreiben“.
       
     • Psychologischer Effekt: Der Nutzer kann die Datei zwar senden, muss aber aktiv auswählen, warum er das tut (z.B. „Geschäftlicher Bedarf“). Da er weiß, dass dies protokolliert wird, sinkt die Missbrauchsrate drastisch. Gleichzeitig entlastest du den IT-Support, da User legitime Ausnahmen selbst lösen können.

Der User-Effekt (Architect’s View): Sobald die Policy aktiv ist (Replikationszeit: ca. 1-24 Stunden), passiert Folgendes: Ein User lädt Kunden_CC_Liste.xlsx in einen Kanal hoch. Der Upload gelingt zunächst. Kurz darauf scannt der SharePoint-Crawler den Inhalt, erkennt die Muster und „sperrt“ das File. Im Teams-Kanal ändert sich das Excel-Icon zu einem Warnsymbol und beim Klick darauf erhält der User die Meldung: „Dieses Element wurde aufgrund von Richtlinienkonflikten blockiert.“

Szenario 2: Externe Kollaboration absichern (Guest Access)

Das „Guest Access“-Feature in Teams ist Segen und Fluch zugleich. Du willst, dass externe Berater oder Partner nahtlos in Projekten mitarbeiten, aber du verlierst oft die Kontrolle darüber, wer in welchem Kanal mitliest. Das Risiko ist hier meist nicht böser Wille, sondern Unachtsamkeit: Ein interner Mitarbeiter lädt das Dokument „Interne_Kalkulation_Q4.xlsx“ in den Kanal „Projekt X“, vergisst aber, dass dort auch zwei externe Freelancer Zugriff haben.

Anstatt Gastzugriffe pauschal zu verbieten (was zur Nutzung von Schatten-IT führt), konfigurieren wir eine DLP-Regel, die als selektiver Filter wirkt. Sie erlaubt Smalltalk und unkritische Dateien, blockiert aber strikt, sobald interne Klassifizierungen erkannt werden.

Wir bauen eine UND-Verknüpfung. Die Regel greift nur, wenn zwei Faktoren gleichzeitig wahr sind:

1. Inhalt: Die Datei enthält sensible Daten (z. B. Keyword „Intern“, „Vertraulich“ oder ein spezifisches Sensitivity Label).
2. Kontext: Das Dokument wird mit jemandem geteilt, der nicht Teil deines Entra ID (Azure AD) Tenants ist.

Die Konfiguration im erweiterten Editor:

1. Erstelle eine neue „Benutzerdefinierte Richtlinie“ für SharePoint und OneDrive.

2. Bedingung 1 (Der Auslöser): Wähle unter Inhalt enthält entweder „Typen vertraulicher Informationen“ (für Keywords/Muster) oder „Vertraulichkeitsbezeichnung“ (Sensitivity Label), sofern du diese in deiner Business Premium Umgebung ausgerollt hast (z.B. Label: Internal Only).
   
3. Bedingung 2 (Der Empfänger): Füge die Bedingung „Inhalt wird freigegeben über Microsoft 365“ hinzu. Im Dropdown-Menü wählst du die Option „mit Personen außerhalb meiner Organisation“.
   • Hinweis: Dies umfasst sowohl externe E-Mail-Empfänger (via SharePoint-Link) als auch Gast-Konten in Teams-Kanälen.

Aktion & Auswirkung: Setze die Aktion auf „Zugriff auf den Inhalt blockieren“. Wichtig: Konfiguriere die Einschränkung im Untermenü auf „Nur Personen außerhalb meiner Organisation blockieren“.

Das Ergebnis im Arbeitsalltag: Der interne Mitarbeiter lädt das vertrauliche Dokument in den gemischten Teams-Kanal.

• Für Kollegen: Die Datei ist ganz normal sichtbar und bearbeitbar.
• Für den Gast: Er sieht den Dateinamen, aber beim Versuch, die Datei zu öffnen, greift SharePoint ein und verweigert den Zugriff. Im Teams-Feed des Gastes erscheint oft gar kein Hinweis, oder der Link läuft ins Leere, je nach Client-Version. Die Daten bleiben also im Haus, obwohl sie im „falschen“ Kanal liegen.

Mehr zu „Sensitivity Labels“ / „Vertraulichkeitsbezeichnungen“ findest du in den Artikeln:

• Purview | Sensitivity Labels: Architektur & Praxis-Guide
• Purview | Automatisierte Anwendung von Sensitivity Labels

Szenario 3: Policy Tips – Den Anwender erziehen statt bestrafen

Nichts erzeugt mehr Tickets beim Helpdesk als eine „Silent Block“-Strategie. Wenn ein Benutzer eine Datei hochlädt und diese kommentarlos verschwindet oder sich nicht öffnen lässt, geht er von einem technischen Fehler aus. Er versucht es erneut, scheitert wieder und ruft genervt den Support an.

Mit Policy Tips (Richtlinientipps) änderst du die Dynamik: Du machst die Compliance-Regel transparent. Der Nutzer lernt im Moment des Fehlers („Learning on the Job“), warum seine Handlung unsicher war. Das reduziert nicht nur False-Positives, sondern schult die Belegschaft langfristig besser als jedes jährliche Compliance-Video.

Die technische Umsetzung: In den DLP-Regeln für SharePoint und OneDrive (unser Backend für Teams) aktivieren wir die Benutzerbenachrichtigung. Da wir uns hier im Datei-Kontext bewegen, funktioniert der Tipp etwas anders als in Outlook: Er erscheint nicht während des Tippens, sondern als visueller Indikator an der Datei.

Um Tipps zu erhalten und die Standard-Meldungen durch hilfreiche Texte zu ersetzen, musst du tief in die bestehende Regel eintauchen.

1. Richtlinie öffnen: Wähle in der Übersicht (Data Loss Prevention > Richtlinien) deine gewünschte Richtlinie aus (nur anklicken, nicht den Namen klicken) und wähle in der Leiste oben „Richtlinie bearbeiten“.

2. Zur Regel navigieren: Klicke im Wizard auf „Weiter“, bis du zum Punkt „Erweiterte DLP-Regeln“ kommst.
   • Regel editieren: Du siehst nun die einzelnen Regeln (z. B. „Geringes Volumen“ oder „Hohes Volumen“). Markiere die gewünschte Regel und klicke auf das Stift-Symbol (Bearbeiten).

3. Benachrichtigung: Scrolle im Fenster herunter bis zum Abschnitt „Benutzerbenachrichtigungen“.
   • Aktiviere: „Verwenden Sie Benachrichtigungen, um Ihre Benutzer …“
   • Aktiviere: „Passen Sie den Text der Richtlinie an“.
     • Beispiel Text: „Diese Datei enthält sensible …daten und darf nicht mit externen geteilt werden. Bitte bereinigen Sie die Datei oder wenden Sie sich an die IT.“
       
   • Tipp: Sei so spezifisch wie möglich, aber halte es kurz (max. 256 Zeichen sind ideal). Der Nutzer muss in Sekundenbruchteilen verstehen: Warum wurde blockiert und was muss er tun, um weiterarbeiten zu können? Wenn du internationale Teams hast, schreibe den Text zweisprachig (DE/EN).

Der Flow in Microsoft Teams: Da der Scan asynchron läuft, sieht der Prozess für den Endanwender so aus:

1. Upload: Der Nutzer lädt die Datei hoch. Sie erscheint kurz normal.
2. Scan & Match: Im Hintergrund schlägt die DLP-Regel an.
3. Indikator: Das Datei-Icon im Teams-Kanal erhält eine kleine rote Markierung (meist ein Schild- oder „Verboten“-Symbol).
4. Erziehung: Fährt der Nutzer mit der Maus über das Symbol oder klickt auf „Weitere Optionen“, wird dein konfigurierter Policy Tip Text angezeigt. Er versteht sofort: „Ah, die Kreditkartennummer!“ und löscht die Datei selbstständig, ohne ein Ticket zu eröffnen.

Szenario 4: Ausnahme-Management

Jede DLP-Strategie erreicht irgendwann den Punkt, an dem die maschinelle Logik an der betrieblichen Realität scheitert. Ein False Positive (z. B. eine interne Projektnummer, die zufällig wie eine Kreditkartennummer aussieht) oder ein legitimer Ausnahmefall (HR muss Gehaltsdaten an den externen Steuerberater senden) darf nicht dazu führen, dass geschäftskritische Prozesse stehen bleiben.

Als Architekt baust du hierfür einen „Notausgang“ ein: Den User Override. Damit gibst du die Verantwortung für den Datentransfer temporär an den Anwender zurück, erzwingst aber gleichzeitig eine Protokollierung. Das wandelt die Rolle der IT von „Verhinderer“ zu „Auditor“.

Die Konfiguration der „Psychologischen Schranke“: Im Regel-Editor der DLP-Policy findest du unterhalb der Aktionen den Bereich für Außerkraftsetzungen.

1. Aktiviere die Option „Außerkraftsetzung durch Benutzer zulassen“.
2. Setze zwingend den Haken bei „Geschäftliche Begründung für das Außerkraftsetzen anfordern“.

Das bloße Klicken eines „Trotzdem senden“-Buttons reicht nicht. Der User muss aktiv auswählen, warum er die Regel umgeht (z. B. via Dropdown „Falsch positiv“ oder Texteingabe). Dies erzeugt eine psychologische Hürde: Der Mitarbeiter weiß, dass sein Name und seine Begründung in einem Compliance-Log landen. Das verhindert den missbräuchlichen „Dauer-Override“ aus Bequemlichkeit.

Der Workflow in der Praxis:

1. Der Nutzer teilt die Datei in Teams.
2. SharePoint blockiert den Zugriff und zeigt das Warnsymbol.
3. Im Policy Tip (siehe Szenario 3) erscheint nun zusätzlich ein Button „Außerkraftsetzen“ (Override).
4. Ein Dialogfenster fordert die Begründung.
5. Nach Bestätigung wird die Datei sofort wieder freigegeben – ohne dass ein Admin eingreifen muss.

Hinweis: Diese Overrides generieren Alerts im Microsoft Purview Compliance Portal. Dein Job ist es nicht, jede Ausnahme manuell zu genehmigen, sondern einmal wöchentlich die Reports zu prüfen: Wenn Abteilung X ständig die Regel „Finanzdaten“ mit der Begründung „Falsch positiv“ überschreibt, ist vermutlich deine Regel zu strikt eingestellt und muss angepasst werden.

Szenario 5: Die „Unscannable“-Falle (Verschlüsselt)

Ein Klassiker der Datenexfiltration – ob durch böswillige Insider oder Malware – ist das Verpacken von gestohlenen Daten in ein passwortgeschütztes ZIP- oder RAR-Archiv. Der Gedanke dahinter: „Wenn DLP nicht reinschauen kann, kann es mich nicht blockieren.“

Als Architekt musst du hier eine Grundsatzentscheidung treffen: Vertraust du Inhalten, die du nicht inspizieren kannst? In Hochsicherheitsbereichen lautet die Antwort „Nein“.

Die Konfiguration: Microsoft DLP bietet eine spezifische Bedingung für Anhänge oder Dateien, die nicht gescannt werden können (z.B. passwortgeschützt oder korrupt).

1. Wähle in der Regel die Bedingung: „Inhalt konnte nicht gescannt werden“ (Content couldn’t be scanned).
2. Aktion: Blockieren oder zumindest den Admin benachrichtigen.

Der Impact: Dies ist eine restriktive Maßnahme. Wenn du sie aktivierst, wird der legitime Workflow „Ich schicke dem Kollegen kurz das passwortgeschützte Lohn-PDF“ in Teams unterbunden. Kommuniziere diesen Schritt daher proaktiv: „Verschlüsselte Dateien dürfen nicht via Teams geteilt werden – bitte nutzt dafür [Alternativer Sicherer Weg].“

Achtung: Dies blockiert auch legitime, passwortgeschützte PDFs (z.B. Gehaltsabrechnungen der HR). Kläre diesen Prozess vorher mit den Fachabteilungen oder baue eine Ausnahme für die HR-SharePoint-Site!

Jetzt, da deine Regeln für SharePoint und OneDrive scharfgeschaltet sind, beginnt die eigentliche Arbeit. Eine DLP-Richtlinie ist kein „Set-and-Forget“-Werkzeug. Sie generiert fortlaufend Signale – von echten Treffern bis hin zu den erwähnten False Positives.

Simulationsmodus

Microsoft zwingt dich am Ende des Wizards zu einer Entscheidung. Die einzig valide Option für eine neue Architektur ist: „Richtlinie im Simulationsmodus ausführen“.

Technisch betrachtet trennst du hier die Erkennung von der Durchsetzung. Das System prüft den Traffic gegen deine Bedingungen und schreibt Matches in das Audit-Log, führt aber keine blockierenden Aktionen (wie NDRs oder Verschlüsselung) aus.

Der Test (Empfohlen): Aktiviere zusätzlich die Checkbox „Richtlinientipps im Simulationsmodus anzeigen“. Das ist der ideale Mittelweg für das Onboarding:

Hinweis: Lasse die Option „Aktivieren Sie die Richtlinie nach 15 Tagen…“ zwingend deaktiviert. Ein Go-Live erfolgt in der Sicherheitsarchitektur niemals zeitbasiert („blind“), sondern erst nach manueller Auswertung der Logs. Wenn du diese Automatik vergisst, riskierst du nach zwei Wochen ungeprüfte Störungen im operativen Geschäft.

Und wo sehe ich, was passiert?

Eine DLP-Regel ist wertlos, wenn du nicht siehst, wann und wo sie greift. Navigiere daher im Purview Portal zu Explorer > Aktivitäten-Explorer. Filter dort gezielt!

Mein Rat: Prüfe diesen Report in den ersten Wochen täglich. Werden legitime Geschäftsprozesse blockiert? Falls ja, musst du die „Instanz-Anzahl“ erhöhen oder Ausnahmen definieren.

Doch das bloße Sammeln von Treffern reicht langfristig nicht aus. Wie du diese Signale richtig interpretierst, bewertest und sogar Automatisierungen dahinterlegst, sprengt den Rahmen dieses Guides. Für diesen operativen „Day-2“-Prozess empfehle ich dir meinen Artikel:

• Purview DLP | Lebenszyklus: Signale verstehen, bewerten und automatisieren

Dort zeige ich dir, wie du aus der anfänglichen Flut an Warnmeldungen einen robusten, handhabbaren Sicherheitsprozess formst.

Fazit & Ausblick

Die Einrichtung von DLP auf der Ebene von SharePoint und OneDrive ist der effektivste Weg, um die Datenhoheit in einer Business-Premium-Umgebung zurückzugewinnen. Da wir direkt an der Quelle (dem Speicherort) ansetzen, funktionieren deine Sicherheitsregeln universell, egal ob der Nutzer die Datei über den Browser / den Windows Explorer oder eben über die Teams-Oberfläche teilt.

Wir haben gesehen: Sobald eine Datei im Teams-Kanal landet, greift die SharePoint-Regel. Sobald sie im privaten Chat geteilt wird, greift die OneDrive-Regel. Damit hast du das Risiko von versehentlichen „File-Leaks“ massiv reduziert, ohne teure Zusatzlizenzen kaufen zu müssen.

Der Ausblick: Die Lücke im Chat-Verlauf Doch eine Frage bleibt offen: Wir haben jetzt die Dateien in Teams gesichert. Aber was passiert, wenn ein Nutzer sensible Daten (wie eine Kreditkartennummer) nicht als Excel-Datei anhängt, sondern sie einfach als Textnachricht in den Chat tippt?

Hier endet die Zuständigkeit von SharePoint und OneDrive. Reine Chat-Nachrichten liegen in einer anderen Architektur und benötigen für DLP-Scans zwingend eine E5-Lizenzierung (Teams Chat & Channel DLP).

Da dies technisch ein komplett anderes Thema ist, widme ich diesem Szenario einen eigenen Artikel im Februar.

Bis dahin gilt:
Deine Dokumente sind jetzt sicher. Das Fundament steht.

weitere Links

This post is also available in: Deutsch English