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 Cloud 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. Abschnittszugriff 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.

Alle im Abschnittszugriff aufgelisteten Feldnamen und Feldwerte werden immer in Großbuchstaben konvertiert. Daher müssen alle Felder, die Teil einer Datenbestandseinschränkung sind, in Großbuchstaben konvertiert werden, um den Angaben in der Abschnittszugriffsanweisung zu entsprechen, auch wenn sie sich außerhalb dieser Abschnittszugriffsanweisung befinden. Sie können alle Feldnamen mit Kleinbuchstaben in der Datenbank in Großbuchstaben konvertieren, indem Sie die Funktion „Upper“ verwenden, bevor das Feld durch die LOAD- oder SELECT-Anweisung gelesen wird.

Weitere Informationen finden Sie unter Upper - Skript- und Diagrammfunktion.

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, USER.EMAIL, REDUCTION USER, USER1@example.com, * USER, USER2@example.com, 1 USER, USER3@example.com, 2 ADMIN, USER4@example.com, ];Load * INLINE [ ACCESS, USER.EMAIL, REDUCTION USER, USER1@EXAMPLE.COM, * USER, USER2@EXAMPLE.COM, 1 USER, USER3@EXAMPLE.COM, 2 ADMIN, USER4@EXAMPLE.COM, ]; 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.

USERID

Enthält einen String, der einem Qlik Cloud-Benutzernamen entspricht. Qlik Cloud ruft die Anmeldedaten vom IdP-Antragsteller ab und vergleicht sie mit dem Wert dieses Felds. Eine alternative Möglichkeit zum Überprüfen der Benutzeridentität mit einer E-Mail-Adresse finden Sie unter USER.EMAIL. In Multi-Cloud-Umgebungen kann der IdP-Antragsteller Ihrer internen Windows-Identität zugeordnet sein. Wenn Qlik Account verwendet wird, kann der Antragsteller nicht der internen Windows-Identität zugeordnet werden. Der IdP-Antragssteller des Benutzers kann im Abschnitt Benutzer des Aktivitätscenters Verwaltung angezeigt werden.

Ein Wildcard-Zeichen (*) 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 sollte eine Zeichenfolge enthalten, die der NetBIOS-Version eines Windows NT-Domänenbenutzernamens oder -gruppennamens entspricht. Wenn ein anderes Authentifizierungssystem verwendet wird, sollte es den Namen eines authentifizierten Benutzers enthalten.

Qlik Cloud ruft die Anmeldedaten vom subject-Anspruch des Identitätsanbieters ab und vergleicht sie mit dem Wert dieses Felds.

USER.EMAIL

Enthält einen String, der einer Benutzer-E-Mail-Adresse entspricht. Qlik Cloud ruft diese Informationen vom Identitätsanbieter ab und vergleicht sie mit dem Wert dieses Felds.

GROUP

Enthält einen String, der einer Gruppe in Qlik Cloud entspricht. Qlik Cloud ruft die Informationen vom “groups”-Anspruch des Identitätsanbieters ab und vergleicht sie mit dem Wert dieses Felds.

Diese Funktion ist in Qlik Sense Business, Qlik Cloud Analytics Standard oder bei Verwendung des Qlik-Identitätsanbieters (IdP) nicht verfügbar.

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

Ein Benutzer mit USERID AD_DOMAIN\C kann die App nicht öffnen, weil diese Benutzer-ID nicht in der Sicherheitstabelle aufgelistet ist.

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-E-Mail-Adresse 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 USER.EMAIL 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, USER.EMAIL ADMIN, USER1@EXAMPLE.COM USER, USER2@EXAMPLE.COM USER, USER3@EXAMPLE.COM ]; Section Application;

Ein Benutzer mit USER.EMAIL USER4@example.com kann die App nicht öffnen, weil diese Benutzer-E-Mail-Adresse nicht in der Sicherheitstabelle aufgelistet ist.

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.

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

Section Access; Authorization: LOAD * inline [ ACCESS, USER.EMAIL, REDUCTION ADMIN, USER1@EXAMPLE.COM, * USER, USER2@EXAMPLE.COM, 1 USER, USER3@EXAMPLE.COM, 2 USER, USER4@EXAMPLE.COM, * ]; 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 USER1@EXAMPLE.COM kann alle Felder, aber nur die Datensätze sehen, die andere Benutzer sehen können, wenn REDUCTION = 1 oder REDUCTION =2.
Benutzer USER2@EXAMPLE.COM kann alle Felder sehen, aber nur jene Datensätze, die mit REDUCTION=1 verknüpft sind.
Benutzer USER3@EXAMPLE.COM kann alle Felder sehen, aber nur jene Datensätze, die mit REDUCTION=2 verknüpft sind.
Benutzer USER4@EXAMPLE.COM 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, USER.EMAIL, REDUCTION, OMIT ADMIN, USER1@example.com, *, USER, USER2@example.com, 1, USER, USER3@example.com, 2, NUM USER, USER4@example.com, 3, ALPHA ]; 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 USER1@example.com-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 USER2@example.com kann alle Felder sehen, aber nur jene Datensätze, die mit REDUCTION=1 verknüpft sind.
Benutzer USER3@example.com kann alle Felder mit Ausnahme von NUM und nur solche Datensätze sehen, die mit REDUCTION=2 verknüpft sind.
Benutzer USER4@example.com 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, AD_DOMAIN\DEV, *, *, ]; 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
Der Benutzer AD_DOMAIN\DEV kann alle Daten in allen Feldern anzeigen.

Qlik Cloud vergleicht den Benutzer mit UserID und ordnet den Benutzer gegenüber 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.

Laden von Daten in Qlik Cloud

Um Daten ohne Einschränkung des Datenbestands in Qlik Cloud in eine App zu laden, wird empfohlen, das Systemfeld USER.EMAIL in der Sicherheitstabelle zu verwenden. Der Wert für das Feld USER.EMAIL sollte die E-Mail-Adresse der Benutzer sein, die die App bearbeiten und laden können. Dies gilt für Apps in freigegebenen und in verwalteten Bereichen. Zum Beispiel:

Section Access; LOAD * inline [ ACCESS, USER.EMAIL, REDUCTION ADMIN, TEST@EXAMPLE.COM, * ];

In diesem Beispiel ist der Benutzer mit der E-Mail-Adresse test@example.com der ADMIN und kann die App laden.

Wenn Sie Gruppen verwenden, würde das folgende Beispiel sowohl für Qlik Sense als auch für Qlik Cloud funktionieren:

Section Access; LOAD * inline [ ACCESS, GROUP, REDUCTION ADMIN, DEVELOPERS, * ];

Sie können auch USERID in der Sicherheitstabelle dem subject claim des Identitätsanbieters zuordnen, wie im folgenden Beispiel gezeigt. Diese Konfiguration wird für die Migration von Qlik Sense zu Qlik Cloud und für Multi-Cloud-Umgebungen vorgeschlagen. Weitere Informationen zum Zuordnen der USERID zum subject claim finden Sie unter Verwalten von Benutzerzugriff in einer Multi-Cloud-Umgebung.

Section Access; LOAD * inline [ ACCESS, USERID, REDUCTION ADMIN, AD_DOMAIN\DEV, * ];

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- oder SAML-Identitätsanbieter (Qlik IdP oder benutzerdefinierter IdP) mit Qlik Cloud verwenden, wird der subject claim zum Identifizieren von Benutzern bei der Anmeldung verwendet. Mit Abschnittszugriff 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	Schweden
USER	*	STEFAN.SVENSSON@EXAMPLE.COM	Access-in-cloud	Schweden

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 jeder Benutzer über zwei Datensätze verfügt: einen für lokalen Zugriff und einen 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.

QlikView-Autorisierungsfelder

Aus Gründen der Abwärtskompatibilität erkennt Qlik Cloud die Autorisierungsfelder aus QlikView. Die USERID wird zwar in QlikView und Qlik Cloud unterschiedlich interpretiert, wird aber in Qlik Cloud genauso interpretiert wie in Qlik Sense: Sie wird mit dem Namen des authentifizierten Benutzers verglichen.

PASSWORD, NTSID und NTDOMAINSID

Wenn eines der Felder PASSWORD, NTSID und NTDOMAINSID verwendet wird und einen relevanten Wert enthält, wird der Zugriff auf das Dokument verweigert. Wenn das Feld einen Platzhalter (*) enthält, kann der Zugriff abhängig von den anderen Feldern in der Autorisierungstabelle gewährt werden.

SERIAL

Wenn das Feld SERIAL verwendet wird und eine Lizenznummer enthält, verweigert die Section Access-Zeile den Zugriff auf das Dokument. Wenn das Feld einen Platzhalter (*) enthält, kann der Zugriff abhängig von den anderen Feldern in der Autorisierungstabelle gewährt werden.

Zudem kann dieses Feld in Qlik Cloud zum Definieren der Umgebung verwendet werden. Wenn das Feld daher den String „QLIKCLOUD“ enthält, kann der Zugriff abhängig von den anderen Feldern in der Autorisierungstabelle gewährt werden.

Gemischte Umgebungen

Wenn Sie die gleiche Sicherheitstabelle in QlikView und in Qlik Cloud verwenden möchten, beachten Sie Folgendes:

• USERID hat in QlikView und Qlik Cloud unterschiedliche Bedeutungen, und ihre Verwendung kann Sicherheitsprobleme verursachen. Verwenden Sie stattdessen NTNAME oder kombinieren Sie sie mit SERIAL, wie weiter unten beschrieben.

• GROUP und Felder, die mit „USER.“ beginnen, beispielsweise „USER.NAME“ und „'USER.EMAIL“, sind bzw. werden Autorisierungsfelder in Qlik Cloud. Wenn Sie diese Felder in Ihrem Section Access verwenden, kann der Zugriff in Qlik Cloud verweigert werden.

• PASSWORD, NTSID und NTDOMAINSID können in Qlik Cloud nicht verwendet werden. Der Zugriff wird verweigert, es sei denn, es wird ein Platzhalter verwendet.

• SERIAL kann nicht zum Prüfen der Lizenznummer in Qlik Cloud verwendet werden. Wenn das Feld aber den String „QLIKCLOUD“ enthält, kann der Zugriff gewährt werden. Dies bedeutet, dass eine Sicherheitstabelle wie die Folgende vorliegen kann, in der Zeile 1 Zugriff in QlikView (aber nicht in Qlik Cloud) gewährt, während Zeile 2 Zugriff in Qlik Cloud (aber nicht in QlikView) gewährt.

Sicherheitstabelle
Zeile	SERIAL	USERID	Kommentar
1	4600 0123 4567 8901	*	Gewährt Zugriff auf die korrekte Lizenznummer in QlikView.
2	QLIKCLOUD	JOHN DOE	Gewährt Zugriff auf den korrekten Benutzer in Qlik Cloud.

Autorisierungsskript:

Section Access; LOAD * INLINE [ ACCESS, USERID, SERIAL USER, *, 4600 0123 4567 8901 USER, JOHN DOE, QLIKCLOUD ];

Verwenden von Section Access und Insight Advisor Chat

Apps, die Section Access nutzen, verwenden einen Indexbenutzer, um zu bestimmen, wie viele Informationen Insight Advisor Chat aus der App abruft. Der Indexbenutzer sollte der Benutzer mit den höchsten Zugriffsrechten auf die App im Section Access-Skript sein. Die an Endbenutzer bereitgestellten Daten unterliegen aber nach wie vor den Einschränkungen durch Section Access.

Eine visuelle Demo der Verwendung von Abschnittszugriff und Insight Advisor Chat finden Sie unter:

Verwenden von Abschnittszugriff und Insight Advisor Chat

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. Zu App-Vorschlägen für Abfragen zählen Apps in Bereichen, auf die die Benutzer Zugriff haben. Dazu gehören möglicherweise Apps, auf die Benutzer keinen Zugriff haben, im Abschnittszugriff der App. 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.

Standardmäßig ist der App-Besitzer der Indexbenutzer. Sie können den Indexbenutzer in Details ändern.

Gehen Sie folgendermaßen vor:

Navigieren Sie in Qlik Cloud zur App.
Klicken Sie in der App auf und wählen Sie Details aus.
Wählen Sie unter Indexbenutzer den Indexbenutzer aus.
Klicken Sie auf Zurück.
Klicken Sie in der App auf und wählen Sie Neu laden aus.

Verwenden von QVDs mit Abschnittszugriff

QVD-Dateien können als regulärer oder als optimierter Ladevorgang gelesen werden. Ein optimierter Ladevorgang liegt vor, wenn während des Ladens keine Datenumwandlungen vorgenommen werden und keine Filter in einem WHERE-Befehl vorhanden sind.

Optimierte Ladevorgänge funktionieren nicht, wenn QVDs mit Abschnittszugriff verwendet werden. Wenn Sie eine QVD-Datei verwenden möchten, um Daten in Abschnittszugriff zu laden, müssen Sie die QVD-Datei erweitern. Das einfachste Verfahren zum Erweitern der QVD-Datei besteht im Vornehmen von Formatierungsänderungen beim Laden der Daten.

Im folgenden Beispiel wird die QVD-Datei nicht erweitert, da die Daten nicht formatiert werden.

Beispiel: Nicht funktionierendes Beispiel ohne Datenformatierung (optimiertes Laden)

section access; LOAD ACCESS, USERID, PASSWORD, [GROUP] FROM SAccess.qvd (qvd);

Stattdessen können Sie beispielsweise die Funktion upper() verwenden, um die Daten zu formatieren, wodurch die QVD-Datei erweitert wird.

Beispiel: Funktionierendes Beispiel mit Datenformatierung

section access; LOAD ACCESS, USERID, PASSWORD, upper([GROUP]) as [GROUP] FROM SAccess.qvd (qvd);

Sie können auch einen Befehl Where 1=1 zur LOAD-Anweisung hinzufügen.

Beispiel: Weiteres funktionierendes Beispiel mit Datenformatierung

section access; LOAD ACCESS, USERID, PASSWORD, [GROUP] FROM SAccess.qvd (qvd) where 1=1;

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 im Abschnittszugriff aufgelisteten Feldnamen und Feldwerte werden immer in Großbuchstaben konvertiert. Daher müssen alle Felder, die Teil einer Datenbestandseinschränkung sind, in Großbuchstaben konvertiert werden, um den Angaben in der Abschnittszugriffsanweisung zu entsprechen, auch wenn sie sich außerhalb dieser Abschnittszugriffsanweisung befinden. Sie können alle Feldnamen mit Kleinbuchstaben in der Datenbank in Großbuchstaben konvertieren, indem Sie die Funktion „Upper“ verwenden, bevor das Feld durch die LOAD- oder SELECT-Anweisung gelesen wird.
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.

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