Zero Trust als neues Paradigma der IT-Sicherheit Zero Trust in der Praxis: Chancen, Stolperfallen und NIST-Leitlinien

Klassische Sicherheitsperimeter sind Geschichte – Cloud, Homeoffice und komplexe Lieferketten machen ein radikales Umdenken nötig. Zero Trust gilt als Goldstandard, doch die Praxis zeigt: Falsch umgesetzt entstehen neue Risiken.

Die Zeiten Perimeter geschützter Unternehmensnetzwerke sind vorbei. Die Allgegenwärtigkeit der Cloud-Services, Homeoffice, Bedrohungen aus der Lieferkette und das Bestreben nach mobiler Produktivität haben die klassischen Sicherheitsgrenzen aufgelöst.

Die Antwort der Branche: Zero Trust. Doch wie lässt sich dieses Konzept konkret umsetzen?

Neue Leitlinien des US-amerikanischen NIST liefern dringend benötigte Orientierung. Über drei Jahre lang testete NIST (National Institute of Standards and Technology) verschiedene Zero Trust-Implementierungen.

Das Resultat war für die Pioniere der Implementierungen nicht ruhmreich. Fragmentierte Richtlinien, übers Knie gebrochene Integrationen und derlei andere halb gebackene Quick-Fixes hätten demnach zu Sicherheitslücken geführt, die teilweise schlimmer waren als gar keine Maßnahmen.

Nicht gut.

Einige Unternehmen haben wiederum zumindest am Anfang den großen Erfolg mit Zero Trust gefeiert, aber ihre operativen Abläufe durch hinderliche technische Schutzmaßnahmen so weit gelähmt, ihre Mitarbeiter so weit demoralisiert und ihre Produktivität so weit eingedämmt, dass sie dann wieder von Null anfangen mussten.

Auch nicht gut.

Wie macht man es denn richtig?

Durchstarten mit Zero Trust Network Access

Vier-Punkte-Plan zur Einführung von ZTNA

Was ist Zero Trust? Die Grundprinzipien

Während klassische Sicherheitsarchitekturen davon ausgingen, dass es hinter dem Perimeter des Unternehmensnetzwerks sicherheitstechnisch mit rechten Dingen zugeht, stellt Zero Trust (NIST SP 800-207) diese Annahme radikal infrage. Niemandem und nichts wird per se vertraut – weder innerhalb noch außerhalb des eigenen Netzwerks.

Der Paradigmenwechsel geht mit neuen Grundprinzipien einher:

• Never trust, always verify: Jeder Zugriff muss kontinuierlich geprüft und authentifiziert, jede Identität verifiziert werden.

• Least Privilege: Nutzer und Systeme erhalten nur die minimal nötigen Berechtigungen, nicht mehr und nicht weniger.

• Micro-Segmentierung: Das Netzwerk wird in kleine Zonen unterteilt, um Bewegungen von Angreifern einzuschränken.

• Kontinuierliche Überwachung: Aktivitäten werden fortlaufend beobachtet und analysiert; bei Anomalien gilt die „Alarmstufe rot“.

Das National Institute of Standards and Technology (NIST) hat im Juni 2025 mit der Veröffentlichung von SP 1800-35 einen Meilenstein gesetzt. Die neue Publikation liefert 19 praxisnahe Beispielarchitekturen, die mit handelsüblichen Technologien umgesetzt wurden. Diese Beispiele decken typische Szenarien ab – von Multi-Cloud-Umgebungen über Filialnetze bis hin zu Remote Work im Internet-Café. Der NIST ist jene Institution in den Vereinigten Staaten, die Standards für Zero-Trust-Architekturen, Post-Quantum-Kryptographie und Datenschutz entwickelt.

Die Beispiele berücksichtigen verschiedene Unternehmensgrößen, Branchen und IT-Landschaften. Sie bieten flexible Migrationspfade, sodass Unternehmen mit unterschiedlichen IT-Ressourcen und Budgets Schritt für Schritt Zero-Trust-Prinzipien umsetzen können – Betonung auf Schritt-für-Schritt. Denn Zero Trust ist kein Selbstläufer.

Das NIST hat sieben zentrale Grundsätze für Zero Trust definiert, die als Leitplanken für jede Umsetzung dienen sollten:

• Alle Ressourcen sind schützenswert – egal ob Daten, Geräte oder Cloud-Services.

• Jede Kommunikation wird abgesichert – unabhängig vom Standort.

• Zugriff erfolgt stets sitzungsbasiert und nach aktueller Prüfung.

• Dynamische Richtlinien steuern den Zugriff – basierend auf Kontext und Risiko.

• Integrität und Sicherheitsstatus aller Assets werden kontinuierlich überwacht.

• Authentifizierung und Autorisierung sind dynamisch und zwingend.

• Umfassende Datensammlung und -analyse stärken die Sicherheitslage (diese Leitlinie beißt sich allerdings mit der EU-GDPR, wenn personenbezogene Daten im Spiel sind – da sind zusätzliche Maßnahmen erforderlich).

Zero-Trust basiert auf der sogenannten Kipling-Methode, die das Projektmanagement maßgeblich beeinflusste. Diese Methode geht auf… ein Gedicht von Rudyard Kipling aus dem Jahr 1902 zurück. Darin formulierte er die sechs grundlegenden Fragen – Wer, Was, Wann, Wo, Warum und Wie, die heute Zero Trust zu Grunde liegen: WWWWWW (englisches Akronym: WWWWWH).

Im Laufe der rund fünfzehn Jahre seit der Entstehung von Zero Trust — und genau 123 Jahre nach Kipling — sind schon unzählige Organisationen an der Umsetzung von Zero Trust sang- und klaglos gescheitert.

Neues eBook „Zero-Trust-Sicherheitsmodelle“

Zero Trust als Basis sicherer Digitalisierung

Zero-Trust Uber-drüssig

Trotz umfassender Zero-Trust-Maßnahmen bei Uber gelang es einem knapp Achtzehnjährigen im September 2022, Zugang zu nahezu allen internen Systemen des Konzerns zu erlangen. Der Cybertäter machte sich ein Phänomen zu Nutze, das heute als „MFA-Fatigue“ oder „Push-Müdigkeit“ die Runde macht.

Der Hacker erlangte erst einmal die Zugangsdaten eines Mitarbeiters von Uber, vermutlich über den Darknet-Handel. Der Benutzername und Passwort allein genügten jedoch nicht, um sich anzumelden, da Uber zu dem Zeitpunkt bereits standardmäßig auf MFA setzte (Multi-Factor Authentication). Der Workaround zum Aushebeln von MFA war MFA-Belästigung.

Der Angreifer löste immer wieder Push-Benachrichtigungen (MFA-Anfragen) aus; diese reflektierten sich bei dem Mitarbeiter auf dem Smartphone. Zunächst hatte dieser die lästigen Anfragen konsequent abgelehnt. Schließlich kam er zu dem Schluss, dass es sich entweder um einen Systemfehler oder um eine legitime Aufforderung im Rahmen der Zero-Trust-Anfragen von Uber handeln musste. Also hat er diese bestätigt. Was könnte da schon schief gehen?

Durch die einmalige Zustimmung erhielt der Angreifer Zugang zu den internen Systemen von Uber — einschließlich der AWS-Umgebung, der Windows-Domäne, aller Bug-Bounty-Programme und der Sicherheitssoftware. Bingo!

MFA-Fatigue ist eine Angriffstaktik, bei der Cyberkriminelle legitime Nutzer mit einer Flut von MFA-Anfragen so lange unter Beschuss halten, bis einem der Geduldsfaden reißt und man auf „Bestätigen“ klickt, damit es mit der Belästigung endlich aufhört.

Technologische Schutzvorkehrungen muss man wie ein Gewürz dosieren. Zero-Trust darf nicht so restriktiv ausfallen, dass sich die betroffenen Fachkräfte ihre Rückkehr zur Produktivität durch Fahrlässigkeit erkaufen müssen. Das ist nicht im Sinne des Erfinders. Erst das Zusammenspiel verschiedener Maßnahmen, die legitime Geschäftsabläufe fördern statt zu behindern, schafft eine sichere Umgebung, indem es den Faktor Mensch in den Mittelpunkt stellt.

Konkret sollte MFA mit zusätzlichen Schutzmaßnahmen wie Ratenbegrenzung (Rate Limiting), geografischen Beschränkungen und kontextsensitiven Prüfungen Anwendung finden.

Phishing trotz Zwei-Faktor-Authentifizierung

Erfolgreiche Hacks trotz 2FA – das können Unternehmen tun

Der Tanz auf dem Vulkan

Ein rigoroser Sicherheitsansatz wie Zero-Trust bedeutet zunächst tiefgreifende Eingriffe in etablierte Prozesse auf allen Ebenen der Organisation. Das ist klar. Doch wo liegt die Grenze zwischen notwendigen Sicherheitsvorkehrungen und dem Korsett überzogener Kontrolle? Wann wird aus Schutz ein lähmender Regelbetrieb, der Innovation und Agilität erstickt?

Zero Trust verlangt, dass kein Benutzer, kein Gerät und keine Anwendung per se als vertrauenswürdig gilt – selbst innerhalb des eigenen Netzwerks. Das führt zu einer Vielzahl von Authentifizierungs- und Autorisierungsprüfungen, die zwar das Risiko eines Vorfalls verringern können, aber auch die tägliche Arbeit erschweren. Wenn Mitarbeitende für jede Aktion mehrfach ihre Identität nachweisen müssen oder auf benötigte Ressourcen nur mit Verzögerung zugreifen können, kommt ihr Arbeitsfluss zum Stillstand. Der Frust fördert die Entstehung von Schatten-IT, das Aufkommen von Umgehungsversuchen und letztlich ein Sicherheitsverlust — das Gegenteil der ursprünglichen Zielsetzung.

Adaptive Authentifizierung, kontextbasierte Zugriffskontrollen und intelligente Automatisierung können helfen, Sicherheit und Benutzerfreundlichkeit in Einklang miteinander zu bringen — sofern sie als ein adaptives Ganzes verstanden und implementiert werden. Ein solches System entsteht im Dialog mit den Fachabteilungen und unter Berücksichtigung deren Anforderungen an die Ausgestaltung der Geschäftsprozesse.

Zero Trust fordert Strategie statt hektischer Betriebsamkeit. Es ist ein langfristiger Transformationsprozess. Er erfordert klare Zielbilder, eine realistische Roadmap und vor allem: Change Management. Nur wenn Mitarbeitende verstehen, warum bestimmte Maßnahmen notwendig sind und wie sie konkret geschützt werden, entsteht Akzeptanz. Transparenz, Schulung und kontinuierliches Feedback sind dabei ebenso wichtig wie technische Exzellenz.

Zero Trust muss mit der Organisation mitwachsen und mit technologischen Entwicklungen Schritt halten.

Ethische und datenschutzrechtliche Erwägungen beim KI-Einsatz

Vertrauen in KI oder Zero-Trust?

Zero Trust vorge-GAU-kelt: die WAF als Einfallstor

Am 19. Juli 2019 hatte Capital One, eines der prominentesten Finanzinstitute der Vereinigten Staaten und einer der Pioniere der AWS-Nutzung im Finanzwesen, ein böses Erwachen. Durch einen Geheimtipp eines GitHub-Users war man auf einen Hack aufmerksam geworden, der sich rund vier Monate zuvor ereignet hatte.

Ein Hacker mit dem Alias „Erratic“ - eine ehemalige systemingenieurische Fachkraft von AWS, die nach dem Ausscheiden beim Hyperscaler ihr Fachwissen missbräuchlich einsetzte - kopierte innerhalb von nur zwei Tagen persönliche Daten von rund 106 Millionen Kreditkartenbewerbern aus den USA und Kanada aus einer AWS-S3-Umgebung (AWS S3) von Capital One. Betroffen waren u. a. 140.000 geheime Sozialversicherungsnummern, 80.000 Bank­kontonummern und Antrags­daten seit 2005.

„Erratic“ nutzte eine SSRF-Schwachstelle (Server-Side Request Forgery) in der Web Application Firewall (WAF) von Capital One aus, um interne AWS-Dienste wie den Instance Metadata Service (IMDS) aufzurufen. Eine restriktive Validierung und Segmentierung hätte den Zugriff auf den Metadatenservice auf den legitimen WAF-Prozess beschränken müssen – ein zentrales Prinzip im Zero-Trust-Ansatz.

Das Risiko entstand nicht durch eine direkte externe Erreichbarkeit des IMDS, sondern durch die Möglichkeit, über eine SSRF-Schwachstelle in der WAF interne Ressourcen indirekt von außen anzusprechen. Der Metadatenservice hätte so abgesichert werden müssen, dass ausschließlich der WAF-Prozess selbst darauf zugreifen kann. Durch fehlende Netzwerk- und Prozessisolation war es jedoch möglich, dass externe Angreifer über die WAF und SSRF interne Dienste ansprachen und sensible Zugangsdaten abgriffen.

Der IDMS-Dienst erlaubt es den EC2-Instanzen in einer AWS-Bereitstellung, Metadaten über sich selbst abzurufen, darunter derart kritische Informationen wie IAM-Rollen und temporäre Zugangstokens, Sicherheitsgruppen und Netzwerkkonfigurationsdaten. Im Unterschied zu seinem Nachfolger, der zu jenem Zeitpunkt bereits verfügbar, aber noch nicht weit verbreitet war, verlangte IMDS v1 keine Token-basierte Authentifizierung, hatte keinen Hop-Limit (Schutz gegen eine Weiterleitung) und war aufgrund der SSRF-Schwachstelle intern aus der WAF heraus erreichbar. Der Metadatenservice hätte nur vom WAF-Prozess selbst aufrufbar sein dürfen.

Als Nächstes gelang es „Erratic“, mehr als siebenhundert S3-Buckets aufzulisten und daraus sensible Objekte zu kopieren. Die betreffende WAF-Rolle besaß mehr Rechte als nötig. Die betreffende Rolle hätte maximal auf die eigenen Log-Buckets zugreifen dürfen. Das Zero-Trust-Prinzip der Mikrosegmentierung mit minimalen Berechtigungen wurde missachtet.

Weil es bei Capital One an einer kontinuierlichen Validierung der Zugriffswege fehlte, blieb der Angriff zunächst unentdeckt – bis ein „guter Samariter“ den auf GitHub veröffentlichten Datendump meldete.

Mehr Sicherheit für hybride IT-Infrastrukturen

Maximale Datensouveränität durch Zero Trust & EU-Cloud

Darum werden in Zero-Trust-Architekturen alle Identitäten und Geräte auch nach dem Log-In während der gesamten Sitzung kontinuierlich überprüft (Stichwort „Continuous Authentication and Attestation“, wobei mit Attestierung die kontinuierliche Prüfung des Gerätezustands gemeint ist). Wenn diese Maßnahme fehlt, spricht man von „fehlender Runtime-Validierung“. Sicherheitsverletzungen wie Credential-Stuffing oder Session-Hijacking bleiben dann unentdeckt.

Beim CapitalOne-Hack haben sich mehrere Cybersicherheitsschnitzer überlagert. Überprivilegierung von Service-Rollen war nur die Spitze des Eisbergs an Konfigurationsfehlern; innerhalb der betroffenen VPC bewegte sich „Erratic“ lateral ohne aufzufallen; die Segmentierung funktionierte nur auf VPC-Ebene. Runtime-Validierung? Fehlanzeige.

Die im Fall Capital One unterlassenen Sicherheitsmaßnahmen hätten weder die Produktivität der Mitarbeiter noch die Benutzererfahrung der Kunden beeinträchtigt. Im Gegenteil.

Der Vorfall hinterließ bei Capital One erhebliche Reputationsschäden, aber auch ein massives finanzielles Loch. Allein die unmittelbaren Incident-Response-Maßnahmen – Forensik, Benachrichtigung betroffener Kunden, Kreditüberwachung – schlugen laut Unternehmensangaben mit 100 bis 150 Mio. US-Dollar zu Buche. Im Pandemiejahr 2020 verhängte das U.S. Office of the Comptroller of the Currency (U.S. OCC) eine zivilrechtliche Strafzahlung von 80 Mio. US-Dollar wegen mangelhafter Cloud-Risikosteuerung. Hinzu kam ein Vergleich in der Sammelklage betroffener Kunden über 190 Mio. US-Dollar.

Parallel musste Capital One seine AWS-Architektur grundlegend härten, u. a. durch den Wechsel auf den abgesicherten Metadata-Dienst v2, den Einsatz von Cloud-Infrastructure-Entitlement-Management (CIEM) und strengere Service-Control-Policies.

Die Eliminierung von Server-Side Request Forgery-(SSRF)-Angriffsflächen hat oberste Priorität. Ein SSRF-Angriff liegt vor, wenn ein Angreifer einen Server dazu bringt, HTTP-Anfragen an interne oder externe Ressourcen zu senden, die eigentlich nicht erreichbar sein sollten.

Maximale Sicherheit für hybride Arbeitswelten

Kontrollierter Zugriff auf Unter­nehmens­ressourcen mit ZTNA

Eine ganze Reihe von Gegenmaßnahmen kann SSRF-Angriffen einen Riegel vorschieben, und zwar:

• Erzwingen von IMDS v2 anstelle von v1,

• Blockieren von Metadaten-Endpunkten auf Netzwerkebene,

• konsequente Egress-Filterung,

• „Least-Privilege-by-Design“: Über CIEM-Plattformen oder Just-in-Time-Access-Modelle lassen sich Service-Rollen automatisch auf den minimal nötigen Umfang beschränken und nur temporär erweitern,

• Mikrosegmentierung darf sich nicht auf VPC-Grenzen beschränken; Workloads müssen auch innerhalb eines Segments standardmäßig isoliert sein, um laterale Bewegungen zu verhindern.

• Verhaltensanalysen (UEBA) und Deception-Telemetrie,

• Umsetzung aller IAM- und Netzwerkänderungen als „Policy as Code“, damit sie durch automatisierte Guardrails laufen; erst wenn DevSecOps-Pipelines Fehlkonfigurationen schon beim Commit blockieren, wird aus dem Buzzword „Zero Trust“ gelebte Praxis.

• Und, und, und.

• Die Umstellung auf Zero Trust ist kein Selbstläufer. Sie erfordert:

• Umfassende Inventarisierung: Wer greift auf welche Ressourcen zu – und warum?

• Technologiewechsel: Integration von MFA, IAM, EDR und Netzwerksegmentierung.

• Kultureller Wandel: Sicherheit wird zur gemeinsamen Aufgabe von IT, Fachbereichen und Management.

Zero Trust gilt als das Sicherheitsparadigma der Zukunft, der Goldstandard der IT-Sicherheit. Es hat eine gewisse Dringlichkeit erlangt.

Doch der Balanceakt zwischen Sicherheit und Usability ist ein Tanz auf dem Vulkan. Die Beispiele von Uber, Capital One & Co. zeigen anschaulich: Bei der Implementierung von Zero Trust müssen alle Bausteine – Technik, Prozesse und Unternehmenskultur – in einem fein orchestrierten Zusammenspiel ineinandergreifen.

Netzwerksegmentierung neu denken

Herausforderungen der Mikrosegmentierung

Fazit

Vertrauen ist gut, Beharrlichkeit ist noch besser. Eine Zero-Trust-Architektur, die nicht mit Kollateralschäden oder erheblichen Einschränkungen der Handlungsfähigkeit einhergeht, muss dynamisch, adaptiv und kontextsensitiv mit den Anforderungen der betrieblichen Prozesse mitwachsen. Die Unternehmen müssen ihre Sicherheitsarchitektur grundlegend überdenken, die Einführung schrittweise umsetzen und die Feinjustierung kontinuierlich fortführen.

Über die Autoren: Das Autorenduo Anna Kobylinska und Filipe Pereira Martins arbeitet für McKinley Denali, Inc., USA.

(ID:50543851)