Section Access in Qlik Cloud: ein prüfbares Referenzbeispiel

Versions- und Quellenstand: Qlik Cloud (SaaS), 23.10.2026. Kein festes Qlik-Sense-Client-Managed-Release. Cloudoberfläche und Funktionsumfang können sich auch bei kleineren Updates ändern; regionale Rollouts, Subscription und Tenantkonfiguration vor Umsetzung prüfen. Installierte Gateway-/Connectorversionen separat protokollieren. Redaktionell gegen Herstellerhilfe geprüft, nicht im Kundentenant ausgeführt.

Namensbeispiel lesen: VERTRIEB-ENTWICKLUNG-APPS bedeutet Fachbereich Vertrieb → Entwicklungsumgebung → Analyse-Apps. Entsprechend steht VERTRIEB-PRODUKTION-APPS für freigegebene produktive Apps. Die Namen sind frei gewählte Beispiele; sie erzeugen keine Berechtigungen. Verwende in Skripten und im Register exakt den Namen eures tatsächlich angelegten Bereichs.

Wie du das Script liest, bevor du es einsetzt

Der fachliche Zusammenhang ist die KPI-Auswertung von Monatsumsatz und Wachstum. Section Access begrenzt den verfügbaren Datenumfang und kann dadurch auch die sichtbare Umsatzsumme verändern. Vergleiche Kennzahlen nur für denselben erlaubten Umfang.

Das folgende kleine Sicherheitslabor prüft Zeilenreduktion und das Auslassen eines Felds. CASE_ID ist hier eine synthetische Prüfbelegkennung, AMOUNT ein Prüfwert; 120 und 250 sind nicht die Monatsumsätze der Grundlagenserie. CONTACT_EMAIL ist ein absichtlicher Testmarker für OMIT. Dass ein Testkonto diesen Marker sehen kann, belegt technische Wirkung und begründet noch keinen Kontaktfeldbedarf für einen KPI.

Section Access ist die Berechtigungstabelle innerhalb der App. Sie ergänzt den Zugang über den Bereich. Ein Konto muss zunächst die App erreichen dürfen; anschließend wird das geladene Modell nach den passenden Berechtigungszeilen eingeschränkt. Eine WHERE-Bedingung für alle Daten im Ladescript ist dagegen eine allgemeine Ladefilterung und noch keine benutzerabhängige Reduktion.

Beide Tabellen müssen beim Reduktionsschlüssel zusammenpassen. NORTH und SOUTH sind im Labor ausdrücklich großgeschrieben. Ein irrtümliches RegionKey auf einer Seite statt REGION_KEY ist kein kosmetischer Fehler. Prüfe im Modell Feldnamen und geladene Werte, bevor du die App für Testkonten öffnest.

Schritt für Schritt: das vorhandene Labor reproduzieren

1. Erstelle eine neue, wiederherstellbare Labor-App in VERTRIEB-ENTWICKLUNG-APPS. Verwende keine produktive App als ersten Versuch. Bereite die drei realen Testidentitäten vor und protokolliere ihre tatsächlich empfangenen E-Mail-Werte.
2. Ersetze alle .INVALID-Adressen im folgenden Script durch die eigenen zulässigen Laborwerte. Lasse die synthetischen Prüfbeleg- und Markerwerte unverändert; diese stehen für Geschäftsdaten, nicht für Login-Identitäten.
3. Lade mit der vorgesehenen Ausführungsidentität und kontrolliere den Erfolg. Schließe die Entwicklungssitzung und teste mit getrennten gewöhnlichen Consumer-Konten. Ein bloßer Benutzerfilter in einem Admin-Dashboard ist kein Identitätswechsel.
4. Erstelle eine Tabelle mit CASE_ID und AMOUNT. NORTH muss einen Prüfbeleg mit 120, SOUTH einen Prüfbeleg mit 250 sehen. Prüfe mit NORTH das ausgelassene Kontaktfeld; ein Diagramm, das dieses Feld voraussetzt, ist dafür allein kein guter Zeilentest.
5. Ändere im Labor die NORTH-Berechtigung auf einen unbekannten Schlüssel und teste den dokumentierten Ablehnungsfall mit USER. Führe ihn nicht ausschließlich als ADMIN aus. Stelle danach den gültigen Wert wieder her und lade erneut.
6. Wiederhole nach Veröffentlichung mit der echten Ziel-App-ID. Verändere anschließend nur die Entwicklungsberechtigung und zeige, dass diese Änderung nicht magisch jede veröffentlichte Fassung aktualisiert. Wende den beschriebenen Reload-/Publish-Weg an und dokumentiere den neuen Wirksamkeitszeitpunkt.

Aufgabe mit mehreren Dimensionen: Soll eine Person nur NORTH/Produkt A und SOUTH/Produkt B sehen, teste ausdrücklich, dass NORTH/B und SOUTH/A nicht hinzukommen. Entwirf dafür eine Zuordnung zulässiger Kombinationen mit einem gemeinsamen Berechtigungsschlüssel. Verwende nicht ungeprüft zwei unabhängige Wertefelder als vermeintliche Paarzuordnung.

Voraussetzungen und bewusst kleiner Scope

Das Beispiel nutzt ausschließlich erfundene Daten. Es zeigt zwei Regionen und ein zusätzliches Klartextfeld. Es ist ein Labor, kein ungeprüft übernehmbares Produktionsscript. Zuerst eine wiederherstellbare Test-App in einem eingeschränkten Shared Space verwenden. Der echte Tenant bestimmt die empfangene Identität; die Beispieladressen müssen durch explizit freigegebene Testidentitäten ersetzt werden.

Space-Zugriff erlaubt den Einstieg; Section Access begrenzt die App-Daten. USER.EMAIL vergleicht die vom IdP gelieferte E-Mail. USERID bezieht sich in Cloud auf den Subject-Claim, nicht automatisch auf eine beliebige lokale AD-Schreibweise. GROUP hat zusätzliche Funktions-/Tarifgrenzen und verlangt eine überprüfte Gruppenauflösung.

Schritt für Schritt

1. Zwei Consumer und einen dedizierten Reload-/Testadministrator planen. Den tatsächlichen E-Mail-Claim sicher prüfen. Großschreibung der Reduktionswerte in Berechtigungstabelle und Anwendungsmodell konsistent halten.
2. Die Test-App sichern und das folgende eigene Lehrbeispiel einsetzen. Jede erlaubte Region steht ausdrücklich in der Tabelle; für das All-Regionen-Testkonto werden zwei Zeilen verwendet statt einer missverständlichen Stern-Regel.

Section Access;
AUTHORIZATION:
LOAD * INLINE [
ACCESS, USER.EMAIL, REGION_KEY, OMIT
ADMIN, RELOAD-LAB@EXAMPLE.INVALID, NORTH,
ADMIN, RELOAD-LAB@EXAMPLE.INVALID, SOUTH,
USER, NORTH-LAB@EXAMPLE.INVALID, NORTH, CONTACT_EMAIL
USER, SOUTH-LAB@EXAMPLE.INVALID, SOUTH,
];

Section Application;
CASES:
LOAD * INLINE [
CASE_ID, REGION_KEY, AMOUNT, CONTACT_EMAIL
LAB-101, NORTH, 120, ALPHA@EXAMPLE.INVALID
LAB-102, SOUTH, 250, BETA@EXAMPLE.INVALID
];

3. Mit der vorgesehenen Reload-Identität laden und frische Consumer-Sessions öffnen. North sieht ausschließlich LAB-101; das Feld CONTACT_EMAIL ist für North ausgelassen. South sieht LAB-102 einschließlich dieses Feldes. Das OMIT-Feld ist absichtlich kein Verknüpfungsschlüssel. Eine Visualisierung, die ein ausgelassenes Feld voraussetzt, kann unvollständig werden.
4. Einen normalen USER ohne passende Berechtigungszeile testen: kein Öffnen. Danach einen USER mit nicht vorhandenem Reduktionswert im Labor testen. Die normale Nutzerreduktion darf nicht durch einen ADMIN-Test ersetzt werden; ADMIN kann bei fehlendem Match anders reagieren und unter Umständen unreduziert öffnen.
5. Bei mehreren erlaubten Zuständigkeitskombinationen einen eindeutigen zusammengesetzten Berechtigungsschlüssel entwerfen und explizit mappen. Mehrere unabhängige Reduktionsfelder nicht ungeprüft kombinieren: damit können unerwünschte Kombinationen entstehen.
6. Erst nach erfolgreichem Einzelidentitätstest Gruppen verwenden. QlikCloudGroupMode bewusst wählen: 0 für IdP-Gruppen, 1 für Custom-Gruppen, 2 für beide. Namenskollisionen vermeiden. Die Hilfe nennt Einschränkungen unter anderem für Qlik Sense Business, Analytics Standard und Qlik IdP beim GROUP-Verfahren; vor Aktivierung die konkrete Subscription prüfen.
7. Rechteänderung im Script durch Reload wirksam machen. Bei Managed Spaces nicht nur die Entwicklungs-App ändern: die aktuelle Hilfe nennt Reload plus erneutes Publish mit Daten oder Publish ohne Daten plus Reload im Ziel. Den tatsächlich verwendeten Weg im Release-Nachweis protokollieren.

Keine Sternchen-Abkürzung für die Freigabe

* bedeutet in einem Reduktionsfeld nicht pauschal jeden irgendwann vorkommenden Quellwert. Leere Werte, Sternchen, Identitätsfelder und ADMIN haben unterschiedliche Semantik. Neue Region, mehrere Gruppen und entfernte Mitgliedschaft sind Pflichtfälle im Testplan. Eine Berechtigungstabelle aus QVD benötigt zudem den in der Hilfe beschriebenen nicht optimierten Ladeweg; nicht unbesehen ein beliebiges optimiertes LOAD übernehmen.

Abnahme

Der Test ist redaktionell entworfen, hier nicht gegen einen Kundentenant ausgeführt. Produktivabnahme braucht reale Testidentitäten und den eingesetzten Release-/Tarifstand. Weiter: Maskierung, QVDs und Ausgabepfade.

Quellen, Hilfe und Lernmaterial

• Qlik: Section Access
• Qlik: Custom and IdP groups
• Qlik Help: Section Access groups — Video
• Qlik: Section Access demonstration (2022)
• Qlik: What is new / staged rollouts

Bei Videos hat die aktuelle schriftliche Hilfe Vorrang. Externe Medien werden vom jeweiligen Anbieter bereitgestellt.