Et stort Business Intelligence (BI) projekt med mange brugere og teams og følsom information kræver en mangesidet sikkerhedsarkitektur. En sådan arkitektur bør give BI-administratorer og -arkitekter mulighed for at minimere mængden af information, der er tilgængelig for brugerne. For en ligetil løsning at administrere Amazon QuickSight bruger- og aktivadgangstilladelser, kan du bruge AWS kommandolinjegrænseflade (AWS CLI) eller AWS Management Console for manuelt at redigere QuickSight-brugerrolle og dashboardadgang. Men i specifikke tilfælde kan en virksomhed nemt have hundreder eller tusinder af brugere og grupper, og disse adgangsstyringsmetoder er ikke effektive. Vi har modtaget et stort antal anmodninger om at levere en avanceret programmerbar tilgang til at implementere og administrere en centraliseret QuickSight-sikkerhedsarkitektur.
Dette indlæg beskriver de bedste fremgangsmåder for QuickSight-godkendelse og autorisation granulær adgangskontrol og giver en centraliseret cloud-applikation med en AWS Cloud Development Kit (AWS CDK) stak til download. En af fordelene ved vores løsning er, at virksomheder kan implementere sikkerhedsrammen til at administrere adgangskontrol af deres BI uden at forlade AWS.
Alle konfigurationer gemmes i AWS Systems Manager Parameter Store. Parameter Store giver sikker, hierarkisk lagring til administration af konfigurationsdata og hemmeligheder. Du kan gemme data såsom brugernavn, brugertilladelser, adgangskoder og databasestrenge som parameterværdier. Du kan referere AWS System Manager parametre i dine scripts og konfigurations- og automatiseringsarbejdsgange ved at bruge det unikke navn, du angav, da du oprettede parameteren.
AWS CDK-applikationsskabelonen passer ind i infrastrukturen for kontinuerlig integration og kontinuerlig implementering (CI/CD) og tildeler eller tilbagekalder alle godkendelser og autorisationer baseret på en defineret politik foreskrevet af AWS. Dette undgår mulige menneskelige fejl begået af BI-udviklere eller -administratorer. BI-udviklere kan redigere konfigurationsparametre for at frigive nye dashboards til slutbrugere. Samtidig kan BI-administratorer redigere et andet sæt parametre for at administrere brugere eller grupper. Dette AWS CDK CI/CD-design bygger bro mellem udviklings- og driftsaktiviteter ved at håndhæve automatisering i opbygning og implementering af BI-applikationer.
Sikkerhedskrav
I enterprise BI-applikationsdesign er multi-tenancy en almindelig anvendelse, som betjener flere sæt brugere med én infrastruktur. Lejere kan enten være forskellige kunder hos en uafhængig softwareleverandør (ISV) eller forskellige afdelinger i en virksomhed. I et multi-lejemålsdesign deler hver lejer dashboards, analyser og andre QuickSight-aktiver. Hver bruger, som kan se alle andre brugere, der tilhører den samme lejer (f.eks. når de deler indhold), forbliver usynlige for andre lejere. Inden for hver lejer skal BI-administratorteamet oprette forskellige brugergrupper for at kontrollere datagodkendelsen, herunder aktivadgangstilladelser og dataadgang på granulært niveau.
Lad os diskutere nogle tilfælde af brug af aktivadgangstilladelser i detaljer. I en BI-applikation kategoriseres forskellige aktiver normalt efter forretningsdomæner (såsom et operationelt dashboard eller et executive summary-dashboard) og dataklassificering (kritisk, yderst fortroligt, kun internt og offentligt). For eksempel kan du have to dashboards til at analysere salgsresultatdata. Udseendet og følelsen af begge dashboards er ens, men sikkerhedsklassificeringen af dataene er forskellig. Ét dashboard, kaldet Sales Critical Dashboard, indeholder vigtige kolonner og rækker af data. Det andet dashboard, kaldet Sales Highly-Confidential Dashboard, indeholder meget fortrolige kolonner og rækker af data. Nogle brugere får tilladelse til at se begge dashboards, og andre har tilladelse på et lavere sikkerhedsniveau og kan kun få adgang til Sales Highly-Confidential Dashboard.
I følgende tilfælde behandler vi dataadgang på granulært niveau som følger:
- Adgang på rækkeniveau (RLS) – For de brugere, der kan få adgang til Sales Critical Dashboard, kan nogle af dem kun se amerikanske data. Nogle globale brugere kan dog se data fra alle lande, inklusive USA og Storbritannien.
- Adgang på kolonneniveau (CLS) – Nogle brugere kan kun se ikke-personligt identificerbare oplysninger (PII) datakolonner i et datasæt, mens HR-teamet kan se alle kolonnerne i det samme datasæt.
Store projekter kan have flere lejere, hundredvis af grupper og tusindvis af brugere på én QuickSight-konto. Datalederteamet ønsker at implementere én protokol til brugeroprettelse og -godkendelse for at reducere vedligeholdelsesomkostningerne og sikkerhedsrisikoen. Arkitekturen og arbejdsgangen beskrevet i dette indlæg hjælper datalederen med at nå dette mål.
For at undgå menneskelige fejl i den daglige drift ønsker vi desuden, at disse sikkerhedstilladelser gives og tilbagekaldes automatisk og passer ind i CI/CD-infrastrukturen. Detaljerne forklares senere i dette indlæg.
Arkitektur oversigt
Følgende diagram viser QuickSight-kontoarkitekturen for denne løsning.
- Forfattere opretter dashboards og opdaterer AWS Systems Manager Parameter Store for at frigive dashboards til forskellige grupper
- Administratorer godkender anmodninger fra forfattere
- Administratorer opdaterer brugeradministration (roller, navneområde) ved at redigere AWS Systems ManagerParameter Store
- DevOps implementerer opdateringerne med AWS CDK
*Grupper: Tilladelsesgrupper for objektadgang styrer ejeren/fremviseren af objekterne. Datasegmentgrupper kombineret med RLS/CLS styrer dataadgang.
*Datasæt: Indeholder alle data, begrænset af sikkerhed på rækkeniveau (RLS) og sikkerhed på kolonneniveau (CLS)
Følgende diagram illustrerer godkendelsesworkflowet for arkitekturen:
*Førstegangslog på QuickSight: Hvis QuickSight-brugeren ikke er registreret før første gangs login, oprettes en læser, og denne læser kan kun se destinationssidens dashboard, som deles med alle brugere af denne konto. Landingssiden giver den rapportliste, som denne bruger kan se.
Følgende diagram illustrerer godkendelsesarbejdsgangen for arkitekturen.
Detaljer om autorisationsdiagram:
- Brugeroplysninger (afdeling, team, geografisk placering) gemmes i Amazon Redshift, Amazon Athena eller enhver anden database. Kombineret med gruppe-bruger-mapping er RLS-databaser bygget til kontrol af dataadgang.
- Tildeling af tilladelser pr. time:
- Ifølge gruppe-medarbejdernavn (bruger) mapping (membership.csv) og gruppe-rolle mapping (/qs/console/rolles), opretter en AWS Lambda-funktion grupper, registrerer, brugere, tildeler gruppemedlemmer, fjerner gruppemedlemskaber, fremmer læsere til forfatter eller administrator, og sletter brugere, hvis de bliver degraderet fra forfatter eller administrator til læser.
- Ifølge gruppe-dashboard-kortlægning i /qs/config/access opdaterer en AWS Lambda-funktion dashboard-tilladelser til QuickSight-grupper.
- Ifølge gruppe-navneområde-tilknytning i membership.csv opretter en AWS Lambda-funktion QuickSight-grupper i det angivne navneområde.
- Eksempel på parametre for objektadgangstilladelser og datasegmenter:
- Eksempel på parametre for QuickSight-brugerrolle:
- Eksempeldata for medlemskab.csv:
I denne løsning er brugerdefinerede navnerum implementeret for at understøtte multi-tenancy. Det default
navneområde er for alle interne brugere af en virksomhed (vi kalder det OkTank). OkTank opretter 3rd-Party
navneområde for eksterne brugere. Hvis vi skal støtte flere lejere, kan vi skabe flere tilpassede navneområder. Som standard er vi begrænset til 100 navneområder pr. AWS-konto. Kontakt QuickSight-produktteamet for at øge denne grænse. For mere information om multi-lejemål, se Integrer multi-tenant-analyse i applikationer med Amazon QuickSight.
I hvert navneområde opretter vi forskellige typer grupper. For eksempel i default
navneområde opretter vi BI-Admin
, BI-Developer
grupper for admin
, author
brugere. Til reader
, implementerer vi to typer QuickSight-grupper til at kontrollere aktivadgangstilladelser og dataadgang: objektadgangstilladelsesgrupper og datasegmentgrupper.
Følgende tabel opsummerer, hvordan objektadgangstilladelsesgrupperne kontrollerer tilladelser.
Gruppe navn | navnerum | Tilladelse | Noter |
critical |
Standard | Se begge dashboards (indeholder de kritiske data og meget fortrolige data) | |
highlyconfidential |
Standard | Se kun Sales High-Confidential Dashboard | |
BI-Admin |
Standard | Kontostyring og redigering af alle aktiver | Brugere i BI-Admin gruppen tildeles Admin QuickSight brugerrolle. |
BI-Developer |
Standard | Rediger alle aktiver | Brugere i BI-Developer gruppe tildeles brugerrollen Author QuickSight. |
Power-reader |
Standard | Se alle aktiver, og opret ad hoc-analyser for at køre selvbetjeningsanalyserapporter |
Brugere i Denne gruppe kan dog ikke gemme eller dele deres ad hoc-rapporter. |
3rd-party |
Ikke-standard navnerum (3rd-party navneområde, for eksempel) |
Kan kun dele med læserne (3rd-party-reader gruppe, for eksempel) i det samme navneområde |
I ikke-standardnavneområder kan vi også oprette andre tilladelsesgrupper for objektadgang, som ligner den kritiske gruppe i standardnavneområdet. |
For mere information om QuickSight-grupper, brugere og brugerroller, se Håndtering af brugeradgang inde i Amazon QuickSight, Klargøring af brugere til Amazon QuickSightog Brug af administrative dashboards til en centraliseret visning af Amazon QuickSight-objekter.
Den anden type grupper (datasegmentgrupper), kombineret med sikkerhed på rækkeniveau datasæt og sikkerhed på kolonneniveau, kontroller dataadgang som beskrevet i følgende tabel.
Gruppe navn | navnerum | Tilladelse | Anvendelsesområde |
USA |
Standard | Se kun amerikanske data på ethvert dashboard | Række-niveau |
GBR |
Standard | Se kun britiske data på ethvert dashboard | Række-niveau |
All countries |
Standard | Se data for alle lande på ethvert dashboard | Række-niveau |
non-PII |
Standard | Kan ikke se CPR-numre, årlig indkomst og alle andre kolonner med PII-data | Kolonneniveau |
PII |
Standard | Kan se alle kolonner inklusive PII-data | Kolonneniveau |
Vi kan oprette lignende grupper i ikke-standardnavneområder.
Disse forskellige grupper kan overlappe hinanden. For eksempel hvis en bruger tilhører grupperne USA
, Critical
og PII
, kan de se amerikanske data på begge dashboards med alle kolonner. Følgende Venn-diagram illustrerer sammenhængen mellem disse grupper.
Sammenfattende kan vi definere en mangefacetteret sikkerhedsarkitektur ved at kombinere QuickSight-funktioner, herunder navneområde, gruppe, bruger, RLS og CLS. Alle relaterede konfigurationer gemmes i parameterlageret. QuickSight-brugerlisten og gruppe-bruger-kortlægningsoplysninger er i en Amazon Simple Storage Service (Amazon S3)-bøtte som en CSV-fil (navngivet membership.csv
). Denne CSV-fil kunne være outputresultater af LDAP-forespørgsler. Flere AWS Lambda funktioner er planlagt til at køre hver time (du kan også aktivere disse funktioner efter behov, f.eks. daglig, ugentlig eller et hvilket som helst tidspunkt, der passer til dine krav) for at læse parametrene og membership.csv
. I henhold til den definerede konfiguration opretter, opdaterer eller sletter Lambda-funktionerne grupper, brugere og aktivadgangstilladelser.
Når de nødvendige sikkerhedskonfigurationer er færdige, kalder en Lambda-funktion QuickSight API'erne for at få de opdaterede oplysninger og registrere resultaterne i en S3-bøtte som CSV-filer. BI-administratorteamet kan bygge datasæt med disse filer og visualisere resultaterne med dashboards. For mere information, se Brug af administrative dashboards til en centraliseret visning af Amazon QuickSight-objekter , Opbygning af en administrativ konsol i Amazon QuickSight til at analysere brugsmålinger.
Derudover gemmes fejlene i Lambda-funktioner og brugersletningshændelser i denne S3-bøtte, så administratorteamet kan gennemgå dem.
Automation
Følgende diagram illustrerer den overordnede arbejdsgang for Lambda-funktionerne.
Vi bruger en programmerbar metode til at oprette og konfigurere grupperne og brugerne automatisk. For enhver ad hoc brugerregistreringsanmodning (såsom brugeren ikke er registreret i membership.csv
dog på grund af latens), så længe brugeren kan godkendes, kan de antage AWS identitets- og adgangsstyring (IAM) rolle quicksight-fed-user
til selvforsyning som QuickSight-læser. Denne selvleverede læser kan kun se et dashboard på en destinationsside, som giver listen over dashboards og tilsvarende grupper. Ifølge kortlægningen af dashboard-gruppe kan denne nye læser ansøge om medlemskab af en given gruppe for at få adgang til dashboards. Hvis gruppeejeren godkender applikationen, tilføjer de timelige Lambda-funktioner den nye bruger til gruppen, næste gang de kører.
CI/CD-pipelinen starter fra AWS CDK. BI-administratoren og forfatteren kan opdatere Systems Manager-parametrene for at frigive nye dashboards eller andre QuickSight-aktiver i AWS CDK-stakken granular_access_stack.py
. BI-administratoren kan opdatere Systems Manager-parametrene i den samme stak for at oprette, opdatere eller slette navnerum, grupper eller brugere. Derefter kan DevOps-teamet implementere den opdaterede AWS CDK-stak for at anvende disse ændringer på Systems Manager-parametrene eller andre AWS-ressourcer. Lambda-funktionerne udløses hver time for at kalde API'er for at anvende ændringer på den relaterede QuickSight-konto.
Scale
Lambda-funktionerne er begrænset af den maksimale køretid på 15 minutter. For at overvinde denne begrænsning kan vi konvertere Lambda-funktionerne til AWS Lim Python shell-scripts med følgende trin på højt niveau:
- Hent Boto3 hjulfiler fra pypi.org.
- Upload hjulfilen i en S3-spand.
- Download Lambda funktioner og flet dem ind i et Python-script og opret et AWS Glue Python-skal-script.
- Tilføj S3-stien til Boto3-hjulfilen til Python-biblioteksstien. Hvis du har flere filer at tilføje, skal du adskille dem med et komma.
- Planlæg dette AWS-lim-job til at køre dagligt.
For mere information, se Programmer AWS Glue ETL-scripts i Python , Brug af Python-biblioteker med AWS-lim.
Forudsætninger
Du skal have følgende forudsætninger for at implementere denne løsning:
- En QuickSight Enterprise-konto
- Grundlæggende kendskab til Python
- Grundlæggende kendskab til SQL
- Grundlæggende kendskab til BI
Opret ressourcerne
Opret dine ressourcer ved at downloade AWS CDK-stakken fra GitHub repo.
I granular_access
mappe, skal du køre kommandoen cdk deploy granular-access
at sætte ressourcerne ind. For mere information, se AWS CDK Intro Workshop: Python Workshop.
Implementer løsningen
Når du implementerer AWS CDK-stakken, opretter den fem Lambda-funktioner, som vist på det følgende skærmbillede.
Stakken skaber også yderligere understøttende ressourcer på din konto.
granular_user_governance
funktionen udløses af amazoncloudwatch begivenhedsregel qs-gc-everyhour
. Oplysningerne om grupper og brugere er defineret i filen membership.csv
. S3-spandnavnet gemmes i parameterlageret /qs/config/groups
. Følgende diagram viser rutediagrammet for denne funktion.
- Indstil destinationen for
granular_user_governance
til en anden lambdafunktion,downgrade_user
, medsource=Asynchronous invocation
,condition=On Success
.
Følgende diagram er et rutediagram over denne funktion.
For at undgå at bryde kritisk adgang til QuickSight-aktiver styret af administrator eller forfatter, degraderer vi en administrator eller forfatter ved at slette administrator- eller forfatterbrugeren og oprette en ny læserbruger med Lambda-funktionen downgrade_user
. Det granular_user_governance
funktion håndterer nedgradering af admin til forfatter, eller opgradering af forfatter til admin.
- Indstil destinationen for
downgrade_user
til Lambda-funktionengranular_access_assets_govenance
medsource=Asynchronous invocation
,condition=On Success
.
Følgende diagram viser et rutediagram over denne funktion.
- Indstil destinationen for
downgrade_user
til Lambda-funktionencheck_team_members
medsource=Asynchronous invocation
,condition=On Failure
.
check_team_members
funktionen kalder ganske enkelt QuickSight API'er for at få navneområder, grupper, brugere og aktiveroplysninger og gemmer resultaterne i S3-bøtten. S3 nøglen er monitoring/quicksight/group_membership/group_membership.csv
, monitoring/quicksight/object_access/object_access.csv
.
Udover de to outputfiler fra det foregående trin, fejllogfilerne og brugersletningslogfilerne (logs af downgrade_user
) gemmes også i monitoring/quicksight
mappe.
- Indstil destinationen for
granular_access_assets_govenance
til Lambda-funktionencheck_team_members
medsource=Asynchronous invocation
,condition=On Success
orcondition=On Failure
.
Opret sikkerhedsdatasæt på rækkeniveau
Som et sidste trin opretter vi RLS-datasæt. Dette giver dig mulighed for at ændre dashboard-posterne baseret på de brugere, der ser dashboards.
QuickSight understøtter RLS ved at anvende et systemstyret datasæt, der undervælger poster fra dashboarddatasættet. Mekanismen gør det muligt for administratoren at levere et filtreringsdatasæt (RLS-datasættet). username
or groupname
kolonner, som automatisk filtreres til den bruger, der er logget ind. F.eks. en bruger navngivet YingWang
tilhører QuickSight-gruppen BI
, så alle rækkerne i RLS-datasættet, der svarer til brugernavnet YingWang
eller gruppenavn BI
er filtreret. De rækker, der forbliver i RLS'en efter anvendelse af brugernavnet og gruppenavnsfiltrene, bruges derefter til at filtrere dashboarddatasættene yderligere ved at matche kolonner med de samme navne. For mere information om sikkerhed på rækkeniveau, se Brug af Row-Level Security (RLS) til at begrænse adgangen til et datasæt.
I denne løsning eksporterer vi prøvebrugeroplysningerne til filen membership.csv
, som opbevares i en S3 spand. I denne fil giver vi nogle eksempelgrupper til definition af RLS-datasæt. Disse grupper er datasegmentgrupperne, som beskrevet i det overordnede arkitekturdesign. Følgende skærmbillede viser nogle af grupperne og brugerne i disse grupper.
granular_user_governance
funktion opretter disse grupper og tilføjer de relaterede brugere til at være medlemmer af disse grupper.
Hvordan opretter vi RLS-datasættet? Lad os sige, at vi har et bord, der hedder employee_information
i vores organisations HR-database. Følgende skærmbillede viser nogle eksempeldata.
Baseret på employee_information
tabel, laver vi en visning kaldet rls
for et RLS-datasæt. Se følgende SQL-kode:
Følgende skærmbillede viser vores eksempeldata.
Nu har vi tabellen klar, vi kan oprette RLS-datasættet med følgende brugerdefinerede SQL:
Følgende skærmbillede viser vores eksempeldata.
For gruppen quicksight-fed-all-countries
, indstiller vi username
, country
og city
som null, hvilket betyder, at alle brugere i denne gruppe kan se data for alle lande.
For landeniveau er det kun sikkerhedsreglerne, der er defineret i groupname
og land columns
bruges til filtrering. Det username
, city
kolonner er sat som null. Brugerne i quicksight-fed-usa
gruppe kan se data fra USA og brugerne i quicksight-fed-gbr
gruppe kan se data fra GBR.
For hver bruger med groupname
indstillet som null, kan de kun se det specifikke land og by, der er tildelt deres brugernavn. For eksempel, TerryRigaud
kan kun se data fra Austin i USA.
I QuickSight kombineres flere regler i et RLS-datasæt sammen med OR.
Med disse mangefacetterede RLS-regler kan vi definere et omfattende dataadgangsmønster.
Ryd op
For at undgå fremtidige gebyrer skal du slette de ressourcer, du har oprettet ved at køre følgende kommando:
Konklusion
Dette indlæg diskuterede, hvordan BI-administratorer kan designe og automatisere QuickSight-godkendelse og granulær adgangskontrol. Vi kombinerede QuickSight-sikkerhedsfunktioner som sikkerhed på række- og kolonneniveau, grupper og navneområder for at give en omfattende løsning. Håndtering af disse ændringer gennem "BIOps" sikrer en robust, skalerbar mekanisme til styring af QuickSight-sikkerhed. For at lære mere, tilmeld dig en QuickSight-demo.
Om forfatterne
Ying Wang er en Senior Data Visualization Engineer med Data & Analytics Global Specialty Practice i AWS Professional Services.
Amir Bar Or er Principal Data Architect hos AWS Professional Services. Efter 20 år at have ledet softwareorganisationer og udviklet dataanalyseplatforme og -produkter, deler han nu sin erfaring med store virksomhedskunder og hjælper dem med at skalere deres dataanalyse i skyen.
- "
- &
- 100
- adgang
- adgangsstyring
- Konto
- aktiviteter
- Ad
- Yderligere
- admin
- Alle
- Amazon
- analyse
- analytics
- API'er
- Anvendelse
- applikationer
- arkitektur
- aktiv
- Aktiver
- austin
- Godkendelse
- tilladelse
- Automation
- AWS
- AWS Lambda
- BEDSTE
- bedste praksis
- grænse
- bygge
- Bygning
- virksomhed
- business intelligence
- ringe
- tilfælde
- lave om
- afgifter
- By
- klassificering
- Cloud
- kode
- Fælles
- selskab
- indhold
- lande
- Oprettelse af
- Kunder
- instrumentbræt
- data
- dataadgang
- Dataanalyse
- datastyring
- datavisualisering
- Database
- databaser
- Efterspørgsel
- Design
- ødelægge
- detail
- udviklere
- Udvikling
- DevOps
- Domæner
- ingeniør
- Enterprise
- virksomhedskunder
- begivenhed
- begivenheder
- udøvende
- eksport
- Funktionalitet
- Filtre
- Fornavn
- første gang
- passer
- Framework
- funktion
- fremtiden
- Global
- tilskud
- gruppe
- Hvordan
- hr
- HTTPS
- Hundreder
- IAM
- Identity
- Herunder
- Indkomst
- Forøg
- oplysninger
- Infrastruktur
- integration
- Intelligens
- IT
- Job
- deltage
- Nøgle
- viden
- destinationsside
- stor
- ldap
- førende
- LÆR
- Niveau
- Bibliotek
- Limited
- Line (linje)
- Liste
- placering
- Lang
- ledelse
- Medlemmer
- navne
- numre
- ordrer
- Andet
- Andre
- ejer
- Nulstilling/ændring af adgangskoder
- Mønster
- PIO
- Platforme
- politik
- Main
- Produkt
- Produkter
- projekt
- projekter
- offentlige
- Python
- Læser
- læsere
- optegnelser
- reducere
- Registrering
- Relationer
- Rapporter
- Krav
- Ressourcer
- Resultater
- gennemgå
- Risiko
- regler
- Kør
- kører
- salg
- Scale
- sikkerhed
- Selvbetjening
- Tjenester
- sæt
- Del
- Aktier
- Shell
- Simpelt
- So
- Social
- Software
- SQL
- opbevaring
- butik
- support
- Understøtter
- Systemer
- tid
- Uk
- union
- Opdatering
- opdateringer
- us
- USA
- brugere
- Specifikation
- visualisering
- ugentlig
- Hjul
- WHO
- inden for
- workflow
- år