Et stort business intelligence (BI)-prosjekt med mange brukere og team og sensitiv informasjon krever en mangefasettert sikkerhetsarkitektur. Slik arkitektur bør gi BI-administratorer og -arkitekter muligheten til å minimere mengden informasjon som er tilgjengelig for brukere. For en grei løsning å administrere Amazon QuickSight bruker- og ressurstilgangstillatelser, kan du bruke AWS kommandolinjegrensesnitt (AWS CLI) eller AWS-administrasjonskonsoll for å manuelt redigere QuickSight-brukerrolle og dashbordtilgang. Men i spesifikke tilfeller kan en bedrift lett ha hundrevis eller tusenvis av brukere og grupper, og disse tilgangsadministrasjonsmetodene er ikke effektive. Vi har mottatt et stort antall forespørsler om å tilby en avansert programmerbar tilnærming for å distribuere og administrere en sentralisert QuickSight-sikkerhetsarkitektur.
Dette innlegget beskriver de beste fremgangsmåtene for QuickSight-autentisering og godkjenning granulær tilgangskontroll, og gir en sentralisert skyapplikasjon med en AWS skyutviklingssett (AWS CDK) stabel for nedlasting. En av fordelene med løsningen vår er at bedrifter kan distribuere sikkerhetsrammeverket for å administrere tilgangskontroll av BI uten å forlate AWS.
Alle konfigurasjoner lagres i AWS Systems Manager Parameter Store. Parameter Store gir sikker, hierarkisk lagring for administrasjon av konfigurasjonsdata og hemmelighetsbehandling. Du kan lagre data som brukernavn, brukertillatelser, passord og databasestrenger som parameterverdier. Du kan referere AWS systemansvarlig parametere i skriptene og arbeidsflytene for konfigurasjon og automatisering ved å bruke det unike navnet du spesifiserte da du opprettet parameteren.
AWS CDK-applikasjonsmalen passer inn i infrastrukturen for kontinuerlig integrasjon og kontinuerlig distribusjon (CI/CD) og gir eller tilbakekaller alle autentiseringer og autorisasjoner basert på en definert policy foreskrevet av AWS. Dette unngår mulige menneskelige feil gjort av BI-utviklere eller -administratorer. BI-utviklere kan redigere konfigurasjonsparametere for å gi ut nye dashboards til sluttbrukere. Samtidig kan BI-administratorer redigere et annet sett med parametere for å administrere brukere eller grupper. Denne AWS CDK CI/CD-designen bygger bro mellom utviklings- og driftsaktiviteter ved å håndheve automatisering i bygging og distribusjon av BI-applikasjoner.
Sikkerhetskrav
I enterprise BI-applikasjonsdesign er multi-tenancy en vanlig brukssak, som betjener flere sett med brukere med én infrastruktur. Leietakere kan enten være forskjellige kunder til en uavhengig programvareleverandør (ISV), eller forskjellige avdelinger i en bedrift. I en multi-tenancy-design deler hver leietaker dashboards, analyser og andre QuickSight-ressurser. Hver bruker, som kan se alle andre brukere som tilhører samme leietaker (for eksempel når de deler innhold), forblir usynlige for andre leietakere. Innenfor hver leietaker må BI-administrasjonsteamet opprette forskjellige brukergrupper for å kontrollere dataautorisasjonen, inkludert tilgangstillatelser og datatilgang på granulært nivå.
La oss diskutere noen brukstilfeller av tilgangstillatelser for eiendeler i detalj. I en BI-applikasjon er forskjellige eiendeler vanligvis kategorisert i henhold til forretningsdomener (for eksempel et operasjonelt dashbord eller executive summary dashboard) og dataklassifisering (kritisk, svært konfidensiell, kun internt og offentlig). Du kan for eksempel ha to dashbord for å analysere salgsresultatdata. Utseendet og følelsen til begge dashbordene er like, men sikkerhetsklassifiseringen av dataene er forskjellig. Ett dashbord, kalt Sales Critical Dashboard, inneholder kritiske kolonner og rader med data. Det andre dashbordet, kalt Sales High-Confidential Dashboard, inneholder svært konfidensielle kolonner og rader med data. Noen brukere får tillatelse til å se begge dashbordene, og andre har tillatelse på lavere sikkerhetsnivå og kan bare få tilgang til Sales Highly Confidential Dashboard.
I følgende brukstilfelle adresserer vi datatilgang på granulært nivå som følger:
- Tilgang på radnivå (RLS) – For brukerne som har tilgang til Sales Critical Dashboard, kan noen av dem bare se amerikanske data. Noen globale brukere kan imidlertid se data fra alle land, inkludert USA og Storbritannia.
- Tilgang på kolonnenivå (CLS) – Noen brukere kan bare se ikke-personlig identifiserbar informasjon (PII) datakolonner i et datasett, mens HR-teamet kan se alle kolonnene i samme datasett.
Store prosjekter kan ha flere leietakere, hundrevis av grupper og tusenvis av brukere i én QuickSight-konto. Datalederteamet ønsker å distribuere én protokoll for brukeroppretting og autentisering for å redusere vedlikeholdskostnadene og sikkerhetsrisikoen. Arkitekturen og arbeidsflyten beskrevet i dette innlegget hjelper datalederen med å nå dette målet.
I tillegg, for å unngå menneskelige feil i daglig drift, ønsker vi at disse sikkerhetstillatelsene skal gis og tilbakekalles automatisk, og passe inn i CI/CD-infrastrukturen. Detaljene er forklart senere i dette innlegget.
Arkitekturoversikt
Følgende diagram viser QuickSight-kontoarkitekturen til denne løsningen.
- Forfattere oppretter dashbord og oppdaterer AWS Systems Manager Parameter Store for å frigi dashboard til forskjellige grupper
- Administratorer godkjenner forespørslene fra forfattere
- Administratorer oppdaterer brukeradministrasjon (roller, navneområde) ved å redigere AWS Systems ManagerParameter Store
- DevOps distribuerer oppdateringene med AWS CDK
*Grupper: Tillatelsesgrupper for objekttilgang kontrollerer eieren/betrakteren av objektene. Datasegmentgrupper kombinert med RLS/CLS kontrollerer datatilgang.
*Datasett: Inneholder alle data, begrenset av sikkerhet på radnivå (RLS) og sikkerhet på kolonnenivå (CLS)
Følgende diagram illustrerer autentiseringsarbeidsflyten til arkitekturen:
*Førstegangslogg på QuickSight: Hvis QuickSight-brukeren ikke er registrert før første gangs pålogging, opprettes en leser og kun denne leseren kan se dashbordet for landingssiden, som deler med alle brukere av denne kontoen. Landingssiden inneholder rapportlisten som denne brukeren kan se.
Følgende diagram illustrerer godkjenningsarbeidsflyten til arkitekturen.
Autorisasjonsdiagramdetaljer:
- Brukerinformasjon (avdeling, team, geografisk plassering) lagres i Amazon Redshift, Amazon Athena eller en hvilken som helst annen database. Kombinert med gruppe-bruker kartlegging, er RLS databaser bygget for kontroll datatilgang.
- Tildeling av tillatelser per time:
- I henhold til gruppe-ansatt navn (bruker) mapping (membership.csv) og gruppe-rolle mapping (/qs/console/rolles), oppretter en AWS Lambda-funksjon grupper, registrerer, brukere, tildeler gruppemedlemmer, fjerner gruppemedlemskap, promoterer lesere til forfatter eller admin, og sletter brukere hvis de blir degradert fra forfatter eller admin til leser.
- I følge gruppe-dashboard-kartlegging i /qs/config/access, oppdaterer en AWS Lambda-funksjon dashbordtillatelser til QuickSight-grupper.
- I henhold til gruppenavneområdetilordning i membership.csv, oppretter en AWS Lambda-funksjon QuickSight-grupper i det angitte navneområdet.
- Eksempelparametere for tilgangstillatelser for objekter og datasegmenter:
- Eksempelparametere for QuickSight-brukerrollen:
- Eksempeldata for medlemskap.csv:
I denne løsningen er tilpassede navneområder distribuert for å støtte multi-tenancy. De default
navneområde er for alle interne brukere i et selskap (vi kaller det OkTank). OkTank oppretter 3rd-Party
navneområde for eksterne brukere. Hvis vi må støtte flere leietakere, kan vi lage flere tilpassede navneområder. Som standard er vi begrenset til 100 navneområder per AWS-konto. For å øke denne grensen, kontakt QuickSight-produktteamet. For mer informasjon om flerleieforhold, se Legge til analyse av flere leietakere i applikasjoner med Amazon QuickSight.
I hvert navneområde lager vi forskjellige typer grupper. For eksempel i default
navneområde oppretter vi BI-Admin
og BI-Developer
grupper for admin
og author
brukere. Til reader
, distribuerer vi to typer QuickSight-grupper for å kontrollere tilgangstillatelser og datatilgang: objekttilgangstillatelsesgrupper og datasegmentgrupper.
Følgende tabell oppsummerer hvordan tillatelsesgrupper for objekttilgang kontrollerer tillatelser.
Gruppenavn | namespace | Tillatelse | Merknader |
critical |
Misligholde | Se begge dashbordene (som inneholder kritiske data og svært konfidensielle data) | |
highlyconfidential |
Misligholde | Vis kun salgsoversikt med høy konfidensialitet | |
BI-Admin |
Misligholde | Kontoadministrasjon og rediger alle eiendeler | Brukere i BI-Admin gruppen er tildelt Admin QuickSight brukerrolle. |
BI-Developer |
Misligholde | Rediger alle eiendeler | Brukere i BI-Developer gruppe blir tildelt forfatter QuickSight-brukerrollen. |
Power-reader |
Misligholde | Se alle eiendeler og lag ad hoc-analyser for å kjøre selvbetjente analyserapporter |
Brukere i Denne gruppen kan imidlertid ikke lagre eller dele ad hoc-rapportene sine. |
3rd-party |
Ikke-standard navnerom (3rd-party navneområde, for eksempel) |
Kan bare dele med lesere (3rd-party-reader gruppe, for eksempel) i samme navneområde |
I navneområder som ikke er standard, kan vi også opprette andre tillatelsesgrupper for objekttilgang, som ligner på den kritiske gruppen i standardnavneområdet. |
For mer informasjon om QuickSight-grupper, brukere og brukerroller, se Administrere brukertilgang i Amazon QuickSight, Klargjøring av brukere for Amazon QuickSightog Bruke administrative dashboards for en sentralisert visning av Amazon QuickSight-objekter.
Den andre typen grupper (datasegmentgrupper), kombinert med sikkerhet på radnivå datasett og sikkerhet på kolonnenivå, kontroller datatilgang som beskrevet i følgende tabell.
Gruppenavn | namespace | Tillatelse | Omfang |
USA |
Misligholde | Se kun amerikanske data på ethvert dashbord | Radnivå |
GBR |
Misligholde | Se kun britiske data på ethvert dashbord | Radnivå |
All countries |
Misligholde | Se data for alle land på ethvert instrumentbord | Radnivå |
non-PII |
Misligholde | Kan ikke se personnummer, årsinntekt og alle andre kolonner med PII-data | Kolonnenivå |
PII |
Misligholde | Kan se alle kolonner inkludert PII-data | Kolonnenivå |
Vi kan sette opp lignende grupper i ikke-standard navnerom.
Disse ulike gruppene kan overlappe hverandre. For eksempel hvis en bruker tilhører gruppene USA
, Critical
og PII
, kan de se amerikanske data på begge dashbordene, med alle kolonnene. Følgende Venn-diagram illustrerer sammenhengene mellom disse gruppene.
Oppsummert kan vi definere en flerfasettert sikkerhetsarkitektur ved å kombinere QuickSight-funksjoner, inkludert navneområde, gruppe, bruker, RLS og CLS. Alle relaterte konfigurasjoner lagres i parameterlageret. QuickSight-brukerlisten og informasjon om gruppebrukerkartlegging er i en Amazon enkel lagringstjeneste (Amazon S3) bøtte som en CSV-fil (navngitt membership.csv
). Denne CSV-filen kan være utdataresultater av LDAP-spørringer. Flere AWS Lambda funksjoner er planlagt til å kjøre hver time (du kan også aktivere disse funksjonene på forespørsel, for eksempel daglig, ukentlig eller når som helst granularitet som passer dine behov) for å lese parameterne og membership.csv
. I henhold til konfigurasjonen som er definert, oppretter, oppdaterer eller sletter Lambda-funksjonene grupper, brukere og tilgangstillatelser.
Når de nødvendige sikkerhetskonfigurasjonene er fullført, kaller en Lambda-funksjon opp QuickSight API-ene for å få oppdatert informasjon og registrere resultatene i en S3-bøtte som CSV-filer. BI-administratorteamet kan bygge datasett med disse filene og visualisere resultatene med dashboards. For mer informasjon, se Bruke administrative dashboards for en sentralisert visning av Amazon QuickSight-objekter og Bygge en administrativ konsoll i Amazon QuickSight for å analysere bruksberegninger.
I tillegg lagres feilene i Lambda-funksjonene og brukerslettingshendelsene i denne S3-bøtten slik at administratorteamet kan se gjennom dem.
Automatisering
Følgende diagram illustrerer den generelle arbeidsflyten til Lambda-funksjonene.
Vi bruker en programmerbar metode for å opprette og konfigurere gruppene og brukerne automatisk. For enhver ad hoc brukerregistreringsforespørsel (som brukeren ikke er registrert i membership.csv
men på grunn av latens), så lenge brukeren kan autentiseres, kan de anta AWS identitets- og tilgangsadministrasjon (IAM) rolle quicksight-fed-user
til selvforsyning som QuickSight-leser. Denne selvtilrettelagte leseren kan bare se et dashbord for destinasjonssider, som gir listen over dashbord og tilsvarende grupper. I henhold til kartleggingen av dashboard-gruppe, kan denne nye leseren søke om medlemskap i en gitt gruppe for å få tilgang til dashboardene. Hvis gruppeeieren godkjenner applikasjonen, legger de timebaserte Lambda-funksjonene til den nye brukeren i gruppen neste gang de kjører.
CI/CD-rørledningen starter fra AWS CDK. BI-administratoren og forfatteren kan oppdatere Systems Manager-parametrene for å frigi nye dashbord eller andre QuickSight-ressurser i AWS CDK-stakken granular_access_stack.py
. BI-administratoren kan oppdatere Systems Manager-parameterne i samme stabel for å opprette, oppdatere eller slette navnerom, grupper eller brukere. Deretter kan DevOps-teamet distribuere den oppdaterte AWS CDK-stakken for å bruke disse endringene på Systems Manager-parametrene eller andre AWS-ressurser. Lambda-funksjonene utløses hver time for å kalle APIer for å bruke endringer på den relaterte QuickSight-kontoen.
Skala
Lambda-funksjonene er begrenset av maksimal kjøretid på 15 minutter. For å overvinne denne begrensningen kan vi konvertere Lambda-funksjonene til AWS Lim Python-skallskript med følgende trinn på høyt nivå:
- Last ned Boto3 hjulfiler fra pypi.org.
- Last opp hjulfilen til en S3-bøtte.
- Last ned Lambda fungerer og slå dem sammen til ett Python-skript og lag et AWS Glue Python-skallskript.
- Legg til S3-banen til Boto3-hjulfilen i Python-bibliotekbanen. Hvis du har flere filer å legge til, skiller du dem med et komma.
- Planlegg denne AWS-limjobben til å kjøre daglig.
For mer informasjon, se Programmer AWS Glue ETL-skript i Python og Bruke Python-biblioteker med AWS-lim.
Forutsetninger
Du må ha følgende forutsetninger for å implementere denne løsningen:
- En QuickSight Enterprise-konto
- Grunnleggende kunnskap om Python
- Grunnleggende kunnskap om SQL
- Grunnleggende kunnskap om BI
Lag ressursene
Lag ressursene dine ved å laste ned AWS CDK-stakken fra GitHub repo.
på granular_access
mappen, kjør kommandoen cdk deploy granular-access
å sette inn ressursene. For mer informasjon, se AWS CDK Intro Workshop: Python Workshop.
Distribuere løsningen
Når du distribuerer AWS CDK-stakken, oppretter den fem Lambda-funksjoner, som vist i følgende skjermbilde.
Stakken skaper også ekstra støtteressurser på kontoen din.
De granular_user_governance
funksjonen utløses av Amazon CloudWatch hendelsesregel qs-gc-everyhour
. Informasjonen til grupper og brukere er definert i filen membership.csv
. S3-bøttenavnet er lagret i parameterlageret /qs/config/groups
. Følgende diagram viser flytskjemaet for denne funksjonen.
- Angi destinasjonen for
granular_user_governance
til en annen Lambda-funksjon,downgrade_user
medsource=Asynchronous invocation
ogcondition=On Success
.
Følgende diagram er et flytskjema for denne funksjonen.
For å unngå å bryte kritisk tilgang til QuickSight-ressurser styrt av administrator eller forfatter, degraderer vi en administrator eller forfatter ved å slette administrator- eller forfatterbrukeren og opprette en ny leserbruker med Lambda-funksjonen downgrade_user
. De granular_user_governance
funksjonen håndterer nedgradering av admin til forfatter, eller oppgradering av forfatter til admin.
- Angi destinasjonen for
downgrade_user
til Lambda-funksjonengranular_access_assets_govenance
medsource=Asynchronous invocation
ogcondition=On Success
.
Følgende diagram viser et flytskjema for denne funksjonen.
- Angi destinasjonen for
downgrade_user
til Lambda-funksjonencheck_team_members
medsource=Asynchronous invocation
ogcondition=On Failure
.
De check_team_members
funksjonen kaller ganske enkelt QuickSight APIer for å få navneområder, grupper, brukere og aktivainformasjon, og lagrer resultatene i S3-bøtten. S3-nøkkelen er monitoring/quicksight/group_membership/group_membership.csv
og monitoring/quicksight/object_access/object_access.csv
.
Foruten de to utdatafilene fra forrige trinn, feilloggene og brukerslettingsloggene (logger av downgrade_user
) er også lagret i monitoring/quicksight
mappe.
- Angi destinasjonen for
granular_access_assets_govenance
til Lambda-funksjonencheck_team_members
medsource=Asynchronous invocation
ogcondition=On Success
orcondition=On Failure
.
Opprett sikkerhetsdatasett på radnivå
Som et siste trinn lager vi RLS-datasett. Dette lar deg endre dashbordpostene basert på brukerne som ser dashbordene.
QuickSight støtter RLS ved å bruke et systemadministrert datasett som undervelger poster fra dashborddatasettet. Mekanismen lar administratoren gi et filtreringsdatasett (RLS-datasettet) med username
or groupname
kolonner, som automatisk filtreres til brukeren som er pålogget. For eksempel en bruker som heter YingWang
tilhører QuickSight-gruppen BI
, så alle radene i RLS-datasettet som tilsvarer brukernavnet YingWang
eller gruppenavn BI
er filtrert. Radene som forblir i RLS etter bruk av brukernavnet og gruppenavnfiltrene, brukes deretter til å filtrere dashborddatasettene videre ved å matche kolonner med de samme navnene. For mer informasjon om sikkerhet på radnivå, se Bruk sikkerhet på radnivå (RLS) for å begrense tilgangen til et datasett.
I denne løsningen eksporterer vi eksempelbrukerinformasjonen til filen membership.csv
, som oppbevares i en S3 bøtte. I denne filen gir vi noen eksempelgrupper for RLS-datasettdefinisjon. Disse gruppene er datasegmentgruppene, som beskrevet i den overordnede arkitekturdesignen. Følgende skjermbilde viser noen av gruppene og brukerne i disse gruppene.
De granular_user_governance
funksjonen oppretter disse gruppene og legger til de relaterte brukerne til å være medlemmer av disse gruppene.
Hvordan lager vi RLS-datasettet? La oss si at vi har et bord som heter employee_information
i vår organisasjons HR-database. Følgende skjermbilde viser noen eksempeldata.
Basert på employee_information
tabell, lager vi en visning kalt rls
for et RLS-datasett. Se følgende SQL-kode:
Følgende skjermbilde viser våre eksempeldata.
Nå har vi tabellen klar, vi kan lage RLS-datasettet med følgende egendefinerte SQL:
Følgende skjermbilde viser våre eksempeldata.
For gruppen quicksight-fed-all-countries
, setter vi username
, country
og city
som null, noe som betyr at alle brukerne i denne gruppen kan se dataene for alle land.
For landnivå er det kun sikkerhetsreglene som er definert i groupname
og land columns
brukes til filtrering. De username
og city
kolonner er satt som null. Brukerne i quicksight-fed-usa
gruppen kan se dataene til USA, og brukerne i quicksight-fed-gbr
gruppe kan se dataene til GBR.
For hver bruker med groupname
satt som null, kan de bare se det spesifikke landet og byen som er tildelt brukernavnet deres. For eksempel, TerryRigaud
kan bare se data fra Austin, i USA.
I QuickSight kombineres flere regler i et RLS-datasett sammen med OR.
Med disse mangefasetterte RLS-reglene kan vi definere et omfattende datatilgangsmønster.
Rydd opp
For å unngå fremtidige kostnader, slett ressursene du opprettet ved å kjøre følgende kommando:
konklusjonen
Dette innlegget diskuterte hvordan BI-administratorer kan designe og automatisere QuickSight-autentisering og granulær tilgangskontroll. Vi kombinerte QuickSight-sikkerhetsfunksjoner som sikkerhet på rad- og kolonnenivå, grupper og navneområder for å gi en omfattende løsning. Å administrere disse endringene gjennom "BIOps" sikrer en robust, skalerbar mekanisme for å administrere QuickSight-sikkerhet. Å lære mer, registrer deg for en QuickSight-demo.
Om forfatterne
Ying Wang er en senior datavisualiseringsingeniør med Data & Analytics Global Specialty Practice i AWS Professional Services.
Amir Bar Or er hoveddataarkitekt ved AWS Professional Services. Etter 20 år å lede programvareorganisasjoner og utvikle dataanalyseplattformer og -produkter, deler han nå sin erfaring med store bedriftskunder og hjelper dem med å skalere dataanalysene sine i skyen.
- "
- &
- 100
- adgang
- tilgangsstyring
- Logg inn
- Aktiviteter
- Ad
- Ytterligere
- admin
- Alle
- Amazon
- analyse
- analytics
- APIer
- Søknad
- søknader
- arkitektur
- eiendel
- Eiendeler
- austin
- Autentisering
- autorisasjon
- Automatisering
- AWS
- AWS Lambda
- BEST
- beste praksis
- grensen
- bygge
- Bygning
- virksomhet
- business intelligence
- ring
- saker
- endring
- avgifter
- City
- klassifisering
- Cloud
- kode
- Felles
- Selskapet
- innhold
- land
- Opprette
- Kunder
- dashbord
- dato
- data tilgang
- Data Analytics
- Dataledelse
- datavisualisering
- Database
- databaser
- Etterspørsel
- utforming
- ødelegge
- detalj
- utviklere
- Utvikling
- DevOps
- domener
- ingeniør
- Enterprise
- bedriftskunder
- Event
- hendelser
- utøvende
- eksportere
- Egenskaper
- filtre
- Først
- første gang
- passer
- Rammeverk
- funksjon
- framtid
- Global
- tilskudd
- Gruppe
- Hvordan
- hr
- HTTPS
- Hundrevis
- IAM
- Identitet
- Inkludert
- Inntekt
- Øke
- informasjon
- Infrastruktur
- integrering
- Intelligens
- IT
- Jobb
- bli medlem
- nøkkel
- kunnskap
- destinasjonssiden
- stor
- ldap
- ledende
- LÆRE
- Nivå
- Bibliotek
- Begrenset
- linje
- Liste
- plassering
- Lang
- ledelse
- medlemmer
- navn
- tall
- rekkefølge
- Annen
- andre
- eieren
- passord
- Mønster
- PII
- Plattformer
- politikk
- Principal
- Produkt
- Produkter
- prosjekt
- prosjekter
- offentlig
- Python
- Reader
- lesere
- poster
- redusere
- Registrering
- Relasjoner
- Rapporter
- Krav
- Ressurser
- Resultater
- anmeldelse
- Risiko
- regler
- Kjør
- rennende
- salg
- Skala
- sikkerhet
- Selvbetjening
- Tjenester
- sett
- Del
- Aksjer
- Shell
- Enkelt
- So
- selskap
- Software
- SQL
- lagring
- oppbevare
- støtte
- Støtter
- Systemer
- tid
- Uk
- union
- Oppdater
- oppdateringer
- us
- USA
- Brukere
- Se
- visualisering
- ukentlig
- Hjul
- HVEM
- innenfor
- arbeidsflyt
- år