Zarządzanie bezpieczeństwem przy użyciu instrukcji Section Access

Section Access służy do kontrolowania bezpieczeństwa aplikacji. Zasadniczo jest to część skryptu ładowania danych, w której dodaje się tabelę zabezpieczeń, aby określić, co kto może zobaczyć. Qlik Cloud wykorzystuje te informacje do zredukowania danych do odpowiedniego zakresu, gdy użytkownik otwiera aplikację. Oznacza to, że niektóre dane w aplikacji są ukrywane przed użytkownikiem na podstawie jego tożsamości. Dostęp do sekcji jest ściśle zintegrowany z danymi w aplikacji i polega na nich w kwestii kontroli dostępu. Ta forma dynamicznej redukcji danych może być stosowana do wierszy tabeli, kolumn lub ich kombinacji. Aby uzyskać więcej informacji, odwiedź stronę Zaufanie i bezpieczeństwo w Qlik.

Sekcje w skrypcie ładowania.

Zarządzanie kontrolą dostępu do danych odbywa się z wykorzystaniem jednej lub większej liczby tabel zabezpieczeń, które są ładowane w taki sam sposób jak zwykłe dane. Dzięki temu można przechowywać te tabele w standardowej bazie danych lub w arkuszu kalkulacyjnym. Instrukcje skryptu używane do zarządzania tabelami zabezpieczeń są podane w sekcji autoryzacji, inicjowanej w skrypcie instrukcją Section Access.

Wszystkie nazwy pól i wartości pól wymienione w Dostępie do sekcji są zawsze konwertowane na wielkie litery. W rezultacie wszystkie pola objęte kompresją danych muszą zostać zamienione na wielkie litery, aby odpowiadały treści podanej w instrukcji Dostęp do sekcji, nawet jeśli znajdują się poza nią. Zapis wszelkich nazw pól zawierających w bazie danych małe litery można zmienić na zapis wielkimi literami przy użyciu funkcji Upper, zanim pole zostanie odczytane przez instrukcję LOAD lub SELECT.

Więcej informacji zawiera temat Upper — funkcja skryptu i funkcja wykresu.

Jeśli skrypt zawiera definicję sekcji autoryzacji, część skryptu ładująca dane aplikacji musi znajdować się w odrębnej sekcji, zainicjowanej instrukcją Section Application.

Przykład:

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, ]; Section Application; T1: Load *, NUM AS REDUCTION; LOAD Chr(RecNo()+ord('A')-1) AS ALPHA, RecNo() AS NUM AUTOGENERATE 3;

Należy pamiętać, że po wprowadzeniu zmian w skrypcie ładowania trzeba zawsze załadować dane, aby zmiany zostały zastosowane.

Pola systemowe w instrukcji Section Access

Poziomy dostępu są przypisywane użytkownikom w jednej lub kilku tabelach zabezpieczeń ładowanych w części Section Access skryptu. Tabele te muszą zawierać co najmniej dwa pola systemowe: ACCESS, czyli pole określające poziom dostępu i USERID lub USER.EMAIL. Inne opcjonalne pola systemowe można dodać w zależności od przypadku. Poniżej opisano pełny zestaw pól systemowych instrukcji Section Access.

ACCESS

Określa poziom dostępu danego użytkownika.

Uprawienia dostępu do aplikacji w Qlik Sense można przyznawać określonym użytkownikom. W tabeli zabezpieczeń każdy użytkownik może mieć jeden z dwóch poziomów dostępu: ADMIN lub USER. Użytkownik z uprawnieniami ADMIN ma dostęp do wszystkich danych w aplikacji, chyba że ogranicza to tabela zabezpieczeń. Użytkownik z uprawnieniami USER ma dostęp do danych jedynie w zakresie zdefiniowanym w tabeli zabezpieczeń. Jeśli użytkownikowi nie zostanie przypisany żaden poprawny poziom dostępu, nie będzie on mógł otworzyć danej aplikacji.

USERID

Zawiera ciąg znaków odpowiadający nazwie użytkownika Qlik Cloud. Qlik Cloud pobierze dane logowania z podmiotu Dostawca tożsamości i porówna je z wartościami w tym polu. Alternatywny sposób weryfikowania tożsamości użytkownika przy użyciu adresu e-mail opisano w temacie USER.EMAIL. Podmiot Dostawca tożsamości może zostać zamapowany względem wewnętrznej tożsamości systemu Windows na potrzeby środowiska wielochmurowego. Podczas korzystania z Konto Qlik Account podmiot nie może zostać zmapowany względem wewnętrznej tożsamości systemu Windows. Podmiot użytkownika Dostawca tożsamości może zostać wyświetlony w sekcji Użytkownicy Konsola zarządzania.

Znak wieloznaczny (*) jest interpretowany jako wszyscy użytkownicy, z zastrzeżeniem dalszych warunków określonych w tabeli zabezpieczeń. Na przykład w poniższej tabeli zabezpieczeń użytkownicy należący do grupy Qlik Sense Tenant Admins mogą zobaczyć wszystkie wymienione wartości REDUCTION.

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

USERID oraz NTNAME używają tych samych danych uwierzytelniających, zatem sprawdzenie obu elementów w tym samym wierszu tabeli zabezpieczeń nie jest konieczne. Różnica między tymi dwoma polami polega na tym, że NTNAME sprawdza także grupy.

NTNAME

NTNAME jest starszą wersją pola QlikView i zaleca się używanie USERID, jeśli QlikView nie używa tej samej tabeli zabezpieczeń.

Pole, które powinno zawierać ciąg znaków odpowiadający nazwie użytkownika lub grupy wersji NetBIOS domeny systemu Windows NT. Jeśli wykorzystywany jest inny system uwierzytelniania, powinien zawierać nazwę zweryfikowanego użytkownika.

Qlik Cloud pobierze dane logowania z oświadczenia subject dostawcy tożsamości i porówna je z wartościami w tym polu.

USER.EMAIL

Zawiera ciąg znaków odpowiadający adresowi e-mail użytkownika. Program Qlik Cloud pobierze te dane od dostawcy tożsamości i porówna je z wartością w tym polu.

GROUP

Zawiera ciąg znaków odpowiadający grupie w programie Qlik Cloud. Qlik Cloud pobierze dane z oświadczenia “groups” dostawcy tożsamości i porówna je z wartościami w tym polu.

Ta funkcjonalność jest niedostępna w Qlik Sense Business i Qlik Cloud Analytics Standard ani podczas używania dostawcy tożsamości Qlik.

OMIT

Zawiera nazwę pola, które ma zostać pominięte w odniesieniu do danego użytkownika. Pole może zawierać symbole wieloznaczne lub być puste.

Zalecane jest, aby nie stosować OMIT w przypadku pól kluczowych. Pola klucza, które są pomijane, są widoczne w przeglądarce modelu danych, ale ich zawartość jest niedostępna, co może być mylące dla użytkownika. Ponadto zastosowanie pola OMIT względem pól używanych w wizualizacji może spowodować, że wizualizacja będzie niekompletna dla użytkowników, którzy nie mają dostępu do pól pominiętych.

Zarządzanie dostępem użytkownika do aplikacji

Użytkownik z identyfikatorem USERID AD_DOMAIN\C nie mógłby w ogóle otworzyć aplikacji, ponieważ ten identyfikator użytkownika nie jest wymieniony w tabeli zabezpieczeń.

Do ograniczenia dostępu do aplikacji określonym użytkownikom można użyć instrukcji Section Access w jej najprostszej formie. Użytkownicy nie mają dostępu do aplikacji przez wykluczenie. Innymi słowy, jeśli określony adres e-mail użytkownika nie zostanie wymieniony w tabeli zabezpieczeń, dany użytkownik nie będzie mógł uzyskać dostępu do aplikacji. Jedynym wyjątkiem od tej reguły jest sytuacja, w której symbol wieloznaczny (*) zostanie przypisany do pola USER.EMAIL w jednym z wierszy tabeli zabezpieczeń. W tym przypadku symbol wieloznaczny oznacza, że wszyscy uwierzytelnieni użytkownicy mają dostęp do aplikacji. Oto przykład tabeli zabezpieczeń z listą identyfikatorów użytkowników:

Section Access; LOAD * inline [ ACCESS, USER.EMAIL ADMIN, USER1@EXAMPLE.COM USER, USER2@EXAMPLE.COM USER, USER3@EXAMPLE.COM ]; Section Application;

Użytkownik z adresem USER.EMAIL USER4@example.com nie mógłby w ogóle otworzyć aplikacji, ponieważ ten adres e-mail użytkownika nie jest wymieniony w tabeli zabezpieczeń.

Zarządzanie dostępem użytkownika do określonych danych w aplikacji

Dynamiczna redukcja danych ogranicza dostęp do wierszy i kolumn w tabelach danych w aplikacjach Qlik Sense po autoryzacji użytkownika w celu uzyskania dostępu do samej aplikacji.

Zarządzanie dostępem do danych na poziomie wiersza

Dostęp do danych na poziomie wiersza można ograniczyć, dodając kolumnę redukcji danych do tabeli zabezpieczeń w sekcji dostępu skryptu ładowania. Określone rekordy (wiersze) można ukrywać przed użytkownikami przez powiązanie danych instrukcji Section Access z rzeczywistymi danymi. Kontrolowanie zakresu danych wyświetlanych lub wykluczanych polega na używaniu pól redukcji o takich samych nazwach w częściach Section Access i Section Application skryptu. Po zalogowaniu użytkownika program Qlik Sense dopasuje wybory w polach redukcji w sekcji dostępu do pól o identycznych nazwach w sekcji aplikacji (nazwy pól muszą być zapisane wielkimi literami). Po dokonaniu wyborów program Qlik Sense trwale ukryje przed użytkownikiem wszystkie dane wykluczone na podstawie tych wyborów. Jeśli jako wartość pola w kolumnie redukcji danych jest używany symbol wieloznaczny (*), jest on interpretowany jako umożliwiający użytkownikowi dostęp do rekordów powiązanych ze wszystkimi wybranymi polami redukcji w tabeli zabezpieczeń.

Kiedy Qlik Sense porównuje pole redukcji w Dostępie do sekcji z polami w modelu danych, oczekiwane jest następujące działanie:

Jeśli wartość pola w modelu danych pasuje do pola redukcji w Dostępie do sekcji, aplikacja otwiera się, pokazując dane powiązane z dopasowaniem dla określonego użytkownika. Inne dane zostaną ukryte.
Jeśli wartość pola redukującego nie pasuje do żadnej z wartości w modelu danych, aplikacja nie otworzy się dla zwykłego UŻYTKOWNIKA. Otworzy się jednak bez redukcji dla użytkownika oznaczonego jako ADMINISTRATOR.

Nie zaleca się używania kilku pól redukujących w Dostępie do sekcji, ponieważ umożliwi to powstanie innych kombinacji dostępu niż zamierzone.

Znak wieloznaczny * w kolumnie redukcji danych odnosi się tylko do wszystkich wartości w tabeli zabezpieczeń. Jeśli w części Section Application znajdują się wartości, które są niedostępne w kolumnie redukcji tabeli zabezpieczeń, zostaną one zredukowane.

Wszystkie nazwy pól używane w opisanej powyżej procedurze przenoszenia oraz wszystkie wartości tych pól muszą być zapisane wielkimi literami, ponieważ w sekcji dostępu wszystkie nazwy i wartości pól są domyślnie zamieniane na wielkie litery.

Przykład: Redukcja danych na podstawie tożsamości użytkownika

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;

W tym przykładzie pole REDUCTION (nazwa zapisana wielkimi literami) istnieje teraz w części zarówno Section Access, jak i Section Application (wszystkie wartości pola również są zapisane wielkimi literami). W zwykłej sytuacji te dwa pola byłyby różne i niepowiązane, ale przez zastosowanie dostępu do sekcji zostaną one powiązane i wykorzystane do zredukowania liczby rekordów wyświetlanych użytkownikowi.

Wynik będzie następujący:

Użytkownik USER1@EXAMPLE.COM widzi wszystkie pola oraz tylko te rekordy, które mogą wyświetlać inni użytkownicy, kiedy REDUCTION = 1 lub REDUCTION =2.
Użytkownik USER2@EXAMPLE.COM widzi wszystkie pola i jedynie rekordy powiązane z wartością REDUCTION=1.
Użytkownik USER3@EXAMPLE.COM widzi wszystkie pola i jedynie rekordy powiązane z wartością REDUCTION=2.
Użytkownik USER4@EXAMPLE.COM widzi wszystkie pola oraz tylko te rekordy, które mogą wyświetlać inni użytkownicy, kiedy REDUCTION = 1 lub REDUCTION =2.

Zarządzanie dostępem do danych na poziomie kolumn

Dostęp do danych na poziomie kolumny można ograniczyć, dodając pole systemowe OMIT do tabeli zabezpieczeń w skrypcie Section Access. Poniższy przykład opiera się na poprzednim przykładzie, w którym stosowana jest już redukcja danych wiersza.

Przykład: Redukcja danych kolumny na podstawie identyfikatora użytkownika

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;

Pole OMIT w dostępie do sekcji definiuje pola, które mają być ukryte przed użytkownikiem.

Wynik będzie następujący:

Użytkownik USER1@example.com widzi wszystkie pola oraz tylko te rekordy w tym przykładzie, które mogą wyświetlać inni użytkownicy, gdy REDUCTION to 1, 2 lub 3.
Użytkownik USER2@example.com widzi wszystkie pola i jedynie rekordy powiązane z wartością REDUCTION=1.
Użytkownik USER3@example.com widzi wszystkie pola oprócz NUM i jedynie rekordy powiązane z wartością REDUCTION=2.
Użytkownik USER4@example.com widzi wszystkie pola oprócz ALPHA i jedynie rekordy powiązane z wartością REDUCTION=3.

Niektóre wizualizacje mają minimalne wymagania dotyczące danych, które należy spełnić, aby były renderowane. W rezultacie może zostać wyświetlony komunikat „Niekompletna wizualizacja”, gdy pole na poziomie kolumny zostanie pominięte w widoku danych użytkownika.

Zarządzanie dostępem do grup użytkowników

Instrukcja Section Access umożliwia ograniczenie zakresu danych widocznych dla użytkowników na podstawie członkostwa w grupie. Aby ograniczyć dane przy użyciu grup użytkowników, dodaj nazwę pola GROUP do tabeli zabezpieczeń w sekcji dostępu i zdefiniuj wartości dla pola GROUP.

Przykład: Redukcja danych na podstawie grup użytkownika

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;

Wynik będzie następujący:

Użytkownicy należący do grupy ADMIN widzą wszystkie pola oraz tylko te rekordy w tym przykładzie, które mogą wyświetlać inni użytkownicy, gdy REDUCTION to 1, 2 lub 3.
Użytkownicy należący do grupy A widzą dane powiązane z wartością REDUCTION=1 we wszystkich polach.
Użytkownicy należący do grupy B widzą dane powiązane z wartością REDUCTION=2, ale nie dane z pola NUM
Użytkownicy należący do grupy C widzą dane powiązane z wartością REDUCTION=3, ale nie dane z pola ALPHA
Użytkownicy należący do grupy GROUP1 widzą dane powiązane z wartością REDUCTION=3 we wszystkich polach
Użytkownik AD_DOMAIN\DEV widzi wszystkie dane we wszystkich polach.

Qlik Cloud porówna dane użytkownika dostarczone przez serwer proxy z identyfikatorem użytkownika (UserID) i rozpozna użytkownika względem grup w tabeli. Jeśli użytkownik jest zgodny lub należy do grupy z uprawnieniami dostępu, może otrzymać dostęp do aplikacji.

Ładowanie danych w Qlik Cloud

Aby załadować aplikację bez redukcji danych w Qlik Cloud, zaleca się użycie pola systemowego USER.EMAIL w tabeli zabezpieczeń. Wartością pola USER.EMAIL powinien być adres e-mail użytkowników, którzy mogą edytować i ładować aplikację. Dotyczy to aplikacji w przestrzeniach zarówno udostępnionych, jak i zarządzanych. Na przykład:

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

W tym przykładzie użytkownik z adresem e-mail test@example.com ma uprawnienia ADMIN i może załadować aplikację.

Jeśli korzystasz z grup, poniższy przykład zadziała w Qlik Sense i Qlik Cloud:

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

Można także zamapować USERID w tabeli zabezpieczeń do subject claim dostawcy tożsamości, jak pokazano w poniższym przykładzie. Ta konfiguracja jest zalecana do migracji z Qlik Sense do Qlik Cloud oraz do środowisk wielochmurowych. Aby uzyskać więcej informacji na temat mapowania USERID do subject claim, zobacz temat Zarządzanie dostępem użytkowników w środowisku wielochmurowym

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

Zarządzanie dostępem użytkowników w środowisku wielochmurowym

Środowisko wielochmurowe Qlik Sense obejmuje różne mechanizmy uwierzytelniania użytkowników. W przypadku Qlik Sense Enterprise on Windows identyfikator USERID jest zwykle weryfikowany w tabeli zabezpieczeń przez usługę proxy. W Qlik Cloud tę rolę uwierzytelniania przyjmuje dostawca tożsamości. W związku z tym instrukcja Section Access skonfigurowana dla środowiska lokalnego, takiego jak Qlik Sense Enterprise on Windows, nie będzie działać w środowisku chmurowym.

W przypadku korzystania z dostawcy tożsamości OIDC lub SAML (Qlik IdP lub niestandardowego dostawcy tożsamości) z Qlik Cloud subject claim służy do identyfikacji użytkowników podczas logowania. Jeżeli stosowany jest instrukcja Dostęp do sekcji, wartość pola USERID w tabeli zabezpieczeń jest porównywana z wartością subject claim. Podczas konfiguracji dzierżawy dopilnuj, by nazwa konta SAM została zamapowana do subject claim Twojego dostawcy tożsamości. Na przykład, jeśli nazwa Twojego konta SAM to AD_DOMAIN\Dev, ustaw subject claim na AD_DOMAIN\Dev. Aby zobaczyć wartość subject claim dostawcy tożsamości, dołącz /api/v1/diagnose-claims do adresu URL dzierżawy w przeglądarce, na przykład your-tenant.us.qlikcloud.com/api/v1/diagnose-claims. W odpowiedzi JSON subject claim nazywa się sub.

Jeśli nie możesz użyć nazwy konta SAM, istnieje inny sposób uwierzytelnienia użytkownika. Ponieważ adresy e-mail zwykle pozostają takie same w różnych środowiskach, możesz użyć w tabeli zabezpieczeń pola USER.EMAIL zamiast USERID. Oto przykład tego, jak mogłaby wyglądać tabela zabezpieczeń:

DOSTĘP	IDENTYFIKATOR UŻYTKOWNIKA	USER.EMAIL	Komentarz	COUNTRY
USER	ABC\JOE	*	Dostęp lokalny	Stany Zjednoczone
USER	*	JOE.SMITH@EXAMPLE.COM	Dostęp w chmurze	Stany Zjednoczone
USER	ABC\URSULA	*	Dostęp lokalny	Niemcy
USER	*	URSULA.SCHULTZ@EXAMPLE.COM	Dostęp w chmurze	Niemcy
USER	ABC\STEFAN	*	Dostęp lokalny	Szwecja
USER	*	STEFAN.SVENSSON@EXAMPLE.COM	Dostęp w chmurze	Szwecja

Skrypt autoryzacji:

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 ];

Pamiętaj, że każdy użytkownik ma dwa rekordy: Jeden do dostępu lokalnego, a drugi do dostępu w chmurze. Symbole wieloznaczne zapewniają używanie tylko odpowiednich pól uwierzytelniających. W tym przykładzie pole COUNTRY jest używane jako pole redukcji danych.

Pola autoryzacji programu QlikView

Qlik Cloud rozpoznaje pola autoryzacji z programu QlikView na rzecz zachowania zgodności z poprzednimi wersjami. Chociaż USERID jest różnie interpretowany w QlikView i Qlik Cloud, w Qlik Cloud będzie interpretowany tak samo jak w Qlik Sense: zostanie zestawiony z nazwą zweryfikowanego użytkownika.

PASSWORD, NTSID oraz NTDOMAINSID

Jeśli jedno z pól PASSWORD, NTSID lub NTDOMAINSID jest używane i zawiera odpowiednią wartość, dostęp do dokumentu nie jest przyznany. Jeśli pole zawiera symbol wieloznaczny (*), dostęp może zostać przydzielony w zależności od innych pól w tabeli autoryzacji.

SERYJNE

Jeśli pole SERIAL jest używane i zawiera numer licencji, wiersz Dostęp do sekcji odmówi dostępu do dokumentu. Jeśli pole zawiera symbol wieloznaczny (*), dostęp może zostać przydzielony w zależności od innych pól w tabeli autoryzacji.

Dodatkowo w Qlik Cloud to pole może zostać użyte także w celu definiowania środowiska. Oznacza to, że jeśli pole zawiera ciąg znaków „QLIKCLOUD”, dostęp może zostać przydzielony w zależności od innych pól w tabeli autoryzacji.

Środowiska mieszane

Jeśli planujesz użycie tej samej tabeli zabezpieczeń zarówno w QlikView, jak i Qlik Cloud, należy pamiętać, że:

• USERID ma różne znaczenia w QlikView i Qlik Cloud, a chmura, jeśli jest w użyciu, powoduje problemy związane z zabezpieczeniami. W zamian użyj NTNAME lub połącz z SERIAL, jak opisano poniżej.

• GROUP oraz pola rozpoczynające się od „USER.”, np. „USER.NAME” lub „USER.EMAIL” są (lub będą) polami autoryzacji w Qlik Cloud. Jeśli używasz tych pól w części Dostęp do sekcji, dostęp może nie zostać przyznany w Qlik Cloud.

• PASSWORD, NTSID i NTDOMAINSID nie mogą być użyte w Qlik Cloud. Dostęp nie zostanie przyznany dopóki używany jest symbol wieloznaczny.

• SERIAL nie może być użyty w celu sprawdzenia numeru licencji w Qlik Cloud. Jeśli jednak to pole zawiera ciąg znaków „QLIKCLOUD”, dostęp może zostać przyznany. To oznacza, że jest możliwe uzyskanie tabeli zabezpieczeń podobnej do następującej, gdzie linia 1 przyzna dostęp do QlikView (ale nie do Qlik Cloud), a linia 2 przyzna dostęp do Qlik Cloud (ale nie do QlikView).

Tabela zabezpieczeń
Linia	SERYJNE	IDENTYFIKATOR UŻYTKOWNIKA	Komentarz
1	4600 0123 4567 8901	*	Przyznaje dostęp do poprawnego numeru licencji w QlikView.
2	QLIKCLOUD	JOHN DOE	Przyznaje dostęp do poprawnego użytkownika w Qlik Cloud.

Skrypt autoryzacji:

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

Używanie Section Access i Czat Wniosków

Aplikacje korzystające z instrukcji Section Access używają użytkownika indeksu do określenia ilości informacji pobieranych przez Czat Wniosków z aplikacji. Użytkownik indeksu powinien być użytkownikiem z najwyższym poziomem dostępu do aplikacji w skrypcie Section Access. Dane dostarczane użytkownikom końcowym są jednak nadal kontrolowane przez ograniczenia instrukcji Section Access.

Aby obejrzeć wizualną prezentację, jak używać dostępu do sekcji i Czat Wniosków, patrz:

Używanie dostępu do sekcji i Insight Advisor Chat

Jeśli masz poufne informacje w nazwach aplikacji, pól lub elementów głównych, mogą one zostać ujawnione przez udostępnienie aplikacji używających instrukcji Section Access dla funkcji Czat Wniosków. Sugestie aplikacji dotyczące zapytań obejmują aplikacje w przestrzeniach, do których użytkownicy mają dostęp. Mogą to być aplikacje, do których użytkownicy nie mają dostępu w sekcji Dostęp do sekcji aplikacji. Jednak wybranie tych aplikacji nie da żadnych efektów. Po kliknięciu Wymiary lub Miary w celu wyświetlenia dostępnych elementów z aplikacji używającej instrukcji Section Access użytkownicy mogą zobaczyć elementy, do których nie mają dostępu. Kliknięcie tych elementów nie spowoduje jednak udostępnienia użytkownikom żadnych danych.

Domyślnie właścicielem aplikacji jest użytkownik indeksu. Użytkownika indeksu można zmienić w Szczegółach.

Wykonaj następujące czynności:

W Qlik Cloud przejdź do aplikacji.
Kliknij w aplikacji i wybierz opcję Szczegóły.
W polu Użytkownik indeksu wybierz użytkownika indeksu.
Kliknij Wstecz.
Kliknij w aplikacji i wybierz opcję Przeładuj.

Korzystanie z QVD z dostępem do sekcji

Pliki QVD można odczytywać jako ładowanie zwykłe lub jako ładowanie zoptymalizowane. Ładowanie zoptymalizowane polega na tym, że nie są wykonywane żadne transformacje danych i nie ma żadnych filtrów w klauzuli WHERE.

Ładowania zoptymalizowane nie działają w przypadku korzystania z QVD z dostępem do sekcji. Jeśli chcesz użyć pliku QVD do załadowania danych do dostępu do sekcji, musisz rozszerzyć plik QVD. Najłatwiejszym sposobem rozszerzenia pliku QVD jest dokonanie zmiany formatowania podczas ładowania danych.

W poniższym przykładzie plik QVD nie jest rozszerzony, ponieważ dane nie są formatowane.

Przykład: Niedziałający przykład bez formatowania danych (ładowanie zoptymalizowane)

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

Zamiast tego możesz na przykład użyć funkcji upper() do sformatowania danych, co spowoduje rozwinięcie pliku QVD.

Przykład: Działający przykład z formatowaniem danych

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

Można także dodać instrukcję Where 1=1 do instrukcji LOAD.

Przykład: Kolejny działający przykład z formatowaniem danych

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

Wytyczne i wskazówki dotyczące korzystania z instrukcji Section Access

Oto kilka ważnych faktów i przydatnych wskazówek dotyczących instrukcji Section Access.

Wszystkie nazwy pól i wartości pól wymienione w Dostępie do sekcji są zawsze konwertowane na wielkie litery. W rezultacie wszystkie pola objęte kompresją danych muszą zostać zamienione na wielkie litery, aby odpowiadały treści podanej w instrukcji Dostęp do sekcji, nawet jeśli znajdują się poza nią. Zapis wszelkich nazw pól zawierających w bazie danych małe litery można zmienić na zapis wielkimi literami przy użyciu funkcji Upper, zanim pole zostanie odczytane przez instrukcję LOAD lub SELECT.
Więcej informacji zawiera temat Upper — funkcja skryptu i funkcja wykresu.
Wymienione tutaj nazwy pól systemowych Section Access nie mogą być używane jako nazwy pól w modelu danych.
Aplikacje muszą zostać opublikowane przed zastosowaniem środków kontroli z części Section Access. Załadowanie aplikacji nie spowoduje zastosowania nowych ani zmienionych skryptów Section Access.
Migawka przedstawia dane zgodnie z uprawnieniami dostępu użytkownika, który ją rejestruje, i może być udostępniana w narracji. Użytkownicy wracający do wizualizacji z narracji w celu wyświetlenia danych na żywo w aplikacji są jednak ograniczeni własnymi uprawnieniami dostępu.
Do wartości wymiaru głównego nie należy przypisywać kolorów, jeśli korzysta się z dostępu do sekcji albo z danych poufnych, ponieważ wartości mogą zostać ujawnione przez konfigurację kolorów.
Aby uniknąć ujawnienia zastrzeżonych danych, przed opublikowaniem aplikacji należy usunąć wszystkie dołączone pliki, względem których obowiązują ustawienia dostępu do sekcji. Dołączone pliki są zawarte w momencie publikowania aplikacji. Jeśli publikowana aplikacja zostanie skopiowana, dołączone pliki zostaną dodane do kopii. Jeśli jednak względem dołączonych plików danych zastosowano ograniczenia dostępu do sekcji, wówczas ustawienia dostępu do sekcji nie zostaną zachowane w przypadku skopiowania plików, dzięki czemu użytkownicy skopiowanej aplikacji będą widzieć wszystkie dane w dołączonych plikach.
Symbol wieloznaczny (*) jest interpretowany jako wszystkie (wymienione) wartości tego pola w tabeli. Jego użycie w jednym z pól systemowych (USERID, GROUP) w tabeli załadowanej w sekcji dostępu skryptu jest interpretowane jako wszystkie możliwe (nie tylko wymienione) wartości tego pola.
Pola zabezpieczeń można umieścić w różnych tabelach.
W przypadku ładowania danych z pliku QVD funkcja Upper powoduje spowolnienie procesu ładowania.

Czy ta strona była pomocna?

Jeżeli natkniesz się na problemy z tą stroną lub jej zawartością — literówkę, brakujący krok lub błąd techniczny — daj nam znać, co możemy poprawić!

Przekaż tu opinię