Security-Teams müssen Copilot-Prompts jetzt härten
8 Min. Lesezeit
Das Center for Internet Security hat mit der April-2026-Revision der Microsoft-365-Benchmarks den Copilot-Angriffsvektor konkret adressiert. Die neuen Kontrollen betreffen Managed-Device-Pflicht, Purview-DLP-Policies für Copilot-Prompts, Conditional-Access-Regeln für Graph-API-Zugriffe und Audit-Logging. Für Security-Teams heißt das: Die bisherige Zero-Trust-Posture greift bei Copilot nur teilweise – die fehlenden Kontrollen müssen in den kommenden Quartalen ergänzt werden.
Das Wichtigste in Kürze
- CIS Microsoft 365 Benchmark v4.0.0: Neue Kontrollen für Copilot-Prompts, erweiterte Entra-ID-Guidance und strengere Managed-Device-Anforderungen. Unmanaged Devices sind als valide Authenticators nicht mehr zugelassen.
- Purview DLP für Copilot in GA: Seit Ignite 2025 und Ausrollphase 2026 können DLP-Policies Prompt-Inhalte in Echtzeit auf Sensitive Information Types prüfen – ein völlig neuer Kontrollpunkt.
- Graph-API als Datenautobahn: Copilot bezieht Antworten über Microsoft Graph. Ohne Least-Privilege-Graph-Permissions liest der Assistent auf mehr Daten zu als die Nutzerin selbst im Alltag öffnet.
- Conditional-Access-Lücke: Die meisten Unternehmen haben Conditional Access für Outlook und Teams sauber konfiguriert – für Copilot-Endpunkte greifen die Regeln oft nur teilweise, weil die App-Identität eine andere ist.
Was ist eine CIS Benchmark? Eine CIS Benchmark ist ein konsensbasiertes Sicherheitskonfigurationsprofil des Center for Internet Security. Sie beschreibt konkrete, umsetzbare Härtungsmaßnahmen für gängige Plattformen wie Microsoft 365, Windows, Linux oder Kubernetes. Für Microsoft 365 liefert die Benchmark abgestufte Hardening-Profile (Level 1 und Level 2) für Entra ID, Exchange Online, SharePoint, Teams, Defender und seit Version 4.0.0 auch für Copilot. Sie dient als praxisnaher technischer Unterbau zu ISO 27001, NIST CSF und BSI-Grundschutz.
Warum Copilot einen eigenen Kontrollrahmen braucht
Microsoft 365 Copilot ist kein klassisches SaaS-Feature, sondern ein Agent, der auf die komplette Informations-Oberfläche eines Nutzerkontos zugreift. Mails, Dokumente, Kalender, Chat-Verläufe, SharePoint-Dateien, OneDrive-Content, Teams-Meetings, Dynamics-Datensätze – alles was der Nutzer theoretisch sehen könnte, kann Copilot zur Antwortgenerierung heranziehen. Der Unterschied zur früheren Microsoft-365-Nutzung liegt im Default-Verhalten: Copilot liest proaktiv, was Menschen in der Regel nur reaktiv öffnen würden.
Diese Architektur hat zwei Konsequenzen für Security-Teams. Erstens wird jede fehlerhafte SharePoint-Berechtigung zum Datenleck. Wenn ein Finance-Ordner versehentlich für alle Mitarbeiter freigegeben ist, fiel das früher kaum auf, weil Menschen den Ordner nicht gezielt aufriefen. Copilot findet ihn sofort und zieht Inhalte in Antworten. Zweitens werden Prompt-Inhalte zu einer neuen Datenklasse: das, was Mitarbeiter in das Prompt-Feld tippen, kann sensibel sein – Kundendaten, Gehaltsinformationen, M-und-A-Details. Ohne Kontrolle verlassen diese Daten den Kontext, in dem sie eigentlich bleiben sollten.
Genau diese beiden Punkte adressiert die CIS-v4.0.0-Revision. Managed-Device-Pflicht verhindert, dass ein BYOD-Mitarbeiter Copilot-Antworten auf einem privaten Gerät verarbeitet. Purview-DLP-Policies für Prompts erkennen Sensitive Information Types in Echtzeit. Damit wird Copilot erstmals regelbasiert in die klassische DLP-Welt eingebunden, die bisher auf Mail und File-Upload fokussiert war.
Die fünf zentralen Kontrollfelder der v4.0.0
Die Revision deckt eine breite Palette an Hardening-Themen ab, fünf davon sind für Copilot-Umgebungen operativ besonders relevant. Erstens: Identitäts-Härtung über Entra ID. Phishing-resistente MFA, Managed Devices als Authenticator-Anforderung, strikte Conditional-Access-Policies für riskante Benutzer und Sessions. Wer diese Basis nicht hat, verliert die erste Verteidigungslinie noch bevor Copilot ins Spiel kommt.
Zweitens: Daten-Schutz über Purview. SharePoint- und OneDrive-Berechtigungen werden durchforstet, öffentliche Links beschränkt, Sensitivity Labels verpflichtend für bestimmte Dokumenttypen. Purview-DLP-Policies werden erweitert auf Copilot-Prompt-Inhalte – jede Prompt-Nachricht wird in Echtzeit gegen definierte Sensitive Information Types geprüft. Der Einsatz ist GA, die Konfiguration erfordert aber gezielte Planung, weil zu strikte Regeln die tägliche Nutzung spürbar behindern.
Drittens: Graph-API-Zugriffe. Copilot bezieht Kontext über Microsoft Graph, nicht über direkte Datei-Leseoperationen. Die Benchmark empfiehlt Least-Privilege für alle Graph-Scopes, regelmäßige Überprüfung granted permissions und automatische Entzugsregeln für ungenutzte Permissions nach 90 Tagen. Ohne diese Hygiene summiert sich ein Berechtigungs-Überhang, der im Incident-Fall zur Stolperstelle wird.
Viertens: Audit-Logging. Copilot-Interaktionen werden standardmäßig im Unified Audit Log erfasst, aber nur auf Basic-Niveau. Für Security-Teams mit ernsthaftem Detection-Bedarf empfiehlt die Benchmark Audit Standard – das liefert Prompt-Metadaten, abgerufene Quellen und Antwort-IDs. Diese Daten fließen in SIEM-Systeme ein und bilden die Grundlage für Copilot-spezifische Detection-Rules.
Fünftens: Administrative Separation. Global-Admin-Rollen werden reduziert, Privileged Identity Management für Copilot-Admin-Rollen verpflichtend, Break-Glass-Konten isoliert und mit Hardware-Token gesichert. Die Benchmark folgt damit dem Zero-Standing-Access-Prinzip, das auf Copilot-Umgebungen übertragen wird.
Copilot verschiebt die Default-Annahme von Zugriff: Was gestern für einen Menschen theoretisch erreichbar war, ist heute für den Agenten praktisch gelesen. Wer seine Berechtigungsstrukturen nicht vor der Copilot-Aktivierung aufräumt, muss es danach unter Zeitdruck tun.
Die operative Herausforderung: Level 1 oder Level 2
Die CIS-Benchmarks sind in zwei Implementierungsstufen organisiert. Level 1 ist das operative Mindestniveau – spürbare Sicherheit ohne Beeinträchtigung der Produktivität. Level 2 geht deutlich weiter und nimmt Komfortverluste in Kauf für messbar höhere Sicherheit. Für Copilot-Umgebungen stellt sich die Wahl heute konkreter als bei klassischen Microsoft-365-Szenarien. Die Regelungen unterscheiden sich in Reichweite und Nutzerauswirkungen.
Level 1 umfasst typischerweise: Phishing-resistent MFA, Sensitivity Labels, DLP-Policies für klassische Dokumente, Audit-Logging auf Standard-Niveau, Conditional Access für riskante Signale. Das ist für die meisten Mittelständler und kleineren Enterprise-Umgebungen das realistische Ziel der nächsten zwei Quartale. Die Einführung greift überschaubar in den Alltag ein, die Compliance-Basis steht.
Level 2 fügt hinzu: Managed-Device-Pflicht für alle Microsoft-365-Anmeldungen, Zero Standing Access mit PIM, strengere Session-Controls, automatische Sperre unkonfigurierter OAuth-Apps, fortgeschrittene DLP-Regeln mit KI-basierter Klassifizierung. Das ist das Niveau, das regulierte Branchen – Finance, Healthcare, kritische Infrastruktur – anstreben müssen. Es ist aber auch das Niveau, bei dem typischerweise 15 bis 25 Prozent der Nutzer initial Produktivitätseinbußen wahrnehmen, bevor die Organisation sich eingeschwungen hat.
Wie Security-Teams den Umbau priorisieren
Die pragmatische Reihenfolge für Security-Teams im DACH-Mittelstand und bei kleineren Enterprise-Organisationen folgt vier klaren Schritten. Wichtig ist, nicht alles gleichzeitig anzugehen, sondern in der richtigen Abfolge zu priorisieren.
Die fünfte Ebene, die in vielen Organisationen vergessen wird, ist die organisatorische. Wer Copilot-Kontrollen technisch umsetzt, aber die Betroffenen nicht mitnimmt, erzeugt Widerstand und Workarounds. Mitarbeiter, die Copilot-Blocks erleben, ohne zu verstehen warum, probieren private Konten, Drittanbieter-Tools oder schreiben sensible Inhalte in Nicht-Copilot-Flächen ab. Die technische Benchmark ist notwendig, aber nicht hinreichend.
Aus Architektursicht lohnt sich der Blick auf die Interaktion zwischen CIS v4 und anderen Frameworks. NIST AI Risk Management Framework, ISO 42001 (AI Management Systems), NIS-2 – alle drei Regelwerke bekommen 2026 Copilot-spezifische Interpretationen. Die CIS-Benchmark liefert die operativen Hebel, die anderen Frameworks die Governance-Struktur. Wer diese Ebene nicht miteinander verzahnt, baut entweder einen technischen Overkill ohne strategische Lenkung oder eine Policy ohne operative Deckung.
Der dritte Aspekt ist die Weiterentwicklung. Microsoft kündigt Agent 365 als zentralen Control Plane für KI-Agenten an, erweitert Purview um DSPM-Features und integriert Credential Scanning in den Defender-Stack. Jede dieser Erweiterungen wird die CIS-Benchmark in den nächsten Revisionen reflektieren. Security-Teams sollten die Entwicklung mitverfolgen und nicht auf eine finale, stabile Baseline warten. Copilot ist 2026 eine bewegliche Zielscheibe, die Kontrollen werden es ebenfalls sein.
Gerade bei Unternehmen mit eigener Copilot-Plugin-Entwicklung oder mit Anbindung an interne Agenten lohnt sich der genaue Blick auf Scope-Vergabe und OAuth-Configs. Fehler an dieser Stelle wirken sich später als stille Datenabflüsse aus, die oft erst bei einem externen Audit entdeckt werden. Eine saubere Startkonfiguration ist hier deutlich günstiger als die spätere Reparatur.
Was die Benchmark nicht abdeckt – und wo externe Bausteine greifen
Die CIS Benchmark v4.0.0 ist stark bei Konfigurations-Hardening, sie ist aber keine vollständige KI-Governance. Drei Themen liegen außerhalb des Geltungsbereichs und müssen separat adressiert werden. Erstens: Prompt-Injection und Jailbreak-Abwehr. Die Benchmark regelt Berechtigungen und Datenflüsse, sie verhindert keine manipulativen Prompt-Formulierungen. Hier braucht es ergänzende Guardrails auf Anwendungsebene.
Zweitens: Modell-Drift-Monitoring. Welche Antworten Copilot liefert, ändert sich mit neuen Model-Releases. Die CIS Benchmark kontrolliert Konfiguration, nicht Qualität. Für sicherheitsrelevante Use Cases empfiehlt sich ein eigener Testsatz mit bekannten Input-Output-Paaren, der vor und nach Model-Releases automatisiert durchläuft. Abweichungen werden dokumentiert und bewertet.
Drittens: Supply-Chain-Risiken bei Plugins. Copilot-Plugins von Drittanbietern bekommen eigenständige Graph-Permissions und greifen in Antwort-Flows ein. Die Benchmark empfiehlt strenge App-Governance, die eigentliche Risikobewertung muss aber je Plugin durchgeführt werden – ähnlich wie bei klassischen SaaS-Einführungen, nur mit kürzerem Einführungszyklus.
Für Security-Teams lohnt sich deshalb die Kombination aus CIS-Benchmark als technische Grundlage und einem zusätzlichen AI-Governance-Framework auf organisatorischer Ebene. NIST AI RMF oder ISO 42001 schließen die Lücken, die CIS bewusst offen lässt. Ohne diesen zweiten Layer bleiben die Kontrollen effektiv für die Konfiguration, aber unvollständig für das Gesamt-Risiko Copilot.
Häufige Fragen
Was hat sich in der CIS-Benchmark-Version 4.0.0 konkret geändert?
Die Version 4.0.0 erweitert die Benchmark um explizite Copilot-Kontrollen, neue Entra-ID-Guidance mit Managed-Device-Pflicht, erweiterte Purview-DLP-Empfehlungen für Prompt-Inhalte und zusätzliche Abschnitte zu Power BI Fabric und Defender for Cloud Apps. Insgesamt sind rund 40 bis 50 neue Einzelrecommendations hinzugekommen, einige bestehende wurden verschärft.
Ist Purview DLP für Copilot-Prompts produktionsreif?
Ja. Microsoft hat die Funktion am Ignite 2025 angekündigt und im Laufe 2026 in General Availability gebracht. Die Funktion ist für alle Microsoft 365 Copilot und Copilot Chat Nutzer aktivierbar, die Policies setzen auf Sensitive Information Types auf und prüfen Prompts in Echtzeit.
Wie aufwendig ist die Umsetzung von Level 1 realistisch?
Für eine typische 1.000-Mitarbeiter-Organisation mit bereits solider Microsoft-365-Basis etwa acht bis zwölf Wochen bis zum Level-1-Niveau. Voraussetzung ist ein Security-Team mit Erfahrung in Purview, Entra ID und Defender. Ohne diese Basisqualifikation sollten zusätzlich vier bis sechs Wochen Vorbereitung eingeplant werden.
Was passiert, wenn Copilot ohne DLP eingeführt wird?
Die häufigste Folge ist eine Häufung von kleineren Data-Leakage-Vorfällen. Gehaltsdaten in Copilot-Prompts, Kundendaten in Antworten, vertrauliche Projektinfos in Zusammenfassungen – einzelne Vorfälle sind selten spektakulär, in Summe entsteht ein Risikoprofil, das ein Wirtschaftsprüfer oder Datenschutzbeauftragter im Audit beanstandet.
Welche Rolle spielt BSI C5 in diesem Kontext?
BSI C5 ist die Zertifizierungs-Anforderung aus Deutschland und Österreich für Cloud-Dienste mit besonderen Sicherheitsanforderungen. CIS-Benchmark-Maßnahmen decken weite Teile der C5-Kontrollen auf Konfigurations-Ebene ab. Für eine vollständige C5-Konformität braucht es zusätzlich Prozess-Dokumentation, Rollenkonzepte und regelmäßige Audits – die CIS-Benchmark liefert aber den technischen Unterbau.
Mehr aus dem MBF Media Netzwerk
cloudmagazin: AWS EC2 C8in und C8ib – 600 Gbps Netzwerk im Praxiseinsatz
mybusinessfuture: Bitkom-KI-Studie 2026
digital-chiefs: Sustainable IT 2026 – Scope 3 für CSRD
Quelle Titelbild: Pexels / cottonbro studio (px:5473298)
