Argumente für „Local Zero Trust“

Von Sarang Warudkar – Leitender technischer PMM

13. November 2026 5 Minuten Lesezeit

Die KI wurde in Ihr Netzwerk integriert. Ihre SSE hingegen nicht.

Zero Trust erlebte seinen eigentlichen Durchbruch, als Mitarbeiter ins Homeoffice wechselten und Anwendungen in die Cloud verlagert wurden. Cloud Access Security Brokers (CASB) und später die breiter gefassten Märkte für „ Security Service Edge “ (SSE) und „Secure Access Service Edge“ (SASE) wuchsen rasch, da sie eine Antwort auf das damalige Risiko boten: dass ein Angreifer mit gestohlenen Anmeldedaten von überall aus auf die Cloud-Ressourcen eines Unternehmens zugreifen könnte. Zero Trust Network Access (ZTNA) entstand auf ähnliche Weise, als SSE-Anbieter ihre Cloud-Plattformen erweiterten, um eine kostengünstigere und stabilere Alternative zum VPN anzubieten. Das Prinzip war richtig und ist es nach wie vor: Die Überprüfung des Benutzers, des Geräts, des Standorts und des umgebenden Kontexts anstelle des blinden Vertrauens in eine Anmeldeinformation allein.

Was sich geändert hat, ist nicht das Prinzip. Es ist der Ort, an dem die Arbeit stattfindet.

Warum die Arbeit wieder ins Haus zurückkam

Vier Veränderungen haben dazu geführt, dass ein zunehmender Anteil der Unternehmensaktivitäten wieder in private Netzwerke verlagert wurde.

1. Die Mitarbeiter kehrten ins Büro zurück. Laut einer Gallup-Umfrage vom Mai 2026 arbeiten 74 % der Beschäftigten im Büro oder im Hybridmodell, davon 22 % in Vollzeit vor Ort und 52 % im Hybridmodell mit 2,3 Tagen pro Woche. Mehr Unternehmenssitzungen beginnen und enden nun im selben Unternehmensnetzwerk als jemals zuvor seit 2019.
2. KI hat den Weg in die Unternehmensinfrastruktur gefunden. KI hat Einzug in die Unternehmensinfrastruktur gehalten, da steigende Token-Kosten, Kontrollprobleme und Bedenken hinsichtlich des Datenschutzes dazu führen, dass Arbeitslasten wieder intern abgewickelt werden. Wenn ein KI-Modell anhand interner Daten trainiert wird – beispielsweise aus den Bereichen Forschung und Entwicklung, Preisgestaltung und Kundendaten –, nimmt es das zentrale geistige Eigentum des Unternehmens auf und wird damit praktisch zu einer funktionierenden Kopie seiner Geschäftsgeheimnisse. Da Vorstände nicht bereit sind, diese Vermögenswerte auf Servern von Drittanbietern zu belassen, ist der Betrieb privater Modelle und interner KI-Tools in eigenen Rechenzentren mittlerweile gängige Praxis.
3. Ein Großteil der von diesen Systemen durchgeführten Aktionen verlässt den Perimeter nie. Gartner gibt an, dass in jeder sechsten KI-Anfrage proprietäre Daten enthalten sind (Cybersicherheitsbedrohung: Kompromittierung von KI-Anwendungen, 2026), und dieses Verhältnis verbessert sich in keiner Weise, wenn das Modell intern statt öffentlich eingesetzt wird. Ein interner Copilot hat nichts, was er abziehen könnte. Er greift auf den Dokumentenspeicher, das Ticketingsystem und die Kundendatenbank zu, denn genau dafür wurde er entwickelt. Ein Agent, dem eine Aufgabe übertragen wurde, verfügt über dauerhafte Zugangsdaten und agiert weitaus schneller als die Person, die ihn autorisiert hat – und zwar gegenüber Systemen in seinem eigenen Netzwerksegment.
4. Auch das Arbeitsmodell kehrt im Zuge der Souveränität zurück. Gartner geht davon aus, dass bis 2028 50 % der multinationalen Unternehmen und mehr als 75 % der nicht-US-amerikanischen multinationalen Unternehmen Anforderungen an die digitale Souveränität stellen werden (Prognoseanalyse: Souveräne Cloud-IaaS, weltweit, 2025). Ein Unternehmen, das ein Modell eigens ins eigene Haus geholt hat, um regulierte Daten unter seiner eigenen Zuständigkeit zu halten, hat berechtigte Bedenken gegenüber jeder Architektur, die die Interaktion an einen anderen Ort weiterleitet, um sie dort zu überprüfen.

Wo die cloudbasierte Durchsetzung an ihre Grenzen stößt

Die Integration von Zero-Trust-Zugriffskontrollen in einen cloudbasierten Dienst ist absolut sinnvoll, wenn sich der Nutzer an einem entfernten Standort befindet oder die Anwendung in der Cloud gehostet wird. Sie ist hingegen deutlich weniger sinnvoll, sobald sich beide Endpunkte im selben Gebäude befinden.

Eine Sitzung innerhalb des Unternehmens – also Datenverkehr, der mit Maschinen-Geschwindigkeit fließt – zur Überprüfung und Durchsetzung an einen Cloud-Standort weiterzuleiten, nur um ihn anschließend direkt zurück an eine private Anwendung oder Datenquelle zwei Stockwerke weiter zu senden, ist aus architektonischer Sicht nicht tragfähig. Dies verursacht Latenz, beansprucht WAN-Kapazität und schafft eine Abhängigkeit von der Internetverbindung für Arbeitsprozesse, die den Standort gar nicht hätten verlassen müssen. Die Verfügbarkeit wird zu einer Sicherheitsentscheidung, was selten im Sinne der Beteiligten ist.

Cloud-ZTNA weist eine zweite, weniger offensichtliche Schwachstelle auf. In der Regel gewährt es einen Zero-Trust-Zugang zum Netzwerk und nicht zu der einzelnen Anwendung, die der Benutzer tatsächlich benötigt. Die Sitzung verfügt vom Moment ihrer Zulassung an über übermäßige Berechtigungen, und die laterale Bewegung innerhalb dieses Segments erfolgt ungehindert. Eine Kontrollmaßnahme, die eingeführt wurde, um implizites Vertrauen zu beseitigen, führt letztendlich dazu, dass dieses eine Ebene tiefer wieder eingeführt wird.

Für das Netzwerkteam ist all dies kein Neuland. Die Segmentierung und die Transparenz des Ost-West-Datenverkehrs sind seit Jahren ein Ziel, doch die Umsetzung eines lokalen Zero-Trust-Ansatzes ohne Beeinträchtigung des Nutzerverhaltens und ohne Erhöhung des Risikos stellte bislang eine Herausforderung dar. Leider waren SSE-Funktionen der nächsten Generation – wie Zugriff auf Anwendungsebene, Web- und TLS-Prüfung sowie datenorientierte Kontrollen – zum Schutz interner Netzwerke oft nicht verfügbar. Diese Lücke ist eher architektonischer als konzeptioneller Natur, weshalb ihre Schließung auch eher eine technische Aufgabe als eine neue Doktrin darstellt.

Da Datenworkflows mittlerweile mit Maschinen-Geschwindigkeit über lokale Netzwerke laufen, sind lokale Zugriffskontrollen auf Anwendungsebene und lokale Inline-Prüfungen kein Wunsch mehr, sondern eine Anforderung an hybride Systemkonzepte. Sie schützen kritische Daten dort, wo diese tatsächlich gespeichert sind und fließen, und gewährleisten den Geschäftsbetrieb auch dann, wenn der Weg in die Cloud unterbrochen ist.

Was die Verlagerung der Strafverfolgung in die Nähe tatsächlich bewirkt

Die Ausbreitung lokaler Daten wird sichtbar. Interne KI-Tools werden ohne Beschaffungsnachweis eingeführt und entwickeln sich zu geschäftskritischen Komponenten, noch bevor jemand sie inventarisiert. Kopien von reguliertem Material sammeln sich in Vektorspeichern, Feinabstimmungsdatensätzen und gemeinsam genutzten Laufwerken an, die von keiner Cloud-basierten Kontrollinstanz erfasst werden, da in diesem Arbeitsablauf keine Datengrenzen überschritten werden. Nur durch eine Überprüfung der lokalen Infrastruktur und der Arbeitsabläufe lassen sich solche Daten aufspüren.

Der Zugriff wird vom Netzwerk auf die Anwendung hin eingeschränkt. Die anwendungsspezifische Autorisierung am lokalen Kontrollpunkt beseitigt die übermäßigen Berechtigungen, die durch die Vermittlung auf Netzwerkebene entstehen, und zwar für den Benutzer im Büro, der derzeit der am wenigsten überwachte Benutzer im gesamten Netzwerk ist.

KI-spezifische Einblendungen lassen sich gezielt ansprechen. Prompt-Injektionen, Jailbreak-Versuche und proprietäres Material, das unbemerkt in einen Prompt eingefügt oder eingegeben wird, können nur von einer Komponente abgefangen werden, die sich auf Browser-Ebene im Verlauf der Interaktion befindet. Wenn diese Interaktion die Website nie verlässt und sich auf der Website nichts in ihrem Verlauf befindet, können die Kontrollmechanismen nicht greifen. Erst durch die Einbeziehung des lokalen Datenverkehrs wird KI-Sicherheit praktikabel – unabhängig davon, wo die Kontrollmechanismen letztendlich ausgeführt werden.

Die Ausfallsicherheit verbessert sich, anstatt sich zu verschlechtern. Ein Standort, der die Zugriffsrichtlinien lokal durchsetzt, führt auch bei einem Ausfall der Verbindung zur Cloud weiterhin Überprüfungen durch und wendet die Zugriffsrichtlinien an. Eine reine Cloud-Architektur, die mit demselben Ausfall konfrontiert ist, steht vor der Wahl, entweder den Betrieb einzustellen oder den Datenverkehr durchzulassen – und niemand kann diese Entscheidung kurzfristig gut treffen.

Wo SSE noch Aufholbedarf hat

All dies ist keine Prognose. Die Mitarbeiter sind derzeit in den Büros. Die Modelle laufen derzeit auf der Infrastruktur der Unternehmen. Die Aufsichtsbehörden stellen derzeit Fragen zur Souveränität und zeigen keinerlei Anzeichen dafür, dass ihr Interesse nachlassen könnte.

Was noch nicht auf dem neuesten Stand ist, ist die Frage, wo die SSE-Kontrollen angesiedelt sein müssen. Bei der Überprüfung und Durchsetzung von SSE in der Cloud wird nach wie vor davon ausgegangen, dass das Risiko das Gebäude verlässt – was von Quartal zu Quartal immer weniger der Realität entspricht.

Bitten Sie Ihren Anbieter, Ihnen zu erläutern, wie er die lokale KI-gestützte Arbeitsweise schützt; welche Steuerungsfunktionen vor Ort ausgeführt werden, welche in der Cloud laufen und was mit den einzelnen Funktionen geschieht, wenn die Verbindung zwischen ihnen unterbrochen ist.

Erfahren Sie, , wie die neue Skyhigh Hybrid Mesh SSE-Plattform das Zero-Trust-Konzept im Büro erweitert, um KI besser zu schützen.

Zurück zu Blogs