Share via

Power BI-implementatieplanning: controle op tenantniveau

  • Artikel

Notitie

Dit artikel maakt deel uit van de reeks artikelen over de implementatieplanning van Power BI. Deze reeks richt zich voornamelijk op de Power BI-workload in Microsoft Fabric. Zie de planning van de Power BI-implementatie voor een inleiding tot de reeks.

Dit artikel over controleplanning op tenantniveau is voornamelijk gericht op:

  • Power BI-beheerders: de beheerders die verantwoordelijk zijn voor het toezicht op Power BI in de organisatie. Power BI-beheerders moeten mogelijk samenwerken met IT, beveiliging, interne audit en andere relevante teams.
  • Center of Excellence, IT en BI-team: de teams die ook verantwoordelijk zijn voor het toezicht op Power BI. Mogelijk moeten ze samenwerken met Power BI-beheerders en andere relevante teams.

Belangrijk

We raden u aan het Power BI-releaseplan nauw te volgen om meer te weten te komen over toekomstige verbeteringen van de controle- en bewakingsmogelijkheden.

Het doel van een controleoplossing op tenantniveau is het vastleggen en analyseren van gegevens voor alle gebruikers, activiteiten en oplossingen die zijn geïmplementeerd in een Power BI-tenant. Deze controlegegevens op tenantniveau zijn waardevol voor veel doeleinden, zodat u acceptatie-inspanningen kunt analyseren, gebruikspatronen kunt begrijpen, gebruikers kunt informeren, gebruikers ondersteunen, risico's beperken, naleving verbeteren, licentiekosten kunt beheren en prestaties kunt bewaken.

Het maken van een end-to-end controleoplossing die veilig en productieklaar is, is een belangrijk project dat tijd kost. U kunt het beschouwen als het bouwen van business intelligence op business intelligence (BI op BI). Zie het overzicht controle en bewaking voor informatie over waarom de controlegegevens zo waardevol zijn.

Zie Controle op rapportniveau voor controle op rapportniveau, die is gericht op makers van rapporten.

Zie Controle op gegevensniveau voor het controleren van gegevensassets die zijn gericht op gegevensmakers.

De rest van dit artikel is gericht op controle op tenantniveau.

Tip

De primaire focus van dit artikel is om u te helpen bij het maken van een end-to-end controleoplossing. Omdat de inhoud in dit artikel is ingedeeld in vier fasen, hebt u informatie nodig over meerdere fasen. U vindt bijvoorbeeld informatie in fase 1 over het plannen van een service-principal en informatie in fase 2 over vereisten en installatie.

Daarom raden we u aan eerst dit hele artikel te lezen, zodat u bekend bent met wat er bij betrokken is. Vervolgens moet u goed voorbereid zijn om uw controleoplossing op een iteratieve manier te plannen en te bouwen.

Wanneer u van plan bent om een controleoplossing op tenantniveau te bouwen, moet u tijd besteden aan de volgende vier fasen.

Fase 1: Planning en beslissingen

De eerste fase is gericht op planning en besluitvorming. Er zijn veel vereisten en prioriteiten waarmee u rekening moet houden, dus we raden u aan voldoende tijd te besteden om inzicht te krijgen in de onderwerpen die in deze sectie zijn geïntroduceerd. Het doel is om vooraf goede beslissingen te nemen, zodat de downstreamfasen soepel verlopen.

Stroomdiagram met een beschrijving van fase 1, die is gericht op planning en beslissingen voor het bouwen van een controleoplossing op tenantniveau.

Vereisten en prioriteiten

In de eerste fase is het doel om te bepalen wat het belangrijkst is. Richt u op wat het belangrijkst is en hoe u de impact in uw organisatie gaat meten. Streven naar het definiëren van bedrijfsgerichte vereisten in plaats van technologiegerichte vereisten.

Hier volgen enkele vragen die u moet beantwoorden.

  • Welke belangrijke vragen moet u beantwoorden? Er is een grote hoeveelheid controlegegevens die u kunt verkennen. De meest effectieve manier om controle te benaderen, is door te focussen op het beantwoorden van specifieke vragen.
  • Wat zijn uw doelstellingen voor acceptatie en gegevenscultuur ? Misschien hebt u bijvoorbeeld een doel om het aantal selfservice-BI-inhoudsmakers in de organisatie te verhogen. In dat geval moet u gebruikersactiviteiten meten met betrekking tot het maken, bewerken en publiceren van inhoud.
  • Welke directe risico's zijn er? U weet bijvoorbeeld dat er in het verleden te veel inhoud is overschreven. Gebruikerstraining is sindsdien uitgebreid en u wilt nu doorlopend beveiligingsinstellingen en -activiteiten controleren.
  • Zijn er huidige KPI's (Key Performance Indicators) of organisatiedoelen? U hebt bijvoorbeeld een KPI van een organisatie die betrekking heeft op digitale transformatie of een meer gegevensgestuurde organisatie wordt. Met controlegegevens op tenantniveau kunt u meten of uw Power BI-implementatie is afgestemd op deze doelstellingen.

Tip

Controleer de controlevereisten en stel prioriteiten in bij uw executive sponsor en Center of Excellence. Het is verleidelijk om controlegegevens te extraheren en rapporten te maken op basis van veel interessante gegevens. Het is echter onwaarschijnlijk dat u een hoge waarde zult afleiden van uw controleoplossing wanneer deze niet wordt aangestuurd door vragen die u moet beantwoorden en acties die u wilt uitvoeren.

Zie het overzicht Controle en bewaking voor meer ideeën over manieren waarop u controlegegevens kunt gebruiken.

Controlelijst : bij het identificeren van vereisten en prioriteiten zijn belangrijke beslissingen en acties:

  • Vereisten identificeren: verzamel en documenteer de belangrijkste zakelijke vereisten voor het controleren van uw Power BI-tenant.
  • Prioriteiten instellen voor de vereisten, ze classificeren als onmiddellijke, korte, middellange termijn en lange termijn (achterstand).
  • Maak een plan voor de onmiddellijke prioriteiten: Stel een plan in om te beginnen met het verzamelen van gegevens, zodat deze beschikbaar is wanneer u het nodig hebt.
  • Beoordeelt regelmatig de vereisten: Maak regelmatig een plan om de vereisten opnieuw te beoordelen (bijvoorbeeld twee keer per jaar). Controleer of de controle- en bewakingsoplossing voldoet aan de vermelde vereisten. Werk indien nodig actie-items in uw plan bij.

Gegevensbehoeften

Nadat u de vereisten en prioriteiten hebt gedefinieerd (eerder beschreven), bent u klaar om de gegevens te identificeren die u nodig hebt. In deze sectie worden vier gegevenscategorieën behandeld.

De meeste gegevens die u nodig hebt, zijn afkomstig van de beheer-API's, die een schat aan metagegevens over de Power BI-tenant bieden. Zie Een gebruikers-API of beheerders-API kiezen verderop in dit artikel voor meer informatie.

Gebruikersactiviteitsgegevens

Maak het uw eerste prioriteit om gegevens over gebruikersactiviteiten te verkrijgen. De gebruikersactiviteiten, ook wel gebeurtenissen of bewerkingen genoemd, zijn handig voor een groot aantal doeleinden.

Deze gegevens worden meestal het activiteitenlogboek of het gebeurtenislogboek genoemd. Technisch gezien zijn er verschillende manieren om gebruikersactiviteitsgegevens te verkrijgen (het activiteitenlogboek is één methode). Zie Toegang tot gebruikersactiviteitsgegevens verderop in dit artikel voor meer informatie over de betrokken beslissingen en activiteiten.

Hier volgen enkele veelgestelde vragen die gebruikersactiviteitsgegevens kunnen beantwoorden.

  • De belangrijkste gebruikers en de belangrijkste inhoud zoeken
    • Welke inhoud wordt het vaakst bekeken en door welke gebruikers?
    • Wat zijn de dagelijkse, wekelijkse en maandelijkse trends voor het weergeven van inhoud?
    • Worden rapportweergaven steeds hoger of lager?
    • Hoeveel gebruikers zijn actief?
  • Inzicht in gebruikersgedrag
    • Welk type beveiliging wordt het vaakst gebruikt (apps, werkruimten of delen per item)?
    • Gebruiken gebruikers meestal browsers of mobiele apps?
    • Welke makers van inhoud publiceren en bijwerken inhoud het meest actief?
    • Welke inhoud wordt gepubliceerd of bijgewerkt, wanneer en door welke gebruikers?
  • Mogelijkheden voor gebruikersonderwijs en -training identificeren
    • Wie deelt (te veel) vanuit hun persoonlijke werkruimte?
    • Wie voert een aanzienlijke hoeveelheid export uit?
    • Wie wordt regelmatig inhoud gedownload?
    • Wie publiceert veel nieuwe semantische modellen, voorheen gegevenssets genoemd?
    • Wie gebruikt abonnementen intensief?
  • Governance- en nalevingsinspanningen verbeteren
    • Wanneer worden tenantinstellingen gewijzigd en door welke Power BI-beheerder?
    • Wie een Power BI-proefversie gestart?
    • Welke inhoud wordt geopend door externe gebruikers, wie, wanneer en hoe?
    • Wie een vertrouwelijkheidslabel toegevoegd of bijgewerkt?
    • Welk percentage rapportweergaven is gebaseerd op gecertificeerde semantische modellen?
    • Welk percentage van semantische modellen ondersteunt meer dan één rapport?
    • Wanneer is een gateway of gegevensbron gemaakt of bijgewerkt en door welke gebruiker?

Zie Inzicht in gebruikspatronen voor meer informatie over manieren om deze gegevens te gebruiken.

Belangrijk

Als u nog geen gebruikersactiviteitengegevens extraheert en opslaat, maakt u dat een dringende prioriteit. Zorg er minimaal voor dat u de onbewerkte gegevens extraheert en op een veilige locatie opslaat. Op die manier zijn de gegevens beschikbaar wanneer u klaar bent om deze te analyseren. Geschiedenis is 30 dagen of 90 dagen beschikbaar, afhankelijk van de bron die u gebruikt.

Zie Voor meer informatie toegang tot gebruikersactiviteitsgegevens verderop in dit artikel.

Tenantinventaris

Vaak is de tweede prioriteit het ophalen van de gegevens om een tenantinventaris te maken. Soms wordt het ook wel werkruimte-inventaris, metagegevens van werkruimten of tenantmetagegevens genoemd.

Een tenantinventaris is een momentopname op een bepaald tijdstip. Hierin wordt beschreven wat er in de tenant wordt gepubliceerd. De tenantinventaris bevat niet de werkelijke gegevens of de werkelijke rapporten. In plaats daarvan zijn het metagegevens die alle werkruimten en hun items (zoals semantische modellen en rapporten) beschrijven.

Hier volgen enkele veelgestelde vragen die de tenantinventaris kan beantwoorden.

  • Begrijpen hoeveel inhoud u hebt en waar
    • Welke werkruimten hebben de meeste inhoud?
    • Welk type inhoud wordt in elke werkruimte gepubliceerd (met name wanneer u rapportagewerkruimten en gegevenswerkruimten scheidt)?
    • Welke afhankelijkheden bestaan er tussen items (zoals gegevensstromen die ondersteuning bieden voor veel semantische modellen of een semantisch model dat een bron is voor andere samengestelde modellen)?
    • Wat is de gegevensherkomst (afhankelijkheden tussen Power BI-items, inclusief externe gegevensbronnen)?
    • Zijn er zwevende rapporten (die zijn losgekoppeld van hun semantische model)?
  • Inzicht in de verhouding tussen semantische modellen en rapporten
    • Hoeveel semantisch model wordt opnieuw gebruikt?
    • Zijn er dubbele of sterk vergelijkbare semantische modellen?
    • Zijn er mogelijkheden om semantische modellen samen te voegen?
  • Trends tussen punten in tijd begrijpen
    • Neemt het aantal rapporten in de loop van de tijd toe?
    • Neemt het aantal semantische modellen na verloop van tijd toe?
  • Ongebruikte inhoud zoeken
    • Welke rapporten worden niet gebruikt (of onderbenut)?
    • Welke semantische modellen worden ongebruikt (of onderbenut)?
    • Zijn er mogelijkheden om inhoud buiten gebruik te stellen?

Een tenantinventaris helpt u bij het gebruik van huidige namen bij het analyseren van historische activiteiten. De momentopname van de items in uw tenant bevat de namen van alle items op dat moment. Het is handig om huidige itemnamen te gebruiken voor historische rapportage. Als de naam van een rapport bijvoorbeeld drie maanden geleden is gewijzigd, wordt in het activiteitenlogboek op dat moment de oude rapportnaam vastgelegd. Met een correct gedefinieerd gegevensmodel kunt u de meest recente tenantinventaris gebruiken om een item te zoeken op basis van de huidige naam (in plaats van de voormalige naam). Zie Een gegevensmodel maken verderop in dit artikel voor meer informatie.

Zie Gepubliceerde inhoud begrijpen voor meer informatie over manieren om een tenantinventaris te gebruiken.

Tip

U gebruikt vaak de gebeurtenissen van de gebruikersactiviteit (zoals beschreven in de vorige sectie) en de tenantinventaris om een volledig beeld te produceren. Op die manier verbetert u de waarde van alle gegevens.

Omdat een tenant-inventarisatie een momentopname op een bepaald moment is, moet u bepalen hoe vaak de metagegevens moeten worden geëxtraheerd en opgeslagen. Een wekelijkse momentopname is handig voor het maken van vergelijkingen tussen de twee tijdstippen. Als u bijvoorbeeld de beveiligingsinstellingen voor een werkruimte wilt onderzoeken, hebt u de vorige momentopname van de tenantinventaris, de gebeurtenissen in het activiteitenlogboek en de momentopname van de huidige tenantinventaris nodig.

Er zijn twee belangrijkste manieren om een tenantinventaris te bouwen. Zie De inventarisgegevens van access-tenants verderop in dit artikel voor meer informatie over de betrokken beslissingen en activiteiten.

Gegevens van gebruikers en groepen

Naarmate uw analytische behoeften toenemen, zult u waarschijnlijk bepalen dat u gegevens over gebruikers en groepen wilt opnemen in uw end-to-end-controleoplossing. Als u deze gegevens wilt ophalen, kunt u Microsoft Graph gebruiken. Dit is de gezaghebbende bron voor informatie over gebruikers en groepen van Microsoft Entra-id (voorheen Bekend als Azure Active Directory).

Gegevens die worden opgehaald uit de Power BI REST API's, bevatten een e-mailadres om de gebruiker of de naam van een beveiligingsgroep te beschrijven. Deze gegevens zijn een momentopname op een bepaald tijdstip.

Hier volgen enkele veelgestelde vragen die Microsoft Graph kan beantwoorden.

  • Gebruikers en groepen identificeren
    • Wat is de volledige gebruikersnaam (naast het e-mailadres), afdeling of locatie die afkomstig is van hun gebruikersprofiel?
    • Wie zijn de leden van een beveiligingsgroep?
    • Wie is de eigenaar van een beveiligingsgroep (om leden te beheren)?
  • Aanvullende gebruikersgegevens verkrijgen
    • Welke licenties, Power BI Pro of Power BI Premium per gebruiker (PPU), worden toegewezen aan gebruikers?
    • Welke gebruikers melden zich het vaakst aan ?
    • Welke gebruikers hebben zich onlangs niet aangemeld bij de Power BI-service?

Waarschuwing

Sommige oudere methoden (die uitgebreid online worden gedocumenteerd) voor toegang tot gebruikers en groepengegevens, worden afgeschaft en mogen niet worden gebruikt. Gebruik Microsoft Graph indien mogelijk als gezaghebbende bron van gebruikers en groepsgegevens.

Zie Access-gebruikers- en groepsgegevens verderop in dit artikel voor meer informatie en aanbevelingen over het openen van gegevens uit Microsoft Graph.

Beveiligingsgegevens

Mogelijk hebt u een vereiste om regelmatige beveiligingscontroles uit te voeren.

Hier volgen enkele veelgestelde vragen die de Power BI REST API's kunnen beantwoorden.

Belangrijk

Soms verwijst dit artikel naar Power BI Premium of de capaciteitsabonnementen (P-SKU's). Houd er rekening mee dat Microsoft momenteel aankoopopties consolideert en de Power BI Premium-SKU's per capaciteit buiten gebruik stelt. Nieuwe en bestaande klanten moeten overwegen om in plaats daarvan F-SKU's (Fabric-capaciteitsabonnementen) aan te schaffen.

Zie Belangrijke update voor Power BI Premium-licenties en veelgestelde vragen over Power BI Premium voor meer informatie.

Tip

Zie de artikelen over beveiligingsplanning voor meer overwegingen over beveiliging.

Deze veelgestelde vragen zijn geen volledige lijst; er zijn tal van Power BI REST API's beschikbaar. Zie De Power BI REST API's gebruiken voor meer informatie.

Zie Een gebruikers-API of beheerders-API kiezen verderop in dit artikel voor meer informatie over het gebruik van de beheerders-API's versus gebruikers-API's (inclusief hoe dit van invloed is op machtigingen die vereist zijn voor de gebruiker die de gegevens uitpakken).

Controlelijst : bij het identificeren van de gegevens die nodig zijn voor controle, zijn belangrijke beslissingen en acties:

  • Identificeer specifieke gegevensbehoeften voor gebruikersactiviteitsgegevens: valideer de vereisten die u hebt verzameld. Bepaal welke controlegegevens nodig zijn om te voldoen aan elke vereiste voor gebruikersactiviteitsgegevens.
  • Identificeer specifieke gegevensbehoeften voor tenantinventarisgegevens: valideer de vereisten die u hebt verzameld. Bepaal welke controlegegevens nodig zijn om een tenantinventaris te compileren.
  • Specifieke gegevensbehoeften voor gebruikers en groepen identificeren: valideer de vereisten die u hebt verzameld. Bepaal welke controlegegevens nodig zijn om te voldoen aan elke vereiste voor gebruikers en groepsgegevens.
  • Identificeer specifieke gegevensbehoeften voor beveiligingsgegevens: valideer de vereisten die u hebt verzameld. Bepaal welke controlegegevens nodig zijn om te voldoen aan elke vereiste voor beveiligingsgegevens.
  • Prioriteiten controleren: controleer de volgorde van prioriteiten, zodat u weet wat u eerst moet ontwikkelen.
  • Bepaal hoe vaak activiteiten moeten worden vastgelegd: Bepaal hoe vaak activiteiten worden vastgelegd (zoals één keer per dag).
  • Bepaal hoe vaak momentopnamen moeten worden vastgelegd: bepaal welk interval u wilt gebruiken om momentopnamegegevens vast te leggen, zoals een tenantinventaris of de gebruikers- en groepsgegevens.

Type controleoplossing

Controle op tenantniveau wordt handmatig of met geautomatiseerde processen uitgevoerd.

De meeste nieuwe controleprocessen beginnen als een handmatig proces, met name tijdens de ontwikkeling en tijdens het testen. Een handmatig controleproces kan zich ontwikkelen tot een geautomatiseerd proces. Niet elk controleproces moet echter volledig worden geautomatiseerd.

Handmatige controleprocessen

Handmatige controle is afhankelijk van scripts en processen die op aanvraag worden uitgevoerd door een gebruiker (meestal een Power BI-beheerder). Indien nodig voert de gebruiker interactief query's uit om controlegegevens op te halen.

Handmatige controle is het meest geschikt voor:

  • Nieuwe scripts die worden ontwikkeld en getest.
  • Af en toe, eenmalige controlebehoeften.
  • Verkennende controlebehoeften.
  • Niet-essentiële controleprocessen waarvoor geen volledige ondersteuning is vereist.

Geautomatiseerde controleprocessen

Controlegegevens die op terugkerende basis nodig zijn, moeten worden geautomatiseerd. Het wordt geëxtraheerd en verwerkt volgens een normaal schema en wordt een geautomatiseerd proces genoemd. Soms wordt het een proces zonder toezicht genoemd.

De doelen van een geautomatiseerd proces zijn het verminderen van handmatige inspanning, het verminderen van het risico op fouten, het verhogen van de consistentie en het elimineren van de afhankelijkheid van een afzonderlijke gebruiker om het uit te voeren.

Geautomatiseerde controle is het meest geschikt voor:

  • Controleprocessen die in productie worden uitgevoerd.
  • Onbeheerde processen die volgens een normaal schema worden uitgevoerd.
  • Scripts die volledig zijn getest.
  • Essentiële controleprocessen met andere rapporten (of andere processen) die hiervan afhankelijk zijn als gegevensbron.
  • Controleprocessen die worden gedocumenteerd en ondersteund.

Het type proces( handmatig of geautomatiseerd) kan van invloed zijn op de manier waarop u verificatie afhandelt. Een Power BI-beheerder kan bijvoorbeeld gebruikersverificatie gebruiken voor een handmatig controleproces, maar een service-principal gebruiken voor een geautomatiseerd proces. Zie De verificatiemethode verderop in dit artikel bepalen voor meer informatie.

Tip

Als er regelmatig, terugkerend, controlegegevens moeten worden verkregen die momenteel handmatig worden verwerkt, kunt u overwegen tijd te investeren om deze te automatiseren. Als een Power BI-beheerder bijvoorbeeld elke dag handmatig een script uitvoert om gegevens op te halen uit het Power BI-activiteitenlogboek, bestaat het risico dat deze persoon ziek of afwezig is op vakantie.

Controlelijst : bij het overwegen van het type controleoplossing voor het ontwikkelen, zijn belangrijke beslissingen en acties:

  • Bepaal het primaire doel voor elke nieuwe controlevereiste: bepaal of u een handmatig of geautomatiseerd proces wilt gebruiken voor elke nieuwe vereiste. Overweeg of deze beslissing tijdelijk of permanent is.
  • Maak een plan voor het automatiseren: wanneer het geschikt is voor een bepaalde controlevereiste, maakt u een plan voor het automatiseren, wanneer en door wie.

Machtigingen en verantwoordelijkheden

Op dit moment moet u een duidelijk beeld hebben van wat u wilt bereiken en de gegevens die u in eerste instantie nodig hebt. Het is nu een goed moment om beslissingen te nemen over gebruikersmachtigingen en rollen en verantwoordelijkheden.

Gebruikersmachtigingen

Als u van plan bent een end-to-end-controleoplossing te bouwen, moet u rekening houden met gebruikersmachtigingen voor andere gebruikers die toegang nodig hebben tot de gegevens. Bepaal met name wie toegang heeft tot controlegegevens en bekijkt.

Hier volgen enkele overwegingen waarmee u rekening moet houden.

Directe toegang tot controlegegevens

U moet beslissen wie rechtstreeks toegang heeft tot de controlegegevens. Er zijn meerdere manieren om erover na te denken.

  • Wie moet een Power BI-beheerder zijn? Een Power BI-beheerder heeft toegang tot alle tenantmetagegevens, inclusief de beheer-API's. Zie Beveiligingsplanning op tenantniveau voor meer informatie over het bepalen wie een Power BI-beheerder moet zijn.
  • Wie kunt u een bestaande service-principal gebruiken? Als u een service-principal (in plaats van gebruikersmachtigingen) wilt gebruiken voor toegang tot controlegegevens, moet een geheim worden verstrekt aan geautoriseerde gebruikers, zodat ze verificatie op basis van een wachtwoord kunnen uitvoeren. Toegang tot geheimen (en sleutels) moet zeer nauw worden beheerd.
  • Moet de toegang strikt worden beheerd? Bepaalde branches met wettelijke en nalevingsvereisten moeten de toegang strikter beheren dan andere branches.
  • Zijn er grote activiteitsgegevensvolumes? Om te voorkomen dat api-beperkingslimieten worden bereikt, moet u mogelijk nauw bepalen wie rechtstreeks toegang heeft tot de API's die controlegegevens produceren. In dit geval is het handig om ervoor te zorgen dat er geen dubbele of overlappende inspanningen zijn.
Toegang tot geëxtraheerde onbewerkte gegevens

U moet bepalen wie de onbewerkte gegevens kan bekijken die zijn geëxtraheerd en geschreven naar een opslaglocatie. Meestal is de toegang tot onbewerkte gegevens beperkt tot beheerders en auditors. Het Center of Excellence (COE) kan ook toegang vereisen. Zie Bepalen waar controlegegevens verderop in dit artikel moeten worden opgeslagen voor meer informatie.

Toegang tot gecureerde analytische gegevens

U moet bepalen wie de gecureerde en getransformeerde gegevens kan bekijken die gereed zijn voor analyse. Deze gegevens moeten altijd beschikbaar worden gesteld aan beheerders en auditors. Soms wordt een gegevensmodel beschikbaar gesteld aan andere gebruikers in de organisatie, met name wanneer u een semantisch Power BI-model maakt met beveiliging op rijniveau. Zie Plan om gecureerde gegevens verderop in dit artikel te maken voor meer informatie.

Rollen en verantwoordelijkheden

Zodra u hebt besloten hoe gebruikersmachtigingen werken, bent u in een goede positie om na te denken over rollen en verantwoordelijkheden. We raden u aan om al vroeg de juiste personen bij te betrekken, met name wanneer meerdere ontwikkelaars of teams betrokken zullen zijn bij het bouwen van de end-to-end-controleoplossing.

Bepaal welke gebruikers of teams verantwoordelijk zijn voor de volgende activiteiten.

- Rol Typen verantwoordelijkheden Rol die doorgaans wordt uitgevoerd door
Communiceren met belanghebbenden Communicatieactiviteiten en vereisten verzamelen. COE in samenwerking met IT. Het kan ook gaan om bepaalde personen uit belangrijke bedrijfseenheden.
Prioriteiten bepalen en richting geven aan vereisten Besluitvormingsactiviteiten met betrekking tot de end-to-end-controleoplossing, waaronder het voldoen aan vereisten. Het team dat toezicht houdt op Power BI in de organisatie, zoals het COE. De executive sponsor of een stuurcomité voor gegevensbeheer kan betrokken worden bij het nemen van kritieke beslissingen of het escaleren van problemen.
De onbewerkte gegevens extraheren en opslaan Het maken van scripts en processen voor toegang tot en het extraheren van de gegevens. Ook moet u de onbewerkte gegevens naar de opslag schrijven. Data engineering personeel, meestal in IT en in samenwerking met de COE.
De gecureerde gegevens maken Gegevens opschonen, transformeren en het maken van de gecureerde gegevens in stervormig schemaontwerp. Data engineering personeel, meestal in IT en in samenwerking met de COE.
Een gegevensmodel maken Het maken van een analytisch gegevensmodel op basis van de gecureerde gegevens. Maker(s) van Power BI-inhoud, meestal in IT of de COE.
Analyserapporten maken Het maken van rapporten voor het analyseren van de gecureerde gegevens. Doorlopende wijzigingen in rapporten op basis van nieuwe vereisten en wanneer nieuwe controlegegevens beschikbaar komen. Power BI-rapportmaker(s), meestal in IT of de COE.
De gegevens analyseren en reageren op de resultaten Analyseer de gegevens en reageer op de controlegegevens. Het team dat toezicht houdt op Power BI in de organisatie, meestal het COE. Kan ook andere teams bevatten, afhankelijk van de controleresultaten en de actie. Andere teams kunnen beveiliging, naleving, juridisch, risicobeheer of wijzigingsbeheer omvatten.
Testen en valideren Test om ervoor te zorgen dat aan de controlevereisten wordt voldaan en dat de gepresenteerde gegevens nauwkeurig zijn. Maker(s) van Power BI-inhoud, in samenwerking met het team dat toezicht houdt op Power BI in de organisatie.
De gegevens beveiligen Stel beveiliging in en beheer voor elke opslaglaag, inclusief de onbewerkte gegevens en de gecureerde gegevens. Beheer de toegang tot semantische modellen die zijn gemaakt voor het analyseren van de gegevens. Systeembeheerder voor het systeem waarin de gegevens worden opgeslagen, in samenwerking met het team dat toezicht houdt op Power BI in de organisatie.
Planning en automatisering Operationaliseer een oplossing en plan het proces met het hulpprogramma naar keuze. Data engineering personeel, meestal in IT en in samenwerking met de COE.
Ondersteuning voor de oplossing Bewaak de controleoplossing, inclusief taakuitvoeringen, fouten en ondersteuning voor technische problemen. Het team dat power BI-systeemondersteuning afhandelt, meestal IT of het COE.

Veel van de bovenstaande rollen en verantwoordelijkheden kunnen worden geconsolideerd als ze worden uitgevoerd door hetzelfde team of dezelfde persoon. Uw Power BI-beheerders kunnen bijvoorbeeld een aantal van deze rollen uitvoeren.

Het is ook mogelijk dat verschillende personen verschillende rollen uitvoeren, afhankelijk van de omstandigheden. Acties zijn contextueel, afhankelijk van de controlegegevens en de voorgestelde actie.

Bekijk verschillende voorbeelden.

  • Voorbeeld 1: De controlegegevens laten zien dat sommige gebruikers vaak gegevens exporteren naar Excel. Actie ondernomen: De COE neemt contact op met de specifieke gebruikers om hun behoeften te begrijpen en hen betere alternatieven te leren.
  • Voorbeeld 2: In de controlegegevens wordt de toegang van externe gebruikers op een onverwachte manier weergegeven. Acties die zijn uitgevoerd: een IT-systeembeheerder werkt de relevante Instellingen voor Microsoft Entra-id's voor externe gebruikerstoegang bij. De Power BI-beheerder werkt de tenantinstelling bij die betrekking heeft op externe gebruikerstoegang. De COE werkt documentatie en training bij voor makers van inhoud die de beveiliging beheren. Zie Strategie voor externe gebruikers voor meer informatie.
  • Voorbeeld 3: De controlegegevens laten zien dat verschillende gegevensmodellen dezelfde meting anders definiëren (beschikbaar in de metagegevensscan-API's, indien toegestaan door de gedetailleerde tenantinstellingen voor metagegevens). Actie ondernomen: Het data governancecomité start een project om gemeenschappelijke definities te definiëren. De COE werkt documentatie en training bij voor makers van inhoud die gegevensmodellen maken. Het COE werkt ook samen met makers van inhoud om hun modellen bij te werken, indien van toepassing. Zie De inventarisgegevens van de Access-tenant verderop in dit artikel voor meer informatie over het ophalen van gedetailleerde metagegevens.

Notitie

Het instellen van processen voor gegevensextractie is meestal een eenmalige inspanning met af en toe verbeteringen en probleemoplossing. Het analyseren en handelen van de gegevens is een doorlopende inspanning waarvoor doorlopende inspanningen nodig zijn.

Controlelijst : bij het overwegen van machtigingen en verantwoordelijkheden zijn belangrijke beslissingen en acties:

  • Bepaal welke teams betrokken zijn: bepaal welke teams betrokken zijn bij het end-to-end maken en ondersteunen van de controleoplossing.
  • Gebruikersmachtigingen bepalen: Bepaal hoe gebruikersmachtigingen worden ingesteld voor toegang tot controlegegevens. Maak documentatie over belangrijke beslissingen voor later gebruik.
  • Rollen en verantwoordelijkheden bepalen: zorg ervoor dat verwachtingen duidelijk zijn voor wie wat doet, met name wanneer meerdere teams betrokken zijn. Maak documentatie voor rollen en verantwoordelijkheden, waaronder verwachte acties.
  • Rollen en verantwoordelijkheden toewijzen: wijs specifieke rollen en verantwoordelijkheden toe aan specifieke personen of teams. Werk afzonderlijke taakbeschrijvingen bij met Human Resources, indien van toepassing.
  • Maak een trainingsplan: Stel een plan in voor trainingspersoneel wanneer ze nieuwe vaardigheden nodig hebben.
  • Maak een plan voor meerdere trainingen: zorg ervoor dat er crosstraining en back-ups aanwezig zijn voor belangrijke rollen.

Technische beslissingen

Wanneer u een controleoplossing op tenantniveau plant, moet u enkele belangrijke technische beslissingen nemen. We raden u aan deze beslissingen zo vroeg mogelijk te nemen om de consistentie te verbeteren, te voorkomen dat u opnieuw werkt en de beveiliging verbetert.

De eerste planningsfase omvat het nemen van de volgende beslissingen.

Selecteer een technologie voor toegang tot controlegegevens

Het eerste wat u moet beslissen, is hoe u toegang krijgt tot de controlegegevens.

De eenvoudigste manier om aan de slag te gaan, is door de vooraf gemaakte rapporten te gebruiken die beschikbaar zijn in de werkruimte voor beheerbewaking.

Wanneer u rechtstreeks toegang nodig hebt tot de gegevens en uw eigen oplossing wilt bouwen, gebruikt u een API (interface voor het toepassingsprogramma). API's zijn ontworpen voor het uitwisselen van gegevens via internet. De Power BI REST API's ondersteunen aanvragen voor gegevens met behulp van het HTTP-protocol. Elke taal of elk hulpprogramma kan Power BI REST API's aanroepen wanneer deze een HTTP-aanvraag kan verzenden en een JSON-antwoord kan ontvangen.

Tip

De PowerShell-cmdlets gebruiken de Power BI REST API's voor toegang tot de controlegegevens. Zie API's of PowerShell-cmdlets verderop in dit artikel voor meer informatie.

Deze sectie is gericht op uw technologiekeuze. Zie Beslissingen over gegevensbronnen verderop in dit artikel voor overwegingen over de bron voor toegang tot specifieke typen controlegegevens.

Platformopties

Er zijn veel verschillende manieren om toegang te krijgen tot controlegegevens. Afhankelijk van de technologie die u kiest, kunt u naar een voorkeurstaal leunen. Mogelijk moet u ook een specifieke beslissing nemen over het plannen van de uitvoering van uw scripts. Technologieën verschillen sterk in hun leercurve en gemak om aan de slag te gaan.

Hier volgen enkele technologieën die u kunt gebruiken om gegevens op te halen met behulp van de Power BI REST API's.

Technologie Goede keuze voor handmatige controleprocessen Goede keuze voor geautomatiseerde controleprocessen
Beheer bewakingswerkruimte Beheer bewakingswerkruimte is een goede keuze voor handmatige controleprocessen.
Probeer het Try-it is een goede keuze voor handmatige controleprocessen.
Powershell PowerShell is een goede keuze voor handmatige controleprocessen. PowerShell is een goede keuze voor geautomatiseerde controleprocessen.
Power BI Desktop Power BI Desktop is een goede keuze voor handmatige controleprocessen.
Power Automate Power Automate is een goede keuze voor geautomatiseerde controleprocessen.
Voorkeursservice voor Azure De voorkeursservice van Azure is een goede keuze voor geautomatiseerde controleprocessen.
Voorkeursprogramma/taal Voorkeursprogramma/taal is een goede keuze voor handmatige controleprocessen. Voorkeursprogramma/taal is een goede keuze voor geautomatiseerde controleprocessen.
Zoeken in auditlogboeken van Microsoft Purview Zoeken in microsoft Purview-auditlogboeken is een goede keuze voor handmatige controleprocessen.
Defender voor cloud-apps Defender voor Cloud Apps is een goede keuze voor handmatige controleprocessen.
Microsoft Sentinel Microsoft Sentinel is een goede keuze voor geautomatiseerde controleprocessen.

De rest van deze sectie bevat een korte inleiding tot elk van de opties die in de tabel worden weergegeven.

Beheer bewakingswerkruimte

De werkruimte voor beheerbewaking bevat vooraf gedefinieerde rapporten en semantische modellen in de Power BI-service. Het is een handige manier voor Fabric-beheerders en globale beheerders om recente controlegegevens te bekijken en hen te helpen inzicht te krijgen in gebruikersactiviteiten.

Try-it in API-documentatie

Try-it is een interactief hulpprogramma waarmee u de Power BI REST API rechtstreeks in de Microsoft-documentatie kunt ervaren. Het is een eenvoudige manier om de API's te verkennen, omdat hiervoor geen andere hulpprogramma's of installatie op uw computer zijn vereist.

U kunt proberen om het volgende te doen:

  • Verzend handmatig een aanvraag naar een API om te bepalen of deze de gewenste informatie retourneert.
  • Lees hoe de URL wordt samengesteld voordat u een script schrijft.
  • Controleer gegevens op een informele manier.

Notitie

U moet een gelicentieerde en geverifieerde Power BI-gebruiker zijn om try-it te kunnen gebruiken. Het volgt het standaardmachtigingsmodel, wat betekent dat de gebruikers-API's afhankelijk zijn van gebruikersmachtigingen en dat de beheerders-API's power BI-beheerdersmachtigingen vereisen. U kunt zich niet verifiëren met Try-it met behulp van een service-principal.

Omdat het interactief is, is Try-it het meest geschikt voor het leren, verkennen en nieuwe handmatige controleprocessen.

PowerShell en Azure Cloud Shell

U kunt PowerShell-scripts op meerdere manieren maken en uitvoeren.

Hier volgen verschillende algemene opties.

  • Visual Studio Code: een moderne, lichtgewicht broncode-editor. Het is een vrij beschikbaar opensource-hulpprogramma dat wordt ondersteund op meerdere platforms, waaronder Windows, macOS en Linux. U kunt Visual Studio Code gebruiken met veel talen, waaronder PowerShell (met behulp van de PowerShell-extensie).
  • Azure Data Studio: een hulpprogramma voor het maken van scripts en notebooks. Het is gebouwd op Visual Studio Code. Azure Data Studio is onafhankelijk beschikbaar of met SQL Server Management Studio (SSMS). Er zijn veel extensies, waaronder een extensie voor PowerShell.
  • Azure Cloud Shell: een alternatief voor lokaal werken met PowerShell. U hebt toegang tot Azure Cloud Shell vanuit een browser.
  • Azure Functions: een alternatief voor lokaal werken met PowerShell. Azure Functions is een Azure-service waarmee u code kunt schrijven en uitvoeren in een serverloze omgeving. PowerShell is een van de verschillende talen die door PowerShell worden ondersteund.

Belangrijk

U wordt aangeraden de nieuwste versie van PowerShell (PowerShell Core) te gebruiken voor alle nieuwe ontwikkelwerkzaamheden. U moet stoppen met het gebruik van Windows PowerShell (die PowerShell Core niet kan uitvoeren) en in plaats daarvan een van de moderne code-editors gebruiken die PowerShell Core ondersteunen. Zorg ervoor dat u naar veel onlinevoorbeelden verwijst die gebruikmaken van Windows PowerShell (versie 5.1), omdat ze mogelijk niet gebruikmaken van de nieuwste (en betere) codemethoden.

U kunt PowerShell op verschillende manieren gebruiken. Zie Api's of PowerShell-cmdlets verderop in dit artikel voor meer informatie over deze technische beslissing.

Er zijn veel onlinebronnen beschikbaar voor het gebruik van PowerShell en het is vaak mogelijk om ervaren ontwikkelaars te vinden die PowerShell-oplossingen kunnen maken en beheren. PowerShell is een goede keuze voor het maken van zowel handmatige als geautomatiseerde controleprocessen.

Power BI Desktop

Omdat Power BI Desktop verbinding kan maken met API's, kunt u deze misschien gebruiken om uw controleoplossing te bouwen. Er zijn echter enkele belangrijke nadelen en complexiteit.

  • Accumulatiegeschiedenis: Omdat het Power BI-activiteitenlogboek maximaal 30 dagen aan gegevens biedt, omvat het maken van uw volledige controleoplossing het verzamelen van een set bestanden in de loop van de tijd waarin alle historische gebeurtenissen worden opgeslagen. Het accumuleren van historische bestanden is eenvoudiger te bereiken met andere hulpprogramma's.
  • Veilig referenties en sleutels verwerken: veel oplossingen die u online vindt van communitybloggers zijn niet veilig omdat ze referenties en sleutels in code in platte tekst in Power Query-query's bevatten. Hoewel deze aanpak eenvoudig is, wordt het niet aanbevolen omdat iedereen die uw Power BI Desktop-bestand verkrijgt, de waarden kan lezen. U kunt het wachtwoord (wanneer u gebruikersverificatie gebruikt) of het geheim (wanneer u een service-principal gebruikt) niet veilig opslaan in Power BI Desktop, tenzij u het volgende doet:
    • Gebruik een aangepaste connector die is ontwikkeld met de Power Query SDK. Een aangepaste connector kan bijvoorbeeld vertrouwelijke waarden lezen uit Azure Key Vault of een andere service waarmee de versleutelde waarde veilig wordt opgeslagen. Er zijn ook verschillende aangepaste connectoropties beschikbaar in de wereldwijde Power BI-community.
    • Gebruik de optie ApiKeyName , die goed werkt in Power BI Desktop. Het is echter niet mogelijk om de sleutelwaarde op te slaan in de Power BI-service.
  • Typen aanvragen: mogelijk ondervindt u enkele beperkingen voor wat u kunt uitvoeren in Power BI Desktop. Power Query biedt bijvoorbeeld geen ondersteuning voor elk type API-aanvraag. Zo worden alleen GET- en POST-aanvragen ondersteund wanneer u de functie Web.Contents gebruikt. Voor controle verzendt u doorgaans GET-aanvragen.
  • Mogelijkheid om te vernieuwen: u moet specifieke Power Query-ontwikkelingspatronen volgen om een semantisch model in de Power BI-service te vernieuwen. De optie moet bijvoorbeeld RelativePath aanwezig zijn wanneer u Web.Contents gebruikt, zodat Power BI de locatie van een gegevensbron correct kan verifiëren zonder dat er een fout in de Power BI-service wordt gegenereerd.

In de meeste gevallen wordt u aangeraden Power BI Desktop slechts voor twee doeleinden te gebruiken. U moet deze gebruiken voor het volgende:

  • Bouw uw gegevensmodel op basis van de bestaande gecureerde gegevens (in plaats van het te gebruiken om de controlegegevens in eerste instantie te extraheren).
  • Analytische rapporten maken op basis van uw gegevensmodel.
Power Automate

U kunt Power Automate op veel manieren gebruiken met Power BI. Met betrekking tot controle kunt u Power Automate gebruiken om aanvragen naar de Rest API's van Power BI te verzenden en vervolgens de geëxtraheerde gegevens op te slaan op de locatie van uw keuze.

Tip

Als u aanvragen naar de Rest API's van Power BI wilt verzenden, kunt u een aangepaste connector voor Power Automate gebruiken om de controlegegevens veilig te verifiëren en te extraheren. U kunt Azure Key Vault ook gebruiken om te verwijzen naar een wachtwoord of geheim. Beide opties zijn beter dan het opslaan van wachtwoorden en geheimen in tekst zonder opmaak in de Power Automate-stroom.

Zoek naar Power BI in de Power Automate-sjablonen voor andere ideeën over manieren om Power Automate te gebruiken.

Voorkeursservice voor Azure

Er zijn verschillende Azure-services die aanvragen kunnen verzenden naar de Power BI REST API's. U kunt uw favoriete Azure-service gebruiken, zoals:

In de meeste gevallen kunt u een rekenservice combineren die de logica voor de gegevensextractie afhandelt met een opslagservice waarin de onbewerkte gegevens (en gecureerde gegevens, indien van toepassing) worden opgeslagen. Overwegingen voor het nemen van beslissingen over technische architectuur worden verderop in dit artikel beschreven.

Voorkeursprogramma en/of taal

U kunt het hulpprogramma van uw voorkeur en de taal van uw voorkeur gebruiken om aanvragen naar de Power BI REST API's te verzenden. Het is een goede aanpak wanneer uw team expertise heeft met een specifieke tool of taal, zoals:

  • Python
  • C# in .NET Framework. U kunt eventueel de Power BI .NET SDK gebruiken, die fungeert als een wrapper boven op de Power BI REST API's om bepaalde processen te vereenvoudigen en de productiviteit te verhogen.
  • JavaScript

De Microsoft Purview-nalevingsportal (voorheen het Microsoft 365-compliancecentrum) bevat een gebruikersinterface waarmee u de auditlogboeken kunt bekijken en doorzoeken. De geïntegreerde auditlogboeken omvatten Power BI en alle andere services die geïntegreerde auditlogboeken van Microsoft 365 ondersteunen.

De gegevens die zijn vastgelegd in het geïntegreerde auditlogboek, zijn exact dezelfde gegevens die zijn opgenomen in het Power BI-activiteitenlogboek. Wanneer u een zoekopdracht in het auditlogboek uitvoert in de Microsoft Purview-nalevingsportal, wordt uw aanvraag aan de wachtrij toegevoegd. Het kan enkele minuten (of langer duren, afhankelijk van het gegevensvolume) voordat de gegevens gereed zijn.

Hier volgen enkele veelvoorkomende manieren om het zoekprogramma voor auditlogboeken te gebruiken. U kunt:

  • Selecteer de Power BI-workload om gebeurtenissen voor een reeks datums weer te geven.
  • Zoek een of meer specifieke activiteiten, zoals:
    • Power BI-rapport verwijderd
    • Beheerderstoegang toegevoegd aan een persoonlijke werkruimte in Power BI
  • Activiteiten van een of meer gebruikers weergeven.

Voor beheerders met voldoende machtigingen is het zoekprogramma voor auditlogboeken in de Microsoft Purview-nalevingsportal een goede optie voor handmatige controleprocessen. Zie Microsoft Purview-nalevingsportal verderop in dit artikel voor meer informatie.

Defender voor Cloud Apps-gebruikersinterface

Defender voor Cloud Apps is beschikbaar voor beheerders in de Microsoft Defender XDR (Microsoft 365-portal). Het bevat een gebruikersinterface voor het weergeven en doorzoeken van activiteitenlogboeken voor verschillende cloudservices, waaronder Power BI. Er worden dezelfde logboekgebeurtenissen weergegeven die afkomstig zijn uit de Microsoft Purview-nalevingsportal, naast andere gebeurtenissen zoals aanmeldingsactiviteiten van gebruikers vanuit Microsoft Entra-id.

De interface van het auditlogboek in Defender voor Cloud Apps is een goede optie voor handmatige controleprocessen. Zie Defender voor Cloud Apps verderop in dit artikel voor meer informatie.

Microsoft Sentinel en KQL

Microsoft Sentinel is een Azure-service waarmee u beveiligingsincidenten en bedreigingen kunt verzamelen, detecteren, onderzoeken en erop kunt reageren. Power BI kan worden ingesteld in Microsoft Sentinel als gegevensconnector, zodat auditlogboeken vanuit Power BI worden gestreamd naar Microsoft Sentinel Azure Log Analytics (een onderdeel van de Azure Monitor-service ). U kunt de Kusto-querytaal (KQL) gebruiken om de gebeurtenissen in het activiteitenlogboek te analyseren die zijn opgeslagen in Azure Log Analytics.

Het gebruik van KQL om de gegevens in Azure Monitor te doorzoeken is een goede optie voor het weergeven van een deel van het auditlogboek. Het is ook een goede optie voor handmatige controleprocessen. Zie Microsoft Sentinel verderop in dit artikel voor meer informatie.

Platformoverwegingen

Hier volgen enkele overwegingen voor het openen van controlegegevens.

  • Implementeert u een handmatig of geautomatiseerd controleproces? Bepaalde hulpprogramma's zijn sterk afgestemd op handmatige verwerking of geautomatiseerde verwerking. Een gebruiker voert bijvoorbeeld altijd interactief de try-it-functionaliteit uit, zodat deze alleen geschikt is voor handmatige controleprocessen.
  • Hoe gaat u verifiëren? Niet alle opties ondersteunen elke verificatieoptie. De try-it-functionaliteit ondersteunt bijvoorbeeld alleen gebruikersverificatie.
  • Hoe slaat u referenties veilig op? Verschillende technologieën hebben verschillende opties voor het opslaan van referenties. Zie De verificatiemethode verderop in dit artikel bepalen voor meer informatie.
  • Met welke technologie heeft uw team al ervaring? Als er een hulpprogramma is dat uw team de voorkeur geeft en vertrouwd is met het gebruik, begint u daar.
  • Wat kan uw team ondersteunen? Als een ander team de geïmplementeerde oplossing ondersteunt, moet u overwegen of dat team deze adequaat kan ondersteunen. Houd er ook rekening mee dat uw interne teams de ontwikkeling kunnen ondersteunen die door consultants wordt uitgevoerd.
  • Welk hulpprogramma hebt u goedkeuring om te gebruiken? Voor bepaalde hulpprogramma's en technologieën is mogelijk goedkeuring vereist. Dit kan te wijten zijn aan de kosten. Dit kan ook worden veroorzaakt door IT-beveiligingsbeleid.
  • Wat is uw voorkeur voor planning? Sommige technologieën nemen de beslissing voor u. Andere keren is het een andere beslissing die u moet nemen. Als u bijvoorbeeld PowerShell-scripts wilt schrijven, zijn er verschillende manieren waarop u ze kunt uitvoeren. Als u daarentegen een cloudservice zoals Azure Data Factory gebruikt, is de planning ingebouwd.

We raden u aan de rest van dit artikel te bekijken voordat u een technologie kiest voor toegang tot controlegegevens.

Controlelijst : bij het bepalen welke technologie moet worden gebruikt voor toegang tot controlegegevens, zijn belangrijke beslissingen en acties:

  • Bespreek met uw IT-medewerkers: neem contact op met uw IT-teams om erachter te komen of er bepaalde hulpprogramma's zijn die zijn goedgekeurd of de voorkeur hebben.
  • Verken opties met een klein proof-of-concept (POC): Experimenteer met een technische POC. Focus in eerste instantie op leren. Richt u vervolgens op uw beslissing voor wat u in de toekomst moet gebruiken.

De verificatiemethode bepalen

Hoe u verificatie wilt instellen, is een kritieke beslissing. Het is vaak een van de moeilijkste aspecten wanneer u aan de slag gaat met controle en controle. Houd zorgvuldig rekening met de beschikbare opties om een weloverwogen beslissing te nemen.

Belangrijk

Neem hierover contact op met uw IT- en beveiligingsteams. Neem de tijd om de basisprincipes te leren van hoe beveiliging in Microsoft Entra ID werkt.

Niet elke API op internet vereist verificatie. Voor alle Rest API's van Power BI is echter verificatie vereist. Wanneer u controlegegevens op tenantniveau opent, wordt het verificatieproces beheerd door het Microsoft Identity Platform. Het is een evolutie van de Microsoft Entra Identity Service die is gebouwd op industriestandaardprotocollen.

Tip

De woordenlijst van het Microsoft Identity Platform van termen is een resource waarmee u vertrouwd raakt met de basisconcepten.

Voordat u controlegegevens ophaalt, moet u zich eerst verifiëren. Dit staat bekend als aanmelden. De concepten van verificatie en autorisatie zijn gescheiden, maar zijn gerelateerd. Een verificatieproces verifieert de identiteit van wie de aanvraag doet. Een autorisatieproces verleent (of weigert) toegang tot een systeem of resource door te controleren wat de gebruiker of service-principal moet doen.

Wanneer een gebruiker of service-principal wordt geverifieerd, wordt een Microsoft Entra-toegangstoken uitgegeven aan een resourceserver, zoals een Power BI REST API of een Microsoft Graph API. Standaard verloopt een toegangstoken na één uur. U kunt indien nodig een vernieuwingstoken aanvragen.

Er zijn twee typen toegangstokens:

  • Gebruikerstokens: uitgegeven namens een gebruiker met een bekende identiteit.
  • Tokens voor alleen apps: uitgegeven namens een Microsoft Entra-toepassing (service-principal).

Zie Toepassings- en service-principalobjecten in Microsoft Entra-id voor meer informatie.

Notitie

Een Microsoft Entra-toepassing is een identiteitsconfiguratie waarmee een geautomatiseerd proces kan worden geïntegreerd met Microsoft Entra-id. In dit artikel wordt het een app-registratie genoemd. De term service-principal wordt ook vaak gebruikt in dit artikel. Deze termen worden verderop in deze sectie gedetailleerder beschreven.

Tip

De eenvoudigste manier om te verifiëren is door de cmdlet Verbinding maken-PowerBIServiceAccount te gebruiken vanuit de Power BI-beheermodule. Mogelijk ziet u andere verificatie-gerelateerde cmdlets in artikelen en blogberichten online. Er zijn bijvoorbeeld de Login-PowerBI en Login-PowerBIServiceAccount cmdlets, die aliassen voor Connect-PowerBIServiceAccount cmdlets zijn. Er is ook de cmdlet Disconnect-PowerBIServiceAccount waarmee u zich expliciet kunt afmelden aan het einde van een proces.

In de volgende tabel worden de twee verificatieopties beschreven.

Type verificatie Beschrijving Bedoeld voor Goede keuze voor handmatige controleprocessen Goede keuze voor geautomatiseerde controleprocessen
Gebruikersverificatie Meld u aan als gebruiker met behulp van de principal-naam van de gebruiker (e-mailadres) en een wachtwoord. Af en toe, interactief gebruik Gebruikersverificatie is een goede keuze voor handmatige controleprocessen
Verificatie van service-principal Meld u aan als een service-principal met behulp van een geheim (sleutel) dat is toegewezen aan een app-registratie. Lopende, geplande, onbeheerde bewerkingen Verificatie van service-principal is een goede keuze voor geautomatiseerde controleprocessen

Elke verificatieoptie wordt uitgebreid beschreven in de volgende sectie.

Gebruikersverificatie

Gebruikersverificatie is handig in de volgende situaties.

  • Handmatige controleprocessen: u wilt een script uitvoeren met behulp van uw gebruikersmachtigingen. Machtigingen kunnen op een van twee niveaus zijn, afhankelijk van het type API-aanvraag:
    • Beheer machtigingen voor beheerders-API's: U moet uw Power BI-beheerdersmachtigingen gebruiken om een aanvraag naar een beheer-API te verzenden.
    • Gebruikersmachtigingen voor gebruikers-API's: u moet uw Power BI-gebruikersmachtigingen gebruiken om een aanvraag naar een gebruikers-API te verzenden. Zie Een gebruikers-API of beheerders-API kiezen voor meer informatie.
  • Interactief aanmelden: u wilt zich interactief aanmelden. Hiervoor moet u uw e-mailadres en wachtwoord invoeren. U moet zich bijvoorbeeld interactief aanmelden om de Try-it-ervaring te gebruiken. Deze vindt u in de Microsoft API-documentatie.
  • Bijhouden wie toegang heeft tot tenantmetagegevens: wanneer afzonderlijke gebruikers en beheerders API-aanvragen verzenden, wilt u mogelijk controleren wie deze personen zijn. Wanneer u zich verifieert met een service-principal (hierna beschreven), is de gebruikers-id die is vastgelegd in het activiteitenlogboek de toepassings-id. Als meerdere beheerders zich verifiëren met dezelfde service-principal, kan het lastig zijn om te weten welke beheerder toegang heeft tot de gegevens.
  • Gedeeld beheerdersaccount: sommige IT-teams gebruiken een gedeeld beheerdersaccount. Afhankelijk van hoe deze wordt geïmplementeerd en beheerd, is dit mogelijk geen best practice. In plaats van een gedeeld account kunt u overwegen Om Microsoft Entra Privileged Identity Management (PIM) te gebruiken, die af en toe en tijdelijke Power BI-beheerdersrechten voor een gebruiker kan verlenen.
  • API's die alleen gebruikersverificatie ondersteunen: soms moet u mogelijk een API gebruiken die geen ondersteuning biedt voor verificatie door een service-principal. In documentatie noteert elke API of een service-principal deze kan aanroepen.

Belangrijk

Waar mogelijk raden we u aan service-principalverificatie te gebruiken voor geautomatiseerde processen.

Verificatie van service-principal

De meeste organisaties hebben één Microsoft Entra-tenant, dus de termen app-registratie en service-principal worden meestal door elkaar gebruikt. Wanneer u een Microsoft Entra-app registreert , zijn er twee onderdelen.

  • App-registratie: een app-registratie is wereldwijd uniek. Het is de globale definitie van een geregistreerde Microsoft Entra-app die door meerdere tenants kan worden gebruikt. Een app-registratie wordt ook wel een clienttoepassing of de actor genoemd. Normaal gesproken impliceert de term clienttoepassing een gebruikerscomputer. Dat is echter niet de situatie voor app-registraties. In Azure Portal vindt u Microsoft Entra-toepassingen op de pagina App-registraties in Microsoft Entra-id.
  • Service-principal: een service-principal is de lokale weergave van de app-registratie voor gebruik in uw specifieke tenant. De service-principal is afgeleid van de geregistreerde Microsoft Entra-app. Voor organisaties met meerdere Microsoft Entra-tenants kan naar dezelfde app-registratie worden verwezen door meer dan één service-principal. In Azure Portal vindt u service-principals op de pagina Bedrijfstoepassingen in Microsoft Entra-id.

Omdat de service-principal de lokale weergave is, is de verificatie van de service-principal de meest voorkomende manier om te verwijzen naar aanmeldingen.

Tip

Uw Microsoft Entra-beheerder kan u laten weten wie er een app-registratie in uw organisatie mag maken en toestemming geven voor een app-registratie.

Verificatie van de service-principal is handig in de volgende situaties.

  • Geautomatiseerde controleprocessen: u wilt een proces zonder toezicht uitvoeren volgens een schema.
  • U hoeft zich niet aan te melden bij de Power BI-service: u hoeft alleen verbinding te maken en gegevens te extraheren. Een service-principal kan zich niet aanmelden bij de Power BI-service.
  • Gedeelde toegang tot gegevens: u (persoonlijk) bent geen Power BI-beheerder, maar u bent gemachtigd om een service-principal te gebruiken. De service-principal is gemachtigd om beheerders-API's uit te voeren om gegevens op tenantniveau (of andere specifieke machtigingen) op te halen.
  • Gebruik door meerdere beheerders: u wilt toestaan dat meerdere beheerders of gebruikers dezelfde service-principal gebruiken.
  • Technische obstakels: er is een technische blokkering die het gebruik van gebruikersverificatie voorkomt. Veelvoorkomende technische obstakels zijn:
    • Meervoudige verificatie (MFA): Geautomatiseerde controleprocessen (die zonder toezicht worden uitgevoerd) kunnen niet worden geverifieerd met behulp van een gebruikersaccount wanneer meervoudige verificatie is ingeschakeld.
    • Wachtwoord-hashsynchronisatie: Microsoft Entra ID vereist wachtwoord-hashsynchronisatie voor een gebruikersaccount om te verifiëren. Soms kunnen IT of een cyberbeveiligingsteam deze functionaliteit uitschakelen.
App-registratiedoel en naamconventie

Elke app-registratie moet een duidelijke naam hebben die het doel en de doelgroep beschrijft (die de app-registratie kan gebruiken).

Overweeg een naamconventie te implementeren, zoals: <Workload> - <Doel> - <Doelgroep> - <Objecttype>

Hier volgen de onderdelen van de naamconventie.

  • Workload: Meestal gelijk aan een gegevensbron (bijvoorbeeld Power BI-gegevens of Microsoft Graph-gegevens).
  • Doel: vergelijkbaar met het machtigingsniveau (bijvoorbeeld Lezen versus ReadWrite). Zoals hieronder beschreven, helpt het doel u om het principe van minimale bevoegdheden te volgen wanneer u afzonderlijke app-registraties maakt die alleen gegevens kunnen lezen.
  • Doelgroep: optioneel. Afhankelijk van de workload en het doel kunt u met de doelgroep de beoogde gebruikers van de app-registratie bepalen.
  • Objecttype:EntraApp is voor duidelijkheid opgenomen.

Uw naamconventie kan specifieker zijn wanneer u meerdere tenants of meerdere omgevingen (zoals ontwikkeling en productie) hebt.

In de volgende tabel ziet u voorbeelden van app-registraties die kunnen worden gebruikt om controlegegevens op tenantniveau te extraheren:

Naam van app-registratie Doel Doelgroep
PowerBIData-Read-Beheer APIs-EntraApp Extraheer tenantbrede metagegevens voor controle en beheer van Power BI. Beheer API's zijn altijd alleen-lezen en zijn mogelijk niet gemachtigd in Microsoft Entra ID (alleen power BI-tenantinstelling). Power BI-beheerders en het Center of Excellence
PowerBIData-ReadWrite-PowerBI Beheer istrators-EntraApp De Power BI-tenant beheren. Vereist lees-/schrijfmachtigingen voor het maken of bijwerken van resources. Power BI-beheerders en het Center of Excellence
GraphData-Read-PowerBI Beheer istrators-EntraApp Gebruikers en groepsgegevens extraheren voor controle en beheer van Power BI. Hiervoor zijn leesmachtigingen vereist. Power BI-beheerders en het Center of Excellence

Het beheren van meerdere app-registraties voor verschillende doeleinden vergt meer inspanning. U kunt echter profiteren van verschillende voordelen.

  • Bekijk waarvoor de app-registratie is bedoeld en waarom: Wanneer u de client-id van de app-registratie in uw controlegegevens ziet, krijgt u een idee van waar deze voor is gebruikt en waarom. Dat is een belangrijk voordeel van het maken van afzonderlijke app-registraties (in plaats van slechts één voor alle doeleinden te gebruiken).
  • Bekijk wie de app-registratie bedoeld is om te worden gebruikt door: Wanneer u de client-id van de app-registratie ziet, wordt weergegeven in uw controlegegevens, hebt u een idee van wie deze gebruikte.
  • Vermijd overprovisioningsmachtigingen: u kunt het principe van minimale bevoegdheden volgen door afzonderlijke app-registraties te verstrekken aan verschillende groepen personen die verschillende behoeften hebben. U kunt overprovisioningsmachtigingen voorkomen met behulp van een alleen-lezen app-registratie wanneer schrijfmachtigingen niet nodig zijn. U hebt bijvoorbeeld een aantal zeer geschikte selfservicegebruikers die gegevens willen verzamelen over hun semantische modellen; ze hebben toegang nodig tot een service-principal met leesmachtigingen . Overwegende dat er mogelijk satellietleden van het Center of Excellence werken voor het financiële team dat programmatisch semantische modellen beheert; ze hebben toegang nodig tot een service-principal met schrijfmachtigingen .
  • Weten wie het geheim moet hebben: het geheim voor elke app-registratie mag alleen worden gedeeld met de personen die het nodig hebben. Wanneer het geheim wordt geroteerd (verderop in deze sectie beschreven), is de impact kleiner wanneer u afzonderlijke app-registraties gebruikt voor verschillende behoeften. Dit is handig wanneer u het geheim moet draaien omdat een gebruiker de organisatie verlaat of rollen wijzigt.
Machtigingen voor app-registratie

Er zijn twee manieren waarop een app-registratie toegang heeft tot gegevens en resources. Dit omvat machtigingen en toestemming.

  • Machtigingen voor alleen apps: toegang en autorisatie worden verwerkt door de service-principal zonder een aangemelde gebruiker. Deze verificatiemethode is handig voor automatiseringsscenario's. Wanneer u alleen-app-machtigingen gebruikt, is het essentieel om te begrijpen dat machtigingen niet zijn toegewezen in Microsoft Entra-id. In plaats daarvan worden machtigingen op twee manieren toegewezen:
    • Voor het uitvoeren van beheerders-API's: Bepaalde Power BI-tenantinstellingen bieden toegang tot de eindpunten voor de beheer-API's (die tenantbrede controlemetagegevens retourneren). Zie Instellingen voor Power BI-tenants verderop in dit artikel instellen voor meer informatie.
    • Voor het uitvoeren van gebruikers-API's: Power BI-werkruimte- en itemmachtigingen zijn van toepassing. Standaard Power BI-machtigingen bepalen welke gegevens kunnen worden geretourneerd naar een service-principal bij het uitvoeren van gebruikers-API's (die controlegegevens retourneren op basis van machtigingen van de gebruiker of service-principal die de API aanroept).
  • Gedelegeerde machtigingen: machtigingen op basis van bereik worden gebruikt. De service-principal opent gegevens namens de gebruiker die momenteel is aangemeld. Dit betekent dat de service-principal geen toegang heeft tot iets anders dan waartoe de aangemelde gebruiker toegang heeft. Houd er rekening mee dat dit een ander concept is dan alleen-gebruikersverificatie, zoals eerder is beschreven. Omdat een aangepaste toepassing vereist is om de combinatie van gebruikers- en app-machtigingen goed te verwerken, worden gedelegeerde machtigingen zelden gebruikt voor controlescenario's. Dit concept wordt meestal verkeerd begrepen, wat leidt tot veel app-registraties die overprovisioned zijn met machtigingen.

Belangrijk

In dit artikel ligt de focus alleen op gebruikersverificatie of app-only-verificatie. Gedelegeerde machtigingen (met een interactieve gebruiker en de service-principal) kunnen een belangrijke rol spelen bij het programmatisch insluiten van Power BI-inhoud. We raden u echter sterk af om gedelegeerde machtigingen in te stellen voor het extraheren van controlegegevens. Elke API beperkt hoe vaak deze kan worden uitgevoerd (met beperking), zodat het niet praktisch is om verschillende gebruikers rechtstreeks toegang te geven tot de onbewerkte controlegegevens. In plaats daarvan raden we u aan de onbewerkte controlegegevens eenmaal te extraheren (met een gecentraliseerd proces) en vervolgens de gecureerde controlegegevens beschikbaar te maken voor geautoriseerde gebruikers downstream.

Zie Een Microsoft Entra-app registreren verderop in dit artikel voor meer informatie.

App-registratiegeheimen

Een app-registratie heeft vaak een geheim toegewezen. Het geheim wordt gebruikt als sleutel voor verificatie en heeft een vervaldatum. Daarom moet u plannen hoe u de sleutel regelmatig draait en hoe u de nieuwe sleutel communiceert met geautoriseerde gebruikers.

U moet zich ook zorgen maken over waar u het geheim veilig kunt opslaan. Een organisatiewachtwoordkluis, zoals Azure Key Vault, is een uitstekende keuze.

Tip

Als alternatief voor het gebruik van een geheim kunt u een beheerde identiteit gebruiken. Een beheerde identiteit elimineert de noodzaak om referenties te beheren. Als u services zoals Azure Functions of Azure Data Factory wilt gebruiken om de gegevens te extraheren, is een beheerde identiteit een goede optie om te onderzoeken.

Referenties veilig beheren

Ongeacht of u gebruikersverificatie of service-principalverificatie gebruikt, is een van de grootste uitdagingen het veilig beheren van wachtwoorden, geheimen en sleutels.

Let op

De eerste regel is een regel die veel mensen schenden: wachtwoorden en sleutels mogen nooit in tekst zonder opmaak in een script worden weergegeven. Veel artikelen, blogs en voorbeelden online doen dat voor het gemak. Het is echter een slechte praktijk die moet worden vermeden. Iedereen die het script (of het bestand) verkrijgt, kan mogelijk toegang krijgen tot dezelfde gegevens waartoe de auteur toegang heeft.

Hier volgen verschillende veilige methoden die u kunt gebruiken om wachtwoorden, geheimen en sleutels te beheren.

  • Integreer indien mogelijk met Azure Key Vault of een ander organisatiewachtwoordkluissysteem.
  • Gebruik referenties en beveiligde tekenreeksen in uw PowerShell-scripts. Een referentie werkt voor zowel gebruikersverificatie als service-principal-verificatie. U kunt echter geen referentie gebruiken wanneer meervoudige verificatie is ingeschakeld voor een gebruikersaccount.
  • Vraag om een wachtwoord in uw PowerShell-script of gebruik interactieve verificatie met een browser.
  • Gebruik de module Secret Management voor PowerShell die is gepubliceerd door Microsoft. Er kunnen waarden worden opgeslagen met behulp van een lokale kluis. Het kan ook worden geïntegreerd met een externe Azure Key Vault, wat handig is wanneer er meerdere beheerders in uw organisatie zijn die met dezelfde scripts werken.
  • Maak een aangepaste connector voor Power BI Desktop, zodat deze referenties veilig kan verwerken. Sommige aangepaste connectors zijn beschikbaar van communityleden (meestal op GitHub).

Tip

We raden u aan om contact op te stellen met uw IT- en beveiligingsteams om de beste methode te kiezen of uw oplossing referenties op een veilige manier beheert.

Microsoft Authentication Library

Ondersteuning voor Azure AD Authentication Library (ADAL) is beëindigd in december 2022. In de toekomst moet u Microsoft Authentication Library (MSAL) gebruiken. Het beveiligingsteam in uw organisatie moet bekend zijn met deze belangrijke wijziging.

Hoewel het niet belangrijk is voor Power BI-professionals om de overgang naar MSAL diep te begrijpen, moet u zich houden aan de volgende aanbevelingen.

  • Gebruik de nieuwste versie van de Power BI-beheermodule wanneer u verifieert met de powershell-cmdlet Verbinding maken-PowerBIServiceAccount. Het is overgeschakeld van ADAL naar MSAL in versie 1.0.946 (26 februari 2021).
  • Gebruik het Microsoft Entra V2-eindpunt wanneer u zich rechtstreeks in uw script verifieert. Het Microsoft Entra V2-eindpunt maakt gebruik van MSAL, terwijl het Microsoft Entra V1-eindpunt ADAL gebruikt.
  • Stop met het gebruik van API's en modules die zijn afgeschaft. Zie afgeschafte API's en modules verderop in dit artikel voor meer informatie.
  • Als u online een communityoplossing vindt, moet u ervoor zorgen dat deze MSAL gebruikt voor verificatie in plaats van ADAL.

Controlelijst : bij het bepalen hoe u verificatie beheert, zijn belangrijke beslissingen en acties:

  • Bepaal welk type verificatie u wilt gebruiken: bepaal of gebruikersverificatie of service-principal-verificatie het meest geschikt is, afhankelijk van het type controleoplossing dat u wilt maken.
  • Plan de app-registraties die u nodig hebt: Houd rekening met uw vereisten, workloads en doelgroep (gebruikers van elke app-registratie). Plan hoeveel app-registraties u moet maken om deze behoeften te ondersteunen.
  • Maak een naamconventie voor app-registraties: stel een naamconventie in waarmee u eenvoudig inzicht hebt in het beoogde doel en de beoogde gebruikers van elke app-registratie.
  • Plannen voor het veilig beheren van referenties: Overweeg manieren om wachtwoorden, geheimen en sleutels veilig te beheren. Bedenk welke documentatie en training nodig zijn.
  • Bevestig het gebruik van MSAL: Bepaal of er bestaande handmatige of geautomatiseerde controleoplossingen zijn die afhankelijk zijn van ADAL. Maak indien nodig een plan om deze oplossingen te herschrijven voor het gebruik van de nieuwere MSAL-verificatiebibliotheek.

Een gebruikers-API of beheer-API kiezen

Bij het ophalen van controlegegevens is het belangrijk om het juiste type API te gebruiken.

Er zijn twee soorten API's die u moet overwegen.

  • Gebruikers-API's: vertrouw op de machtigingen van de aangemelde gebruiker (of service-principal) om aanvragen naar de API te verzenden. Een manier om bijvoorbeeld een lijst met semantische modellen in een werkruimte te retourneren, is met een gebruikers-API. Machtigingen voor het lezen van semantische modellen kunnen worden verleend door de werkruimterol of machtigingen per item. Er zijn twee manieren om gebruikers-API's uit te voeren:
    • Gebruikersverificatie: de aangemelde gebruiker moet gemachtigd zijn om toegang te krijgen tot de werkruimte of het item.
    • Verificatie van de service-principal: de service-principal moet gemachtigd zijn voor toegang tot de werkruimte of het item.
  • Beheer API's: Metagegevens ophalen uit de tenant. Dit wordt soms ook wel het organisatiebereik genoemd. Als u bijvoorbeeld een lijst met alle semantische modellen in de tenant wilt retourneren, gebruikt u een beheer-API. Er zijn twee manieren om beheerders-API's uit te voeren:
    • Gebruikersverificatie: de aangemelde gebruiker moet een Power BI-beheerder zijn om beheerders-API's uit te voeren.
    • Verificatie van de service-principal: de service-principal moet gemachtigd zijn om beheerders-API's uit te voeren (zonder te vertrouwen op beveiligingsmachtigingen zoals een gebruikers-API).

Tip

Alle beheer-API's behoren tot de Beheer-bewerkingsgroep. Elke API met het achtervoegsel As Beheer is een beheerders-API. Alle resterende API's zijn gebruikers-API's.

Bekijk een voorbeeld waarin u een lijst met semantische modellen moet verkrijgen. In de volgende tabel ziet u zes API-opties die u hiervoor kunt gebruiken. Vier opties zijn gebruikers-API's en twee opties zijn beheerders-API's. Het bereik en het aantal geretourneerde items verschillen, afhankelijk van de API die u kiest.

API-naam Type of API Scope Aantal semantische modellen
Gegevensset ophalen User Persoonlijke werkruimte Eén
Gegevenssets ophalen User Persoonlijke werkruimte Alle
Gegevensset ophalen in groep User Eén werkruimte Een, mits de aangemelde gebruiker gemachtigd is om het semantische model te lezen
Gegevenssets ophalen in groep User Eén werkruimte Alle, mits de aangemelde gebruiker gemachtigd is om elk semantisch model te lezen
Gegevenssets in groep ophalen als Beheer Beheerder Eén werkruimte Alle
Gegevenssets ophalen als Beheer Beheerder Hele tenant Alle

Notitie

Sommige API-namen bevatten de term Groep als verwijzing naar een werkruimte. Deze term is afkomstig van het oorspronkelijke Power BI-beveiligingsmodel, dat is gebaseerd op Microsoft 365-groepen. Hoewel het Power BI-beveiligingsmodel in de loop der jaren aanzienlijk is ontwikkeld, blijven de bestaande API-namen ongewijzigd om te voorkomen dat bestaande oplossingen worden onderbroken.

Zie Tenantinstellingen voor Power BI instellen verderop in dit artikel voor meer informatie over tenantinstellingen.

Controlelijst : wanneer u kiest of u een gebruikers-API of een beheer-API wilt gebruiken, zijn belangrijke beslissingen en acties:

  • Raadpleeg de gegevensvereisten: Verzamel en documenteer de belangrijkste zakelijke vereisten voor een controleoplossing. Bepaal op basis van het type gegevens dat nodig is, of een gebruikersbereik of organisatiebereik geschikt is.
  • Test de resultaten: Experimenteer wat. Test de nauwkeurigheid van de resultaten die worden geretourneerd door de verschillende API's.
  • Controlemachtigingen: Voor bestaande controleoplossingen controleert u of machtigingen juist zijn toegewezen voor Power BI-beheerders en -service-principals. Voor nieuwe controleoplossingen controleert u welke verificatiemethode wordt gebruikt.

API's of PowerShell-cmdlets kiezen

Een belangrijke beslissing om te nemen is of u PowerShell-cmdlets wilt gebruiken wanneer deze beschikbaar zijn voor de specifieke gegevens die u wilt ophalen. Deze beslissing is belangrijk als u hebt besloten dat PowerShell een van de technologieën is die u gebruikt voor toegang tot controlegegevens.

PowerShell is een oplossing voor taakautomatisering. De term PowerShell is een collectieve term die verwijst naar de scripttaal, een opdrachtregelshelltoepassing en een framework voor configuratiebeheer. PowerShell Core is de nieuwste versie van PowerShell, die wordt uitgevoerd in Windows, Linux en macOS.

Een PowerShell-cmdlet is een opdracht waarmee een actie wordt uitgevoerd. Een PowerShell-module is een pakket dat PowerShell-leden bevat, zoals cmdlets, providers, functies, werkstromen, variabelen en aliassen. U downloadt en installeert modules.

Een PowerShell-module maakt een abstractielaag over de API's. Met de cmdlet Get-PowerBIActivityEvent worden bijvoorbeeld controlegebeurtenissen opgehaald (of opgehaald) voor een Power BI-tenant. Met deze PowerShell-cmdlet worden de gegevens opgehaald uit de REST API voor Get Activity Events . Over het algemeen is het eenvoudiger om aan de slag te gaan met behulp van de cmdlets, omdat het de toegang tot de onderliggende API's vereenvoudigt.

Alleen een subset van de API's zijn beschikbaar als PowerShell-cmdlets. Wanneer u uw volledige controleoplossing blijft uitbreiden, is het waarschijnlijk dat u een combinatie van cmdlets en API's gebruikt. In de rest van deze sectie kunt u bepalen op welke manier u toegang krijgt tot de gegevens.

PowerShell-modules

Microsoft heeft twee PowerShell-modules gepubliceerd die cmdlets bevatten die betrekking hebben op Power BI. Dit zijn de Power BI-beheermodule en de Data Gateway-module. Deze PowerShell-modules fungeren als api-wrapper boven op de onderliggende Power BI REST API's. Met deze PowerShell-modules kunt u eenvoudiger scripts schrijven.

Tip

Naast de modules die door Microsoft zijn gepubliceerd, zijn er vrijelijk beschikbare PowerShell-modules en -scripts (meestal op GitHub) gepubliceerd door leden van de Power BI-community, partners en Microsoft Most Valued Professionals (MVP's).

Beginnen met een community-oplossing kan een belangrijke rol spelen bij het bouwen van uw end-to-end-controleoplossing. Als u ervoor kiest om een vrij beschikbare oplossing te gebruiken, moet u deze volledig testen. Raak vertrouwd met hoe het werkt, zodat u uw oplossing in de loop van de tijd effectief kunt beheren. Uw IT-afdeling kan criteria hebben voor het gebruik van openbaar beschikbare communityoplossingen.

Power BI-beheermodule

De Power BI-beheermodule is een samengetelde module die specifieke Power BI-modules bevat voor beheer, capaciteiten, werkruimten en meer. U kunt ervoor kiezen om de rollup-module te installeren om alle modules te verkrijgen of u kunt specifieke modules installeren. Alle Power BI-beheermodules worden ondersteund in Zowel Windows PowerShell als PowerShell Core.

Belangrijk

U wordt aangeraden windows PowerShell niet meer te gebruiken (waarvoor PowerShell Core niet kan worden uitgevoerd). Gebruik in plaats daarvan een van de moderne code-editors die PowerShell Core ondersteunen. Windows PowerShell ISE (geïntegreerde scriptomgeving) is alleen geschikt voor het uitvoeren van PowerShell versie 5.1, die niet meer wordt bijgewerkt. Windows PowerShell is nu afgeschaft, dus we raden u aan PowerShell Core te gebruiken voor alle nieuwe ontwikkelwerkzaamheden.

Hier volgen verschillende veelgebruikte cmdlets die u kunt gebruiken om controlegegevens op te halen.

Beheermodule Cmdlet Doel
Profiel Verbinding maken-PowerBIServiceAccount Een Power BI-gebruiker of -service-principal verifiëren.
Beheerder Get-PowerBIActivityEvent Gebeurtenissen in het Power BI-activiteitenlogboek voor de tenant weergeven of extraheren.
Workspaces Get-PowerBIWorkspace Een lijst met werkruimten compileren.
Rapporten Get-PowerBIReport Compileer een lijst met rapporten voor een werkruimte of de tenant.
Gegevens Get-PowerBIDataset Compileer een lijst met semantische modellen voor een werkruimte of de tenant.
Profiel Invoke-PowerBIRestMethod Een REST API-aanvraag (opdracht) verzenden. Deze cmdlet is een goede optie omdat deze een van de Power BI REST API's kan aanroepen. Het is ook een goede keuze als u de eenvoudigere vorm van verificatie wilt gebruiken met behulp van de Connect-PowerBIServiceAccount cmdlet en een API kunt aanroepen die geen bijbehorende PowerShell-cmdlet heeft. Zie Overwegingen voor het gebruik van PowerShell-cmdlets verderop in deze sectie voor meer informatie.

Tip

Er zijn andere cmdlets beschikbaar voor het beheren en publiceren van inhoud. De focus van dit artikel ligt echter op het ophalen van controlegegevens.

U kunt de Power BI-beheermodule downloaden uit de PowerShell Gallery. De eenvoudigste manier om modules te installeren is door PowerShellGet te gebruiken.

U wordt aangeraden de power BI-beheerpakketmodule te installeren. Op die manier zijn alle cmdlets die u nodig hebt mogelijk beschikbaar. U hebt minimaal de profielmodule (voor verificatie) en eventuele specifieke modules nodig die de cmdlets bevatten die u wilt gebruiken.

Let op

Zorg ervoor dat u de modules up-to-date houdt op elke server, gebruikerscomputer en cloudservice (zoals Azure Automation) waar u PowerShell gebruikt. Als de modules niet regelmatig worden bijgewerkt, kunnen onvoorspelbare fouten of problemen optreden. Met sommige hulpprogramma's (zoals Visual Studio Code) kunt u de modules bijgewerkt houden. Houd er ook rekening mee dat PowerShellGet niet automatisch oudere versies van een module verwijdert wanneer u een nieuwere versie installeert of bijwerkt. Er worden nieuwere versies naast de oudere versies geïnstalleerd. U wordt aangeraden te controleren op geïnstalleerde versies en regelmatig oudere versies te verwijderen.

Data Gateway-module

De Data Gateway-module bevat cmdlets waarmee gegevens worden opgehaald uit een on-premises gegevensgateway en de bijbehorende gegevensbronnen. De Data Gateway-module wordt alleen ondersteund in PowerShell Core. Dit wordt niet ondersteund in Windows PowerShell.

In tegenstelling tot de Power BI-beheermodule (eerder beschreven), bevat de Data Gateway-module geen beheer-cmdlets. Veel van de cmdlets (en de bijbehorende gateway-API's) vereisen dat de gebruiker beheerdersrechten voor de gateway heeft.

Waarschuwing

Het is niet mogelijk om een service-principal toe te wijzen als gatewaybeheerder (zelfs als de service-principal lid is van een beveiligingsgroep). Plan daarom gebruikersreferenties te gebruiken bij het ophalen van informatie over gegevensgateways.

Hier volgen verschillende cmdlets uit de Data Gateway-module die u kunt gebruiken om controlegegevens op te halen.

Cmdlet Doel
Verbinding maken-DataGatewayServiceAccount Een Power BI-gebruiker verifiëren (meestal vereist dat de gebruiker deel uitmaakt van de rol van gatewaybeheerder).
Get-DataGatewayCluster Compileer een lijst met gatewayclusters.
Get-DataGatewayClusterDataSource Compileer een lijst met gegevensbronnen voor een gatewaycluster.
Get-DataGatewayInstaller Controleer welke gebruikers gateways in de organisatie mogen installeren en registreren.

U kunt de Data Gateway-module downloaden uit de PowerShell Gallery.

Technieken voor het gebruik van PowerShell

U kunt PowerShell op verschillende manieren gebruiken. De beslissing die u neemt is belangrijk.

In de volgende tabel worden drie verschillende technieken beschreven voor het gebruik van PowerShell.

Techniek Beschrijving Voorbeeld
Gebruik PowerShell-cmdlets om verificatie te vereenvoudigen en API's rechtstreeks aan te roepen. Aanbevolen benadering Met deze techniek is er een balans tussen eenvoud en flexibiliteit. De cmdlet Invoke-PowerBIRestMethod is beschikbaar via de module Power BI-beheerprofiel. Deze cmdlet wordt vaak een Swiss Army Knife genoemd, omdat u deze kunt gebruiken om een van de Power BI REST API's aan te roepen. Het voordeel van het gebruik van deze techniek is dat u verificatie kunt vereenvoudigen en vervolgens een van de Rest API's van Power BI kunt aanroepen. We raden u ten zeerste aan deze techniek te gebruiken. Nadat u bent geverifieerd met de cmdlet Verbinding maken-PowerBIServiceAccount, gebruikt u de cmdlet Invoke-PowerBIRestMethod om gegevens op te halen uit de gewenste API (bijvoorbeeld Pijplijngebruikers ophalen als Beheer).
Gebruik cmdlets uit PowerShell zoveel mogelijk, zowel voor verificatie als voor het ophalen van gegevens. Met deze techniek wordt PowerShell uitgebreid gebruikt. PowerShell wordt gebruikt om het uitvoeren van het script te coördineren en PowerShell-modules worden waar mogelijk gebruikt voor toegang tot de gegevens. Hierdoor ontstaat een grotere afhankelijkheid van PowerShell op basis van meerdere aspecten. Gebruik na verificatie met de cmdlet Verbinding maken-PowerBIServiceAccount een cmdlet (bijvoorbeeld Get-PowerBIActivityEvent) om gegevens op te halen.
Gebruik PowerShell alleen om het uitvoeren van het proces te coördineren. PowerShell-modules worden zo weinig mogelijk gebruikt. Met deze techniek is er minder afhankelijkheid van PowerShell als hulpprogramma, omdat het primaire gebruik ervan is het inschakelen van API-aanroepen te organiseren. Er wordt slechts één algemene PowerShell-module gebruikt voor toegang tot API's (geen van de modules uit de Power BI-beheermodules worden gebruikt). Nadat u bent geverifieerd met behulp van de Microsoft Authentication Library (MSAL), roept u de gewenste API aan (bijvoorbeeld Pijplijngebruikers ophalen als Beheer) met behulp van de algemene cmdlet Invoke-RestMethod om gegevens op te halen.

In de bovenstaande tabel beschrijft de eerste techniek een benadering die het gebruiksgemak met flexibiliteit in balans brengt. Deze aanpak biedt de beste balans voor de behoeften van de meeste organisaties, daarom wordt het aanbevolen. Sommige organisaties hebben mogelijk bestaande IT-beleidsregels en personeelsvoorkeuren die van invloed zijn op de wijze waarop u PowerShell wilt gebruiken.

Tip

U kunt de PowerShell-cmdlet Invoke-ASCmd gebruiken om DAX-, XMLA- en TMSL-scripts te maken en uit te voeren. Deze use cases vallen echter buiten het bereik van dit artikel. Zie Controle op gegevensniveau voor meer informatie over het uitvoeren van query's op dynamische beheerweergaven (DMV's).

Technische gebruikers (en beheerders) kunnen de Power BI-beheermodules gebruiken om gegevens op te halen of bepaalde aspecten van inhoudsbeheer te automatiseren.

  • Voor beheerders: stel de -Scope parameter in voor toegang tot Organization entiteiten in de hele tenant (bijvoorbeeld om een lijst met alle werkruimten op te halen).
  • Voor technische gebruikers: stel de -Scope parameter in op Individual (of laat de parameter weg) om toegang te krijgen tot entiteiten die tot de gebruiker behoren (bijvoorbeeld om een lijst met werkruimten op te halen waartoe de gebruiker gemachtigd is).

Overweeg een scenario waarin u een lijst met semantische modellen moet verkrijgen. Als u ervoor kiest om rechtstreeks met de API's te werken, moet u opgeven welke API moet worden aangeroepen. Als u er echter voor kiest om de Get-PowerBIDataset-cmdlet te gebruiken, kunt u de -Scope parameter instellen om een gebruikersspecifieke of tenantbrede lijst met semantische modellen op te halen. De keuze die u maakt, is afhankelijk van uw beslissing voor het gebruik van PowerShell (behandeld in de vorige tabel).

In de volgende tabel wordt beschreven hoe de parameters die in de PowerShell-cmdlet worden gebruikt, worden omgezet in de API PowerShell-aanroepen.

Cmdlet-parameters API die door de cmdlet wordt gebruikt Type of API Scope Opgehaalde items
-DatasetID {DatasetID}
-Scope Individual		 Gegevensset ophalen User Persoonlijke werkruimte Eén semantisch model
-Scope Individual Gegevenssets ophalen User Persoonlijke werkruimte Alle semantische modellen
-DatasetID {DatasetID}
-GroupID {WorkspaceID}		 Gegevensset ophalen in groep User Eén werkruimte Eén semantisch model, mits de aangemelde gebruiker gemachtigd is om het semantische model te lezen
-GroupID {WorkspaceID} Gegevenssets ophalen in groep User Eén werkruimte Alle semantische modellen, mits de aangemelde gebruiker gemachtigd is om toegang te krijgen tot de werkruimte en het semantische model te lezen
-GroupID {WorkspaceID}
-Scope Organization		 Gegevenssets in groep ophalen als Beheer Beheerder Eén werkruimte Alle semantische modellen
-Scope Organization Gegevenssets ophalen als Beheer Beheerder Hele tenant Alle semantische modellen
Overwegingen voor het gebruik van PowerShell-cmdlets

De Power BI PowerShell-cmdlets zijn eenvoudiger te gebruiken omdat ze een deel van de complexiteit van de REST API-aanroepen abstraheren.

Hier volgen enkele manieren waarop de cmdlets de toegang tot controlegegevens vereenvoudigen.

  • Verificatie: de eenvoudigste manier om te verifiëren in een PowerShell-script is het gebruik van de Connect-PowerBIServiceAccount cmdlet.
  • Eenvoud: het is eenvoudiger om aan de slag te gaan, omdat de technieken voor het ophalen van controlegegevens eenvoudig zijn. Houd er rekening mee dat wanneer u de cmdlet Get-PowerBIActivityEvent gebruikt, u één dag met controlegegevens ophaalt. Wanneer u echter rechtstreeks de REST API voor get-activiteitsgebeurtenissen aanroept, haalt u één uur controlegegevens op. Dus wanneer u de REST API gebruikt om één dag controlegegevens op te halen, moet u een lus gebruiken om de API 24 keer aan te roepen om elk uur van de dag te extraheren.
  • Paginering van grote resultatensets: Grote resultatensets worden efficiënt opgehaald door paginering. Paginering omvat het ophalen van één segment van de resultaten tegelijk. De cmdlets beheren automatisch paginering voor u. Wanneer u echter rechtstreeks de REST API's gebruikt, moet uw script een vervolgtoken controleren om te bepalen of er meer resultaten moeten komen. Het script moet doorgaan met het ophalen van segmenten van resultaten totdat er geen vervolgtoken is ontvangen. Zie REST API voor activiteitsevenementen voor een voorbeeld van het gebruik van een vervolgtoken.
  • Verloop van toegangstokens: Na verificatie wordt een toegangstoken geretourneerd. Deze verloopt standaard na één uur. De cmdlets verwerken het verlopen van toegangstokens voor u. Op die manier hoeft u geen logica te schrijven om een vernieuwingstoken aan te vragen.
  • Opmaak: de gegevens die door een cmdlet worden geretourneerd, zijn iets mooier opgemaakt dan de gegevens die worden geretourneerd door de REST API. De uitvoer is gebruiksvriendelijker. Voor geautomatiseerde controleprocessen is dat waarschijnlijk geen probleem. Voor handmatige controleprocessen kan de mooier opmaak echter nuttig zijn.
Overwegingen voor het rechtstreeks gebruiken van de REST API's

Soms zijn er voordelen voor het rechtstreeks aanroepen van de Power BI REST API's.

  • Er zijn nog veel meer API's beschikbaar: er zijn meer REST API's beschikbaar dan PowerShell-cmdlets. Vergeet echter niet de flexibiliteit van de cmdlet Invoke-PowerBIRestMethod , die u kunt gebruiken om een van de Power BI REST API's aan te roepen.
  • Frequentie van updates: Microsoft werkt de REST API's vaker bij dan de PowerShell-modules worden bijgewerkt. Als er bijvoorbeeld een nieuw kenmerk wordt toegevoegd aan het antwoord gegevensset-API ophalen, kan het enige tijd duren voordat het beschikbaar komt in de resultaten van de Cmdlet Get-PowerBIDataset .
  • Minder taal-/hulpprogrammaafhankelijkheid: wanneer u de REST API's rechtstreeks gebruikt (in plaats van een cmdlet), hoeft u PowerShell niet te gebruiken. U kunt er ook voor kiezen om PowerShell alleen te gebruiken om veel API's in een script aan te roepen. Door eventuele afhankelijkheid van PowerShell te verwijderen (of te vermijden), kunt u uw logica op een bepaald moment in een andere taal herschrijven. Wanneer uw IT- of ontwikkelaarsteam sterke voorkeuren heeft voor hulpprogramma's en talen, kan minder afhankelijkheid een belangrijke overweging zijn om rekening mee te houden.

Ongeacht welke methode u wilt gebruiken, kunnen de REST API's na verloop van tijd worden gewijzigd. Wanneer een technologie zich ontwikkelt, kunnen API's (en PowerShell-modules) worden afgeschaft en vervangen. Daarom raden we u aan om doelbewust scripts te maken die eenvoudig te onderhouden en bestand zijn tegen wijzigingen.

Controlelijst : wanneer u kiest of u rechtstreeks toegang wilt krijgen tot de REST API's of met behulp van PowerShell-cmdlets, zijn belangrijke beslissingen en acties:

  • Neem contact op met IT over het gebruik van PowerShell: neem contact op met de relevante IT-team(s) om te bepalen of er bestaande interne vereisten of voorkeuren zijn over hoe PowerShell kan worden gebruikt.
  • Bepaal hoe u PowerShell wilt gebruiken: bepaal welke PowerShell-technieken u wilt gebruiken en of u uw afhankelijkheid van PowerShell opzettelijk wilt vergroten of verminderen. Overweeg of interne communicatie of training noodzakelijk is.
  • Voer een upgrade uit naar PowerShell Core: Onderzoek met behulp van PowerShell Core. Bepaal of beheerderscomputers moeten worden bijgewerkt. Overweeg welke bestaande scripts moeten worden getest. Bepaal of beheerders of ontwikkelaars aanvullende training nodig hebben om hun vaardigheden te upgraden.
  • Bepaal welke PowerShell-modules moeten worden gebruikt: Overweeg of de Power BI-beheermodules en/of de Data Gateway-module worden gebruikt.
  • Bepaal of communityprojecten zijn toegestaan: Bepaal of u bent toegestaan (of zelfs aangemoedigd) om PowerShell-modules te gebruiken die online beschikbaar zijn (versus modules die door Microsoft zijn gepubliceerd). Neem contact op met IT om te bepalen of er criteria zijn voor communityprojecten die online zijn verkregen.
  • Verduidelijken hoe u communityprojecten kunt ondersteunen: als PowerShell-communityprojecten zijn toegestaan, moet u overwegen wie verantwoordelijk is voor de ondersteuning ervan zodra ze intern worden gebruikt.
  • Voltooi een klein proof of concept (POC): Experimenteer met een technische POC. Bevestig de clienthulpprogramma's van uw voorkeur en de methode voor toegang tot gegevens.
  • Bepaal hoe u geavanceerde gebruikers ondersteunt: Overweeg hoe u technische gebruikers gaat ondersteunen die zelf automatisering maken met behulp van de gebruikers-API's.

Bepalen waar controlegegevens moeten worden opgeslagen

Wanneer u van plan bent een end-to-end-controleoplossing te bouwen, moet u bepalen waar de onbewerkte gegevens moeten worden opgeslagen (en de gecureerde gegevens, die in de volgende sectie worden behandeld). Uw beslissingen over gegevensopslag zijn gerelateerd aan uw voorkeuren voor het afhandelen van gegevensintegratie.

Wanneer u onbewerkte controlegegevens extraheert, houdt u deze eenvoudig. U wordt aangeraden geen specifieke kenmerken te selecteren, transformaties uit te voeren of opmaak toe te passen wanneer u de gegevens in eerste instantie extraheert. Pak in plaats daarvan alle beschikbare kenmerken uit en sla de gegevens in de oorspronkelijke staat op.

Hier volgen verschillende redenen waarom het opslaan van de onbewerkte gegevens in de oorspronkelijke staat een best practice is.

  • Alle gegevens die beschikbaar zijn in de geschiedenis: nieuwe kenmerken en nieuwe gebeurtenistypen zijn na verloop van tijd beschikbaar. Het opslaan van alle onbewerkte gegevens is een goede manier om ervoor te zorgen dat u altijd toegang hebt tot de gegevens die beschikbaar waren op het moment dat u deze hebt geëxtraheerd. Zelfs wanneer u tijd nodig hebt (weken of maanden) om te realiseren dat er nieuwe gegevenskenmerken beschikbaar zijn, is het mogelijk om ze historisch te analyseren omdat u ze hebt vastgelegd in de onbewerkte gegevens.
  • Tolerant om te wijzigen: als de onbewerkte gegevensindeling verandert, wordt het proces waarmee de gegevens worden geëxtraheerd, niet beïnvloed. Omdat sommige controlegegevens tijdgevoelig zijn, is het belangrijk om ervoor te zorgen dat u een proces voor gegevensextractie ontwerpt dat niet mislukt wanneer er een wijziging in de bron optreedt.
  • Rollen en verantwoordelijkheden: Verschillende teamleden (zoals gegevenstechnici of globale beheerders) zijn mogelijk verantwoordelijk voor het maken van de processen voor het openen, extraheren en opslaan van de onbewerkte controlegegevens. Door het proces voor gegevensextractie te vereenvoudigen, kunnen meerdere teams gemakkelijker samenwerken.

Hier volgen enkele opties voor het opslaan van onbewerkte gegevens.

  • Data lake of objectopslag: een cloudservice zoals OneLake die gespecialiseerd is in het opslaan van bestanden van elke structuur. Het is een ideale keuze voor het opslaan van de onbewerkte controlegegevens. In een data lake-architectuur moeten onbewerkte gegevens worden opgeslagen in de bronslaag.
  • Bestandssysteem: Een bestandssysteem (zoals Windows of Linux) is een veelgebruikte keuze voor het opslaan van onbewerkte controlegegevens.
  • Database: Het is mogelijk om JSON-gegevens op te slaan in een relationele database, zoals Azure SQL Database. Het is echter minder gebruikelijk dan het opslaan van de gegevens in een data lake of bestandssysteem. Dat komt doordat het opvragen en onderhouden van JSON-gegevens lastig en duur kan worden, met name naarmate de gegevensvolumes toenemen.

Tip

Wanneer u een data lake, objectopslag of een bestandssysteem gebruikt, raden we u aan de gegevens op een manier op te slaan die eenvoudig te ordenen en te beveiligen is. Het is ook belangrijk om duidelijk te zijn of de gegevens gebeurtenissen bevatten (die meestal worden toegevoegd) of dat het een momentopname van een bepaald tijdstip is (waarvoor een datum moet worden geselecteerd om te analyseren).

Bekijk een voorbeeld met een onbewerkte gegevenszone van een data lake. De zone heeft een maphiërarchie voor het opslaan van activiteitenlogboekgegevens: Raw > ActivityLog > JJJJ > MM. De mappen worden gepartitioneerd op jaar en maand. Een bestand dat is opgeslagen in de maandmap, gebruikt de volgende indeling: PBIActivityLog-YYYYMMDD-YYYYMMDDTTTT.json. JJJJMMDDD vertegenwoordigt de werkelijke gegevens en JJJJMMDDTTTT vertegenwoordigt het tijdstempel voor extractie. Door het tijdstempel voor extractie op te geven, kunt u bepalen welk bestand het meest recente is (voor het geval u de gegevens opnieuw moet extraheren). Als u bijvoorbeeld gegevens om 9:00 uur (UTC) op 25 april 2023 extraheert voor activiteit op 23 april 2023, is de bestandsnaam PBIActivityLog-20230523-202305250900.

We raden u ten zeerste aan een technologie te gebruiken waarmee u de onbewerkte gegevens kunt schrijven naar onveranderbare opslag. Onveranderbare opslag garandeert dat wanneer de gegevens zijn geschreven, deze niet kunnen worden overschreven of verwijderd. Dat onderscheid is belangrijk voor auditors en het stelt u in staat om te vertrouwen dat de onbewerkte gegevens betrouwbaar zijn.

U moet ook overwegen om de onbewerkte gegevens veilig op te slaan. Normaal gesproken hebben zeer weinig gebruikers toegang nodig tot de onbewerkte gegevens. Toegang tot onbewerkte gegevens wordt doorgaans geboden op basis van behoeften, meestal voor gegevenstechnici en systeembeheerders. Uw interne auditors hebben mogelijk ook toegang nodig. De teamleden die verantwoordelijk zijn voor het maken van de gecureerde gegevens (hierna beschreven), hebben ook toegang nodig tot de onbewerkte gegevens.

Hier volgen enkele overwegingen om u te helpen bij het kiezen van uw onbewerkte gegevensopslag.

  • Is het een handmatig of geautomatiseerd controleproces? Een geautomatiseerd controleproces heeft doorgaans strengere vereisten voor hoe en waar gegevens worden opgeslagen.
  • Is het onderwerp bijzonder gevoelig? Afhankelijk van het type gegevens en hoe gevoelig het is, heeft uw organisatie mogelijk een vereiste voor hoe en waar deze worden opgeslagen. Power BI-auditgegevens bevatten het identificeren van gebruikersgegevens en IP-adressen, dus deze moeten worden opgeslagen in een beveiligd gebied.
  • Is er een voorkeursopslagtechnologie? Er is mogelijk een bestaande opslagtechnologie die in gebruik is binnen de organisatie, dus het is een logische keuze.
  • Hebben gebruikers rechtstreeks toegang tot de opslag? Het beveiligingsmodel is een belangrijke overweging. Meestal krijgen zeer weinig gebruikers toegang tot onbewerkte gegevens. Toegang tot de gecureerde gegevens wordt doorgaans beschikbaar gesteld aan makers van Power BI-inhoud die verantwoordelijk zijn voor het maken van het gecentraliseerde gegevensmodel (het semantische model dat fungeert als de laag voor rapportage).
  • Hebt u vereisten voor gegevenslocatie? Sommige organisaties hebben wettelijke of wettelijke vereisten voor gegevenslocatie om gegevens op te slaan in een specifieke gegevensregio.
  • Hoe worden de gegevens ingedeeld? Het gebruik van de medalsight-architectuur is een gangbare praktijk, met name in data lake- en lakehouse-implementaties. Het doel is om uw gegevens op te slaan in brons-, zilver- en gouden gegevenslagen. De bronslaag bevat de oorspronkelijke onbewerkte gegevens. De zilveren laag bevat gevalideerde en ontdubbelde gegevens die worden gebruikt voor transformaties. De gouden laag bevat de gecureerde, zeer verfijnde gegevens die klaar zijn voor analyse.

Controlelijst : bij het plannen van de locatie voor het opslaan van onbewerkte gegevens zijn belangrijke beslissingen en acties:

  • Neem contact op met it: neem contact op met de relevante IT-team(s) om te bepalen of er bestaande processen worden uitgevoerd om de onbewerkte controlegegevens te extraheren. Zo ja, kijk dan of u toegang hebt tot de bestaande gegevens. Als een nieuw proces voor gegevensextracten vereist is, moet u bepalen of er voorkeuren of vereisten zijn voor waar de gegevens moeten worden opgeslagen.
  • Bepaal waar onbewerkte gegevens moeten worden opgeslagen: bepaal de beste opslaglocatie en -structuur voor het opslaan van de onbewerkte gegevens.
  • Vereisten voor gegevenslocatie bepalen: ontdek of er wettelijke of wettelijke vereisten zijn voor waar de gegevens kunnen worden opgeslagen.
  • Maak een mapstructuur en naamconventie: Bepaal welke naamconventie moet worden gebruikt voor onbewerkte gegevensbestanden, inclusief de mapstructuur. Neem deze gegevens op in uw technische documentatie.
  • Bedenk hoe beveiliging voor onbewerkte gegevens werkt: terwijl u de opslaglocatie voor onbewerkte gegevens ontwerpt, moet u overwegen wie toegang nodig heeft tot de gegevens en hoe toegang wordt verleend.

Plan om gecureerde gegevens te maken

Gecureerde gegevens ondersteunen analyse en zijn ontworpen om gebruiksvriendelijk te zijn. U moet enkele beslissingen nemen over hoe en waar gecureerde gegevens worden gemaakt. De technologie die u kiest om de gecureerde gegevens op te slaan, kan een van de technologieën zijn die in de vorige sectie worden vermeld.

Het doel van gecureerde gegevens is om de gegevens te transformeren in een meer beschrijvende indeling die is geoptimaliseerd voor analyse en rapportage. Het vormt de gegevensbron van een Power BI-gegevensmodel, zodat u een Power BI-gegevensmodel gebruikt om het gebruik van Power BI in uw organisatie te analyseren. Basisrichtlijnen voor gegevensmodellen zijn van toepassing: u moet een stervormig schemaontwerp gebruiken, dat is geoptimaliseerd voor prestaties en bruikbaarheid.

U kunt ervoor kiezen om gecureerde gegevens op verschillende manieren te maken. U moet bepalen hoe u gegevensintegratie moet uitvoeren en hoe ver upstream moet worden toegepast om de transformaties toe te passen waarmee de gegevens worden voorbereid voor het laden in een stervormig schema.

Data lake

U kunt transformaties toepassen en gecureerde gegevensbestanden maken in een data lake. U moet een gouden laag gebruiken voor gecureerde gegevens, zodat deze logisch gescheiden zijn van de onbewerkte gegevens die zijn opgeslagen in de bronslaag. Het scheiden van de gegevens in lagen vereenvoudigt ook het instellen van verschillende machtigingen voor gebruikerstoegang.

Gebruik een data lake om de gegevens te transformeren en te cureren wanneer:

  • U verwacht dat er meerdere Power BI-gegevensmodellen zijn die rapportage dienen (waardoor een tussenliggende zilveren laag wordt gemaakt).
  • U moet meerdere selfservice-inhoudsmakers ondersteunen die toegang nodig hebben tot controlegegevens op tenantniveau.
  • U beschikt over bestaande hulpprogramma's en processen die u wilt gebruiken om gegevens te transformeren en laden.
  • U wilt de gegevensvoorbereiding minimaliseren die moet worden uitgevoerd (en mogelijk gedupliceerd) in een of meer Power BI-gegevensmodellen.
Power BI-gegevensmodel

Mogelijk kunt u al het transformatiewerk in Power BI voltooien. Gebruik Power Query om de gegevens te openen en te transformeren van de onbewerkte status naar de gecureerde indeling.

Gebruik een Power BI-gegevensmodel wanneer:

  • U wilt de end-to-end-architectuur vereenvoudigen en het gegevensmodel rechtstreeks vanuit de onbewerkte gegevens laden. (Incrementeel vernieuwen kan helpen bij het verminderen van de vernieuwingsduur.)
  • Uw voorkeur is om alle transformatiewerkzaamheden uit te voeren tijdens het laden van het gegevensmodel.
  • U verwacht één gecentraliseerd gegevensmodel te hebben voor de controlegegevens op tenantniveau. Alle rapporten (of andere gegevensmodellen) kunnen het gecentraliseerde semantische Power BI-model als bron gebruiken.
  • U wilt alleen gebruikerstoegang verlenen tot het gecentraliseerde semantische Power BI-model (en niet tot een van de brongegevens).

Tip

Wanneer u de gecureerde gegevens maakt, stelt u deze zodanig in dat u het proces voor eerdere datumbereiken eenvoudig opnieuw kunt uitvoeren. Als u bijvoorbeeld ontdekt dat er drie maanden geleden een nieuw kenmerk in de auditlogboeken wordt weergegeven, wilt u het kunnen analyseren omdat het voor het eerst werd weergegeven. De mogelijkheid om de gecureerde gegevensgeschiedenis opnieuw te laden is een van de verschillende redenen waarom het belangrijk is om de onbewerkte gegevens in de oorspronkelijke staat op te slaan (zoals eerder in dit artikel wordt beschreven).

Zie Een gegevensmodel maken verderop in dit artikel voor meer informatie over de dimensietabellen en feitentabellen die u in uw stervormig schema kunt opnemen.

Controlelijst : bij het plannen van het maken van gecureerde gegevens zijn belangrijke beslissingen en acties:

  • Bepaal waar transformaties moeten worden uitgevoerd: Overweeg hoe ver het transformatiewerk moet worden uitgevoerd en waar dat past in uw plan voor de hele architectuur.
  • Bepaal welk hulpprogramma u wilt gebruiken om de gegevens te transformeren in een stervormig schema: controleer welke hulpprogramma's en services worden gebruikt voor het transformeren van de onbewerkte gegevens naar gecureerde gegevens.
  • Bepaal waar gecureerde gegevens moeten worden opgeslagen: Bepaal de beste keuze voor het opslaan van de onbewerkte gegevens die zijn getransformeerd in een stervormige schema-indeling. Bepaal of een tussenliggende zilveren laag nuttig is in de end-to-end-architectuur.
  • Maak een naamconventie: bepaal welke naamconventie moet worden gebruikt voor gecureerde gegevensbestanden en mappen (indien van toepassing). Neem de details op in uw technische documentatie.
  • Bedenk hoe beveiliging voor gecureerde gegevens werkt: Bedenk bij het ontwerpen van de gecureerde locatie voor gegevensopslag wie toegang nodig heeft tot de gegevens en hoe de beveiliging wordt toegewezen.

Beslissingen over gegevensbronnen

Op dit moment moet u duidelijk zijn over vereisten, gegevensbehoeften en machtigingen. Er zijn belangrijke technische beslissingen genomen. U moet nu enkele beslissingen nemen over de aanpak voor het verkrijgen van bepaalde typen gegevens.

Toegang tot gebruikersactiviteitsgegevens

De activiteitsgegevens van Power BI-gebruikers, ook wel het activiteitenlogboek of auditlogboek genoemd, bevatten een schat aan informatie om u te helpen begrijpen wat er gebeurt in uw Power BI-tenant. Zie gegevens van gebruikersactiviteiten eerder in dit artikel voor meer informatie over het identificeren van uw gegevensbehoeften.

Power BI integreert de logboeken met het geïntegreerde auditlogboek van Microsoft Purview (voorheen bekend als het geïntegreerde auditlogboek van Microsoft 365). Deze integratie is een voordeel omdat elke service in Microsoft 365 geen eigen unieke manier van logboekregistratie hoeft te implementeren. Standaard is deze functionaliteit ingeschakeld.

Belangrijk

Als u nog geen gebruikersactiviteitsgegevens extraheert, moet u dat een dringende prioriteit maken. De gegevens van de gebruikersactiviteit zijn beschikbaar voor de meest recente 30 of 90 dagen (afhankelijk van de bron). Zelfs als u nog niet klaar bent om diepgaande analyses uit te voeren, is het belangrijk om de gegevens zo snel mogelijk te extraheren en op te slaan. Op die manier is waardevolle geschiedenis beschikbaar om te analyseren.

U hebt verschillende opties om gebruikersactiviteitsgegevens op te halen.

Techniek Beschrijving Standaarddagen van de geschiedenis beschikbaar Goede keuze voor handmatige controleprocessen Goede keuze voor geautomatiseerde controleprocessen Goede keuze om waarschuwingen in te stellen Goede keuze om snel aan de slag te gaan
Handmatig (gebruikersinterface) Microsoft Purview-nalevingsportal 90 Microsoft Purview-nalevingsportal is een goede keuze voor handmatige controleprocessen. Microsoft Purview-nalevingsportal is een goede keuze om snel aan de slag te gaan.
Handmatig (gebruikersinterface) Defender voor cloud-apps 30 Defender voor Cloud Apps is een goede keuze voor handmatige controleprocessen. Defender voor Cloud Apps is een goede keuze om waarschuwingen in te stellen.
Via programmacode Power BI-activiteitenlogboek (API of PowerShell-cmdlet) 30 Power BI-activiteitenlogboek (API of PowerShell-cmdlet) is een goede keuze voor geautomatiseerde controleprocessen. Power BI-activiteitenlogboek (API of PowerShell-cmdlet) is een goede keuze om snel aan de slag te gaan.
Via programmacode Office 365 Management Activity-API 7 Office 365 Management Activity-API is een goede keuze voor geautomatiseerde controleprocessen.
Via programmacode Microsoft Sentinel (Azure Monitor) 30 Microsoft Sentinel (Azure Monitor) is een goede keuze voor geautomatiseerde controleprocessen. Microsoft Sentinel (Azure Monitor) is een goede keuze voor het instellen van waarschuwingen.

In de rest van deze sectie worden alle technieken in de tabel geïntroduceerd.

Microsoft Purview-nalevingsportal

Het zoekprogramma voor controles in de Microsoft Purview-nalevingsportal (voorheen bekend als het Microsoft 365-compliancecentrum) is een handige plek om activiteiten en waarschuwingen weer te geven. Voor dit hulpprogramma hoeft u geen script te maken om de gegevens te extraheren en te downloaden. U kunt een Power BI-workload kiezen om alle auditlogboekrecords gedurende een bepaalde periode weer te geven. U kunt de resultaten ook verfijnen door specifieke activiteiten en gebruikers te selecteren. Een manager vraagt u bijvoorbeeld om erachter te komen wie een werkruimte eerder die dag heeft verwijderd, zodat hij of zij snel contact kan opnemen met de persoon om de situatie te bespreken.

De meest recente 90 dagen geschiedenis zijn beschikbaar met Audit (Standard). Met Audit (Premium) kunt u met langetermijnretentie auditlogboeken (optioneel) langer bewaren. Aangezien langetermijnretentie alleen van toepassing is op gelicentieerde E5-gebruikers, worden controlerecords uitgesloten voor niet-E5-gebruikers en gastgebruikers. Daarom raden we u aan alleen te vertrouwen op de standaardgeschiedenis van 90 dagen om ervoor te zorgen dat alle activiteit wordt vastgelegd.

Er zijn licentievereisten voor toegang tot de auditlogboeken in de Microsoft Purview-nalevingsportal. Verhoogde Exchange Online-machtigingen zijn ook vereist om toegang te krijgen tot de auditlogboeken.

Tip

Power BI-beheerders hebben standaard geen toegang tot de geïntegreerde zoekopdracht in het auditlogboek in de Microsoft Purview-nalevingsportal. Omdat het gegevens bevat voor veel Microsoft 365-services, is het een rol met hoge bevoegdheden. In de meeste organisaties zijn deze machtigingen gereserveerd voor een klein aantal IT-beheerders. Er zijn andere opties beschikbaar voor Power BI-beheerders, die verderop in deze sectie worden beschreven.

De gebruikersinterface in de Microsoft Purview-nalevingsportal is handig voor handmatige controleprocessen en incidentele onderzoeken van gebruikersactiviteiten.

Defender voor cloud-apps

De portal in Defender voor Cloud Apps is een handige plek om activiteiten en waarschuwingen weer te geven zonder dat u een script hoeft te maken om de gegevens te extraheren en te downloaden. Hiermee kunt u ook gegevens bekijken uit het Power BI-activiteitenlogboek en aanmeldingen van gebruikers.

Defender voor Cloud Apps bevat een gebruikersinterface voor het weergeven en doorzoeken van activiteitenlogboeken voor verschillende cloudservices, waaronder Power BI. Er worden dezelfde logboekgebeurtenissen weergegeven die afkomstig zijn uit het geïntegreerde auditlogboek van Microsoft Purview en andere gebeurtenissen, zoals aanmeldingsactiviteiten van gebruikers van Microsoft Entra-id.

Net als de Microsoft Purview-nalevingsportal (beschreven in de vorige sectie), heeft Defender voor Cloud Apps een doorzoekbare gebruikersinterface. De filteropties verschillen echter. Naast de standaardgeschiedenis van 30 dagen kunt u Defender voor Cloud Apps gebruiken om maximaal zes maanden aan activiteitenlogboekgeschiedenis weer te geven (in stappen van zeven dagen).

Er zijn licentievereisten voor toegang tot Defender voor Cloud Apps. Er zijn ook afzonderlijke machtigingen vereist.

Tip

Power BI-beheerders zijn standaard niet gemachtigd voor toegang tot Defender voor Cloud Apps. Er is een Power BI-rol in Defender voor Cloud Apps. Het toevoegen van Power BI-beheerders aan deze rol is een goede manier om ze toegang te verlenen tot een beperkte set gegevens.

De gebruikersinterface in Defender voor Cloud Apps is handig voor handmatige controleprocessen en eenmalige onderzoeken van gebruikersactiviteiten.

Power BI-activiteitenlogboek

Het Power BI-activiteitenlogboek is afkomstig uit het geïntegreerde auditlogboek. Het bevat alleen gebruikersactiviteiten die betrekking hebben op de Power BI-service.

Tip

Voor organisaties die van plan zijn om gebruikersactiviteiten te extraheren, raden we aan dat ze beginnen met het Power BI-activiteitenlogboek. Het is de eenvoudigste bron om programmatisch toegang te krijgen.

U hebt twee opties voor toegang tot het Power BI-activiteitenlogboek.

Zie API's of PowerShell-cmdlets kiezen eerder in dit artikel voor meer informatie over welke optie u wilt gebruiken.

Tip

Zie Het Power BI-activiteitenlogboek openen voor voorbeelden van het openen van het Power BI-activiteitenlogboek met PowerShell.

Power BI-activiteitenlogboekgegevens zijn beschikbaar voor alle Power BI-beheerders, Power Platform-beheerders en globale beheerders. De gegevens kunnen worden geopend vanuit het geïntegreerde auditlogboek, dat beschikbaar is voor bepaalde Exchange Online-rollen. Zie Gebruikersactiviteiten bijhouden in Power BI voor meer informatie.

U wordt aangeraden het Power BI-activiteitenlogboek te gebruiken wanneer u alleen Power BI-auditlogboekrecords wilt ophalen.

Notitie

In de auditlogboekgegevens worden werkruimten aangeduid als mappen. In de REST API van Power BI worden werkruimten aangeduid als groepen.

Office 365 Management Activity-API

U kunt gegevens extraheren uit het geïntegreerde auditlogboek voor andere services, zoals SharePoint Online, Teams, Exchange Online, Dynamics 365 en Power BI. Wanneer u een controle- en bewakingsoplossing voor meerdere services wilt implementeren, raden we u aan de Office 365 Management Activity-API te gebruiken. Omdat deze API gegevens van veel services retourneert, wordt deze de Unified Auditing-API (of het geïntegreerde auditlogboek) genoemd. Het is een van de Office 365-beheer-API's.

Voordat u een nieuwe oplossing bouwt, raden we u aan contact op te leggen met uw IT-afdeling om te bepalen of bestaande Power BI-auditrecords beschikbaar zijn. Het is mogelijk dat een proces de gegevens al extraheert en opslaat. Het is ook mogelijk dat u toestemming krijgt voor toegang tot deze gegevens in plaats van een nieuwe oplossing te bouwen.

U kunt de gegevens op twee manieren openen.

Belangrijk

De Search-UnifiedAuditLog cmdlet schaalt niet goed en hiervoor moet u een lusstrategie implementeren om de limiet van 5000 rijen te overwinnen. Om deze redenen is het geschikt voor incidentele query's of voor kleine organisaties die te weinig activiteit ervaren. Als u alleen Power BI-gegevens nodig hebt, wordt u aangeraden in plaats daarvan de cmdlet Get-PowerBIActivityEvent te gebruiken.

Over het algemeen is het lastiger om aan de slag te gaan met de Office 365 Management Activity-API dan het Power BI-activiteitenlogboek te gebruiken (eerder beschreven). Dat komt doordat de API inhoudsblobs retourneert en elke inhoudsblob afzonderlijke controlerecords bevat. Voor grote organisaties kunnen er duizenden inhoudsblobs per dag zijn. Omdat klanten en toepassingen van derden deze API intensief gebruiken, implementeert Microsoft beperking om ervoor te zorgen dat hun gebruik van de service geen negatieve gevolgen heeft voor anderen (ook wel bekend als het probleem met lawaaierige buren ). Daarom kan het ophalen van grote hoeveelheden geschiedenis een uitdaging zijn in grotere organisaties. Zie dit artikel voor probleemoplossing voor meer informatie.

Als u deze API wilt gebruiken, moet u zich verifiëren met een service-principal die is gemachtigd om gegevens op te halen uit de Office 365 Management Activity-API.

Tip

Power BI-beheerders hebben standaard geen toegang tot de Office 365 Management Activity-API. Omdat deze gegevens bevat voor veel Microsoft 365-services, zijn de beheerders- of auditrollen met hoge bevoegdheden vereist. In de meeste organisaties zijn deze rollen gereserveerd voor een klein aantal IT-beheerders. Het Power BI-activiteitenlogboek is bedoeld voor gebruik door Power BI-beheerders.

Het programmatisch ophalen van de controlegegevens uit de Office 365 Management Activity-API is een goede keuze wanneer IT auditlogboeken uit verschillende services moet extraheren en opslaan (buiten Power BI).

Microsoft Sentinel

Microsoft Sentinel is een Azure-service waarmee u beveiligingsincidenten en bedreigingen kunt verzamelen, detecteren, onderzoeken en erop kunt reageren. U kunt Power BI in Microsoft Sentinel instellen als een gegevensconnector. Wanneer u verbinding hebt, worden auditlogboeken (die een subset met gegevens bevatten) vanuit Power BI gestreamd naar Azure Log Analytics. Dit is een mogelijkheid van Azure Monitor.

Tip

Azure Log Analytics is gebaseerd op dezelfde architectuur die wordt gebruikt door de gebeurtenislogboeken van het semantische model op werkruimteniveau. Zie Controle op gegevensniveau voor meer informatie over logboeken voor semantische modelgebeurtenissen.

Omdat het een afzonderlijke Azure-service is, moeten beheerders of gebruikers die u Kusto-querytaal (KQL)-query's wilt uitvoeren, machtigingen krijgen in Azure Log Analytics (Azure Monitor). Wanneer ze gemachtigd zijn, kunnen ze een query uitvoeren op de controlegegevens die zijn opgeslagen in de PowerBIActivity-tabel . Houd er echter rekening mee dat u in de meeste gevallen gebruikers toegang verleent tot de gecureerde gegevens in de gouden laag in plaats van de onbewerkte gegevens in de bronslaag.

U gebruikt KQL om de gebeurtenissen in het activiteitenlogboek te analyseren die zijn opgeslagen in Azure Log Analytics. Als u SQL-ervaring hebt, zult u veel overeenkomsten vinden met KQL.

Er zijn verschillende manieren om toegang te krijgen tot de gebeurtenissen die zijn opgeslagen in Azure Log Analytics. U kunt gebruikmaken van:

  • De vooraf gemaakte Log Analytics voor de sjabloon-app Semantische modellen van Power BI.
  • Power BI Desktop-connector voor Azure Data Explorer (Kusto).
  • Query-ervaring op basis van het web in Azure Data Explorer.
  • Elk queryprogramma dat KQL-query's kan verzenden.

Let op

Houd er rekening mee dat alleen een subset van de power BI-activiteitenlogboekgegevens wordt opgeslagen in Azure Monitor. Wanneer u van plan bent een uitgebreide analyse uit te voeren van power BI-gebruik en -acceptatie in de organisatie, raden we u aan andere opties te gebruiken (eerder in deze sectie beschreven) om activiteitsgegevens op te halen.

De periode van de geschiedenis die u kunt ophalen, is afhankelijk van het bewaarbeleid voor gegevens voor de Azure Log Analytics-werkruimte. Houd rekening met kosten en toegang tot onbewerkte gegevens bij het bepalen hoeveel gegevens moeten worden bewaard.

Microsoft Sentinel en Azure Monitor zijn goede opties wanneer IT al een investering heeft gedaan met Microsoft Sentinel, het vastgelegde detailniveau voldoet aan uw behoeften en activiteiten zoals detectie van bedreigingen zijn een prioriteit. Omdat Microsoft Sentinel echter niet alle Power BI-activiteitsgegevens vastlegt, biedt dit geen ondersteuning voor het uitvoeren van uitgebreide analyses van power BI-gebruik en -acceptatie.

Overwegingen voor gegevens over gebruikersactiviteit

Hier volgen enkele overwegingen om u te helpen uw bron te kiezen voor gebruikersactiviteitsgegevens.

  • Is het een handmatig of geautomatiseerd controleproces? De opties voor de gebruikersinterface werken goed voor handmatige controleprocessen en incidentele eenmalige query's, met name wanneer u een specifieke activiteit moet onderzoeken. Een geautomatiseerd controleproces waarmee de gebruikersactiviteitsgegevens volgens een schema worden geëxtraheerd, is ook nodig om historische gegevensanalyse te ondersteunen.
  • Hoe vaak hebt u de gebruikersactiviteitsgegevens nodig? Voor geautomatiseerde controleprocessen wilt u gegevens extraheren die ten minste één dag vóór de huidige datum vallen met behulp van Coordinated Universal Time (UTC), in plaats van uw lokale tijd. Als uw proces bijvoorbeeld wordt uitgevoerd op vrijdagochtend (UTC-tijd), moet u gegevens extraheren uit woensdag. Er zijn verschillende redenen waarom u gegevens met latentie van één dag moet extraheren.
    • Uw bestanden zijn eenvoudiger om mee te werken wanneer u altijd een volledige 24 uur tegelijk extraheert, waardoor gedeeltelijke dagresultaten worden vermeden.
    • U minimaliseert het risico dat bepaalde controlegebeurtenissen ontbreken. Controlegebeurtenissen komen meestal binnen 30 minuten binnen. Soms kan het tot 24 uur duren voordat sommige gebeurtenissen binnenkomen in het geïntegreerde auditlogboek.
  • Hebt u meer nodig dan Power BI-gegevens? Overweeg de meest efficiënte manier om toegang te krijgen tot wat u nodig hebt.
  • Wie gaat de oplossing ontwikkelen? Plan enige tijd te investeren om de oplossing uit te bouwen. Het kan veel moeite kosten om een script dat gereed is voor productie te produceren.

Controlelijst : bij het plannen van toegang tot gegevens van gebruikersactiviteiten, zijn belangrijke beslissingen en acties:

  • Bereik van behoeften verduidelijken: bepaal of u alleen toegang nodig hebt tot Power BI-auditrecords of controlegegevens voor meerdere services.
  • Neem contact op met IT: ontdek of IT momenteel auditlogboeken extraheert en of het mogelijk is om toegang te krijgen tot de onbewerkte gegevens, zodat u geen nieuwe oplossing hoeft te bouwen.
  • Beslis over een gegevensbron: bepaal de beste bron om toegang te krijgen tot gebruikersactiviteitsgegevens.
  • Een proof of concept voltooien: Plan een klein technisch bewijs van concept (POC) te voltooien. Gebruik deze om uw beslissingen te valideren over hoe de uiteindelijke oplossing wordt gebouwd.
  • Aanvullende gegevensbehoeften bijhouden: u kunt activiteitenlogboekgegevens correleren met andere bronnen om de waarde van de gegevens te verbeteren. Houd deze kansen bij terwijl ze zich voordoen, zodat ze kunnen worden toegevoegd aan het bereik van uw project.

Toegang tot tenantinventarisgegevens

Een tenantinventaris is een waardevol en noodzakelijk onderdeel van een volwassen controle- en bewakingsoplossing. Het helpt u te begrijpen welke werkruimten en inhoud (semantische modellen, rapporten en andere items) in Power BI bestaan en het is een uitstekende aanvulling op de gebruikersactiviteitsgegevens (beschreven in de vorige sectie). Zie Tenantinventaris eerder in dit artikel voor meer informatie over het identificeren van uw gegevensbehoeften.

Gebruikersactiviteiten (eerder beschreven) zijn gecontroleerde gebeurtenissen; ze zijn een record van acties die een gebruiker heeft uitgevoerd op een specifieke datum en tijd. De tenantinventaris is echter anders. De tenantinventaris is een momentopname op een bepaald tijdstip. Hierin wordt de huidige status van alle gepubliceerde items in de Power BI-service beschreven op het moment dat u deze hebt geëxtraheerd.

Notitie

Power BI REST API-documentatie verwijst naar gepubliceerde items als artefacten.

Tip

Veel organisaties vinden het handig om de tenantinventaris elke week op hetzelfde tijdstip van de dag te extraheren.

Als u goed wilt analyseren wat er gebeurt in uw Power BI-tenant, hebt u zowel de gebruikersactiviteitsgegevens als de tenantinventaris nodig. Door ze te combineren, kunt u begrijpen hoeveel inhoud u hebt en waar deze zich bevindt. Hiermee kunt u ook ongebruikte of onderbenutte inhoud vinden (omdat er geen gebeurtenissen voor zijn in het activiteitenlogboek). De tenantinventaris helpt u ook bij het compileren van een lijst met huidige namen voor alle items, wat handig is wanneer itemnamen worden gewijzigd.

Zie Tenantinventaris eerder in dit artikel voor meer informatie over de waarde van de tenantinventaris.

Tip

U kunt ongebruikte artefacten ophalen als Beheer API gebruiken om te zoeken naar items die de afgelopen 30 dagen geen gebruikersactiviteit hebben. U kunt die periode echter niet aanpassen. U kunt bijvoorbeeld kritieke inhoud hebben die alleen elk kwartaal wordt gebruikt. Door uw tenantinventaris te combineren met de gebruikersactiviteitsgegevens, kunt u ongebruikte items vinden op manieren die u kunt aanpassen.

U kunt tenantinventarisgegevens op twee verschillende manieren verkrijgen.

Techniek Beschrijving Meest geschikt voor Goede keuze voor handmatige controleprocessen Goede keuze voor geautomatiseerde controleprocessen
Via programmacode De Get Groups as Admin API of de Get-PowerBIWorkspace PowerShell-cmdlet kan een lijst met werkruimten voor de hele tenant bieden. Optioneel kunnen afzonderlijke items (zoals semantische modellen en rapporten) per werkruimte worden opgenomen. Kleinere organisaties of een laag gegevensvolume De Get Groups als Beheer API of de Get-PowerBIWorkspace PowerShell-cmdlet is een goede keuze voor handmatige controleprocessen. De Get Groups als Beheer API of de Get-PowerBIWorkspace PowerShell-cmdlet is een goede keuze voor geautomatiseerde controleprocessen.
Via programmacode Een set asynchrone beheerders-API's, gezamenlijk bekend als de API's voor het scannen van metagegevens of scanner-API's, kan een lijst met werkruimten en afzonderlijke items retourneren. Optioneel kunnen ook gedetailleerde metagegevens (zoals tabellen, kolommen en metingexpressies) worden opgenomen. Organisaties met een hoog gegevensvolume en/of een behoefte aan gedetailleerde resultaten De API's voor het scannen van metagegevens zijn een goede keuze voor geautomatiseerde controleprocessen.

In de rest van deze sectie worden alle technieken in de tabel geïntroduceerd.

Cmdlet voor groepen-API's of werkruimten

Als u een lijst met werkruimten wilt ophalen, kunt u een van de verschillende REST API's gebruiken, zoals de Get Groups als Beheer API (met behulp van het hulpprogramma van uw keuze). De resultaten bevatten extra metagegevens, zoals de beschrijving en of de werkruimte is opgeslagen in een Premium-capaciteit.

Notitie

De API met de naam bevat de termengroep als verwijzing naar een werkruimte. Deze term is afkomstig van het oorspronkelijke Power BI-beveiligingsmodel, dat is gebaseerd op Microsoft 365-groepen. Hoewel het Power BI-beveiligingsmodel in de loop der jaren aanzienlijk is ontwikkeld, blijven de bestaande API-namen ongewijzigd om te voorkomen dat bestaande oplossingen worden onderbroken.

De Get Groups as Admin REST API bevat de nuttige $expand parameter. Met deze parameter kunt u desgewenst de resultaten uitbreiden, zodat ze een lijst met items bevatten die zijn gepubliceerd naar de werkruimte (zoals semantische modellen en rapporten). U kunt het users gegevenstype ook doorgeven aan de $expand parameter om de gebruikers op te nemen die zijn toegewezen aan een werkruimterol.

U kunt ook de Cmdlet Get-PowerBIWorkspace PowerShell gebruiken. Dit is afkomstig uit de module Power BI-beheerwerkruimten. Wanneer u de -Scope parameter organizationinstelt, werkt deze als de Get Groups as Admin API. De cmdlet accepteert ook de -Include parameter (het equivalent van de parameter in de $expand REST API) om items op te nemen die zijn gepubliceerd in de werkruimte (zoals semantische modellen en rapporten).

Tip

Door parameters door te geven, kunt u de cmdlet op verschillende manieren gebruiken. Deze sectie is gericht op het ophalen van een tenantbrede inventaris. Zie Een gebruikers-API of beheer-API eerder in dit artikel kiezen voor meer informatie over het gebruik van de -Scope parameter.

Zie API's of PowerShell-cmdlets eerder in dit artikel kiezen om te kiezen welke optie u wilt gebruiken.

De Get Groups as Admin REST API of de Get-PowerBIWorkspace PowerShell-cmdlet is het meest geschikt voor handmatige controleprocessen en eenmalige onderzoeken. Grotere organisaties met een hoog gegevensvolume vinden deze opties doorgaans lastig om te gebruiken. De REST API en cmdlet extraheren altijd een volledige set gegevens, zodat het lang kan duren voordat ze worden uitgevoerd. Het is dus ook waarschijnlijk dat grotere organisaties te maken krijgen met beperkingen voor het aantal aanvragen dat per uur is toegestaan (ook wel beperking genoemd, wat wordt gedaan om de status van de service te beschermen). De API's voor het scannen van metagegevens (hierna beschreven) bieden een betrouwbaarder en schaalbaar alternatief.

API's voor scannen van metagegevens

De API's voor het scannen van metagegevens, ook wel de scanner-API's genoemd, zijn een set API's die een lijst met werkruimten en hun Power BI-items retourneren (semantische modellen, rapporten en andere items). Conceptueel bieden ze dezelfde gegevens (en meer) als de groeps-API's of de werkruimte-cmdlet, die in de vorige sectie worden beschreven. De methode die u gebruikt om de gegevens op te halen, is echter anders en is beter geschikt voor het extraheren van de tenantinventaris.

Notitie

Let op hoe sommige mensen de term scanner-API's gebruiken of de woordgroep die de tenant scant. Ze gebruiken deze termen vaak om te betekenen dat een tenantinventaris wordt verzameld, waardoor deze wordt onderscheiden van de gebeurtenissen van de gebruikersactiviteit. Ze verwijzen mogelijk of niet letterlijk naar het gebruik van de API's voor het scannen van metagegevens.

Er zijn twee primaire redenen waarom u moet overwegen om de API's voor het scannen van metagegevens te gebruiken in plaats van de Get Groups as Admin REST API of de Get-PowerBIWorkspace cmdlet (eerder beschreven).

  • Incrementeel gegevensextract: De scanner-API's extraheren alleen gegevens die zijn gewijzigd sinds de laatste keer dat deze werd uitgevoerd. Omgekeerd zijn de Get Groups as Admin REST API en de Get-PowerBIWorkspace cmdlet synchrone bewerkingen waarmee elke keer dat ze worden uitgevoerd, de volledige set gegevens worden geëxtraheerd.
  • Gedetailleerder detailniveau: de scanner-API's kunnen gedetailleerde details ophalen (zoals tabellen, kolommen en metingexpressies), waarbij machtigingen worden verleend door de twee tenantinstellingen voor gedetailleerde metagegevens. Het laagste detailniveau dat beschikbaar is met de Get Groups as Admin REST API en de Get-PowerBIWorkspace cmdlet is daarentegen op itemtype (bijvoorbeeld een lijst met rapporten in een werkruimte).

Het gebruik van de scanner-API's vergt meer inspanning omdat u een reeks API's moet aanroepen. Ze worden ook uitgevoerd als een asynchroon proces. Een asynchroon proces wordt op de achtergrond uitgevoerd en u hoeft dus niet te wachten totdat het is voltooid. Mogelijk moet u samenwerken met IT of een ontwikkelaar wanneer het tijd is om een script te maken dat gereed is voor productie die wordt gepland.

Hier volgt de volgorde van de stappen die uw proces moet volgen bij het gebruik van de scanner-API's.

  1. Aanmelden: meld u aan bij de Power BI-service met behulp van een Power BI-beheerdersaccount of een service-principal die gemachtigd is om beheerders-API's uit te voeren. Zie De verificatiemethode eerder in dit artikel bepalen voor meer informatie.
  2. Haal de werkruimte-id's op: verzend een aanvraag om een lijst met werkruimte-id's op te halen. De eerste keer dat deze wordt uitgevoerd, hebt u geen gewijzigde datum, zodat er een volledige lijst met werkruimten wordt geretourneerd. Normaal gesproken geeft u de gewijzigde datum door om alleen werkruimten op te halen die sinds dat tijdstip zijn gewijzigd. De gewijzigde datum moet binnen de afgelopen 30 dagen vallen.
  3. Start een scan voor metagegevens: initieer een aanroep om een scan van werkruimtegegevens aan te vragen door de werkruimte-id's door te geven die zijn opgehaald in stap 2. Houd er rekening mee dat dit een POST-API is (in plaats van een GET-API , wat gebruikelijker is bij het ophalen van controlegegevens). Een POST-API is een HTTP-aanvraag waarmee gegevens voor een opgegeven resource worden gemaakt of geschreven. Deze query geeft het detailniveau op dat wordt geëxtraheerd, zoals gegevensbrondetails, semantisch modelschema, semantische modelexpressies of gebruikers. Wanneer deze wordt verzonden, wordt een id voor de scan geretourneerd door de API. Het retourneert ook de datum en tijd van de scan, die u moet opnemen als de datum van de momentopname.
  4. Controleer de scanstatus: gebruik de scan-id die u in stap 3 hebt verkregen om de scanstatus op te halen. Mogelijk moet u deze API meerdere keren aanroepen. Wanneer de geretourneerde status Geslaagd is, kunt u doorgaan met de volgende stap. De tijd die nodig is om te scannen, is afhankelijk van de hoeveelheid gegevens die u aanvraagt.
  5. Haal de resultaten op: gebruik de scan-id die u hebt verkregen in stap 3 om het scanresultaat op te halen en de gegevens te extraheren. U moet deze stap binnen 24 uur na het voltooien van stap 4 uitvoeren. Houd er rekening mee dat het tijdstempel van de momentopname moet worden gecorreleerd met stap 3 in plaats van stap 5 (wanneer er een aanzienlijke vertraging is). Op die manier hebt u een nauwkeurige tijdstempel voor momentopnamen. Sla de resultaten op de opslaglocatie van uw voorkeur op. Zoals al beschreven in dit artikel, raden we u aan de onbewerkte gegevens in de oorspronkelijke staat op te slaan.
  6. Bereid u voor op het volgende proces: Noteer het tijdstempel van de scan uit stap 3, zodat u deze in stap 2 kunt gebruiken wanneer u het proces de volgende keer uitvoert. Op die manier extraheert u alleen gegevens die zijn gewijzigd sinds dat tijdstip. In de toekomst zijn alle volgende gegevensextracties incrementele wijzigingen in plaats van volledige momentopnamen.

Controlelijst : bij het plannen van toegang tot de tenantinventarisgegevens zijn belangrijke beslissingen en acties:

  • Bevestig de vereisten: Maak duidelijk wat de behoeften zijn voor het compileren van een tenantinventaris en de analytische vereisten voor de gegevens.
  • Bepaal de frequentie voor het extraheren van tenantinventaris: Controleer hoe vaak u een nieuwe tenantinventaris nodig hebt (zoals elke week).
  • Bepaal hoe u de tenantinventaris extraheert: controleer welke methode u gebruikt om de tenantinventarisgegevens (API, cmdlet of metagegevensscan-API's) te verkrijgen.
  • Een proof of concept voltooien: Plan een klein technisch bewijs van concept (POC) te voltooien. Gebruik deze om uw beslissingen te valideren over hoe de uiteindelijke oplossing wordt gebouwd.

Toegang tot gebruikers- en groepsgegevens

Naast de identificatiegegevens (zoals een e-mailadres) die zijn opgenomen in de gegevens van de gebruikersactiviteit, is het waardevol om aanvullende informatie op te halen, zoals locatie- of organisatiegegevens. U kunt Microsoft Graph gebruiken om gegevens op te halen over gebruikers, groepen, service-principals en licenties. Microsoft Graph bestaat uit een set API's en clientbibliotheken waarmee u controlegegevens kunt ophalen uit een groot aantal services.

Hier volgen enkele details over de Microsoft Entra-objecten waartoe u toegang hebt.

  • Gebruiker: Een identiteit die in Microsoft Entra-id bestaat als werk-, school- of Microsoft-account. De term domeingebruiker wordt vaak gebruikt om organisatiegebruikers te beschrijven, terwijl de formele term user principal name (UPN) is. Een UPN is meestal dezelfde waarde als het e-mailadres van de gebruiker (maar als een e-mailadres wordt gewijzigd, verandert de UPN niet omdat deze onveranderbaar is). Er is ook een unieke Microsoft Graph-id voor elke gebruiker. Vaak is een gebruikersaccount gekoppeld aan één persoon. Sommige organisaties maken gebruikers die serviceaccounts zijn die worden gebruikt voor geautomatiseerde activiteiten of voor beheertaken.
  • Service-principal: Een ander type identiteit, dat wordt ingericht wanneer u een app-registratie maakt. Een service-principal is bedoeld voor onbeheerde, geautomatiseerde activiteiten. Zie De verificatiemethode eerder in dit artikel bepalen voor meer informatie.
  • Groep: Een verzameling gebruikers en service-principals. Er zijn verschillende soorten groepen die u kunt gebruiken om het beheer van machtigingen te vereenvoudigen. Zie Strategie voor het gebruik van groepen voor meer informatie.

Notitie

Wanneer dit artikel verwijst naar gebruikers en groepen, bevat deze term ook service-principals. Deze kortere termijn wordt gebruikt voor beknoptheid.

De gebruikers en groepsgegevens die u ophaalt, zijn een momentopname die de huidige status op een bepaald tijdstip beschrijft.

Tip

Zie Integratie met Microsoft Entra-id voor meer informatie over gebruikers, service-principals en groepen.

Analytische kenmerken

Voor controle op Tenantniveau van Power BI kunt u de volgende kenmerken uit Microsoft Graph extraheren en opslaan.

  • Volledige naam van gebruikers: veel gegevensbronnen bevatten alleen het e-mailadres van de gebruiker die een activiteit heeft uitgevoerd of die is toegewezen aan een rol. Gebruik dit kenmerk als u de volledige naam (weergavenaam) wilt weergeven in analytische rapporten. Als u de volledige naam gebruikt, worden rapporten gebruiksvriendelijker.
  • Andere gebruikerseigenschappen: Andere beschrijvende kenmerken over gebruikers zijn mogelijk beschikbaar in Microsoft Entra-id. Enkele voorbeelden van ingebouwde kenmerken van gebruikersprofielen met analytische waarde zijn functie, afdeling, manager, regio en kantoorlocatie.
  • Leden van een beveiligingsgroep: De meeste gegevensbronnen geven de naam van een groep op (bijvoorbeeld het Power BI-activiteitenlogboek registreert dat een beveiligingsgroep is toegewezen aan een werkruimterol). Door het groepslidmaatschap op te halen, kunt u beter volledig analyseren wat een afzonderlijke gebruiker doet of waartoe hij toegang heeft.
  • Gebruikerslicenties: het is handig om te analyseren welke gebruikerslicenties , gratis, Power BI Pro of Power BI Premium Per Gebruiker (PPU)) aan gebruikers worden toegewezen. Met deze gegevens kunt u bepalen wie geen licentie gebruikt. Het helpt u ook bij het analyseren van alle gebruikers (afzonderlijke gebruikers met een licentie) versus actieve gebruikers (met recente activiteiten). Als u overweegt om uw Power BI Premium-licenties toe te voegen of uit te breiden, raden we u aan om de gebruikerslicentiegegevens samen met gebruikersactiviteitsgegevens te analyseren om een kostenanalyse uit te voeren.
  • Leden van de beheerdersrollen: u kunt een lijst met uw Power BI-beheerders compileren (waaronder Power Platform-beheerders en globale beheerders).

Zie productnamen en serviceplan-id's voor licenties voor de gezaghebbende naslaginformatie over Power BI-licentie die u kunt vinden in de auditgegevens van Microsoft Graph.

Tip

Het ophalen van leden uit groepen kan een van de meest uitdagende aspecten zijn van het verkrijgen van controlegegevens. U moet een transitieve zoekopdracht uitvoeren om alle geneste leden en geneste groepen plat te maken. U kunt een transitieve zoekopdracht uitvoeren naar groepsleden. Dit type zoekopdracht is vooral lastig wanneer er duizenden groepen in uw organisatie zijn. In dat geval kunnen er betere alternatieven worden overwogen om de gegevens op te halen. Een optie is om alle groepen en groepsleden uit Microsoft Graph te extraheren. Dit kan echter niet praktisch zijn wanneer slechts een klein aantal groepen wordt gebruikt voor Power BI-beveiliging. Een andere optie is om vooraf een referentielijst te maken met groepen die worden gebruikt door elk type Power BI-beveiliging (werkruimterollen, app-machtigingen, delen per item, beveiliging op rijniveau en andere). Vervolgens kunt u de naslaglijst doorlopen om groepsleden op te halen uit Microsoft Graph.

Hier volgen enkele andere kenmerken die u kunt extraheren en opslaan.

  • Gebruikerstype: Gebruikers zijn leden of gasten. Meestal zijn leden interne gebruikers en zijn gasten externe gebruikers (B2B). Het opslaan van gebruikerstype is handig wanneer u de activiteiten van externe gebruikers moet analyseren.
  • Rolwijzigingen: Wanneer u een beveiligingscontrole uitvoert, is het handig om te begrijpen wanneer een gebruiker rollen in de organisatie heeft gewijzigd (bijvoorbeeld wanneer deze worden overgedragen naar een andere afdeling). Op die manier kunt u controleren of hun Power BI-beveiligingsinstellingen zijn bijgewerkt of moeten worden bijgewerkt.
  • Uitgeschakelde gebruikers: wanneer een gebruiker de organisatie verlaat, schakelt een beheerder meestal zijn of haar account uit. U kunt een proces maken om te controleren of uitgeschakelde gebruikers werkruimtebeheerders of semantische modeleigenaren zijn.

Tip

Het Power BI-activiteitenlogboek bevat een gebeurtenis die wordt geregistreerd wanneer een gebruiker zich registreert voor een proeflicentie. U kunt deze gebeurtenis combineren met de gebruikerslicentiegegevens (afkomstig van Microsoft Entra ID) om een volledig beeld te produceren.

Gebruikers en groepsgegevens ophalen

U kunt gegevens over gebruikers en groepen op verschillende manieren ophalen.

Techniek Beschrijving Goede keuze voor handmatige controleprocessen Goede keuze voor geautomatiseerde controleprocessen
Handmatig Grafiekverkenner Graph Explorer is een goede keuze voor handmatige controleprocessen.
Via programmacode Microsoft Graph-API's en SDK's Microsoft Graph API's en SDK's zijn goede keuzes voor geautomatiseerde controleprocessen.
Via programmacode Az-module PowerShell Az PowerShell-module is een goede keuze voor geautomatiseerde controleprocessen.

In de rest van deze sectie worden alle technieken in de tabel geïntroduceerd. Andere technieken, die zijn afgeschaft en niet mogen worden gebruikt voor nieuwe oplossingen, worden aan het einde van deze sectie beschreven.

Notitie

Wees voorzichtig wanneer u informatie online leest omdat veel namen van hulpprogramma's vergelijkbaar zijn. Sommige hulpprogramma's in het Microsoft-ecosysteem bevatten de term Graph in hun naam, zoals Azure Resource Graph, GraphQL en de Microsoft Security Graph API. Deze hulpprogramma's zijn niet gerelateerd aan Microsoft Graph en ze vallen buiten het bereik van dit artikel.

Microsoft Graph Explorer

Microsoft Graph Explorer is een hulpprogramma voor ontwikkelaars waarmee u meer informatie kunt krijgen over Microsoft Graph-API's. Het is een eenvoudige manier om aan de slag te gaan, omdat hiervoor geen andere hulpprogramma's of installatie op uw computer nodig zijn. U kunt zich aanmelden om gegevens op te halen uit uw tenant of voorbeeldgegevens ophalen uit een standaardtenant.

U kunt Graph Explorer gebruiken om het volgende te doen:

  • Verzend handmatig een aanvraag naar een Microsoft Graph API om te controleren of deze de gewenste informatie retourneert.
  • Lees hoe u de URL, headers en hoofdtekst maakt voordat u een script schrijft.
  • Controleer gegevens op een informele manier.
  • Bepaal welke machtigingen vereist zijn voor elke API. U kunt ook toestemming geven voor nieuwe machtigingen.
  • Haal codefragmenten op die moeten worden gebruikt wanneer u scripts maakt.

Gebruik deze koppeling om Graph Explorer te openen.

Microsoft Graph-API's en SDK's

Gebruik de Microsoft Graph-API's om gebruikers en groepsgegevens op te halen. U kunt deze ook gebruiken om gegevens op te halen uit services zoals Microsoft Entra ID, SharePoint Online, Teams, Exchange, Outlook en meer.

De Microsoft Graph SDK's fungeren als api-wrapper boven op de onderliggende Microsoft Graph-API's. Een SDK is een software development kit die hulpprogramma's en functionaliteit samen bundelt. De Microsoft Graph SDK's maken de volledige set Microsoft Graph-API's beschikbaar.

U kunt ervoor kiezen om aanvragen rechtstreeks naar de API's te verzenden. U kunt ook een vereenvoudigingslaag toevoegen met behulp van uw voorkeurstaal en een van de SDK's. Zie Api's of PowerShell-cmdlets kiezen eerder in dit artikel voor meer informatie.

De Microsoft Graph SDK's ondersteunen verschillende talen en er zijn ook de Microsoft Graph PowerShell-modules . Andere SDK's zijn beschikbaar voor Python, C# en andere talen.

Belangrijk

De Microsoft Graph PowerShell-module vervangt de Azure AD PowerShell-modules en MSOnline-modules (MSOL), die beide zijn afgeschaft. U moet geen nieuwe oplossingen maken met afgeschafte modules. De Microsoft Graph PowerShell-module heeft veel functies en voordelen. Zie Upgrade van Azure AD PowerShell naar Microsoft Graph PowerShell voor meer informatie.

U kunt de Microsoft Graph PowerShell-modules installeren vanuit de PowerShell Gallery. Omdat Microsoft Graph werkt met veel Microsoft 365-services, zijn er veel PowerShell-modules die u installeert.

Voor controle op Tenantniveau van Power BI zijn dit de meest voorkomende PowerShell-modules die u moet installeren.

Tip

Microsoft werkt de Microsoft Graph PowerShell-modules regelmatig bij. Soms worden preview-modules beschikbaar gesteld op basis van een voorlopige release of een bèta-eindpunt. U kunt de versie opgeven waarin u geïnteresseerd bent wanneer u de modules installeert en bijwerkt. Wanneer u onlinedocumentatie bekijkt, moet u er ook rekening mee houden dat het huidige versienummer automatisch wordt toegevoegd aan het einde van de URL (dus wees voorzichtig bij het opslaan of delen van URL's).

Az-module PowerShell

U kunt ook de Az PowerShell-module gebruiken om gebruikers en groepsgegevens op te halen. Het richt zich op Azure-resources.

Belangrijk

De Az PowerShell-module vervangt de AzureRM PowerShell-modules, die zijn afgeschaft. U moet geen nieuwe oplossingen maken met afgeschafte modules.

U kunt de cmdlet Invoke-AzRestMethod gebruiken wanneer er geen bijbehorende cmdlet voor een API is. Het is een flexibele benadering waarmee u een aanvraag naar een Microsoft Graph API kunt verzenden met behulp van de Az PowerShell-module.

Vanaf Az versie 7 verwijzen de Az-cmdlets nu naar de Microsoft Graph API. Daarom fungeert de Az-module als api-wrapper boven op Microsoft Graph. De Az-modules hebben een subset van functionaliteit die is opgenomen in de Microsoft Graph-API's en PowerShell-modules. Voor nieuwe oplossingen raden we u aan de Microsoft Graph PowerShell SDK te gebruiken.

Afgeschafte API's en modules

Mogelijk vindt u online artikelen en blogberichten die alternatieve opties voorstellen die niet in deze sectie worden weergegeven. We raden u ten zeerste aan geen nieuwe oplossingen te maken (en/of uw bestaande oplossingen te migreren) met behulp van een van de volgende API's of modules.

  • AzureRM PowerShell-modules: afgeschaft en buiten gebruik gesteld. Ze zijn vervangen door de Az PowerShell-module.
  • Azure AD Graph API en Azure AD PowerShell-module: afgeschaft en buiten gebruik gesteld. Deze wijziging is het resultaat van de migratie van Azure AD Graph naar Microsoft Graph (houd er rekening mee dat Graph in beide namen wordt weergegeven, maar Microsoft Graph is de toekomstige richting). Alle toekomstige PowerShell-investeringen worden gedaan in de Microsoft Graph PowerShell SDK. (Microsoft Entra-id staat nu bekend als Microsoft Entra-id.)
  • MS Online (MSOL) PowerShell-module: afgeschaft en wordt buiten gebruik gesteld. Alle toekomstige PowerShell-investeringen worden gedaan in de Microsoft Graph PowerShell SDK.

Let op

Controleer de status van een afgeschafte API of module die u momenteel gebruikt. Zie deze aankondiging voor meer informatie over de buitengebruikstelling van AzureRM.

Zie dit aankondigingsbericht over buitengebruikstelling voor meer informatie over Microsoft Entra ID en MSOL.

Neem contact op met uw Microsoft-accountteam als u vragen hebt of uitleg nodig hebt over de toekomstige richting van toegang tot programmatische gegevens.

Controlelijst : wanneer u van plan bent om toegang te krijgen tot gegevens van gebruikers en groepen, zijn belangrijke beslissingen en acties:

  • Vereisten bevestigen: maak duidelijk wat de behoeften zijn voor het compileren van gegevens met betrekking tot gebruikers, groepen en licenties.
  • Vereisten prioriteren: controleer wat de belangrijkste prioriteiten zijn, zodat u weet waar u eerst tijd aan moet besteden.
  • Bepaal de frequentie voor het extraheren van gegevens: Bepaal hoe vaak u een nieuwe momentopname nodig hebt van de gebruikers en groepsgegevens (zoals elke week of elke maand).
  • Bepaal hoe u gegevens extraheert met Microsoft Graph: bepaal welke methode u gebruikt om de gegevens op te halen.
  • Een proof of concept voltooien: Plan een klein technisch proof of concept (POC) te voltooien om gebruikers en groepsgegevens te extraheren. Gebruik deze om uw beslissingen te valideren over hoe de uiteindelijke oplossing wordt gebouwd.

Toegang tot gegevens vanuit Power BI REST API's

Misschien kunt u als lagere prioriteit ook andere gegevens ophalen met behulp van de Power BI REST API's.

U kunt bijvoorbeeld gegevens ophalen over:

Tijdens een beveiligingscontrole kunt u het volgende identificeren:

  • Items die breed zijn gedeeld met de hele organisatie.
  • Items die beschikbaar zijn op het openbare internet met behulp van publiceren op internet.

Zie Een gebruikers-API of beheerders-API kiezen eerder in dit artikel voor meer informatie over de andere typen API's.

Controlelijst: bij het plannen van toegang tot gegevens uit de API van Power BI s zijn belangrijke beslissingen en acties:

  • Vereisten verkrijgen: Analytische vereisten compileren wanneer deze zich voordoen. Houd ze bij in uw achterstand.
  • Vereisten prioriteren: stel prioriteiten in voor de nieuwe vereisten die zich voordoen.

Fase 2: Vereisten en installatie

De tweede fase van het plannen en implementeren van een controleoplossing op tenantniveau is gericht op vereisten en installatie die moeten worden uitgevoerd voordat u begint met het ontwikkelen van de oplossing.

Stroomdiagram met een beschrijving van fase 2, die is gericht op vereisten en installatie voor het bouwen van een controleoplossing op tenantniveau.

Een opslagaccount maken

Op dit moment hebt u besloten om onbewerkte gegevens op te slaan en hoe u gecureerde gegevens maakt. Op basis van deze beslissingen kunt u nu een opslagaccount maken. Afhankelijk van de processen van uw organisatie kan het nodig zijn om een aanvraag in te dienen bij IT.

Zoals eerder beschreven, raden we u aan een technologie te gebruiken waarmee u de onbewerkte gegevens kunt schrijven naar onveranderbare opslag. Zodra de gegevens zijn geschreven, kunnen deze niet meer worden gewijzigd of verwijderd. U kunt dan vertrouwen hebben in de onbewerkte gegevens omdat u weet dat een beheerder met toegang deze op geen enkele manier kan wijzigen. De gecureerde gegevens hoeven echter niet (meestal) te worden opgeslagen in onveranderbare opslag. Gecureerde gegevens kunnen veranderen of opnieuw worden gegenereerd.

Controlelijst : bij het maken van een opslagaccount zijn belangrijke beslissingen en acties:

  • Een opslagaccount maken: maak of dien een aanvraag in voor het maken van een opslagaccount. Gebruik indien mogelijk onveranderbare opslaginstellingen voor de onbewerkte gegevens.
  • Machtigingen instellen: bepaal welke machtigingen moeten worden ingesteld voor het opslagaccount.
  • Testtoegang: Voer een kleine test uit om ervoor te zorgen dat u het opslagaccount kunt lezen en schrijven.
  • Bevestig de verantwoordelijkheden: zorg ervoor dat u weet wie het opslagaccount doorlopend beheert.

Software installeren en services instellen

Op dit moment hebt u uw beslissingen genomen over welke technologie moet worden gebruikt voor toegangscontrolegegevens. Op basis van deze beslissingen bent u nu klaar om software te installeren en services in te stellen.

Stel de voorkeursontwikkelingsomgeving in voor elke beheerder. Met de ontwikkelomgeving kunnen ze scripts schrijven en testen. Visual Studio Code is een modern hulpprogramma voor het ontwikkelen van scripts, dus het is een goede optie. Er zijn ook veel extensies beschikbaar om te werken met Visual Studio Code.

Als u de beslissing (eerder beschreven) hebt genomen om PowerShell te gebruiken, moet u PowerShell Core en de benodigde PowerShell-modules installeren op:

  • De computer van elke beheerder/ontwikkelaar die scripts voor controle schrijft of test.
  • Elke virtuele machine of server waarop geplande scripts worden uitgevoerd.
  • Elke onlineservice (zoals Azure Functions of Azure Automation).

Als u ervoor hebt gekozen om Azure-services (zoals Azure Functions, Azure Automation, Azure Data Factory of Azure Synapse Analytics) te gebruiken, moet u deze ook inrichten en instellen.

Controlelijst : bij het installeren van software en het instellen van services zijn belangrijke beslissingen en acties:

  • Beheerders- en ontwikkelaarsmachines instellen: installeer indien van toepassing de benodigde hulpprogramma's die worden gebruikt voor ontwikkeling.
  • Servers instellen: installeer indien van toepassing de benodigde hulpprogramma's op servers of virtuele machines die aanwezig zijn in uw architectuur.
  • Azure-services instellen: inrichten en instellen van elke Azure-service, indien van toepassing. Wijs machtigingen toe voor elke beheerder/ontwikkelaar die ontwikkelwerkzaamheden uitvoert.

Een Microsoft Entra-toepassing registreren

Op dit moment hebt u besloten hoe u zich moet verifiëren. U wordt aangeraden een Microsoft Entra-toepassing (service-principal) te registreren. Dit wordt meestal een app-registratie genoemd. Deze moet worden gebruikt voor bewerkingen zonder toezicht die u automatiseert.

Zie Service-principalverificatie inschakelen voor alleen-lezen-beheerders-API's voor meer informatie over het maken van een app-registratie om controlegegevens op tenantniveau op te halen.

Controlelijst : bij het registreren van een Microsoft Entra-toepassing zijn belangrijke beslissingen en acties:

  • Controleer of er een bestaande app-registratie bestaat: controleer bij IT of een bestaande app-registratie beschikbaar is voor het uitvoeren van beheerders-API's. Als dat het geval is, bepaalt u of de bestaande moet worden gebruikt of of er een nieuwe moet worden gemaakt.
  • Maak een nieuwe app-registratie: Maak een app-registratie indien van toepassing. Overweeg het gebruik van een app-naam, zoals PowerBI-Beheer APIs-EntraApp, die het doel duidelijk beschrijft.
  • Maak een geheim voor de app-registratie: Zodra de app-registratie bestaat, maakt u er een geheim voor. Stel de vervaldatum in op basis van hoe vaak u het geheim wilt draaien.
  • Sla de waarden veilig op: Sla het geheim, de app-id (client-id) en de tenant-id op, omdat u ze nodig hebt om te verifiëren met de service-principal. Gebruik een locatie die veilig is, zoals een organisatiewachtwoordkluis. (Als u het maken van een app-registratie van IT wilt aanvragen, geeft u op dat u deze waarden nodig hebt die aan u worden geretourneerd.)
  • Een beveiligingsgroep maken: maak (of aanvraag) een beveiligingsgroep die wordt gebruikt voor Power BI. Overweeg het gebruik van groepsnaam, zoals Power BI-service-principals voor beheerders, waarmee wordt aangegeven dat de groep wordt gebruikt voor toegang tot metagegevens voor de hele tenant.
  • Voeg de service-principal toe als lid van de beveiligingsgroep: gebruik de app-id (client-id) om de nieuwe (of bestaande) service-principal toe te voegen als lid van de nieuwe beveiligingsgroep.
  • De tenantinstelling voor de beheerders-API bijwerken in Power BI: Voeg in de Power BI-beheerportal de beveiligingsgroep toe aan de service-principals toestaan om de tenantinstelling alleen-lezen power BI-beheerders-API's te gebruiken.
  • U kunt het toewijzen van machtigingen in Azure overslaan: delegeer geen machtigingen voor de app-registratie (deze krijgt toegang tot de auditgegevens op tenantniveau van Power BI via de Power BI-service-principals toestaan om alleen-lezen power BI-beheerders-API's te gebruiken).
  • Bepaal of de app-registratie toegang moet hebben tot gedetailleerde metagegevens: Bepaal of u gedetailleerde informatie wilt extraheren over semantische modeltabellen, kolommen en metingexpressies wanneer u uw tenantinventaris maakt.
  • Werk de gedetailleerde tenantinstellingen voor metagegevens bij in Power BI: Voeg desgewenst in de Power BI-beheerportal de beveiligingsgroep toe aan de antwoorden van de Api voor verbeterde beheer met gedetailleerde tenantinstellingen voor metagegevens en ook de antwoorden van de Beheer-API verbeteren met DAX en mashup-expressies voor tenantinstellingen.
  • Test de service-principal: maak een eenvoudig script om u aan te melden met behulp van de service-principal en test of deze gegevens kan ophalen uit een beheer-API.
  • Maak een proces voor het beheren van app-registratiegeheimen: maak documentatie en een proces om geheimen regelmatig te roteren. Bepaal hoe u veilig een nieuw geheim communiceert met beheerders en ontwikkelaars die dit nodig hebben.

Instellingen voor Power BI-tenants instellen

Er zijn verschillende tenantinstellingen in de Power BI-beheerportal die relevant zijn voor het extraheren van controlegegevens op tenantniveau.

API's voor Beheer

Er zijn drie tenantinstellingen die relevant zijn voor het uitvoeren van beheerders-API's.

Belangrijk

Omdat deze instellingen metagegevenstoegang verlenen voor de hele tenant (zonder directe Power BI-machtigingen toe te wijzen), moet u deze strikt beheren.

Met de tenantinstelling Alleen-lezen power BI-beheerders-API's toestaan kunt u instellen welke service-principals beheerders-API's kunnen aanroepen. Met deze instelling kan Microsoft Purview ook de volledige Power BI-tenant scannen, zodat deze de gegevenscatalogus kan vullen.

Notitie

U hoeft niet expliciet andere Power BI-beheerders toe te wijzen aan de service-principals toestaan om de tenantinstelling alleen-lezen power BI-beheerders-API's te gebruiken omdat ze al toegang hebben tot tenantbrede metagegevens.

Met de api-antwoorden verbeteren met gedetailleerde tenantinstellingen voor metagegevens kunt u instellen welke gebruikers en service-principals gedetailleerde metagegevens kunnen ophalen. Metagegevens worden opgehaald met behulp van de API's voor het scannen van metagegevens en bevatten tabellen, kolommen en meer. Met deze instelling heeft Microsoft Purview ook toegang tot informatie op schemaniveau over semantische Power BI-modellen, zodat deze in de gegevenscatalogus kan worden opgeslagen.

Met de api-antwoorden verbeteren met DAX en mashup-expressies kunt u instellen welke gebruikers en service-principals gedetailleerde metagegevens kunnen ophalen. Metagegevens worden opgehaald uit de API's voor het scannen van metagegevens en kunnen query's en semantische modelmetingexpressies bevatten.

Notitie

Service-principals toestaan om de tenantinstelling alleen-lezen power BI-beheerders-API's te gebruiken, gaat specifiek over het openen van beheerders-API's. De naam is vergelijkbaar met de tenantinstelling die is bedoeld voor toegang tot gebruikers-API's (hierna beschreven). Zie Een gebruikers-API of beheerders-API kiezen eerder in dit artikel voor meer informatie over het verschil tussen beheerders-API's en gebruikers-API's.

Gebruikers-API's

Er is één tenantinstelling die van toepassing is op het aanroepen van gebruikers-API's. In dit geval zijn power BI-machtigingen ook vereist voor de service-principal (bijvoorbeeld een werkruimterol).

Met de instelling Service-principals toestaan om API van Power BI s tenantinstelling te gebruiken, kunt u instellen welke service-principals toegang hebben om REST API's uit te voeren (met uitzondering van de beheerders-API's, die worden verleend door een andere tenantinstelling, zoals hierboven beschreven).

Er zijn andere tenantinstellingen die betrekking hebben op API's, waarmee toegang tot de ingesloten API's, streaming-API's, export-API's en de API voor het uitvoeren van query's is toegestaan. Deze API's zijn echter buiten het bereik van dit artikel.

Zie Controle op rapportniveau voor meer informatie over de tenantinstellingen voor metrische gegevens over gebruik.

Controlelijst : bij het instellen van de Instellingen van de Power BI-tenant zijn belangrijke beslissingen en acties:

  • Controleer of elke service-principal zich in de juiste groep bevindt: controleer of de power BI-beheerservice-principals de juiste service-principals bevatten.
  • Werk de tenantinstelling voor de beheerders-API bij in Power BI: voeg de beveiligingsgroep toe aan de service-principals toestaan om de tenantinstelling alleen-lezen Power BI-beheerders-API's te gebruiken, zodat de beheerders-API's metagegevens voor de hele tenant kunnen ophalen.
  • Werk de gedetailleerde tenantinstellingen voor metagegevens bij in Power BI: Voeg zo nodig de beveiligingsgroep toe aan de antwoorden van de beheer-API verbeteren met gedetailleerde tenantinstellingen voor metagegevens en de antwoorden van de Beheer-API verbeteren met DAX en mashup-expressies voor tenantinstellingen.
  • Controleer welke gebruikers-API's worden geopend: controleer of een of meer gebruikers-API's nodig zijn (naast de beheerders-API's).
  • Werk de tenantinstelling van de gebruikers-API bij in Power BI: voeg de beveiligingsgroep toe aan de service-principals toestaan API van Power BI s tenantinstelling te gebruiken, die is bedoeld voor gebruikers-API's.

Fase 3: Ontwikkeling en analyse van oplossingen

De derde fase van het plannen en implementeren van een controleoplossing op tenantniveau is gericht op het ontwikkelen en analyseren van oplossingen. Op dit moment is alle planning en besluitvorming opgetreden en u hebt voldaan aan de vereisten en de installatie voltooid. U bent nu klaar om te beginnen met het ontwikkelen van oplossingen, zodat u analyses kunt uitvoeren en inzichten kunt verkrijgen uit uw controlegegevens.

Stroomdiagram met een beschrijving van fase 3, die is gericht op het ontwikkelen en analyseren van oplossingen van een controleoplossing op tenantniveau.

De onbewerkte gegevens extraheren en opslaan

Op dit moment moeten uw vereisten en prioriteiten duidelijk zijn. De belangrijkste technische beslissingen zijn genomen over het openen van controlegegevens en de locatie voor het opslaan van controlegegevens. Voorkeurshulpprogramma's zijn geselecteerd en de vereisten en instellingen zijn ingesteld. Tijdens de vorige twee fasen hebt u mogelijk een of meer kleine projecten (proof of concept) voltooid om haalbaarheid te bewijzen. De volgende stap is het instellen van een proces voor het extraheren en opslaan van de onbewerkte controlegegevens.

Net als bij gegevens die door de meeste Microsoft-API's worden geretourneerd, worden controlegegevens opgemaakt als JSON. JSON-opgemaakte gegevens zijn zelfbeschrijfbaar omdat het leesbare tekst is die structuur en gegevens bevat.

JSON vertegenwoordigt gegevensobjecten die bestaan uit kenmerk-waardeparen en matrices. Is bijvoorbeeld "state": "Active" een voorbeeld waarbij de waarde van het statuskenmerk actief is. Een JSON-matrix bevat een geordende lijst met elementen, gescheiden door een komma en die tussen vierkante haken ([ ]) staan. Het is gebruikelijk om geneste matrices te vinden in JSON-resultaten. Zodra u bekend raakt met de hiërarchische structuur van een JSON-resultaat, is het eenvoudig om de gegevensstructuur te begrijpen, zoals een lijst (matrix) met semantische modellen in een werkruimte.

Hier volgen enkele overwegingen voor het extraheren en opslaan van de onbewerkte gegevens die zijn opgehaald uit de API's.

  • Welke naamconventie wordt gebruikt? Voor een systeem op basis van bestanden is een naamconventie nodig voor bestanden, mappen en Data Lake-zones. Voor een database is een naamconventie nodig voor tabellen en kolommen.
  • Welke indeling wordt gebruikt om de onbewerkte gegevens op te slaan? Naarmate Power BI nieuwe functies blijft introduceren, worden nieuwe activiteiten weergegeven die momenteel niet bestaan. Daarom raden we u aan de oorspronkelijke JSON-resultaten te extraheren en te behouden. De gegevens niet parseren, filteren of opmaken terwijl ze worden geëxtraheerd. Op die manier kunt u de oorspronkelijke onbewerkte gegevens gebruiken om uw gecureerde controlegegevens opnieuw te genereren.
  • Welke opslaglocatie wordt gebruikt? Een data lake of blob-opslag wordt vaak gebruikt voor het opslaan van onbewerkte gegevens. Zie Bepalen waar controlegegevens eerder in dit artikel moeten worden opgeslagen voor meer informatie.
  • Hoeveel geschiedenis zal je opslaan? Exporteer de controlegegevens naar een locatie waar u de geschiedenis kunt opslaan. Plan om ten minste twee jaar geschiedenis te verzamelen. Op die manier kunt u trends en wijzigingen analyseren buiten de standaardretentieperiode van 30 dagen. U kunt ervoor kiezen om de gegevens voor onbepaalde tijd op te slaan, of u kunt besluiten over een kortere periode, afhankelijk van het bewaarbeleid voor gegevens voor uw organisatie.
  • Hoe kunt u bijhouden wanneer het proces voor het laatst is uitgevoerd? Stel een configuratiebestand of het equivalent in om de tijdstempels vast te leggen wanneer een proces wordt gestart en voltooid. De volgende keer dat het proces wordt uitgevoerd, kunnen deze tijdstempels worden opgehaald. Het is vooral belangrijk dat u tijdstempels opslaat wanneer u gegevens extraheert met behulp van de API's voor het scannen van metagegevens.
  • Hoe gaat u beperking afhandelen? Sommige Power BI REST API's en de Microsoft Graph API implementeren beperking. U ontvangt een 429-fout (te veel aanvragen) als uw API-aanvraag wordt beperkt. Beperking kan een veelvoorkomend probleem zijn voor grotere organisaties die een grote hoeveelheid gegevens moeten ophalen. Hoe u mislukte pogingen door beperking vermijdt, is afhankelijk van de technologie die u gebruikt om de gegevens te openen en te extraheren. Een optie is het ontwikkelen van logica in uw scripts die reageert op een fout 429 'Te veel aanvragen' door het opnieuw te proberen na een wachttijd.
  • Zijn de controlegegevens nodig voor naleving? Veel organisaties gebruiken de onbewerkte auditlogboekrecords om nalevingscontroles uit te voeren of om te reageren op beveiligingsonderzoeken. In dergelijke gevallen raden we u ten zeerste aan de onbewerkte gegevens op te slaan in onveranderbare opslag. Zodra de gegevens zijn geschreven, kunnen deze niet worden gewijzigd of verwijderd door een beheerder of andere gebruiker.
  • Welke opslaglagen zijn nodig om uw vereisten te ondersteunen? De beste plaatsen om onbewerkte gegevens op te slaan, zijn een data lake (zoals Azure Data Lake Storage Gen2) of objectopslag (zoals Azure Blob Storage). Een bestandssysteem kan ook worden gebruikt als cloudservices geen optie zijn.

Controlelijst : bij het extraheren en opslaan van de onbewerkte gegevens zijn belangrijke beslissingen en acties:

  • Bevestig vereisten en prioriteiten: Verhelder de vereisten en prioriteiten voor de gegevens die u eerst gaat extraheren.
  • Bevestig de gegevensbron die moet worden geëxtraheerd: controleer de bron voor elk type gegevens dat u nodig hebt.
  • Stel een proces in om de gegevens te extraheren en te laden in de onbewerkte gegevenszone: maak het eerste proces om de onbewerkte gegevens in de oorspronkelijke staat te extraheren en te laden, zonder transformaties. Test of het proces werkt zoals bedoeld.
  • Maak een planning om de processen uit te voeren: stel een terugkerend schema in om de processen voor extraheren, laden en transformeren uit te voeren.
  • Controleer of referenties veilig worden beheerd: controleer of wachtwoorden, geheimen en sleutels veilig worden opgeslagen en gecommuniceerd.
  • Controleer of de beveiliging juist is ingesteld: controleer of de toegangsmachtigingen juist zijn ingesteld voor de onbewerkte gegevens. Zorg ervoor dat beheerders en auditors toegang hebben tot de onbewerkte gegevens.

Zie Operationeel maken en verbeteren verderop in dit artikel voor meer informatie over hoe een controle- en bewakingsoplossing in de loop van de tijd groeit.

De gecureerde gegevens maken

Op dit moment worden de onbewerkte gegevens geëxtraheerd en opgeslagen. De volgende stap is het maken van een afzonderlijke gouden gegevenslaag voor de gecureerde gegevens. Het doel is om de gegevensbestanden te transformeren en op te slaan in een stervormig schema. Een stervormig schema bestaat uit dimensietabellen en feitentabellen en is opzettelijk geoptimaliseerd voor analyse en rapportage. De bestanden in de gecureerde gegevenslaag worden de bron van een Power BI-gegevensmodel (beschreven in het volgende onderwerp).

Tip

Wanneer u verwacht dat er meer dan één gegevensmodel is, is investeren in een gecentraliseerde gecureerde gegevenslaag bijzonder nuttig.

Controlelijst : bij het maken van de gecureerde gegevenslaag zijn belangrijke beslissingen en acties:

  • Bevestig de vereisten en prioriteiten: Als u een tussenliggende zilveren laag voor de getransformeerde gegevens wilt gebruiken, moet u de vereisten en doelstellingen verduidelijken voor wat u moet bereiken.
  • Stel een proces in om de onbewerkte gegevens te transformeren en te laden in de gecureerde gegevenszone: Maak een proces om de gegevens te transformeren en te laden in een stervormig schema. Test of het proces werkt zoals bedoeld.
  • Maak een planning om de processen uit te voeren: stel een terugkerend schema in om de gecureerde gegevenslaag te vullen.
  • Controleer of de beveiliging juist is ingesteld: controleer of de toegangsmachtigingen juist zijn ingesteld voor de gecureerde gegevens. Zorg ervoor dat ontwikkelaars van het gegevensmodel toegang hebben tot de gecureerde gegevens.

Een gegevensmodel maken

Het onderwerp gaat over het instellen van een analytisch gegevensmodel. Een gegevensmodel is een op query's gebaseerde gegevensresource die is geoptimaliseerd voor analyse. Soms wordt het een semantisch model of gewoon een model genoemd. Voor uw controle- en bewakingsoplossing wordt het gegevensmodel waarschijnlijk geïmplementeerd als een semantisch Power BI-model.

In de context van controle en bewaking, een gegevensmodelbrongegevens uit de gecureerde (gouden) gegevenslaag. Als u ervoor kiest om geen gecureerde gegevenslaag te maken, worden de gegevens rechtstreeks uit de onbewerkte gegevens opgehaald.

Het is raadzaam dat uw Power BI-gegevensmodel een stervormig schemaontwerp implementeert. Wanneer de brongegevens de gecureerde gegevenslaag zijn, moet het sterschema van het Power BI-gegevensmodel het gecureerde gegevenslaagsterschema spiegelen.

Tip

Zie Stervormige schema's en het belang van Power BI voor een overzicht van het ontwerp van stervormige schema's.

Net als bij elk Power BI-project is het maken van een gegevensmodel een iteratief proces. U kunt indien nodig nieuwe metingen toevoegen. U kunt ook nieuwe tabellen en kolommen toevoegen wanneer er nieuwe controlegebeurtenissen beschikbaar komen. Op tijd kunt u zelfs nieuwe gegevensbronnen integreren.

Hier volgen enkele nuttige dimensietabellen die u in het gegevensmodel kunt opnemen.

  • Datum: Een set datumkenmerken voor het inschakelen van analyse (segmentering en segmentering) van gegevens per dag, week, maand, kwartaal, jaar en andere relevante tijdsperioden.
  • Tijd: Als u wilt analyseren op het tijdstip van de dag en u een zeer groot aantal controlegegevens hebt, kunt u overwegen om het tijdgedeelte afzonderlijk van de datum op te slaan. Deze aanpak kan helpen om de queryprestaties te verbeteren.
  • Gebruikers: Kenmerken die gebruikers beschrijven (zoals afdeling en geografische regio) die veel onderwerpen van controlegegevens kunnen filteren. Het doel is om alle gebruikersgegevens uit de feitentabellen te verwijderen en op te slaan in deze dimensietabel, zodat ze veel feitentabellen kunnen filteren. U kunt ook service-principals opslaan in deze tabel.
  • Activiteitsevenementen: Kenmerken die de activiteitsevenementen (bewerkingen) groeperen en beschrijven. Om uw rapportage te verbeteren, kunt u een gegevenswoordenlijst maken waarin elke activiteitsevenement wordt beschreven. U kunt ook een hiërarchie maken die vergelijkbare activiteitsgebeurtenissen groepert en classificeert. U kunt bijvoorbeeld alle gebeurtenissen voor het maken van items groeperen, gebeurtenissen verwijderen, enzovoort.
  • Werkruimten: Een lijst met werkruimten in de eigenschappen van de tenant en werkruimte, zoals type (persoonlijk of standaard) en beschrijving. Sommige organisaties registreren meer informatie over werkruimten (mogelijk met behulp van een SharePoint-lijst). U kunt deze details integreren in deze dimensietabel. U moet bepalen of deze dimensietabel alleen de huidige status van de werkruimte opslaat of dat versiegegevens worden opgeslagen die aanzienlijke wijzigingen in de werkruimte in de loop van de tijd weerspiegelen. Wanneer de naam van een werkruimte bijvoorbeeld wordt gewijzigd, worden in historische rapporten de naam van de huidige werkruimte of de naam van de werkruimte weergegeven die op dat moment actueel was? Zie Langzaam veranderende dimensies voor meer informatie over versiebeheer.
  • Itemtypen: een lijst met Power BI-itemtypen (semantische modellen, rapporten en andere).
  • Capaciteiten: een lijst met Premium-capaciteiten in de tenant.
  • Gateways: een lijst met gegevensgateways in de tenant.
  • Gegevensbronnen: een lijst met gegevensbronnen die worden gebruikt door een semantisch model, gegevensstroom of datamart.

Hier volgen enkele nuttige feitentabellen (onderwerpen) die u in het gegevensmodel kunt opnemen.

  • Gebruikersactiviteiten: de feitgegevens die afkomstig zijn van de oorspronkelijke JSON-gegevens. Alle kenmerken die geen analytische waarde hebben, worden verwijderd. Alle kenmerken die deel uitmaken van de dimensietabellen (hierboven) worden ook verwijderd.
  • Tenantinventaris: Een momentopname van een bepaald tijdstip van alle items die in de tenant zijn gepubliceerd. Zie Tenantinventaris eerder in dit artikel voor meer informatie.
  • Semantische modellen: bevat gebruikersactiviteit met semantische modellen (zoals wijzigingen in semantische modellen) of gerelateerde gegevensbronnen.
  • Semantische modelvernieuwingen: slaat bewerkingen voor gegevensvernieuwing op, inclusief details over het type (gepland of on-demand), duur, status en welke gebruiker de bewerking heeft gestart.
  • Werkruimterollen: Een momentopname van een bepaald tijdstip van roltoewijzingen van de werkruimte.
  • Gebruikerslicenties: Een momentopname van een bepaald tijdstip van gebruikerslicenties. Hoewel u misschien geneigd bent om de gebruikerslicentie op te slaan in de dimensietabel Gebruikers , biedt deze benadering geen ondersteuning voor de analyse van licentiewijzigingen en trends in de loop van de tijd.
  • Lidmaatschappen van gebruikersgroepen: een momentopname van gebruikers (en service-principals) die zijn toegewezen aan een beveiligingsgroep.
  • Communityactiviteiten: Bevat aan community gerelateerde feiten, zoals trainingsgebeurtenissen. U kunt bijvoorbeeld Power BI-gebruikersactiviteiten analyseren in vergelijking met aanwezigheid van trainingen. Deze gegevens kunnen het Center of Excellence helpen potentiële nieuwe kampioenen te identificeren.

Feitentabellen mogen geen kolommen bevatten die door rapportmakers worden gefilterd. In plaats daarvan behoren deze kolommen tot gerelateerde dimensietabellen. Dit ontwerp is niet alleen efficiënter voor query's, maar bevordert ook het hergebruik van dimensietabellen door meerdere feiten (ook wel drill across genoemd). Dat laatste punt is belangrijk om een nuttig en gebruiksvriendelijk gegevensmodel te produceren dat uitbreidbaar is wanneer u nieuwe feitentabellen (onderwerpen) toevoegt.

De dimensietabel Gebruikers is bijvoorbeeld gerelateerd aan elke feitentabel. Deze moet zijn gerelateerd aan de feitentabel Gebruikersactiviteiten (die de activiteit hebben uitgevoerd), de feitentabel tenantinventaris (die het gepubliceerde item heeft gemaakt) en alle andere feitentabellen. Wanneer een rapport filtert op een gebruiker in de dimensietabel Gebruikers , kunnen visuals in dat rapport feiten voor die gebruiker weergeven vanuit een gerelateerde feitentabel.

Wanneer u uw model ontwerpt, moet u ervoor zorgen dat een kenmerk eenmaal en slechts eenmaal zichtbaar is in het model. Het e-mailadres van de gebruiker mag bijvoorbeeld alleen zichtbaar zijn in de dimensietabel Gebruikers . Deze bestaat ook in andere feitentabellen (als dimensiesleutel ter ondersteuning van een modelrelatie). U moet deze echter verbergen in elke feitentabel.

U wordt aangeraden uw gegevensmodel gescheiden van rapporten te maken. De ontkoppeling van een semantisch model en de bijbehorende rapporten resulteert in een gecentraliseerd semantisch model dat veel rapporten kan leveren. Zie het beheerde bi-gebruiksscenario voor selfservice voor meer informatie over het gebruik van een gedeeld semantisch model.

Overweeg om beveiliging op rijniveau (RLS) in te stellen, zodat andere gebruikers, buiten het Center of Excellence, auditors en beheerders, kunnen analyseren en rapporteren over controlegegevens. U kunt bijvoorbeeld RLS-regels gebruiken om inhoudsmakers en consumenten toe te staan hun eigen gebruikersactiviteiten of ontwikkelingsinspanningen te rapporteren.

Controlelijst : bij het maken van het gegevensmodel zijn belangrijke beslissingen en acties:

  • Het gegevensmodel plannen en maken: ontwerp het gegevensmodel als een stervormig schema. Valideer of relaties werken zoals bedoeld. Tijdens het ontwikkelen van het model maakt u iteratief metingen en voegt u aanvullende gegevens toe op basis van analytische vereisten. Voeg zo nodig toekomstige verbeteringen toe aan een achterstand.
  • Beveiliging op rijniveau instellen: Als u het gegevensmodel beschikbaar wilt maken voor andere algemene gebruikers, stelt u beveiliging op rijniveau in om de toegang tot gegevens te beperken. Controleer of de RLS-rollen de juiste gegevens retourneren.

Het gegevensmodel verbeteren

Als u het gebruik van inhoud en gebruikersactiviteiten effectief wilt analyseren, raden we u aan uw gegevensmodel te verrijken. Verbeteringen aan gegevensmodellen kunnen geleidelijk en iteratief worden uitgevoerd wanneer u kansen en nieuwe vereisten ontdekt.

Classificaties maken

Een manier om het model te verbeteren en de waarde van uw gegevens te verhogen, is door classificaties toe te voegen aan het gegevensmodel. Zorg ervoor dat deze classificaties consistent worden gebruikt door uw rapporten.

U kunt ervoor kiezen om gebruikers te classificeren op basis van hun gebruiksniveau of om inhoud te classificeren op basis van het gebruiksniveau.

Classificatie van gebruikersgebruik

Houd rekening met de volgende classificaties voor gebruikersgebruik.

  • Frequente gebruiker: Activiteit geregistreerd in de afgelopen week en in negen van de afgelopen 12 maanden.
  • Actieve gebruiker: Activiteit vastgelegd in de afgelopen maand.
  • Incidentele gebruiker: Activiteit die is vastgelegd in de afgelopen negen maanden, maar zonder activiteit in de afgelopen één maand.
  • Inactieve gebruiker: Er is geen activiteit vastgelegd in de afgelopen negen maanden.

Tip

Het is handig om te weten wie uw incidentele of inactieve gebruikers zijn, met name wanneer ze Pro- of PPU-licenties hebben (waarvoor kosten zijn verbonden). Het is ook handig om te weten wie uw frequente en meest actieve gebruikers zijn. U kunt ze uitnodigen om deel te nemen aan kantooruren of trainingen bij te wonen. Uw meest actieve makers van inhoud kunnen kandidaten zijn om lid te worden van uw kampioenennetwerk.

Classificatie van inhoudsgebruik

Houd rekening met de volgende classificaties voor inhoudsgebruik.

  • Veelgebruikte inhoud: Activiteit die is vastgelegd in de afgelopen week en in negen van de afgelopen 12 maanden.
  • Actief gebruikte inhoud: activiteit vastgelegd in de afgelopen maand.
  • Af en toe gebruikte inhoud: Activiteit die is vastgelegd in de afgelopen negen maanden, maar zonder activiteit in de afgelopen één maand.
  • Ongebruikte inhoud: er is geen activiteit vastgelegd in de afgelopen negen maanden.
Classificatie van gebruikerstypen

Houd rekening met de volgende classificaties voor gebruikerstype.

  • Maker van inhoud: activiteit die is vastgelegd in de afgelopen zes maanden die inhoud heeft gemaakt, gepubliceerd of bewerkt.
  • Inhoudsviewer: Activiteit die is vastgelegd in de afgelopen zes maanden die inhoud heeft bekeken, maar zonder activiteit voor het maken van inhoud.

U moet beslissen of de gebruiksclassificaties voor gebruikers of inhoud alleen moeten zijn gebaseerd op hoe recent een activiteit heeft plaatsgevonden. U kunt ook rekening houden met het gemiddelde of trendinggebruik in de loop van de tijd.

Bekijk enkele voorbeelden die laten zien hoe eenvoudige classificatielogica de realiteit mogelijk onjuist vertegenwoordigt.

  • Een manager heeft deze week één rapport bekeken. Vóór die week had de manager echter de afgelopen zes maanden geen rapporten bekeken. U moet deze manager niet beschouwen als een frequente gebruiker op basis van recent gebruik.
  • Een maker van een rapport publiceert elke week een nieuw rapport. Wanneer u het gebruik analyseert door frequente gebruikers, lijkt de reguliere activiteit van de maker van het rapport positief te zijn. Na nader onderzoek ontdekt u echter dat deze gebruiker een nieuw rapport (met een nieuwe rapportnaam) opnieuw heeft gepubliceerd telkens wanneer ze het rapport bewerken. Het zou handig zijn voor de maker van het rapport om meer training te krijgen.
  • Een leidinggevende bekijkt een rapport sporadisch, zodat de gebruiksclassificatie regelmatig verandert. Mogelijk moet u bepaalde typen gebruikers, zoals leidinggevenden, anders analyseren.
  • Een interne auditor bekijkt eenmaal per jaar kritieke rapporten. De interne auditor lijkt een inactieve gebruiker te zijn vanwege hun onregelmatige gebruik. Iemand kan stappen ondernemen om hun Pro- of PPU-licentie te verwijderen. Of iemand kan geloven dat een rapport buiten gebruik moet worden gesteld omdat het niet vaak wordt gebruikt.

Tip

U kunt gemiddelden en trends berekenen met behulp van de DAX-functies voor time intelligence. Als u wilt weten hoe u deze functies gebruikt, kunt u de leermodule DAX-time intelligence-functies gebruiken in Power BI Desktop-modellen .

Controlelijst : bij het maken van classificatie van gebruiksgegevens zijn belangrijke beslissingen en acties:

  • Krijg consensus over classificatiedefinities: Bespreek classificatiedefinities met de relevante belanghebbenden. Zorg ervoor dat er overeenstemming is bij het nemen van de beslissingen.
  • Documentatie maken: Zorg ervoor dat de classificatiedefinities zijn opgenomen in documentatie voor makers en consumenten van inhoud.
  • Een feedbacklus maken: zorg ervoor dat gebruikers vragen kunnen stellen of wijzigingen in de classificatiedefinities kunnen voorstellen.

Analytische rapporten maken

Op dit moment zijn de controlegegevens geëxtraheerd en opgeslagen en u hebt een gegevensmodel gepubliceerd. De volgende stap is het maken van analytische rapporten.

Richt u op de belangrijkste informatie die het meest relevant is voor elke doelgroep. Mogelijk hebt u verschillende doelgroepen voor uw controlerapporten. Elke doelgroep is geïnteresseerd in verschillende informatie en voor verschillende doeleinden. De doelgroepen die u met uw rapporten kunt bedienen, zijn onder andere:

  • Eindverantwoordelijke
  • Center of Excellence
  • Power BI-beheerders
  • Werkruimtebeheerders
  • Premium-capaciteitsbeheerders
  • Gatewaybeheerders
  • Power BI-ontwikkelaars en makers van inhoud
  • Auditors

Hier volgen enkele van de meest voorkomende analytische vereisten waarmee u kunt beginnen wanneer u uw controlerapporten maakt.

  • Belangrijkste inhoudsweergaven: Uw executive sponsor en leiderschapsteams zijn mogelijk vooral geïnteresseerd in samenvattingsinformatie en trends in de loop van de tijd. Uw werkruimtebeheerders, ontwikkelaars en makers van inhoud zijn meer geïnteresseerd in de details.
  • Belangrijkste gebruikersactiviteiten: uw Center of Excellence is geïnteresseerd in wie Power BI gebruikt, hoe en wanneer. Uw Premium-capaciteitsbeheerders zijn geïnteresseerd in wie de capaciteit gebruikt om de status en stabiliteit ervan te waarborgen.
  • Tenantinventaris: Uw Power BI-beheerders, werkruimtebeheerders en auditors willen weten welke inhoud er bestaat, waar, herkomst en de beveiligingsinstellingen.

Deze lijst is niet all-inclusive. Het is bedoeld om u te voorzien van ideeën over het maken van analytische rapporten die zijn gericht op specifieke behoeften. Zie gegevensbehoeften eerder in dit artikel voor meer overwegingen en overzicht van controle en bewaking. Deze resources bevatten veel ideeën voor het gebruik van controlegegevens en de typen informatie die u in uw rapporten kunt presenteren.

Tip

Hoewel het verleidelijk is om veel gegevens weer te geven, neemt u alleen informatie op waar u op voorbereid bent om actie te ondernemen. Zorg ervoor dat elke rapportpagina duidelijk is over het doel, welke actie moet worden ondernomen en door wie.

Als u wilt weten hoe u analytische rapporten maakt, moet u het leertraject Effectieve rapporten ontwerpen in Power BI doorlopen.

Controlelijst : bij het plannen van analytische controlerapporten zijn belangrijke beslissingen en acties:

  • Vereisten controleren: prioriteit geven aan het maken van rapporten op basis van bekende behoeften en specifieke vragen die moeten worden beantwoord.
  • Bevestig uw doelgroep(en): Maak duidelijk wie de controlerapporten gaat gebruiken en wat hun beoogde doel is.
  • Rapporten maken en implementeren: ontwikkel de eerste set kernrapporten. Breid ze geleidelijk uit en verbeter ze geleidelijk in de loop van de tijd.
  • Rapporten distribueren in een app: Overweeg om een app te maken die al uw controle- en bewakingsrapporten bevat.
  • Controleer wie toegang heeft tot rapporten: zorg ervoor dat de rapporten (of de app) beschikbaar zijn voor de juiste set gebruikers.
  • Een feedbacklus maken: zorg ervoor dat gebruikers van rapporten feedback of suggesties kunnen geven of problemen kunnen melden.

Actie ondernemen op basis van de gegevens

Controlegegevens zijn waardevol omdat u hiermee inzicht krijgt in wat er in uw Power BI-tenant gebeurt. Hoewel het misschien duidelijk lijkt, kunt u zich expliciet gedragen op wat u van de controlegegevens leert, gemakkelijk over het hoofd worden gezien. Daarom raden we u aan iemand toe te wijzen die verantwoordelijk is voor het bijhouden van meetbare verbeteringen, in plaats van alleen controlerapporten te bekijken. Op die manier kunt u geleidelijk, meetbare vooruitgang boeken in uw acceptatie en volwassenheid met Power BI.

U kunt veel verschillende acties uitvoeren op basis van uw doelen en wat u leert van de controlegegevens. In de rest van deze sectie vindt u verschillende ideeën.

Inhoudsgebruik

Hier volgen enkele acties die u kunt uitvoeren op basis van de wijze waarop inhoud wordt gebruikt.

  • Inhoud wordt vaak gebruikt (dagelijks of wekelijks): Controleer of kritieke inhoud is gecertificeerd. Controleer of het eigendom duidelijk is en of de oplossing voldoende wordt ondersteund.
  • Groot aantal werkruimteweergaven: wanneer een groot aantal werkruimteweergaven plaatsvindt, onderzoekt u waarom Power BI-apps niet worden gebruikt.
  • Inhoud wordt zelden gebruikt: neem contact op met de doelgebruikers om te bepalen of de oplossing aan hun behoeften voldoet of of hun vereisten zijn gewijzigd.
  • Vernieuwingsactiviteit vindt vaker plaats dan weergaven: neem contact op met de eigenaar van de inhoud om te begrijpen waarom een semantisch model regelmatig wordt vernieuwd zonder recent gebruik van het semantische model of gerelateerde rapporten.

Gebruikersactiviteiten

Hier volgen enkele acties die u kunt uitvoeren op basis van gebruikersactiviteiten.

  • Eerste publicatieactie door een nieuwe gebruiker: bepaal wanneer een gebruiker van het type gebruiker verandert van de maker, die u kunt identificeren wanneer ze inhoud voor de eerste keer publiceren. Het is een geweldige gelegenheid om ze een standaard-e-mail te sturen die richtlijnen en koppelingen naar nuttige bronnen biedt.
  • Betrokkenheid bij de meest voorkomende makers van inhoud: nodig uw meest actieve makers uit om deel te nemen aan uw kampioenennetwerk of om betrokken te raken bij uw community van de praktijk.
  • Licentiebeheer: controleer of inactieve makers nog steeds een Pro- of PPU-licentie nodig hebben.
  • Activering van proefversies van gebruikers: een activering van een proeflicentie kan u vragen om een permanente licentie aan de gebruiker toe te wijzen voordat de proefversie afloopt.

Mogelijkheden voor gebruikerstraining

Hier volgen enkele mogelijkheden voor gebruikerstraining die u kunt identificeren op basis van de controlegegevens.

  • Groot aantal semantische modellen die door dezelfde maker van inhoud zijn gepubliceerd: leer gebruikers over gedeelde semantische modellen en waarom het belangrijk is om dubbele semantische modellen te voorkomen.
  • Overmatig delen vanuit een persoonlijke werkruimte: Neem contact op met een gebruiker die veel deelt vanuit hun persoonlijke werkruimte. Leer ze over standaardwerkruimten.
  • Belangrijke rapportweergaven van een persoonlijke werkruimte: Neem contact op met een gebruiker die eigenaar is van inhoud met een groot aantal rapportweergaven. Leer hen hoe standaardwerkruimten beter zijn dan persoonlijke werkruimten.

Tip

U kunt uw trainingsinhoud of documentatie ook verbeteren door vragen te bekijken die worden beantwoord door uw interne Power BI-community en problemen die zijn ingediend bij de helpdesk.

Beveiliging

Hier volgen enkele beveiligingssituaties die u mogelijk actief wilt bewaken.

Zie de artikelen over beveiligingsplanning voor meer informatie.

Governance en risicobeperking

Hier volgen enkele situaties die u kunt tegenkomen. Overweeg expliciet te zoeken naar dit soort situaties in uw controlerapporten, dus u bent voorbereid om snel te handelen.

  • Een groot aantal weergaven voor rapporten (en onderliggende semantische modellen) die niet zijn goedgekeurd.
  • Belangrijk gebruik van onbekende of niet-opgegeven gegevensbronnen.
  • Bestandslocaties die niet overeenkomen met governancerichtlijnen voor de locatie waar bronbestanden zich moeten bevinden.
  • Werkruimtenamen zijn niet afgestemd op governancevereisten.
  • Vertrouwelijkheidslabels worden gebruikt voor gegevensbeveiliging.
  • Consistente fouten bij het vernieuwen van gegevens.
  • Belangrijk en terugkerend gebruik van afdrukken.
  • Onverwacht of overmatig gebruik van abonnementen.
  • Onverwacht gebruik van persoonlijke gateways.

De specifieke acties die in elke situatie moeten worden ondernomen, zijn afhankelijk van uw governancebeleid. Zie Governance in de roadmap voor acceptatie van infrastructuur voor meer informatie.

Controlelijst : bij het plannen van mogelijke acties op basis van de controlegegevens zijn belangrijke beslissingen en acties:

  • Verwachtingen verduidelijken: maak controlerapporten met een duidelijke set verwachtingen voor welke acties worden verwacht.
  • Verduidelijken wie verantwoordelijk is voor acties: zorg ervoor dat rollen en verantwoordelijkheden worden toegewezen.
  • Automatisering maken: automatiseer indien mogelijk bekende acties die kunnen worden herhaald.
  • Gebruik een traceringssysteem: gebruik een systeem om een waargenomen situatie bij te houden, inclusief contact gemaakt, volgende geplande actie, wie verantwoordelijk, oplossing en status is.

Fase 4: Onderhouden, verbeteren en bewaken

De vierde fase van het plannen en implementeren van een controleoplossing op tenantniveau is gericht op onderhoud, verbeteringen en bewaking. Op dit moment is uw controleoplossing in productiegebruik. U houdt zich nu voornamelijk bezig met het onderhouden, verbeteren en bewaken van de oplossing.

Stroomdiagram met een beschrijving van fase 4, die is gericht op het onderhouden, verbeteren en bewaken van een controleoplossing op tenantniveau.

Operationeel maken en verbeteren

Controleprocessen worden doorgaans beschouwd als in productie wanneer de eerste ontwikkeling en testen zijn voltooid en u het proces hebt geautomatiseerd. Geautomatiseerde controleprocessen die in productie worden uitgevoerd, hebben meer verwachtingen (dan handmatige processen) voor kwaliteit, betrouwbaarheid, stabiliteit en ondersteuning.

Er is een controleproces op productieniveau uitgevoerd. Een operationele oplossing bevat meestal veel van de volgende kenmerken.

  • Veilig: referenties worden veilig opgeslagen en beheerd. Scripts bevatten geen wachtwoorden of sleutels in tekst zonder opmaak.
  • Planning: Er is een betrouwbaar planningssysteem aanwezig.
  • Wijzigingsbeheer: het gebruik van procedures voor wijzigingsbeheer en meerdere omgevingen worden gebruikt om ervoor te zorgen dat de productieomgeving wordt beveiligd. U kunt ook werken met ontwikkel- en testomgevingen, of alleen met een ontwikkelomgeving.
  • Ondersteuning: Het team dat de oplossing ondersteunt, is duidelijk gedefinieerd. Teamleden zijn getraind en ze begrijpen de operationele verwachtingen. Back-upleden zijn geïdentificeerd en crosstraining vindt plaats indien van toepassing.
  • Waarschuwingen: wanneer er iets misgaat, melden waarschuwingen het ondersteuningsteam automatisch. Bij voorkeur omvat waarschuwingen zowel logboeken als e-mail (in plaats van alleen e-mail). Een logboek is handig voor het analyseren van vastgelegde fouten en waarschuwingen.
  • Logboekregistratie: processen worden geregistreerd, zodat er een geschiedenis is van wanneer de controlegegevens zijn bijgewerkt. Vastgelegde gegevens moeten de begintijd, eindtijd en de identiteit vastleggen van de gebruiker of app die het proces heeft uitgevoerd.
  • Foutafhandeling: Scripts en processen verwerken probleemloos en logboekfouten (zoals of u onmiddellijk wilt afsluiten, doorgaan of wachten en het opnieuw proberen). Waarschuwingsmeldingen worden naar het ondersteuningsteam verzonden wanneer er een fout optreedt.
  • Coderingsstandaarden: Goede coderingstechnieken die goed presteren, worden gebruikt. Lussen worden bijvoorbeeld doelbewust vermeden, behalve wanneer dat nodig is. Consistente coderingsstandaarden, opmerkingen, opmaak en syntaxis worden gebruikt, zodat de oplossing gemakkelijker te onderhouden en te ondersteunen is.
  • Hergebruik en modularisatie: om duplicatie te minimaliseren, worden code- en configuratiewaarden (zoals verbindingsreeks s of e-mailadressen voor meldingen) ge modulariseerd, zodat andere scripts en processen deze opnieuw kunnen gebruiken.

Tip

U hoeft niet alles in één keer te doen. Naarmate u ervaring krijgt, kunt u de oplossing stapsgewijs verbeteren, zodat deze volledig en robuust wordt. Houd er rekening mee dat de meeste voorbeelden die u online vindt, eenvoudige, eenmalige scriptfragmenten zijn die mogelijk geen productiekwaliteit zijn.

Controlelijst : wanneer u van plan bent om een controleoplossing operationeel te maken en te verbeteren, zijn belangrijke beslissingen en acties:

  • Evalueer het niveau van bestaande oplossingen: Bepaal of er mogelijkheden zijn om bestaande controleoplossingen te verbeteren en te stabiliseren die geautomatiseerd zijn.
  • Stel standaarden op productieniveau in: Bepaal welke standaarden u wilt hebben voor uw geautomatiseerde controleprocessen. Houd rekening met verbeteringen die u in de loop van de tijd realistisch kunt toevoegen.
  • Maak een plan voor verbetering: plan om de kwaliteit en stabiliteit van productiecontroleoplossingen te verbeteren.
  • Bepaal of een afzonderlijke ontwikkelomgeving nodig is: Beoordeel het risiconiveau en de afhankelijkheid van de productiegegevens. Bepaal wanneer u afzonderlijke ontwikkel- en productieomgevingen (en testomgevingen) wilt maken.
  • Overweeg een strategie voor gegevensretentie: Bepaal of u een gegevensretentieproces moet implementeren waarmee gegevens na een bepaalde periode of op verzoek worden verwijderd.

Documentatie en ondersteuning

Documentatie en ondersteuning zijn essentieel voor elke oplossing op productieniveau. Het is handig om verschillende typen documentatie te maken, afhankelijk van de doelgroep en het doel.

Technische documentatie

Technische documentatie is gericht op het technische team dat de oplossing heeft gebouwd en die de oplossing geleidelijk zal verbeteren en uitbreiden in de loop van de tijd. Het is ook een nuttige resource voor het ondersteuningsteam.

Technische documentatie moet het volgende omvatten:

  • Een overzicht van architectuuronderdelen en vereisten.
  • Wie eigenaar is van en beheert de oplossing.
  • Wie ondersteunt de oplossing.
  • Een architectuurdiagram.
  • Ontwerpbeslissingen, waaronder doelen, redenen waarom bepaalde technische keuzes zijn gemaakt en beperkingen (zoals kosten of vaardigheden).
  • Beveiligingsbeslissingen en -keuzes.
  • Naamconventies die worden gebruikt.
  • Coderen en technische normen en richtlijnen.
  • Vereisten voor wijzigingsbeheer.
  • Implementatie-, installatie- en installatie-instructies.
  • Bekende gebieden van technische schulden (gebieden die kunnen worden verbeterd als er mogelijkheden zijn om dit te doen).

Ondersteuningsdocumentatie

Afhankelijk van het niveau van kritiek voor uw controleoplossing, hebt u mogelijk een helpdesk of ondersteuningsteam als er urgente problemen optreden. Ze zijn mogelijk de hele dag beschikbaar, elke dag.

Ondersteuningsdocumentatie wordt soms een knowledge base of een runbook genoemd. Deze documentatie is gericht op uw helpdesk of ondersteuningsteam en moet het volgende omvatten:

  • Richtlijnen voor probleemoplossing voor wanneer er iets misgaat. Als er bijvoorbeeld een fout is opgetreden bij het vernieuwen van gegevens.
  • Acties die doorlopend moeten worden uitgevoerd. Er kunnen bijvoorbeeld enkele handmatige stappen zijn die iemand regelmatig moet uitvoeren totdat een probleem is opgelost.

Documentatie voor inhoudsmaker

U hebt meer waarde afgeleid van uw controleoplossing door gebruiks- en acceptatieanalyses te bieden aan andere teams in de hele organisatie (waarbij beveiliging op rijniveau wordt afgedwongen, indien nodig).

Documentatie voor inhoudsmaker is gericht op selfservice-makers van inhoud die rapporten en gegevensmodellen maken die de gecureerde controlegegevens genereren. Het bevat informatie over het gegevensmodel, inclusief algemene gegevensdefinities.

Controlelijst : bij het plannen van documentatie en ondersteuning voor uw controleoplossing zijn belangrijke beslissingen en acties:

  • Controleer wie de oplossing moet ondersteunen: bepaal wie controleoplossingen ondersteunt die als productieniveau worden beschouwd (of downstreamrapportafhankelijkheden hebben).
  • Zorg ervoor dat het ondersteuningsteam gereed is: controleer of het ondersteuningsteam is voorbereid om de controleoplossing te ondersteunen. Bepaal of er hiaten in de gereedheid zijn die moeten worden aangepakt.
  • Zorg voor crosstraining: Voer kennisoverdrachtsessies of crosstrainingssessies uit voor het ondersteuningsteam.
  • Verhelder de verwachtingen van het ondersteuningsteam: zorg ervoor dat de verwachtingen voor reactie en oplossing duidelijk worden gedocumenteerd en gecommuniceerd. Bepaal of iemand in gesprek moet zijn om snel problemen met betrekking tot de controleoplossing op te lossen.
  • Technische documentatie maken: Maak documentatie over de technische architectuur en ontwerpbeslissingen.
  • Ondersteuningsdocumentatie maken: Werk de knowledgebase van de helpdesk bij om informatie over de ondersteuning van de oplossing op te nemen.
  • Documentatie maken voor makers van inhoud: maak documentatie om selfservicemakers te helpen het gegevensmodel te gebruiken. Beschrijf algemene gegevensdefinities om de consistentie van hun gebruik te verbeteren.

Waarschuwingen inschakelen

Mogelijk wilt u waarschuwingen genereren op basis van specifieke voorwaarden in de controlegegevens. U kunt bijvoorbeeld een waarschuwing genereren wanneer iemand een gateway verwijdert of wanneer een Power BI-beheerder een tenantinstelling wijzigt.

Zie Bewaking op tenantniveau voor meer informatie.

Doorlopend beheer

U moet doorlopend beheer uitvoeren van de volledige controleoplossing. Mogelijk moet u uw controleoplossing uitbreiden of wijzigen wanneer:

  • De organisatie detecteert nieuwe gegevensvereisten.
  • Nieuwe controlegebeurtenissen worden weergegeven in de onbewerkte gegevens die u exact uit de Rest API's van Power BI gebruikt.
  • Microsoft brengt wijzigingen aan in de Power BI REST API's.
  • Werknemers identificeren manieren om de oplossing te verbeteren.

Belangrijk

Belangrijke wijzigingen zijn zeldzaam, maar ze kunnen zich voordoen. Het is belangrijk dat u iemand hebt die snel problemen kan oplossen of de controleoplossing zo nodig kan bijwerken.

Controlelijst : bij het plannen van doorlopend beheer van de controleoplossing zijn belangrijke beslissingen en acties:

  • Wijs een technische eigenaar toe: Zorg ervoor dat er duidelijk eigendom en verantwoordelijkheid is voor de volledige controleoplossing.
  • Controleer of er een back-up bestaat: zorg ervoor dat er een technische eigenaar van een back-up is die betrokken kan worden als er een urgent probleem optreedt dat ondersteuning niet kan oplossen.
  • Houd een traceringssysteem bij: Zorg ervoor dat u een manier hebt om nieuwe aanvragen vast te leggen en een manier om prioriteit te geven aan onmiddellijke prioriteiten, en ook prioriteiten op de korte, middellange en lange termijn (achterstand).

Gerelateerde inhoud

In het volgende artikel in deze reeks vindt u meer informatie over bewaking op tenantniveau.