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 Cloud 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.
Tutti i nomi e i valori di campo elencati in Section Access sono sempre convertiti in maiuscolo. Di conseguenza, tutti i campi che appartengono a una riduzione devono essere convertiti in maiuscolo per corrispondere all'istruzione in Section Access, anche se si trovano al di fuori di quest'ultima. È possibile convertire qualsiasi nome di campo contenente caratteri minuscoli nel database in caratteri maiuscoli utilizzando la funzione Upper prima che il campo venga letto dalle istruzioni LOAD o SELECT.
Per ulteriori informazioni, vedere Upper - funzione dello script e del grafico.
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:
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.
USERID
Contiene una stringa corrispondente al nome utente di Qlik Cloud. Qlik Cloud otterrà le informazioni di accesso dall'oggetto IdP e le confronterà con il valore in questo campo. Per un modo alternativo di verificare l'identità degli utenti usando l'indirizzo e-mail, vedere USER.EMAIL. Per gli ambienti multi-cloud, l'oggetto IdP può essere mappato rispetto alla propria identità interna di Windows. Al momento di utilizzare Account Qlik, non è possibile mappare l'oggetto rispetto a un'identità interna di Windows. L'oggetto IdP dell'utente può essere visualizzato nella sezione Utenti del centro attività Amministrazione.
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.
NTNAME
Un campo che dovrebbe contenere una stringa corrispondente alla versione NetBIOS di un nome utente o nome di gruppo del Dominio Windows NT. Se viene utilizzato un metodo di autenticazione diverso, esso dovrebbe contenere il nome di un utente autenticato.
Qlik Cloud recupererà le informazioni di accesso dall'attestazione subject del provider di identità e le confronterà al valore contenuto in questo campo.
USER.EMAIL
Contiene una stringa corrispondente a un indirizzo e-mail utente. Qlik Cloud otterrà queste informazioni dal provider di identità e le confronterà con il valore in questo campo.
GROUP
Contiene una stringa corrispondente a un gruppo in Qlik Cloud. Qlik Cloud otterrà tali informazioni dall'attestazione “groups” del provider di identità e le confronterà al valore in questo campo.
OMIT
Contiene il nome del campo che deve essere omesso per questo utente specifico. È possibile utilizzare caratteri speciali e il campo può essere vuoto.
Gestione dell'accesso degli utenti a un'app
Un utente con USERID AD_DOMAIN\C non sarebbe affatto in grado di aprire l'app, perché tale ID utente non è elencato nella tabella di sicurezza.
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 indirizzo e-mail di un 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 USER.EMAIL 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:
Un utente con USER.EMAIL USER4@esempio.com non sarebbe affatto in grado di aprire l'app, perché tale indirizzo e-mail utente non è elencato nella tabella di sicurezza.
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.
Quando Qlik Sense confronta il campo di riduzione in Section Access con il modello dati, sono previsti i seguenti comportamenti:
Se il valore di un campo nel modello dati corrisponde al campo di riduzione in Section Access, l'app si aprirà per mostrare i dati associati alla corrispondenza per l'utente specificato. Gli altri dati saranno nascosti.
Se il valore del campo di riduzione non corrisponde a nessuno dei valori nel modello dati, l'app non si aprirà per un UTENTE normale. Tuttavia, si aprirà senza limitazioni per un utente contrassegnato come ADMIN.
Non si consiglia l'utilizzo di più campi di riduzione in Section Access, poiché consentirà combinazioni di accesso diverse da quelle desiderate.
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.
Esempio: Riduzione dei dati di livello riga basata sull'identità utente
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 USER1@EXAMPLE.COM può visualizzare tutti i campi e solo i record che gli altri utenti possono vedere quando REDUCTION = 1 o REDUCTION =2.
- L'utente USER2@EXAMPLE.COM può visualizzare tutti i campi, ma solo i record associati a REDUCTION=1.
- L'utente USER3@EXAMPLE.COM può visualizzare tutti i campi, ma solo i record associati a REDUCTION=2.
- L'utente USER4@EXAMPLE.COM 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
Il campo OMIT in Section Access definisce i campi da nascondere all'utente.
Il risultato sarà:
- L'utente USER1@example.com 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 USER2@example.com può visualizzare tutti i campi, ma solo i record associati a REDUCTION=1.
- L'utente USER3@example.com può visualizzare tutti i campi eccetto NUM e solo i record associati a REDUCTION=2.
- L'utente USER4@example.com può visualizzare tutti i campi eccetto ALPHA e solo i record associati a REDUCTION=3.
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
Il risultato sarà:
- Gli utenti che appartengono al gruppo ADMIN possono visualizzare tutti i campi e solo i record che gli altri utenti possono vedere in questo esempio quando REDUCTION è 1, 2 o 3.
- 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.
- L'utente AD_DOMAIN\DEV è autorizzato a visualizzare tutti i dati in tutti i campi.
Qlik Cloud 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.
Caricamento dati in Qlik Cloud
Per caricare un'app senza riduzione dati in Qlik Cloud, si raccomanda di utilizzare il campo del sistema USER.EMAIL nella tabella di sicurezza. Il valore per il campo USER.EMAIL deve corrispondere all'indirizzo e-mail degli utenti che sono in grado di modificare e caricare l'app. Ciò si applica alle app in spazi gestiti e condivisi. Ad esempio:
In questo esempio, l'utente con indirizzo e-mail test@example.com è ADMIN ed è in grado di caricare l'app.
Se si stanno utilizzando gruppi, il seguente esempio funzionerebbe ugualmente per Qlik Sense e Qlik Cloud:
È inoltre possibile mappare USERID nella tabella di sicurezza per l'subject claim del Provider di identità, come mostrato nell'esempio seguente. Questa configurazione è suggerita per la migrazione da Qlik Sense a Qlik Cloud e per gli ambienti multicloud. Per ulteriori informazioni sulla mappatura del valore USERID per l'subject claim, vedere Gestione dell'accesso utente in un ambiente multicloud
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 Cloud, 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 o SAML (Qlik IdP o IdP personalizzato) con Qlik Cloud, subject claim viene utilizzato 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 | Germania |
| USER | * | URSULA.SCHULTZ@EXAMPLE.COM | Accesso nel cloud | Germania |
| USER | ABC\STEFAN | * | Accesso in loco | Svezia |
| USER | * | STEFAN.SVENSSON@EXAMPLE.COM | Accesso nel cloud | Svezia |
Script di autorizzazione:
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.
Campi di autorizzazione QlikView
Per la retrocompatibilità, Qlik Cloud riconosce i campi di autorizzazione da QlikView. Nonostante USERID venga interpretato in modo diverso in QlikView e Qlik Cloud, in Qlik Cloud verrà interpretato così come avviene in Qlik Sense: verrà fatto corrispondere al nome dell'utente autenticato.
PASSWORD, NTSID e NTDOMAINSID
Se viene utilizzato uno dei campi PASSWORD, NTSID e NTDOMAINSID contenente un valore rilevante, l'accesso al documento sarà negato. Se il campo contiene un carattere jolly (*), l'accesso può essere consentito, in base ad altri campi nella tabella di autorizzazione.
SERIAL
Se viene utilizzato il campo SERIAL e al suo interno è presente un numero di licenza, la riga Section Access negherà l'accesso al documento. Se il campo contiene un carattere jolly (*), l'accesso può essere consentito, in base ad altri campi nella tabella di autorizzazione.
Inoltre, in Qlik Cloud questo campo può anche essere utilizzato per definire l'ambiente. Ciò significa che se il campo contiene la stringa 'QLIKCLOUD', l'accesso potrebbe essere consentito, in base agli altri campi presenti nella tabella di autorizzazione.
Ambienti misti
Se si pianifica l'utilizzo della stessa tabella di sicurezza per QlikView e Qlik Cloud, tenere presente che:
• USERID presenta significati diversi in QlikView e Qlik Cloud, e potrebbe, se utilizzato, causare problemi di sicurezza. Utilizzare invece NTNAME oppure combinarlo con SERIAL come descritto in basso.
• GROUP e i campi che iniziano con ‘USER.’, come 'USER.NAME' e 'USER.EMAIL', sono (o saranno) campi di autorizzazione in Qlik Cloud. Se si utilizzano tali campi nel proprio Section Access, l'accesso potrebbe essere negato in Qlik Cloud.
• PASSWORD, NTSID e NTDOMAINSID non possono essere utilizzati in Qlik Cloud. L'accesso verrà negato, a meno che non venga utilizzato un carattere jolly.
• Non è possibile utilizzare SERIAL per verificare il numero di licenza in Qlik Cloud. Tuttavia, se il campo contiene la stringa ‘QLIKCLOUD’, l'accesso potrebbe essere garantito. Ciò significa che è possibile avere una tabella di sicurezza come la seguente, ma in cui la riga 1 concederà l'accesso a QlikView (ma non a Qlik Cloud), e la riga 2 concederà l'accesso a Qlik Cloud (ma non a QlikView).
| Linea | SERIAL | USERID | Commento |
|---|---|---|---|
| 1 | 4600 0123 4567 8901 | * | Concede l'accesso al numero di licenza corretto in QlikView. |
| 2 | QLIKCLOUD | JOHN DOE | Concede l'accesso all'utente corretto in Qlik Cloud. |
Script di autorizzazione:
Utilizzo di Section Access e Insight Advisor Chat
Le app che utilizzano Section Access impiegano un utente indice per determinare quante informazioni Insight Advisor Chat recuperi dall'app. L'utente indice dovrebbe essere l'utente con il più alto livello di accesso per l'app nello script Section Access. I dati forniti agli utenti finali, tuttavia, sono ancora controllati dalle limitazioni di Section Access.
Per una dimostrazione visiva dell'uso di Section Access e Insight Advisor Chat, vedere:
Utilizzo di Section Access e Insight Advisor Chat
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 sulle app per le query includono le app negli spazi a cui gli utenti hanno accesso. Questi possono inoltre includere app a cui gli utenti non hanno accesso nell'impostazione Section Access dell'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.
Per impostazione predefinita, il proprietario dell'app è l'utente indice. È possibile modificare l'utente indice in Dettagli.
Procedere come indicato di seguito:
In Qlik Cloud, navigare nell'app.
Fare clic su
sull'app e selezionare Dettagli.Sotto Utente indice, selezionare l'utente indice.
Fare clic su Indietro.
Fare clic su
sull'app e selezionare Ricarica.
Utilizzo di file QVD con Section Access
I file QVD possono essere letti come un caricamento normale o un caricamento ottimizzato. Un caricamento è ottimizzato quando non ci sono trasformazioni dei dati durante il caricamento e non ci sono filtri in una clausola WHERE.
I caricamenti ottimizzati non funzionano quando si utilizzano file QVD con Section Access. Se si vuole utilizzare un file QVD per caricare dati in Section Access, è necessario espandere il file QVD. Il modo più semplice per espandere il file QVD è modificare la formattazione quando si caricano i dati.
Nel seguente esempio, il QVD non è espanso perché i dati non sono stati formattati.
Esempio: Esempio non funzionante senza formattazione dei dati (caricamento ottimizzato)
Invece, è possibile, ad esempio, utilizzare la funzione upper() per formattare i dati, con una conseguente espansione del file QVD.
Esempio: Esempio funzionante con formattazione dei dati
È inoltre possibile aggiungere un'istruzione Where 1=1 all'istruzione LOAD.
Esempio: Un altro esempio funzionante con formattazione dei dati
Linee guida e consigli per l'utilizzo di Section Access
Ecco alcuni dati importanti e suggerimenti utili da conoscere su Section Access.
- Tutti i nomi e i valori di campo elencati in Section Access sono sempre convertiti in maiuscolo. Di conseguenza, tutti i campi che appartengono a una riduzione devono essere convertiti in maiuscolo per corrispondere all'istruzione in Section Access, anche se si trovano al di fuori di quest'ultima. È possibile convertire qualsiasi nome di campo contenente caratteri minuscoli nel database in caratteri maiuscoli utilizzando la funzione Upper prima che il campo venga letto dalle istruzioni 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.