Ranger: Resource-Policies oder Tag-Policies?

zwei Wege, dieselbe Zugriffsfrage zu beantworten. Eine resource-basierte Policy nennt Datenbank, Tabelle und Spalte direkt. Eine tag-basierte Policy nennt eine Klassifikation und wirkt auf alles, was diese Klassifikation trägt. Beide funktionieren. Beide gleichzeitig, ohne Regel für ihre Verwendung, erzeugen ein Modell, das niemand mehr im Kopf auswerten kann.

Lösung: Verwende resource-basierte Policies für stabile organisatorische Grenzen und tag-basierte Policies für wiederverwendbare Schutzregeln.

In einem Satz: Verwende resource-basierte Policies für stabile organisatorische Grenzen und tag-basierte Policies für wiederverwendbare Schutzregeln.

Problem

Ranger bietet zwei Wege, dieselbe Zugriffsfrage zu beantworten. Eine resource-basierte Policy nennt Datenbank, Tabelle und Spalte direkt. Eine tag-basierte Policy nennt eine Klassifikation und wirkt auf alles, was diese Klassifikation trägt. Beide funktionieren. Beide gleichzeitig, ohne Regel für ihre Verwendung, erzeugen ein Modell, das niemand mehr im Kopf auswerten kann.

Das typische Ergebnis nach zwei Jahren Betrieb: mehrere hundert Policies, viele mit ähnlichen Namen, ein Teil resource-basiert für Bequemlichkeit, ein Teil tag-basiert für Anspruch, dazwischen Deny-Regeln, die niemand mehr erklärt, und Exceptions ohne Ablaufdatum. Bei einer Prüfung wird dann die Policy-Liste vorgelegt statt einer Antwort auf die eigentliche Frage: Wer kann diese Spalte heute tatsächlich lesen?

Die schwierigere Variante desselben Problems ist die stille Wirkungsverschiebung. Eine tag-basierte Policy verändert ihren Effekt, sobald eine Klassifikation in Atlas ergänzt oder entfernt wird — ohne dass eine Policy geändert wurde. Wer Klassifikation und Policy als getrennte Welten behandelt, verliert die Kontrolle über die effektive Entscheidung.

Entscheidung

Verwende resource-basierte Policies für stabile organisatorische Grenzen und tag-basierte Policies für wiederverwendbare Schutzregeln. Die Trennung ist keine Stilfrage, sondern folgt daraus, was sich häufiger ändert: Strukturen oder Schutzbedarf.

Konkret:

• Grenze zwischen Domänen, Produkten, Zonen und Environments → resource-basiert. Diese Grenzen wechseln selten und sollen nicht von einer Klassifikationsänderung abhängen.
• Schutzregel für eine Datenklasse, die überall gleich gelten soll (Maskierung, Zeilenfilter, Verweigerung) → tag-basiert. Diese Regel soll neue Objekte automatisch erfassen.

Zusätzlich gilt: Jede tag-basierte Policy hat einen benannten Owner für die Klassifikationsentscheidung, nicht nur für die Policy. Ohne diesen Owner ist die Policy nicht betriebsbereit.

Der Pilot umfasst ein Environment und eine Domäne mit gemischten resource- und tag-basierten Policies. Erfolgreich ist er, wenn für eine Spalte des Pilotprodukts ohne mündliches Zusatzwissen gesagt werden kann, welche Policy-Art entscheidet, wer die Klassifikation freigibt und welches Effective-Access-Ergebnis zuletzt gemessen wurde.

Wie Ranger auswertet

Bevor Policy-Design sinnvoll ist, muss die Auswertungslogik geklärt sein. Vier Punkte reichen für die meisten Entscheidungen:

• Tag-basierte Richtlinien werden vor resource-basierten geprüft. Eine Verweigerung auf Tag-Ebene beendet die Prüfung; eine Erlaubnis auf Tag-Ebene kann die Anfrage bereits abschließen.
• Deny gewinnt gegen Allow innerhalb derselben Ebene. Wer über breite Deny-Regeln arbeitet, muss Ausnahmen bewusst modellieren, nicht durch eine weitere Allow-Richtlinie „überschreiben“ wollen.
• Deny-Exceptions und Allow-Exceptions sind Teil der Richtlinie, nicht eine separate Richtlinie. Sie sind das vorgesehene Mittel für „alle außer diesen“ und deutlich besser prüfbar als eine Sammlung konkurrierender Regeln.
• Fehlt eine passende Erlaubnis, wird verweigert. Ranger vergibt keinen impliziten Zugriff. Ausnahme sind Verantwortung- und Admin-Pfade, die außerhalb der normalen Richtlinie-Logik wirken können.

Praktische Konsequenz: Ein Policy-Review ohne Kenntnis dieser Reihenfolge liest die Liste, nicht die Wirkung.

Wann resource-basiert

Resource-basierte Policies sind das richtige Werkzeug, wenn die Antwort von der Struktur abhängt und nicht vom Inhalt.

• Domänen- und Produktgrenzen. Ein Team arbeitet auf seinen eigenen Datenbanken und liest definierte fremde Produkte. Das ist eine strukturelle Aussage.
• Zonen und Reifegrade. Roh-, Kurations- und Publikationszone haben unterschiedliche Zugriffsprofile, unabhängig von Klassifikation.
• Betriebsaufgaben. Wartungs- und Deployment-Prinzipale brauchen definierte Rechte auf definierten Objekten.
• Kafka-Topics und HDFS-Pfade mit klarer Zuordnung. Solange die Objektmenge überschaubar und benannt ist, ist die direkte Referenz die verständlichere.

Der Preis: Neue Objekte sind nicht automatisch erfasst. Deshalb braucht jede resource-basierte Policy eine Konvention, wie neue Objekte in den Scope kommen — über Namensmuster mit Wildcards oder über einen definierten Schritt im Deployment.

Wildcards sind erlaubt und nützlich, aber sie verlagern die Kontrolle in die Namenskonvention. Wenn kunde_* erlaubt ist, wird der nächste Tabellenname zur Sicherheitsentscheidung. Diese Abhängigkeit gehört dokumentiert.

Wann tag-basiert

Tag-basierte Policies sind das richtige Werkzeug, wenn die Antwort vom Inhalt abhängt und überall gleich sein soll.

• Personenbezogene Daten. Maskierung oder Verweigerung soll gelten, egal in welcher Tabelle die Spalte auftaucht.
• Regulatorische Klassen. Zahlungsdaten, Gesundheitsdaten, Vertragsgeheimnisse — Regeln, die aus einer Anforderung stammen und nicht aus einer Struktur.
• Zeitliche und geografische Einschränkungen. Wenn eine Klasse nur in bestimmten Regionen oder nur für begrenzte Zeit zugänglich ist.
• Schnell wachsende Bestände. Wo täglich neue Tabellen entstehen, ist eine Klassifikationsregel realistischer als eine Pflegeliste.

Der Preis: Die Wirkung hängt vollständig von der Klassifikationsqualität ab. Drei Fragen müssen vor dem Einsatz beantwortet sein:

• Wer entscheidet, dass eine Spalte eine Klassifikation erhält, und in welchem Verfahren?
• Wie schnell wirkt eine Klassifikationsänderung — und wie wird der Zustand zwischen Änderung und Wirksamkeit behandelt?
• Was passiert, wenn eine Klassifikation entfernt wird? Fällt der Schutz weg, oder greift eine resource-basierte Grundregel?

Die dritte Frage entscheidet, ob das Modell belastbar ist. Eine tragfähige Antwort ist meist ein konservatives Grundniveau resource-basiert, verschärft durch tag-basierte Regeln — nicht Schutz ausschließlich über Tags.

Principals: Users, Groups, Roles und Service Accounts

Policies sollten nicht auf einzelne Benutzer verweisen, außer als dokumentierte, befristete Ausnahme. Für den Regelfall gilt eine klare Reihenfolge:

• Gruppen aus dem Unternehmens-IdP für fachliche Zugehörigkeit. Sie sind bereits Teil eines Joiner-Mover-Leaver-Prozesses.
• Ranger-Rollen für die Zusammenfassung mehrerer Gruppen oder Service-Prinzipale zu einer Zugriffsintention. Rollen halten die Richtlinie-Anzahl niedrig und machen Änderungen an einer Stelle nachvollziehbar.
• Service-Prinzipale getrennt von menschlichen Identitäten. Ein technischer Zugriff hat einen verantwortliche Person, ein Rotationsverfahren und einen definierten Zweck. Er darf nicht in derselben Gruppe wie Personen liegen.

Für jeden Principal wird festgehalten: Zweck, Owner, Herkunft der Mitgliedschaft, Rezertifizierungsintervall. Ein Principal ohne Owner ist ein Findung, kein Detail.

Maskierung und Zeilenfilter richtig einordnen

Spaltenmaskierung und Zeilenfilter sind starke Werkzeuge, aber sie sind Sichtbarkeitsregeln, keine Datenschutzgarantie. Drei Einschränkungen gehören in jede Bewertung:

• Sie wirken nur an Durchsetzung-Punkten mit aktivem Plugin. Direkter Dateizugriff sieht sie nicht.
• Sie sind gegen Rückschlüsse nur begrenzt wirksam. Maskierte Spalten in Kombination mit Aggregaten und Joins können identifizierend bleiben.
• Sie erhöhen die Testlast. Jede Maskierungsregel braucht einen Test mit einer Identität, die maskiert sieht, und einer, die nicht maskiert sieht.

Wo eine Anforderung echte Nichtverfügbarkeit verlangt, ist ein separates, unmaskiert nicht erreichbares Produkt die klarere Lösung als eine komplexe Maskierungsmatrix.

Effective Access testen

Ein Policy-Review beweist nichts. Die belastbare Aussage entsteht aus Tests mit realen Identitäten am realen Pfad. Die Mindestmatrix umfasst sechs Fälle:

• Erlaubter Standardzugriff einer fachlichen Rolle
• Verweigerter Zugriff einer benachbarten Rolle auf dasselbe Objekt
• Maskierter Zugriff, wo Maskierung vorgesehen ist
• Zugriff eines Service-Prinzipals auf genau seinen Umfang
• Verweigerter Zugriff desselben Service-Prinzipals außerhalb seines Umfang
• Privilegierter Zugriff über Admin- oder Verantwortung-Pfad, protokolliert und begründet

Jeder Test protokolliert Identität, Zeitpunkt, Objekt, erwartetes Ergebnis, tatsächliches Ergebnis und die wirksame Policy-Version. Ohne Versionsbezug ist das Ergebnis nach der nächsten Änderung wertlos.

Zusätzlich lohnt ein Negativtest auf der Tag-Ebene: eine Klassifikation testweise auf ein Testobjekt setzen und prüfen, ob die erwartete Regel greift — und wie lange es dauert. Dieser Test misst die Kopplung zwischen Atlas und Ranger, die im Alltag oft angenommen und selten verifiziert wird.

Rezertifizierung

Rezertifizierung prüft nicht Gruppenmitgliedschaften, sondern Zweckfortbestand. Vier Fragen pro Zugriffsintention:

• Besteht der fachliche Zweck weiterhin, und wer bestätigt das?
• Ist die Menge der Principals noch angemessen, oder ist sie durch Bequemlichkeit gewachsen?
• Ist die Richtlinie noch die einfachste Umsetzung, oder wurde sie durch Ausnahmen ersetzt?
• Sind Testergebnisse aktuell genug, um die Wirkung zu belegen?

Sinnvolle Kadenz: kritische Produkte quartalsweise, übrige halbjährlich, Service-Prinzipale bei jeder Rotation. Eine überfällige Rezertifizierung ist ein Befund mit Owner, keine Nachlässigkeit im Betrieb.

Ausnahmen mit Ablaufdatum

Eine Ausnahme ist eine Entscheidung, nicht ein Kommentar. Sie enthält Scope, Begründung, Risiko, kompensierendes Control, accountable Genehmiger, Ablaufdatum und Remediation Owner.

Technisch hilft es, das Ablaufdatum direkt in der Policy zu verankern, wo Ranger einen Gültigkeitszeitraum unterstützt. Dann endet die Ausnahme, wenn niemand handelt — statt unbegrenzt weiterzulaufen, wenn niemand aufräumt. Das ist der wichtigste einzelne Hebel gegen Rechte-Erosion.

Ausnahmen brauchen zusätzlich eine Obergrenze: Wenn ein Produkt mehr als eine kleine, definierte Zahl offener Ausnahmen hat, ist nicht die Ausnahmeverwaltung das Problem, sondern das Policy-Design.

Häufige Anti-Patterns

Tag-basiert als Selbstzweck

Tag-Policies ohne belastbaren Klassifikationsprozess verlagern das Problem von der Policy in die Metadaten, ohne es zu lösen.

Resource-basiert für alles

Wachsende Bestände führen zu Pflegelisten, die nie vollständig sind. Der Schutzbedarf gehört an die Klasse, nicht an den Tabellennamen.

Deny-Regeln als Standardwerkzeug

Breite Deny-Regeln mit vielen konkurrierenden Allow-Policies erzeugen ein Modell, dessen Wirkung nur noch durch Testen ermittelbar ist.

Einzelne Benutzer in Policies

Jeder Personalwechsel wird zur Sicherheitsaufgabe, und der Joiner-Mover-Leaver-Prozess wird umgangen.

Admin-Test als Nachweis

Ein erfolgreicher Zugriff mit privilegiertem Konto sagt nichts über die reguläre Zugriffsentscheidung.

Ausnahmen ohne Ablauf

Dauerhaft temporärer Zugriff ist ein zweites, undokumentiertes Berechtigungsmodell.

Policy-Namen als Dokumentation

Ein guter Name ist hilfreich. Er ersetzt weder Zweck, Owner, Testfall noch Review-Datum.

Umsetzung in 40 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: Zugriffsintentionen erheben

Für ein Produkt alle realen Zugriffsintentionen sammeln — fachlich formuliert, nicht als Policy. Pro Intention Zweck, Principals, Objekte, Sensitivität und Owner festhalten.

Schritt: Werkzeug zuordnen

Jede Intention wird resource-basiert oder tag-basiert klassifiziert, mit Begründung. Verbleibende Grauzonen erhalten eine bewusste Entscheidung, nicht beide Varianten.

Schritt: Implementieren mit Rollen

Ranger-Rollen definieren, Policies aufsetzen, Deny-Exceptions statt konkurrierender Regeln nutzen, Ausnahmen mit Gültigkeitszeitraum anlegen.

Schritt: Testmatrix ausführen

Sechs Mindestfälle plus Tag-Propagationstest. Abweichungen als Backlog behandeln, nicht als Testfehler wegdiskutieren.

Schritt: Rezertifizierung verankern

Intervalle, Verantwortliche und Auslöser festlegen. Erste Rezertifizierung terminieren und Evidenzort benennen.

Messung

• Anteil der Zugriffsintentionen mit dokumentierter Werkzeugentscheidung
• Verhältnis von Richtlinien zu Zugriffsintentionen als Indikator für Modellkomplexität
• Anteil der Richtlinien mit Rollen statt Einzelbenutzern
• Anteil der Zugriffsintentionen mit aktuellem Testergebnis und Richtlinie-Version
• Anzahl und Durchschnittsalter offener Ausnahmen sowie Anteil mit Ablaufdatum
• Zeit von Klassifikationsänderung bis nachgewiesener Richtlinie-Wirkung
• Anteil überfälliger Rezertifizierungen bei kritischen Produkten

Checkliste

• Für jede Zugriffsintention ist resource- oder tag-basiert bewusst entschieden.
• Die Auswertungsreihenfolge ist im Team bekannt und im Review berücksichtigt.
• Tag-basierte Richtlinien haben einen verantwortliche Person für die Klassifikationsentscheidung.
• Ein konservatives resource-basiertes Grundniveau existiert, falls Tags entfallen.
• Richtlinien verweisen auf Gruppen und Rollen, nicht auf Einzelbenutzer.
• Service-Prinzipale sind von menschlichen Identitäten getrennt und haben verantwortliche Person.
• Ausnahmen sind über Deny- oder Allow-Exceptions modelliert, nicht über Gegenpolicies.
• Maskierung und Zeilenfilter sind als Sichtbarkeitsregeln bewertet, nicht als Garantie.
• Die Testmatrix deckt erlaubt, verweigert, maskiert, Service, Service-außerhalb und privilegiert ab.
• Testergebnisse tragen Identität, Zeitpunkt, Objekt und Richtlinie-Version.
• Der Tag-Propagationstest wurde durchgeführt und die Latenz ist bekannt.
• Jede Ausnahme hat Ablaufdatum, kompensierendes Kontrollregel und Remediation verantwortliche Person.
• Rezertifizierungsintervalle sind festgelegt und einer Rolle zugeordnet.

Artefakt

Das Ergebnis ist eine Access Intent Matrix je Datenprodukt. Eine Zeile pro Zugriffsintention mit fachlicher Formulierung, Principals, Objekten, Sensitivität, gewähltem Policy-Typ mit Begründung, Ranger-Rolle, Maskierungs- oder Filterregel, Testfällen, letztem Testergebnis, offenen Ausnahmen und Rezertifizierungsdatum.

Die Matrix ist bewusst kein Policy-Export. Ein Export beschreibt die Konfiguration; die Matrix beschreibt die Absicht und erlaubt damit die eigentliche Prüfung: Setzt die Konfiguration noch um, was entschieden wurde?

Änderungen an Principals, Objektmengen oder Sensitivität erzeugen eine neue Version der betroffenen Zeile und lösen die zugehörigen Tests erneut aus.

Tools und Verweise

• Ranger Richtlinie Pattern Generator
• Authority Matrix Builder
• Custom Stack Builder
• Cloudera SDX als Betriebsgrenze verstehen
• Cloudera CDP mit Ranger als Governance-Einstieg
• Governance-Plattform-Einstieg wählen
• Lernpfad Cloudera CDP Governance
• Glossary: Apache Ranger, Cloudera CDP, Apache Hive, Kerberos