Warum Ihre Infrastrukturregeln als Code geschrieben sein sollten

Ihr Team hat eine Richtlinie: Keine Security Group darf jemals SSH (Port 22) für das gesamte Internet öffnen. Alle stimmen zu. Es steht in der Dokumentation. Jemand hat es sogar ausgedruckt und an die Wand gehängt.

Dann, an einem Freitagnachmittag, erstellt ein Entwickler eine neue Security Group für einen schnellen Test. Er setzt den CIDR-Block auf 0.0.0.0/0 auf Port 22, weil er einfach schnell etwas testen will. Die Änderung wird durchgeführt. Niemand bemerkt es, bis am Montagmorgen das Sicherheitsteam eine Warnung über einen offenen SSH-Port sendet.

Dieses Szenario wiederholt sich jede Woche in vielen Teams. Nicht, weil die Leute nachlässig sind, sondern weil manuelle Richtlinien nicht skalieren. Wenn Infrastrukturänderungen mehrmals täglich stattfinden, ist es eine Einladung zu Sicherheitslücken, sich auf menschliches Gedächtnis oder dokumentenbasierte Regeln zu verlassen.

Das Problem mit dokumentenbasierten Richtlinien

Die meisten Teams beginnen mit Richtlinien, die in Dokumenten gespeichert sind. Ein Google Doc, eine Confluence-Seite oder ein PDF in einem gemeinsamen Laufwerk. Diese Dokumente beschreiben, was passieren soll und was nicht: „Alle S3-Buckets müssen verschlüsselt sein“, „Nur genehmigte AMIs dürfen verwendet werden“, „Jede Ressource muss ein Cost-Center-Tag haben“.

Das Problem ist, dass Dokumente nichts durchsetzen. Sie beschreiben die Absicht, aber sie führen sie nicht aus. Wenn jemand eine Änderung vornimmt, die gegen eine Richtlinie verstößt, stoppt das Dokument ihn nicht. Es existiert einfach still vor sich hin und wartet darauf, dass jemand daran denkt, es zu überprüfen.

Dokumente driften auch auseinander. Jemand aktualisiert die Richtlinie, aber die alte Version bleibt in den Lesezeichen eines anderen. Oder das Team wächst, und neue Mitglieder wissen nichts von dem Dokument. Mit der Zeit wird die Lücke zwischen dem, was dokumentiert ist, und dem, was tatsächlich bereitgestellt wird, immer größer.

Was es bedeutet, Policy als Code zu schreiben

Policy as Code bedeutet, diese Regeln zu nehmen und in einem Format zu schreiben, das Maschinen lesen und ausführen können. Statt eines Dokuments, das sagt „Öffne SSH nicht für die Welt“, schreiben Sie eine Regel, die jede Infrastrukturänderung automatisch auf diese Einschränkung überprüft.

Die Richtlinie lebt in einer Datei, genau wie Ihr Anwendungscode. Sie durchläuft die Versionskontrolle. Sie wird in Pull-Requests überprüft. Sie kann getestet, aktualisiert und zurückgesetzt werden. Wenn jemand eine Änderung vorschlägt, die gegen die Richtlinie verstößt, fängt die Pipeline sie ab, bevor die Ressource erstellt wird.

Dieser Wechsel vom Dokument zum Code verändert die Art und Weise, wie Teams mit Regeln umgehen. Richtlinien werden Teil des Engineering-Workflows, nicht ein nachträglicher Gedanke, den jemand während eines Audits überprüft.

Ein konkretes Beispiel mit Open Policy Agent

Machen wir das greifbar. Open Policy Agent (OPA) ist ein beliebtes Tool zum Schreiben von Policy als Code. Es verwendet eine Sprache namens Rego. So sieht eine einfache Richtlinie aus, die SSH-Zugriff von überall blockiert:

deny if {
    input.resource.type == "aws_security_group_rule"
    "0.0.0.0/0" in input.resource.cidr_blocks
    input.resource.port == 22
}

Diese Regel besagt: Wenn jemand versucht, eine Security-Group-Regel zu erstellen, die Port 22 für alle IP-Adressen öffnet, wird sie als abgelehnt markiert. Die Richtliniendatei liegt in Ihrem Repository. Wenn ein Pull-Request eingeht, der eine Security-Group-Regel hinzufügt, führt die CI-Pipeline OPA gegen die vorgeschlagenen Änderungen aus. Wenn die Regel zutrifft, schlägt die Pipeline fehl, und der Entwickler erhält sofortiges Feedback.

Sie können auch das Gegenteil schreiben: eine Regel, die nur bestimmte CIDR-Blöcke für SSH-Zugriff erlaubt:

allow if {
    input.resource.type == "aws_security_group_rule"
    input.resource.cidr_blocks[_] != "0.0.0.0/0"
}

Die genaue Syntax hängt von Ihrem Tool und Ihrer Richtliniensprache ab, aber das Muster ist dasselbe: Regeln sind Code, und Code läuft automatisch.

Ein anderer Ansatz: Sentinel für Terraform-Benutzer

Wenn Ihr Team intensiv Terraform nutzt, bietet HashiCorps Sentinel eine engere Integration. Sentinel-Richtlinien sind speziell für den Ausführungskontext von Terraform geschrieben. Hier ist dieselbe SSH-Einschränkung in Sentinel:

import "tfplan"

allowed_cidrs = ["10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16"]

main = rule {
    all tfplan.resource_changes as _, change {
        change.type is "aws_security_group_rule" implies
        change.change.after.cidr_blocks all allowed_cidrs
    }
}

Diese Richtlinie prüft, dass jede Security-Group-Regel nur private IP-Bereiche verwendet. Wenn jemand versucht, einen öffentlichen CIDR-Block zu verwenden, blockiert die Richtlinie die Änderung.

Der Unterschied zwischen OPA und Sentinel liegt hauptsächlich im Ökosystem. OPA ist universell einsetzbar und funktioniert mit vielen Tools über Terraform hinaus. Sentinel ist tief in HashiCorp-Produkte integriert, was die Einrichtung vereinfacht, wenn Sie bereits in diesem Ökosystem sind. Aber die Kernidee ist identisch: Richtlinien sind Code, der in Ihrer Pipeline läuft.

Wo Sie Ihre Richtliniendateien speichern sollten

Sie haben zwei Hauptoptionen für die Speicherung von Richtliniendateien:

Im selben Repository wie Ihr Infrastrukturcode. Dies hält die Richtlinien in der Nähe der Ressourcen, die sie verwalten. Wenn jemand die Infrastruktur ändert, sieht er die relevanten Richtlinien im selben Pull-Request. Dies funktioniert gut für teamspezifische Richtlinien.

In einem dedizierten Policy-Repository. Dies zentralisiert alle Richtlinien organisationsweit. Ein Plattformteam pflegt das Repository, und mehrere Infrastruktur-Repos beziehen Richtlinien daraus. Dies funktioniert besser für organisationsweite Compliance-Regeln, die zwischen Teams nicht variieren sollten.

Beide Ansätze sind gültig. Beginnen Sie mit dem Ansatz des gleichen Repositorys, wenn Sie neu bei Policy as Code sind. Wechseln Sie zu einem dedizierten Repository, wenn Sie Richtlinien konsistent über mehrere Teams hinweg durchsetzen müssen.

Praktische Checkliste für den Einstieg

Bevor Sie sich ins Schreiben von Richtlinien stürzen, gehen Sie diese kurze Checkliste durch:

• Identifizieren Sie Ihre drei am häufigsten verletzten Richtlinien. Versuchen Sie nicht, alles auf einmal zu kodifizieren. Wählen Sie die Regeln, die die meisten Schmerzen oder das größte Risiko verursachen.
• Wählen Sie ein Tool. Beginnen Sie mit OPA, wenn Sie Flexibilität über verschiedene Tools hinweg wünschen. Beginnen Sie mit Sentinel, wenn Sie stark in Terraform investiert sind.
• Schreiben Sie eine Richtlinie und testen Sie sie manuell. Führen Sie sie gegen einen bekannten Verstoß aus, um zu bestätigen, dass sie das Problem erkennt.
• Fügen Sie die Richtlinienprüfung zu Ihrer CI-Pipeline hinzu. Lassen Sie sie den Build blockieren, nicht nur warnen. Warnungen werden ignoriert.
• Überprüfen und iterieren Sie. Überprüfen Sie nach einer Woche, ob die Richtlinie etwas Unerwartetes abgefangen hat. Passen Sie Fehlalarme an.

Der wahre Wert liegt im Workflow

Das von Ihnen gewählte Tool ist weniger wichtig als der Workflow, den Sie einführen. Wenn Richtlinien Code sind, erhalten sie dieselbe Behandlung wie Anwendungscode. Sie werden überprüft, getestet, versioniert und im Laufe der Zeit verbessert. Wenn eine Richtlinie einen Fehlalarm verursacht, eröffnet jemand einen Pull-Request, um sie zu korrigieren. Wenn eine neue Compliance-Anforderung eingeht, schreibt jemand eine neue Regel und liefert sie über dieselbe Pipeline aus.

Dieser Workflow beseitigt die Lücke zwischen Richtlinienabsicht und tatsächlicher Durchsetzung. Die Regel, die besagt „Kein SSH für die Welt“, ist nicht länger ein Dokument, das jemand vergessen könnte zu überprüfen. Es ist eine Codezeile, die jedes Mal ausgeführt wird, wenn sich die Infrastruktur ändert. Das ist der Unterschied zwischen der Hoffnung, dass Ihr Team die Regeln befolgt, und dem Wissen, dass sie es tun.