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 są zapisywane w folderach o odpowiednich ustawieniach zabezpieczeń systemu operacyjnego, co oznacza, ż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ą dostępu do sekcji w skrypcie QlikView można przygotować pojedynczy plik zawierający dane wielu użytkowników lub grup użytkowników. Program QlikView wykorzysta dane dostępu do sekcji 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 serwer 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 konsoli 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 kontrolą dostępu odbywa się z wykorzystaniem jednej lub kilku tabel zabezpieczeń, które są ładowane przez aplikację QlikView w taki sam sposób jak zwykłe dane. Dzięki temu można przechowywać te tabele w zwykłej bazie danych. Instrukcje skryptu używane do zarządzania tabelami zabezpieczeń są podane w sekcji dostępu, inicjowanej w skrypcie instrukcją section access.

Jeśli skrypt zawiera definicję sekcji dostępu, część skryptu ładująca „zwykłe” dane musi znajdować się w odrębnej sekcji, zainicjowanej instrukcją section application.

Example:  

Section Access;

Load * inline

[ACCESS,USERID,PASSWORD

ADMIN, A,X

USER,U,Y ];

Section Application;

Load... ... from... ...

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.

Uwaga: Uprawnienie ADMIN ma zastosowanie jedynie w przypadku dokumentów lokalnych! Dostęp do dokumentów otwieranych na serwerze zawsze odbywa się z uprawnieniem USER.

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. Oznacza to, że niekoniecznie trzeba używać pola USERID — możliwe jest dokonanie autoryzacji na podstawie innych pól, na przykład samego numeru seryjnego.

 

ACCESS Pole definiujące poziom dostępu danego użytkownika.
USERID To pole powinno zawierać akceptowany ID użytkownika. Aplikacja QlikView wyświetli monit o podanie ID użytkownika i porówna podany ID z wartością w tym polu. Jest to inny identyfikator niż ID użytkownika systemu Windows.
PASSWORD To pole powinno zawierać akceptowane hasło. Aplikacja QlikView wyświetli monit o podanie hasła i porówna podane hasło z wartością w tym polu. Jest to inne hasło niż hasło użytkownika systemu Windows.
SERIAL To pole powinno zawierać liczbę odpowiadającą numerowi seryjnemu aplikacji QlikView.
Przykład: 4900 2394 7113 7304
Aplikacja QlikView sprawdzi numer seryjny użytkownika i porówna go z wartością w tym polu.
NTNAME To pole powinno zawierać ciąg znaków odpowiadający nazwie użytkownika lub grupy w domenie Windows NT.
Aplikacja QlikView pobierze informacje logowania z systemu operacyjnego i porówna je z wartością w tym polu.
NTDOMAINSID To pole powinno zawierać ciąg znaków odpowiadający SID domeny Windows NT.
Przykład: S-1-5-21-125976590-4672381061092489882
Aplikacja QlikView pobierze informacje logowania z systemu operacyjnego i porówna je z wartością w tym polu.
NTSID To pole powinno zawierać SID Windows NT.
Przykład: S-15-21-125976590-467238106-1092489882-1378
Aplikacja QlikView pobierze informacje logowania z systemu operacyjnego i porówna je z wartością w tym polu.
OMIT

To pole powinno określać pole, które należy pomijać dla danego użytkownika. Pole może zawierać symbole wieloznaczne lub być puste. Najłatwiej to zrobić za pomocą podpola.

Uwaga: Pola OMIT nie należy stosować do pól kluczowych, gdyż zmieniłoby to bazową strukturę danych. To z kolei mogłoby powodować powstawanie wysp logicznych i prowadzić do niespójności w obliczeniach.

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.

Uwaga: W przypadku ładowania danych z pliku QVD użycie funkcji upper spowolni proces ładowania.
Uwaga: Do generowania tabel dostępu w instrukcjach wbudowanych służy Kreator tabeli ograniczeń dostępu.
Uwaga: Jeśli włączono funkcję dostępu do sekcji, wymienione tutaj nazwy pól systemowych funkcji dostępu do sekcji nie mogą być używane jako nazwy pól w modelu danych.

Example 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.

ACCESS SERIAL
ADMIN 4900 2394 7113 7304
USER *

Example 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.

ACCESS SERIAL NTDOMAINSID USERID PASSWORD
ADMIN * S-1-5-21-125976590-467238106-1092489882 ADMIN ADMIN
ADMIN 4900 2394 7113 7304 * * *
USER * S-1-5-21-125976590-467238106-1092489882 USER USER

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.

Uwaga: 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 section access wszystkie nazwy i wartości pól są domyślnie zamieniane na wielkie litery.

Example:  

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,

RechNo() 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.