Amazon QuickSight er en fullstendig administrert, cloud-native business intelligence (BI)-tjeneste som gjør det enkelt å koble til dataene dine, lage interaktive dashboards og dele disse med titusenvis av brukere, enten i QuickSight selv, eller innebygd i programvare som en tjenesteapper (SaaS).
QuickSight Enterprise Edition har nylig lagt til radnivåsikkerhet (RLS) ved hjelp av tagger, en ny funksjon som lar utviklere dele et enkelt dashbord med titusenvis av brukere, samtidig som de sikrer at hver bruker bare kan se og ha tilgang til bestemte data. Dette betyr at når en uavhengig programvareleverandør (ISV) legger til et QuickSight-innebygd dashbord i appen sin, trenger de ikke å klargjøre sluttbrukerne sine i QuickSight, og kan ganske enkelt sette opp tagger for å filtrere data basert på hvem dashbordet er blir servert til. For eksempel, hvis en ISV ønsket å sette opp et dashbord som skulle deles med 20,000 100 brukere på tvers av 20,000 kunder av en app, der alle brukere i en kunde har tilgang til identiske data, lar denne nye funksjonen deg dele et enkelt dashbord for alle brukere, uten å måtte sette opp eller administrere de XNUMX XNUMX brukerne i QuickSight.
RLS håndhevet ved hjelp av tagger sørger for at hver sluttbruker bare ser data som er relevante for dem, mens QuickSight automatisk skaleres for å møte brukernes samtidighet for å sikre at hver sluttbruker ser konsekvent rask ytelse. I dette innlegget ser vi på hvordan dette kan implementeres.
Løsningsoversikt
For å bygge inn dashbord uten brukerklargjøring, bruker vi API GenererEmbedURLForAnonymouser, som fungerer med QuickSights prissetting av øktkapasitet. Med denne APIen bestemmer og administrerer innebyggingsserveren (logikk i SaaS-appen) identiteten til brukeren som dashbordet vises for (i motsetning til at denne identiteten blir klargjort og administrert i QuickSight).
Følgende diagram viser et eksempel på en arbeidsflyt av innebygde dashbord som sikrer data basert på hvem som får tilgang til applikasjonen ved hjelp av RLS med tagger.
I dette tilfellet har en ISV en SaaS-applikasjon som er tilgjengelig for to sluttbrukere. Den ene er en leder og den andre er en arbeidsleder. Begge brukerne får tilgang til den samme applikasjonen og det samme QuickSight-dashbordet som er innebygd i applikasjonen, og de er ikke klargjort i QuickSight. Når administratoren får tilgang til dashbordet, ser de bare data knyttet til nettstedet deres, og når administratoren får tilgang til dashbordet, ser de data som gjelder alle nettstedene de administrerer.
For å oppnå denne oppførselen bruker vi en ny funksjon som gjør det mulig å konfigurere sikkerheten på radnivå ved hjelp av tagger. Denne metoden for å sikre data på innebygde dashbord fungerer bare når dashbord er innebygd uten brukerklargjøring (også kalt anonym innebygging). Prosessen inkluderer to trinn:
- Sett opp taggnøkler på kolonnene i datasettene som brukes til å bygge dashbordet.
- Angi verdier for tag-nøklene ved kjøretid når du bygger inn dashbordet anonymt.
Sett opp taggnøkler på kolonner i datasettene som brukes til å bygge dashbordet
ISV-er eller utviklere kan angi kolonner på datasettene ved å bruke CreateDataset
or UpdateDataset
APIer som følger:
I den foregående eksempelkoden, row-level-permission-tag-configuration
er elementet du kan bruke til å definere taggnøkler på kolonnene i et datasett. For hver kode kan du definere følgende valgfrie elementer:
- TagMultiValueDelimiter – Når dette alternativet er satt på en kolonne, kan du sende mer enn én verdi til taggen under kjøring, og verdiene er avgrenset av strengen som er satt for dette alternativet. I dette eksemplet er et komma satt som en avgrensningsstreng.
- MatchAll Value – Når dette alternativet er satt på en kolonne, kan du sende alle verdiene til en kolonne under kjøring, og verdiene er representert av strengsettet for dette alternativet. I dette eksemplet er en stjerne satt som en samsvarsstreng.
Etter at vi har definert taggene våre, kan vi aktivere eller deaktivere disse reglene ved å bruke Status
element i API. I dette tilfellet settes verdien til ENABLED
. For å deaktivere reglene er verdien DISABLED
. Etter at taggene er aktivert, kan vi sende verdier til taggene ved kjøring for å sikre dataene som vises basert på hvem som har tilgang til dashbordet.
Hvert datasett kan ha opptil 50 tag-nøkler.
Vi mottar følgende svar for CreateDataset
or UpdateDataset
API:
Gjør det mulig for forfattere å få tilgang til data som er beskyttet av tag-nøkler når de skriver analyser
Etter at taggernøkler er satt og aktivert på datasettet, er det sikret. Forfattere som bruker dette datasettet til å skrive et dashbord, ser ingen data. De må gis tillatelser for å se noen av dataene i datasettet når de oppretter et dashbord. For å gi QuickSight-forfattere tillatelse til å se data i datasettet, opprett en tillatelsesfil eller et regeldatasett. For mer informasjon, se Opprette datasettregler for sikkerhet på radnivå. Følgende er et eksempelregeldatasett.
UserName | kolonnenavn_1 | kolonnenavn_2 | kolonnenavn_3 |
admin/sampleauthor |
I dette eksempeldatasettet har vi forfatterens brukernavn oppført i kolonnen Brukernavn. De tre andre kolonnene er kolonnene fra datasettet som vi setter taggnøkler på. Verdiene er tomme for disse kolonnene for forfatteren som er lagt til i denne tabellen. Dette gjør det mulig for forfatteren å se alle dataene i disse kolonnene uten noen begrensninger når de skriver analyser.
Angi verdier til tag-nøklene under kjøring når du bygger inn dashbordet
Etter at tag-nøklene er angitt for kolonner i datasettene, setter utviklere verdier til nøklene under kjøring når de bygger inn dashbordet. Utviklere kaller API GenerateDashboardEmbedURLForAnonymousUser
for å bygge inn dashbordet og sende verdier til tag-nøklene i elementet SessionTags
, som vist i følgende eksempelkode:
Fordi denne funksjonen sikrer data for brukere som ikke er klargjort i QuickSight, er API-kallet for AnonymousUser
bare og derfor fungerer denne funksjonen bare med API GenerateDashboardEmbedURLForAnonymousUser
.
Den foregående eksempelkoden har følgende komponenter:
- Til
tag_name_1
, angir du to verdier (value1
ogvalue2
) brukerTagMultiValueDelimiter
definert når du angir merketastene (i dette tilfellet et komma). - Til
tag_name_2
, angir du én verdi som en stjerne. Dette gjør det mulig for denne tag-nøkkelen å ha alle verdier for den kolonnen tildelt fordi vi definerte stjerne somMatchAllValue
når du angir en taggnøkkel på kolonnen tidligere. - Til
tag_name_3
, angir du én verdi (value3
).
API-responsdefinisjon
Responsen til API-en har EmbedURL
, Status
og RequestID
. Du kan bygge inn denne URL-en i HTML-siden din. Data i dette dashbordet er sikret basert på verdiene som sendes til tag-nøklene ved oppkalling av embedding API GenerateDashboardEmbedURLForAnonymousUser
:
- EmbedUrl (streng) – En engangs-URL som du kan legge inn på serversiden din for å bygge inn dashbordet. Denne nettadressen er gyldig i 5 minutter. API-operasjonen gir URL-en en
auth_code
verdi som muliggjør én (og bare én) pålogging til en brukerøkt som er gyldig i opptil 10 timer. Denne nettadressen gjengir dashbordet med RLS-regler brukt basert på verdiene som er angitt for RLS-tagnøklene. - Status (heltall) – HTTP-statusen til forespørselen.
- RequestId (streng) – AWS-forespørsels-IDen for denne operasjonen.
Finkornet tilgangskontroll
Du kan oppnå finmasket tilgangskontroll ved å bruke dynamisk AWS identitets- og tilgangsadministrasjon (IAM) policygenerering. For mer informasjon, se Isolere SaaS-leietakere med dynamisk genererte IAM-policyer. Når du bruker GenerateEmbedUrlForAnonymousUser
API for innebygging, må du nevne to ressurstyper i IAM-policyen: navneområde-ARN-ene dine anonyme brukere praktisk talt tilhører, og dashboard-ARN-ene som kan brukes i AuthorizedResourceArns
inndataparameterverdi. Øktene som genereres ved hjelp av denne API-en, kan få tilgang til de autoriserte ressursene og de (dashboards) som deles med navneområdet.
Fordi anonyme brukere er en del av et navneområde, er alle dashbord som deles med navneområdet tilgjengelige for dem, uavhengig av om de sendes eksplisitt via AuthorizedResourceArns
parameter.
For å la innringerens identitet generere en URL for enhver bruker og ethvert instrumentbord, Resource
blokk av policyen kan settes til *
. For å la innringerens identitet generere en URL for enhver anonym bruker i et spesifikt navneområde (som f.eks Tenant1
), Den Resource
en del av policyen kan settes til arn:aws:quicksight:us-east-1:<YOUR_AWS_ACCOUNT_ID>:namespace/Tenant1
. Dette er det samme for dashbord-ID. For dynamisk policygenerering kan du også bruke plassholdere for navneområdet og brukerne.
Følgende kode er et eksempel på IAM-policy:
Bruk saken
OkTank er en ISV i helsevesenet. De har en SaaS-applikasjon som brukes av forskjellige sykehus på tvers av forskjellige regioner i landet for å administrere inntektene deres. OkTank har tusenvis av helseansatte som har tilgang til applikasjonen deres og har innebygd operasjoner knyttet til virksomheten deres i et QuickSight-dashbord i applikasjonen deres. OkTank ønsker ikke å administrere sine brukere i QuickSight separat, og ønsker å sikre data basert på hvilken bruker fra hvilket sykehus som får tilgang til applikasjonen deres. OkTank sikrer dataene på dashbordene under kjøring ved hjelp av sikkerhet på radnivå ved hjelp av tagger.
OkTank har sykehus (North Hospital, South Hospital og Downtown Hospital) i regionene Sentral, Øst, Sør og Vest.
I dette eksemplet får følgende brukere tilgang til OkTanks applikasjon og det innebygde dashbordet. Hver bruker har et visst nivå av restriksjonsregler som definerer hvilke data de har tilgang til i dashboardene. PowerUser
er en superbruker som kan se dataene for alle sykehus og regioner.
OkTanks applikasjons bruker | Hospital | Region |
NorthUser | Nord -sykehuset | Sentral og Øst |
NorthAdmin | Nord -sykehuset | Alle regioner |
Sør-bruker | Sykehuset Sør | Sør |
SouthAdmin | Sykehuset Sør | Alle regioner |
Kraftbruker | Alle sykehus | Alle regioner |
Ingen av disse brukerne har blitt klargjort i QuickSight. OkTank administrerer disse brukerne i sin egen applikasjon og vet derfor hvilken region og sykehus hver bruker tilhører. Når noen av disse brukerne får tilgang til det innebygde QuickSight-dashbordet i applikasjonen, må OkTank sikre dataene på dashbordet slik at brukerne kun kan se dataene for sin region og sykehus.
Først opprettet OkTank tag-nøkler på datasettet de bruker for å drive dashbordet. I deres UpdateDataset
API-kall, den RowLevelPermissionTagConfiguration
element på datasettet er som følger:
For det andre, ved kjøretid når du bygger inn dashbordet via GenerateDashboardEmbedURLForAnonymousUser
API, satte de SessionTags
for hver bruker.
SessionTags
forum NorthUser
i GenerateDashboardEmbedURLForAnonymousUser
API-kall er som følger:
SessionTags
forum NorthAdmin
er som følger:
SessionTags
forum SouthUser
er som følger:
SessionTags
forum SouthAdmin
er som følger:
SessionTags
forum PowerUser
er som følger:
Følgende skjermbilde viser hva SouthUser
ser vedr. Sykehuset Sør i region Sør.
Følgende skjermbilde viser hva SouthAdmin
ser vedr. Sykehuset Sør i alle regioner.
Følgende skjermbilde viser hva PowerUser
ser gjelder alle sykehus i alle regioner.
Basert på økttagger har OkTank sikret data på de innebygde dashboardene slik at hver bruker bare ser spesifikke data basert på tilgangen deres. Du kan få tilgang til dashbordet som en av brukerne (ved å endre bruker i rullegardinmenyen øverst til høyre) og se hvordan dataene endres basert på den valgte brukeren.
Totalt sett, med sikkerhet på radnivå ved bruk av tagger, er OkTank i stand til å gi en overbevisende analyseopplevelse i deres SaaS-applikasjon, samtidig som de sørger for at hver bruker bare ser de riktige dataene uten å måtte klargjøre og administrere brukere i QuickSight. QuickSight gir et svært skalerbart, sikkert analysealternativ som du kan sette opp og rulle ut til produksjon på dager, i stedet for uker eller måneder tidligere.
konklusjonen
Kombinasjonen av innebygd dashbord for brukere som ikke er klargjort i QuickSight og sikkerhet på radnivå ved bruk av tagger gjør det mulig for utviklere og ISV-er å raskt og enkelt sette opp sofistikerte, tilpassede analyser for applikasjonsbrukerne – alt uten infrastrukturoppsett eller administrasjon mens de skaleres til millioner av brukere . For flere oppdateringer fra QuickSight innebygde analyser, Se Hva er nytt i Amazon QuickSight-brukerveiledningen.
Om forfatterne
Raji Sivasubramaniam er spesialistløsningsarkitekt hos AWS, med fokus på Analytics. Raji har 20 års erfaring med å bygge ende-til-ende Enterprise Data Management, Business Intelligence og Analytics-løsninger for Fortune 500- og Fortune 100-selskaper over hele verden. Hun har inngående erfaring med integrerte helsedata og analyser med et bredt utvalg helsedatasett inkludert administrert marked, legemålretting og pasientanalyse. På fritiden liker Raji fotturer, yoga og hagearbeid.
Srikanth Baheti er en spesialisert World Wide Sr. Solution Architect for Amazon QuickSight. Han startet sin karriere som konsulent og jobbet for flere private og offentlige organisasjoner. Senere jobbet han for PerkinElmer Health and Sciences & eResearch Technology Inc., hvor han var ansvarlig for å designe og utvikle nettapplikasjoner med høy trafikk, svært skalerbare og vedlikeholdbare datapipelines for rapporteringsplattformer som bruker AWS-tjenester og serverløs databehandling.
Kareem Syed-Mohammed er produktsjef hos Amazon QuickSight. Han fokuserer på innebygd analyse, APIer og utvikleropplevelse. Før QuickSight har han vært i AWS Marketplace og Amazon retail som PM. Kareem startet sin karriere som utvikler og deretter PM for call center-teknologier, Local Expert og Ads for Expedia. Han jobbet som konsulent hos McKinsey and Company en kort stund.
- '
- "
- &
- 000
- 100
- 11
- adgang
- Logg inn
- Handling
- annonser
- Alle
- Amazon
- analytics
- api
- APIer
- app
- Søknad
- søknader
- apps
- forfattere
- AWS
- bygge
- virksomhet
- business intelligence
- ring
- Kapasitet
- Karriere
- kode
- Kolonne
- Selskaper
- Selskapet
- databehandling
- konsulent
- Kunder
- dashbord
- dato
- Dataledelse
- Utvikler
- utviklere
- Downtown
- ansatte
- Enterprise
- erfaring
- FAST
- Trekk
- Regjeringen
- Helse
- helsetjenester
- her.
- Høy
- vandreturer
- Hospital
- sykehus
- Hvordan
- HTTPS
- IAM
- Identitet
- Inkludert
- informasjon
- Infrastruktur
- Intelligens
- interaktiv
- IT
- nøkkel
- nøkler
- Nivå
- lokal
- Making
- ledelse
- marked
- markedsplass
- Match
- måneder
- ny funksjon
- nord
- Drift
- Alternativ
- Annen
- ytelse
- lege
- Plattformer
- politikk
- makt
- privat
- Produkt
- Produksjon
- ressurs
- Ressurser
- svar
- detaljhandel
- inntekter
- Rull
- regler
- SaaS
- skalering
- VITENSKAPER
- sikkerhet
- Sees
- valgt
- server~~POS=TRUNC
- Tjenester
- sett
- innstilling
- Del
- delt
- Kort
- Nettsteder
- So
- Software
- Solutions
- Sør
- Rom
- startet
- Uttalelse
- status
- Technologies
- Teknologi
- tid
- topp
- trafikk
- oppdateringer
- Brukere
- verdi
- web
- nettapplikasjoner
- Vest
- HVEM
- innenfor
- arbeidsflyt
- virker
- verden
- år
- yoga