Dein Blog zum Thema digitales Business

In vielen Pipelines gibt es genau einen Satz Zugangsdaten. Ein Deploy-Key, ein Cloud-Account, ein Datenbank-Passwort. Damit läuft der Build nach Staging, und damit läuft er nach Produktion. Das ist bequem, spart Einrichtung und funktioniert jahrelang problemlos. Bis zu dem Tag, an dem jemand Zugriff auf Staging bekommt und feststellt, dass Staging der Generalschlüssel für alles ist.

Staging ist nicht weniger wichtig, es ist weniger geschützt

Der Denkfehler steckt in der Bewertung. Produktion gilt als schützenswert, Staging als Spielwiese. Genau deshalb ist Staging in der Praxis lockerer: mehr Leute haben Zugriff, Test-Tools laufen mit, Debug-Ausgaben sind an, Logs werden nicht so genau angeschaut, ein Feature-Branch darf dorthin deployen. Wenn beide Umgebungen dieselben Credentials benutzen, dann gilt für Produktion faktisch das Schutzniveau von Staging. Der Angreifer sucht sich die schwächere Tür aus, nicht die wichtigere.

Das ist der eigentliche Punkt bei der Trennung von Umgebungen. Es geht nicht darum, ob Staging sensibel ist. Es geht darum, wie weit ein Zugriff reicht, den man dort bekommt.

Was geteilte Credentials praktisch bedeuten

Ein paar typische Wege, wie aus einem Staging-Zugriff ein Produktionsvorfall wird:

• Ein Pull Request aus einem Fork löst einen Workflow aus, der die Deploy-Secrets sieht. Der Code im PR schreibt sie ins Log oder schickt sie weg.
• Ein Entwickler, der nur für Staging gedacht war, holt sich das Secret aus der Pipeline-Konfiguration und deployt versehentlich nach Prod.
• Ein Test-Skript in Staging räumt Daten auf. Es zeigt aber auf denselben Storage-Bucket, weil die Credentials keinen Umgebungs-Scope haben.
• Ein kompromittiertes Test-Dependency in Staging bekommt Zugriff auf einen Cloud-Token, der in Produktion volle Rechte hat.

In keinem dieser Fälle ist Produktion selbst angegriffen worden. Die Rechte sind einfach mitgelaufen.

Trennung heißt drei Dinge, nicht eins

Getrennte Umgebungen sind mehr als zwei URLs. Damit die Trennung trägt, braucht sie drei Ebenen. Erstens getrennte Identitäten: Staging und Produktion deployen mit verschiedenen Service-Accounts, nicht mit demselben unter anderem Namen. Zweitens getrennte Rechte: der Staging-Account darf ausschließlich Staging-Ressourcen anfassen, technisch erzwungen über Policies oder Rollen, nicht über eine Konvention in der README. Drittens getrennte Freigaben: der Weg nach Produktion braucht einen anderen Auslöser als der Weg nach Staging.

Die dritte Ebene wird am häufigsten vergessen. Wenn jeder Merge automatisch bis in die Produktion durchläuft, existiert die Trennung nur auf dem Papier.

GitHub Environments als konkreter Hebel

Wer auf GitHub Actions arbeitet, hat dafür ein fertiges Werkzeug. Environments sind benannte Ziele mit eigenen Secrets und eigenen Schutzregeln. Ein Job, der environment: production deklariert, sieht die Production-Secrets. Ein Job ohne diese Deklaration sieht sie nicht, auch nicht aus demselben Repository heraus. Dazu kommen Regeln pro Umgebung: welche Branches überhaupt deployen dürfen, ob eine manuelle Freigabe nötig ist, ob eine Wartezeit davor liegt.

Das löst zwei Probleme gleichzeitig. Die Secrets sind an das Ziel gebunden statt an das Repository, und die Freigabe hängt an derselben Stelle. Wer bisher alles in Repository-Secrets hatte, hat hier den kürzesten Weg zu einer echten Trennung.

Der zweite Hebel ist die Lebensdauer. Umgebungs-Trennung begrenzt, wie weit ein Zugang reicht. Rotation begrenzt, wie lange er gilt. Beides gehört zusammen, wir haben den zweiten Teil in Pipeline-Secrets rotieren beschrieben.

Wie man den Zustand prüft

Die Frage ist nicht, ob es getrennte Umgebungen gibt. Die Frage ist, ob ein Zugang aus der einen in der anderen etwas bewirkt. Drei Prüfungen, die das schnell zeigen: Nimm die Zugangsdaten, mit denen Staging deployt, und versuche damit eine Leseoperation auf einer Produktionsressource. Wenn sie durchgeht, ist die Trennung nicht vorhanden. Schau nach, wie viele Workflows im Repository ohne Environment-Deklaration auf Secrets zugreifen. Und prüfe, welche Branches nach Produktion deployen dürfen, nicht welche es laut Absprache sollen.

Wenn diese drei Punkte sauber sind, ist der Rest meistens Aufräumarbeit. Wenn nicht, ist die Trennung eine Namenskonvention.

---

GitSecOps QuickCheck: Wir sehen uns Ihre Pipeline an und sagen konkret, welche Zugänge über Umgebungsgrenzen hinweg wirken, wo Secrets ohne Scope liegen und was zuerst zu ändern ist. 1.990 Euro netto, Ergebnis in 3 Werktagen. Kontakt: mm@crank.zone