In QlikView è possibile impostare un meccanismo di sicurezza in due modi diversi: può essere integrato in uno script del documento di QlikView o può essere configurato utilizzando QlikView Publisher.
Autenticazione e autorizzazione
Per autenticazione si intende qualsiasi processo mediante il quale si verifica l'effettiva identità di un utente. QlikView può delegare l'autenticazione al sistema operativo Windows o richiedere l'ID utente e la password (diversi da ID utente e password di Windows) o, ancora, utilizzare la chiave di licenza QlikView come semplice metodo di autenticazione.
Con il termine autorizzazione si intende verificare se un soggetto, una volta identificato, è autorizzato ad accedere alla risorsa. QlikView può lasciare che sia il sistema operativo Windows a eseguire l'autorizzazione o effettuare tale operazione autonomamente. Nel secondo caso, è necessario incorporare una tabella di sicurezza nello script.
Sicurezza mediante QlikView Publisher
Se QlikView Publisher è configurato per gestire la sicurezza, ogni file QlikView sarà suddiviso in più file, ciascuno dei quali conterrà dati relativi all'utente o al gruppo di utenti correlato. Questi file saranno memorizzati in cartelle e corredati delle impostazioni di sicurezza pertinenti del sistema operativo. In tal caso, QlikView lascia che sia il sistema operativo a gestire le attività di autenticazione e autorizzazione.
Tuttavia, in questo caso non vi sono impostazioni di sicurezza incorporate nel file e, di conseguenza, il file scaricato non usufruisce di alcuna protezione.
In genere, le dimensioni dei file risultano inferiori, perché ogni file è suddiviso in più file e l'utente è autorizzato ad aprire solo quelli contenenti i dati di pertinenza. Tuttavia, questo comporta parimenti che un'istanza QlikView Server può utilizzare potenzialmente più memoria rispetto a quella necessaria in caso di dati contenuti in un solo file. Infatti, in alcuni casi saranno caricati più file contenenti gli stessi dati.
Per ulteriori informazioni, vedere la documentazione di QlikView Publisher.
Sicurezza tramite la sezione relativa al controllo degli accessi nello script QlikView
Se è Section Access dello script QlikView a essere configurato per gestire la sicurezza, si otterrà un unico file di dati per tutti i relativi utenti o gruppi di utenti. QlikView utilizza le informazioni di Section Access per eseguire le operazioni di autenticazione e autorizzazione; in questo modo, i dati vengono ridotti in modo dinamico e vengono visualizzati solo i dati pertinenti a ciascun utente.
Le opzioni di sicurezza sono incorporate nel file stesso. Pertanto, anche un file scaricato può ritenersi in qualche modo protetto. Tuttavia, in caso di esigenze di sicurezza particolarmente rigorose, è consigliabile evitare di scaricare file da utilizzare in modalità non in linea in un secondo momento. I file devono essere pubblicati esclusivamente da QlikView Server.
Poiché tutti i dati sono memorizzati in un file, è possibile che tale documento sia di dimensioni molto grandi.
I documenti QlikView possono essere resi invisibili in modalità offline. Per rendere invisibile un documento utente offline, aggiungere il seguente attributo nella sezione delle informazioni sul documento di un documento utente utilizzando QMC:
- Nome: Invisibile
- Valore: Vero
Tutte le informazioni riportate di seguito si riferiscono alla configurazione della sicurezza basata sull'uso della sezione relativa a Section Access nello script QlikView.
Sezioni nello script
L'accesso a livello di righe viene gestito mediante una o più tabelle di sicurezza caricate secondo la normale procedura di caricamento dei dati. Ciò rende possibile archiviare tali tabelle in un database standard o in foglio di calcolo. Le istruzioni di script che gestiscono le tabelle di sicurezza sono incluse all'interno di una sezione di autorizzazione, che nello script viene inizializzata dall'istruzione Section Access.
Se una sezione di autorizzazione è definita nello script, la parte dello script destinata al caricamento dei dati dell'app deve far parte di una sezione differente, inizializzata dall'istruzione Applicazione sezione.
Esempio:
Livelli di accesso nella sezione relativa al controllo degli accessi
L'autorizzazione ad accedere ai documenti QlikView può essere assegnata a utenti o gruppi di utenti specifici. Nella tabella di sicurezza, gli utenti possono essere assegnati ai livelli di accesso ADMIN o USER. In caso di mancata assegnazione dei livelli di accesso, all'utente non è consentito aprire il documento QlikView.
Un utente con accesso ADMIN è autorizzato a modificare qualsiasi aspetto del documento. Utilizzando la pagina Sicurezza all'interno delle finestre di dialogo Proprietà documento e Proprietà foglio, un utente con accesso ADMIN può limitare le possibilità degli altri utenti di apportare modifiche al documento. Un utente con privilegi USER non può accedere alle pagine Sicurezza.
Campi di sistema della sezione relativa al controllo degli accessi
I livelli di accesso vengono assegnati agli utenti tramite una o più tabelle caricate all'interno della sezione relativa al controllo degli accessi. Queste tabelle possono contenere diversi campi di sistema specifici per utente, in genere USERID e PASSWORD, ai quali si aggiunge ACCESS, il campo impiegato per definire il livello di accesso. Tutti i campi di sistema della sezione relativa al controllo degli accessi vengono utilizzati nelle operazioni di autenticazione o autorizzazione. Di seguito è descritto il gruppo completo dei campi di sistema della sezione relativa al controllo degli accessi.
Nella sezione relativa al controllo degli accessi è possibile caricare tutti i campi di sicurezza, una combinazione qualsiasi di tali campi o nessun campo. Non è pertanto necessario utilizzare USERID, bensì è possibile impostare un'autorizzazione utilizzando altri campi, ad esempio solo il numero di serie.
| Campo | Descrizione |
|---|---|
| ACCESS | Campo che definisce il tipo di accesso che verrà assegnato all'utente corrispondente. |
| USERID | Campo che deve contenere un identificativo utente accettato. QlikView richiede l'identificativo utente e lo confronta con il valore incluso in questo campo. Questo ID utente non coincide con l'ID utente di Windows. |
| USER.EMAIL | Attualmente non supportato, in QlikView fornirà corrispondenze solo in base a caratteri jolly. |
| PASSWORD | Campo che deve contenere una password accettata. QlikView richiede la password e confronta l'immissione con il valore incluso in questo campo. Questa password non coincide con la password Windows. |
| SERIAL | Campo che deve contenere un numero corrispondente al numero di serie di QlikView o alla stringa 'QLIKVIEW'. Esempio: 4900 2394 7113 7304. QlikView verifica il numero di serie dell'utente o la stringa 'QLIKVIEW' e lo confronta con il valore presente in questo campo. |
| NTNAME | Campo che deve contenere una stringa corrispondente a un nome utente o a un nome gruppo di un dominio Windows NT. Se viene utilizzato un sistema di autenticazione diverso, deve contenere il nome di un utente autenticato. QlikView recupera le informazioni di accesso dal sistema operativo e le confronta con il valore incluso in questo campo. |
| NTDOMAINSID | Campo che deve contenere una stringa corrispondente a un SID di un dominio Windows NT. Esempio: S-1-5-21-125976590-4672381061092489882 QlikView recupera le informazioni di accesso dal sistema operativo e le confronta con il valore incluso in questo campo. |
| NTSID | Campo che deve contenere il SID di un dominio Windows NT. Esempio: S-15-21-125976590-467238106-1092489882-1378 QlikView recupera le informazioni di accesso dal sistema operativo e le confronta con il valore incluso in questo campo. |
| OMIT |
Campo che deve contenere il campo da omettere in riferimento all'utente specifico. È possibile utilizzare caratteri speciali e il campo può essere vuoto. Un modo semplice per agire in questo senso consiste nell'utilizzare un campo secondario. Nota informaticaÈ necessario applicare OMIT sui campi chiave, in quando ciò consentirà di modificare la struttura dei dati sottostante. Questo può creare isole logiche e incoerenze tra i calcoli.
|
QlikView confronta il numero di serie di QlikView con il campo SERIAL, il nome utente e i gruppi Windows NT con il campo NTNAME, il SID del dominio Windows NT con il campo NTDOMAINSID e il SID Windows NT con il campo NTSID. Quindi, richiede l'immissione dell'identificativo utente e della password, che confronta con i dati contenuti nei campi USERID e PASSWORD.
Se la combinazione di ID utente, password e proprietà ambiente corrisponde ai dati inclusi nella tabella relativa alla sezione di controllo degli accessi, il documento viene aperto con il livello di accesso corrispondente. Diversamente, QlikView negherà l'accesso utente al documento. Al terzo tentativo errato di immissione di identificativo utente e/o password, è necessario ripetere l'intera procedura di accesso.
Poiché nella sezione relativa al controllo degli accessi viene utilizzata la logica interna distintiva di QlikView, i campi di sicurezza potrebbero essere localizzati in tabelle differenti. (Di conseguenza, la gestione di sistema può estrarre un documento QlikView dalle tabelle di sicurezza. In questo caso numero di serie, password e altri valori corretti sono simulati facendo clic sul valore di campo corrispondente).
Durante la procedura di accesso, QlikView controlla innanzitutto i campi SERIAL, NTNAME, NTDOMAINSID e NTSID per verificare se le informazioni in essi contenute sono sufficienti per concedere l'accesso utente al documento. Se le informazioni sono sufficienti, QlikView aprirà il documento senza richiedere l'ID utente e la password.
Nel caso in cui siano caricati esclusivamente alcuni dei campi di accesso, saranno utilizzati solo i requisiti indispensabili fra quelli indicati sopra.
Tutti i campi elencati nell'istruzione Load o Select della sezione relativa al controllo degli accessi devono essere redatti in MAIUSCOLO. Tutti i nomi dei campi contenenti caratteri minuscoli devono essere convertiti in caratteri maiuscoli tramite la funzione upper, prima di essere letti dall'istruzione Load o Select.
Upper - funzione dello script e del grafico
Tuttavia, l'ID utente e la password immessi dall'utente finale all'apertura dei documenti QlikView non sono soggetti alla distinzione tra maiuscole/minuscole.
Un carattere jolly (*) viene interpretato come tutti i valori (elencati) di questo campo, ossia un valore elencato in qualsiasi punto all'interno di questa tabella. Se viene utilizzato in un campo di sistema (USERID, PASSWORD, NTNAME o SERIAL) di una tabella caricata nella sezione dello script relativa al controllo degli accessi, viene interpretato come tutti i valori possibili di tale campo (inclusi quelli non compresi nell'elenco).
Esempio 1:
È sottoposto a verifica esclusivamente il numero di serie. Un computer specifico ottiene l'accesso ADMIN. Tutti gli altri ottengono l'accesso USER. È possibile utilizzare un asterisco per contrassegnare “qualsiasi numero di serie”.
| ACCESS | SERIAL |
|---|---|
| ADMIN | 4900 2394 7113 7304 |
| USER | * |
Esempio 2:
L'amministratore e il server sul quale QlikView è eseguito come lavoro batch ottengono l'accesso ADMIN. Tutti gli altri utenti nel dominio ottengono l'accesso USER immettendo “USER” come ID utente e password.
| 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 |
Ambienti misti
Se si pianifica di utilizzare la stessa tabella di autorizzazione sia in QlikView sia in Qlik Sense SaaS, ci sono alcuni aspetti da considerare:
• USERID ha significati diversi in QlikView e Qlik Sense SaaS, e potrebbe, in caso di utilizzo, causare problemi di sicurezza. Utilizzare invece NTNAME o combinarlo con SERIAL come descritto in basso.
• Il valore GROUP e i campi che iniziano con ‘USER.’, come 'USER.NAME' e 'USER.EMAIL', ecc. sono (o saranno) campi di autenticazione in Qlik Sense Enterprise SaaS. Se si utilizzano questi campi nel proprio Section Access, l'accesso potrebbe essere negato in Qlik Sense SaaS.
• PASSWORD, NTSID e NTDOMAINSID non possono essere utilizzati in Qlik Sense SaaS. L'accesso verrà negato, a meno che non venga utilizzato un carattere jolly.
• Impossibile utilizzare SERIAL per controllare il numero di licenza in Qlik Sense SaaS. Tuttavia, se questo campo contiene la stringa ‘QLIKCLOUD’ o 'QLIKVIEW', l'accesso potrebbe essere consentito. Ciò significa che è possibile avere una tabella di autorizzazione come la seguente, in cui line 1 consentirà l'accesso a QlikView (ma non a Qlik Sense SaaS), e line 2 consentirà l'accesso a Qlik Sense SaaS (ma non a QlikView).
| Linea | SERIAL | USERID | Commento |
|---|---|---|---|
| 1 | 4600 0123 4567 8901 | * | Concede accesso al numero di licenza corretto in QlikView. |
| 2 | QLIKCLOUD | John Doe | Concede l'accesso all'utente corretto in Qlik Sense Enterprise SaaS. |
| Linea | SERIAL | USERID | Commento |
|---|---|---|---|
| 1 | QLIKVIEW | * | Concede l'accesso a QlikView. |
| 2 | QLIKCLOUD | John Doe | Concede l'accesso all'utente corretto in Qlik Sense Enterprise SaaS. |
Restrizioni alle funzionalità QlikView
I controlli disponibili nella pagina Proprietà documento: Sicurezza e nella pagina Proprietà foglio: Sicurezza consentono di impedire l'accesso ad alcune voci di menu e di apportare modifiche alla presentazione. Se queste impostazioni devono essere utilizzate come misure di protezione effettive, è importante che gli utenti del documento eseguano l'accesso come USER. Qualsiasi utente che esegue l'accesso come ADMIN è autorizzato a modificare le impostazioni di sicurezza in qualsiasi momento.
Un utente che apre il documento con diritti USER non dispone delle pagine Sicurezza nelle finestra di dialogo Proprietà.
Riduzione dinamica dei dati
QlikView e QlikView Server supportano una funzionalità che consente di nascondere alcuni dati del documento all'utente in base all'autenticazione eseguita nella sezione relativa al controllo degli accessi.
Come prima cosa, i campi (le colonne) possono essere nascosti impiegando il campo di sistema OMIT.
In secondo luogo, i record (righe) possono essere nascosti collegando i dati di Section Access con i dati reali: La selezione dei valori da visualizzare/escludere viene controllata tramite uno o più campi aventi nomi comuni in Section Access e in Section Application. Dopo l'autenticazione dell'utente, QlikView esegue un tentativo di copia delle selezioni effettuate nei campi Section Access all'interno dei campi Section Application rispettando esattamente gli stessi nomi di campo (i nomi di campo devono essere scritti in MAIUSCOLO). Dopo avere effettuato le selezioni, QlikView nasconde definitivamente all'utente tutti i dati esclusi.
Per utilizzare questa procedura, è necessario selezionare l'opzione Riduzione iniziale dei dati basata su Section Access nella pagina Proprietà documento: Apertura. Se questa funzione è utilizzata in documenti che devono essere distribuiti mediante mezzi diversi da QlikView Server, è necessario selezionare l'opzione Caricamento binario non ammesso nella stessa pagina di Proprietà documento, al fine di mantenere la protezione dei dati.
Esempio:
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;
Il campo REDUCTION (maiuscolo) ora è incluso sia nella sezione relativa al controllo degli accessi sia nella sezione dell'applicazione (anche tutti i valori di campo sono in maiuscolo). In genere i due campi sono completamente diversi e separati; tuttavia, se è selezionata l'opzione Riduzione iniziale dei dati basata sul controllo degli accessi i due campi sono collegati e il numero dei record visualizzati all'utente si riduce.
Il campo OMIT in Section Access definisce i campi da nascondere all'utente.
Si otterrà il seguente risultato:
L'utente A può visualizzare tutti i campi, ma solo i record connessi a REDUCTION=1.
L'utente B può visualizzare tutti i campi eccetto NUM, e tuttavia solo i record connessi a REDUCTION=2.
L'utente C può visualizzare tutti i campi eccetto ALPHA e solo i record connessi a REDUCTION=3.
Restrizioni di accesso ereditate
L'istruzione binary load fa sì che il nuovo documento QlikView erediti le restrizioni di accesso. Un utente con diritti ADMIN per questo nuovo documento può modificare i diritti di accesso applicati allo stesso aggiungendo una nuova sezione relativa al controllo degli accessi. Un utente con diritti USER può eseguire e modificare lo script, quindi aggiungere dati personalizzati al file sottoposto a caricamento binario. Un utente con diritti USER non può modificare i diritti di accesso. In questo modo, l'amministratore di database può controllare l'accesso degli utenti anche ai documenti QlikView sottoposti a caricamento binario.
Crittografia
La trasmissione di dati fra un'istanza QlikView Server e un client QlikView Windows è crittografata. La crittografia non è invece prevista in caso di utilizzo di un client AJAX.
Inoltre, tutti i documenti QlikView sono crittografati per rendere le informazioni in essi contenute illeggibili mediante visualizzatori, debugger e così via.
È anche possibile crittografare i dati sensibili nei file QVD con coppie di chiavi fornite dal cliente che consentono di controllare chi accede ai propri dati. Vedere Crittografia QVD (solo in lingua inglese).
