Amazon QuickSight er en fuldt administreret, cloud-native business intelligence (BI)-tjeneste, der gør det nemt at oprette forbindelse til dine data, oprette interaktive dashboards og dele disse med titusindvis af brugere, enten i QuickSight selv eller indlejret i software som en service (SaaS) apps.
QuickSight Enterprise Edition tilføjede for nylig rækkeniveausikkerhed (RLS) ved hjælp af tags, en ny funktion, der giver udviklere mulighed for at dele et enkelt dashboard med titusindvis af brugere, samtidig med at det sikres, at hver bruger kun kan se og have adgang til bestemte data. Dette betyder, at når en uafhængig softwareleverandør (ISV) tilføjer et QuickSight-indlejret dashboard i deres app, behøver de ikke at klargøre deres slutbrugere i QuickSight, og de kan simpelthen opsætte tags til at filtrere data baseret på, hvem dashboardet er. bliver serveret for. For eksempel, hvis en ISV ønskede at oprette et dashboard, der skulle deles med 20,000 brugere på tværs af 100 kunder af en app, hvor alle brugere inden for en kunde har adgang til identiske data, giver denne nye funktion dig mulighed for at dele et enkelt dashboard for alle brugere, uden at skulle opsætte eller administrere de 20,000 brugere i QuickSight.
RLS håndhævet ved hjælp af tags sikrer, at hver slutbruger kun ser data, der er relevante for dem, mens QuickSight automatisk skalerer for at imødekomme brugerens samtidighed for at sikre, at hver slutbruger ser konsekvent hurtig ydeevne. I dette indlæg ser vi på, hvordan dette kan implementeres.
Løsningsoversigt
For at integrere dashboards uden brugerklargøring bruger vi API'en GenererEmbedURLForAnonymouser, som fungerer med QuickSight's prissætning af sessionskapacitet. Med denne API bestemmer og administrerer indlejringsserveren (logik i SaaS-appen) identiteten på den bruger, som dashboardet vises for (i modsætning til, at denne identitet klargøres og administreres i QuickSight).
Følgende diagram viser et eksempel på en arbejdsgang af indlejrede dashboards, der sikrer data baseret på, hvem der tilgår applikationen ved hjælp af RLS med tags.
I dette tilfælde har en ISV en SaaS-applikation, der tilgås af to slutbrugere. Den ene er en leder og den anden er en site supervisor. Begge brugere får adgang til den samme applikation og det samme QuickSight-dashboard, der er indlejret i applikationen, og de er ikke klargjort i QuickSight. Når webstedsadministratoren tilgår dashboardet, ser de kun data vedrørende deres websted, og når administratoren får adgang til dashboardet, ser de data vedrørende alle websteder, de administrerer.
For at opnå denne adfærd bruger vi en ny funktion, der gør det muligt at konfigurere sikkerheden på rækkeniveau ved hjælp af tags. Denne metode til at sikre data på indlejrede dashboards fungerer kun, når dashboards er integreret uden brugerklargøring (også kaldet anonym indlejring). Processen omfatter to trin:
- Konfigurer tagtaster på kolonnerne i de datasæt, der bruges til at bygge dashboardet.
- Indstil værdier for tagnøglerne ved kørsel, når du indlejrer dashboardet anonymt.
Konfigurer tagnøgler på kolonner i de datasæt, der bruges til at bygge dashboardet
ISV'er eller udviklere kan indstille kolonner på datasættene ved hjælp af CreateDataset
or UpdateDataset
API'er som følger:
I det foregående eksempelkode, row-level-permission-tag-configuration
er det element, du kan bruge til at definere tagnøgler på kolonnerne i et datasæt. For hvert tag kan du definere følgende valgfrie elementer:
- TagMultiValueDelimiter – Denne indstilling, når den er indstillet på en kolonne, giver dig mulighed for at sende mere end én værdi til tagget under kørsel, og værdierne er afgrænset af strengen, der er sat for denne indstilling. I dette eksempel er et komma angivet som en afgrænsningsstreng.
- MatchAllValue – Denne indstilling, når den er angivet på en kolonne, giver dig mulighed for at videregive alle værdier af en kolonne under kørsel, og værdierne er repræsenteret af strengen, der er sat for denne indstilling. I dette eksempel er en stjerne sat som en match alle streng.
Når vi har defineret vores tags, kan vi aktivere eller deaktivere disse regler ved hjælp af Status
element i API'et. I dette tilfælde er værdien sat til ENABLED
. For at deaktivere reglerne er værdien DISABLED
. Efter at taggene er aktiveret, kan vi videregive værdier til tags under kørsel for at sikre de viste data baseret på, hvem der har adgang til dashboardet.
Hvert datasæt kan have op til 50 tagnøgler.
Vi modtager følgende svar pr CreateDataset
or UpdateDataset
API'er:
Giv forfattere adgang til data, der er beskyttet af tagnøgler, når de udarbejder analyse
Når tag-nøgler er indstillet og aktiveret på datasættet, er det sikret. Forfattere, når de bruger dette datasæt til at oprette et dashboard, ser ingen data. De skal have tilladelse til at se nogen af dataene i datasættet, når de opretter et dashboard. For at give QuickSight-forfattere tilladelse til at se data i datasættet, skal du oprette en tilladelsesfil eller et regeldatasæt. For mere information, se Oprettelse af datasætregler for sikkerhed på rækkeniveau. Det følgende er et eksempel på et regeldatasæt.
Brugernavn | kolonnenavn_1 | kolonnenavn_2 | kolonnenavn_3 |
admin/sampleauthor |
I dette eksempeldatasæt har vi forfatterens brugernavn angivet i kolonnen Brugernavn. De andre tre kolonner er kolonnerne fra datasættet, som vi sætter tag-nøgler på. Værdierne efterlades tomme for disse kolonner for forfatteren tilføjet til denne tabel. Dette gør det muligt for forfatteren at se alle data i disse kolonner uden nogen begrænsning, når de udarbejder analyser.
Indstil værdier til tagtasterne under kørsel, når du integrerer dashboardet
Efter at tag-nøglerne er indstillet til kolonner i datasættene, indstiller udviklere værdier til tasterne under kørsel, når de indlejrer dashboardet. Udviklere kalder API GenerateDashboardEmbedURLForAnonymousUser
at indlejre dashboardet og sende værdier til tag-tasterne i elementet SessionTags
, som vist i følgende eksempelkode:
Fordi denne funktion sikrer data for brugere, der ikke er klargjort i QuickSight, er API-kaldet til AnonymousUser
kun, og derfor virker denne funktion kun med API'en GenerateDashboardEmbedURLForAnonymousUser
.
Den foregående eksempelkode har følgende komponenter:
- Til
tag_name_1
, indstiller du to værdier (value1
,value2
) brugerTagMultiValueDelimiter
defineret ved indstilling af tagtasterne (i dette tilfælde et komma). - Til
tag_name_2
, angiver du én værdi som en stjerne. Dette gør det muligt for denne tagnøgle at få tildelt alle værdier for den kolonne, fordi vi definerede stjerne somMatchAllValue
ved tidligere indstilling af en tag-nøgle på kolonnen. - Til
tag_name_3
, du indstiller én værdi (value3
).
API svar definition
API'ens svar har EmbedURL
, Status
og RequestID
. Du kan indlejre denne URL på din HTML-side. Data i dette dashboard er sikret baseret på de værdier, der sendes til tagnøglerne, når indlejrings-API'en kaldes GenerateDashboardEmbedURLForAnonymousUser
:
- EmbedUrl (streng) – En engangs-URL, som du kan indsætte på din serverside for at integrere dit dashboard. Denne URL er gyldig i 5 minutter. API-operationen giver URL'en en
auth_code
værdi, der muliggør én (og kun én) log-on til en brugersession, der er gyldig i op til 10 timer. Denne URL gengiver dashboardet med anvendte RLS-regler baseret på de værdier, der er angivet for RLS-tagnøglerne. - Status (heltal) – HTTP-status for anmodningen.
- RequestId (streng) – AWS-anmodnings-id'et for denne operation.
Finmasket adgangskontrol
Du kan opnå finmasket adgangskontrol ved at bruge dynamisk AWS identitets- og adgangsstyring (IAM) politikgenerering. For mere information, se Isolering af SaaS-lejere med dynamisk genererede IAM-politikker. Når du bruger GenerateEmbedUrlForAnonymousUser
API til indlejring, skal du nævne to ressourcetyper i IAM-politikken: de navneområde-ARN'er, dine anonyme brugere virtuelt tilhører, og dashboard-ARN'erne, der kan bruges i AuthorizedResourceArns
input parameter værdi. De sessioner, der genereres ved hjælp af denne API, kan få adgang til de autoriserede ressourcer og dem (dashboards), der deles med navneområdet.
Fordi anonyme brugere er en del af et navneområde, er alle dashboards, der deles med navneområdet, tilgængelige for dem, uanset om de videregives eksplicit via AuthorizedResourceArns
parameter.
For at tillade opkaldsidentiteten at generere en URL for enhver bruger og ethvert dashboard, skal Resource
blok af politikken kan indstilles til *
. At tillade opkaldsidentiteten at generere en URL for enhver anonym bruger i et specifikt navneområde (f.eks Tenant1
), Den Resource
en del af politikken kan indstilles til arn:aws:quicksight:us-east-1:<YOUR_AWS_ACCOUNT_ID>:namespace/Tenant1
. Dette er det samme for dashboard-id'et. Til dynamisk politikgenerering kan du også bruge pladsholdere til navneområdet og brugerne.
Følgende kode er et eksempel på en IAM-politik:
Brug sag
OkTank er en ISV inden for sundhedsområdet. De har en SaaS-applikation, der bruges af forskellige hospitaler på tværs af forskellige regioner i landet til at styre deres indtægter. OkTank har tusindvis af sundhedspersonale, der har adgang til deres applikation og har indlejret operationer relateret til deres virksomhed i et QuickSight-dashboard i deres applikation. OkTank ønsker ikke at administrere deres brugere i QuickSight separat, og ønsker at sikre data baseret på, hvilken bruger fra hvilket hospital der tilgår deres applikation. OkTank sikrer dataene på dashboards under kørsel ved hjælp af række-niveau sikkerhed ved hjælp af tags.
OkTank har hospitaler (North Hospital, South Hospital og Downtown Hospital) i regionerne Central, East, South og West.
I dette eksempel får følgende brugere adgang til OkTanks applikation og det indlejrede dashboard. Hver bruger har et vist niveau af begrænsningsregler, der definerer, hvilke data de kan få adgang til i dashboards. PowerUser
er en superbruger, der kan se data for alle hospitaler og regioner.
OkTanks applikations bruger | Hospital | Område |
Nordbruger | Nord Hospital | Central og Øst |
NorthAdmin | Nord Hospital | Alle regioner |
Sydbruger | Syd Sygehus | Syd |
SouthAdmin | Syd Sygehus | Alle regioner |
magtbruger | Alle hospitaler | Alle regioner |
Ingen af disse brugere er blevet klargjort i QuickSight. OkTank administrerer disse brugere i sin egen applikation og ved derfor hvilken region og hospital hver bruger tilhører. Når nogen af disse brugere får adgang til det indlejrede QuickSight-dashboard i applikationen, skal OkTank sikre dataene på dashboardet, så brugerne kun kan se dataene for deres region og hospital.
Først oprettede OkTank tag-nøgler på det datasæt, de bruger til at drive dashboardet. I deres UpdateDataset
API-kald, den RowLevelPermissionTagConfiguration
element på datasættet er som følger:
For det andet ved kørsel, når instrumentbrættet indlejres via GenerateDashboardEmbedURLForAnonymousUser
API, sætter de SessionTags
for hver bruger.
SessionTags
forum NorthUser
i GenerateDashboardEmbedURLForAnonymousUser
API-kald 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 skærmbillede viser hvad SouthUser
ser vedrørende Sydhospitalet i region Syd.
Følgende skærmbillede viser hvad SouthAdmin
ser vedrørende Sydhospitalet i alle regioner.
Følgende skærmbillede viser hvad PowerUser
ser vedrørende alle hospitaler i alle regioner.
Baseret på sessionstags har OkTank sikret data på de indlejrede dashboards, således at hver bruger kun ser specifikke data baseret på deres adgang. Du kan få adgang til dashboardet som en af brugerne (ved at ændre bruger i rullemenuen øverst til højre) og se hvordan data ændres ud fra den valgte bruger.
Samlet set er OkTank med sikkerhed på rækkeniveau ved hjælp af tags i stand til at give en overbevisende analyseoplevelse i deres SaaS-applikation, samtidig med at den sikrer, at hver bruger kun ser de relevante data uden at skulle klargøre og administrere brugere i QuickSight. QuickSight giver en meget skalerbar, sikker analysemulighed, som du kan konfigurere og udrulle til produktion på dage i stedet for uger eller måneder tidligere.
Konklusion
Kombinationen af indlejring af dashboard til brugere, der ikke er klargjort i QuickSight, og sikkerhed på rækkeniveau ved hjælp af tags gør det muligt for udviklere og ISV'er hurtigt og nemt at opsætte sofistikerede, tilpassede analyser til deres applikationsbrugere - alt sammen uden nogen infrastrukturopsætning eller -administration, mens de skaleres til millioner af brugere . For flere opdateringer fra QuickSight indlejret analyseSe Hvad er nyt i Amazon QuickSight-brugervejledningen.
Om forfatterne
Raji Sivasubramaniam er Specialist Solutions Architect hos AWS med fokus på Analytics. Raji har 20 års erfaring med at udvikle end-to-end Enterprise Data Management, Business Intelligence og Analytics-løsninger for Fortune 500 og Fortune 100 virksomheder over hele kloden. Hun har dybdegående erfaring med integrerede sundhedsdata og analyser med en bred vifte af sundhedsdatasæt, herunder administreret marked, lægemålretning og patientanalyse. I sin fritid nyder Raji at vandre, yoga og havearbejde.
Srikanth Baheti er en specialiseret World Wide Sr. Solution Architect for Amazon QuickSight. Han startede sin karriere som konsulent og arbejdede for flere private og offentlige organisationer. Senere arbejdede han for PerkinElmer Health and Sciences & eResearch Technology Inc., hvor han var ansvarlig for at designe og udvikle webapplikationer med høj trafik, meget skalerbare og vedligeholdelige datapipelines til rapporteringsplatforme ved hjælp af AWS-tjenester og serverløs computing.
Kareem Syed-Mohammed er produktchef hos Amazon QuickSight. Han fokuserer på indlejret analyse, API'er og udvikleroplevelse. Før QuickSight har han været hos AWS Marketplace og Amazon detailhandel som PM. Kareem startede sin karriere som udvikler og derefter PM for call center-teknologier, Local Expert og Ads for Expedia. Han arbejdede som konsulent hos McKinsey and Company i et kort stykke tid.
- '
- "
- &
- 000
- 100
- 11
- adgang
- Konto
- Handling
- annoncer
- Alle
- Amazon
- analytics
- api
- API'er
- app
- Anvendelse
- applikationer
- apps
- forfattere
- AWS
- bygge
- virksomhed
- business intelligence
- ringe
- Kapacitet
- Karriere
- kode
- Kolonne
- Virksomheder
- selskab
- computing
- konsulent
- Kunder
- instrumentbræt
- data
- datastyring
- Udvikler
- udviklere
- Downtown
- medarbejdere
- Enterprise
- erfaring
- FAST
- Feature
- Regering
- Helse
- sundhedspleje
- link.
- Høj
- hiking
- Hospital
- sygehuse
- Hvordan
- HTTPS
- IAM
- Identity
- Herunder
- oplysninger
- Infrastruktur
- Intelligens
- interaktiv
- IT
- Nøgle
- nøgler
- Niveau
- lokale
- Making
- ledelse
- Marked
- markedsplads
- Match
- måned
- ny funktion
- Nord
- Produktion
- Option
- Andet
- ydeevne
- læge
- Platforme
- politik
- magt
- private
- Produkt
- produktion
- ressource
- Ressourcer
- svar
- detail
- indtægter
- Roll
- regler
- SaaS
- skalering
- VIDENSKABER
- sikkerhed
- Sees
- valgt
- Serverless
- Tjenester
- sæt
- indstilling
- Del
- delt
- Kort
- Websteder
- So
- Software
- Løsninger
- Syd
- Space
- påbegyndt
- Statement
- Status
- Teknologier
- Teknologier
- tid
- top
- Trafik
- opdateringer
- brugere
- værdi
- web
- webapplikationer
- Vest
- WHO
- inden for
- workflow
- virker
- world
- år
- Yoga