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, gegevenssets en visualisaties kunt maken. Met Power BI kunt u verbinding maken met veel verschillende gegevensbronnen, gegevens via deze verbindingen combineren en vormgeven, en vervolgens rapporten en dashboards maken die met anderen kunnen worden gedeeld.

Schrijvers: Yitzhak Hiermeeman, Paddy Osborne, Matt Neely, Tony Bencic, Srinivasan Turuvekere, Cristian Petculescu, Adi Regev, Naveen Sivaescu, 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, Jamie 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.

Introductie

Power BI is een online softwareservice-aanbod (SaaS of software als een dienst) van Microsoft waarmee u snel en eenvoudig selfservice Business Intelligence-dashboards, -rapporten, -gegevenssets en -visualisaties (BI) kunt maken. Met Power BI kunt u verbinding maken met veel verschillende gegevensbronnen, gegevens via 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 grotere vraag van klanten naar onlineservices en meer gebruik van geavanceerde technologieën in bewerkingen en zakelijke besluitvorming. En dit alles wordt mogelijk gemaakt door de cloud.

Naarmate de overgang naar de cloud is veranderd van een overloop naar een stroom, en met het nieuwe, blootgestelde oppervlaktegebied dat eraan wordt geleverd, vragen meer en 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 lekken? En voor de BI-platformen die vaak een aantal van de meest strategische informatie in de onderneming verwerken, zijn deze vragen dubbel belangrijk.

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

Power BI is gebouwd om toonaangevende complete 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 beveiligingsinstellingen, financiële instellingen en zorgverleners het vertrouwd met hun meest gevoelige informatie.

Het begint allemaal met de basis. Na een ruwe periode in het begin van de jaren 2000 heeft Microsoft enorme investeringen gedaan om de beveiligingsproblemen aan te pakken en in de volgende decennia heeft een zeer sterke beveiligingsstack gebouwd die zo diep gaat als de machine on-chip bios kernel en zich uitbreidt tot eindgebruikerservaringen. Deze diepgaande investeringen worden voortgezet en vandaag zijn er 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 toegewezen 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 zeer sterke basis. Het maakt gebruik van dezelfde beveiligingsstack die Azure het recht heeft verdiend om de meest gevoelige gegevens ter wereld te bedienen en te beschermen, en kan worden geïntegreerd met de meest geavanceerde hulpprogramma's voor gegevensbescherming en naleving van Microsoft 365. Bovendien biedt het beveiliging door middel van 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 oplossen op meerdere gelijktijdige fronten:

• Hoe bepalen we wie verbinding kan maken, waar ze verbinding mee kunnen maken en hoe ze verbinding kunnen maken?Hoe kunnen we de verbindingen beheren?
• Hoe worden de gegevens opgeslagen?Hoe wordt het versleuteld?Welke besturingselementen heb ik op 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 is onderworpen aan de Microsoft Online Services-voorwaarden en de Microsoft Enterprise-privacyverklaring. Raadpleeg voor de locatie van gegevensverwerking de voorwaarden voor gegevensverwerking in de voorwaarden voor Microsoft Online Services en de invoegtoepassing gegevensbescherming. Het Microsoft Vertrouwenscentrum is de primaire resource voor nalevingsinformatie met betrekking tot Power BI. Het Power BI-team doet er alles aan om klanten de nieuwste innovaties en productiviteit te bieden. Meer informatie over naleving in de Microsoft-complianceaanbiedingen.

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 de ernst van beveiligingsproblemen in software te verminderen, terwijl de ontwikkelingskosten worden verminderd. Meer informatie vindt u in de levenscyclusprocedures van Microsoft Security Development.

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. Daarnaast zijn er even veel passieve implementaties, die als back-up fungeren voor alle actieve implementaties.

Web-front-endcluster (WFE)

Het WFE-cluster biedt de browser van de gebruiker met de initiële inhoud van de HTML-pagina bij het laden van de site en beheert het initiële verbindings- en verificatieproces voor Power BI, met behulp van Azure Active Directory (Azure AD) om clients te verifiëren en tokens te bieden voor volgende clientverbindingen met de Power BI-back-endservice.

Een WFE-cluster bestaat uit een ASP.NET website die wordt uitgevoerd in de Azure App Service-omgeving. 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.

Het WFE-cluster dat aan de gebruiker is toegewezen, beheert de aanmeldings- en verificatiereeks (verderop in dit artikel beschreven) en verkrijgt een Azure AD toegangstoken zodra de verificatie is geslaagd. Het ASP.NET onderdeel in het WFE-cluster parseert het token om te bepalen tot welke organisatie de gebruiker behoort en raadpleegt vervolgens de globale Power BI-service. De WFE geeft aan de browser op welk back-endcluster de tenant van de organisatie bevat. Zodra een gebruiker is geverifieerd, vinden volgende clientinteracties voor klantgegevens rechtstreeks plaats met het back-end- of Premium-cluster, zonder dat de WFE een tussenmediator voor deze aanvragen is.

Statische resources zoals *.js, *.css en afbeeldingsbestanden worden meestal opgeslagen in Azure Content Delivery Network (CDN) en rechtstreeks opgehaald door de browser. Houd er rekening mee dat soevereine overheidsclusterimplementaties een uitzondering zijn op deze regel en om nalevingsredenen het CDN weglaten en in plaats daarvan een WFE-cluster gebruiken vanuit een compatibele regio 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 webfront-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 ze beschikbaar komen. Eén Azure-regio fungeert als host voor 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 door de webfront-end gebruikt 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 passief op een ander moment.

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:

• Gatewayservice
• Azure API Management

Power BI Premium-infrastructuur

Power BI Premium biedt een service voor abonnees die premium Power BI-functies nodig hebben, zoals gegevensstromen, gepagineerde rapporten, AI, enzovoort. Wanneer een klant zich registreert voor een Power BI Premium-abonnement, wordt de Premium-capaciteit gemaakt via de 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 verschillende manieren worden uitgevoerd, afhankelijk van het gebruikersscenario. Power BI Premium-clients kunnen de browser van een gebruiker zijn, een gewone 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 (minimaal één). Het merendeel van de Premium-resources wordt 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 maken een snelle en pijnloze toename van rekenknooppunten mogelijk naarmate het gebruik groeit en de implementatie, het beheer en de bewaking van Power BI Premium services en toepassingen organiseert.

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. Elke verificatie wordt uitgevoerd via integratie met Azure AD uitsluitend.

Elke aanvraag die betrekking heeft op 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 Power BI Premium mogelijkheden en functies.

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 technisch document worden beschreven. Met de mobiele Power BI-toepassingen voor iOS en Android wordt een browsersessie binnen de toepassing zelf geopend, terwijl de mobiele Windows-app een broker biedt 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 de service)	Ondersteund	Ondersteund	Niet ondersteund
SSRS ADFS on-premises (verbinding maken met SSRS-server)	Niet ondersteund	Ondersteund	Niet ondersteund
SSRS-appproxy	Ondersteund	Ondersteund	Niet ondersteund

Power BI Mobile-apps communiceren actief met de Power BI-service. Telemetrie wordt gebruikt om gebruiksstatistieken van mobiele apps en vergelijkbare gegevens te verzamelen, 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 vergemakkelijkt:

• Azure AD 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 Behulp van 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 door de gebruiker expliciet ingeschakeld of uitgeschakeld. Indien ingeschakeld, worden geolocatiegegevens niet opgeslagen op het apparaat en worden ze niet gedeeld met Microsoft.
• Meldingen worden expliciet ingeschakeld 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 mobile device and application management biedt. Alle drie de platforms waarvoor Power BI - Mobiel beschikbaar is, bieden ondersteuning Intune. Als Intune is ingeschakeld en geconfigureerd, worden gegevens op het mobiele apparaat versleuteld en kan de Power BI-app niet op een SD-kaart worden geïnstalleerd. 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 Azure Active Directory Authentication Library (ADAL) SDK.

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 het token of het wijzigen van het wachtwoord). De gegevenscache bevat dashboards en rapporten die eerder zijn geopend vanuit de Power BI Mobile-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 voor de Power BI-service

De 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 worden gebruikt door Power BI. Deze reeks beschrijft het proces van gebruikersverificatie in Power BI, dat volgt op de stroom voor verificatiecode van Azure Active Directory. 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 landingspagina van Power BI (https://powerbi.microsoft.com). De verbinding wordt tot stand gebracht met behulp van TLS 1.2 en HTTPS, en bij alle verdere communicatie tussen de browser en de Power BI-service wordt HTTPS gebruikt.

2. Azure Traffic Manager controleert de DNS-record van de gebruiker om het meest geschikte (meestal dichtstbijzijnde) datacenter te bepalen waar Power BI is 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, leidt de aanmeldingspagina de gebruiker om naar het eerder vastgestelde dichtstbijzijnde Power BI-service WFE-cluster met een verificatiecode.

5. Het WFE-cluster controleert met de Azure AD-service om een Azure AD beveiligingstoken te verkrijgen met behulp van de verificatiecode. Wanneer Azure AD de geslaagde verificatie van de gebruiker retourneert en een Azure AD 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 Power BI-back-endservicecluster 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 back-endclusteradres met het Azure AD toegangstoken in de autorisatieheader. Het Back-endcluster van Power BI leest het Azure AD toegangstoken en valideert de handtekening om ervoor te zorgen dat de identiteit voor de aanvraag geldig is. Het Azure AD toegangstoken heeft een standaardlevensduur van 1 uur en om de huidige sessie te onderhouden, zal de browser van de gebruiker periodieke aanvragen indienen om het toegangstoken te vernieuwen voordat het verloopt.

Gegevenslocatie

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

De toewijzing van een Azure-geografie voor tenantgegevensopslag wordt uitgevoerd door het land of de regio die is geselecteerd als onderdeel van de Azure AD tenantconfiguratie 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 de thuis geo genoemd), behalve in gevallen waarin organisaties gebruikmaken van implementaties met meerdere geografische gebieden.

Meerdere geografische gebieden (meerdere geografische gebieden)

Sommige organisaties hebben een wereldwijde aanwezigheid en vereisen mogelijk Power BI-services 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 voorschriften. Deze functie van de Power BI-service wordt multi-geo genoemd.

De uitvoeringslaag voor query's, querycaches en artefactgegevens die zijn toegewezen aan een werkruimte met meerdere geografische gebieden, worden gehost en blijven in de geografische locatie van Azure voor externe capaciteit. 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 geografische locatie van de tenant, zelfs voor werkruimten die worden gehost in een Premium-capaciteit met meerdere geografische gebieden.

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-services zijn beschikbaar in specifieke Azure-geografische gebieden, zoals beschreven in het Vertrouwenscentrum van Microsoft. Raadpleeg het Vertrouwenscentrum van Microsoft voor meer informatie over waar uw gegevens worden opgeslagen en hoe deze worden gebruikt. Toezeggingen met betrekking tot de locatie van data-at-rest worden opgegeven in de voorwaarden voor gegevensverwerking van de Voorwaarden voor Microsoft Online Services.

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

Gegevensverwerking

In deze sectie worden de procedures voor het verwerken van Power BI-gegevens beschreven 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 de 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 gegevensset worden geïmporteerd. Deze methode wordt vaak beschreven als Bring Your Own Key (BYOK). Door BYOK te gebruiken, zorgt u ervoor dat zelfs in het geval van een fout van een serviceoperator, klantgegevens niet 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.

Power BI-gegevenssets bieden verschillende verbindingsmodi voor gegevensbronnen die bepalen of de gegevensbrongegevens al dan niet in de service worden bewaard.

Gegevenssetmodus (soort)	Gegevens behouden in Power BI
Importeren	Yes
Direct Query	No
Live Connect	No
Composite	Als deze een gegevensbron importeren bevat
Streaming	Als deze is geconfigureerd om te behouden

Ongeacht de gegevenssetmodus die wordt gebruikt, kan Power BI tijdelijk alle opgehaalde gegevens in de cache opslaan om query- en rapportbelastingprestaties 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 aanraakt. 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 workload.

Actieve gegevens

Voor Power BI moet al het binnenkomende HTTP-verkeer worden versleuteld met TLS 1.2 of hoger. Aanvragen die de service willen gebruiken met TLS 1.1 of lager, worden geweigerd.

Verificatie voor gegevensbronnen

Wanneer een gebruiker verbinding maakt met een gegevensbron, kan een gebruiker ervoor kiezen om een kopie van de gegevens in Power BI te importeren of rechtstreeks verbinding te 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 de gegevensset 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, hebben de gegevens in rapporten en dashboards geen toegang tot de onderliggende gegevensbron. Power BI ondersteunt verificatie voor eenmalige aanmelding voor geselecteerde gegevensbronnen. Als de verbinding is geconfigureerd voor gebruik van eenmalige aanmelding, worden de referenties van de eigenaar van de gegevensset 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 OLS (Row Level Security) en/of objectniveaubeveiliging (OLS) worden geïmplementeerd in de gegevensbron. Hierdoor kunnen gebruikers alleen gegevens weergeven die ze toegangsrechten hebben. Wanneer de verbinding is met gegevensbronnen in de cloud, wordt Azure AD verificatie gebruikt voor eenmalige aanmelding; voor on-premises gegevensbronnen, Kerberos, Security Assertion Markup Language (SAML) en Azure AD worden ondersteund.

Als de gegevensbron is Azure Analysis Services of on-premises Analysis Services en RLS en/of OLS is geconfigureerd, worden de Power BI-service die beveiliging op rijniveau toegepast 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 ze onvoldoende bevoegdheden hebben.

Premium-functies

Architectuur van gegevensstromen

Gegevensstromen bieden gebruikers de mogelijkheid om back-endgegevensverwerkingsbewerkingen te configureren waarmee gegevens uit polymorfe gegevensbronnen worden geëxtraheerd, transformatielogica worden uitgevoerd op basis van de gegevens en deze vervolgens in een doelmodel kunnen worden geplaatst 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. Zodra een gegevensstroom is gemaakt, kunnen leden, inzenders of beheerders 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 nodig zijn voor toegang tot deze referenties, wordt gevormd om overeen te komen met de vereiste implementatiedetails van de gegevensbron. Transformatielogica wordt toegepast door Power Query services terwijl de gegevens onderweg zijn. 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 naar de gateway wordt opgehaald, gebruikt het transport, indien van toepassing, beveiligingsmethodologie die specifiek is voor de clienttechnologie. Wanneer gegevens worden overgedragen van de gateway naar de cloudservice, worden deze versleuteld. Zie de sectie Gegevens in verwerking hierboven.

Wanneer door de klant opgegeven gegevensbronnen referenties vereisen voor toegang, geeft de eigenaar/maker van de gegevensstroom deze tijdens het ontwerpen op. Ze worden opgeslagen met standaardreferentieopslag voor het hele product. Zie de sectie Verificatie voor gegevensbronnen hierboven. Er zijn verschillende methoden die gebruikers kunnen configureren om gegevenspersistentie en toegang te optimaliseren. Standaard worden de gegevens in een power BI-opslagaccount in eigendom en beveiligd geplaatst. Opslagversleuteling is ingeschakeld op de Blob Storage-containers om de gegevens te beveiligen terwijl deze 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. Wanneer u dit doet, krijgt een Power BI-service-principal toegang tot dat opslagaccount, zodat de gegevens daar tijdens het vernieuwen kunnen worden geschreven. 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 de prestaties bij het openen van opslagaccounts mogelijk suboptimaal zijn voor sommige gegevens, hebben gebruikers ook de mogelijkheid om een door Power BI gehoste compute-engine 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. Al het secundaire of indirecte gebruik van DirectQuery wordt beheerd door dezelfde toegangsbeheeropties die eerder zijn beschreven. Omdat gegevensstromen altijd zijn gebonden aan een werkruimte, wordt de toegang tot de gegevens altijd beperkt door de rol van de gebruiker in die werkruimte. Een gebruiker moet ten minste leestoegang hebben om de gegevens op elk gewenst moment op te vragen.

Wanneer Power BI Desktop wordt gebruikt voor toegang tot gegevens in een gegevensstroom, moet de gebruiker eerst worden geverifieerd met behulp van Azure AD 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 pijplijn verzendt Office 365 controle-gebeurtenissen. Sommige van deze gebeurtenissen leggen beveiligings- en privacygerelateerde bewerkingen vast.

Gepagineerde rapporten

Gepagineerde rapporten zijn ontworpen om te worden afgedrukt of gedeeld. Ze worden gepagineerd genoemd, omdat ze zo zijn opgemaakt dat ze op een pagina passen. Alle gegevens worden in een tabel weergegeven, zelfs als de tabel meerdere pagina's omvat. Ze worden soms pixelperfect genoemd, omdat de pagina-indeling van dit type rapport exact kan worden ingesteld.

Gepagineerde rapporten ondersteunen uitgebreide en krachtige expressies die zijn geschreven in Microsoft Visual Basic .NET. Expressies worden op grote schaal in gepagineerde rapporten van Power BI Report Builder gebruikt voor het ophalen, berekenen, weergeven, groeperen, sorteren en filteren van gegevens, om parameters aan gegevens toe te wijzen en om gegevens op te maken.

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 verifiëren en autoriseren op dezelfde manier als beschreven in de sectie Verificatie voor de Power BI-service hierboven.

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

Voor Premium Gen1 bestaat er één sandbox per één van de capaciteiten van de tenant en wordt gedeeld door de werkruimten die zijn toegewezen aan de capaciteit.

Voor Premium Gen2 wordt een individuele en exclusieve tijdelijke sandbox gemaakt voor elk van de renders van een rapport, waardoor een hoger isolatieniveau tussen gebruikers wordt geboden.

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 oproepen 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 is 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 insluitscenario voor uw organisatie hebben Azure AD 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 OLS (Object Level Security) 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-artefacten (dashboards, rapporten, gegevenssets, enzovoort). 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 naar de eindgebruikers volgens de bedrijfslogica van de ISV. Eindgebruikers die een browser of andere clienttoepassingen gebruiken, kunnen invoegtokens 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 tijdens de generatie is opgegeven door de ISV.

Als u insluiten en automatiseren wilt inschakelen en de hierboven beschreven insluittokens wilt genereren, maakt Power BI een uitgebreide set REST API's beschikbaar. Deze Power BI REST API's ondersteunen zowel gebruikers gedelegeerd als service-principal Azure AD methoden voor verificatie en autorisatie.

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

AI-functies

Power BI ondersteunt momenteel twee brede categorieën AI-functies in het product: AI-visuals en AI-verrijkingen. De AI-functies op visualniveau omvatten mogelijkheden zoals Key-Influencers, Decomposition-Tree, Smart-Narrative, Anomaly-Detection, R-visual, Python-visual, Clustering, Forecasting, Q&A, Quick-Insights, enzovoort. De AI-verrijkingsmogelijkheden omvatten mogelijkheden zoals AutoML, AzureML, CognitiveServices, R/Python transformaties, enzovoort.

De meeste hierboven genoemde functies worden momenteel ondersteund in zowel Gedeelde als Premium-werkruimten. AutoML en CognitiveServices worden echter alleen ondersteund in Premium-werkruimten vanwege IP-beperkingen. Tegenwoordig kan een gebruiker met de AutoML-integratie in Power BI een aangepast ML-model bouwen en trainen (bijvoorbeeld Voorspelling, Classificatie, Regressie, enzovoort) en deze toepassen om voorspellingen te krijgen 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/gegevensset die 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 Power BI-gegevensset of -gegevensstroom. Houd er rekening mee dat deze functies ook kunnen worden geopend vanuit de huidige omgevingen voor het ontwerpen van gegevensstromen/gegevenssets 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 Azure AD token is vereist voor de Power BI-gebruiker die de AI-functie gebruikt. Deze AI-gegevensbronnen zijn speciaal omdat ze geen van hun eigen gegevens weergeven en ze leveren alleen deze functies/transformaties. Tijdens de uitvoering voeren deze functies geen uitgaande aanroepen naar andere services uit 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 Experimenten AzureML-service aan om een geschikt model en hyperparameters voor de huidige iteratie te selecteren. In deze uitgaande aanroep worden alleen relevante experimentmetagegevens (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 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 gegevenssets. Tijdens het ontwerpen van een gegevensset in Power BI Desktop hebben gebruikers alleen toegang tot deze functionaliteit als ze toegang hebben tot een Premium Power BI-werkruimte. Klanten wordt daarom gevraagd om hun Azure AD 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 besturingselementen voor netwerktoegang 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 zijn omvat door de servicetag en werkt de servicetag automatisch bij wanneer adressen worden gewijzigd.

Private Link-integratie

Azure-netwerken bieden de Azure Private Link functie waarmee Power BI beveiligde toegang kan bieden via privé-eindpunten van Azure-netwerken. 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 wordt doorgestuurd naar een privé-eindpunt voor Azure-cloudresources.
• Netwerkverkeerisolatie 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, zorgt de VNet-connectiviteitsfunctie ervoor dat uitgaande connectiviteit van Power BI naar gegevensbronnen in een VNet wordt ingeschakeld.

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 binnen 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 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 Key Vault, wijs het juiste toegangsbeleid toe aan de kluis en controleer regelmatig de toegangsmachtigingen.

Zie Taken voor De Premium-werkruimte en gegevensset automatiseren met service-principals voor meer informatie.

Microsoft Purview voor Power BI

Microsoft Purview Informatiebeveiliging

Power BI is nauw geïntegreerd met Microsoft Perview Information Protection (voorheen Microsoft 365 Compliance Information Protection). 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 behulp van dezelfde vertrouwelijkheidslabels die worden gebruikt in Office en in Azure.
• 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 in Power BI Desktop te classificeren en te beveiligen, 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 vertrouwelijke zakelijke 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 Power BI-gegevenssets 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 van classificatie en beveiliging 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 gegevenssets of datamarts in de Power BI-service worden toegepast op nieuwe inhoud die bovenop deze gegevenssets 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 gegevensset of datamart wordt toegepast of gewijzigd, het label automatisch wordt toegepast of gewijzigd op alle downstream-inhoud die is verbonden met de gegevensset of datamart.

Zie Vertrouwelijkheidslabels in Power BI voor meer informatie.

beleid voor Microsoft Purview-preventie van gegevensverlies (DLP) 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 te voldoen aan de nalevingsvereisten van overheids- of branchevoorschriften, zoals DE 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 gegevenssets 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 gegevensset tegenkomt die als gevoelig is geïdentificeerd, ziet u een aangepaste beleidstip waarmee u begrijpt wat u moet doen.
• Als u eigenaar van een gegevensset bent, kunt u een beleid overschrijven en voorkomen dat uw gegevensset wordt geïdentificeerd als 'gevoelig' als u hiervoor een geldige reden hebt.
• Als u eigenaar van een gegevensset 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, kunnen worden aangeroepen.

Zie Preventiebeleid voor gegevensverlies voor Power BI voor meer informatie.

Microsoft Defender for Cloud Apps voor Power BI

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

Met Defender for 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, kan de sessie worden bewaakt door de realtime besturingselementen van Defender voor Cloud Apps en riskante acties, zoals het downloaden van gegevens die zijn getagd met een vertrouwelijkheidslabel zeer vertrouwelijk, 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 labels. Beheerders kunnen gebruikmaken van de geavanceerde filters en snelle acties van Defender for Cloud Apps voor effectief probleemonderzoek.
• Maak aangepast beleid om waarschuwingen te geven over verdachte gebruikersactiviteiten in Power BI. De beleidsfunctie voor Defender voor Cloud 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 kan ondernemen als het te gevaarlijk lijkt.
• Werken met de ingebouwde anomaliedetectie van Defender for 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 beleid voor anomaliedetectie een verdacht gedrag identificeert, wordt er een beveiligingswaarschuwing geactiveerd.
• Power BI-beheerdersrol in de Defender for Cloud Apps-portal. Defender for Cloud Apps biedt een app-specifieke beheerdersrol die kan worden gebruikt om Power BI-beheerders alleen de machtigingen te verlenen die ze nodig hebben om toegang te krijgen tot Power BI-relevante gegevens in de portal, zoals waarschuwingen, gebruikers die risico lopen, activiteitenlogboeken en andere informatie met betrekking tot Power BI.

Zie Using Microsoft Defender for Cloud Apps Controls in Power BI (Besturingselementen gebruiken in Power BI) voor meer informatie.

Preview van beveiligingsfuncties

Dit onderwerp bevat functies die tot en met maart 2021 zijn gepland voor release. Omdat in dit onderwerp functies worden vermeld die mogelijk nog niet zijn uitgebracht, kunnen leveringstijdlijnen worden gewijzigd en kunnen 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, interactieve querytaal en ingebouwde machine learning-constructies.

Power BI-beveiligingsvragen en -antwoorden

De volgende vragen zijn algemene 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 gegevensbronnen en hoe worden deze geopend 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 gegevensset mag de gebruiker een referentie selecteren in hun persoonlijke archief of een on-premises gegevensgateway gebruiken om een gedeelde referentie te gebruiken.

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

  Voor rapporten die zijn verbonden met DirectQuery, wordt de gegevensbron rechtstreeks verbonden met behulp van 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 in de gegevensbron. Hierdoor kunnen gebruikers gegevens bekijken die ze toegangsrechten hebben. Wanneer de verbinding met gegevensbronnen in de cloud is, wordt Azure AD verificatie gebruikt voor eenmalige aanmelding. Voor on-premises gegevensbronnen worden Kerberos, SAML en Azure AD ondersteund.

  Wanneer de gebruiker verbinding maakt met Kerberos, wordt de UPN van de gebruiker doorgegeven aan de gateway en wordt de beperkte Kerberos-overdracht 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 is Azure Analysis Services of on-premises Analysis Services and Row Level Security (RLS) en/of beveiliging op objectniveau (OLS) is geconfigureerd, wordt die beveiliging op rijniveau toegepast op de Power BI-service en zien gebruikers die niet over voldoende referenties beschikken om toegang te krijgen tot de onderliggende gegevens (een query die kan worden 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 echter 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 gegevenssets, zodat alleen gebruikers met de vereiste machtigingen toegang hebben om gevoelige gegevens weer te geven en ermee te werken.

Hoe worden gegevens overgedragen 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 HTTPS ondersteunt) om vanuit de gegevensbron verbinding te maken met de Power BI-service. Er wordt een beveiligde verbinding met de gegevensprovider gemaakt en de gegevens stromen pas in het netwerk nadat de verbinding tot stand is gebracht.

Hoe worden rapporten, dashboards of modelgegevens in Power BI opgeslagen en zijn deze veilig?

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

Worden gegevens van webpagina's lokaal opgeslagen door clients?

• Wanneer browserclients Power BI openen, stellen de webservers van Power BI de instructie Cache-Control in op no-store. De instructie no-store geeft browsers de opdracht om de webpagina die door de gebruiker wordt bekeken niet op te slaan in de cache of in de cachemap van de client.

Hoe zit het met beveiliging op basis van rollen, het delen van rapporten of dashboards en gegevensverbindingen? Hoe werkt dat met betrekking tot gegevenstoegang, dashboardweergave, toegang tot rapporten en vernieuwen?

• Voor niet-RLS ingeschakelde gegevensbronnen geldt dat wanneer een dashboard, rapport of gegevensmodel wordt gedeeld met andere gebruikers via Power BI, de gegevens beschikbaar zijn voor gebruikers waarmee deze worden gedeeld voor weergave en gebruik. Power BI verifieert gebruikers niet opnieuw aan de hand van de oorspronkelijke bron van de gegevens; zodra de gegevens zijn geüpload naar Power BI, is de gebruiker die is geverifieerd aan de hand van de brongegevens verantwoordelijk voor de toegang tot de gegevens door gebruikers en groepen.

  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 gegevensset wordt weergegeven of geopend in Power BI die gebruikmaakt van gegevens uit de RLS-compatibele gegevensbron, opent de Power BI-service de gegevensbron om gegevens op te halen op basis van de referenties van de gebruiker. Als de gebruiker voldoende machtigingen heeft, worden de gegevens geladen in het rapport of gegevensmodel voor de gebruiker. Als de verificatie mislukt, wordt een fout weergegeven.

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

Onze gebruikers maken telkens verbinding met dezelfde gegevensbronnen en voor sommige gegevensbronnen zijn andere referenties nodig dan de domeinreferenties. Hoe kunnen ze voorkomen dat ze deze referenties telkens opnieuw moeten opgeven wanneer ze verbinding maken?

• Power BI ondersteunt de Power BI Personal Gateway. Hiermee kunnen gebruikers referenties voor meerdere verschillende gegevensbronnen maken en deze referenties vervolgens automatisch gebruiken voor toegang tot een van deze gegevensbronnen. Zie Power BI Personal Gateway voor meer informatie.

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

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

Als u werkt met de on-premises gegevensgateway, hoe worden herstelsleutels gebruikt en waar worden deze opgeslagen? Hoe zit het met het beveiligde referentiebeheer?

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

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

  Wanneer een gebruiker referenties van de gegevensbron invoert in de gebruikersinterface van de 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. Door 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 zijn 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 vereist voor uitgaande communicatie. Dit protocol heeft de voorkeur vanwege de lagere overhead aan communicatie.

  • HTTPS – WebSockets via HTTPS + TLS: dit protocol maakt alleen gebruik van poort 443. De WebSocket wordt geïnitieerd door één HTTP CONNECT-bericht. Nadat het kanaal is ingesteld, is de communicatie in feite 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 Content Delivery Network (CDN) om de benodigde statische inhoud en bestanden op een efficiënte manier te distribueren naar gebruikers op basis van geografische landinstelling. Specifieker gezegd, de Power BI-service maakt gebruik van meerdere CDN's om de benodigde statische inhoud en bestanden op een efficiënte manier te distribueren naar gebruikers via het openbare internet. Deze statische bestanden bevatten productdownloads (zoals Power BI Desktop, de on-premises gegevensgateway of Power BI-apps van verschillende onafhankelijke serviceproviders), browserconfiguratiebestanden die worden gebruikt om volgende verbindingen met de Power BI-service te initiëren en tot stand te brengen, en de eerste, beveiligde Power BI-aanmeldingspagina.

  Op basis van informatie die tijdens een eerste verbinding met de Power BI-service wordt opgegeven, neemt de browser van een gebruiker contact op met de opgegeven Azure CDN (of voor bepaalde bestanden de WFE) voor het downloaden van de verzameling opgegeven algemene bestanden die nodig zijn voor de interactie van de browser met de Power BI-service. De browserpagina bevat vervolgens het Azure AD token, sessiegegevens, de locatie van het gekoppelde 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 visuele code voordat items naar de galerie worden gepubliceerd?

• Nee. Het is de verantwoordelijkheid van de klant om te controleren en te bepalen of aangepaste visualcode betrouwbaar is. Alle aangepaste visualcode wordt in een sandbox-omgeving uitgevoerd zodat eventuele onjuiste code in een aangepaste visual geen nadelige invloed heeft op de rest van de Power BI-service.

Zijn er andere Power BI-visuals waarmee gegevens buiten het klantnetwerk worden verzenden?

• Ja. Met Bing Maps- en ESRI-visuals worden gegevens buiten de Power BI-service verzonden 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 of deze moet worden vertrouwd.

Zijn er sjabloon-apps die informatie buiten het klantnetwerk 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 in 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 onafhankelijkheid van gegevens? Kunnen er tenants in datacenters op specifieke locaties worden ingericht zodat de gegevens niet over de landsgrenzen gaan?

• Sommige klanten in bepaalde geografische gebieden hebben de mogelijkheid om een tenant te maken in een nationale cloud waar de opslag en verwerking van gegevens gescheiden blijft van alle andere datacenters. De beveiliging van nationale clouds is iets anders omdat een afzonderlijke gegevensbeheerder namens Microsoft de nationale cloud met de Power BI-service uitvoert.

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

Hoe gaat Microsoft om met verbindingen voor klanten met Power BI Premium-abonnementen? Zijn dit andere verbindingen dan de verbindingen die zijn ingesteld voor de niet-Premium Power BI-service?

• De verbindingen voor klanten met Power BI Premium abonnementen implementeren een B2B-autorisatieproces (Azure Business-to-Business) met behulp van Azure AD om toegangsbeheer en autorisatie in te schakelen. Verbindingen met Power BI Premium-resources van Power BI Premium-abonnees worden met Power BI net zo afgehandeld als voor elke andere Azure AD-gebruiker.

Aanvullende resources

Raadpleeg de volgende resources voor meer informatie over Power BI.

• Getting Started with Power BI Desktop (Aan de slag met Power BI Desktop)
• Overzicht van de REST API voor Power BI
• Naslag voor API van Power BI
• On-premises data gateway (On-premises gegevensgateway)
• Power BI National Clouds
• Power BI Premium
• Overzicht van eenmalige aanmelding (SSO) voor gateways in Power BI