Zabezpieczenia

Istnieją dwa różne sposoby konfigurowania mechanizmu zabezpieczeń w aplikacji QlikView: 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 będą przechowywane w folderach z odpowiednimi ustawieniami zabezpieczeń systemu operacyjnego, co oznacza, że QlikView umożliwia systemowi operacyjnemu obsługę uwierzytelniania i autoryzacji.

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 arkuszu kalkulacyjnym. Instrukcje skryptu używane do zarządzania tabelami zabezpieczeń są podane w sekcji uwierzytelniania, 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, inicjowanej instrukcją Section Application.

Przykład:  

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.

Przykład 1:  

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.

Przykład 2:  

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życie tej samej tabeli autoryzacji zarówno w QlikView, jak i Qlik Sense SaaS, należy pamiętać o kilku kwestiach:

• USERID ma różne znaczenia w QlikView i Qlik Sense SaaS i może, jeśli jest w użyciu, powodować problemy związane z zabezpieczeniami. W zamian użyj pola NTNAME lub połącz je z polem SERIAL, jak opisano poniżej.

• GROUP i pola zaczynające się od „USER.”, takie jak „USER.NAME” i „USER.EMAIL”, są (lub będą) polami uwierzytelniania 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 Sense SaaS.

• PASSWORD, NTSID i NTDOMAINSID nie mogą być używane w Qlik Sense SaaS. 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 Sense SaaS. Jeżeli jednak to pole zawiera ciąg znaków „QLIKCLOUD” lub „QLIKVIEW”, dostęp może zostać przyznany. To oznacza, że uzyskanie tabeli autoryzacji podobnej do następującej jest możliwe, gdzie linia 1 przyzna dostęp do QlikView (ale nie do Qlik Sense SaaS), a linia 2 przyzna dostęp do Qlik Sense SaaS (ale nie do QlikView).

 

Ograniczenia dostępu do funkcji aplikacji QlikView

Kontrolki na stronach Właściwości dokumentu: Zabezpieczenia i Właściwości arkusza: Zabezpieczenia umożliwiają zablokowanie możliwości wprowadzania zmian w układzie i korzystania z wybranych pozycji menu. 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.

Dynamiczna kompresja 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.

Wiersze można ukrywać poprzez odpowiednie powiązanie danych w sekcji Section Access z faktycznymi danymi. Selekcję wartości wyświetlanych lub ukrywanych można kontrolować, nadając te same nazwy polom w sekcjach section access i section 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.

Przykład:  

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 wiersze powiązane z wartością REDUCTION=2.

Użytkownik C widzi wszystkie pola poza ALPHA i jedynie wiersze 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żna także zaszyfrować poufne dane w plikach QVD za pomocą dostarczonych przez klienta par kluczy, które pozwolą kontrolować dostęp do danych. Patrz Szyfrowanie QVD (tylko w języku angielskim).