Secure by Design - Teil 1

Warum moderne Plattformen nicht nachträglich abgesichert werden können

Die Diskussion über IT-Sicherheit wird noch immer von einem Denkfehler geprägt. Sicherheit wird häufig als zusätzliche Schicht betrachtet, die auf bestehende Systeme aufgesetzt wird. Zunächst werden Anwendungen entwickelt, Infrastrukturen aufgebaut und Automatisierungsprozesse etabliert. Erst danach folgen Firewalls, Vulnerability Scanner, Endpoint Protection oder Compliance–Maßnahmen.

Dieses Modell funktioniert in einer Welt statischer Systeme vielleicht noch akzeptabel. In modernen Plattformarchitekturen führt es jedoch zwangsläufig zu Problemen.

Cloud-native Umgebungen bestehen heute aus tausenden Infrastrukturkomponenten, die kontinuierlich erstellt, verändert und wieder entfernt werden. Kubernetes–Cluster entstehen innerhalb weniger Minuten. Terraform provisioniert komplette Cloud-Landschaften automatisiert. Ansible konfiguriert Betriebssysteme und Middleware in großem Maßstab. GitOps-Pipelines deployen Änderungen teilweise hunderte Male pro Tag.

In einer solchen Umgebung ist Sicherheit keine nachgelagerte Funktion mehr.

Sie muss integraler Bestandteil der Architektur sein.

Genau das beschreibt der Begriff Secure by Design.

Die eigentliche Angriffsfläche liegt nicht in der Infrastruktur

Wenn über Angriffsflächen gesprochen wird, denken viele zunächst an öffentliche Endpunkte, Datenbanken oder Anwendungen. Technisch betrachtet befindet sich die kritischste Komponente jedoch häufig an einer ganz anderen Stelle.

In der Automatisierungsschicht.

Moderne Infrastrukturen werden nicht mehr manuell betrieben. Die Kontrolle liegt heute in Terraform-Projekten, Ansible-Playbooks, CI/CD-Pipelines, Kubernetes–Manifests und den Plattformen, die diese Werkzeuge orchestrieren.

Wer Zugriff auf diese Ebene erhält, benötigt häufig keinen direkten Zugriff auf Produktionssysteme mehr.

Die Automatisierung besitzt diesen Zugriff bereits.

Ein kompromittiertes Deployment-System kann Anwendungen manipulieren. Eine fehlerhafte Terraform-Ausführung kann Sicherheitsrichtlinien verändern. Ein kompromittiertes Ansible-System kann innerhalb weniger Minuten tausende Server konfigurieren.

Aus sicherheitstechnischer Sicht ist die Automatisierungsebene daher kein Hilfssystem.

Sie ist selbst kritische Infrastruktur.

Warum klassische Automatisierungsansätze Sicherheitsprobleme erzeugen

Viele Unternehmen verfügen über beeindruckende Automatisierungslandschaften. Terraform wird eingesetzt, Kubernetes betrieben und Ansible flächendeckend genutzt.

Dennoch entsteht häufig ein Problem, das zunächst unsichtbar bleibt.

Die Werkzeuge sind standardisiert.

Die Ausführungsumgebungen sind es nicht.

Administratoren verwenden unterschiedliche Versionen von Terraform. Entwickler arbeiten mit individuellen Python-Abhängigkeiten. Teams installieren eigene Ansible Collections oder nutzen lokale Erweiterungen. Playbooks werden von Workstations ausgeführt, deren Zustand sich von Benutzer zu Benutzer unterscheidet.

Die Folgen zeigen sich meist erst später.

Ein Deployment verhält sich unerwartet. Eine Infrastrukturänderung erzeugt unterschiedliche Ergebnisse. Ein Incident kann nicht vollständig rekonstruiert werden.

Die Ursache liegt häufig nicht im Code selbst.

Sie liegt in der Runtime.

Diese Unterschiede wirken zunächst operativ.

Tatsächlich haben sie unmittelbare Auswirkungen auf die Sicherheit.

Reproduzierbarkeit ist eine Sicherheitsanforderung

In der Softwareentwicklung gilt seit Jahren ein fundamentales Prinzip:

Ein identischer Build muss identische Ergebnisse erzeugen.

Erstaunlicherweise wird dieser Gedanke bei Infrastrukturautomatisierung häufig nicht konsequent weitergeführt.

Dabei sind die Konsequenzen gravierend.

Wenn dieselbe Terraform-Konfiguration abhängig von der lokalen Umgebung unterschiedliche Ergebnisse erzeugt, existiert keine vollständige Kontrolle über den Zielzustand. Wenn unterschiedliche Ansible-Versionen verschiedene Konfigurationsstände erzeugen können, wird Infrastrukturverhalten schwer vorhersagbar.

Sicherheit basiert jedoch auf Vorhersagbarkeit.

Ein System, dessen Verhalten nicht eindeutig reproduzierbar ist, lässt sich nur eingeschränkt kontrollieren.

Deshalb gewinnt die Containerisierung von Runtime-Umgebungen zunehmend an Bedeutung. Nicht nur die Infrastrukturdefinition selbst wird versioniert, sondern auch die gesamte Ausführungsumgebung. Terraform, OpenTofu, Ansible, kubectl oder Helm werden innerhalb definierter und reproduzierbarer Container-Runtimes ausgeführt.

Die Runtime wird damit Teil der Architektur.

Nicht mehr Teil der individuellen Workstation.

Governance scheitert häufig an fehlender Transparenz

Ein weiteres Problem moderner Automatisierungslandschaften besteht darin, dass Änderungen zwar stattfinden, ihre Entstehung jedoch nur schwer nachvollziehbar ist.

Wer hat eine bestimmte Änderung ausgeführt?

Welche Version eines Playbooks wurde verwendet?

Welche Runtime kam zum Einsatz?

Welche Zielsysteme waren betroffen?

Welche Credentials wurden genutzt?

Viele Organisationen können diese Fragen nur mit erheblichem Aufwand beantworten.

Das ist problematisch.

Nicht nur aus Compliance–Sicht, sondern insbesondere bei Sicherheitsvorfällen.

Incident Response basiert auf Kontext. Je besser die Entstehung einer Änderung nachvollziehbar ist, desto schneller lassen sich Auswirkungen bewerten und Gegenmaßnahmen einleiten.

Auditierbarkeit ist daher keine regulatorische Pflichtübung.

Sie ist ein Sicherheitsmechanismus.

Das unterschätzte Risiko: Secrets und privilegierte Zugriffe

Kaum ein Bereich wird in Infrastrukturplattformen so häufig unterschätzt wie der Umgang mit privilegierten Zugangsdaten.

API-Tokens, SSH-Schlüssel, Cloud-Credentials oder Zertifikate bilden die Vertrauensbasis nahezu jeder modernen Infrastruktur.

Gleichzeitig befinden sich diese Informationen häufig an Orten, an denen sie nie hätten landen dürfen.

In lokalen Home-Verzeichnissen.

Auf Entwicklerrechnern.

In Build-Systemen.

Teilweise sogar in Git-Repositories.

Das eigentliche Risiko entsteht dabei nicht durch das Secret selbst.

Das Risiko entsteht durch die fehlende Kontrolle über dessen Verwendung.

Secure by Design bedeutet deshalb, dass Identitäten, Berechtigungen und Secrets nicht als Nebensache behandelt werden. Sie müssen als zentrale Plattformfunktionen betrachtet werden.

Eine sichere Plattform beantwortet jederzeit die Frage, wer auf welche Ressourcen zugreifen kann, wann dieser Zugriff stattgefunden hat und welche Aktionen daraus resultiert haben.

Warum Plattformen wichtiger werden als Werkzeuge

Terraform ist nicht das Problem.

Ansible ist nicht das Problem.

Kubernetes ist ebenfalls nicht das Problem.

Im Gegenteil.

Diese Werkzeuge haben sich als Industriestandards etabliert und sind aus modernen IT-Landschaften nicht mehr wegzudenken.

Die Herausforderung liegt auf einer anderen Ebene.

Unternehmen benötigen nicht nur leistungsfähige Werkzeuge. Sie benötigen ein konsistentes Betriebsmodell für diese Werkzeuge.

Genau hier entstehen Plattformen.

Plattformen ersetzen Terraform nicht.

Sie ersetzen Ansible nicht.

Sie ersetzen Kubernetes nicht.

Sie schaffen einen kontrollierten Rahmen für deren Nutzung.

Standardisierte Runtime-Umgebungen, zentrale Governance, reproduzierbare Ausführungen, integrierte Auditierbarkeit und kontrollierter Umgang mit Secrets sind keine Eigenschaften einzelner Werkzeuge. Sie entstehen erst auf Plattformebene.

Polycrate verfolgt genau diesen Ansatz. Statt einzelne Technologien zu abstrahieren, werden sie in einer gemeinsamen Ausführungsschicht zusammengeführt. Infrastrukturteams arbeiten weiterhin mit den Werkzeugen, die sich in der Praxis bewährt haben. Gleichzeitig entsteht eine Plattform, die die Nutzung dieser Werkzeuge reproduzierbar, nachvollziehbar und kontrollierbar macht.

Fazit: Secure by Design ist eine Architekturentscheidung

Viele Sicherheitsmaßnahmen setzen erst dann an, wenn Infrastruktur bereits existiert.

Secure by Design verfolgt einen anderen Ansatz.

Die Frage lautet nicht, wie Systeme nachträglich abgesichert werden können. Die Frage lautet, wie sie von Beginn an so gestaltet werden, dass Risiken gar nicht erst entstehen.

Je komplexer moderne Plattformen werden, desto wichtiger wird die Architektur der Automatisierungsschicht. Dort entstehen heute die meisten Veränderungen. Dort konzentrieren sich die höchsten Berechtigungen. Und dort entscheidet sich letztlich, ob eine Organisation ihre Infrastruktur kontrolliert oder lediglich auf Vorfälle reagiert.

Sicherheit beginnt deshalb nicht bei der Firewall.

Sie beginnt bei der Plattform.