Amazon QuickSight è un servizio di business intelligence (BI) cloud-native completamente gestito che semplifica la connessione ai dati, la creazione di dashboard interattivi e la condivisione di questi con decine di migliaia di utenti, all'interno di QuickSight stesso o integrato nel software come app di servizio (SaaS).
QuickSight Enterprise Edition ha recentemente aggiunto la sicurezza a livello di riga (RLS) utilizzando i tag, una nuova funzionalità che consente agli sviluppatori di condividere un'unica dashboard con decine di migliaia di utenti, garantendo al contempo che ogni utente possa vedere e avere accesso solo a dati particolari. Ciò significa che quando un fornitore di software indipendente (ISV) aggiunge un dashboard integrato in QuickSight nella sua app, non deve fornire i propri utenti finali in QuickSight e può semplicemente impostare tag per filtrare i dati in base a chi è il dashboard essere servito a. Ad esempio, se un ISV desiderasse impostare un dashboard da condividere con 20,000 utenti su 100 clienti di un'app, con tutti gli utenti di un cliente che hanno accesso a dati identici, questa nuova funzionalità consente di condividere un unico dashboard per tutti gli utenti, senza dover configurare o gestire i 20,000 utenti in QuickSight.
L'applicazione dell'RLS tramite i tag garantisce che ogni utente finale veda solo i dati rilevanti per lui, mentre QuickSight si ridimensiona automaticamente per soddisfare la concorrenza degli utenti per garantire che ogni utente finale veda prestazioni costantemente veloci. In questo post, vediamo come questo può essere implementato.
Panoramica della soluzione
Per incorporare dashboard senza provisioning utente, utilizziamo l'API GeneraEmbedURLForAnonymousUser, che funziona con QuickSight's prezzi della capacità di sessione. Con questa API, il server di incorporamento (logica nell'app SaaS) determina e gestisce l'identità dell'utente a cui viene visualizzata la dashboard (al contrario di questa identità fornita e gestita all'interno di QuickSight).
Il diagramma seguente mostra un flusso di lavoro di esempio di dashboard incorporati che protegge i dati in base a chi accede all'applicazione utilizzando RLS con tag.
In questo caso, un ISV ha un'applicazione SaaS a cui accedono due utenti finali. Uno è un manager e l'altro è un supervisore del sito. Entrambi gli utenti accedono alla stessa applicazione e alla stessa dashboard QuickSight incorporata nell'applicazione e non sono forniti in QuickSight. Quando il supervisore del sito accede al dashboard, vede solo i dati relativi al proprio sito e quando il manager accede al dashboard, vede i dati relativi a tutti i siti che gestisce.
Per ottenere questo comportamento, utilizziamo una nuova funzionalità che consente di configurare la sicurezza a livello di riga utilizzando i tag. Questo metodo di protezione dei dati sui dashboard incorporati funziona solo quando i dashboard sono incorporati senza provisioning dell'utente (chiamato anche incorporamento anonimo). Il processo prevede due passaggi:
- Imposta le chiavi dei tag nelle colonne dei set di dati utilizzati per creare il dashboard.
- Imposta i valori per le chiavi dei tag in fase di esecuzione quando incorpori il dashboard in modo anonimo.
Imposta le chiavi dei tag sulle colonne nei set di dati utilizzati per creare il dashboard
Gli ISV o gli sviluppatori possono impostare colonne sui set di dati utilizzando il CreateDataset
or UpdateDataset
API come segue:
Nel codice di esempio precedente, row-level-permission-tag-configuration
è l'elemento che puoi utilizzare per definire chiavi di tag nelle colonne di un set di dati. Per ogni tag è possibile definire i seguenti elementi facoltativi:
- TagMultiValueDelimiter – Questa opzione, se impostata su una colonna, consente di passare più di un valore al tag in fase di esecuzione e i valori sono delimitati dalla stringa impostata per questa opzione. In questo esempio, una virgola è impostata come stringa di delimitazione.
- CorrispondenzaTuttoValore – Questa opzione, se impostata su una colonna, consente di passare tutti i valori di una colonna in fase di esecuzione e i valori sono rappresentati dalla stringa impostata per questa opzione. In questo esempio, un asterisco è impostato come una stringa di corrispondenza.
Dopo aver definito i nostri tag, possiamo abilitare o disabilitare queste regole usando il Status
elemento dell'API. In questo caso il valore è impostato su ENABLED
. Per disabilitare le regole, il valore è DISABLED
. Dopo che i tag sono stati abilitati, possiamo passare i valori ai tag in fase di esecuzione per proteggere i dati visualizzati in base a chi accede alla dashboard.
Ogni set di dati può avere fino a 50 chiavi tag.
Riceviamo la seguente risposta per il CreateDataset
or UpdateDataset
API:
Consenti agli autori di accedere ai dati protetti dalle chiavi dei tag durante la creazione dell'analisi
Dopo che le chiavi dei tag sono state impostate e abilitate sul set di dati, questo è protetto. Gli autori quando utilizzano questo set di dati per creare un dashboard non vedono alcun dato. Devono disporre delle autorizzazioni per visualizzare i dati nel set di dati durante la creazione di un dashboard. Per concedere agli autori di QuickSight l'autorizzazione a visualizzare i dati nel set di dati, creare un file di autorizzazioni o un set di dati delle regole. Per ulteriori informazioni, vedere Creazione di regole del set di dati per la sicurezza a livello di riga. Di seguito è riportato un set di dati di regole di esempio.
UserName | nome_colonna_1 | nome_colonna_2 | nome_colonna_3 |
amministratore/autore del campione |
In questo set di dati di esempio, abbiamo il nome utente dell'autore elencato nella colonna UserName. Le altre tre colonne sono le colonne del set di dati su cui impostiamo le chiavi dei tag. I valori vengono lasciati vuoti per queste colonne per l'autore aggiunto a questa tabella. Ciò consente all'autore di visualizzare tutti i dati in queste colonne senza alcuna restrizione durante la creazione delle analisi.
Imposta i valori sulle chiavi dei tag in fase di esecuzione quando incorpori il dashboard
Dopo che le chiavi dei tag sono state impostate per le colonne dei set di dati, gli sviluppatori impostano i valori sulle chiavi in fase di esecuzione quando incorporano il dashboard. Gli sviluppatori chiamano l'API GenerateDashboardEmbedURLForAnonymousUser
per incorporare la dashboard e passare i valori alle chiavi dei tag nell'elemento SessionTags
, come mostrato nel seguente codice di esempio:
Poiché questa funzione protegge i dati per gli utenti non forniti in QuickSight, la chiamata API è per AnonymousUser
solo e quindi questa funzione funziona solo con l'API GenerateDashboardEmbedURLForAnonymousUser
.
Il codice di esempio precedente ha i seguenti componenti:
- Nel
tag_name_1
, si impostano due valori (value1
edvalue2
) usando ilTagMultiValueDelimiter
definito durante l'impostazione delle chiavi dei tag (in questo caso, una virgola). - Nel
tag_name_2
, imposti un valore come asterisco. Ciò consente a questa chiave di tag di avere tutti i valori per quella colonna assegnati perché abbiamo definito l'asterisco come ilMatchAllValue
quando si imposta una chiave tag sulla colonna in precedenza. - Nel
tag_name_3
, imposti un valore (value3
).
Definizione della risposta API
La risposta dell'API ha il EmbedURL
, Status
e RequestID
. Puoi incorporare questo URL nella tua pagina HTML. I dati in questa dashboard sono protetti in base ai valori passati alle chiavi dei tag quando si chiama l'API di incorporamento GenerateDashboardEmbedURLForAnonymousUser
:
- EmbedUrl (stringa) – Un URL monouso che puoi inserire nella tua pagina web lato server per incorporare la tua dashboard. Questo URL è valido per 5 minuti. L'operazione API fornisce all'URL un
auth_code
valore che abilita un (e solo uno) accesso a una sessione utente valido fino a 10 ore. Questo URL esegue il rendering del dashboard con le regole RLS applicate in base ai valori impostati per le chiavi dei tag RLS. - Stato (intero) – Lo stato HTTP della richiesta.
- IDRichiesta (stringa) – L'ID richiesta AWS per questa operazione.
Controllo degli accessi a grana fine
È possibile ottenere un controllo degli accessi granulare utilizzando dynamic Gestione dell'identità e dell'accesso di AWS (IAM) generazione di criteri. Per ulteriori informazioni, vedere Isolamento dei tenant SaaS con policy IAM generate dinamicamente. Quando si utilizza il GenerateEmbedUrlForAnonymousUser
API per l'incorporamento, è necessario menzionare due tipi di risorse nella policy IAM: gli ARN dello spazio dei nomi a cui appartengono virtualmente gli utenti anonimi e gli ARN del dashboard che possono essere utilizzati nel AuthorizedResourceArns
valore del parametro di ingresso. Le sessioni generate utilizzando questa API possono accedere alle risorse autorizzate ea quelle (dashboard) condivise con il namespace.
Poiché gli utenti anonimi fanno parte di uno spazio dei nomi, tutti i dashboard condivisi con lo spazio dei nomi sono accessibili a loro, indipendentemente dal fatto che siano passati esplicitamente tramite il AuthorizedResourceArns
parametro.
Per consentire all'identità del chiamante di generare un URL per qualsiasi utente e qualsiasi dashboard, il Resource
il blocco del criterio può essere impostato su *
. Per consentire all'identità del chiamante di generare un URL per qualsiasi utente anonimo in uno spazio dei nomi specifico (come Tenant1
), La Resource
parte della politica può essere impostata su arn:aws:quicksight:us-east-1:<YOUR_AWS_ACCOUNT_ID>:namespace/Tenant1
. Questo è lo stesso per l'ID dashboard. Per la generazione di criteri dinamici, puoi anche utilizzare i segnaposto per lo spazio dei nomi e gli utenti.
Il codice seguente è un esempio di policy IAM:
Caso d'uso
OkTank è un ISV nel settore sanitario. Hanno un'applicazione SaaS che viene utilizzata da diversi ospedali in diverse regioni del paese per gestire le proprie entrate. OkTank ha migliaia di dipendenti del settore sanitario che accedono alla loro applicazione e ha incorporato operazioni relative alla loro attività in una dashboard QuickSight nella loro applicazione. OkTank non vuole gestire i propri utenti in QuickSight separatamente e vuole proteggere i dati in base all'utente da quale ospedale accede alla propria applicazione. OkTank sta proteggendo i dati sui dashboard in fase di esecuzione utilizzando la sicurezza a livello di riga utilizzando i tag.
OkTank ha ospedali (North Hospital, South Hospital e Downtown Hospital) nelle regioni Central, East, South e West.
In questo esempio, i seguenti utenti accedono all'applicazione di OkTank e alla dashboard incorporata. Ogni utente ha un certo livello di regole di restrizione che definiscono a quali dati può accedere nei dashboard. PowerUser
è un super utente che può vedere i dati per tutti gli ospedali e le regioni.
Utente dell'applicazione di OkTank | Ospedale | Regione |
Utente Nord | Ospedale del Nord | Centro e Oriente |
NordAdmin | Ospedale del Nord | Tutte le regioni |
Utente del Sud | Ospedale del sud | Sud |
SudAdmin | Ospedale del sud | Tutte le regioni |
Power user | Tutti gli ospedali | Tutte le regioni |
A nessuno di questi utenti è stato eseguito il provisioning in QuickSight. OkTank gestisce questi utenti nella propria applicazione e quindi sa a quale regione e ospedale appartiene ogni utente. Quando uno di questi utenti accede al dashboard QuickSight integrato nell'applicazione, OkTank deve proteggere i dati sul dashboard in modo che gli utenti possano vedere solo i dati della propria regione e ospedale.
Innanzitutto, OkTank ha creato chiavi di tag sul set di dati che stanno utilizzando per alimentare la dashboard. nella loro UpdateDataset
chiamata API, il RowLevelPermissionTagConfiguration
elemento sul set di dati è il seguente:
In secondo luogo, in fase di esecuzione quando si incorpora la dashboard tramite il GenerateDashboardEmbedURLForAnonymousUser
API, hanno impostato SessionTags
per ogni utente.
SessionTags
per NorthUser
nel GenerateDashboardEmbedURLForAnonymousUser
Le chiamate API sono le seguenti:
SessionTags
per NorthAdmin
sono come segue:
SessionTags
per SouthUser
sono come segue:
SessionTags
per SouthAdmin
sono come segue:
SessionTags
per PowerUser
sono come segue:
La seguente schermata mostra cosa SouthUser
vede relative al South Hospital nella regione del sud.
La seguente schermata mostra cosa SouthAdmin
vede relative al South Hospital in tutte le regioni.
La seguente schermata mostra cosa PowerUser
vede relative a tutti gli ospedali in tutte le regioni.
Sulla base dei tag di sessione, OkTank ha dati protetti sui dashboard incorporati in modo tale che ogni utente veda solo dati specifici in base al proprio accesso. Puoi accedere alla dashboard come uno degli utenti (modificando l'utente nel menu a tendina in alto a destra) e vedere come cambiano i dati in base all'utente selezionato.
Nel complesso, con la sicurezza a livello di riga che utilizza i tag, OkTank è in grado di fornire un'esperienza di analisi convincente all'interno della propria applicazione SaaS, assicurandosi che ogni utente veda solo i dati appropriati senza dover fornire e gestire gli utenti in QuickSight. QuickSight offre un'opzione di analisi sicura e altamente scalabile che puoi configurare e implementare in produzione in pochi giorni, anziché settimane o mesi prima.
Conclusione
La combinazione dell'incorporamento del dashboard per gli utenti non sottoposti a provisioning in QuickSight e della sicurezza a livello di riga utilizzando i tag consente agli sviluppatori e agli ISV di impostare rapidamente e facilmente analisi sofisticate e personalizzate per gli utenti delle loro applicazioni, il tutto senza alcuna configurazione o gestione dell'infrastruttura e scalando a milioni di utenti . Per ulteriori aggiornamenti da Analisi integrate QuickSight, Vedere Novità della Guida per l'utente di Amazon QuickSight.
Informazioni sugli autori
Raji Sivasubramaniam è uno Specialist Solutions Architect presso AWS, specializzato in Analytics. Raji ha 20 anni di esperienza nell'architettura di soluzioni end-to-end di Enterprise Data Management, Business Intelligence e Analytics per aziende Fortune 500 e Fortune 100 in tutto il mondo. Ha un'esperienza approfondita in dati e analisi sanitari integrati con un'ampia varietà di set di dati sanitari tra cui mercato gestito, targeting per medici e analisi dei pazienti. Nel suo tempo libero, Raji ama le escursioni, lo yoga e il giardinaggio.
Srikanth Baheti è un architetto di soluzioni specializzato in tutto il mondo per Amazon QuickSight. Ha iniziato la sua carriera come consulente e ha lavorato per diverse organizzazioni private e governative. Successivamente ha lavorato per PerkinElmer Health and Sciences & eResearch Technology Inc, dove era responsabile della progettazione e dello sviluppo di applicazioni Web ad alto traffico, pipeline di dati altamente scalabili e manutenibili per piattaforme di reporting che utilizzano i servizi AWS e l'elaborazione Serverless.
Kareem Syed-Mohammed è un Product Manager presso Amazon QuickSight. Si concentra su analisi integrate, API ed esperienza degli sviluppatori. Prima di QuickSight ha lavorato in AWS Marketplace e Amazon Retail come PM. Kareem ha iniziato la sua carriera come sviluppatore e poi PM per le tecnologie dei call center, Local Expert e Ads per Expedia. Ha lavorato come consulente con McKinsey and Company per un breve periodo.
- '
- "
- &
- 000
- 100
- 11
- accesso
- Il mio account
- Action
- Ads - Annunci
- Tutti
- Amazon
- analitica
- api
- API
- App
- Applicazioni
- applicazioni
- applicazioni
- gli autori
- AWS
- costruire
- affari
- business intelligence
- chiamata
- Ultra-Grande
- Career
- codice
- Colonna
- Aziende
- azienda
- informatica
- consulente
- Clienti
- cruscotto
- dati
- gestione dei dati
- Costruttori
- sviluppatori
- In centro città
- dipendenti
- Impresa
- esperienza
- FAST
- caratteristica
- Enti Pubblici
- Salute e benessere
- assistenza sanitaria
- qui
- Alta
- escursionismo
- Ospedale
- ospedali
- Come
- HTTPS
- IAM
- Identità
- Compreso
- informazioni
- Infrastruttura
- Intelligence
- interattivo
- IT
- Le
- Tasti
- Livello
- locale
- Fare
- gestione
- Rappresentanza
- mercato
- partita
- mese
- nuova funzione
- Nord
- Operazioni
- Opzione
- Altro
- performance
- medico
- Piattaforme
- politica
- energia
- un bagno
- Prodotto
- Produzione
- risorsa
- Risorse
- risposta
- nello specifico retail
- Le vendite
- Rotolo
- norme
- SaaS
- scala
- SCIENZE
- problemi di
- vede
- selezionato
- serverless
- Servizi
- set
- regolazione
- Condividi
- condiviso
- Corti
- Siti
- So
- Software
- Soluzioni
- Sud
- lo spazio
- iniziato
- dichiarazione
- Stato dei servizi
- Tecnologie
- Tecnologia
- tempo
- top
- traffico
- Aggiornamenti
- utenti
- APPREZZIAMO
- sito web
- applicazioni web
- ovest
- OMS
- entro
- flusso di lavoro
- lavori
- mondo
- anni
- Yoga