Gestione della sicurezza dati con Section Access

Section Access è utilizzato per controllare la sicurezza di un'applicazione. In pratica rappresenta una parte dello script di caricamento dei dati in cui si aggiunge una tabella di sicurezza per definire chi può vedere cosa. Qlik Sense utilizza queste informazioni per ridurre i dati all'ambito appropriato quando l'utente apre l'applicazione, cioè alcuni dei dati nell'applicazione sono nascosti all'utente in base alla sua identità. Section Access è altamente integrato con i dati nell'app e si affida a essa per controllare l'accesso. Questa forma di riduzione dinamica dei dati può riferirsi a righe della tabella, colonne o a una combinazione di entrambe. Per ulteriori informazioni, vedere Trust and Security at Qlik.

Sezioni nello script di caricamento

Il controllo degli accessi ai dati viene gestito mediante una o più tabelle di sicurezza caricate secondo la normale procedura di caricamento dei dati. Ciò consente di memorizzare queste tabelle in un database standard o in un foglio di calcolo. Le istruzioni dello script che gestiscono le tabelle di sicurezza sono incluse nella sezione di autorizzazione, riconoscibile nello script perché inizia con l'istruzione Section Access.

Se nello script è definita una sezione di autorizzazione, la parte dello script relativa al caricamento dei dati dell'app deve essere inserita in una sezione diversa, che inizia con l'istruzione Section Application.

Esempio:

Section Access; Load * INLINE [ ACCESS, USERID, REDUCTION USER, AD_DOMAIN\ADMIN, * USER, AD_DOMAIN\A, 1 USER, AD_DOMAIN\B, 2 USER, AD_DOMAIN\C, 3 ADMIN, INTERNAL\SA_SCHEDULER, ]; Section Application; T1: Load *, NUM AS REDUCTION; LOAD Chr(RecNo()+ord('A')-1) AS ALPHA, RecNo() AS NUM AUTOGENERATE 3;

Tenere presente che dopo aver effettuato modifiche allo script di caricamento, è sempre necessario caricare i dati affinché le modifiche abbiano effetto.

Campi di sistema di Section access

I livelli di accesso sono assegnati agli utenti in uno o più tabelle di sicurezza situate all'interno della parte Section Access dello script. Queste tabelle devono contenere, come minimo, due campi di sistema: ACCESS, che rappresenta il campo che definisce il livello di accesso, e USERID o USER.EMAIL . Altri campi di sistema opzionali possono essere aggiunti in base al caso di utilizzo. Di seguito è descritto il gruppo completo dei campi del sistema di Section access.

ACCESS

Definisce il tipo di accesso che l'utente corrispondente dovrà avere.

L'accesso alle app di Qlik Sense può essere autorizzato per utenti o gruppi specifici. Nella tabella di sicurezza è possibile assegnare agli utenti i livelli di accesso ADMIN o USER. Un utente con privilegi ADMIN dispone dell'accesso a tutti i dati nell'app, fatto salvo quanto limitato dalla tabella di sicurezza. Un utente con privilegi USER può esclusivamente accedere ai dati, così come definito nella tabella di sicurezza. Se non viene assegnato alcun livello di accesso valido, all'utente non è consentito aprire l'app.

Se Section Access viene utilizzato in uno scenario di caricamento, INTERNAL\SA_SCHEDULER, ovvero l'utente del servizio dell'utilità di pianificazione, necessita l'accesso ADMIN per eseguire i caricamenti. Ad esempio:

Section Access; LOAD * inline [ ACCESS, USERID ADMIN, INTERNAL\SA_SCHEDULER ];

Se non si desidera utilizzare l'account INTERNAL\SA_SCHEDULER, vedere Utilizzo dell'impersonificazione per caricare i dati per un metodo alternativo.

Se Section Access viene utilizzato in uno scenario di generazione di app On-demand (ODAG) nell'app modello, deve essere incluso l'utente INTERNAL\SA_API come ADMIN nella tabella Section Access. Ad esempio:

Section Access; LOAD * inline [ ACCESS, USERID ADMIN, INTERNAL\SA_API ];

USERID

Contiene una stringa corrispondente a un nome di dominio e nome utente Qlik Sense. Qlik Sense recupera le informazioni di accesso dal servizio proxy e le confronta con il valore incluso in questo campo.

Un carattere jolly (*) viene interpretato come tutti gli oggetti, soggetto a ulteriori condizioni specificate nella tabella di sicurezza. Ad esempio, nella tabella di sicurezza seguente, gli utenti che si trovano negli Amministratori tenant Qlik Sense possono vedere tutti i valori di RIDUZIONE elencati.

Section Access; LOAD * INLINE [ ACCESS, USERID, GROUP, REDUCTION ADMIN, *, Qlik Sense Tenant Admins, * USER, QLIK-POC\SOMEOTHERUSER1, *, 1 USER, QLIK-POC\SOMEOTHERUSER2, *, 2 ... ];

USERID e NTNAME utilizzano entrambi le stesse informazioni di autenticazione, pertanto non è necessario spuntarli entrambi sulla stessa riga nella tabella di sicurezza. La differenza tra i due campi è che NTNAME controlla anche i gruppi.

NTNAME

NTNAME è un campo legacy di QlikView e si consiglia l'uso di USERID se QlikView non sta utilizzando la stessa tabella di sicurezza.

Un campo che dovrebbe contenere una stringa corrispondente a un nome utente o nome di gruppo del Dominio Windows. Se viene utilizzato un metodo di autenticazione diverso, esso dovrebbe contenere il nome di un utente autenticato. Qlik Sense recupererà le informazioni di accesso dal sistema operativo e le confronterà con il valore in questo campo.

GROUP

Contiene una stringa corrispondente a un gruppo in Qlik Sense. Qlik Sense risolverà l'utente specificato dal servizio proxy confrontandolo con questo gruppo.

SERIAL

SERIAL è un campo QlikView legacy e non viene utilizzato se si sta utilizzando soltanto Qlik Sense.

Contiene una stringa corrispondente alla piattaforma. Se il campo contiene la stringa ‘QLIKSENSE’ o un carattere jolly ‘*’, l'accesso può essere consentito, in base agli altri campi nella tabella di sicurezza.

Se il campo SERIAL contiene un numero di licenza, la riga Section Access negherà l'accesso al documento. Questa impostazione è valida solo in QlikView.

OMIT

Contiene il nome del campo che deve essere omesso per questo utente specifico. È possibile utilizzare caratteri speciali e il campo può essere vuoto.

Si raccomanda di non applicare OMIT sui campi chiave. I campi chiave omessi sono visibili nel sistema di visualizzazione modello dati, ma il loro contenuto non è disponibile e questo può confondere gli utenti. Inoltre l'applicazione di OMIT su campi utilizzati in una visualizzazione può rendere quest'ultima incompleta per gli utenti che non hanno accesso ai campi omessi.

Gestione dell'accesso degli utenti a un'app

Section access, nella sua forma più semplice, è utilizzabile per impedire a utenti specifici di accedere a un'app. Agli utenti viene negato l'accesso a un'app mediante esclusione. In altre parole, se un ID utente specifico non viene elencato nella tabella di sicurezza, non potrà accedere all'app. L'unica eccezione a questa regola è se un carattere jolly (*) viene assegnato al campo USERID in una delle righe nella tabella di sicurezza. Un carattere jolly, in questo caso, significa che tutti gli utenti autenticati possono accedere all'app. Ecco un esempio di una tabella di sicurezza con un elenco di ID utenti:

Section Access; LOAD * inline [ ACCESS, USERID ADMIN, AD_DOMAIN\ADMIN USER, AD_DOMAIN\A USER, AD_DOMAIN\B ]; Section Application;

Gestione dell'accesso utenti a dati specifici in un'app

La riduzione dinamica dei dati limita l'accesso a righe e colonne nelle tabelle dati all'interno delle app Qlik Sense dopo che un utente è stato autorizzato ad accedere all'app stessa.

Gestione dell'accesso ai dati di livello riga

Limitare l'accesso ai dati a livello di riga aggiungendo una colonna di riduzione dati sulla tabella di sicurezza nella sezione accesso dello script di caricamento. I record specifici (righe) possono essere nascosti dagli utenti collegando i dati di Section Access con i dati reali. La selezione dei dati da mostrare o escludere è controllata avendo uno o più campi di riduzione con nomi comuni in Section Access e parti di Section Application dello script. Dopo l'autenticazione dell'utente, Qlik Sense fa corrispondere le selezioni effettuate nei campi di riduzione nella sezione di accesso a tutti i campi nella sezione di applicazione, rispettando esattamente gli stessi nomi di campo (i nomi di campo devono essere scritti in maiuscolo). Dopo avere effettuato le selezioni, Qlik Sense nasconde definitivamente all'utente tutti i dati esclusi da queste selezioni. Se un carattere jolly (*) viene utilizzato come valore di campo nella colonna di riduzione dati, viene interpretato come una concessione dell'utente all'accesso a record associati con tutti i campi di riduzione selezionati nella tabella di sicurezza.

Il carattere jolly * nella colonna di riduzione dati fa riferimento solo a tutti i valori nella tabella di sicurezza. Se sono presenti valori nell'applicazione sezione non disponibili nella colonna riduzione della tabella di sicurezza, essi verranno ridotti.

Tutti i nomi di campo utilizzati nel trasferimento descritto sopra e tutti i valori di campo in questi campi devono essere in caratteri maiuscoli in quanto, per impostazione predefinita, tutti i nomi di campo e i valori di campo vengono convertiti in caratteri maiuscoli nella sezione di accesso.

Per impostazione predefinita, se si desidera abilitare il caricamento dello script in un'attività di Qlik Management Console, è richiesto l'utente dell'account INTERNAL\SA_SCHEDULER con accesso ADMIN. Se non si desidera utilizzare l'account INTERNAL\SA_SCHEDULER, vedere Utilizzo dell'impersonificazione per caricare i dati per un metodo alternativo.

Esempio: Riduzione dei dati di livello riga basata sull'identità utente

Section Access; Authorization: LOAD * inline [ ACCESS, USERID, REDUCTION ADMIN, AD_DOMAIN\ADMIN, * USER, AD_DOMAIN\A, 1 USER, AD_DOMAIN\B, 2 USER, AD_DOMAIN\C, * ADMIN, INTERNAL\SA_SCHEDULER, * ]; Section Application; T1: LOAD *, NUM AS REDUCTION; LOAD RecNo() AS NUM AUTOGENERATE 3;

In questo esempio, il campo REDUCTION (maiuscole) ora esiste sia in Section Access sia in Section Application (anche tutti i valori di campo sono in maiuscole). In genere i due campi sono diversi e separati; tuttavia, utilizzando Section Access, questi campi vengono collegati e il numero dei record visualizzati dall'utente viene ridotto.

Il risultato sarà:

L'utente ADMIN può visualizzare tutti i campi e solo i record che gli altri utenti possono vedere quando REDUCTION = 1 o REDUCTION =2.
L'utente A può visualizzare tutti i campi, ma solo i record associati a REDUCTION=1.
L'utente B può visualizzare tutti i campi, ma solo i record associati a REDUCTION=2.
L'utente C può visualizzare tutti i campi e solo i record che gli altri utenti possono vedere quando REDUCTION = 1 o REDUCTION =2.

Gestione dell'accesso ai dati di livello colonna

Limitare l'accesso ai dati a livello di colonna aggiungendo il campo di sicurezza OMIT alla tabella di sicurezza nello script Section Access. L'esempio seguente si basa sull'esempio precedente in cui la riduzione dei dati delle righe è già stata impostata.

Esempio: Riduzione dei dati delle colonne in base all'identità utente

Section Access; LOAD * inline [ ACCESS, USERID, REDUCTION, OMIT ADMIN, AD_DOMAIN\ADMIN, *, USER, AD_DOMAIN\A, 1, USER, AD_DOMAIN\B, 2, NUM USER, AD_DOMAIN\C, 3, ALPHA ADMIN, INTERNAL\SA_SCHEDULER, *, ]; Section Application; T1: LOAD *, NUM AS REDUCTION; LOAD Chr( RecNo()+ord('A')-1) AS ALPHA, RecNo() AS NUM AUTOGENERATE 3;

Il campo OMIT in Section Access definisce i campi da nascondere all'utente.

Il risultato sarà:

L'utente ADMIN può visualizzare tutti i campi e solo i record che possono vedere gli altri utenti in questo esempio quando REDUCTION è 1, 2 o 3.
L'utente A può visualizzare tutti i campi, ma solo i record associati a REDUCTION=1.
L'utente B può visualizzare tutti i campi eccetto NUM e solo i record associati a REDUCTION=2.
L'utente C può visualizzare tutti i campi eccetto ALPHA e solo i record associati a REDUCTION=3.

Alcune visualizzazioni presentano requisiti dati minimi che devono essere rispettati al fine di eseguire il rendering. Di conseguenza, potrebbe apparire il messaggio "Visualizzazione incompleta" nel caso in cui un campo a livello di colonna venga omesso dalla vista dati di un utente.

Gestione dell'accesso a gruppi di utenti

Section Access offre l'opzione di limitare l'ambito dei dati visibili agli utenti mediante l'appartenenza ai gruppi. Per limitare i propri dati usando i gruppi di utenti, aggiungere il nome di campo GROUP alla tabella di sicurezza nella sezione di accesso e definire i valori per il campo GROUP .

Esempio: Riduzione dei dati basata su gruppi di utenti

Section Access; LOAD * inline [ ACCESS, USERID, GROUP, REDUCTION, OMIT USER, *, ADMIN, *, USER, *, A, 1, USER, *, B, 2, NUM USER, *, C, 3, ALPHA USER, *, GROUP1, 3, ADMIN, INTERNAL\SA_SCHEDULER, *, *, ]; section application; T1: LOAD *, NUM AS REDUCTION; LOAD Chr( RecNo()+ord('A')-1) AS ALPHA, RecNo() AS NUM AUTOGENERATE 3;

Il risultato sarà:

Gli utenti che appartengono al gruppo ADMIN possono visualizzare tutti i dati e tutti i campi.
Gli utenti che appartengono al gruppo A possono visualizzare i dati associati a REDUCTION=1 in tutti i campi.
Gli utenti che appartengono al gruppo B possono visualizzare i dati associati a REDUCTION=2 ma non nel campo NUM.
Gli utenti che appartengono al gruppo C possono visualizzare i dati associati a REDUCTION=3, ma non nel campo ALPHA.
Gli utenti che appartengono al gruppo GROUP1 possono visualizzare i dati associati a REDUCTION=3 in tutti i campi.

Qlik Sense confronterà l'utente con UserID e risolverà l'utente relativamente ai gruppi della tabella. Se l'utente appartiene a un gruppo a cui è consentito l'accesso, o in caso di corrispondenza utente, sarà possibile accedere all'app.

Utilizzo dell'impersonificazione per caricare i dati

Per impostazione predefinita, l'account di sistema interno, SA_SCHEDULER, viene utilizzato per eseguire attività di caricamento. Questo account ha privilegi elevati e, tecnicamente, può utilizzare qualsiasi sorgente dati. Tuttavia, in QMC è presente un'impostazione che utilizza l'impersonificazione per eseguire le attività di caricamento con le autorizzazioni del proprietario dell'app invece dell'account di sistema interno. Configurando tale impostazione, per i caricamenti viene utilizzato il proprietario dell'app e non SA_SCHEDULER, pertanto non si aggiunge SA_SCHEDULER nella tabella Section Access ma si aggiunge invece il proprietario dell'app. All'interno di una catena di attività, le app possono avere proprietari diversi con autorizzazioni alle sorgenti in base ai diritti di accesso di ciascun proprietario. Vedere Cluster del servizio (solo in lingua inglese) per ulteriori informazioni.

Gestione dell'accesso utente in un ambiente multicloud

Un ambiente multicloud Qlik Sense coinvolge un mix di meccanismi di autenticazione utente. In genere, con Qlik Sense Enterprise on Windows, il valore USERID nella tabella di sicurezza Section Access è verificato dal servizio proxy. In Qlik Sense SaaS, un Provider identità assume tale ruolo di autenticazione. Di conseguenza, se Section Access viene configurato per un ambiente in loco come Qlik Sense Enterprise on Windows, non funzionerà in un ambiente cloud.

Quando si utilizza un Provider di identità OIDC (Qlik IdP o IdP personalizzato) con Qlik Sense SaaS, l'subject claim viene utilizzata per identificare gli utenti al momento dell'accesso. Con Section Access, il valore del campo USERID nella tabella di sicurezza viene confrontato con il valore dell'subject claim. Quando si configura il proprio tenant, assicurarsi che il nome dell'account SAM sia mappato all'subject claim del proprio provider di identità. Pertanto, ad esempio, se il nome dell'account SAM è AD_DOMAIN\Dev, impostare l'subject claim su AD_DOMAIN\Dev. Se si desidera vedere il valore dell'subject claim dell'IdP, aggiungere /api/v1/diagnose-claims all'URL tenant nel browser, ad esempio, your-tenant.us.qlikcloud.com/api/v1/diagnose-claims. Nella risposta JSON , l'subject claim è definita sub.

Se non è possibile utilizzare il nome account SAM , esiste un metodo alternativo per autenticare un utente. Dato che gli indirizzi e-mail tendono a rimanere invariati in ambienti diversi, è possibile utilizzare il campo USER.EMAIL al posto di USERID nella tabella di sicurezza. Ecco un esempio del possibile aspetto della tabella di sicurezza:

ACCESS	USERID	USER.EMAIL	Commento	COUNTRY
USER	ABC\Joe	*	Accesso in loco	Stati Uniti
USER	*	joe.smith@example.com	Accesso nel cloud	Stati Uniti
USER	ABC\Ursula	*	Accesso in loco	Germany
USER	*	ursula.schultz@example.com	Accesso nel cloud	Germany
USER	ABC\Stefan	*	Accesso in loco	Svezia
USER	*	stefan.svensson@example.com	Accesso nel cloud	Svezia

Script di autorizzazione:

Section Access; LOAD * INLINE [ ACCESS, USERID, USER.EMAIL, COUNTRY USER, ABC\Joe, *, United States USER, *, joe.smith@example.com, United States USER, ABC\Ursula, *, Germany USER, *, ursula.schultz@example.com, Germany USER, ABC\Stefan, *, Sweden USER, *, stefan.svensson@example.com, Sweden ];

Notare che ciascun utente presenta due record: Uno per l'accesso in loco e uno per l'accesso cloud. I caratteri jolly assicurano che vengano utilizzati solo i campi di autenticazione pertinenti. In questo esempio, COUNTRY è utilizzato come campo di riduzione dati.

Utilizzo di Section Access e Insight Advisor Chat

Per fare in modo che le app che utilizzano Section Access siano disponibili in Insight Advisor Chat, è necessario assicurarsi che i seguenti utenti del servizio abbiano l'accesso admin allo script di Section Access:

INTERNAL/sa_repository: Ciò rende lo script di Section Access disponibile con il servizio repository per controllare l'accesso degli utenti.
INTERNAL/sa_scheduler: Ciò consente il ricaricamento dell'app usando le attività QMC.

Se sono presenti informazioni sensibili nei nomi delle app, nei nomi dei campi o nei nomi delle voci principali, queste potrebbero essere esposte rendendo le app che usano Section Access disponibili per Insight Advisor Chat. I suggerimenti delle app per le query includono le app nei flussi a cui gli utenti hanno accesso. Queste possono includere app a cui gli utenti non hanno accesso nel Section Access di un'app. Ciononostante, la selezione di queste app non avrà alcuna conseguenza. Quando si fa clic su Dimensioni o Misure per visualizzare gli elementi disponibili da un'app utilizzando Section Access, gli utenti potrebbero vedere elementi a cui non hanno accesso. Tuttavia, fare clic su questi elementi non fornirà alcun dato agli utenti.

Ad esempio:

Section Access; LOAD * inline [ USERID ,ACCESS INTERNAL\sa_repository ,ADMIN INTERNAL\sa_scheduler ,ADMIN DOMAINNAME\user1 ,ADMIN DOMAINNAME\user2 ,USER DOMAINNAME\user3 ,USER ];

Una volta che questi utenti si trovano nello script Section Access, si può rendere l'app disponibile per Insight Advisor Chat. Una volta che l'app è stata ricaricata, l'app sarà disponibile in Insight Advisor Chat.

Linee guida e consigli per l'utilizzo di Section Access

Ecco alcuni dati importanti e suggerimenti utili da conoscere su Section Access.

Tutti i campi elencati nelle istruzioni LOAD o SELECT nella sezione di accesso devono essere scritti in maiuscolo. Convertire qualsiasi nome di campo del database contenente caratteri minuscoli in caratteri maiuscoli tramite la funzione Upper prima che il campo venga letto dall'istruzione LOAD o SELECT.
Per ulteriori informazioni, vedere Upper - funzione dello script e del grafico.
Non è possibile utilizzare i nomi dei campi del sistema Section Access elencati come nomi dei campi nel proprio modello dati.
Le app devono essere pubblicate prima dell'applicazione dei controlli di Section Access. Il caricamento dell'app non applica alcuno script nuovo o modificato di Section Access.
Uno snapshot visualizza i dati in base ai diritti di accesso dell'utente che lo esegue e può essere quindi condiviso in un racconto. Tuttavia, quando gli utenti tornano a una visualizzazione da un racconto per vedere i dati attivi nell'app, la visualizzazione è limitata dai loro diritti di accesso.
Non assegnare colori ai valori della dimensione principale se si utilizza Section Access o si trattano dati sensibili, poiché i valori potrebbero essere esposti dalla configurazione colore.
Per evitare di esporre dati con restrizioni, rimuovere tutti i file allegati con impostazioni Section Access prima di pubblicare l'app. Quando l'app viene pubblicata, sono inclusi i file allegati. Se l'app pubblicata viene copiata, i file allegati sono inclusi nella copia. Tuttavia, se ai file di dati allegati sono state applicate limitazioni di Section Access, le impostazioni di Section Access non verranno mantenute nei file copiati e gli utenti dell'app copiata potranno vedere tutti i dati nei file allegati.
Il carattere jolly (*) viene interpretato come tutti i valori (elencati) di questo campo nella tabella. Se viene utilizzato in un campo del sistema (USERID, GROUP) in 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).
I campi di sicurezza possono essere posizionati in tabelle diverse.
Al momento di caricare i dati da un file QVD, la funzione Upper rallenta la velocità di caricamento.
Se non è possibile accedere a un'app dopo aver impostato Section Access, sarà comunque possibile aprirla senza dati e modificare la sezione relativa al controllo degli accessi nello script di caricamento dei dati. L'utente deve disporre dell'accesso per la modifica e il caricamento dello script di caricamento dei dati.
Per ulteriori informazioni, vedere Apertura di un'app senza dati.
Un caricamento binario fa sì che la nuova app Qlik Sense erediti le restrizioni di accesso.

Hai trovato utile questa pagina?

Se riscontri problemi con questa pagina o con il suo contenuto – un errore di battitura, un passaggio mancante o un errore tecnico – facci sapere come possiamo migliorare!

Lascia qui il tuo feedback