1 00:00:00,480 --> 00:00:04,480 Nur ein npm Package, ein versteckter Wurm und Zack, 2 00:00:04,480 --> 00:00:08,039 plötzlich sind Eure Github Tokens Adbl, US Keys und 3 00:00:08,039 --> 00:00:10,720 Datenbankpasswörter in den falschen Händen. 4 00:00:11,120 --> 00:00:14,800 Wie sicher ist deine developer Maschine wirklich und warum 5 00:00:14,800 --> 00:00:18,160 arbeiten wir überhaupt noch mit langlebigen Secrets, die überall 6 00:00:18,160 --> 00:00:20,600 rumliegen? In dieser Folge sprechen wir 7 00:00:20,600 --> 00:00:25,280 über Zero Trust für Developer von der Dot End Hölle hinzu 8 00:00:25,280 --> 00:00:28,640 Manage Identities die Passwörter komplett überflüssig machen. 9 00:00:29,080 --> 00:00:31,360 Es wird konkret, es wird praktisch und am Ende habt ihr 10 00:00:31,360 --> 00:00:33,680 eine Liste, was ihr morgen ändern könnt. 11 00:00:33,680 --> 00:00:42,480 Viel Spaß. Und damit herzlich Willkommen zu 12 00:00:42,480 --> 00:00:46,000 einer neuen Folge des To do Developer Podcasts, eurem 13 00:00:46,000 --> 00:00:50,400 deutschen Developer Podcast. Mit mir malte Lantin und Robin 14 00:00:50,400 --> 00:00:54,160 Manuel Thiel Robin Manuel ist Director AI und Cloud beim E 15 00:00:54,160 --> 00:00:57,400 Commerce Softwareunternehmen Jtl und ich bin Solutions Engineer 16 00:00:57,400 --> 00:01:00,160 bei github. Den Podcast machen wir wie immer 17 00:01:00,240 --> 00:01:03,520 privat und in unserer Freizeit, sprechen aber hier natürlich auf 18 00:01:03,520 --> 00:01:08,400 Basis unserer Praxiserfahrung und zahlreichen Gesprächen und 19 00:01:08,400 --> 00:01:11,680 der Zusammenarbeit mit. Euch in der Community und heute 20 00:01:11,680 --> 00:01:15,280 geht es um das Thema Security und wie wir unseren eigenen 21 00:01:15,280 --> 00:01:18,640 Arbeitsplatz sicherer gestalten können, damit wir nicht 22 00:01:18,640 --> 00:01:22,560 diejenigen sind, die beim nächsten online kursierenden 23 00:01:22,560 --> 00:01:24,880 Wurm alle unsere Secrets verlieren. 24 00:01:25,200 --> 00:01:27,520 Ein sicherer Arbeitsplatz ist aber auch ein wacher 25 00:01:27,520 --> 00:01:29,560 Arbeitsplatz. Damit man nämlich aufmerksam ist 26 00:01:29,560 --> 00:01:31,280 und sich allen Gefahren bewusst ist. 27 00:01:31,760 --> 00:01:35,280 Und da hilft dem klassischen Developer natürlich Kaffee und 28 00:01:35,280 --> 00:01:37,880 Kaffee haben wir ganz viel von Euch bekommen, von unserer 29 00:01:37,880 --> 00:01:40,000 Community ganz ganz herzlichen Dank. 30 00:01:40,480 --> 00:01:44,480 Und zwar hat der David uns 3 Kaffee ausgegeben, der Nico hat 31 00:01:44,480 --> 00:01:47,400 uns einen Kaffee ausgegeben, vom Lars haben wir 3 Kaffee 32 00:01:47,440 --> 00:01:51,000 bekommen, vom Gerhard haben wir 3 Kaffee bekommen und vom Jonas 33 00:01:51,000 --> 00:01:52,400 haben wir noch einen Kaffee bekommen. 34 00:01:52,880 --> 00:01:54,720 Wow, das ist eine richtige Kaffeeflut. 35 00:01:54,720 --> 00:01:56,760 Vielen, vielen Lieben Dank auf jeden Fall und alle, die uns 36 00:01:56,760 --> 00:01:59,600 Ihren Kaffee ausgegeben haben. Und dann lasst uns direkt ins 37 00:01:59,600 --> 00:02:02,640 Thema einsteigen. Wir reden heute über die 38 00:02:02,640 --> 00:02:06,280 Sicherheit unserer Developer Maschine und dem, was hinten 39 00:02:06,280 --> 00:02:10,680 dran kommt, CI Pipelines oder natürlich auch die Secrets die 40 00:02:10,680 --> 00:02:13,680 wir brauchen, damit unsere Applikation mit anderen Systemen 41 00:02:13,920 --> 00:02:17,440 kommunizieren kann und das Ganze, damit wir nicht auf. 42 00:02:17,760 --> 00:02:22,360 Opfer werden von einem Wurm wie Chaihulut, der nach Secrets auf 43 00:02:22,360 --> 00:02:26,240 der lokalen Maschine gescannt hat und dann diese Secrets 44 00:02:26,240 --> 00:02:29,600 extrahiert hat. Und ja, da gibt es ganz viele 45 00:02:29,600 --> 00:02:34,080 Dinge, die man tun kann, damit man nicht seine Github Tokens, 46 00:02:34,080 --> 00:02:38,720 npm Tokens oder WS Keys verliert, weil man sie mal 47 00:02:38,720 --> 00:02:41,960 wieder in seiner Dot NV Datei abgelegt hat. 48 00:02:42,160 --> 00:02:43,800 Genau darüber haben wir ja die letzten Folgen auch viel 49 00:02:43,800 --> 00:02:45,280 gesprochen. Jetzt wird es diese Folge 50 00:02:45,280 --> 00:02:47,280 konkret, was man da eigentlich machen kann, dass. 51 00:02:47,600 --> 00:02:48,920 Denn das haben wir auch besprochen. 52 00:02:48,920 --> 00:02:52,240 Dieser Wurm konnte sich ja nur verbreiten, weil ganz viele von 53 00:02:52,240 --> 00:02:56,600 uns halt auch einfach Tokens, die in irgendwelchen Dateien auf 54 00:02:56,600 --> 00:02:58,400 der eigenen Maschine liegen haben lassen, die dieser Wurm 55 00:02:58,400 --> 00:03:01,440 dann scannen konnte und benutzt hat, um sich selber 56 00:03:01,920 --> 00:03:04,720 fortzupflanzen und deswegen steigen wir doch einfach mal an 57 00:03:04,720 --> 00:03:07,640 mit einer provokanten Frage, fasst euch da mal selber an die 58 00:03:07,640 --> 00:03:10,400 Nase, wie viele von euch, die hier gerade zuhören. 59 00:03:10,800 --> 00:03:14,480 Haben einen npm Token auf ihrer Festplatte liegen oder irgendwie 60 00:03:14,480 --> 00:03:17,520 ein Äquivalent davon, vielleicht sogar in den von Malte gerade 61 00:03:17,760 --> 00:03:22,520 angesprochenen Dot 11 Dateien oder einen Connection String zu 62 00:03:22,520 --> 00:03:25,920 einer Datenbank oder irgendwas wo man sich eigentlich schon 63 00:03:25,920 --> 00:03:28,720 bewusst ist, dass es da nicht da nicht hingehört. 64 00:03:28,720 --> 00:03:33,120 Und genau darum geht es heute. Zero Trust für unsere Dev 65 00:03:33,120 --> 00:03:35,520 Maschinen, aber auch für unsere Pipelines und unsere Apps 66 00:03:35,520 --> 00:03:37,440 nachher und. Und da gehen wir jetzt ein 67 00:03:37,440 --> 00:03:40,720 bisschen rein. Und wenn wir über Zero Trust 68 00:03:40,720 --> 00:03:44,800 reden, reden wir darüber, dass wir nicht einfach pauschal 69 00:03:44,800 --> 00:03:47,440 unserer lokalen Entwicklermaschine oder einem 70 00:03:47,440 --> 00:03:51,040 Secret, was da drauf liegt, vertrauen, sondern immer prüfen, 71 00:03:51,200 --> 00:03:55,760 ob wirklich diese Person oder diese Pipeline den Zugriff auch 72 00:03:55,840 --> 00:03:58,640 haben soll. Und von daher müssen wir das ein 73 00:03:58,640 --> 00:04:00,040 bisschen breiter. Spannend. 74 00:04:00,040 --> 00:04:03,320 Es ist nicht nur mein mein Laptop oder irgendwie meine 75 00:04:03,320 --> 00:04:07,360 Entwicklungsumgebung, sondern das ist alles, was mit meinem 76 00:04:07,360 --> 00:04:10,000 Arbeitsplatz zu tun hat, wo ich secret. 77 00:04:10,360 --> 00:04:14,880 Ablege, weil diese Secrets natürlich gern genommene Beute 78 00:04:14,880 --> 00:04:19,200 von Cyberkriminellen sind, weil sie entsprechende Werte 79 00:04:19,200 --> 00:04:21,839 darstellen. Wenn ich entweder dadurch meinen 80 00:04:21,839 --> 00:04:24,400 Wurm verbreiten kann oder vielleicht auch einfach über 81 00:04:24,400 --> 00:04:30,400 einen Cloud Key die Möglichkeit habe, zu deinen Kosten irgendwie 82 00:04:30,800 --> 00:04:34,080 Bitcoin Mining zu machen oder vielleicht meinen Open Claw 83 00:04:34,080 --> 00:04:37,040 Agent auf einer WM laufen zu lassen, für die du zahlst. 84 00:04:37,840 --> 00:04:40,240 Warum auch nicht? Und dabei kommt es nicht nur 85 00:04:40,240 --> 00:04:43,040 darauf an, was ich denn alles auf meinem Rechner oder 86 00:04:43,040 --> 00:04:46,880 vielleicht generell in meinem Zugriffsbereich an API Keys, 87 00:04:46,880 --> 00:04:51,120 Passwörtern, Tokens, Connection, Strings, all diesen Dingen habe, 88 00:04:51,440 --> 00:04:54,320 sondern natürlich auch, auf welche Systeme ich generell 89 00:04:54,320 --> 00:04:56,240 Zugriff habe. Wir haben, du hast gerade Open 90 00:04:56,240 --> 00:04:59,440 Claw schon selber erwähnt, da kann mein Browser fernsteuern, 91 00:04:59,440 --> 00:05:01,520 das heißt, ich könnte sogar theoretisch mit Schadsoftware 92 00:05:01,520 --> 00:05:04,000 über so ein Tool einfangen oder es könnte Schadsoftware auf 93 00:05:04,000 --> 00:05:05,720 meinem Rechner geben, die einfach anfängt meinen Rechner 94 00:05:05,720 --> 00:05:07,640 fernzusteuern. Und da muss ich mich schon 95 00:05:07,640 --> 00:05:10,720 fragen, habe ich vielleicht dauerhaft Admin Rechte auch auf 96 00:05:10,720 --> 00:05:12,800 dem System, wo ich vielleicht nicht dauerhaft Admin rechte 97 00:05:12,800 --> 00:05:15,920 haben sollte oder muss mir die über besser mal über 98 00:05:15,920 --> 00:05:17,920 irgendwelche Elevated permissions holen oder einen 99 00:05:17,920 --> 00:05:20,560 dedizierten Admin account? Das heißt, das müssen wir 100 00:05:20,560 --> 00:05:22,680 eigentlich Gesamtheitlich betrachten, die Dinge, über die 101 00:05:22,680 --> 00:05:26,800 ich über Tokens und Credentials Zugriff habe und die Dinge, auf 102 00:05:26,800 --> 00:05:29,120 die mein User Account Zugriff hat, einfach dadurch, dass er 103 00:05:29,120 --> 00:05:30,480 auf meinem Rechner angemeldet ist. 104 00:05:30,880 --> 00:05:33,840 Ja, und da hat sich ja in den letzten 1015 Jahren auch ein 105 00:05:33,840 --> 00:05:36,680 bisschen was verschoben. In der Vergangenheit konnte man 106 00:05:36,680 --> 00:05:40,960 sagen, ich habe irgendwie eine Sicherheit, allein dadurch, dass 107 00:05:41,120 --> 00:05:44,960 meine developer Maschine im Unternehmensnetzwerk ist oder 108 00:05:44,960 --> 00:05:49,840 vielleicht meine cicd Pipeline auf einem System läuft, welches 109 00:05:49,840 --> 00:05:53,440 direkt im gleichen Netzwerk ist wie das Zielsystem und 110 00:05:53,520 --> 00:05:58,080 mittlerweile ist sowohl mein lokaler Rechner außerhalb des 111 00:05:58,080 --> 00:06:00,760 Unternehmensnetzwerks häufig, ich bin unterwegs. 112 00:06:00,840 --> 00:06:02,880 Unterwegs. Ich arbeite von zu Hause, ich 113 00:06:02,880 --> 00:06:05,360 arbeite vielleicht mit dem eigenen Laptop oder ich bin in 114 00:06:05,360 --> 00:06:08,440 irgendeinem nichts vertrauenswürdigen wi fi 115 00:06:08,480 --> 00:06:13,120 unterwegs und kann dann trotzdem oder muss dann trotzdem auf 116 00:06:13,120 --> 00:06:17,520 bestimmte Systeme zugreifen und von daher kann ich nicht einfach 117 00:06:18,320 --> 00:06:21,720 dem User vertrauen, sobald er in meinem Netzwerk ist, sondern ich 118 00:06:21,720 --> 00:06:24,160 muss mir halt neue Dinge überlegen und selbst wenn ich 119 00:06:24,160 --> 00:06:28,080 jetzt mich per VPN einwähle, heißt das ja nicht unbedingt, 120 00:06:28,080 --> 00:06:30,760 dass ich vertrauenswürdig bin, nicht. 121 00:06:30,840 --> 00:06:33,200 Nur weil ich dann in diesem Netzwerk bin, sondern ich muss 122 00:06:33,200 --> 00:06:37,040 auch weiterhin, das hast du gerade gesagt, prüfen, ja, wer 123 00:06:37,040 --> 00:06:39,600 bist du eigentlich und welche Rechte hast du? 124 00:06:39,760 --> 00:06:42,960 Und das ist so diese Grundidee von Zero Trust. 125 00:06:42,960 --> 00:06:46,720 Das heißt, ich kann nicht pauschal jemandem vertrauen, 126 00:06:46,720 --> 00:06:49,520 sondern ich muss dieses Vertrauen mir quasi immer 127 00:06:49,520 --> 00:06:53,120 erarbeiten, das heißt, ich verifiziere jedes Mal, wenn es 128 00:06:53,120 --> 00:06:56,480 eine Anfrage gibt, wer ist das eigentlich und welche Rechte 129 00:06:56,480 --> 00:07:00,040 sollte diese Person haben. Und deswegen sollten wir, wenn 130 00:07:00,040 --> 00:07:02,720 wir das Problem angehen oder für uns erkannt haben, idealerweise 131 00:07:02,720 --> 00:07:04,360 mal mit einer Bestandsaufnahme starten. 132 00:07:04,360 --> 00:07:06,960 So was gibt es denn eigentlich bei uns im Unternehmen für 133 00:07:07,200 --> 00:07:13,600 Secrets und für übermäßig überzogen große Rechte und ja, 134 00:07:13,600 --> 00:07:16,200 die Realität zeigt dann oft so typische Antipedanz, die man 135 00:07:16,200 --> 00:07:19,680 schon kennt, ich sag mal, manche Dinge sind davon 136 00:07:20,240 --> 00:07:22,360 glücklicherweise schon ein bisschen seltener geworden, zum 137 00:07:22,360 --> 00:07:25,360 Beispiel irgendwie hart codierte Secrets im Code, die. 138 00:07:25,640 --> 00:07:29,280 Das ist, glaube ich, hoffentlich nach über 150 Folgen to do Cast 139 00:07:29,600 --> 00:07:33,800 jedem und jeder der hier zuhört, klar, dass die da nicht 140 00:07:33,800 --> 00:07:36,800 reingehören, aber eigentlich gehören die auch nicht in eine 141 00:07:36,800 --> 00:07:39,840 NF Datei neben den Code und nur weil man sagt, ja die ist ja im 142 00:07:39,840 --> 00:07:42,760 Gittig no, die ist ja gar nicht eingecheckt, haben wir durch 143 00:07:42,760 --> 00:07:45,040 Shyhoulood und so was uns eines Besseren belehren lassen uns, 144 00:07:45,040 --> 00:07:47,200 dass sie da eigentlich genauso schlimm sind und. 145 00:07:47,680 --> 00:07:50,160 Auch theoretisch halt auch nicht eingecheckte und vor allem auch 146 00:07:50,160 --> 00:07:53,680 unverschlüsselte Dot 11 Dateien Risiken bergen können, genauso 147 00:07:53,680 --> 00:07:56,640 wie Hardcodierte Secrets im Code und genauso schlimm sind 148 00:07:56,640 --> 00:08:00,480 natürlich sowas wie geteilte Admin Konten, wo dann das ganze 149 00:08:00,480 --> 00:08:03,440 Team das gleiche Passwort verwendet oder Stichwort 150 00:08:03,440 --> 00:08:07,120 gleiches Passwort, auch wenn man für die Def und Staging und prot 151 00:08:07,120 --> 00:08:12,240 Umgebungen dieselben Passwörter verwendet und das kann natürlich 152 00:08:12,240 --> 00:08:14,680 alles irgendwie passieren und das ist jetzt auch nicht 153 00:08:14,680 --> 00:08:16,880 komplett abwegig. Also wenn ich mir anschaue. 154 00:08:17,840 --> 00:08:20,720 Wie viele Unternehmen ich schon gesehen habe, in denen Secrets 155 00:08:20,720 --> 00:08:23,520 auch einfach mal schnell über eine E Mail geschickt werden, 156 00:08:23,520 --> 00:08:25,600 weil es vielleicht einfacher ist als sie den Passwortmanager 157 00:08:25,600 --> 00:08:28,760 einzutragen oder über Slack oder Teams sich mal eben einen API 158 00:08:28,760 --> 00:08:31,760 Key hin und her geschickt, wird das natürlich auch auf dem 159 00:08:31,760 --> 00:08:34,640 eigenen Rechner landet und auch Auslesbar ist. 160 00:08:34,880 --> 00:08:37,600 Das sind natürlich alles Dinge, wo ich mir sagen kann, das 161 00:08:37,840 --> 00:08:39,960 wissen wahrscheinlich die meisten Leute, dass das nicht 162 00:08:39,960 --> 00:08:42,120 ganz cool ist, aber ist halt auch irgendwie so ein 163 00:08:42,120 --> 00:08:44,880 Convenience Faktor und. Und da kommen wir, glaube ich, 164 00:08:44,880 --> 00:08:47,120 gleich schon zu einem ganz, ganz spannenden Punkt, dass 165 00:08:47,120 --> 00:08:50,720 Sicherheit, und davon bin ich überzeugt, auch immer irgendwie 166 00:08:50,720 --> 00:08:53,680 einfach sein muss, weil wenn sie mir im Weg steht, wird sie auch 167 00:08:53,680 --> 00:08:55,480 irgendwie umgangen, aber ich glaube, von all diesen 168 00:08:55,480 --> 00:08:59,760 Beispielen haben wir alle mindestens 1 dieses Jahr schon 169 00:08:59,920 --> 00:09:03,200 mal selber gemacht. Ja, und das, obwohl uns, glaube 170 00:09:03,200 --> 00:09:06,160 ich, allen bewusst sind. Was die Risiken sind. 171 00:09:06,160 --> 00:09:10,400 Also ich weiß, dass ich dieses Secret ausnutzen kann, wenn sie 172 00:09:10,400 --> 00:09:14,640 verloren gehen, wenn sie leaken und so ein Leak kann ja nicht 173 00:09:14,880 --> 00:09:17,640 oder muss ja nicht unbedingt durch irgendwie Schadsoftware 174 00:09:17,640 --> 00:09:21,040 entstehen, es kann auch tatsächlich jemand sein, der 175 00:09:21,040 --> 00:09:24,080 vielleicht bei mir im Unternehmen wirklich böswillig 176 00:09:24,080 --> 00:09:26,560 Informationen extrahiert, oder es kann einfach. 177 00:09:27,000 --> 00:09:29,800 Passieren, dass irgendwelche Datenträger verloren gehen, wo 178 00:09:29,800 --> 00:09:32,960 diese Passwörter gespeichert sind in irgendwelchen Dateien 179 00:09:33,120 --> 00:09:37,920 und diese credentials kann ich dann ausnutzen, sofern sie lange 180 00:09:37,920 --> 00:09:41,400 gültig sind und die größte Herausforderung dabei ist 181 00:09:41,400 --> 00:09:45,360 natürlich auch, dass ich dann auch nicht zuordnen kann, wer 182 00:09:45,360 --> 00:09:47,920 hat eigentlich auf eine bestimmte Ressource zugegriffen, 183 00:09:47,920 --> 00:09:51,280 weil es ja vielfach geteilte Secrets sind, das heißt, sobald 184 00:09:51,280 --> 00:09:54,400 du jetzt zu mir gehst, sagst schick mir mal einen Secret per 185 00:09:54,400 --> 00:09:56,920 Slag rüber, ist am Ende nicht mehr klar, habe ich. 186 00:09:57,000 --> 00:09:58,400 Nicht auf eine Ressource zugegriffen. 187 00:09:58,400 --> 00:10:02,400 Hast du das gemacht und falls dieses Secret letzten Endes 188 00:10:02,400 --> 00:10:05,440 irgendwie verloren geht, eine League passiert, können wir auch 189 00:10:05,440 --> 00:10:08,400 gar nicht mehr zuordnen. Wo ist eigentlich diese Lücke 190 00:10:08,400 --> 00:10:11,520 entstanden, also müssen wir jetzt dein System vipen mein 191 00:10:11,520 --> 00:10:13,600 System vipen Wer hat die Schadsoftware drauf? 192 00:10:14,000 --> 00:10:17,680 Das einzige was wir wissen ist, dass wir sobald wie möglich 193 00:10:17,680 --> 00:10:21,360 dieses Secret rotieren ungültig machen müssen, eigentlich sofort 194 00:10:21,360 --> 00:10:23,360 wenn wir merken, da findet Missbrauch statt. 195 00:10:23,880 --> 00:10:26,720 Und das ist dann natürlich auch eine Situation, wo extrem Druck 196 00:10:26,720 --> 00:10:28,560 entsteht. Wir müssen das möglichst schnell 197 00:10:28,560 --> 00:10:31,880 machen, um das Risiko zu minimieren, und wenn wir dann 198 00:10:31,880 --> 00:10:34,160 nicht wissen, wo wir angreifen müssen, haben wir natürlich ein 199 00:10:34,160 --> 00:10:37,000 extrem großes Problem. Ja, auch nicht nur, wenn wir es 200 00:10:37,000 --> 00:10:39,320 unter Druck machen, sondern es gibt ja auch einfach so diese 201 00:10:39,320 --> 00:10:41,760 klassische Horror Story. Der Freelancer verlässt die 202 00:10:41,760 --> 00:10:45,840 Firma und ja, er hat natürlich noch alle Tokens für unsere 203 00:10:45,840 --> 00:10:48,240 Package Manager und unsere Cloud Umgebung auf dem Rechner und. 204 00:10:48,920 --> 00:10:51,520 Und ja, alle wissen, eigentlich müssten wir jetzt mal Secrets 205 00:10:51,520 --> 00:10:53,320 rotieren. Dasselbe natürlich, wenn 206 00:10:53,320 --> 00:10:56,400 irgendwie ein Secret geleakt wird, aber das ist auch 207 00:10:56,400 --> 00:10:58,520 manueller Aufwand, das haben wir noch nie irgendwie 208 00:10:58,520 --> 00:11:01,560 durchgespielt, da gibt es keine Prozesse für und dann habe ich 209 00:11:01,560 --> 00:11:03,280 einfach Angst, dass ich vielleicht irgendwas kaputt 210 00:11:03,280 --> 00:11:08,080 mache, indem ich was rotiere und dann ja rotiere ich vielleicht 211 00:11:08,080 --> 00:11:11,680 lieber nicht, vertraue diesem Freelancer idealerweise oder 212 00:11:11,680 --> 00:11:13,840 kann ja auch ein ehemaliger Mitarbeiter sein, der das 213 00:11:13,840 --> 00:11:16,920 Unternehmen verlässt, oder? Und die Keys bleiben aktiv und 214 00:11:16,920 --> 00:11:18,720 da komme ich wieder so ein bisschen zu meinem Punkt am 215 00:11:18,720 --> 00:11:22,080 Anfang. Am besten wäre es, wenn wir gar 216 00:11:22,080 --> 00:11:24,960 keine Secrets erst haben und deswegen schauen wir uns jetzt 217 00:11:24,960 --> 00:11:28,000 mal so ein bisschen an wie wir so richtiges Zero Trust in cicd 218 00:11:28,000 --> 00:11:30,400 Umgebungen, aber auch auf developer Maschinen umsetzen 219 00:11:30,400 --> 00:11:33,560 können, ohne dass es überhaupt Secrets gibt, die. 220 00:11:33,560 --> 00:11:35,720 Die ich liegen kann, denn da gibt es mittlerweile Methoden 221 00:11:35,720 --> 00:11:37,120 für. Wir sind schon sehr viel weiter 222 00:11:37,120 --> 00:11:40,080 als noch vor 5 Jahren. Ganz viele Plattformen haben 223 00:11:40,080 --> 00:11:43,240 auch schon Dinge eingebaut, auch jetzt gerade noch mal in den 224 00:11:43,240 --> 00:11:46,240 letzten sage ich mal 6 Monaten ist viel dazu gekommen, weil wir 225 00:11:46,240 --> 00:11:49,360 immer mehr diese Angriffe gesehen haben und es geht schon 226 00:11:49,360 --> 00:11:52,160 mittlerweile und das Beste Secret ist eigentlich gar kein 227 00:11:52,160 --> 00:11:55,040 Secret. Und da kann ich sowohl in der 228 00:11:55,040 --> 00:11:58,480 cicd Umgebung als auch auf meinen eigenen Rechnern schon 229 00:11:58,480 --> 00:12:00,880 relativ viele Secrets eigentlich rausschmeißen. 230 00:12:00,960 --> 00:12:03,240 Wenn ich weiß wie. Ja, vielleicht fangen wir mal 231 00:12:03,240 --> 00:12:06,320 mit der developer Maschine an, weil du hast gerade dieses 232 00:12:06,320 --> 00:12:09,320 Beispiel genannt von dem Freelancer, der mein Unternehmen 233 00:12:09,320 --> 00:12:12,160 verlässt. Und da wäre es natürlich gut, 234 00:12:12,160 --> 00:12:14,960 wenn die. Die gerade genannten Adabl OS 235 00:12:14,960 --> 00:12:18,080 Secrets dort nicht auf der Maschine liegen würden, weil 236 00:12:18,080 --> 00:12:22,680 diese Person zwar Zugriff auf bestimmte Ressourcen hatte, aber 237 00:12:22,680 --> 00:12:27,600 das jeweils nur per Login. Single Sign on mit Multifactor 238 00:12:27,600 --> 00:12:31,920 Authentication auf entsprechende Systeme, dort dann per Roll 239 00:12:31,920 --> 00:12:35,760 based Access Control Zugriff auf diese Ressourcen hatte und 240 00:12:35,760 --> 00:12:39,600 sobald diese Person das. Das Unternehmen verlässt kann 241 00:12:39,600 --> 00:12:43,200 ich den Account deaktivieren und damit verlieren alle diese 242 00:12:43,200 --> 00:12:48,080 Zugänge sofort ihre Rechte und können nicht mehr missbraucht 243 00:12:48,080 --> 00:12:51,760 werden. Und genauso sollten natürlich 244 00:12:52,000 --> 00:12:57,600 diese Zugangsrechte im Idealfall immer extrem kurzlebig sein, im 245 00:12:57,600 --> 00:13:01,600 Idealfall per just in Time, das heißt, wenn ich irgendwelche. 246 00:13:02,160 --> 00:13:06,400 Ja, so Admin Oberflächen für meine Applikation habe, dann 247 00:13:06,400 --> 00:13:11,160 sollte ich natürlich sicherstellen, dass die User, 248 00:13:11,160 --> 00:13:15,440 wenn Sie darauf zugreifen, dann auch nur gezielt für einen sehr 249 00:13:15,440 --> 00:13:18,880 kurzen Zeitraum da drauf können und die Sessions nicht unnötig 250 00:13:18,880 --> 00:13:22,960 lange laufen, damit die Session vielleicht sofort abgelaufen 251 00:13:22,960 --> 00:13:25,440 ist. Wenn ich entsprechend entweder 252 00:13:25,440 --> 00:13:27,920 das Unternehmen verlasse oder mein Laptop verloren geht. 253 00:13:28,400 --> 00:13:30,320 Zum anderen gibt es ganz, ganz viele Tools mittlerweile für 254 00:13:30,320 --> 00:13:31,640 dich. Diese Secrets und Tokens halt 255 00:13:31,640 --> 00:13:34,080 gar nicht mehr brauchen. Also wenn ich mich gegen meinen 256 00:13:34,600 --> 00:13:37,880 unternehmensinterne Package Registry anmelde, dann kann ich 257 00:13:37,880 --> 00:13:40,200 das mittlerweile auch einfach über den Account machen, der 258 00:13:40,200 --> 00:13:44,040 dann idealerweise derselbe Single seinen Account ist und 259 00:13:44,160 --> 00:13:47,120 habe dann quasi diese ganzen Secrets, die ich ja eigentlich 260 00:13:47,120 --> 00:13:50,560 ach so unbedingt brauche um eine Applikation zu starten um eine 261 00:13:50,560 --> 00:13:54,160 Applikation zu bauen, halt nicht irgendwo rumliegen, sondern 262 00:13:54,160 --> 00:13:56,480 melde ich in dem Account und das ist schon so der erste Appell. 263 00:13:57,200 --> 00:14:01,560 Wenn das irgendwo geht, schaut doch mal, ob ihr euren npm Token 264 00:14:01,560 --> 00:14:05,000 nicht durch ein Login gegen npm euren New Get Token nicht gegen 265 00:14:05,000 --> 00:14:07,840 nicht durch ein Login gegen New Get ersetzen könnt. 266 00:14:07,920 --> 00:14:11,160 Das ist 1000000 mal sicherer und wenn jemand jetzt das 267 00:14:11,160 --> 00:14:14,160 Unternehmen verlässt kann ich die wenn ich eben SSO verwende, 268 00:14:14,160 --> 00:14:18,000 dann auch noch quasi einfach nur sauber aus meiner sag ich mal 269 00:14:18,000 --> 00:14:20,160 ich nutze hier wie entra id, also diese ganze Microsoft 270 00:14:20,160 --> 00:14:23,800 Umgebung ausgliedern und damit haben die haben die betroffenen 271 00:14:23,800 --> 00:14:26,080 Personen dann eben auch automatisch keinen Zugriff mehr 272 00:14:26,080 --> 00:14:28,200 drauf. Bei diesem zweiten Punkt, man 273 00:14:28,200 --> 00:14:31,160 muss natürlich dazu sagen, oft ist das bei diesen vielen Tools 274 00:14:31,160 --> 00:14:34,240 hinter irgendeinem Enterprise Tier versteckt, dass man sich da 275 00:14:34,240 --> 00:14:36,240 mit diesem Single sein und anmelden kann. 276 00:14:36,480 --> 00:14:39,120 Wer das nicht hat oder weil ich aber sagen, ich bin ein kleines 277 00:14:39,120 --> 00:14:41,320 Startup, ich kann jetzt nicht über den Enterprise Tier leisten 278 00:14:41,320 --> 00:14:43,800 um Single sein und zu erlauben, da macht euch wenigstens 279 00:14:43,800 --> 00:14:46,320 irgendwie eine oft Boarding Checklist, dass man dann einfach 280 00:14:46,320 --> 00:14:49,440 nur die entsprechenden User Accounts ausgeht habe und aus 281 00:14:49,440 --> 00:14:51,440 den ganzen anderen Tools, die man irgendwie so verwendet, 282 00:14:51,440 --> 00:14:54,320 vielleicht dann wieder. Rausschmeißt aber stellt 283 00:14:54,320 --> 00:14:58,400 zumindest sicher, dass die Leute eben auf user Account Ebene sich 284 00:14:58,400 --> 00:15:00,480 auch gern dann gegen die entsprechenden Systeme 285 00:15:00,480 --> 00:15:03,920 authentifizieren, die sie zum Bauen des Source Codes brauchen, 286 00:15:04,080 --> 00:15:06,560 aber auch vielleicht, um ihre developer Umgebung mit der 287 00:15:06,560 --> 00:15:08,800 Developer Datenbank oder sowas zu verbinden. 288 00:15:09,080 --> 00:15:11,920 Und eben nicht auf irgendwelche Keys und Tokens zurückgreifen. 289 00:15:12,080 --> 00:15:15,000 Ja, und ich denke, es ist auch realistisch, dass man auf 290 00:15:15,000 --> 00:15:19,920 absehbare Zeit nicht vollständig auf solche Secrets oder API Keys 291 00:15:19,920 --> 00:15:22,560 verzichten kann und dementsprechend ist es umso 292 00:15:22,560 --> 00:15:25,480 wichtiger, dass ich auf meiner developer Maschine natürlich 293 00:15:25,480 --> 00:15:28,720 darauf achte, dass sie auf keinen Fall in meinem Git 294 00:15:28,720 --> 00:15:30,360 repository landen. Aber. 295 00:15:30,480 --> 00:15:33,640 Aber du hast es auch gerade gesagt, möglichst auch nicht 296 00:15:33,640 --> 00:15:38,040 irgendwo sonst irgendwie auf meinem Dateisystem rumliegen und 297 00:15:38,040 --> 00:15:41,520 es gibt entsprechende Tools, die ich nutzen kann, egal ob es 298 00:15:41,520 --> 00:15:45,040 jetzt irgendwie einen Secret Scanner in meinem in meiner 299 00:15:45,040 --> 00:15:47,920 Developer Plattform wie github ist mit Secret Scanning oder 300 00:15:47,920 --> 00:15:51,040 Truffle Hawk oder Git Guardian verwendet, teilweise mit Pre 301 00:15:51,040 --> 00:15:53,760 commit Hooks, die einfach sicherstellen, dass ich auch 302 00:15:53,760 --> 00:15:58,080 nicht aus Versehen eine Datei mit Secrets zu irgendeinem 303 00:15:58,080 --> 00:15:59,960 Commit hinzufüge. Vielleicht habe ich das gar 304 00:15:59,960 --> 00:16:00,680 nicht gemerkt. Merkt. 305 00:16:00,680 --> 00:16:02,360 Und dann sind sie Teil des Commits. 306 00:16:02,360 --> 00:16:06,360 Ich pushe das ganze und schon liegt es auf github oder meinem 307 00:16:06,360 --> 00:16:09,920 anderen Source Control System was ich nutze und hier sollte 308 00:16:09,920 --> 00:16:11,920 ich auch nicht nur darauf achten, sondern auch die 309 00:16:11,920 --> 00:16:15,400 entsprechenden Tools nutzen um sicherzustellen, dass das auch 310 00:16:15,400 --> 00:16:17,880 nicht aus Versehen passiert, weil jedes Secret was erst 311 00:16:17,880 --> 00:16:21,840 einmal irgendwo in meiner Git history ist muss rotiert werden 312 00:16:21,840 --> 00:16:25,200 muss als kompromittiert. Gesehen werden, und das Macht 313 00:16:25,200 --> 00:16:27,920 natürlich extrem viel Arbeit. Und falls ihr sagt, Ja, ist ja 314 00:16:27,920 --> 00:16:30,440 schön, was die beiden da erzählen, aber meine Realität 315 00:16:30,440 --> 00:16:32,400 sieht anders aus. Ich brauche für Tool XY halt 316 00:16:32,400 --> 00:16:35,600 irgendwie einen Token, dann schaut zumindest, dass der 317 00:16:35,600 --> 00:16:38,280 Token, der auf eurer Maschine ist, vielleicht nur ein sag ich 318 00:16:38,280 --> 00:16:41,520 mal read only token ist. In den seltensten Fällen will 319 00:16:41,520 --> 00:16:45,600 ich von meiner Maschine aus wirklich Pakete pushen in einen. 320 00:16:46,160 --> 00:16:48,760 Package Manager, den ich vielleicht unternehmensintern 321 00:16:48,760 --> 00:16:51,240 benutze, sondern braucht da vielleicht zum Bauen des Codes 322 00:16:51,240 --> 00:16:53,360 ja wirklich nur den Read only token. 323 00:16:53,520 --> 00:16:55,280 Noch mal, wenn wir uns hier an so was wie Schalke luth 324 00:16:55,440 --> 00:16:57,720 erinnern, der konnte sich verbreiten, weil da auch 325 00:16:57,720 --> 00:17:01,320 wirklich Tokens mit Publish Rechten auf den developer 326 00:17:01,320 --> 00:17:03,280 Maschinen gelegen haben. Also selbst wenn ich 327 00:17:03,280 --> 00:17:06,240 irgendwelche Tokens brauche, kann man die ja oft zumindest so 328 00:17:06,240 --> 00:17:10,400 einschränken, dass sie wirklich. Nach least Privileg nur das 329 00:17:10,400 --> 00:17:13,920 können, was ich wirklich, wirklich, wirklich brauche, wenn 330 00:17:13,920 --> 00:17:15,960 keiner der anderen Dinge, die wir gerade eben aufgezählt 331 00:17:15,960 --> 00:17:18,960 haben, überhaupt gehen. Aber dann gibt es natürlich die 332 00:17:18,960 --> 00:17:22,640 Systeme, die berechtigt etwas veröffentlichen müssen, sei es 333 00:17:22,640 --> 00:17:27,280 Pakete in meinen Package Manager oder meine Anwendung in unsere 334 00:17:27,280 --> 00:17:31,920 Test und Produktivumgebung. Und das sind meine cicd Umgebung 335 00:17:32,080 --> 00:17:35,120 und auch hier muss ich diese gleichen Prinzipien 336 00:17:35,120 --> 00:17:38,040 berücksichtigen und muss zum einen mit. 337 00:17:38,120 --> 00:17:42,880 Mit least privilege arbeiten im Idealfall nicht irgendwie 338 00:17:42,880 --> 00:17:46,480 Secrets verwenden, auch wenn diese Systeme natürlich immer 339 00:17:46,480 --> 00:17:50,880 diese Secret Management Lösung irgendwie mitbringen und man 340 00:17:50,880 --> 00:17:53,840 denkt da ist mein Secret ja sicher, sie werden nur just in 341 00:17:53,840 --> 00:17:57,120 Time in meine Pipeline injected, aber auch da können sie 342 00:17:57,120 --> 00:18:01,320 natürlich leaken, alle diese Systeme, sie schreiben Logs und 343 00:18:01,320 --> 00:18:04,000 wenn jemand. Die Möglichkeit hat, meine 344 00:18:04,000 --> 00:18:06,880 Pipelines zu modifizieren, können natürlich diese Secrets 345 00:18:06,880 --> 00:18:10,080 auch ausgegeben werden und dementsprechend muss ich auch 346 00:18:10,080 --> 00:18:15,840 hier Strategien finden und anwenden um hier auch genauso 347 00:18:15,840 --> 00:18:19,520 wie auf der persönlichen Entwicklungsumgebung am besten 348 00:18:19,520 --> 00:18:22,320 völlig ohne solche Passwörter und Secrets zu. 349 00:18:22,320 --> 00:18:25,960 Arbeiten, um das umzusetzen, kann ich zum Beispiel moderne 350 00:18:25,960 --> 00:18:28,640 Authentifizierungsmechanismen nutzen, wie zum Beispiel Open Id 351 00:18:28,640 --> 00:18:32,240 Connect oder kurz Oidc. Das ist in vielen Umgebungen 352 00:18:32,240 --> 00:18:33,600 mit. Mittlerweile eingebaut und 353 00:18:33,600 --> 00:18:37,120 funktioniert so, dass ich mir eine Identität irgendwo anlege. 354 00:18:37,120 --> 00:18:40,520 Wenn ich jetzt zum Beispiel sagen will, meine mein Gitter 355 00:18:40,520 --> 00:18:45,360 repository darf in meine Azure produktiv Umgebung deproyen, 356 00:18:45,600 --> 00:18:49,120 dann lege ich mir bei Azure eine Managed Identity an und sage 357 00:18:49,120 --> 00:18:54,240 dann, dass ich dass diese github repository in genau auf diesem 358 00:18:54,240 --> 00:18:58,320 Branch und mit genau diesem github actions Workflow. 359 00:18:58,720 --> 00:19:03,760 Das darf sich dann dieser Azure Identität annehmen und hat dann 360 00:19:03,760 --> 00:19:06,800 auch die Rechte, die ich dieser Identität zuweise. 361 00:19:07,280 --> 00:19:09,840 Bedeutet aber auch, ich hinterlege bei Github dann gar 362 00:19:09,840 --> 00:19:13,360 kein Secret oder Passwort, mit dem sich das Ding gegen Azure 363 00:19:13,400 --> 00:19:16,960 identifiziert, sondern ich sage okay hier, das ist der in dem 364 00:19:16,960 --> 00:19:21,800 Fall die Client ID, die ist. Nicht, nicht ultraschützenswert, 365 00:19:21,800 --> 00:19:24,160 die kann ich theoretisch wissen, weil damit der der alleine kann 366 00:19:24,160 --> 00:19:26,640 ich nichts anfangen. Und wenn dann jemand zu Azure 367 00:19:26,640 --> 00:19:30,200 geht und nachweisen kann über diese Federation, die github in 368 00:19:30,200 --> 00:19:33,440 dem Fall mit Microsoft man gebaut hat, nachweisen kann, ja 369 00:19:33,440 --> 00:19:37,600 hier schau ich bin wirklich. Der Guitar Runner, der den Code 370 00:19:37,600 --> 00:19:41,040 ausführt, der aus dieser Pipeline kommt, die jetzt auf in 371 00:19:41,040 --> 00:19:44,560 diesem Repository auf diesem Branch läuft, dann sagt in dem 372 00:19:44,560 --> 00:19:46,960 Fall der Azure okay, dann darfst du dich mit dieser Identität 373 00:19:46,960 --> 00:19:50,400 jetzt hier ausstatten und die Dinge tun, für die diese 374 00:19:50,400 --> 00:19:53,480 Identität Berechtigung hat und in der Realität sieht es dann so 375 00:19:53,480 --> 00:19:56,320 aus, dass ich mir da am besten mehrere von anlege, also 376 00:19:56,320 --> 00:19:59,200 vielleicht eine, die gegen Pod deployen darf und einige, die 377 00:19:59,200 --> 00:20:02,000 gegen Def deployen darf und. Und die, die gegen Prot Deployen 378 00:20:02,000 --> 00:20:04,280 darf, die wird dann zum Beispiel auf gar keinen Fall bei einem 379 00:20:04,280 --> 00:20:07,680 Pull Request Review verwendet und die, die gegen Def deployen 380 00:20:07,680 --> 00:20:10,840 darf, die wird dann vielleicht automatisch, wenn auf dem Def 381 00:20:10,840 --> 00:20:14,320 Branch ein neues, ein neuer Change auftaucht oder wenn ein 382 00:20:14,320 --> 00:20:16,160 Pull request reinkommt verwendet. 383 00:20:16,240 --> 00:20:18,960 Die darf aber auch nur mein Developer System sprechen, 384 00:20:18,960 --> 00:20:21,280 vielleicht hat die auch nur Read only recht oder was auch immer 385 00:20:21,680 --> 00:20:24,360 und so kann man sich dann also durch diesen Zusammenschluss 386 00:20:24,360 --> 00:20:26,760 diese Federation, die diese beiden Unternehmen eingegangen 387 00:20:26,760 --> 00:20:28,320 sind. Bekommt man einen sehr 388 00:20:28,320 --> 00:20:32,160 kurzlebigen Token ausgestellt, einen sehr kurzlebigen Open ID 389 00:20:32,160 --> 00:20:34,760 connect Token, der wirklich auch nur für diese eine Session 390 00:20:34,760 --> 00:20:37,280 irgendwie da ist, mit der niemand anderes wirklich 391 00:20:37,280 --> 00:20:40,240 großartig was anfangen kann. Und diese Connections gibt es 392 00:20:40,240 --> 00:20:42,800 mittlerweile zwischen ganz, ganz vielen Systemen, also auch wenn 393 00:20:42,800 --> 00:20:45,600 ich jetzt sage, ich möchte Packages in die. 394 00:20:46,240 --> 00:20:50,000 Npm package Registry publishen dann kann ich auch da diese man 395 00:20:50,000 --> 00:20:53,320 das federated Creedencials in Anspruch nehmen und habe halt 396 00:20:53,320 --> 00:20:56,320 den ganz ganz großen Vorteil, dass ich meinem Deployment 397 00:20:56,320 --> 00:21:00,640 Partner in dem Fall npm oder schon Vorhersage pass auf man 398 00:21:00,880 --> 00:21:04,120 ich bei dir darf jemand was publishen der von mir kommt aber 399 00:21:04,120 --> 00:21:06,200 wirklich nur auf diesem Rudge wirklich nur aus diesem 400 00:21:06,200 --> 00:21:09,320 Repository und das kann da eben beweisen dadurch dass die beiden 401 00:21:09,320 --> 00:21:13,200 Plattformen eben diese diese Federation eingegangen sind und 402 00:21:13,200 --> 00:21:17,120 so komme ich dann dazu. Dong Story short, dass ich in 403 00:21:17,120 --> 00:21:20,920 meinem Guitar Repository gar keine Creidentials mehr habe, um 404 00:21:20,920 --> 00:21:23,000 mich gegen diese Systeme zu identifizieren und einfach nur 405 00:21:23,000 --> 00:21:26,080 mit der Tatsache, dass ich ich bin und das über die Plattform 406 00:21:26,080 --> 00:21:29,480 beweisen kann, an der anderen Plattform dann bestimmte 407 00:21:29,480 --> 00:21:31,440 Aktionen angenommen und erlaubt werden. 408 00:21:31,600 --> 00:21:35,760 Ja, und jetzt mag man überlegen, ja, was ist, wenn ich Systeme 409 00:21:35,760 --> 00:21:39,920 ansprechen muss, die Oidc nicht unterstützen, wo ich tatsächlich 410 00:21:39,920 --> 00:21:43,360 nur einen. Developer Key bekomme oder 411 00:21:43,360 --> 00:21:47,200 irgendein Secret, dann kann ich das trotzdem verwenden, indem 412 00:21:47,200 --> 00:21:51,400 ich einen Secret oder Password World verwende, egal ob es jetzt 413 00:21:51,400 --> 00:21:54,680 irgendwie hushy Cope World ist oder ein World in der Cloud 414 00:21:54,680 --> 00:21:59,200 Plattform meiner Wahl, die dann wiederum Oidc unterstützen in 415 00:21:59,200 --> 00:22:02,320 Kombination mit einem Rollbase Access Control. 416 00:22:02,840 --> 00:22:06,640 Das heißt, mein geht ab Action, Workflow oder meine Pipeline 417 00:22:06,720 --> 00:22:10,320 bekommt dann die Rechte bestimmte Secrets aus diesem 418 00:22:10,320 --> 00:22:15,200 Password World zu lesen und kann diese dann zur Laufzeit abrufen 419 00:22:15,200 --> 00:22:19,120 und verwenden. Das heißt in meinem cicd System 420 00:22:19,120 --> 00:22:22,000 habe ich weiterhin keine Secrets, obwohl ich hier mit 421 00:22:22,000 --> 00:22:26,480 Systemen arbeite, die vielleicht nur so ein klassisches Secret 422 00:22:26,560 --> 00:22:28,960 unterstützen ich. Und auch die Secrets ich mir 423 00:22:28,960 --> 00:22:31,920 dann da rausziehe. Die sollen natürlich keine 424 00:22:32,080 --> 00:22:34,880 Passwörter für irgendwelche Gott user sein oder irgendwelche 425 00:22:34,880 --> 00:22:37,360 Cluster Admins, das soll die am besten natürlich direkt 426 00:22:37,360 --> 00:22:40,320 verbanden, sondern auch hier wieder least Privileg auch meine 427 00:22:40,320 --> 00:22:43,800 cicd Pipeline soll natürlich, wenn sie zum Beispiel in einen 428 00:22:43,800 --> 00:22:48,760 kobanitis Cluster publish. Wirklich nur auf diesen einen 429 00:22:48,760 --> 00:22:51,360 Namespace, vielleicht sogar wirklich nur Right Rechte oder 430 00:22:51,360 --> 00:22:54,160 irgendwas haben auch gar keine Admin Rechte um mit Secrets da 431 00:22:54,160 --> 00:22:57,600 auszulesen, sondern wirklich nur die Rechte die sie braucht. 432 00:22:57,840 --> 00:23:00,400 Und wenn ich eben nicht OECD verwenden kann, dann hole ich 433 00:23:00,400 --> 00:23:03,000 mir da halt irgendwie die Credentials für aber auch wie 434 00:23:03,000 --> 00:23:06,440 gesagt auch dann wieder wirklich nur mit dem absoluten Least 435 00:23:06,440 --> 00:23:10,000 Privileg, also auch Pipelines behandeln wir potenziell als 436 00:23:10,000 --> 00:23:13,120 unzuverlässige Akteure. Und ich glaub, das ist dieser 437 00:23:13,120 --> 00:23:14,360 Mindset Shift, den wir machen müssen. 438 00:23:14,360 --> 00:23:17,360 Ne in meinen developer Rechner, selbst wenn ich davor setze 439 00:23:17,520 --> 00:23:21,360 sitze der ist nicht vertrauenswürdig oder sicher 440 00:23:21,360 --> 00:23:27,360 genug um diese ja diese God Mode User Credentials zu beherbergen 441 00:23:27,600 --> 00:23:29,600 und genauso wenig meine CICD pip. 442 00:23:29,600 --> 00:23:32,440 Ja, und ganz konkret heißt das jetzt, ich leg diese 443 00:23:32,440 --> 00:23:35,920 entsprechenden Identities in meinem Cloud Provider an. 444 00:23:36,280 --> 00:23:39,920 Kann dann entsprechend dort Rechte vergeben. 445 00:23:40,160 --> 00:23:44,160 Über Oidc findet dieses Vertrauensverhältnis statt 446 00:23:44,160 --> 00:23:49,440 zwischen meinem cicd System und dieser entsprechenden Plattform 447 00:23:49,440 --> 00:23:52,080 und ich kann dann auf sichere Art und Weise auf Secrets 448 00:23:52,080 --> 00:23:55,520 zugreifen oder in produktionsumgebung Dinge 449 00:23:55,520 --> 00:23:59,760 veröffentlichen und das Risiko, dass dann jetzt hier ein Secret 450 00:23:59,760 --> 00:24:03,640 verloren geht, ist absolut minimiert, weil natürlich auch 451 00:24:03,640 --> 00:24:06,400 meine ganzen. Pipelines oder Workflows 452 00:24:06,400 --> 00:24:09,720 entsprechend geschützt sind. Ich habe in meinem Source 453 00:24:09,720 --> 00:24:13,120 Control System die entsprechenden Rechte darauf so 454 00:24:13,120 --> 00:24:16,560 gesetzt, dass nicht jeder einfach diese Workflows 455 00:24:16,560 --> 00:24:20,880 verändern kann, um zum Beispiel Informationen rauszuloggen oder 456 00:24:20,960 --> 00:24:24,760 dort auch Dinge zu deployen, die nicht legitim sind, das heißt, 457 00:24:24,760 --> 00:24:26,480 hier greifen natürlich verschiedene 458 00:24:26,480 --> 00:24:30,880 Sicherheitsmechanismen ineinander, aber prinzipiell 459 00:24:31,120 --> 00:24:34,840 basiert alles auf dieser Idee von Zero. 460 00:24:34,960 --> 00:24:39,520 Trust, das heißt, ich vertraue per Definition niemandem, auch 461 00:24:39,520 --> 00:24:43,280 wenn er sich im eigenen Netzwerk bewegt, sondern ich validiere 462 00:24:43,280 --> 00:24:47,920 die Identität und weiß dann, welche Rechte diese Identität 463 00:24:47,920 --> 00:24:51,080 entsprechend bekommen soll. Und das Gleiche mache ich nicht 464 00:24:51,080 --> 00:24:54,000 nur beim Bauen oder beim Deployen von meiner Applikation, 465 00:24:54,160 --> 00:24:56,080 sondern auch wenn die Applikation läuft. 466 00:24:56,240 --> 00:24:59,120 Hier selber. Gleiches Prinzip, auch ich kann 467 00:24:59,160 --> 00:25:02,640 auf jeder modernen Plattform heute meiner Anwendung auch 468 00:25:02,640 --> 00:25:04,840 wieder eine Identity zuweisen, das. 469 00:25:04,840 --> 00:25:08,240 Denn ich höre schon, ja, ist ja schön und gut, dass vielleicht 470 00:25:09,360 --> 00:25:14,440 mein Bild jetzt ohne ein Passwort für den npm Feed 471 00:25:14,440 --> 00:25:17,120 auskommt, aber meine App muss ich ja trotzdem irgendwie gegen 472 00:25:17,120 --> 00:25:19,040 meine Datenbank verbinden und wenn ich eine App irgendwo mein 473 00:25:19,040 --> 00:25:21,440 Cluster deploye und da als Environment variable den 474 00:25:21,440 --> 00:25:24,160 connection string mit reinziehe, dann habe ich ja wieder einen 475 00:25:24,160 --> 00:25:27,360 Secret, was ich irgendwo habe und auch hier, nein idealerweise 476 00:25:27,360 --> 00:25:29,840 und das kann ich auch, selbst wenn ich in Cubanetes oder sowas 477 00:25:29,840 --> 00:25:33,400 rein deploye, kann ich sowas wie Workload Identity heißt das eine 478 00:25:33,400 --> 00:25:34,480 Azure L? Es gibt auch oft. 479 00:25:34,840 --> 00:25:37,360 Wieder Cloud Plattform da irgendwie einen Pondor zu das 480 00:25:37,360 --> 00:25:39,880 verwenden oder wenn ich einen gemanagten Par Service irgendwo 481 00:25:39,880 --> 00:25:42,560 verwende haben die das häufig auch auch dann kann sich eine 482 00:25:42,560 --> 00:25:46,560 Applikation die auf genau diesem Pass Host deployed ist eine 483 00:25:46,560 --> 00:25:50,360 Identität annehmen, nämlich die Identität von diesem Service und 484 00:25:50,360 --> 00:25:52,840 da kann ich diesem Service auch wieder Rechte zuweisen, das 485 00:25:52,840 --> 00:25:56,080 heißt ich kann dann sagen, EY diese Datenbank, die gibt gar 486 00:25:56,080 --> 00:25:58,520 keinen Connection String im Sinne von Username und Passwort 487 00:25:58,520 --> 00:26:02,240 mehr raus und an der sage ich ey wenn der Service der auf diesen. 488 00:26:02,560 --> 00:26:06,960 Diesen Pass host hier im Develop in der developer Umgebung ist, 489 00:26:06,960 --> 00:26:09,760 der darf auf dich liebe Developer Datenbank zugreifen. 490 00:26:09,840 --> 00:26:12,720 Auf dich liebe pod Datenbank aber nicht und der darf da aber 491 00:26:12,720 --> 00:26:14,640 auch nur die folgenden Rechte haben, das heißt wenn ich 492 00:26:14,640 --> 00:26:17,120 dieselbe Applikation auf meinem Computer starte. 493 00:26:17,600 --> 00:26:20,000 Dann wird die sich nicht gegen die Datenbank verbinden können. 494 00:26:20,080 --> 00:26:23,120 Wenn ich die Applikation aber auf dem Zielserver starte und 495 00:26:23,120 --> 00:26:25,440 der Server ist von einem Cloud Provider gemanagt, so dass 496 00:26:25,440 --> 00:26:27,600 dieser Server oder dann wurde vielleicht sogar nur der 497 00:26:27,600 --> 00:26:30,480 Container auf dem Server eine Identity bekommt, dann kann 498 00:26:30,480 --> 00:26:33,000 diese Identity wieder Rechte haben, das heißt es ist exakt 499 00:26:33,000 --> 00:26:35,800 derselbe Code und nur die Tatsache, dass der aufeinander 500 00:26:35,800 --> 00:26:38,880 Infrastruktur läuft, gibt ihr eben die Berechtigung mit 501 00:26:38,880 --> 00:26:41,560 verschiedenen externen Services wie einer Datenbank oder wie 502 00:26:41,560 --> 00:26:44,680 einem Cache zu sprechen. Jetzt habe ich gerade gesagt, 503 00:26:44,680 --> 00:26:46,400 wenn die auf deinem Rechner startet, hat sie keine 504 00:26:46,400 --> 00:26:48,600 Verbindung gegen die Datenbank und jetzt höre ich euch schon 505 00:26:48,600 --> 00:26:51,440 wieder schreien zu sagen, ja ich brauche aber jetzt mal eine 506 00:26:51,440 --> 00:26:53,800 Verbindung zur Datenbank oder ich muss zumindest auch bei mir 507 00:26:53,800 --> 00:26:56,640 bei mir mal lokal die App starten können und dass ich 508 00:26:56,640 --> 00:26:59,320 zumindest mich gegen die Development Umgebung verbinden 509 00:26:59,320 --> 00:27:01,840 kann und auch das geht über diese Identitäten. 510 00:27:01,840 --> 00:27:04,640 Ich kann mich dann auch auf dieser Plattform auf meiner 511 00:27:04,640 --> 00:27:07,800 Zielplattform bei WBS, bei GCP, bei Azure, wo auch immer ich 512 00:27:07,800 --> 00:27:10,960 bin. Natürlich auch mit meinem meinem 513 00:27:10,960 --> 00:27:14,120 User Account anmelden und die die Anwendung dann so 514 00:27:14,120 --> 00:27:16,360 konfigurieren, dass wir haben ja eben gehört, wenn sie auf diesem 515 00:27:16,360 --> 00:27:18,920 Zielserver läuft, sie die Identität von dem Server 516 00:27:18,920 --> 00:27:21,040 bekommt. Und wenn Sie auf meinem Rechner 517 00:27:21,040 --> 00:27:25,080 läuft, meine Identität bekommt. Das heißt, wenn ich meinem User 518 00:27:25,080 --> 00:27:28,640 Account Zugang gebe, zum Beispiel in der Developer 519 00:27:28,640 --> 00:27:31,640 Datenbank zu lesen und zu schreiben, dann kann die auch 520 00:27:31,640 --> 00:27:35,280 die Anwendung, die auf meinem Rechner läuft, die kann sich 521 00:27:35,280 --> 00:27:37,520 dann auch wieder diese Identität schnappen, also wieder diese 522 00:27:37,520 --> 00:27:40,600 Host Identität und auch damit sich dann gegen die Datenbank 523 00:27:40,600 --> 00:27:43,400 verbinden und auch hier wieder, wenn ich diese Systeme nicht 524 00:27:43,400 --> 00:27:46,000 unterstütze, kann es sich mindestens mit der Identität 525 00:27:46,000 --> 00:27:49,840 gegen einen Secret Store wie hushicop, Void oder Ash. 526 00:27:50,000 --> 00:27:53,040 Keyword oder sowas verbinden und dann zur Laufzeit die Secrets 527 00:27:53,040 --> 00:27:54,560 einladen. Also genau wie bei der Bild 528 00:27:54,560 --> 00:27:57,600 Pipeline auch und das geht auf jeden Fall und dann kann ich 529 00:27:57,600 --> 00:28:00,640 nämlich wirklich auf meinem Rechner und egal wo die 530 00:28:00,640 --> 00:28:03,480 Anwendung läuft. Ein Passwort zur Datenbank oder 531 00:28:03,480 --> 00:28:06,560 Connection String zur Datenbank vermeiden, weil ich das genauso 532 00:28:06,560 --> 00:28:10,160 wie beim Bild und genauso wie beim Deploy über Identitäten 533 00:28:10,160 --> 00:28:11,320 mache. Und ich weiß natürlich jetzt 534 00:28:11,320 --> 00:28:13,760 nicht genau, auf welchem System ihr unterwegs seid, aber auf 535 00:28:13,760 --> 00:28:17,120 allen modernen Systemen geht das mittlerweile und so kann ich 536 00:28:17,120 --> 00:28:20,640 langsam und sicher meine Dot n Datei aufräumen und vielleicht 537 00:28:20,640 --> 00:28:23,360 sogar am Ende der Folge wegschmeißen. 538 00:28:23,760 --> 00:28:26,960 Und wenn ich das ganze jetzt aufs nächste Level heben will, 539 00:28:26,960 --> 00:28:30,800 kann ich natürlich bei Oidc noch mal eine Schippe drauflegen. 540 00:28:31,200 --> 00:28:36,480 Mit entsprechenden zusätzlichen Conditional Access Policies und 541 00:28:36,480 --> 00:28:39,680 kann sagen Okay dieser Zugriff von Robin Mardol auf die Prod 542 00:28:39,680 --> 00:28:42,640 Datenbank funktioniert nur von seinem Arbeitsrechner und auch 543 00:28:42,640 --> 00:28:46,240 nur, wenn er sich gerade in Deutschland befindet. 544 00:28:46,320 --> 00:28:49,200 Das heißt ich kann da zusätzlich noch Policies ergänzen. 545 00:28:49,520 --> 00:28:53,600 Aber das Ganze wird entsprechend komplex und da kann man sich 546 00:28:53,600 --> 00:28:56,080 natürlich fragen, wer baut das alles auf? 547 00:28:56,080 --> 00:28:59,600 Das mache ich ja jetzt nicht als Developer alleine, das mache ich 548 00:28:59,600 --> 00:29:02,400 vielleicht auch nicht als Projektteam, was an einer 549 00:29:02,400 --> 00:29:06,200 bestimmten Applikation arbeitet, sondern ich brauche dort auch 550 00:29:06,200 --> 00:29:10,240 Expertinnen und Experten, mit denen ich zusammenarbeite und 551 00:29:10,240 --> 00:29:15,440 die das im Idealfall direkt für das ganze Unternehmen ausrollen 552 00:29:15,440 --> 00:29:18,480 und natürlich auch einheitlich bereitstellen. 553 00:29:19,120 --> 00:29:23,680 Dass wir halt dieses Grundprinzip von Zero Trust 554 00:29:23,840 --> 00:29:28,960 wirklich als Unternehmen auch verinnerlichen können und über 555 00:29:28,960 --> 00:29:31,600 das gesamte Unternehmen hinweg auch verwenden. 556 00:29:31,600 --> 00:29:33,600 Genau das hat natürlich, wie du gerade ansprichst. 557 00:29:33,600 --> 00:29:35,760 Wir müssen verschiedene Rollen und verschiedene Personen als 558 00:29:35,760 --> 00:29:37,320 verschiedene Dinge tun. Ich kann einfach so ein bisschen 559 00:29:37,320 --> 00:29:39,640 erzählen, wie wir das jetzt aufgesetzt haben und wie das bei 560 00:29:39,640 --> 00:29:43,080 uns funktioniert. Sind 2 Dinge zum einen läuft das 561 00:29:43,080 --> 00:29:45,040 halt natürlich über Policies, das heißt? 562 00:29:45,360 --> 00:29:48,880 Die Datenbanken, die ich, die Pleuel, die, die dürfen gar kein 563 00:29:48,880 --> 00:29:51,680 Connection String oder kein Secret ausstellen, die müssen 564 00:29:51,680 --> 00:29:56,080 über eine Identitäts und Rollenzuweisung angesprochen 565 00:29:56,080 --> 00:29:57,960 werden. Das heißt, Develop hatte davon 566 00:29:57,960 --> 00:30:01,040 noch nie gehört hat, läuft zwangsläufig vor diese Wand. 567 00:30:01,120 --> 00:30:03,240 Wie kann ich mich jetzt mit der Datenbank verbinden, weil wenn 568 00:30:03,240 --> 00:30:05,680 ich hier auf den Generate connection String Knopf klicke, 569 00:30:05,680 --> 00:30:08,440 dann kommt eine Fehlermeldung und ich muss mich dann damit 570 00:30:08,440 --> 00:30:12,000 damit beschäftigen, okay über Identitäten wie gebe ich denn 571 00:30:12,000 --> 00:30:15,080 überhaupt meiner laufenden App eine solche Identität, das 572 00:30:15,080 --> 00:30:17,120 heißt? Über so Policies kann man das 573 00:30:17,120 --> 00:30:19,800 natürlich einschränken. Ne zweite Sache, die wir hier 574 00:30:19,800 --> 00:30:23,200 als Plattform und Infrastructure Team machen ist, wenn jemand zu 575 00:30:23,200 --> 00:30:25,440 mir kommt und sagt Hey ich möchte irgendwas in die Azure 576 00:30:25,440 --> 00:30:29,200 Cloud deployen. Dann setzen wir so ein bisschen 577 00:30:29,520 --> 00:30:32,160 Plattform Engineering mäßig direkt, so eine leere 578 00:30:32,160 --> 00:30:35,760 Projekthülle auf, und da wird neben der Einrichtung einer 579 00:30:35,760 --> 00:30:38,320 Azure Subscription, die sich dann an diese Policies hält, 580 00:30:38,560 --> 00:30:41,080 auch in diese Subscription zum Beispiel direkt werden, da 581 00:30:41,080 --> 00:30:44,200 mehrere Identitäten rein deployed, die werden über diese 582 00:30:44,200 --> 00:30:50,000 Federated Credentials und Oidc direkt eingetragen in das in das 583 00:30:50,000 --> 00:30:53,440 Guitar Prepository, mit dem dieses Team dann arbeitet oder 584 00:30:53,440 --> 00:30:56,680 die Guitar Prepositories bedeutet bei den Federated 585 00:30:56,680 --> 00:30:59,280 Credentials. Ich direkt okay jemand der von 586 00:30:59,280 --> 00:31:02,080 diesem Repo, von diesem Runch kommt, der da sie identifizieren 587 00:31:02,080 --> 00:31:05,360 und im Github tragen wir quasi dann schon automatisiert über 588 00:31:05,360 --> 00:31:08,120 Terror Form, in unserem Fall mit Infrastructure ist Code die 589 00:31:08,120 --> 00:31:11,440 entsprechenden Variablen für die entsprechenden Environments ein, 590 00:31:11,440 --> 00:31:14,160 dass die auch wissen, welche Identity sie wann wie wo 591 00:31:14,160 --> 00:31:18,160 verwenden und so kann ich so ein bisschen dieses, ja ich sage mal 592 00:31:18,160 --> 00:31:20,560 so gerne forest developers into success. 593 00:31:20,840 --> 00:31:22,480 Kann ich damit so ein bisschen fördern, weil eigentlich alles 594 00:31:22,480 --> 00:31:24,800 schon aufgesetzt ist? Wenn du da noch so ein bisschen 595 00:31:24,960 --> 00:31:28,360 gute Dokumentation obendrauf Streust, dann hast du eigentlich 596 00:31:28,360 --> 00:31:31,040 schon mal, glaube ich, ein ganz cooles Setup, wo die Leute sich 597 00:31:31,040 --> 00:31:33,480 auch wohlfühlen und gar nicht so viel falsch machen können, weil 598 00:31:33,480 --> 00:31:36,880 du es über Policies manche Dinge gar nicht erlaubst und b das 599 00:31:36,880 --> 00:31:40,640 Grundsetup zumindest was so die Infrastruktur angeht, ohnehin 600 00:31:40,640 --> 00:31:43,520 schon aufsetzt, so dass es auch quasi mehr oder weniger von 601 00:31:43,520 --> 00:31:45,960 vornherein flüssig läuft und die Leute sagen, ah okay, das ist ja 602 00:31:45,960 --> 00:31:48,320 cool. Ich glaube, das bringt dann so 603 00:31:48,320 --> 00:31:51,040 beide Seiten zusammen. Zum einen ist es für mich als 604 00:31:51,040 --> 00:31:54,960 Developer sehr einfach zu nutzen und es macht mein Leben auch 605 00:31:54,960 --> 00:31:58,160 einfacher, weil ich muss jetzt nicht mehr mir irgendwo von 606 00:31:58,160 --> 00:32:01,280 Kollegen irgendwie einen Datenbank connection string 607 00:32:01,280 --> 00:32:03,840 holen, sondern ich mache einfach weiß nicht in dem Beispiel 608 00:32:03,840 --> 00:32:06,760 Secret Server Management Studio auf und logge mich mit meinem n 609 00:32:06,760 --> 00:32:10,080 3 D Account ein und kann dann direkt auf die Datenbank 610 00:32:10,080 --> 00:32:14,000 zugreifen mit den Rechten die ich in meiner Rolle haben sollte 611 00:32:14,000 --> 00:32:15,920 und. Und auf der anderen Seite, wenn 612 00:32:15,920 --> 00:32:20,560 ich so ein zentrales Identity Management habe, egal welche 613 00:32:20,560 --> 00:32:23,360 Plattform das jetzt ist, habe ich da natürlich auch eine 614 00:32:23,360 --> 00:32:27,440 Nachvollziehbarkeit und kann dann, falls mal irgendwas schief 615 00:32:27,440 --> 00:32:30,600 geht oder es zu irgendeinem Security Incident kommt, kann 616 00:32:30,600 --> 00:32:35,360 ich genau schauen, wer hat wann auf was zugegriffen und wenn ich 617 00:32:35,360 --> 00:32:38,640 sage wer muss das ja nicht unbedingt eine Kollegin Kollege 618 00:32:38,640 --> 00:32:42,160 sein, das kann auch. Jede dieser anderen Identities 619 00:32:42,160 --> 00:32:43,720 sein, über die wir gerade gesprochen haben. 620 00:32:43,720 --> 00:32:48,120 Das kann meine Applikation sein, die läuft, das kann irgendwie 621 00:32:48,120 --> 00:32:51,840 meine Ci pipeline sein und all das finde ich dann entsprechend 622 00:32:51,840 --> 00:32:54,720 in meinen Audit logs wieder und kann dann halt genau 623 00:32:54,720 --> 00:32:57,280 nachvollziehen, wann was passiert ist. 624 00:32:57,280 --> 00:33:00,800 Und das ist natürlich, gerade wenn es zu Sicherheitsvorfällen 625 00:33:00,800 --> 00:33:05,080 kommt, extrem wertvoll, wenn man genau weiß wo die Zugriffe 626 00:33:05,080 --> 00:33:07,400 herkamen. Also zusammenfassend, was könnt 627 00:33:07,400 --> 00:33:10,280 ihr morgen oder vielleicht sogar heute noch tun, um die. 628 00:33:10,880 --> 00:33:13,440 Quasi Zero Trust für Developer vielleicht auch nicht komplett 629 00:33:13,440 --> 00:33:15,800 zu machen, aber deutlich nach vorne zu bringen. 630 00:33:15,800 --> 00:33:17,680 Ich glaube die ersten Schritte haben wir ganz am Anfang schon 631 00:33:17,680 --> 00:33:20,960 erwähnt, ganz einfach easy Win ist Secret Scanning zu 632 00:33:20,960 --> 00:33:24,000 aktivieren, da gibt es ganz ganz viele Tools über Gitap Advanced 633 00:33:24,000 --> 00:33:26,720 Security, über Git Guardian über ganz, ganz viele Tools, die man 634 00:33:26,720 --> 00:33:30,560 sich in seine repo reininstallieren kann. 635 00:33:30,840 --> 00:33:32,560 Ich kann das sogar schon noch ein bisschen erweitern über so 636 00:33:32,560 --> 00:33:35,400 Pre commit Hooks. Da kann ich geht secrets quasi 637 00:33:35,400 --> 00:33:37,840 schon scannen, bevor oder während ich auf den Commit 638 00:33:37,840 --> 00:33:41,600 Button klicke oder den Commit Befehl absetze, das heißt die 639 00:33:41,600 --> 00:33:46,560 landen gar nicht erst irgendwo auf einem Remote Repository, das 640 00:33:46,560 --> 00:33:49,360 haben wir besprochen und das zweite ist so eine offboarding 641 00:33:49,360 --> 00:33:50,880 Checkliste. Wir haben ganz viel über 642 00:33:50,880 --> 00:33:53,600 Identity Provider und wie cool die sind gesprochen, aber ich 643 00:33:53,600 --> 00:33:55,960 weiß auch, dass sie sich oft hinter irgendwelchen Enterprise 644 00:33:55,960 --> 00:33:57,920 Tears, die sehr sehr teuer sein können, verstecken. 645 00:33:58,120 --> 00:34:00,680 Das heißt, mal mindestens sagen okay, wenn jemand das 646 00:34:00,680 --> 00:34:03,800 Unternehmen verlässt, muss ich dann eine Secret Rotation 647 00:34:03,800 --> 00:34:05,360 machen? Und wie sieht der Workflow dafür 648 00:34:05,360 --> 00:34:07,000 aus und wie kann ich das irgendwie so machen, dass ich da 649 00:34:07,000 --> 00:34:11,760 keine Angst vor habe und am Ende natürlich auch, wenn die Leute 650 00:34:11,760 --> 00:34:14,159 irgendwelche Personal access Tokens dann doch für irgendwas 651 00:34:14,159 --> 00:34:17,440 verwendet haben, selbst wenn sie sehr eingeschränkt sind und nur 652 00:34:17,440 --> 00:34:19,520 für bestimmte den bestimmten Use Case. 653 00:34:19,840 --> 00:34:22,639 Dann setze ich da halt trotzdem irgendwie eine Expiry drauf, 654 00:34:22,960 --> 00:34:25,600 idealerweise nicht 2 Jahre, sondern vielleicht irgendwie 3 655 00:34:25,600 --> 00:34:28,080 Monate oder so, dass ich zumindest alle 3 Monate mal 656 00:34:28,080 --> 00:34:29,920 darauf hingewiesen werde. A ich muss hier glaube ich noch 657 00:34:29,920 --> 00:34:33,520 was rotieren und b ist es auch irgendwie nervig genug, dass man 658 00:34:33,520 --> 00:34:35,520 sich so alle 3 Monate noch mal überlegen kann, ob es da nicht 659 00:34:35,520 --> 00:34:38,280 einen smoothheren Weg gibt, sich gegen das System zu 660 00:34:38,280 --> 00:34:40,800 authentifizieren. Und dann sollte ich natürlich 661 00:34:40,800 --> 00:34:44,320 entsprechende Passwort Management Tools einführen. 662 00:34:44,320 --> 00:34:48,080 Einmal für uns als Menschen über einen Passwort Manager, den ich 663 00:34:48,080 --> 00:34:51,480 im Team verwende oder vielleicht im ganzen Unternehmen Teile, wo 664 00:34:51,480 --> 00:34:55,760 ich dann gezielt sagen kann, wer hat auf welche Secrets Zugriff 665 00:34:55,840 --> 00:34:57,840 und das gleiche brauche ich natürlich für meine 666 00:34:57,840 --> 00:35:00,440 Automatisierung für meine Ci Pipeline, für meine 667 00:35:00,440 --> 00:35:04,720 Applikationen über einen Secret World, der zum Beispiel in 668 00:35:04,720 --> 00:35:07,680 meiner Cloud Plattform direkt integriert ist. 669 00:35:07,840 --> 00:35:09,360 Und dann kann ich natürlich auch. 670 00:35:09,520 --> 00:35:14,720 Auch in meinen Pipelines, in meinem cicd System von solchen 671 00:35:14,720 --> 00:35:18,240 Dingen wie Oidc vollständig profitieren, weil ich dann alle 672 00:35:18,240 --> 00:35:21,440 Secrets aus meiner Pipeline verbannen kann. 673 00:35:21,440 --> 00:35:25,360 Ich kann mich gegen meine Zielsysteme authentifizieren, 674 00:35:25,360 --> 00:35:30,320 kann aber auch weitere Secrets entsprechend abrufen und wenn 675 00:35:30,320 --> 00:35:33,520 ich das Ganze dann kombiniere mit einem Piloten, den ich 676 00:35:33,520 --> 00:35:37,680 starte rund um das Thema Managed identities, weil meine Cloud 677 00:35:37,680 --> 00:35:40,680 Plattform das unterstützt und. Umso besser, weil dann kann ich 678 00:35:40,680 --> 00:35:45,160 natürlich auch im laufenden Betrieb meiner Anwendung diese 679 00:35:45,160 --> 00:35:48,680 Identity zuweisen und dann über diese Identity die 680 00:35:48,680 --> 00:35:51,680 Zugriffsrechte zum Beispiel auf einen Storage Account oder eine 681 00:35:51,680 --> 00:35:54,320 Datenbank regeln. Was ich aber auf jeden Fall mal 682 00:35:54,320 --> 00:35:56,800 machen kann, wenn ich jetzt nach der Folge gemerkt habe, ah okay, 683 00:35:56,800 --> 00:35:59,200 ich lebe ja noch gar nicht in dieser perfekten Welt. 684 00:35:59,720 --> 00:36:02,160 Ist man sollte sich zumindest mal so ein Inventar 685 00:36:02,240 --> 00:36:05,240 aufschreiben, wo liegen denn überall Secrets, also nicht in 686 00:36:05,240 --> 00:36:07,920 dem Inventar die Secrets auflisten, sondern zumindest mal 687 00:36:07,920 --> 00:36:09,560 gucken, was haben wir denn überhaupt für Sachen, die jetzt 688 00:36:09,560 --> 00:36:13,480 vielleicht noch nicht über irgendwelche Fancy Omid connect 689 00:36:13,480 --> 00:36:16,160 identities gemanagt sind, sondern wo haben wir denn 690 00:36:16,160 --> 00:36:19,160 überhaupt noch welche Secrets, wer kann darauf zugreifen, wofür 691 00:36:19,160 --> 00:36:21,440 brauchen wir die? Und dann kann man ja auch mal so 692 00:36:21,440 --> 00:36:24,160 eine Zero Trust Roadmap aufstellen, wenn ihr ein 693 00:36:24,160 --> 00:36:26,360 Plattformteam habt, vielleicht sogar mit denen zusammen, weil 694 00:36:26,360 --> 00:36:29,480 wir haben eben gelernt, das ist sowohl die developer Maschine 695 00:36:29,480 --> 00:36:33,200 als auch die cicd Pipeline, also dann wirklich die die Deployment 696 00:36:33,200 --> 00:36:36,640 Umgebung am Ende. Wie kommen wir denn dahin? 697 00:36:36,960 --> 00:36:40,240 Und last but not least ist das natürlich, wie oft bei so Secret 698 00:36:40,240 --> 00:36:42,360 Themen auch, einfach eine kulturelle und eine 699 00:36:42,360 --> 00:36:44,840 Wissensfrage, also schaut mal, vielleicht gibt es irgendwelche 700 00:36:44,840 --> 00:36:47,400 Schulungen die cool sind, vielleicht wir haben bei uns zum 701 00:36:47,400 --> 00:36:50,000 Beispiel so eine Security Champions Community. 702 00:36:50,800 --> 00:36:53,600 Die jetzt nicht Sicherheitspolizei darstellen 703 00:36:53,600 --> 00:36:56,200 soll, sondern am Ende des Tages finden, dass die meisten 704 00:36:56,200 --> 00:36:58,480 Developer, mit denen ich besprochen habe, auch ziemlich 705 00:36:58,480 --> 00:37:00,600 cool mit diesen Identitäten zu arbeiten, auch weil es das 706 00:37:00,600 --> 00:37:02,520 eigene Leben leichter macht und das Setup von einem neuen 707 00:37:02,520 --> 00:37:03,840 Developer im Team leichter macht. 708 00:37:04,000 --> 00:37:06,400 Der muss nämlich nicht erst mal 15 secrets sich in irgendwelche 709 00:37:06,400 --> 00:37:08,880 Environment Variablen setzen, sondern es reicht, wenn er sich 710 00:37:08,880 --> 00:37:13,000 mit seinem Account anmeldet und wenn ihr einen Cezo oder sowas 711 00:37:13,000 --> 00:37:15,440 im Unternehmen habt, dann ist das ja auch was, wo man sich mal 712 00:37:15,440 --> 00:37:18,800 gemeinsam hinsetzen kann. Und genau diese Schulungs und 713 00:37:18,800 --> 00:37:22,080 Kulturfrage angehen kann, um das Thema auch langfristig in den 714 00:37:22,080 --> 00:37:24,800 Griff zu kriegen. Ja, und das reduziert natürlich 715 00:37:24,800 --> 00:37:27,520 auch das Risiko und den Druck für alle. 716 00:37:27,520 --> 00:37:30,360 Ich meine, stell dir vor, wir haben irgendwie ein gemeinsam 717 00:37:30,360 --> 00:37:33,680 genutztes Secret, was dann irgendwie liegt und du bist dann 718 00:37:34,240 --> 00:37:36,600 der Praktikant in einem Unternehmen, der als erstes 719 00:37:36,600 --> 00:37:39,200 gefragt wird, ob du derjenige warst, der das irgendwie aus 720 00:37:39,200 --> 00:37:41,480 Versehen öffentlich gepostet hat und. 721 00:37:42,080 --> 00:37:44,600 Das willst du nicht und von daher sind diese Systeme 722 00:37:44,600 --> 00:37:48,960 natürlich auch im Sinne der User selber, der Development Teams 723 00:37:49,280 --> 00:37:52,880 und ich glaube langfristig sollten wir dementsprechend zum 724 00:37:52,880 --> 00:37:56,560 einen keine neuen langlebigen Secrets mehr einführen. 725 00:37:56,560 --> 00:37:58,880 Wir sollten Identities verwenden, wir sollten Policies 726 00:37:58,880 --> 00:38:02,480 verwenden und. Und im Laufe der Zeit dann auch 727 00:38:02,560 --> 00:38:07,600 womöglich existierende Secrets in diese Systeme übertragen. 728 00:38:07,760 --> 00:38:11,360 Also wirklich zu schauen, wo kann ich von diesen modernen 729 00:38:11,360 --> 00:38:14,880 Authentifizierungsmechanismen profitieren und wo kann ich das 730 00:38:14,880 --> 00:38:19,200 Ganze dann möglichst schnell umstellen, damit wir hoffentlich 731 00:38:19,360 --> 00:38:22,960 dann perspektivisch irgendwann an diesem Punkt angekommen sind, 732 00:38:22,960 --> 00:38:26,680 wo wir gar keine Secrets mehr haben, weder auf der Development 733 00:38:26,680 --> 00:38:29,920 Maschine noch im CI System, noch in unserer Produktionsanwendung 734 00:38:29,920 --> 00:38:33,120 und. Sondern tatsächlich per Zero 735 00:38:33,120 --> 00:38:37,120 Trust und den entsprechenden Identities das Ganze abbilden 736 00:38:37,120 --> 00:38:38,680 können. Wobei wir da, glaube ich, gar 737 00:38:38,680 --> 00:38:40,400 nicht an diesem einen Punkt ankommen. 738 00:38:40,400 --> 00:38:43,600 Ich würde sagen, Zero Trust ist kein Projekt mit einem Enddatum, 739 00:38:43,600 --> 00:38:45,400 sondern eigentlich eine Denkweise, weil das fängt ja 740 00:38:45,400 --> 00:38:48,160 auch mit jedem weiteren Tool, was ich mir dazu hole, wieder 741 00:38:48,320 --> 00:38:51,880 neu an und deswegen fangt auch diese Woche an, die ersten 742 00:38:51,880 --> 00:38:54,200 Sachen umzusetzen. Also wenn ihr noch kein Secret 743 00:38:54,200 --> 00:38:57,120 Scanning habt oder sowas dann mindestens mal damit, wenn Euch 744 00:38:57,120 --> 00:38:58,560 die Folge hier gefallen hat, dann. 745 00:38:59,240 --> 00:39:01,200 Lasst uns gerne eine gute Bewertung da oder gebt uns einen 746 00:39:01,200 --> 00:39:02,960 Kaffee aus. Da freuen wir uns auch immer 747 00:39:02,960 --> 00:39:05,680 mega drüber. Findet den Link zu unten in den 748 00:39:05,680 --> 00:39:08,240 Shownotes, da haben wir so eine bei mir Coffee Seite 749 00:39:08,240 --> 00:39:10,760 eingerichtet. Und wie immer freuen wir uns 750 00:39:10,760 --> 00:39:13,040 natürlich auch, wenn ihr uns Feedback gebt. 751 00:39:13,040 --> 00:39:15,920 Und falls euch diese Folge weiter gebracht habt, lasst uns 752 00:39:15,920 --> 00:39:17,840 gerne eine positive Bewertung da. 753 00:39:17,840 --> 00:39:21,120 Das könnt ihr auf der Podcast Plattform eurer Wahl machen, zum 754 00:39:21,120 --> 00:39:23,360 Beispiel auf Spotify oder Apple Podcast. 755 00:39:23,600 --> 00:39:26,320 Ansonsten freuen wir uns natürlich auch auf einen Like 756 00:39:26,320 --> 00:39:29,160 von euch auf youtube, wenn ihr uns auf der Plattform hört und. 757 00:39:30,000 --> 00:39:31,600 Ansonsten hören wir uns nächste Woche wieder. 758 00:39:31,600 --> 00:39:34,560 Der to do Cast erscheint jede Woche, jeden Montag mit 759 00:39:34,560 --> 00:39:38,000 abwechselnd einem developer Thema wie diesem hier oder den 760 00:39:38,000 --> 00:39:40,160 aktuellen Tag und Developer News, die wir dann aus den 761 00:39:40,160 --> 00:39:43,680 letzten 2 Wochen zusammentragen. Seid also auch nächste Woche 762 00:39:43,680 --> 00:39:47,280 wieder mit dabei und bis dahin habt eine gute Zeit und schreibt 763 00:39:47,280 --> 00:39:50,080 ganz viel sicheren Code ohne viele Secrets. 764 00:39:51,440 --> 00:39:52,080 Bis dahin.