Bezpieczeństwo

Ostatnia aktualizacja: 7.10.2026

Mechanizm zabezpieczeń w QlikView można skonfigurować na dwa różne sposoby: wbudowanie zabezpieczeń w skrypt dokumentu QlikView lub konfiguracja z użyciem programu QlikView Publisher.

Uwierzytelnianie i autoryzacja

Uwierzytelnianie to każdy proces umożliwiający weryfikację tożsamości. W aplikacji QlikView dostępne są trzy metody uwierzytelniania: wykorzystanie uwierzytelniania w systemie operacyjnym Windows, żądanie podania ID użytkownika i hasła (jest to inne ID i hasło od danych użytkownika w systemie Windows) lub używanie klucza licencji QlikView jako prostej metody uwierzytelniania.

Autoryzacja polega na ustaleniu, czy zidentyfikowana wcześniej osoba jest uprawniona do korzystania z żądanego zasobu. Aplikacja QlikView może powierzyć autoryzację systemowi operacyjnemu Windows lub realizować ją samodzielnie. W tym drugim przypadku konieczne jest wbudowanie w skrypt tabeli zabezpieczeń.

Zabezpieczenia w przypadku używania programu QlikView Publisher

W przypadku skonfigurowania obsługi zabezpieczeń przez program QlikView Publisher każdy plik QlikView zostanie podzielony na kilka plików, z których każdy będzie zawierać dane związane z określonym użytkownikiem lub grupą użytkowników. Pliki te są zapisywane w folderach o odpowiednich ustawieniach zabezpieczeń systemu operacyjnego, to znaczy, że aplikacja QlikView powierza uwierzytelnianie i autoryzację systemowi operacyjnemu.

W sam plik nie są jednak wbudowane żadne mechanizmy zabezpieczeń, więc po pobraniu plik nie jest chroniony.

Takie pliki zazwyczaj będą mniejsze, ponieważ jeden plik jest dzielony na kilka części, a każdy użytkownik otwiera plik zawierający tylko jego dane. Z drugiej strony oznacza to jednak, że serwer QlikView Server może niekiedy potrzebować więcej pamięci niż w przypadku przechowywania wszystkich danych w jednym pliku, ponieważ może się zdarzyć, że zostanie załadowanych wiele plików zawierających te same dane.

Dodatkowe informacje zawiera dokumentacja programu QlikView Publisher.

Definiowanie zabezpieczeń za pomocą dostępu do sekcji w skrypcie QlikView

W przypadku skonfigurowania obsługi zabezpieczeń za pomocą instrukcji Section Access w skrypcie QlikView można przygotować pojedynczy plik zawierający dane wielu użytkowników lub grup użytkowników. QlikView wykorzysta dane instrukcji Section Access do uwierzytelnienia i autoryzacji, a następnie dynamicznego ograniczenia zakresu danych jedynie do danych odpowiedniego użytkownika.

Zabezpieczenia są wbudowane w sam plik, więc również plik pobrany jest w pewnej mierze chroniony. W przypadku rygorystycznych wymagań względem bezpieczeństwa należy jednak zapobiegać pobieraniu plików i używaniu ich w trybie offline. Pliki powinny być publikowane wyłącznie przez QlikView Server.

Ponieważ wszystkie dane są przechowywane w jednym pliku, może on potencjalnie być bardzo duży.

Dokumenty QlikView można ustawić jako niewidoczne w trybie offline. Aby ustawić dokument jako niewidoczny dla użytkownika w trybie offline, należy dodać następujący atrybut w sekcji informacji o dokumencie użytkownika, korzystając z QMC:

• Nazwa:Niewidoczne
• Wartość: True

Wszystkie informacje podane poniżej dotyczą zabezpieczeń z użyciem dostępu do sekcji w skrypcie QlikView.

Sekcje w skrypcie

Zarządzanie dostępem na poziomie wierszy odbywa się z wykorzystaniem jednej lub kilku 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.

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

Poziomy dostępu w Section Access

Autoryzację dostępu do dokumentów QlikView można przyznawać określonym użytkownikom lub grupom użytkowników. W tabeli zabezpieczeń każdy użytkownik może mieć jeden z dwóch poziomów dostępu: ADMIN lub USER. Jeśli użytkownikowi nie zostanie przypisany żaden poziom dostępu, nie będzie on mógł otworzyć danego dokumentu QlikView.

Użytkownik z uprawnieniem ADMIN może zmieniać wszystkie aspekty dokumentu. Na stronie Zabezpieczenia w oknach dialogowych Właściwości dokumentu i Właściwości arkusza użytkownik z uprawnieniem ADMIN może ograniczyć opcje modyfikowania dokumentu dostępne dla innych jego użytkowników. Użytkownicy z uprawnieniem USER nie mają dostępu do stron Zabezpieczenia.

Pola systemowe dostępu do sekcji

Poziomy dostępu są przypisywane użytkownikom w jednej lub kilku tabelach ładowanych w ramach funkcji dostępu do sekcji. Tabele te mogą zawierać kilka różnych pól systemowych zależnych od użytkownika — najczęściej będą to pola USERID i PASSWORD oraz pole ACCESS definiujące poziom dostępu. Wszystkie pola systemowe sekcji Section Access są używane do uwierzytelniania lub autoryzacji. Poniżej opisano pełen zestaw pól systemowych w sekcji section access.

W sekcji dostępu może być załadowana dowolna kombinacja pól zabezpieczeń, w tym wszystkie lub żadne z nich. W związku z tym niekoniecznie trzeba używać pola USERID — autoryzacji można dokonać na podstawie innych pól, na przykład samego numeru seryjnego.

Aplikacja QlikView porówna numer seryjny QlikView z wartością pola SERIAL, nazwę użytkownika lub grupy Windows NT z wartością pola NTNAME, SID domeny Windows NT z wartością pola NTDOMAINSID, a SID Windows NT z wartością pola NTSID. Aplikacja wyświetli też monit o podanie ID użytkownika i hasła, po czym porówna wprowadzone wartości z polami USERID i PASSWORD.

Jeśli znaleziona kombinacja ID użytkownika, hasła i właściwości środowiskowych odpowiada wartościom w tabeli section access, dokument zostanie otwarty z odpowiednim poziomem dostępu. W przeciwnym razie aplikacja QlikView odmówi użytkownikowi dostępu do dokumentu. Po trzykrotnym wprowadzeniu nieprawidłowego ID użytkownika lub hasła konieczne będzie powtórzenie całej procedury logowania.

Ponieważ sekcja dostępu podlega tej samej logice co inne aspekty aplikacji QlikView, możliwe jest umieszczenie pól zabezpieczeń w różnych tabelach. Dzięki temu menedżer systemu ma możliwość przekształcenia tabel zabezpieczeń w dokument QlikView — w takim przypadku wprowadzenie prawidłowego numeru seryjnego, hasła itd. jest symulowane kliknięciem odpowiedniej wartości pola.

W ramach procedury logowania aplikacja QlikView zacznie od sprawdzenia pól SERIAL, NTNAME, NTDOMAINSID i NTSID, aby ustalić, czy podane informacje są wystarczające do przyznania użytkownikowi dostępu do dokumentu. Jeśli tak, aplikacja QlikView otworzy dokument bez żądania ID użytkownika i hasła.

Jeśli tylko niektóre z pól dostępu są załadowane, zostaną użyte tylko odpowiednie spośród powyższych wymagań.

Wszystkie pola wymienione w instrukcjach LOAD lub SELECT w ramach funkcji dostępu do sekcji muszą być zapisane WIELKIMI LITERAMI. Wszelkie nazwy pól w bazie danych zawierające małe litery trzeba zamienić na wielkie litery funkcją upper, zanim zostaną one wczytane przez instrukcję Load lub Select.

Upper — funkcja skryptu i funkcja wykresu

Wielkość liter nie jest natomiast rozróżniana w ID użytkownika i haśle, które wprowadza użytkownik podczas otwierania dokumentów QlikView.

Symbol wieloznaczny (*) jest interpretowany jako wszystkie (wymienione) wartości tego pola, czyli wszystkie wartości podane w innych miejscach tabeli. Jego użycie w jednym z pól systemowych (USERID, PASSWORD, NTNAME lub SERIAL) w tabeli załadowanej w sekcji dostępu skryptu jest interpretowane jako wszystkie możliwe (nie tylko wymienione) wartości tego pola.

Sprawdzany jest tylko numer seryjny. Jeden konkretny komputer dostaje uprawnienia ADMIN. Wszyscy inni dostają uprawnienia USER. Można użyć gwiazdki w znaczeniu dowolnego numeru seryjnego.

Administrator oraz serwer, na którym aplikacja QlikView jest wykonywana jako zadanie wsadowe, dostają uprawnienia ADMIN. Wszyscy inni w domenie dostają uprawnienia USER, podając ciąg „USER” jako ID użytkownika i hasło.

Środowiska mieszane

Jeśli planujesz używać tej samej tabeli autoryzacji zarówno w QlikView, jak i w Qlik Cloud, należy pamiętać o kilku kwestiach:

• USERID ma inne znaczenie w QlikView i Qlik Cloud, a jego użycie mogłoby spowodować problemy z bezpieczeństwem. W zamian użyj pola NTNAME lub połącz je z polem SERIAL, jak opisano poniżej.

• GROUP i pola rozpoczynające się od ‘USER.’, takie jak 'USER.NAME' i 'USER.EMAIL' itp., są (lub będą) polami uwierzytelniającymi w Qlik Sense Enterprise SaaS. Jeśli używasz tych pól w instrukcji Section Access, może nastąpić odmowa dostępu w Qlik Cloud.

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

• Nie można używać pola SERIAL w celu sprawdzenia numeru licencji w Qlik Cloud. Jeżeli jednak to pole zawiera ciąg znaków „QLIKCLOUD” lub „QLIKVIEW”, dostęp może zostać przyznany. Oznacza to, że można mieć tabelę autoryzacji, taką jak poniższa, w której wiersz 1 przyzna dostęp w QlikView (ale nie w Qlik Cloud), a wiersz 2 przyzna dostęp w Qlik Cloud (ale nie w QlikView).

Ograniczenia dostępu do funkcji aplikacji QlikView

Elementy sterujące znajdujące się na stronie Właściwości dokumentu: Zabezpieczenia oraz na stronie Właściwości arkusza: Zabezpieczenia umożliwiają zablokowanie dostępu do określonych elementów menu oraz zabronienie wprowadzania zmian w układzie. Jeśli te ustawienia mają zapewniać skuteczną ochronę, trzeba dopilnować, aby użytkownicy dokumentu byli logowani z uprawnieniami USER. Użytkownik z uprawnieniami ADMIN może w każdej chwili zmienić ustawienia zabezpieczeń.

Po otwarciu dokumentu użytkownik z uprawnieniami USER nie będzie widzieć stron Zabezpieczenia w oknach dialogowych Właściwości.

Dynamiczne redukowanie danych

Programy QlikView i QlikView Server wyposażono w funkcję umożliwiającą ukrywanie przed użytkownikiem niektórych danych w dokumencie na podstawie danych logowania podanych w sekcji section access.

Pola (kolumny) można ukrywać z wykorzystaniem pola systemowego OMIT.

Po drugie rekordy (wiersze) można ukryć poprzez powiązanie danych Dostęp do sekcji z danymi rzeczywistymi: wybór wartości, która ma zostać pokazana/wykluczona, jest kontrolowany za pomocą jednego lub większej liczby pól o wspólnych nazwach w sekcjach: sekcja access i sekcja application. Po zalogowaniu użytkownika aplikacja QlikView podejmie próbę skopiowania selekcji w polach wymienionych w sekcji section access do pól o identycznych nazwach w sekcji section application (nazwy pól muszą być zapisane WIELKIMI LITERAMI). Po dokonaniu selekcji aplikacja QlikView trwale ukryje przed użytkownikiem wszystkie dane wykluczone na podstawie tych selekcji.

Aby ta procedura była wykonywana, trzeba zaznaczyć opcję Początkowa redukcja danych na podstawie dostępu do sekcji na stronie Właściwości dokumentu: Otwieranie. W przypadku używania tej funkcji w dokumentach dystrybuowanych poza serwerem QlikView Server utrzymanie ochrony danych wymaga zaznaczenia opcji Nie zezwalaj na binarną operację ładowania na tej samej stronie okna Właściwości dokumentu.

section access;

LOAD * inline [

ACCESS, USERID, REDUCTION, OMIT

ADMIN, ADMIN, *,

USER, A, 1

USER, B, 2, NUM

USER, C, 3, ALPHA

];

section application;

T1:

LOAD *,

NUM AS REDUCTION;

LOAD

Chr( RecNo()+ord('A')-1) AS ALPHA,

RecNo() AS NUM

AUTOGENERATE 3;

Pole REDUCTION (nazwa zapisana wielkimi literami) istnieje teraz zarówno w sekcji section access, jak i sekcji section application (wszystkie wartości pola również są zapisane wielkimi literami). Standardowo te dwa pola byłyby zupełnie różne i niepowiązane, ale w przypadku zaznaczenia opcji Początkowa redukcja danych na podstawie dostępu do sekcji zostaną one powiązane i wykorzystane do zredukowania liczby rekordów wyświetlanych użytkownikowi.

Pole OMIT w sekcji section access definiuje pola, które mają być ukryte przed użytkownikiem.

Wynik będzie taki, jak przedstawiono poniżej:

Użytkownik A widzi wszystkie pola, ale tylko te wiersze, które są powiązane z wartością REDUCTION=1.

Użytkownik B widzi wszystkie pola poza NUM i jedynie rekordy powiązane z wartością REDUCTION=2.

Użytkownik C widzi wszystkie pola poza ALPHA i jedynie rekordy powiązane z wartością REDUCTION=3.

Dziedziczone ograniczenia dostępu

Po wykonaniu ładowania binarnego ograniczenia dostępu zostaną odziedziczone przez nowy dokument QlikView. Użytkownik z uprawnieniami ADMIN do tego nowego dokumentu może zmienić prawa dostępu do niego, dodając nową sekcję access. Użytkownik z uprawnieniami USER może wykonywać skrypt i modyfikować go, tym samym dodając własne dane do pliku załadowanego w trybie binarnym. Użytkownicy z uprawnieniem USER nie mogą zmieniać praw dostępu. Dzięki temu administrator bazy danych może kontrolować dostęp użytkowników również w przypadku dokumentów QlikView ładowanych w trybie binarnym.

Szyfrowanie

Komunikacja między serwerem QlikView Server a klientem QlikView dla systemu Windows jest szyfrowana. Komunikacja nie jest natomiast szyfrowana w przypadku używania klienta Ajax.

Ponadto same dokumenty QlikView są szyfrowane, dzięki czemu przesyłanych danych nie da się odczytać za pomocą snifferów sieciowych, debugerów itp.

Możesz również szyfrować poufne dane w plikach QVD za pomocą par kluczy dostarczonych przez klienta, co pozwala kontrolować, kto uzyskuje dostęp do Twoich danych. Patrz Szyfrowanie QVD (tylko w języku angielskim).

Właściwości dokumentu: Zabezpieczenia

Właściwości dokumentu: Zabezpieczenia

Właściwości arkusza: Zabezpieczenia