5 Copilot Readiness Gaps: Lessons From a Real Client Assessment - TrustedTech

5 Lücken bei der Copilot-Bereitschaft: Erkenntnisse aus einer realen Kundenbewertung

Need Help Figuring Out the Licensing You Need? Save Up to 20% by Chatting with our Experts!

Get Expert Licensing Help

Die meisten Microsoft 365-Mandanten sind am ersten Tag noch nicht auf Copilot vorbereitet, und das Problem liegt selten in der Lizenzierung; in der Regel handelt es sich um eine Frage der Governance. Da Copilot alle Informationen abruft und zusammenfasst, die ein angemeldeter Benutzer über Microsoft Graph bereits einsehen darf, werden jede Lücke im Identitätszugriff, jede nicht gekennzeichnete Datei und jedes veraltete Gerät nun zu Elementen, die Copilot schneller und einer größeren Gruppe von Personen anzeigen kann als zuvor. Bevor Sie Copilot aktivieren, müssen Sie daher feststellen, ob Ihre Identitäts-, Daten- und Endpunktkontrollen dieser intensiven Überprüfung standhalten können.

TrustedTech unterteilt die Copilot-Bereitschaft in fünf Schlüsselbereiche: Identitätssicherheit, Schutz vor Bedrohungen, Daten-Governance, Endpunktmanagement und Kontrollen für die Zusammenarbeit. Dies basiert auf den wiederholten Beobachtungen der Ingenieure von TrustedTech im Rahmen ihrer Microsoft 365 Copilot-Bereitschaftsbewertungen, darunter eine kürzlich durchgeführte Untersuchung bei einem globalen Rohstoffdienstleister, der eine Kombination aus den Microsoft 365-Editionen E3 und E5 für etwa 250 lizenzierte Benutzer einsetzte. Diese Bewertung dient im gesamten Artikel als nützliches Beispiel, da zwar bereits eine solide Microsoft-Lizenzierung und grundlegende Tools vorhanden waren, die Sicherheits- und Governance-Kontrollen jedoch nie vollständig nach Produktionsstandards eingerichtet worden waren. Für alle IT-Manager, Microsoft-Administratoren oder CIOs, die eine Einführung von Copilot in Betracht ziehen, ist dies die Checkliste, die als Erstes abgearbeitet werden sollte.

Die 5 Säulen der Copilot-Bereitschaft

Copilot verstärkt all jene Aspekte, die für Ihren Mandanten ohnehin bereits zutreffen. In einer gut geregelten Umgebung verbessern sich Sicherheit und Geschwindigkeit durch Copilot, während in einer weniger streng geregelten Umgebung die Risiken deutlicher zutage treten. In der Praxis konzentrieren sich diese Risiken auf fünf Bereiche:

  1. Identitätssicherheit (Entra) – Wer kann sich authentifizieren und unter welchen Bedingungen?
  2. Schutz vor Bedrohungen (Defender) – wie schnell ein kompromittiertes Konto oder Gerät erkannt wird
  3. Datenverwaltung (Purview) – ob sensible Daten gekennzeichnet, geschützt und über einen festgelegten Lebenszyklus hinweg aufbewahrt werden
  4. Endpunktverwaltung (Intune) – ob ausschließlich konforme, verwaltete Geräte auf Mandantendaten zugreifen können
  5. Kontrollmechanismen für die Zusammenarbeit (Teams, SharePoint, Exchange) – wie streng die Freigabe und der Zugriff plattformübergreifend geregelt sind, die Copilot tatsächlich ausliest

In den folgenden Abschnitten werden die typischen Lücken untersucht, die TrustedTech bei seinen Bewertungen feststellt, es wird erläutert, warum diese Lücken gerade für Copilot (und nicht nur für die Sicherheit im Allgemeinen) von Bedeutung sind, und es wird dargelegt, wie sie behoben werden können.

Säule 1: Identitätssicherheit (Entra)

Copilot übernimmt sein Zugriffsmodell vollständig von Entra ID. Selbst wenn das Konto eines Benutzers kompromittiert wurde und der bedingte Zugriff nicht streng eingeschränkt ist, verursacht Copilot diese Schwachstelle zwar nicht, erleichtert jedoch deren Ausnutzung erheblich, da ein Angreifer nicht mehr Ordner durchsuchen muss. Er kann eine Frage in natürlicher Sprache stellen und erhält eine synthetisierte Antwort, die aus allen Inhalten zusammengestellt wird, auf die das Konto Zugriff hat.

Die häufigsten Lücken, die bei den Bewertungen von TrustedTech in diesem Bereich festgestellt wurden, sind, dass die Multi-Faktor-Authentifizierung nicht flächendeckend, sondern nur uneinheitlich durchgesetzt wird, dass veraltete Authentifizierungsmethoden weiterhin aktiviert sind, dass Richtlinien für den bedingten Zugriff im Laufe der Zeit komplex und widersprüchlich geworden sind und dass Identitätsattribute (wie Abteilung, Position und Vorgesetzter) unvollständig sind, was die nachgelagerte Automatisierung und Zugriffsprüfungen beeinträchtigt. Bei dem oben erwähnten Projekt im Bereich Commodities Services erzielte eine Umgebung mit etwa 250 Benutzern und einem gemischten E3/E5-Tenant einen Entra Secure Score von 56,71 Prozent – ein Wert, der fast ausschließlich auf diese vier Lücken zurückzuführen ist und nicht das Ergebnis einer einzelnen schwerwiegenden Fehlkonfiguration darstellt. Das Unternehmen hatte zwar die richtigen SKUs erworben, jedoch die Konfiguration der Funktionen, die diese SKUs ermöglichen, nicht vollständig vorgenommen.

Der Weg zur Umsetzung ist zwar nicht besonders spannend, verläuft aber schrittweise. Dazu gehört die Neugestaltung des bedingten Zugriffs (Conditional Access), sodass dieser aus einer geringeren Anzahl sich nicht widersprechender Richtlinien besteht, die Durchsetzung der Multi-Faktor-Authentifizierung sowohl für Administratoren als auch für normale Benutzer, die vollständige Deaktivierung veralteter Authentifizierungsmethoden sowie die anschließende umfassende Überprüfung der Rollenverteilung unter Benutzern und Dienstprinzipalen. Aus diesem Grund betrachtet die „TrustedTech Copilot Readiness Assessment“ diesen Bereich als Ausgangspunkt: Da die Identität den Haupteingang darstellt, setzen alle anderen Säulen voraus, dass diese bereits gesichert ist.

Es sollte ausdrücklich erwähnt werden, dass das Unternehmen, das Dienstleistungen im Rohstoffbereich anbietet, bereits über die Microsoft Entra ID P2-Lizenz verfügte – also jene Version, die risikobasierte Anmeldung und Identity Governance ermöglicht. Diese war lediglich noch nicht in Betrieb genommen worden. TrustedTech stellt diese Situation häufiger fest als eine vollständige Lizenzlücke: Das Unternehmen verfügt bereits über die benötigten Kontrollmechanismen, hat diese jedoch noch nicht aktiviert.

Säule 2: Schutz vor Bedrohungen (Defender)

Copilot erhöht den Wert eines kompromittierten Kontos oder Geräts, da es einem Angreifer nach dem Zugriff ein schnelleres Suchwerkzeug an die Hand gibt. Die Aufgabe von „Defender“ besteht darin, die Kompromittierung von vornherein zu verhindern oder sie zu erkennen, bevor Copilot in den Angriff einbezogen wird. Es ist durchaus berechtigt, direkt zu fragen, ob Microsoft Copilot selbst sicher ist. Die ehrliche Antwort lautet, dass Copilot die Sicherheitslage übernimmt, die beim Mandanten bereits besteht – und genau deshalb muss dieser Aspekt vor der Einführung geklärt werden, nicht erst danach.

TrustedTech stößt regelmäßig auf Fälle, in denen „Defender for Endpoint“ zwar lizenziert, aber nicht tatsächlich implementiert ist, was bedeutet, dass Unternehmen für einen Schutz bezahlen, den sie nie aktiviert haben. Es kommt zudem recht häufig vor, dass ein E-Mail-Sicherheitstool eines Drittanbieters, das vor „Defender for Office 365“ geschaltet ist, dieses effektiv umgeht, und dass „Defender for Cloud Apps“ gänzlich ungenutzt bleibt, was dazu führt, dass kein Einblick in die mit SaaS-Anwendungen verbundenen Risiken besteht. Im Rahmen desselben Commodities-Services-Einsatzes lag der Secure Score von Defender bei 78,77 Prozent und damit etwa 22 Punkte höher als der Entra-Score des Mandanten. Endpoint-Tools schneiden in der Regel besser ab als Maßnahmen zur Identitätshygiene, da sie einmalig während des Onboardings eingerichtet und dann bei der Erweiterung der Umgebung nie wieder überprüft werden.

Um diese Lücke zu schließen, ist es erforderlich, Richtlinien zur Verringerung der Angriffsfläche umzusetzen, den EDR vom Überwachungsmodus in den Blockiermodus zu versetzen, eine Web-Inhaltsfilterung einzurichten und SaaS-Anwendungen von Drittanbietern in „Defender for Cloud Apps“ zu integrieren, damit Schatten-IT nicht vollständig außerhalb des Sicherheitsperimeters bleibt.

Säule 3: Daten-Governance (Geltungsbereich)

Genau hier liegt das größte Copilot-spezifische Risiko. Da Copilot von Haus aus kein Verständnis dafür hat, was sensible Informationen ausmacht, und sofern es von Purview nicht anders angewiesen wird, wird eine Datei als normale Datei behandelt – unabhängig davon, ob sie eine Essensbestellung oder die Finanzunterlagen eines Kunden enthält. Es ist die Data-Governance-Ebene, die tatsächlich festlegt, was für alle nachgelagerten Tools – darunter auch Copilot – als sensibel gilt.

In allen seinen Bewertungen hat TrustedTech durchweg dieselben sechs Mängel festgestellt: das Fehlen eines strukturierten Rahmens für die Sensitivitätskennzeichnung, Richtlinien zur Verhinderung von Datenverlusten (DLP), die lediglich im Simulationsmodus laufen, anstatt aktiv durchgesetzt zu werden, das Fehlen eines Aufbewahrungs- oder Lebenszyklusmanagements (was dazu führt, dass sich veraltete Daten ansammeln und die Datenmenge erhöht, aus der Copilot Daten abrufen kann), das Fehlen eines Programms zum Management interner Risiken, die Nichtaktivierung von DSPM für KI (was bedeutet, dass kein Einblick darin besteht, wie Copilot selbst mit Daten interagiert) sowie das Fehlen trainierbarer Klassifikatoren, sodass die Klassifizierung vollständig auf manuelle und uneinheitliche Maßnahmen angewiesen ist. Bei dem Projekt im Bereich Rohstoffdienstleistungen traten alle sechs dieser Probleme gleichzeitig auf, und das entspricht eher der Regel als der Ausnahme. „Purview“ ist in der Regel die Säule, deren Umsetzung Unternehmen aufschieben können, da keine der damit verbundenen Lücken zu einem offensichtlichen Ausfall führt, wie er beispielsweise durch Fehler in Identitäts- oder Endpunktsystemen verursacht wird.

Am besten beginnen Sie mit der Vergabe von Sensitivitätskennzeichnungen, da alle anderen Purview-Einstellungen davon abhängen, dass die Daten zuvor klassifiziert wurden. Anschließend sollten Sie den DLP-Modus aus dem Simulationsmodus in den aktiven Durchsetzungsmodus versetzen, Aufbewahrungskennzeichnungen einrichten, um die Lebensdauer der Daten zu verwalten, und DSPM für KI aktivieren, damit Sie eine Grundlage dafür haben, auf welche Daten Copilot tatsächlich zugreift, wenn es in Betrieb genommen wird. Was die meisten Unternehmen in dieser Phase versäumen, ist die Erkenntnis, dass sie ein Problem mit der Weitergabe zu vieler Daten haben – und zwar erst, nachdem Copilot bereits live ist und genutzt wird.

Säule 4: Endpunktverwaltung (Intune)

Auf Copilot-Daten sollte nur von einem Gerät aus zugegriffen werden können, dem Sie vertrauen, und Intune ist der Mechanismus, der dies ermöglicht – oder auch nicht.

In den Auswertungen zeigt sich immer wieder ein Muster: Es gibt keine verbindlichen Einschränkungen hinsichtlich der Geräteplattform, veraltete oder inaktive Geräte verbleiben im Mandanten, obwohl sie weiterhin aktiven Zugriff haben, die Durchsetzung von Compliance-Richtlinien erfolgt uneinheitlich, Autopilot wurde nur teilweise eingeführt, und Richtlinien zum Mobile Application Management (MAM) werden nur in begrenztem Umfang genutzt, wobei es keine MAM-Grenze gibt, die den Zugriff persönlicher Geräte auf Unternehmensdaten verhindert. Im Mandanten für Standarddienste war Autopilot auf einer kleinen Anzahl von Geräten getestet worden und nie darüber hinaus ausgeweitet worden – ein typischer Fall, in dem Pilotprojekte ins Stocken geraten, sobald sich das ursprüngliche Projektteam anderen Prioritäten zuwendet. Keine dieser Mängel ist auf Copilot zurückzuführen. Im Gegenteil: Jeder einzelne wird umso bedeutender, je besser Copilot in der Lage ist, Mandantendaten von jedem Gerät zusammenzufassen, das sich authentifizieren kann.

Um diesen Grundpfeiler zu stärken, sollten Compliance-Richtlinien für den gesamten Mandanten gelten und direkt mit dem bedingten Zugriff verknüpft sein, sodass nicht konforme Geräte blockiert und nicht nur gekennzeichnet werden. Dies sollte mit Regeln zur Gerätebereinigung kombiniert werden, die inaktive Geräte nach 30 bis 90 Tagen automatisch löschen, sowie mit einer abgeschlossenen Autopilot-Einführung für eine standardisierte Bereitstellung und MAM-Richtlinien, die speziell auf die jeweilige BYOD-Nutzergruppe zugeschnitten sind.

Säule 5: Kontrollmechanismen für die Zusammenarbeit (Teams, SharePoint, Exchange)

An dieser Säule führt Copilot seine täglichen Abrufvorgänge durch. Das System liest E-Mails aus Exchange, Unterhaltungen in Teams und Inhalte aus Besprechungen sowie Dokumente aus SharePoint und OneDrive aus, sodass die Governance über diese drei Plattformen hinweg als letzte Sicherheitsmaßnahme gegen unbeabsichtigtes Überteilen von Informationen dient.

Bei Exchange stellt TrustedTech immer wieder Weiterleitungsregeln fest, die noch nie überprüft wurden, eine DNS-Authentifizierung (SPF, DKIM, DMARC), die nicht vollständig verifiziert wurde, sowie eine DLP-Abdeckung, die den E-Mail-Verkehr nicht vollständig abdeckt. Der Mandant aus dem Rohstoffsektor wies all dies auf, zusammen mit einigen veralteten E-Mail-Flusskonfigurationen, die von einer früheren Migration übrig geblieben waren und die niemand entfernt hatte. Da Copilot E-Mail-Inhalte auf Anfrage zusammenfassen und anzeigen kann, stellt eine nicht überprüfte Weiterleitungsregel nicht mehr nur ein Phishing-Risiko dar; sie ist zu einem Mittel geworden, durch das zusammengefasste sensible Inhalte automatisch das Unternehmen verlassen können.

In Teams werden die Richtlinien für Besprechungen und Nachrichten in der Regel auf den Standardwerten belassen, anstatt sie an die Anforderungen des Unternehmens anzupassen. Das bedeutet, dass die Einstellungen für Transkription und Aufbewahrung den von Microsoft vorgegebenen Werten entsprechen und nicht das Ergebnis einer bewussten Entscheidung sind. Da Copilot direkt auf den Unterhaltungen und Besprechungsinhalten in Teams basiert, ist es sinnvoll, sich mit diesem Thema auch in Unternehmen auseinanderzusetzen, die ihre Teams-Governance als vollständig betrachten.

Die Modelle für die Website-Inhaberschaft und die Einstellungen für die externe Freigabe in SharePoint sind in der Regel am weitesten ausgereift – jedoch selten vollständig sicher. Der Großteil der verbleibenden Sicherheitslücke lässt sich schließen, indem ein System für Website-Inhaber und -Verwalter formalisiert, standardisierte Governance-Verfahren in allen Geschäftsbereichen eingeführt und Vertraulichkeitskennzeichnungen auf der Ebene der Dokumentbibliotheken angewendet werden.

Die stufenweise Roadmap zur Copilot-Bereitschaft

TrustedTech gliedert die Maßnahmen in vier Phasen, anstatt alle fünf Säulen parallel anzugehen, da Identitäts- und Daten-Governance Voraussetzungen für alle nachfolgenden Schritte sind:

  1. Phase 1: Identität und Zugriff (Entra). Durchsetzung der Multi-Faktor-Authentifizierung, Vereinfachung und Neugestaltung des bedingten Zugriffs, Sperrung veralteter Authentifizierungsmethoden und Umsetzung des Prinzips der geringstmöglichen Berechtigungen.
  2. Phase 2: Daten-Governance (Geltungsbereich). Sensitivitätskennzeichnungen implementieren, DLP aktiv durchsetzen, Aufbewahrungsrichtlinien konfigurieren und Kontrollmaßnahmen gegen Insiderrisiken einführen.
  3. Phase 3: Endpunktsicherheit (Intune). Stellen Sie die Gerätekonformität sicher, nutzen Sie Autopilot zur Standardisierung der Bereitstellung und schützen Sie Daten sowohl auf verwalteten als auch auf nicht verwalteten Geräten.
  4. Phase 4: Pilotprogramm. Führen Sie ein kontrolliertes Copilot-Pilotprojekt mit einer bestimmten Nutzergruppe durch, um sicherzustellen, dass Sicherheit, Datenzugriff und Akzeptanz wie erwartet funktionieren, bevor Copilot mandantenweit eingeführt wird.

In der Realität sind es gerade die Organisationen, die direkt zu Phase 4 übergehen, die einige Monate später wieder bei Phase 1 landen – diesmal jedoch, um auf Vorfälle zu reagieren, anstatt geplante Korrekturmaßnahmen durchzuführen. Die Phasen sind in dieser Reihenfolge angeordnet, weil Copilot eine Governance-Lücke nicht beseitigen kann; es kann lediglich dazu beitragen, dass diese Lücke für die erste Person leichter zu erkennen ist.

Häufig gestellte Fragen

Frage Bringt der Einsatz von Copilot neue Sicherheitsrisiken mit sich oder deckt er lediglich bereits bestehende auf?

A. Copilot an sich bringt keine neuen Risikoarten mit sich. Vielmehr beschleunigt es den Zugriff auf Risiken, die durch eine Identitäts-, Geräte- oder Freigabelücke ohnehin bereits bestanden hätten. Aus diesem Grund gewinnt die Reife der Identitäts- und Daten-Governance nach der Einführung von Copilot an Bedeutung – mehr noch als zuvor.

Frage: Sind Microsoft E5-Lizenzen erforderlich, um diese Lücken zu schließen?

A. Kontrollmechanismen wie die risikobasierte Anmeldung und PIM sind P2-Funktionen, die mit höheren Lizenzstufen verbunden sind. Obwohl viele der wichtigsten Korrekturen, wie beispielsweise die Durchsetzung der MFA, die Aktivierung von DLP und Richtlinien zur Gerätekonformität, bereits in niedrigeren Lizenzstufen verfügbar sind, bleiben sie oft deaktiviert, anstatt dass keine Lizenz dafür vorliegt.

Frage Wie lange dauert eine Copilot-Eignungsprüfung in der Regel?

A. Die „Copilot Readiness Assessment“-Prüfung von TrustedTech umfasst in der Regel ein oder zwei kurze Erstgespräche sowie eine technische Analyse der Konfiguration des Mandanten. Anschließend wird ein schriftlicher Bericht erstellt und die Ergebnisse werden besprochen.

Frage Sollten wir Copilot nutzen, bevor wir alle fünf Säulen abgeschlossen haben?

A. Ein Pilotprojekt mit einer kleinen, klar definierten Nutzergruppe kann parallel zu den Maßnahmen in späteren Phasen durchgeführt werden, allerdings sollten die Identitäts- und Datenverwaltung (Phasen 1 und 2) zuvor weitgehend abgeschlossen sein. Ein Pilotprojekt in einer nicht regulierten Datenumgebung zeigt Ihnen in erster Linie, was Copilot erkennen kann, nicht jedoch, wie es funktioniert.

Frage Welche Rolle spielt der Secure Score bei dieser Bewertung?

A. Der Secure Score kann als guter erster Indikator für den Reifegrad von Entra und Defender dienen, ist jedoch kein umfassender Maßstab für die Einsatzbereitschaft. Da Lücken bei Purview, Intune und der Governance im Bereich der Zusammenarbeit im Secure Score nicht berücksichtigt werden, werden bei einer Copilot-spezifischen Bewertung alle fünf Säulen berücksichtigt, anstatt sich ausschließlich auf den Secure Score zu stützen.

Wo soll man anfangen?

Die meisten Unternehmen müssen nicht erst herausfinden, welche der fünf Säulen die schwächste ist. Eine Copilot-Bereitschaftsprüfung untersucht alle fünf Säulen im Zusammenhang mit Ihrer spezifischen Mandantenkonfiguration und liefert einen Schritt-für-Schritt-Plan anstelle einer Standard-Checkliste. Wenn die Unternehmensleitung bereits Fragen zum Return on Investment oder zum Zeitplan für Copilot stellt, ist diese Prüfung der schnellste Weg, ihr eine Antwort zu geben, die auf den Daten Ihres eigenen Mandanten basiert und nicht auf einem Branchendurchschnitt.

Dieser Bericht wurde vom Team für Cloud-Lösungsarchitektur von TrustedTech erstellt.