Zum Inhalt springen
Search the hub
Control Plane vs. Data Plane — Admin-Grenzen

Control Plane vs. Data Plane — Admin-Grenzen

Control Plane und Data Plane trennen: wer administriert was, welche Zugriffe, welche Evidenz — ohne Vendor-Ideologie.

Category
Data Governance
Reading time
4 min
Published
Tags
control-plane data-plane admin-access hosting security
Download PDF

Wer die Control Plane administriert, steuert Identitäten, Policies und Orchestrierung. Wer die Data Plane berührt, greift auf Inhalte zu. Vermischen beide Rollen ohne Vertrag, entsteht unsichtbarer Superuser-Zugriff — unabhängig vom Hosting-Label.

Dieser Teil definiert den Mindestvertrag für Admin-Scope, Rollentrennung und Break-glass — bevor Residenz-Gates darauf aufsetzen.

Vorher: Hosting-Entscheidungsrahmen. Weiter: Residenz- und Souveränitäts-Gates. Standalone: Host vs Cloud.

zu. Vermischen beide Rollen ohne Vertrag, entsteht unsichtbarer Superuser-Zugriff — unabhängig vom Hosting-Label.

Lösung: Jede Plattform erhält vor produktivem Admin-Zugriff einen Control-Plane-Scope, einen Data-Plane-Scope, getrennte Admin-Rollen mit Owner-Freigabe und Steward-Review, Custodian-Umsetzung für Break-glass, Logging und Session-Evidenz sowie keinen dauerhaften kombinierten Superuser ohne Ausnahme und Ablauf.

In einem Satz: Kein produktiver Admin-Zugriff ohne getrennte Control-/Data-Plane-Rollen, Owner-Freigabe und Break-glass-Evidenz.

Entscheidung

Für jede Plattform gilt:

  1. Control-Plane-Scope (Accounts, IAM, Policies, Scheduler, Billing);
  2. Data-Plane-Scope (Datenlesen/-schreiben, Exports, Notebooks);
  3. getrennte Admin-Rollen mit Owner-Freigabe und Steward-Review;
  4. Custodian-Umsetzung (Break-glass, Logging, Session-Evidenz);
  5. kein dauerhafter kombinierter Superuser ohne Ausnahme und Ablauf.

Catalog listet Services; Governance begrenzt Admin-Rechte.

Workflow

1. Flächen kartieren

Der Platform Owner benennt, welche Konsolen, APIs und Agenten zur Control Plane gehören und welche Jobs, Clients und Exports zur Data Plane. Artefakt ist die Flächenkarte mit Systemen und Zugriffsarten — nicht ein Catalog-Tag „admin“. Der Steward hält die Karte gegen reale Konten; der Custodian liefert Inventar aus IAM. Wird die Karte übersprungen, bleibt Superuser unsichtbar, weil niemand weiß, welche Fläche welches Recht trägt.

2. Rollen schneiden

Platform Admin, Data Admin und Data Owner sind drei Rollen. Der Business-Owner entscheidet Semantik und Freigaben; der Steward reviewed Anträge; der Custodian setzt Rechte um und ist nicht A für Inhalt. Artefakt ist die Admin-Rollenmatrix mit Owner-Zeichnung. Fehlt der Schnitt, ist dieselbe Person Owner und alleiniger Admin — Control-Plane-Kompromittierung gleich Business-Kompromittierung.

3. Break-glass

Notfallzugriff ist zeitlich begrenzt, geloggt und nachträglich reviewed — kein stiller Dauerzustand. Der Security-Steward führt das Review an den Owner; der Custodian stellt Session-Evidenz und automatisches Ablaufdatum. Ein ungetesteter Break-glass ist kein Gate: Bypass ohne Evidenz entwertet die Grenze-Story. Wird Break-glass übersprungen oder dauerhaft offengelassen, ist die Rollentrennung Theater.

4. Drittparteien und Support

Vendor-Support auf der Control Plane braucht denselben Vertrag wie interne Admins: Zweck, Dauer, Evidenz. Der Vendor Manager stellt den Zugang mit Ablauf an den Steward; der Custodian scoped das Konto und loggt Sessions. Undokumentierter Support-Zugang ist Dritt-Control-Plane-Reach ohne Gate. Residenz-Labels im nächsten Teil heilen das nicht.

5. Evidenz

Zugriffslogs und Recertifizierung gehören zum Operating Contract, nicht nur zur Security-Folie. Der Steward setzt den Recert-Termin und das Admin-Evidenzpack; der Owner bestätigt, dass kombinierte Superuser Ausnahme oder getrennt sind. Fehlt Recertifizierung, überleben Shared-Root und Team-Owner-Accounts die erste Audit-Frage nicht.

Handoffs

Von An Artefakt
Platform Owner Steward Admin-Rollenmatrix
Steward Custodian IAM-/Policy-Umsetzung
Security Steward Owner Break-glass-Review
Vendor Manager Steward Support-Zugang mit Ablauf
Steward Audit Admin-Evidenzpack

Anti-Patterns

  • Shared root / owner-account für Teams
  • Kontrollregel-Plane-Admin automatisch mit Data-Plane-Vollzugriff
  • Dienstleister-Support ohne zeitliche Begrenzung
  • Nur Catalog-Tags „admin“ ohne Recertifizierung
  • Technical verantwortliche Person ersetzt Business-verantwortliche Person bei Freigaben

Umsetzung im Alltag

Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.

  1. Admin-Rollen einer Plattform in Control vs. Data Plane sortieren.
  2. Kombinierte Superuser finden und Ausnahme oder Trennung beschließen.
  3. Break-glass einmal testen und Evidenz prüfen.
  4. Recertifizierungs-Termin für Steward setzen.

Platform and hosting decisions

Part 2 of 5

View series

Knowledge check

Tour