Technisch document over Power BI-beveiliging

Samenvatting: Power BI is een online softwareservice (SaaS of Software as a Service) van Microsoft waarmee u eenvoudig en snel selfservice Business Intelligence-dashboards, rapporten, semantische modellen (voorheen gegevenssets) en visualisaties kunt maken. Met Power BI kunt u verbinding maken met veel verschillende gegevensbronnen, gegevens uit deze verbindingen combineren en vormgeven en vervolgens rapporten en dashboards maken die met anderen kunnen worden gedeeld.

Schrijvers: Yitzhak Gemarkeerdman, Paddy Osborne, Matt Neely, Tony Bencic, Srinivasan Turuvekere, Cristian Petculescu, Adi Regev, Naveen Sivaraj, Ben Glastein, Evgeny Tshiorny, Arthi Ramasubramanian Iyer, Sid Jayadevan, Ronald Chang, Ori Eduar, Anton Fritz, Idan Sheinberg, Ron Gilad, Sagiv Hadaya, Paul Inbar, Igor Uzhviev, Michael Roth, Microsoft Tarquino, Gennady Pats, Orion Lee, Yury Berezansky, Maya Shenhav, Romit Chattopadhyay, Yariv Maimon, Bogdan Crivat

Technische revisoren: Cristian Petculescu, Amir Netz, Sergei Gundorov

Van toepassing op: Power BI SaaS, Power BI Desktop, Power BI Premium, Power BI Embedded Analytics, Power BI - Mobiel.

Notitie

U kunt dit wit papier opslaan of afdrukken door Afdrukken te selecteren in uw browser en vervolgens Opslaan als PDF te selecteren.

Inleiding

Power BI is een online softwareservice (SaaS of Software as a Service) van Microsoft waarmee u eenvoudig en snel selfservice Business Intelligence-dashboards, rapporten, semantische modellen en visualisaties kunt maken. Met Power BI kunt u verbinding maken met veel verschillende gegevensbronnen, gegevens uit deze verbindingen combineren en vormgeven en vervolgens rapporten en dashboards maken die met anderen kunnen worden gedeeld.

De wereld verandert snel; organisaties doorlopen een versnelde digitale transformatie, en we zien een enorme toename van werken op afstand, een toegenomen vraag van klanten naar onlineservices en meer gebruik van geavanceerde technologieën in operationele en zakelijke besluitvorming. En dit alles wordt mogelijk gemaakt door de cloud.

Naarmate de overgang naar de cloud is veranderd van een stroming naar een overstroming, en met het nieuwe, blootgestelde oppervlak dat eraan wordt geleverd, vragen meer bedrijven hoe veilig zijn mijn gegevens in de cloud? En welke end-to-end-beveiliging is beschikbaar om te voorkomen dat mijn gevoelige gegevens worden gelekt? En voor de BI-platformen die vaak enkele van de meest strategische informatie in de onderneming verwerken, zijn deze vragen dubbel belangrijk.

De decennia oude basisbeginselen van het BI-beveiligingsmodel - beveiliging op object- en rijniveau - hoewel het nog steeds belangrijk is, is het duidelijk niet meer voldoende om het soort beveiliging te bieden dat nodig is in het cloudtijdperk. In plaats daarvan moeten organisaties zoeken naar een cloudeigen, multilaagse, diepgaande beveiligingsoplossing voor hun business intelligence-gegevens.

Power BI is gebouwd om toonaangevende volledige en hermetische beveiliging voor gegevens te bieden. Het product heeft de hoogste beveiligingsclassificaties verdiend die beschikbaar zijn in de branche, en tegenwoordig hebben veel nationale beveiligingsbureaus, financiële instellingen en zorgverleners het toevertrouwen aan hun meest gevoelige informatie.

Het begint allemaal met de basis. Na een zware periode in het begin van de jaren 2000 heeft Microsoft enorme investeringen gedaan om de beveiligingsproblemen aan te pakken en in de volgende decennia een sterke beveiligingsstack gebouwd die zo diep gaat als de kernel van de machine on-chip bios en zich helemaal uitbreidt tot eindgebruikerservaringen. Deze diepe investeringen blijven bestaan, en tegenwoordig zijn meer dan 3500 Microsoft-technici bezig met het bouwen en verbeteren van de beveiligingsstack van Microsoft en proactief het veranderende bedreigingslandschap. Met miljarden computers, biljoenen aanmeldingen en talloze zettabytes aan informatie die is toevertrouwd aan de bescherming van Microsoft, beschikt het bedrijf nu over de meest geavanceerde beveiligingsstack in de tech-industrie en wordt algemeen gezien als de wereldwijde leider in de strijd tegen kwaadwillende actoren.

Power BI bouwt voort op deze sterke basis. Het maakt gebruik van dezelfde beveiligingsstack die Azure het recht heeft verdiend om de meest gevoelige gegevens ter wereld te leveren en te beschermen, en kan worden geïntegreerd met de meest geavanceerde hulpprogramma's voor informatiebeveiliging en naleving van Microsoft 365. Bovendien biedt het beveiliging via beveiligingsmaatregelen met meerdere lagen, wat resulteert in end-to-end-beveiliging die is ontworpen om de unieke uitdagingen van het cloudtijdperk aan te pakken.

Om een end-to-end oplossing te bieden voor het beveiligen van gevoelige assets, moest het productteam uitdagende klantproblemen op meerdere gelijktijdige fronten aanpakken:

• Hoe bepalen we wie verbinding kan maken, waar ze verbinding mee maken en hoe ze verbinding maken?Hoe kunnen we de verbindingen beheren?
• Hoe worden de gegevens opgeslagen?Hoe wordt het versleuteld?Welke besturingselementen heb ik voor mijn gegevens?
• Hoe kan ik mijn gevoelige gegevens beheren en beveiligen?Hoe kan ik ervoor zorgen dat deze gegevens niet buiten de organisatie kunnen lekken?
• Hoe kan ik controleren wie welke bewerkingen uitvoert?Hoe kan ik snel reageren als er verdachte activiteiten op de service zijn?

Dit artikel bevat een uitgebreid antwoord op al deze vragen. Het begint met een overzicht van de servicearchitectuur en legt uit hoe de belangrijkste stromen in het systeem werken. Vervolgens wordt beschreven hoe gebruikers zich verifiëren bij Power BI, hoe gegevensverbindingen tot stand worden gebracht en hoe Power BI gegevens opslaat en verplaatst via de service. In de laatste sectie worden de beveiligingsfuncties besproken waarmee u als servicebeheerder uw meest waardevolle assets kunt beveiligen.

De Power BI-service valt onder de voorwaarden van Microsoft Online Services en de privacyverklaring van Microsoft Enterprise. Voor de locatie van gegevensverwerking raadpleegt u de voorwaarden voor de locatie van gegevensverwerking in de voorwaarden voor Microsoft Online Services en de gegevensbeschermingsinvoegtoepassing. Voor informatie over naleving is het Vertrouwenscentrum van Microsoft de primaire resource voor Power BI. Het Power BI-team werkt hard om klanten de nieuwste innovaties en productiviteit te bieden. Meer informatie over naleving in de Microsoft-nalevingsaanbiedingen.

De Power BI-service volgt de SDL (Security Development Lifecycle), strikte beveiligingsprocedures die ondersteuning bieden voor beveiligingscontrole en nalevingsvereisten. De SDL helpt ontwikkelaars bij het bouwen van veiligere software door het aantal en ernst van beveiligingsproblemen in software te verminderen, terwijl de ontwikkelingskosten worden verlaagd. Meer informatie vindt u op Levenscycluspraktijken voor Microsoft-beveiligingsontwikkeling

Power BI-architectuur

De Power BI-service is gebouwd op Azure, het cloudcomputingplatform van Microsoft. Power BI wordt momenteel geïmplementeerd in veel datacenters over de hele wereld. Er zijn veel actieve implementaties beschikbaar gesteld aan klanten in de regio's die door deze datacenters worden bediend, en een gelijk aantal passieve implementaties die als back-ups fungeren voor elke actieve implementatie.

Web-front-endcluster (WFE)

Het WFE-cluster biedt de browser van de gebruiker de initiële inhoud van de HTML-pagina bij het laden van de site en verwijst naar CDN-inhoud die wordt gebruikt om de site in de browser weer te geven.

Een WFE-cluster bestaat uit een ASP.NET website die wordt uitgevoerd in de Azure-app Service Environment. Wanneer gebruikers verbinding proberen te maken met de Power BI-service, kan de DNS-service van de client communiceren met Azure Traffic Manager om het meest geschikte (meestal dichtstbijzijnde) datacenter te vinden met een Power BI-implementatie. Zie de routeringsmethode voor prestatieverkeer voor Azure Traffic Manager voor meer informatie over dit proces.

Statische resources, zoals *.js, *.css en afbeeldingsbestanden, worden meestal opgeslagen op een CdN (Azure Content Delivery Network) en rechtstreeks door de browser opgehaald. Houd er rekening mee dat soevereine overheidsclusterimplementaties een uitzondering zijn op deze regel. Om nalevingsredenen wordt het CDN weggelaten en wordt in plaats daarvan een WFE-cluster uit een compatibele regio gebruikt voor het hosten van statische inhoud.

Power BI-back-endcluster (BE)

Het back-endcluster is de backbone van alle functionaliteit die beschikbaar is in Power BI. Het bestaat uit verschillende service-eindpunten die worden gebruikt door web-front-end- en API-clients, evenals achtergrondwerkservices, databases, caches en verschillende andere onderdelen.

De back-end is beschikbaar in de meeste Azure-regio's en wordt geïmplementeerd in nieuwe regio's zodra deze beschikbaar komen. Eén Azure-regio host een of meer back-endclusters die onbeperkte horizontale schaalaanpassing van de Power BI-service toestaan zodra de verticale en horizontale schaallimieten van één cluster zijn uitgeput.

Elk back-endcluster is stateful en host alle gegevens van alle tenants die aan dat cluster zijn toegewezen. Een cluster dat de gegevens van een specifieke tenant bevat, wordt het basiscluster van de tenant genoemd. De basisclustergegevens van een geverifieerde gebruiker worden verstrekt door Global Service en gebruikt door de webfront-end om aanvragen naar het basiscluster van de tenant te routeren.

Elk back-endcluster bestaat uit meerdere virtuele machines gecombineerd in meerdere schaalsets die zijn afgestemd op het uitvoeren van specifieke taken, stateful resources zoals SQL-databases, opslagaccounts, servicebussen, caches en andere benodigde cloudonderdelen.

Tenantmetagegevens en -gegevens worden opgeslagen binnen clusterlimieten, met uitzondering van gegevensreplicatie naar een secundair back-endcluster in een gekoppelde Azure-regio in dezelfde Azure-geografie. Het secundaire back-endcluster fungeert als een failovercluster in het geval van regionale storingen en is op elk ander moment passief.

Back-endfunctionaliteit wordt geleverd door microservices die worden uitgevoerd op verschillende machines in het virtuele netwerk van het cluster die niet toegankelijk zijn van buitenaf, met uitzondering van twee onderdelen die toegankelijk zijn via het openbare internet:

• Gateway Service
• Azure API Management

Power BI Premium-infrastructuur

Power BI Premium biedt een service voor abonnees die premium Power BI-functies nodig hebben, zoals geavanceerde AI, distributie naar gebruikers zonder licentie, enzovoort. Wanneer een klant zich registreert voor een Power BI Premium-abonnement, wordt de Premium-capaciteit gemaakt via Azure Resource Manager.

Power BI Premium-capaciteiten worden gehost in back-endclusters die onafhankelijk zijn van de reguliere Power BI-back-end, zie hierboven). Dit biedt betere isolatie, resourcetoewijzing, ondersteuning, beveiligingsisolatie en schaalbaarheid van het Premium-aanbod.

In het volgende diagram ziet u de architectuur van de Power BI Premium-infrastructuur:

De verbinding met de Power BI Premium-infrastructuur kan op veel manieren worden uitgevoerd, afhankelijk van het gebruikersscenario. Power BI Premium-clients kunnen een browser van een gebruiker zijn, een reguliere Power BI-back-end, directe verbindingen via XMLA-clients, ARM-API's, enzovoort.

De Power BI Premium-infrastructuur in een Azure-regio bestaat uit meerdere Power BI Premium-clusters (het minimum is één). De meeste Premium-resources worden ingekapseld in een cluster (bijvoorbeeld compute) en er zijn enkele algemene regionale resources (bijvoorbeeld metagegevensopslag). Premium-infrastructuur biedt twee manieren om horizontale schaalbaarheid in een regio te bereiken: het verhogen van resources binnen clusters en/of het toevoegen van meer clusters op aanvraag (als clusterresources hun limieten naderen).

De backbone van elk cluster zijn rekenresources die worden beheerd door Virtuele-machineschaalsets en Azure Service Fabric. Virtuele-machineschaalsets en Service Fabric zorgen voor een snelle en pijnloze toename van rekenknooppunten naarmate het gebruik groeit en de implementatie, het beheer en de bewaking van Power BI Premium-services en -toepassingen indelen.

Er zijn veel omringende resources die zorgen voor een veilige en betrouwbare infrastructuur: load balancers, virtuele netwerken, netwerkbeveiligingsgroepen, servicebus, opslag, enzovoort. Geheimen, sleutels en certificaten die vereist zijn voor Power BI Premium, worden uitsluitend beheerd door Azure Key Vault . Verificatie wordt uitgevoerd via integratie met Microsoft Entra ID (voorheen bekend als Azure Active Directory).

Elke aanvraag die betrekking heeft op de Power BI Premium-infrastructuur gaat eerst naar front-endknooppunten. Dit zijn de enige knooppunten die beschikbaar zijn voor externe verbindingen. De rest van de resources wordt verborgen achter virtuele netwerken. De front-endknooppunten verifiëren de aanvraag, verwerken of doorsturen naar de juiste resources (bijvoorbeeld back-endknooppunten).

Back-endknooppunten bieden de meeste mogelijkheden en functies van Power BI Premium.

Power BI Mobile

Power BI - Mobiel is een verzameling apps die zijn ontworpen voor de drie primaire mobiele platforms: Android, iOS en Windows (UWP). Beveiligingsoverwegingen voor de Power BI - Mobiel-apps vallen in twee categorieën:

• Apparaatcommunicatie
• De toepassing en gegevens op het apparaat

Voor apparaatcommunicatie communiceren alle Power BI - Mobiel toepassingen met de Power BI-service en gebruiken ze dezelfde verbindings- en verificatiereeksen die worden gebruikt door browsers, die eerder in dit witboek gedetailleerd worden beschreven. Met de mobiele Power BI-toepassingen voor iOS en Android wordt een browsersessie in de toepassing zelf geopend, terwijl de mobiele Windows-app een broker beschikbaar stelt om het communicatiekanaal met Power BI tot stand te brengen (voor het aanmeldingsproces).

In de volgende tabel ziet u CBA-ondersteuning (Certificate Based Authentication) voor Power BI - Mobiel, op basis van het platform voor mobiele apparaten:

CBA-ondersteuning	iOS	Android	Windows
Power BI (aanmelden bij service)	Ondersteund	Ondersteund	Niet ondersteund
SSRS ADFS on-premises (verbinding maken met SSRS-server)	Niet ondersteund	Ondersteund	Niet ondersteund
SSRS App-proxy	Ondersteund	Ondersteund	Niet ondersteund

Power BI - Mobiel apps communiceren actief met de Power BI-service. Telemetrie wordt gebruikt voor het verzamelen van gebruiksstatistieken van mobiele apps en soortgelijke gegevens, die worden verzonden naar services die worden gebruikt om het gebruik en de activiteit te bewaken; er worden geen klantgegevens verzonden met telemetrie.

In de Power BI-toepassing worden gegevens opgeslagen op het apparaat waarmee het gebruik van de app wordt vereenvoudigd:

• Microsoft Entra ID- en vernieuwingstokens worden opgeslagen in een beveiligd mechanisme op het apparaat, met behulp van standaardbeveiligingsmaatregelen.
• Gegevens en instellingen (sleutel-waardeparen voor gebruikersconfiguratie) worden in de cache opgeslagen op het apparaat en kunnen worden versleuteld door het besturingssysteem. In iOS wordt dit automatisch gedaan wanneer de gebruiker een wachtwoordcode instelt. In Android kan dit worden geconfigureerd in de instellingen. In Windows wordt dit bereikt met BitLocker.
• Voor de Android- en iOS-apps worden de gegevens en instellingen (sleutel-waardeparen voor gebruikersconfiguratie) in de cache opgeslagen op het apparaat in een sandbox en interne opslag die alleen toegankelijk is voor de app. Voor de Windows-app zijn de gegevens alleen toegankelijk voor de gebruiker (en systeembeheerder).
• Geolocatie wordt expliciet in- of uitgeschakeld door de gebruiker. Indien ingeschakeld, worden geolocatiegegevens niet opgeslagen op het apparaat en niet gedeeld met Microsoft.
• Meldingen worden expliciet in- of uitgeschakeld door de gebruiker. Indien ingeschakeld, bieden Android en iOS geen ondersteuning voor geografische gegevenslocatievereisten voor meldingen.

Gegevensversleuteling kan worden verbeterd door versleuteling op bestandsniveau toe te passen via Microsoft Intune, een softwareservice die mobiel apparaat- en toepassingsbeheer biedt. Alle drie de platforms waarvoor Power BI - Mobiel beschikbaar is, ondersteunen Intune. Als Intune is ingeschakeld en geconfigureerd, worden gegevens op het mobiele apparaat versleuteld en kan de Power BI-toepassing zelf niet worden geïnstalleerd op een SD-kaart. Meer informatie over Microsoft Intune.

De Windows-app biedt ook ondersteuning voor Windows Information Protection (WIP).

Om eenmalige aanmelding te implementeren, zijn sommige beveiligde opslagwaarden met betrekking tot de verificatie op basis van tokens beschikbaar voor andere microsoft-apps (zoals Microsoft Authenticator) en worden beheerd door de Microsoft Authentication Library (MSAL).

Power BI - Mobiel gegevens in de cache worden verwijderd wanneer de app wordt verwijderd, wanneer de gebruiker zich afmeldt bij Power BI - Mobiel of wanneer de gebruiker zich niet kan aanmelden (bijvoorbeeld na een verloopgebeurtenis van een token of wachtwoordwijziging). De gegevenscache bevat dashboards en rapporten die eerder zijn geopend vanuit de Power BI - Mobiel-app.

Power BI - Mobiel heeft geen toegang tot andere toepassingsmappen of bestanden op het apparaat.

Met de Power BI-apps voor iOS en Android kunt u uw gegevens beveiligen door aanvullende identificatie te configureren, zoals het opgeven van Face ID, Touch ID of een wachtwoordcode voor iOS en biometrische gegevens (Vingerafdruk-id) voor Android. Meer informatie over aanvullende identificatie.

Verificatie bij de Power BI-service

Gebruikersverificatie voor de Power BI-service bestaat uit een reeks aanvragen, antwoorden en omleidingen tussen de browser van de gebruiker en de Power BI-service of de Azure-services die door Power BI worden gebruikt. Deze reeks beschrijft het proces van gebruikersverificatie in Power BI, dat volgt op de stroom voor het verlenen van Microsoft Entra-verificatiecodes. Zie Een aanmeldingsmodel kiezen voor Microsoft 365 voor meer informatie over opties voor gebruikersverificatiemodellen van een organisatie (aanmeldingsmodellen).

Verificatiereeks

De gebruikersverificatiereeks voor de Power BI-service vindt plaats zoals beschreven in de volgende stappen, die worden geïllustreerd in de afbeelding die erop volgt.

1. Een gebruiker initieert een verbinding met de Power BI-service vanuit een browser door het Power BI-adres in de adresbalk te typen of door Aanmelden te selecteren op de power BI-marketingpagina (https://powerbi.microsoft.com). De verbinding wordt tot stand gebracht via TLS en HTTPS, en alle volgende communicatie tussen de browser en de Power BI-service maakt gebruik van HTTPS.

2. De Azure Traffic Manager controleert de DNS-record van de gebruiker om het meest geschikte (meestal dichtstbijzijnde) datacenter te bepalen waar Power BI wordt geïmplementeerd en reageert op de DNS met het IP-adres van het WFE-cluster waarnaar de gebruiker moet worden verzonden.

3. WFE retourneert vervolgens een HTML-pagina naar de browserclient, die een MSAL.js bibliotheekverwijzing bevat die nodig is om de aanmeldingsstroom te initiëren.

4. De browserclient laadt de HTML-pagina die is ontvangen van de WFE en leidt de gebruiker om naar de aanmeldingspagina van Microsoft Online Services.

5. Nadat de gebruiker is geverifieerd, stuurt de aanmeldingspagina de gebruiker terug naar de Power BI WFE-pagina met een verificatiecode.

6. De browserclient laadt de HTML-pagina en gebruikt de verificatiecode om tokens (toegang, id, vernieuwing) aan te vragen vanuit Microsoft Entra-id.

7. De tenant-id van de gebruiker wordt door de browserclient gebruikt om een query uit te voeren op de Globale Power BI-service, die een lijst met tenants en hun Power BI-back-endclusterlocaties onderhoudt. De Globale Power BI-service bepaalt welk Power BI-back-endservicecluster de tenant van de gebruiker bevat en retourneert de BACK-endcluster-URL van Power BI naar de client.

8. De client kan nu communiceren met de URL-API van het Back-endcluster van Power BI met behulp van het toegangstoken in de autorisatieheader voor de HTTP-aanvragen. Het Microsoft Entra-toegangstoken heeft een vervaldatum die is ingesteld op basis van het Microsoft Entra-beleid en om de huidige sessie te onderhouden, zal de Power BI-client in de browser van de gebruiker periodieke aanvragen indienen om het toegangstoken te vernieuwen voordat het verloopt.

In zeldzame gevallen waarin verificatie aan de clientzijde mislukt vanwege een onverwachte fout, probeert de code terug te vallen op het gebruik van verificatie aan de serverzijde in de WFE. Raadpleeg de sectie vragen en antwoorden aan het einde van dit document voor meer informatie over de verificatiestroom aan de serverzijde.

Gegevensresidentie

Tenzij anders aangegeven in de documentatie, slaat Power BI klantgegevens op in een Azure-geografie die wordt toegewezen wanneer een Microsoft Entra-tenant zich voor het eerst registreert voor Power BI-service s. Een Microsoft Entra-tenant bevat de identiteiten, groepen en andere relevante informatie die betrekking heeft op een organisatie en de beveiliging ervan.

De toewijzing van een Azure-geografie voor tenantgegevensopslag wordt uitgevoerd door het land of de regio die is geselecteerd als onderdeel van de installatie van de Microsoft Entra-tenant toe te wijzen aan de meest geschikte Azure-geografie waar een Power BI-implementatie bestaat. Zodra deze beslissing is gemaakt, worden alle Power BI-klantgegevens opgeslagen in deze geselecteerde Azure-geografie (ook wel thuis geo genoemd), behalve in gevallen waarin organisaties multi-geo-implementaties gebruiken.

Meerdere geografische gebieden (meerdere geografische gebieden)

Sommige organisaties hebben een wereldwijde aanwezigheid en vereisen mogelijk Power BI-service s in meerdere Azure-geografische gebieden. Een bedrijf kan bijvoorbeeld zijn hoofdkantoor hebben in de Verenigde Staten, maar kan ook zaken doen in andere geografische gebieden, zoals Australië. In dergelijke gevallen kan het bedrijf vereisen dat bepaalde Power BI-gegevens in rust blijven opgeslagen in de externe regio om te voldoen aan de lokale regelgeving. Deze functie van de Power BI-service wordt aangeduid als multi-geo.

De queryuitvoeringslaag, querycaches en artefactgegevens die zijn toegewezen aan een werkruimte met meerdere geografische gebieden, worden gehost en blijven in de geografie van de externe capaciteit van Azure. Sommige metagegevens van artefacten, zoals rapportstructuur, kunnen echter in rust blijven opgeslagen in de geografische locatie van de tenant. Daarnaast kunnen sommige gegevensoverdracht en -verwerking nog steeds plaatsvinden in de thuislocatie van de tenant, zelfs voor werkruimten die worden gehost in een multi-geo Premium-capaciteit.

Zie Multi-Geo-ondersteuning configureren voor Power BI Premium voor meer informatie over het maken en beheren van Power BI-implementaties die meerdere Azure-geografische gebieden omvatten.

Regio's en datacenters

Power BI-service zijn beschikbaar in specifieke Azure-geografische gebieden, zoals beschreven in de Microsoft Trust Center. Raadpleeg het Vertrouwenscentrum van Microsoft voor meer informatie over waar uw gegevens worden opgeslagen en hoe deze worden gebruikt. Toezeggingen over de locatie van data-at-rest van klanten zijn te vinden in de voorwaarden voor gegevensverwerking van de voorwaarden voor Microsoft Online Services.

Microsoft biedt ook datacenters voor onafhankelijke entiteiten. Zie Nationale/regionale Clouds van Power BI voor meer informatie over Power BI-service beschikbaarheid voor nationale/regionale clouds.

Gegevensverwerking

In deze sectie vindt u een overzicht van de procedures voor het verwerken van Power BI-gegevens als het gaat om het opslaan, verwerken en overdragen van klantgegevens.

Inactieve gegevens

Power BI maakt gebruik van twee primaire resourcetypen voor gegevensopslag:

• Azure Storage
• Azure SQL Databases

In de meeste scenario's wordt Azure Storage gebruikt om de gegevens van Power BI-artefacten te behouden, terwijl Azure SQL Databases worden gebruikt om metagegevens van artefacten te behouden.

Alle gegevens die door Power BI worden bewaard, worden standaard versleuteld met behulp van door Microsoft beheerde sleutels. Klantgegevens die zijn opgeslagen in Azure SQL Databases, worden volledig versleuteld met behulp van TDE-technologie (Transparent Data Encryption) van Azure SQL. Klantgegevens die zijn opgeslagen in Azure Blob Storage, worden versleuteld met behulp van Azure Storage Encryption.

Organisaties kunnen desgewenst Power BI Premium gebruiken om hun eigen sleutels te gebruiken om data-at-rest te versleutelen die in een semantisch model worden geïmporteerd. Deze benadering wordt vaak beschreven als Bring Your Own Key (BYOK). Door BYOK te gebruiken, zorgt u ervoor dat zelfs in het geval van een serviceoperatorfout geen klantgegevens worden weergegeven. Dit is iets dat niet eenvoudig kan worden bereikt met transparante versleuteling aan de servicezijde. Zie Bring Your Own Encryption Keys voor Power BI voor meer informatie.

Met semantische Power BI-modellen kunnen verschillende verbindingsmodi voor gegevensbronnen worden gebruikt om te bepalen of de gegevensbrongegevens al dan niet in de service worden bewaard.

Semantische modelmodus (soort)	Gegevens die worden bewaard in Power BI
Importeren	Ja
DirectQuery	Nee
Live-Verbinding maken	Nee
Samengesteld	Als dit een gegevensbron importeren bevat
Streaming	Als deze is geconfigureerd om te behouden

Ongeacht de semantische modelmodus die wordt gebruikt, kan Power BI tijdelijk alle opgehaalde gegevens in de cache opslaan om de prestaties van query's en rapportbelastingen te optimaliseren.

Gegevens in verwerking

Gegevens worden verwerkt wanneer ze actief worden gebruikt door een of meer gebruikers als onderdeel van een interactief scenario, of wanneer een achtergrondproces, zoals vernieuwen, deze gegevens raakt. Power BI laadt actief verwerkte gegevens in de geheugenruimte van een of meer serviceworkloads. De verwerkte gegevens in het geheugen worden niet versleuteld om de functionaliteit te vergemakkelijken die vereist is voor de werkbelasting.

Actieve gegevens

Power BI vereist dat al het binnenkomende HTTP-verkeer wordt versleuteld met TLS 1.2 of hoger. Aanvragen voor het gebruik van de service met TLS 1.1 of lager worden geweigerd.

Verificatie voor gegevensbronnen

Wanneer een gebruiker verbinding maakt met een gegevensbron, kan hij of zij een kopie van de gegevens importeren in Power BI of rechtstreeks verbinding maken met de gegevensbron.

In het geval van importeren brengt een gebruiker een verbinding tot stand op basis van de aanmelding van de gebruiker en opent deze de gegevens met de referentie. Nadat het semantische model is gepubliceerd naar de Power BI-service, gebruikt Power BI altijd de referenties van deze gebruiker om gegevens te importeren. Zodra gegevens zijn geïmporteerd, heeft het weergeven van de gegevens in rapporten en dashboards geen toegang tot de onderliggende gegevensbron. Power BI biedt ondersteuning voor verificatie van eenmalige aanmelding voor geselecteerde gegevensbronnen. Als de verbinding is geconfigureerd voor gebruik van eenmalige aanmelding, worden de referenties van de eigenaar van het semantische model gebruikt om verbinding te maken met de gegevensbron.

Als een gegevensbron rechtstreeks is verbonden met vooraf geconfigureerde referenties, worden de vooraf geconfigureerde referenties gebruikt om verbinding te maken met de gegevensbron wanneer een gebruiker de gegevens bekijkt. Als een gegevensbron rechtstreeks is verbonden met behulp van eenmalige aanmelding, worden de referenties van de huidige gebruiker gebruikt om verbinding te maken met de gegevensbron wanneer een gebruiker de gegevens bekijkt. Wanneer u eenmalige aanmelding gebruikt, kunnen BEVEILIGING op rijniveau (RLS) en/of beveiliging op objectniveau (OLS) worden geïmplementeerd op de gegevensbron. Hierdoor kunnen gebruikers alleen gegevens bekijken die ze toegangsrechten hebben. Wanneer de verbinding met gegevensbronnen in de cloud is, wordt Microsoft Entra-verificatie gebruikt voor eenmalige aanmelding; voor on-premises gegevensbronnen worden Kerberos, Security Assertion Markup Language (SAML) en Microsoft Entra ID ondersteund.

Als de gegevensbron Azure Analysis Services of on-premises Analysis Services is en RLS en/of OLS is geconfigureerd, past de Power BI-service die beveiliging op rijniveau toe en zien gebruikers die niet voldoende referenties hebben voor toegang tot de onderliggende gegevens (die een query kunnen zijn die wordt gebruikt in een dashboard, rapport of ander gegevensartefact) geen gegevens waarvoor ze onvoldoende bevoegdheden hebben.

Premium-functies

Architectuur voor gegevensstromen

Gegevensstromen bieden gebruikers de mogelijkheid om back-endgegevensverwerkingsbewerkingen te configureren waarmee gegevens uit polymorfe gegevensbronnen worden geëxtraheerd, transformatielogica op de gegevens worden uitgevoerd en deze vervolgens in een doelmodel terechtkomen voor gebruik in verschillende presentatietechnologieën voor rapportage. Elke gebruiker met een lid-, inzender- of beheerdersrol in een werkruimte kan een gegevensstroom maken. Gebruikers in de viewerrol kunnen gegevens bekijken die door de gegevensstroom worden verwerkt, maar kunnen geen wijzigingen aanbrengen in de samenstelling ervan. Zodra een gegevensstroom is gemaakt, kan een lid, inzender of beheerder van de werkruimte vernieuwingen plannen en de gegevensstroom bekijken en bewerken door eigenaar te worden van de gegevensstroom.

Elke geconfigureerde gegevensbron is gebonden aan een clienttechnologie voor toegang tot die gegevensbron. De structuur van referenties die vereist zijn voor toegang tot deze referenties, wordt gevormd zodat deze overeenkomt met de vereiste implementatiedetails van de gegevensbron. Transformatielogica wordt toegepast door Power Query-services terwijl de gegevens worden uitgevoerd. Voor Premium-gegevensstromen worden Power Query-services uitgevoerd in back-endknooppunten. Gegevens kunnen rechtstreeks worden opgehaald uit de cloudbronnen of via een gateway die on-premises is geïnstalleerd. Wanneer het transport rechtstreeks van een cloudbron naar de service of de gateway wordt opgehaald, gebruikt het transport beveiligingsmethodologie die specifiek is voor de clienttechnologie, indien van toepassing. Wanneer gegevens worden overgedragen van de gateway naar de cloudservice, worden deze versleuteld. Zie de sectie Data in Transit hierboven.

Wanneer door de klant opgegeven gegevensbronnen referenties nodig hebben voor toegang, geeft de eigenaar/maker van de gegevensstroom deze op tijdens het ontwerpen. Ze worden opgeslagen met standaard referentieopslag voor het hele product. Zie de sectie Verificatie voor gegevensbronnen hierboven. Er zijn verschillende benaderingen die gebruikers kunnen configureren om gegevenspersistentie en -toegang te optimaliseren. De gegevens worden standaard in een power BI-opslagaccount in eigendom en beveiligd geplaatst. Opslagversleuteling is ingeschakeld op de Blob Storage-containers om de gegevens te beveiligen terwijl ze in rust zijn. Zie de sectie Data at Rest hieronder. Gebruikers kunnen echter hun eigen opslagaccount configureren dat is gekoppeld aan hun eigen Azure-abonnement. Als u dit doet, krijgt een Power BI-service-principal toegang tot dat opslagaccount, zodat deze de gegevens daar kan schrijven tijdens het vernieuwen. In dit geval is de eigenaar van de opslagresource verantwoordelijk voor het configureren van versleuteling voor het geconfigureerde ADLS-opslagaccount. Gegevens worden altijd verzonden naar Blob Storage met behulp van versleuteling.

Omdat prestaties bij het openen van opslagaccounts mogelijk suboptimaal zijn voor sommige gegevens, hebben gebruikers ook de mogelijkheid om een door Power BI gehoste rekenengine te gebruiken om de prestaties te verbeteren. In dit geval worden gegevens redundant opgeslagen in een SQL-database die beschikbaar is voor DirectQuery via toegang door het back-end-Power BI-systeem. Gegevens worden altijd versleuteld op het bestandssysteem. Als de gebruiker een sleutel biedt voor het versleutelen van de gegevens die zijn opgeslagen in de SQL-database, wordt die sleutel gebruikt om deze dubbel te versleutelen.

Bij het uitvoeren van query's met Behulp van DirectQuery wordt het versleutelde transportprotocol HTTPS gebruikt voor toegang tot de API. Alle secundaire of indirecte gebruik van DirectQuery wordt beheerd door dezelfde besturingselementen voor toegang die eerder zijn beschreven. Omdat gegevensstromen altijd zijn gebonden aan een werkruimte, wordt de toegang tot de gegevens altijd gegateeerd door de rol van de gebruiker in die werkruimte. Een gebruiker moet ten minste leestoegang hebben om een query uit te kunnen voeren op de gegevens via een willekeurige manier.

Wanneer Power BI Desktop wordt gebruikt voor toegang tot gegevens in een gegevensstroom, moet de gebruiker eerst worden geverifieerd met behulp van Microsoft Entra ID om te bepalen of de gebruiker voldoende rechten heeft om de gegevens weer te geven. Zo ja, dan wordt een SaS-sleutel verkregen en gebruikt om rechtstreeks toegang te krijgen tot opslag met behulp van het versleutelde transportprotocol HTTPS.

De verwerking van gegevens in de hele pijplijn verzendt controle-gebeurtenissen van Office 365. Bij sommige van deze gebeurtenissen worden beveiligings- en privacygerelateerde bewerkingen vastgelegd.

Gepagineerde rapporten

Gepagineerde rapporten zijn ontworpen om te worden afgedrukt of gedeeld. Ze worden gepagineerd genoemd omdat ze zo zijn opgemaakt dat ze goed op een pagina passen. Alle gegevens in een tabel worden weergegeven, zelfs als de tabel meerdere pagina's omvat. U kunt de pagina-indeling van het rapport exact beheren.

Gepagineerde rapporten ondersteunen uitgebreide en krachtige expressies die zijn geschreven in Microsoft Visual Basic .NET. Expressies worden veel gebruikt in gepagineerde rapporten van Power BI Report Builder voor het ophalen, berekenen, weergeven, groeperen, sorteren, filteren, parameteriseren en opmaken van gegevens.

Expressies worden gemaakt door de auteur van het rapport met toegang tot het brede scala aan functies van het .NET Framework. De verwerking en uitvoering van gepagineerde rapporten wordt uitgevoerd in een sandbox.

Gepagineerde rapportdefinities (.rdl) worden opgeslagen in Power BI en om een gepagineerd rapport te publiceren en/of weer te geven, moet een gebruiker zich op dezelfde manier verifiëren en autoriseren als beschreven in de sectie Verificatie voor de Power BI-service hierboven.

Het Microsoft Entra-token dat tijdens de verificatie is verkregen, wordt gebruikt om rechtstreeks vanuit de browser te communiceren met het Power BI Premium-cluster.

In Power BI Premium biedt de Power BI-service runtime een op de juiste wijze geïsoleerde uitvoeringsomgeving voor elke rapportweergave. Dit geldt ook voor gevallen waarin de rapporten die worden weergegeven, behoren tot werkruimten die aan dezelfde capaciteit zijn toegewezen.

Een gepagineerd rapport heeft toegang tot een breed scala aan gegevensbronnen als onderdeel van de weergave van het rapport. De sandbox communiceert niet rechtstreeks met een van de gegevensbronnen, maar communiceert in plaats daarvan met het vertrouwde proces om gegevens aan te vragen en vervolgens voegt het vertrouwde proces de vereiste referenties toe aan de verbinding. Op deze manier heeft de sandbox nooit toegang tot referenties of geheimen.

Om functies zoals Bing-kaarten of aanroepen naar Azure Functions te ondersteunen, heeft de sandbox wel toegang tot internet.

Ingesloten analyses in Power BI

Onafhankelijke softwareleveranciers (ISV's) en oplossingsproviders hebben twee hoofdmodi voor het insluiten van Power BI-artefacten in hun webtoepassingen en -portals: insluiten voor uw organisatie en insluiten voor uw klanten. Het artefact wordt ingesloten in een IFrame in de toepassing of portal. Een IFrame mag geen gegevens lezen of schrijven vanuit de externe webtoepassing of -portal en de communicatie met het IFrame wordt uitgevoerd met behulp van de Power BI Client SDK met POST-berichten.

In een insluiting voor uw organisatiescenario hebben Microsoft Entra-gebruikers toegang tot hun eigen Power BI-inhoud via portals die zijn aangepast door hun ondernemingen en ID's. Alle Power BI-beleidsregels en -mogelijkheden die in dit document worden beschreven, zoals Beveiliging op rijniveau (RLS) en BEVEILIGING op objectniveau (OLS), worden automatisch toegepast op alle gebruikers, onafhankelijk van of ze toegang hebben tot Power BI via de Power BI-portal of via aangepaste portals.

In een insluitscenario voor uw klanten zijn ISV's doorgaans eigenaar van Power BI-tenants en Power BI-items (dashboards, rapporten, semantische modellen en andere). Het is de verantwoordelijkheid van een ISV-back-endservice om de eindgebruikers te verifiëren en te bepalen welke artefacten en welk toegangsniveau geschikt is voor die eindgebruiker. ISV-beleidsbeslissingen worden versleuteld in een insluittoken dat door Power BI wordt gegenereerd en doorgegeven aan de ISV-back-end voor verdere distributie aan de eindgebruikers volgens de bedrijfslogica van de ISV. Eindgebruikers die een browser of andere clienttoepassingen gebruiken, kunnen insluittokens niet ontsleutelen of wijzigen. SDK's aan de clientzijde, zoals Power BI Client-API's , voegen automatisch het versleutelde insluittoken toe aan Power BI-aanvragen als autorisatie : EmbedToken-header . Op basis van deze header dwingt Power BI alle beleidsregels (zoals toegang of beveiliging op rijniveau) af zoals is opgegeven door de ISV tijdens het genereren.

Als u insluiten en automatiseren wilt inschakelen en de hierboven beschreven insluitingstokens wilt genereren, maakt Power BI een uitgebreide set REST API's beschikbaar. Deze Power BI REST API's ondersteunen zowel door de gebruiker gedelegeerde als de service-principal Microsoft Entra-methoden voor verificatie en autorisatie.

Ingesloten analyses van Power BI en de REST API's ondersteunen alle mogelijkheden voor isolatie van Power BI-netwerken die in dit artikel worden beschreven: bijvoorbeeld servicetags en privékoppelingen.

AI-functies

Power BI ondersteunt momenteel twee algemene categorieën AI-functies in het product: AI-visuals en AI-verrijkingen. De AI-functies op visueel niveau omvatten mogelijkheden zoals Key-Influencers, Decomposition-Tree, Smart-Narrative, Anomaliedetectie, R-visual, Python-visual, Clustering, Forecasting, Q&A, Quick-Insights, enzovoort. De AI-verrijkingsmogelijkheden omvatten mogelijkheden zoals AutoML, Azure Machine Learning, CognitiveServices, R/Python-transformaties, enzovoort.

De meeste hierboven genoemde functies worden momenteel ondersteund in gedeelde en Premium-werkruimten. AutoML en CognitiveServices worden echter alleen ondersteund in Premium-werkruimten vanwege IP-beperkingen. Vandaag de dag kan een gebruiker met de AutoML-integratie in Power BI een aangepast ML-model bouwen en trainen (bijvoorbeeld Voorspelling, Classificatie, Regressie, enzovoort) en toepassen om voorspellingen op te halen tijdens het laden van gegevens in een gegevensstroom die is gedefinieerd in een Premium-werkruimte. Daarnaast kunnen Power BI-gebruikers verschillende CognitiveServices-API's, zoals TextAnalytics en ImageTagging, toepassen om gegevens te transformeren voordat ze worden geladen in een gegevensstroom/semantisch model dat is gedefinieerd in een Premium-werkruimte.

De Premium AI-verrijkingsfuncties kunnen het beste worden weergegeven als een verzameling stateless AI-functies/transformaties die kunnen worden gebruikt door Power BI-gebruikers in hun pijplijnen voor gegevensintegratie die worden gebruikt door een semantisch Power BI-model of -gegevensstroom. Houd er rekening mee dat deze functies ook toegankelijk zijn vanuit de huidige ontwerpomgevingen voor gegevensstromen/semantische modellen in de Power BI-service en Power BI Desktop. Deze AI-functies/transformaties worden altijd uitgevoerd in een Premium-werkruimte/-capaciteit. Deze functies worden in Power BI weergegeven als gegevensbron waarvoor een Microsoft Entra-token is vereist voor de Power BI-gebruiker die de AI-functie gebruikt. Deze AI-gegevensbronnen zijn speciaal omdat ze geen eigen gegevens weergeven en ze alleen deze functies/transformaties leveren. Tijdens de uitvoering worden met deze functies geen uitgaande aanroepen naar andere services uitgevoerd om de gegevens van de klant te verzenden. Laten we de Premium-scenario's afzonderlijk bekijken om inzicht te hebben in de communicatiepatronen en relevante beveiligingsgerelateerde details met betrekking tot deze scenario's.

Voor het trainen en toepassen van een AutoML-model gebruikt Power BI de Azure AutoML SDK en voert alle training uit in de Power BI-capaciteit van de klant. Tijdens trainingsiteraties roept Power BI een experimentele Azure Machine Learning-service aan om een geschikt model en hyperparameters te selecteren voor de huidige iteratie. In deze uitgaande aanroep worden alleen relevante metagegevens van het experiment (bijvoorbeeld nauwkeurigheid, ml-algoritme, algoritmeparameters, enzovoort) van de vorige iteratie verzonden. De AutoML-training produceert een ONNX-model en trainingsrapportgegevens die vervolgens worden opgeslagen in de gegevensstroom. Later kunnen Power BI-gebruikers het getrainde ML-model vervolgens toepassen als een transformatie om het ML-model op een geplande basis operationeel te maken. Voor TextAnalytics- en ImageTagging-API's roept Power BI de CognitiveServices-service-API's niet rechtstreeks aan, maar gebruikt een interne SDK om de API's uit te voeren in de Power BI Premium-capaciteit. Tegenwoordig worden deze API's ondersteund in zowel Power BI-gegevensstromen als semantische modellen. Tijdens het ontwerpen van een gegevensmodel in Power BI Desktop hebben gebruikers alleen toegang tot deze functionaliteit als ze toegang hebben tot een Premium Power BI-werkruimte. Daarom wordt klanten gevraagd hun Microsoft Entra-referenties op te geven.

Netwerkisolatie

In deze sectie vindt u een overzicht van geavanceerde beveiligingsfuncties in Power BI. Sommige functies hebben specifieke licentievereisten. Zie de onderstaande secties voor meer informatie.

Servicetags

Een servicetag vertegenwoordigt een groep IP-adresvoorvoegsels van een bepaalde Azure-service. Het helpt de complexiteit van frequente updates voor netwerkbeveiligingsregels te minimaliseren. Klanten kunnen servicetags gebruiken om netwerktoegangsbeheer in netwerkbeveiligingsgroepen of Azure Firewall te definiëren. Klanten kunnen servicetags gebruiken in plaats van specifieke IP-adressen bij het maken van beveiligingsregels. Door de naam van de servicetag (zoals PowerBI) op te geven in het juiste bron- of doelveld (voor API's) van een regel, kunnen klanten het verkeer voor de bijbehorende service toestaan of weigeren. Microsoft beheert de adresvoorvoegsels die worden omvat door de servicetag en werkt de servicetag automatisch bij wanneer adressen worden gewijzigd.

Private Link-integratie

Azure-netwerken biedt de Azure Private Link-functie waarmee Power BI beveiligde toegang kan bieden via privé-eindpunten van Azure Networking. Met Azure Private Link en privé-eindpunten wordt gegevensverkeer privé verzonden met behulp van de backbone-netwerkinfrastructuur van Microsoft. De gegevens gaan dus niet via internet.

Private Link zorgt ervoor dat Power BI-gebruikers de backbone van het microsoft-privénetwerk gebruiken wanneer ze naar resources in de Power BI-service gaan.

Het gebruik van Private Link met Power BI biedt de volgende voordelen:

• Private Link zorgt ervoor dat verkeer via de Azure-backbone naar een privé-eindpunt stroomt voor Azure-cloudresources.
• Isolatie van netwerkverkeer van niet-Azure-infrastructuur, zoals on-premises toegang, vereist dat klanten ExpressRoute of een VPN (Virtual Private Network) hebben geconfigureerd.

Zie Privékoppelingen voor toegang tot Power BI voor meer informatie.

VNet-connectiviteit (preview- binnenkort beschikbaar)

Hoewel de private link-integratiefunctie beveiligde binnenkomende verbindingen met Power BI biedt, maakt de VNet-connectiviteitsfunctie beveiligde uitgaande connectiviteit van Power BI mogelijk naar gegevensbronnen binnen een VNet.

VNet-gateways (door Microsoft beheerd) elimineren de overhead van het installeren en bewaken van on-premises gegevensgateways voor het maken van verbinding met gegevensbronnen die zijn gekoppeld aan een VNet. Ze volgen echter nog steeds het vertrouwde proces voor het beheren van beveiliging en gegevensbronnen, net als bij een on-premises gegevensgateway.

Hier volgt een overzicht van wat er gebeurt wanneer u communiceert met een Power BI-rapport dat is verbonden met een gegevensbron in een VNet met behulp van VNet-gateways:

1. De Power BI-cloudservice (of een van de andere ondersteunde cloudservices) start een query en verzendt de query, gegevensbrondetails en referenties naar de Power Platform VNet-service (PP VNet).

2. De PP VNet-service injecteert vervolgens veilig een container waarop een VNet-gateway wordt uitgevoerd in het subnet. Deze container kan nu verbinding maken met gegevensservices die toegankelijk zijn vanuit dit subnet.

3. De PP VNet-service verzendt vervolgens de query, gegevensbrondetails en referenties naar de VNet-gateway.

4. De VNet-gateway haalt de query op en maakt verbinding met de gegevensbronnen met deze referenties.

5. De query wordt vervolgens verzonden naar de gegevensbron voor uitvoering.

6. Na de uitvoering worden de resultaten verzonden naar de VNet-gateway en de PP-VNet-service pusht de gegevens veilig van de container naar de Power BI-cloudservice.

Deze functie is binnenkort beschikbaar in de openbare preview.

Service-principals

Power BI ondersteunt het gebruik van service-principals. Sla alle referenties van de service-principal op die worden gebruikt voor het versleutelen of openen van Power BI in een Sleutelkluis, wijs het juiste toegangsbeleid toe aan de kluis en controleer regelmatig de toegangsmachtigingen.

Zie Taken voor Het automatiseren van Premium-werkruimten en semantische modellen met service-principals voor meer informatie.

Microsoft Purview voor Power BI

Microsoft Purview Information Protection

Power BI is nauw geïntegreerd met Microsoft Purview Informatiebeveiliging. Microsoft Purview Informatiebeveiliging stelt organisaties in staat om één geïntegreerde oplossing te hebben voor classificatie, labels, controle en naleving in Azure, Power BI en Office.

Wanneer gegevensbeveiliging is ingeschakeld in Power BI:

• Gevoelige gegevens, zowel in de Power BI-service als in Power BI Desktop, kunnen worden geclassificeerd en gelabeld met dezelfde vertrouwelijkheidslabels die in Office en in Azure worden gebruikt.
• Governancebeleid kan worden afgedwongen wanneer Power BI-inhoud wordt geëxporteerd naar Excel-, PowerPoint-, PDF-, Word- of PBIX-bestanden om ervoor te zorgen dat gegevens worden beveiligd, zelfs wanneer ze Power BI verlaten.
• Het is eenvoudig om PBIX-bestanden te classificeren en te beveiligen in Power BI Desktop, net zoals in Excel-, Word- en PowerPoint-toepassingen. Bestanden kunnen eenvoudig worden gelabeld op basis van hun gevoeligheidsniveau. Bovendien kunnen ze worden versleuteld als ze zakelijke vertrouwelijke gegevens bevatten, zodat alleen geautoriseerde gebruikers deze bestanden kunnen bewerken.
• Excel-werkmappen nemen automatisch vertrouwelijkheidslabels over wanneer ze verbinding maken met Power BI (preview), zodat u end-to-end-classificatie kunt behouden en beveiliging kunt toepassen wanneer semantische Power BI-modellen worden geanalyseerd in Excel.
• Vertrouwelijkheidslabels die zijn toegepast op Power BI-rapporten en -dashboards zijn zichtbaar in de mobiele Power BI-apps voor iOS en Android.
• Vertrouwelijkheidslabels blijven behouden wanneer een Power BI-rapport is ingesloten in Teams, SharePoint of een beveiligde website. Dit helpt organisaties bij het exporteren classificatie en beveiliging bij het insluiten van Power BI-inhoud bij het insluiten van Power BI-inhoud.
• Labelovername bij het maken van nieuwe inhoud in de Power BI-service zorgt ervoor dat labels die worden toegepast op semantische modellen of datamarts in de Power BI-service worden toegepast op nieuwe inhoud die bovenop deze semantische modellen en datamarts wordt gemaakt.
• Power BI-beheerdersscan-API's kunnen het vertrouwelijkheidslabel van een Power BI-item extraheren, zodat Power BI- en InfoSec-beheerders labelen in de Power BI-service kunnen bewaken en leidinggevende rapporten kunnen produceren.
• Met Power BI-beheer-API's kunnen centrale teams programmatisch vertrouwelijkheidslabels toepassen op inhoud in de Power BI-service.
• Centrale teams kunnen verplicht labelbeleid maken om het toepassen van labels op nieuwe of bewerkte inhoud in Power BI af te dwingen.
• Centrale teams kunnen standaardlabelbeleid maken om ervoor te zorgen dat een vertrouwelijkheidslabel wordt toegepast op alle nieuwe of gewijzigde Power BI-inhoud.
• Automatische downstream vertrouwelijkheidslabels in de Power BI-service zorgt ervoor dat wanneer een label op een semantisch model of datamart wordt toegepast of gewijzigd, het label automatisch wordt toegepast of gewijzigd op alle downstream-inhoud die is verbonden met het semantische model of datamart.

Zie Vertrouwelijkheidslabels in Power BI voor meer informatie.

Microsoft Purview-preventie van gegevensverlies (DLP)-beleid voor Power BI (preview)

Het DLP-beleid van Microsoft Purview kan organisaties helpen het risico te verminderen dat gevoelige bedrijfsgegevens uit Power BI lekken. DLP-beleid kan hen helpen voldoen aan de nalevingsvereisten van overheids- of branchevoorschriften, zoals AVG (de Algemene verordening gegevensbescherming van de Europese Unie) of CCPA (de California Consumer Privacy Act) en ervoor te zorgen dat hun gegevens in Power BI worden beheerd.

Wanneer DLP-beleid voor Power BI is ingesteld:

• Alle semantische modellen in de werkruimten die in het beleid zijn opgegeven, worden geëvalueerd door het beleid.
• U kunt detecteren wanneer gevoelige gegevens worden geüpload naar uw Premium-capaciteiten. DLP-beleid kan het volgende detecteren:
  • Vertrouwelijkheidslabels.
  • Typen gevoelige informatie. Meer dan 260 typen worden ondersteund. Detectie van gevoelige informatietypen is afhankelijk van het scannen van Microsoft Purview-inhoud.
• Wanneer u een semantisch model tegenkomt dat als gevoelig wordt geïdentificeerd, ziet u een aangepaste beleidstip waarmee u begrijpt wat u moet doen.
• Als u een semantische modeleigenaar bent, kunt u een beleid negeren en voorkomen dat uw semantische model wordt geïdentificeerd als 'gevoelig' als u een geldige reden hiervoor hebt.
• Als u een semantische modeleigenaar bent, kunt u een probleem met een beleid melden als u besluit dat een type gevoelige informatie onwaar is geïdentificeerd.
• Automatische risicobeperking, zoals waarschuwingen aan de beveiligingsbeheerder, kan worden aangeroepen.

Zie Beleid voor preventie van gegevensverlies voor Power BI voor meer informatie.

Microsoft Defender voor Cloud-apps voor Power BI

Microsoft Defender voor Cloud Apps is een van de toonaangevende cloudtoegangsbeveiligingsbrokers, genoemd als leider in de Magic Quadrant van Gartner voor de CASB-markt (Cloud Access Security Broker). Defender voor Cloud Apps wordt gebruikt om het gebruik van cloud-apps te beveiligen. Hiermee kunnen organisaties riskante Power BI-sessies, zoals gebruikerstoegang vanaf onbeheerde apparaten, in realtime bewaken en beheren. Beveiligingsbeheerders kunnen beleidsregels definiëren om gebruikersacties te beheren, zoals het downloaden van rapporten met gevoelige informatie.

Met Defender voor Cloud Apps kunnen organisaties de volgende DLP-mogelijkheden verkrijgen:

• Stel realtime-besturingselementen in om riskante gebruikerssessies in Power BI af te dwingen. Als een gebruiker bijvoorbeeld verbinding maakt met Power BI van buiten het land of de regio, kan de sessie worden bewaakt door de Defender voor Cloud Apps realtime-besturingselementen en riskante acties, zoals het downloaden van gegevens die zijn getagd met een vertrouwelijkheidslabel zeer vertrouwelijk, kunnen onmiddellijk worden geblokkeerd.
• Onderzoek power BI-gebruikersactiviteit met het activiteitenlogboek van Defender voor Cloud Apps. Het activiteitenlogboek van Defender voor Cloud Apps bevat Power BI-activiteiten zoals vastgelegd in het Office 365-auditlogboek, dat informatie bevat over alle activiteiten van gebruikers en beheerders, evenals informatie over vertrouwelijkheidslabels voor relevante activiteiten, zoals toepassen, wijzigen en verwijderen van label. Beheer s kunnen gebruikmaken van de geavanceerde filters van Defender voor Cloud Apps en snelle acties voor effectief probleemonderzoek.
• Maak aangepast beleid om waarschuwingen te geven over verdachte gebruikersactiviteit in Power BI. De functie Defender voor Cloud-beleid voor apps-activiteiten kan worden gebruikt om uw eigen aangepaste regels te definiëren, zodat u gebruikersgedrag kunt detecteren dat afwijkt van de norm en zelfs automatisch actie ondernemen, als het te gevaarlijk lijkt.
• Werken met de ingebouwde anomaliedetectie van Defender voor Cloud Apps. Het beleid voor anomaliedetectie van Defender voor Cloud Apps biedt kant-en-klare analyse van gebruikersgedrag en machine learning, zodat u vanaf het begin klaar bent om geavanceerde detectie van bedreigingen uit te voeren in uw cloudomgeving. Wanneer een anomaliedetectiebeleid een verdacht gedrag identificeert, wordt er een beveiligingswaarschuwing geactiveerd.
• Power BI-beheerdersrol in de portal Defender voor Cloud Apps. Defender voor Cloud Apps biedt een app-specifieke beheerdersrol die kan worden gebruikt om Power BI-beheerders alleen de machtigingen te verlenen die ze nodig hebben voor toegang tot relevante Power BI-gegevens in de portal, zoals waarschuwingen, gebruikers die risico lopen, activiteitenlogboeken en andere informatie met betrekking tot Power BI.

Zie Besturingselementen voor Microsoft Defender voor Cloud-apps gebruiken in Power BI voor meer informatie.

Preview-beveiligingsfuncties

Deze sectie bevat functies die tot en met maart 2021 zijn uitgebracht. Omdat in dit onderwerp functies worden vermeld die mogelijk nog niet zijn uitgebracht, kunnen leveringstijdlijnen worden gewijzigd en kan de verwachte functionaliteit later dan maart 2021 worden uitgebracht of helemaal niet worden uitgebracht. Raadpleeg de voorwaarden voor onlineservices voor meer informatie over previews.

Bring Your Own Log Analytics (BYOLA)

Bring Your Own Log Analytics maakt integratie mogelijk tussen Power BI en Azure Log Analytics. Deze integratie omvat de geavanceerde analyse-engine van Azure Log Analytics, de interactieve querytaal en ingebouwde machine learning-constructies.

Power BI-beveiligingsvragen en -antwoorden

De volgende vragen zijn veelvoorkomende beveiligingsvragen en antwoorden voor Power BI. Deze zijn georganiseerd op basis van wanneer ze aan dit witboek zijn toegevoegd, zodat u snel nieuwe vragen en antwoorden kunt vinden wanneer dit document wordt bijgewerkt. De nieuwste vragen worden toegevoegd aan het einde van deze lijst.

Hoe maken gebruikers verbinding met en krijgen ze toegang tot gegevensbronnen tijdens het gebruik van Power BI?

• Power BI beheert referenties voor gegevensbronnen voor elke gebruiker voor cloudreferenties of voor connectiviteit via een persoonlijke gateway. Gegevensbronnen die worden beheerd door een on-premises gegevensgateway, kunnen worden gedeeld in de hele onderneming en machtigingen voor deze gegevensbronnen kunnen worden beheerd door de gateway-Beheer. Bij het configureren van een semantisch model mag de gebruiker een referentie selecteren in zijn persoonlijke archief of een on-premises gegevensgateway gebruiken om een gedeelde referentie te gebruiken.

  In het importscenario brengt een gebruiker een verbinding tot stand op basis van de aanmelding van de gebruiker en opent deze de gegevens met de referentie. Nadat het semantische model is gepubliceerd naar Power BI-service, gebruikt Power BI altijd de referenties van deze gebruiker om gegevens te importeren. Zodra gegevens zijn geïmporteerd, heeft het weergeven van de gegevens in rapporten en het dashboard geen toegang tot de onderliggende gegevensbron. Power BI biedt ondersteuning voor verificatie van eenmalige aanmelding voor geselecteerde gegevensbronnen. Als de verbinding is geconfigureerd voor gebruik van eenmalige aanmelding, wordt de referenties van de eigenaar van het semantische model gebruikt om verbinding te maken met de gegevensbron.

  Voor rapporten die zijn verbonden met DirectQuery, wordt de gegevensbron rechtstreeks verbonden met een vooraf geconfigureerde referentie. De vooraf geconfigureerde referentie wordt gebruikt om verbinding te maken met de gegevensbron wanneer een gebruiker de gegevens bekijkt. Als een gegevensbron rechtstreeks is verbonden met behulp van eenmalige aanmelding, wordt de referenties van de huidige gebruiker gebruikt om verbinding te maken met de gegevensbron wanneer de gebruiker de gegevens bekijkt. Wanneer u eenmalige aanmelding gebruikt, kunnen BEVEILIGING op rijniveau (RLS) en/of beveiliging op objectniveau (OLS) worden geïmplementeerd op de gegevensbron. Hierdoor kunnen gebruikers gegevens bekijken die ze toegangsrechten hebben. Wanneer de verbinding met gegevensbronnen in de cloud is, wordt Microsoft Entra-verificatie gebruikt voor eenmalige aanmelding; voor on-premises gegevensbronnen, Kerberos, SAML en Microsoft Entra-id worden ondersteund.

  Wanneer u verbinding maakt met Kerberos, wordt de UPN van de gebruiker doorgegeven aan de gateway en wordt de beperkte Kerberos-delegering gebruikt, wordt de gebruiker geïmiteerd en verbonden met de respectieve gegevensbronnen. SAML wordt ook ondersteund op de gateway voor SAP HANA-gegevensbron. Meer informatie is beschikbaar in het overzicht van eenmalige aanmelding voor gateways.

  Als de gegevensbron Azure Analysis Services of on-premises Analysis Services en Beveiliging op rijniveau (RLS) en/of beveiliging op objectniveau (OLS) is geconfigureerd, past de Power BI-service die beveiliging op rijniveau toe en zien gebruikers die niet over voldoende referenties beschikken om toegang te krijgen tot de onderliggende gegevens (die een query kunnen zijn die wordt gebruikt in een dashboard, rapport of ander gegevensartefact) geen gegevens waarvoor de gebruiker onvoldoende bevoegdheden heeft.

  Beveiliging op rijniveau met Power BI kan worden gebruikt om de toegang tot gegevens voor bepaalde gebruikers te beperken. Filters beperken de toegang tot gegevens op rijniveau en u kunt filters binnen de rol definiëren.

  Beveiliging op objectniveau (OLS) kan worden gebruikt om gevoelige tabellen of kolommen te beveiligen. In tegenstelling tot beveiliging op rijniveau beveiligt beveiliging op objectniveau ook objectnamen en metagegevens. Hiermee voorkomt u dat kwaadwillende gebruikers zelfs het bestaan van dergelijke objecten detecteren. Beveiligde tabellen en kolommen worden verborgen in de lijst met velden bij het gebruik van rapportagehulpprogramma's zoals Excel of Power BI, en bovendien hebben gebruikers zonder machtigingen geen toegang tot beveiligde metagegevensobjecten via DAX of een andere methode. Vanuit het oogpunt van gebruikers zonder de juiste toegangsmachtigingen bestaan beveiligde tabellen en kolommen gewoon niet.

  Beveiliging op objectniveau, samen met beveiliging op rijniveau, maakt verbeterde beveiliging op bedrijfsniveau mogelijk voor rapporten en semantische modellen, zodat alleen gebruikers met de vereiste machtigingen toegang hebben om gevoelige gegevens te bekijken en ermee te communiceren.

Hoe worden gegevens overgebracht naar Power BI?

• Alle gegevens die door Power BI worden aangevraagd en verzonden, worden versleuteld via HTTPS (behalve wanneer de door de klant gekozen gegevensbron geen ondersteuning biedt voor HTTPS) om verbinding te maken vanuit de gegevensbron met de Power BI-service. Er wordt een beveiligde verbinding tot stand gebracht met de gegevensprovider. Zodra deze verbinding tot stand is gebracht, worden gegevens via het netwerk verzonden.

Hoe worden rapport-, dashboard- of modelgegevens van Power BI in de cache opgeslagen en beveiligd?

• Wanneer een gegevensbron wordt geopend, volgt de Power BI-service het proces dat wordt beschreven in de sectie Verificatie voor gegevensbronnen eerder in dit document.

Worden webpaginagegevens lokaal opgeslagen in de cache van clients?

• Wanneer browserclients toegang hebben tot Power BI, stellen de Power BI-webservers de instructie Cachebeheer in op geen archief. De instructie no-store geeft browsers de opdracht om de webpagina die door de gebruiker wordt bekeken niet in de cache op te slaan, en niet om de webpagina op te slaan in de cachemap van de client.

Hoe zit het met beveiliging op basis van rollen, rapporten of dashboards en gegevensverbindingen? Hoe werkt dat in termen van gegevenstoegang, dashboardweergave, rapporttoegang of vernieuwing?

• Voor niet-rolniveaubeveiliging (RLS) ingeschakelde gegevensbronnen, als een dashboard, rapport of gegevensmodel wordt gedeeld met andere gebruikers via Power BI, zijn de gegevens vervolgens beschikbaar voor gebruikers met wie deze worden gedeeld om te bekijken en ermee te communiceren. Power BI verifieert gebruikers niet opnieuw op basis van de oorspronkelijke bron van de gegevens. Zodra gegevens zijn geüpload naar Power BI, is de gebruiker die is geverifieerd bij de brongegevens verantwoordelijk voor het beheren van welke andere gebruikers en groepen de gegevens kunnen bekijken.

  Wanneer gegevensverbindingen worden gemaakt met een gegevensbron die geschikt is voor beveiliging op rijniveau, zoals een Analysis Services-gegevensbron, worden alleen dashboardgegevens in de cache opgeslagen in Power BI. Telkens wanneer een rapport of semantisch model wordt bekeken of geopend in Power BI die gebruikmaakt van gegevens uit de gegevensbron die geschikt is voor beveiliging op rijniveau, wordt de Power BI-service de gegevensbron geopend om gegevens op te halen op basis van de referenties van de gebruiker. Als er voldoende machtigingen bestaan, worden de gegevens in het rapport of gegevensmodel voor die gebruiker geladen. Als de verificatie mislukt, krijgt de gebruiker een fout te zien.

  Zie de sectie Verificatie voor gegevensbronnen eerder in dit document voor meer informatie.

Onze gebruikers maken altijd verbinding met dezelfde gegevensbronnen, waarvan sommige referenties vereisen die verschillen van hun domeinreferenties. Hoe kunnen ze voorkomen dat ze deze referenties telkens moeten invoeren wanneer ze een gegevensverbinding maken?

• Power BI biedt de persoonlijke Power BI-gateway. Dit is een functie waarmee gebruikers referenties voor meerdere verschillende gegevensbronnen kunnen maken en die referenties vervolgens automatisch kunnen gebruiken wanneer ze vervolgens toegang hebben tot elk van deze gegevensbronnen. Zie Power BI Personal Gateway voor meer informatie.

Welke poorten worden gebruikt door een on-premises gegevensgateway en persoonlijke gateway? Zijn er domeinnamen die moeten worden toegestaan voor connectiviteitsdoeleinden?

• Het gedetailleerde antwoord op deze vraag is beschikbaar via de volgende koppeling: Gatewaypoorten

Wanneer u werkt met de on-premises gegevensgateway, hoe worden herstelsleutels gebruikt en waar worden ze opgeslagen? Hoe zit het met beveiligd referentiebeheer?

• Tijdens de installatie en configuratie van de gateway typt de beheerder een gatewayherstelsleutel. Deze herstelsleutel wordt gebruikt om een sterke symmetrische AES-sleutel te genereren. Er wordt ook tegelijkertijd een RSA-asymmetrische sleutel gemaakt.

  Deze gegenereerde sleutels (RSA en AES) worden opgeslagen in een bestand op de lokale computer. Dat bestand is ook versleuteld. De inhoud van het bestand kan alleen worden ontsleuteld door die specifieke Windows-computer en alleen door dat specifieke gatewayserviceaccount.

  Wanneer een gebruiker gegevensbronreferenties invoert in de gebruikersinterface van Power BI-service, worden de referenties versleuteld met de openbare sleutel in de browser. De gateway ontsleutelt de referenties met behulp van de persoonlijke RSA-sleutel en versleutelt ze opnieuw met een AES-symmetrische sleutel voordat de gegevens worden opgeslagen in de Power BI-service. Met dit proces heeft de Power BI-service nooit toegang tot de niet-versleutelde gegevens.

Welke communicatieprotocollen worden gebruikt door de on-premises gegevensgateway en hoe worden deze beveiligd?

• De gateway ondersteunt de volgende twee communicatieprotocollen:

  • AMQP 1.0 – TCP + TLS: voor dit protocol zijn poorten 443, 5671-5672 en 9350-9354 geopend voor uitgaande communicatie. Dit protocol heeft de voorkeur, omdat het minder communicatieoverhead heeft.

  • HTTPS : WebSockets via HTTPS + TLS: dit protocol maakt alleen gebruik van poort 443. De WebSocket wordt geïnitieerd door één HTTP CONNECT-bericht. Zodra het kanaal tot stand is gebracht, is de communicatie in wezen TCP+TLS. U kunt afdwingen dat de gateway dit protocol gebruikt door een instelling te wijzigen die wordt beschreven in het artikel over de on-premises gateway.

Wat is de rol van Azure CDN in Power BI?

• Zoals eerder vermeld, gebruikt Power BI het Azure CdN (Content Delivery Network) om de benodigde statische inhoud en bestanden efficiënt te distribueren naar gebruikers op basis van geografische landinstellingen. Voor meer informatie gebruikt de Power BI-service meerdere CDN's om de benodigde statische inhoud en bestanden efficiënt te distribueren naar gebruikers via het openbare internet. Deze statische bestanden omvatten productdownloads (zoals Power BI Desktop, de on-premises gegevensgateway of Power BI-apps van verschillende onafhankelijke serviceproviders), browserconfiguratiebestanden die worden gebruikt voor het initiëren en tot stand brengen van eventuele volgende verbindingen met de Power BI-service, evenals de eerste beveiligde Power BI-aanmeldingspagina.

  Op basis van informatie die is verstrekt tijdens een initiële verbinding met de Power BI-service, neemt de browser van een gebruiker contact op met de opgegeven Azure CDN (of voor sommige bestanden, de WFE) om de verzameling opgegeven algemene bestanden te downloaden die nodig zijn om de interactie van de browser met de Power BI-service mogelijk te maken. De browserpagina bevat vervolgens het Microsoft Entra-token, sessiegegevens, de locatie van het bijbehorende back-endcluster en de verzameling bestanden die zijn gedownload van het Azure CDN- en WFE-cluster voor de duur van de Power BI-service browsersessie.

Voor Power BI-visuals voert Microsoft een beveiligings- of privacybeoordeling uit van de aangepaste visualcode voordat items in de galerie worden gepubliceerd?

• Nee Het is de verantwoordelijkheid van de klant om te controleren en te bepalen of aangepaste visuele code moet worden vertrouwd. Alle aangepaste visualcode wordt uitgevoerd in een sandbox-omgeving, zodat eventuele onjuiste code in een aangepaste visual de rest van de Power BI-service niet nadelig beïnvloedt.

Zijn er andere Power BI-visuals die informatie buiten het klantnetwerk verzenden?

• Ja. Bing Kaarten- en ESRI-visuals verzenden gegevens uit de Power BI-service voor visuals die gebruikmaken van deze services.

Voor sjabloon-apps voert Microsoft een beveiligings- of privacybeoordeling uit van de sjabloon-app voordat items in de galerie worden gepubliceerd?

• Nee De uitgever van de app is verantwoordelijk voor de inhoud, terwijl het de verantwoordelijkheid van de klant is om de uitgever van de sjabloon-app te controleren en te bepalen.

Zijn er sjabloon-apps die informatie buiten het netwerk van de klant kunnen verzenden?

• Ja. Het is de verantwoordelijkheid van de klant om het privacybeleid van de uitgever te controleren en te bepalen of de sjabloon-app op de tenant moet worden geïnstalleerd. De uitgever is verantwoordelijk voor het informeren van de klant over het gedrag en de mogelijkheden van de app.

Hoe zit het met gegevenssoevereine? Kunnen we tenants inrichten in datacenters die zich in specifieke geografische gebieden bevinden, om ervoor te zorgen dat gegevens het land of de regiogrenzen niet verlaten?

• Sommige klanten in bepaalde geografische gebieden hebben een optie om een tenant te maken in een nationale/regionale cloud, waarbij gegevensopslag en -verwerking gescheiden blijft van alle andere datacenters. Nationale/regionale clouds hebben een iets ander type beveiliging, omdat een afzonderlijke gegevensbeheerder de nationale/regionale cloud beheert Power BI-service namens Microsoft.

  Klanten kunnen ook een tenant instellen in een specifieke regio. Dergelijke tenants hebben echter geen afzonderlijke gegevensbeheerder van Microsoft. Prijzen voor nationale/regionale clouds verschillen van de algemeen beschikbare commerciële Power BI-service. Zie Nationale/regionale Clouds van Power BI voor meer informatie over Power BI-service beschikbaarheid voor nationale/regionale clouds.

Hoe behandelt Microsoft verbindingen voor klanten met Power BI Premium-abonnementen? Zijn deze verbindingen anders dan die voor de niet-Premium-Power BI-service?

• De verbindingen voor klanten met Power BI Premium-abonnementen implementeren een Autorisatieproces van Microsoft Entra business-to-business (B2B) met behulp van Microsoft Entra ID om toegangsbeheer en autorisatie in te schakelen. Power BI verwerkt verbindingen van Power BI Premium-abonnees met Power BI Premium-resources, net zoals elke andere Microsoft Entra-gebruiker.

Hoe werkt verificatie aan de serverzijde in de WFE?

• De verificatie aan de servicezijde van de gebruikersverificatiereeks vindt plaats zoals beschreven in de volgende stappen, die worden geïllustreerd in de afbeelding die erop volgt.

1. Een gebruiker initieert een verbinding met de Power BI-service vanuit een browser door het Power BI-adres in de adresbalk te typen of door Aanmelden te selecteren op de power BI-marketingpagina (https://powerbi.microsoft.com). De verbinding wordt tot stand gebracht via TLS 1.2 en HTTPS, en alle volgende communicatie tussen de browser en de Power BI-service maakt gebruik van HTTPS.

2. De Azure Traffic Manager controleert de DNS-record van de gebruiker om het meest geschikte (meestal dichtstbijzijnde) datacenter te bepalen waar Power BI wordt geïmplementeerd en reageert op de DNS met het IP-adres van het WFE-cluster waarnaar de gebruiker moet worden verzonden.

3. WFE leidt de gebruiker vervolgens om naar de aanmeldingspagina van Microsoft Online Services.

4. Nadat de gebruiker is geverifieerd, wordt de aanmeldingspagina de gebruiker omgeleid naar het eerder vastgestelde dichtstbijzijnd Power BI-service e WFE-cluster met een verificatiecode.

5. Het WFE-cluster controleert met De Microsoft Entra-id om een Microsoft Entra-beveiligingstoken te verkrijgen met behulp van de verificatiecode. Wanneer Microsoft Entra ID de geslaagde verificatie van de gebruiker retourneert en een Microsoft Entra-beveiligingstoken retourneert, raadpleegt het WFE-cluster de Globale Power BI-service, die een lijst met tenants en hun Power BI-back-endclusterlocaties onderhoudt en bepaalt welk Back-endservicecluster van Power BI de tenant van de gebruiker bevat. Het WFE-cluster retourneert vervolgens een toepassingspagina naar de browser van de gebruiker met de sessie-, toegangs- en routeringsgegevens die vereist zijn voor de bewerking.

6. Wanneer de browser van de client nu klantgegevens vereist, worden aanvragen verzonden naar het adres van het back-endcluster met het Microsoft Entra-toegangstoken in de autorisatieheader. Het Power BI-back-endcluster leest het Microsoft Entra-toegangstoken en valideert de handtekening om ervoor te zorgen dat de identiteit voor de aanvraag geldig is. Het Microsoft Entra-toegangstoken heeft een vervaldatum die is ingesteld op basis van het Microsoft Entra-beleid en om de huidige sessie te onderhouden, zal de Power BI-client in de browser van de gebruiker periodieke aanvragen indienen om het toegangstoken te vernieuwen voordat het verloopt.

Aanvullende bronnen

Zie de volgende bronnen voor meer informatie over Power BI.

• Aan de slag met Power BI Desktop
• Power BI REST API - Overzicht
• API van Power BI verwijzing
• On-premises gegevensgateway
• Nationale/regionale Clouds van Power BI
• Power BI Premium
• Overzicht van eenmalige aanmelding (SSO) voor gateways in Power BI