 Also unser nächster Vortrag ist ein Netzwerks Security eingeschoben, reingeschmuggelt und er erklärt, wie man die Sicherung von Computernetzwerken raufskalieren kann und insbesondere in existierenden Netzwerken. Er ist ein ehemaliger Pentester und jetzt ist er ein Blue Team Mitarbeiter. Bitte einen Applaus für Maximilian. Vielen Dank. Mein Name ist Max Burkhart und ich bin heute hier, um euch zu erzählen, wie die anderen Sicherheitsingenieure und ich um ein starkes Netzwerks-Sekumentierungsmodell umsetzen. Ich bin ein Viseeheitsingenieur bei Airbnb und die praktische Arbeit ist in diesem Netzwerk passiert. Aber die Techniken, die ich hier angewendet habe und zeige, die lassen sich leicht auf andere Netzwerke übertragen. Und ich werde über die technische Theorie dahinter dem Ansatz erzählen und wie wir es ausgerollt haben. Und dann zeige ich auch gute Beweise, dass es funktioniert hat. Also lass uns darüber reden, wie man das in 2018 macht. Segmentierung war eine gute Sache. Wir wussten, dass es also Probleme geben würde, wenn es jetzt ein Zero Day war, war es ganz schlimm. Aber manchmal wurde auch noch vergessen, Server zu patchen. Und Segmentierung gibt dir die Kontrolle, die einzelnen Bereiche unabhängig voneinander zu halten und dass eine Einbreche halt nicht sofort an alles dran kommt. Und dass auch unsere Teams Zeit haben, den festzustellen. Und das funktioniert jetzt nicht mehr so gut. Wir wissen, warum es nicht mehr so geht. Wir sind ein kleines Sicherheits-Team und das Netzwerk ist schnell gewachsen. Und wir müssen unsere Arbeit so priorisieren, dass es da am meisten bringt. Und das ist meistens an der Außengrenze, wo man zum Internet geht. Und das heißt so, wir haben eigentlich eine harte Schale und einen weichen Kern. Und wenn der Angreifer außen die harte Schale durchbricht, dann hat er es häufig einfacher. Und wir wollen das natürlich nicht. Und jedes Sicherheits-Team Mitglied möchte das natürlich nicht. Aber Veränderung ist schwer und besonders mit dem großen Netzwerk. Und jetzt möchte ich mal ein bisschen Gefühl dafür geben, wie groß unser Netzwerk ist. Unser Produktionsnetzwerk hatte 2.500 Services und wir hatten 20.000 Knoten. Das ist sowas wie ein Host. Also entweder ist es eine Instanz im EC2 oder ein Kubernetes-Pod. Und unsere Ingenieure, die haben Hunderte von Services pro Tag ausgerollt. Und da jetzt segmentierung einzubauen, ist schwierig. Und das ist sehr stark serviceorientiert. Und die reden auch viel miteinander. Das heißt also festzustellen, wo die Zonen sind, ist schwierig. Ist nicht offensichtlich. Und unsere Entwicklerproduktivität ist natürlich wichtig für uns. Und meine Manager und deren Manager. Wenn man 1100 Ingenieure hat, die Ingenieure, die der Code schreiben. Und dann wollen wir die natürlich nicht bremsen. Das ist eine teure Sache. Wie soll man das machen? Dass wir von einem Netzwerk, was in der Mitte ein weichen Kern hat und eine gute Sekumentierung hat, zu einem sicheren Netzwerk. Ohne dass wir diese Sicherheit anhalten. Und das, was wir häufig hören. Und was man auch beim Pentesting hört. Und wenn man da reinkommt und da Dinge macht, ohne dass jemand was merkt. Das ist, wenn man Verteidigung macht, genauso wichtig man muss reingehen und Dinge tun, ohne dass jemand was merkt. Also unsere Theorie hier. Wir müssen aufhören über Sicherheit, als einen Layer zu denken, der ein weiterer Schritt im Wasserfallmodell ist. Das ist vielleicht das, was wir vor 30 Jahren gedacht haben. Ich baue eine Anwendung und dann hinterher mache ich Sicherheitstechnik. Und dann tue ich es in Produktion. Aber das geht aber heute nicht mehr. Heute macht man Dinge anders. Da gibt es Agile-Sicherheit, DevSecOps, SecDevOps. Und das ist die Vereinigung von Software Engineering und Security Engineering, dass man das gleichzeitig baut. Jetzt haben wir jetzt nicht erfunden, sondern das ist halt einfach, so wie man es heute macht. Und wenn man Anwendungen entwickelt, dann muss man jetzt auch mit Netzwerksicherheit integrieren. Das Wichtige ist, dass es skaliert. Wir müssen eine Sicherheitslösung bauen, die mit der Größe skaliert. Es ist gut, wenn man faule Ingenieure und Sicherheitsingenieure einstellt, weil die nämlich Dinge automatisieren werden und das ist das Beste, was man haben kann. Wir sind gute Projektleiter und deswegen werden wir zuerst mal festlegen, was wir denn überhaupt erreichen wollen, die Requirements. Also was wir bauen, darf die Ingenieure nicht behindern. Die dürfen vielleicht wissen, dass es da ist, aber je weiter wir das aus deren Bereich aushalten, desto besser. Denn unsere Organisation hat natürlich andere Ziele. Sicherheit sollte der Standard sein. Und das haben wir eine lange Zeit verfolgt. Aber wir können auch darüber hinausgehen. Wir können aber das noch ein bisschen verbessern und können sagen, es sollte hart sein, eine unsichere Konfiguration auszurollen. Und wir wollen etwas, das so weit wie möglich flexible ist und wir wissen nicht genau, was für Dienste oder Protokolle hier in sechs Monaten gebraucht werden. Zurzeit nutzen wir viel Linux auf Amazon, aber in Zukunft können wir vielleicht Haskell auf Azure brauchen oder irgendwie zu unseren eigenen Data Centers gehen. Wir brauchen also eine Lösung, die so organistisch ist wie möglich. Meine nächste Slide ist die ganze Lösung in zwei Sätzen. Wir werden TLS für Authentisierung und Vertraulichkeit in den Service Directory einbauen. Und damit kann man die Zugangslisten automatisch finden, um Null-Konfiguration Sicherheit zu gewährleisten. Jetzt kann man damit verteilte Systeme zusammensetzen, die automatisch gut konfiguriert sind. Ich habe also jetzt hier drei Säulen gebaut. Wir lieben TLS. Das ist eines der richtig guten Protokollen in der Sicherheitsindustrie. Und es gibt uns klasse Sicherheitsgarantien. Also erstmal müssen wir alles darauf ausrichten, dass es TLS nutzt und das überall läuft, ohne Anwendungsintegration. Ein zweites Säule ist, die Identität an Knoten binden. Vielleicht hat man in der Vergangenheit Subnetze oder IP-Adressen gemacht. Aber heute brauchen wir das nicht mehr. Wir können unsere eigenen Konzepte definieren und können die TLS Identitäten verwenden. Und das Dritte ist, wir werden eine Autorisierungsmap bauen. Und da werden wir herausfinden, nachdem wir herausgefunden haben, wie die Daten durch das Netzwerk fliegen. Und dann können wir also diese Zugangsrechte automatisch generieren und dann auch feststellen, wie die Zure funktionieren dürfen sollen. So funktionieren die Teile. Hier ist ein Beispiel mit drei Knoten. Jedes von diesen Knoten hat ein Zertifikat, mit dem sie sich identifiziert. Und die können miteinander durch TLS die Tunnel kommunizieren. Und die haben Autorisierungslogik, die durch eine zentralisierte Karte festgelegt wird. Hier ist die erste Säule, die ausreunden von TLS, die Umsetzung von TLS. Wir hören uns die Tunnel an. Wir müssen ein paar Grundzüge klarstellen. Wir benutzen gegenseitiges TLS, was ihr bestimmt von traditionellen TLS gehört. Das benutzt euer Webbrowser die ganze Zeit. Habt ihr einen Client, der normalerweise holt sich das Zert, der macht sich sicher, dass das dem Domainnamen übereinstimmt und guckt, ob das... Out of the Box macht das Autofinzieren beide Richtungen. Der Client, der auch in... ...using an equally strong authenticate. Das ist schwer einzurichten in den Netzwerk. Kannst du noch mal? Also in meinem eigenen Produktionsnetzwerk funktioniert das wunderbar. Das ist wunderbar. Und jetzt können wir in beide Richtungen starke Authentisierung haben. Wir wissen, wie man mit solchen Systemen umgeht. Nicht nur, kann man sicherstellen, dass Clienten solche Services haben. Die Server können schauen, wer mit ihm redet und überprüfen, dass der das auch durften sollte. So, jetzt kommt Services Entdecken. Ich habe das nicht so viel gehört, bevor ich nicht bei so großen Cloudfirmen gearbeitet habe. Im Kern ist das so, dass wir also einen Haufen Services haben und einen Knoten, der muss finden, mit wem er redet. Und DNS ist das Älteste von diesen Diensten, einer der Ältesten. Wir wollen Google Search gehen. Das heißt so, ich schau Google.com nach und der DNS kann Google Services für mich geben. Und das ist immer komplexer geworden und die Hosts sind sehr flexibel und das Zeug bewegt sich rum. Und die sind eigentlich in allen modernen serviceorientierten Architekturen. Und das ist ein bisschen problematisch für Sicherheit, weil wenn man es falsch macht, das versucht eine Karte zu sein. Und man sagt, hier ist der eine Service und da ist der andere Service und man kann das nutzen, um Sicherheit umzusetzen. Also was wir so genutzt haben ist Smart Stack und wir haben unsere Sicherheits extension auf das Obendraufgesetz. Und diese Konzepte können auf die meisten angewandt werden. Hier ist, wie Smart Stack funktioniert. Das haben wir als Open Source vor ein paar Jahren hergestellt. Wir nutzen Zookeeper und den HA-Proxy. Und wenn man sich das Beispiel anschaut, der zweite Knoten, der hat ein Service B angeboten und der berichtet in einen Zookeeper und sagt, hallo, ich bin hier und da kannst du mich finden. Und der Knoten 1, der möchte mit Service B reden und der holt sich die Adresse von dem Zookeeper und steckt das in die lokale Reverse-Proxy-Instanz. Und wenn der Service A jetzt den Service B aufrufen möchte, dann schickt er ein Request zum Localhost und der HA-Proxy, der kümmert sich darum, den Rest zu machen. Das war nicht für Sicherheit ausgerichtet. Alles kann den Zookeeper reinschreiben und das ist das Schlimmste, was man haben kann. Man fragt einfach noch eine Liste von Knoten und dann guckt man alles. Aber ich zeige euch auf den nächsten Seiten, wie man da Sicherheit einbauen kann. Der alte Weg, wie wir uns damit verbunden haben, ist wie folgt. Service A möchte mit Service B reden, der schickt ein Request nach Localhost und der schickt es dann rüber. Und Service B geht dann rüber zu Service B, genau. Was wir insogefügt haben, ist eine Sicherheitsschale und die läuft auf der Empfängerseite und wir haben die Proxys so umgebaut, dass wir damit beide mit TLS funktionieren, und zwar in beide Richtungen. Und das heißt also, alles, was über das Internet geht, ist durch den TLS-Tunnel. A und B ändern sich nicht. A schickt den gleichen Request und B kriegt den gleichen Request. Wir haben zwar radikal das Sicherheitsmodell geändert, aber wir haben die Services nicht geändert und die Ingenieure brauchen noch nichts zu ändern. Und damit kriegen wir unsere Unsichtbarkeit. Es gibt also zwei Service Proxys und weil die beide mit TLS sind und mit Authentizierung arbeiten, können die mit so einem Tunnel arbeiten. Und die Sicherheit hat das einmal gebaut und hat die über das gesamte Ding verteilt. Die gleichen Proxys können unabhängig von Sprachen und Protokollen usw. laufen. Und damit braucht man nicht alles autorisieren. Und damit haben wir also das Problem gelöst. Was hilfreich ist, ist, dass, wenn wir das auf beiden Seiten haben, dass es sehr hilfreich ist für Nicht-Sicherheitsgründen. Sachen wie zum Beispiel konsistente Metriken, besseres Tracing, besseres Low-Testing. Wir kriegen das umsonst, indem wir mehr Proxys haben. Wir kriegen auch Unterstützung von... Wesentlichen, was wir gemacht haben, ist das umgekehrt, als das, was die NSA macht. Vielleicht erinnert euch an die Slide. Wo wer ist schon? Wir fügen nur SSL hinzu und wir lassen es dort. Und alle Pfeile rechts müssen an TLS sein. Eine wichtige Sache ist, ist das Konzept von Proxy... von Proxy ausschließen. Wir brauchen dieses... ist wichtig, dass wir über diese Proxys gehen, dass die einzige Möglichkeit ist, mit dem Service zu reden. Wenn dieser Service... Also, der kann vielleicht HDDP mit dem Proxy reden und damit die ganze Sicherheit umgehen. Das heißt, wir müssen darüber Gedanken machen, wie wir das ausschalten können, dieses Problem. Also, wir haben jetzt... den zusätzlichen Proxy implementiert und damit TLS überall eingesetzt und damit die Services... also die Architektur radikal verändert. Das Zweite, was wir wollen, ist die Segmentierung. Wir wollen nur, dass legitime... Identitäten sich verbinden dürfen. So, und diese Zeitifikate können benutzt werden, um diese Identifizierung durchzuführen. Wir müssen uns überlegen, was diese Zeitifikate sagen und was sie sind. Wir versuchen, dass ein Knoten nur mit dem reden kann, wo man auch mit Reden darf oder reden sollen dürfe. Die wollen vielleicht mit allen möglichen Reden für Businessgründe, aber das müssen wir dann möglich machen. Und viele vorherige Segmentierungsversuche sind auf dem Subnetz-Level passiert. Und vielleicht sind sie über vordefinierte Kanäle zu anderen Sachen herausgekommen. Aber in einem Microservice-Netzwerk... da kann es vielleicht sinnvoller sein, auf einem Service-Ebenen darüber nachzudenken. Vielleicht wollen wir die Zahlungskonfigurationsseite mit dem Backend, mit der Service sprechen lassen. Aber wir haben auch ein Slackboard am Laufen, der Ideen an Ingenieure verschickt und der sollte nicht damit reden dürfen. Und wir wollen das nicht als statische Ebenen von Hosts abbilden. Sondern wir wollen, dass es eine Liste von Identitäten gibt, mit denen sie verbinden dürfen. Und wir haben diese Arbeit gemacht, diese Proxies aufzubauen, damit die TLS verstehen und benutzen können und TLS ist wunderbar, da drin Identitäten zu verifizieren. Jetzt können wir die Segmentierung machen, indem wir sagen, für diesen Listener, da dürfen folgende Dienste mitreden. Und jetzt können nur die richtigen Dinge miteinander reden. Wir müssen alle Knoten im Netzwerk identifizieren. Das wird in jedem Netzwerk ein bisschen anders aussehen, je nachdem wie es aufgesetzt ist. Das heißt, man muss ein Konzept von der Identität finden und das muss bestimmte Attribute haben. Die Identität für den Knoten muss unterschiedlich sein. Wenn die alle gleich sind, dann haben wir ein zentrales Netzwerk. Wir haben eine Identität, was der Knoten nicht ändern kann. Wenn ich einen Host identifiziere, dann kann ich die Identität ändern und dann kann ich mich mit anderen verbinden. Es ist etwas, was ich automatisch finden kann. Damit ich die Zertifikate verteilen kann. Wenn ich das mit dem Extra-Schied mache, dann habe ich ein ziemlich großes Problem. Und ich muss das Konzept in einem Zertifikat widerspiegeln. Also, wir wollten das in einen Subject-Alternative-Name von X509 reinfügen. Und die Rolle ist ganz gut dafür. Also, wir geben den Dingen Identitäten auf Basis ihrer Funktion. Und in AWS haben wir bestimmte Rollen und viele Services haben diese Rollen und die können nicht geändert werden. Außer man hat sehr hohe administrative Rechte und das kann durch den String abgebildet werden. Und jetzt schauen wir mal, was wir hier machen. Wir geben alle eine Identität und wir machen es seit der Fetagarte, die den Knoten es erlauben, ihre Identität zu beweisen. Und wir bauen dann eine Karte welche Identitäten welche Dienstag zugreifen dürfen. Und wir verteilen diese Karte und da steht dann drauf, wer das Payment Packend zugreifen darf. Und damit komme ich an Punkt, wo nur ganz wenige Hosts halt miteinander reden dürfen. Wie mache ich diese Karte? Das ist das letzte Segment von diesem Diagramm. Ich muss rausfinden, wer mit wem reden darf. Eine große Frage ist, wer sollte wem vertrauen? Wie komme ich dahin, dass ich mit minimalem menschlichem Aufwand herausfinde, was reden muss? Das, was ich erwähnte, ist, die menschliche Aufwand, die Segmentierung herauszufinden. Und wenn die Leute das halt von Hand machen müssen, dann ist es schwierig, das aktuell zu halten und sicher zu halten. Das heißt, wir wollen zu einer konfigurierenden Liste. Und die Frage war, ob wir das Netzwerk rausfinden können, wie das Netzwerk aktuell funktioniert, wie unsere Konfigurationen definiert sind und das dafür nutzen, wie Kommunikation passieren soll. Jetzt kommt ein interessanter Punkt. Und jetzt ist die Frage, wie man über Bedrohungen in der Organisation nachdenkt. Also, wenn wir jemandem erlauben, dass er peer-reviewed-in-code in das Config-Management-System reinstecken darf, dann hast du schon ziemlich Rechte in der Organisation. Und in unserem Fall haben wir folgende Repository für Chef. Und das kann zu allen Knoten was verteilen. Und das beschreibt schon die Abhängigkeiten von den Diensten in der Maschinenlesbahnart. Hier sieht man der Service 1, hat eine Abhängigkeit von der Produktion Database, von der Produktion Cache und von der Monitoring Service. Und das ist in dem Repository, das ist sehr stark kontrolliert und man muss ein Ingenieur sein, der also peer-review kriegt und so weiter. Und wir können das nehmen und können daraus rauslesen, dass also der Service ein Caller für die anderen Reitungen ist und können das daraus bauen. Dafür haben wir den Dienst der Erachne genannt ist. Das ist die griechische Göttin der Spinnen. Und das geht regelmäßig zu unserem Chef Repository und zu den Kubernetes-Hartefakten und baut daraus diese Karte für einen bestimmten Dienst, was der dürfen soll. Und schiebt ihr rüber in S3. Und dann können die von dort aus zu allen Knoten geschickt werden. Und die Barrieren, die wir hier machen, die hängen davon ab, wie wir über Insider-Bedrohungen in meiner Firma nachdenken. Wir vertrauen unseren Ingenieuren und wir schauen CI-Chats an und wir schauen, dass also die Karte und wir schauen, dass also unsere Ingenieure auch der Firma treu sind. Aber manchmal will man halt mehr Kontrollen haben. Und das System hier ist sehr flexibel. Wir brauchen ein System, das automatisch so viel finden kann, wie es kann und dann halt diese Karte generieren, weil man mehr Kontrollen haben will. Wenn das Ding jetzt eine neue Verbindung findet, dann kann man zum Beispiel das Security-Team bitten, diese neue Verbindung zu überprüfen. Die können also hier Monitoring machen oder zusätzliche Genehmigung. Und man kann auch schauen, was mit wem redet. Wir können mit Autorisierung auch weiter vorausgehen. Bevor wir diesen ganzen Service-Discovery-Process das erzählen, weil wir ein einfaches TLS verwenden, können wir auf diese Protokolle uns verlassen. Und der Inbound-Proxy, den wir da eingebaut haben, der hat das Feature, dass man das Client-Zertifikat in den HTTPS-Stream einfügen kann. Die meisten Protokolle, die wir nutzen, sind HTTPS. Das heißt also immer, wenn ein Service einen Aufruf kriegt, dann kann man halt den header pausen und kann halt schauen, wer der caller ist. Das wäre sonst ziemlich schwierig gewesen, umzusetzen. Man hätte vielleicht Tokens oder Keys oder sonst was verteilen müssen. Aber das hier erlaubt es uns, die ganzen schwierigen Kryptosachen zu dem Security-Proxy zu lassen und uns selber die einfachen Sachen zu machen. Das sind die drei Säulen. Wir geben hier mal eine Identität, um sicherzustellen, dass sie sich gegenseitig autizizieren können. Wir machen Segmentierungen, die wir bei bestimmten erlaubten Listen machen für Services und automatisch sehen wir dann diese Karte, diese Abbildung. Ich bin nicht hier, um euch diese Lösung zu verkaufen, weil ich sie mag. Es gibt auch ein paar negative Seiten, von denen möchte ich euch was erzählen, bevor ihr euch das anguckt. Das sind ein paar Sachen, die wir uns jetzt anguckt haben. Zuerst muss man immer diese Karte synchronisieren von diesen erlaubten Listen oder irgendeiner Untermenge davon, statt einer zentralisierten Erlaubung wie in einer Firewall, machen wir es sozusagen in einer verteilten Weise. Das heißt, wir haben ... ... und können Caching benutzen. Das macht manche Sachen einfacher. Ich erzähle euch, warum wir das gemacht haben. Aber das kostet ein bisschen Update, Latents. Es könnte langsam sein, wenn ihr in Cache benutzt. Als Zweites, wenn TLS ein Problem hat, dann hat man mehr Probleme, als man je hatte. Man auf die Grundelemente des Systems. Begründung ist hier, wenn HardBleed wieder passiert, dann wird ... Sicherheit. Wir verlassen uns darauf, dass ein großer SSL-Probleme von der Community schnell gelöst werden. Wenn man jetzt mehr Reverse-Process in den Traffic reinsteckt, dann ist das schon ein bisschen schwierig. Wir haben interessantes Verhalten in unseren Services generiert. Und ich werde gleich ein bisschen mehr darüber sagen. Das Hinzufügen von TLS hat wenig kaputt gemacht, aber der Extra-Hobb, der hat erstaunliche Dinge mit sich gebracht. Wir müssen Software laufen lassen, wo man den Traffic empfängt. Und wir brauchen einen sicheren Listener, der dazu hört, an diesen Traffic empfängt. Aber wenn wir jetzt gehostete Services haben, wo wir das nicht installieren können, oder wenn wir Herstellergeräte haben, dann wird das schwierig. Also tun wir normalerweise Proxyboxen davor. Und wir wollen natürlich Zertifikat-Entfernung implementieren. Wenn irgendein Node geknackt wird, dann müssen wir das natürlich auch ausrollen. Das lässt sich machen. Aber das sollte man natürlich mit einbeziehen. Ja, wie machen wir das jetzt? Wie rollen wir das aus? Das ist nicht theoretisch. Das ist etwas, was wir machen. Und ich hoffe, dass ich euch so viel von unseren Erfahrungen mit euch teilen kann. Erst mal die technischen Details. Wir haben das aus Komponenten, die Open Source verfügbar sind, und daraus haben wir es gebaut. Wir haben Envoy als den Empfängerproxiege genutzt. Wir haben das mit den Komponenten, die Open Source verfügbar sind, und daraus haben wir es gebaut. Wir haben Envoy als den Empfängerproxiege genutzt. Und in der Service-Netzwelt ist er sehr beliebt, er ist modern, er hat gutes ATL, er ist schnell, und er hat viele Eigenschaften, die nützlich sind. Und er ist gut. Ein Problem mit Envoy ist HTT P1.1. Da gab es ein bisschen komisches Verhalten in anderen Anwendungen, die nicht so strikt damit umgegangen sind. Aber Envoy war eine gute Wahl. Und wir migrieren, dass wir das auf der ausgehenden Seite auch nutzen. Also der Amazon IAM gibt eine Rolle, und wir haben die Zertifikate verteilt auf Basis von dieser Rolle. Und damit haben wir kontrolliert, welche Services mit welchen Reden dürfen. Der Erachnerservice, der ist ein bisschen Rubi-Skript, und der latest Chef Repository und die Kubernetes Artifakte. Diese Authorisation-Maps, die wird auch und runtergeladen auf S3. Und das nehmen wir als die Quelle wo das alles herkommt. Es braucht ungefähr 4 Minuten, bis wir das generieren und verteilen. Das heißt also 4 Minuten Verzögerung, bis das ermöglicht ist. Und unsere Erfahrung ist, dass das Ausrollen in Produktion langsamer ist. Das heißt also, wir haben jetzt keine neue Abhängigkeit geschaffen. Wir hatten besondere Vorstellungen für Verfügbarkeit und insbesondere über das Caching von den Ausgaben von unserem Erachner-Generator. Wenn der kaputt geht und aufhört, die zu generieren, dann wollten wir trotzdem, dass der Traffic weiter fließt. Wir wollten nicht, dass dieser Zentraldienst alles runternehmen kann. Wenn man diese Authentisierung dezentralisiert, dann wollen wir das natürlich auch als ein Vorteil nutzen können. Und dadurch, dass wir das aus S3 holen, können wir garantieren, dass wenn der Erachner ein Problem hat, dass wir neue Topologien nicht so schnell zur Verfügung stellen können. Der Traffic geht trotzdem weiter. S3 ist letztes Jahr runtergegangen und dann hat es trotzdem noch irgendwie funktioniert. Die haben zwar keine neue Topologie runtergeladen, aber die hatten noch einen lokalen Cache auf der Platte und sind trotzdem weitergelaufen. Das ist eine Designentscheidung, die uns gut bewährt hat. Der Plan für ein Rollout ist in sechs Schritte. Wir haben also zuerst diese Autorisierung generiert und weil das alles Offline-Data war, das heißt, wir haben viel Zeit verwendet, das ordentlich zu machen und auch zu überprüfen, dass es das ordentlich macht. Wir haben eben ein identifizierendes Zertifikat gegeben und das ist eine kleine Veränderung gewesen und die konnten wir relativ sicher machen. Und die haben wir halt verteilt und es war auch relativ einfach zu überprüfen, dass es funktioniert, bevor wir zum nächsten Schritt gegangen sind. Und haben also geschaut, dass die gut aussehen und dass die funktionieren. Als nächstes haben wir den Empfänger-Proxy installiert, um die Inhalte zu bekommen. Jetzt ist noch kein Traffic durch diese Tunnel geflossen, aber wir haben den Fahrt angeboten und das hat uns erlaubt den Schritt zu verifizieren, bevor wir jetzt zum nächsten Schritt weitergegangen sind. Als nächstes haben wir angefangen zu testen und haben die Inhalte gebaut. Wir waren in der Lage, das Pro-Service an- und auszuschalten. Wir haben jetzt ein paar ausgewählte Dienste gewählt, hohe QPS, niedrige QPS, HTTP, andere Protokolle und haben die Einnahmen an den Angeschalten und Stress-Tests gemacht. Als fünftes waren wir dann radikal und haben dann alles umgeschaltet. Das ist nicht, wie man unbedingt Operations betreiben will. Es gab zwei Leute, die auf diesem Projekt waren und es waren 1.920 andere Ingenieure, die so schnell wie möglich anderes Zeug gebaut haben. Wir hätten die nie eingeholt und das heißt, wir mussten ein System bauen, wo wir alles einschalten können und dann in einer neuen Kryptotext, also Neon-Plane-Text-Zukunft angekommen sind. Und dann haben wir die lokalen Dienste an Locals gebunden, um sich jetzt zu stellen, dass der Proxy genutzt werden muss. Erst nach dem sechsten Schritt waren die Sicherheitsgarantien gegeben, und da hatten wir dann natürlich auch keine Möglichkeit zurückzugehen. Also wir konnten einzelne Schritte zurückrollen. Jetzt zeige ich es nochmal visuell. Wir haben also mit den Knoten angefangen, dann haben wir die Karte gebaut, dann haben wir die IDs ausgerollt, die Zertifikate ausgerollt hinzugefügt, die Zertifikate installiert, dann haben wir für einige den TLS eingeschaltet und dann am Schluss haben wir alles live geschaltet. Wir haben das in April gemacht und eine ganze Menge ist gut gelaufen. Wir sind von 15 TLS zu TLS gegangen an einem Abend von 15 zu 70 an einem arbeiten und anders wäre das auch nicht möglich gewesen. Wir haben sichergestellt, dass es viele andere Benefits hatte. Damit haben wir in der Organisation auch Unterstützung gefunden. Weil das alles beeinträchtigt, werden da natürlich die anderen Ingenieure nervös. Und zwar die Leute, die über die Abtäume interessiert sind. Also wir haben einfache Konfigurationen als Vorteil angeboten. Die mussten jetzt nicht mehr lange drüber nachdenken, irgendwelche TLS Verbindungen aufzusetzen, wenn sie Sicherheit brauchten. Wir haben Performance tatsächlich verbessert. Es gab zehn weitere Metriken. Und das war für die Operations sehr hilfreich. Wir haben sichergestellt, dass wir die richtige Einstellung haben. Wir konnten für Einzeldienste TLS Routing hatten. Wenn also der Dienst ein Problem hatte, dann brauchten wir nicht alles zurückzuhalten. Wir konnten die Dinge, die funktioniert haben, benutzen und konnten einzelne Dienste zurückrollen, um die in Ordnung zu bringen. Dann gibt es natürlich auch ein paar Sachen, die nicht so gut liefen. Also alles durch ein Inbound Proxy, das klingt gut auf dem Papier. Aber wir haben ein paar komische Sachen gefunden. Vorne in 2500 Diensten sind die meisten ganz gut gelaufen. Vorne ein kleiner Prozentsatz, der nicht gut verkraftet hat. Auf einmal kommt der ganze Traffic von Localhost. In der Spec darf man z.B. die Kapitalisierung in den HTTP-Headern ändern. Das haben nicht alle Dienste verkraftet. Außerdem hat der Reverse Pocket Proxy die Web Sockets nicht wirklich unterstützt. Die haben wir nicht in Ordnung gemacht. Am ersten Tag hatten wir es dann, und alle diese Dinge konnten wir überkommen. Aber das, was komisch war, oder was lustig war, hatte nichts mit den Sicherheitseigenschaften zu tun. Unser Testen, so wie wir es angeschaltet haben, wir haben den Fall gut getestet, wo alle Traffic über diesen TLS-Proxy kommt. Das haben wir gut getestet. Was passiert denn jetzt, wenn die Dienste, die ich brauche, TLS brauchen? Oder verlangen? Der HAA-Proxy, den wir als ausgehenden Proxy genutzt haben, das war eine ältere Version. Das ist mit den TLS-Zertifikaten nicht so gut zurechtgekommen. Das hat für Tausende von Abhängigkeiten jeweils ein Zertifikat geladen, und damit den Speicher ziemlich überladen. Wir hätten das besser testen müssen. Das letzte, was ich noch erwähnen sollte, ist, dass wir die Dienste an Lokalhosen dranbinden. Wir haben gedacht, wir können einfach im Configuration Management das ändern. Alle, die an 0000 gegangen sind, sollen jetzt bitte zu 127 001 gehen. Das hat nicht so gut geklappt. Es hat zwei Wochen gedauert. Ich habe über Performance geredet. Das kommt häufiger mal, wenn man ein TLS-Projekt macht, aber es ist noch langsam. Zum Glück kann ich sagen, oft sind die schneller geworden. Das habe ich nicht erwartet. Jedes Mal, wenn jemand das sagt, habe ich gedacht, das kann das sein. Für einige unserer Dienste ist das 95. % der Latents bis zu 80 % besser geworden. Passwortdienste usw. Die haben das vorher schon gehabt. Die haben das auf dem Applayer gemacht, und die Anwendung zu Anwendung waren jeweils mit TLS dabei zu reden. Sie haben häufig neu gestartet, und neue Boxen sind gestartet. Und dann konnten die keinen TLS-Session-Caching nutzen. Und das heißt, die haben den TLS-Handshake die ganze Zeit gemacht, und das hat so langsam gemacht. Und die Service Discovery Proxies, die sind selten neu gestartet. Und die bleiben häufig Wochen oder Monate oben. Und deren TLS-Session-Caching ist sehr warm. Und die haben fast 100 % immer wieder richtig hingekommen. Das heißt, wir haben nur die IS-Verschlüsselung bezahlt, und das ist ein Hardware, und das war nicht so viel. Und damit haben wir alle Bedenken, dass es zu langsam wäre, auf unseren Netz aus dem Wind geschlagen. Das ist das, was man in eurer Infrastruktur machen wollte. Und vielleicht sind eure Netzwerke nicht so schön segmentiert, wie ihr das wollt, und vielleicht ist das ein guter Ansatz für euch, das auf großer Skala auszuholen. Hier sind die Dinge, die euch fragen solltet. Ist das eine gute Lösung für mich? Das Erste. Wie effektiv kann ich diese Proxies in meiner Organisation verteilen? Wir hatten ein Configuration Management System, was das verteilen konnte. Und wir hatten die Outbound Proxies. Das heißt, das war für uns eine relativ natürliche Sache. Aber ihr müsst natürlich drüber nachdenken. Und wie würdet ihr Identitäten verteilen? Das ist richtig wichtig, denn eine Identität ist eine Zone. Und wenn ihr Dinge habt, die spezifisch das ausdrücken, dann habt ihr vielleicht eine einfache Art Zertifikate zuzuweisen. Am Anfang hatten nicht jede Instanz eine IAM-Rolle. Das heißt, wir mussten erst mal sicherstellen, dass das über die ganze Infrastruktur so ist. Werdet ihr händische Konfigurationen brauchen? Oder könnt ihr die automatisch generieren? Also wenn ihr es automatisch macht, dann kriegt ihr aber einmal tolle Effizienzgewinne. Und momentan gibt es im Markt ein paar Möglichkeiten, die im Markt vorhanden sind, die das für einen machen. Wir haben es von Hand gemacht, aber hier sind Lösungen, die das für dich tun können. Und die machen das schon heute. Das ist nichts, was wir erfunden haben. Die Idee ist schon eine Weile auf dem Markt. Und die machen das hier auf eine einfache Weise. Und ihr könntet einfach sowas bauen. Aber wenn ihr keinen so großen Sprung machen wollt, dann könnt ihr mit der existierenden Service Discovery schon ein paar Vorteile mitnehmen. In Zusammenfassung, sag ich, es funktioniert, dass man zusammen am tief authentisierten Netzwerk machen kann. Und das ist, wenn man es schnell machen kann und wenn man es unsichtbar machen kann. Dieses automatische TLS und diese Autoresierungsmaps die helfen. Und der Ingenieur hatte vorher und hinterher die gleiche Erfahrung. Und die nutzen die gleichen HTDP-Aufrufe. Die haben die gleichen Abhängigkeiten und die Dienstetagen hintereinander. Der Arbeitsablauf bleibt der gleiche. Wenn ein Angreifer da jetzt irgendwie was hackt, dann ist er in der Netzwerkszone, wo er nicht mit besonders viel reden kann. Und vorher war das ganze Netz offen. Und jetzt werden wir einfach die Verbindung ablehnen. Das ist etwas, wovon ich denke, dass es möglich ist, weil wir es gemacht haben und es ist eine klasse Strategie. Und das konnten wir am Anfang nicht machen, als unser Netzwerk gestartet ist. Ja, vielen Dank fürs Zuhören. Und wenn ihr mich einzufragen fragen wollt, dann könnt ihr mich hier finden, maxb auf Twitter, maxbrokard.erbnw.com oder wenn ihr das Engineering sehen wollt, dann erbnwio. Ja, vielen Dank. Thank you, Max. If you do have a question, please line up on the microphones, try to limit your question to a single sentence. If you'd like to leave at this point, please do that as quietly as possible. Signal Angel, your first question from the Internet, please. Die erste Frage aus dem Internet, bitte. Question from the Internet. Warum ist OpenSSL und nicht LibreSSL? Ich habe OpenSSL gesagt, also ein zufälliges Beispiel. Man benutzt den Stack, den man der am besten für einen selber passiert. Von die Pakete. Für weiteres Hardening wäre es natürlich besser, wenn man zu boring oder LibreSSL wechselt. What are you currently doing to mitigate the increased risk of local host bound SSRF? Was ist das Risiko von einem local host SSRF? Ja, das ist ein Problem für mich. Da habe ich schon vorher dran gearbeitet. Unser Ansatz ist sehr gezielte statische Analyse. Und wir schauen den Engineer Code sehr genau an, wie wir das in der FDP-Aufrufe rausgehen. Und da es keine internen Dienste trifft. Und mein Team arbeitet da stark dran. Und vielleicht könnte das ein zukünftiger Vortrag werden. Wollt ihr Workstations mit einbegreifen? Das ist eine interessante Frage. Aber momentan sind unsere Workstations nicht in der gleichen Service Discovery. Und damit haben die keine Core Proxies, die damit arbeiten könnten. Aber wenn das eine Architektur wäre, dann würde das gut funktionieren. Wenn man die Workstations verwaltet, dann kann man den Identitäten geben. Wahrscheinlich müsste man den anderen Identifizierungsstrategie verwenden, damit man eine andere Rolle bekommen. Aber ansonsten ist es ein guter Weg. Haben sie den Proxycode auditiert, bevor sie den allen Services ausgerollt haben? Ja, das haben wir gemacht. Was waren die Kosten-Auswirkungen? Was waren die Kosten-Auswirkungen? Die Kosten-Auswirkungen sind den Rollout und den Betrieb. Auch die Kosten waren relativ niedrig. Der Reverse Proxy ist sehr effizient und hat nicht extra Computen gebraucht. Das heißt, wir brauchen nicht mehr Maschinen. AES an sich ist relativ billig. Die Generierung der Map ist einfach. Wir haben einen einzelnen Haus dafür. Wir haben die Transfer-Karte. Da arbeiten wir daran, das zu reduzieren. Wir müssen ein bisschen schlauer damit umgehen, wie häufig wir checken. Wenn wir nicht so viele Topologie-Änderungen haben, dann können wir das vielleicht ein bisschen seltener machen. Okay. Wie sieht es mit der Zertifizierungsautorität aus? Wie lange sind eure Zertifikate gültig? Was habt ihr darüber nachgedacht? Wir wollen zu einem Punkt, wo unsere Zertifikate schneller und älter werden. Bei manchen sind sie nur zwei Wochen. Manche sind nur zwei Wochen. Bei manchen sind sie nur ein Monat oder zwei Wochen alt, bevor sie ausgetauscht werden. Aber wir haben noch ein Verlässlichkeitsproblem, wenn wir das so viel reduzieren. Momentan können wir Dinge rausschmeißen, indem wir nach vier Minuten abschalten, indem wir in eine Blacklist reinschreiben und in einer Blacklist trainieren. Aber es ist ein länger laufender Projekt, die Lebensdauer von den Zertifikaten kürzer zu machen. Weil ihr alles auf einem flachen Layer 3-Netzwerk machten. Was bedeutet das für eure PC, ICSS-Umpfang? Und was bedeutet das für Firewalls? Unser PCI-Netzwerk ist interessant. Das ist komplett separat. Dieses Problem hat uns jetzt keine Probleme gemacht. Aber die Auditoren haben uns auch noch ein bisschen ein effektiver Weg, Zugangskontrolle zu strukturieren. Der ist jetzt nicht so ganz standard. Unser Kartenhalter-Environment, das ist... wir gehen zu Braintree. Also unsere Compliance-Leute, die haben das gut aufgenommen, was wir hier gemacht haben. Kannst du erklären, wie du das Management und die Ingenieure überzeugt hast und deren Bayern bekommen hast für diese Änderung? Ja, vielen Dank. Das ist eine gute Frage. Da red ich gerne drüber. Ein großer Teil von Sicherheit ist ein guter Verkäufer von Lösungen zu sein. Wenn du so etwas mit so einer bereiten Anwendbarkeit hast, dann musst du mit ganz vielen Teilen in deinem Reden, die sich um andere Dinge Sorgen machen. Und du musst drüber nachdenken, wie du deren Schmerz reduzierst. Und wir haben also aufgezeigt, dass die mit ihren eigenen Implementierungen von TLS Probleme hatten. Hier Performance Benefits. Das sind Dinge, die andere Infrastruktur an Produktteams gehört haben und das wollten sie. Und das heißt, die waren offen gegenüber unserem Anfrage. Und außerdem haben wir gute Pläne gehabt. Wir haben gezeigt, dass wir gut getestet haben und wir haben die Infrastruktur Ingenieure gedacht. Dass Sicherheit ist unser Ziel. Aber wir haben gut darauf aufgepasst, dass wir nicht unsere Glaubwürdigkeiten mit dem Rest der Organisation verbrannt haben. Man muss auch drüber nachdenken, dass es nicht alles durcheinanderbringt. Haben alle Knoten die volle Karte? Also unser Technologie-Stack ist Jason. Und da gibt es was ganz Kleines, was dieses File runterholt von S3. Und die relevante Liste von erlaubten Identitäten. In das NVoy-Konfigurations-File reintut. Und NVoy nutzt eine automatische updatende SDS-Konfiguration, um das alles ein paar Sekunden zu laden. Habt ihr drüber nachgedacht. Publish, Subscribe, Push für die relevante habt ihr drüber nachgedacht, Publish, Subscribe, Push für die relevanten Metataten zu nutzen, sodass ihr nicht alles verteilen braucht. Ja, wir haben drüber nachgedacht. Man kann das einfach zahaken, was man verteilt. Das ist eine Frage der Ingenieurzeit. Und wir haben eine ganze Menge anderer Möglichkeiten durch die Service Discovery. Es wäre einfach das zu machen. Und weil alles eine IEM-Rolle ist, kann man einfach IEM-Rollen spezifische Webfiles und dann halt die runterladen. Das wäre nicht so hart. Vielen Dank für die ganzen Fragen. Und jetzt einen Applaus für diese Präsentation.