Zero Trust Security mit Jörn Stenkamp

Hallo und herzlich willkommen, liebe Hörerinnen, zu einer neuen Folge der Programmier.bar. Wir reden heute über Zero Trust Security. Und das tun wir mit jemanden, den ihr schon mal gehört haben könntet in unserem Podcast. Jörn Steenkamp Herzlichen Dank für die Einladung. Danke Dennis. Schön, dass du da bist und. Wieder hier zu sein. An meiner Seite, der Sebi, Sebi, der ist auch dabei. Und ja, tatsächlich sind wir hier ganz lokal in einem echten Raum und nicht remote connected. Denn du hast heute Abend auch noch die Aufgabe, das Meetup mit dem Thema zu bespielen. Also genau. Da. Für bist du schon ein bisschen früher vorbeigekommen, damit wir heute noch diese Aufnahmen machen können. Vor allen Dingen, um auch mal euer schönes Office zu sehen hier im schönen Bad Nauheim und muss sagen, ich bin extremst begeistert. Sehr schön, das freut uns. Ganz kurz zu dir, Jörn. Man könnte natürlich jetzt auch die andere Folge nachhören. Haben wir ein bisschen schon über dich geredet, als Wie beschreibst du deinen Job? Oh, das ist eine gute Frage. Also ich bin Mitarbeiter der Firma HashiCorp HashiCorp kennt man unter Umständen, wenn man im Cloud und Bereich unterwegs ist für die Tools wie Terraform, World Wide Background, Packer usw.. Also wir sind im Prinzip eine Software Open Source Company mit Enterprise Support. Das ist das, was wir so machen. Und meine Rolle ist Solutions Engineer. Das heißt, ich helfe dabei, dass unsere Partner und unsere Kunden die Technologie verstehen und den Mehrwert daraus erkennen können. Und ich versuche natürlich dann auch beratend tätig zu sein und zu sagen, wie man unsere Tools sinnbringend und weltstiftend in Organisationen einsetzen kann. Also perfekt eigentlich, um im Podcast darüber zu sprechen, was ihr das, was ihr da macht, Cool. Sehr schön. Zero Trust Security. Sicher ein Thema, von dem ich noch nicht so wahnsinnig viel weiß und es einfach mal ein Begriff ist, der irgendwie hier und da mal jetzt aufploppt. In der Vergangenheit Zero Trust zumindest. Also ich vertraue niemandem oder habe kein Vertrauen. Ist so das, was man aus dem Wort rauslesen kann auf einem hohen Level. Wie würdest du jemandem erst mal grundsätzlich erklären? Worum geht es bei Zero Trust Security? Deine Interpretation ist schon ziemlich gut. Also das ist genau der Punkt, dass man nichts und niemanden per se vertraut, sondern bevor ich Zugriff auf Informationen gebe, dass ich im Vorfeld den Anfragen dann einen Punkt Authentifizierung und autorisieren sprich auf Grund der Eigenschaft oder auf Grund des Ortes, wo sich jemand befindet, bekomme ich nicht automatisch den Zugriff auf Information. Wenn wir das klassisch wieder betrachten Wie gesagt, die IT ist gerade im Umbruch. Wir kommen ja aus einer traditionellen statischen Infrastruktur, wo Unternehmen ihre Applikationen im Rechenzentrum gehostet haben und gehen jetzt mehr in eine hybride Cloud, Multi Cloud oder in eine Cloud Native welt, wo ich eben die Infrastruktur nicht mehr besitzen muss, um ein IT Service, ein Webservices, Datenbankservice damit zu gestalten. In der Vergangenheit haben wir zum Beispiel die Identität von einem Server, sagen wir einen Webserver daran festgemacht, welche IP Adresse dieser Server hat. Wenn wir jetzt aber in die Cloud gehen und die Cloud Native elastizität auch benutzen wollen, dann ist die IP Adresse eigentlich nur ein Attribut eines Servers, aber nicht etwas, was in Stein gemeißelt ist. Das heißt in dem man vielleicht auch die Vorteile von Cloud benutze, möchte ich ja auch die Vorteile der Elastizität einer Cloud benutzen. Was bedeutet, ein Workload ist eigentlich immer relativ auf die Größe abgestimmt, die auch gerade gefordert wird. Sprich ich kann relativ einfach eine Cloud machen und aus drei Server 30 machen und ich kann auch sehr schnell wieder das runterskalieren und aus 30 wieder drei machen, weil ich die Last gerade nicht habe. Das hat aber immer zur Folge, dass wenn ich jetzt drei oder fünf oder zehn mehr Server habe, habe ich auch 3510 mehr IP Adressen, die ich aber im Vorfeld nicht kenne. In der klassischen Welt kann ich die IP Adresse und habe die IP Adresse immer als Basis meiner Kommunikationsbeziehung genannt. In der Cloud habe ich da nicht mehr unmittelbaren Einfluss drauf. Und genau das ist die Grundlage, warum wir jetzt so etwas brauchen. Weil diese Dynamik kriege ich nicht mehr abgebildet mit den klassischen Netzwerk Perimeter Kontrollinstanzen wie Firewalls und Load Balance und Co.. Das hat immer als Basis eine statische IP Adresse, die im Vorfeld bekannt ist, zur Folge, um das sauber zu machen. Also das Konzept muss man viel bedenken, wenn es um Skalierung dynamische. Umgebungen geht? Oder ist es auch was, was man auf. Selbst wenn man einfach nur, sagen wir mal man fährt eine Infrastruktur hoch, hat fünf Dienste und und die laufen erstmal so, ist es dann auch relevant oder hat es viel mit der Dynamik zu tun, die in der Cloud passieren kann? Das sowohl als auch, weil der Zwitter. Ich mache immer den klassischen Vergleich, der ist ja schwarz und weiß und nicht immer zutreffen in jeder Erscheinungsform. Aber man kann damit anhand dessen natürlich sehr gut die Beispiele exemplarischer machen und nachvollziehbarer. Noch mal im klassischen Rechenzentrum Umfeld habe ich eine IP Adresse und sobald die einmal in der Firewall drin steht als gesicherte IP Adresse bleibt sie da immer drin. Das heißt, wenn das IT Service jetzt auch 123 Jahre bestehen bleibt, wie diese IP Adresse nie wieder überprüft und der klassische Angriffsvektor auch in diesen Umgebungen ist ja, dass jemand reinkommt oder Zugriff auf ein geschütztes System bekommen hat, warum auch immer und damit kompromittiert hat. Und damit hatte ich Zugriff auf die ganze Umgebung unter Umständen. Problem daran ist, dass ich ja nur einmalig in der Firewall die Autorisierung programmiert habe, dass ein IT Service A mit B sprechen kann über die IP Adresse Zero Trust jeden anderen Weg, nämlich dass ich diese Autorisierung regelmäßig überprüfe, wie Zertifikate zum Beispiel. Das heißt, ich gebe nur einen Endpunkt für einen Tag oder eine Woche frei und danach muss der sich neu authentifiziert, um wieder an dieser Kommunikationsbeziehung teilhaben zu können. Ganz generell die Frage. Wir haben ja Technologien, die wir irgendwie hier in dem Podcast besprechen Was ist der Zero Trust letztendlich? Also ist das einfach, Ist das, gibt es das irgendwie als greifbares Dokument? Gibt es da irgendjemanden, der festgelegt hat, So, das sind jetzt Standards und das nennen wir Zero Trust. Ist das einfach etwas, was sich entwickelt hat? Ist das was eine Art Richtlinie oder gibt es auch tatsächlich ein Tool oder ein Produkt, was dahinter. Steht? Gute Frage. Also es ist genau kein Tool und ist auch kein Produkt, sondern ist ein Architektur Guideline nach auf Grundlage oder mit dem Namen Zero Trust. Und dieses Diese Guidelines bestehen aus wenigen Prinzipien, die man sozusagen damit einführt. Und soll man das eine oder erste Prinzip haben? Im Prinzip schon genannt. Das ist Vertrauen, nichts und niemanden Authentifizierung und autorisiere alles. Ein zweites prinzipiell ist prinzipiell auf List privilege, das heißt ich gebe nur die Information frei für den Endpunkt, die relevant sind, aber nichts darüber hinaus. Und dann gibt es noch einen dritten, das Prinzip. Das klingt jetzt schon fast widersinnig. Das ist das Young Bridge. Also egal, wie wir heute das definieren wollen, das 100 % sichere Netzwerk gibt es nicht. Das ist eigentlich ein Konstrukt, das in der Natur nicht vorkommt, wieso auch hundertProzentige Lösung in der Natur eigentlich nicht vorkommen. Es gibt immer Wechselwirkungen, die ich nicht bedenken kann oder im Vorfeld bedenken kann, die später einen Einfluss haben. Beispiel eins ist Egal welche Software ich einsetze im Unternehmen, egal welches Betriebssystem, Es ist eigentlich immer nur eine Frage der Zeit, bis an irgendeiner Stelle ein Wollen oder Ability bekannt wird und dann auch eine Schwachstelle in dieser Software ist. Genauso kann ich Menschen auch nicht vertrauen, weil Menschen per se nicht vertrauenswürdig sind. Aber Menschen machen Fehler, Menschen bringen human error darein. Menschen können abseits sein, in einer Organisation sagen Ich möchte mich jetzt rächen. Es ist nur eine Spielart. Grundsätzlich Menschen sind fehleranfällig, da bin ich auch keine Ausnahme. Bist du keine Ausnahme. Wir machen halt alle Fehler. Wenn wir schlecht geschlafen haben, kommt dieser menschliche Fehler mehr zum Tragen. Gibt es dazu ein aktuelles Gegenmodell? Also wenn wir sagen, eine Vergangenheit aus der Vergangenheit oder von früher, vom klassischen Modell, so gesprochen kommen wir hin zu, Hat sich das in ein anderes Modell Zero Trust involviert. Wenn ich jetzt also ich habe halt nur das Beispiel mit der Google Cloud wo wir mit Service Accounts und Authentifizierung also so viel machen wir damit nicht aber gibt es also außer Trust im Cloud Umfeld noch ein anderes Paradigma? Mir nicht wirklich bekannt, weil sie wo Trust ist, glaube ich gerade das, was aktuell die meiste Traktion auch in der Industrie gerade hat, zum Beispiel selbst die amerikanische Regierung baut jetzt ihre Systeme auf Trust um. Das heißt, selbst diese behördlichen Strukturen nehmen an dieser Initiative teil und nutzen auch diese als Grundlage für Security. Und ich glaube, der Kernpunkt, dass er das immer noch oder viel versucht wird mit dem Wissen der Vergangenheit, was sehr infrastrukturlastig. Statisch und Rechenzentrum lastig war. Die Prinzipien zu benutzen und heute auf die Cloud Infrastruktur zu übertragen. Und das ist genau das Problem. Was glaube ich viele Organisationen haben ist sie sind so, nur viele agil. Also es machen sie einen Wasserfall agilen Ansatz, sprich Sie schaffen es innerhalb von Sekunden und Minuten in Ihrer Privat oder Public Cloud Infrastruktur Ressourcen zur Verfügung zu stellen, brauchen aber danach weitere vier oder sechs Wochen, um die Firewall freizuschalten, um Netzwerk und Security da drauf zu kriegen. Und das ist eigentlich dieses klassische wasserfall prozessuale Modell, was wir aus der Vergangenheit kennen, was sich aber relativ schlecht bis gar nicht in die Cloud übertragen lässt. Und grundsätzlich also die drei Prinzipien, die das da genannt hast, so erstens man muss sich identifizieren. Zweitens Man soll möglichst wenig Informationen teilen. Und drittens Es kann immer was passieren. Das hört sich ja irgendwie so an, als wäre das etwas, womit man tagtäglich schon irgendwie umgeht. Oder zumindest das, Wenn wir, wenn wir jetzt irgendwelche Cloudanbieter Namespaces Google Cloud, was auch immer, so ist das da eigentlich schon in den Prinzipien standardmäßig drin und es ist eher was, wenn man von klassischen Strukturen migriert oder irgendwie so was oder gibt es da auch dann Dinge, die man, die man anders machen könnte, wenn man Zero Trust kennt und darüber nachdenkt? Ich glaube, darum geht es ja viel, dass man dann einfach in den entscheidenden Situationen das so ausrichtet, dass nach den Prinzipien gehandelt wird. Ja. Also alle Cloud Provider haben natürlich auch so was als Prinzip in ihrer eigenen Umgebung. Das steht außer Frage. Die Herausforderung kommt dann häufig nur, wenn ich mehr als einen Cloud Provider Verwendung. Und dann kann ich die SEO Trust Prinzipien, die Identität, die ich eigentlich brauche und die eine gesicherte, eine digitale Identität, die ich dafür benötige, nicht unbedingt sicherstellen, über mehrere Cloudprovider Grenzen hinaus. Klassisches Szenario Ich bin Hybrid Cloud Kunde und habe mein Preact Data Center und möchte jetzt ein oder die andere Cloud mit hinzu benutzen. Oder Multi Cloud. Ich habe nicht nur einen Cloud Provider, sondern zwei oder drei in Benutzung. Dann habe ich die Herausforderung. Wie komme ich denn auf eine gesicherte, ein eindeutige digitale Identität? Weil Identität ist ja im jeden Cloud Provider sozusagen immanent. Aber außerhalb des Cloud Providers nicht unbedingt. Und das ist im Prinzip genau das, was wir von HashiCorp machen. Wir schieben die Komplexität aus einem Technologiebereich höher und agieren als Broker zwischen den ganzen Cloud Providern, zwischen allen Systemen, die Identität zur Verfügung stellen können. Das beinhaltet die Cloud Provider selber. Das beinhaltet aber auch, dass Systeme wie Octa oder Active Directory oder Elder oder Ping. Also es gibt eine große Anzahl unterschiedlicher Identitätsprovider. Und mit Hilfe der Tools, die wir zur Verfügung stellen, können wir aus der Varianz der unterschiedlichen Technologien eine einheitliche digitale Identität, überprüfbare Identität zur Verfügung stellen. Und diese Identität kann dann alles Mögliche sein. Also das kann ein Nutzer sein, der sich irgendwie ins System einloggt. Es kann aber auch ein Service oder ein Dienst sein, der auf irgendeinem. Cloud, was auch immer. Läuft. Korrekt. Absolut richtig. Also man kann unterscheiden in zwei große Use Cases. Es gibt so die Maschine zu Maschine Kommunikation. Das ist das, was wir klassischen Netzwerktreffen nennen. Das andere ist eine Mensch Maschine Kommunikation. Was ich vielleicht mal brauche zum Backen. Aber das ist ein anderer Use Case. Beide Use Cases bedienen sich aber denselben Prinzipien. Das heißt, egal ob ich Mensch bin oder Maschine, ich brauche eine eindeutige Identität als Basis der Vertraulichkeit. Ich muss sozusagen die Identität verifizieren, überprüfbar machen. Um darauf aufbauend die nächsten Schritte zu gehen. Wenn ich mich innerhalb eines Jahres in meinem Kopf innerhalb eines Projekts bewege, dann stellt der Cloudprovider das eigentlich sicher. Ja, korrekt. Wenn ich hier oder da Multi Cloud betreibe, dann habe ich ein Problem, weil ich dann die Identität nicht sicherstellen kann von den Anfragen. Wenn ich von einem Rechenzentrum auf die Datenbank von anderen zugreifen möchte, wer greift eigentlich gerade drauf zu? Dann habe ich zumindest die Herausforderung, genau das zu lösen. Gut. Und da vertraue ich erst mal niemandem. Zero Trust. Okay, sehr gut. Wie kann ich denn jetzt die Identität feststellen? Der klassische Ansatz ist, Wenn ich wieder einen Vergleich mache, statische oder on PremysInfrastruktur und Cloud, dann kann ich das so darlegen wie früher, um eine Identität zu überprüfen. Und ich fange ich bei mir als Mensch an. Dann ist mein Identitätsdokument ein Personalausweis. Das ist eine relativ aufwendiger Prozess, um zu einem Ausweis zu gelangen. Und das ist ein sehr sicherer Prozess, weil dafür muss ich behördliche Institutionen, die Kommunalverwaltung beauftragen, zu sagen Hier bin ich. Das mein alter Ausweis ist mein Lichtbild. Die machen das in einem schönen Formular, schicken das zur Bundesdruckerei. Das ist sehr fälschungssicher. Sprich ich bekomme ein Identitätsdokument zurück, das ja auch ein Time to live hat. Ein Ausweis ist fünf oder zehn Jahre gültig und dann brauche ich ein neues. Der Prozess, um zum Ausweis zu kommen, ist ja fälschungssicher. Darum ist natürlich die Überprüfung eines Personalausweises eine klassische Authentifizierungsmethode für Menschen. Sprich wenn ich die Identität von Menschen überprüfen möchte oder verifizieren möchte, dann geht das hervorragend mit einem Identity Document in Form eines Personalausweises. Die Überprüfung ist aber in aller Regel jetzt ein manueller Schritt, denn ich muss meinem Ausweis ja irgendeiner anderen Person zeigen, die das überprüfen kann, dass das stimmig ist, um dann darauf hin, mich zu irgendetwas zu autorisieren. Beispiel, mir Zugang zu meinem Hotelzimmer zu geben. Oder wenn wir uns nicht kennen. Bevor ich hier reingehe, könnte ja jeder reinkommen und sagen Ich bin hier und den Kampf darüber könnte ich mich jetzt ausweisen und die Authentizität meiner Person sicherstellen. Bei Maschinen sieht das ein bisschen anders aus. Ja, natürlich, kein Personalausweis. Aber ich brauche natürlich eine Möglichkeit, das zu überprüfen. Das heißt, in Maschinen gibt es in aller Regel schon eine digitale Signatur, ein Zertifikat zum Beispiel, um das zu tun. Oder es gibt die sogenannten Identity Access Management Systeme. Klingt schon wieder schwierig. Ist es gar nicht. Das ist schlichtweg so was wie die Google Cloud oder AWS oder E Mail. In diesem System ist hinterlegt, welcher welcher Instanz, welche Infrastruktur zu welchem Kontext gehört. Und wen frage ich dann? Oder wie sieht dieser Prozess aus? Ich weiß gar nicht, ob wir jetzt eher von Ich will mich identifizieren oder ich bekomme eine Anfrage und will überprüfen, von welcher Seite wir es aufziehen. Ja. Also um die Identität eines Clients automatisiert überprüfbar zu machen, muss ich natürlich in ein sogenanntes Single Zeichensystem oder in einen Identitätsprovider. Das ist zum Beispiel Active Directory. Das heißt, wenn ich mich jetzt in einem Unternehmen skontext an meinen Arbeitsplatz begeben möchte, ist zum Beispiel die Grundlage, dass ich im Vorfeld natürlich einmal ein Onboarding hatte, um in dieses Active Directory reinzukommen. Über Ich bin ein Mitarbeiter, ich gehöre der Abteilung XY an und bin jetzt on the border und bekomme in Form von Usern ein Passwort oder noch einen Ausweis im Unternehmen oder ein Multifaktor, was auch immer das ist. Aber jetzt kann ich meine Identität über diesen Identitätsprovider überprüfen lassen. Automatisiert. Ich halte nur meine Karte vor das Kartenlesegerät. Ich. Bevor ich anfangen kann mein Bildschirm zu entsperren, muss ich meinen Username Passwort eingeben, vielleicht auch noch eine Art Karte hinzufügen. Das sind aber alles jetzt Dinge, die ich genau über so ein Active Directory überprüfen kann. Und damit kann ich aber die Identität. Automatisiert überprüfen. Ich brauche nicht mehr diesen Menschen in der Mitte, der das über den Personalausweis macht, sondern das kann ich jetzt über einen Identitätsprovider automatisieren. Wie gesagt, Maschinen haben jetzt keinen Personalausweis und müssen auch nicht unbedingt im Directory sein. Maschinen sind zum Beispiel bekannt innerhalb eines Cloud Providers. Jetzt kann ich aber, wenn sich eine Maschine irgendwo anmelden, sagt ich bin Maschine XY und Z auch ausweisen und zwar mit dem digitalen Zertifikat, was ich vom Cloud Frau weiter komme. Damit kann ich natürlich wieder die Identität einer Maschine automatisiert überprüfen. Jetzt hat man mir gesagt, wenn ich diesen Scale out mache, dann weiß ich ja nicht, oder? Dann müsste ich dieses Zertifikat von einem potenziellen neuen Webserver irgendwo registrieren oder oder wissen, dass der ist. Den hatte ich ja vorher noch nicht. Der ist ja jetzt wahrscheinlich ganz neu oder so. Und habe ich dann nicht das gleiche Problem wie mit der IP Adresse? Nicht wirklich, denn in dem Moment wo wir heute Infrastruktur Ressourcen zur Verfügung stellen, machen wir das ja nicht mehr per point and click, sondern wir machen das in aller Regel über eine Infrastruktur aus Code Pipeline CLI Prozess. Das ist alles, was wir heute generieren. Besteht ja im Prinzip nur aus Software Deklaration und nicht mehr aus direkt menschlichen Einfluss auf Ressourcen. Wenn ich das mache, habe ich für den menschlichen Fehler mit in die Ressourcen reingebaut und ich muss am Ende das Ergebnis überprüfen. Das ganze aber per Infrastruktur aus Code automatisiert kodifizierten mache und das einmal funktioniert hat und überprüft wurde. Und dann kann ich das halt unendlich reproduzieren. In dem Moment, wo ich aber eine Pipeline habe, Kontrolle über die Pipeline, auch die Ressourcen, die ich zum Beispiel brauche, die ich, wo ich ein Skalout mache, die ich verändern möchte. Über den Weg kann ich natürlich auch über diesen Pipeline Gedanken gleich das richtige Zertifikat oder die richtige Identität mitbringen oder gleichzeitig die Überprüfbarkeit der Identität der Ressourcen mit einbauen, damit ich dann im nächsten Schritt genau diesen Ansatz wieder fahren kann und die Identität als Basis für alle weiteren Schritte nehmen kann. Macht Sinn. Doch macht so eine, dann ist das mit einer Pipeline drin, dass die Menschen irgendwo sich bekannt machen oder so.. Selbst wenn es nicht in der Pipeline ist, also nicht so Bild Time schon mit drin ist, kann ich. Es. Auch zur Runtime integrieren, indem ich jetzt sage kommt eine Maschine als Prozess, weil ich nur den prozessualen Schritt mal versuche zu abstrahieren. Kommt jetzt eine Maschine, die kommt von CloudProvider? A hat folgende Tags oder Informationen, die sie mir mit bietet, so dass ich die Identität dieser Maschine eineindeutig überprüfen kann. Notfalls schlichtweg jede Instituinstanz Scientia im System. Und dieses Zertifikat kann ich ja überprüfen. Damit habe ich ja gleich meine digitale Signatur, um eine Maschine zu überprüfen. Auf Basis dieser Überprüfung dieser Authentifizierung kann ich dieser Maschine jetzt sagen Du kriegst genau dieses Zertifikat, um an andere sensitive Informationen ranzukommen bzw. Bestandteil eines Service Mesh zu werden. Im Sinne von Die Maschine ist ein Webserver und darf jetzt eine Datenbank Server anfragen für Content. Ich glaube, der entscheidende Punkt ist immer, dass das ganze Fundament von Zero Trust baut auf die überprüfbare Identität auf Identität. Ist the way out of trust. Als Parallelbeispiel kann man immer nur sagen Jetzt stellen wir uns vor, wir haben irgendeine Datei in Klartext, Die wollen wir mal verschlüsseln, also geheim halten. Jetzt kann ich natürlich einfach Kryptografie benutzen, um diese Datei zu verschlüsseln. Dann habe ich aber wieder ein Geheimnis, nämlich den Kryptographie Schlüssel. So. Jetzt kann ich dir natürlich sagen wie die muss ich mich schützen? Dann packe ich jetzt diesen Kryptographie Schlüssel in einen statischen alten Metallschrank mit schöner Zahlenkombination. Da ist der schon drin. Und das hat zur Folge, dass ich wieder ein neues Geheimnis habe. Nämlich jetzt habe ich den Pin Code oder die. Die Kombination dieses Safes muss ich ja wieder irgendwo schützen. Das kann ich jetzt eigentlich unendlich weiterspielen, bis ich final an die Person, an die Identität einer Person komme, die sagt, sie hat die Berechtigung, das zu tun. Aber damit binde ich den Zugriff auf das Geheimnis eigentlich immer an die Identität, an etwas. Wenn ich das nicht tue, habe ich eigentlich so eine endlose Schleife von Ein Geheimnis. Das Ich hat ein neues Geheimnis zur Folge und wieder ein neues Geheimnis und wieder eins. Um diesen Endlosloop aufzubrechen, geht irgendwann zurück auf die Identität von etwas. Ich sage nicht jemand, der das Geheimnis kennt, darf darauf zugreifen, sondern ich sage nur jemand, der eine bestimmte Person ist. Jemand, der eine Identität hat, darf darauf zugreifen. Absolut korrekt, weil jetzt kann ich auch automatisiert mit diesen Prinzipien Royal Based Access Control einführen. Ich nehme es wieder. Mensch als Beispiel, weil das ist mal einfacher zu erklären, vielleicht auch einfacher nachzuvollziehen. Zumindest für mich, wenn wir jetzt wieder im Unternehmenskontext sind. Und du hast ein Record im Active Directory und bist der Gruppe Webserver zugehörig, weil du Mitarbeiter der Webserver Truppe bist, dann ist genau dieses Attribut ja schon im Active Directory drin. Authentifizierung st du dich jetzt gegenüber dem Active Directory auch das aktive Directory? Für die Person kenn ich die Auswahl wieder, die die ist sozusagen in meinem Datenbestand drin und zusätzlich habe ich die Information für dich. Der gehört der Gruppe Webserver an, Mit dieser Information kann ich aber den nächsten Schritt machen sagen Hey, gib doch allen Mitarbeiterinnen und Mitarbeiter die der Gruppe Webserver zu gehören, die Policy Webserver und damit regele ich den Autorisierungspfad im Sinne von Alle Menschen der Gruppe Webserver dürfen auf gewisse Informationen für Webserver zugreifen, aber nicht für Datenbanken, nicht für API und für nichts anderes. Damit kann ich diesen Roll Access Control schlichtweg komplett automatisieren, weil er alle identitätsstiftende Informationen sind über Identity Provider. In dem Beispiel jetzt Active Directory. Bei dem letzten dieser drei wichtigen Punkte, die zu Carters Security gehören, mit dem also Krieg oder Erziehung reagiert. Haben wir gar nicht näher beleuchtet. Wir haben nur den Oberbegriff genannt. Und weil ich das nicht immer schon. Oder hast du Beispiele, wo man es gar nicht gesummt oder wo man das dann irgendwie so baut, dass wenn man ist, das dann so, wie wenn man einmal drin ist, dann kann ich irgendwie alles kaputt machen oder so oder. Und das bedeutet, wenn jemand also Ex Assad oder so was wäre es nämlich das heißt aber also wo kommt dieses Prinzip zum Tragen in der Kette? Ich glaube. Ich verstehe die Frage. Es heißt natürlich, dass es Verwundbarkeiten in einem System weiter gibt, aber b dass ich die im Vorfeld mit einplanen. Das heißt so viel wie sollte jetzt in einem gewissen Bereich etwas in Ungnade fallen, Soll das keinen, soll das nicht ausstrahlen auf andere Bereiche. Damit limitiere ich sozusagen den Blast Radius, den ein möglicher Security LinkedIn haben kann. Der Worst Case ist Jemand ist im Rechenzentrum und damit in einem speziellen Netzwerkbereich, nur um ein Beispiel zu nennen und ist damit automatisch komplett im Netzwerk drin und kann alles andere auch sehen. Damit habe ich keine Trennung zwischen Datenbank und Webserver und internen Informationen, die ich als Geschäftsheiligkeit habe, sondern sobald ich drin bin, sind unter Umständen alle Systeme kompromittiert, weil ich eben nicht ausschließen kann, dass ein gewisser Angriff der Blast Radius auf andere Systeme übergesprungen ist. Bis zum Break heißt es im Zero Trust Kontext, dass wenn ich eine Maschine habe, die mit einem anderen Service kommunizieren darf und diese Maschine wird geklaut, kompromittiert oder nimmt einer mit, steckt woanders rein, sagt Hier habe ich eine Maschine, die kann sich ja einloggen, dann kann ich über sie trust Methoden. A Wenn ich das im Vorfeld schon mitbekomme, den Key, also den Schlüssel oder die die Authentifizierung dieses einzelnen Clients komplett und sagen Du bist sofort raus. Und b baue ich bei CJ fast immer ein Time to live ein. Das heißt, ich gebe nicht. Du bist einmal angemeldet und ich überprüfe dich nie wieder. Kommt immer heraus. Ich Du bist einmal angemeldet und musst dich zyklisch wieder anmelden. Immer wieder Authentifizierung, um festzustellen, dass du weiter. Dazugehören darfst und ich authentisch bist. Auch cool. Dass. Es virtuell ist. Zertifikate haben ja auch eine Lebenszeit in einer klassischen Welt. Früher wurden die immer so ausgestellt, dass eine Lebzeit von zehn Jahren haben war ich, dann bin ich in Rente und dann muss ich nicht gucken, wie der Blastradius ist, wenn meine Zertifikate ausgelaufen sind. Wenn ich das Vorfeld sauber definiere, dann baue ich einen Prozess auf, wo aufgrund der Identität ein Server ein neues Zertifikat auschecken kann und automatisch renoviert wird und das kein manueller Prozess ist. Jetzt will ich wieder die Infrastruktur Pipeline und dieses programmatische Ansetzen von Ressourcen plus den Methoden von so etwas zusammen. Weil gemeinschaftlich ist das unglaublich stark und vor allen Dingen unglaublich sicher. Auf die Gefahr hin, eher noch mal Chaos zu stiften, dann den Gedanken dann woanders hin zu machen. Ich hänge immer noch fest an dem, was für mich sehr bildlich war. Dieses Ding, das, wenn du einen Schlüssel weitergibst und ein Passwort hinschreiben, dass es immer weitergeht und am Ende doch einfach die Identität bestätigt werden muss. Du bist derjenige, der dieses Recht erfährt. Ist das auch das, was die Firmen verfolgen, wenn es darum geht, wenn wir über eine passwortfreie Zukunft sprechen? Also ich weiß nicht, wer das macht. Apple macht das doch beispielsweise die wollen irgendwie Passwörter, aber dann ist es auch das, dass man praktisch letztendlich einfach nur sagt, die stellen sicher, dass sie wissen, ich bin Dennis. Und die wissen dann, worauf ich den Zugriff haben kann. Ist das weiß ich jetzt eigentlich schon seit bin aber ich bin ich gerade wegen. Der Post schon fast schon so meldest dich ja heute unter Umständen schon mit deinem auch mit nem Bashing hier. Aber wir haben so viele Cloud Provider und das ist keine Verbesserung. Aber es gibt halt Google ADS und Escher und Alibaba. Und jetzt habe ich ganz viele vergessen, aber es gibt sehr, sehr viele davon. Und was ja schon mal ein klassisches Szenario ist als Login Screen bekomme ich als User wie möchtest du dich einloggen bei einem Service, den ich vorher noch nie in Anspruch genommen habe? Aber mir wird von vornherein angeboten, Du kannst dich mit deinem Google Account einloggen, du kannst dich mit Facebook einloggen, du kannst dich mit einloggen, du kannst dich mit unterschiedlichen Identitätsprovider einloggen, wo du unter Umständen schon einen Account hast. Die Magie findet im Hintergrund statt, weil die Herausforderung ist ja nicht, dass du jetzt immer wieder deinen Namen und deine Daten eingeben muss und ein neues Passwort suchst, sondern dass du ja im Prinzip den Identitätsprovider, das Single sein on System von Facebook oder Google oder auch das schon benutzen kannst, weil da ist ja schon überprüft, dass Dennis authentisch ist und da einen sauberen Record hat. Und was man jetzt natürlich wunderbar machen kann, ist, dass ich sage mir ist egal, wo du dich anmeldest, ich habe vertrauenswürdige Identitätsprovider. Und bist du bei einem von denen im Vorfeld, kannst du den ja auch benutzen, damit ich dich authentifiziert kann. Das heißt, es ist praktisch so eine Art von Interoperabilität zwischen den Identitäts Providern, die dann irgendwann ermöglicht, dass man keine Passwörter mehr braucht. Weil. Wenn man von einem Ausgehen praktisch startet, da gesicherte Identität hat und die immer weitergeben kann. Das läuft auch im Webbrowser. Im Hintergrund bekommt ein Token eine digitale Signatur, wo etwas drinsteht. Hier ist ein Session Token. Das hat eine Laufzeit von den nächsten zwölf Stunden. Und solange du dich jetzt, solange die Time Tools nicht abgehlaufen ist, kommst du auch auf andere Systeme drauf, weil einfach die Identität wird dann zwischen den einzelnen anderen Systemen geteilt. Über dieses Token ist das Token abgelaufen. Dadurch musst du dich neu Authentifizierung passiert zum Beispiel bei Google. Ich kann zwei Tage arbeiten, dann kommt irgendwann der Tag, dein Timeout. Du musst dich nur anmelden, mich an meiner Stelle sein oder mein Multifaktor. Wie das so schön heißt. Also Username Passwort plus einen schönen Key, wo ich den Fingerabdruck noch hinterlegen muss. Und das ist dann sozusagen die Bestätigung, dass ich als Person wieder weitermachen darf und die Prinzipien eigentlich ziemlich genau auf den Punkt. Und das sogar schon mit Ich kann unterschiedliche Identitätsprofile haben und es gibt eine gewisse Art von Federation dazwischen. Das heißt, ich muss mich nicht 15 mal anmelden, einmal auf Apps, auf Google, einmal auf okay, sondern. Untereinander können sich die Identitäten austauschen bzw. federieren im Sinne von Ich kann mein Facebookaccount nutzen, um mich bei Netflix anzumelden. Ich wollte fragen warum? Ich weiß nicht, ob man das Implementieren von Zero Trust nennt, aber kennst du so ein paar klassische Sachen, die man öfter falsch macht, die du so, die dir so über den Weg laufen und sagst Ach ja, das hier und mach bitte lieber so. Die größten Herausforderungen, die ich immer sehe, ist, dass Organisationen tatsächlich mit einem veralteten Mindset versuchen, die neue Welt zu be zu gestalten und so zu begehen. Das heißt, sie versuchen klassische alte Systeme cloudfähig zu machen. Also es ist im Prinzip das, was, was ich vorhin schon mal kurz erwähnt habe, dass man versucht, mit den Methoden der Vergangenheit aus der eher physikalisch orientierten statischen Welt die Dinge zu adaptieren, um damit die neue und rein virtuelle Cloudwelt zu gestalten und sicher zu machen. Und eine Stilblüte ist zum Beispiel, dass natürlich viele Unternehmen weiter versuchen, alles mit Layer zwei drei Perimeter Netzwerkidentifikation abzusichern sowie Firewalls und Load Balance, die ja nicht per se schlecht sind. Das heißt auch nicht, die sind alle überflüssig. Aber ich kann ein Cloudsecurity Konzept schwerlich damit in Übereinstimmung bringen, weil ich einfach zu viele unterschiedliche Technologiesilos in aller Regel habe, die ich in den Cloud benutze, um Workloads darauf zu binden und zum anderen die Dynamik viel zu groß ist. Ein schönes Buch, Open Source, das heißt. SEO the Turtle. Weil man danach googelt, wird man es Fall finden. Und das erklärt brilliant. Für mich auch sehr anschaulich, was eigentlich der Unterschied ist und warum sich Security weiterentwickeln muss, basierend auf die Konzepte der Vergangenheit, um besser in der Cloud zu sein und auch die Cloud Herausforderung anzunehmen. Und die finale Schlussfolgerung ist schlichtweg, dass ich am Ende auf einer Cloud Umgebung mehr als normalerweise mehr als ein Cloud Provider habe. Unterschiedliche Run Time Umgebungen, so was wie Kubernetes, so was wie Cloud, so was wie On Premers, also unterschiedliche Dinge habe und dann auch noch kein statisches Netzwerk drum herum. Aber ich kann diese ganzen Dinge eigentlich, kann keine präzise Linie mehr und um die Ressourcen zeichnen, die ich absichern möchte. Allein die Elastizität. Wenn ich sage, ich mache ein Auto, dann verändert sich sehr schnell etwas aus dem Konstrukt oder aus der momentanen Aufnahme, wie die Infrastruktur für meinen Workflow gerade aussieht. Und wenn ich das jetzt versuche, über den klassischen Weg zu lösen, habe ich eigentlich immer nur eine blöde Abteilung, die nichts anderes macht als Ich bekomme Requests per Ticketsystem zum Beispiel Bitte füge IP, Adresse XY und setz in deine Firewall ein, damit mein Service funktioniert, den ich aber jetzt brauche. Ich mache jetzt Fenster laut und wenn ich jetzt wieder 4321 Woche brauche, um die Firewall Regel zu aktualisieren, was ja nun mal glaube ich schon recht schnell wäre in vielen Organisationen, dann habe ich nichts davon. Dann habe ich, bin ich entkoppelt von der Dynamik, die mir eigentlich Cloud bietet. Das ist jetzt nur ein Beispiel. Es gibt noch viele andere. Aber das heißt, dass die Methoden der Vergangenheit nicht unbedingt tauglich sind. Die Technologie, die Cloud bietet, zu orchestrieren, zu administrieren, abzusichern. Gibt auch irgendwie was vor. Was die Art der Sicherheit angeht. Also das heißt, ich meine, wir haben jetzt davon gesprochen, Maschinen können sich über Zertifikate, beispielsweise Authentifizierung, aber da gibt es wahrscheinlich also das alles nicht meine Expertise, aber vermutlich verschiedene Formate und Sicherheitsstufen wie so ein Zertifikat sein kann und das kann toll sein, aber das kann auch Fake sein und also ist irgendein STANDARD mit verbunden, sodass man sagt ja, okay, damit das funktioniert und damit dieses Prinzip überhaupt aufgeht, muss so ein Level an, an, an Sicherheit, an Technologien, die dahinter stehen, irgendwie gewährleistet sein. Oh, jetzt öffnen wir die Büchse der Pandora. Und natürlich können wir es jetzt mathematisch versuchen, uns dem zu nähern, warum die Sicherheitskonstrukte von Public Key Infrastrukturen und TLS Zertifikate sicher ist. Das lassen wir jetzt alles mal beiseite und sagen, wir glauben mal, dass das sicher ist und gut die Angriffsvektoren dafür wie eine eigene Podcastfolge wird. Das haben wir im Bereich der Mutmaßungen, Verschwörungstheorien und Co. Also grundsätzlich können wir, glaube ich, vertrauen, dass die Art der Mathematik gesichert und sicher ist. Also einfach moderne Krypto oder Fiat Sicherheitsmechanismen. Zertifikate etc. nutzen genau das, was auch alle schon kennen. Wenn Sie dann zu Hause mal den Webbrowser benutzen, um mit der Bank zu kommunizieren, dann ist das eine gesicherte TLS verschlüsselte Verbindung, die auf einer PKI, einer Public Key Infrastruktur aufbaut und dementsprechend über Zertifikate die Vertraulichkeit und die Sicherheit sicherstellen kann, Vertraulichkeit und Sicherheit sicherstellen kann. Eine schöne Doppelmoppelung, aber mit denselben Prinzipien funktioniert das dann natürlich. Wenn ich zum Beispiel zwei Workloads miteinander kommunizieren lasse, klassische Konnektivität, dann müssen beide enden zuvor, wenn sie denn die Erlaubnis haben, in Verbindung zu treten. Einer Mutual TLS verschlüsselt Verbindung aufbauen. Und genau damit entkoppelte ich das Trust Netzwerk Konstrukt im Prinzip komplett von der eigentlichen Netzwerkinfrastruktur, weil brauche ich Netzwerk. Ja natürlich, ich brauch weiter irgendwie Verbindung Layer zwei drei damit sich Maschinen sehen können. Aber die Verbindung oder dieses diese Netzwerkinfrastruktur muss nicht mehr sicher sein, wie man das in der Vergangenheit gemacht hat, sondern ich kann jetzt auch über ein unsicheres Internet, über Unsicherheit von Cloud Providern über die. Das ist nicht unsicher, sondern es ist einfach keine kann ja keine vertrauensvolle Umgebung haben. Und so kann ich aber jetzt auf der nicht vertrauensvollen Infrastruktur vertrauensvolle Ende zu Ende Verbindung bauen. TLS verschlüsselt über ganz klassische PKI X509 Zertifikate. Das kann keine Raketenwissenschaft, aber ich meine, mein Hirn reicht nicht aus, um die Mathematik da jetzt im Vordergrund zu stellen. Hier hätte zumindest bei mir kein Empfänger, der das verstehen will. Von daher ist die Empfehlung für einen Podcast, dass einer 15 20 Minuten das nachvollziehbar, anschaulich, plakativ zu erklären, dass das meine neue Lieblingsfolge. Hast du mal so ein so ein greifbares Beispiel für ich habe vielleicht einen Webserver in der Cloud und meine Daten liegen und. Ja. Das ist das perfekte Szenario für einen Kunden. Den kann man jetzt sozusagen als Brownfield identifizieren. Der fängt nicht an nativ auf der Cloud, sondern der hat schon mal Ressourcen und eine Datenbank oder State Information, die geschützt im eigenen Rechenzentrum sich befinden. Jetzt möchte ich aber diese Informationen zum Beispiel einem IT Service zur Verfügung stellen. Von mir aus ein Webserver, den ich habe jetzt nicht on Premise, sondern in der Cloud und schon habe ich den klassischen Hybrid Cloud Anwendungsfall. Wo ich natürlich aus der bösen Cloud, dem bösen Internet, auf Informationen zugreifen muss, die schön geschützt in meinem vier Wände geschützten Bereich liegen. Und das kann ich jetzt ganz wunderbar natürlich mit den Methoden von Zero Trust bewerkstelligen. Jetzt kommen wir eigentlich eher in die Tooldiskussion, wie wir das machen. Wir haben eigentlich über Konzepte gesprochen, aber jetzt kann ich zum Beispiel von uns das Tool benutzen mit dem Namen Consul und Consul ist ein Service Mash oder ein Tool. Das. Service Networking bewerkstelligt, auf egal welchem und egal auf welcher für sich. Ich muss im Vorfeld natürlich die Identität ich sage jetzt mal, mein Rechenzentrum ist der Datenbank Service und ich baue den nächsten Webserver und der Webserver möchte auf den Datenbank Service zugreifen. Habe ich zwei Workloads. Webservice Datenbank service bieten Services. Muss ich aber jetzt eine Identität zur Verfügung stellen. Und das mache ich wieder mit Zertifikaten. Das heißt, ich habe ein Zertifikat in meinem Webservice in der Cloud und ich habe ein Zertifikat in meinem Datenbank Service. Jetzt autorisiere ich über den Weg, dass der Datenbank Service und Webserver miteinander kommunizieren dürfen und autorisierte damit diese Mängel. TLS verschlüsselte Verbindung Ende zu Ende. Als Grundlage für die Vertraulichkeit muss natürlich die Identität meines Mannes, meines Nots herausfinden, um dann im nächsten Schritt ein Zertifikat zu übermitteln und zu sagen Das ist das Zertifikat, an denen meine Vertraulichkeit hängt. Mit dem Zertifikat bekommst du die Möglichkeiten der Netzwerkverbindung, der Netzwerk Konnektivität. Genau das hat jetzt aber nichts mehr mit dem eigentlichen Netzwerk zu tun im Sinne von Layer 123, sondern ist eigentlich eine applikationszentrierte Kommunikationsbeziehung, die ich über den Weg jetzt sauber orchestrieren kann. Wenn ich das so löse, habe ich ein neues Passwort. Dann habe ich ein Service Mesh integriert. Das heißt, ich mache meine Netzwerksegmentierung sehr logisch über einen Service Mesh über Console. Das magister für viele Organisationen auch das Ziel sein, zu einem Service zu kommen. Aber häufig geht das ja nicht so schnell. Ich kann nicht von heute auf morgen meine komplette Art und Weise, wie ich zum Beispiel IT Services betreibe, umändern. Oder die Migration von klassisch auf supermodern ist nicht ein Schritt, sondern benötigt mehrere Iterationen. Das kann man auch genauso gut Consul benutzen, um Netzwerk Automatisierung damit zu machen, weil Konsul kennt ja die Dynamik der einzelnen Services spricht. Das selbe Beispiel Ich habe den Web Service in der Cloud, mache jetzt ein SQL out von zehn auf 20, dann würde ich am Final auch zehn neue IP Adressen bekommen, die ich sozusagen autorisiere, auf was zuzugreifen. Consul ist ein Service Registry, das heißt, jeder einzelne Web Not in der Cloud registriert sich an Konsul unter dem Namen Web Service zum Beispiel und teilt Konsul die IP Adresse mit. Über den Weg habe ich jetzt eine zentrale globale Instanz, an der ich abfragen kann Wie viele Wrap Notes gibt es denn und und sind die? Hält sie? Funktionieren die auch? Und damit habe ich auch in Consul in der Kontrollpflanzenkonsole die Information, welche IP Adressen dazu gehören. Jetzt kann ich schlichtweg Konsole benutzen und die Information einem anderen System zur Verfügung zu stellen, um daraus was zu machen. Genauer gesprochen ich benutze jetzt Consul, um die Information der IP Adressen in die Firewall zu übertragen. Die Ende zu Ende automatisierbar keit bedeutet nämlich jetzt, dass Application Team das entschieden hat. Ich brauche ein Scale out und jetzt von zehn auf 20 Maschinen macht damit automatisch die Security Regeln für die nächsten zehn Interessen in der klassischen Firewall. Und es ist ja durchaus die Notwendigkeit gewesen, dass die Application Scale out macht, dementsprechend so, dass das schnell stattfindet. Und ich benutze Konsole und die Information die Konsole schon hat, um die Firewall zu konfigurieren oder Notbremse zu konfigurieren oder einfach irgendwas mit diesen Informationen zu machen. Das ist relativ frei. Darum jetzt vielleicht auch ein bisschen schwammig die Antwort. Aber über diese Tools kann ich genau solche Workflows, Hybriden, Workflows, Cloud nativ lösen oder klassisch in ich Netzwerkinfrastruktur Ressourcen wie eine Firewall Notbremse damit aktualisiere. Die Information, die die Konsole hat sind relativ identisch zu denen, die Luftballons hat irgendwie in meinem Kopf zumindest, weil der musste ja auch die IP Adressen alle kennen und da müssen sich die Maschinen ja zumindest mal mit einem Health Track irgendwie sagen So, Hallo, ich bin da. Das ist ja die große Frage wie kriegt der Load Balanca valide den Input, welche Maschinen, welche IP Adressen jetzt für ihn zum Fortpflanzen zur Verfügung stehen? Dass ich da jetzt nicht willkürlich einen IP Adresse meldet, dessen Ursprung ich nicht kenne, die sich nicht authentifiziert hat. Da habe ich mir noch nie Gedanken drüber gemacht. Oder das ganze manuell eingetragen wird, weil ich habe jetzt sozusagen zwei innerhalb von fünf Minuten zehn neue Maschinen in der Cloud. Aber jetzt brauche ich fünf Tage oder bis fünf Wochen um die IP Adressen in den Nordpol einzutragen. Das ist ein nicht sonderlich effizienter Prozess und auch nicht sicher, weil ich das wieder manuell mache, kann ich mich vertippen. Ich kann ihn vergessen, kann Zahlendreher haben. Das heißt, ihr setzt das praktisch als ein Produkt obendrauf, um diese Verbindung einfach managen zu können, die dann automatisch mit skaliert automatisch ja einfach den Status des Ganzen abdeckt. Und das vereinfacht, dass man eben nicht die manuellen Aufwände hat, die Dinge miteinander zu verknüpfen. Jetzt verzahnen wir im Prinzip das Prinzip von Zero Trust mit den Tools, die HashiCorp zur Verfügung stellt. Und jetzt habe ich eins sogenanntes Consul Consul, das genau für diese Maschine zur Maschine Kommunikation. Um das zu automatisieren, zu sichern, Netzwerke zu segmentieren, Netzwerkinfrastruktur zu automatisieren für genau das Szenario, was wir gerade skizziert haben oder halt am Ende tatsächlich einen Service Mesh zu haben und dann die Sicherheit gar nicht mehr wirklich an Netzwerkinfrastruktur Komponenten wie Login und Firewalls zu koppeln. Weil das kann ich direkt mit Konsole schon machen. Daneben muss ich jetzt ein anderes Tool noch nennen. Das ist World. World ist unser Security Produkt. Und das ist mehr dazu da, natürlich einen Chip Management zu betreiben oder auch die aus den unterschiedlichen Identitätsprovider, Google Apps, Drpping usw. ein konsistentes Layer zu machen im Sinne von Egal wo ich herkomme, ich schließe darauf eine eineindeutige digitale Identität, mit der ich dann weiterarbeiten kann, um dann Zugriff auf bestimmte Secrets zu geben, wie zum Beispiel klassisch Smart Key-Value-Store. Was viele Leute haben wollen, Key-Value-Store aber in aller Regel etwas, wo ich statisch extern generierte Geheimnisse speichern möchte Das Rootpasswort auf eine Datenbank, dass irgendjemand aus meinem Ensemble wollt. Ja, da ja. Also alles geheime Informationen, deren Ursprung irgendwo aus dem Himmel fallen, von außen kommen. Und das ist aber nur ein Bereich, was jetzt Word machen kann, wenn ich Key-Value-Store nutze. Was natürlich auch noch mal die Security auf ein ganz anderes Level hebt, ist, wenn diese Secrets dynamisch erzeugt werden. Sprich der Zugriff auf eine Datenbank existiert noch gar nicht, der ist noch gar nicht angelegt. Aber wenn ich aufgrund meiner Rolle die Berechtigung habe, auf eine Datenbank zuzugreifen, dann generiert mir World als Security Management System die Zugangskarte zur Datenbank on the fly. Und die sind zum Beispiel nur zehn Minuten gültig oder nur für den einmaligen Gebrauch gültig. Und damit habe ich nicht das Problem, dass wenn ich die Route identisches von etwas bekomme und sie mir die aufschreibe und die einmal gelesen und gesehen wurden, ist dieses Geheimnis nicht mehr wirklich sicher oder vertrauenswürdig. Weil ich kann jetzt menschlichen Fehler haben. Ich schreibe es mal auf, ich verliere es auf dem Posten, es steht irgendwo anders, ich teile es mit dir. Damit ist die Vertraulichkeit und die Sicherheit ja nicht mehr gegeben. Bei dynamischen Credentials umgehe ich das einfach, indem es einfach. Den Zugriff zu dem System gibt es gar nicht. Also gibt es nicht mehr den Angriffsvektor und die Identität. Die kurzlebigen Credentials werden erst zur Laufzeit Request generiert. Und dann würde die Datenbank fragen So, da war das. Nicht. Die Datenbank würde fragen, sondern wir. Wir reden ja über rollenbasierte oder identitätsbasierten Zugriff auf Systeme und aufgrund meiner Identität nicht entstehen kann ist die Identität, sondern entstehen kann, hat die Rolle Datenbank Admin Und damit kann ich Datenbankadministratoren natürlich die grundsätzliche Berechtigung geben, auch auf Datenbanken zuzugreifen, aber nicht in Webadministratoren, zum Beispiel weil das eine andere Gruppe ist. Wer ich dann nur fünf zehn Minuten lang Datenbankadministrator. Der Punkt ist, dass die Credentials, die erzeugt werden, um auf eine Datenbank zuzugreifen, nur für den einmaligen Gebrauch sind und danach wieder gebraucht werden. Das heißt, selbst wenn ich die Credentials verliere und jemand findet, die ist die Zeit für den Angriffsvektor schon abgelaufen. Das heißt, die sind schon ungültig. Ich kann mit dem gar nichts mehr anfangen. Und ihr stelle ich mir über euer Produkt. Das kann zum Beispiel Wald machen. Genau. Okay, also wenn man das nutzt, dann will ich darauf zugreifen und lasse mir temporäre Zugangsdaten erstellen. World weiß das ich es darf. Und dann kriege ich die und kann sie einmalig nutzen. Genau. Und wenn man das jetzt mal wieder von Menschen entkoppeln soll und sagen wir stellen jetzt Zertifikate für Maschinen aus und mit einem Webservice und ein Datenbank Service. Sobald ich die Identität der Maschine Web Service herausgefunden habe, weil ich sie auch durch Authentifizierung und durch das Cloud Provider Zertifikat überprüfen konnte, dann weiß ich, diese Maschine kommt aus meinem Kontext, ist bei dem Cloud Provider und ich habe vielleicht noch gesagt über eine Pipeline Du bekommst. Ein Multifaktormit übermittelt. Also kann ich den Prozess der Authentifizierung dieser Maschine sehr sicher machen. Jetzt kann ich mich natürlich Authentifizierung gegenüber im World System und bekomme dann die Policy zugewiesen, dass ich ein spezielles gesichertes PKN Zertifikat ausdrücken kann oder dass Ding Key, den ich jetzt dynamisch auf der Maschine habe sein lasse durch ein World System. Und dieses Sein, genau diese PKI, genau diese Kryptographie sorgt dafür, dass dann dieser Webservice mit einem Datenbankservice kommunizieren darf. Weil ich das alles sozusagen über ich wiederhole mich jetzt. Der Out of Trust ist Identity. Und über Identität kann ich sauber Access Control bewerkstelligen. Über Access Control kann ich genau zuweisen, für welche Information oder Funktion ich einen Anfragen an Klienten autorisieren. Und das ist genau dieser Dreiklang im Prinzip. Aber es hängt immer mit der Identität zusammen. Soweit ich die automatisiert überprüfen kann, kann ich ein Ich, ein Token oder ein Zertifikat ausstellen mit einer gewissen Berechtigung auch mit gewissen Policies, die dahinter hängen. Und mit diesen Policies kann ich einschränken, auf welche Informationen dann ein System Zugriff bekommt oder eben nicht. Fein verstanden. Vielleicht ein nicht komplexes Thema, aber eigentlich durch die einfachen drei Prinzipien sehr einfach nachvollziehbar. Und sofern man das dann einmal wirklich mit einer. Die. Konzepte mit Tools dann auch untermauert und sieht, wie einfach so ein Workflow sein kann, dann wird da doch ein Schuh draus. Relativ einfach. Ich weiß jetzt nicht, die ganzen Hörerinnen und Hörer kommen ja meistens aus unterschiedlichen Bereichen. Also wenn man den OPs, die OPs Brille auf hat, kommt man ja aus der Infrastruktur, wenn die Brille auf hat. Komme aus der Programmierung auf der Applikationsebene. Aber egal aus welcher Branche ich jetzt komme, jede Applikation muss gewisse Infrastrukturressourcen konsumieren, um zu funktionieren. Das beginnt tatsächlich mit der virtuellen Maschine oder dem Container, in dem die Applikation läuft. Hinzu kommt aber Jede Applikation braucht irgendwie Gates Credentials oder Geheimnisse Security App UIKit Zertifikat, jedenfalls um überhaupt Cloudressourcen auszurücken. Und jede Applikation braucht als Drittes irgendwie geartete Netzwerkapplikationen, die ich nicht erreichen kann. Es ist sinnlos, wenn ich auf meinem Mobiltelefon die Bahn App oder meine Bank oder was auch immer nicht erreiche. Ist die Businessapplikation der Bahn Ticket Buchung sinnlos. Also brauche ich Netzwerk dafür. Und das sind eigentlich immer die drei Achillesverse oder die drei Grundlagen für jede Art von Applikation. Ich brauche die Infrastruktur, ich brauche Security, ich brauche ein Netzwerk. Und basierend auf diesen drei Grundressourcen kann ich dann meine Applikation einsetzen. Und wenn man kein Netzwerk hat, dann fliegen keine Flieger mehr, so wie gestern. Aber das wird bei der Veröffentlichung der Folge schon ein paar Tage her sein. Aber ja. Eine doch interessante Begebenheit. Und was man halt nicht planen kann. Ja, also man kann jetzt ein Rechenzentrum noch so sicher machen, aber wenn dieses eine noch so sichere Rechenzentrum abgeschnitten ist und da genau diese Single Point of Fehler drin ist, dann ist der Blast Radius das mal ein Tag nicht geflogen werden kann. Das stimmt. Besonders lustig, wenn ich es im Radio gehört, dass die Bauarbeiter das Beton noch zugeklebt haben. Ich weiß nicht ob das das. Ich weiß das nicht mehr. Also das Loch gebohrt haben, die Kabel angebohrt und dann aber schnell zubetoniert. Und deswegen hat es ein bisschen länger gedauert, weil der Beton wieder raus musste. Ich habe überhaupt nix von Ausrüstung. Okay. Vielleicht. Guten Morgen. Äh. Irgendwelche Bauarbeiter haben bei der Lufthansa im Rechenzentrum Kabel angebohrt? Nein. Okay, also in den Nachrichten. Was war gestern? Gestern in den Nachrichten kam das unter anderem. Lufthansa hatte keinen Zugriff mehr auf ihr komplettes System, was dazu führte, dass sie alle Flüge einstellen mussten gestern. Was auch dazu führte, dass der ganze Frankfurter Flughafen alle alles einstellen musste, weil sich da die Flugzeuge gestaut haben, sodass das praktisch den ganzen Tag alles außer Gefecht war. Nur das mit dem Bohren. Ursache für das Ganze ist, dass hier in unserer Bahnstrecke zwischen Bad Nauheim und Frankfurt ist ja die Baustelle. Da haben Sie mit so einem Tiefbohrer in fünf Metern Tiefe einfach ihr Glasfaserkabel durch gebohrt. Und anscheinend, als sie das gemerkt haben, war es zubetoniert und dann gedacht damit ist es wieder erledigt. Und genau die wurden dann wieder langsam zusammengefrickelt. Dass das. Frage ich dich gleich noch mal, was das für Kabel waren. Nicht recherchiert. Das war nur Kabelschnur für die Lufthansa. Das habe ich mich dann auch gefragt, ob die. Ob die Lufthansa praktisch irgendwie selbst Infrastruktur so betreibt, dass sie tatsächlich Glasfaserkabel irgendwo liegen haben, die nur ihnen gehören oder nicht. Es waren ja auch viele Privathaushalte in Frankfurt getroffen. Das heißt, da war durchaus auch mehr, was daran hing. Aber anscheinend war es sehr zentral, dass was schon mehr oder weniger von Lufthansa abhängig war und anscheinend nicht über eine andere Internet Connection da wieder dran kam. Okay. Aber egal ob es deren eigenen Kabel waren oder gemietete Leitungen, die Auswirkungen wären trotzdem identisch gewesen. Und es ist interessant, dass ein Kabel. Ja ja genau. Um zu diesem Blast Radius zu führen, zu diesen Auswirkungen Ja. Nee, absolut. Ist irgendwie immer noch schwer vorstellbar, dass sie. Dass man so was dann nicht irgendwie umgeleitet bekommt auf so einer Skala von. Alles, was wir jetzt machen, ist natürlich auch Mutmaßung und das steht mir fern, der Häme oder sonst irgendwas an Tag zu bringen. Aber das wäre ein klassischer. Wir. Trennen das mal komplett von Lufthansa, sondern wir abstrahieren das Problem nur. Okay, da war eine geschäftskritische Applikation, die war in einem bestimmten Rechenzentrum und das war zum Beispiel die Datenbank, die die Statusinformationen für alle Passagiere hatte, zum Beispiel. Und wenn auf diese Daten nicht mehr zugegriffen werden kann, ist das ganze System sozusagen nicht nutzbar. Jetzt kann man natürlich sagen okay, man hat jetzt einen Geo oder geografischen Single Point of Contact, also nämlich genau ein Rechenzentrum. Natürlich gibt es andere Konstrukte, wo ich das Ganze in die Cloud hebe. Dann habe ich es nicht in einem Rechenzentrum und vielleicht nicht nur eine Glasfaseranbindung, sondern kann das jetzt natürlich anders gestalten. Das ist jetzt aber. Kein Hinweis, keine Beratung für die Lufthansa. Der Teufel steckt im Detail. Und es gibt noch viele, viele freie Informationen, die wir alle nicht wissen. Aber grundsätzlich kann man natürlich sagen, dass egal wie sicher ich jetzt sage, hier ist mein Rechenzentrum und das alles, was ich brauche. Es wird immer einen Fall geben, der nicht berücksichtigt wird, wo man sagen kann, wenn ich den Dominostein umwerfe, dann bricht halt das ganze Konstrukt zusammen. Ist ja auch ein bisschen, um wieder auf die Prinzipien zurückzukommen, ein bisschen, was in dem dritten auch drinsteckt. Also auch wenn es jetzt kein aktiver Breach war von Trust, aber du hast in diesen Systemen, da haben wahrscheinlich viele. Würde ich mal denken, Lufthansa hat die Größe, dass sie Leute haben, die sich um so was Gedanken machen. Aktiv, Was kann passieren? Und wahrscheinlich ist keiner davon ausgegangen, dass ein Glasfaserkabel in fünf Metern Tiefe einfach durchbohrt wird und zubetoniert. Das finde ich immer noch besonders schön. Das war das. Ich weiß nicht. Und das war schon. Das war schon ne, ne, das war schon. Damals wir so, dieses klassische was immer auf der Google Cloud Next immer sagen so bitte plan ein was passiert, wenn dein Rechenzentrum down ist, so Multi Cloud, Highway out usw. Aber ich denke, so ein Rechenzentrum geht überhaupt nicht down. So ein Quatsch. Das häufiger als du denkst, nämlich Dann wird an der Stromversorgung gearbeitet und fällt immer irgendwie der Schraubendreher aus der Hand und macht einen Kurzschluss in der Batterie. Es wird nur Staub aufgewirbelt und der Brandmelder fängt an an zu sprengen und lässt sozusagen. Und. Ist das. Das ist gar nicht so unwahrscheinlich. Zumindest was ich noch vor ein paar Jahren ist das auch mal in einem großen Rechenzentrum in Frankfurt mal passiert. Und soweit ich weiß, gibt es da einen großen Notausgang. Was, wenn die Feuerwehr kommt, kann ich ja nicht löschen, wenn da überall Strom drauf ist. Darum gibt es diesen großen Schalter im Flur, der wird dann umgelegt. Dann ist das ganze Rechenzentrum zumindest die Etage stromfrei. Das ist jetzt ein paar Jahre her. Das heißt, Festplatten haben eigentlich alle noch rotierende Massen gehabt und die Lüfter drehen sich. Wenn man so was wieder einschaltet, gibt es in aller Regel auch ein paar Prozent Kollateralschäden, weil einfach Festplatten nicht mehr laufen, Lüfter nicht mehr andrehen. Ja, das passiert auf jeden Fall. Okay. Aber das müssen wir ja zum Glück in unserem Alltag nicht beachten. Zum Glück hast du noch was, wo du sagst, Jetzt haben wir über sehr viel geredet, da ist noch irgendein Konzept, irgendeine Idee, die wir noch mit aufnehmen müssen. Wenn ich die Quintessenz zusammenfassen soll, ist, glaube ich, fast natürlich die Methode der Wahl der heutigen Zeit, weil sie automatisierbar viel mehr Sicherheit in IT Infrastrukturen bringt als alles, was wir bisher kennen. Und ja, ich glaube, dass der Kernpunkt ist, dass Identität die Basis für Vertraulichkeit und Vertrauen ist und natürlich damit eine sauber überprüfbare Identität von Menschen und Maschinen die Grundlage ist für sie ist. Weil nur über den Weg, dass ich die Identität habe, kann ich auch Access Control anwenden. Und über Access Control kann ich die Policies definieren, die dann auf einen Klienten, auf jemand, der sich authentifiziert hat, anwenden kann, um dann genau zu sagen, worauf gibt es dann überhaupt Zugriff und worauf nicht, bzw. es gibt auf nichts Zugriff, sondern nur das, was ich autorisiere. Das kann ich zugreifen. Und das ist eigentlich ein ganz schlankes, elegantes Etwas. Wir haben es genau das glaube ich, ein bisschen beleuchtet von mehreren Seiten, mal sehr technisch, mal sehr sinnbildlich, hoffe ich. Und ja, das ist, glaube ich das, wo sich zumindest eigentlich alle Organisationen und Organisationen damit beschäftigen müssen, wie sie dann auch skaliert fähig ihre Businessapplikationen an den Markt bringen können. Kue. Eine Buchempfehlung hätte ich bzw. zwei. Eine habe ich schon genannt. Das ist allerdings Bottom, Turtle. Ja. Jetzt möchtest du die als PixiJS of the Day verpacken. Das kann ich gerne machen. Was muss ich dafür tun? Ähm, warten, bis unser Jingle abgespielt wurde. Ich gucke mal zum Sebi rüber, ob der auch einen hat oder ob wir das einfach so haben. Na dann ist ja gut. Du hast zwei Bücher, dann machen wir erstmal das erste Buch von dir. Okay. Eins habe ich schon erwähnt und das ist ein Open Source Buch. Darüber bin ich mal gestolpert, um mich dem Thema Source Rust und Netzwerksicherheit zu nähern. Und das heißt allerdings Bottom total. Dass man schnell googeln musste, dass The Bottom Turtle. Einfach nur. Ja, genau das passt. The Bottom ist ein PDF mal runterladen und mir haben allein die ersten 20 30 Seiten so viel Freude bereitet, dass ich keine Gelegenheit auslasse, das auch noch mal kundzutun. Sehr gut. Cool werden auf jeden Fall. Ist ein Picks of the Day. Brauch man gar nicht nicht schon auspacken, sondern findet er auf der Webseite nämlich super. Ja, mein ich habe auch was zum Lesen und zwar einen Artikel, der beschreibt, warum es keine gute Idee ist, auf den Mars zu fliegen. Das ist ziemlich lang, hat mich aber interessiert und hat mich auch gut unterhalten. Ja, wie gesagt, es wird halt ein bisschen abgeklopft. Ist das überhaupt nötig? Müssen wir da hin? Hat das nicht vielleicht auch irgendwelche Gefahren mit? Wir wollen ja eigentlich dahin fliegen, um mal zu gucken, was davon leben, was, Wie hat sich das entwickelt? Aber wenn wir da so eine riesengroße Menschenkolonie aufbauen, bringen wir auch allerhand mit. Ist nur irgendwo hin mit unserer Kacke, wenn wir vermutlich da irgendwo hin wollen. Und hat das so viele Vorteile, dort als Mensch präsent zu sein, wo wir eigentlich jetzt gerade die ganzen Roboter Technik haben, um dort auch einfach so einen Roboter abzusetzen. Ja also mich interessiert so was, deswegen hab ich das gelesen. Haben wir würden zwei Ausnahmen einfallen so spontan die sich gerne sofort heute in ein Flugzeug Raumschiff One way reinsetzen können und einfach mal zum Mars fliegen. Ich glaub der eine baut auch an so einem Flugzeug und auf der. Ich brauch die Person nicht, sonst finde ich das ähnlich. Eigentlich haben wir einen schönen Planeten, der ist schon im Weltraum. Wir sind sozusagen schon auf einem Raumschiff. Lass uns das doch erst mal schützen und lebenswert machen, bevor wir den nächsten Planeten auch noch zerstören. Mit was? Das Problem mit der Lebenserhaltung ist noch gar nicht so richtig gelöst. Also wir kriegen es noch nicht hin, sustainable im Weltall zu fliegen. Auf der ISS müssen sie irgendwie jede Woche oder alle zwei Wochen oder so was irgendwie frische Wäsche und Essen hin transportieren und also sind viele Probleme. Und dann fand ich auch Lust, dass wir dann Elon Musk ist, also der, der die Fahne hochhält. Und wir müssen unbedingt auf den Mars fliegen und so und das müsste halt alle technischen Probleme des Q2 nächsten Jahres irgendwie gelöst haben und so war es einfach nicht so einfach. Sehr gut im Titel. Ich habe noch mal den richtigen Titel sagen, aber wie gesagt, steht dann in der Werkstatt. Aber du hast noch ein zweites Buch, was du mitgebracht hast. Ja, zumindest eins, das mir. Das hat jetzt nicht unbedingt was mit dem heutigen besprochenen Thema zu tun. Also im Prinzip schon. Es geht auch um IT. Aber nachdem ich vor Jahren schon mal so Phoenix Projekt gelesen habe, was glaube ich vielen bekannt sein sollte und glaube auch so eine große gewisse Grundlage von Agilität DevOps und Co darstellt, gibt es für mich eigentlich die die nächste logische Konsequenz als Buch, was gut daran anschließt, wie man heute mit Prozessen und IT umgeht. Und das ist von Mick Kirsten heißt da glaube ich, vertraue ich mal meinem Namen und das heißt von Projekt zu Produkt. Weil das beleuchtet. Noch mal schön, dass wir heute im Zeitalter der Software sind und dass es die Software ist, die die entscheidende Asset in Organisation ist und nicht mehr die Infrastruktur, die Hardware. Und er macht das ganz wunderbar anschaulich. Und ich hatte viel Spaß beim Lesen, weil ich komme auch aus der operativen Sicht und aus klassischen großen Konzernen wie Telekommunikationsprovider und Co, wo alles in Projekten gemanagt wird und die Widersinnigkeit, eigentlich heutige IT Services in Projekte zu managen und zu quetschen und das nicht als Produkt zu managen, ist sehr anschaulich und sehr lustig dargestellt. Sehr schön, große Empfehlung. Vielen Dank! Werden wir auf jeden Fall in die Liste aufnehmen. Coole Sache. Denn es ist kein Picks of the Day Achse. Wie ich sagt. Auch immer, ich als Moderator muss nicht unbedingt eine haben. Ich hatte. Zwei dafür. Ja, genau. Danke. Nächstes Mal. Ich verspreche, wenn wir das nächste Mal wieder Picks of the Day machen, werde ich auch wieder einen mitbringen. Jörn. Vielen, vielen. Dank, Dennis, dass. Du hier bist. Danke. Sehr cool, dich vor Ort zu haben. Natürlich auch. Jetzt noch mal auf das mit ab in anderem Format heute Abend. Falls ihr jetzt denkt, wir ab und die schafft es nicht mehr hier hin. Das ist richtig, weil wir kurz vor 12:00 aufnehmen. Aber wir haben auch schon. Vor allem, wenn Sie das hören, dass das nicht. Da ist das schon lange vorbei. Das ist richtig. Aber unseres nächstes findet statt am 16. März. Da geht es um Web Assembly und das nächste darauffolgende ist am 13. April, wo es um Architektur geht. Um mal zwei zu sein an dieser Stelle. Wir haben auch noch mehr Themen, die wir schon fertig haben mit dem Termin. Vielen Dank fürs Zuhören. Eine schöne Zeit. Gebt uns Feedback, Podcast Programmier.bar oder über unsere Programmier.bar Webseite. Jörn Vielen, vielen Dank! Herzlichen Dank, dass ich hier sein durfte. Und bis bald. Christian. Tschüss.