Restrizioni Accessi - Access Restriction (Section Access)

IT
Più la Business Intelligence è radicata, maggiore è il rischio che dati sensibili siano a disposizione di chi non dovrebbe vederli.
Il processo di Business Intelligence dovrebbe andare sempre a braccetto di un'attività di verifica sulla privacy e sicurezza (non a caso il Dlgs 196/2003 obbliga le aziende a designare un responsabile alla sicurezza).

QlikView sa che prevenire è meglio di curare, e permette di limitare la visibilità di dati in più modi:

QlikView Analyzer/Professional/Enterprise (il programma per Windows)

• è possibile richiedere utente e password all'apertura del documento, negando l'accesso o filtrando i dati

QlikView Server (accesso via web)
Usare il server è la soluzione ideale: si può fare quanto suddetto, ma si hanno anche i seguenti vantaggi:

• si ha un repository con tutti i documenti QlikView (non si rischia che un utente si copi un .qvw e se lo porti a casa, o lo venda alla concorrenza)
• viene tenuta traccia di ogni accesso (utente, documento, ora, durata, ecc)
• si possono nascondere interi documenti (l'utente non ne conoscerà l'esistenza) o parti di documenti a certi utenti
• tutte le comunicazioni col server sono crittografate (RSA 128bit)
• si possono restringere gli accessi in base all'utenza di rete (la cui password deve cambiare periodicamente, sempre secondo il suddetto decreto legislativo)
• non esiste il rischio (attualmente solo virtuale, non reale) che si rompa la sicurezza di QlikView standalone e si riesca ad aprire comunque il documento o estrarne i dati senza aprirlo, visto che non si ha accesso fisico al file

Ci sono altri vantaggi ad utilizzare QlikView Server (non si duplicano documenti, non si rischiano modifiche contemporanee, si può accedere da Linux e MacOS...), ma, per quanto interessante, è un'altra storia.

Qualunque sia la soluzione adottata, è necessaria una profonda comprensione dei meccanismi di restrizione accessi di QlikView (l'utilizzo della Section Access), poiché una policy scorretta comporta gravi rischi: banalmente, il fallimento della restrizione, ma anche la distruzione totale e irrecuperabile del documento (qualora si scrivano condizioni di accesso sempre false per ipotesi), nel qual caso il documento va riscritto da zero.
E' per questo che nei prossimi giorni scriverò un messaggio con un po' di appunti miei e dei miei soci di Querit, visto che l'help in linea e la documentazione esistente sono tutt'altro che esaustivi e spesso alquanto ambigui.

EN
The deeper the Business Intelligence goes, the higher the risk of leaking data.
The B.I. process should be tightly coupled with privacy and security practices.

I.T. security should be proactive, not reactive.
QlikView allows the developer to restrict accesses in several ways:

QlikView Analyzer/Professional/Enterprise (Windows standalone app)

• document opening protected by user and password, denying access or restricting data to certain users

QlikView Server (web access)
QVS is the best way to ensure security: the former method still works, though you gain many advantages:

• it is a document repository (users can't bring .qvw files home or sell them to competitors)
• every single access is logged (user, document, date and time, duration, etc)
• whole documents can be hidden (users won't even know their existence) or part of documents to certain users
• client-server communications run over a secure socket layer (128bit RSA)
• accesses can be restricted based on a domain user or group name
• no risk that the QlikView standalone app security can be broken, or the qvw format is reverse engineered in order to extract data, since users don't have physical access to the file

There are many other advantages in using QlikView Server, (no documents springing up everywhere, no concurrent savings, Linux and MacOS clients...) but they don't belong here, though interesting nevertheless.

Whichever way you choose, you need a deep knowledge of QlikView access restriction mechanisms in order not to have high risks, since a broken policy could just leave data available for everyone as well as irreparably compromise documents, which shall then be rewritten from scratch.
That's why in the next few days I'm going to post some notes about access restrictions, since the online help is often quite obscure and incomplete.