Nur ein npm Package, ein versteckter Wurm und Zack,
plötzlich sind Eure Github Tokens Adbl, US Keys und
Datenbankpasswörter in den falschen Händen.
Wie sicher ist deine developer Maschine wirklich und warum
arbeiten wir überhaupt noch mit langlebigen Secrets, die überall
rumliegen? In dieser Folge sprechen wir
über Zero Trust für Developer von der Dot End Hölle hinzu
Manage Identities die Passwörter komplett überflüssig machen.
Es wird konkret, es wird praktisch und am Ende habt ihr
eine Liste, was ihr morgen ändern könnt.
Viel Spaß. Und damit herzlich Willkommen zu
einer neuen Folge des To do Developer Podcasts, eurem
deutschen Developer Podcast. Mit mir malte Lantin und Robin
Manuel Thiel Robin Manuel ist Director AI und Cloud beim E
Commerce Softwareunternehmen Jtl und ich bin Solutions Engineer
bei github. Den Podcast machen wir wie immer
privat und in unserer Freizeit, sprechen aber hier natürlich auf
Basis unserer Praxiserfahrung und zahlreichen Gesprächen und
der Zusammenarbeit mit. Euch in der Community und heute
geht es um das Thema Security und wie wir unseren eigenen
Arbeitsplatz sicherer gestalten können, damit wir nicht
diejenigen sind, die beim nächsten online kursierenden
Wurm alle unsere Secrets verlieren.
Ein sicherer Arbeitsplatz ist aber auch ein wacher
Arbeitsplatz. Damit man nämlich aufmerksam ist
und sich allen Gefahren bewusst ist.
Und da hilft dem klassischen Developer natürlich Kaffee und
Kaffee haben wir ganz viel von Euch bekommen, von unserer
Community ganz ganz herzlichen Dank.
Und zwar hat der David uns 3 Kaffee ausgegeben, der Nico hat
uns einen Kaffee ausgegeben, vom Lars haben wir 3 Kaffee
bekommen, vom Gerhard haben wir 3 Kaffee bekommen und vom Jonas
haben wir noch einen Kaffee bekommen.
Wow, das ist eine richtige Kaffeeflut.
Vielen, vielen Lieben Dank auf jeden Fall und alle, die uns
Ihren Kaffee ausgegeben haben. Und dann lasst uns direkt ins
Thema einsteigen. Wir reden heute über die
Sicherheit unserer Developer Maschine und dem, was hinten
dran kommt, CI Pipelines oder natürlich auch die Secrets die
wir brauchen, damit unsere Applikation mit anderen Systemen
kommunizieren kann und das Ganze, damit wir nicht auf.
Opfer werden von einem Wurm wie Chaihulut, der nach Secrets auf
der lokalen Maschine gescannt hat und dann diese Secrets
extrahiert hat. Und ja, da gibt es ganz viele
Dinge, die man tun kann, damit man nicht seine Github Tokens,
npm Tokens oder WS Keys verliert, weil man sie mal
wieder in seiner Dot NV Datei abgelegt hat.
Genau darüber haben wir ja die letzten Folgen auch viel
gesprochen. Jetzt wird es diese Folge
konkret, was man da eigentlich machen kann, dass.
Denn das haben wir auch besprochen.
Dieser Wurm konnte sich ja nur verbreiten, weil ganz viele von
uns halt auch einfach Tokens, die in irgendwelchen Dateien auf
der eigenen Maschine liegen haben lassen, die dieser Wurm
dann scannen konnte und benutzt hat, um sich selber
fortzupflanzen und deswegen steigen wir doch einfach mal an
mit einer provokanten Frage, fasst euch da mal selber an die
Nase, wie viele von euch, die hier gerade zuhören.
Haben einen npm Token auf ihrer Festplatte liegen oder irgendwie
ein Äquivalent davon, vielleicht sogar in den von Malte gerade
angesprochenen Dot 11 Dateien oder einen Connection String zu
einer Datenbank oder irgendwas wo man sich eigentlich schon
bewusst ist, dass es da nicht da nicht hingehört.
Und genau darum geht es heute. Zero Trust für unsere Dev
Maschinen, aber auch für unsere Pipelines und unsere Apps
nachher und. Und da gehen wir jetzt ein
bisschen rein. Und wenn wir über Zero Trust
reden, reden wir darüber, dass wir nicht einfach pauschal
unserer lokalen Entwicklermaschine oder einem
Secret, was da drauf liegt, vertrauen, sondern immer prüfen,
ob wirklich diese Person oder diese Pipeline den Zugriff auch
haben soll. Und von daher müssen wir das ein
bisschen breiter. Spannend.
Es ist nicht nur mein mein Laptop oder irgendwie meine
Entwicklungsumgebung, sondern das ist alles, was mit meinem
Arbeitsplatz zu tun hat, wo ich secret.
Ablege, weil diese Secrets natürlich gern genommene Beute
von Cyberkriminellen sind, weil sie entsprechende Werte
darstellen. Wenn ich entweder dadurch meinen
Wurm verbreiten kann oder vielleicht auch einfach über
einen Cloud Key die Möglichkeit habe, zu deinen Kosten irgendwie
Bitcoin Mining zu machen oder vielleicht meinen Open Claw
Agent auf einer WM laufen zu lassen, für die du zahlst.
Warum auch nicht? Und dabei kommt es nicht nur
darauf an, was ich denn alles auf meinem Rechner oder
vielleicht generell in meinem Zugriffsbereich an API Keys,
Passwörtern, Tokens, Connection, Strings, all diesen Dingen habe,
sondern natürlich auch, auf welche Systeme ich generell
Zugriff habe. Wir haben, du hast gerade Open
Claw schon selber erwähnt, da kann mein Browser fernsteuern,
das heißt, ich könnte sogar theoretisch mit Schadsoftware
über so ein Tool einfangen oder es könnte Schadsoftware auf
meinem Rechner geben, die einfach anfängt meinen Rechner
fernzusteuern. Und da muss ich mich schon
fragen, habe ich vielleicht dauerhaft Admin Rechte auch auf
dem System, wo ich vielleicht nicht dauerhaft Admin rechte
haben sollte oder muss mir die über besser mal über
irgendwelche Elevated permissions holen oder einen
dedizierten Admin account? Das heißt, das müssen wir
eigentlich Gesamtheitlich betrachten, die Dinge, über die
ich über Tokens und Credentials Zugriff habe und die Dinge, auf
die mein User Account Zugriff hat, einfach dadurch, dass er
auf meinem Rechner angemeldet ist.
Ja, und da hat sich ja in den letzten 1015 Jahren auch ein
bisschen was verschoben. In der Vergangenheit konnte man
sagen, ich habe irgendwie eine Sicherheit, allein dadurch, dass
meine developer Maschine im Unternehmensnetzwerk ist oder
vielleicht meine cicd Pipeline auf einem System läuft, welches
direkt im gleichen Netzwerk ist wie das Zielsystem und
mittlerweile ist sowohl mein lokaler Rechner außerhalb des
Unternehmensnetzwerks häufig, ich bin unterwegs.
Unterwegs. Ich arbeite von zu Hause, ich
arbeite vielleicht mit dem eigenen Laptop oder ich bin in
irgendeinem nichts vertrauenswürdigen wi fi
unterwegs und kann dann trotzdem oder muss dann trotzdem auf
bestimmte Systeme zugreifen und von daher kann ich nicht einfach
dem User vertrauen, sobald er in meinem Netzwerk ist, sondern ich
muss mir halt neue Dinge überlegen und selbst wenn ich
jetzt mich per VPN einwähle, heißt das ja nicht unbedingt,
dass ich vertrauenswürdig bin, nicht.
Nur weil ich dann in diesem Netzwerk bin, sondern ich muss
auch weiterhin, das hast du gerade gesagt, prüfen, ja, wer
bist du eigentlich und welche Rechte hast du?
Und das ist so diese Grundidee von Zero Trust.
Das heißt, ich kann nicht pauschal jemandem vertrauen,
sondern ich muss dieses Vertrauen mir quasi immer
erarbeiten, das heißt, ich verifiziere jedes Mal, wenn es
eine Anfrage gibt, wer ist das eigentlich und welche Rechte
sollte diese Person haben. Und deswegen sollten wir, wenn
wir das Problem angehen oder für uns erkannt haben, idealerweise
mal mit einer Bestandsaufnahme starten.
So was gibt es denn eigentlich bei uns im Unternehmen für
Secrets und für übermäßig überzogen große Rechte und ja,
die Realität zeigt dann oft so typische Antipedanz, die man
schon kennt, ich sag mal, manche Dinge sind davon
glücklicherweise schon ein bisschen seltener geworden, zum
Beispiel irgendwie hart codierte Secrets im Code, die.
Das ist, glaube ich, hoffentlich nach über 150 Folgen to do Cast
jedem und jeder der hier zuhört, klar, dass die da nicht
reingehören, aber eigentlich gehören die auch nicht in eine
NF Datei neben den Code und nur weil man sagt, ja die ist ja im
Gittig no, die ist ja gar nicht eingecheckt, haben wir durch
Shyhoulood und so was uns eines Besseren belehren lassen uns,
dass sie da eigentlich genauso schlimm sind und.
Auch theoretisch halt auch nicht eingecheckte und vor allem auch
unverschlüsselte Dot 11 Dateien Risiken bergen können, genauso
wie Hardcodierte Secrets im Code und genauso schlimm sind
natürlich sowas wie geteilte Admin Konten, wo dann das ganze
Team das gleiche Passwort verwendet oder Stichwort
gleiches Passwort, auch wenn man für die Def und Staging und prot
Umgebungen dieselben Passwörter verwendet und das kann natürlich
alles irgendwie passieren und das ist jetzt auch nicht
komplett abwegig. Also wenn ich mir anschaue.
Wie viele Unternehmen ich schon gesehen habe, in denen Secrets
auch einfach mal schnell über eine E Mail geschickt werden,
weil es vielleicht einfacher ist als sie den Passwortmanager
einzutragen oder über Slack oder Teams sich mal eben einen API
Key hin und her geschickt, wird das natürlich auch auf dem
eigenen Rechner landet und auch Auslesbar ist.
Das sind natürlich alles Dinge, wo ich mir sagen kann, das
wissen wahrscheinlich die meisten Leute, dass das nicht
ganz cool ist, aber ist halt auch irgendwie so ein
Convenience Faktor und. Und da kommen wir, glaube ich,
gleich schon zu einem ganz, ganz spannenden Punkt, dass
Sicherheit, und davon bin ich überzeugt, auch immer irgendwie
einfach sein muss, weil wenn sie mir im Weg steht, wird sie auch
irgendwie umgangen, aber ich glaube, von all diesen
Beispielen haben wir alle mindestens 1 dieses Jahr schon
mal selber gemacht. Ja, und das, obwohl uns, glaube
ich, allen bewusst sind. Was die Risiken sind.
Also ich weiß, dass ich dieses Secret ausnutzen kann, wenn sie
verloren gehen, wenn sie leaken und so ein Leak kann ja nicht
oder muss ja nicht unbedingt durch irgendwie Schadsoftware
entstehen, es kann auch tatsächlich jemand sein, der
vielleicht bei mir im Unternehmen wirklich böswillig
Informationen extrahiert, oder es kann einfach.
Passieren, dass irgendwelche Datenträger verloren gehen, wo
diese Passwörter gespeichert sind in irgendwelchen Dateien
und diese credentials kann ich dann ausnutzen, sofern sie lange
gültig sind und die größte Herausforderung dabei ist
natürlich auch, dass ich dann auch nicht zuordnen kann, wer
hat eigentlich auf eine bestimmte Ressource zugegriffen,
weil es ja vielfach geteilte Secrets sind, das heißt, sobald
du jetzt zu mir gehst, sagst schick mir mal einen Secret per
Slag rüber, ist am Ende nicht mehr klar, habe ich.
Nicht auf eine Ressource zugegriffen.
Hast du das gemacht und falls dieses Secret letzten Endes
irgendwie verloren geht, eine League passiert, können wir auch
gar nicht mehr zuordnen. Wo ist eigentlich diese Lücke
entstanden, also müssen wir jetzt dein System vipen mein
System vipen Wer hat die Schadsoftware drauf?
Das einzige was wir wissen ist, dass wir sobald wie möglich
dieses Secret rotieren ungültig machen müssen, eigentlich sofort
wenn wir merken, da findet Missbrauch statt.
Und das ist dann natürlich auch eine Situation, wo extrem Druck
entsteht. Wir müssen das möglichst schnell
machen, um das Risiko zu minimieren, und wenn wir dann
nicht wissen, wo wir angreifen müssen, haben wir natürlich ein
extrem großes Problem. Ja, auch nicht nur, wenn wir es
unter Druck machen, sondern es gibt ja auch einfach so diese
klassische Horror Story. Der Freelancer verlässt die
Firma und ja, er hat natürlich noch alle Tokens für unsere
Package Manager und unsere Cloud Umgebung auf dem Rechner und.
Und ja, alle wissen, eigentlich müssten wir jetzt mal Secrets
rotieren. Dasselbe natürlich, wenn
irgendwie ein Secret geleakt wird, aber das ist auch
manueller Aufwand, das haben wir noch nie irgendwie
durchgespielt, da gibt es keine Prozesse für und dann habe ich
einfach Angst, dass ich vielleicht irgendwas kaputt
mache, indem ich was rotiere und dann ja rotiere ich vielleicht
lieber nicht, vertraue diesem Freelancer idealerweise oder
kann ja auch ein ehemaliger Mitarbeiter sein, der das
Unternehmen verlässt, oder? Und die Keys bleiben aktiv und
da komme ich wieder so ein bisschen zu meinem Punkt am
Anfang. Am besten wäre es, wenn wir gar
keine Secrets erst haben und deswegen schauen wir uns jetzt
mal so ein bisschen an wie wir so richtiges Zero Trust in cicd
Umgebungen, aber auch auf developer Maschinen umsetzen
können, ohne dass es überhaupt Secrets gibt, die.
Die ich liegen kann, denn da gibt es mittlerweile Methoden
für. Wir sind schon sehr viel weiter
als noch vor 5 Jahren. Ganz viele Plattformen haben
auch schon Dinge eingebaut, auch jetzt gerade noch mal in den
letzten sage ich mal 6 Monaten ist viel dazu gekommen, weil wir
immer mehr diese Angriffe gesehen haben und es geht schon
mittlerweile und das Beste Secret ist eigentlich gar kein
Secret. Und da kann ich sowohl in der
cicd Umgebung als auch auf meinen eigenen Rechnern schon
relativ viele Secrets eigentlich rausschmeißen.
Wenn ich weiß wie. Ja, vielleicht fangen wir mal
mit der developer Maschine an, weil du hast gerade dieses
Beispiel genannt von dem Freelancer, der mein Unternehmen
verlässt. Und da wäre es natürlich gut,
wenn die. Die gerade genannten Adabl OS
Secrets dort nicht auf der Maschine liegen würden, weil
diese Person zwar Zugriff auf bestimmte Ressourcen hatte, aber
das jeweils nur per Login. Single Sign on mit Multifactor
Authentication auf entsprechende Systeme, dort dann per Roll
based Access Control Zugriff auf diese Ressourcen hatte und
sobald diese Person das. Das Unternehmen verlässt kann
ich den Account deaktivieren und damit verlieren alle diese
Zugänge sofort ihre Rechte und können nicht mehr missbraucht
werden. Und genauso sollten natürlich
diese Zugangsrechte im Idealfall immer extrem kurzlebig sein, im
Idealfall per just in Time, das heißt, wenn ich irgendwelche.
Ja, so Admin Oberflächen für meine Applikation habe, dann
sollte ich natürlich sicherstellen, dass die User,
wenn Sie darauf zugreifen, dann auch nur gezielt für einen sehr
kurzen Zeitraum da drauf können und die Sessions nicht unnötig
lange laufen, damit die Session vielleicht sofort abgelaufen
ist. Wenn ich entsprechend entweder
das Unternehmen verlasse oder mein Laptop verloren geht.
Zum anderen gibt es ganz, ganz viele Tools mittlerweile für
dich. Diese Secrets und Tokens halt
gar nicht mehr brauchen. Also wenn ich mich gegen meinen
unternehmensinterne Package Registry anmelde, dann kann ich
das mittlerweile auch einfach über den Account machen, der
dann idealerweise derselbe Single seinen Account ist und
habe dann quasi diese ganzen Secrets, die ich ja eigentlich
ach so unbedingt brauche um eine Applikation zu starten um eine
Applikation zu bauen, halt nicht irgendwo rumliegen, sondern
melde ich in dem Account und das ist schon so der erste Appell.
Wenn das irgendwo geht, schaut doch mal, ob ihr euren npm Token
nicht durch ein Login gegen npm euren New Get Token nicht gegen
nicht durch ein Login gegen New Get ersetzen könnt.
Das ist 1000000 mal sicherer und wenn jemand jetzt das
Unternehmen verlässt kann ich die wenn ich eben SSO verwende,
dann auch noch quasi einfach nur sauber aus meiner sag ich mal
ich nutze hier wie entra id, also diese ganze Microsoft
Umgebung ausgliedern und damit haben die haben die betroffenen
Personen dann eben auch automatisch keinen Zugriff mehr
drauf. Bei diesem zweiten Punkt, man
muss natürlich dazu sagen, oft ist das bei diesen vielen Tools
hinter irgendeinem Enterprise Tier versteckt, dass man sich da
mit diesem Single sein und anmelden kann.
Wer das nicht hat oder weil ich aber sagen, ich bin ein kleines
Startup, ich kann jetzt nicht über den Enterprise Tier leisten
um Single sein und zu erlauben, da macht euch wenigstens
irgendwie eine oft Boarding Checklist, dass man dann einfach
nur die entsprechenden User Accounts ausgeht habe und aus
den ganzen anderen Tools, die man irgendwie so verwendet,
vielleicht dann wieder. Rausschmeißt aber stellt
zumindest sicher, dass die Leute eben auf user Account Ebene sich
auch gern dann gegen die entsprechenden Systeme
authentifizieren, die sie zum Bauen des Source Codes brauchen,
aber auch vielleicht, um ihre developer Umgebung mit der
Developer Datenbank oder sowas zu verbinden.
Und eben nicht auf irgendwelche Keys und Tokens zurückgreifen.
Ja, und ich denke, es ist auch realistisch, dass man auf
absehbare Zeit nicht vollständig auf solche Secrets oder API Keys
verzichten kann und dementsprechend ist es umso
wichtiger, dass ich auf meiner developer Maschine natürlich
darauf achte, dass sie auf keinen Fall in meinem Git
repository landen. Aber.
Aber du hast es auch gerade gesagt, möglichst auch nicht
irgendwo sonst irgendwie auf meinem Dateisystem rumliegen und
es gibt entsprechende Tools, die ich nutzen kann, egal ob es
jetzt irgendwie einen Secret Scanner in meinem in meiner
Developer Plattform wie github ist mit Secret Scanning oder
Truffle Hawk oder Git Guardian verwendet, teilweise mit Pre
commit Hooks, die einfach sicherstellen, dass ich auch
nicht aus Versehen eine Datei mit Secrets zu irgendeinem
Commit hinzufüge. Vielleicht habe ich das gar
nicht gemerkt. Merkt.
Und dann sind sie Teil des Commits.
Ich pushe das ganze und schon liegt es auf github oder meinem
anderen Source Control System was ich nutze und hier sollte
ich auch nicht nur darauf achten, sondern auch die
entsprechenden Tools nutzen um sicherzustellen, dass das auch
nicht aus Versehen passiert, weil jedes Secret was erst
einmal irgendwo in meiner Git history ist muss rotiert werden
muss als kompromittiert. Gesehen werden, und das Macht
natürlich extrem viel Arbeit. Und falls ihr sagt, Ja, ist ja
schön, was die beiden da erzählen, aber meine Realität
sieht anders aus. Ich brauche für Tool XY halt
irgendwie einen Token, dann schaut zumindest, dass der
Token, der auf eurer Maschine ist, vielleicht nur ein sag ich
mal read only token ist. In den seltensten Fällen will
ich von meiner Maschine aus wirklich Pakete pushen in einen.
Package Manager, den ich vielleicht unternehmensintern
benutze, sondern braucht da vielleicht zum Bauen des Codes
ja wirklich nur den Read only token.
Noch mal, wenn wir uns hier an so was wie Schalke luth
erinnern, der konnte sich verbreiten, weil da auch
wirklich Tokens mit Publish Rechten auf den developer
Maschinen gelegen haben. Also selbst wenn ich
irgendwelche Tokens brauche, kann man die ja oft zumindest so
einschränken, dass sie wirklich. Nach least Privileg nur das
können, was ich wirklich, wirklich, wirklich brauche, wenn
keiner der anderen Dinge, die wir gerade eben aufgezählt
haben, überhaupt gehen. Aber dann gibt es natürlich die
Systeme, die berechtigt etwas veröffentlichen müssen, sei es
Pakete in meinen Package Manager oder meine Anwendung in unsere
Test und Produktivumgebung. Und das sind meine cicd Umgebung
und auch hier muss ich diese gleichen Prinzipien
berücksichtigen und muss zum einen mit.
Mit least privilege arbeiten im Idealfall nicht irgendwie
Secrets verwenden, auch wenn diese Systeme natürlich immer
diese Secret Management Lösung irgendwie mitbringen und man
denkt da ist mein Secret ja sicher, sie werden nur just in
Time in meine Pipeline injected, aber auch da können sie
natürlich leaken, alle diese Systeme, sie schreiben Logs und
wenn jemand. Die Möglichkeit hat, meine
Pipelines zu modifizieren, können natürlich diese Secrets
auch ausgegeben werden und dementsprechend muss ich auch
hier Strategien finden und anwenden um hier auch genauso
wie auf der persönlichen Entwicklungsumgebung am besten
völlig ohne solche Passwörter und Secrets zu.
Arbeiten, um das umzusetzen, kann ich zum Beispiel moderne
Authentifizierungsmechanismen nutzen, wie zum Beispiel Open Id
Connect oder kurz Oidc. Das ist in vielen Umgebungen
mit. Mittlerweile eingebaut und
funktioniert so, dass ich mir eine Identität irgendwo anlege.
Wenn ich jetzt zum Beispiel sagen will, meine mein Gitter
repository darf in meine Azure produktiv Umgebung deproyen,
dann lege ich mir bei Azure eine Managed Identity an und sage
dann, dass ich dass diese github repository in genau auf diesem
Branch und mit genau diesem github actions Workflow.
Das darf sich dann dieser Azure Identität annehmen und hat dann
auch die Rechte, die ich dieser Identität zuweise.
Bedeutet aber auch, ich hinterlege bei Github dann gar
kein Secret oder Passwort, mit dem sich das Ding gegen Azure
identifiziert, sondern ich sage okay hier, das ist der in dem
Fall die Client ID, die ist. Nicht, nicht ultraschützenswert,
die kann ich theoretisch wissen, weil damit der der alleine kann
ich nichts anfangen. Und wenn dann jemand zu Azure
geht und nachweisen kann über diese Federation, die github in
dem Fall mit Microsoft man gebaut hat, nachweisen kann, ja
hier schau ich bin wirklich. Der Guitar Runner, der den Code
ausführt, der aus dieser Pipeline kommt, die jetzt auf in
diesem Repository auf diesem Branch läuft, dann sagt in dem
Fall der Azure okay, dann darfst du dich mit dieser Identität
jetzt hier ausstatten und die Dinge tun, für die diese
Identität Berechtigung hat und in der Realität sieht es dann so
aus, dass ich mir da am besten mehrere von anlege, also
vielleicht eine, die gegen Pod deployen darf und einige, die
gegen Def deployen darf und. Und die, die gegen Prot Deployen
darf, die wird dann zum Beispiel auf gar keinen Fall bei einem
Pull Request Review verwendet und die, die gegen Def deployen
darf, die wird dann vielleicht automatisch, wenn auf dem Def
Branch ein neues, ein neuer Change auftaucht oder wenn ein
Pull request reinkommt verwendet.
Die darf aber auch nur mein Developer System sprechen,
vielleicht hat die auch nur Read only recht oder was auch immer
und so kann man sich dann also durch diesen Zusammenschluss
diese Federation, die diese beiden Unternehmen eingegangen
sind. Bekommt man einen sehr
kurzlebigen Token ausgestellt, einen sehr kurzlebigen Open ID
connect Token, der wirklich auch nur für diese eine Session
irgendwie da ist, mit der niemand anderes wirklich
großartig was anfangen kann. Und diese Connections gibt es
mittlerweile zwischen ganz, ganz vielen Systemen, also auch wenn
ich jetzt sage, ich möchte Packages in die.
Npm package Registry publishen dann kann ich auch da diese man
das federated Creedencials in Anspruch nehmen und habe halt
den ganz ganz großen Vorteil, dass ich meinem Deployment
Partner in dem Fall npm oder schon Vorhersage pass auf man
ich bei dir darf jemand was publishen der von mir kommt aber
wirklich nur auf diesem Rudge wirklich nur aus diesem
Repository und das kann da eben beweisen dadurch dass die beiden
Plattformen eben diese diese Federation eingegangen sind und
so komme ich dann dazu. Dong Story short, dass ich in
meinem Guitar Repository gar keine Creidentials mehr habe, um
mich gegen diese Systeme zu identifizieren und einfach nur
mit der Tatsache, dass ich ich bin und das über die Plattform
beweisen kann, an der anderen Plattform dann bestimmte
Aktionen angenommen und erlaubt werden.
Ja, und jetzt mag man überlegen, ja, was ist, wenn ich Systeme
ansprechen muss, die Oidc nicht unterstützen, wo ich tatsächlich
nur einen. Developer Key bekomme oder
irgendein Secret, dann kann ich das trotzdem verwenden, indem
ich einen Secret oder Password World verwende, egal ob es jetzt
irgendwie hushy Cope World ist oder ein World in der Cloud
Plattform meiner Wahl, die dann wiederum Oidc unterstützen in
Kombination mit einem Rollbase Access Control.
Das heißt, mein geht ab Action, Workflow oder meine Pipeline
bekommt dann die Rechte bestimmte Secrets aus diesem
Password World zu lesen und kann diese dann zur Laufzeit abrufen
und verwenden. Das heißt in meinem cicd System
habe ich weiterhin keine Secrets, obwohl ich hier mit
Systemen arbeite, die vielleicht nur so ein klassisches Secret
unterstützen ich. Und auch die Secrets ich mir
dann da rausziehe. Die sollen natürlich keine
Passwörter für irgendwelche Gott user sein oder irgendwelche
Cluster Admins, das soll die am besten natürlich direkt
verbanden, sondern auch hier wieder least Privileg auch meine
cicd Pipeline soll natürlich, wenn sie zum Beispiel in einen
kobanitis Cluster publish. Wirklich nur auf diesen einen
Namespace, vielleicht sogar wirklich nur Right Rechte oder
irgendwas haben auch gar keine Admin Rechte um mit Secrets da
auszulesen, sondern wirklich nur die Rechte die sie braucht.
Und wenn ich eben nicht OECD verwenden kann, dann hole ich
mir da halt irgendwie die Credentials für aber auch wie
gesagt auch dann wieder wirklich nur mit dem absoluten Least
Privileg, also auch Pipelines behandeln wir potenziell als
unzuverlässige Akteure. Und ich glaub, das ist dieser
Mindset Shift, den wir machen müssen.
Ne in meinen developer Rechner, selbst wenn ich davor setze
sitze der ist nicht vertrauenswürdig oder sicher
genug um diese ja diese God Mode User Credentials zu beherbergen
und genauso wenig meine CICD pip.
Ja, und ganz konkret heißt das jetzt, ich leg diese
entsprechenden Identities in meinem Cloud Provider an.
Kann dann entsprechend dort Rechte vergeben.
Über Oidc findet dieses Vertrauensverhältnis statt
zwischen meinem cicd System und dieser entsprechenden Plattform
und ich kann dann auf sichere Art und Weise auf Secrets
zugreifen oder in produktionsumgebung Dinge
veröffentlichen und das Risiko, dass dann jetzt hier ein Secret
verloren geht, ist absolut minimiert, weil natürlich auch
meine ganzen. Pipelines oder Workflows
entsprechend geschützt sind. Ich habe in meinem Source
Control System die entsprechenden Rechte darauf so
gesetzt, dass nicht jeder einfach diese Workflows
verändern kann, um zum Beispiel Informationen rauszuloggen oder
dort auch Dinge zu deployen, die nicht legitim sind, das heißt,
hier greifen natürlich verschiedene
Sicherheitsmechanismen ineinander, aber prinzipiell
basiert alles auf dieser Idee von Zero.
Trust, das heißt, ich vertraue per Definition niemandem, auch
wenn er sich im eigenen Netzwerk bewegt, sondern ich validiere
die Identität und weiß dann, welche Rechte diese Identität
entsprechend bekommen soll. Und das Gleiche mache ich nicht
nur beim Bauen oder beim Deployen von meiner Applikation,
sondern auch wenn die Applikation läuft.
Hier selber. Gleiches Prinzip, auch ich kann
auf jeder modernen Plattform heute meiner Anwendung auch
wieder eine Identity zuweisen, das.
Denn ich höre schon, ja, ist ja schön und gut, dass vielleicht
mein Bild jetzt ohne ein Passwort für den npm Feed
auskommt, aber meine App muss ich ja trotzdem irgendwie gegen
meine Datenbank verbinden und wenn ich eine App irgendwo mein
Cluster deploye und da als Environment variable den
connection string mit reinziehe, dann habe ich ja wieder einen
Secret, was ich irgendwo habe und auch hier, nein idealerweise
und das kann ich auch, selbst wenn ich in Cubanetes oder sowas
rein deploye, kann ich sowas wie Workload Identity heißt das eine
Azure L? Es gibt auch oft.
Wieder Cloud Plattform da irgendwie einen Pondor zu das
verwenden oder wenn ich einen gemanagten Par Service irgendwo
verwende haben die das häufig auch auch dann kann sich eine
Applikation die auf genau diesem Pass Host deployed ist eine
Identität annehmen, nämlich die Identität von diesem Service und
da kann ich diesem Service auch wieder Rechte zuweisen, das
heißt ich kann dann sagen, EY diese Datenbank, die gibt gar
keinen Connection String im Sinne von Username und Passwort
mehr raus und an der sage ich ey wenn der Service der auf diesen.
Diesen Pass host hier im Develop in der developer Umgebung ist,
der darf auf dich liebe Developer Datenbank zugreifen.
Auf dich liebe pod Datenbank aber nicht und der darf da aber
auch nur die folgenden Rechte haben, das heißt wenn ich
dieselbe Applikation auf meinem Computer starte.
Dann wird die sich nicht gegen die Datenbank verbinden können.
Wenn ich die Applikation aber auf dem Zielserver starte und
der Server ist von einem Cloud Provider gemanagt, so dass
dieser Server oder dann wurde vielleicht sogar nur der
Container auf dem Server eine Identity bekommt, dann kann
diese Identity wieder Rechte haben, das heißt es ist exakt
derselbe Code und nur die Tatsache, dass der aufeinander
Infrastruktur läuft, gibt ihr eben die Berechtigung mit
verschiedenen externen Services wie einer Datenbank oder wie
einem Cache zu sprechen. Jetzt habe ich gerade gesagt,
wenn die auf deinem Rechner startet, hat sie keine
Verbindung gegen die Datenbank und jetzt höre ich euch schon
wieder schreien zu sagen, ja ich brauche aber jetzt mal eine
Verbindung zur Datenbank oder ich muss zumindest auch bei mir
bei mir mal lokal die App starten können und dass ich
zumindest mich gegen die Development Umgebung verbinden
kann und auch das geht über diese Identitäten.
Ich kann mich dann auch auf dieser Plattform auf meiner
Zielplattform bei WBS, bei GCP, bei Azure, wo auch immer ich
bin. Natürlich auch mit meinem meinem
User Account anmelden und die die Anwendung dann so
konfigurieren, dass wir haben ja eben gehört, wenn sie auf diesem
Zielserver läuft, sie die Identität von dem Server
bekommt. Und wenn Sie auf meinem Rechner
läuft, meine Identität bekommt. Das heißt, wenn ich meinem User
Account Zugang gebe, zum Beispiel in der Developer
Datenbank zu lesen und zu schreiben, dann kann die auch
die Anwendung, die auf meinem Rechner läuft, die kann sich
dann auch wieder diese Identität schnappen, also wieder diese
Host Identität und auch damit sich dann gegen die Datenbank
verbinden und auch hier wieder, wenn ich diese Systeme nicht
unterstütze, kann es sich mindestens mit der Identität
gegen einen Secret Store wie hushicop, Void oder Ash.
Keyword oder sowas verbinden und dann zur Laufzeit die Secrets
einladen. Also genau wie bei der Bild
Pipeline auch und das geht auf jeden Fall und dann kann ich
nämlich wirklich auf meinem Rechner und egal wo die
Anwendung läuft. Ein Passwort zur Datenbank oder
Connection String zur Datenbank vermeiden, weil ich das genauso
wie beim Bild und genauso wie beim Deploy über Identitäten
mache. Und ich weiß natürlich jetzt
nicht genau, auf welchem System ihr unterwegs seid, aber auf
allen modernen Systemen geht das mittlerweile und so kann ich
langsam und sicher meine Dot n Datei aufräumen und vielleicht
sogar am Ende der Folge wegschmeißen.
Und wenn ich das ganze jetzt aufs nächste Level heben will,
kann ich natürlich bei Oidc noch mal eine Schippe drauflegen.
Mit entsprechenden zusätzlichen Conditional Access Policies und
kann sagen Okay dieser Zugriff von Robin Mardol auf die Prod
Datenbank funktioniert nur von seinem Arbeitsrechner und auch
nur, wenn er sich gerade in Deutschland befindet.
Das heißt ich kann da zusätzlich noch Policies ergänzen.
Aber das Ganze wird entsprechend komplex und da kann man sich
natürlich fragen, wer baut das alles auf?
Das mache ich ja jetzt nicht als Developer alleine, das mache ich
vielleicht auch nicht als Projektteam, was an einer
bestimmten Applikation arbeitet, sondern ich brauche dort auch
Expertinnen und Experten, mit denen ich zusammenarbeite und
die das im Idealfall direkt für das ganze Unternehmen ausrollen
und natürlich auch einheitlich bereitstellen.
Dass wir halt dieses Grundprinzip von Zero Trust
wirklich als Unternehmen auch verinnerlichen können und über
das gesamte Unternehmen hinweg auch verwenden.
Genau das hat natürlich, wie du gerade ansprichst.
Wir müssen verschiedene Rollen und verschiedene Personen als
verschiedene Dinge tun. Ich kann einfach so ein bisschen
erzählen, wie wir das jetzt aufgesetzt haben und wie das bei
uns funktioniert. Sind 2 Dinge zum einen läuft das
halt natürlich über Policies, das heißt?
Die Datenbanken, die ich, die Pleuel, die, die dürfen gar kein
Connection String oder kein Secret ausstellen, die müssen
über eine Identitäts und Rollenzuweisung angesprochen
werden. Das heißt, Develop hatte davon
noch nie gehört hat, läuft zwangsläufig vor diese Wand.
Wie kann ich mich jetzt mit der Datenbank verbinden, weil wenn
ich hier auf den Generate connection String Knopf klicke,
dann kommt eine Fehlermeldung und ich muss mich dann damit
damit beschäftigen, okay über Identitäten wie gebe ich denn
überhaupt meiner laufenden App eine solche Identität, das
heißt? Über so Policies kann man das
natürlich einschränken. Ne zweite Sache, die wir hier
als Plattform und Infrastructure Team machen ist, wenn jemand zu
mir kommt und sagt Hey ich möchte irgendwas in die Azure
Cloud deployen. Dann setzen wir so ein bisschen
Plattform Engineering mäßig direkt, so eine leere
Projekthülle auf, und da wird neben der Einrichtung einer
Azure Subscription, die sich dann an diese Policies hält,
auch in diese Subscription zum Beispiel direkt werden, da
mehrere Identitäten rein deployed, die werden über diese
Federated Credentials und Oidc direkt eingetragen in das in das
Guitar Prepository, mit dem dieses Team dann arbeitet oder
die Guitar Prepositories bedeutet bei den Federated
Credentials. Ich direkt okay jemand der von
diesem Repo, von diesem Runch kommt, der da sie identifizieren
und im Github tragen wir quasi dann schon automatisiert über
Terror Form, in unserem Fall mit Infrastructure ist Code die
entsprechenden Variablen für die entsprechenden Environments ein,
dass die auch wissen, welche Identity sie wann wie wo
verwenden und so kann ich so ein bisschen dieses, ja ich sage mal
so gerne forest developers into success.
Kann ich damit so ein bisschen fördern, weil eigentlich alles
schon aufgesetzt ist? Wenn du da noch so ein bisschen
gute Dokumentation obendrauf Streust, dann hast du eigentlich
schon mal, glaube ich, ein ganz cooles Setup, wo die Leute sich
auch wohlfühlen und gar nicht so viel falsch machen können, weil
du es über Policies manche Dinge gar nicht erlaubst und b das
Grundsetup zumindest was so die Infrastruktur angeht, ohnehin
schon aufsetzt, so dass es auch quasi mehr oder weniger von
vornherein flüssig läuft und die Leute sagen, ah okay, das ist ja
cool. Ich glaube, das bringt dann so
beide Seiten zusammen. Zum einen ist es für mich als
Developer sehr einfach zu nutzen und es macht mein Leben auch
einfacher, weil ich muss jetzt nicht mehr mir irgendwo von
Kollegen irgendwie einen Datenbank connection string
holen, sondern ich mache einfach weiß nicht in dem Beispiel
Secret Server Management Studio auf und logge mich mit meinem n
3 D Account ein und kann dann direkt auf die Datenbank
zugreifen mit den Rechten die ich in meiner Rolle haben sollte
und. Und auf der anderen Seite, wenn
ich so ein zentrales Identity Management habe, egal welche
Plattform das jetzt ist, habe ich da natürlich auch eine
Nachvollziehbarkeit und kann dann, falls mal irgendwas schief
geht oder es zu irgendeinem Security Incident kommt, kann
ich genau schauen, wer hat wann auf was zugegriffen und wenn ich
sage wer muss das ja nicht unbedingt eine Kollegin Kollege
sein, das kann auch. Jede dieser anderen Identities
sein, über die wir gerade gesprochen haben.
Das kann meine Applikation sein, die läuft, das kann irgendwie
meine Ci pipeline sein und all das finde ich dann entsprechend
in meinen Audit logs wieder und kann dann halt genau
nachvollziehen, wann was passiert ist.
Und das ist natürlich, gerade wenn es zu Sicherheitsvorfällen
kommt, extrem wertvoll, wenn man genau weiß wo die Zugriffe
herkamen. Also zusammenfassend, was könnt
ihr morgen oder vielleicht sogar heute noch tun, um die.
Quasi Zero Trust für Developer vielleicht auch nicht komplett
zu machen, aber deutlich nach vorne zu bringen.
Ich glaube die ersten Schritte haben wir ganz am Anfang schon
erwähnt, ganz einfach easy Win ist Secret Scanning zu
aktivieren, da gibt es ganz ganz viele Tools über Gitap Advanced
Security, über Git Guardian über ganz, ganz viele Tools, die man
sich in seine repo reininstallieren kann.
Ich kann das sogar schon noch ein bisschen erweitern über so
Pre commit Hooks. Da kann ich geht secrets quasi
schon scannen, bevor oder während ich auf den Commit
Button klicke oder den Commit Befehl absetze, das heißt die
landen gar nicht erst irgendwo auf einem Remote Repository, das
haben wir besprochen und das zweite ist so eine offboarding
Checkliste. Wir haben ganz viel über
Identity Provider und wie cool die sind gesprochen, aber ich
weiß auch, dass sie sich oft hinter irgendwelchen Enterprise
Tears, die sehr sehr teuer sein können, verstecken.
Das heißt, mal mindestens sagen okay, wenn jemand das
Unternehmen verlässt, muss ich dann eine Secret Rotation
machen? Und wie sieht der Workflow dafür
aus und wie kann ich das irgendwie so machen, dass ich da
keine Angst vor habe und am Ende natürlich auch, wenn die Leute
irgendwelche Personal access Tokens dann doch für irgendwas
verwendet haben, selbst wenn sie sehr eingeschränkt sind und nur
für bestimmte den bestimmten Use Case.
Dann setze ich da halt trotzdem irgendwie eine Expiry drauf,
idealerweise nicht 2 Jahre, sondern vielleicht irgendwie 3
Monate oder so, dass ich zumindest alle 3 Monate mal
darauf hingewiesen werde. A ich muss hier glaube ich noch
was rotieren und b ist es auch irgendwie nervig genug, dass man
sich so alle 3 Monate noch mal überlegen kann, ob es da nicht
einen smoothheren Weg gibt, sich gegen das System zu
authentifizieren. Und dann sollte ich natürlich
entsprechende Passwort Management Tools einführen.
Einmal für uns als Menschen über einen Passwort Manager, den ich
im Team verwende oder vielleicht im ganzen Unternehmen Teile, wo
ich dann gezielt sagen kann, wer hat auf welche Secrets Zugriff
und das gleiche brauche ich natürlich für meine
Automatisierung für meine Ci Pipeline, für meine
Applikationen über einen Secret World, der zum Beispiel in
meiner Cloud Plattform direkt integriert ist.
Und dann kann ich natürlich auch.
Auch in meinen Pipelines, in meinem cicd System von solchen
Dingen wie Oidc vollständig profitieren, weil ich dann alle
Secrets aus meiner Pipeline verbannen kann.
Ich kann mich gegen meine Zielsysteme authentifizieren,
kann aber auch weitere Secrets entsprechend abrufen und wenn
ich das Ganze dann kombiniere mit einem Piloten, den ich
starte rund um das Thema Managed identities, weil meine Cloud
Plattform das unterstützt und. Umso besser, weil dann kann ich
natürlich auch im laufenden Betrieb meiner Anwendung diese
Identity zuweisen und dann über diese Identity die
Zugriffsrechte zum Beispiel auf einen Storage Account oder eine
Datenbank regeln. Was ich aber auf jeden Fall mal
machen kann, wenn ich jetzt nach der Folge gemerkt habe, ah okay,
ich lebe ja noch gar nicht in dieser perfekten Welt.
Ist man sollte sich zumindest mal so ein Inventar
aufschreiben, wo liegen denn überall Secrets, also nicht in
dem Inventar die Secrets auflisten, sondern zumindest mal
gucken, was haben wir denn überhaupt für Sachen, die jetzt
vielleicht noch nicht über irgendwelche Fancy Omid connect
identities gemanagt sind, sondern wo haben wir denn
überhaupt noch welche Secrets, wer kann darauf zugreifen, wofür
brauchen wir die? Und dann kann man ja auch mal so
eine Zero Trust Roadmap aufstellen, wenn ihr ein
Plattformteam habt, vielleicht sogar mit denen zusammen, weil
wir haben eben gelernt, das ist sowohl die developer Maschine
als auch die cicd Pipeline, also dann wirklich die die Deployment
Umgebung am Ende. Wie kommen wir denn dahin?
Und last but not least ist das natürlich, wie oft bei so Secret
Themen auch, einfach eine kulturelle und eine
Wissensfrage, also schaut mal, vielleicht gibt es irgendwelche
Schulungen die cool sind, vielleicht wir haben bei uns zum
Beispiel so eine Security Champions Community.
Die jetzt nicht Sicherheitspolizei darstellen
soll, sondern am Ende des Tages finden, dass die meisten
Developer, mit denen ich besprochen habe, auch ziemlich
cool mit diesen Identitäten zu arbeiten, auch weil es das
eigene Leben leichter macht und das Setup von einem neuen
Developer im Team leichter macht.
Der muss nämlich nicht erst mal 15 secrets sich in irgendwelche
Environment Variablen setzen, sondern es reicht, wenn er sich
mit seinem Account anmeldet und wenn ihr einen Cezo oder sowas
im Unternehmen habt, dann ist das ja auch was, wo man sich mal
gemeinsam hinsetzen kann. Und genau diese Schulungs und
Kulturfrage angehen kann, um das Thema auch langfristig in den
Griff zu kriegen. Ja, und das reduziert natürlich
auch das Risiko und den Druck für alle.
Ich meine, stell dir vor, wir haben irgendwie ein gemeinsam
genutztes Secret, was dann irgendwie liegt und du bist dann
der Praktikant in einem Unternehmen, der als erstes
gefragt wird, ob du derjenige warst, der das irgendwie aus
Versehen öffentlich gepostet hat und.
Das willst du nicht und von daher sind diese Systeme
natürlich auch im Sinne der User selber, der Development Teams
und ich glaube langfristig sollten wir dementsprechend zum
einen keine neuen langlebigen Secrets mehr einführen.
Wir sollten Identities verwenden, wir sollten Policies
verwenden und. Und im Laufe der Zeit dann auch
womöglich existierende Secrets in diese Systeme übertragen.
Also wirklich zu schauen, wo kann ich von diesen modernen
Authentifizierungsmechanismen profitieren und wo kann ich das
Ganze dann möglichst schnell umstellen, damit wir hoffentlich
dann perspektivisch irgendwann an diesem Punkt angekommen sind,
wo wir gar keine Secrets mehr haben, weder auf der Development
Maschine noch im CI System, noch in unserer Produktionsanwendung
und. Sondern tatsächlich per Zero
Trust und den entsprechenden Identities das Ganze abbilden
können. Wobei wir da, glaube ich, gar
nicht an diesem einen Punkt ankommen.
Ich würde sagen, Zero Trust ist kein Projekt mit einem Enddatum,
sondern eigentlich eine Denkweise, weil das fängt ja
auch mit jedem weiteren Tool, was ich mir dazu hole, wieder
neu an und deswegen fangt auch diese Woche an, die ersten
Sachen umzusetzen. Also wenn ihr noch kein Secret
Scanning habt oder sowas dann mindestens mal damit, wenn Euch
die Folge hier gefallen hat, dann.
Lasst uns gerne eine gute Bewertung da oder gebt uns einen
Kaffee aus. Da freuen wir uns auch immer
mega drüber. Findet den Link zu unten in den
Shownotes, da haben wir so eine bei mir Coffee Seite
eingerichtet. Und wie immer freuen wir uns
natürlich auch, wenn ihr uns Feedback gebt.
Und falls euch diese Folge weiter gebracht habt, lasst uns
gerne eine positive Bewertung da.
Das könnt ihr auf der Podcast Plattform eurer Wahl machen, zum
Beispiel auf Spotify oder Apple Podcast.
Ansonsten freuen wir uns natürlich auch auf einen Like
von euch auf youtube, wenn ihr uns auf der Plattform hört und.
Ansonsten hören wir uns nächste Woche wieder.
Der to do Cast erscheint jede Woche, jeden Montag mit
abwechselnd einem developer Thema wie diesem hier oder den
aktuellen Tag und Developer News, die wir dann aus den
letzten 2 Wochen zusammentragen. Seid also auch nächste Woche
wieder mit dabei und bis dahin habt eine gute Zeit und schreibt
ganz viel sicheren Code ohne viele Secrets.
Bis dahin.