Zero Trust bezeichnet kein absolutes Misstrauen, sondern das Ersetzen impliziter Vertrauensannahmen durch explizit modellierte Vertrauensbeziehungen. Statt pauschal dem internen Netzwerk zu vertrauen, wird jede Vertrauensbeziehung bewusst definiert, etwa zu einem Token eines Identity Providers. Große Organisationen gliedern Zero Trust typischerweise in sechs Bereiche: Netzwerk, Identitäten, Geräte, Daten, Anwendungen und Monitoring.
Das Wichtigste in Kürze
- Zero Trust bedeutet nicht “niemandem vertrauen”, sondern implizites Vertrauen durch explizit modellierte Vertrauensbeziehungen zu ersetzen: Wer vertraut wem, warum und auf welcher Grundlage?
- Bevor Tokens und Autorisierungsregeln skalieren können, muss die Identity-Provider-Landschaft konsolidiert sein. Die Telekom hat dafür die Zahl der Identity Provider von 30 auf 3 reduziert.
- Zero Trust in großen Organisationen braucht eine gemeinsame Definition. Ohne sie bringt dasselbe Konzept in einem Raum mit zehn Personen elf verschiedene Meinungen hervor.
- Den Einstieg findet man dort, wo ein externer Request die eigene Trust Boundary überschreitet: Was muss an diesem Punkt vorliegen, und wem muss man vertrauen, um eine fundierte Autorisierungsentscheidung treffen zu können?
- Security-Initiativen kommen in bestehenden Organisationen weiter, wenn sie an laufende Business-Ziele andocken. Cost-Saving-Programme bieten eine Win-Win-Situation, weil Zero-Trust-Maßnahmen dort direkt messbare Effekte liefern.
Zero Trust ist ein Buzzword, das jede Rolle anders versteht
Zero Trust hat keine geteilte Definition. Wer mit zehn Kollegen in ein Meeting geht und fragt, was Zero Trust bedeutet, kommt mit elf Meinungen wieder heraus. Genau das ist der Ausgangspunkt für jedes ernsthafte Projekt zum Thema.
Der Begriff markiert einen Trend, der Unternehmen zwingt, ihr Sicherheitskonzept zu überdenken. Aber jede Rolle interpretiert ihn aus der eigenen Ecke. Ein Netzwerker sieht ein unsicheres Intranet und fordert neue Hardware. Systemarchitekten winken ab und halten ihr System längst für sicher.
Waldemar Schäfer von der Telekom warnt vor der Wiederholung eines alten Fehlers. Bei SOA wurde ein ESB verkauft mit dem Versprechen, man habe jetzt eine entkoppelte Architektur. Der Begriff trug die Erwartung, die Technik löste sie nicht ein. Damit das bei Zero Trust nicht passiert, muss ein Unternehmen zuerst definieren, was es selbst darunter versteht.
Null Vertrauen heißt nicht kein Vertrauen, sondern explizites Vertrauen
Zero bei Zero Trust ist nicht wörtlich gemeint. Die Leitformel “Always verify, never trust” beißt sich logisch mit sich selbst: Um etwas zu verifizieren, musst du den Daten vertrauen, gegen die du prüfst.
Der eigentliche Punkt ist der Unterschied zwischen implizitem und explizitem Vertrauen. Zero Trust verbietet implizites Vertrauen. Jede Vertrauensbeziehung wird stattdessen explizit modelliert.
Ein Beispiel: Eine API vertraut dem Token eines Identity Providers. Das ist eine bewusst modellierte Beziehung, kein stillschweigend vorausgesetztes “das Intranet ist schon sicher”. Die Frage lautet immer: Welchen Teilen der Infrastruktur vertraust du strategisch, welchen nicht?
Für Architekten kommt damit eine neue Sicht hinzu. Bisher wurden Datenflüsse, logische Sicht und Ablaufsicht modelliert. Zero Trust ergänzt eine weitere Dimension: Wem vertraust du an welcher Stelle, und warum?
Sechs Aspekte, an denen die Telekom Zero Trust festmacht
Die Telekom hat Zero Trust auf sechs Bereiche heruntergebrochen: Netzwerk, Identities (IAM), Geräte, Daten, Anwendungen und Monitoring. Diese sechs Aspekte bilden den gemeinsamen Rahmen, an dem die unterschiedlichen Teams arbeiten.
Der Anstoß war ein Zusammenstoß der Perspektiven. Waldemar war für die Autorisierung der APIs zuständig, während eine bestehende Zero-Trust-Initiative sich vor allem mit Identity Providern, etwas Netzwerk und Geräten beschäftigte. Beide redeten über dasselbe Wort und meinten verschiedene Dinge.
Die Lösung war, sich zusammenzusetzen und die Bereiche gemeinsam zu definieren. Eine geteilte Definition zu haben ist die Voraussetzung dafür, dass das Konzept in einer großen Organisation überhaupt verkaufbar wird. Kein Fachbereich steht parat und freut sich über neue Security-Features.
Aufräumen kommt vor Absichern: erst die Identity Provider konsolidieren
Bevor APIs anfangen, Identity Tokens zu prüfen, muss die Zahl der Quellen sinken. Sonst entsteht auf der Token-Ebene genau das Chaos, das man auf der API-Ebene gerade zu verhindern versucht.
Die Telekom fand allein für Mitarbeiter rund 30 Identity Provider vor, dazu kamen B2B und B2C. Würden APIs anfangen, all diesen Quellen zu vertrauen, multipliziert sich die Komplexität. Die erste Maßnahme war deshalb Konsolidierung: von 30 auf 3 strategische Identity Provider.
Diese drei mussten moderne Protokolle unterstützen, damit Teams sie auch freiwillig nutzen wollen. Rückenwind kam vom Management und von einem laufenden Audit. Wenn der Druck von außen schon da ist, lässt sich eine Aufräumaktion leichter durchsetzen.
Wie die Telekom Zero Trust ausrollt: Enabler bauen, Consumer anschließen
Der Ausrollweg ist iterativ, nicht der große Knall. Es werden Enabler bereitgestellt, dann kommen nach und nach Consumer dazu. Gegen den Big Bang funktioniert das in einer großen Organisation nicht.
Ein zweiter Treiber war die Entscheidung, dass Geräte ins Internet gehen. Daraus folgte die Frage, was das für die Applikationen bedeutet. Es gibt mehrere Landing Zones mit unterschiedlich hohen Schutzmechanismen, und die Infrastruktur muss die Applikationen so absichern, dass sie internetfähig sind. Das ist nicht trivial: Die Frage ist nicht, ob man angegriffen wird, sondern wann und wie stark.
Am API-Gateway laufen die nächsten Schritte. Dort sollen die Token standardisiert werden, ein eigenes Team verwaltet die Autorisierungs-Policies zentral. Erste Proof of Concepts sind gelaufen, weitere Milestones folgen Release für Release.
Standardisierung ist dabei eine Frage der Ebene. Je weiter oben standardisiert wird, desto länger dauert es und desto aufwendiger ist es. Je weiter unten, desto schneller und pragmatischer. Im Ergebnis landet eine Anforderung als Story, aber auf unterschiedlichen Ebenen: erst auf System- oder Hub-Ebene, dann bei den Teams.
| Ebene der Standardisierung | Eigenschaft |
|---|---|
| Weit oben (organisationsweit) | langsamer, aufwendiger, aber breit gültig |
| Weit unten (Team-nah) | schneller, pragmatischer, aber lokal |
Wenn eine Security-Anforderung ohne Vorlauf direkt bei den Teams landet, weil ein Security Officer sie ab morgen verlangt, entsteht Chaos. Deshalb beginnt jede Anforderung bei den System- und Hub-Architekten, bevor sie zu den Teams durchgereicht wird.
Security verliert gegen Features, wenn der Mindchange fehlt
Die größte Hürde ist nicht die Technik, sondern die Haltung der Teams. Man kommt in ein Team, erklärt Zero Trust, und bekommt zu hören: Schön, aber wir sind schon sicher.
Der Mindchange beginnt mit Fragen statt mit Statements. Wem vertraut ihr eigentlich? A, B, C, D. Wenn das aufgemalt ist, folgt die nächste Frage: Habt ihr geprüft, welche Sicherheitsstufe diese Stellen haben, wie gut sie geschützt sind? Lautet die Antwort nein, dann ist das eigene Sicherheitsniveau genauso hoch wie das der schwächsten Stelle, der man vertraut.
Dieser Wechsel hält selten an. Auf der Konferenz klingt alles einleuchtend, zurück im Alltag kommt der Druck der Features. Security müsste man machen, aber man hält sich für ganz gut. Genau hier entscheidet sich, ob das Konzept trägt.
Man hört etwas zu und denkt, es ist schön. Aber wenn man dann zurückkommt, kommt der Druck mit den Features. Security steht immer im Kampf gegen Features. (Waldemar Schäfer) Wer Teams gewinnen will, überredet nicht per Autorität. Das typische “Der Chief Architect sagt, ihr müsst” funktioniert selten. Was funktioniert: fragen, den Druck von Datenschutz und Informationssicherheit nutzen und konkrete Hilfe anbieten. Schau, das ist der Enabler, so binde ich dich an. Hilfe schlägt Ansage.
Wo anfangen: Kronjuwelen schützen und Win-win-Initiativen suchen
Der Einstiegspunkt ergibt sich aus zwei Kriterien. Das erste sind die Daten. Schütze die Kronjuwelen, also die besonders schützenswerten Daten, und schau zuerst dort hinein.
Das zweite Kriterium ist eine Business-Initiative, die eine Win-win-Situation schafft. Eine Security-Initiative allein durchzusetzen ist schwer. Koppelt man sie an ein Vorhaben, das ohnehin Fahrt hat, wird es leichter.
Bei der Telekom war das eine Initiative zur Kostensenkung. Wenn eine Applikation Daten mit höherer Schutzklasse konsumiert, steigen die Anforderungen: kein Betrieb in der Public Cloud, Betrieb aus Deutschland, höhere Kosten. Daraus entsteht die Frage, ob die Applikation diese Daten wirklich braucht. Lassen sich diese Daten herausnehmen, sinkt die Schutzklasse und die Kosten fallen. Genau dort, wo Cost Savings winken, steigt man ein und macht die Absicherung nachvollziehbar, statt sie nur zu versprechen.
Der erste praktische Schritt: setz dich auf die API und frage, wem du vertraust
Wer konkret loslegen will, beginnt an der eigenen Trust Boundary. Setz dich gedanklich auf die API und frag: Was brauche ich, um autorisieren zu können?
Das heißt im Detail: Welche Daten brauche ich, in welcher Qualität, wie schnell, und wie komme ich an sie heran? Latenz und Performance kommen danach. Der Startpunkt ist die Erkenntnis, dass die API der erste Punkt ist, an dem ein fremder, potenziell bösartiger Request hereinkommt. Dort hört das Vertrauen auf. Was muss ich dort bereithalten, und wem vertraue ich, um weiterzugehen?
Es gibt allerdings einen Schritt davor, und der ist der eigentliche Knackpunkt: erkennen, dass Zero Trust ein Buzzword ist, das definiert werden muss. Für den einen ist klar, dass man es machen muss, der andere versteht etwas völlig anderes darunter. Diesen Common Sense muss man so weit nach unten verschieben, bis man ganz vorne neu anfängt, gemeinsam zu definieren.
Nicht jeder Bereich lässt sich gleich gut absichern
Strukturierte Domänen sind der einfache Teil. APIs mit klarer Struktur lassen sich gut mit Policies autorisieren, hier funktioniert das Modell sauber.
Schwieriger wird es bei unstrukturierten Data Lakes. Wenn alle Daten in einen Lake geworfen werden, um daraus Business-Mehrwert zu schöpfen, fehlt die Struktur, auf der eine zuverlässige Autorisierung aufsetzen könnte. Für diesen Fall gibt es noch keine fertige Antwort.
Das ist kein Widerspruch zum Vorgehen, sondern seine Konsequenz. Nicht alle Konzepte stehen auf derselben Reifestufe. Es geht erst darum, eine Strategie und einen Enabler zu haben und dann parallel mit dem Enabler in die Breite zu gehen. Genau in dieser Phase, vom Proof of Concept in die Fläche, liegt die aktuelle Herausforderung.
Häufig gestellte Fragen
Warum stößt die Leitformel “Always verify, never trust” an ihre Grenzen?
Sie widerspricht sich selbst: Wer etwas verifiziert, muss den Daten vertrauen, gegen die er prüft. Das Null in Zero Trust ist nicht wörtlich gemeint. Verboten ist implizites Vertrauen, etwa die Annahme, das Intranet sei schon sicher. Jede Beziehung wird stattdessen bewusst modelliert, zum Beispiel eine API, die dem Token eines bestimmten Identity Providers vertraut.
Warum reden Teams in Zero-Trust-Projekten oft aneinander vorbei?
Weil eine geteilte Definition fehlt. Geht man mit zehn Kollegen in ein Meeting, kommt man mit elf Meinungen wieder heraus. Der Netzwerker sieht ein unsicheres Intranet und fordert Hardware, Systemarchitekten halten ihr System längst für sicher. Waldemar Schäfer verweist auf SOA, wo ein ESB als entkoppelte Architektur verkauft wurde und die Technik das Versprechen des Begriffs nicht einlöste.
Was ändert Zero Trust an der Arbeit von Architekten?
Es kommt eine Sicht hinzu. Bisher wurden Datenflüsse, logische Sicht und Ablaufsicht modelliert. Zero Trust ergänzt die Frage, wem man an welcher Stelle vertraut und warum. Große Organisationen brechen das oft auf sechs Bereiche herunter: Netzwerk, Identitäten, Geräte, Daten, Anwendungen und Monitoring. Diese Bereiche bilden den Rahmen, an dem verschiedene Teams gemeinsam arbeiten.
Warum sollte man Identity Provider konsolidieren, bevor APIs Tokens prüfen?
Sonst entsteht auf Token-Ebene genau das Chaos, das man auf API-Ebene verhindern will. Die Telekom fand allein für Mitarbeiter rund 30 Identity Provider vor, dazu kamen B2B und B2C. Würden APIs all diesen Quellen vertrauen, multipliziert sich die Komplexität. Konsolidiert wurde auf drei strategische Provider, die moderne Protokolle unterstützen mussten, damit Teams sie freiwillig nutzen.
Auf welcher Ebene sollte eine Security-Anforderung standardisiert werden?
Das ist ein Abwägen. Je weiter oben standardisiert wird, desto länger dauert es und desto aufwendiger ist es, dafür gilt das Ergebnis breit. Weiter unten, nah an den Teams, geht es schneller und pragmatischer, bleibt aber lokal. Landet eine Anforderung ohne Vorlauf direkt bei den Teams, weil ein Security Officer sie ab morgen verlangt, entsteht Chaos.
Wie gewinnt man Entwicklungsteams, die sich bereits für sicher halten?
Mit Fragen statt Statements. Wem vertraut ihr? Und habt ihr geprüft, welche Sicherheitsstufe diese Stellen haben? Lautet die Antwort nein, ist das eigene Sicherheitsniveau so hoch wie das der schwächsten Stelle, der man vertraut. Autorität hilft wenig: Das typische “Der Chief Architect sagt, ihr müsst” funktioniert selten. Konkrete Enabler und Hilfe wirken besser.
Wo lohnt sich der Einstieg in Zero Trust am ehesten?
Bei den Kronjuwelen, also den besonders schützenswerten Daten, und bei einer Business-Initiative, die ohnehin Fahrt hat. Bei der Telekom war das ein Kostensenkungsprogramm: Konsumiert eine Applikation Daten höherer Schutzklasse, darf sie nicht in der Public Cloud laufen und muss aus Deutschland betrieben werden. Lassen sich diese Daten herausnehmen, sinken Schutzklasse und Kosten.
Lässt sich jeder Datenbereich gleich gut mit Zero Trust absichern?
Nein. Strukturierte Domänen sind der einfache Teil: APIs mit klarer Struktur lassen sich sauber mit Policies autorisieren. Bei unstrukturierten Data Lakes fehlt die Struktur, auf der eine zuverlässige Autorisierung aufsetzen könnte, und dafür existiert keine fertige Antwort. Die Konzepte stehen auf unterschiedlichen Reifestufen: erst Strategie und Enabler, dann parallel in die Breite gehen.
