Wem gehört die Produktion? Warum Berechtigungsgrenzen zwischen Umgebungen wichtig sind

Ein Entwickler in Ihrem Team nimmt eine kleine Änderung an einer Konfigurationsdatei vor. Er wollte die Staging-Umgebung aktualisieren, aber versehentlich hat er den Befehl gegen die Produktion ausgeführt. Fünf Minuten später melden Benutzer Fehler. Das Team versucht hektisch herauszufinden, was passiert ist, wer die Änderung vorgenommen hat und wie man sie rückgängig machen kann. Der Entwickler, der das Problem verursacht hat, ist sich unterdessen nicht einmal sicher, ob er überhaupt die Berechtigung hatte, die Produktion zu berühren.

Dieses Szenario spielt sich häufiger ab, als die meisten Teams zugeben wollen. Es geht nicht um böse Absichten oder inkompetente Ingenieure. Es geht um eine fehlende Grenze zwischen Umgebungen. Wenn jeder den gleichen Zugriff auf Entwicklung, Staging und Produktion hat, kann das System nicht zwischen beabsichtigten Änderungen und Fehlern unterscheiden.

Das Problem mit universellem Zugriff

Viele Teams beginnen mit einem einfachen Setup: Jeder bekommt Zugriff auf alles. Entwickler können Staging, Produktion oder sogar die Entwicklungsumgebung eines anderen Teams modifizieren. Das fühlt sich zunächst praktisch an. Niemand muss auf Berechtigungen warten. Niemand muss um Hilfe bitten, um einen Fix bereitzustellen.

Aber dieser Ansatz schafft zwei Probleme. Erstens wird die Verantwortlichkeit verschwommen. Wenn etwas in der Produktion kaputt geht und jeder Zugriff hatte, dauert es länger, die Ursache zu finden. Man muss überprüfen, wer welchen Befehl von welchem Rechner zu welcher Zeit ausgeführt hat. Zweitens wächst der Schadensradius eines Fehlers. Ein Entwickler, der an einem Feature-Branch arbeitet, kann versehentlich einen Produktions-Deployment auslösen. Ein Tippfehler in einer Konfigurationsdatei kann einen Dienst lahmlegen, von dem Hunderte von Benutzern abhängen.

Die Lösung ist nicht, alles so stark einzuschränken, dass niemand mehr arbeiten kann. Die Lösung ist, klare Berechtigungsgrenzen zwischen Umgebungen zu schaffen.

Was ist eine Berechtigungsgrenze?

Eine Berechtigungsgrenze ist eine klare Trennung, wer in jeder Umgebung was tun darf. Es geht nicht nur um Berechtigungen in einem Tool. Es geht darum, wie Sie Ihr State-Backend, Ihr Repository und Ihre Pipeline-Konfiguration strukturieren.

Zum Beispiel sollte die State-Datei für die Produktion an einem anderen Ort liegen als die State-Datei für die Entwicklung. Wenn Sie Terraform verwenden, könnte das Produktions-State-Backend ein separater S3-Bucket mit strengeren IAM-Richtlinien sein. Nur wenige Personen im Team haben Zugriff auf diesen Bucket. Das Entwicklungs-State-Backend könnte sich in einem gemeinsamen Bucket befinden, den jedes Teammitglied lesen und beschreiben kann.

Das Prinzip hier ist das der geringsten Privilegien. Jede Person oder jedes System erhält nur den Zugriff, den sie für ihre Arbeit benötigen. Ein Entwickler benötigt möglicherweise vollen Zugriff auf die Entwicklungsumgebung. Er benötigt möglicherweise schreibgeschützten Zugriff auf den Produktions-State, um zu verstehen, was läuft. Aber wenn er eine Änderung in der Produktion vornehmen muss, sollte diese Änderung einen formelleren Prozess durchlaufen: einen Pull-Request, der von einem anderen Teammitglied überprüft wird, oder eine Pipeline, die eine Genehmigung erfordert.

Eigentum macht Grenzen konkret

Berechtigungsgrenzen funktionieren am besten, wenn jede Umgebung einen klaren Eigentümer hat. Der Eigentümer ist die Person oder das Team, das verantwortlich ist, wenn in dieser Umgebung etwas schief geht. Eigentum geht es nicht um Kontrolle. Es geht um Verantwortlichkeit.

In der Praxis sieht Eigentum oft so aus:

  • Das Platform-Engineering-Team besitzt die Produktion. Es ist für deren Stabilität, Leistung und Sicherheit verantwortlich.
  • Das Anwendungsentwicklungsteam besitzt das Staging. Es verwendet es, um seine Änderungen zu validieren, bevor es eine Produktionsbereitstellung anfordert.
  • Einzelne Entwickler besitzen ihre persönlichen Entwicklungsumgebungen. Sie können sie kaputt machen, neu aufbauen und frei experimentieren.

Diese Aufteilung bedeutet nicht, dass Entwickler die Produktion nicht anfassen dürfen. Es bedeutet, dass sie, wenn sie es tun, einem Prozess folgen, der den Produktionseigentümer einbezieht. Der Eigentümer überprüft die Änderung, versteht das Risiko und genehmigt oder lehnt die Bereitstellung ab.

So implementieren Sie Berechtigungsgrenzen in der Praxis

Berechtigungsgrenzen zeigen sich an drei Stellen: Ihrer Repository-Struktur, Ihrer Pipeline-Konfiguration und Ihrem State-Backend.

Repository-Struktur

Der einfachste Weg, Grenzen durchzusetzen, ist die Verzeichnisstruktur und Branch-Schutz. Produktionskonfigurationen können in einem separaten Verzeichnis oder sogar einem separaten Repository leben. Wenn sie sich im selben Repository befinden, sollte das Produktionsverzeichnis geschützt sein. Nur bestimmte Teammitglieder können Änderungen daran pushen. Pull-Requests, die Produktionskonfigurationen ändern, erfordern die Genehmigung des Produktionseigentümers.

Das folgende Flussdiagramm zeigt, wie ein Änderungsantrag basierend darauf, wer die Änderung vornimmt und welche Umgebung betroffen ist, durch Berechtigungsgrenzen fließt.

flowchart TD A[Änderungsantrag] --> B{Wer nimmt die Änderung vor?} B -->|Entwickler| C{Zielumgebung?} B -->|Ops/Admin| D{Zielumgebung?} C -->|Dev/Staging| E[PR erstellen] C -->|Produktion| F[Blockiert - an Eigentümer eskalieren] D -->|Dev/Staging| G[PR erstellen] D -->|Produktion| H[PR mit Eigentümer-Review erstellen] E --> I[Plan-Schritt] G --> I H --> J[Plan-Schritt + Eigentümer-Genehmigung] I --> K[Auf Dev/Staging anwenden] J --> L[Auf Produktion anwenden]

Pipeline-Konfiguration

Ihre CI/CD-Pipeline ist der Ort, an dem Grenzen operativ werden. Die Pipeline für die Produktion sollte nur laufen, wenn bestimmte Bedingungen erfüllt sind. Beispielsweise könnte sie nur von einem geschützten Branch aus ausgelöst werden. Sie könnte eine manuelle Genehmigung durch eine bestimmte Person erfordern. Sie könnte zusätzliche Validierungsschritte ausführen, die die Entwicklungspipeline überspringt.

Einige Teams gehen noch weiter. Sie konfigurieren die Produktionspipeline so, dass sie nur von einem bestimmten CI/CD-Runner aus läuft, der Zugriff auf das Produktions-State-Backend hat. Entwickler können die Produktionspipeline nicht von ihren Laptops aus ausführen, da ihre lokalen Maschinen nicht über die erforderlichen Anmeldeinformationen verfügen.

State-Backend

Das State-Backend ist der Ort, an dem Infrastructure-as-Code-Tools den aktuellen Zustand Ihrer Umgebungen speichern. Wenn Sie Terraform verwenden, sollte die State-Datei für die Produktion in einem separaten Backend mit strengen Zugriffskontrollen liegen. Die IAM-Richtlinie für dieses Backend sollte nur Operationen von der Produktionspipeline zulassen, nicht von einzelnen Entwicklerkonten.

Sie können das Produktions-State-Backend beispielsweise mit einer Richtlinie konfigurieren, die besagt: „Nur das CI/CD-Dienstkonto kann in diese State-Datei schreiben. Alle anderen können sie nur lesen.“ Auf diese Weise schlägt der Befehl fehl, selbst wenn ein Entwickler versehentlich einen Terraform-Befehl gegen die Produktion ausführt, da er keine State-Sperre erwerben kann.

Hier ist eine Terraform-IAM-Richtlinie, die diese Grenze durchsetzt, indem sie Schreibzugriff nur auf Dev-State-Dateien erlaubt, während Schreibzugriff auf Prod-State-Dateien verweigert wird:

data "aws_iam_policy_document" "state_access" {
  statement {
    sid    = "AllowDevWrite"
    effect = "Allow"
    actions = [
      "s3:PutObject",
      "s3:GetObject",
      "s3:DeleteObject"
    ]
    resources = [
      "arn:aws:s3:::my-tf-state-bucket/env:/dev/*"
    ]
  }

  statement {
    sid    = "DenyProdWrite"
    effect = "Deny"
    actions = [
      "s3:PutObject",
      "s3:DeleteObject"
    ]
    resources = [
      "arn:aws:s3:::my-tf-state-bucket/env:/prod/*"
    ]
  }
}

Grenzen sind kein Zeichen von Misstrauen

Einige Teams sträuben sich gegen Berechtigungsgrenzen, weil sie sich wie ein Zeichen von Misstrauen anfühlen. „Wir haben kluge Leute eingestellt. Warum können wir ihnen keinen Produktionszugriff anvertrauen?“

Diese Argumentation verfehlt den Punkt. Bei Berechtigungsgrenzen geht es nicht um Vertrauen. Es geht um Klarheit und Verantwortlichkeit. Wenn jeder Zugriff auf alles hat, weiß niemand, wen er anrufen soll, wenn etwas kaputt geht. Wenn die Grenzen klar sind, weiß das Team genau, wem jede Umgebung gehört und welchem Prozess zu folgen ist.

Grenzen schützen auch die Personen, die Fehler machen. Ein Entwickler, der versehentlich die Produktion kaputt macht, weil er uneingeschränkten Zugriff hatte, fühlt sich schrecklich. Er verschwendet auch die Zeit des Teams, während alle den Vorfall untersuchen. Mit klaren Grenzen wäre derselbe Entwickler gestoppt worden, bevor die Änderung die Produktion erreicht hätte. Das System fängt den Fehler ab, nicht die Person.

Eine kurze Checkliste für die Einrichtung von Berechtigungsgrenzen

Wenn Sie Ihr aktuelles Setup überprüfen, hier ein paar Dinge, die Sie prüfen sollten:

  • Ist das Produktions-State-Backend von Entwicklung und Staging getrennt?
  • Können Entwickler von ihren Laptops aus in den Produktions-State schreiben?
  • Erfordert die Produktionspipeline eine manuelle Genehmigung?
  • Gibt es einen klaren Eigentümer für jede Umgebung?
  • Werden Änderungen an Produktionskonfigurationen vor der Bereitstellung vom Eigentümer überprüft?

Diese Prüfungen sind nicht vollständig, aber sie decken die häufigsten Lücken ab, die zu Produktionsvorfällen führen.

Was als Nächstes kommt

Sobald Sie Berechtigungsgrenzen und Eigentumsverhältnisse eingerichtet haben, besteht die nächste Herausforderung darin, Ihren Infrastruktur-State genau zu halten. Manchmal erfolgen Änderungen außerhalb Ihrer Infrastructure-as-Code-Tools. Jemand ändert eine Serverkonfiguration direkt über die Cloud-Konsole. Ein Teammitglied wendet während eines Vorfalls manuell einen Hotfix an. Diese Änderungen erzeugen eine Abweichung zwischen Ihrem State und der Realität. Diese Abweichung untergräbt die Zuverlässigkeit Ihrer Infrastruktur und macht zukünftige Änderungen unberechenbar. Das ist ein Thema, das es wert ist, separat behandelt zu werden, aber für den Moment ist der wichtige Schritt, zuerst klare Grenzen zu schaffen. Ohne sie werden die Erkennung und Behebung von Abweichungen viel schwieriger zu handhaben.