Een groot business intelligence (BI)-project met veel gebruikers en teams en gevoelige informatie vereist een veelzijdige beveiligingsarchitectuur. Een dergelijke architectuur zou BI-beheerders en architecten de mogelijkheid moeten bieden om de hoeveelheid informatie die toegankelijk is voor gebruikers te minimaliseren. Voor een eenvoudige oplossing om te beheren Amazon QuickSight gebruikers- en activatoegangsrechten, kunt u de AWS-opdrachtregelinterface (AWS CLI) of AWS-beheerconsole om de QuickSight-gebruikersrol en dashboardtoegang handmatig te bewerken. In specifieke gevallen kan een onderneming echter gemakkelijk honderden of duizenden gebruikers en groepen hebben, en deze methoden voor toegangsbeheer zijn niet efficiënt. We hebben een groot aantal verzoeken ontvangen om een geavanceerde programmeerbare aanpak te bieden voor het implementeren en beheren van een gecentraliseerde QuickSight-beveiligingsarchitectuur.
Dit bericht beschrijft de best practices voor QuickSight-authenticatie en autorisatie, granulaire toegangscontrole, en biedt een gecentraliseerde cloudapplicatie met een AWS Cloud-ontwikkelingskit (AWS CDK) stapel om te downloaden. Een van de voordelen van onze oplossing is dat ondernemingen het beveiligingsframework kunnen inzetten om de toegangscontrole van hun BI te beheren zonder AWS te verlaten.
Alle configuraties worden opgeslagen in de AWS Systems Manager-parameteropslag. Parameter Store biedt veilige, hiërarchische opslag voor configuratiegegevensbeheer en geheimenbeheer. U kunt gegevens zoals gebruikersnaam, gebruikersrechten, wachtwoorden en databasereeksen opslaan als parameterwaarden. U kunt verwijzen AWS-systeembeheerder parameters in uw scripts en configuratie- en automatiseringsworkflows door de unieke naam te gebruiken die u hebt opgegeven toen u de parameter maakte.
De AWS CDK-applicatiesjabloon past in de infrastructuur voor continue integratie en continue implementatie (CI/CD) en verleent of trekt alle authenticaties en autorisaties in op basis van een gedefinieerd beleid dat is voorgeschreven door AWS. Dit voorkomt mogelijke menselijke fouten gemaakt door BI-ontwikkelaars of -beheerders. BI-ontwikkelaars kunnen configuratieparameters bewerken om nieuwe dashboards vrij te geven aan eindgebruikers. Tegelijkertijd kunnen BI-beheerders een andere set parameters bewerken om gebruikers of groepen te beheren. Dit AWS CDK CI/CD-ontwerp overbrugt de kloof tussen ontwikkelings- en operationele activiteiten door automatisering af te dwingen bij het bouwen en implementeren van BI-applicaties.
Beveiligingsvereisten
Bij het ontwerpen van zakelijke BI-applicaties is multi-tenancy een veelvoorkomend gebruiksscenario, waarbij meerdere sets gebruikers met één infrastructuur worden bediend. Huurders kunnen verschillende klanten zijn van een onafhankelijke softwareleverancier (ISV), of verschillende afdelingen van een onderneming. In een multi-tenancy-ontwerp deelt elke huurder de dashboards, analyses en andere QuickSight-middelen. Elke gebruiker, die alle andere gebruikers van dezelfde tenant kan zien (bijvoorbeeld bij het delen van inhoud), blijft onzichtbaar voor andere tenants. Binnen elke tenant moet het BI-beheerteam verschillende gebruikersgroepen maken om de gegevensautorisatie te controleren, inclusief toegangsmachtigingen voor activa en gegevenstoegang op gedetailleerd niveau.
Laten we enkele gebruiksscenario's van machtigingen voor toegang tot activa in detail bespreken. In een BI-toepassing worden verschillende assets gewoonlijk gecategoriseerd op basis van bedrijfsdomeinen (zoals een operationeel dashboard of een dashboard met samenvattingen) en gegevensclassificatie (kritiek, zeer vertrouwelijk, alleen intern en openbaar). U kunt bijvoorbeeld twee dashboards hebben voor het analyseren van verkoopresultatengegevens. De look en feel van beide dashboards zijn vergelijkbaar, maar de beveiligingsclassificatie van de gegevens is anders. Eén dashboard, genaamd Sales Critical Dashboard, bevat cruciale kolommen en rijen met gegevens. Het andere dashboard, genaamd Sales Very-Confidential Dashboard, bevat zeer vertrouwelijke kolommen en rijen met gegevens. Sommige gebruikers krijgen toestemming om beide dashboards te bekijken, en anderen hebben toestemming op een lager beveiligingsniveau en hebben alleen toegang tot het Sales Zeer Vertrouwelijk Dashboard.
In het volgende gebruiksscenario behandelen we gegevenstoegang op gedetailleerd niveau als volgt:
- Toegang op rijniveau (RLS) – Voor de gebruikers die toegang hebben tot het Sales Critical Dashboard: sommigen kunnen alleen Amerikaanse gegevens bekijken. Sommige wereldwijde gebruikers kunnen echter de gegevens van alle landen bekijken, inclusief de VS en het VK.
- Toegang op kolomniveau (CLS) – Sommige gebruikers kunnen alleen niet-persoonlijk identificeerbare informatie (PII)-gegevenskolommen van een dataset bekijken, terwijl het HR-team alle kolommen van dezelfde dataset kan bekijken.
Grote projecten kunnen meerdere tenants, honderden groepen en duizenden gebruikers in één QuickSight-account hebben. Het dataleidersteam wil één protocol inzetten voor het aanmaken en authenticeren van gebruikers om de onderhoudskosten en het beveiligingsrisico te verminderen. De architectuur en workflow die in dit bericht worden beschreven, helpen de dataleider dit doel te bereiken.
Om menselijke fouten in de dagelijkse bedrijfsvoering te voorkomen, willen we bovendien dat deze beveiligingsmachtigingen automatisch worden verleend en ingetrokken, en dat ze passen in de CI/CD-infrastructuur. De details worden verderop in dit bericht uitgelegd.
Architectuur overzicht
Het volgende diagram toont de QuickSight-accountarchitectuur van deze oplossing.
- Auteurs maken dashboards en updaten de AWS Systems Manager Parameter Store om dashboards vrij te geven aan verschillende groepen
- Beheerders keuren de verzoeken van auteurs goed
- Beheerders updaten het gebruikersbeheer (rollen, naamruimte) door AWS Systems ManagerParameter Store te bewerken
- DevOps implementeert de updates met AWS CDK
*Groepen: Permissiegroepen voor objecttoegang bepalen de eigenaar/viewer van de objecten. Gegevenssegmentgroepen in combinatie met RLS/CLS regelen de gegevenstoegang.
*Gegevenssets: Bevat alle gegevens, beperkt door beveiliging op rijniveau (RLS) en beveiliging op kolomniveau (CLS)
Het volgende diagram illustreert de authenticatieworkflow van de architectuur:
*Eerste keer inloggen op QuickSight: Als de QuickSight-gebruiker niet is geregistreerd voordat hij voor de eerste keer inlogt, wordt er een lezer aangemaakt en kan deze lezer alleen het dashboard van de landingspagina bekijken, dat wordt gedeeld met alle gebruikers van dit account. De landingspagina bevat de rapportenlijst die deze gebruiker kan bekijken.
Het volgende diagram illustreert de autorisatieworkflow van de architectuur.
Details van het autorisatiediagram:
- Gebruikersinformatie (afdeling, team, geografische locatie) wordt opgeslagen in Amazon Redshift, Amazon Athena of een andere database. Gecombineerd met het in kaart brengen van groepen en gebruikers, worden RLS-databases gebouwd voor toegang tot controlegegevens.
- Toewijzing van rechten per uur:
- Volgens de toewijzing van de naam van de medewerker (gebruiker) (membership.csv) en toewijzing van groepsrollen (/qs/console/roles), creëert een AWS Lambda-functie groepen, registreert, gebruikers, wijst groepsleden toe, verwijdert groepslidmaatschappen, promoot lezers naar auteur of beheerder, en verwijdert gebruikers als ze worden gedegradeerd van auteur of beheerder naar lezer.
- Volgens de groepsdashboardtoewijzing in /qs/config/access werkt een AWS Lambda-functie de dashboardmachtigingen bij voor QuickSight-groepen.
- Volgens de groepsnaamruimtetoewijzing in lidmaatschap.csv creëert een AWS Lambda-functie QuickSight-groepen in de opgegeven naamruimte.
- Voorbeeldparameters van toegangsrechten voor objecten en gegevenssegmenten:
- Voorbeeldparameters van QuickSight-gebruikersrol:
- Voorbeeldgegevens van lidmaatschap.csv:
In deze oplossing worden aangepaste naamruimten geïmplementeerd ter ondersteuning van multi-tenancy. De default
naamruimte is voor alle interne gebruikers van een bedrijf (we noemen het OkTank). OkTank maakt de 3rd-Party
naamruimte voor externe gebruikers. Als we meer tenants moeten ondersteunen, kunnen we meer aangepaste naamruimten maken. Standaard zijn we beperkt tot 100 naamruimten per AWS-account. Neem contact op met het QuickSight-productteam om deze limiet te verhogen. Zie voor meer informatie over multi-tenancy Integreer multi-tenant analyses in applicaties met Amazon QuickSight.
In elke naamruimte creëren we verschillende soorten groepen. Bijvoorbeeld in de default
naamruimte, we creëren de BI-Admin
en BI-Developer
groepen voor de admin
en author
gebruikers. Voor reader
, implementeren we twee soorten QuickSight-groepen om toegangsrechten voor activa en gegevenstoegang te beheren: machtigingsgroepen voor objecttoegang en groepen voor gegevenssegmenten.
In de volgende tabel wordt samengevat hoe de machtigingsgroepen voor objecttoegang de machtigingen beheren.
Groepsnaam | namespace | Toestemming | Opmerkingen |
critical |
Standaard | Bekijk beide dashboards (met de kritische gegevens en zeer vertrouwelijke gegevens) | |
highlyconfidential |
Standaard | Bekijk alleen het zeer vertrouwelijke verkoopdashboard | |
BI-Admin |
Standaard | Accountbeheer en bewerken van alle activa | gebruikers in de BI-Admin groep krijgt de opdracht Admin QuickSight-gebruikersrol. |
BI-Developer |
Standaard | Bewerk alle items | gebruikers in de BI-Developer groep krijgen de gebruikersrol Auteur QuickSight toegewezen. |
Power-reader |
Standaard | Bekijk alle assets en maak ad-hocanalyses om selfservice-analyserapporten uit te voeren |
gebruikers in de Deze groep kan hun ad-hocrapporten echter niet opslaan of delen. |
3rd-party |
Niet-standaard naamruimten (3rd-party naamruimte, bijvoorbeeld) |
Kan alleen delen met lezers (3rd-party-reader group bijvoorbeeld) in dezelfde naamruimte |
In niet-standaardnaamruimten kunnen we ook andere machtigingsgroepen voor objecttoegang maken, die vergelijkbaar zijn met de kritieke groep in de standaardnaamruimte. |
Zie voor meer informatie over QuickSight-groepen, gebruikers en gebruikersrollen Gebruikerstoegang beheren binnen Amazon QuickSight, Gebruikers inrichten voor Amazon QuickSight en Gebruik van administratieve dashboards voor een gecentraliseerde weergave van Amazon QuickSight-objecten.
Het tweede type groepen (datasegmentgroepen), gecombineerd met beveiliging op rijniveau datasets en beveiliging op kolomniveau, beheert u de gegevenstoegang zoals beschreven in de volgende tabel.
Groepsnaam | namespace | Toestemming | strekking |
USA |
Standaard | Bekijk alleen Amerikaanse gegevens op elk dashboard | Rijniveau |
GBR |
Standaard | Bekijk alleen Britse gegevens op elk dashboard | Rijniveau |
All countries |
Standaard | Bekijk gegevens van alle landen op elk dashboard | Rijniveau |
non-PII |
Standaard | Kan burgerservicenummers, jaarinkomen en alle andere kolommen met PII-gegevens niet bekijken | Kolomniveau |
PII |
Standaard | Kan alle kolommen bekijken, inclusief PII-gegevens | Kolomniveau |
We kunnen vergelijkbare groepen instellen in niet-standaardnaamruimten.
Deze verschillende groepen kunnen elkaar overlappen. Bijvoorbeeld als een gebruiker tot de groepen behoort USA
, Critical
en PII
, kunnen ze Amerikaanse gegevens op beide dashboards bekijken, met alle kolommen. Het volgende Venn-diagram illustreert de relaties tussen deze groepen.
Samenvattend kunnen we een veelzijdige beveiligingsarchitectuur definiëren door QuickSight-functies te combineren, waaronder naamruimte, groep, gebruiker, RLS en CLS. Alle gerelateerde configuraties worden opgeslagen in het Parameter Store. De QuickSight-gebruikerslijst en de toewijzingsinformatie voor groepen en gebruikers bevinden zich in een Amazon eenvoudige opslagservice (Amazon S3)-bucket als CSV-bestand (genaamd membership.csv
). Dit CSV-bestand kunnen uitvoerresultaten zijn van LDAP-query's. Meerdere AWS Lambda functies zijn gepland om elk uur te worden uitgevoerd (u kunt deze functies ook op aanvraag aanroepen, zoals dagelijkse, wekelijkse of op elk gewenst moment granulariteit die aan uw vereisten voldoet) om de parameters en de membership.csv
. Afhankelijk van de gedefinieerde configuratie kunnen de Lambda-functies groepen, gebruikers en toegangsmachtigingen voor activa maken, bijwerken of verwijderen.
Wanneer de noodzakelijke beveiligingsconfiguraties zijn voltooid, roept een Lambda-functie de QuickSight API's aan om de bijgewerkte informatie op te halen en de resultaten in een S3-bucket op te nemen als CSV-bestanden. Het BI-beheerteam kan met deze bestanden datasets bouwen en de resultaten visualiseren met dashboards. Voor meer informatie, zie Gebruik van administratieve dashboards voor een gecentraliseerde weergave van Amazon QuickSight-objecten en Een beheerconsole bouwen in Amazon QuickSight om gebruiksstatistieken te analyseren.
Bovendien worden de fouten van Lambda-functies en de gebruikersverwijderingsgebeurtenissen in deze S3-bucket opgeslagen, zodat het beheerdersteam deze kan beoordelen.
Automatisering
Het volgende diagram illustreert de algemene workflow van de Lambda-functies.
We gebruiken een programmeerbare methode om de groepen en gebruikers automatisch aan te maken en te configureren. Voor elk ad-hoc gebruikersregistratieverzoek (zoals de gebruiker niet is geregistreerd in membership.csv
maar vanwege latentie), zolang de gebruiker kan worden geverifieerd, kunnen ze ervan uitgaan dat de AWS Identiteits- en toegangsbeheer (IAM) rol quicksight-fed-user
tot zelfvoorziening als QuickSight-lezer. Deze zelfingerichte lezer kan alleen het dashboard van een landingspagina bekijken, dat de lijst met dashboards en bijbehorende groepen bevat. Volgens de dashboardgroeptoewijzing kan deze nieuwe lezer lidmaatschap van een bepaalde groep aanvragen om toegang te krijgen tot de dashboards. Als de groepseigenaar de applicatie goedkeurt, voegen de Lambda-functies op uurbasis de nieuwe gebruiker toe aan de groep de volgende keer dat ze worden uitgevoerd.
De CI/CD-pijplijn begint bij AWS CDK. De BI-beheerder en auteur kunnen de Systems Manager-parameters bijwerken om nieuwe dashboards of andere QuickSight-middelen vrij te geven in de AWS CDK-stack granular_access_stack.py
. De BI-beheerder kan de Systems Manager-parameters in dezelfde stapel bijwerken om naamruimten, groepen of gebruikers te maken, bij te werken of te verwijderen. Vervolgens kan het DevOps-team de bijgewerkte AWS CDK-stack implementeren om deze wijzigingen toe te passen op de Systems Manager-parameters of andere AWS-bronnen. De Lambda-functies worden elk uur geactiveerd om API's aan te roepen om wijzigingen toe te passen op het gerelateerde QuickSight-account.
Scale
De Lambda-functies zijn beperkt door de maximale looptijd van 15 minuten. Om deze beperking te omzeilen, kunnen we de Lambda-functies omzetten naar AWS lijm Python-shellscripts met de volgende stappen op hoog niveau:
- Downloaden Boto3 wielbestanden van pypi.org.
- Upload het wielbestand naar een S3-bucket.
- Download de Lambda-functies en voeg ze samen tot één Python-script en maak een AWS Glue Python-shellscript.
- Voeg het S3-pad van het Boto3-wielbestand toe aan het Python-bibliotheekpad. Als u meerdere bestanden wilt toevoegen, scheidt u deze met een komma.
- Plan dat deze AWS Glue-taak dagelijks wordt uitgevoerd.
Voor meer informatie, zie Programmeer AWS Glue ETL-scripts in Python en Python-bibliotheken gebruiken met AWS Glue.
Voorwaarden
U moet aan de volgende vereisten voldoen om deze oplossing te implementeren:
- Een QuickSight Enterprise-account
- Basiskennis van Python
- Basiskennis van SQL
- Basiskennis van BI
Maak de bronnen
Creëer uw bronnen door de AWS CDK-stack te downloaden van de GitHub repo.
In het granular_access
map, voer de opdracht uit cdk deploy granular-access
om de middelen in te zetten. Voor meer informatie, zie AWS CDK-introductieworkshop: Python-workshop.
Implementeer de oplossing
Wanneer u de AWS CDK-stack implementeert, worden er vijf Lambda-functies aangemaakt, zoals weergegeven in de volgende schermafbeelding.
De stapel creëert ook extra ondersteunende bronnen in uw account.
De granular_user_governance
functie wordt geactiveerd door de Amazon Cloud Watch gebeurtenis regel qs-gc-everyhour
. De informatie van groepen en gebruikers wordt gedefinieerd in het bestand membership.csv
. De S3-bucketnaam wordt opgeslagen in het parameterarchief /qs/config/groups
. Het volgende diagram toont het stroomdiagram van deze functie.
- Stel de bestemming in van
granular_user_governance
naar een andere Lambda-functie,downgrade_user
metsource=Asynchronous invocation
encondition=On Success
.
Het volgende diagram is een stroomdiagram van deze functie.
Om te voorkomen dat kritieke toegang wordt verbroken tot QuickSight-middelen die worden beheerd door de beheerder of auteur, degraderen we een beheerder of auteur door de beheerder of auteur te verwijderen en een nieuwe lezergebruiker te maken met de Lambda-functie downgrade_user
. De granular_user_governance
functie zorgt voor het downgraden van beheerder naar auteur, of het upgraden van auteur naar beheerder.
- Stel de bestemming in van
downgrade_user
naar de Lambda-functiegranular_access_assets_govenance
Metsource=Asynchronous invocation
encondition=On Success
.
Het volgende diagram toont een stroomdiagram van deze functie.
- Stel de bestemming in van
downgrade_user
naar de Lambda-functiecheck_team_members
Metsource=Asynchronous invocation
encondition=On Failure
.
De check_team_members
functie roept eenvoudigweg QuickSight API's aan om de naamruimten, groepen, gebruikers en activa-informatie op te halen, en slaat de resultaten op in de S3-bucket. De S3-sleutel is monitoring/quicksight/group_membership/group_membership.csv
en monitoring/quicksight/object_access/object_access.csv
.
Naast de twee uitvoerbestanden van de vorige stap, zijn de foutlogboeken en logbestanden voor gebruikersverwijdering (logboeken van downgrade_user
) worden ook opgeslagen in de monitoring/quicksight
map.
- Stel de bestemming in van
granular_access_assets_govenance
naar de Lambda-functiecheck_team_members
Metsource=Asynchronous invocation
encondition=On Success
orcondition=On Failure
.
Maak beveiligingsgegevenssets op rijniveau
Als laatste stap creëren we RLS-datasets. Hierdoor kunt u de dashboardrecords wijzigen op basis van de gebruikers die de dashboards bekijken.
QuickSight ondersteunt RLS door een door het systeem beheerde dataset toe te passen die records uit de dashboarddataset subselecteert. Met dit mechanisme kan de beheerder een filterende dataset (de RLS-dataset) ter beschikking stellen username
or groupname
kolommen, die automatisch worden gefilterd op de gebruiker die is ingelogd. Bijvoorbeeld een gebruiker met de naam YingWang
behoort tot de QuickSight-groep BI
, dus alle rijen van de RLS-gegevensset die overeenkomen met de gebruikersnaam YingWang
of groepsnaam BI
worden gefilterd. De rijen die in de RLS achterblijven na het toepassen van de gebruikersnaam en de groepsnaamfilters worden vervolgens gebruikt om de dashboardgegevenssets verder te filteren door kolommen met dezelfde namen te matchen. Zie voor meer informatie over beveiliging op rijniveau Row-Level Security (RLS) gebruiken om de toegang tot een gegevensset te beperken.
In deze oplossing exporteren we de voorbeeldgebruikersinformatie naar het bestand membership.csv
, die wordt opgeslagen in een S3-emmer. In dit bestand bieden we enkele voorbeeldgroepen voor de definitie van RLS-gegevenssets. Deze groepen zijn de datasegmentgroepen, zoals beschreven in het algemene architectuurontwerp. De volgende schermafbeelding toont enkele van de groepen en de gebruikers in die groepen.
De granular_user_governance
function maakt deze groepen en voegt de gerelateerde gebruikers toe als lid van deze groepen.
Hoe maken we de RLS-dataset? Laten we zeggen dat we een tafel hebben genaamd employee_information
in de HR-database van onze organisatie. De volgende schermafbeelding toont enkele voorbeeldgegevens.
Gebaseerd op de employee_information
tabel, creëren we een weergave genaamd rls
voor een RLS-gegevensset. Zie de volgende SQL-code:
De volgende schermafbeelding toont onze voorbeeldgegevens.
Nu we de tabel gereed hebben, kunnen we de RLS-dataset maken met de volgende aangepaste SQL:
De volgende schermafbeelding toont onze voorbeeldgegevens.
Voor de groep quicksight-fed-all-countries
, wij stellen de username
, country
en city
als null, wat betekent dat alle gebruikers in deze groep de gegevens van alle landen kunnen bekijken.
Op landniveau gelden alleen de beveiligingsregels die zijn gedefinieerd in de groupname
en land columns
worden gebruikt voor filtering. De username
en city
kolommen zijn ingesteld als nul. De gebruikers in de quicksight-fed-usa
groep kan de gegevens van de VS bekijken, en de gebruikers in de quicksight-fed-gbr
groep kan de gegevens van GBR bekijken.
Voor elke gebruiker met groupname
ingesteld als nul, kunnen ze alleen het specifieke land en de stad zien die aan hun gebruikersnaam is toegewezen. Bijvoorbeeld, TerryRigaud
kan alleen gegevens van Austin, in de VS, bekijken.
In QuickSight worden meerdere regels in een RLS-dataset gecombineerd met OR.
Met deze veelzijdige RLS-regels kunnen we een uitgebreid gegevenstoegangspatroon definiëren.
Opruimen
Om toekomstige kosten te voorkomen, verwijdert u de bronnen die u hebt gemaakt door de volgende opdracht uit te voeren:
Conclusie
In dit bericht werd besproken hoe BI-beheerders QuickSight-authenticatie en autorisatie-granulaire toegangscontrole kunnen ontwerpen en automatiseren. We hebben QuickSight-beveiligingsfuncties zoals beveiliging op rij- en kolomniveau, groepen en naamruimten gecombineerd om een alomvattende oplossing te bieden. Het beheren van deze veranderingen via “BIOps” zorgt voor een robuust, schaalbaar mechanisme voor het beheren van QuickSight-beveiliging. Meer leren, meld u aan voor een QuickSight-demo.
Over de auteurs
Ying wang is een Senior Data Visualization Engineer met de Data & Analytics Global Specialty Practice in AWS Professional Services.
Amir Bar Of is een Principal Data Architect bij AWS Professional Services. Na twintig jaar leiding te hebben gegeven aan softwareorganisaties en data-analyseplatforms en -producten te hebben ontwikkeld, deelt hij nu zijn ervaring met grote zakelijke klanten en helpt hij hen hun data-analyses in de cloud op te schalen.
- "
- &
- 100
- toegang
- toegangsbeheer
- Account
- activiteiten
- Ad
- Extra
- beheerder
- Alles
- Amazone
- analyse
- analytics
- APIs
- Aanvraag
- toepassingen
- architectuur
- aanwinst
- Activa
- austin
- authenticatie
- machtiging
- Automatisering
- AWS
- AWS Lambda
- BEST
- 'best practices'
- grens
- bouw
- Gebouw
- bedrijfsdeskundigen
- business intelligence
- Bellen
- gevallen
- verandering
- lasten
- Plaats
- classificatie
- Cloud
- code
- Gemeen
- afstand
- content
- landen
- Wij creëren
- Klanten
- dashboards
- gegevens
- toegang tot data
- gegevens Analytics
- gegevensbeheer
- data visualisatie
- Database
- databanken
- Vraag
- Design
- vernietigen
- detail
- ontwikkelaars
- Ontwikkeling
- DevOps
- domeinen
- ingenieur
- Enterprise
- zakelijke klanten
- Event
- EVENTS
- uitvoerend
- exporteren
- Voordelen
- filters
- Voornaam*
- eerste keer
- geschikt
- Achtergrond
- functie
- toekomst
- Globaal
- subsidies
- Groep
- Hoe
- hr
- HTTPS
- Honderden
- IAM
- Identiteit
- Inclusief
- Inkomen
- Laat uw omzet
- informatie
- Infrastructuur
- integratie
- Intelligentie
- IT
- Jobomschrijving:
- mee
- sleutel
- kennis
- landing page
- Groot
- ldap
- leidend
- LEARN
- Niveau
- Bibliotheek
- Beperkt
- Lijn
- Lijst
- plaats
- lang
- management
- Leden
- namen
- nummers
- bestellen
- Overige
- Overig
- eigenaar
- wachtwoorden
- Patronen
- pii
- platforms
- beleidsmaatregelen
- Principal
- Product
- Producten
- project
- projecten
- publiek
- Python
- Lezer
- lezers
- archief
- verminderen
- Registratie
- Relaties
- Rapporten
- Voorwaarden
- Resources
- Resultaten
- beoordelen
- Risico
- reglement
- lopen
- lopend
- verkoop
- Scale
- veiligheid
- Zelfbediening
- Diensten
- reeks
- Delen
- Aandelen
- Shell
- Eenvoudig
- So
- Social
- Software
- SQL
- mediaopslag
- shop
- ondersteuning
- steunen
- Systems
- niet de tijd of
- Uk
- unie
- bijwerken
- updates
- us
- USA
- gebruikers
- Bekijk
- visualisatie
- per week
- Wiel
- WIE
- binnen
- workflow
- jaar