Secure by Design – Teil 3

Warum Reproduzierbarkeit eine Sicherheitsanforderung ist

In den vergangenen Jahren hat sich Infrastructure as Code als einer der wichtigsten Bausteine moderner Plattformarchitekturen etabliert. Kaum eine Organisation betreibt heute noch größere Cloud- oder Kubernetes-Umgebungen ohne Terraform, OpenTofu, Ansible oder vergleichbare Werkzeuge. Infrastruktur wird beschrieben, versioniert und automatisiert bereitgestellt. Aus operativer Sicht stellt dies zweifellos einen enormen Fortschritt gegenüber manuellen Prozessen dar.

Gleichzeitig hat sich jedoch eine bemerkenswerte Annahme etabliert: Die bloße Verwendung von Infrastructure as Code werde automatisch zu reproduzierbaren und kontrollierbaren Systemen führen.

Diese Annahme ist nur teilweise richtig.

Infrastructure as Code beschreibt einen gewünschten Zustand. Ob dieser Zustand tatsächlich reproduzierbar erreicht werden kann, hängt jedoch von einer Vielzahl weiterer Faktoren ab, die in der Praxis häufig unterschätzt werden. Die eigentliche Herausforderung beginnt dort, wo nicht nur der Code selbst betrachtet wird, sondern die Bedingungen, unter denen dieser Code ausgeführt wird.

Genau an diesem Punkt wird aus einer operativen Fragestellung eine Sicherheitsfrage.

Die Illusion der identischen Infrastruktur

Wer ein Terraform-Repository betrachtet, gewinnt häufig den Eindruck, dass die Infrastruktur vollständig beschrieben sei. Die Definitionen befinden sich im Quellcode, Änderungen werden versioniert und jede Anpassung lässt sich nachvollziehen.

Die Realität moderner Plattformen ist jedoch komplexer.

Zwischen einer Infrastrukturdefinition und ihrer tatsächlichen Ausführung existiert eine zusätzliche Ebene, die in vielen Diskussionen nur unzureichend berücksichtigt wird: die Runtime.

Terraform selbst entwickelt sich kontinuierlich weiter. Provider erhalten neue Funktionen. Abhängigkeiten ändern sich. Ansible Collections werden aktualisiert. Python-Bibliotheken erhalten neue Versionen. Kubernetes-Werkzeuge verändern ihr Verhalten zwischen Releases.

Damit entsteht ein Problem, das vielen Organisationen erst auffällt, wenn erste Inkonsistenzen auftreten.

Zwei Teams können denselben Code ausführen und dennoch unterschiedliche Ergebnisse erhalten.

Nicht weil der Code fehlerhaft wäre.

Sondern weil die Umgebung, in der dieser Code ausgeführt wird, nicht identisch ist.

Aus Sicht der Plattformentwicklung handelt es sich dabei um ein Qualitätsproblem.

Aus Sicht der Sicherheit handelt es sich um ein Kontrollproblem.

Warum Sicherheit Vorhersagbarkeit benötigt

Sicherheit wird häufig mit Schutzmechanismen gleichgesetzt. Firewalls, Zugriffskontrollen, Verschlüsselung oder Netzwerksegmentierung gelten als klassische Sicherheitsmaßnahmen. Weniger offensichtlich ist die Tatsache, dass nahezu jede Sicherheitsentscheidung auf einer grundlegenden Voraussetzung basiert:

Vorhersagbarkeit.

Eine Organisation kann Risiken nur dann bewerten, wenn das Verhalten ihrer Systeme hinreichend bekannt ist. Sicherheitsrichtlinien können nur dann wirksam durchgesetzt werden, wenn die zugrunde liegende Infrastruktur konsistent arbeitet. Compliance-Anforderungen können nur dann überprüft werden, wenn nachvollziehbar bleibt, wie ein bestimmter Zustand entstanden ist.

Sobald dieselbe Infrastrukturdefinition unter unterschiedlichen Bedingungen unterschiedliche Ergebnisse erzeugen kann, beginnt diese Vorhersagbarkeit zu erodieren.

Das eigentliche Risiko liegt dabei nicht in einzelnen Abweichungen.

Das Risiko liegt in der schleichenden Entkopplung zwischen gewünschtem und tatsächlichem Zustand.

Viele Sicherheitsvorfälle entstehen nicht durch spektakuläre Angriffe. Sie entstehen durch kleine Unterschiede, die über längere Zeiträume unbemerkt bleiben.

Eine nicht aktualisierte Runtime.

Eine abweichende Provider-Version.

Eine lokale Anpassung auf einer Administrator-Workstation.

Eine veraltete Ansible Collection.

Jede einzelne Abweichung erscheint zunächst harmlos. In ihrer Summe führen sie jedoch dazu, dass die Organisation die Kontrolle über ihre eigene Infrastruktur verliert.

Das Problem der impliziten Abhängigkeiten

Besonders problematisch wird diese Entwicklung dort, wo technische Abhängigkeiten nicht mehr explizit dokumentiert sind.

Viele Plattformteams kennen dieses Phänomen.

Ein Deployment funktioniert zuverlässig auf einer bestimmten Workstation, während dieselbe Ausführung auf einem anderen System fehlschlägt. Bestimmte Terraform-Pläne erzeugen unerwartete Änderungen. Ansible-Playbooks verhalten sich unterschiedlich, obwohl sie auf identischen Zielsystemen ausgeführt werden.

Die Ursache liegt häufig nicht im sichtbaren Code.

Sie liegt in impliziten Annahmen über die Umgebung.

Diese impliziten Abhängigkeiten stellen eines der größten Hindernisse für reproduzierbare Infrastruktur dar. Solange sie außerhalb des eigentlichen Plattformmodells existieren, bleibt jede Ausführung von Faktoren abhängig, die sich nur schwer kontrollieren lassen.

Warum Runtime-Standardisierung wichtiger wird

Interessanterweise konzentrieren sich viele Diskussionen über Infrastructure as Code auf die Definition von Infrastruktur. Die Ausführungsumgebung selbst wird häufig als technische Nebensache betrachtet.

Dabei ist sie ein zentraler Bestandteil des Systems.

In der Softwareentwicklung wurde diese Erkenntnis bereits vor Jahren akzeptiert. Moderne Build-Pipelines definieren nicht nur den Quellcode, sondern auch die vollständige Build-Umgebung. Containerisierung hat sich gerade deshalb durchgesetzt, weil sie eine reproduzierbare Runtime bereitstellt.

Für Infrastrukturautomatisierung gilt derselbe Grundsatz.

Wenn die Runtime Einfluss auf das Ergebnis besitzt, muss sie Teil der Architektur werden.

Werkzeuge wie Terraform, OpenTofu, Ansible oder Kubernetes-Clients dürfen dann nicht länger von individuellen Workstations abhängig sein. Stattdessen müssen sie innerhalb kontrollierter und reproduzierbarer Ausführungsumgebungen betrieben werden.

Erst dadurch entsteht eine belastbare Grundlage für konsistente Automatisierung.

Reproduzierbarkeit als Grundlage von Governance

Die Bedeutung reproduzierbarer Ausführungen reicht weit über operative Stabilität hinaus.

Governance basiert letztlich auf der Fähigkeit, Entscheidungen nachvollziehen und überprüfen zu können. Eine Organisation kann jedoch nur dann belastbare Governance etablieren, wenn identische Eingaben zu identischen Ergebnissen führen.

Andernfalls wird jede Analyse von Änderungen zur Interpretation.

Sobald unklar bleibt, welche Runtime verwendet wurde, welche Abhängigkeiten aktiv waren oder welche Werkzeuge tatsächlich zum Einsatz kamen, lässt sich der Entstehungsprozess eines Infrastrukturzustands nur noch näherungsweise rekonstruieren.

Für Compliance mag dies bereits problematisch sein.

Für Incident Response wird es kritisch.

Denn die Rekonstruktion eines Vorfalls setzt voraus, dass die zugrunde liegenden Prozesse reproduzierbar sind.

Eine Plattform, deren Verhalten nicht reproduzierbar ist, lässt sich zwar betreiben.

Sie lässt sich jedoch nur eingeschränkt kontrollieren.

Die eigentliche Bedeutung von Secure by Design

Betrachtet man Secure by Design ausschließlich als Sammlung von Sicherheitsmechanismen, entsteht leicht der Eindruck, dass Sicherheit primär durch zusätzliche Schutzschichten erreicht wird.

Die Realität ist deutlich grundlegender.

Secure by Design bedeutet vor allem, Systeme so zu gestalten, dass ihre Eigenschaften vorhersehbar bleiben.

Reproduzierbarkeit ist deshalb keine Komfortfunktion moderner Plattformen.

Sie ist eine Voraussetzung für Sicherheit.

Nur wenn Infrastruktur konsistent erzeugt, verändert und betrieben werden kann, entsteht die notwendige Grundlage für Governance, Auditierbarkeit und belastbare Sicherheitsentscheidungen.

Die Diskussion über Secure by Design führt daher zwangsläufig zu einer Erkenntnis:

Nicht jede automatisierte Infrastruktur ist kontrollierbar.

Und nicht jede kontrollierbare Infrastruktur ist reproduzierbar.

Langfristig sicher betreiben lassen sich jedoch nur Systeme, die beides sind.

Im nächsten Teil dieser Reihe betrachten wir deshalb einen Bereich, der eng mit Reproduzierbarkeit verknüpft ist und in vielen Organisationen dennoch erstaunlich wenig Aufmerksamkeit erhält: den Umgang mit privilegierten Identitäten, Secrets und maschinellen Zugriffsrechten innerhalb moderner Plattformarchitekturen.