Secrets Management

Jörg Müller: Willkommen zu einer neuen Folge des INNOQ-Podcasts. Wir wollen uns heute zum Thema Secrets-Management unterhalten und dafür habe ich mir Daniel eingeladen. Hallo Daniel!

Daniel Bornkessel: Hallo Jörg!

Jörg Müller: Möchtest du kurz ein paar Worte zu dir sagen, wer du bist und was du so bei INNOQ machst?

Daniel Bornkessel: Klar. Mein Name ist Daniel Bornkessel, ich bin Senior Consultant bei INNOQ Deutschland. Und ich habe mich die letzten Jahre hauptsächlich beschäftigt mit Themen wie Infrastruktur, Continuous Integration, Continuous Delivery und in letzter Zeit auch verstärkt mit – wenn man man einen Hype-Begriff nennen möchte – DevSecOps. Ich komme aber aus der Ecke der Applikations-Entwicklung. Das heißt, ich bin nicht ursprünglich ein Admin oder Operations-Entwickler gewesen, sondern eher aus der Applikationsecke.

Jörg Müller: Wir haben uns jetzt ja das Thema Secrets-Management ausgesucht. Das ist ein Thema, wenn man den Namen hört, dann klingt das erst einmal wahnsinnig wichtig, ganz geheim. Aber ich glaube, so richtig klar ist den meisten nicht, was darunter zu verstehen ist. Vielleicht für unser heutiges Gespräch: Was verstehst du unter Secrets-Management und was macht man damit?

Daniel Bornkessel: Ja, genau, diesen Begriff Secrets-Management, so richtig gibt es den nicht. Man wird dafür zum Beispiel keinen Eintrag bei Wikipedia finden. Es geht um Secrets, wie der Begriff schon sagt. Erst einmal ganz kurz: Unter einem Secret verstehen wir hier nicht Daten, die verschlüsselt zum Beispiel abgespeichert werden müssen in einer Datenbank, sondern es geht wirklich um Passwörter, API-Keys, Tokens, Zertifikate und so weiter.

Jörg Müller: Also eigentlich die Dinge, mit denen man dann auf die verschlüsselten Daten zugreift?

Daniel Bornkessel: Genau richtig, ja. Also beim Secrets-Management geht es um die Schlüssel, mit denen ich Daten verschlüsseln kann, zum Beispiel. Das Ganze ist Teil eines Sicherheitskonzepts in der Firma. Aber im Gegensatz zu den externen Problemen oder Gefahren, die auftreten können, wie zum Beispiel Angriffe von außen, wofür man Firewalls hat, beschäftigt sich Secrets-Management sehr viel mit den Problemen, die von internen Angriffen ausgehen können. Also wenn im Extremfall ein Mitarbeiter der Firma wirklich etwas Böses möchte oder auch wenn ein Mitarbeiter die Firma verlässt und dann aber Passwörter hat, die immer noch gültig sind, obwohl er nicht mehr in der Firma ist.

Jörg Müller: Okay, cool. Bevor wir uns jetzt darüber unterhalten, wie man das ganz modern und schick macht, lohnt sich ja durchaus mal ein Blick in die Vergangenheit und zu schauen, wie man das eigentlich früher gemacht hat und wie ist man früher mit Datenbank-Passwörtern zum Beispiel umgegangen?

Daniel Bornkessel: Genau. Früher, ich sage mal so, vor ungefähr zehn Jahren war das normale Setup von IT eigentlich noch, eine Applikationen war ein Monolith, der wurde auf einem Server deployt und die Server wurden von Admins – also damals hat man immer Admins gesagt, heute sagt man oft OPs oder Operations – von Hand gepflegt. Das Sicherheitskonzept war da einfach, dass es eigentlich eine relativ kleine Gruppe von Leuten gab, die sich um die Secrets oder Passwörter – Datenbank-Passwörter, das ist ein gutes Beispiel – gekümmert haben. Das heißt, sie haben dann auch eine Datenbank aufgesetzt. Der Admin hat eine Datenbank aufgesetzt, hat ein – meistens – sicheres Passwort generiert, die Admins an sich haben damals, glaube ich, auch schon häufig einen Passwortmanager benutzt, bei dem sie die Passwörter abgespeichert haben. Sie haben den Server vorbereitet und haben dort dann Konfigurationsdateien hinterlegt, die dann wiederum Applikationen benutzt haben, um zum Beispiel eine Verbindung zur Datenbank aufzubauen.

Jörg Müller: Und warum geht das nicht mehr?

Daniel Bornkessel: Die Architektur hat sich in den letzten Jahren ziemlich geändert. Vor zehn Jahren waren die Anforderung noch nicht so hoch. Das heißt, mit einem Monolithen konnte man eigentlich noch relativ gut fahren. Wenn man sich heutzutage Geschäfte anschaut, also auch klassische Geschäfte wie zum Beispiel Otto, wird einfach der online-Anteil immer höher. Das heißt, mit dem Monolithen ist man nicht mehr weitergekommen, die haben irgendwann nicht mehr skaliert. Relativ häufig ist man auf eine Microservice-Architektur umgechwenkt. Und das bedeutet dann auch, dass man nicht mehr vielleicht fünf Rechner hat, die man pflegen muss, sondern dass man zwanzig oder dreißig Maschinen hat, weil man zum Beispiel auch fünfzig Microservices hat. Da skaliert die alte Strategie mit „Ich setze einen Server von Hand auf, ich lege dort eine Passwort-Datei hin und ich erzeuge Passwörter für die Datenbanken von Hand“ irgendwann nicht mehr.

Jörg Müller: Und dann ist ja auch noch dieses Thema Continuous Delivery irgendwie dazu gekommen. Dass man gesagt hat, man will das Ganze auch noch automatisch ausrollen. Ich kann mir vorstellen, dass das dabei auch ein Problem ist, wenn ich das…

Daniel Bornkessel: Genau, das auch, vor allem bei Microservices ist man irgendwann auch weg von dem Rechner-zentralisierten Ansatz. Das heißt, früher hatte ich wirklich eine statische Liste und habe gesagt, auf Rechner eins ist Applikation eins deployt und vielleicht auch auch auf Rechner zwei und drei oder von mir aus auch auf einer virtuellen Maschine. Und heute mit Frameworks wie Kubernetes zum Beispiel, weiß ich gar nicht mehr, wo welche App deployt wird. Das heißt, mit der Strategie, ich lege dort eine Passwort-Datei hin, würde ich hier auch einfach nicht mehr weiterkommen.

Jörg Müller: Du hast jetzt schon Passwort-Manager erwähnt, dass man sich also irgendwo zumindest die Passwörter gemerkt hat, damit auch mal ein Kollege darauf schauen kann oder so, damit man das nicht in seinem eigenen kleinen schwarzen Büchlein hat. Gab es daneben noch andere Möglichkeiten, wie man sich das schon mal erleichtern konnte oder wie ist man damit umgegangen?

Daniel Bornkessel: Ja, ganz am Anfang… Ich habe das auch gemacht in einem Projekt. Was ich eben schon gesagt hatte, man ist weg von den Rechnern, und irgendwann kam auch die Container-Technologie auf. Das heißt, eine Applikation, also ich nehme jezt einmal Java- oder Ruby und Rails-Applikationen, wird in einen Container verpackt und hat somit auch überhaupt nicht mehr Zugriff auf den Host, auf dem es läuft. Das heißt, die ursprüngliche Strategie, dass jemand eine Konfigurationsdatei mit den Passwörtern auf einen Host legt, wird da nicht mehr funktionieren, weil der Container normalerweise keinen Zugriff hat. Man muss also eine Möglichkeit haben, wie man die Passwörter der Applikation zum Deployment übergibt. Das sind im Wesentlichen zwei Möglichkeiten gewesen, die man da durchgeführt hat. Einmal, wenn man jetzt eine 12-Factor-App hat, hat man die Passwörter per Environment-Variable hineingegeben, also Umgebungsvariablen, oder man hat die Konfigurationsdatei einfach verschlüsselt in den Container abgelegt und zur Startzeit wurde die Datei dann entschlüsselt und gelesen.

Jörg Müller: Ah ja, okay. Gut, jetzt haben wir sehr oft Applikationen, die nicht nur auf lokaler Infrastruktur laufen, bei denen das so gilt, sondern teilweise auch schon in einer Cloud. Ich habe zumindest bei dem einen oder anderen Cloud-Anbieter auch schon Lösungen gesehen, die sagen, hier, wir machen Secrets-Management. Bei Kubernetes zum Beispiel gibt es Kubernetes-Secrets und ähnliche Dinge. Wie sieht es da aus? Hat sich das schon weiter entwickelt, ist es schon besser geeignet, um meine Passwörter zu speichern?

Daniel Bornkessel: Diese Ansätze wie Kubernetes-Secrets, AWS – da gibt es einen Secrets-Store, es gibt AWS-KMS – die arbeiten im Prinzip ähnlich wie herkömmliche Passwort-Manager. Das heißt, ich habe ein Passwort, das von jemandem, automatisiert oder nicht automatisiert, generiert wird. Jemand nimmt dieses Passwort, speichert es irgendwo verschlüsselt ab und dann zur Startzeit hole ich mir das verschlüsselte Passwort, entschlüssele es und starte damit meinen Service. Das größte Problem sind aber lang anhaltende Secrets. Das heißt, wenn ich eine Datenbank generiere, ein Passwort erzeuge, dann ist das Passwort gültig. Und wenn man das nicht regelmäßig tauscht, dann kann jeder, der einmal das Passwort hatte, einfach so lange auf die Datenbank zugreifen, wie das Passwort gültig ist. Was früher war oder ich denke, in den meisten Firmen ist es immer noch so: Die Datenbank wird erstellt, ein Passwort wird erstellt und dann ist das Passwort einfach gültig. In größeren Unternehmen gibt es dann Compliance-Prozesse. Wenn ich eine ISO 27001 habe, dass ich das einmal pro Jahr oder alle halbe Jahr wechseln muss, aber das sind immer noch sehr langlebige Passwörter. Das heißt, das Problem von langlebigen Passwörtern lösen diese Systeme eigentlich auch nicht.

Jörg Müller: Okay, das heißt, du sagst, nach dem, was man heute eigentlich als Best-Practices – ich mag ja den Begriff nicht so – was man als beste Varianten oder Vorgehensweisen verwendet, um Secrets sicher zu machen, wird dadurch noch nicht hundertprozentig erfüllt? Also was sind denn das für Dinge, auf die man da heutzutage achten müsste?

Daniel Bornkessel: Also das große Problem sind wirklich langlebige Credentials, ob es jetzt Passwörter oder API-Keys oder so etwas sind. Das Problem ist, wenn ich Entwickler bin und eine App deploye und ich möchte wirklich vielleicht einfach böse sein und der Firma etwas Böses wollen, an das Passwort zu einer Datenbank, daran komme ich dann immer. Selbst wenn ich nicht auf den Rechner komme, über den Code kann ich das aus Versehen ausloggen und kann es mir aufschreiben. Mit dieser Methode sind die Passwörter verschlüsselt gesichert, aber man hat immer noch nicht das Problem gelöst, dass Passwörter meistens einfach sehr, sehr lange gültig sind. Ich kenne einfach aus der Praxis kaum eine Firma, die jedes Mal, wenn sie ein Mitarbeiter verlässt, der potenziell mal das Passwort einer Datenbank hätte lesen können, das Passwort dann wirklich wechselt. Das ist der Idealzustand, das weiß auch jeder. Ich sage mal so, die Best-Practices von Secrets-Management, die sind eigentlich wenig überraschend, aber sie sind relativ aufwendig und es ist noch nicht üblich, das so zu automatisieren wie eine Firewall aufzusetzen. Eine Firewall aufsetzen wird jeder machen, HTTPS macht mittlerweile auch fast jeder und das ist bei dem Secrets-Management, würde ich sagen, noch nicht selbstverständlich. Obwohl die Best-Practices, glaube ich, schon eigentlich wenig überraschend sind.

Jörg Müller: Okay. Du hast jetzt, glaube ich, schon an der eim oder anderen Stelle einen Vortrag darüber gehalten, deswegen werde ich dich dazu jetzt genauer fragen: Und zwar über ein Produkt, das nennt sich HashiCorp-Vault. Das scheint ja einen Teil dieser Probleme jetzt irgendwo zu lösen; was ist das und warum sollte man sich das vielleicht anschauen?

Daniel Bornkessel: Genau. Also HashiCorp-Vault reden auch immer über Secrets-Management. Also wie gesagt, es ist nicht so eindeutig spezifiziert, was Secrets-Management jetzt alles bedeutet. Von daher ist es bei mir auch ein bisschen so, die Definition von Secrets-Management ist auch von dem abgeleitet, was Vault als Feature-Set hat. Ganz kurz, bevor ich über Vault rede: Es gibt noch ein paar andere Lösungen, es gibt bei Amazon-AWS – für die, die da zu Hause sind – da gibt es auch den AWS-Secrets-Manager seit… Ich wollte erst sagen, das ist relativ neu, in AWS-Zeiten ist etwas über ein Jahr ja schon fast alt und etabliert. Für die, die auf Cloud Foundry sind, da gibt es CredHub, das macht auch etwas Ähnliches, und dann gibt es noch KeyWhiz von Square.

Jörg Müller: Die machen alle so etwas Ähnliches wie Vault, oder?

Daniel Bornkessel: Jein. Also sie machen alle etwas Ähnliches; Vault ist wirklich mit Abstand die umfangreichste Lösung, wenn es um Secrets-Management geht. Denn Vault hat das Problem geknackt, dass man eigentlich immer langlebige Secrets hat. Die anderen haben auch etwas Ähnliches, die sagen dann nur, dass man Secrets „durchrollieren“ kann oder einfach automatisiert austauschen kann, das muss ich aber von Hand antriggern. Was Vault so besonders macht ist, dass es dynamische Secrets sind. Darüber können wir gleich noch einmal im Detail reden.

Jörg Müller: Ja, genau, das wäre jetzt meine Frage: Also wie hat denn Vault das jetzt geknackt? Du hast gesagt, sie haben das Problem geknackt mit den kurzfristigen Secrets, aber wie?

Daniel Bornkessel: Vault hat etwas einegführt, das sind sogenannte dynamische Secrets. Wenn wir jetzt bei dem Beispiel der Datenbank bleiben, ist es ja im Prinzip so, ich habe einen User-Namen und Passwort damit ich mich bei der Datenbank authentifizieren kann. Das ist halt bei allen Systemen im Prinzip das Gleiche. Manchmal habe ich einen API-Key, was dann nur ein langer String ist, oder ich habe ein Token. Und das Problem ist, wie gesagt, wenn dieser User-Name und das Passwort relativ lange gültig sind. Und was Vault jetzt macht und wie das funktioniert, erkläre ich gleich. Aber was im Prinzip passiert ist, ich fahre eine Instanz meiner Applikation hoch und sie fragt bei Vault an: Ich möchte mit folgender Datenbank sprechen. Und wenn die Applikation authentifiziert und autorisiert ist, erzeugt Vault im Hintergrund quasi on-the-fly einen User-Namen mit einem Passwort und gibt das der Applikation. Und dieser User-Namen und das Passwort sind dann auch nur für eine bestimmte Zeit gültig, das kann ich konfigurieren, normalerweise einen Tag oder so. Im Hintergrund, das hört sich jetzt ein bisschen wie Magie an, das ist nicht so viel Magie. Was da passiert ist, ich konfiguriere Vault so, dass es quasi einen Super-User hat in der Datenbank oder einen Admin-User, der User on-the-fly erstellen und auch löschen kann. Das heißt, was wirklich passiert ist, ich konfiguriere Vault so, Vault hat dann wirklich Zugriff auf meine SQL-Datenbank, wenn eine Applikation ankommt und sagt, ich möchte jetzt Zugriff auf folgende Datenbank haben, dann erstellt Vault bei MySQL jetzt zum Beispiel wirklich Nutzer und Passwort, liefert das meiner Applikation zurück und wenn die time-to-live, also die Gültigkeit, abgelaufen ist, löscht Vault diesen User wieder auf der MySQL-Datenbank.

Jörg Müller: Ah, okay. Und das wahrscheinlich auch nicht nur für Datenbanken, sondern auch für AWS-Accounts etc.

Daniel Bornkessel: Genau, es gibt ja ziemlich viele Systeme im Hintergrund. Man muss dann noch beachten, dass zum Beispiel Postgres selbst so etwas implementiert hat. Da kann ich direkt sagen, ich erzeuge jetzt einen User, der ist gültig bis morgen beispielsweise. Dann macht Vault das nicht, das Löschen, sondern dann verlässt es sich auf das Backend-System, das das macht.

Jörg Müller: Okay, das heißt also, Vault kann dynamisch Passwörter vergeben, die meine Applikationen dann eben nur kurzzeitig verwendet. Und wenn das jetzt irgendjemand klaut oder wenn ein Mitarbeiter geht, dem nützt das nicht allzu viel, wenn er dieses Passwort hat, weil er dann am Ende etwas mitnimmt, was wahrscheinlich morgen schon gar nicht mehr gültig ist.

Daniel Bornkessel: Genau. Je nachdem wie kurz man diese Gültigkeit fasst. Und Vault unterstützt da halt relativ viele Systeme. Also es unterstützt Datenbanken, man kann das mit AWS machen, also wenn man AWS-Zugriff haben möchte, kann man dann auch einfach einen Key generieren, der dann nur eine halbe Stunde gültig ist oder eine Stunde. Ich glaube, RabbitMQ wird zum Beispiel auch unterstützt, Kassandra-Datenbanken. Es werden relativ viele System unterstützt.

Jörg Müller: Jetzt ist dieses Vault also sehr mächtig und kann mir quasi für alle möglichen Sachen in meiner Infrastruktur Passwörter generieren. Das ist dann natürlich auch wieder so ein zentraler Gefahrenpunkt. Wie stellt es denn sicher, dass nicht jeder, der jetzt auf Vault Zugriff hat, dann wiederum auf alle meine anderen Systeme Zugriff hat? Wie funktioniert das?

Daniel Bornkessel: Ja genau, klar. Es ist nicht so, dass das Vault irgendwo ein System ist und jeder kann einfach bei Vault etwas anfragen. Erst einmal noch ganz kurz, das hatte ich, glaube ich, nicht gesagt, Vault hat eine REST-API. Das heißt, ich kann da ganz normal mit mit REST anfragen. Und da kann natürlich nicht jeder anfragen. Das heißt, ich muss mich irgendwie bei Vault erst einmal authentifizieren, dass ich darauf zugreifen darf und dann, wenn ich mich authentifiziert habe, gibt es einen Autorisierung-Mechanismus, bei dem Vault feststellt, was ich lesen darf und was nicht.

Jörg Müller: Aha, okay.

Daniel Bornkessel: Und das Schöne an Vault ist, man muss sich das so vorstellen: In der Mitte ist dieses Vault, ich komme von links an, ich authentifiziere mich irgendwo und rechts kommen viele mögliche Arten von Secrets heraus. Wenn ich jetzt mal bei der rechten Seite anfange: Wir hatten eben schon diese dynamischen Secrets, die dann neu erstellt werden. Ich kann dort natürlich auch statische Secrets speichern, die werden dann einfach verschlüsselt abgelegt. Wenn ich zum Beispiel einen API-Key von einem Fremdanbieter habe, steht es nicht in meiner Macht, den dynamisch zu erstellen. Das heißt, ich habe auch weiterhin wahrscheinlich einige Secrets, die statisch sind. Und auf der linken Seite von Vault melde ich mich irgendwie an. Da gibt es verschiedene Arten, wie ich mich anmelden kann, zum Beispiel als Benutzer kann ich einfach ein LDAP anhängen. Ich sage Vault, ich möchte auhentifizieren mit der Methode LDAP, gebe Username und Passwort an Vault. Vault schickt das dann weiter zu dem LDAP-Server und bekommt dann zurück, das ist zum Beispiel User Daniel für die Gruppe Entwickler. Und dann gibt es innerhalb von Vault ein Mapping, das sagt, okay, Anmeldung über LDAP, Gruppe Entwickler, User Daniel. Dann erstellt Vault ein Token und an dem Token hängen Berechtigungen dran, was ich lesen darf. Das heißt, man meldet sich immer an mit welchen Systemen und bekommt im Austausch, wenn man authentifiziert ist, ein Token und an dem Token hängen Berechtigung dran, was ich lesen darf.

Jörg Müller: Okay, also wenn ich wenn ich der Super-Admin bin, dann kann ich mir quasi jedes Passwort generieren oder auch auslesen, wenn es ein statisches ist, und wenn ich zum Beispiel die Anwendung bin, die wirklich nur einen Datenbank-Passwort braucht, dann gibt es vielleicht für diese Anwendung eine Rolle Datenbank-Passwort-Owner oder wie auch immer.

Daniel Bornkessel: Genau. Und bei den Authentifizierungsmechanismen gibt es auch zahlreiche Arten, wie ich mich authentifizieren kann. Also das, was ich eben als Beispiel gesagt habe, ist jetzt halt ein Benutzer, der einen Usernamen und ein Passwort hat. Das wäre jetzt für eine Applikation ziemlicher Quatsch, weil ich dann quasi das Datenbank-Username-Passwort-Paar durch ein Vault-Username-Passwort-Paar ersetze, dadurch hätte nichts gewonnen. Vielleicht wie beim herkömmlichen Passwort-Manager, dass ich statt zehn Passwörtern nur noch eins haben muss, aber das Problem bleibt gleich, ob ich jetzt ein Passwort dahin geben muss oder zehn, ist dann auch nicht mehr der große Unterschied. Das heißt, für Applikationen gibt es dann auch bestimmte Mechanismen, wie die sich authentifizieren können.

Jörg Müller: Was wären das so für Mechanismen?

Daniel Bornkessel: Zum Beispiel in Kubernetes läuft jeder Container mit einem Service-Account. Also ein Service-Account, wer das nicht kennt, das ist so etwas wie ein technischer User. Das heißt, man kann keinen Container starten, der nicht mit einem Service-Account gestartet ist. Und jeder Service-Account hat wiederum einen Token, der benutzt werden kann, um mit der Kubernetes-API zu sprechen. Und dieser Token ist in jedem Container, der in Kubernetes läuft, unter einem bestimmten Pfad, ich glaube /var/kubernetes/secrets, gemountet. Und dann kann ich, wenn ich Vault nutzen möchte, diesen Toten nehmen und kann zu Vault sagen: Ich möchte mich authentifizieren mit der Methode Kubernetes und gebe Vault den Token. Vault nimmt den Token, fragt bei der Kubernetes-API an, ob das ein gültiger Token ist und in der Antwort – und das ist wieder ähnlich zu LDAP – steht in Kubernetes jetzt drin, das ist der Service-Account mit diesem Namen und der Container läuft in diesem Namespace. Und basierend auf der Kombi von Namen und Namenspace erzeugt Vault dann wieder ein Token, an dem bestimmte Berechtigungen hängen. Für eine Applikation zum Beispiel, dass die Applikation das Datenbank-Passwort für folgende Datenbank lesen darf.

Jörg Müller: Ah, okay.

Daniel Bornkessel: Das heißt, das Problem, wer das Secret hat, haben wir jetzt bis zu Kubernetes hin ausgelagert. Das heißt, wir müssen kein initiales Passwort mehr irgendwem geben, sondern Kubernetes legt ein Token in den Container hinein und wir verlassen uns auf die Sicherheitsmechanismen von Kubernetes.

Jörg Müller: Okay. Vergleichbares gibt es dann vermutlich auch für AWS-IAM-Rollen oder Ähnliches, oder?

Daniel Bornkessel: Genau, bei AWS, Azure und auch bei Google ist es so, dass… Virtuelle Maschinen haben immer so etwas wie Metainformationen, die kann man meistens mit Curl abfragen wie http://169.254.169.254.

Jörg Müller: Super. Wir schreiben das in die Shownotes.

Daniel Bornkessel: Darin stehen Metainformationen. Bei AWS steht darin zum Beispiel, das ist die virtuelle Maschine mit folgender ID, die hat die folgenden Rollen, läuft in folgendem Datenzentrum. Es gibt da relativ viele Informationen. Und dieses Dokument, diese Metainformationen, gibt es auch einmal verschlüsselt. Eine verschlüsselte Form mit dem Private Key von AWS. Wenn man sich jetzt mit der Methode AWS authentifizieren möchte, nimmt man dieses verschlüsselte Dokument und gibt es Vault. Und Vault wiederum kennt die Public Keys von AWS, die sind ja allgemein bekannt. Das heißt, Vault entschlüsselt das Dokument, wenn das funktioniert, weiß es, okay, das wurde von Amazon signiert, und kann dann, basierend wiederum auf dem, was in diesem Dokument an Metainformationen drinsteht, Token erzeugen. Das heißt, da haben wir wieder so ein Mapping von: Wenn es eine EC2-Instanz ist mit folgender Rolle oder folgendem Profil, dann hat die folgende Rechte.

Jörg Müller: Ah ja, okay. Das heißt also, wir haben jetzt relativ klar beleuchtet, wie man überhaupt an das Vault, an die Informationen in Vault herankommt, da gibt es also wahnsinnig viele Mechanismen. Du hast das vorhin die linke Seite genannt, wenn Vault dann sozusagen in der Mitte ist, und auf der rechten Seite haben wir dann ganz viele Möglichkeiten, die Passwörter zu erzeugen. Jetzt gibt es ja häufig in so einem Umfeld, in dem man vielleicht Compliance-Regeln zu beachten hat etc., noch die Anforderung, dass man noch herausfindet, wer hat was gemacht, also Auditing. Wird das von Vault auch unterstützt oder wie ist das?

Daniel Bornkessel: Also es ist default-mäßig nicht eingeschaltet, man muss es einschalten. Und dann gibt es zwei oder drei Backends, in die man hinschreiben kann. Das ist einmal einfach ins Dateisystem oder ins Syslog, glaube ich, und ich weiß nicht, ob es noch eins gibt, einen Unix-Socket, glaube ich. Und das ist so, wenn Vault das Audit-Log nicht schreiben kann, dann beantwortet Vault überhaupt keine Fragen. Das ist einfach so, wenn es eine Datei wäre, könnte man sonst einfach als Angreifer die Festplatte so voll schreiben, dass Vault nichts mehr schreiben kann, macht irgendetwas und danach löscht man die Dateien wieder, dann sieht man das im Log nicht. Das heißt erst einmal, wenn Audit eingeschaltet ist, funktioniert Vault nur, wenn er schreiben kann, ansonsten beantwortet Vault keine Fragen mehr. Das heißt, man muss wirklich aufpassen, dass das funktioniert. Und dann wird jede Operation, die ich mache, geloggt und zwar inklusive der Secrets, die ausgegeben werden, aber in einer gehashten Form. Das heißt, das Datenbank-Passwort wird ins Log geschrieben, zum Beispiel Jörg hat sich angemeldet mit LDAP und hat das Passwort für die Datenbank eins gelesen und das Passwort war Folgendes. Dann steht aber der Hashwert da, das heißt, ich will natürlich in den Logs nicht mein Datenbank-Passwort haben.

Jörg Müller: Ja, das wäre irgendwie…

Daniel Bornkessel: Genau. Das heißt auch wirklich gehasht, nicht encrypted. Und die Idee dahinter ist, wenn es jetzt wirklich einen Angriff gegeben hat und wir wissen, folgendes Passwort wurde benutzt, dann kann ich das Passwort mit demselben Hash-Mechanismus hashen und kann dann in den Audit-Logs danach suchen.

Jörg Müller: Und dann kann ich quasi herausfinden, dieses Passwort, das wurde von Vault an den Jörg herausgegeben und ich höre schon die Handschellen klicken bei mir. Das heißt, ich weiß ganz genau, dass, was da geleakt ist, kann eigentlich nur auf diesem Weg geleakt worden sein. Okay, das ist natürlich dann auch ein interessanter Mechanismus, die Sicherheit dann noch einmal zu erhöhen. Spannend. Jetzt habe ich im Zusammenhang mit Vault mal irgendwo etwas ganz Spannendes gelesen: Diese Vault-Datenbank, du hast es gerade gesagt, wenn das Audit nicht funktioniert, dann antwortet sie nicht. Aber man kann sie ja auch so komplett zu machen, habe ich mal gehört. Also man kann sie locken, also die gesamte Datenbank dicht machen, sodass gar niemand darauf kommt, und kann sie dann auch quasi wieder freischalten und da benutzen sie irgendeinen ganz interessanten Mechanismus namens Shamir’s Secret Sharing oder so. Was ist das? Ich fand das ganz faszinierend.

Daniel Bornkessel: Da muss man, glaube ich, kurz erklären, wie… Also Vault speichert natürlich alle Daten verschlüsselt ab, encryptet at rest. Das heißt, es wird nie auf Festplatte irgendetwas geschrieben, was nicht verschlüsselt ist, und alle Daten sind mit einem Key verschlüsselt. Und dieser Key wiederum liegt auch auf der Festplatte, aber auch wiederum verschlüsselt. Also ich habe Daten, die sind verschlüsselt mit einem Key, der Key liegt neben den Daten und die sind wiederum mit einem anderen Schlüssel verschlüsselt und das ist der sogenannte Master-Key. Und um den Master-Key zu entschlüsseln, da wird dieser Algorithmus benutzt, dieses Shamir’s Secret Sharing. Das funkioniert folgendermaßen: Wenn ich das entschlüsseln will, brauche ich halt mindestens – ich sage mal, ich nehme einfach drei – ich brauche mindestens drei andere Keys. Statt Key kann man auch Passwort sagen, wenn man gerne möchte. Also ich brauche drei Keys, um dieses Master-Passwort zu entschlüsseln. Und die Keys können in beliebiger Reihenfolge angegeben werden. Das Interessante dabei ist jetzt, dass ich auch insgesamt fünf Keys erzeugen lassen kann. Das heißt, ich habe fünf Keys, um dem Master-Key zu entschlüsseln, ich brauche aber immer nur drei. Die können in beliebiger Reihenfolge angegeben werden. Die Idee dahinter ist, dass wenn der Vault zum Beispiel neu deployt wird – das gilt auch für jede Instanz von Vault, wenn ich fünf Instanzen von Vault deployt habe, weil ich eine hohe Verfügbarkeit haben möchte – muss jede Instanz, wenn sie neu gestartet wird, einmal von Hand ungesealt werden, also entschlüsselt werden. Im Prinzip heißt das, den Master-Key entschlüsseln. Und dafür brauche ich dann drei meiner Keys von den fünf zum Beispiel. Drei von fünf brauche ich, um den Key zu entschlüsseln. Dann wird der Master-Key entschlüsselt, der Master-Key entschlüsselt wiederum den anderen Key, mit dem die Daten verschlüsselt sind. Dann kann Vault erst einmal die Daten lesen. Das heißt, wenn ich Vault starte, kann ich mich auch authentifizieren, aber das nützt mir nichts. Ich muss erst einmal den Schlüssel entschlüsseln, mit dem die Daten verschlüsselt sind. Das sind jetzt sehr viele Schlüssel und Entschlüsselungs-Keys.

Jörg Müller: Secrets over Secrets over Secrets, sehr schön.

Daniel Bornkessel: Genau. Und diese fünf Keys, das ist auch noch interessant, die werden erzeugt, wenn ich den Vault initialisiere. Und das Problem ist jetzt natürlich, man kann sagen, wenn ich sie initialisiere, hat jemand alle fünf Keys und dann sind doch alle fünf Key alle auf einmal sichtbar gewesen. Das Interessante dabei ist, dass man da auch GPG-Keys benutzen kann.

Jörg Müller: PGP ist?

Daniel Bornkessel: Pretty good privacy (Anm. eigentlich: GNU Privacy Guard)

Jörg Müller: Genau.

Daniel Bornkessel: Ich weiß nicht, ob ich jetzt hier zu technisch abnerde, aber was man machen kann, wenn man zum Beispiel fünf Keys erzeugen möchte, man kann sich von fünf Kollegen fünf Public GPG-Keys geben lassen, kann sagen, initialisiere Vault und ich bekomme diese Keys zum Entschlüsseln, die sind dann jeweils mit den Public Keys verschlüsselt, und kann die dann an die Entwickler zurückgeben. Das heißt, jeder bekommt seinen eigenen Key und bekommt den komplett verschlüsselt und kann den nur mit seinem Private Key entschlüsseln. Das heißt, ich kann Vault wirklich aufsetzen von Anfang an, ohne dass irgendeiner alleine den Vault entschlüsseln kann mit irgendeinem Master-Passwort.

Jörg Müller: Okay, das ist natürlich durchaus wichtig, gerade auch für später. Interessant. Das Ganze klingt natürlich wahnsinnig komplex. Wie komme ich denn an so eine Instanz von Vault? Wie installiert ich das?

Daniel Bornkessel: Ja, das ist gut. Also wenn man Tutorials für Vault sucht, sieht das immer total super einfach aus; man kann auch relativ schnell mit Vault herumspielen. Es gibt, glaube ich, auch so eine interaktive Sache im Internet, da wird einfach eine Vault-Instanz hochgefahren. Das Problem bei den Tutorials ist immer nur, dass die im Developer-Modus starten. Das heißt, ich habe eine Instanz, ich brauche keine Zertifikate und das ist super einfach. Wenn ich das jetzt produktionsreif aufsetzen möchte, muss man erst einmal mindestens mindestens drei Vault-Instanzen am Laufen haben, würde ich sagen, damit ich die Hoch-Verfügbarkeit habe. Das heißt, falls dann eine eine Vault-Instanz umfällt, übernimmt die nächste automatisch. Das Setup ist immer: Eine ist aktiv und zwei sind passiv. Das heißt, es antwortet immer dieselbe Instanz, sobald sie nicht da ist, übernimmt die nächste Instanz. Das Problem ist, wenn ich die Development-Version aufsetze, ist das relativ einfach. Ich habe eine Instanz und wenn ich produktionsreif aufsetze, findet die Kommunikation natürlich verschlüsselt statt. Das heißt, ich muss auch mit Zertifikaten herumhantieren und muss Vault dann aufsetzen. Da ist erst einmal relativ wenig zu finden. Die Lernkurve für Vault ist auf ziemlich steil, finde ich. Denn dadurch, dass wir viele Arten haben, um uns authentifizieren zu können, und auf der anderen Seite viele verschiedene Arten von Secrets haben, die Vault ausspucken kann, gibt es sehr viele Systeme, mit denen man interagiert und alle haben ähnliche Begriffe, alle haben Keys und Tokens und times-to-live und alles ist irgendwie so ein bisschen anders. Und man jongliert im Kopf die ganze Zeit mit Keys und Zertifikaten herum. Ich fand es am Anfang sehr verwirrend. Das heißt, die Lernkurve für Vault ist, ehrlich gesagt, ziemlich steil am Anfang. Wenn man das dann einmal geknackt hat, dann geht das, aber es dauert erst. Das heißt, ich finde es relativ schwer zu lernen am Anfang.

Jörg Müller: Das schreckt jetzt ja potentielle Hörer durchaus ab.

Daniel Bornkessel: Das schreckt vielleicht wirklich ab. Aber wir hatten das im Projekt auch mal, dass wir uns entschieden haben, Vault zu nutzen, obwohl es abschreckend war, weil es erst einmal aufwändig ist. Aber danach konnte jedes Problem mit regulatorischen Anforderungen, die man hat, dann wirklich durch Vault gelöst werden. Man hat dieses Auditing darin; man kann garantieren, dass Secrets – die Anforderung war, glaube ich, ein halbes Jahr, aber unsere Secrets waren maximal einen Tag gültig. Man hat automatisch seine Zertifikate, weil das auch Privat Key Infrastructure ist. Darauf möchte ich jetzt vielleicht nicht eingehen, ich möchte nur kurz erwähnt, dass auf jeden Fall auch automatisierte Privat Key Infrastructure im Vault drin ist. Man hat diese ganzen regulatorischen Probleme dann gelöst. Zwei Wochen am Anfang schwirrt einem der Kopf und danach löst Vault einfach super viele Probleme für einen automatisch, die man hat.

Jörg Müller: Gibt denn es etwas, wo man sich, wenn man sich mit dem Thema näher beschäftigen möchte, ganz gut einarbeiten kann? Irgendwelche Hinweise, die du gehen kannst?

Daniel Bornkessel: Es gibt zahlreiche Tutorials und dann gibt es auf [vaultproject.io], wie gesagt, so ein interaktives Tutorial, da kann man sich schon einmal herantasten. Nur ein Problem ist, das ist vielleicht auch das Problem am Anfang, wenn man Vault nutzen möchte und zwar zum Beispiel auch im Kubernetes- und AWS-Umfeld, dann ist das Problem, dass man das nicht wegmocken kann. Das heißt, wenn ich testen möchte, funktioniert das in Kubernetes mit einer MySQL-Datenbank und einer Postgres-Datenbank und einer Cassandra-Datenbank auf AWS, dann muss ich diese ganzen Systeme wirklich haben. Ich kann da nicht herumspielen, sondern ich muss diese Systeme haben. Das hat es auch für mich auf jeden Fall am Anfang schwer gemacht, mal eben so einen Proof of Concept zu machen. Denn man braucht halt eine Datenbank, die dann läuft, man braucht einen AWS-Account, der dann irgendwie funktioniert, oder man braucht ein Kubernetes-Cluster. Das finde ich erst einmal relativ schwer. Und noch eine Sache, die man auch bedenken muss: Man muss jede Applikation anpassen, dass sie mit so etwas umgehen kann. Ich sage mal so, die normale Applikation kann jetzt nicht damit umgehen, dass ein Passwort von einer Datenbank nach einem Tag nicht mehr gültig ist. Also wir hatten da Spring-Applikationen, denen wir das erst beibringen mussten: Wenn das Passwort nicht gültig ist, dann lies noch einmal die Konfigurationsdatei, versuch es noch einmal, wahrscheinlich funktioniert es dann. Das heißt, man muss die Applikation auch so ein bisschen anpassen. Selbst wenn man das wegabstrahiert, indem auch die Secrets über ganz normale Property-Dateien hineingegeben werden, dass Secrets verfallen oder dass Passwörter nicht mehr gültig sind, das müssen die Applikation halt auch können, darauf sind wenige vorbereitet.

Jörg Müller: Okay, klar. Also ich habe schon einen gewissen Aufwand, mich überhaupt erst einmal in das Vault und in das Setup von dem Vault einzuarbeiten, und ich muss meine Applikationen entsprechend darauf anpassen, dass sie damit arbeiten. Wenn ich das allerdings habe, dann habe ich am Ende ein ziemlich modernes Secrets-Management, womit ich jeden Auditor in irgendeiner Form glücklich mache, womit ich auch Sicherheitsanforderungen erfülle, die, ich sage mal, ein sehr, sehr hohes Level haben, die eigentlich alle guten Verfahren und Dinge einsetzen, die man so haben möchte an der Stelle. Okay, die Arbeit lohnt sich, aber man muss sich erst einmal doch schon tiefer damit beschäftigen, höre ich da heraus.

Daniel Bornkessel: Ja, also ich würde sagen, die Arbeit lohnt sich auf jeden Fall. Es sei denn, man hat wirklich quasi nichts zu verstecken. Wenn man jetzt wenig sensible Daten hat, ist es vielleicht overkill, aber es lohnt sich relativ früh. Und wenn man das einmal verstanden hat, dann kann man viele Probleme einfach damit erschlagen. Es ist eine gute Investition, aber halt eine ein bisschen anstrengende Investition am Anfang.

Jörg Müller: Cool. Das war eine sehr spannende Einführung. Tatsächlich nur ein Anfang mit ein paar Momenten, einem auch Respekt davor zu verschaffen, was man da machen muss, aber ein sehr spannendes Thema. Vielen Dank, vielen Dank für das Gespräch Daniel und bis zum nächsten Mal.