Secure by Design – Teil 2

Warum die kritischsten Systeme Ihrer Infrastruktur häufig nicht produktiv sind

Im klassischen Verständnis von IT-Sicherheit standen produktive Systeme stets im Mittelpunkt der Betrachtung. Datenbanken wurden gehärtet, Netzwerksegmente voneinander isoliert und Anwendungen gegen externe Angriffe abgesichert. Die Annahme dahinter war ebenso naheliegend wie plausibel: Wer kritische Daten schützen möchte, muss die Systeme schützen, auf denen diese Daten verarbeitet werden.

Diese Sichtweise war über viele Jahre hinweg richtig.

Mit dem Aufkommen von Cloud Computing, Infrastructure as Code und hochgradig automatisierten Plattformarchitekturen hat sich jedoch die Verteilung von Verantwortung und Kontrolle innerhalb moderner Infrastrukturen grundlegend verändert. Infrastruktur wird heute nicht mehr primär administriert, sondern definiert. Ressourcen werden nicht mehr manuell bereitgestellt, sondern durch deklarative Beschreibungen erzeugt. Änderungen erfolgen nicht mehr durch Administratoren auf einzelnen Systemen, sondern durch Pipelines, Automatisierungsplattformen und Runtime-Umgebungen.

Damit hat sich auch die eigentliche Macht innerhalb moderner IT-Landschaften verschoben.

Wer heute die Automatisierung kontrolliert, kontrolliert die Infrastruktur.

Die Verlagerung der Kontrolle

Um die Tragweite dieser Entwicklung zu verstehen, lohnt sich ein Blick auf die vergangenen Jahre.

In klassischen Rechenzentrumsumgebungen war die Kompromittierung eines einzelnen Systems häufig bereits ein erheblicher Sicherheitsvorfall. Administratoren arbeiteten direkt auf Servern, Konfigurationen wurden lokal verändert und viele Systeme besaßen klar definierte Verantwortungsbereiche. Selbst privilegierte Zugriffe waren häufig auf einzelne Plattformen oder Anwendungen begrenzt.

Moderne Plattformarchitekturen funktionieren anders.

Ein Terraform-Prozess besitzt nicht selten Berechtigungen zum Erstellen kompletter Netzwerke, Datenbanken und Kubernetes-Cluster. CI/CD-Systeme können produktive Anwendungen weltweit ausrollen. GitOps-Plattformen entscheiden über den gewünschten Zustand ganzer Umgebungen. Automatisierungssysteme verwalten Betriebssysteme, Middleware und Sicherheitsrichtlinien über tausende Systeme hinweg.

Die Folge dieser Entwicklung ist bemerkenswert.

Während die Anzahl einzelner Systeme kontinuierlich zunimmt, konzentriert sich die tatsächliche Kontrolle über diese Systeme auf immer weniger Plattformen.

Aus Sicht eines Angreifers entsteht dadurch ein völlig anderes Bedrohungsmodell.

Die Kompromittierung eines einzelnen Servers ermöglicht Zugriff auf genau diesen Server. Die Kompromittierung einer Automatisierungsplattform kann hingegen Auswirkungen auf die gesamte Infrastruktur haben.

Das Paradoxon erfolgreicher Automatisierung

Je erfolgreicher eine Organisation automatisiert, desto stärker konzentrieren sich Berechtigungen innerhalb weniger Systeme.

Dieser Zusammenhang erscheint zunächst widersprüchlich, ist jedoch die logische Konsequenz moderner Betriebsmodelle.

Automatisierung verfolgt das Ziel, manuelle Eingriffe zu reduzieren und Infrastruktur konsistent zu betreiben. Damit Automatisierung diese Aufgabe erfüllen kann, benötigt sie zwangsläufig weitreichende Berechtigungen. Eine Plattform kann keine Infrastruktur bereitstellen, wenn sie keine Ressourcen erzeugen darf. Sie kann keine Systeme konfigurieren, wenn ihr administrative Zugriffe fehlen. Sie kann keine Deployments durchführen, wenn sie nicht über entsprechende Rechte innerhalb der Zielumgebungen verfügt.

Je stärker Unternehmen auf Automatisierung setzen, desto wichtiger wird daher die Frage, wie diese privilegierten Systeme selbst abgesichert werden.

Interessanterweise konzentrieren sich viele Sicherheitsmaßnahmen weiterhin primär auf Produktionssysteme, während die Plattformen, die diese Systeme kontrollieren, vergleichsweise selten Gegenstand derselben Aufmerksamkeit sind.

Dabei besitzen sie häufig die größere Reichweite.

Diese Gegenüberstellung verdeutlicht, weshalb sich moderne Sicherheitsarchitekturen zunehmend von einer rein systemzentrierten Betrachtung lösen.

Die entscheidende Frage lautet nicht mehr ausschließlich, welche Systeme geschützt werden müssen.

Sie lautet vielmehr, welche Systeme die Fähigkeit besitzen, andere Systeme zu kontrollieren.

Warum Berechtigungen allein kein geeignetes Sicherheitsmodell darstellen

Viele Sicherheitskonzepte basieren implizit auf der Annahme, dass privilegierte Systeme vertrauenswürdig sind, solange ausschließlich autorisierte Personen darauf zugreifen können.

Diese Annahme wird den Anforderungen moderner Plattformen jedoch immer seltener gerecht.

Die Zahl technischer Komponenten zwischen Benutzer und Infrastruktur wächst kontinuierlich. Ein einzelner Infrastruktur-Change kann heute über mehrere Git-Repositories, CI/CD-Pipelines, Container-Runtimes und Automatisierungswerkzeuge hinweg verarbeitet werden, bevor die eigentliche Änderung produktiv wirksam wird.

Gleichzeitig nimmt die Bedeutung klassischer Benutzerkonten ab.

API-Token, Service Accounts, Machine Identities und automatisierte Workflows übernehmen zunehmend Aufgaben, die früher von Administratoren ausgeführt wurden. Das eigentliche Sicherheitsproblem besteht daher nicht mehr ausschließlich darin, wer Zugriff besitzt.

Entscheidend ist vielmehr die Frage, unter welchen Bedingungen dieser Zugriff genutzt werden kann.

Ein privilegierter Zugriff, dessen Nutzung nicht nachvollziehbar ist, stellt ein erheblich größeres Risiko dar als ein stark eingeschränkter Zugriff mit vollständiger Transparenz.

Sicherheit entsteht deshalb nicht allein durch Berechtigungen.

Sicherheit entsteht durch kontrollierte Ausführung.

Von Zugriffskontrolle zu Ausführungskontrolle

Diese Unterscheidung gewinnt in modernen Plattformarchitekturen zunehmend an Bedeutung.

Klassische Zugriffskontrolle beantwortet die Frage:

Wer darf etwas tun?

Secure-by-Design-Ansätze erweitern diese Perspektive um eine zusätzliche Dimension:

Unter welchen Bedingungen darf etwas ausgeführt werden?

Damit verschiebt sich der Fokus von Identitäten auf Prozesse.

Nicht mehr ausschließlich die Person oder das System stehen im Mittelpunkt, sondern der vollständige Ausführungskontext.

Welche Runtime wurde verwendet?

Welche Version eines Artefakts kam zum Einsatz?

Welche Parameter wurden übergeben?

Welche Systeme waren betroffen?

Welche Identitäten wurden verwendet?

Erst wenn diese Fragen beantwortet werden können, entsteht die Grundlage für belastbare Governance und nachvollziehbare Sicherheitsentscheidungen.

Warum Auditierbarkeit eine technische Eigenschaft sein muss

Viele Organisationen betrachten Auditierung noch immer als Compliance-Thema.

Tatsächlich handelt es sich um eine fundamentale technische Eigenschaft moderner Plattformen.

Je stärker Infrastruktur automatisiert wird, desto schwieriger wird es, die Entstehung einzelner Änderungen nachträglich zu rekonstruieren. Zwischen einem Commit und einer produktiven Änderung liegen heute oftmals zahlreiche technische Komponenten, die jeweils eigene Zustände, Abhängigkeiten und Berechtigungen besitzen.

Ohne eine systematische Erfassung dieser Zusammenhänge wird jede Form von Incident Response erheblich erschwert.

Die eigentliche Herausforderung besteht dabei nicht im Sammeln von Informationen.

Die Herausforderung besteht darin, die relevanten Informationen bereits während der Ausführung verfügbar zu machen.

Auditierbarkeit lässt sich deshalb nur begrenzt nachträglich ergänzen.

Sie muss Bestandteil der Plattformarchitektur sein.

Secure by Design bedeutet Kontrolle über die Kontrollsysteme

Die vergangenen Jahre haben gezeigt, dass sich die Architektur moderner Infrastrukturen grundlegend verändert hat. Während sich Sicherheitsstrategien lange Zeit auf produktive Systeme konzentrierten, verlagert sich die eigentliche Kontrolle zunehmend auf Plattformen, die Infrastruktur erzeugen, verändern und betreiben.

Diese Entwicklung macht Automatisierung nicht unsicher.

Sie verändert lediglich die Orte, an denen Sicherheit hergestellt werden muss.

Die kritischsten Systeme einer Organisation sind heute häufig nicht jene, auf denen Anwendungen laufen oder Daten gespeichert werden. Es sind die Systeme, die entscheiden, welche Anwendungen ausgerollt werden, welche Infrastruktur entsteht und welche Konfigurationen produktiv wirksam werden.

Wer über Secure by Design spricht, muss deshalb zwangsläufig über Automatisierung sprechen. Und wer über Automatisierung spricht, kommt früher oder später zu einer zentralen Erkenntnis:

Die wichtigste Sicherheitsfrage moderner Plattformen lautet nicht, welche Systeme kontrolliert werden.

Die wichtigste Sicherheitsfrage lautet, wer die Systeme kontrolliert, die alles andere kontrollieren.