Berechtigungsmatrizen und Section Access gehören in die DB

Section Access in der sales_otc-App filtert Regionen — die Matrix existiert nur im Skript und weicht von der IAM-Gruppe ab. Durchsetzung ist lokal; die Berechtigungsmatrix ist das Steuerdaten-Produkt.

zertifizierung. Die Zeilen, die entscheiden, wer welche Company, Kostenstelle oder Region sieht, leben trotzdem nur im App-Skript und weichen von der IAM-Gruppe ab.

Lösung: Berechtigungsmatrizen als Steuerdaten-Produkt der Klasse entitlement in der Datenbank pflegen; die App setzt durch nur.

In einem Satz: Durchsetzung ist lokal; die Matrix ist das Produkt.

Problem

Access-Governance-Programme definieren Policies, Rollen und Rezertifizierung. Währenddessen leben die Zeilen, die tatsächlich entscheiden, wer welche Company, Kostenstelle oder Region sieht, noch als:

• LOAD INLINE Section Access in jeder Qlik-App;
• Excel-USERID-Listen per E-Mail an Entwickler;
• duplizierte RLS-Rollen-Tabellen pro Power-BI-Dataset;
• Warehouse-Richtlinien ad hoc editiert ohne Steward-UI;
• Kopien, die nach jeder Joiner-/Leaver-Welle driften.

Access Security Governance deckt den Policy-Rahmen ab. Es macht die Matrix allein noch nicht zum governeden Produkt. Wenn die Matrix Inline oder dateibasiert ist, entsteht derselbe technische Albtraum wie bei anderem Steuerdaten: kein einzelner Owner, keine Impact-Analyse, kein Dual-Run, kein Audit wer eine Reduktion gewährt hat, und keine geteilte Wahrheit über Qlik, Power BI und SQL.

Failure Modes verstärken sich:

• App A erlaubt REGION=NORTH; App B hat noch gestriges Sheet — derselbe User, unterschiedliche Wahrheit.
• Ein Entwickler hardcodet „vorübergehend“ eine ADMIN-Zeile und vergisst sie zu entfernen.
• Spaltenumbenennung in Excel bricht den nächsten Reload; Produktion öffnet zu weit oder scheitert unvorhersehbar closed.
• Rezertifizierung signiert IdP-Gruppen ab, während Orphan-Matrix-Zeilen weiterhin Reduktions gewähren.

Entscheidung

Behandeln Sie Berechtigungsmatrizen als Steuerdaten-Produkte der Klassifikation entitlement. Enforce im Consumer (Section Access, RLS, Warehouse Row Policies, API-Filter). Pflegen Sie eine zentrale Matrix (oder eine kleine Familien von Matrizen) mit dem Produktvertrag aus Teil 8.

Beispiel (Lehrfall, keine Kundendaten): Typisches Muster aus Governance-Projekten — im eigenen Umfeld durch Catalog-/BI-/Ticket-/Prozessquellen ersetzen.

Central entitlement product (Postgres + contract view)
        │
        ├─→ Qlik Section Access load (enforcement)
        ├─→ Power BI RLS / OLS mapping (enforcement)
        ├─→ Warehouse / lake RLS policies (enforcement)
        └─→ API authorization filters (enforcement)

Durchsetzung vs. Produkt

Verwechseln Sie nicht „Section Access funktioniert in der App“ mit „Berechtigungs sind governed.“ Die App muss fail-closed, wenn das Produkt stale oder fehlend ist; sie darf nicht System of Record werden.

Multi-Consumer, dieselbe Tabelle

Gestalten Sie Reduktion-Schlüssel als Business Keys (company_code, cost_center, region_id), nicht als tool-spezifische Feldnamen. Veröffentlichen Sie bei Bedarf eine Consumer-View pro Durchsetzung-Stil:

Beispiel (Lehrfall, keine Kundendaten): Typisches Muster aus Governance-Projekten — im eigenen Umfeld durch Catalog-/BI-/Ticket-/Prozessquellen ersetzen.

control_access.v_entitlement_matrix     canonical rows
control_access.v_qlik_section_access    ACCESS, USERID, REGION, ...
control_access.v_pbi_rls_bridge         user_principal, dimension_key, ...

Transformationen von kanonisch → Engine-Form gehören in versioniertes SQL oder geskriptete Loads, nicht in stille Excel-Formeln. Halten Sie Identity Mapping (IdP-User → analytische USERID) explizit und owned.

DIY-Tipp: Stufen B und D

Generische Open-Source-Grids sind ein schlechter Default für Berechtigungs: leichtes Over-Grant, schwache Freigabe, unbequemes Audit. Bevorzugen Sie Teil 7:

• Stufe B — kleines Formular für Add/Change/Disable mit serverseitiger Validierung;
• Stufe D — Freigabe vor Publish für Produktions-Grants.

Nutzen Sie nie ungesteuertes Excel als führende Quelle für USER×Reduktion-Zeilen. Template-Upload (Stufe C) ist nur akzeptabel mit Reject-Reports, ohne Partial Commit und Freigabe vor Publish.

Zentrale Berechtigungs + lokales Durchsetzung

Entscheidungsregel:

Eine governed Berechtigung-Quelle; nur app-lokales Durchsetzung. Inline Section Access und Mailbox-Excel-Listen sind technische Schuld, kein Sicherheitsdesign.

Richten Sie Change Windows an Access Operations aus. Ein Joiner-/Leaver-Feed darf Identity upserten; Reduktion-Grants brauchen weiterhin Steward oder automatisierte Regeln mit Audit. Rezertifizieren Sie Matrix-Zeilen im selben Takt wie Access Reviews.

Failure Modes, gegen die Sie designen

• Inline SA über Apps kopiert mit lokalen „Fixes.“
• Excel als führende Quelle für USERID-Listen.
• Nutzer lesen Draft-Berechtigung-Zeilen.
• Reduktion-Codes mit neuer Bedeutung wiederverwenden.
• ADMIN- / Break-Glass-Accounts undokumentiert im Produkt.
• Kein Dual-Run beim Wechsel einer App auf die zentrale Matrix.
• Katalog zeigt Richtlinie-Dokumente, aber keine Lineage zur Matrix-Tabelle.

Checkliste

• Berechtigung-Assets sind klassifiziert und als Steuerprodukte registriert.
• Die kanonische Matrix lebt in der Steuerdatenbank mit veröffentlichten Views.
• Qlik / Power BI / Warehouse / API durchsetzen lokal aus diesem Vertrag.
• Keine Produktions-App stützt sich auf INLINE oder Mailbox-Excel als führende Quelle.
• Identity Mapping (IdP → analytischer User Key) ist dokumentiert und owned.
• Schreibpfad ist Stufe B/D (oder äquivalent) mit Validierung und Audit.
• Freigabe für Produktions-Grant-Änderungen, wo Risiko es verlangt.
• Automatisierte Tests decken Uniqueness, erforderliche ACCESS-Felder, Orphan Users/Keys ab.
• Rezertifizierungs-Checkliste ist geplant und mit Evidenz belegt.
• Break-Glass- / ADMIN-Zeilen sind inventarisiert und zeitlich begrenzt.
• Dual-Run und Abgleich abgeschlossen, bevor per-App-Matrizen retired werden.
• Lineage von Matrix → Apps ist im Katalog sichtbar.

Artefakt

Berechtigung Matrix Contract (Mindestfelder)

product_id: ctrl.access.entitlement_matrix
classification: entitlement
owner: security-or-data-governance-lead
steward: access-steward
custodian: analytics-platform
contract:
  canonical_view: control_access.v_entitlement_matrix
  grain: user_key × reduction_key × access_level
  keys: [user_key, reduction_key]
  attributes: [access_level, valid_from, valid_to, grant_reason, ticket_id]
enforcement_bindings:
  - engine: qlik-section-access
    view: control_access.v_qlik_section_access
  - engine: powerbi-rls
    view: control_access.v_pbi_rls_bridge
write_path:
  type: diy
  tier: D
recertification:
  cadence: quarterly
  aligns_with: access-review-cycle
break_glass:
  rows_documented: true
  max_duration_days: 7

Rezertifizierungs-Checkliste

• verantwortliche Person bestätigt, dass die Matrix weiterhin dem Richtlinie-Intent entspricht.
• Stichprobe von Grants zu Tickets / Joiner-Workflows zurückverfolgt.
• Leavers haben valid_to gesetzt; keine aktiven Orphans vs. IdP.
• ADMIN- / Break-Glass-Zeilen reviewed oder abgelaufen.
• Jeder gebundene App-Reload gegen die veröffentlichte View im letzten Fenster erfolgreich.
• Drift-Check: Inventar app-lokaler Overrides ist leer (oder mit Ablauf waivered).
• Audit-Stichprobe aufbewahrt (wer Grants seit letztem Review geändert hat).
• Katalog-Review-Datum und Evidenz-Links aktualisiert.

Tools

• Steuer-DB + DIY-Formular/Freigabe aus Teil 7 — bevorzugter Schreibpfad für Berechtigungs.
• Qlik Section Access / Power BI RLS / Warehouse-Richtlinien — nur Durchsetzung.
• Katalog-Lineage — beweisen, welche Apps an welche Matrix-Version binden.
• Access-Review-Workflow-Tooling — planen und belegen (Access Recertification Workflow, wo genutzt).

Ressourcen

• Serie: Steuer- und Referenzdaten Deep Dive
• Produktbetrieb: Steuerdaten als Datenprodukte betreiben
• DIY: Einfache Stewardship-Lösungen selbst bauen
• Weiter: Von Inline und Excel zu governeden Steuerdaten migrieren
• Access Security Governance
• Fachlogik außerhalb der BI-Apps halten — SA als gültiges lokales Durchsetzung, nicht geteilte Wahrheit
• BI-Governance-Entscheidungen
• BI-Publish Deep Dive — RLS/OLS und Tool-Adapter durchsetzen diese Matrix, sie ersetzen sie nicht