Power BI document over 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 Kesselman, Moet Osborne, Matt Neely,Bare Bencic, Srinivasan Thouvekere, Cristian Petculescu, Adi Regev, Naveen Sivararra, Ben Glastein, Evgeny Tshiorny, Arthi Balksubramanian Iyer, Sid Jayadevan,Ava Chang, Ori Eduar, Pads, Idan Sheinberg, Ron Recad, Sagiv Hadhim, Paul Inbar, Igor Uzhmingv, MichaelNell, Jaime Tarchoro, Gennady Pats, Orion Lee, Yury Bereezsky, Maya Shenhav, Romit Chattopadhyhav, Yariv Pseudodan Crivat

Technische revisoren: Cristian Petculescu, Amir Netz, Moeti Gundorov

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

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 maken een versnelde digitale transformatie door en we zien een enorme toename in werken op afstand, een toegenomen vraag van klanten naar onlineservices en een toenemend gebruik van geavanceerde technologieën in bewerkingen en zakelijke besluitvorming. En dit alles is powered by de cloud.

Naarmate de overgang naar de cloud is veranderd van een lastige in een overstroming, en met de nieuwe, beschikbaar te maken surface area die bij de cloud hoort, vragen steeds meer bedrijven zich af hoe veilig mijn gegevens in de cloud zijn en Welke end-to-end-beveiliging is er beschikbaar om te voorkomen dat mijn gevoelige gegevens lekken? 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 basis van het BI-beveiligingsmodel ( beveiliging op object- en rijniveau) zijn nog steeds belangrijk, maar zijn 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, multi-tiered, 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 vertrouwen veel nationale beveiligingsinstanties, financiële instellingen en gezondheidszorgverleners het product met hun meest gevoelige informatie.

Het begint allemaal met de basis. Na een ruwe periode aan het begin van de jaren 2000 heeft Microsoft enorme investeringen gedaan om beveiligingsproblemen op te pakken. In de volgende decennia heeft Microsoft een zeer sterke beveiligingsstack gebouwd die net zo diep gaat als de bioskernel van de machine op de chip en zich uitbreidt naar de ervaringen van eindgebruikers. Deze diepgaande investeringen worden voortgezet en vandaag de dag zijn meer dan 3500 Microsoft-technici betrokken bij het bouwen en verbeteren van de beveiligingsstack van Microsoft en het proactief aanpakken van het steeds opnieuw veranderende bedreigingslandschap. Met miljarden computers, biljoenen aanmeldingen en talloze zettabytes aan informatie die de bescherming van Microsoft garanderen, beschikt het bedrijf nu over de meest geavanceerde beveiligingsstack in de tech-industrie en wordt het algemeen gezien als de wereldwijde leider in de strijd tegen kwaadwillende actoren.

Power BI is gebaseerd 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 dienen en te beveiligen, en kan worden geïntegreerd met de meest geavanceerde hulpprogramma's voor gegevensbeveiliging en naleving van Microsoft 365. Bovendien biedt het beveiliging met meerdere lagen, wat resulteert in end-to-end-beveiliging die is ontworpen om de unieke uitdagingen van het cloudtijdperk het hoofd te bieden.

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

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

Dit artikel biedt 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 door de service kunnen worden op- en verplaatst. In de laatste sectie worden de beveiligingsfuncties besproken waarmee u als servicebeheerder uw waardevolste assets kunt beveiligen.

De Power BI-service is onderworpen aan de Microsoft Online Services-voorwaarden en de Microsoft Enterprise-privacyverklaring. Voor de locatie van gegevensverwerking raadpleegt u de voorwaarden locatie van gegevensverwerking in de Microsoft Voorwaarden voor Online Diensten en naar de gegevensbeschermingsinvoegteken. 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-nalevingsaanbiedingen.

De Power BI-service volgt de Security Development Lifecycle (SDL), strikte beveiligingsprocedures die ondersteuning bieden voor beveiligingsgarantie- en nalevingsvereisten. De SDL helpt ontwikkelaars veiligere software te bouwen door het aantal en de ernst van beveiligingsproblemen in software te verminderen en tegelijkertijd de ontwikkelingskosten te verlagen. Meer informatie op Microsoft Security Development Lifecycle Practices.

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 de initiële inhoud van de HTML-pagina bij het laden van de site en beheert het eerste verbindings- en verificatieproces voor Power BI, met behulp van Azure Active Directory (Azure AD) voor het verifiëren van clients en het leveren van tokens voor volgende clientverbindingen met de Power BI-back-endservice.

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

Het WFE-cluster dat is toegewezen aan de gebruiker beheert de aanmeldings- en verificatievolgorde (zoals verderop in dit artikel wordt beschreven) en verkrijgt een Azure AD-toegangsteken 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 Power BI Global Service. De WFE geeft aan de browser aan in welk back-endcluster de tenant van de organisatie is opgeslagen. Zodra een gebruiker is geverifieerd, vinden volgende clientinteracties voor klantgegevens rechtstreeks plaats met de back-end of het Premium-cluster, zonder dat de WFE een intermediator voor deze aanvragen is.

Statische resources zoals .js,.css en afbeeldingsbestanden worden voornamelijk opgeslagen in Azure Content Delivery Network (CDN) en rechtstreeks opgehaald door de browser. Houd er rekening mee dat clusterimplementaties van onafhankelijke overheden een uitzondering vormen op deze regel. Om nalevingsredenen wordt de CDN weglaten 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 achtergrondservice, 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 onbeperkt horizontaal schalen van de Power BI-service mogelijk maken 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 thuiscluster van de tenant genoemd. De gegevens van het thuiscluster van een geverifieerde gebruiker worden verstrekt door global service en gebruikt door de webfront-end om aanvragen naar het thuiscluster van de tenant te routeeren.

Elk back-endcluster bestaat uit meerdere virtuele machines die zijn gecombineerd in meerdere schaalbare sets die zijn afgestemd op het uitvoeren van specifieke taken, stateful resources zoals SQL-databases, opslagaccounts, servicebusjes, 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 uitval en is op elk ander moment passief.

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

• Gatewayservice
• Azure API Management

Power BI Premium-infrastructuur

Power BI Premium biedt een service voor abonnees die premium-Power BI nodig hebben, zoals gegevensstromen, ge pagineerde rapporten, AI, enzovoort. Wanneer een klant zich voor een abonnement Power BI Premium, wordt Premium capaciteit gemaakt via de Azure Resource Manager.

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

Het volgende diagram illustreert 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 normale Power BI back-end, directe verbindingen via XMLA-clients, ARM-API's, enzovoort.

De Power BI Premium-infrastructuur in een Azure-regio bestaat uit Power BI Premium clusters (het minimum is één). Het merendeel van Premium resources zijn ingekapseld in een cluster (bijvoorbeeld compute) en er zijn enkele algemene regionale resources (bijvoorbeeld opslag van metagegevens). Premium infrastructuur kunt u op twee manieren horizontale schaalbaarheid bereiken in een regio: resources binnen clusters vergroten en/of indien nodig meer clusters op aanvraag toevoegen (als de limieten van clusterresources worden bereikt).

De backbone van elk cluster zijn rekenbronnen die worden beheerd door Virtual Machine Scale Sets (VMSS) en Azure Service Fabric. VMSS en Service Fabric snelle en moeiteloze toename van rekenknooppunten mogelijk naarmate het gebruik toeneemt en de implementatie, het beheer en de bewaking van Power BI Premium services en toepassingen in orden.

Er zijn veel omliggende 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 Azure Key Vault beheerd. Verificatie wordt uitsluitend uitgevoerd via integratie met Azure AD.

Elke aanvraag die naar de Power BI Premium gaat eerst naar front-endknooppunten: dit zijn de enige knooppunten die beschikbaar zijn voor externe verbindingen. De rest van de resources zijn verborgen achter virtuele netwerken. De front-endknooppunten verifiëren de aanvraag, verwerken deze of sturen deze door naar de juiste resources (bijvoorbeeld back-endknooppunten).

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

Power BI Mobile

Power BI - Mobiel is een verzameling apps die is ontworpen voor de drie primaire mobiele platforms: Android, iOS en Windows (UWP). Beveiligingsoverwegingen voor de Power BI - Mobiel-apps kunnen worden onderverdeeld 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 door browsers worden gebruikt. Deze worden eerder in dit whitepaper uitgebreid beschreven. De Power BI mobiele toepassingen voor iOS en Android zorgen voor een browsersessie in de toepassing zelf, terwijl de mobiele Windows-app een broker in de hand heeft om het communicatiekanaal met Power BI tot stand te brengen (voor het aanmeldingsproces).

De volgende tabel bevat ondersteuning voor verificatie op basis van certificaten (CBA) voor Power BI - Mobiel, op basis van het platform voor mobiele apparaten:

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

De Power BI slaat gegevens op het apparaat op die het gebruik van de app mogelijk maken:

• 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 opgeslagen in de cache op het apparaat en kunnen worden versleuteld door het besturingssysteem. In iOS wordt dit automatisch gedaan wanneer de gebruiker een wachtwoordcode in stelt. In Android kan dit worden geconfigureerd in de instellingen. In Windows wordt dit bereikt met behulp van BitLocker.
• Voor 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 de systeembeheerder).
• Geolocatie wordt expliciet door de gebruiker ingeschakeld of uitgeschakeld. Als deze functie is ingeschakeld, worden geolocatiegegevens niet op het apparaat opgeslagen en niet gedeeld met Microsoft.
• Meldingen worden expliciet door de gebruiker ingeschakeld of uitgeschakeld. Als deze functie is ingeschakeld, bieden Android en iOS geen ondersteuning voor geografische vereisten voor gegevensstatussen voor meldingen.

Gegevensversleuteling kan worden verbeterd door versleuteling op bestandsniveau toe te passen via Microsoft Intune, een softwareservice die beheer van mobiele apparaten en toepassingen biedt. Alle drie de platforms waarvoor Power BI - Mobiel beschikbaar zijn, ondersteunen 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 ondersteunt ook Windows Information Protection (WIP).

Om eenmalige aanmelding te implementeren, zijn sommige beveiligde opslagwaarden met betrekking tot de verificatie op basis van een token beschikbaar voor andere microsoft-apps van derden (zoals Microsoft Authenticator) en worden ze beheerd door de ADAL-SDK (Azure Active Directory Authentication Library).

Power BI - Mobiel gegevens in de cache worden verwijderd wanneer de app wordt verwijderd, wanneer de gebruiker zich bij Power BI - Mobiel af meldt of wanneer de gebruiker zich niet kan aanmelden (bijvoorbeeld nadat een token is verlopen of het wachtwoord is gewijzigd). 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 extra identificatie te configureren, zoals het leveren 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

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 Azure Active Directory stroom voor het verlenen van verificatiecode van de gebruiker. Zie Een aanmeldingsmodel kiezen voor een 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 onderstaande afbeelding.

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. De Azure Traffic Manager controleert de DNS-record van de gebruiker om te bepalen van de meest geschikte (meestal dichtstbijzijnde) datacenter waar Power BI is geïmplementeerd en reageert op de DNS met het IP-adres van de WFE-cluster die 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 vastgesteld dichtstbijzijnde WFE-cluster Power BI service met een verificatiecode.

5. Het WFE-cluster controleert met de Azure AD-service om een Azure AD-beveiliging token te verkrijgen met behulp van de auth-code. Wanneer Azure AD de geslaagde verificatie van de gebruiker retourneert en een Azure AD-beveiliging token retourneert, raadpleegt het WFE-cluster de Power BI Global 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 werking ervan.

6. Wanneer de browser van de client nu klantgegevens vereist, worden aanvragen naar het adres van het back-endcluster met het Azure AD-toegangsken in de autorisatie-header gestuurd. Het Power BI back-endcluster leest het Azure AD-toegangsken en valideert de handtekening om ervoor te zorgen dat de identiteit voor de aanvraag geldig is. Het Azure AD-toegang tokenheeft een standaardlevensduur van 1 uur en voor het onderhouden van de huidige sessie doet de browser van de gebruiker periodieke aanvragen om het toegangsken te vernieuwen voordat het verloopt.

Gegevenslocatie

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

De toewijzing van een Azure-geografie voor de opslag van tenantgegevens wordt uitgevoerd door het land of de regio die is geselecteerd als onderdeel van de installatie van de Azure AD-tenant toe tewijst aan de meest geschikte Azure-geografie waar een Power BI-implementatie bestaat. Zodra deze beslissing is genomen, worden alle Power BI-klantgegevens opgeslagen in deze geselecteerde Azure-geografie (ook wel bekend als de thuisgeo), behalve in gevallen waarin organisaties gebruikmaken van implementaties met meerdere geografische gebieden.

Meerdere geografische gebieden (multi-geo)

Sommige organisaties hebben een wereldwijde aanwezigheid en vereisen mogelijk Power BI in meerdere Azure-regio's. Een bedrijf kan bijvoorbeeld zijn hoofdkantoor 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 in rust opgeslagen blijven in de externe regio om te voldoen aan de lokale regelgeving. Deze functie van de Power BI-service wordt aangeduid als multi-geo.

De uitvoeringslaag voor query's, querycaches en artefactgegevens die zijn toegewezen aan een werkruimte met meerdere geografische gebieden, worden gehost en blijven in de azure-geografie van de externe capaciteit. Sommige metagegevens van artefacten, zoals de rapportstructuur, kunnen echter at-rest worden opgeslagen in het geografische gebied van de tenant. Bovendien kan sommige gegevensverloop en -verwerking nog steeds plaatsvinden in het geografische gebied van de tenant, zelfs voor werkruimten die worden gehost in een multigeo-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-geografieën omvatten.

Regio's en datacenters

Power BI-services zijn beschikbaar in specifieke Azure-regio's, 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 van klanten worden opgegeven in de voorwaarden voor gegevensverwerking van microsoft Voorwaarden voor Online Diensten.

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 Power BI procedures voor gegevensverwerking beschreven voor 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 worden opgeslagen door Power BI worden standaard versleuteld met door Microsoft beheerde sleutels. Klantgegevens die zijn opgeslagen in Azure SQL Databases, worden volledig versleuteld met behulp van de Transparent Data Encryption-technologie van Azure SQL (TDE). Klantgegevens die zijn opgeslagen in Azure Blob Storage, worden versleuteld met Azure Storage Encryption.

Optioneel kunnen organisaties gebruikmaken van Power BI Premium eigen sleutels te gebruiken voor het versleutelen van data-at-rest die in een gegevensset wordt geïmporteerd. Deze methode wordt vaak beschreven als Bring Your Own Key (BYOK). Het gebruik van BYOK helpt ervoor te zorgen dat, zelfs in het geval van een serviceoperatorfout, klantgegevens niet openbaar worden gemaakt. Dit kan niet eenvoudig worden bereikt met behulp van transparante versleuteling aan de servicezijde. Zie Bring Your Own Encryption Keys for Power BI (Bring Your Own Encryption Keys) voor meer informatie.

Power BI gegevenssets zijn verschillende verbindingsmodi voor gegevensbron mogelijk, waarmee wordt bepaald of de gegevensbrongegevens al dan niet in de service worden persistent gemaakt.

Ongeacht de gebruikte gegevenssetmodus kunnen Power BI opgehaalde gegevens tijdelijk in de cache opslaan om de prestaties van query- en rapportbelasting 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 actief verwerkte gegevens in de geheugenruimte van een of meer serviceworkloads laadt. De verwerkte gegevens in het geheugen worden niet versleuteld om de functionaliteit te vergemakkelijken die nodig is voor de werkbelasting.

Actieve gegevens

Power BI vereist dat al het binnenkomende HTTP-verkeer wordt versleuteld met TLS 1.2 of hoger. Aanvragen die proberen de service met TLS 1.1 of lager te gebruiken, worden geweigerd.

Verificatie bij gegevensbronnen

Wanneer een gebruiker verbinding maakt met een gegevensbron, kan deze ervoor kiezen om een kopie van de gegevens te importeren in Power BI of om 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 Power BI service, Power BI altijd de referenties van deze gebruiker gebruiken 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 met een enkele aanmelding voor geselecteerde gegevensbronnen. Als de verbinding is geconfigureerd voor gebruik van een enkele 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 behulp van 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 een enkele aanmelding, worden de referenties van de huidige gebruiker gebruikt om verbinding te maken met de gegevensbron wanneer een gebruiker de gegevens bekijkt. Wanneer u ols gebruikt met een enkele aanmelding, kunnen beveiliging op rijniveau (RLS) en/of beveiliging op objectniveau (OLS) worden geïmplementeerd op de gegevensbron. Hierdoor kunnen gebruikers alleen gegevens weergeven die toegangsrechten hebben. Wanneer de verbinding is gemaakt met gegevensbronnen in de cloud, wordt Azure AD-verificatie gebruikt voor een enkele aanmelding; voor on-prem gegevensbronnen worden Kerberos, Security Assertion Markup Language (SAML) en Azure AD ondersteund.

Als de gegevensbron Azure Analysis Services of on-premises Analysis Services is en RLS en/of OLS is geconfigureerd, zal de Power BI-service die beveiliging op rijniveau toepassen en krijgen gebruikers die niet over voldoende referenties beschikken om toegang te krijgen tot de onderliggende gegevens (dit kan een query zijn die wordt gebruikt in een dashboard, rapport of ander gegevensartefact) geen gegevens te zien waarvoor ze niet voldoende bevoegdheden hebben.

Premium functies

Architectuur van gegevensstromen

Gegevensstromen bieden gebruikers de mogelijkheid om back-endgegevensverwerkingsbewerkingen te configureren die gegevens extraheren uit polymorfe gegevensbronnen, transformatielogica uitvoeren op de gegevens en deze vervolgens in een doelmodel plaatsen voor gebruik in verschillende rapportagepresentatietechnologieën. Elke gebruiker met een lid-, bijdrager- of beheerdersrol in een werkruimte kan een gegevensstroom maken. Gebruikers met de rol Kijker 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 weergeven en bewerken door er eigenaar van te worden.

Elke geconfigureerde gegevensbron is gebonden aan een clienttechnologie voor toegang tot die gegevensbron. De structuur van de 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 worden uitgevoerd. Voor Premium-gegevensstromen worden Power Query uitgevoerd in back-endknooppunten. Gegevens kunnen rechtstreeks uit de cloudbronnen worden gehaald of via een gateway die on-premises is geïnstalleerd. Wanneer het transport rechtstreeks vanuit een cloudbron naar de service of naar de gateway wordt overgebracht, maakt het transport gebruik van een beveiligingsmethodologie die specifiek is voor de clienttechnologie, indien van toepassing. Wanneer gegevens worden overgebracht van de gateway naar de cloudservice, worden deze versleuteld. Zie de sectie Gegevens in verwerking hierboven.

Wanneer de door de klant opgegeven gegevensbronnen referenties nodig hebben voor toegang, zal de eigenaar/maker van de gegevensstroom deze leveren tijdens het schrijven. Ze worden opgeslagen met behulp van standaard referentieopslag voor het hele product. Zie de sectie Verificatie bij gegevensbronnen hierboven. Er zijn verschillende manieren die gebruikers kunnen configureren om gegevens persistentie en toegang te optimaliseren. Standaard worden de gegevens in een Power BI opslagaccount geplaatst. Storage-versleuteling 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 Power BI service-principal toegang tot dat opslagaccount, zodat deze de gegevens daar tijdens het vernieuwen kan schrijven. 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 suboptimale zijn voor sommige gegevens, hebben gebruikers ook de mogelijkheid om een door Power BI gehoste berekeningsen 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 levert voor het versleutelen van de gegevens die zijn opgeslagen in de SQL-database, wordt die sleutel gebruikt om deze twee keer te versleutelen.

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

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. Als dat het zo is, wordt er een SaS-sleutel verkregen en gebruikt om rechtstreeks toegang te krijgen tot de opslag met behulp van het versleutelde HTTPS-transportprotocol.

De verwerking van gegevens in de pijplijn Office 365 controlegebeurtenissen. 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.

Ge pagineerde 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 ge pagineerde rapporten wordt uitgevoerd binnen een sandbox.

Ge pagineerde rapportdefinities (.rdl) worden opgeslagen in Power BI en voor het publiceren en/of weergeven van een ge pagineerd rapport moet een gebruiker zich verifiëren en autoriseren op dezelfde manier als wordt beschreven in de bovenstaande sectie Verificatie bij de Power BI-service.

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

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

Voor Premium Gen2 wordt een afzonderlijke en exclusieve kortstondige sandbox gemaakt voor elk van de renders van een rapport, waardoor gebruikers een hoger isolatieniveau hebben.

Een ge pagineerd 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. Vervolgens worden de vereiste referenties aan de verbinding door het vertrouwde proces aan de verbinding toe te appen. Op deze manier heeft de sandbox nooit toegang tot referenties of geheimen.

Ter ondersteuning van functies zoals Bing kaarten of aanroepen naar Azure Functions, heeft de sandbox wel toegang tot internet.

Power BI ingesloten analyse

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 behulp van POST-berichten.

In een scenario met insluiten voor uw organisatie hebben Azure AD-gebruikers toegang tot hun eigen Power BI via portals die zijn aangepast door hun ondernemingen en IT'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 scenario met insluiten 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 insluit token dat is gegenereerd door Power BI 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 insluittokens niet ontsleutelen of wijzigen. SDK's aan de clientzijde, zoals Power BI Client-API's, toevoegen het versleutelde insluittoken automatisch aan Power BI-aanvragen als autorisatie: EmbedToken-header. Op basis van deze header dwingt Power BI alle beleidsregels (zoals toegang of RLS) af die tijdens het genereren door de ISV zijn opgegeven.

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

Power BI ingesloten analyses en de REST API's bieden ondersteuning voor alle Power BI-netwerkisolatiemogelijkheden 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 visualniveau omvatten mogelijkheden zoals Belangrijke beïnvloeders, Uitcompositiestructuur, Smart-Narrative, Anomaliedetectie, R-visual, Python-visual, Clustering, prognose, Q&A, Quick-Insights enzovoort. De AI-verrijkingsmogelijkheden omvatten mogelijkheden zoals AutoML, AzureML, CognitiveServices, R/Python-transformaties, enzovoort.

De meeste functies die hierboven worden vermeld, worden momenteel ondersteund in gedeelde 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 (bijvoorbeeld voorspelling, classificatie, regressie, enzovoort) bouwen en trainen en toepassen om voorspellingen te krijgen tijdens het laden van gegevens in een gegevensstroom die is gedefinieerd in een Premium-werkruimte. Daarnaast kunnen Power BI 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 gezien als een verzameling staatloze AI-functies/-transformaties die door Power BI-gebruikers kunnen worden gebruikt in hun pijplijnen voor gegevensintegratie die worden gebruikt door een Power BI-gegevensset of -gegevensstroom. Houd er rekening mee dat deze functies ook toegankelijk zijn vanuit de huidige ontwerpomgevingen voor gegevensstromen/gegevenssets in Power BI Service en Power BI Desktop. Deze AI-functies/transformaties worden altijd uitgevoerd in Premium werkruimte/capaciteit. Deze functies worden in een Power BI als een gegevensbron die een Azure AD-token vereist voor de Power BI gebruiker die de AI-functie gebruikt. Deze AI-gegevensbronnen zijn speciaal omdat ze geen eigen gegevens aan het licht brengen en ze alleen deze functies/transformaties leveren. Tijdens de uitvoering maken deze functies geen uitgaande aanroepen naar andere services om de gegevens van de klant te verzenden. Laten we eens kijken naar Premium scenario's om inzicht te krijgen 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 wordt alle training uitgevoerd in de Power BI capaciteit van de klant. Tijdens het trainen van iteraties roept Power BI AzureML-service voor experimenten aan om een geschikt model en hyperparameters voor de huidige iteratie te selecteren. In deze uitgaande aanroep worden alleen relevante metagegevens van het experiment (zoals 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 het getrainde ML-model toepassen als een transformatie om het ML model volgens een planning operationeel te maken. Voor TextAnalytics- en ImageTagging-API's roept Power BI niet rechtstreeks de CognitiveServices-service-API's aan, maar gebruikt het een interne SDK om de API's in de Power BI Premium uitvoeren. Tegenwoordig worden deze API's ondersteund in Power BI gegevensstromen en gegevenssets. Tijdens het maken 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 worden geavanceerde beveiligingsfuncties in Power BI. Sommige functies hebben specifieke licentievereisten. Zie de secties hieronder voor meer informatie.

Servicetags

Een servicetag vertegenwoordigt een groep IP-adres voorvoegsels van een bepaalde Azure-service. Het helpt de complexiteit van regelmatige updates van netwerkbeveiligingsregels te minimaliseren. Klanten kunnen servicetags gebruiken voor het definiëren van besturingselementen voor netwerktoegang in netwerkbeveiligingsgroepen of Azure Firewall. Klanten kunnen servicetags gebruiken in plaats van specifieke IP-adressen bij het maken van beveiligingsregels. Door de naam van de servicetag (bijvoorbeeld 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 adres-voorvoegsels die worden omvat door de servicetag en werkt de servicetag automatisch bij wanneer adressen worden gewijzigd.

Private Link integratie

Azure-netwerken biedt Azure Private Link functie waarmee Power BI beveiligde toegang kunnen bieden via Azure-netwerken privé-eindpunten. Met Azure Private Link en privé-eindpunten wordt gegevensverkeer privé verzonden met behulp van de backbone-netwerkinfrastructuur van Microsoft, waardoor de gegevens niet via internet worden verzonden.

Private Link zorgt ervoor dat Power BI de Microsoft-backbone voor privénetwerk gebruiken wanneer ze naar resources in de Power BI service gaan.

Het Private Link met Power BI biedt de volgende voordelen:

• Private Link zorgt ervoor dat verkeer via de Azure-backbone naar een privé-eindpunt voor Azure-cloudbronnen stroomt.
• Voor netwerkverkeerisolatie van een niet-Azure-infrastructuur, zoals on-premises toegang, moeten klanten ExpressRoute of een VIRTUEEL particulier netwerk (VPN) hebben geconfigureerd.

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

VNet-connectiviteit (preview - binnenkort beschikbaar)

Hoewel de functie Private Link-integratie beveiligde binnenkomende verbindingen met Power BI biedt, maakt de VNet-connectiviteit veilige uitgaande connectiviteit mogelijk van Power BI naar gegevensbronnen binnen een VNet.

VNet-gateways (door Microsoft beheerd) elimineren de overhead van het installeren en bewaken van on-premises gegevensgateways om verbinding te maken 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, gegevensbrongegevens en referenties naar de Power Platform VNet-service (PP VNet).

2. De PP VNet-service injecteert vervolgens veilig een container met een VNet-gateway 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, gegevensbrongegevens en referenties naar de VNet-gateway.

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

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

6. Na de uitvoering worden de resultaten verzonden naar de VNet-gateway en pusht de PP VNet-service 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 voor 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 Automate Premium workspace and dataset tasks with service principals (Taken voor werkruimten en gegevenssets automatiseren met service-principals) voor meer informatie.

Preventie van gegevensverlies (DLP)

Microsoft 365-gevoeligheidslabels toevoegen

Power BI heeft een diepe integratie met Microsoft Information Protection-gevoeligheidslabels (MIP), waarmee organisaties één geïntegreerde oplossing kunnen hebben voor DLP-beleidsbeheer, -controle en -naleving in de Office suite.

Wanneer gevoeligheidslabels zijn ingeschakeld in Power BI:

• Gevoelige gegevens, zowel in de Power BI-service als in Power BI Desktop, kunnen worden geclassificeerd en gelabeld met dezelfde vertrouwde Microsoft Information Protection-vertrouwelijkheidslabels die worden gebruikt in Office en in Azure Purview.
• Governancebeleid kan worden afgedwongen, zelfs wanneer Power BI-inhoud wordt geëxporteerd naar Excel-, PowerPoint-, PDF- of PBIX-bestanden, om ervoor te zorgen dat gegevens worden beveiligd, zelfs wanneer ze Power BI.
• PBIX-bestanden kunnen worden versleuteld volgens het MIP-labelbeleid wanneer een MIP-label wordt toegepast op het PBIX-bestand in Desktop, zodat alleen geautoriseerde gebruikers dit bestand kunnen bewerken.
• Het is eenvoudig om PBIX-bestanden te classificeren en te beveiligen, net zoals bij Excel-, Word- en PowerPoint bestanden. Met slechts twee klikken kan een bestand worden getagd op basis van het vertrouwelijkheidsniveau en, nog verder, worden versleuteld als het vertrouwelijke bedrijfsgegevens bevat.
• Excel werkmappen nemen automatisch de gevoeligheidslabels over wanneer ze verbinding maken met Power BI (preview), waardoor end-to-end-classificatie kan worden onderhouden en beveiliging kan worden toegepast wanneer de Power BI-gegevensset wordt geanalyseerd in Excel.
• Gevoeligheidslabels die worden toegepast Power BI rapporten en dashboards zijn zichtbaar in de Power BI mobiele iOS- en Android-apps.
• Gevoeligheidslabels blijven behouden wanneer een Power BI wordt ingesloten in Teams, SharePoint of een beveiligde website (preview). Dit helpt organisaties bij het onderhouden van classificatie en beveiliging bij het exporteren bij het insluiten Power BI inhoud.
• Label overname bij het maken van nieuwe inhoud in de Power BI-service zorgt ervoor dat het label dat is toegepast op een gegevensset in de Power BI-service wordt toegepast op nieuwe inhoud die boven op de gegevensset is gemaakt.
• Power BI-API's voor scan van beheerders kunnen het gevoeligheidslabel van een Power BI-artefact extraheren, waardoor Power BI- en InfoSec-beheerders labels in de Power BI-service kunnen bewaken en leidinggevende rapporten kunnen produceren.
• Power BI zorgt ervoor dat alleen geautoriseerde gebruikers labels met beveiligingsinstellingen in de Power BI verwijderen.
• Binnenkort beschikbaar
  • Power BI voor beheerders-API's voor het toepassen van MIP-labels zodat centrale teams programmatisch inhoud kunnen labelen in de Power BI service.
  • Beheerders kunnen het toepassen van labels op nieuwe of bewerkte inhoud afdwingen met een verplicht labelbeleid in de Power BI service (preview).
  • Automatisch downstream artefact labelen binnen de Power BI service. Wanneer een label op een gegevensset wordt toegepast of gewijzigd, wordt het label automatisch toegepast op alle downstreaminhoud die is verbonden met dit artefact.

Zie de Microsoft Information Protection over gevoeligheidslabels in Power BI voor meer informatie.

Microsoft Cloud App Security (MCAS) voor Power BI

Microsoft Cloud App Security is een van de toonaangevende cloudtoegangsbeveiligingsbrokers ter wereld, met de naam leader in Gartner's Magic Kwadrant for the Cloud Access Security Broker (CASB) market. Cloud App Security wordt gebruikt om het gebruik van cloud-apps te beveiligen. Hiermee kunnen organisaties in realtime riskante en Power BI controleren, zoals gebruikerstoegang vanaf onbeheerde apparaten. Beveiligingsbeheerders kunnen beleidsregels definiëren voor het beheer van gebruikersacties, zoals het downloaden van rapporten met gevoelige informatie.

Met Cloud App Security kunnen organisaties de volgende DLP-mogelijkheden krijgen:

• Stel realtime-besturingselementen in om riskante gebruikerssessies af te dwingen in Power BI. Als een gebruiker bijvoorbeeld verbinding maakt met Power BI van buiten zijn land, kan de sessie worden bewaakt door de realtime besturingselementen van Cloud App Security en kunnen riskante acties, zoals het downloaden van gegevens met het vertrouwelijkheidslabel Uiterst vertrouwelijk, onmiddellijk worden geblokkeerd.
• Onderzoek Power BI gebruikersactiviteit met Cloud App Security activiteitenlogboek van de gebruiker. Het Cloud App Security-activiteitenlogboek bevat Power BI-activiteit zoals vastgelegd in het auditlogboek van Office 365, dat informatie bevat over alle activiteiten van gebruikers en beheerders, evenals informatie over het gevoeligheidslabel voor relevante activiteiten zoals label toepassen, wijzigen en verwijderen. Beheerders kunnen gebruikmaken van Cloud App Security geavanceerde filters en snelle acties voor effectief onderzoek van problemen.
• Aangepaste beleidsregels maken om te waarschuwen over verdachte gebruikersactiviteiten in Power BI. De Cloud App Security van het activiteitenbeleid van Cloud App Security kan worden gebruikt om uw eigen aangepaste regels te definiëren, zodat u het gedrag van gebruikers kunt detecteren dat afwijkt van de norm en er zelfs automatisch actie op kunt ondernemen als het te gevaarlijk lijkt.
• Werken met Cloud App Security van de ingebouwde anomaliedetectie van Cloud App Security. het beleid voor anomaliedetectie van Cloud App Security biedt kant-en-klaar gedragsanalyses en machine learning voor gebruikers, 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 activeert.
• Power BI-beheerdersrol in de Cloud App Security portal. Cloud App Security 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 Power BI-relevante gegevens in de portal, zoals waarschuwingen, gebruikers die risico lopen, activiteitenlogboeken en andere Power BI-gerelateerde informatie.

Zie Besturingselementen voor Microsoft Cloud App Security gebruiken in Power BI voor meer informatie.

Preview-beveiligingsfuncties

Dit onderwerp bevat functies die tot maart 2021 moeten worden uitgebracht. Omdat dit onderwerp functies bevat die mogelijk nog niet zijn uitgebracht, kan de leveringstijdlijn worden gewijzigd en kan de verwachte functionaliteit later dan maart 2021 worden uitgebracht of helemaal niet worden uitgebracht. Raadpleeg de Voorwaarden voor Online Diensten voor meer informatie Voorwaarden voor Online Diensten.

Bring Your Own Log Analytics (BYOLA)

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

Power BI en antwoorden over beveiliging

De volgende vragen zijn algemene beveiligingsvragen en -antwoorden voor Power BI. Deze zijn ingedeeld op basis van de tijd waarop ze aan dit whitepaper 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 binnen de onderneming en machtigingen voor deze gegevensbronnen kunnen worden beheerd door de gatewaybeheerder. Bij het configureren van een gegevensset mag de gebruiker een referentie selecteren uit zijn persoonlijke opslag of een on-premises gegevensgateway gebruiken om een gedeelde referentie te gebruiken.

  In het geval van importeren 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 dashboard geen toegang tot de onderliggende gegevensbron. Power BI biedt ondersteuning voor verificatie van een aanmelding voor geselecteerde gegevensbronnen. Als de verbinding is geconfigureerd voor gebruik van een enkele aanmelding, wordt de referentie 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 een enkele aanmelding, wordt de referentie van de huidige gebruiker gebruikt om verbinding te maken met de gegevensbron wanneer de gebruiker de gegevens bekijkt. Wanneer u gebruikt met een enkele aanmelding, 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 is gemaakt met gegevensbronnen in de cloud, wordt Azure AD-verificatie gebruikt voor een aanmelding; voor on-prem gegevensbronnen worden Kerberos, SAML en Azure AD ondersteund.

  Wanneer u verbinding maakt met Kerberos, wordt de UPN van de gebruiker doorgegeven aan de gateway. Met behulp van beperkte Kerberos-delegering wordt de gebruiker imiteerd 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 een aanmelding voor gateways.

  Als de gegevensbron Azure Analysis Services of on-premises Analysis Services is en beveiliging op rijniveau (RLS) en/of beveiliging op objectniveau (OLS) is geconfigureerd, zal de Power BI-service die beveiliging op rijniveau toepassen en gebruikers die onvoldoende referenties hebben voor toegang tot de onderliggende gegevens (dit kan een query zijn die wordt gebruikt in een dashboard, -rapport of ander gegevensartefact) ziet geen gegevens waarvoor de gebruiker niet voldoende 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. Dit helpt te voorkomen dat kwaadwillende gebruikers zelfs het bestaan van dergelijke objecten detecteren. Beveiligde tabellen en kolommen worden verborgen in de lijst met velden wanneer u hulpprogramma's zoals Excel of Power BI gebruikt. Bovendien hebben gebruikers zonder machtigingen geen toegang tot beveiligde metagegevensobjecten via DAX of een andere methode. Vanuit het oogpunt van gebruikers zonder juiste toegangsmachtigingen bestaan beveiligde tabellen en kolommen gewoon niet.

  Beveiliging op objectniveau biedt, samen met beveiliging op rijniveau, verbeterde beveiliging op bedrijfsniveau voor rapporten en gegevenssets, zodat alleen gebruikers met de vereiste machtigingen toegang hebben om gevoelige gegevens weer te geven en te gebruiken.

Hoe worden gegevens overgedragen naar Power BI?

• Alle gegevens die door Power BI worden aangevraagd en verzonden, worden tijdens de overdracht versleuteld met https (behalve wanneer de gegevensbron die door de klant is gekozen geen ondersteuning biedt voor HTTPS) 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 gebruikt, volgt de Power BI-service het proces dat eerder in dit document wordt 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 op rollen gebaseerde beveiliging, het delen van rapporten of dashboards en gegevensverbindingen? Hoe werkt dat op het gebied van gegevenstoegang, dashboardweergave, rapporttoegang of 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 er gegevensverbindingen worden gemaakt met een RLS-geschikte gegevensbron, 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 bij gegevensbronnen eerder in dit document voor meer informatie.

Onze gebruikers maken altijd verbinding met dezelfde gegevensbronnen, waarvan sommige referenties verschillen van hun domeinreferenties. Hoe kunnen ze voorkomen dat ze deze referenties telkens moeten invoeren wanneer ze een gegevensverbinding 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 on-premises gegevensgateway en persoonlijke gateway? Zijn er domeinnamen die moeten worden toegestaan voor verbindingsdoeleinden?

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

Hoe worden herstelsleutels gebruikt en waar worden ze opgeslagen wanneer u met de on-premises gegevensgateway werkt? Hoe zit het met beveiligd 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 symmetrische AES-sleutel te genereren. Er wordt ook een asymmetrische RSA-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 deze opnieuw met een symmetrische AES-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 moeten de poorten 443, 5671-5672 en 9350-9354 zijn geopend voor uitgaande communicatie. Dit protocol heeft de voorkeur vanwege de lagere overhead aan communicatie.

  • HTTPS – WebSockets via HTTPS + TLS: dit protocol gebruikt alleen 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 de gateway dwingen dit protocol te gebruiken 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 gedurende de Power BI-servicebrowsersessie.

Voert Power BI microsoft beveiligings- of privacybeoordelingen uit van de code van de aangepaste visual 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.

Voert Microsoft voor sjabloon-apps een beveiligings- of privacyevaluatie uit van de sjabloon-app voordat items naar 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 kunnen verzenden buiten het klantnetwerk?

• 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 gegevenssoevereiniteit? Kunnen we tenants inrichten in datacenters die zich in specifieke geografische gebieden bevinden, om ervoor te zorgen dat gegevens de grenzen van het land niet verlaten?

• 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 behandelt Microsoft verbindingen voor klanten die Power BI Premium hebben? Zijn deze verbindingen anders dan de verbindingen die zijn ingesteld voor de niet-Premium Power BI service?

• De verbindingen die tot stand zijn gebracht voor klanten met Power BI Premium-abonnementen implementeren een Azure B2B-autorisatieproces (Business-to-Business), waarbij Azure AD wordt gebruikt om toegangsbeheer en autorisatie mogelijk te maken. 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 bronnen

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