Wenn Sicherheitsregeln in Dokumenten leben, werden sie ignoriert

Ein Sicherheitsteam erstellt wochenlang eine Richtlinie zum Scannen von Container-Images. Sie verschicken sie per E-Mail, kündigen sie im All-Hands-Meeting an und speichern sie im Firmen-Wiki. Drei Monate später stellt jemand fest, dass der Scan in der Produktions-Pipeline nie aktiviert wurde. Die Konfiguration fehlte in einem Projekt, und niemand hat es bemerkt.

Dies ist keine Geschichte über böse Absichten. Es ist eine Geschichte darüber, wie Regeln brechen, wenn sie außerhalb der Pipeline leben.

Das Problem mit Regeln als Dokumente

Geschriebene Richtlinien haben eine grundlegende Schwäche: Sie sind darauf angewiesen, dass Menschen sie lesen, behalten und korrekt anwenden. Jedes Team interpretiert dieselbe Regel anders. Jedes Projekt hat seine eigenen Konfigurationsbesonderheiten. Wenn sich eine Regel ändert, muss jemand jede Stelle, an der sie gilt, manuell aktualisieren, und jemand anderes muss überprüfen, ob die Aktualisierung tatsächlich stattgefunden hat.

Das Ergebnis ist vorhersehbar. Einige Teams befolgen die Regeln. Einige Teams befolgen eine leicht abweichende Version. Einige Teams vergessen es ganz. Und niemand weiß, welche Situation gerade eintritt, bis etwas schiefgeht.

Der Unterschied zwischen diesen beiden Ansätzen wird deutlich, wenn man den Ablauf visualisiert:

Dies ist kein Menschenproblem. Es ist ein Auslieferungsproblem. Die Regeln sind nicht Teil des Systems, das Software ausliefert. Sie existieren außerhalb davon, als Text, der erst durch menschliches Handeln in die Tat umgesetzt werden muss.

Regeln als Code schreiben

Policy as Code verändert das Auslieferungsmodell für Regeln. Anstatt Richtlinien in Dokumenten zu schreiben, schreibt man sie in einem Format, das Maschinen lesen können, speichert sie in einem Repository und führt sie als Teil der Pipeline aus. Derselbe Workflow, der Anwendungscode behandelt, verwaltet jetzt Ihre Sicherheits- und Compliance-Regeln.

Das Format variiert. Manche Teams verwenden Rego von Open Policy Agent. Manche verwenden YAML mit einem definierten Schema. Manche verwenden die integrierten Policy-Frameworks ihrer vorhandenen Scanning-Tools. Die Sprache ist weniger wichtig als das Prinzip: Regeln werden geschrieben, versioniert, geprüft und automatisch ausgeführt.

Betrachten Sie eine einfache Regel: Container dürfen nicht als Root laufen. In Policy as Code wird daraus eine klare Anweisung, die eine Policy-Engine auswerten kann. Die Pipeline führt die Engine vor dem Deployment gegen jedes Container-Image aus. Wenn das Image als Root läuft, stoppt die Pipeline. Wenn die Regel geändert werden muss, bearbeitet jemand die Policy-Datei, erstellt einen Pull-Request und wartet auf die Überprüfung. Die Änderung durchläuft denselben Prozess wie jede Code-Änderung.

Was sich ändert, wenn Regeln zu Code werden

Der erste Vorteil ist Konsistenz. Dieselbe Regel wird gegen jedes Projekt, jede Pipeline, jedes Deployment ausgeführt. Es gibt keine Lücke, weil jemand vergessen hat, einen Scan zu aktivieren, oder weil zwei Teams dasselbe Tool unterschiedlich konfiguriert haben. Wenn eine neue Regel hinzugefügt wird, übernehmen alle Pipelines sie automatisch.

Der zweite Vorteil ist Testbarkeit. Wie wussten Sie vor Policy as Code, ob eine neue Regel korrekt war? Sie haben sie vielleicht in einer Produktions-Pipeline getestet, was riskant ist. Oder Sie haben das Testen ganz übersprungen und auf das Beste gehofft. Mit Policy as Code schreiben Sie Tests für Ihre Regeln. Sie erstellen einen Testfall, bei dem ein Container mit Root-Benutzer die Policy nicht besteht, und einen weiteren, bei dem ein Nicht-Root-Container sie besteht. Diese Tests laufen in CI, genau wie Unit-Tests. Wenn jemand die Regel ändert und die Logik bricht, fangen die Tests es ab, bevor die Regel die Produktion erreicht.

Der dritte Vorteil ist Prüfbarkeit. Jede Regeländerung wird in der Versionskontrolle aufgezeichnet. Sie können sehen, wer was wann und warum geändert hat. Sie können eine fehlerhafte Regeländerung genauso rückgängig machen wie eine fehlerhafte Code-Änderung. Wenn ein Prüfer fragt, ob Ihre Container als Root laufen, zeigen Sie auf die Policy-Datei und die Pipeline-Logs, nicht auf ein Dokument, das möglicherweise veraltet ist.

Sie müssen nicht alles von Grund auf neu schreiben

Ein häufiges Missverständnis ist, dass Policy as Code bedeutet, jede Regel selbst zu schreiben. In der Praxis stammen die meisten Regeln aus vorhandenen Frameworks. Sicherheitstools liefern Richtlinien für CIS-Benchmarks, regulatorische Frameworks und gängige Sicherheitsmuster. Sie aktivieren diejenigen, die für Ihre Organisation relevant sind, und passen die Schwellenwerte an Ihre Risikotoleranz an.

Was Sie von Grund auf neu schreiben, ist normalerweise spezifisch für Ihre Organisation. Vielleicht verbietet Ihr Unternehmen die Bereitstellung in bestimmten Cloud-Regionen. Vielleicht muss jede Ressource einen bestimmten Satz von Labels haben. Vielleicht erfordern Produktions-Deployments eine zweite Signatur. Dies sind die Regeln, die vorhandene Frameworks nicht abdecken, und diese profitieren am meisten davon, als Code geschrieben zu werden.

Der praktische Wandel

Policy as Code verändert die Beziehung zwischen Sicherheitsteams und Entwicklungsteams. Die Sicherheitsabteilung schickt keine Regeln mehr über die Mauer und hofft, dass sie umgesetzt werden. Die Sicherheitsabteilung schreibt Regeln als Code, reicht sie durch denselben Überprüfungsprozess wie Anwendungscode ein und sieht die Ergebnisse in jedem Pipeline-Lauf.

Entwicklungsteams müssen nicht mehr raten, ob sie die Regeln einhalten. Die Pipeline sagt es ihnen sofort. Wenn eine Änderung gegen eine Policy verstößt, schlägt der Build mit einer klaren Nachricht fehl. Das Team behebt das Problem, bevor es in die Produktion gelangt, und nicht erst, nachdem eine Prüfung es sechs Monate später entdeckt.

Eine kurze Checkliste für den Einstieg

• Wählen Sie eine Regel aus, die derzeit dokumentiert, aber häufig verletzt wird.
• Schreiben Sie diese Regel als Code mit dem Policy-Framework Ihres vorhandenen Sicherheitstools.
• Fügen Sie die Policy-Prüfung zu Ihrer CI-Pipeline hinzu.
• Schreiben Sie einen Test, der beweist, dass die Regel Verstöße erkennt.
• Schreiben Sie einen weiteren Test, der beweist, dass die Regel konforme Änderungen zulässt.
• Entfernen Sie das alte Dokument und verweisen Sie die Leute stattdessen auf die Policy-Datei.

Beginnen Sie mit einer Regel. Beweisen Sie, dass der Workflow funktioniert. Dann erweitern Sie ihn.

Das Fazit

Regeln, die in Dokumenten leben, sind Regeln, die ignoriert werden. Regeln, die in der Pipeline leben, sind Regeln, die durchgesetzt werden. Bei Policy as Code geht es nicht darum, mehr Regeln zu schreiben. Es geht darum, die Regeln, die Sie bereits haben, tatsächlich zum Funktionieren zu bringen – jedes Mal, bei jeder Änderung, ohne dass jemand daran denken muss, eine E-Mail zu lesen.