Amazon QuickSight är en helt hanterad, molnbaserad business intelligence (BI)-tjänst som gör det enkelt att ansluta till dina data, skapa interaktiva instrumentpaneler och dela dessa med tiotusentals användare, antingen inom QuickSight själv, eller inbäddad i programvara som en tjänst (SaaS) appar.
QuickSight Enterprise Edition lade nyligen till radnivåsäkerhet (RLS) med hjälp av taggar, en ny funktion som gör det möjligt för utvecklare att dela en enda instrumentpanel med tiotusentals användare, samtidigt som de säkerställer att varje användare bara kan se och ha tillgång till viss data. Detta innebär att när en oberoende mjukvaruleverantör (ISV) lägger till en QuickSight-inbäddad instrumentpanel i sin app, behöver de inte tillhandahålla sina slutanvändare i QuickSight, utan kan helt enkelt ställa in taggar för att filtrera data baserat på vem instrumentbrädan är serveras till. Till exempel, om en ISV ville sätta upp en instrumentpanel som skulle delas med 20,000 100 användare över 20,000 kunder av en app, där alla användare inom en kund har tillgång till identisk data, låter den här nya funktionen dig dela en enda instrumentpanel för alla användare, utan att behöva konfigurera eller hantera de XNUMX XNUMX användarna i QuickSight.
RLS som upprätthålls med taggar ser till att varje slutanvändare bara ser data som är relevant för dem, medan QuickSight automatiskt skalas för att möta användarsamfällighet för att säkerställa att varje slutanvändare ser konsekvent snabb prestanda. I det här inlägget tittar vi på hur detta kan genomföras.
Lösningsöversikt
För att bädda in instrumentpaneler utan användaradministration använder vi API GenereraBädda in URL för anonym användare, som fungerar med QuickSights prissättning av sessionskapacitet. Med detta API bestämmer och hanterar inbäddningsservern (logik i SaaS-appen) identiteten för användaren som instrumentpanelen visas för (i motsats till att denna identitet tillhandahålls och hanteras inom QuickSight).
Följande diagram visar ett exempel på ett arbetsflöde av inbäddade instrumentpaneler som säkrar data baserat på vem som använder applikationen med RLS med taggar.
I det här fallet har en ISV en SaaS-applikation som nås av två slutanvändare. Den ene är chef och den andra är arbetsledare. Båda användarna får åtkomst till samma applikation och samma QuickSight-instrumentpanel som är inbäddad i applikationen och de tillhandahålls inte i QuickSight. När platsövervakaren kommer åt instrumentpanelen ser de bara data som hänför sig till deras webbplats, och när chefen kommer åt instrumentpanelen ser de data som hänför sig till alla webbplatser de hanterar.
För att uppnå detta beteende använder vi en ny funktion som gör det möjligt att konfigurera säkerheten på radnivå med taggar. Denna metod för att säkra data på inbäddade instrumentpaneler fungerar endast när instrumentpaneler är inbäddade utan användaradministration (även kallad anonym inbäddning). Processen omfattar två steg:
- Ställ in taggnycklar på kolumnerna i de datauppsättningar som används för att bygga instrumentpanelen.
- Ställ in värden för taggnycklarna vid körning när du bäddar in instrumentpanelen anonymt.
Ställ in taggnycklar på kolumner i datauppsättningarna som används för att bygga instrumentpanelen
ISV:er eller utvecklare kan ställa in kolumner på datamängderna med hjälp av CreateDataset
or UpdateDataset
API:er enligt följande:
I föregående exempelkod, row-level-permission-tag-configuration
är elementet som du kan använda för att definiera taggnycklar på kolumnerna i en datauppsättning. För varje tagg kan du definiera följande valfria objekt:
- TagMultiValueDelimiter – Det här alternativet när det är inställt på en kolumn gör att du kan skicka mer än ett värde till taggen vid körning, och värdena avgränsas av strängen för detta alternativ. I det här exemplet sätts ett kommatecken som en avgränsningssträng.
- MatchAllValue – När det här alternativet är inställt på en kolumn kan du skicka alla värden i en kolumn under körning, och värdena representeras av strängen för detta alternativ. I det här exemplet är en asterisk satt som en matchande sträng.
När vi har definierat våra taggar kan vi aktivera eller inaktivera dessa regler med hjälp av Status
element i API:t. I detta fall är värdet satt till ENABLED
. För att inaktivera reglerna är värdet DISABLED
. Efter att taggarna har aktiverats kan vi skicka värden till taggarna vid körning för att säkra data som visas baserat på vem som har tillgång till instrumentpanelen.
Varje datauppsättning kan ha upp till 50 taggnycklar.
Vi får följande svar för CreateDataset
or UpdateDataset
API:
Gör det möjligt för författare att få tillgång till data som skyddas av taggnycklar vid författaranalys
Efter att taggnycklar har ställts in och aktiverats på datamängden är den säker. Författare som använder denna datauppsättning för att skapa en instrumentpanel ser inga data. De måste ges behörighet att se någon av data i datamängden när de skapar en instrumentpanel. För att ge QuickSight-författare behörighet att se data i datasetet, skapa en behörighetsfil eller en regeldatauppsättning. För mer information, se Skapa datauppsättningsregler för säkerhet på radnivå. Följande är ett exempel på en regeldatauppsättning.
Användarnamn | kolumnnamn_1 | kolumnnamn_2 | kolumnnamn_3 |
admin/sampleauthor |
I denna exempeldatauppsättning har vi författarens användarnamn listat i kolumnen Användarnamn. De andra tre kolumnerna är kolumnerna från datamängden som vi sätter taggnycklar på. Värdena lämnas tomma för dessa kolumner för författaren som lagts till i denna tabell. Detta gör att författaren kan se all data i dessa kolumner utan några begränsningar när de skapar analyser.
Ställ in värden på taggnycklarna vid körning när du bäddar in instrumentpanelen
Efter att taggnycklarna har ställts in för kolumner i datamängderna ställer utvecklare in värden på nycklarna vid körning när instrumentpanelen bäddas in. Utvecklare anropar API GenerateDashboardEmbedURLForAnonymousUser
för att bädda in instrumentpanelen och skicka värden till taggnycklarna i elementet SessionTags
, som visas i följande exempelkod:
Eftersom den här funktionen säkrar data för användare som inte tillhandahålls i QuickSight, är API-anropet för AnonymousUser
endast och därför fungerar den här funktionen endast med API GenerateDashboardEmbedURLForAnonymousUser
.
Den föregående exempelkoden har följande komponenter:
- För
tag_name_1
, ställer du in två värden (value1
ochvalue2
) användaTagMultiValueDelimiter
definieras när du ställer in taggnycklarna (i det här fallet ett kommatecken). - För
tag_name_2
, anger du ett värde som en asterisk. Detta gör det möjligt för denna taggnyckel att ha alla värden för den kolumnen tilldelade eftersom vi definierade asterisk somMatchAllValue
när du ställer in en taggnyckel på kolumnen tidigare. - För
tag_name_3
, ställer du in ett värde (value3
).
API-svarsdefinition
Svaret från API:t har EmbedURL
, Status
och RequestID
. Du kan bädda in denna URL i din HTML-sida. Data i den här instrumentpanelen är säkrad baserat på de värden som skickas till taggnycklarna när API:et för inbäddning anropas GenerateDashboardEmbedURLForAnonymousUser
:
- EmbedUrl (sträng) – En webbadress för engångsbruk som du kan lägga in på din webbsida på serversidan för att bädda in din instrumentpanel. Denna URL är giltig i 5 minuter. API-operationen förser URL:en med en
auth_code
värde som möjliggör en (och endast en) inloggning till en användarsession som är giltig i upp till 10 timmar. Den här webbadressen återger instrumentpanelen med tillämpade RLS-regler baserat på de värden som ställts in för RLS-taggnycklarna. - Status (heltal) – HTTP-statusen för begäran.
- RequestId (sträng) – AWS-begärans ID för denna operation.
Finkornad åtkomstkontroll
Du kan uppnå finkornig åtkomstkontroll genom att använda dynamisk AWS identitets- och åtkomsthantering (IAM) policygenerering. För mer information, se Isolera SaaS-hyresgäster med dynamiskt genererade IAM-policyer. När du använder GenerateEmbedUrlForAnonymousUser
API för inbäddning, du måste nämna två resurstyper i IAM-policyn: namnutrymmets ARN:er som dina anonyma användare praktiskt taget tillhör, och instrumentpanelens ARN:er som kan användas i AuthorizedResourceArns
ingångsparametervärde. Sessionerna som genereras med detta API kan komma åt de auktoriserade resurserna och de (dashboards) som delas med namnområdet.
Eftersom anonyma användare är en del av ett namnutrymme är alla instrumentpaneler som delas med namnområdet tillgängliga för dem, oavsett om de skickas uttryckligen via AuthorizedResourceArns
parameter.
För att tillåta uppringarens identitet att generera en URL för vilken användare och vilken instrumentpanel som helst, Resource
block av policyn kan ställas in på *
. För att tillåta uppringarens identitet att generera en URL för alla anonyma användare i ett specifikt namnområde (t.ex Tenant1
), Den Resource
en del av policyn kan ställas in på arn:aws:quicksight:us-east-1:<YOUR_AWS_ACCOUNT_ID>:namespace/Tenant1
. Detta är samma sak för instrumentpanelens ID. För dynamisk policygenerering kan du också använda platshållare för namnutrymmet och användare.
Följande kod är ett exempel på IAM-policy:
Användningsfall
OkTank är en ISV inom sjukvården. De har en SaaS-applikation som används av olika sjukhus i olika regioner i landet för att hantera sina intäkter. OkTank har tusentals sjukvårdsanställda som har tillgång till deras applikation och har inbäddat verksamhet relaterade till deras verksamhet i en QuickSight-instrumentpanel i deras applikation. OkTank vill inte hantera sina användare i QuickSight separat, och vill säkra data baserat på vilken användare från vilket sjukhus som kommer åt deras applikation. OkTank säkrar data på instrumentpanelerna under körning med hjälp av radnivåsäkerhet med taggar.
OkTank har sjukhus (North Hospital, South Hospital och Downtown Hospital) i regionerna Central, East, South och West.
I det här exemplet får följande användare tillgång till OkTanks applikation och den inbäddade instrumentpanelen. Varje användare har en viss nivå av begränsningsregler som definierar vilken data de kan komma åt i instrumentpanelerna. PowerUser
är en superanvändare som kan se data för alla sjukhus och regioner.
OkTanks applikations användare | Sjukhuset | Region |
NorthUser | Norra sjukhuset | Central och öst |
NorthAdmin | Norra sjukhuset | Alla regioner |
South User | Södra sjukhuset | Söder |
SouthAdmin | Södra sjukhuset | Alla regioner |
Kraft användare | Alla sjukhus | Alla regioner |
Ingen av dessa användare har tillhandahållits i QuickSight. OkTank hanterar dessa användare i sin egen applikation och vet därför vilken region och sjukhus varje användare tillhör. När någon av dessa användare kommer åt den inbäddade QuickSight-instrumentbrädan i applikationen måste OkTank säkra data på instrumentpanelen så att användare bara kan se data för sin region och sitt sjukhus.
Först skapade OkTank taggnycklar på datamängden de använder för att driva instrumentpanelen. I deras UpdateDataset
API-anrop, den RowLevelPermissionTagConfiguration
element i datamängden är som följer:
För det andra, vid körning när man bäddar in instrumentpanelen via GenerateDashboardEmbedURLForAnonymousUser
API, satte de SessionTags
för varje användare.
SessionTags
för NorthUser
i GenerateDashboardEmbedURLForAnonymousUser
API-anrop är följande:
SessionTags
för NorthAdmin
är följande:
SessionTags
för SouthUser
är följande:
SessionTags
för SouthAdmin
är följande:
SessionTags
för PowerUser
är följande:
Följande skärmdump visar vad SouthUser
ser rörande Sydsjukhuset i region Syd.
Följande skärmdump visar vad SouthAdmin
ser rörande Södra sjukhuset i alla regioner.
Följande skärmdump visar vad PowerUser
ser avser alla sjukhus i alla regioner.
Baserat på sessionstaggar har OkTank säkrat data på de inbäddade instrumentpanelerna så att varje användare bara ser specifik data baserat på deras åtkomst. Du kan öppna instrumentpanelen som en av användarna (genom att ändra användaren i rullgardinsmenyn uppe till höger) och se hur data ändras baserat på den valda användaren.
Sammantaget, med säkerhet på radnivå med taggar, kan OkTank ge en övertygande analysupplevelse i sin SaaS-applikation, samtidigt som de ser till att varje användare bara ser lämplig data utan att behöva tillhandahålla och hantera användare i QuickSight. QuickSight tillhandahåller ett mycket skalbart, säkert analysalternativ som du kan ställa in och rulla ut till produktion på dagar, istället för veckor eller månader tidigare.
Slutsats
Kombinationen av inbäddad instrumentpanel för användare som inte tillhandahålls i QuickSight och säkerhet på radnivå med taggar gör det möjligt för utvecklare och ISV:er att snabbt och enkelt ställa in sofistikerad, anpassad analys för sina applikationsanvändare – allt utan någon infrastrukturinstallation eller hantering samtidigt som de skalas till miljontals användare . För fler uppdateringar från QuickSight inbäddad analys, Se Vad är nytt i Amazon QuickSights användarhandbok.
Om författarna
Raji Sivasubramaniam är en Specialist Solutions Architect på AWS, med fokus på Analytics. Raji har 20 års erfarenhet av att utforma end-to-end Enterprise Data Management-, Business Intelligence- och Analytics-lösningar för Fortune 500- och Fortune 100-företag över hela världen. Hon har djupgående erfarenhet av integrerad vårddata och analys med ett brett utbud av vårddatauppsättningar, inklusive hanterad marknad, läkarinriktning och patientanalys. På fritiden tycker Raji om vandring, yoga och trädgårdsarbete.
Srikanth Baheti är en specialiserad World Wide Sr. Solution Architect för Amazon QuickSight. Han började sin karriär som konsult och arbetade för flera privata och statliga organisationer. Senare arbetade han för PerkinElmer Health and Sciences & eResearch Technology Inc, där han var ansvarig för att designa och utveckla högtrafikerade webbapplikationer, mycket skalbara och underhållsbara datapipelines för rapporteringsplattformar som använder AWS-tjänster och serverlös datoranvändning.
Kareem Syed-Mohammed är produktchef på Amazon QuickSight. Han fokuserar på inbäddad analys, API:er och utvecklarupplevelse. Före QuickSight har han varit PM på AWS Marketplace och Amazon retail. Kareem började sin karriär som utvecklare och sedan PM för callcenterteknologier, Local Expert och Ads for Expedia. Han arbetade som konsult hos McKinsey and Company en kort stund.
- '
- "
- &
- 000
- 100
- 11
- tillgång
- Konto
- Handling
- annonser
- Alla
- amason
- analytics
- api
- API: er
- app
- Ansökan
- tillämpningar
- appar
- Författarna
- AWS
- SLUTRESULTAT
- företag
- business intelligence
- Ring
- Kapacitet
- Karriär
- koda
- Kolumn
- Företag
- företag
- databehandling
- konsult
- Kunder
- instrumentbräda
- datum
- datahantering
- Utvecklare
- utvecklare
- Downtown
- anställda
- Företag
- erfarenhet
- SNABB
- Leverans
- Regeringen
- Hälsa
- hälso-och sjukvård
- här.
- Hög
- vandring
- Sjukhuset
- sjukhus
- Hur ser din drömresa ut
- HTTPS
- IAM
- Identitet
- Inklusive
- informationen
- Infrastruktur
- Intelligens
- interaktiva
- IT
- Nyckel
- nycklar
- Nivå
- lokal
- Framställning
- ledning
- marknad
- marknadsplats
- Match
- månader
- ny funktion
- Nord
- Verksamhet
- Alternativet
- Övriga
- prestanda
- Läkaren
- Plattformar
- policy
- kraft
- privat
- Produkt
- Produktion
- resurs
- Resurser
- respons
- detaljhandeln
- intäkter
- Rulla
- regler
- SaaS
- skalning
- VETENSKAPER
- säkerhet
- ser
- vald
- Server
- Tjänster
- in
- inställning
- Dela
- delas
- Kort
- Områden
- So
- Mjukvara
- Lösningar
- Söder
- Utrymme
- igång
- .
- status
- Tekniken
- Teknologi
- tid
- topp
- trafik
- Uppdateringar
- användare
- värde
- webb
- webbapplikationer
- väster
- VEM
- inom
- arbetsflöde
- fungerar
- världen
- år
- Yoga