Die 4 Phasen zur Automatisierung des Cloud-Managements

Die Cloud-Automatisierungsreise eines Security-Profis

Wenn Sie mich auf einer Konferenz antreffen, hören Sie mich mit hoher Wahrscheinlichkeit sagen: „Cloud-Sicherheit beginnt mit Architektur und endet mit Automatisierung.“ Gleich darauf folgt der Hinweis, wie wichtig eine Cloud-native Denkweise ist – selbst dann, wenn Sie in den Mühen einer unschönen Lift-and-Shift-Migration stecken, bevor der Rechenzentrumsvertrag ausläuft und Sie das Licht ausschalten. Das ist ein netter Einzeiler, aber er beschreibt nicht, wie ich mich von einem Security-Profi der Hausmannskost (Firewalls und Patch-Management) zu einem Cloud-Native für Architektur und Automatisierung entwickelt habe. Statt von der Kanzel zu predigen, halte ich es für nützlicher, meinen persönlichen Weg und meine technischen Erkenntnisse entlang dieses Weges zu schildern. Wenn Sie ein Security-Profi sind oder jemand, der einen Security-Profi für die Cloud weiterqualifizieren möchte, werden Sie sehr wahrscheinlich auf einem sehr ähnlichen Pfad landen.

Phase 1: Konfigurationen automatisieren

Für mich begann alles vor etwa neun Jahren, als ich gebeten wurde, das erste Schulungsprogramm für die Cloud Security Alliance aufzubauen. Schon früh wurde mir klar, dass wir wiederholbare Labs brauchten, die sich überall auf der Welt ausführen lassen – mit Teilnehmenden und Trainern, deren Kenntnisse von „Entwickler“ bis „papierschiebender Auditor“ reichten. Damals hatte Amazon Web Services IAM noch nicht wirklich eingeführt, und VPCs waren reine private Netzwerke. Und Konzepte wie Infrastructure as Code wurden gerade erst umsetzbar.

Da saß ich also und überlegte, wie sich für Tausende von Teilnehmenden ein praxisnahes Lab mit einem kompletten Anwendungs-Stack in der Cloud aufbauen ließe. Konsistent *und* aktualisierbar, während AWS seine Technologie weiterentwickelte. Eigene AMIs zu erstellen war damals noch mühsam, doch dann entdeckte ich die Wunder von `cloud-init`. Ein einfaches Skript, das ich in einem S3-Bucket hosten konnte, mit zwei kurzen Zeilen, die die Teilnehmenden in das Feld „User Data“ ihrer Instanzen einfügen konnten und die die Instanzen beim Start exakt wie gewünscht konfigurierten. Und wenn Software-Updates etwas kaputt machten, musste ich lediglich das Skript unter der veröffentlichten URL aktualisieren, und jede neue Instanz verwendete die neue Konfiguration – magisch! Beim Patchen laufender Systeme half das zwar nicht, aber es ermöglichte mir, ein gutes Ersteinstiegserlebnis aufrechtzuerhalten – weit einfacher, als neue AMIs zu aktualisieren und zu veröffentlichen. Und in einem Akt völliger reputationsbezogener Leichtsinnigkeit können Sie sich hier auf S3 noch immer eine spätere Version davon ansehen.

Mein erster Schritt war `cloud-init`. Ich nutze es heute nicht mehr, aber es war eine Offenbarung, dass ich einen kompletten Server per Skript einrichten und das Ganze mit Copy-and-paste und einer einzigen gehosteten Datei ausführen lassen konnte.

Phase 2: Workflows automatisieren

Der nächste Schritt hatte jedoch weit größere Wirkung. Nachdem ich einige Jahre praxisorientierte Schulungen durchgeführt und eigene Workloads aufgebaut hatte, begann ich, mit der Idee von Software Defined Security zu spielen. Vor mir lag ein Füllhorn an Cloud-APIs, die mir alle „ruf mich auf“ ins Ohr flüsterten. Ich suchte nach Beispielen und fand … nichts. Selbst Security Monkey war damals noch nicht öffentlich verfügbar.

Für die Sicherheitskonferenz Black Hat stand ein Kurs an, und ich nahm ihn zum Anlass, Ruby und die AWS-APIs (über das Ruby SDK) zu lernen. Am Ende schrieb ich drei Demonstrationen:

• Eine Incident-Response-Anwendung, die eine Instanz in Quarantäne nimmt, sämtliche Metadaten analysiert, sie mit AWS IAM sperrt, den gesamten Speicher abbildet und einen Forensik-Analyseserver startet, der die angehängten Snapshots analysieren kann. Was mich früher 30 Minuten gekostet hat, erledigte das in 3 Sekunden.
• Eine kleine App, die sich mit AWS und Chef verbindet und alle Instanzen identifiziert, auf denen Chef nicht läuft („nicht verwaltete“ Server). Ein Vorgang, der in einem traditionellen Rechenzentrum Wochen dauern kann.
• Eine weitere App, die Security Groups für einen Qualys-Scanner öffnet, einen Scan auslöst und die Security Group nach Abschluss wieder schließt.

Ich hatte zuvor nicht in Ruby programmiert, daher dauerte es rund zwei Monate Teilzeitarbeit, bis alle drei liefen. Sie waren recht einfach, aber ich habe einige wertvolle Lektionen gelernt.

• Die Verwaltung von Anmeldedaten war entscheidend und erschwerte es zugleich, den Code zu teilen und andere dazu zu bringen, ihre Umgebungen korrekt zu konfigurieren. Werte aus Konfigurationsdateien zu ziehen war … lästig. Vor allem bei Dingen wie der Frage, welche Security Group in welcher Region als Quarantänegruppe dient.
• Ruby funktionierte auf meinem lokalen System einwandfrei, aber dann sprengte ich Service-Limits und musste Verzögerungstimer einbauen, wenn ich den Code in einer Instanz in AWS ausführte. API-Service-Limits sind nicht Ihre Freunde.
• All das war wirklich statisch. So schick es für Demos auch war, letztlich lief es darauf hinaus, Code manuell von einem Desktop oder einer Instanz aus auszuführen. Das ist nicht gut gealtert.

Ich habe das Ganze als „SecuritySquirrel“ paketiert, und Sie finden die Versionen von 2014 auf GitHub. Ob Sie es glauben oder nicht: Das sind nicht einmal die Originale, die ich ein paar Jahre lang vor der Veröffentlichung genutzt habe.

Phase 3: Die Cloud selbst automatisieren

Als AWS die Rules für CloudWatch veröffentlichte, habe ich am darauffolgenden Samstagmorgen in etwa 2 Stunden genug Python-Code zusammengezimmert, um jede Änderung an Security Groups innerhalb von 10-15 Sekunden rückgängig zu machen – einschließlich Filtern, um die Absicherung anhand von Tags, der VPC oder der anfragenden Person einzugrenzen. Sie können den Code und die Anleitung herunterladen, und anders als mein Ruby-Code funktioniert dieser für 3 Jahre alten Cloud-Code noch immer recht gut.

Seit dieser ersten Demonstration habe ich eine Bibliothek ereignisgesteuerter Automatisierungen aufgebaut, die in Lambda laufen; einige davon können Sie herunterladen. Mein Favorit in diesem Paket ist `identify_internet_facing_servers.py`, das ich zu Demozwecken so verknüpft habe, dass es ausgelöst wird, wenn ich auf eine IoT-Variante eines Amazon-Dash-Buttons drücke. Ganz richtig: Ich trage einen echten, physischen Easy-Button in meiner Tasche. Das Skript findet alle Instanzen mit zum Internet offenem Port 22, und mit einem Doppelklick auf den Button kann ich die Regeln widerrufen und erhalte eine SMS auf mein Handy, sobald alles sicher und geschützt ist.

Meine wichtigste Erkenntnis hier kam unerwartet. Es war nicht so, dass diese ereignisgesteuerten Automatisierungen meine hostbasierten Workflows ersetzten – sie erfüllten einen anderen Zweck. Mir wurde klar, dass ich mich vom Bauen von Workflows, die mir Dinge schneller erledigen halfen, hin zum Bauen von Leitplanken bewegt hatte, die im Hintergrund für Sicherheit sorgen. Beides hat enormen Wert.

Phase 4: Alles automatisieren

Meine jüngste Arbeit dreht sich um den Einsatz von Jenkins und Infrastructure as Code (überwiegend CloudFormation) zur Verbesserung der Sicherheit. Diese Kombination ermöglicht es mir, Sicherheit in die Infrastruktur und die Anwendungen selbst hinein zu automatisieren und weniger auf externe Tools angewiesen zu sein.

Zum Beispiel habe ich einen einfachen Credentials-Scanner veröffentlicht, der in Jenkins läuft und gespeicherte Zugriffsschlüssel findet, noch bevor der Build überhaupt startet. Warum warten und später mühsam danach suchen? Anschließend habe ich weitere Test-Harnesses geschrieben, mit denen ich praktisch jedes gewünschte Analysewerkzeug in Jenkins ausführen und Builds fehlschlagen lassen kann, wenn sie einen Sicherheitstest wie einen Netzwerk-Scan nicht bestehen (Profi-Tipp: Jenkins lässt einen Build fehlschlagen, wenn Sie aus einem Skript einen anderen Exit-Code als 0 senden).

Um den Bogen zu schließen: Wir führen die Schulung inzwischen mit CloudFormation-Templates durch, die alle Elemente des Anwendungs-Stacks aufbauen, sodass sich die Teilnehmenden auf das Hinzufügen von Sicherheit konzentrieren können. Aus konsistenten Schulungsservern wurden konsistente Schulungsumgebungen – mit eigenen AMIs, die wir in Minuten aktualisieren können … weltweit … mit sehr geringem Aufwand, und mit vorinstallierter Software, bereit für die finale Konfiguration.

Meine Cloud-Reise begann vor etwa neun Jahren, meine Automatisierungsreise nahezu zeitgleich. Zunächst habe ich Dinge gebaut und dann versucht, Teile davon zu automatisieren; heute beginne ich mit der Annahme der Automatisierung. Meine frühesten Arbeiten drehten sich um den Betrieb, heute geht es fast ausschließlich um Sicherheit. Darum, den operativen Overhead abzuschmelzen und den sicherheitsbezogenen Teilen meines Denkens zu erlauben, sich auf das zu konzentrieren, worin sie am besten sind. Unterwegs habe ich außerdem gelernt, dass nicht jede Automatisierung gleich ist: Es gibt Einsatzbereiche für Leitplanken, Workflows, plattformübergreifende Orchestrierung, Infrastructure as Code und die Automatisierung von Pipelines. All das bringt heute nahezu unvorstellbare Sicherheitsvorteile, doch wir stehen noch sehr am Anfang, wenn man eine Woche allein damit verlieren kann, eine schlecht dokumentierte API zu rekonstruieren.

Wenn Sie in der Sicherheit tätig sind, wird es Zeit, Ihre Code-Fähigkeiten aufzubauen. Wenn Sie in Entwicklung oder Betrieb arbeiten, wird es Zeit, Ihre Sicherheitsfähigkeiten aufzubauen. Denn die größte Lektion von allen lautet: Die Zeiten, in denen Sicherheit ein Schirm war, sind vorbei, und die Zeiten, in denen Sicherheit Teil des Gewebes ist, sind angebrochen.