Ett stort Business Intelligence-projekt (BI) med många användare och team och känslig information kräver en mångfacetterad säkerhetsarkitektur. En sådan arkitektur bör ge BI-administratörer och arkitekter förmågan att minimera mängden information som är tillgänglig för användare. För en enkel lösning att hantera Amazon QuickSight användar- och tillgångsbehörigheter kan du använda AWS-kommandoradsgränssnitt (AWS CLI) eller AWS Management Console för att manuellt redigera QuickSight-användarroll och tillgång till instrumentpanelen. Men i specifika fall kan ett företag lätt ha hundratals eller tusentals användare och grupper, och dessa åtkomsthanteringsmetoder är inte effektiva. Vi har fått ett stort antal förfrågningar om att tillhandahålla en avancerad programmerbar metod för att distribuera och hantera en centraliserad QuickSight-säkerhetsarkitektur.
Det här inlägget beskriver de bästa metoderna för QuickSight-autentisering och granulär behörighetskontroll, och tillhandahåller en centraliserad molnapplikation med en AWS Cloud Development Kit (AWS CDK) stack att ladda ner. En av fördelarna med vår lösning är att företag kan distribuera säkerhetsramverket för att administrera åtkomstkontroll av sin BI utan att lämna AWS.
Alla konfigurationer sparas i AWS Systems Manager Parameter Store. Parameter Store tillhandahåller säker, hierarkisk lagring för hantering av konfigurationsdata och hemlighetshantering. Du kan lagra data som användarnamn, användarbehörigheter, lösenord och databassträngar som parametervärden. Du kan referera AWS systemchef parametrar i dina skript och arbetsflöden för konfiguration och automatisering genom att använda det unika namn som du angav när du skapade parametern.
AWS CDK-applikationsmallen passar in i infrastrukturen för kontinuerlig integration och kontinuerlig driftsättning (CI/CD) och beviljar eller återkallar alla autentiseringar och auktoriseringar baserat på en definierad policy som föreskrivs av AWS. Detta undviker möjliga mänskliga fel som görs av BI-utvecklare eller administratörer. BI-utvecklare kan redigera konfigurationsparametrar för att släppa nya instrumentpaneler till slutanvändare. Samtidigt kan BI-administratörer redigera ytterligare en uppsättning parametrar för att hantera användare eller grupper. Denna AWS CDK CI/CD-design överbryggar klyftorna mellan utvecklings- och driftaktiviteter genom att framtvinga automatisering vid byggande och driftsättning av BI-applikationer.
Säkerhetskrav
Inom BI-applikationsdesign för företag är multi-tenancy ett vanligt användningsfall som betjänar flera uppsättningar användare med en infrastruktur. Hyresgäster kan antingen vara olika kunder hos en oberoende mjukvaruleverantör (ISV) eller olika avdelningar på ett företag. I en design för flera hyresrätter delar varje hyresgäst instrumentpaneler, analyser och andra QuickSight-tillgångar. Varje användare, som kan se alla andra användare som tillhör samma hyresgäst (till exempel när de delar innehåll), förblir osynliga för andra hyresgäster. Inom varje hyresgäst måste BI-administratörsteamet skapa olika användargrupper för att kontrollera dataauktoriseringen, inklusive tillgångsbehörigheter och dataåtkomst på granulär nivå.
Låt oss diskutera några användningsfall av tillgångsbehörigheter för tillgångar i detalj. I en BI-applikation kategoriseras olika tillgångar vanligtvis efter affärsdomäner (som en operativ instrumentpanel eller sammanfattningsinstrumentpanel) och dataklassificering (kritisk, mycket konfidentiell, endast intern och offentlig). Du kan till exempel ha två instrumentpaneler för att analysera försäljningsresultatdata. Utseendet och känslan för båda instrumentpanelerna är liknande, men säkerhetsklassificeringen av data är olika. En instrumentpanel, som heter Sales Critical Dashboard, innehåller viktiga kolumner och rader med data. Den andra instrumentpanelen, kallad Sales Highly-Confidential Dashboard, innehåller mycket konfidentiella kolumner och rader med data. Vissa användare beviljas behörighet att visa båda instrumentpanelerna, och andra har behörighet på lägre säkerhetsnivå och kan bara komma åt Sales Highly-Confidential Dashboard.
I följande användningsfall adresserar vi dataåtkomst på granulär nivå enligt följande:
- Åtkomst på radnivå (RLS) – För de användare som har tillgång till Sales Critical Dashboard kan vissa av dem bara se USA-data. Vissa globala användare kan dock se data från alla länder, inklusive USA och Storbritannien.
- Åtkomst på kolumnnivå (CLS) – Vissa användare kan bara se datakolumner för icke-personligt identifierbar information (PII), medan HR-teamet kan se alla kolumner i samma dataset.
Stora projekt kan ha flera hyresgäster, hundratals grupper och tusentals användare i ett QuickSight-konto. Dataledarteamet vill distribuera ett protokoll för skapande och autentisering av användare för att minska underhållskostnaden och säkerhetsrisken. Arkitekturen och arbetsflödet som beskrivs i det här inlägget hjälper dataledaren att uppnå detta mål.
Dessutom, för att undvika mänskliga fel i den dagliga driften, vill vi att dessa säkerhetsbehörigheter ska beviljas och återkallas automatiskt och passa in i CI/CD-infrastrukturen. Detaljerna förklaras senare i detta inlägg.
Arkitekturöversikt
Följande diagram visar QuickSight-kontoarkitekturen för denna lösning.
- Författare skapar instrumentpaneler och uppdaterar AWS Systems Manager Parameter Store för att släppa instrumentpaneler till olika grupper
- Administratörer godkänner förfrågningar från författare
- Administratörer uppdaterar användarhantering (roller, namnutrymme) genom att redigera AWS Systems ManagerParameter Store
- DevOps distribuerar uppdateringarna med AWS CDK
*Grupper: Behörighetsgrupper för objektåtkomst styr ägaren/visaren av objekten. Datasegmentgrupper kombinerade med RLS/CLS styr dataåtkomst.
*Datauppsättningar: Innehåller all data, begränsad av säkerhet på radnivå (RLS) och säkerhet på kolumnnivå (CLS)
Följande diagram illustrerar autentiseringsarbetsflödet för arkitekturen:
*Första gången du loggar in i QuickSight: Om QuickSight-användaren inte är registrerad före första inloggningen skapas en läsare och den här läsaren kan endast se målsidans instrumentpanel, som delas med alla användare av detta konto. Målsidan tillhandahåller rapportlistan som den här användaren kan se.
Följande diagram illustrerar auktoriseringsarbetsflödet för arkitekturen.
Detaljer för auktoriseringsdiagram:
- Användarinformation (avdelning, team, geografisk plats) lagras i Amazon Redshift, Amazon Athena eller någon annan databas. I kombination med gruppanvändarmappning byggs RLS-databaser för kontroll av dataåtkomst.
- Tilldelning av tillstånd per timme:
- Enligt grupp-anställds namn (användare) mappning (membership.csv) och grupp-roll mappning (/qs/console/rolles) skapar en AWS Lambda-funktion grupper, registrerar, användare, tilldelar gruppmedlemmar, tar bort gruppmedlemskap, främjar läsare till författare eller administratör, och tar bort användare om de degraderas från författare eller administratör till läsare.
- Enligt grupp-dashboard-mappning i /qs/config/access uppdaterar en AWS Lambda-funktion instrumentpanelsbehörigheter till QuickSight-grupper.
- Enligt group-namespace-mappning i membership.csv skapar en AWS Lambda-funktion QuickSight-grupper i det angivna namnutrymmet.
- Exempelparametrar för objekts åtkomstbehörigheter och datasegment:
- Exempelparametrar för QuickSight-användarroll:
- Exempeldata för membership.csv:
I den här lösningen distribueras anpassade namnutrymmen för att stödja multi-tenancy. De default
namnutrymme är för alla interna användare av ett företag (vi kallar det OkTank). OkTank skapar 3rd-Party
namnutrymme för externa användare. Om vi måste stödja fler hyresgäster kan vi skapa fler anpassade namnutrymmen. Som standard är vi begränsade till 100 namnutrymmen per AWS-konto. För att öka denna gräns, kontakta QuickSights produktteam. För mer information om flerboende, se Bädda in flera hyresgästanalyser i applikationer med Amazon QuickSight.
I varje namnområde skapar vi olika typer av grupper. Till exempel i default
namnutrymme skapar vi BI-Admin
och BI-Developer
grupper för admin
och author
användare. För reader
, distribuerar vi två typer av QuickSight-grupper för att kontrollera tillgångsbehörigheter och dataåtkomst: behörighetsgrupper för objektåtkomst och grupper av datasegment.
Följande tabell sammanfattar hur behörighetsgrupperna för objektåtkomst kontrollerar behörigheter.
Grupp namn | namespace | tillstånd | Anmärkningar |
critical |
Standard | Visa båda instrumentpanelerna (som innehåller kritiska data och mycket konfidentiell data) | |
highlyconfidential |
Standard | Visa endast Sales Highly-Confidential Dashboard | |
BI-Admin |
Standard | Kontohantering och redigera alla tillgångar | Användare i BI-Admin gruppen tilldelas Admin QuickSight användarroll. |
BI-Developer |
Standard | Redigera alla tillgångar | Användare i BI-Developer gruppen tilldelas användarrollen Author QuickSight. |
Power-reader |
Standard | Visa alla tillgångar och skapa ad hoc-analyser för att köra självbetjäningsanalysrapporter |
Användare i Den här gruppen kan dock inte spara eller dela sina ad hoc-rapporter. |
3rd-party |
Namnutrymmen som inte är standard (3rd-party namnutrymme, till exempel) |
Kan bara dela med läsare (3rd-party-reader grupp, till exempel) i samma namnområde |
I icke-standardnamnutrymmen kan vi också skapa andra behörighetsgrupper för objektåtkomst, vilket liknar den kritiska gruppen i standardnamnutrymmet. |
För mer information om QuickSight-grupper, användare och användarroller, se Hantera användaråtkomst inuti Amazon QuickSight, Provisioning användare för Amazon QuickSightoch Använda administrativa instrumentpaneler för en centraliserad vy av Amazon QuickSight-objekt.
Den andra typen av grupper (datasegmentgrupper), i kombination med radnivå säkerhet datauppsättningar och säkerhet på kolumnnivå, kontrollera dataåtkomst enligt beskrivningen i följande tabell.
Grupp namn | namespace | tillstånd | Omfattning |
USA |
Standard | Visa endast amerikanska data på någon instrumentpanel | Rad-nivå |
GBR |
Standard | Visa endast data från Storbritannien på någon instrumentpanel | Rad-nivå |
All countries |
Standard | Visa data för alla länder på valfri instrumentpanel | Rad-nivå |
non-PII |
Standard | Kan inte se personnummer, årsinkomst och alla andra kolumner med PII-data | Kolumnnivå |
PII |
Standard | Kan se alla kolumner inklusive PII-data | Kolumnnivå |
Vi kan sätta upp liknande grupper i icke-standardnamnrymder.
Dessa olika grupper kan överlappa varandra. Till exempel om en användare tillhör grupperna USA
, Critical
och PII
, kan de se USA-data på båda instrumentpanelerna, med alla kolumner. Följande Venn-diagram illustrerar sambanden mellan dessa grupper.
Sammanfattningsvis kan vi definiera en mångfacetterad säkerhetsarkitektur genom att kombinera QuickSight-funktioner, inklusive namnområde, grupp, användare, RLS och CLS. Alla relaterade konfigurationer sparas i Parameter Store. QuickSight-användarlistan och kartinformationen för gruppanvändare finns i en Amazon enkel lagringstjänst (Amazon S3) hink som en CSV-fil (namngiven membership.csv
). Den här CSV-filen kan vara resultat av LDAP-frågor. Flera AWS Lambda funktioner är schemalagda att köras varje timme (du kan också anropa dessa funktioner på begäran, såsom daglig, veckovis eller när som helst granularitet som passar dina krav) för att läsa parametrarna och membership.csv
. Enligt den definierade konfigurationen skapar, uppdaterar eller tar Lambda-funktionerna åtkomstbehörigheter för grupper, användare och tillgångar.
När de nödvändiga säkerhetskonfigurationerna är klara anropar en Lambda-funktion QuickSight API:erna för att få den uppdaterade informationen och registrera resultaten i en S3-bucket som CSV-filer. BI-administratörsteamet kan bygga datauppsättningar med dessa filer och visualisera resultaten med instrumentpaneler. För mer information, se Använda administrativa instrumentpaneler för en centraliserad vy av Amazon QuickSight-objekt och Bygga en administrativ konsol i Amazon QuickSight för att analysera användningsstatistik.
Dessutom lagras felen i Lambda-funktioner och användarraderingshändelser i denna S3-bucket för administratörsteamet att granska.
Automation
Följande diagram illustrerar det övergripande arbetsflödet för Lambda-funktionerna.
Vi använder en programmerbar metod för att skapa och konfigurera grupperna och användarna automatiskt. För någon ad hoc-användarregistreringsförfrågan (som att användaren inte är registrerad i membership.csv
men på grund av latens), så länge som användaren kan autentiseras, kan de anta AWS identitets- och åtkomsthantering (IAM) roll quicksight-fed-user
till självförsörjning som QuickSight-läsare. Den här självtillgängliga läsaren kan bara se en målsidas instrumentpanel, som ger listan över instrumentpaneler och motsvarande grupper. Enligt dashboard-gruppmappningen kan den här nya läsaren ansöka om medlemskap i en given grupp för att få tillgång till instrumentpanelerna. Om gruppägaren godkänner applikationen lägger Lambda-funktionerna varje timme till den nya användaren i gruppen nästa gång de körs.
CI/CD-pipelinen startar från AWS CDK. BI-administratören och författaren kan uppdatera Systems Manager-parametrarna för att släppa nya instrumentpaneler eller andra QuickSight-tillgångar i AWS CDK-stacken granular_access_stack.py
. BI-administratören kan uppdatera Systems Manager-parametrarna i samma stack för att skapa, uppdatera eller ta bort namnområden, grupper eller användare. Sedan kan DevOps-teamet distribuera den uppdaterade AWS CDK-stacken för att tillämpa dessa ändringar på Systems Manager-parametrarna eller andra AWS-resurser. Lambdafunktionerna utlöses varje timme för att anropa API:er för att tillämpa ändringar på det relaterade QuickSight-kontot.
Skala
Lambdafunktionerna är begränsade av den maximala körtiden på 15 minuter. För att övervinna denna begränsning kan vi konvertera Lambda-funktionerna till AWS-lim Python-skalskript med följande steg på hög nivå:
- Download Boto3 hjulfiler från pypi.org.
- Ladda upp hjulfilen i en S3-hink.
- ladda ner Lambda-funktioner och slå samman dem till ett Python-skript och skapa ett AWS Glue Python-skalskript.
- Lägg till S3-sökvägen för Boto3-hjulfilen i Python-bibliotekets sökväg. Om du har flera filer att lägga till, separera dem med ett kommatecken.
- Schemalägg detta AWS-limjobb att köras dagligen.
För mer information, se Programmera AWS Glue ETL-skript i Python och Använda Python Libraries med AWS Glue.
Förutsättningar
Du måste ha följande förutsättningar för att implementera den här lösningen:
- Ett QuickSight Enterprise-konto
- Grundläggande kunskaper i Python
- Grundläggande kunskaper i SQL
- Grundläggande kunskaper i BI
Skapa resurserna
Skapa dina resurser genom att ladda ner AWS CDK-stacken från GitHub repo.
I granular_access
mapp, kör kommandot cdk deploy granular-access
att använda resurserna. För mer information, se AWS CDK Intro Workshop: Python Workshop.
Distribuera lösningen
När du distribuerar AWS CDK-stacken skapar den fem Lambda-funktioner, som visas i följande skärmdump.
Stacken skapar också ytterligare stödjande resurser på ditt konto.
Smakämnen granular_user_governance
funktionen utlöses av amazoncloudwatch händelseregel qs-gc-everyhour
. Informationen om grupper och användare definieras i filen membership.csv
. S3-skopnamnet lagras i parameterlagret /qs/config/groups
. Följande diagram visar flödesschemat för denna funktion.
- Ställ in destinationen för
granular_user_governance
till en annan lambdafunktion,downgrade_user
, medsource=Asynchronous invocation
ochcondition=On Success
.
Följande diagram är ett flödesschema för denna funktion.
För att undvika att bryta kritisk åtkomst till QuickSight-tillgångar som styrs av admin eller författare, degraderar vi en administratör eller författare genom att ta bort admin- eller författareanvändaren och skapa en ny läsaranvändare med Lambda-funktionen downgrade_user
. De granular_user_governance
funktion hanterar nedgradering av admin till författare, eller uppgradering av författare till admin.
- Ställ in destinationen för
downgrade_user
till Lambdafunktionengranular_access_assets_govenance
medsource=Asynchronous invocation
ochcondition=On Success
.
Följande diagram visar ett flödesschema för denna funktion.
- Ställ in destinationen för
downgrade_user
till Lambdafunktionencheck_team_members
medsource=Asynchronous invocation
ochcondition=On Failure
.
Smakämnen check_team_members
Funktionen anropar helt enkelt QuickSight API:er för att få information om namnområden, grupper, användare och tillgångar och sparar resultaten i S3-bucket. S3-nyckeln är monitoring/quicksight/group_membership/group_membership.csv
och monitoring/quicksight/object_access/object_access.csv
.
Förutom de två utdatafilerna från föregående steg, felloggar och användarraderingsloggar (loggar för downgrade_user
) sparas också i monitoring/quicksight
mapp.
- Ställ in destinationen för
granular_access_assets_govenance
till Lambdafunktionencheck_team_members
medsource=Asynchronous invocation
ochcondition=On Success
orcondition=On Failure
.
Skapa säkerhetsdatauppsättningar på radnivå
Som ett sista steg skapar vi RLS-datauppsättningar. Detta låter dig ändra instrumentpanelsposterna baserat på de användare som ser instrumentpanelerna.
QuickSight stöder RLS genom att tillämpa en systemhanterad datauppsättning som underväljer poster från instrumentpanelens datauppsättning. Mekanismen tillåter administratören att tillhandahålla en filtreringsdatauppsättning (RLS-datauppsättningen). username
or groupname
kolumner, som automatiskt filtreras till den användare som är inloggad. Till exempel en användare som heter YingWang
tillhör QuickSight-gruppen BI
, så alla rader i RLS-datauppsättningen som motsvarar användarnamnet YingWang
eller gruppnamn BI
filtreras. De rader som finns kvar i RLS efter att användarnamnet och gruppnamnfiltren har använts används sedan för att filtrera instrumentpanelens datauppsättningar ytterligare genom att matcha kolumner med samma namn. För mer information om säkerhet på radnivå, se Använda Row-Level Security (RLS) för att begränsa åtkomst till en datamängd.
I den här lösningen exporterar vi exempelanvändarinformationen till filen membership.csv
, som förvaras i en S3 hink. I den här filen tillhandahåller vi några exempelgrupper för definition av RLS-datauppsättning. Dessa grupper är datasegmentgrupperna, som beskrivs i den övergripande arkitekturdesignen. Följande skärmdump visar några av grupperna och användarna i dessa grupper.
Smakämnen granular_user_governance
funktionen skapar dessa grupper och lägger till relaterade användare för att vara medlemmar i dessa grupper.
Hur skapar vi RLS-datauppsättningen? Låt oss säga att vi har ett bord som heter employee_information
i vår organisations HR-databas. Följande skärmdump visar några exempeldata.
Baserat på employee_information
tabell skapar vi en vy som heter rls
för en RLS-datauppsättning. Se följande SQL-kod:
Följande skärmdump visar våra exempeldata.
Nu har vi tabellen klar, vi kan skapa RLS-datauppsättningen med följande anpassade SQL:
Följande skärmdump visar våra exempeldata.
För gruppen quicksight-fed-all-countries
, ställer vi in username
, country
och city
som null, vilket innebär att alla användare i denna grupp kan se data för alla länder.
För landsnivå gäller endast säkerhetsreglerna som definieras i groupname
och land columns
används för filtrering. De username
och city
kolumner sätts som null. Användarna i quicksight-fed-usa
grupp kan se data från USA och användarna i quicksight-fed-gbr
grupp kan se data för GBR.
För varje användare med groupname
inställd som null, kan de bara se det specifika land och stad som tilldelats deras användarnamn. Till exempel, TerryRigaud
kan bara se data från Austin, i USA.
I QuickSight kombineras flera regler i en RLS-datauppsättning tillsammans med OR.
Med dessa mångfacetterade RLS-regler kan vi definiera ett omfattande dataåtkomstmönster.
Städa upp
För att undvika framtida avgifter, radera resurserna du skapade genom att köra följande kommando:
Slutsats
Det här inlägget diskuterade hur BI-administratörer kan designa och automatisera QuickSight-autentisering och granulär behörighetskontroll. Vi kombinerade QuickSight-säkerhetsfunktioner som säkerhet på rad- och kolumnnivå, grupper och namnområden för att tillhandahålla en heltäckande lösning. Att hantera dessa ändringar genom "BIOps" säkerställer en robust, skalbar mekanism för att hantera QuickSight-säkerhet. Att lära sig mer, registrera dig för en QuickSight-demo.
Om författarna
Ying Wang är en senior datavisualiseringsingenjör med Data & Analytics Global Specialty Practice inom AWS Professional Services.
Amir Bar Or är en huvuddataarkitekt på AWS Professional Services. Efter 20 år att ha lett mjukvaruorganisationer och utvecklat dataanalysplattformar och -produkter delar han nu med sig av sin erfarenhet med stora företagskunder och hjälper dem att skala sin dataanalys i molnet.
- "
- &
- 100
- tillgång
- Behörighets förvaltning
- Konto
- aktiviteter
- Ad
- Annat
- administration
- Alla
- amason
- analys
- analytics
- API: er
- Ansökan
- tillämpningar
- arkitektur
- tillgång
- Tillgångar
- austin
- Autentisering
- tillstånd
- Automation
- AWS
- AWS Lambda
- BÄST
- bästa praxis
- gränsen
- SLUTRESULTAT
- Byggnad
- företag
- business intelligence
- Ring
- fall
- byta
- avgifter
- Stad
- klassificering
- cloud
- koda
- Gemensam
- företag
- innehåll
- länder
- Skapa
- Kunder
- instrumentbräda
- datum
- datatillgång
- Data Analytics
- datahantering
- datavisualisering
- Databas
- databaser
- Efterfrågan
- Designa
- förstöra
- detalj
- utvecklare
- Utveckling
- DevOps
- domäner
- ingenjör
- Företag
- företagskunder
- händelse
- händelser
- verkställande
- export
- Funktioner
- filter
- Förnamn
- första gången
- passa
- Ramverk
- fungera
- framtida
- Välgörenhet
- bidrag
- Grupp
- Hur ser din drömresa ut
- hr
- HTTPS
- Hundratals
- IAM
- Identitet
- Inklusive
- Inkomst
- Öka
- informationen
- Infrastruktur
- integrering
- Intelligens
- IT
- Jobb
- delta
- Nyckel
- kunskap
- målsida
- Large
- ldap
- ledande
- LÄRA SIG
- Nivå
- Bibliotek
- Begränsad
- linje
- Lista
- läge
- Lång
- ledning
- Medlemmar
- namn
- nummer
- beställa
- Övriga
- Övrigt
- ägaren
- lösenord
- Mönster
- pii
- Plattformar
- policy
- Principal
- Produkt
- Produkter
- projektet
- projekt
- allmän
- Python
- Läsare
- läsare
- register
- minska
- Registrering
- Förhållanden
- Rapport
- Krav
- Resurser
- Resultat
- översyn
- Risk
- regler
- Körning
- rinnande
- försäljning
- Skala
- säkerhet
- Självbetjäning
- Tjänster
- in
- Dela
- aktier
- Shell
- Enkelt
- So
- Social hållbarhet
- Mjukvara
- SQL
- förvaring
- lagra
- stödja
- Stöder
- System
- tid
- Uk
- fackliga
- Uppdatering
- Uppdateringar
- us
- USA
- användare
- utsikt
- visualisering
- vecka
- Hjul
- VEM
- inom
- arbetsflöde
- år