Verwaltung der Datensicherheit mit Section Access

Section Access dient zur Kontrolle der Sicherheit einer Anwendung. Im Grund handelt es sich dabei um einen Teil des Datenladeskripts, dem Sie eine Sicherheitstabelle hinzufügen, um zu definieren, wer was anzeigen darf. Qlik Sense nutzt diese Informationen zum Beschränken des Datenbestands auf den angemessenen Umfang, wenn der Benutzer die Anwendung öffnet. Das bedeutet, dass ein Teil der Daten in der App je nach Benutzeridentität für den Benutzer ausgeblendet ist. Section Access ist eng in die Daten in der App integriert und stützt sich auf diese, um den Zugriff zu steuern. Diese Form der dynamischen Einschränkung des Datenbestands kann für Tabellenzeilen, -spalten oder eine Kombination aus beiden gelten. Weitere Informationen finden Sie unter Vertrauen und Sicherheit bei Qlik.

Abschnitte im Ladeskript

Die Datenzugriffssteuerung wird über eine oder mehrere Sicherheitstabellen verwaltet, die auf die gleiche Weise wie für andere Daten üblich geladen werden. Dadurch wird es möglich, diese Tabellen in einer Standarddatenbank oder in einer Kalkulationstabelle zu speichern. Die Skriptanweisungen, die die Sicherheitstabellen verwalten, werden innerhalb eines Autorisierungsabschnitts angegeben, welcher im Skript durch die Anweisung Section Access eingeleitet wird.

Falls ein Autorisierungsabschnitt im Skript definiert ist, muss der Teil des Skripts, der die App-Daten lädt, in einem anderen Abschnitt stehen, der durch die Anweisung Section Application eingeleitet wird.

Beispiel:

Section Access; Load * INLINE [ ACCESS, USERID, REDUCTION USER, AD_DOMAIN\ADMIN, * USER, AD_DOMAIN\A, 1 USER, AD_DOMAIN\B, 2 USER, AD_DOMAIN\C, 3 ADMIN, INTERNAL\SA_SCHEDULER, ]; Section Application; T1: Load *, NUM AS REDUCTION; LOAD Chr(RecNo()+ord('A')-1) AS ALPHA, RecNo() AS NUM AUTOGENERATE 3;

Beachten Sie, dass nach Änderungen am Ladeskript immer die Daten geladen werden müssen, damit die Änderungen in Kraft treten.

Section Access-Systemfelder

Die Berechtigungsstufen werden den Benutzern in einer oder mehreren Sicherheitstabellen zugewiesen, die im Section Access-Teil des Skripts geladen werden. Diese Tabellen müssen mindestens zwei Systemfelder enthalten: ACCESS, das Feld, das die Berechtigungsstufe definiert, und USERID oder USER.EMAIL . Andere optionale Systemfelder können je nach Anwendungsfall hinzugefügt werden. Nachfolgend finden Sie eine komplette Liste der Section Access-Systemfelder.

ACCESS

Berechtigungsstufe des Anwenders.

Der Zugriff auf Qlik Sense-Apps kann bestimmten Benutzern gewährt werden. In der Sicherheitstabelle können Benutzer den Berechtigungsstufen ADMIN oder USER zugewiesen werden. Ein Benutzer mit ADMIN-Rechten hat Zugriff auf alle Daten der App, sofern dieser nicht durch die Sicherheitstabelle beschränkt ist. Benutzer mit USER-Rechten können nur auf Daten zugreifen, wie sie in der Sicherheitstabelle definiert sind. Ist einem Anwender keine gültige Berechtigungsstufe zugeordnet, kann er die App nicht öffnen.

Wenn Section Access in einem Ladeszenario verwendet wird, benötigt INTERNAL\SA_SCHEDULER, der der Scheduler-Dienstbenutzer ist, ADMIN-Zugriff, um die Ladevorgänge durchzuführen. Hier ein Beispiel:

Section Access; LOAD * inline [ ACCESS, USERID ADMIN, INTERNAL\SA_SCHEDULER ];

Wenn Sie das Konto INTERNAL\SA_SCHEDULER nicht verwenden möchten, informieren Sie sich unter Verwenden des Wechsels der Benutzeridentität zum Laden von Daten über eine alternative Methode.

Wenn Abschnittszugriff im Szenario der Generierung einer On-Demand-App (ODAG) in der Vorlagen-App verwendet wird, muss der INTERNAL\SA_API-Benutzer als ADMIN in der Abschnittszugriffstabelle enthalten sein. Hier ein Beispiel:

Section Access; LOAD * inline [ ACCESS, USERID ADMIN, INTERNAL\SA_API ];

USERID

Enthält einen String, der einem Qlik Sense Domänennamen und Benutzernamen entspricht. Qlik Sense prüft die Anmeldedaten des Proxys-Diensts und vergleicht sie mit dem Wert dieses Felds.

Ein Platzhalterzeichen (*) wird als alle Benutzer interpretiert, vorbehaltlich weiterer in der Sicherheitstabelle angegebener Bedingungen. Beispiel: In der folgenden Sicherheitstabelle können Benutzer, die zu den Qlik Sense Mandantenadministratoren gehören, alle aufgelisteten REDUCTION-Werte sehen.

Section Access; LOAD * INLINE [ ACCESS, USERID, GROUP, REDUCTION ADMIN, *, Qlik Sense Tenant Admins, * USER, QLIK-POC\SOMEOTHERUSER1, *, 1 USER, QLIK-POC\SOMEOTHERUSER2, *, 2 ... ];

USERID und NTNAME verwenden die gleichen Authentifizierungsinformationen. Daher ist es nicht erforderlich, beide in der gleichen Zeile in der Sicherheitstabelle zu prüfen. Der Unterschied zwischen den beiden Feldern ist, dass mit NTNAME auch Gruppen geprüft werden.

NTNAME

NTNAME ist ein veraltetes QlikView Feld, und es wird empfohlen, USERID zu verwenden, wenn QlikView nicht die gleiche Sicherheitstabelle verwendet.

Ein Feld, das eine Zeichenfolge enthalten sollte, die einem Windows NT-Domänenbenutzernamen oder -gruppennamen entspricht. Wenn ein anderes Authentifizierungssystem verwendet wird, sollte es den Namen eines authentifizierten Benutzers enthalten. Qlik Sense ruft die Anmeldedaten vom Betriebssystem ab und vergleicht sie mit dem Wert dieses Felds.

GROUP

Enthält einen String, der einer Gruppe in Qlik Sense entspricht. Qlik Sense ordnet den vom Proxy-Dienst bereitgestellten Benutzer nach Abgleich mit dieser Gruppe zu.

SERIAL

SERIAL ist ein veraltetes QlikView Feld und wird nicht verwendet, wenn Sie nur Qlik Sense verwenden.

Enthält einen String, der der Plattform entspricht. Wenn das Feld den String ‘QLIKSENSE’ oder einen Platzhalter ‘*’ enthält, kann der Zugriff abhängig von den anderen Feldern in der Sicherheitstabelle gewährt werden.

Wenn das Feld SERIAL eine Lizenznummer enthält, verweigert die Section Access-Zeile den Zugriff auf das Dokument. Diese Einstellung ist nur in QlikView gültig.

OMIT

Enthält den Namen des Felds, das für diesen speziellen Benutzer ausgelassen werden soll. Darf der Anwender alle Felder sehen, bleibt dieses Feld leer. Es können die üblichen Wildcards verwendet werden.

Es wird empfohlen, OMIT nicht auf Schlüsselfelder anzuwenden. Ausgelassene Schlüsselfelder sind im Datenmodell sichtbar, aber der Inhalt ist nicht verfügbar, was für einen Benutzer verwirrend erscheinen mag. Außerdem kann die Anwendung von OMIT auf Felder, die in einer Visualisierung verwendet werden, für Benutzer, die keinen Zugriff auf die ausgelassenen Felder haben, zu einer unvollständigen Visualisierung führen.

Verwalten des Benutzerzugriffs auf eine App

Section Access kann in seiner einfachsten Form verwendet werden, um den Zugriff bestimmter Benutzer auf eine App einzuschränken. Benutzern wird der Zugriff auf eine App durch Ausschluss verweigert. Wenn also eine bestimmte Benutzer-ID nicht in der Sicherheitstabelle aufgelistet ist, kann der betreffende Benutzer nicht auf die App zugreifen. Die einzige Ausnahme für diese Regel gilt, wenn dem Feld USERID in einer der Zeilen in der Sicherheitstabelle ein Platzhalter (*) zugewiesen ist. Ein Platzhalter bedeutet in diesem Fall, dass alle authentifizierten Benutzer auf die App zugreifen können. Im folgenden Beispiel geht es um eine Sicherheitstabelle mit einer Liste von Benutzer-IDs:

Section Access; LOAD * inline [ ACCESS, USERID ADMIN, AD_DOMAIN\ADMIN USER, AD_DOMAIN\A USER, AD_DOMAIN\B ]; Section Application;

Verwalten des Benutzerzugriffs auf spezifische Daten einer App

Die dynamische Dateneinschränkung schränkt den Zugriff auf Zeilen und Spalten in den Datentabellen in Qlik Sense Apps ein, nachdem ein Benutzer für den Zugriff auf die App selbst autorisiert wurde.

Verwalten des Zugriffs auf Daten auf Zeilenebene

Schränken Sie den Zugriff auf Daten auf Zeilenebene ein, indem Sie eine Dateneinschränkungsspalte zur Sicherheitstabelle im Zugriffsabschnitt des Ladeskripts hinzufügen. Bestimmte Datensätze (Zeilen) können für Benutzer ausgeblendet werden, indem die Section Access-Daten mit den reellen Daten verknüpft werden. Die Auswahl der anzuzeigenden bzw. auszuschließenden Daten wird dadurch gesteuert, dass ein oder mehrere Einschränkungsfelder mit gemeinsamen Namen in den Teilen Section Access und Section Application des Skripts vorhanden sind. Nach der Benutzeranmeldung gleicht Qlik Sense die Auswahlen in Einschränkungsfeldern im Zugriffsabschnittt mit allen Feldern im Anwendungsabschnitt mit genau denselben Feldnamen (Feldnamen müssen großgeschrieben werden) ab. Nach abgeschlossener Auswahl werden alle von diesen Auswahlen ausgeschlossenen Daten dauerhaft in Qlik Sense für den Benutzer ausgeblendet. Wenn ein Platzhalter (*) als Feldwert in der Dateneinschränkungsspalte verwendet wird, wird er so interpretiert, dass er den Benutzern den Zugriff auf Datensätze gewährt, die mit allen ausgewählten Einschränkungsfeldern in der Sicherheitstabelle verknüpft sind.

Wenn Qlik Sense das Einschränkungsfeld im Abschnittszugriff mit Feldern im Datenmodell vergleicht, werden die folgenden Verhaltensweisen erwartet:

Wenn ein Feldwert im Datenmodell mit dem Einschränkungsfeld im Abschnittszugriff übereinstimmt, wird die App geöffnet und zeigt Daten an, die eine Übereinstimmung mit dem angegebenen Benutzer aufweisen. Andere Daten werden ausgeblendet.
Wenn der Einschränkungsfeldwert mit keinen Werten im Datenmodell übereinstimmt, wird die App für einen regulären USER nicht geöffnet. Sie wird aber ohne Einschränkungen für einen Benutzer geöffnet, der als ADMIN gekennzeichnet ist.

Es wird nicht empfohlen, im Abschnittszugriff mehrere Einschränkungsfelder zu verwenden, da dadurch andere Zugriffskombinationen als beabsichtigt zugelassen werden.

Das Platzhalterzeichen * in der Dateneinschränkungsspalte bezieht sich nur auf alle Werte in der Sicherheitstabelle. Wenn in Section Application Werte vorhanden sind, die in der Einschränkungsspalte der Sicherheitstabelle nicht verfügbar sind, werden sie eingeschränkt.

Alle Feldnamen, die für die Übermittlung oben herangezogen werden, und alle Feldwerte in diesen Feldern müssen in Großbuchstaben geschrieben sein, da alle Feldnamen und Feldwerte standardmäßig in Access Section in Großbuchstaben konvertiert werden.

Wenn Sie das Laden des Skripts in einer Qlik Management Console-Aufgabe aktivieren möchten, ist standardmäßig der INTERNAL\SA_SCHEDULER-Kontobenutzer mit ADMIN-Zugriff erforderlich. Wenn Sie das Konto INTERNAL\SA_SCHEDULER nicht verwenden möchten, informieren Sie sich unter Verwenden des Wechsels der Benutzeridentität zum Laden von Daten über eine alternative Methode.

Beispiel: Einschränkung der Daten auf Zeilenebene über Benutzeridentität

Section Access; Authorization: LOAD * inline [ ACCESS, USERID, REDUCTION ADMIN, AD_DOMAIN\ADMIN, * USER, AD_DOMAIN\A, 1 USER, AD_DOMAIN\B, 2 USER, AD_DOMAIN\C, * ADMIN, INTERNAL\SA_SCHEDULER, * ]; Section Application; T1: LOAD *, NUM AS REDUCTION; LOAD RecNo() AS NUM AUTOGENERATE 3;

In diesem Beispiel existiert das Feld REDUCTION (in Großbuchstaben) nun in exakt gleicher Schreibweise in Section Access und in Section Application (auch alle Feldwerte sind in Großbuchstaben geschrieben). Normalerweise werden diese beiden Felder getrennt verarbeitet. Durch Verwendung von Section Access werden diese Felder jedoch verknüpft und die Anzahl der Datensätze, die dem Benutzer angezeigt werden, verringert.

Dadurch ergibt sich Folgendes:

Benutzer ADMIN kann alle Felder, aber nur die Datensätze sehen, die andere Benutzer sehen können, wenn REDUCTION = 1 oder REDUCTION =2.
Benutzer A kann alle Felder sehen, aber nur jene Datensätze, die mit REDUCTION=1 verknüpft sind.
Benutzer B kann alle Felder sehen, aber nur jene Datensätze, die mit REDUCTION=2 verknüpft sind.
Benutzer C kann alle Felder, aber nur die Datensätze sehen, die andere Benutzer sehen können, wenn REDUCTION = 1 oder REDUCTION =2.

Verwalten des Zugriffs auf Daten auf Spaltenebene

Schränken Sie den Zugriff auf Daten auf Spaltenebene ein, indem Sie ein OMIT-Systemfeld zur Sicherheitstabelle im Section Access-Skript hinzufügen. Das folgende Beispiel baut auf dem vorigen Beispiel auf, in dem eine Dateneinschränkung auf Zeilenbasis bereits eingerichtet ist.

Beispiel: Spaltenbasierte Dateneinschränkung über Benutzeridentität

Section Access; LOAD * inline [ ACCESS, USERID, REDUCTION, OMIT ADMIN, AD_DOMAIN\ADMIN, *, USER, AD_DOMAIN\A, 1, USER, AD_DOMAIN\B, 2, NUM USER, AD_DOMAIN\C, 3, ALPHA ADMIN, INTERNAL\SA_SCHEDULER, *, ]; Section Application; T1: LOAD *, NUM AS REDUCTION; LOAD Chr( RecNo()+ord('A')-1) AS ALPHA, RecNo() AS NUM AUTOGENERATE 3;

Das Feld OMIT in Section Access definiert die Felder, die dem Benutzer nicht angezeigt werden sollen.

Dadurch ergibt sich Folgendes:

Der ADMIN-Anwender kann alle Felder, aber nur die Datensätze sehen, die andere Anwender in diesem Beispiel sehen können, wenn REDUCTION 1, 2 oder 3 ist.
Benutzer A kann alle Felder sehen, aber nur jene Datensätze, die mit REDUCTION=1 verknüpft sind.
Benutzer B kann alle Felder mit Ausnahme von NUM und nur solche Datensätze sehen, die mit REDUCTION=2 verknüpft sind.
Benutzer C kann alle Felder mit Ausnahme von ALPHA und nur solche Datensätze sehen, die mit REDUCTION=3 verknüpft sind.

Für einige Visualisierungen gelten minimale Datenanforderungen, die erfüllt sein müssen, damit die Visualisierung gerendert wird. Daher kann „Unvollständige Visualisierung“ angezeigt werden, wenn ein Feld auf Spaltenebene aus der Datenansicht des Benutzers ausgeblendet ist.

Verwalten des Zugriffs auf Benutzergruppen

Section Access bietet die Option, die den Benutzern angezeigte Datenmenge über Gruppenmitgliedschaft einzuschränken. Um die Daten mithilfe von Benutzergruppen einzuschränken, fügen Sie den Feldnamen GROUP zur Sicherheitstabelle in Access Section hinzu und definieren Sie Werte für das Feld GROUP.

Beispiel: Einschränkung des Datenbestands über Benutzergruppen

Section Access; LOAD * inline [ ACCESS, USERID, GROUP, REDUCTION, OMIT USER, *, ADMIN, *, USER, *, A, 1, USER, *, B, 2, NUM USER, *, C, 3, ALPHA USER, *, GROUP1, 3, ADMIN, INTERNAL\SA_SCHEDULER, *, *, ]; section application; T1: LOAD *, NUM AS REDUCTION; LOAD Chr( RecNo()+ord('A')-1) AS ALPHA, RecNo() AS NUM AUTOGENERATE 3;

Dadurch ergibt sich Folgendes:

Benutzer, die zur Gruppe ADMIN gehören, können alle Felder, aber nur die Datensätze sehen, die andere Benutzer in diesem Beispiel sehen können, wenn REDUCTION 1, 2 oder 3 ist.
Benutzer aus der Gruppe A können die mit REDUCTION=1 verknüpften Daten über alle Felder hinweg anzeigen.
Benutzer aus der Gruppe B können alle mit REDUCTION=2 verknüpften Daten anzeigen, aber nicht diejenigen im Feld NUM
Benutzer aus der Gruppe C können alle mit REDUCTION=3 verknüpften Daten anzeigen, aber nicht diejenigen im Feld ALPHA
Benutzer aus der Gruppe GROUP1 können alle mit REDUCTION=3 verknüpften Daten über alle Felder hinweg anzeigen

Qlik Sense vergleicht den Benutzer mit UserID und ordnet den Benutzer im Abgleich mit den Gruppen in der Tabelle zu. Wenn der Benutzer zu einer Gruppe gehört, der Zugriff eingeräumt ist, oder der Benutzer übereinstimmt, kann er auf die App zugreifen.

Verwenden des Wechsels der Benutzeridentität zum Laden von Daten

Standardmäßig wird das interne Systemkonto SA_SCHEDULER zum Ausführen von Ladeaufgaben verwendet. Dieses Konto hat eine hohe Berechtigungsstufe und kann rein technisch jede Datenquelle verwenden. Es gibt jedoch eine Einstellung in der QMC, die den Wechsel der Benutzeridentität verwendet, um Ladeaufgaben mit den Berechtigungen des App-Besitzers anstelle des internen Systemkontos auszuführen. Wenn diese Einstellung konfiguriert wird, wird der App-Besitzer und nicht SA_SCHEDULER für Ladevorgänge verwendet. Das bedeutet, dass Sie nicht SA_SCHEDULER in der Section Access-Tabelle hinzufügen, sondern stattdessen den App-Besitzer. Innerhalb einer Aufgabenkette können Apps verschiedene Besitzer mit Berechtigungen für Quellen haben, abhängig von den Zugriffsrechten des jeweiligen Besitzers. Weitere Informationen finden Sie unter Dienstcluster (nur auf Englisch).

Verwalten von Benutzerzugriff in einer Multi-Cloud-Umgebung

Eine Qlik Sense-Multi-Cloud-Umgebung umfasst eine Kombination aus Benutzerauthentifizierungsmechanismen. In der Regel wird in Qlik Sense Enterprise on Windows die USERID in der Section Access-Sicherheitstabelle vom Proxydienst verifiziert. In Qlik Cloud übernimmt ein Identitätsanbieter diese Authentifizierungsrolle. Infolgedessen funktioniert Section Access, der für eine lokale Umgebung wie Qlik Sense Enterprise on Windows eingerichtet wurde, in einer Cloud-Umgebung nicht.

Wenn Sie einen OIDC-Identitätsanbieter (Qlik IdP oder benutzerdefinierter IdP) mit Qlik Cloud verwenden, wird der subject claim zum Identifizieren von Benutzern bei der Anmeldung verwendet. Mit Section Access wird der Wert des Felds USERID in der Sicherheitstabelle mit dem Wert von subject claim verglichen. Wenn Sie Ihren Mandanten einrichten, vergewissern Sie sich, dass der SAM-Kontoname dem subject claim Ihres Identitätsanbieters zugeordnet ist. Beispiel: Wenn Ihr SAM-Kontoname AD_DOMAIN\Dev lautet, legen Sie den subject claim auf AD_DOMAIN\Dev fest. Wenn Sie den Wert des subject claim des IdP anzeigen möchten, hängen Sie /api/v1/diagnose-claims an die Mandanten-URL im Browser an, zum Beispiel your-tenant.us.qlikcloud.com/api/v1/diagnose-claims. In der JSON-Antwort wird der subject claim als sub bezeichnet.

Wenn Sie den SAM-Kontonamen nicht verwenden können, gibt es eine alternative Möglichkeit zur Authentifizierung eines Benutzers. Da E-Mail-Adressen sich in der Regel in verschiedenen Umgebungen nicht ändern, können Sie das Feld USER.EMAIL anstelle von USERID in der Sicherheitstabelle verwenden. Das folgende Beispiel zeigt, wie die Sicherheitstabelle aussehen könnte:

ACCESS	USERID	USER.EMAIL	Kommentar	COUNTRY
USER	ABC\Joe	*	Access-on-prem	Vereinigte Staaten
USER	*	joe.smith@example.com	Access-in-cloud	Vereinigte Staaten
USER	ABC\Ursula	*	Access-on-prem	Deutschland
USER	*	ursula.schultz@example.com	Access-in-cloud	Deutschland
USER	ABC\Stefan	*	Access-on-prem	Sweden
USER	*	stefan.svensson@example.com	Access-in-cloud	Sweden

Autorisierungsskript:

Section Access; LOAD * INLINE [ ACCESS, USERID, USER.EMAIL, COUNTRY USER, ABC\Joe, *, United States USER, *, joe.smith@example.com, United States USER, ABC\Ursula, *, Germany USER, *, ursula.schultz@example.com, Germany USER, ABC\Stefan, *, Sweden USER, *, stefan.svensson@example.com, Sweden ];

Beachten Sie, dass für jeden Benutzer zwei Einträge vorhanden sind: einer für lokalen Zugriff und einer für Cloud-Zugriff. Die Platzhalter stellen sicher, dass nur die relevanten Autorisierungsfelder verwendet werden. In diesem Feld wird COUNTRY als Feld für die Einschränkung des Datenbestands verwendet.

Verwenden von Section Access und Insight Advisor Chat

Um Apps, die Section Access verwenden, in Insight Advisor Chat verfügbar zu machen, müssen Sie im Section Access-Skript sicherstellen, dass die folgenden Dienstbenutzer Administratorzugriff haben:

INTERNAL/sa_repository: Damit wird das Section Access-Skript dem Repository-Dienst zur Kontrolle des Benutzerzugriffs zur Verfügung gestellt.
INTERNAL/sa_scheduler: Damit kann die App Ladevorgänge mithilfe von QMC-Aufgaben durchführen.

Wenn sensible Informationen in App-Namen, Feldnamen oder Master-Elementnamen enthalten sind, können diese offengelegt werden, wenn Sie Apps, die Section Access verwenden, für Insight Advisor Chat zur Verfügung stellen. App-Vorschläge für Abfragen umfassen Apps in Streams, auf die Benutzer Zugriff haben. Dazu können auch Apps gehören, auf welche die Benutzer im Section Access der App keinen Zugriff haben. Eine Auswahl dieser Apps hat aber keine Aktion zur Folge. Wenn Sie auf Dimensionen oder Kennzahlen klicken, um die verfügbaren Elemente einer App anzuzeigen, die Section Access verwendet, können Benutzern Elemente angezeigt werden, auf die sie keinen Zugriff haben. Durch Klicken auf diese Elemente erhalten die Benutzer aber keine Daten.

Hier ein Beispiel:

Section Access; LOAD * inline [ USERID ,ACCESS INTERNAL\sa_repository ,ADMIN INTERNAL\sa_scheduler ,ADMIN DOMAINNAME\user1 ,ADMIN DOMAINNAME\user2 ,USER DOMAINNAME\user3 ,USER ];

Nachdem diese Benutzer in das Section Access-Skript aufgenommen wurden, können Sie die App für Insight Advisor Chat bereitstellen. Nachdem die App geladen wurde, ist sie in Insight Advisor Chat verfügbar.

Anweisungen und Tipps für die Verwendung von Section Access

Die folgenden wichtigen Fakten und nützlichen Hinweise zu Section Access sollten dem Benutzer bekannt sein.

Alle Feldnamen und Werte im Zugriffsabschnitt unter LOAD oder SELECT müssen in Großbuchstaben geschrieben werden. Konvertieren Sie alle Feldnamen mit Kleinbuchstaben in der Datenbank in Großbuchstaben, indem Sie die Funktion Upper verwenden, bevor Sie das Feld durch die LOAD- oder SELECT-Anweisung lesen.
Weitere Informationen finden Sie unter Upper - Skript- und Diagrammfunktion.
Sie können die hier aufgeführten Section Access-Systemfeldnamen nicht als Feldnamen in Ihrem Datenmodell verwenden.
Apps müssen veröffentlicht werden, bevor Section Access-Steuerelemente angewendet werden können. Beim Laden der App werden keine neuen oder geänderten Section Access-Skripts angewendet.
Ein Schnappschuss zeigt Daten entsprechend den Zugriffsrechten des Benutzers an, der den Schnappschuss erstellt. Der Schnappschuss kann daraufhin in einer Story freigegeben werden. Wenn Benutzer jedoch aus einer Story zur Visualisierung zurückkehren, um die Daten in der App "live" anzusehen, gelten die Zugriffsbeschränkungen der eigenen Benutzerrechte.
Weisen Sie Master-Dimensionswerten keine Farben zu, wenn Sie Section Access verwenden oder mit vertraulichen Daten arbeiten, da die Werte durch die Farbkonfiguration offengelegt werden könnten.
Damit vertrauliche Daten nicht offengelegt werden, entfernen Sie alle angehängten Dateien mit Section Access-Einstellungen aus der App, bevor Sie sie veröffentlichen. Angehängte Dateien werden beim Veröffentlichen der App eingeschlossen. Wenn die veröffentlichte App kopiert wird, sind die angehängten Dateien auch in der Kopie enthalten. Wenn den angehängten Datendateien jedoch Abschnittszugriffseinschränkungen zugewiesen wurden, bleiben diese Einstellungen beim Kopieren der Daten nicht erhalten. Das bedeutet, dass alle Benutzer der kopierten App alle Daten in den angehängten Daten sehen können.
Ein Platzhalter (*) wird als alle (aufgelisteten) Werte des Felds in der Tabelle interpretiert. Werden Wildcards in einem der sicherheitsrelevanten Felder (USERID, GROUP) verwendet, interpretiert das Programm, dass sie für alle (auch für nicht explizit aufgeführte) Werte des Felds stehen.
Sicherheitsfelder können in verschiedenen Tabellen platziert werden.
Beim Laden von Daten aus einer QVD-Datei verlangsamt die Upper-Funktion die Ladegeschwindigkeit.
Wenn Sie sich durch Festlegen von Section Access selbst aus der App ausgesperrt haben, können Sie die App ohne Daten öffnen und den Zugriffsabschnitt im Datenladeskript bearbeiten. Dazu müssen Sie Zugriff auf das Datenladeskript haben, um es bearbeiten und neu laden zu können.
Weitere Informationen finden Sie unter Öffnen einer App ohne Daten.
Durch Laden von Dateien mit Hilfe des binary-Befehls werden Zugriffsbeschränkungen auf die neue Qlik Sense-App übertragen.

Hat diese Seite Ihnen geholfen?

Wenn Sie Probleme mit dieser Seite oder ihren Inhalten feststellen – einen Tippfehler, einen fehlenden Schritt oder einen technischen Fehler –, teilen Sie uns bitte mit, wie wir uns verbessern können!

Geben Sie hier Ihr Feedback ab