Ihre Terraform-State-Datei ist das mit Abstand sensibelste Artefakt in Ihrer Cloud. Sie ist eine vollständige Landkarte jeder Ressource, die Sie betreiben, und je nach Ihren Providern enthält sie zudem Geheimnisse im Klartext: Verbindungszeichenfolgen, generierte Passwörter, Schlüssel. Standardmäßig liegt diese Datei in einem Cloud-Storage-Account mit einem öffentlichen Endpunkt, abgesichert durch nicht mehr als einen Zugriffsschlüssel. Wenn dieser Schlüssel durchsickert, muss der Angreifer Ihre Infrastruktur nicht erst aufzählen. Sie haben ihm das Diagramm in die Hand gedrückt.
Wir verkaufen Authentifizierung. Ein Auth-Anbieter, der die Schlüssel zu seinem eigenen Königreich im offenen Internet liegen lässt, hat nichts damit zu tun, Ihre zu verwahren. Deshalb hat unser Produktions-State-Account überhaupt keine öffentliche Angriffsfläche. Der Weg dorthin hat drei Fallen, und wir sind in die Form jeder einzelnen hineingelaufen, bevor wir es richtig hinbekommen haben.
Falle eins: das Henne-Ei-Problem
Remote-State braucht ein Backend, das bereits existiert, bevor Terraform laufen kann. Aber das Backend ist selbst Infrastruktur, und idealerweise soll Terraform sie verwalten. Sie können den Storage-Account nicht nutzen, um den State des Storage-Accounts zu speichern, den es noch gar nicht gibt.
Der Ausweg ist ein bewusstes zweiphasiges Bootstrapping. Phase eins läuft mit lokalem State und erzeugt genau das Fundament: den State-Storage-Account, das Netzwerk, in dem er liegen wird, und den Zugriffspfad. Phase zwei kippt den Backend-Block von lokal auf remote und migriert die nun existierende State-Datei hinauf in den Account, den sie gerade erstellt hat. Ab diesem Punkt verwaltet sich diese Bootstrap-Schicht selbst aus der Ferne, wie alles andere auch. Es sind ein paar Minuten, in denen man sich fühlt, als stünde man auf einer Leiter, die man noch baut, und dann ist es für immer erledigt.
Falle zwei: das Erreichbarkeitsproblem und die VPN-Gateway-Steuer
Den Account privat zu machen ist eine einzige Zeile: öffentlichen Netzwerkzugriff abschalten und einen privaten Endpunkt davorsetzen. Jetzt ist der Storage-Account nur noch von innerhalb Ihres virtuellen Netzwerks erreichbar. Was genau das Problem ist, denn das, was ihn am häufigsten erreichen muss, Ihre CI-Pipeline, ist nicht innerhalb Ihres virtuellen Netzwerks. Sie selbst auch nicht.
Die Lehrbuchantwort ist, ein VPN beim Provider aufzubauen. Ein verwaltetes VPN-Gateway, oder einen Bastion-Host, oder Point-to-Site mit Client-Zertifikaten. Jeder, der das schon gemacht hat, kennt die Steuer: Das Gateway ist teuer und langsam bereitzustellen, Point-to-Site bedeutet, Client-Zertifikate auszustellen und zu rotieren, jeder neue Operator ist ein Einrichtungsritual, und ein Bastion ist eine weitere Box zum Patchen und Bezahlen. Es ist eine Menge dauerhaft laufender Infrastruktur, deren einzige Aufgabe es ist, vertrauenswürdige Leute eine private Sache erreichen zu lassen.
Wir haben das alles übersprungen. Statt eines VPN-Gateways läuft ein kleiner Zero-Trust-Connector als Container innerhalb des VNet, die Kategorie, die Tailscale, Twingate und Cloudflare Access besetzen. Er tritt einem identitätsbewussten Mesh bei. Autorisierte Personen und die CI-Pipeline erreichen den privaten Endpunkt durch dieses Mesh, pro Identität authentifiziert, mit Zugriff, der auf genau die eine Ressource beschränkt ist, die ihn braucht. Kein Gateway, keine öffentliche IP, keine zu rotierenden Zertifikate, kein Jump-Host. CI bringt seine Verbindung für die Dauer eines Laufs hoch und reißt sie danach wieder ab. Das Erreichbarkeitsproblem verschwindet, ohne die Rechnung für dauerhaft laufende Infrastruktur.
Falle drei: die Abriegelung, die man nicht in einem Schritt machen kann
Der naheliegende Instinkt ist, den Account von Anfang an als privat zu deklarieren, im selben Terraform-Apply, das ihn erstellt. Tun Sie das, dann kappen Sie die Leitung, bevor der private Pfad existiert: Das Apply muss den State über den öffentlichen Endpunkt schreiben, der private Endpunkt und DNS sind noch nicht verdrahtet, und Sie sperren Terraform, und sich selbst, aus genau dem Account aus, den Sie gerade erstellen. Wir haben das durchdacht, bevor wir es ausgelöst haben, und das ist der eine Moment, in dem der Probelauf im Kopf stattfindet statt im Terminal.
Die Abriegelung ist also ein bewusster separater Schritt, der erst ausgeführt wird, nachdem das Netzwerk, der private Endpunkt und der Connector alle laufen und erprobt sind. Ein einziger Befehl schaltet den öffentlichen Netzwerkzugriff auf deaktiviert. In dem Moment, in dem er greift, ist der öffentliche Endpunkt weg, die alte IP-Allowlist wird irrelevant, weil keine öffentliche Angriffsfläche mehr übrig ist, auf die man irgendetwas zulassen könnte, und jeder zukünftige Lauf erreicht den State über das Mesh. Wir haben es auf die einzige Art verifiziert, die zählt: indem wir geprüft haben, dass der Account jetzt über den privaten Pfad antwortet und den öffentlichen verweigert.
Die andere Hälfte: kein Passwort zum Stehlen
Das Töten des öffentlichen Endpunkts entfernt die Netzwerktür. Der passende Zug ist, sicherzustellen, dass auch kein dauerhafter Schlüssel dahinter liegt. Unsere Pipeline hält keine Cloud-Credentials. Sie authentifiziert sich mit Workload Identity Federation: Das CI-System legt ein kurzlebiges OIDC-Token vor, die Cloud vertraut diesem Token für genau ein bestimmtes Repository und gibt Zugriff zurück, der in Minuten abläuft. Es gibt kein Service-Principal-Secret, das in einem Vault auf das Durchsickern wartet, weil es von vornherein gar kein Secret gibt.
Der State-Zugriff folgt derselben Regel. Terraform liest und schreibt das State-Blob mit einem kurzlebigen Verzeichnis-Token, das an diese Identität gebunden ist, nicht mit dem Zugriffsschlüssel des Storage-Accounts. So kommen die beiden Dinge, die ein Angreifer am meisten will, ein Weg hinein und eine Credential, um ihn zu nutzen, als ein rein privater Endpunkt und ein Token heraus, das bereits ablief, während er es las. Nichts Statisches zum Mitnehmen.
Warum der Aufwand
State-Dateien sickern für gewöhnlich nicht durch, weil jemand die Verschlüsselung gebrochen hat. Sie sickern durch, weil der Account öffentlich war, ein Schlüssel in einem Log oder einem Fork oder auf einem Laptop landete und sonst nichts mehr im Weg stand. Den öffentlichen Endpunkt zu entfernen löscht die gesamte Klasse von "der Schlüssel ist durchgesickert" aus dem Bedrohungsmodell. Der Schlüssel wird nutzlos, wenn man nicht auch im Mesh ist.
Es ist dasselbe Prinzip, auf dem wir das Produkt aufbauen: Sicherheit nicht hinter Aufwand oder Tarifstufe verstecken, sondern einfach machen, weil die Alternative das ist, was man um zwei Uhr nachts bereut. Jedes Sicherheitsfeature, das wir an Kunden ausliefern, SSO und SAML, SCIM, MFA, erzwungene Webhooks, Audit-Export, ist in jedem Tarif aktiv, nicht für einen Enterprise-Upsell zurückgehalten. Sehen Sie, was enthalten ist.
Top comments (0)