Mit "Configuration as Code"-Werkzeugen zum sicheren Betrieb von Serversystemen beitragen – und dabei auch noch Zeit sparen

Vorteile von Configuration as Code

Der klassische Ansatz zur Administration von IT-Systemen basiert primär auf manueller Arbeit. Soll eine Aufgabe erledigt werden, meldet sich der Administrator interaktiv am System an und führt die erforderlichen Schritte durch. Gibt es nicht nur ein System, sondern gleich mehrere, etwa aus Gründen der Redundanz, wird dieses Vorgehen wiederholt, bis die Änderung auf allen Systemen durchgeführt wurde. Nach kurzer Zeit kann sich diese Arbeit monoton anfühlen und dem Fähigkeitslevel eines IT-Administrators nicht angemessen erscheinen. Wenn irgendwann sogar ein neues System dazukommt oder ein bestehendes neu aufgesetzt wird, beginnt die Arbeit von vorn, nur dass diesmal nicht nur die kürzlich vorgenommenen Änderungen eine Rolle spielen, sondern auch die gesamte Grundkonfiguration erneut eingerichtet werden muss. Sollte die Dokumentation nicht ganz auf dem neuesten Stand sein – wie es leider oftmals vorkommt –, kann dies frustrierend sein und es entstehen Zweifel, ob nicht doch ein relevanter Schritt vergessen wurde.

Bei all diesen Punkten unterstützt ein Configuration as Code-Ansatz enorm. Besteht eine Änderung beispielsweise darin, ein neues Softwarepaket zu installieren und einige Zeilen in der Konfigurationsdatei zu ändern, ist dies mit dem Hinzufügen eines neuen Tasks und der Änderung des Konfigurationstemplates schnell erledigt. Durch Anstoßen des Configuration as Code-Werkzeugs beginnt dieses mit der Arbeit, loggt sich auf jedem gewünschten System ein und führt die Änderung durch. Nach einigen Sekunden ist die Änderung auf jedem System vorhanden.

Wird ein neues System in Betrieb genommen, kann es auf Knopfdruck in den gewünschten Zustand gebracht werden, vorausgesetzt die Zielkonfiguration wurde zuvor vollständig modelliert. Dies kann auch modular erfolgen, sodass zunächst etwa eine Grundkonfiguration für einen Linux-Server angewendet wird, dann ein Webserver nach Vorgabe eingerichtet wird und schließlich eine konkrete Anwendung "deployt" wird.

Ein unschätzbarer Vorteil ergibt sich zudem aus dem Umstand, dass das Niederschreiben der notwendigen Schritte zur Einrichtung der Systeme in leicht lesbarer YAML-Syntax gleichzeitig als akkurate Dokumentation gewertet werden kann. Wer beispielsweise wissen will, welche Softwarepakete für eine bestimmte Systemgruppe installiert werden, kann dies dort leicht nachlesen.

Configuration as Code für Sicherheitsmaßnahmen

Während die beschriebenen Vorteile ganz grundsätzlich beim Betrieb von IT-Infrastrukturen nützlich sind, ergeben sich auch positive Effekte für die IT-Sicherheit. Änderungen nicht jedes Mal erneut von Hand durchzuführen hilft dabei, Flüchtigkeitsfehler zu vermeiden oder keine Schritte zu vergessen, die im Zweifelsfall sicherheitsrelevant waren. Etwa, wenn es sich um eine Härtungsmaßnahme handelt oder ein Account mit Standardzugangsdaten deaktiviert werden soll.

Auch trägt die Verwaltung von Konfiguration in einem Configuration as Code-System dazu bei, eine gewisse Konsistenz zu schaffen. So kann vermieden werden, dass dieselbe Software auf verschiedenen Servern in unterschiedlichster Konfiguration und mit schwankenden Sicherheitseinstellungen existiert, über die kaum noch jemand den Überblick hat.

Wer schon einmal die eigene im Internet erreichbare Infrastruktur im Rahmen eines Pentests von der SySS GmbH hat untersuchen lassen hat, kennt vermutlich einige der typischen konfigurativen Schwachstellen: veraltete TLS-Protokollversionen und kryptografische Algorithmen, Letztere ebenfalls für SSH. Dabei handelt es sich um kleinere Probleme, die oftmals eine größere Zahl von Systemen betreffen. Auf jedem Server die entsprechenden Konfigurationsdateien anzupassen, kann dabei schnell der Mühe nicht Wert erscheinen. Mit Configuration as Code könnte die relevante Webserverkonfiguration einmal in den gewünschten Zustand gebracht und dann auf alle Webserver angewendet werden.

Eine solche Konfiguration mit Ansible zu verwalten, wird im Folgenden auszugsweise als Beispiel dargestellt.

YAML-Datei mit Tasks zur Installation und Konfiguration von nginx (weitere Konfigurationsdateien können und sollten ebenfalls ausgerollt werden):

Templatedatei "tls_settings.conf.j2" (sollte in den VHost-Konfigurationen der einzelnen Sites inkludiert werden, hier nicht dargestellt):

Die Templatedatei enthält dabei Jinja2-Syntaxelemente (insbesondere "if"), um eine Fallunterscheidung, basierend auf Variablen, zu treffen. Diese werden von Ansible ausgewertet; auf das Zielsystem gelangt nur eine der Varianten. So können verschiedene TLS Cipher Suites konfiguriert werden, je nachdem, ob die Variable "nginx_tls_ciphers" auf den Wert "modern" oder auf den Wert "compatibility" gesetzt ist. Auch die Unterstützung von OCSP Stapling bleibt optional, abhängig davon, wie die Variable "nginx_ocsp_stapling" gesetzt wird. In diesem vereinfachten Beispiel wurden die Variablen direkt im Task gesetzt, der die Datei auf das Zielsystem kopiert. In der Praxis würde man stattdessen sinnvolle Standardwerte wählen und diese bei Bedarf in systemspezifischen Variablendateien überschreiben.

Der Zeitspareffekt

Ein System oder sogar eine Systemlandschaft mit Configuration as Code zu modellieren, kann initial eine sehr große Menge Arbeit bedeuten. Insbesondere wenn das Vorgehen neu ist, muss zunächst auch das ein oder andere Tutorial durchgearbeitet werden.

Schließlich bietet es aber die bereits genannten Vorteile wie Konsistenz sowie die inhärente Existenz von Dokumentation.

Darüber hinaus lässt sich langfristig aber auch Zeit durch den sinnvollen Einsatz von Configuration as Code-Werkzeugen sparen. Sich wiederholende Arbeiten können leicht automatisiert werden, bis selbst die Installation eines neuen Systems kaum Mehraufwand bedeutet.

Interessant kann dies auch nach einem Security Incident sein, sobald das Thema Disaster Recovery aufkommt. In der Regel wird hier auf das Wiedereinspielen von Backups zurückgegriffen. Dies ist jedoch nicht immer möglich, etwa wenn Zweifel besteht, ob ein Angreifer nicht schon so lange im System war, dass das Backup ebenfalls betroffen ist. Manchmal fällt also doch die Wahl darauf, zumindest manche Systeme vollständig neu zu installieren. Existiert nun ein Configuration as Code-System, ist eine Neuinstallation schnell bewerkstelligt und das frische System kann automatisiert in den gewünschten Zustand gebracht werden.