Guardrails statt Schranken

Wer ist dieser Hersteller?

Trotz seines Images als traditioneller Industriekonzern betreibt dieser Hersteller eine bemerkenswert moderne Entwicklungsorganisation. Tausende unabhängige Teams bauen und deployen ihre eigenen Anwendungen, von Bestellsystemen in der Lieferkette über die Zeiterfassung bis zu Produkt-APIs für Kunden. Jedes Team verantwortet seine eigene Infrastruktur, ausgerollt in Tausende separate Cloud-Projekte, und liefert mit hoher Geschwindigkeit, ohne schwergewichtige Change-Control-Boards und ohne aufwendige Sicherheitsprüfungen.

Diese Autonomie ist eine bewusste Entscheidung, und sie funktioniert. Sie hat aber ein wachsendes Problem geschaffen: Wenn jedes Team entscheiden kann, wie seine Infrastruktur aussieht, entscheidet es eben auch, wie sicher oder unsicher sie ist.

Woran sind die internen Standards gescheitert?

Das Unternehmen hatte interne Standards festgehalten. Eine Produktionsdatenbank braucht Replikation und Backups, eine Entwicklungsinstanz nicht. Service-Accounts sollen keine Cloud-Defaults mit überzogenen Rechten nutzen, und Instanzen sollen für ihre Umgebung richtig dimensioniert sein. Das Team nennt das „Compliance mit kleinem c“: kein externes Framework wie SOC 2 oder ISO 27001, sondern die eigene Definition des Unternehmens, wie seine Infrastruktur auszusehen hat. Wie die meisten internen Standarddokumente hat auch sie kaum jemand gelesen, und durchgesetzt hat sie niemand.

Die Folgen waren real und teuer. Ausfälle: Eine einzige Fehlkonfiguration hat einmal ein kritisches Bestellsystem lahmgelegt, das die Geschäftspartner des Unternehmens nutzen. Die Bestellungen sind ausgefallen, damit auch die nachgelagerten Abläufe bei den Partnern, und die sind auf andere Lieferanten ausgewichen. Umsatz, der schlicht verloren war. In Produktionsanlagen kostet Stillstand Millionen Dollar.

Verschwendung: Entwicklungsumgebungen mit Replikation auf Produktionsniveau, überdimensionierte Instanzen und terabyteweise unnötig vorgehaltene Daten haben sich zu erheblichen, vermeidbaren Cloud-Kosten summiert. Risiko: Teams haben Standard-Service-Accounts weiterverwendet, die faktisch Root-Rechte hatten. Ein bekanntes Anti-Pattern: Das Cloud-Team hat vermutet, dass es weit verbreitet ist, konnte es aber weder finden noch belegen.

Warum ist das vorherige Tool gescheitert?

Das Unternehmen hatte Policy-Scanning schon einmal versucht, mit einem verbreiteten Open-Source-Checker für Infrastructure as Code. Er ist im gesamten Konzern gelaufen und hat fast nichts erreicht. Dafür gibt es zwei Gründe.

Erstens konnte er unternehmensspezifische Richtlinien gar nicht abbilden. Seine eingebauten Regeln haben branchenübliche Best Practices abgebildet, durchgesetzt werden mussten aber die eigenen: der Datenbankstandard dieses Unternehmens, kein Standard zum Abhaken.

Zweitens hat er nie etwas blockiert. Die Befunde sind in Tausenden Seiten Build-Logs untergegangen, während die Pipelines grün geblieben sind. Entwickler haben nie ein Problem gesehen, also hat sich nichts geändert.

Wie setzt Mondoo Policy as Code durch?

Das Unternehmen hat Mondoo in jede CI-Pipeline ausgerollt. Jede Softwareänderung im Konzern läuft jetzt durch Mondoo. Die Plattform scannt den Terraform-Code, aus dem die Infrastruktur entsteht, integriert in den bestehenden Workflow, und fängt Fehlkonfigurationen ab, bevor sie überhaupt in die Produktion gelangen. Entscheidend dabei: Die Policies und ihre Controls stecken als nachvollziehbarer Code in der Plattform. Es gibt also keine Mapping-Tabellen zu bauen und keine Herleitungen von Hand zu dokumentieren.

Die Fachteams schreiben ihre Policies selbst. Das Datenbankteam, der erste große Anwender, hat rund ein Dutzend Policy Packs geschrieben, die jede im Unternehmen eingesetzte Datenbanktechnologie abdecken: etwa 20 Checks für PostgreSQL, ein ähnliches Set für BigQuery und so weiter. Die Policies greifen kontextabhängig: Wenn ein Pull Request eine Postgres-Datenbank hochzieht, läuft die Postgres-Policy genau gegen diesen Code.

Was passiert bei einem Richtlinienverstoß?

Wenn ein Entwickler in Indien einen Pull Request öffnet, der gegen eine Richtlinie verstößt, wird die Pipeline sofort rot, auch wenn das Plattform-Team in den USA gerade schläft. In GitHub, im gewohnten Workflow. Kein Scanner-Portal, das man erst lernen muss, kein Ticket, kein Security-Team dazwischen. Er liest den Befund, korrigiert das Terraform, pusht einen Commit, und die Pipeline wird grün. Damit ist er aus eigener Kraft wieder innerhalb der Guardrails, in seiner eigenen Zeitzone und fast ohne Tempoverlust.

Wie werden Ausnahmen behandelt?

In einem Konzern dieser Größe hat jede Regel berechtigte Ausnahmen. Vielleicht 20 von Tausenden Projekten brauchen Replikation tatsächlich schon in der Entwicklung. Der frühere selbstgebaute Ausnahmeprozess war ein verworrenes Geflecht interner Web-Apps. Mit Mondoo beantragen Entwickler Ausnahmen direkt in der Anwendung, und die Anfragen landen automatisch beim zuständigen Fachteam: Datenbank-Ausnahmen beim Datenbankteam, Cloud-Plattform-Ausnahmen beim Cloud-Team. Das antragstellende Team genehmigt seine Ausnahme nie selbst, und bei jeder Entscheidung entsteht ein prüfbarer Nachweis. Nach der Freigabe läuft die Pipeline erneut und wird grün.

Wie bauen sich Altlasten von selbst ab?

Hier wird nicht auf der grünen Wiese gebaut, sondern im Bestand, und der ist über Jahrzehnte gewachsen. Das Ziel war nicht nur, neue Verstöße zu verhindern, sondern die angewachsenen Konfigurations-Altlasten Stück für Stück abzutragen. Die Durchsetzung in der CI erledigt das automatisch: Sobald jemand ein schlafendes Repository anfasst, und sei es nur für einen Tippfehler in der README-Datei, meldet Mondoo jeden bestehenden Verstoß in diesem Projekt, bevor die Änderung gemergt werden kann. Die Probleme lösen sich mit der Zeit von selbst, ohne dass jemand ein Remediation-Backlog zuweisen muss.

Wie integriert sich Mondoo im Konzernmaßstab?

Die Anforderungen an die Integration waren extrem. Das Active Directory des Unternehmens enthält Millionen von Identitäten, praktisch jeden, der jemals in irgendeiner Rolle mit dem Konzern zu tun hatte. Neue Mitarbeiter gehören vom ersten Tag an Hunderten Gruppen an. Dafür sind Standard-Identitätsprotokolle schlicht nicht ausgelegt. Die rollenbasierte Zugriffskontrolle musste dicht sein: In einem Unternehmen, in dem Sicherheitsdaten Rückschlüsse auf ein noch unangekündigtes Produktvorhaben zulassen, darf jeder nur das sehen, wofür er verantwortlich ist.

Der gesamte Mondoo-Rollout wird zu 100 % über Terraform verwaltet, ohne einen einzigen Klick. Das schließt Identitätsintegration, Organisationsstruktur und Workspace-Aufbau ein. Die Struktur bildet beides ab: konzernweite Vorgaben von oben und kontrollierte Autonomie der Geschäftsbereiche. Die Finanzsparte, die fast wie ein eigenes Unternehmen arbeitet, kann eigene, strengere Anforderungen auf die Konzern-Baseline aufsetzen, sie aber nie außer Kraft setzen. Die vollständige Konzernintegration hat weniger als ein Jahr gedauert.

“Mondoo ist der schnellste Anbieter, mit dem wir je gearbeitet haben. Der einzige, der wirklich mit all unseren Systemen integriert ist. Wir haben es mit Riesen zu tun, die uns gesagt haben, dass sie das seit Jahren nicht hinbekommen.”

Technologieverantwortlicher, Cloud-Infrastruktur-Team

Welche Ergebnisse hat der Hersteller erzielt?

Die Durchsetzung ist erst seit Kurzem scharfgeschaltet, und die ersten Zahlen zeigen, dass das Modell funktioniert. Rund um die Uhr wird etwa alle 30 Sekunden ein Softwareprojekt auf Compliance geprüft. Rund 31.000 Scans haben Verstöße gemeldet, die unter dem alten Tooling unbemerkt in Produktion gegangen wären. Die Zahl der offenen Befunde bleibt stabil, während immer mehr Befunde behoben werden, und das, obwohl laufend weitere Policies dazukommen. Dass diese beiden Kurven auseinanderlaufen, ist genau das Kennzeichen wirksamer Guardrails: Neue Verstöße werden an der Quelle verhindert, und die Altlasten werden Stück für Stück abgearbeitet.

Genauso wichtig: Das Unternehmen hat sich bewahrt, was ihm am meisten wert ist. Die Teams liefern weiterhin mit hoher Geschwindigkeit, entscheiden weiterhin selbst über ihren Weg, und sie müssen sich nach wie vor keinem Change-Control-Board stellen. Die Guardrails haben Bürokratie ersetzt, nicht Autonomie.