Zero Trust bei der Deutschen Telekom

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.

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. Lässt sich das Datum 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.