Hallo und herzlich willkommen zu einer neuen Folge vom Podcast Software Testing. Ich bin euer Host Ritschi und hier live auf der OOP 2024 in München. Zero Trust, nichts und niemandem vertrauen, darüber habe ich mit Waldemar Schäfer von der Telekom gesprochen. Zero Trust ist ein Buzzword, was gerade wieder rauf und runter gespielt wird, aber kaum einer weiß wirklich, was damit gemeint ist. Und kann man das überhaupt wissen? Darüber haben wir uns unterhalten. Wie
definiert man Zero Trust? Wie hat die Telekom das für sich gelöst? Wie sind sie da rangegangen? Welche Fallstricke gibt es und was ist der weitere Ausblick? Ja und denkt bitte dran, ich freue mich immer über Feedback an [email protected]. Schreibt mir doch mal, was gefällt euch an dem Podcast? Was wollt ihr anders haben? Was sind Themen, die euch interessieren? Welche Speaker würdet ihr gerne mal holen? Das hilft mir, den Podcast für euch auch immer besser
zu machen. In diesem Sinne viel Spaß bei der Folge. Hallo Waldemar, schön, dass du da bist. Danke Richard, schön, dass du mich eingeladen hast. Ja, du hast ja auch ein spannendes Thema mitgebracht. Wir sind ja hier auf der OOP 2024 in München. Tolle Konferenz, ganz viel Inspiration und Input schon bekommen auch. Und
du hast morgen deinen Vortrag auch hier im Haus. Das ist natürlich auch sehr spannend, weil das Thema, was du mitgebracht hast, ist Zero Trust und eure Erfahrungen bei der Telekom und den Projekten, die ihr auch gemacht habt. Vielleicht steigen wir da gleich mal ein, was heißt denn eigentlich Zero Trust? Das steht ja sehr häufig irgendwo, aber was bedeutet denn das? Ja, eine sehr gute Frage. Insbesondere, wenn man in ein Meeting reingeht mit zehn Kollegen und
fragt, was ist ein Zero Trust, dann kommt man mit elf Meinungen raus. Also im Prinzip ist es ein neues Buzzword, wo man sagt, okay, da gibt es jetzt ein paar Trends und diese Trends zwingen uns dazu, unser Sicherheitskonzept zu überdenken. Und jeder Rolle sieht das für sich unterschiedlich. Also ein Netzwerker sieht das, okay, wir müssen Netzwerk, Intranet, sind nicht mehr sicher, anfordern Hardware, denken andersrum und an IAM und die ganzen Systemarchitekten, die sagen,
ja, lass mich in Ruhe, wir sind schon sicher. Im Prinzip geht es darum, zu definieren in einem größeren Unternehmen, wie interpretieren wir das, was bedeutet für uns Zero Trust, um nicht in diese Gefahr zu kommen, wie wir früher bei SOA hatten, wo man also ein ESB verkauft und sagt, okay, jetzt hast du eine entkoppelte Architektur, also ein Service. Genau darum geht es. Und wie habt ihr das für euch definiert? Also was habt ihr dann quasi gesagt,
was bedeutet Zero Trust in unserem Verständnis? Erstens mussten wir feststellen, dass wir überhaupt das unterschiedlich gemeint haben. Ich war zum Beispiel für die APIs unterwegs, um die Autorisierung der APIs zu definieren. Also wie machen wir das, weil immer wieder neue Anforderungen kamen und die haben gesagt, wie passt das nicht, es wird ein Chaos geben. Und dann habe ich gesagt, okay, es gibt aber eine Zero Trust-Initiative, die sich jetzt darum beschäftigt.
Dann habe ich gesehen, die beschäftigen sich hauptsächlich mit der IAM, also Identity Provider, ein bisschen Netzwerk, ein bisschen Geräte. Also es ist eine aus der Ecke gekommen, wo die Kollegen herkommen. Dann haben wir uns zusammengetan und gesagt, okay, lasst uns das gemeinsam definieren. Dann haben wir sechs Aspekte zusammengenommen, also das Netzwerk, dann IAM, also Identities, dann Geräte, Daten, Anwendungen und das Thema Monitoring.
Und seit einem Jahr sind wir unterwegs, um genau das jetzt zu finalisieren, auch zu erklären. Es ist ja nicht so, dass man sagt, ja, das ist jetzt so und jetzt macht das jeder. Man muss es ja auch praktisch verkaufen. Das ist ja eine riesige Organisation. Und es ist ja auch nicht so, dass Fachbereich jetzt da steht und sagt, oh, endlich hat jemand neue Features für Security, ich könnte sie jetzt gut gebrauchen. Verstehe. Also Zero Trust ist ja übersetzt quasi kein
Vertrauen. Das heißt, für diese sechs Bereiche oder so was, da geht ihr quasi mit der Idee, da gibt es jetzt quasi kein Vertrauen und da müssen wir was tun. Oder wie macht ihr das? Ja, ich verstehe. Also Zero ist nicht Zero. Das heißt, wenn man jetzt den großen Vätern von Zero Trust zuhört, die sagen ja, always verify, never trust. Aber um etwas zu verifizieren, man muss auf etwas vertrauen, auf die Daten, die ich verifiziere. Bei Zero Trust geht es darum,
dass man keine implizite Vertrauen eingeht, sondern man muss es explizit modellieren. Also zum Beispiel, ich vertraue einem Token von einem Identity Provider. Das ist eine explizite, modellierte Beziehung, die ich auf Vertrauen setze. Und ihr sagt zum Beispiel, ich vertraue nicht dem Frontend und so weiter. Und die Frage ist, also für Zero Trust, welchen Teilen in der Infrastruktur vertrauen wir strategisch, welche nicht? Und dementsprechend, es ändert sich für
die Architekten, indem sie, wir haben bis jetzt nur Datenflüsse betrachtet und so weiter. Das bleibt ja noch. Die logische Sicht, die Ablaufsicht, die Pläne und so weiter. Und jetzt kommt immer dazu, wir müssten auch immer dazu mit modellieren, was ist der Vertrauen? Also an wen vertraue ich da? Naja, verstehe. Also das macht das Ganze expliziter, auch diese Prüfung. Und auch dein Vortrag, der geht ja auch sehr viel um eure Erfahrung, dann quasi diesen Weg zu gehen.
Nimm uns da mal so ein bisschen mit auf die Reise. Wie seid ihr dann rangegangen und was sind so die Kernpunkte, die ihr dann so auf dem Weg auch dann entdeckt habt oder erfahren habt? Okay. Erstmal haben wir einige Probleme festgestellt. Weil so dieses pragmatische Vorgehen, wo man sagt, okay, ab jetzt schicken alle Applikationen an die APIs ihrer Identity Tokens mit. Also die Identity. Und die müssen das jetzt prüfen. Dann haben wir geschaut, da sind 30 Stück,
alleine schon für Employees. Und dann kommt noch B2B und B2C. Wenn wir jetzt anfangen, in den APIs, denen zu vertrauen und die zu verstehen, haben wir am Ende genau das gleiche Chaos, was wir jetzt mit den API-Gateways auf der API-Ebene versuchen zu verhindern. Okay, also die erste Maßnahme war, ja, wir müssen jetzt Identity Provider aufräumen. Das heißt, von 30 auf 3, also in die strategischen. Erstmal identifizieren, dafür sorgen,
dass sie auch moderne Protokolle unterstützen, dass man sie auch nehmen will. Und das war dann eigentlich ganz gut. Also das war die erste Maßnahme. Da war auch vom Management viel Unterstützung. Gerade Audit ist gelaufen und das war schon ein Haufen. Also wenn Audit da ist, dann ist alles gut. Und da gab es ein Programm, und viele sind jetzt schon in die Richtung von strategischen Identity Provider gegangen. Das war so der erste Schritt. Der zweite ist,
es gibt auch vom Management getrieben, dass unsere Geräte ins Internet gehen. Das heißt, nicht defaultmäßig ins Internet, sondern ins Internet. Und dann mussten wir jetzt daraus ableiten, was bedeutet das für die Applikationen. Und jetzt geht es darum, okay, wir haben jetzt mehrere Landing zones, okay, und die haben ihre Schutzmechanismen mal hoch, mal weniger hoch.
Jetzt müssen wir dafür sorgen, dass wenn die Applikationen da drauf sind, was können wir denen bereitstellen, zumindest auf der Infrastruktur-Ebene, dass die einfach internetfähig sind. Das ist ja halt nicht trivial. Also es ist nicht die Frage, ob man angegriffen wird, sondern wann und wie stark. Und das sind jetzt Schritte nach den Schritten. Wo ich jetzt intensiv reinschaue, ist am API Gateway. Dort wollen wir genau diese
Token standardisieren. Und es gibt ein Team, was sich damit beschäftigt, um die Policies für diese Autorisierung zentral zu verwalten. Und wir haben jetzt Release diese Woche, einen weiteren Milestone. Ich bin jetzt gespannt, wie kriegen wir das jetzt in der Organisation weit. Die ersten Proof of Concept sind gelaufen. Also im Prinzip ist es immer ein Schritt nach dem anderen. Wir bauen
Enabler, es kommen immer mehr Consumer drauf. Dann geht immer der Nisch. Also gegen BANG wird es nicht funktionieren. Ja, ja. Was sind denn da auf diesem Weg dann so die großen Herausforderungen? Also das läuft ja wahrscheinlich nicht so einfach durch alles. Wo habt ihr dann, werdet ihr dann auf dem Weg, da müssen wir doch ein bisschen mehr machen oder da sind so ein paar Hindernisse, die man bearbeiten muss? Naja, sagen wir so, ich komme in so ein Team rein und sage, okay, Zero Trust erklären.
Ja, also schön, aber wir sind schon sicher. Also wir sind schon Zero Trust. Und dann fängt man an zu fragen, okay, was sind denn eigentlich eure Vertrauen, also zu wem vertraut. Und dann A, B, C, D. Und dann malt man das auf und sagt, okay, guck mal, pass auf, das ist jetzt, wer mir jetzt vertraut. Habt ihr mal gecheckt, dem System, dem ihr vertraut, was ist das für eigentlich eine Sicherheitsstufe? Also wie gut ist das geschützt?
Nee. Na gut, also dann ist ungefähr euer Sicherheitslevel genauso wie von dem. Und dieser Mind Change ist nicht so ganz trivial, weil das ist genau wie auf der Konferenz. Man hört etwas zu und denkt, okay, es ist schön, aber wenn man dann wieder zurückkommt, dann kommt der Druck mit den Features. Und dann, ja, Security,
ja, müssten wir machen, aber wir sind eigentlich ganz gut. Und das ist der Mind Change, das zu ändern, dass wir sagen, okay, wir haben die gleiche Herausforderung wie bei den APIs-Managements früher. Da müssen wir jetzt aufpassen, dass wir das auf der Token-Ebene, Autorisierungsebene, nicht die gleiche Kopplung erreichen. Und ja klar, also Security steht immer im Kampf gegen Features.
Ja, ja, ja. Und wenn ihr dann quasi entscheidet, was da geändert wird, wird das dann im normalen Entwicklungsprozess mit bearbeitet, als im Agilent, zum Beispiel als User Stories oder so was, dass es dann auch mit reinkommt? Oder wie bringt ihr das in den Prozess rein? Oder ändert ihr den Prozess dadurch? Ja, verstehe. Also erstens, wir haben Enabler. Die sagen, okay, wir haben so einen Sidecar, du kannst es dir vorstellen, dann kannst du bestimmte Autorisierungen machen. Es ist aber
nicht so, dass eine Domäne für sich erstmal nichts machen muss. Sie muss etwas bereitstellen, die Daten für die Autorisierung und so weiter. Und es ist ein Mix daraus. Erstmal wollen wir den Systemarchitekten oder den Hub-Architekten haben und sagen, pass auf, das ist jetzt, das kommt jetzt, bald wird diese Anforderung bei dir sein, lass uns mal schauen, wie kriegen wir das hin. Und wir wollen ja auch nicht so, dass jedes Team anfängt, für sich den gesamten Infrastrukt
aufzubauen. Deswegen ist die Frage, auf welcher Ebene ich standardisieren, je weiter nach oben, umso länger es dauert und so, je mehr aufwendiger es ist und je weiter nach unten, umso schneller und pragmatischer. Also im Prinzip landet das als Story, aber auf unterschiedlichen Ebenen. Also es fängt immer auf dem System oder Hub-Ebenen und dann kommt es zu den Teams.
Weil wenn wir nichts machen und es direkt bei den Teams landet, weil jetzt der Security Officer sagt, du musst jetzt ab morgen das machen, dann wird es einfach Chaos geben. Ja, genau. Wie wählt ihr denn aus, wo ihr beginnt? Also ihr habt ja jetzt nicht nur ein System, ihr seid ja ein Riesenladen. Und da muss ja irgendwo anfangen. Und ich glaube, viele große Unternehmen haben das, die haben tausende Systeme, wo geht es eigentlich los?
Welche Strategie habt ihr denn genommen, zu entscheiden, okay, hier legen wir mal los. Was waren denn da so die Kriterien? Okay, es sind eigentlich zwei. Das erste ist von den Daten. Auch die Vierter von Sero Trast sagen, die Cronjuwelen schützen. Also man sagt, diese Daten sind besonders schützenswert und wir gucken dort rein. Und das andere ist immer dann, wenn man eine Initiative in einem großen Laden macht, dann man versucht, eine Business-Initiative
zu finden, sodass man eine Win-Win erreicht. Alleine ist es immer schwierig, so eine zu machen. Und dann ist es so, wir haben im Moment eine Initiative, die versucht, die Kosten bei den Applikationen runterzufahren, wo die Datenschutzanforderungen zu hoch sind. Und das passiert immer dann, wenn man auf einmal Daten konsumiert, die eine höhere Schutzklasse haben. Und dann darf man den Betrieb nicht in der Public Cloud machen, man darf ihn aus Deutschland machen,
weil die ganzen Kosten. Und jetzt kommt man auf die Idee, okay, wie sieht es aus, brauche ich wirklich diese Daten? Kann ich die aus dem System rausnehmen und dann einfach eine Stufe runtergehen? Und genau dort, wo Cost Savings sind, kommen wir dazu, ich helfe dir, das zu machen, sodass du das auch sicherstellen kannst. Nicht nur irgendwie, ich verspreche das, sondern es ist wirklich so nachvollziehbar. Also zwei Sachen. Einmal, was ist von den Daten her,
das Wichtigste? Und das Zweite ist, was sind so die Business-Initiativen oder Savings-Initiativen, wo man sagt, okay, da haben wir eine Win-Win-Situation. Wenn du jetzt dann so zu den Teams kommst und sagst, so wir machen jetzt hier Zero Trust. Für dich ist ja, sie sagen dann häufig, ja, machen wir eh schon alles. Wie kriegst du denn dann, sagen wir, das Mindset da geändert? Oder wie argumentierst du dann da, nee, wir müssen da doch ein bisschen mehr drauf schauen?
Eine sehr gute Frage. Ich habe gelernt, dass, wenn man fragt, kommt man weiter, als wenn man Statements abgibt. Meistens sagt man, okay, du bist schon sicher, erzähl es mal. Und dann erzählt er und dann sagst du, okay, aber wie machst du das? Wenn du das machst, dann denke ich an das, machst du das? Oh, stimmt, an das habe ich auch nicht gedacht. Also es funktioniert nicht immer, aber dieses typische Chief Architect, Senior Enterprise
Architekt und deswegen müsste das machen, das funktioniert selten. Also im Prinzip, man versucht hier zu überreden. Und es ist immer so, es gibt einen Druck von Datenschutz und Informationsschutz und dann kommt man und sagt, ich helfe dir. Und guck mal, das ist der Enabler und ich verbinde dich da und so weiter. Ja, okay, also das kann ich gut mit dir, also über Fragen und quasi über die
Unterstützungsleistung das anzubieten und dann auch mit zu integrieren. Das Ziel ist ja, denke ich auch, dass die Teams ja das irgendwann einmal auch in ihrer DNA dann drinnen haben, da so zu denken. Also die da auch so hinzubekommen. Jetzt ist es ja so, ihr seid ja da jetzt schon einige Zeit lang auch auf dem Weg. Was sind denn so die Meilensteine, wo du sagst, okay, da muss noch mehr passieren oder das sind so die nächsten Themen in dem
Bereich Zero Trust, die wir noch angehen müssen? Ja, im Prinzip, wir haben jetzt ein Konzept und Proof of Concepts, wo es um die Enabler sind, schon in einem guten Zustand. Jetzt geht es darum, in die Breite zu bringen und das ist eine Herausforderung. Wo ich noch keine Antwort habe, ist, wie kriegen wir das mit den unstrukturierten Data Lakes hin? Also wir haben hier Domänen, unsere APIs, die sind ganz gut strukturiert, das ist alles cool und da können
wir auch relativ gut mit Policies autorisieren. Und dann kommt einer und sagt, wir wollen für Business Mehrwert schaffen, deswegen schmeißen wir alle Daten in einen Lake und dann kann man da super Daten aufgreifen. Wenn die nicht strukturiert sind, wie kann ich die dann wirklich auktorisieren? Deswegen sind nicht alle Konzepte auf einer Ebene da, aber es geht erstmal verstehen, eine Strategie zu haben, Enabler zu haben und dann parallel mit Enablern das in die Breite zu bringen.
Und wir sind gerade jetzt in die Breite zu gehen. Wenn du jetzt unseren Hörerinnen und Hörern einen Tipp geben müsstest, wo beginnen, womit beginnen? Einige, die sich ja auch mit dem Thema Security mehr auseinandersetzen und so in den Teams sind, denken, das wäre vielleicht auch ein Konzept, wo wir mal uns Gedanken machen sollen. Was würdest du so als Startpunkt mal sagen,
fangt mal an, euch damit zu beschäftigen? Ja, das war meine Herausforderung. Ich bin ein Frontend-Architekt, also habe meistens Frontends, größere Systeme gebaut, die bei Default im Internet sind. Also so ungefähr. Ich hatte so den Mindset. Und irgendwann mussten wir APIs konsumieren und dann haben wir gesagt, irgendwie stimmt das nicht, irgendwie müssen sie zu viel Aufwand machen. Und dann gab es den Auftrag von Chief Architekt, Architektin damals,
die hat gesagt, Waldemar, mach ein Konzept. Wie sieht es aus? Und wie fange ich an? Und dann habe ich gesagt, ich mache das ganz, ich gehe ganz zurück. Ich bin eine API, was brauche ich? Ja. Also ich setze mich auf die API drauf und gucke, was brauche ich, um autorisieren zu können. Was muss ich für Daten haben, in welcher Qualität und wie schnell und wie komme ich an die Daten? Da kommen natürlich diese Latenzen und so weiter, die Fragen, die kommen danach. Aber man fängt immer
dort an. Ich bin der erste Punkt, wo ein fremder Request reinkommt, also böse. Also dort, wo meine Trust Boundary aufhört, ich bin dort. Was muss ich da bereit haben und wem vertraue ich, um weiter zu gehen? Und das war meine Anfangsphase. Und dann haben wir natürlich mit Gartner und Co. gesprochen, was machen sie, Konzepte geschärft, bis wir zur Entscheidung gekommen sind. Aber vielleicht der Schritt davor ist, zu erkennen, dass Zero Trust ein Passwort ist. Man muss es definieren. Also
das war für mich so, ja, ist doch klar, dass man machen muss. Und dann so der andere, ja, aber ich verstehe es anders. Und ich auch. Und das war so, okay. Also man hat immer so dieses Common Sense immer weiter nach unten gesetzt, bis man gesagt hat, jetzt müssen wir ganz vorne anfangen. Ja, genau. Okay, also mal zu beginnen, einfach mal zu definieren für sich auch, was heißt denn eigentlich Zero Trust in dem Kontext, in dem Unternehmen, in dem Team, in dem man auch agiert.
Das ist, glaube ich, ein guter erster Schritt. Und dann zu schauen, okay, wo kann ich, wo habe ich so meine Boundaries, wo kann ich dann auch beginnen. Ja, super. Waldemar, vielen lieben Dank für diese Einsichten, für diese Inspiration. Wir haben ein bisschen was gelernt über Zero Trust. Für mich war es bis jetzt auch nur ein Passwort. Ich würde mir also gar nicht viel darunter vorstellen. Deswegen finde ich es schön, dass wir darüber gesprochen haben auch. Und ja,
ich wünsche dir noch ganz viel Spaß auf der OOP. Viel Erfolg morgen für deinen Vortrag. Danke. Und ja, bis bald mal. Danke. Danke. Gute Einladung. Gerne. Bis bald. Sehr schön. *Musik* Untertitel von Stephanie Geiges