Cloudera SDX als Betriebsgrenze verstehen

Problem

SDX wird in Architekturdiagrammen gern als „Governance-Layer“ bezeichnet. Diese Beschreibung ist bequem und führt in die Irre. SDX ist eine Sammlung geteilter Dienste — Ranger für Autorisierung, Atlas für Metadaten und Lineage, der Hive Metastore für Schema- und Tabellenidentität, dazu Identity-Anbindung und Audit-Ablage. Diese Dienste setzen Entscheidungen durch und machen Zustände sichtbar. Sie treffen keine Entscheidungen.

Größenordnung: KMU/SMB — eine CDP-Umgebung und ein Datenprodukt mit schriftlicher SDX-Grenze (Plugins, Metastore, Outside-Pfade). Mid-Market — Ranger/Atlas-Evidenz für dieses Produkt und Identity-Mapping. Enterprise — Hybrid/Multi-Cluster-Authority-Maps und Environment-Transition-Controls.

Die Folge ist ein wiederkehrendes Muster: Eine Organisation richtet ein CDP-Environment ein, schließt Ranger und Atlas an und betrachtet Governance als adressiert. Sechs Monate später existieren mehrere Environments, unterschiedliche Ranger-Policy-Repositories, ein zweiter Metastore für ein Data-Hub-Cluster, externe Tabellen auf Storage, der auch von Nicht-CDP-Engines gelesen wird, und niemand kann sagen, welche Entscheidung für ein bestimmtes Datenprodukt tatsächlich gilt.

Der zweite Fehler ist die Annahme, die SDX-Grenze sei identisch mit der Grenze des fachlichen Betriebsmodells. Sie ist es fast nie. Ein Datenprodukt hat Consumer in BI-Werkzeugen, Exporte in Dateisysteme, Kopien in Sandboxes und Abhängigkeiten von Quellsystemen, die außerhalb jedes Ranger-Plugins liegen. Wer die Grenze nicht schriftlich zieht, führt Audits über eine Fläche, die kleiner ist als das tatsächliche Risiko.

Entscheidung

Behandle SDX als durchsetzende und beobachtende Fläche innerhalb einer explizit gezogenen Grenze — nicht als Governance-Programm. Für jedes Datenprodukt im Scope wird schriftlich festgehalten: Welche Entscheidung gilt, wer sie verantwortet, welcher SDX-Dienst sie durchsetzt, wo die Evidenz liegt und welche Teile des Pfads außerhalb von SDX liegen.

Zieh die Grenze auf Environment-Ebene, nicht auf Cluster- oder Tabellenebene. Ein CDP-Environment ist die kleinste Einheit, die eine gemeinsame Ranger-Policy-Basis, ein gemeinsames Atlas-Inventar und einen gemeinsamen Metastore besitzt. Alles, was diese Einheit verlässt, ist eine Übergabe und braucht eine dokumentierte Übergabeentscheidung.

Der Pilot umfasst ein CDP-Environment und ein Datenprodukt darin — nicht die gesamte Landschaft. Erfolg ist nicht die Existenz eines Diagramms. Erfolg ist, wenn eine beteiligte Person für dieses Pilotprodukt in unter 30 Minuten sagen kann, welche Zugriffsentscheidung von welchem Dienst durchgesetzt wird und wo die Durchsetzung genau endet.

Was SDX besitzt und was nicht

SDX besitzt zuverlässig drei Dinge:

• Autorisierungsentscheidungen an angebundenen Durchsetzung-Punkten. Ranger-Plugins in Hive, Impala, HDFS, HBase, Kafka, Solr und weiteren Diensten fragen die Richtlinie-Basis ab und protokollieren das Ergebnis. Wo ein Plugin aktiv ist, gilt die Richtlinie.
• Technische Metadaten und Lineage-Erfassung, soweit Hooks liefern. Atlas erhält Entitäten und Beziehungen über Hooks. Ohne aktiven Hook existiert das Objekt in Atlas nicht.
• Objektidentität für Hive- und Impala-Tabellen. Der Hive Metastore ist die Referenz dafür, was eine Tabelle ist, wo ihre Daten liegen und welches Schema gilt.

SDX besitzt ausdrücklich drei Dinge nicht:

• Fachliche Bedeutung und erlaubter Zweck. Eine als pii klassifizierte Spalte ersetzt nicht die Entscheidung, welche Nutzung erlaubt ist und welches Restrisiko akzeptiert wird.
• Priorität und Risikoakzeptanz. Kein Dienst kann entscheiden, dass ein Marketing-Use-Case eine Aufbewahrungsanforderung überwiegt.
• Durchsetzung außerhalb angebundener Engines. Ein Spark-Job mit direktem Storage-Zugriff, ein CSV-Export, eine Kopie in eine Sandbox oder ein Zugriff über eine nicht integrierte Query-Schicht sieht Ranger-Tabellen-Richtlinien nie.

Diese Trennung ist der Kern dieses Playbooks. Alles Weitere wendet sie an.

Environment-Grenzen als Governance-Grenzen

Ein CDP-Environment bündelt Identity-Anbindung, Ranger-Policies, das Atlas-Inventar, den Metastore und die Konventionen für Storage-Pfade. Damit ist es die natürliche Einheit für eine Governance-Aussage. Zwei Environments mit „denselben“ Policy-Namen sind zwei getrennte Kontrollflächen mit getrennter Evidenz.

Halte für jedes Environment vier Dinge fest:

• Zweck und Kritikalität. Produktion, Integration, Entwicklung, Analytics-Sandbox — mit unterschiedlichen Erwartungen an Kontrollen und Evidenz.
• Identity-Quelle. Welcher IdP, welche Gruppen, welche Service-Principals, welches Mapping des Kerberos-Realms.
• Im Environment erlaubte Datenklassen. Ob regulierte Daten überhaupt zulässig sind und in welcher Form (roh, maskiert, aggregiert).
• Erlaubte Übergänge. Welche Replikationen, Exporte und Sandbox-Kopien zulässig sind und wer sie genehmigt.

Der häufigste unbemerkte Bruch ist die Analytics-Sandbox. Sie entsteht aus guten Gründen, bekommt großzügige Rechte, weil „nur Kopien“ verarbeitet werden, und wird nach einigen Monaten selbst zur Quelle für Berichte. Ohne dokumentierten Übergang wandert reguliertes Material in ein Environment mit schwächeren Kontrollen und ohne Consumer-Register.

Wie die vier Kontrollflächen zusammenwirken

Ranger: Autorisierung und Audit

Ranger entscheidet pro Anfrage anhand von Policies, die entweder direkt auf Ressourcen oder auf Klassifikationen wirken. Jede Entscheidung erzeugt ein Audit-Event. Damit ist Ranger die belastbarste Evidenzquelle für tatsächlichen Zugriff — aber nur für Pfade mit aktivem Plugin.

Praktische Konsequenz: Die Liste der aktiven Plugins ist ein Governance-Artefakt, keine Betriebsnotiz. Sie beantwortet, wo Policies überhaupt wirken können.

Atlas: Metadaten, Klassifikation und Lineage

Atlas hält Entitäten, Klassifikationen und Beziehungen. Über Tag-Sync fließen Klassifikationen nach Ranger und werden dort zu Policy-Eingaben. Damit ist Atlas indirekt sicherheitsrelevant: Eine falsche oder fehlende Klassifikation verändert die effektive Zugriffsentscheidung.

Praktische Konsequenz: Änderungen an Klassifikationen brauchen die gleiche Change-Kontrolle wie Policy-Änderungen. Teil 3 dieser Serie behandelt das im Detail.

Hive Metastore: Objektidentität

Der Metastore definiert, was eine Tabelle ist. Ranger-Ressourcen-Policies referenzieren Datenbank-, Tabellen- und Spaltennamen; Atlas referenziert Qualified Names, die aus Metastore-Objekten abgeleitet sind. Wird eine Tabelle gelöscht und neu erzeugt, sehen beide Dienste neue Fakten — Klassifikationen und teils auch Policy-Zuordnungen gehen verloren.

Praktische Konsequenz: DROP und CREATE als Deployment-Muster ist eine Governance-Entscheidung, nicht bloß eine technische Vorliebe.

Identity: Gruppen, Rollen und Service-Principals

Die Kette aus Unternehmensgruppe, Environment-Rolle, Ranger-Rolle und Kerberos-Principal bestimmt, wer eine Anfrage stellt. Ein sauberer Gruppenname belegt keinen effektiven Zugriff, solange daneben Direktvergaben, Storage-Zugriffsregels, Verantwortung-Rechte und Notfallkonten existieren.

Praktische Konsequenz: Tests auf effektiven Zugriff sind Pflicht; Policy-Reviews allein genügen nicht.

Wo die SDX-Grenze tatsächlich bricht

Sechs Stellen erzeugen in der Praxis die meisten Überraschungen:

• Externe Tabellen auf geteiltem Storage. Wenn ein Nicht-CDP-Prozess denselben Pfad liest oder schreibt, ist die Tabellen-Richtlinie nicht die effektive Grenze. Die effektive Grenze ist die Storage-Berechtigung.
• Spark mit direktem Dateizugriff. Ein Job, der Pfade statt Tabellen liest, umgeht Spalten- und Zeilenregeln vollständig.
• Replikation zwischen Environments. Daten wandern; Richtlinien und Klassifikationen wandern nicht automatisch mit identischer Wirkung. Nach jeder Replikation ist ein Test auf effektiven Zugriff im Ziel erforderlich.
• Exporte und Downloads. Die Ranger-Durchsetzung endet am Export. Der Export ist der Punkt, an dem eine fachliche Nutzungsentscheidung nachweisbar vorliegen muss.
• Privilegierte und Notfallkonten. Admin-Pfade existieren aus guten Gründen. Sie gehören in den Umfang, mit eigenem Test und eigener Evidenz.
• Nicht integrierte Query- und BI-Schichten. Ein Werkzeug mit eigenem Service-Account und eigenem Berechtigungsmodell verlagert Autorisierung aus SDX heraus. Dieses Werkzeug ist dann ein zweiter Durchsetzung-Punkt und braucht einen eigenen verantwortliche Person.

Keine dieser Stellen ist „gelöst“. Jede wird benannt, mit einer kompensierenden Kontrolle versehen und in einem festen Takt überprüft.

Betriebsmodell an der Grenze

• Environment-verantwortliche Person: verantwortet Zweck des Environments, erlaubte Datenklassen und Übergänge.
• Data Owner pro Produkt: entscheidet über Bedeutung, erlaubte Nutzung, Risikoakzeptanz und Priorität.
• Platform technischer Betreiber: implementiert genehmigte Entscheidungen in Ranger, Atlas und Metastore und betreibt die Plugins.
• kontrollverantwortliche Person: definiert das erwartete Kontrollergebnis, die Testmethode und den Ausnahmeprozess.
• Nutzer verantwortliche Person: bestätigt Abhängigkeit, Nutzungszweck und Migrationsfähigkeit.

Jede Entscheidung hat genau eine verantwortliche Rolle. Der Platform Custodian ist ausdrücklich nicht der Genehmiger für neue Zwecke, verlängerte Aufbewahrung oder akzeptiertes Restrisiko.

Häufige Anti-Muster

„SDX ist unsere Governance“

Ein Bündel von Diensten kann kein Risiko akzeptieren und keine konkurrierenden Zwecke abwägen. Die Aussage verschiebt Verantwortung an eine Stelle, die sie nicht tragen kann.

Eine Grenze pro Cluster statt pro Environment

Cluster kommen und gehen. Die stabile Einheit für Policy-Basis, Metastore und Atlas-Inventar ist das Environment.

Plugin-Abdeckung wird nicht nachgehalten

Ohne aktuelle Liste der aktiven Ranger-Plugins ist jede Aussage über Durchsetzung eine Vermutung.

Sandbox ohne Übergangsentscheidung

Kopien mit schwächeren Kontrollen werden zu Produktionsquellen, ohne dass jemand diese Entscheidung getroffen hat.

Replikation ohne Nachtest im Ziel

Gleiche Daten, andere Wirkung. Policy-Namen im Ziel belegen keine gleichwertige Autorisierung.

Externe Tabellen wie „normale“ Tabellen behandeln

Solange der Storage-Pfad anders erreichbar ist, ist die Tabellen-Policy Kosmetik.

Umsetzung in 45 Tagen

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.

• Arbeitsplan — Cloudera CDP Governance
• Lernpfad — Cloudera CDP Governance

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.

Schritt 1: Grenze ziehen

Ein Environment, ein Datenprodukt, ein realer Pfad von der Quelle bis zum Consumer. Erfasse aktive Ranger-Plugins, Metastore-Objekte, Atlas-Abdeckung und jeden Austritt aus der Grenze.

Schritt 2: Verantwortung zuordnen

Halte für die fünf wichtigsten Governance-Fragen des Produkts fest: Entscheidung, verantwortliche Rolle, Durchsetzung-Punkt, Ort der Evidenz und Ausnahmeweg. Lass offene Fragen sichtbar, statt sie zu glätten.

Schritt 3: Grenze testen

Erlaubter Zugriff, verweigerter Zugriff, Service-Zugriff, privilegierter Bypass und mindestens ein Austrittspfad (Export, Sandbox-Kopie oder externe Tabelle). Protokolliere Ergebnisse mit Identität, Zeitstempel, Ressource und Policy-Version.

Schritt 4: Lücken bewerten und entscheiden

Jede gefundene Lücke erhält eine kompensierende Kontrolle, einen Owner und eine Frist — oder eine dokumentierte Risikoakzeptanz mit Ablaufdatum. Erst danach auf weitere Produkte ausdehnen.

Messung

• Anteil kritischer Produkte mit dokumentierter und bestätigter Environment-Grenze
• Anteil der Durchsetzung-Punkte mit aktivem Plugin gegenüber den erwarteten Punkten
• Anzahl bekannter Austrittspfade mit kompensierender Kontrolle und verantwortliche Person
• Anteil der Replikationen und Sandbox-Kopien mit Test auf effektiven Zugriff im Ziel
• Zeit, die benötigt wird, um Durchsetzung und Evidenz für ein Produkt zu erklären
• Anzahl privilegierter Zugriffspfade mit getestetem und protokolliertem Bypass-Weg

Checkliste

• Die Governance-Grenze ist schriftlich auf Environment-Ebene gezogen.
• Für jedes Environment sind Zweck, Datenklassen und erlaubte Übergänge festgehalten.
• Die Liste der aktiven Ranger-Plugins ist aktuell und wird als Artefakt gepflegt.
• Die Atlas-Abdeckung ist gegen die tatsächlich betriebenen Objekte geprüft.
• Externe Tabellen und direkte Storage-Zugriffe sind identifiziert und bewertet.
• Exporte, Sandbox-Kopien und Replikationen haben eine Übergangsentscheidung.
• Privilegierte und Notfallkonten sind im Umfang, getestet und protokolliert.
• Jede Governance-Frage hat genau eine verantwortliche Rolle.
• Tests auf effektiven Zugriff haben erlaubte, verweigerte, Service- und Bypass-Pfade abgedeckt.
• Nicht integrierte BI- oder Query-Schichten sind als separate Durchsetzung-Punkte benannt.
• Jede offene Lücke hat eine kompensierende Kontrolle, einen Owner und eine Frist.
• Ein Review-Termin für die Grenze und ihre Annahmen ist gesetzt.

Artefakt

Das Ergebnis ist eine SDX-Grenzkarte pro Environment. Sie enthält Zweck und Kritikalität, Identity-Quelle, erlaubte Datenklassen, aktive Durchsetzung-Punkte, Atlas-Abdeckung, Metastore-Konventionen, alle bekannten Austrittspfade mit kompensierenden Kontrollen, Rollen pro Fragestellung, Testergebnisse und einen Review-Termin.

Daneben entsteht ein kurzes Austrittsregister: eine Zeile pro Pfad, der die Grenze verlässt, mit Ziel, Datenklasse, Genehmiger, Kontrolle und nächstem Review. In Audits ist dieses Register regelmäßig wertvoller als das Policy-Inventar, weil es das Restrisiko zeigt.

Die Karte ist ein Betriebsvertrag. Änderungen an Environment-Zweck, Plugin-Abdeckung oder erlaubten Übergängen erzeugen eine neue Version und lösen gezielte Nachtests aus.

Werkzeuge und Referenzen

• Custom Stack Builder
• Authority Matrix Builder
• Ranger Richtlinie Pattern Generator
• Cloudera CDP mit Ranger als Governance-Startpunkt
• Governance-Plattform-Startpunkt wählen
• Lernpfad: Cloudera CDP Governance
• Glossar: Cloudera CDP, Apache Ranger, Apache Atlas, Apache Hive, Kerberos