Microsoft 365 Copilot | bringt Ordnung – oder Chaos! Du entscheidest!

Die Einführung von Microsoft 365 Copilot ist kein einfaches Lizenzprojekt, sondern ein fundamentaler Eingriff in die Sicherheitsarchitektur deiner Organisation.

Der Aktuelle Zustand vieler Unternehmen ist geprägt von historisch gewachsenen Berechtigungen, unstrukturierten Datenablagen und dem trügerischen Schutz durch „Security by Obscurity“. In diesem alten Modell blieben sensible Daten oft nur deshalb geschützt, weil niemand wusste, wo genau sie lagen oder wie man sie findet.

Der Zukünftige Zustand verlangt hingegen eine „Zero Trust“-Umgebung, in der Daten granular klassifiziert und Zugriffe streng kontrolliert werden. Copilot respektiert Berechtigungen kompromisslos, aber er verändert die Auffindbarkeit drastisch.

Technisch gesehen wird dies durch den Semantic Index getrieben. Anders als die klassische Stichwortsuche kartografiert der Semantic Index nicht nur Inhalte, sondern auch die Beziehungen zwischen Usern und Daten im Microsoft Graph.

Copilot versteht den Kontext (z.B. „Gehaltsdaten“ oder „Strategiepapier“) und fördert Informationen zutage, die ein Mitarbeiter zwar technisch lesen darf, aber früher nie gefunden hätte. Das macht Copilot zum ultimativen Stresstest für deine Data Governance: Er macht „Over-Sharing“ (übermäßige Freigaben) sofort sichtbar und operationalisiert Berechtigungsfehler in Sekundenbruchteilen.

Die Mechanik des Scheiterns: Der Semantic Index und ACLs

Um die Tragweite zu verstehen, musst du die Funktionsweise von Copilot kennen. Der Dienst arbeitet nicht wie ein Mensch, der Dateien manuell durchsucht, sondern nutzt den Semantic Index for Copilot, eine semantische Datenkarte auf Basis des Microsoft Graph. Dieser Index verknüpft Inhalte, Benutzer und Aktionen und macht Informationen auffindbar, die bisher im Schatten lagen.

Das Problem entsteht, wenn Access Control Lists (ACLs) über Jahre hinweg verwildert sind. Eine Datei, die auf einer SharePoint-Site mit der Einstellung „Jeder außer externen Benutzern“ liegt, war früher praktisch unsichtbar, weil sie in der Masse der Daten unterging. Copilot eliminiert diese Unsichtbarkeit. Ein einfacher Prompt wie „Fasse alle Dokumente zum Thema ‚Bonuszahlungen‘ zusammen“ kann vertrauliche Daten ans Licht bringen, wenn die Berechtigungen zu weit gefasst sind. Die Konsequenz: Du musst deine Berechtigungsstruktur nicht nur prüfen, sondern neu denken.

Der Semantic Index ist gnadenlos effizient: Er validiert Berechtigungen zwar technisch korrekt (sogenanntes Security Trimming), aber er unterscheidet nicht zwischen „technisch erlaubt“ und „inhaltlich sinnvoll“.

Warum ACLs im KI-Zeitalter versagen

Hier sind die technischen Mechanismen, die zu diesem Risiko führen:

• Security Trimming in Echtzeit: Copilot prüft bei jeder Abfrage den User-Token gegen die ACLs des Elements im Index. Das Problem ist nicht, dass Copilot Berechtigungen umgeht, sondern dass er technisch gültige Berechtigungen nutzt, die organisatorisch längst veraltet oder falsch sind.
  
• Broken Inheritance (Unterbrochene Vererbung): Dies ist der häufigste technische Fehler. Wenn Nutzer in SharePoint den „Teilen“-Button nutzen, wird oft unbemerkt die Vererbung der Berechtigungen unterbrochen. Es entsteht eine „Schatten-Berechtigungsstruktur“ auf Item-Level, die in klassischen Admin-Reports oft nicht sichtbar ist, aber vom Semantic Index voll erfasst wird.
  
• Granularität der Sharing Links: Ein „Firma-weiter Link“ (Organization-wide Link), der vielleicht vor 3 Jahren für ein einzelnes Dokument erstellt wurde, bleibt gültig. Copilot findet diesen Link und somit den Inhalt, auch wenn der ursprüngliche Empfänger das Unternehmen längst verlassen hat.
  
• Verschachtelte Sicherheitsgruppen (Nested Groups): In vielen Active Directory Umgebungen sind Gruppen in Gruppen verschachtelt. Der Semantic Index „flacht“ diese Strukturen bei der Prüfung der Zugriffsberechtigungen effektiv ab (Flattening). Das führt dazu, dass User Zugriff auf Daten haben, von denen die IT-Abteilung aufgrund der Komplexität der Schachtelung gar nichts mehr wusste.

Oversharing: Die unsichtbare Bedrohung quantifizieren

Bevor du Maßnahmen ergreifst, musst du das Ausmaß des Oversharings quantifizieren. Oversharing bedeutet technisch gesehen, dass der Scope der Zugriffsberechtigung (ACL) größer ist als die Sensibilität des Inhalts erfordert.

Typische Ursachen sind organisationsweite Links („Jeder in Contoso“), öffentliche Teams und vererbte Berechtigungen aus alten File-Server-Migrationen.

Diese Risiken waren früher latent („Security by Obscurity“). Copilot macht sie akut, indem er sie über den Semantic Index gnadenlos offenlegt.

Die Analyse erfolgt primär mit SharePoint Advanced Management (SAM) und den Data Security Posture Management (DSPM) Funktionen in Microsoft Purview. Ziel ist die Definition eines konkreten „Blast Radius“: Welche Menge an Sensitive Information Types (SITs) – wie IBANs, Passwörter oder Strategiepapiere – würde durch einen einzigen kompromittierten User-Account abfließen? Erst wenn du diese Diskrepanz zwischen Datenwert (Content Sensitivity) und Zugriffsebene (Exposure) kennst, kannst du die Architektur härten.

Reports und Tools:

• Data Access Governance (DAG) Reports (in SAM): Dies ist dein wichtigstes Werkzeug. Nutze speziell den Report „Sharing links“, um alle Links zu identifizieren, die auf „People in your organization“ (Jeder im Unternehmen) eingestellt sind. Diese Links hebeln oft Site-Berechtigungen aus und sind Futter für Copilot.
• Oversharing Baseline Report: SAM bietet mittlerweile Baseline-Reports, die Sites hervorheben, auf denen sensible Daten (erkannt durch Sensitivity Labels) mit zu weiten Gruppen (z.B. „Everyone except external users“) geteilt werden.
• DSPM for AI (Data Security Posture Management): Im Purview Portal findest du unter AI Hub eine Übersicht, die Risiken speziell für Copilot bewertet. Achte auf die „Data Risk Assessments“, die automatisch für die Top-100 aktivsten SharePoint-Sites laufen und dir zeigen, wo ungelabelte, sensible Daten in offenen Sites liegen.
• Site Access Reviews: Ein Feature von SAM, um die Verantwortung an die Business-Owner zu delegieren. Statt dass die IT rät, wer Zugriff braucht, forderst du Site-Owner technisch dazu auf, Zugriffe auf „Everyone“-Gruppen zu bestätigen oder abzulehnen.

Wichtige Abgrenzung: Unterscheide zwischen technischem Zugriff (User ist in der Member-Gruppe) und effektivem Zugriff (User hat Zugriff via Sharing Link). Copilot nutzt beides. Deine Quantifizierung muss daher zwingend Sharing-Links einschließen, nicht nur Gruppenmitgliedschaften.

Architektur der Härtung: Sensitivity Labels als Gatekeeper

Die wirksamste Verteidigungslinie ist eine datenzentrierte Sicherheitsarchitektur. Statt den Speicherort (die „Burgmauer“) zu schützen, sicherst du das Objekt selbst. Sensitivity Labels in Microsoft Purview sind der Schlüssel. Sie schreiben Verschlüsselung und Zugriffsrechte direkt in die Metadaten der Datei.

Copilot respektiert diese Labels strikt. Das technische Kriterium ist hier das Usage Right „EXTRACT“. Hat ein Nutzer zwar Lesezugriff („VIEW“), aber nicht das Recht, Inhalte zu kopieren oder zu extrahieren („EXTRACT“), ist Copilot blind für den Inhalt dieser Datei. Er kann sie weder zusammenfassen noch für Antworten nutzen, selbst wenn der Nutzer die Datei öffnen kann. Damit schaffst du eine granulare Ebene der Sicherheit, die weit über simple Dateiberechtigungen hinausgeht.

Entscheidende Konfigurationen:

• Service-Side Auto-Labeling: Verlasse dich nicht auf Client-Side Labeling (wenn der User speichert). Aktiviere Auto-labeling policies im Purview Backend. Diese scannen asynchron ruhende Daten (Data at Rest) in SharePoint und OneDrive und wenden Verschlüsselung automatisch an, ohne dass der User die Datei öffnen muss. Das ist essenziell für die Bereinigung von Altlasten („Brownfield“).
  
• Default Sensitivity Labels für SharePoint Libraries: Du kannst (und solltest) für kritische Document Libraries ein Standard-Label konfigurieren. Jede neue Datei, die in diese Library hochgeladen wird, erbt automatisch dieses Label. Das ist effektiver als User-Training und verhindert, dass neue Dateien ungeschützt in den Index gelangen.
  
• Container Labels vs. Item Labels: Unterscheide technisch sauber: Ein Label auf einem „Team“ oder einer „Site“ (Container Level) steuert den Zugriff von außen (z.B. Gastzugriff blockieren). Es verschlüsselt aber nicht die Dateien darin. Nur Item-Level Labels verschlüsseln die Datei selbst und schützen vor internem Oversharing durch Copilot.
  
• Label Priority: Copilot nutzt immer das Label mit der höchsten Priorität. Wenn eine Datei manuell als „Public“ gelabelt wurde, aber sensible Daten enthält, greift (je nach Policy-Einstellung) das automatische Labeling möglicherweise nicht. Überprüfe deine „Downgrade“-Richtlinien (darf ein User ein Label entfernen?), um Lücken zu schließen.

Container-Level Security und Just-Enough-Access

Neben der Objektklassifizierung (Labels) musst du die Container-Architektur überarbeiten. Vermischte Teams, in denen „Allgemeines“ (z.B. Mittagspausen-Planung) und „Streng Vertrauliches“ (z.B. Gehaltslisten) im selben Kanal liegen, sind ein tödliches Risiko für die Datenhygiene. Die Lösung ist eine strikte Entflechtung der Informationsarchitektur und die Einführung von Restricted Access Control (RAC) für SharePoint Sites. Damit legst du eine harte technische Obergrenze fest: Selbst wenn eine Datei per Link geteilt wird, greift der Zugriff nur, wenn der User zusätzlich Mitglied einer definierten Sicherheitsgruppe ist.

Ergänzend implementierst du Retention Policies und Microsoft 365 Archive, um redundante, veraltete oder triviale Daten (ROT-Daten) aus dem „heißen“ Speicher zu entfernen. Weniger Daten bedeuten weniger Angriffsfläche und – entscheidend für die Akzeptanz – präzisere Antworten der KI. Eine Umgebung, die auf Projektdaten von 2015 basiert, halluziniert zwangsläufig veraltete Fakten in aktuelle Antworten. Die Bereinigung ist also nicht nur ein Sicherheits-, sondern ein massiver Qualitätsfaktor für den Semantic Index.

Entscheidende Konfigurationen:

• Restricted Access Control (RAC) für SharePoint: Technisch gesehen fungiert RAC als eine „UND-Verknüpfung“ bei der Autorisierung.
  • Normal: User hat Link ODER ist Mitglied = Zugriff.
  • Mit RAC: User hat Link/Mitgliedschaft UND ist in der RAC-Sicherheitsgruppe = Zugriff. Das neutralisiert effektiv alte „Jeder“-Links, die noch im System herumgeistern, da diese externen oder unbefugten Usern meist die Gruppenzugehörigkeit zur RAC-Gruppe fehlt.
    
• Microsoft 365 Archive (Cold Storage): Dies ist der wichtigste Hebel für ROT-Daten im Jahr 2025. Anstatt Daten hart zu löschen (was Fachbereiche oft blockieren), verschiebst du inaktive SharePoint Sites in das Microsoft 365 Archive.
  • Der Copilot-Effekt: Archivierte Daten werden aus dem Semantic Index entfernt. Copilot „vergisst“ diese Daten, sie stören nicht mehr bei Antworten, sind aber für Admins/Owner im Notfall wiederherstellbar. Das spart zudem Speicherkosten.
    
• Adaptive Scopes für Retention Policies: Vermeide statische Richtlinien („Alle Sites“). Nutze Adaptive Scopes, die dynamisch auf Site-Attribute reagieren.
  • Beispiel: Wenn ein Projekt im SharePoint-Property-Bag als Status: Closed markiert wird, greift automatisch die Retention Policy „Löschen nach 7 Jahren“ und verschiebt die Site ggf. sofort ins Archiv.
    
• Site Lifecycle Management (in SAM): Nutze die „Inactive Sites“ Reports im SharePoint Admin Center, um verwaiste Container zu identifizieren. Ein automatisierter Workflow kann Site-Owner anschreiben: „Deine Site wird in 30 Tagen archiviert, wenn du nicht reagierst.“

Fazit: Von der Chat-KI zu autonomen Agenten

Die Einführung von Copilot markiert das Ende der alten Firewall-Welt und den endgültigen Durchbruch der Zero-Trust-Architektur. Es geht nicht mehr darum, das Netzwerk zu schützen, sondern die Daten selbst. Doch Vorsicht: Der „Ist-Zustand“ vieler Dateisysteme – offene Freigaben und Datenfriedhöfe – wird im KI-Zeitalter zum Risiko. Wer Copilot auf dieses Chaos loslässt, bekommt „Garbage In, Garbage Out“ in Lichtgeschwindigkeit.

Bessere Daten, bessere KI
Technisch gesehen verbessert eine saubere Datenbasis das sogenannte „Grounding“. Wenn Copilot weniger irrelevante Daten im Index findet, halluziniert er weniger. Die Härtung der Architektur erhöht also direkt die Qualität der Antworten. Zudem greifen Schutzmechanismen wie Microsoft Purview Insider Risk Management (IRM): Auffällige KI-Interaktionen mit sensiblen Daten hinterlassen Spuren im Audit Log.

Vorbereitung auf AI Agents
Der wichtigste Grund für diese Hygiene liegt jedoch in der nahen Zukunft. Schon bald (ca. Ende 2025) wird Copilot nicht mehr nur chatten, sondern als autonomer Agent handeln – Verträge versenden, Bestellungen auslösen. Saubere Berechtigungen sind dann keine Option mehr, sondern die überlebenswichtigen Leitplanken, damit der Agent nicht zum internen Sicherheitsrisiko wird.

weitere Links

Ich habe hier bewusst auf offizielle Microsoft-Dokumentationen gesetzt

MS365 Admin Center | Copilot Einstellungen