Schatten-IT aufdecken: Cloud Application Visibility der XGS und Defender for Cloud Apps im Duett

Schatten-IT erkennen mit der Firewall, Cloud-Discovery mit Defender for Cloud Apps — hinter beiden Suchen steckt dieselbe Ahnung der IT-Leitung: Da draußen läuft mehr, als wir wissen. Die Kurzantwort vorab: Die Ahnung stimmt fast immer, und zwar um den Faktor fünf bis zehn — aber die gute Nachricht ist, dass beide Werkzeuge für die Sichtbarkeit längst im Haus oder in Reichweite sind. Die Sophos XGS zeigt aus dem Netzverkehr, welche Cloud-Dienste tatsächlich genutzt werden — sofort, ohne Zusatzlizenz, für jedes Gerät hinter der Firewall. Defender for Cloud Apps ergänzt den Katalog-Verstand: Risiko-Bewertungen für zehntausende Dienste, Sicht auf verwaltete Geräte auch außerhalb des Firmennetzes, und Governance-Werkzeuge für den Umgang mit den Funden. Dieser Artikel zeigt beide Wege, ihr Zusammenspiel — und was nach dem Fund kommt: Denn 400 entdeckte Dienste sind noch kein Ergebnis; das Ergebnis ist der bewertete Katalog mit drei Töpfen — dulden, ersetzen, blocken — und eine Kommunikation, die Bedarf einlädt statt Nutzer zu jagen.

Warum Schatten-IT ein Compliance-Thema ist, kein Kavaliersdelikt

Zuerst die Einordnung, denn am Anfang vieler Projekte steht ein Missverständnis in zwei Richtungen. Richtung eins unterschätzt das Problem: »Sollen die Kollegen doch ihre Tools nutzen« — aber jeder unbekannte Cloud-Dienst ist eine unbewertete Datenverarbeitung: Firmendaten liegen bei einem Anbieter ohne Auftragsverarbeitungsvertrag, ohne Eintrag im Verarbeitungsverzeichnis, ohne Prüfung von Datenhaltung und Sicherheit — im Auditfall und beim Datenvorfall ist jeder dieser Dienste eine offene Flanke, und unter NIS2 sind unbekannte Dienste schlicht unbewertete Lieferanten ([LINK: C1]-Lieferketten-Logik). Dazu die stillen Folgen: Zugänge, die Austritte überleben; Lizenz- und Vertragsrisiken; und die Abfluss-Wege aus [LINK: C5]. Richtung zwei überschätzt die Bosheit: Schatten-IT ist fast nie Sabotage, sondern fast immer ungedeckter Bedarf — das Projekt-Board, das die IT nicht anbietet, der Großdatei-Versand, der offiziell nicht existiert. Diese zweite Einsicht entscheidet über den Projekterfolg: Die Funde sind keine Täterliste, sondern eine Bedarfsanalyse mit Compliance-Beifang — und genau so gehören sie behandelt. Was der erste Blick typischerweise zutage fördert, beziffert der Faktenkasten.

Sichtbarkeit per XGS: Cloud Application Visibility nutzen

Der schnellste Einstieg liegt auf der Firewall, und er kostet exakt nichts: Die XGS klassifiziert den durchlaufenden Verkehr ohnehin nach Anwendungen und Cloud-Diensten — die Cloud-Applications-Sicht macht daraus den Bericht: welche Dienste genutzt werden, mit welchem Datenvolumen, von wie vielen Benutzern, mit welchem Verlauf. Die Stärken dieser Netzwerksicht: Sie erfasst jeden, der durch die Firewall geht — verwaltete wie unverwaltete Geräte; sie ist sofort verfügbar; und sie ist handlungsnah — aus dem Bericht heraus lässt sich ein Dienst direkt einstufen oder per App-Control-Regel blockieren. Die ehrlichen Grenzen: Die XGS kennt die Dienste, aber nicht deren Risikoprofil — ob der entdeckte Anbieter DSGVO-tauglich ist, wo er Daten hält, ob er MFA kann, steht in keinem Firewall-Bericht; und sie sieht nur, was durch sie fließt — das Notebook im Homeoffice ohne VPN und das Mobilfunk-Tethering bleiben unsichtbar. Für beide Lücken gibt es Antworten: die erste liefert der Katalog des nächsten Kapitels, die zweite der Hinweis-Kasten.

Sichtbarkeit per Defender for Cloud Apps: Discovery und Risiko-Scores

Die Microsoft-Seite bringt das mit, was der Firewall fehlt: Wissen über die Dienste selbst. Das Herzstück von Defender for Cloud Apps ist der Cloud-App-Katalog — zehntausende Dienste, jeder mit einem Risiko-Profil aus Dutzenden Attributen: Wo hält der Anbieter Daten, welche Zertifizierungen (ISO, SOC), wie steht es um DSGVO-Aussagen, unterstützt der Dienst MFA und SSO, wem gehört er. Die Discovery speist sich aus zwei Quellen: dem Defender-Endpoint-Sensor, der die Cloud-Nutzung verwalteter Geräte meldet — bemerkenswert: auch außerhalb des Firmennetzes, im Homeoffice, im Zug —, und dem Log-Upload von Firewalls, womit die Netzwerksicht der XGS in den Katalog einfließt (dazu gleich mehr im Zusammenspiel-Kapitel). Auf die Sichtbarkeit setzt die Governance: Dienste lassen sich sanktionieren oder sperren, Richtlinien alarmieren bei neuen Apps oder Schwellwerten, und nicht sanktionierte Dienste blockt der Endpoint-Sensor direkt auf den verwalteten Geräten — die Durchsetzung reist mit dem Gerät. Die Grenzen spiegelbildlich zur XGS: Gesehen werden nur verwaltete, onboardete Geräte — Gastnetz, IoT und Unverwaltetes bleiben dunkel. Und die Eintrittskarte regelt der Faktenkasten — denn anders als der Firewall-Bericht ist dieser Katalog eine Lizenzfrage.

Beide Quellen zusammenführen

Jetzt das Duett, das die Skizze zeigt — denn die beiden Sichten ergänzen sich präzise an ihren blinden Flecken: Die XGS sieht die Breite im Haus (alle Geräte, auch unverwaltete), aber ohne Katalogwissen und ohne Außer-Haus-Sicht; Defender for Cloud Apps sieht verwaltete Geräte überall und kennt jedes Risikoprofil, aber Gastnetz und Unverwaltetes bleiben dunkel. Die Zusammenführung hat zwei Stufen. Stufe eins, sofort machbar: beide Berichte in einen gemeinsamen App-Katalog überführen — je Dienst Quelle(n), Nutzerzahl, Volumen, Risikoeinschätzung und Status; eine schlichte Tabelle, die zum zentralen Arbeitsdokument wird. Stufe zwei, technisch und eleganter: die Firewall-Logs in die Defender-Discovery einspeisen — per Protokoll-Upload für Momentaufnahmen oder über einen Log-Collector kontinuierlich; damit bekommt der komplette Netzverkehr der XGS die Katalog-Anreicherung, und jede im Haus gesehene App trägt automatisch ihr Risikoprofil. Der Werkzeugvergleich in der Tabelle fasst die Arbeitsteilung zusammen — und für die Frage, wohin die Alerts beider Welten laufen, gilt die Cluster-Antwort: ins gemeinsame Lagebild nach [LINK: B8]-Muster.

Skizze 1: Netzbreite von der XGS, Katalogwissen und Außer-Haus-Sicht von Defender for Cloud Apps — und der Log-Upload als Brücke zwischen beiden.

Vom Fund zur Entscheidung: dulden, ersetzen, blocken

Mit der Fundliste beginnt die eigentliche Arbeit, und der Entscheidungsfluss in der Skizze gibt ihr die Form: Jede relevante App durchläuft drei Fragen. Frage eins filtert das hohe Risiko — Anonymisierer, riskante Filesharer, Dienste, über die sensible Daten ohne vertragliche Grundlage laufen: Sie werden geblockt, netzseitig per XGS-Regel und geräteseitig über die Nicht-sanktioniert-Sperre, stets mit Information an die Betroffenen. Frage zwei erkennt den Bedarf — Dienste, die ein echtes Arbeitsproblem lösen (Großdatei-Versand, Projekt-Boards, KI-Werkzeuge): Sie werden ersetzt — sanktionierte Alternative bereitstellen, kommunizieren, dann erst sperren; die C5-Regel »nie ohne Alternative blocken« gilt hier wörtlich. Frage drei prüft die Legitimität des Rests — das etablierte Fachbereichs-SaaS mit sauberem Profil wird sanktioniert, aber richtig: Auftragsverarbeitungsvertrag nachziehen, Verarbeitungsverzeichnis ergänzen, einen Verantwortlichen im Fachbereich benennen, wo möglich per SSO und MFA an Entra anbinden — und ab in den offiziellen Katalog. Die Maßnahmen-Tabelle übersetzt die drei Töpfe in konkrete Schritte; die Praxis-Geschichte zeigt, wie sich das in echt anfühlt.

Skizze 2: Drei Fragen, drei Töpfe — blocken mit Information, ersetzen mit Alternative, sanktionieren mit Papierkram. Das Ergebnis ist der bewertete Katalog.

Kommunikation statt Verbotskultur

Der letzte Baustein entscheidet über die Nachhaltigkeit, und er ist keine Technik: Wie das Haus über die Funde spricht, bestimmt, ob die nächste Discovery-Runde noch etwas findet — oder ob die Nutzung nur unsichtbarer geworden ist. Die Grundhaltung: Funde sind Bedarfsmeldungen. Wer die Fachbereiche einlädt (»Was davon braucht ihr wirklich, was fehlt euch an unserem Angebot?«), bekommt ehrliche Antworten — und die Anforderungsliste, die nie jemand geschrieben hat. Dazu gehören vier Bausteine: ein veröffentlichter App-Katalog, der zeigt, was freigegeben ist und wofür; ein Antragsweg, der in Tagen statt Monaten antwortet — wenn die offizielle Freigabe ein halbes Jahr dauert, gewinnt immer der Schatten; eine Übergangs-Amnestie, in der gemeldete Dienste ohne Vorwurf in den Entscheidungsfluss wandern; und der Quartals-Kreislauf aus der Skizze, der das Thema vom Einmal-Projekt zum Rhythmus macht — mit sinkendem Aufwand, weil nur noch Neues und Verändertes bewertet wird. Und über allem die Beteiligungsfrage, die die Warnung ausführt: Discovery wertet Nutzung aus — der [LINK: C3]-Rahmen gilt.

Skizze 3: Erfassen, bewerten, entscheiden, kommunizieren — im Quartals-Takt. Der Erstlauf ist ein Sprint, danach kostet die Runde einen Tag.

FAQ — häufige Fragen zur Schatten-IT-Discovery

Wie erkenne ich, welche Cloud-Dienste meine Mitarbeiter nutzen?

Mit zwei Quellen, deren erste sofort verfügbar ist: Der Cloud-Applications-Bericht der Sophos XGS zeigt aus dem laufenden Netzverkehr, welche Dienste mit welchem Volumen und von wie vielen Benutzern genutzt werden — ohne Zusatzlizenz, ohne Projekt, der Blick kostet zehn Minuten und ist die beste erste Bestandsaufnahme. Die zweite Quelle ist die Discovery von Defender for Cloud Apps: Der Endpoint-Sensor verwalteter Geräte meldet die Cloud-Nutzung von überall (auch Homeoffice und Mobilfunk), und der Katalog reichert jeden Fund mit einem Risikoprofil an — Datenhaltung, Zertifikate, MFA-Fähigkeit; per Log-Upload lässt sich zusätzlich die komplette Firewall-Sicht einspeisen und anreichern. Die pragmatische Reihenfolge: erst der XGS-Bericht (heute), dann bei Lizenz der Katalog dazu — beides zusammen im gemeinsamen App-Katalog als Arbeitsdokument. Zwei Randnotizen: Für die reine Erkennung braucht es keine TLS-Inspection, und vor dem ersten Lauf gehören Betriebsrat und DSB informiert — Discovery ist Nutzungsauswertung und startet sauber aggregiert statt personenbezogen.

Was ist der Unterschied zwischen XGS-Visibility und Defender for Cloud Apps?

Blickwinkel und Wissen — die Kurzformel: Die XGS sieht breit, Defender weiß viel. Die Firewall-Sicht erfasst jeden Verkehr, der sie passiert — verwaltete wie unverwaltete Geräte, Gäste, IoT —, liefert Volumen, Nutzerzahlen und Verlauf, und sie ist handlungsnah: Aus dem Bericht heraus ist der Block eine Regel entfernt. Aber sie weiß nichts über die Dienste selbst (kein Risikoprofil) und sieht nichts außerhalb des Hauses (Homeoffice ohne VPN, Mobilfunk). Defender for Cloud Apps ist das Spiegelbild: Der Katalog bewertet zehntausende Dienste nach Compliance- und Sicherheitsattributen, der Endpoint-Sensor sieht verwaltete Geräte überall, und die Governance reicht von der Einstufung über Alerts bis zur Gerätesperre — aber unverwaltete Geräte und das Gastnetz bleiben dunkel, und die Eintrittskarte ist eine Lizenzfrage (E5 beziehungsweise E5 Security). Die Konsequenz ist keine Entweder-oder-Wahl, sondern Arbeitsteilung: XGS für Breite im Haus und Netz-Durchsetzung, Defender für Bewertung, Fernsicht und Geräte-Durchsetzung — verbunden über den Log-Upload. Wer nur eines hat, arbeitet trotzdem sinnvoll — er sollte nur seinen toten Winkel kennen und benennen.

Brauche ich dafür TLS-Inspection?

Für die Discovery selbst: nein — und diese Antwort überrascht viele. Die Erkennung, welcher Cloud-Dienst genutzt wird, funktioniert auch im verschlüsselten Verkehr: Die Ziel-Domain ist beim Verbindungsaufbau sichtbar, und die App-Signaturen erkennen Dienste an ihren Verkehrsmustern — für die Frage »Was läuft hier?« reicht das in aller Regel aus, und der erste Discovery-Lauf kann heute starten, unabhängig vom Inspection-Stand. Wo die Inspection ins Spiel kommt: bei der Erkennungsschärfe verschachtelter Dienste — und vor allem bei der Durchsetzungs-Feinarbeit aus dem C5-Artikel: Upload-Blocking nach Dateityp, Warnseiten und präzise App-Steuerung profitieren deutlich von der Entschlüsselung. Wer vom Sehen zum gezielten Eingreifen übergeht, landet also mittelfristig beim Inspection-Thema — mit dem Pflichtprogramm aus A7-Ausnahmen und C3-Schranken. Die Reihenfolge deshalb: Discovery heute ohne Inspection starten, Entscheidungsfluss durchlaufen — die Inspection folgt als eigener Feinmechanik-Schritt.

Darf ich entdeckte Dienste einfach blocken?

Technisch ja, in Minuten — klug ist es nur in einem der drei Töpfe. Für die Hochrisiko-Klasse (Anonymisierer, riskante Filesharer, klare Verstöße gegen bestehende Regeln) ist der schnelle Block richtig und geboten: XGS-Regel, Geräte-Sperre, kurze Information an die Betroffenen mit Begründung und Ansprechpartner — fertig. Für alles andere gilt die Bremse aus zwei Gründen. Grund eins ist praktisch: Ein Dienst mit zwanzig aktiven Nutzern löst ein reales Arbeitsproblem — wer ihn kommentarlos sperrt, sperrt einen Arbeitsablauf und treibt die Nutzung in unsichtbare Kanäle, wo keine Discovery mehr hinreicht; die C5-Regel »nie ohne Alternative blocken« ist hier Wirksamkeitsbedingung, keine Freundlichkeit. Grund zwei ist rechtlich: Pauschale Sperren sind unkritisch, aber sobald die Entscheidung auf benutzerbezogener Nutzungsauswertung beruht oder mit Einzelansprache verbunden wird, ist das Mitbestimmungs-Terrain — der C3-Rahmen mit aggregierter Standard-Auswertung und Anlass-Prozess gehört vor den ersten Block, nicht nach die erste Beschwerde. Die saubere Antwort auf die Frage lautet also: Blocken ja — aber durch den Entscheidungsfluss: Hochrisiko sofort mit Information, Bedarfs-Dienste erst nach der Alternative, und der legitime Rest wird gar nicht geblockt, sondern ordentlich sanktioniert.

Wie gehe ich mit berechtigten Fachbereichs-Tools um?

Mit dem dritten Topf des Entscheidungsflusses — sanktionieren, aber richtig — und mit einer Haltungsänderung: Das entdeckte Fachbereichs-SaaS ist kein Regelverstoß, sondern eine ungefragte, aber oft vernünftige Beschaffungsentscheidung, der nur der Compliance-Unterbau fehlt. Der Nachzieh-Katalog: erstens der Auftragsverarbeitungsvertrag mit dem Anbieter — bei etablierten Diensten meist ein Standarddokument, das nur nie jemand angefordert hat; zweitens der Eintrag ins Verarbeitungsverzeichnis samt kurzer Risikoeinschätzung (Datenkategorien, Datenhaltung, Empfänger); drittens ein benannter Verantwortlicher im Fachbereich — der Dienst gehört dem Team, das ihn nutzt, inklusive Nutzerpflege und Budget, die IT liefert Anbindung und Rahmen; viertens die technische Einbettung: SSO über Entra und MFA, wo der Dienst es kann — damit greifen Conditional Access und Offboarding auch hier; fünftens die Aufnahme in den offiziellen Katalog, damit das nächste Team nicht denselben Dienst noch einmal einführt. Und ein ehrlicher Zusatz: Manchmal endet die Prüfung negativ — Datenhaltung untragbar, AVV verweigert; dann wandert der Dienst trotz Bedarfs in Topf zwei: Alternative suchen, migrieren, ablösen. Auch das schlägt den Dauerzustand »genutzt, aber ungeregelt«.

Ist Schatten-IT-Discovery mitbestimmungspflichtig?

Nach denselben Maßstäben wie die übrige Firewall- und Auswertungstechnik: Die Discovery-Werkzeuge erfassen, welche Dienste von welchen Geräten und — je nach Auswertung — welchen Benutzern genutzt werden; damit sind sie objektiv zur Verhaltenskontrolle geeignet, und genau darauf stellt die Rechtsprechung zum Mitbestimmungsrecht ab (die Grundsätze samt BAG-Linie stehen im C3-Artikel). Praktisch heißt das nicht Stillstand, sondern Reihenfolge: Betriebsrat und DSB vor dem ersten Lauf einbinden — mit dem ehrlichen Zwei-Quellen-Bild und dem erklärten Zweck (Bestandsaufnahme und Bedarfsanalyse, keine Leistungskontrolle); die aggregierte, app-bezogene Auswertung als Standard vereinbaren — »Dienst X, 23 Nutzer, 40 GB« genügt für jede Entscheidung, Namen braucht der Alltag nicht; Benutzerbezogenes ausschließlich über den Anlass-Prozess mit den C2/C3-Beteiligungen; und die Discovery gleich in die Firewall-Betriebsvereinbarung aufnehmen — sie ist ein Anwendungsfall derselben Systematik, kein neues Fass. Die Erfahrung dazu ist ermutigend: Ein Betriebsrat, dem Discovery als das präsentiert wird, was es gut gemacht ist — Schutz vor unbewerteten Datenabflüssen plus Bedarfsanalyse für bessere Werkzeuge —, trägt das Vorhaben fast immer mit; das Misstrauen entsteht wie üblich nicht an der Technik, sondern am Vorgehen.

Fazit: Sichtbarkeit ist der Anfang — der Katalog ist das Ergebnis

Die Ausgangsahnung bestätigt sich fast immer: Es läuft mehr, als die IT weiß, typischerweise um den Faktor fünf bis zehn. Aber die Antwort darauf ist weder Panik noch Verbotswelle, sondern ein geordneter Weg mit vorhandenen Mitteln: der XGS-Bericht als sofortiger, kostenloser Einstieg in die Breite; Defender for Cloud Apps als Katalog-Verstand und Fernsicht, sobald die Lizenz da ist; der Log-Upload als Brücke, die beide Sichten vereint; der Entscheidungsfluss, der aus 400 Funden drei saubere Töpfe macht — blocken mit Information, ersetzen mit Alternative, sanktionieren mit Papierkram; und der Quartals-Kreislauf mit einer Kommunikation, die Bedarf einlädt statt Nutzer zu jagen, flankiert von Betriebsrat und DSB nach dem C3-Fahrplan. Wer so vorgeht, bekommt mehr als Compliance: einen gepflegten Katalog für den nächsten Lieferketten-Fragebogen, eine ehrliche Bedarfsanalyse fürs eigene IT-Angebot — und eine Belegschaft, die neue Tools anmeldet, weil der offizielle Weg der schnellere geworden ist. Das ist der eigentliche Sieg: nicht, dass Schatten-IT verboten wäre — sondern dass sie sich nicht mehr lohnt.

Von hier aus weiter im Cluster: Das Gesamtbild der XGS in Microsoft-Umgebungen zeichnet der Pillar-Artikel [LINK: Pillar]. Wie aus der Sichtbarkeit die Abfluss-Kontrolle wird — Kontrollpunkte, Richtlinien-Kaskade, Stufenplan — steht in [LINK: C5]. Den Mitbestimmungs- und Auswertungsrahmen für alles, was hier gemessen wird, liefert [LINK: C3]. Und die Endpoint-Strategiefrage, an der die Defender-Sensor-Quelle hängt, klärt [LINK: B13].