Power BI:n käyttöönoton suunnittelu: vuokraajatason valvonta

Muistiinpano

Tämä artikkeli on osa Power BI:n käyttöönoton suunnittelun artikkelisarjaa. Tässä sarjassa keskitytään ensisijaisesti Microsoft Fabricin Power BI -kokemukseen. Johdanto sarjaan on artikkelissa Power BI:n käyttöönoton suunnittelu.

Tämä vuokraajatason valvonnan suunnittelua koskeva artikkeli on tarkoitettu ensisijaisesti seuraaville:

• Power BI -järjestelmänvalvojat: Järjestelmänvalvojat, jotka vastaavat Power BI:n valvonnasta organisaatiossa. Power BI -järjestelmänvalvojien on ehkä tehtävä yhteistyötä IT-, suojaus- ja sisäisen tarkastuksen ja muiden asiaankuuluvien tiimien kanssa.
• Center of Excellence, IT ja BI-tiimi: Tiimit, jotka vastaavat myös Power BI:n valvonnasta. Heidän on ehkä tehtävä yhteistyötä Power BI -järjestelmänvalvojien ja muiden asiaankuuluvien tiimien kanssa.

Tärkeä

Suosittelemme, että seuraat tarkasti Power BI:n julkaisusuunnitelmaa saadaksesi tietoa valvonta- ja valvontaominaisuuksien tulevista parannuksista.

Vuokraajatason valvontaratkaisun tarkoituksena on tallentaa ja analysoida kaikkien Power BI -vuokraajaan käyttöön otettujen käyttäjien, toimintojen ja ratkaisujen tietoja. Nämä vuokraajatason valvontatiedot ovat arvokkaita moniin tarkoituksiin, joten voit analysoida käyttöönottotoimia, ymmärtää käyttömalleja, valistaa käyttäjiä, tukea käyttäjiä, vähentää riskejä, parantaa vaatimustenmukaisuutta, hallita käyttöoikeuskustannuksia ja valvoa suorituskykyä.

Turvallisen ja tuotantovalmiin päästä päähän -valvontaratkaisun luominen on merkittävä, aikaa vievä projekti. Ajattele sitä liiketoimintatiedon kehittämiseksi liiketoimintatiedon hallinnan (BI on BI) avulla. Jos haluat lisätietoja siitä, miksi valvontatiedot ovat niin arvokkaita, tutustu valvonnan ja seurannan yleiskatsaukseen.

Raporttitason valvonta, joka on suunnattu raporttien tekijöille, on artikkelissa Raporttitason valvonta.

Tietoresurssien valvonta, joka on suunnattu tietojen luojille, on kohdassa Tietotason valvonta.

Tämän artikkelin loppuosassa keskitytään vuokraajatason valvontaan.

Vihje

Tämän artikkelin ensisijaisena painopisteenä on auttaa sinua luomaan päästä päähän -valvontaratkaisun. Koska tämän artikkelin sisältö on järjestetty neljään vaiheeseen, tarvitset tietoja useissa vaiheissa. Vaiheessa 1 on esimerkiksi tietoja palvelun päänimen käytön suunnittelusta ja vaiheen 2 tiedoista edellytyksistä ja määrityksestä.

Siksi suosittelemme, että luet ensin tämän koko artikkelin, jotta saat perehdytykseen. Sen jälkeen sinun tulee olla hyvin valmistautunut valvontaratkaisusi suunnitteluun ja rakentamiseen toistuvalla tavalla.

Kun aiot luoda vuokraajatason valvontaratkaisun, aiot käyttää aikaa seuraavissa neljässä vaiheessa.

• Vaihe 1: Suunnittelu ja päätökset
  • Vaatimukset ja prioriteetit
  • Tietojen tarpeet
  • Valvontaratkaisun tyyppi
  • Käyttöoikeudet ja vastuut
  • Tekniset päätökset
  • Tietolähdepäätökset
• Vaihe 2: Edellytykset ja määritys
  • Tallennustilin luominen
  • Asentaa ohjelmistoja ja määrittää palveluita
  • Microsoft Entra -sovelluksen rekisteröinti
  • Power BI -vuokraajan asetusten määrittäminen
• Vaihe 3: Ratkaisun kehittäminen ja analysointi
  • Raakatietojen poimiminen ja tallentaminen
  • Koostettujen tietojen luominen
  • Tietomallin luominen
  • Paranna tietomallia
  • Analyysiraporttien luominen
  • Tee tietoihin perustuva toiminto
• Vaihe 4: Ylläpidä, paranna ja valvo
  • Toiminnallinen toiminta ja parannus
  • Dokumentaatio ja tuki
  • Ota ilmoitukset käyttöön
  • Jatkuva hallinta

Vaihe 1: Suunnittelu ja päätökset

Ensimmäisessä vaiheessa keskitytään suunnitteluun ja päätöksentekoon. Huomioi monia vaatimuksia ja prioriteetteja, joten suosittelemme, että käytät riittävästi aikaa tässä osiossa esitettyjen aiheiden ymmärtämiseen. Tavoitteena on tehdä hyviä alkupäätöksiä, jotta jatkovaiheet sujuvat ongelmitta.

Vaatimukset ja prioriteetit

Alkuvaiheessa tavoitteena on tunnistaa, mikä on tärkeintä. Keskity siihen, mikä on tärkeintä ja miten mittaat vaikutusta organisaatiossasi. Pyri määrittämään liiketoimintaan suuntautuneita vaatimuksia teknologiakeskeisten vaatimusten sijaan.

Seuraavassa on joitakin kysymyksiä, joihin sinun kannattaa vastata.

• Mihin tärkeisiin kysymyksiin sinun on vastattava? Voit tarkastella paljon valvontatietoja. Tehokkain tapa lähestyä valvontaa on keskittyä vastaamaan tiettyihin kysymyksiin.
• Mitkä ovat omaksumisen ja tietokulttuurin tavoitteet? Sinulla voi olla esimerkiksi tavoite lisätä omatoimisen BI-sisällöntuottajien määrää organisaatiossa. Tässä tapauksessa sinun on mitattava käyttäjien toimia, jotka liittyvät sisällön luomiseen, muokkaamiseen ja julkaisemiseen.
• Mitä välittömiä riskejä on? Saatat esimerkiksi tietää, että aiemmin on tapahtunut sisällön ylijakamista. Käyttäjien koulutusta on sittemmin parannettu, ja haluat nyt jatkuvasti valvoa suojausasetuksia ja -toimintoja.
• Onko olemassa nykyisiä suorituskykyilmaisimia tai organisaation tavoitteita? Sinulla voi olla esimerkiksi organisaation suorituskykyilmaisin, joka liittyy digitaaliseen muuntamiseen tai tietopohjaisemmaksi organisaatioksi ryhtymiseen. Vuokraajatason valvontatietojen avulla voit mitata, onko Power BI -toteutus linjassa näiden tavoitteiden kanssa.

Vihje

Tarkista valvontavaatimukset ja määritä prioriteetit yrityssponsorina ja Center of Excellencessä. On houkuttelevaa poimia valvontatiedot ja aloittaa raporttien luominen monien kiinnostavien tietojen perusteella. On kuitenkin epätodennäköistä, että saat suurta arvoa valvontaratkaisustasi, jos siihen ei johdu kysymyksiin, joihin sinun on vastattava, ja toimintoihin, joihin aiot ryhtyä.

Lisätietoja tavoista, joilla voit käyttää valvontatietoja, on artikkelissa Valvonnan ja seurannan yleiskatsaus.

Tarkistusluettelo – Kun tunnistetaan vaatimuksia ja prioriteetteja, keskeiset päätökset ja toiminnot ovat seuraavat:

• Tunnista vaatimukset: Kerää ja dokumentoi Tärkeimmät liiketoimintavaatimukset Power BI -vuokraajasi valvonnan kannalta.
• Priorisoi vaatimukset: Aseta vaatimusten prioriteetit luokittelemalla ne välittömiksi, lyhytkestoisiksi, keskipitkällä ja pitkällä aikavälillä (keskeneräisiksi).
• Tee suunnitelma välittömiä prioriteetteja varten: Luo suunnitelma tietojen keräämisen aloittamiseksi niin, että se on käytettävissä tarvittaessa.
• Vaatimusten uudelleenarviointi säännöllisesti: Luo suunnitelma vaatimusten arvioimiseksi uudelleen säännöllisin väliajoin (esimerkiksi kahdesti vuodessa). Tarkista, täyttääkö valvonta- ja valvontaratkaisut ilmoitetut vaatimukset. Päivitä suunnitelmasi toimintokohteet tarpeen mukaan.

Tietojen tarpeet

Kun olet määrittänyt vaatimukset ja prioriteetit (kuvattu aiemmin), olet valmis tunnistamaan tarvitsemasi tiedot. Tässä osiossa käsitellään neljää tietoluokkaa.

• Käyttäjän toimintatiedot
• Vuokraajavarasto
• Käyttäjien ja ryhmien tiedot
• Suojaustiedot

Suurin osa tarvitsemasi tiedot ovat peräisin järjestelmänvalvojan ohjelmointirajapinnoista, jotka tarjoavat paljon metatietoja Power BI -vuokraajasta. Lisätietoja on jäljempänä tässä artikkelissa kohdassa Käyttäjän ohjelmointirajapinnan tai järjestelmänvalvojan ohjelmointirajapinnan valitseminen.

Käyttäjän toimintatiedot

Priorisointisi tulee antaa käyttäjien toimia koskevien tietojen saamiseksi. Käyttäjän toiminnoista, joita kutsutaan myös tapahtumiksi tai toiminnoiksi, on hyötyä monenlaisissa tarkoituksissa.

Näitä tietoja kutsutaan useimmiten toimintolokiksi tai tapahtumalokiksi. Teknisesti on useita tapoja hankkia käyttäjän toimintatietoja (toimintoloki on yksi menetelmä). Katso lisätietoja siihen liittyvistä päätöksistä ja toiminnoista tämän artikkelin myöhemmästä kohdasta Käyttäjien toimintatietojen käyttäminen.

Seuraavassa on joitakin yleisiä kysymyksiä, joihin käyttäjien toiminnan tiedot voivat vastata.

• Huippukäyttäjien ja suosituimman sisällön etsiminen
  • Mitä sisältöä katsellaan useimmiten ja ketkä käyttäjät tarkastelevat sitä?
  • Mitä ovat sisällön tarkastelun päivittäiset, viikoittaiset ja kuukausittaiset trendit?
  • Ovatko raportin tarkastelut trendikkäitä ylös- vai alaspäin?
  • Kuinka moni käyttäjä on aktiivinen?
• Käyttäjän toiminnan ymmärtäminen
  • Mitä suojaustyyppiä käytetään useimmiten (sovellukset, työtilat tai kohdekohtainen jakaminen)?
  • Käyttävätkö käyttäjät useimmiten selaimia tai mobiilisovelluksia?
  • Ketkä sisällöntekijät julkaisevat ja päivittävät sisältöä aktiivisimmin?
  • Mitä sisältöä julkaistaan tai päivitetään, milloin ja mitkä käyttäjät?
• Käyttäjien koulutusmahdollisuuksien tunnistaminen
  • Kuka jakaa (liikaa) omasta työtilastaan?
  • Kuka vie huomattavan määrän vientiä?
  • Kuka lataa sisältöä säännöllisesti?
  • Kuka julkaisee monia uusia semanttisia malleja, joita kutsutaan aiemmin tietojoukoiksi?
  • Kuka käyttää tilauksia raskaasti?
• Hallinnon ja vaatimustenmukaisuuden parantaminen
  • Milloin vuokraajan asetuksia muutetaan ja millä Power BI -järjestelmänvalvojalla?
  • Kuka aloitti Power BI -kokeilun?
  • Mitä sisältöä ulkoiset käyttäjät käyttävät, kuka, milloin ja miten?
  • Kuka on lisännyt tai päivittänyt luottamuksellisuustunnisteen?
  • Mikä prosenttiosuus raportin näkymistä perustuu sertifioituihin semanttisiin malleihin?
  • Mikä prosenttiosuus semanttisista malleista tukee useampaa kuin yhtä raporttia?
  • Milloin yhdyskäytävä tai tietolähde luodaan tai päivitetään ja kuka käyttäjä sen luo?

Lisätietoja näiden tietojen käyttötavoista on kohdassa Tutustu käyttömalleihin.

Tärkeä

Jos et vielä poimi ja tallenna käyttäjien toimia koskevia tietoja, aseta se kiireelliseksi prioriteetiksi. Varmista vähintään, että poimit raakatiedot ja tallennat ne turvalliseen sijaintiin. Näin tiedot ovat käytettävissä, kun olet valmis analysoimaan niitä. Historia on käytettävissä 30 päivää tai 90 päivää käyttämäsi lähteen mukaan.

Katso lisätietoja kohdasta Käyttäjien toimintatietojen käyttäminen alempana tässä artikkelissa.

Vuokraajavarasto

Toinen prioriteetti on usein tietojen noutaminen vuokraajavaraston luomista varten. Joskus sitä kutsutaan työtilan varastoksi, työtilan metatietoiksi tai vuokraajan metatiiksi.

Vuokraajavarasto on tilannevedos tietyllä hetkellä. Siinä kuvataan, mitä vuokraajassa julkaistaan. Vuokraajavarasto ei sisällä todellisia tietoja tai todellisia raportteja. Sen sijaan metatiedot kuvaavat kaikkia työtiloja ja niiden kohteita (kuten semanttisia malleja ja raportteja).

Seuraavassa on joitakin yleisiä kysymyksiä, joihin vuokraajavarastoon voidaan vastata.

• Opit ymmärtämään, kuinka paljon sisältöä sinulla on ja missä
  • Missä työtiloissa on eniten sisältöä?
  • Millaista sisältöä kussakin työtilassa julkaistaan (etenkin erotettaessa raporttityötiloja ja tietotyötiloja)?
  • Mitä riippuvuuksia kohteiden välillä on (kuten useita semanttisia malleja tukevat tietovuot tai semanttinen malli, joka on muiden yhdistelmämallien lähde)?
  • Mikä tietojen historiatiedot ovat (Power BI -kohteiden väliset riippuvuudet, mukaan lukien ulkoiset tietolähteet)?
  • Onko orpoja raportteja (jotka ovat yhteydessä niiden semanttiseen malliin)?
• Semanttisten mallien ja raporttien välisen suhteen ymmärtäminen
  • Kuinka paljon semanttista mallia käytetään uudelleen?
  • Onko siinä kaksoiskappaleita tai erittäin samankaltaisia semanttisia malleja?
  • Onko mahdollisuuksia semanttisten mallien yhdistämiseen?
• Tutustu ajanvälisten pisteiden trendeihin
  • Kasvaako raporttien määrä ajan mittaan?
  • Kasvaako semanttisten mallien määrä ajan kuluessa?
• Käyttämättömän sisällön etsiminen
  • Mitä raportteja ei käytetä (tai ovatko ne vajaakäyttöisiä)?
  • Mitä semanttisia malleja ei käytetä (tai käytetäänkö niitä heikosti)?
  • Onko mahdollista poistaa sisältö käytöstä?

Vuokraajavaraston avulla voit käyttää nykyisiä nimiä historiatoimintoja analysoitaessa. Vuokraajasi kohteiden tilannevedos sisältää kaikkien kohteiden nimet kyseisellä hetkellä. On hyödyllistä käyttää nykyisten kohteiden nimiä historialliseen raportointiin. Jos esimerkiksi raportti nimettiin uudelleen kolme kuukautta sitten, kyseisenä ajankohtana toimintolokiin kirjataan vanha raportin nimi. Kun tietomalli on oikein määritetty, voit käyttää uusinta vuokraajaluetteloa paikantaaksesi kohteen sen nykyisen nimen perusteella (sen entisen nimen sijaan). Lisätietoja on tämän artikkelin kohdassa Tietomallin luominen.

Lisätietoja vuokraajan varaston käyttötavoista on kohdassa Tutustu julkaistuun sisältöön.

Vihje

Kokonaiskuvan tuottamiseen käytetään usein käyttäjän toimintotapahtumia (kuvattu edellisessä osiossa) ja vuokraajavarastoa. Tällä tavalla voit parantaa kaikkien tietojen arvoa.

Koska vuokraajavarasto on tilannevedos tietyllä hetkellä, sinun on päätettävä, kuinka usein haluat poimia ja tallentaa metatiedot. Viikoittainen tilannevedos on hyödyllinen kahden pisteen välisen vertailun tekemisessä. Jos esimerkiksi haluat tutkia työtilan suojausasetuksia, tarvitset edellisen vuokraajavaraston tilannevedoksen, toimintolokitapahtumat ja nykyisen vuokraajavaraston tilannevedoksen.

Vuokraajavaraston luomiseen on kaksi pääasiallista tapaa. Lisätietoja siihen liittyvistä päätöksistä ja toiminnoista on tämän artikkelin kohdassa Vuokraajien varastotietojen käyttäminen.

Käyttäjien ja ryhmien tiedot

Analyyttisten tarpeiden kasvaessa päätät todennäköisesti, että haluat sisällyttää käyttäjiä ja ryhmiä koskevia tietoja päästä päähän -valvontaratkaisuusi. Tietojen noutamiseen voit käyttää Microsoft Graphia, joka on kelvollinen lähde microsoft Entra -tunnuksen (aiemmin Azure Active Directory) käyttäjiä ja ryhmiä koskeviin tietoihin.

Power BI REST -ohjelmointirajapinnoista noudetuissa tiedoissa on käyttäjän sähköpostiosoite tai käyttöoikeusryhmän nimi. Nämä tiedot ovat tilannevedoksia tietyllä hetkellä.

Seuraavassa on joitakin yleisiä kysymyksiä, joihin Microsoft Graph voi vastata.

• Käyttäjien ja ryhmien tunnistaminen
  • Mikä on koko käyttäjänimi (sähköpostiosoitteen lisäksi), osasto tai sijainti, joka on hankittu hänen käyttäjäprofiilistaan?
  • Ketkä ovat käyttöoikeusryhmän jäseniä?
  • Kuka on käyttöoikeusryhmän omistaja (jäsenten hallintaa varten)?
• Käyttäjätietojen hankkiminen
  • Mitkä käyttöoikeudet – Power BI Pro tai käyttäjäkohtainen Power BI Premium (PPU) on määritetty käyttäjille?
  • Ketkä käyttäjät kirjautuvat sisään useimmin ?
  • Ketkä käyttäjät eivät ole kirjautuneet Power BI teenus viime aikoina?

Varoitus

Jotkin vanhemmat menetelmät (joita dokumentoidaan laajalti verkossa) käyttäjien ja ryhmien tietojen käyttämiseksi ovat vanhentuneita, eikä niitä tule käyttää. Käytä Microsoft Graphia käyttäjien ja ryhmien tietojen valtuuttajana lähteenä aina kun se on mahdollista.

Lisätietoja ja suosituksia tietojen käyttämiseen Microsoft Graphista on jäljempänä tässä artikkelissa kohdassa Käyttäjien ja ryhmien tietojen käyttäminen.

Suojaustiedot

Sinun täytyy ehkä suorittaa säännöllisiä suojaustarkastuksia.

Seuraavassa on joitakin yleisiä kysymyksiä, joihin Power BI REST -ohjelmointirajapinnat voivat vastata.

• Tunnista henkilöt ja sovellukset
  • Mihin raportteihin käyttäjällä, ryhmällä tai palvelun päänimellä on käyttöoikeus?
  • Ketkä käyttäjät, ryhmät tai palvelun päänimet ovat tilaajia, jotka saavat sähköpostitilauksella varustettuja raportteja?
• Sisällön käyttöoikeuksien ymmärtäminen
  • Mitkä työtilaroolit määritetään kullekin käyttäjälle tai ryhmälle?
  • Ketkä käyttäjät ja ryhmät määritetään kullekin Power BI -sovelluksen kohderyhmälle?
  • Mitkä kohdekohtaiset käyttöoikeudet on määritetty, mihin raportteihin ja mille käyttäjille?
  • Mitkä kohdekohtaiset käyttöoikeudet on määritetty, mille semanttisille malleille ja kummallekin käyttäjälle?
  • Mihin semanttisiin malleihin ja tietomalleihin on määritetty rivitason suojaus (RLS)?
  • Mitä kohteita jaetaan koko organisaation käyttäjille?
  • Mitkä kohteet julkaistaan julkisesti Internetissä?
• Tutustu muihin käyttöoikeuksiin
  • Kenellä on oikeus julkaista käyttöönottoputken avulla?
  • Kenellä on oikeus hallita yhdyskäytäviä ja tietoyhteyksiä?
  • Kenellä on Premium-kapasiteetin hallintaoikeus?

Tärkeä

Joskus tämä artikkeli viittaa Power BI Premiumiin tai sen kapasiteettitilauksiin (P-varastointiyksiköt). Ota huomioon, että Microsoft vahvistaa parhaillaan ostovaihtoehtoja ja poistaa käytöstä Kapasiteettikohtaisen Power BI Premiumin. Uusien ja nykyisten asiakkaiden kannattaa harkita Fabric-kapasiteettitilausten (F-varastointiyksiköiden) ostamista.

Lisätietoja on artikkelissa Power BI Premium -käyttöoikeuksien tärkeä päivitys ja Power BI Premiumin usein kysytyt kysymykset.

Vihje

Lisätietoja suojauksesta on suojauksen suunnittelun artikkeleissa.

Yleiset kysymykset eivät ole tyhjentävä luettelo. Saatavilla on monenlaisia Power BI REST -ohjelmointirajapintoja. Lisätietoja on artikkelissa Power BI REST -ohjelmointirajapintojen käyttäminen.

Lisätietoja järjestelmänvalvojan ohjelmointirajapintojen käyttämisestä verrattuna käyttäjien ohjelmointirajapintoihin (mukaan lukien sen vaikutus tietoihin poimivan käyttäjän käyttöoikeuksiin) on jäljempänä tässä artikkelissa olevassa kohdassa Käyttäjän ohjelmointirajapinnan tai järjestelmänvalvojan ohjelmointirajapinnan valitseminen.

Tarkistusluettelo – Tarkastukseen tarvittavia tietoja määritettäessä tärkeimmät päätökset ja toiminnot ovat seuraavat:

• Tunnista käyttäjän toimintatietojen tietyt tietotarpeet: Vahvista keräämäsi vaatimukset. Selvitä, mitkä valvontatiedot ovat välttämättömiä kunkin käyttäjän toimintatietoa koskevan vaatimuksen täyttämiseksi.
• Määritä vuokraajan varastotietojen tarkat tietotarpeet: Vahvista keräämäsi vaatimukset. Määritä, mitä valvontatietoja tarvitaan vuokraajaluettelon kääntämiseen.
• Tunnista käyttäjien ja ryhmien tietojen tarkat tietotarpeet: Vahvista keräämäsi vaatimukset. Selvitä, mitä valvontatietoja tarvitaan kunkin käyttäjien ja ryhmien tietoja koskevan vaatimuksen täyttämiseksi.
• Tunnista tietyt suojaustietojen tietotarpeet: Vahvista keräämäsi vaatimukset. Selvitä, mitkä valvontatiedot ovat välttämättömiä kunkin suojaustietovaatimuksen täyttämiseksi.
• Tarkista prioriteetit: Tarkista prioriteettien järjestys, jotta tiedät, mitä sinun pitää kehittää ensin.
• Päätä, kuinka usein toimintoja siepataan: Päätä, kuinka usein toimintotapahtumat kerätään (esimerkiksi kerran päivässä).
• Päätä, kuinka usein tilannevedoksia siepataan: Päätä, mikä aikaväli tilannevedostiedot, kuten vuokraajavarasto, tai käyttäjät ja ryhmät, tallennetaan.

Valvontaratkaisun tyyppi

Vuokraajatason valvonta suoritetaan joko manuaalisesti tai automatisoiduilla prosesseilla.

Useimmat uudet valvontaprosessit alkavat manuaalisina prosesseina erityisesti kehityksen aikana ja testauksen aikana. Manuaalinen valvontaprosessi voi muuttua automatisoiduksi prosessiksi. Kaikkien valvontaprosessien ei kuitenkaan tarvitse olla täysin automatisoituja.

Manuaaliset valvontaprosessit

Manuaalinen valvonta käyttää komentosarjoja ja prosesseja, jotka käyttäjä suorittaa pyynnöstä (yleensä Power BI -järjestelmänvalvoja). Tarvittaessa käyttäjä suorittaa kyselyjä vuorovaikutteisesti valvontatietojen noutamista varten.

Manuaalinen valvonta sopii parhaiten seuraaviin:

• Uudet kehitetyt ja testattavat komentosarjat.
• Satunnaisen ja kertaluonteisen valvonnan tarpeet.
• Valmistelevien tarkastusten tarpeet.
• Ne eivät edellytä täyttä tukea.

Automaattiset valvontaprosessit

Toistuvasti tarvittavien tietojen valvonta tulee automatisoida. Se poimitaan ja käsitellään tavallisen aikataulun mukaisesti, ja sitä kutsutaan automatisoiduksi prosessiksi. Joskus sitä kutsutaan valvomattomaksi prosessiksi.

Automatisoidun prosessin tavoitteena on vähentää manuaalista työtä, vähentää virheriskiä, lisätä johdonmukaisuutta ja poistaa riippuvuus yksittäisestä käyttäjästä.

Automaattinen valvonta sopii parhaiten seuraaviin:

• Tuotannossa suoritettavien prosessien valvonta.
• Valvomattomat prosessit, jotka suoritetaan tavallisen aikataulun mukaisesti.
• Komentosarjat, jotka on testattu täysin.
• Olennaiset valvontaprosessit, joilla on muita raportteja (tai muita prosesseja), jotka riippuvat siitä tietolähteenä.
• Valvotaan prosesseja, jotka on dokumentoitu ja joita tuetaan.

Prosessin tyyppi – manuaalinen tai automaattinen – voi vaikuttaa todentamisen käsittelyyn. Power BI -järjestelmänvalvoja voi esimerkiksi käyttää käyttäjätodennusta manuaalisessa valvontaprosessissa mutta käyttää palvelun päänimeä automatisoidussa prosessissa. Lisätietoja on tämän artikkelin kohdassa Todennusmenetelmän määrittäminen.

Vihje

Jos käytössä on säännöllinen ja toistuva tarve hankkia manuaalisesti käsiteltäviä valvontatietoja, harkitse investointiaikaa niiden automatisointeihin. Jos Esimerkiksi Power BI -järjestelmänvalvoja suorittaa joka päivä komentosarjan tietojen noutamiseksi Power BI:n toimintolokista, puuttuvien tietojen riski on, jos henkilö on sairas tai poissa lomalla.

Tarkistusluettelo – Tarkasteltaessa kehitettävää valvontaratkaisua tärkeimmät päätökset ja toiminnot ovat seuraavat:

• Määritä kunkin uuden valvontavaatimuksen ensisijainen tarkoitus: Päätä, käytetäänkö manuaalista vai automaattista prosessia jokaiselle uudelle vaatimukselle. Harkitse, onko päätös tilapäinen vai pysyvä.
• Luo suunnitelma automatisointia varten: Kun se soveltuu tietylle valvontavaatimukselle, luo suunnitelma sen automatisoimiseksi, milloin ja kuka sitä käyttää.

Käyttöoikeudet ja vastuut

Tässä vaiheessa sinulla pitäisi olla selkeä käsitys siitä, mitä haluat saavuttaa ja mitä tietoja tarvitset aluksi. Nyt on hyvä aika tehdä käyttöoikeuksia sekä rooleja ja vastuita koskevia päätöksiä.

Käyttäjien käyttöoikeudet

Kun aiot luoda päästä päähän -valvontaratkaisun, harkitse muiden käyttäjien käyttöoikeuksia, joiden on käytettävä tietoja. Päätä tarkemmin, ketkä saavat käyttää ja tarkastella valvontatietoja.

Seuraavassa on huomioitavia seikkoja.

Valvontatietojen suora käyttö

Päätä suoraan, ketkä voivat käyttää valvontatietoja. Voit ajatella sitä useilla tavoilla.

• Kenen pitäisi olla Power BI -järjestelmänvalvoja? Power BI -järjestelmänvalvoja voi käyttää kaikkia vuokraajan metatietoja, mukaan lukien järjestelmänvalvojan ohjelmointirajapintoja. Lisätietoja siitä, kuka päättää, kuka voi olla Power BI -järjestelmänvalvoja, on artikkelissa Vuokraajatason suojauksen suunnittelu.
• Kuka voi käyttää olemassa olevaa palvelun päänimeä? Jos haluat käyttää valvontatietojen käyttöön palvelun päänimeä (käyttöoikeuksien sijaan), valtuutetuille käyttäjille on annettava salauskoodi, jotta he voivat suorittaa salasanapohjaisen todennuksen. Salaisten koodien (ja avainten) käyttöä tulisi hallita hyvin tiukasti.
• Pitääkö pääsyä hallita tiukasti? Tiettyjen teollisuudenalojen, joilla on sääntely- ja yhteensopivuusvaatimuksia, on valvottava käyttöä tiukemmin kuin muilla toimialoilla.
• Onko aktiviteettitietomääriä suuria? Ohjelmointirajapinnan rajoittamisrajoitusten ylittämisen välttämiseksi sinun on ehkä valvottava tiukasti sitä, ketkä saavat käyttää suoraan valvontatietoja tuottavia ohjelmointirajapintoja. Tässä tapauksessa on hyödyllistä varmistaa, että päällekkäisiä tai päällekkäisiä ponnisteluja ei ole.

Käyttö poimittuihin raakatietoihin

Päätä, kuka voi tarkastella raakatietoja, jotka on poimittu ja kirjoitettu tallennussijaintiin. Yleensä raakatietojen käyttö on rajoitettu järjestelmänvalvojille ja auditoijille. Center of Excellence (COE) saattaa myös edellyttää käyttöoikeutta. Lisätietoja on tämän artikkelin kohdassa Määritä valvontatietojen tallennuspaikka.

Käytettävissä olevien analyyttisten tietojen käyttö

Päätä, kuka voi tarkastella koostettuja ja muunnettuja tietoja, jotka ovat valmiita analysoitaville. Nämä tiedot tulee aina antaa järjestelmänvalvojien ja auditoijien saataville. Joskus tietomalli tuodaan organisaation muiden käyttäjien saataville, erityisesti kun luot rivitason suojauksen sisältävän Power BI -semanttisen mallin. Lisätietoja on tämän artikkelin kohdassa Suunnitelma koostettujen tietojen luomiseksi.

Roolit ja velvollisuudet

Kun olet päättänyt, miten käyttöoikeudet toimivat, voit alkaa miettiä rooleja ja vastuita. Suosittelemme, että otat mukaan oikeat henkilöt varhaisessa vaiheessa, erityisesti silloin, kun useita kehittäjiä tai tiimejä osallistuu päästä päähän -valvontaratkaisun rakentamiseen.

Päätä, ketkä käyttäjät tai tiimi vastaavat seuraavista toimista.

Rooli	Vastuutyypit	Roolin suorittaa yleensä
Viestintä sidosryhmille	Viestintätoiminnot ja vaatimusten kerääminen.	COE yhteistyössä IT:n kanssa. Se voi sisältää myös valittuja henkilöitä tärkeistä liiketoimintayksiköistä.
Päätä prioriteeteista ja anna ohjeita vaatimuksiin	Päästä päähän -valvontaratkaisuun liittyvät päätöksentekotoimet, mukaan lukien vaatimusten täyttäminen.	Tiimi, joka valvoo Power BI:tä organisaatiossa, kuten COE. Yrityssponsori tai tietohallinnon ohjauskomitea voi osallistua kriittisten päätösten tekemiseen tai ongelmien kärjistymiseen.
Raakatietojen poimiminen ja tallentaminen	Komentosarjojen ja prosessien luominen tietojen käyttöä ja purkamista varten. Sisältää myös raakatietojen kirjoittamisen tallennustilaan.	Tietotekniikan henkilöstö, tavallisesti IT-alalle kuuluva henkilö ja yhteistyössä COE:n kanssa.
Koostettujen tietojen luominen	Tietojen puhdistaminen, muuntaminen ja koostettujen tietojen luominen tähtirakenteessa.	Tietotekniikan henkilöstö, tavallisesti IT-alalle kuuluva henkilö ja yhteistyössä COE:n kanssa.
Tietomallin luominen	Analyyttisen tietomallin luominen kootun tiedon perusteella.	Power BI -sisällöntekijät), yleensä IT-palvelussa tai COE:ssä.
Analytiikkaraporttien luominen	Koostettujen tietojen analysointia varten luotujen raporttien luominen. Raporttien jatkuvat muutokset uusien vaatimusten perusteella ja sen jälkeen, kun uusia valvontatietoja tulee saataville.	Power BI -raporttien luojat, yleensä IT- tai COE-ympäristössä.
Tietojen analysointi ja tulosten perusteella toimiminen	Analysoi tiedot ja toimi vastauksena valvontatietoihin.	Tiimi, joka valvoo Power BI:tä organisaatiossa, yleensä COE. Muita ryhmiä voi olla myös valvontatulosten ja toiminnon mukaan. Muita tiimejä voivat olla suojaus, vaatimustenmukaisuus, juridinen hallinta, riskienhallinta tai muutosten hallinta.
Testaa ja vahvista	Testaa sen varmistamiseksi, että valvontavaatimukset täyttyvät ja että esitetyt tiedot ovat tarkkoja.	Power BI -sisällöntekijät yhdessä Power BI:tä organisaatiossa valvovan tiimin kanssa.
Tietojen suojaaminen	Määritä kunkin tallennuskerroksen suojaus ja hallitse sitä, mukaan lukien raakatiedot ja kootut tiedot. Hallitse tietojen analysointia varten luotujen semanttisten mallien käyttöoikeuksia.	Tiedot tallentavan järjestelmänvalvoja yhteistyössä organisaation Power BI:tä valvovan tiimin kanssa.
Aikataulutus ja automaatio	Ratkaisun toiminnallinen määrittäminen ja prosessin ajoittaminen haluamasi työkalun avulla.	Tietotekniikan henkilöstö, tavallisesti IT-alalle kuuluva henkilö ja yhteistyössä COE:n kanssa.
Ratkaisun tukeminen	Valvo valvontaratkaisua, mukaan lukien työn suoritukset, virheet ja tuki teknisissä ongelmissa.	Power BI -järjestelmätukea hoitavan tiimin, joka on yleensä IT- tai COE-tuki.

Monet edellä mainituista rooleista ja vastuista voidaan yhdistää, jos sama tiimi tai sama henkilö suorittaa ne. Power BI -järjestelmänvalvojasi saattavat esimerkiksi suorittaa joitakin näistä rooleista.

On myös mahdollista, että eri ihmiset suorittavat eri rooleja tilanteesta riippuen. Toimet ovat tilannekohtaisia valvontatietojen ja ehdotetun toimen mukaan.

Harkitse useita esimerkkejä.

• Esimerkki 1: Valvontatiedot osoittavat, että jotkin käyttäjät vievät tietoja usein Exceliin. Toiminto: COE ottaa yhteyttä tiettyihin käyttäjiin, jotta he ymmärtävät heidän tarpeensa ja opettavat heille parempia vaihtoehtoja.
• Esimerkki 2: Valvontatiedoissa näkyy, että ulkoisten käyttäjien käyttöoikeuksia tapahtuu odottamattomasti. Toiminnot: IT-järjestelmänvalvoja päivittää tarvittavat Microsoft Entra -tunnuksen asetukset ulkoisten käyttäjien käyttöoikeuksia varten. Power BI -järjestelmänvalvoja päivittää ulkoiseen käyttöön liittyvän vuokraaja-asetuksen. COE päivittää tietoturvaa hallitsevien sisällöntuottajien dokumentaation ja koulutuksen. Lisätietoja on artikkelissa Ulkoisten käyttäjien strategia.
• Esimerkki 3: Valvontatiedot osoittavat, että useat tietomallit määrittävät saman mittarin eri tavalla (käytettävissä metatietojen tarkistuksen ohjelmointirajapinnoista, jos ne on sallittu yksityiskohtaisissa metatietovuokraajan asetuksissa). Toteutetut toimet: Tietojen hallinnointikomitea käynnistää hankkeen yhteisten määritelmien määrittelemiseksi. COE päivittää dokumentaation ja koulutuksen tietomalleja luoville sisällöntekijöille. COE tekee myös yhteistyötä sisällöntuottajien kanssa mallien päivittämiseksi tarvittaessa. Lisätietoja yksityiskohtaisten metatietojen noutamisesta on tämän artikkelin kohdassa Vuokraajien varastotietojen käyttäminen.

Muistiinpano

Tietojen poimintaprosessien määrittäminen on yleensä kertatyötä, jossa tehdään satunnaisia parannuksia ja vianmääritystä. Tietojen analysointi ja toimiminen on jatkuvaa työtä, joka edellyttää jatkuvaa työtä toistuvasti.

Tarkistusluettelo – Kun harkitaan käyttöoikeuksia ja vastuita, tärkeimpiä päätöksiä ja toimintoja ovat seuraavat:

• Selvitä, mitkä tiimit osallistuvat: Selvitä, mitkä tiimit osallistuvat päästä päähän -valvontaratkaisun luomiseen ja tukeen.
• Päätä käyttäjien käyttöoikeudet: Määritä, miten käyttöoikeudet määritetään valvontatietojen käyttöä varten. Luo dokumentaatio tärkeimmistä päätöksistä myöhempää viittausta varten.
• Päätä rooleista ja vastuista: Varmista, että odotukset ovat selviä siitä, kuka tekee mitäkin, erityisesti silloin, kun mukana on useita tiimejä. Luo rooleille ja vastuille dokumentaatio, joka sisältää odotetut toimet.
• Roolien ja vastuiden määrittäminen: Määritä tietyt roolit ja vastuut tietyille henkilöille tai tiimeille. Päivitä tarvittaessa yksittäisten työkuvausten tiedot henkilöstöhallintojen avulla.
• Luo koulutussuunnitelma: Laadi suunnitelma henkilöstön kouluttamiseksi, kun he tarvitsevat uutta osaamista.
• Luo raporttien välinen suunnitelma: Varmista, että ristiinkoulutus ja varmuuskopiot ovat valmiina avainrooleille.

Tekniset päätökset

Kun suunnittelet vuokraajatason valvontaratkaisua, sinun on tehtävä tärkeitä teknisiä päätöksiä. Johdonmukaisuuden parantamiseksi, muokkauksen välttämiseksi ja suojauksen parantamiseksi suosittelemme, että teet nämä päätökset mahdollisimman aikaisin.

Ensimmäisessä suunnitteluvaiheessa tehdään seuraavat päätökset.

• Valvontatietojen käytön teknologian valitseminen
• Todennusmenetelmän määrittäminen
• Käyttäjän ohjelmointirajapinnan tai järjestelmänvalvojan ohjelmointirajapinnan valitseminen
• Valitse ohjelmointirajapinnat tai PowerShellin cmdlet-komennot.
• Määritä valvontatietojen tallennuspaikka
• Suunnitelma koostettujen tietojen luomiseksi

Valvontatietojen käytön teknologian valitseminen

Sinun on ensiksi päätettävä, miten voit käyttää valvontatietoja.

Helpoin tapa päästä alkuun on käyttää järjestelmänvalvojan valvontatyötilassa käytettävissä olevia valmiita raportteja.

Kun haluat käyttää tietoja suoraan ja luoda oman ratkaisusi, käytät ohjelmointirajapintaa (sovellusohjelman käyttöliittymä). Ohjelmointirajapinnat on suunniteltu tietojen vaihtamiseen Internetin kautta. Power BI REST -ohjelmointirajapinnat tukevat tietopyyntöjä HTTP-protokollan avulla. Mikä tahansa kieli tai työkalu voi käynnistää Power BI REST -ohjelmointirajapintoja, kun se pystyy lähettämään HTTP-pyynnön ja vastaanottamaan JSON-vastauksen.

Vihje

PowerShellin cmdlet-komennot käyttävät valvontatietoja Power BI REST -ohjelmointirajapintojen avulla. Lisätietoja on tämän artikkelin kohdassa Ohjelmointirajapintojen tai PowerShellin cmdlet-komentojen valitseminen.

Tässä osiossa keskitytään teknologiavaihtoehtoosi. Lisätietoja lähteestä tietyntyyppisten valvontatietojen käyttämiseen on jäljempänä tässä artikkelissa olevassa kohdassa Tietolähdepäätökset.

Käyttöympäristöasetukset

Valvontatietoja voi käyttää monella eri tavalla. Valitsemasi tekniikan perusteella saatat valita haluamasi kielen. Sinun on ehkä myös tehtävä tietty päätös siitä, miten komentosarjat suoritetaan. Teknologiat eroavat suuresti niiden oppimiskäyrässä ja helpottavat aloittamista.

Seuraavassa on joitakin tekniikoita, joiden avulla voit noutaa tietoja Power BI REST -ohjelmointirajapintojen avulla.

Tekniikka	Hyvä valinta manuaalisille valvontaprosesseille	Hyvä valinta automatisoituihin valvontaprosesseihin
Järjestelmänvalvojan valvontatyötila
Kokeile
PowerShell
Power BI Desktop
Power Automate
Ensisijainen Azure-palvelu
Ensisijainen työkalu/kieli
Microsoft Purview -valvontalokin haku
Defender for Cloud Apps
Microsoft Sentinel

Tämän osion loppuosa sisältää lyhyen esittelyn kaikista taulukossa esitetyistä vaihtoehdoista.

Järjestelmänvalvojan valvontatyötila

Järjestelmänvalvojan valvontatyötila sisältää Power BI teenus esimääritettyjä raportteja ja semanttisia malleja. Se on kätevä tapa Fabric-järjestelmänvalvojille ja yleisille järjestelmänvalvojille tarkastella viimeaikaisia valvontatietoja ja auttaa heitä ymmärtämään käyttäjien toimia.

Kokeile ohjelmointirajapinnan dokumentaatiossa

Try-it on vuorovaikutteinen työkalu, jonka avulla voit käyttää Power BI REST -ohjelmointirajapintaa suoraan Microsoftin dokumentaatiossa. Se on helppo tapa tutustua ohjelmointirajapintoihin, koska se ei edellytä muita työkaluja tai mitään määritystä tietokoneessasi.

Try-it-käytöllä voit tehdä seuraavaa:

• Lähetä pyyntö manuaalisesti ohjelmointirajapintaan sen määrittämiseksi, palauttaako se haluamasi tiedot.
• Lue ennen komentosarjan kirjoittamista, miten URL-osoite on muodostettu.
• Tarkista tiedot epävirallisesti.

Muistiinpano

Sinulla on oltava Power BI -käyttöoikeuden saanut ja todennettu käyttäjä, jotta voit käyttää Try-it-toimintoa. Se noudattaa vakiokäyttöoikeusmallia, mikä tarkoittaa sitä, että käyttäjän ohjelmointirajapinnat käyttävät käyttöoikeuksia ja järjestelmänvalvojan ohjelmointirajapinnat vaativat Power BI -järjestelmänvalvojan oikeudet. Try-it-toiminnon avulla ei voi suorittaa todennusta palvelun päänimen avulla.

Koska se on vuorovaikutteinen, Try-it soveltuu parhaiten oppimiseen, tarkasteluun ja uusiin manuaalisiin valvontaprosesseihin.

PowerShell ja Azure Cloud Shell

Voit luoda ja suorittaa PowerShell-komentosarjoja useilla tavoilla.

Seuraavassa on useita yleisiä vaihtoehtoja.

• Visual Studio Code: Nykyaikainen ja kevyt lähdekoodieditori. Se on vapaasti saatavilla oleva avoimen lähdekoodin työkalu, jota tuetaan useissa ympäristöissä, kuten Windowsissa, macOS:ssä ja Linuxissa. Voit käyttää Visual Studio Codea useilla kielillä, kuten PowerShellillä (PowerShell-laajennuksen avulla).
• Azure Data Studio: Työkalu komentosarjojen ja muistikirjojen luomiseen. Se perustuu Visual Studio Codeen. Azure Data Studio on käytettävissä itsenäisesti tai SQL Server Management Studion (SSMS) kanssa. Laajennuksia on useita, mukaan lukien PowerShellin laajennus.
• Azure Cloud Shell: Vaihtoehto powerShellin paikalliselle työskentelylle. Voit käyttää Azure Cloud Shelliä selaimen kautta.
• Azure’i funktsioonid: Vaihtoehto powerShellin paikalliselle työskentelylle. Azure’i funktsioonid on Azure-palvelu, jonka avulla voit kirjoittaa ja suorittaa koodia palvelimettomassa ympäristössä. PowerShell on yksi monista kielistä, joita se tukee.

Tärkeä

Suosittelemme, että käytät uusinta PowerShellin versiota (PowerShell Core) kaikkiin uusiin kehitystöihin. Sinun kannattaa lopettaa Windows PowerShellin käyttäminen (joka ei voi suorittaa PowerShell Corea) ja käyttää sen sijaan yhtä nykyaikaisista koodieditoreista, jotka tukevat PowerShell Corea. Ole varovainen viitatessasi useisiin verkkoesimerkkeihin, joissa käytetään Windows PowerShelliä (versio 5.1), koska niissä ei ehkä käytetä uusimpia (ja parempia) koodimenetelmiä.

Voit käyttää PowerShelliä useilla eri tavoilla. Lisätietoja tästä teknisestä päätöksestä on jäljempänä tässä artikkelissa kohdassa Ohjelmointirajapintojen tai PowerShellin cmdlet-komentojen valitseminen .

PowerShellin käyttämiseen on saatavilla useita verkkoresursseja, ja usein on mahdollista löytää kokeneita kehittäjiä, jotka voivat luoda ja hallita PowerShell-ratkaisuja. PowerShell on hyvä valinta sekä manuaalisten että automaattisten valvontaprosessien luomiseen.

Power BI Desktop

Koska Power BI Desktop voi muodostaa yhteyden ohjelmointirajapintoihin, saatat haluta käyttää sitä valvontaratkaisusi rakentamiseen. Tähän liittyy kuitenkin merkittäviä haittapuolia ja monimutkaisuutta.

• Kertymishistoria: Koska Power BI:n toimintoloki tarjoaa enintään 30 päivän tiedot, koko valvontaratkaisun luominen edellyttää tiedostojen joukon keräämistä ajan kuluessa kaikkien historiallisten tapahtumien tallentamiseksi. Historiallisten tiedostojen kertyminen on yksinkertaisempaa tehdä muiden työkalujen avulla.
• Tunnistetietojen ja avainten turvallinen käsittely: Monet yhteisön bloggaajien verkosta löytämiä ratkaisuja eivät ole suojattuja, koska niissä on pysyväiskoodatut tunnistetiedot ja avaimet salaa Power Query -kyselyissä. Vaikka tämä lähestymistapa on helppo, sitä ei suositella, koska kaikki, jotka hankkivat Power BI Desktop -tiedoston, voivat lukea arvot. Et voi tallentaa salasanaa (käyttäjän todentamista käytettäessä) tai salaista koodia (palvelun päänimeä käytettäessä) turvallisesti Power BI Desktopiin, ellet:
  • Käytä mukautettua liitintä, joka on kehitetty Power Query SDK:n kanssa. Mukautettu liitin voi esimerkiksi lukea luottamuksellisia arvoja Azuren võtmehoidla tai toisesta palvelusta, joka tallentaa salatun arvon turvallisesti. Maailmanlaajuisessa Power BI -yhteisössä on käytettävissä myös erilaisia mukautettuja liitinvaihtoehtoja.
  • Käytä ApiKeyName-vaihtoehtoa, joka toimii hyvin Power BI Desktopissa. Avainarvoa ei kuitenkaan voi tallentaa Power BI teenus.
• Pyyntötyypit: Saatat törmätä joihinkin rajoituksiin sen osalta, mitä voit suorittaa Power BI Desktopissa. Esimerkiksi Power Query ei tue kaikkia ohjelmointirajapintapyyntöjä. Esimerkiksi vain GET- ja POST-pyyntöjä tuetaan, kun web.contents-funktiota käytetään. Valvontaa varten lähetät yleensä GET-pyyntöjä.
• Päivitysmahdollisuus: Sinun on noudatettava tiettyjä Power Queryn kehitysmalleja, jotta voit onnistuneesti päivittää semanttisen mallin Power BI teenus. Asetuksen on esimerkiksi oltava käytössä Web.Contents-kohdetta käytettäessä, RelativePath jotta Power BI voi varmistaa tietolähteen sijainnin oikein aiheuttamatta virhettä Power BI teenus.

Useimmissa tapauksissa suosittelemme, että käytät Power BI Desktopia vain kahteen tarkoitukseen. Sitä tulisi käyttää

• Luo tietomalli olemassa olevien koostettujen tietojen perusteella (sen sijaan, että käyttäisit sitä alun perin valvontatietojen poimimiseen).
• Luo tietomalliin perustuvia analyysiraportteja.

Power Automate

Voit käyttää Power Automatea Power BI:n kanssa monella tavalla. Valvonnan osalta voit Power Automaten avulla lähettää pyyntöjä Power BI REST -ohjelmointirajapintoihin ja tallentaa sitten poimitut tiedot valitsemaasi sijaintiin.

Vihje

Jos haluat lähettää pyyntöjä Power BI REST -ohjelmointirajapintoihin, voit käyttää Power Automaten mukautettua liitintä valvontatietojen turvalliseen todentamiseen ja purkamiseen. Vaihtoehtoisesti voit käyttää Azure-võtmehoidla viittaamaan salasanaan tai salauskoodiin. Molemmat vaihtoehdot ovat parempia kuin salaisten salaisten koodien tallentaminen salaamattomana Power Automate -työnkulkuun.

Saat muita ideoita Power Automaten käyttötavoista hakemalla Power BI:n Power Automate -malleista.

Ensisijainen Azure-palvelu

Useat Azure-palvelut voivat lähettää pyyntöjä Power BI REST -ohjelmointirajapintoihin. Voit käyttää haluamaasi Azure-palvelua, kuten:

• Azure-funktiot
• Azure Automation
• Azure Data Factory
• Azure Synapse Analytics

Useimmissa tapauksissa voit yhdistää tietojen poiminnan logiikan käsittelevän käsittelypalvelun tallennuspalveluun, joka tallentaa raakatiedot (ja valitut tiedot tarvittaessa). Huomioitavia seikkoja teknisten arkkitehtuuripäätösten tekemisessä on kuvattu jäljempänä tässä artikkelissa.

Ensisijainen työkalu ja/tai kieli

Voit käyttää haluamaasi työkalua ja haluamaasi kieltä pyyntöjen lähettämiseen Power BI REST -ohjelmointirajapintoihin. Se on hyvä lähestymistapa, kun tiimilläsi on asiantuntemusta tietystä työkalusta tai kielestä, kuten:

• Python
• C# .NET Frameworkissa. Vaihtoehtoisesti voit käyttää Power BI .NET SDK:ta, joka toimii kääreenä Power BI REST -ohjelmointirajapintojen päällä, jotta joitakin prosesseja voidaan yksinkertaistaa ja tuottavuutta lisätä.
• JavaScript

Microsoft Purview -valvontahaku

Microsoft Purview -yhteensopivuusportaali (aiemmin Microsoft 365 -yhteensopivuuskeskus) sisältää käyttöliittymän, jonka avulla voit tarkastella ja hakea valvontalokeja. Yhtenäiset valvontalokit sisältävät Power BI:n ja kaikki muut palvelut, jotka tukevat Microsoft 365:n yhdistettyjä valvontalokeja.

Yhdistettyyn valvontalokiin talletetut tiedot ovat täsmälleen samat kuin Power BI: n toimintalokiin sisältyvät tiedot. Kun teet haku valvontalokista Microsoft Purview -yhteensopivuusportaalissa, se lisää pyyntösi jonoon. Tietojen valmistelu voi kestää muutamia minuutteja (tai kauemmin tietojen määrästä riippuen).

Seuraavassa on yleisiä tapoja käyttää valvontalokin hakutyökalua. Voit tehdä seuraavia toimintoja:

• Valitse Power BI -kuormitus, jos haluat tarkastella päivämäärien sarjan tapahtumia.
• Etsi vähintään yksi tietty toiminto, kuten:
  • Poistettu Power BI -raportti
  • Lisätty järjestelmänvalvojan käyttöoikeus henkilökohtaiseen työtilaan Power BI:ssä
• Voit tarkastella yhden tai useamman käyttäjän toimintoja.

Järjestelmänvalvojille, joilla on riittävät oikeudet, Microsoft Purview -yhteensopivuusportaalin valvontalokin hakutyökalu on hyvä vaihtoehto manuaalisiin valvontaprosesseihin. Lisätietoja on tämän artikkelin kohdassa Microsoft Purview -yhteensopivuusportaali .

Defender for Cloud Apps -käyttöliittymä

Defender for Cloud Apps on järjestelmänvalvojien käytettävissä Microsoft Defender XDR:ssä (Microsoft 365 -portaali). Se sisältää käyttöliittymän, jonka avulla voit tarkastella ja hakea eri pilvipalveluiden, kuten Power BI:n, toimintalokeja. Se näyttää samat lokitapahtumat, jotka ovat peräisin Microsoft Purview -yhteensopivuusportaalista, muiden tapahtumien lisäksi, kuten käyttäjän kirjautumistoiminta Microsoft Entra -tunnuksesta.

Defender for Cloud Appsin valvontalokin käyttöliittymä on hyvä vaihtoehto manuaalisiin valvontaprosesseihin. Lisätietoja on tämän artikkelin myöhemmässä kohdassa Defender for Cloud Apps .

Microsoft Sentinel ja KQL

Microsoft Sentinel on Azure-palvelu, jonka avulla voit kerätä, tunnistaa, tutkia ja vastata suojaustapauksiin ja uhkiin. Power BI voidaan määrittää Microsoft Sentinelissä tietoyhdistimenä niin, että valvontalokit virtautetaan Power BI:stä Microsoft Sentinel Azure Log Analyticsiin (joka on Azure Monitor -palvelun osa). Kusto Query Languagen (KQL) avulla voit analysoida Azure Log Analyticsiin tallennettuja toimintolokitapahtumia.

Tietojen hakeminen Azure Monitorista KQL:n avulla on hyvä vaihtoehto valvontalokin osan tarkastelemiseen. Se on hyvä vaihtoehto myös manuaalisille valvontaprosesseille. Katso lisätietoja Microsoft Sentinelistä jäljempänä tässä artikkelissa.

Käyttöympäristössä huomioitavat seikat

Seuraavassa on joitakin huomioon otettavia seikkoja siitä, miten voit käyttää valvontatietoja.

• Oletko toteuttamassa manuaalista tai automaattista valvontaprosessia? Tietyt työkalut ovat vahvasti yhteydessä manuaaliseen käsittelyyn tai automatisoituun prosessointiin. Esimerkiksi käyttäjä suorittaa Try-it-toiminnon aina vuorovaikutteisesti, joten se sopii vain manuaalisiin valvontaprosesseihin.
• Miten todennat? Kaikki vaihtoehdot eivät tue kaikkia todentamisvaihtoehtoja. Esimerkiksi Kokeile-toiminto tukee vain käyttäjien todentamista.
• Miten tunnistetiedot tallennetaan turvallisesti? Eri tekniikoilla on eri vaihtoehtoja tunnistetietojen tallentamiseen. Lisätietoja on tämän artikkelin kohdassa Todennusmenetelmän määrittäminen.
• Minkä teknologian parissa tiimisi on jo taitava? Jos tiimisi suosii jotakin työkalua ja sen käyttäminen on mukavaa, aloita siitä.
• Mikä on joukkueesi, joka pystyy tukemaan? Jos toinen ryhmä tukee käyttöön otettua ratkaisua, harkitse, pystyykö kyseinen tiimi tukemaan sitä riittävästi. Huomaa myös, että sisäiset tiimisi saattavat tukea konsulttien suorittamaa kehitystä.
• Mitä työkalua hyväksynnällä voit käyttää? Jotkin työkalut ja tekniikat saattavat vaatia hyväksyntää. Se voi johtua kustannuksista. Se voi johtua myös IT-suojauskäytännöistä.
• Mikä on etusija aikataulujen määrittämiseen? Jotkin teknologiat tekevät päätöksen puolestasi. Joskus se on toinen päätös, joka sinun on tehtävä. Jos esimerkiksi päätät kirjoittaa PowerShell-komentosarjoja, voit ajoittaa niiden suorittamisen useilla eri tavoilla. Jos taas käytät pilvipalvelua, kuten Azure Data Factorya, aikataulut ovat valmiit.

Suosittelemme, että tarkastelet artikkelin loppuosaa ennen kuin valitset teknologian valvontatietojen käyttöä varten.

Tarkistusluettelo – Päätettäessä siitä, mitä teknologiaa käytetään valvontatietojen käyttämiseen, tärkeimmät päätökset ja toiminnot ovat seuraavat:

• Keskustele IT-henkilöstösi kanssa: Kysy IT-tiimeiltäsi, onko tiettyjä hyväksyttyjä tai suosimiasi työkaluja.
• Tutki vaihtoehtoja, joilla on pieni soveltuvuusselvitys: Kokeile teknistä soveltuvuusselvitystä. Keskity aluksi oppimiseen. Keskity sitten päätökseesi siitä, mitä käytetään jatkossa.

Todennusmenetelmän määrittäminen

Todentamisen käyttöönottotapa on kriittinen päätös. Se on usein yksi vaikeimmista seikoista, kun aloitat valvonnan ja seurannan. Harkitse tarkkaan käytettävissä olevia vaihtoehtoja, jotta voit tehdä tietoon perustuvan päätöksen.

Tärkeä

Keskustele asiasta IT- ja tietoturvatiimien kanssa. Tutustu nyt perusteisiin siitä, miten Microsoft Entra -tunnuksen suojaus toimii.

Kaikki Internetin ohjelmointirajapinnat eivät edellytä todentamista. Kaikki Power BI REST -ohjelmointirajapinnat edellyttävät kuitenkin todentamista. Kun käytät vuokraajatason valvontatietoja, Microsofti identimisplatvorm hallitsee todennusprosessia. Se on Microsoft Entra -käyttäjätietopalvelun kehityskulku, joka perustuu alan vakioprotokolliin.

Vihje

Termien Microsofti identimisplatvorm sanasto on resurssi, joka auttaa tutustumaan peruskäsitteisiin.

Ennen kuin noudat valvontatiedot, sinun on ensin suoritettava todennus. Tätä kutsutaan kirjautumiseksi. Todentamisen ja valtuutuksen käsitteet ovat erilliset, mutta liittyvät toisiinsa. Todentamisprosessi tarkistaa pyynnön esittävien käyttäjätiedot. Valtuutusprosessi myöntää (tai estää) järjestelmän tai resurssin käytön tarkistamalla, mitä käyttäjällä tai palvelun päänimellä on oikeus tehdä.

Kun käyttäjä tai palvelun päänimi todennetaan, resurssipalvelimelle, kuten Power BI REST -ohjelmointirajapinnalle tai Microsoft Graph -ohjelmointirajapinnalle, annetaan Microsoft Entra -käyttöoikeustietue. Käyttöoikeustietue vanhenee oletusarvoisesti tunnin kuluttua. Päivitystunnusta voidaan tarvittaessa pyytää.

Käyttöoikeustietueita on kahdenlaisia:

• Käyttäjätunnukset: Myönnetty tunnetut käyttäjätiedot sisältävän käyttäjän puolesta.
• Vain sovelluksen tunnukset: Myönnetty Microsoft Entra -sovelluksen (palvelun päänimi) puolesta.

Lisätietoja on artikkelissa Sovelluksen ja palvelun päänimen objektit Microsoft Entra -tunnuksella.

Muistiinpano

Microsoft Entra -sovellus on käyttäjätietojen määritys, joka mahdollistaa automatisoidun prosessin integroinnin Microsoft Entra -tunnuksen kanssa. Tässä artikkelissa sitä kutsutaan sovelluksen rekisteröinniksi. Tässä artikkelissa käytetään myös yleisesti termiä palvelun päänimi . Nämä termit kuvataan tarkemmin jäljempänä tässä osiossa.

Vihje

Helpoin tapa todentaa on käyttää Power BI:n hallintamoduulin Connect-PowerBIServiceAccount-cmdlet-komentoa . Saatat nähdä muita todentamiseen liittyviä cmdlet-komentoja artikkeleissa ja blogikirjoituksissa verkossa. Käytettävissä ovat esimerkiksi - Login-PowerBI ja Login-PowerBIServiceAccount cmdlet-komennot, jotka ovat cmdlet-aliaksia Connect-PowerBIServiceAccount . Voit myös kirjautua ulos nimenomaisesti prosessin lopussa käyttämällä Disconnect-PowerBIServiceAccount-cmdlet-komentoa .

Seuraavassa taulukossa kuvataan kaksi todennusvaihtoehtoa.

Todentamisen tyyppi	Kuvaus	Tarkoitettu	Hyvä valinta manuaalisille valvontaprosesseille	Hyvä valinta automatisoituihin valvontaprosesseihin
Käyttäjän todennus	Kirjaudu sisään käyttäjänä käyttämällä käyttäjän päänimeä (sähköpostiosoitetta) ja salasanaa.	Satunnainen ja vuorovaikutteinen käyttö
Palveluobjektin todentaminen	Kirjaudu sisään palvelun päänimenä käyttämällä sovelluksen rekisteröinnille määritettyä salaista (avainta).	Meneillään olevat, ajoitetut ja valvomattomat toiminnot

Kutakin todentamisvaihtoehtoa käsitellään tarkemmin seuraavassa osiossa.

Käyttäjän todennus

Käyttäjän todentaminen on hyödyllistä seuraavissa tilanteissa.

• Manuaaliset valvontaprosessit: Haluat suorittaa komentosarjan käyttämällä käyttäjäoikeuksia. Käyttöoikeudet voivat olla kahdella tasolla ohjelmointirajapintapyynnön tyypin mukaan:
  • Järjestelmänvalvojan ohjelmointirajapintojen järjestelmänvalvojan oikeudet: Sinun on käytettävä Power BI -järjestelmänvalvojan käyttöoikeuksia pyynnön lähettämiseksi järjestelmänvalvojan ohjelmointirajapinnalle.
  • Käyttäjien ohjelmointirajapintojen käyttöoikeudet: Sinun on käytettävä Power BI -käyttäjäoikeuksiasi pyynnön lähettämiseksi käyttäjän ohjelmointirajapinnalle. Lisätietoja on artikkelissa Käyttäjän ohjelmointirajapinnan tai järjestelmänvalvojan ohjelmointirajapinnan valitseminen.
• Vuorovaikutteinen sisäänkirjautuminen: Haluat kirjautua sisään vuorovaikutteisesti, jolloin sinun on annettava sähköpostiosoitteesi ja salasanasi. Sinun on esimerkiksi kirjauduttava vuorovaikutteisesti, jotta voit käyttää Kokeile-toimintoa , joka löytyy Microsoftin ohjelmointirajapintadokumentaatiosta.
• Seuraa, ketkä ovat voineet käyttää vuokraajan metatietoja: Kun yksittäiset käyttäjät ja järjestelmänvalvojat lähettävät API-pyyntöjä, haluat ehkä valvoa, keitä kyseiset henkilöt ovat. Kun todennat palvelun päänimellä (kuvataan seuraavaksi), toimintolokin tallentama käyttäjätunnus on sovellustunnus. Jos useat järjestelmänvalvojat todentavat samalla palvelun päänimellä, voi olla vaikeaa tietää, kuka järjestelmänvalvojista on käyttää tietoja.
• Jaettu järjestelmänvalvojatili: Jotkin IT-tiimit käyttävät jaettua järjestelmänvalvojatiliä. Sovellus ei välttämättä ole paras käytäntö sen mukaan, miten se otetaan käyttöön ja miten sitä hallitaan. Jaetun tilin sijaan kannattaa harkita Microsoft Entra Privileged Identity Managementia (PIM), joka voi myöntää satunnaiset ja väliaikaiset Power BI -järjestelmänvalvojan oikeudet käyttäjälle.
• Ohjelmointirajapinnat, jotka tukevat vain käyttäjien todentamista: Joskus saatat joutua käyttämään ohjelmointirajapintaa, joka ei tue palvelun päänimen todennusta. Dokumentaatiossa kukin ohjelmointirajapinta ilmoittaa, voiko palvelun päänimi kutsua sitä.

Tärkeä

Suosittelemme, että käytät palvelun päänimen todentamista automatisoiduissa prosesseissa aina, kun se on mahdollista.

Palveluobjektin todentaminen

Useimmissa organisaatioissa on yksi Microsoft Entra -vuokraaja, joten sovelluksen rekisteröinti- ja palvelun päänimiä käytetään yleensä samalla tavalla. Kun rekisteröit Microsoft Entra -sovelluksen, siinä on kaksi osaa.

• Sovelluksen rekisteröinti:Sovelluksen rekisteröinti on yleisesti yksilöllistä. Kyseessä on rekisteröidyn Microsoft Entra -sovelluksen yleinen määritelmä, jota useat vuokraajat voivat käyttää. Sovelluksen rekisteröinti tunnetaan myös asiakassovelluksena tai näyttelijänä. Yleensä termi asiakassovellus merkitsee käyttäjäkonetta. Tämä ei kuitenkaan ole tilanne sovellusten rekisteröinnissä. Microsoft Entra -sovellukset löytyvät Azure-portaalin Microsoft Entra -tunnuksen Sovelluksen rekisteröinnit -sivulta.
• Palvelun päänimi:Palvelun päänimi on sovelluksen rekisteröinnin paikallinen esitys kyseisessä vuokraajassa käytettäväksi. Palvelun päänimi johdetaan rekisteröidystä Microsoft Entra -sovelluksesta. Jos organisaatiolla on useita Microsoft Entra -vuokraajia, samaan sovelluksen rekisteröintiin voi viitata useammalla kuin yhdellä palvelun päänimellä. Azure-portaalissa palvelujen päänimet löytyvät Microsoft Entra ID:n Yrityssovellukset-sivulta .

Koska palvelun päänimi on paikallinen esitys, termi palvelun päänimitodentaminen on yleisin tapa viitata kirjautumisiin.

Vihje

Microsoft Entra -järjestelmänvalvojasi voi kertoa sinulle, ketkä voivat luoda sovelluksen rekisteröinnin organisaatiossasi ja antaa suostumuksensa siihen.

Palvelun päänimen todentaminen on hyödyllistä seuraavissa tilanteissa.

• Automatisoidut valvontaprosessit: Haluat suorittaa valvomattoman prosessin aikataulun mukaisesti.
• Sinun ei tarvitse kirjautua sisään Power BI teenus: Sinun tarvitsee vain muodostaa yhteys ja poimia tiedot. Palvelun päänimi ei voi kirjautua sisään Power BI teenus.
• Tietojen jaettu käyttö: Sinä (henkilökohtaisesti) et ole Power BI -järjestelmänvalvoja, mutta sinulla on oikeus käyttää palvelun päänimeä. Palvelun päänimellä on oikeus suorittaa järjestelmänvalvojan ohjelmointirajapintoja vuokraajatason tietojen (tai muiden erityisoikeuksien) noutamiseksi.
• Käytä useille järjestelmänvalvojille: Haluat sallia sen, että useat järjestelmänvalvojat tai käyttäjät voivat käyttää samaa palvelun päänimeä.
• Tekniset estotoiminnot: On olemassa tekninen estotoiminto, joka estää käyttäjän todentamisen käytön. Yleisiä teknisiä estotoiminnoita ovat muun muassa seuraavat:
  • Monimenetelmäinen todentaminen (MFA): automaattisia valvontaprosesseja (joita ei suoriteta valvotusti) ei voi todentaa käyttäjätilillä, kun monimenetelmäinen todentaminen on käytössä.
  • Salasanan hajautuksen synkronointi: Microsoft Entra ID edellyttää salasanan hajautuskoodin synkronointia, jotta käyttäjätili voidaan todentaa. Joskus IT tai kyberturvallisuusryhmä saattaa poistaa tämän toiminnon käytöstä.

Sovelluksen rekisteröinnin tarkoitus ja nimeämiskäytäntö

Kullakin sovelluksen rekisteröinnillä on oltava selkeä nimi, joka kuvaa sen tarkoitusta ja kohderyhmää (joka voi käyttää sovelluksen rekisteröintiä).

Harkitse nimeämiskäytännön, kuten: <Kuormitus> – <Tarkoitus> – <kohderyhmä> – objektityyppi - <käyttöönotto>

Tässä ovat nimeämiskäytännön osat.

• Kuormitus: Yleensä vastaa tietolähdettä (esimerkiksi Power BI -tietoja tai Microsoft Graph -tietoja).
• Tarkoitus: Käyttöoikeustasoa vastaava (esimerkiksi Luku vs. lukukirjoitus). Kuten alla on kuvattu, tarkoitus auttaa noudattamaan pienintä oikeusperiaatetta , kun luot erilliset sovellusrekisteröinnit, jotka voivat vain lukea tietoja.
• Kohderyhmä: Valinnainen. Kohderyhmä antaa sinun määrittää sovelluksen rekisteröintiin tarkoitetut käyttäjät kuormituksen ja tarkoituksen mukaan.
• Objektityyppi:EntraApp sisältyy selkeyden vuoksi.

Nimeämiskäytäntösi voi olla tarkempi, kun sinulla on useita vuokraajia tai useita ympäristöjä (kuten kehitys ja tuotanto).

Seuraavassa taulukossa on esimerkkejä sovellusten rekisteröinnistä, joiden avulla voidaan poimia vuokraajatason valvontatietoja:

Sovelluksen rekisteröintinimi	Tarkoitus	Kohderyhmä
PowerBIData-Read-AdminAPIs-EntraApp	Poimi vuokraajan laajuiset metatiedot Power BI:n valvontaa ja hallintaa varten. Järjestelmänvalvojan ohjelmointirajapinnat ovat aina vain luku -tilassa, eikä niitä välttämättä ole myönnetty Microsoft Entra -tunnuksella (vain Power BI -vuokraaja-asetus).	Power BI -järjestelmänvalvojat ja Center of Excellence
PowerBIData-ReadWrite-PowerBIAdministrators-EntraApp	Hallinnoi Power BI -vuokraajaa. Resurssien luominen tai päivittäminen edellyttää luku- ja kirjoitusoikeuksia.	Power BI -järjestelmänvalvojat ja Center of Excellence
GraphData-Read-PowerBIAdministrators-EntraApp	Poimi käyttäjien ja ryhmien tietoja Power BI:n valvontaa ja hallintaa varten. Edellyttää lukuoikeuksia.	Power BI -järjestelmänvalvojat ja Center of Excellence

Useiden sovellusten rekisteröintien hallinta eri tarkoituksia varten vaatii enemmän vaivaa. Voit kuitenkin hyötyä useista eduista.

• Katso, mihin sovelluksen rekisteröinti on tarkoitettu ja miksi: Kun näet sovelluksen rekisteröinnistä peräisin olevan asiakastunnuksen valvontatiedoissasi, saat käsityksen siitä, mihin sitä on käytetty ja miksi. Tämä on merkittävä etu erillisten sovellusrekisteröinnit (sen sijaan, että käyttäisit vain yhtä kaikkiin tarkoituksiin).
• Katso, kuka sovelluksen rekisteröinti on tarkoitettu käytettäväksi: Kun näet sovelluksen rekisteröinnistä peräisin olevan asiakastunnuksen valvontatiedoissasi, näet, kuka sovellusta on käyttänyt.
• Vältä käyttöoikeuksien ylikäyttöä: Voit noudattaa pieninten oikeuksien periaatetta tarjoamalla erilliset sovellusrekisteröinnit eri henkilöjoukoille, joilla on erilaiset tarpeet. Voit välttää käyttöoikeuksien ylikäytön käyttämällä vain luku -sovellusrekisteröintiä, kun kirjoitusoikeudet eivät ole välttämättömiä. Sinulla voi olla esimerkiksi erittäin toimivia omatoimisia käyttäjiä, jotka haluavat kerätä tietoja semanttisista malleistaan. palvelun päänimen ja lukuoikeuden on oltava hänen käytettävissään. Center of Excellencessä saattaa olla satelliittijäseniä, jotka työskentelevät rahoitustiimille ja hallitsevat semanttisia malleja ohjelmallisesti, Palvelun päänimen ja kirjoitusoikeuden on oltava hänen käytettävissään.
• Tiedä, kenellä pitäisi olla salaus hallussaan: Jokaisen sovelluksen rekisteröinnin salaisuus tulisi jakaa vain sitä tarvitseville henkilöille. Kun salaisuus kierrätetään (kuvataan myöhemmin tässä osiossa), vaikutus on pienempi, kun käytät erillisiä sovellusrekisteröinteja eri tarpeisiin. Siitä on hyötyä, kun haluat kiertää salaisen koodin, koska käyttäjä poistuu organisaatiosta tai vaihtaa roolia.

Sovelluksen rekisteröinnin käyttöoikeudet

Sovelluksen rekisteröinti voi käyttää tietoja ja resursseja kahdella tavalla. Siihen liittyy käyttöoikeuksia ja suostumus.

• Vain sovelluksen käyttöoikeudet: Palvelun päänimi käsittelee käytön ja valtuutuksen ilman sisäänkirjautuneissa olevaa käyttäjää. Tämä todentamismenetelmä on hyödyllinen automaatioskenaarioita varten. Kun käytät sovelluksen käyttöoikeuksia, on tärkeää ymmärtää, että käyttöoikeuksia ei ole määritetty Microsoft Entra -tunnuksessa. Sen sijaan käyttöoikeudet määritetään kahdella tavalla:
  • Järjestelmänvalvojan ohjelmointirajapintojen suorittaminen: Tietyt Power BI -vuokraaja-asetukset sallivat järjestelmänvalvojan ohjelmointirajapintojen päätepisteiden käytön (jotka palauttavat vuokraajan laajuiset valvonnan metatiedot). Lisätietoja on tämän artikkelin kohdassa Power BI -vuokraaja-asetusten määrittäminen.
  • Käyttäjien ohjelmointirajapintojen suorittamiseen: Power BI -työtila ja kohteen käyttöoikeudet ovat voimassa. Power BI:n vakio-oikeudet määrittävät, mitä tietoja voidaan palauttaa palvelun päänimelle suoritettaessa käyttäjän ohjelmointirajapintoja (jotka palauttavat valvontatiedot ohjelmointirajapinnan käynnistävän käyttäjän tai palvelun päänimen käyttöoikeuksien perusteella).
• Delegoidut käyttöoikeudet: Käytetään vaikutusalueeseen perustuvia käyttöoikeuksia. Palvelun päänimi käyttää tietoja tällä hetkellä kirjautuneena olevan käyttäjän puolesta. Tämä tarkoittaa sitä, että palvelun päänimi ei voi käyttää mitään muuta kuin sitä, mitä kirjautunut käyttäjä voi käyttää. Huomaa, että tämä on eri käsite kuin aiemmin kuvattu vain käyttäjä -todennus. Koska mukautettua sovellusta tarvitaan käyttäjä- ja sovellusoikeuksien yhdistelmän asianmukaiseen käsittelyyn, delegoituja käyttöoikeuksia käytetään harvoin valvontaskenaarioita varten. Tämä konsepti ymmärretään yleisesti väärin, mikä johtaa moniin sovellusrekisteröinteihin, jotka on ylikuormitettu käyttöoikeuksilla.

Tärkeä

Tässä artikkelissa keskitytään vain käyttäjän todentamiseen tai vain sovellustodentamiseen. Delegoidut käyttöoikeudet (vuorovaikutteisen käyttäjän ja palvelun päänimen kanssa) voivat olla tärkeässä roolissa, kun Power BI -sisältöä upotetaan ohjelmallisesti. Kehotamme kuitenkin voimakkaasti estämään sinua määrittämästä delegoituja käyttöoikeuksia valvontatietojen poimimiselle. Jokainen ohjelmointirajapinta rajoittaa sen suoritusmäärää (rajoittamalla käyttöä), joten ei ole käytännöllistä, että eri käyttäjät käyttävät raakavalvontatietoja suoraan. Suosittelemme sen sijaan, että poimit raa'at valvontatiedot kerran (keskitetyllä prosessilla) ja tuot sitten valtuutetut käyttäjät saataville jatkossa.

Lisätietoja on tämän artikkelin kohdassa Microsoft Entra -sovelluksen rekisteröinti.

Sovelluksen rekisteröinnin salaisuudet

Sovelluksen rekisteröinnille on usein määritetty salainen koodi . Salaista koodia käytetään todentamisen avaimena, ja sillä on vanhentumispäivä. Siksi sinun on suunniteltava, miten avain kierrätetään säännöllisesti ja miten uusi avain ilmoitetaan valtuutetuille käyttäjille.

Sinun täytyy myös huolehtia siitä, mihin salaista salaisuutta tallennetaan turvallisesti. Organisaation salasanavarasto, kuten Azure võtmehoidla, on erinomainen valinta.

Vihje

Vaihtoehtoisena menetelmänä salaisen koodin käyttämiseen voit käyttää hallittuja käyttäjätietoja. Hallitut käyttäjätiedot poistavat tunnistetietojen hallinnan tarpeen. Jos aiot käyttää tietojen poimimiseen palveluja, kuten Azure’i funktsioonid tai Azure Data Factorya, hallitut käyttäjätiedot ovat hyvä tapa tutkia niitä.

Tunnistetietojen turvallinen hallinta

Riippumatta siitä, käytätkö käyttäjän todentamista vai palvelun päänimen todennusta, yksi suurimmista haasteista on salasanojen, salaisten koodien ja avainten turvallinen hallinta.

Varoitus

Ensimmäinen sääntö on sääntö, jota monet rikkovat: salasanoja ja avaimia ei pitäisi koskaan näyttää salaamattomana komentosarjassa. Yksinkertaisuuden vuoksi monet verkossa olevat artikkelit, blogit ja esimerkit tekevät sen. Se on kuitenkin huono käytäntö, jota tulisi välttää. Kuka tahansa, joka hankkii komentosarjan (tai tiedoston), voi mahdollisesti käyttää samoja tietoja, joihin tekijällä on käyttöoikeus.

Seuraavassa on useita suojattuja menetelmiä, joiden avulla voit hallita salaisia menetelmiä, salaisuuksia ja avaimia.

• Integroi azure võtmehoidla tai muuhun organisaation salasanavarastoon aina, kun se on mahdollista.
• Käytä tunnistetietoja ja suojattuja merkkijonoja PowerShell-komentosarjoissa. Tunnistetiedot toimivat sekä käyttäjän todentamisessa että palvelun päänimen todentamisessa. Et kuitenkaan voi käyttää tunnistetietoja, kun monimenetelmäinen todentaminen on käytössä käyttäjätilille.
• Kysy salasana PowerShell-komentosarjassa tai käytä vuorovaikutteista todentamista selaimen kanssa.
• Käytä Microsoftin julkaisemaa PowerShellin Salaisen koodin hallinta -moduulia. Se voi tallentaa arvoja käyttämällä paikallista säilöä. Se voidaan integroida myös Azuren etähallintaan võtmehoidla, mikä on hyödyllistä, kun organisaatiossasi on useita järjestelmänvalvojia, jotka käyttävät samoja komentosarjoja.
• Luo Power BI Desktopille mukautettu liitin, jotta se voi käsitellä tunnistetietoja turvallisesti. Jotkin mukautetut liittimet ovat saatavilla yhteisön jäseniltä (yleensä GitHubissa).

Vihje

Suosittelemme, että konsultoit IT- ja tietoturvatiimejäsi ja autat valitsemaan parhaan menetelmän tai vahvistamaan, että ratkaisusi hallitsee tunnistetietoja turvallisesti.

Microsoftin todentamiskirjasto

Azure AD -todentamiskirjaston (ADAL) tuki päättyi joulukuussa 2022. Käytä jatkossa Microsoftin todentamiskirjastoa (MSAL). Organisaatiosi suojaustiimin tulisi tuntea tämä merkittävä muutos.

Vaikka Power BI -ammattilaisten ei ole tärkeää ymmärtää syvästi siirtymistä MSAL:iin, sinun on noudatettava seuraavia suosituksia.

• Käytä Power BI -hallintamoduulin uusinta versiota, kun todennat Connect-PowerBIServiceAccount PowerShell -cmdlet-komennolla. Se siirtyi ADAL-versiosta MSAL-tiedostoon versiossa 1.0.946 (26.2.2021).
• Käytä Microsoft Entra V2 -päätepistettä, kun todennat suoraan komentosarjassa. Microsoft Entra V2 -päätepiste käyttää MSAL-päätepistettä, kun taas Microsoft Entra V1 -päätepiste käyttää ADAL-päätepistettä.
• Lopeta vanhentuneet ohjelmointirajapinnat ja moduulit. Lisätietoja on tämän artikkelin kohdassa Vanhentuneet ohjelmointirajapinnat ja moduulit .
• Jos löydät yhteisöratkaisun verkosta, varmista, että se käyttää MSAL-palvelua todentamiseen ADAL:n sijaan.

Tarkistusluettelo – Kun päätät, miten todennusta hallitaan, tärkeimmät päätökset ja toiminnot ovat seuraavat:

• Päätä, minkä tyyppistä todennusta käytät: Määritä, onko käyttäjän todentaminen tai palvelun päänimi todennus sopivinta, riippuen luotavan valvontaratkaisun tyypistä.
• Suunnittele, mitä sovelluksen rekisteröinteja tarvitset: Mieti tarpeitasi, kuormituksiasi ja kohdeyleisöäsi (kunkin sovelluksen rekisteröinnin käyttäjiä). Suunnittele, kuinka monta sovellusrekisteröintiä sinun on luotava näiden tarpeiden tukemiseksi.
• Nimeämiskäytännön luominen sovellusten rekisteröinnille: Määritä nimeämiskäytäntö, jonka avulla on helppo ymmärtää aiottua tarkoitusta ja kunkin sovelluksen rekisteröinnin suunniteltuja käyttäjiä.
• Suunnittele tunnistetietojen turvallinen hallinta: Harkitse tapoja hallita salasanoja, salaisia salaisuuksia ja avaimia suojatusti. Mieti, millainen dokumentaatio ja koulutus voisi olla tarpeen.
• Vahvista MSAL:n käyttö: Selvitä, onko olemassa olevia manuaalisia tai automaattisia valvontaratkaisuja, jotka käyttävät ADAL:ia. Luo tarvittaessa suunnitelma näiden ratkaisujen uudelleenkirjoittamiseksi, jotta voit käyttää uudempaa MSAL-todentamiskirjastoa.

Käyttäjän ohjelmointirajapinnan tai järjestelmänvalvojan ohjelmointirajapinnan valitseminen

Kun suunnittelet valvontatietojen noutamista, on tärkeää käyttää oikeanlaista ohjelmointirajapintaa.

On otettava huomioon kahdenlaisia ohjelmointirajapintoja.

• Käyttäjän ohjelmointirajapinnat: Voit lähettää pyyntöjä ohjelmointirajapintaan kirjautuneen käyttäjän (tai palvelun päänimen) käyttöoikeuksista. Esimerkiksi työtilan semanttisten mallien luettelo voidaan palauttaa käyttämällä käyttäjän ohjelmointirajapintaa. Semanttisten mallien lukuoikeus voidaan myöntää joko työtilan roolin tai kohdekohtaisten käyttöoikeuksien perusteella. Käyttäjien ohjelmointirajapintoja voi suorittaa kahdella tavalla:
  • Käyttäjän todentaminen: Kirjautuvalla käyttäjällä on oltava työtilan tai kohteen käyttöoikeus.
  • Palvelun päänimen todentaminen: Palvelun päänimellä on oltava oikeus käyttää työtilaa tai kohdetta.
• Järjestelmänvalvojan ohjelmointirajapinnat: nouda metatiedot vuokraajasta. Sitä kutsutaan joskus organisaation vaikutusalueeksi. Jos haluat esimerkiksi palauttaa luettelon kaikista vuokraajan semanttisista malleista, käytä järjestelmänvalvojan ohjelmointirajapintaa. Järjestelmänvalvojan ohjelmointirajapintoja voi suorittaa kahdella tavalla:
  • Käyttäjän todentaminen: Kirjautuneen käyttäjän on oltava Power BI -järjestelmänvalvoja, jotta järjestelmänvalvojan ohjelmointirajapinnat voidaan suorittaa.
  • Palvelun päänimitodentaminen: Palvelun päänimellä on oltava oikeus suorittaa järjestelmänvalvojan ohjelmointirajapintoja (ilman käyttäjän ohjelmointirajapinnan käyttöoikeusoikeuksia).

Vihje

Kaikki järjestelmänvalvojan ohjelmointirajapinnat kuuluvat Järjestelmänvalvojan toimintoryhmään. Ohjelmointirajapinta, jolla on Järjestelmänvalvoja-jälkiliite, on järjestelmänvalvojan ohjelmointirajapinta. Kaikki jäljellä olevat ohjelmointirajapinnat ovat käyttäjien ohjelmointirajapintoja.

Harkitse esimerkkiä, jossa sinun on hankittava semanttisten mallien luettelo. Seuraavassa taulukossa on kuusi ohjelmointirajapinnan vaihtoehtoa, joiden avulla voit tehdä sen. Neljä vaihtoehtoa ovat käyttäjien ohjelmointirajapintoja ja kaksi vaihtoehtoa ovat järjestelmänvalvojan ohjelmointirajapinnat. Palautettujen kohteiden laajuus ja määrä vaihtelevat valitsemasi ohjelmointirajapinnan mukaan.

Ohjelmointirajapinnan nimi	Ohjelmointirajapinnan tyyppi	Vaikutusalue	Semanttisten mallien määrä
Nouda tietojoukko	User	Henkilökohtainen työtila	Yksi
Hae tietojoukot	User	Henkilökohtainen työtila	Kaikki
Hae tietojoukko ryhmässä	User	Yksi työtila	Yksi, mikäli kirjautuvalla käyttäjällä on oikeus lukea semanttinen malli
Tietojoukkojen noutaminen ryhmässä	User	Yksi työtila	Kaikki edellyttäen, että kirjautuvalla käyttäjällä on oikeus lukea kukin semanttinen malli
Ryhmän tietojoukkojen noutaminen järjestelmänvalvojana	Järjestelmänvalvoja	Yksi työtila	Kaikki
Hae tietojoukot järjestelmänvalvojaksi	Järjestelmänvalvoja	Koko vuokraaja	Kaikki

Muistiinpano

Joidenkin ohjelmointirajapintojen nimiin sisältyy termi Ryhmä viitteeksi työtilaan. Tämä termi on peräisin alkuperäisestä Power BI -suojausmallista, joka oli riippuvainen Microsoft 365 -ryhmistä. Vaikka Power BI:n suojausmalli on kehittynyt huomattavasti vuosien varrella, olemassa olevat ohjelmointirajapinnat pysyvät muuttumattomina, jotta olemassa olevia ratkaisuja ei rikota.

Lisätietoja vuokraajan asetuksista on tämän artikkelin kohdassa Power BI -vuokraaja-asetusten määrittäminen.

Tarkistusluettelo – Kun valitset, käytetäänkö käyttäjän ohjelmointirajapintaa vai järjestelmänvalvojan ohjelmointirajapintaa, tärkeimmät päätökset ja toiminnot ovat seuraavat:

• Tutustu tietovaatimuksiin: Kerää ja dokumentoi valvontaratkaisun tärkeimmät liiketoimintavaatimukset. Tarvittavien tietojen tyypin perusteella voit määrittää, onko käyttäjän vaikutusalue tai organisaation laajuus sopiva.
• Testaa tulokset: Kokeile hieman. Testaa eri ohjelmointirajapintojen palauttamien tulosten tarkkuus.
• Tarkista käyttöoikeudet: Tarkista olemassa olevien valvontaratkaisujen osalta, että käyttöoikeudet on määritetty oikein Power BI -järjestelmänvalvojille ja palvelun päänimille. Varmista uusissa valvontaratkaisuissa, mitä todentamismenetelmää käytetään.

Valitse ohjelmointirajapinnat tai PowerShellin cmdlet-komennot.

Tärkeä päätös on, käytetäänkö PowerShellin cmdlet-komentoja, kun ne ovat käytettävissä noudettaville tietyille tiedoille. Tämä päätös on tärkeä, jos olet päättänyt, että PowerShell on yksi niistä tekniikoista, joita käytät valvontatietojen käyttämiseen.

PowerShell on tehtävien automatisointiratkaisu. Termi PowerShell on yhteistermi, joka viittaa komentosarjakieleen, komentorivikäyttösovellukseen ja määritysten hallintakehykseen. PowerShell Core on PowerShellin uusin versio, joka toimii Windowsissa, Linuxissa ja macOS:ssä.

PowerShellin cmdlet-komento on komento, joka suorittaa toiminnon. PowerShell-moduuli on paketti, joka sisältää PowerShell-jäseniä, kuten cmdlet-komentoja, palveluntarjoajia, funktioita, työnkulkuja, muuttujia ja aliaksia. Lataat ja asennat moduuleja.

PowerShell-moduuli luo abstraktiokerroksen ohjelmointirajapintojen päälle. Esimerkiksi Get-PowerBIActivityEvent cmdlet noutaa (tai noutaa) Power BI -vuokraajan valvontatapahtumat. Tämä PowerShellin cmdlet-komento noutaa tiedot Hae toimintatapahtumat REST-ohjelmointirajapinnasta. Yleensä cmdlet-komentojen käytön aloittaminen on helpompaa, koska se yksinkertaistaa pohjana olevien ohjelmointirajapintojen käyttöoikeuksia.

Vain ohjelmointirajapintojen alijoukko on käytettävissä PowerShellin cmdlet-komentoina. Kun jatkat koko valvontaratkaisusi laajentamista, käytät todennäköisesti cmdlet-komentojen ja ohjelmointirajapintojen yhdistelmää. Tämän osion loppuosassa päätät, mihin suuntaan käytät tietoja.

PowerShell-moduulit

Microsoft on julkaissut kaksi PowerShell-moduulia, jotka sisältävät Power BI:hin liittyviä cmdlet-komentoja. Ne ovat Power BI :n hallintamoduuli ja tietoyhdyskäytävämoduuli. Nämä PowerShell-moduulit toimivat ohjelmointirajapinnan paketoijana pohjana olevien Power BI REST -ohjelmointirajapintojen lisäksi. Käyttämällä näitä PowerShell-moduuleja voit helpottaa komentosarjojen kirjoittamista.

Vihje

Microsoftin julkaisemien moduulien lisäksi saatavilla on vapaasti saatavilla powershell-moduuleja ja komentosarjoja, jotka Power BI:n yhteisön jäsenet, kumppanit ja Microsoft Most Valued Professionals (MVP) julkaisevat (yleensä GitHubissa).

Yhteisöratkaisusta alkaen voi olla tärkeä rooli päästä päähän -valvontaratkaisun kehittämisessä. Jos päätät käyttää vapaasti saatavilla olevaa ratkaisua, muista testata se täysin. Tutustu sen toimintaan, jotta voit hallita ratkaisuasi tehokkaasti ajan mittaan. IT-osastollasi voi olla ehtoja julkisesti saatavilla olevien yhteisöratkaisujen käytölle.

Power BI :n hallintamoduuli

Power BI - hallintamoduuli on koontimoduuli, joka sisältää tiettyjä Power BI -moduuleja esimerkiksi hallintaan, kapasiteetteihin ja työtiloihin. Voit asentaa koontimoduulin, jotta saat kaikki moduulit, tai voit asentaa tiettyjä moduuleja. Kaikkia Power BI:n hallintamoduuleja tuetaan sekä Windows PowerShellissä että PowerShell Coressa.

Tärkeä

Suosittelemme, että lopetat Windows PowerShellin käytön (joka ei voi suorittaa PowerShell Corea). Käytä sen sijaan yhtä nykyaikaisista koodieditoreista, joka tukee PowerShell Corea. Windows PowerShell ISE (integroitu komentosarjaympäristö) pystyy suorittamaan vain PowerShell-version 5.1, jota ei enää päivitetä. Windows PowerShell on nyt vanhentunut, joten suosittelemme, että käytät PowerShell Corea kaikkiin uusiin kehitystöihin.

Seuraavassa on useita usein käytettyjä cmdlet-komentoja, joiden avulla voit noutaa valvontatietoja.

Hallintamoduuli	Cmdlet-komento	Tarkoitus
Profiili	Connect-PowerBIServiceAccount	Todenna Power BI -käyttäjä tai palvelun päänimi.
Järjestelmänvalvoja	Get-PowerBIActivityEvent	Tarkastele tai poimi vuokraajan Power BI:n toimintolokitapahtumia.
Työtilat	Get-PowerBIWorkspace	Laadi luettelo työtiloista.
raportit	Get-PowerBIReport	Laadi luettelo raporteista työtilaa tai vuokraajaa varten.
Tiedot	Get-PowerBIDataset	Laadi työtilan tai vuokraajan semanttisen mallin luettelo.
Profiili	Invoke-PowerBIRestMethod	Lähetä REST-ohjelmointirajapinnan pyyntö (komento). Tämä cmdlet-komento on hyvä vaihtoehto, koska se voi käynnistää minkä tahansa Power BI REST -ohjelmointirajapinnan. Se on myös hyvä valinta, kun haluat käyttää yksinkertaisempaa todentamismuotoa cmdlet-komennon avulla Connect-PowerBIServiceAccount ja käynnistää ohjelmointirajapinnan, jolla ei ole vastaavaa PowerShellin cmdlet-komentoa. Lisätietoja on jäljempänä tässä osiossa kohdassa Huomioitavaa PowerShellin cmdlet-komentojen käytössä.

Vihje

Sisällön hallintaan ja julkaisemiseen on saatavilla myös muita cmdlet-komentoja. Tässä artikkelissa keskitytään kuitenkin valvontatietojen noutamiseen.

Voit ladata Power BI :n hallintamoduulin PowerShell-valikoimasta. Yksinkertaisin tapa asentaa moduuleja on käyttää PowerShellGetiä.

Suosittelemme Power BI:n hallinnan koontimoduulin asentamista. Näin käytettävissä ovat kaikki cmdlet-komennot, joita saatat tarvita. Tarvitset vähintään profiilimoduulin (todentamiseen) ja kaikki tietyt moduulit, jotka sisältävät cmdlet-komennot, joita haluat käyttää.

Varoitus

Muista pitää moduulit ajan tasalla jokaisessa palvelimessa, käyttäjäkoneessa ja pilvipalvelussa (kuten Azure Automationissa), jossa käytät PowerShelliä. Jos moduuleja ei päivitetä säännöllisesti, voi ilmetä arvaamattomia virheitä tai ongelmia. Jotkin työkalut (kuten Visual Studio Code) auttavat pitämään moduulit ajan tasalla. Huomaa myös, että PowerShellGet ei poista automaattisesti moduulin vanhempia versioita, kun asennat tai päivität uudemman version. Se asentaa uudemmat versiot aiempien versioiden rinnalle. Suosittelemme, että tarkistat asennetut versiot ja poistat vanhempien versioiden asennuksen säännöllisesti.

Tietoyhdyskäytävä-moduuli

Tietoyhdyskäytävä-moduuli sisältää cmdlet-komentoja, jotka noutavat tietoja paikallisesta tietoyhdyskäytävästä ja sen tietolähteistä. Tietoyhdyskäytävä-moduulia tuetaan vain PowerShell Coressa. Sitä ei tueta Windows PowerShellissä.

Toisin kuin Power BI -hallintamoduulissa (aiemmin kuvattiin), Tietoyhdyskäytävä-moduulissa ei ole järjestelmänvalvojan cmdlet-komentoja. Monet cmdlet-komennot (ja vastaavat yhdyskäytävän ohjelmointirajapinnat) edellyttävät, että käyttäjällä on yhdyskäytävän järjestelmänvalvojan oikeudet.

Varoitus

Palvelun päänimeä ei voi määrittää yhdyskäytävän järjestelmänvalvojaksi , vaikka palvelun päänimi olisi käyttöoikeusryhmän jäsen. Siksi haluat käyttää käyttäjän tunnistetietoja noudettaessa tietoyhdyskäytäviä koskevia tietoja.

Seuraavassa on useita tietoyhdyskäytävämoduulin cmdlet-komentoja, joiden avulla voit noutaa valvontatietoja.

Cmdlet-komento	Tarkoitus
Connect-DataGatewayServiceAccount	Todenna Power BI -käyttäjä (edellyttää yleensä, että käyttäjä kuuluu yhdyskäytävän järjestelmänvalvojan rooliin).
Get-DataGatewayCluster	Laadi luettelo yhdyskäytäväklustereista.
Get-DataGatewayClusterDataSource	Laadi luettelo yhdyskäytäväklusterin tietolähteistä.
Get-DataGatewayInstaller	Varmista, ketkä käyttäjät voivat asentaa ja rekisteröidä yhdyskäytäviä organisaatiossa.

Voit ladata Tietoyhdyskäytävä-moduulin PowerShell-valikoimasta.

PowerShellin käyttötekniikat

Voit käyttää PowerShelliä useilla eri tavoilla. Tekemäsi päätös on tärkeä.

Seuraavassa taulukossa kuvataan kolme eri menetelmää PowerShellin käyttämiseen.

Tekniikka	Kuvaus	Esimerkki
Yksinkertaista todentamista ja kutsu ohjelmointirajapintoja suoraan PowerShellin cmdlet-komentojen avulla. Suositeltu lähestymistapa	Tämän tekniikan avulla on olemassa yksinkertaisuuden ja joustavuuden tasapaino. Invoke-PowerBIRestMethod-cmdlet-komento on saatavilla Power BI:n hallintaprofiilimoduulista. Tätä cmdlet-komentoa kutsutaan usein Sveitsin armeijan veitseksi, koska sen avulla voit kutsua mitä tahansa Power BI REST -ohjelmointirajapintaa. Tämän tekniikan etuna on, että voit yksinkertaistaa todentamista ja kutsua sitten mitä tahansa Power BI REST -ohjelmointirajapintoja. Suosittelemme, että käytät tätä tekniikkaa.	Kun olet todentanut sen Connect-PowerBIServiceAccount-cmdlet-komennolla, nouda tiedot haluamastasi ohjelmointirajapinnasta Käyttämällä Invoke-PowerBIRestMethod-cmdlet-komentoa (esimerkiksi Hae putken käyttäjät järjestelmänvalvojana).
Käytä cmdlet-komentoja PowerShellistä mahdollisimman paljon sekä todentamiseen että tietojen noutamiseen.	Tämän tekniikan avulla PowerShelliä käytetään laajasti. PowerShellin avulla koordinoidaan komentosarjan suorittamista, ja PowerShell-moduuleja käytetään aina, kun se on mahdollista tietojen käyttämiseen. Tämä luo suuremman riippuvuuden PowerShelliin useista näkökohdista.	Kun olet todentanut sen Connect-PowerBIServiceAccount-cmdlet-komennolla , nouda tiedot cmdlet-komennolla (esimerkiksi Get-PowerBIActivityEvent).
Käytä PowerShelliä vain prosessin suorittamisen koordinoimiseen. PowerShell-moduuleja käytetään mahdollisimman vähän.	Tämän tekniikan avulla PowerShellissä on vähemmän riippuvuutta työkaluna, koska sen ensisijainen käyttötarkoitus on API-kutsujen käynnistämisen järjestäminen. Ohjelmointirajapintojen käyttämiseen käytetään vain yhtä geneeristä PowerShell-moduulia (mitään Power BI:n hallintamoduulien moduuleista ei käytetä).	Kun olet todentanut käyttäen Microsoftin todentamiskirjastoa (MSAL), kutsu haluamaasi ohjelmointirajapintaa (esimerkiksi Hae jakson käyttäjät järjestelmänvalvojaksi) käyttämällä yleistä Invoke-RestMethod-cmdlet-komentoa tietojen noutamiseen.

Yllä olevassa taulukossa ensimmäinen menetelmä kuvaa lähestymistapaa, joka tasapainottaa helppokäyttöisyyden joustavuuden kanssa. Tämä lähestymistapa tarjoaa parhaan tasapainon useimpien organisaatioiden tarpeisiin, minkä vuoksi sitä suositellaan. Joillakin organisaatioilla voi olla olemassa olevia IT-käytäntöjä ja henkilöstön asetuksia, jotka vaikuttavat siihen, miten päätät käyttää PowerShelliä.

Vihje

Voit käyttää Invoke-ASCmd PowerShell-cmdlet-komentoa DAX-, XMLA- ja TMSL-komentosarjojen luomiseen ja suorittamiseen. Nämä käyttötapaukset eivät kuitenkaan kuulu tässä artikkelissa käsiteltyihin tapauksiin. Lisätietoja dynaamisten hallintanäkymien kyselyistä on kohdassa Tietotason valvonta.

Tekniset käyttäjät (ja järjestelmänvalvojat) voivat käyttää Power BI:n hallintamoduuleja tietojen noutamiseen tai tiettyjen sisällönhallinnan näkökohtien automatisointeihin.

• Järjestelmänvalvojat: Määritä -Scope parametri niinOrganization, että se käyttää koko vuokraajan entiteettejä (esimerkiksi kaikkien työtilojen luettelon noutamiseksi).
• Tekniset käyttäjät: Määritä parametrin -Scope arvoksi Individual (tai poista parametri) käyttäjälle kuuluvien entiteettien käyttämiseksi (esimerkiksi hakemaan luettelo työtiloista , joihin käyttäjällä on käyttöoikeus).

Harkitse skenaariota, jossa sinun on hankittava semanttisten mallien luettelo. Jos päätät käsitellä ohjelmointirajapintoja suoraan, sinun on määritettävä, mihin ohjelmointirajapintaan kutsut. Jos kuitenkin päätät käyttää Get-PowerBIDataset cmdlet-komentoa, voit määrittää parametrin -Scope noutamaan käyttäjäkohtaisen tai vuokraajan laajuisen semanttisten mallien luettelon. Tekemäsi valinta riippuu päätöksestäsi käyttää PowerShelliä (käsitellään edellisessä taulukossa).

Seuraavassa taulukossa kuvataan, miten PowerShellin cmdlet-komennossa käytetyt parametrit kääntävät ohjelmointirajapinnan PowerShell-kutsuille.

Cmdlet-parametrit	Ohjelmointirajapinta, jota cmdlet käyttää	Ohjelmointirajapinnan tyyppi	Vaikutusalue	Noudetut kohteet
-DatasetID {DatasetID} -Scope Individual	Nouda tietojoukko	User	Henkilökohtainen työtila	Yksi semanttinen malli
-Scope Individual	Hae tietojoukot	User	Henkilökohtainen työtila	Kaikki semanttiset mallit
-DatasetID {DatasetID} -GroupID {WorkspaceID}	Hae tietojoukko ryhmässä	User	Yksi työtila	Yksi semanttinen malli, mikäli kirjautuvalla käyttäjällä on oikeus lukea semanttinen malli
-GroupID {WorkspaceID}	Tietojoukkojen noutaminen ryhmässä	User	Yksi työtila	Kaikki semanttiset mallit, mikäli kirjautuvalla käyttäjällä on oikeus käyttää työtilaa ja lukea semanttinen malli
-GroupID {WorkspaceID} -Scope Organization	Ryhmän tietojoukkojen noutaminen järjestelmänvalvojana	Järjestelmänvalvoja	Yksi työtila	Kaikki semanttiset mallit
-Scope Organization	Hae tietojoukot järjestelmänvalvojaksi	Järjestelmänvalvoja	Koko vuokraaja	Kaikki semanttiset mallit

Huomioitavaa PowerShellin cmdlet-komentojen käytössä

Power BI:n PowerShell-cmdlet-komentoja on helpompi käyttää, koska ne abstraktisoivat osan REST-ohjelmointirajapinnan kutsujen monimutkaisuudesta.

Seuraavassa on joitakin tapoja, joilla cmdlet-komennot yksinkertaistavat valvontatietojen käyttöä.

• Todentaminen: Yksinkertaisin tapa todentaa PowerShell-komentosarja on käyttää cmdlet-komentoa Connect-PowerBIServiceAccount .
• Yksinkertaisuus: Aloittaminen on yksinkertaisempaa, koska valvontatietojen noutamisen tekniikat ovat yksinkertaisia. Ota huomioon, että kun käytät Get-PowerBIActivityEvent-cmdlet-komentoa , noudat yhden päivän valvontatiedot. Kun kutsut suoraan Hae toimintatapahtumat REST -ohjelmointirajapintaa, noudat kuitenkin valvontatietoja tunnin . Joten kun käytät REST-ohjelmointirajapintaa yhden päivän valvontatietojen noutamiseen, sinun on käytettävä silmukkaa kutsuaksesi ohjelmointirajapinnan 24 kertaa, jotta voit poimia jokaisen päivän tunnin.
• Suurten tulosjoukkojen sivutus: Suuret tulosjoukot noudetaan tehokkaasti sivutetusti. Sivutus tarkoittaa yhden tuloslohkon noutamista kerrallaan. Cmdlet-komennot hallitsevat sivutusta automaattisesti puolestasi. Kun käytät suoraan REST-ohjelmointirajapintoja, komentosarjasi on kuitenkin tarkistettava jatkumistunnuksen ja selvitettävä, onko tulos tulossa. Komentosarjan pitäisi jatkaa tuloslohkojen noutamista, kunnes jatkumistunnusta ei vastaanoteta. Lisätietoja jatkumistunnuksen käyttämisestä on kohdassa Toimintatapahtumat REST-ohjelmointirajapinta.
• Käyttöoikeustietueen vanhentuminen: Kun todennus suoritetaan, palautetaan käyttöoikeustietue. Oletusarvoisesti se vanhenee tunnin kuluttua. Cmdlet-komennot käsittelevät käyttöoikeustietueen vanhentumisia puolestasi. Näin sinun ei tarvitse kirjoittaa logiikkaa päivitystunnuksen pyytämiseksi.
• Muotoilu: Cmdlet-komennon palauttamat tiedot on muotoiltu hieman hienommin kuin REST-ohjelmointirajapinnan palauttamat tiedot. Tulos on käyttäjäystävällisempi. Automaattisissa valvontaprosesseissa tämä ei todennäköisesti ole ongelma. Manuaalisten valvontaprosessien muotoilusta voi kuitenkin olla hyötyä.

Huomioon otettavia seikkoja, kun käytetään suoraan REST-ohjelmointirajapintoja

Joskus Power BI REST -ohjelmointirajapintojen kutsumisessa suoraan on monia etuja.

• Saatavilla on paljon enemmän ohjelmointirajapintoja: REST-ohjelmointirajapintoja on enemmän kuin PowerShellin cmdlet-komentoja. Älä kuitenkaan unohda Invoke-PowerBIRestMethod-cmdlet-komennon joustavuutta, jota voit käyttää minkä tahansa Power BI REST -ohjelmointirajapinnan kutsumiseen.
• Päivitystiheys: Microsoft päivittää REST-ohjelmointirajapintoja useammin kuin PowerShell-moduuleja. Jos esimerkiksi uusi määrite lisätään Nouda tietojoukko -ohjelmointirajapinnan vastaukseen, voi kestää jonkin aikaa, ennen kuin se tulee saataville Get-PowerBIDataset-cmdlet-komennon tuloksissa.
• Vähemmän kielen tai työkalun riippuvuussuhteet: Kun käytät REST-ohjelmointirajapintoja suoraan (cmdlet-komennon sijaan), sinun ei tarvitse käyttää PowerShelliä. Saatat myös käyttää PowerShelliä vain useiden ohjelmointirajapintojen kutsumisen järjestämiseen komentosarjassa. Poistamalla (tai välttämällä) kaikki riippuvuudet PowerShellissä voit joskus tulevaisuudessa kirjoittaa logiikan uudelleen eri kielellä. Kun IT- tai kehittäjätiimilläsi on vahvat työkalut ja kielet, pienempi riippuvuus voi olla tärkeä huomioitava seikka.

REST-ohjelmointirajapinnat voivat muuttua ajan mittaan riippumatta siitä, mitä menetelmää valitset. Kun teknologia kehittyy, ohjelmointirajapinnat (ja PowerShell-moduulit) voidaan vanhentua ja korvata. Siksi suosittelemme, että luot tarkoituksellisesti komentosarjoja, joita on helppo ylläpitää ja jotka kestävät muuttumisen.

Tarkistusluettelo – Valittaessa, käytetäänkö REST-ohjelmointirajapintoja suoraan vai PowerShellin cmdlet-komentojen avulla, tärkeimmät päätökset ja toiminnot ovat seuraavat:

• Kysy IT-osastolta PowerShellin käytöstä: Ota yhteyttä asianmukaisiin IT-tiimiin ja selvitä, onko PowerShellin käyttöön olemassa sisäisiä vaatimuksia tai asetuksia.
• Päätä, miten haluat käyttää PowerShelliä: Selvitä, mitä PowerShell-tekniikoita käytetään ja haluatko tarkoituksella lisätä vai pienentää riippuvuuttasi PowerShellissä. Mieti, onko sisäinen viestintä tai koulutus tarpeen.
• Päivitä PowerShell Coreen: tutkimus PowerShell Coren avulla. Määritä, onko järjestelmänvalvojakoneet päivitettävä. Harkitse, mitä olemassa olevia komentosarjoja on testattava. Määritä, tarvitsevatko järjestelmänvalvojat tai kehittäjät lisäkoulutusta taitojensa päivittämiseen.
• Käytettävien PowerShell-moduulien selvittäminen: Harkitse, käytetäänkö Power BI -hallintamoduuleja ja/tai tietoyhdyskäytävä-moduulia.
• Päätä, onko yhteisöprojektit sallittuja: Selvitä, saako (tai jopa kannustaa) käyttää PowerShell-moduuleja verkossa (Microsoftin julkaisemien moduulien sijaan). Kysy IT-konsultilta, onko verkossa hankittuja yhteisöprojekteja koskevia ehtoja.
• Selvitä, miten voit tukea yhteisöprojekteja: Jos PowerShell-yhteisöprojektit ovat sallittuja, mieti, kuka vastaa niiden tukemisesta, kun niitä käytetään sisäisesti.
• Viimeistele pieni soveltuvuusselvitys: Kokeile teknistä soveltuvuusselvitystä. Vahvista haluamasi asiakastyökalut ja tietojen käyttötapa.
• Päätä, miten voit tukea kokeneita käyttäjiä: Harkitse, miten aiot tukea teknisiä käyttäjiä, jotka luovat automaatiota itse käyttämällä käyttäjäliittymiä.

Määritä valvontatietojen tallennuspaikka

Kun aiot luoda päästä päähän -valvontaratkaisun, sinun on päätettävä, mihin raakatiedot tallennetaan (ja valitut tiedot, jotka käsitellään seuraavassa osiossa). Tietojen tallennustilaa koskevat päätöksesi liittyvät asetukseesi siitä, miten voit käsitellä tietojen integrointia.

Kun poimit raakavalvontatietoja, pidä ne yksinkertaisina. Suosittelemme, että et valitse tiettyjä määritteitä, suorita muunnoksia tai käytä muotoiluja, kun poimit tiedot ensin. Poimi sen sijaan kaikki käytettävissä olevat määritteet ja tallenna tiedot niiden alkuperäisessä tilassa.

Tässä on useita syitä siihen, miksi raakatietojen tallentaminen alkuperäisessä tilassa on paras käytäntö.

• Kaikki historiassa käytettävissä olevat tiedot: Uudet määritteet ja uudet tapahtumatyypit tulevat saataville ajan kuluessa. Kaikkien raakatietojen tallentaminen on hyvä tapa varmistaa, että sinulla on aina käyttöoikeus siihen, mitä tietoja oli saatavilla poimiessasi ne. Vaikka uusien tietomääritteiden käyttö vie aikaa – jopa viikkoja tai kuukausia – niitä on mahdollista analysoida historiallisesti, koska ne on otettu kiinni raakatiedoissa.
• Kestävä muutos: Jos raakadatamuoto muuttuu, tietoja poimittavaan prosessiin ei vaikuteta. Koska jotkin valvontatiedot ovat aikasietoisia, on tärkeää varmistaa, että suunnittelet tietojen poimintaprosessin, joka ei epäonnistu, kun lähteessä tapahtuu muutos.
• Roolit ja vastuut: Eri tiimin jäsenet (kuten tietoteknikot tai yleiset järjestelmänvalvojat) saattavat vastata prosessien luomisesta raakavalvontatietojen käyttöä, poimimista ja tallentamista varten. Tietojen poimintaprosessin yksinkertaistaminen helpottaa useiden tiimien yhteistyötä.

Seuraavassa on joitakin vaihtoehtoja raakatietojen tallentamiseen.

• Data Lake- tai objektisäilö: Pilvipalvelu, kuten OneLake , joka on erikoistunut minkä tahansa rakenteen tiedostojen tallentamiseen. Se on erinomainen valinta raakavalvontatietojen tallentamiseen. Data Lake -arkkitehtuurissa raakatiedot tulee tallentaa pronssikerrokseen.
• Tiedostojärjestelmä: Raakavalvontatietojen tallentamiseen käytetään usein tiedostojärjestelmää (kuten Windows tai Linux).
• Tietokanta: JSON-tiedot voidaan tallentaa relaatiotietokantaan, kuten Azure SQL -tietokantaan. Se on kuitenkin harvinaisempaa kuin tietojen tallentaminen Data Lake- tai tiedostojärjestelmään. Tämä johtuu siitä, että JSON-tietojen kyseleminen ja ylläpito voi tulla haastavaksi ja kalliiksi, varsinkin kun tietomäärät kasvavat.

Vihje

Kun käytät Data Lake -tallennustilaa, objektisäilöä tai tiedostojärjestelmää, suosittelemme tallentamaan tiedot helposti järjestettävällä ja turvallisella tavalla. On myös tärkeää tietää, sisältävätkö tiedot tapahtumia (jotka ovat yleensä liitettyjä) vai onko kyseessä pistetilannevedos (joka edellyttää päivämäärän valitsemista analysoitavaksi).

Otetaan esimerkiksi Data Lake -tallennustilan raakatietovyöhyke. Vyöhykkeellä on kansiohierarkia toimintalokitietojen tallentamista varten: Raaka > ActivityLog > VVVV > KK. Kansiot ositetaan vuoden ja kuukauden mukaan. Kuukausi-kansioon tallennettu tiedosto käyttää seuraavaa muotoa: PBIActivityLog-YYYYMMDD-YYYYMMDDTTTT.json. VVVVKKD edustaa todellisia tietoja ja YYYYYMMDTTT tarkoittaa poiminta-aikaleimaa. Ottamalla mukaan poiminta-aikaleiman voit määrittää, mikä tiedosto on viimeisin (siltä varalta, että sinun on purettava tiedot uudelleen). Jos esimerkiksi poimit tiedot 25.4.2023 klo 9.00 (UTC) 23.4.2023 toiminnolle, tiedostonimi on PBIActivityLog-20230523-202305250900.

Suosittelemme käyttämään tekniikkaa, jonka avulla voit kirjoittaa raakadatan muuttumattomaan tallennustilaan. Muuttumattomia tallennustakuita siitä, että kun tiedot on kirjoitettu, niitä ei voi korvata tai poistaa. Tämä ero on tärkeä auditoijille, ja sen avulla voit luottaa siihen, että raakatiedot ovat luotettavia.

Sinun täytyy myös miettiä, miten voit tallentaa raakatiedot turvallisesti. Yleensä vain harvat käyttäjät tarvitsevat raakadatan käytön. Raakadatan käyttö annetaan yleensä tarvepohjaisesti, yleensä tietoteknikoille ja järjestelmänvalvojille. Myös sisäiset tarkastajasi tarvitsevat käyttöoikeuden. Tiimin jäsenet, jotka vastaavat koostettujen tietojen luomisesta (kuvataan seuraavaksi), tarvitsevat myös raakatietojen käyttöoikeuden.

Seuraavassa on joitakin huomioon otettavia seikkoja, joiden avulla voit valita raakatietojen tallennustilan.

• Onko kyseessä manuaalinen vai automaattinen valvontaprosessi? Automatisoidulla valvontaprosessilla on yleensä tiukemmat vaatimukset tietojen tallennustavan ja -tallennustilan osalta.
• Onko aihealue erityisen arkaluonteinen? Tietojen tyypistä ja niiden arkaluonteisesta tyypistä riippuen organisaatiossasi saattaa olla vaatimuksia siitä, miten ja mihin se on tallennettu. Power BI:n valvontatiedot sisältävät käyttäjätietojen ja IP-osoitteiden tunnistamisen, joten ne tulee tallentaa suojatulle alueelle.
• Onko olemassa ensisijainen tallennustekniikka? Organisaatiossa voi olla käytössä aiemmin luotu tallennustekniikka, joten se on looginen valinta.
• Käyttävätkö käyttäjät tallennustilaa suoraan? Suojausmalli on tärkeä huomioita. Yleensä vain harvoille käyttäjille myönnetään raakatietojen käyttöoikeus. Kootut tiedot tarjotaan yleensä Power BI -sisällöntekijöille, jotka vastaavat keskitetyn tietomallin (semanttisen mallin, joka toimii raportoinnin kerroksena) luomisesta.
• Onko sinulla tietojen sijaintia koskevia vaatimuksia? Joillakin organisaatioilla on juridisia tai lainsäädännöllisiä tietojen tallennusvaatimuksia tietojen tallentamiseksi tietylle tietoalueelle.
• Miten tiedot järjestetään? Medallion-arkkitehtuurin käyttö on yleinen käytäntö erityisesti Data Lake- ja Lakehouse-toteuttuksissa. Tavoitteena on tallentaa tiedot pronssi-, hopea- ja kultatietokerroksiin. Pronssikerros sisältää alkuperäiset raakatiedot. Hopeinen kerros sisältää muunnoksiin käytettyjä vahvistettuja ja deduplicoituja tietoja. Kultakerros sisältää kuratoidut, erittäin tarkennetut tiedot, jotka ovat valmiita analysoitaville.

Tarkistusluettelo – Kun suunnittelet raakatietojen tallennussijaintia, tärkeimmät päätökset ja toiminnot ovat seuraavat:

• Konsultoi IT-ohjeita: Ota yhteyttä asianmukaisiin IT-tiimiin tai asianomaisiin IT-tiimiin ja selvitä, onko käynnissä olemassa olevia prosesseja raakavalvontatietojen poimimiseksi. Jos on, selvitä, voitko käyttää olemassa olevia tietoja. Jos tarvitaan uusi tietojen poimintaprosessi, määritä, onko tietojen tallennussijainnille asetuksia tai vaatimuksia.
• Päätä, mihin raakatiedot tallennetaan: Määritä paras tallennussijainti ja rakenne raakatietojen tallentamista varten.
• Määritä tietojen sijaintivaatimukset: Selvitä, onko tietojen tallennussijainnille oikeudellisia tai lakisääteisiä vaatimuksia.
• Luo kansiorakenne ja nimeämiskäytäntö: Määritä, mitä nimeämiskäytäntöä käytetään raakadatatiedostoissa, mukaan lukien kansiorakenne. Sisällytä nämä tiedot tekniseen dokumentaatioon.
• Mieti, miten raakatietojen suojaus toimii: Kun suunnittelet raakatietojen tallennussijaintia, mieti, kenen on käytettävä tietoja ja miten käyttöoikeus myönnetään.

Suunnitelma koostettujen tietojen luomiseksi

Kootut tiedot tukevat analyyseja, ja ne on suunniteltu käyttäjäystävällisiksi. Sinun on tehtävä joitakin päätöksiä siitä, miten ja missä kootut tiedot luodaan. Teknologia, jonka päätät tallentaa kootut tiedot, voi olla mikä tahansa edellisessä osiossa luetelluista tekniikoista.

Kootun tiedon tavoitteena on muuntaa tiedot entistä ystävällisempään muotoon, joka on optimoitu analysointia ja raportointia varten. Se muodostaa Power BI -tietomallin tietolähteen, joten analysoit Power BI:n käyttöä organisaatiossasi Power BI -tietomallin avulla. Perustietomallin ohjeet pätevät: Sinun tulee ottaa käyttöön tähtirakenne, joka on optimoitu suorituskykyä ja käytettävyyttä varten.

Voit luoda kootut tiedot eri tavoin. Sinun on päätettävä, miten tiedot integroidaan ja miten pitkälle ennen tähtirakenteeseen lataamista valmistelevat muunnokset on otettava käyttöön.

Data Lake -tallennustila

Voit käyttää muunnoksia ja luoda koostettuja datatiedostoja Data Lake -järjestelmässä. Käytä kultaista kerrosta kuratoituihin tietoihin niin, että se on loogisesti erillään pronssikerrokseen tallennetuista raakatiedoista. Tietojen erottaminen kerroksittain yksinkertaistaa myös eri käyttäjien käyttöoikeuksien määrittämistä.

Data Lake -tallennustilan avulla voit muuntaa ja koostaa tiedot seuraavissa tilanteissa:

• Oletat, että raportoinnin mahdollistavia Power BI -tietomalleja on useita (mikä oikeuttaa hopeisen välittäjäkerroksen luomisen).
• Sinun on tuettava useita omatoimisia sisällön tekijöitä, jotka tarvitsevat vuokraajatason valvontatietojen käyttöoikeuden.
• Sinulla on aiemmin luotuja työkaluja ja prosesseja, joiden avulla haluat muuntaa ja ladata tietoja.
• Haluat minimoida tietojen valmistelun, joka on tehtävä (ja mahdollisesti kaksoiskappaleita) yhdessä tai useammassa Power BI -tietomallissa.

Power BI -tietomalli

Saatat pystyä suorittamaan kaikki muunnostyöt Power BI:ssä. Power Queryn avulla voit käyttää ja muuntaa tietoja sen raakatilasta koostettuun muotoon.

Käytä Power BI -tietomallia, kun:

• Haluat yksinkertaistaa alusta loppuun -arkkitehtuuria ja ladata tietomallin suoraan raakatiedoista. (Lisäävä päivitys voi auttaa lyhentämään päivitysten kestoa.)
• Suosit sitä, että teet kaikki muunnostyöt tietomallin lataamisen aikana.
• Sinulla odotetaan olevan yksi keskitetty tietomalli vuokraajatason valvontatieduksille. Kaikki raportit (tai muut tietomallit) voivat käyttää lähteenään keskitettyä Power BI -semanttista mallia.
• Haluat antaa käyttäjälle käyttöoikeuden vain keskitettyyn Power BI:n semanttiseen malliin (etkä mihinkään lähdetietoon).

Vihje

Kun luot valitut tiedot, määritä ne siten, että voit helposti suorittaa prosessin uudelleen aiemmille päivämääräalueille. Jos esimerkiksi huomaat, että uusi määrite näkyi valvontalokeissa kolme kuukautta sitten, haluat pystyä analysoimaan sitä siitä lähtien, kun se ilmestyi ensimmäisen kerran. Kuratoidun tietohistorian lataaminen uudelleen on yksi monista syistä, miksi on tärkeää tallentaa raakatiedot niiden alkuperäisessä tilassa (kuvattiin aiemmin tässä artikkelissa).

Lisätietoja siitä, mitä dimensiotaulukoita ja faktataulukoita voit sisällyttää tähtirakenteeseen, on jäljempänä tässä artikkelissa olevassa kohdassa Tietomallin luominen.

Tarkistusluettelo – Kun suunnittelet koostettujen tietojen luomista, tärkeimmät päätökset ja toiminnot ovat seuraavat:

• Päätä, mihin muunnokset tulisi tehdä: Mieti, miten pitkälle muuntamistyö tulisi tehdä ja mihin se sopii koko arkkitehtuurin suunnitelmassasi.
• Päätä, millä työkalulla tiedot muunnetaan tähtirakenteeksi: Varmista, mitä työkaluja ja palveluita käytetään raakatietojen muuntamiseen kootuiksi tiedoiksi.
• Päätä, mihin kootut tiedot tallennetaan: Määritä paras vaihtoehto tähtirakenteeksi muunnetun raakadatan tallentamiseen. Päätä, onko välittäjän hopeakerros hyödyllinen päästä päähän -arkkitehtuurissa.
• Nimeämiskäytännön luominen: Selvitä, mitä nimeämiskäytäntöä käytetään kootuissa datatiedostoissa ja kansioissa (jos sovellettavissa). Sisällytä tiedot tekniseen dokumentaatioon.
• Harkitse, miten kootut tiedot toimivat: Kun suunnittelet kootun tietojen tallennussijaintia, mieti, kenen on käytettävä tietoja ja miten suojaus määritetään.

Tietolähdepäätökset

Tässä vaiheessa sinun tulee olla selvillä vaatimuksista, tietotarpeista ja käyttöoikeuksista. Keskeisiä teknisiä päätöksiä on tehty. Sinun on nyt tehtävä joitakin päätöksiä siitä, miten saat tietyntyyppisiä tietoja.

Käyttäjän toimintatietojen käyttäminen

Power BI:n käyttäjän toimintatiedot, joita kutsutaan joskus toimintolokeiksi tai valvontalokeiksi, sisältävät runsaasti tietoja, joiden avulla voit ymmärtää, mitä Power BI -vuokraajassasi tapahtuu. Lisätietoja tietotarpeiden tunnistamisesta on tämän artikkelin kohdassa Käyttäjän toimintatiedot .

Power BI integroi lokinsa Microsoft Purview'n yhdistettyihin valvontalokeihin (tunnettiin aiemmin nimellä Microsoft 365:n yhdistetty valvontaloki). Tämä integrointi on etu, koska se tarkoittaa, että jokaisen Microsoft 365 -palvelun ei tarvitse ottaa käyttöön omaa ainutlaatuista kirjaamistapaansa. Se on oletusarvoisesti käytössä.

Tärkeä

Jos et vielä poimi käyttäjien toimintatietoja, aseta ne kiireelliseksi prioriteetiksi. Käyttäjän toimintatiedot ovat käytettävissä viimeisimmät 30 tai 90 päivää (lähteestä riippuen). Vaikka et olisikaan valmis tekemään perusteellisia analyyseja, on tärkeää aloittaa tietojen purkaminen ja tallentaminen mahdollisimman pian. Näin analysoitavissa on arvokasta historiaa.

Sinulla on useita vaihtoehtoja käyttäjän toimintotietojen noutamiseen.

Tekniikka	Kuvaus	Käytettävissä olevien historiapäivien oletuspäivät	Hyvä valinta manuaalisille valvontaprosesseille	Hyvä valinta automatisoituihin valvontaprosesseihin	Hyvä valinta hälytysten määrittämiseksi	Hyvä valinta aloittaa nopeasti
Manuaalinen (käyttöliittymä)	Microsoft Purview -vaatimustenmukaisuusportaali	90
Manuaalinen (käyttöliittymä)	Defender for Cloud Apps	30
Ohjelmallinen	Power BI:n toimintoloki (ohjelmointirajapinta tai PowerShellin cmdlet-komento)	30
Ohjelmallinen	Office 365:n hallintatoimintojen ohjelmointirajapinta	7
Ohjelmallinen	Microsoft Sentinel (Azure Monitor)	30

Tämän osion loppuosassa esitellään kaikki taulukossa esitetyt menetelmät.

Microsoft Purview -vaatimustenmukaisuusportaali

Microsoft Purview -yhteensopivuusportaalin hakutyökalu (aiemmalta nimeltään Microsoft 365 -yhteensopivuuskeskus) on kätevä paikka tarkastella toimintoja ja hälytyksiä. Tämä työkalu ei edellytä komentosarjan luomista tietojen poimimista ja lataamista varten. Voit valita Power BI -kuormituksen, jos haluat tarkastella kaikkia valvontalokin tietueita tietyllä ajanjaksolla. Voit myös rajata tuloksia valitsemalla tietyt toiminnot ja käyttäjät. Esimerkiksi esimies pyytää sinua selvittämään, kuka on poistanut työtilan aiemmin kyseisenä päivänä, jotta hän voi nopeasti ottaa yhteyttä henkilöön ja keskustella tilanteesta.

Viimeisimmät 90 päivää historiaa ovat käytettävissä Audit (Standard) -kohteella. Audit (Premium)-toiminnolla pitkän aikavälin säilytys mahdollistaa valvontalokien säilyttämisen (valinnaisesti) pidempään. Koska pitkäaikainen säilytys koskee vain lisensoituja E5-käyttäjiä, se ei sisällä muiden kuin E5-käyttäjien ja vieraskäyttäjien valvontatietueita. Siksi suosittelemme, että luotat vain oletusarvoiseen 90 päivän historiaan sen varmistamiseksi, että kaikki toiminta siepataan.

Microsoft Purview -yhteensopivuusportaalin valvontalokien käyttämiseen liittyy käyttöoikeusvaatimuksia . Valvontalokien käyttäminen edellyttää myös laajennettuja Exchange Online -käyttöoikeuksia .

Vihje

Oletusarvoisesti Power BI -järjestelmänvalvojilla ei ole oikeuksia käyttää yhdistettyä valvontalokihakua Microsoft Purview -yhteensopivuusportaalissa. Koska se sisältää tietoja useista Microsoft 365 -palveluista, se on hyvin tärkeä rooli. Useimmissa organisaatioissa nämä oikeudet on varattu pienelle määrälle IT-järjestelmänvalvojia. Power BI -järjestelmänvalvojilla on käytettävissään myös muita vaihtoehtoja, jotka kuvataan myöhemmin tässä osiossa.

Microsoft Purview -yhteensopivuusportaalin käyttöliittymästä on hyötyä manuaalisissa valvontaprosesseissa ja käyttäjien toiminnan satunnaisissa tutkimuksissa.

Defender for Cloud Apps

Defender for Cloud Appsin portaali on kätevä paikka tarkastella toimintoja ja hälytyksiä ilman, että sinun tarvitsee luoda komentosarjaa tietojen poimimista ja lataamista varten. Sen avulla voit myös tarkastella Tietoja Power BI:n toimintolokista ja käyttäjien kirjautumisista.

Defender for Cloud Apps sisältää käyttöliittymän, jossa voit tarkastella ja hakea eri pilvipalveluiden, kuten Power BI:n, toimintalokeja. Se näyttää samat lokitapahtumat, jotka ovat peräisin Microsoft Purview'n yhdistetystä valvontalokista, ja se sisältää muita tapahtumia, kuten käyttäjän kirjautumistoiminnan Microsoft Entra -tunnuksesta.

Kuten Microsoft Purview -yhteensopivuusportaalissa (kuvattiin edellisessä osiossa), Defender for Cloud Appsilla on haettavissa oleva käyttöliittymä. Suodatinasetukset ovat kuitenkin erilaiset. Defender for Cloud Appsin avulla voit normaalin 30 päivän historian lisäksi tarkastella jopa kuuden kuukauden toimintalokihistoriaa (seitsemän päivän lisäyksinä).

Defender for Cloud Appsin käyttämiseen liittyy käyttöoikeusvaatimuksia . Myös erilliset käyttöoikeudet vaaditaan.

Vihje

Oletusarvoisesti Power BI -järjestelmänvalvojilla ei ole Defender for Cloud Apps -käyttöoikeutta. Defender for Cloud Appsissa on Power BI:n rooli . Power BI -järjestelmänvalvojien lisääminen tähän rooliin on hyvä tapa myöntää heille käyttöoikeus rajoitettuun tietojoukkoon.

Defender for Cloud Appsin käyttöliittymä on hyödyllinen manuaalisissa valvontaprosesseissa ja käyttäjien toiminnan kertaluonteisissa tutkimuksissa.

Power BI:n toimintoloki

Power BI:n toimintoloki on peräisin yhdistetystä valvontalokista. Se sisältää vain Power BI teenus liittyvät käyttäjätoiminnot.

Vihje

Jos organisaatio suunnittelee käyttäjätoimintojen poimimista, suosittelemme, että ne aloittavat Power BI:n toimintolokista. Se on yksinkertaisin lähde, jota voi käyttää ohjelmallisesti.

Voit käyttää Power BI:n toimintolokia kahdella eri tavalla.

• Kutsu Hae toimintatapahtumat REST-ohjelmointirajapinta käyttämällä haluamaasi työkalua.
• Käytä Get-PowerBIActivityEvent PowerShellin cmdlet-komentoa. Se on käytettävissä Power BI:n hallinnan hallintamoduulista.

Lisätietoja käytettävästä vaihtoehdosta on tämän artikkelin kohdassa Ohjelmointirajapintojen tai PowerShellin cmdlet-komentojen valitseminen.

Vihje

Esimerkkejä Power BI:n toimintolokin käytöstä PowerShellin avulla on artikkelissa Power BI:n toimintolokin käyttäminen.

Power BI:n toimintolokin tiedot ovat kaikkien Power BI -järjestelmänvalvojien, Power Platform -järjestelmänvalvojien ja globaaleiden järjestelmänvalvojien käytettävissä. Tietoja voidaan käyttää yhdistetystä valvontalokista, joka on käytettävissä tietyissä Exchange Online -rooleissa. Lisätietoja on artikkelissa Käyttäjien toiminnan seuraaminen Power BI:ssä.

Suosittelemme, että käytät Power BI:n toimintolokia, kun aiot noutaa vain Power BI -valvontalokitietueet.

Muistiinpano

Valvontalokitiedoissa työtiloja kutsutaan kansioiksi. Power BI REST -ohjelmointirajapinnassa työtiloja kutsutaan ryhmiksi.

Office 365:n hallintatoimintojen ohjelmointirajapinta

Voit poimia tietoja yhdistetystä valvontalokista muille palveluille, kuten SharePoint Onlinelle, Teamsille, Exchange Onlinelle, Dynamics 365:lle ja Power BI:lle. Kun haluat ottaa käyttöön valvonta- ja valvontaratkaisun useille palveluille, on suositeltavaa käyttää Office 365: n hallintatoimintojen ohjelmointirajapintaa. Koska tämä ohjelmointirajapinta palauttaa tietoja monista palveluista, sitä kutsutaan Unified Auditing -ohjelmointirajapinnaksi (tai yhtenäiseksi valvontalokiksi). Se on yksi Office 365:n hallinnan ohjelmointirajapinnoista.

Ennen kuin luot uuden ratkaisun, suosittelemme ottamaan yhteyttä IT-osastoon ja määrittämään, onko olemassa olevia Power BI -valvontatietueita käytettävissä. On mahdollista, että prosessi poimii ja tallentaa tiedot jo. On myös mahdollista, että saatat saada oikeuden käyttää näitä tietoja uuden ratkaisun luomisen sijaan.

Voit käyttää tietoja jomminkin kahdella tavalla.

• Kutsu Office 365:n hallintatoimintojen ohjelmointirajapinta suoraan käyttämällä haluamaasi työkalua. Ohjelmointirajapinta palauttaa oletusarvoisesti 24 tuntia tietoja. Voit noutaa enintään seitsemän päivän historian.
• Käytä Search-UnifiedAuditLog PowerShell-cmdlet-komentoa. Se on Exchange Onlinen PowerShell-cmdlet-komento. Voit noutaa enintään 90 päivän historian.

Tärkeä

Cmdlet-komento Search-UnifiedAuditLog ei skaalaudu hyvin, ja se edellyttää silmukkastrategian käyttöönottoa sen 5 000 rivin rajan ylittämiseksi. Tästä syystä se soveltuu satunnaisesti kyselyihin tai pieniin organisaatioihin, joiden toiminta on vähäistä. Kun tarvitset vain Power BI -tietoja, suosittelemme käyttämään sen sijaan Get-PowerBIActivityEvent-cmdlet-komentoa .

Office 365:n hallintatoimintojen ohjelmointirajapinnan käytön aloittaminen on yleensä haastavampaa kuin Power BI:n toimintalokin käyttäminen (kuvattu aiemmin). Tämä johtuu siitä, että ohjelmointirajapinta palauttaa sisällön blob-objektit ja kukin sisällön blob-objekti sisältää yksittäisiä valvontatietueita. Suurissa organisaatioissa voi olla tuhansia sisällön blob-objekita päivässä. Koska asiakkaat ja kolmannen osapuolen sovellukset käyttävät tätä ohjelmointirajapintaa voimakkaasti, Microsoft toteuttaa rajoittamista varmistaakseen, että palvelun käyttö ei vaikuta haitallisesti muihin (kutsutaan meluisan naapurin ongelmaksi). Näin ollen suurten historiamäärien noutaminen voi olla haaste suuremmissa organisaatioissa. Lisätietoja on tässä vianmääritysartikkelissa.

Jotta voit käyttää tätä ohjelmointirajapintaa, sinun täytyy todentautua palvelun päänimellä, jolle on myönnetty oikeus noutaa tietoja Office 365 :n hallintatoimintojen ohjelmointirajapinnasta.

Vihje

Oletusarvoisesti Power BI -järjestelmänvalvojilla ei ole Office 365:n hallintatoimintojen ohjelmointirajapinnan käyttöoikeuksia. Koska se sisältää tietoja monelle Microsoft 365 -palvelulle, käyttö edellyttää korkean tason järjestelmänvalvojaa tai valvontaroolia. Useimmissa organisaatioissa nämä roolit on varattu pienelle määrälle IT-järjestelmänvalvojia. Power BI:n toimintaloki on tarkoitettu Power BI:n järjestelmänvalvojien käytettäväksi.

Valvontatietojen noutaminen ohjelmallisesti Office 365:n hallintatoiminnon ohjelmointirajapinnasta on hyvä valinta, kun IT-virasto poimii ja tallentaa valvontalokeja eri palveluista (Power BI:n ulkopuolella).

Microsoft Sentinel

Microsoft Sentinel on Azure-palvelu, jonka avulla voit kerätä, tunnistaa, tutkia ja vastata suojaustapauksiin ja uhkiin. Voit määrittää Power BI:n Microsoft Sentinelissä tietoyhdistimenä. Kun yhteys on muodostettu, valvontalokit (jotka sisältävät tietojen alijoukon) virtautetaan Power BI:stä Azure Log Analyticsiin, joka on Azure Monitorin toiminto.

Vihje

Azure Log Analytics perustuu samaan arkkitehtuuriin, jota käytetään työtilatason semanttisen mallin tapahtumalokeissa. Lisätietoja semanttisen mallin tapahtumalokeista on kohdassa Tietotason valvonta.

Koska kyseessä on erillinen Azure-palvelu, kaikille järjestelmänvalvojille tai käyttäjille, joiden haluat suorittavan Kusto Query Language (KQL) -kyselyjä, on myönnettävä käyttöoikeudet Azure Log Analyticsiin (Azure Monitor). Kun heillä on käyttöoikeus, he voivat tehdä kyselyjä PowerBIActivity-taulukkoon tallennetuista valvontatiedoista. Muista kuitenkin, että useimmissa tapauksissa myönnät käyttäjille käyttöoikeuden kuratoituihin tietoihin kultakerroksessa pronssikerroksen raakatietojen sijaan.

KQL:n avulla voit analysoida toimintolokitapahtumia, jotka on tallennettu Azure Log Analyticsiin. Jos sinulla on SQL-kokemusta, löydät paljon samankaltaisuuksia KQL:n kanssa.

Azure Log Analyticsiin tallennettuja tapahtumia voi käyttää useilla tavoilla. Seuraavia voi käyttää:

• Valmis Log Analytics Power BI:n semanttisille malleille -mallisovellus.
• Power BI Desktop -liitin Azure Data Explorerille (Kusto).
• Verkkopohjainen kyselykokemus Azure Data Explorerissa.
• Mikä tahansa kyselytyökalu, joka voi lähettää KQL-kyselyjä.

Varoitus

Huomaa, että vain osa Power BI:n toimintolokitiedoista tallennetaan Azure Monitoriin. Kun aiot tehdä kattavan analyysin Power BI:n käytöstä ja käyttöönotosta organisaatiossa, suosittelemme, että käytät muita vaihtoehtoja (kuvattu aiemmin tässä osiossa) toimintotietojen noutamiseen.

Noudettavissa oleva historiajakso riippuu Azure Log Analytics -työtilan tietojen säilytyskäytännöstä . Harkitse raakatietojen kustannuksia ja käyttöoikeuksia päätettäessä siitä, kuinka paljon tietoja säilytetään.

Microsoft Sentinel ja Azure Monitor ovat hyviä vaihtoehtoja, kun IT-organisaatio on jo investoinut Microsoft Sentineliin, kaapatut tiedot vastaavat tarpeitasi ja toiminta, kuten uhkien havaitseminen , ovat prioriteetteja. Koska Microsoft Sentinel ei kuitenkaan tallenna kaikkia Power BI:n toimintotietoja, se ei tue kattavan analyysin tekemistä Power BI:n käytöstä ja käyttöönotosta.

Käyttäjän toiminnan tietojen huomioitavat seikat

Seuraavassa on joitakin huomioon otettavia seikkoja, joiden avulla voit valita lähteen käyttäjän toimintatiedoilla.

• Onko kyseessä manuaalinen vai automaattinen valvontaprosessi? Käyttöliittymän asetukset toimivat hyvin manuaalisissa valvontaprosesseissa ja satunnaisissa kertaluonteisissa kyselyissä, erityisesti silloin, kun sinun on tutkittava tiettyä toimintaa. Myös automaattinen valvontaprosessi, joka poimii käyttäjän toimintatiedot aikataulun mukaisesti, on tarpeen historiatietojen analysoinnin tukemiseksi.
• Kuinka usein tarvitset käyttäjän toimintatietoja? Jos käytät automatisoituja valvontaprosesseja, aiot poimia tiedot, jotka ovat vähintään päivää ennen nykyistä päivää, käyttämällä UTC (Coordinated Universal Time) -aikaa paikallisesta ajastasi alkaen. Jos prosessisi suoritetaan esimerkiksi perjantaiaamuna (UTC-aikaa), poimi tiedot keskiviikosta. On useita syitä, miksi sinun kannattaa poimia tiedot yhden päivän viiveellä.
  • Tiedostoja on helpompi käsitellä, kun purat aina täydet 24 tuntia kerrallaan, jolloin vältetään osittaiset päivän tulokset.
  • Pienennät joidenkin valvontatapahtumien puuttumisen riskin. Yleensä seurantatapahtumat saapuvat 30 minuutin kuluessa. Toisinaan yhtenäiseen valvontalokiin saapuminen voi kestää jopa 24 tuntia.
• Tarvitsetko muutakin kuin Power BI -tietoja? Harkitse tehokkainta tapaa käyttää mitä tarvitset.
  • Kun tarvitset vain Power BI:n käyttäjän toimintatietoja, käytä Power BI:n toimintolokia.
  • Kun tarvitset valvontalokeja useista palveluista, käytä Office 365:n hallintatoimintojen ohjelmointirajapintaa yhtenäisen valvontalokin käyttämiseen.
• Kuka kehittää ratkaisun? Aiomme käyttää jonkin aikaa ratkaisun rakentamiseen. Tuotantovalmiin komentosarjan luominen voi kestää huomattavasti.

Tarkistusluettelo – Kun suunnittelet käyttäjien toimintatietojen käyttöä, tärkeimmät päätökset ja toiminnot ovat seuraavat:

• Selventää tarpeiden kattavuutta: Selvitä, onko sinun käytettävä vain Power BI -valvontatietueita vai useiden palvelujen tietoja.
• Konsultoi IT-alaa: Selvitä, poimiiko IT tällä hetkellä valvontalokeja ja onko mahdollista saada raakatietojen käyttöoikeus, jotta sinun ei tarvitse luoda uutta ratkaisua.
• Päätä tietolähteestä: Määritä paras lähde, jota käytetään käyttäjän toimintatietojen käyttämiseen.
• Viimeistele soveltuvuusselvitys: Suunnittele pienen teknisen soveltuvuusselvityksen valmistumista. Sen avulla voit vahvistaa päätöksesi lopullisen ratkaisun luomisesta.
• Seuraa lisätietotarpeita: Voit korreloida toimintolokin tiedot muihin lähteisiin tietojen arvon parantamiseksi. Seuraa näitä mahdollisuuksia niiden ilmaantuessa, jotta ne voivat lisätä projektisi vaikutusaluetta.

Vuokraajavaraston tietojen käyttö

Vuokraajavarasto on korvaamaton ja välttämätön osa kypsää valvonta- ja valvontaratkaisua. Se auttaa ymmärtämään, mitä työtiloja ja sisältöä (semanttiset mallit, raportit ja muut kohteet) Power BI:ssä on, ja se on erinomainen täydennys käyttäjän toimintatietoihin (kuvattu edellisessä osiossa). Lisätietoja tietotarpeiden tunnistamisesta on tämän artikkelin kohdassa Vuokraajaluettelo .

Käyttäjän toimia (aiemmin kuvattu) ovat valvottuja tapahtumia; Ne ovat tietue toiminnoista, jotka käyttäjä teki tiettynä päivänä ja tiettynä ajankohtana. Vuokraajavarasto on kuitenkin erilainen. Vuokraajavarasto on tilannevedos tietyllä hetkellä. Se kuvaa kaikkien Power BI teenus julkaistujen kohteiden nykyisen tilan poimimishetkellä.

Muistiinpano

Power BI:n REST-ohjelmointirajapinnan dokumentaatio viittaa julkaistuihin kohteisiin artefakteina.

Vihje

Monien organisaatioiden mielestä on hyödyllistä poimia vuokraajaluettelo samaan aikaan päivästä joka viikko.

Jotta voit analysoida oikein Power BI -vuokraajan tapahtumia, tarvitset sekä käyttäjän toimintatiedot että vuokraajavaraston. Yhdistämällä ne ymmärrät, kuinka paljon sisältöä sinulla on ja missä se sijaitsee. Sen avulla voit myös etsiä käyttämätöntä tai vajaakäyttöistä sisältöä (koska sille ei ole tapahtumia toimintolokissa). Vuokraajavaraston avulla voit myös kääntää luettelon kaikkien kohteiden nykyisistä nimistä, mikä on hyödyllistä kohteiden nimien muuttuessa.

Lisätietoja vuokraajavaraston arvosta on tämän artikkelin kohdassa Vuokraajavarasto .

Vihje

Järjestelmänvalvojan ohjelmointirajapinnana voit käyttää Nouda käyttämättömät artefaktit -toimintoa etsiäksesi kohteita, joiden käyttäjä ei ole tehnyt toimia viimeisten 30 päivän aikana. Et kuitenkaan voi mukauttaa kyseistä ajanjaksoa. Sinulla voi olla esimerkiksi kriittistä sisältöä, jota käytetään vain neljännesvuosittain. Yhdistämällä vuokraajavaraston käyttäjän toimintatietoihin voit etsiä käyttämättömiä kohteita mukauttamalla.

Voit hankkia vuokraajan varastotiedot kahdella eri tavalla.

Tekniikka	Kuvaus	Soveltuu parhaiten	Hyvä valinta manuaalisille valvontaprosesseille	Hyvä valinta automatisoituihin valvontaprosesseihin
Ohjelmallinen	Ohjelmointirajapinta Get Groups as Admin tai Get-PowerBIWorkspace PowerShellin cmdlet-komento voi tarjota luettelon työtiloista koko vuokraajalle. Vaihtoehtoisesti voit sisällyttää mukaan yksittäisiä kohteita (kuten semanttisia malleja ja raportteja) per työtila.	Pienemmät organisaatiot tai pieni tietomäärä
Ohjelmallinen	Joukko asynkronisia järjestelmänvalvojan ohjelmointirajapintoja, joita kutsutaan yhteisesti metatietojen skannauksen ohjelmointirajapinnoiksi tai skannerin ohjelmointirajapinnoiksi, voi palauttaa luettelon työtiloista ja yksittäisistä kohteista. Vaihtoehtoisesti myös yksityiskohtaiset metatiedot (kuten taulukot, sarakkeet ja mittarilausekkeet) voidaan sisällyttää.	Organisaatiot, joiden tietomäärä on suuri ja/tai joiden on saatava yksityiskohtaisia tuloksia

Tämän osion loppuosassa esitellään kaikki taulukossa esitetyt menetelmät.

Ryhmien ohjelmointirajapinnat tai työtilat, cmdlet

Voit noutaa työtilojen luettelon käyttämällä jotakin useista REST-ohjelmointirajapinnoista, kuten Hae ryhmät järjestelmänvalvojan ohjelmointirajapintana ( käyttämällä haluamaasi työkalua). Tulokset sisältävät ylimääräisiä metatietoja, kuten kuvauksen ja sen, onko työtila tallennettu Premium-kapasiteettiin.

Muistiinpano

Nimetty ohjelmointirajapinta sisältää termiryhmän viitteenä työtilaan. Tämä termi on peräisin alkuperäisestä Power BI -suojausmallista, joka oli riippuvainen Microsoft 365 -ryhmistä. Vaikka Power BI:n suojausmalli on kehittynyt huomattavasti vuosien varrella, olemassa olevat ohjelmointirajapinnat pysyvät muuttumattomina, jotta olemassa olevia ratkaisuja ei rikota.

REST-ohjelmointirajapinta Get Groups as Admin sisältää hyödyllisen $expand parametrin. Tämän parametrin avulla voit halutessasi laajentaa tuloksia niin, että ne sisältävät luettelon työtilaan julkaistuista kohteista (kuten semanttiset mallit ja raportit). Voit myös välittää users tietotyypin parametriin $expand sisältämään käyttäjät, jotka on määritetty työtilan rooliin.

Voit myös käyttää Get-PowerBIWorkspace PowerShell -cmdlet-komentoa. Se on Power BI:n hallintatyötilat -moduulista. Kun määrität parametrin -Scopeorganization, se toimii ohjelmointirajapinnan Get Groups as Admin tavoin. Cmdlet-komento hyväksyy myös parametrin -Include (joka vastaa REST-ohjelmointirajapinnan $expand parametria) sisällyttävän työtilaan julkaistuja kohteita (kuten semanttisia malleja ja raportteja).

Vihje

Välittämällä parametrit voit käyttää cmdlet-komentoa eri tavoilla. Tässä osiossa keskitytään vuokraajan laajuisen varaston noutamiseen. Lisätietoja parametrin -Scopekäyttämisestä on edellä tämän artikkelin kohdassa Käyttäjän ohjelmointirajapinnan tai järjestelmänvalvojan ohjelmointirajapinnan valitseminen.

Jos haluat ohjeita käytettävän vaihtoehdon valitsemiseen, katso tämän artikkelin aiempi osio Ohjelmointirajapintojen tai PowerShellin cmdlet-komentojen valitseminen.

REST-ohjelmointirajapinta Get Groups as Admin tai Get-PowerBIWorkspace PowerShellin cmdlet-komento sopii parhaiten manuaalisiin valvontaprosesseihin ja kertaluonteisiin tutkimuksiin. Suurten tietomääriä sisältävien organisaatioiden käyttö on yleensä haastavaa. REST-ohjelmointirajapinta ja cmdlet-komento poimivat aina koko tietojoukon, joten niiden suorittaminen voi kestää kauan. On siis todennäköistä, että suuriin organisaatioihin liittyy tuntikohtaisia sallittujen pyyntöjen määrää koskevia rajoituksia (kutsutaan rajoitkseksi, joka tehdään palvelun kunnon suojaamiseksi). Metatietojen skannauksen ohjelmointirajapinnat (kuvattu seuraavaksi) tarjoavat luotettavamman ja skaalattavamman vaihtoehdon.

Metatietojen skannaamisen ohjelmointirajapinnat

Metatietojen skannauksen ohjelmointirajapinnat, joita kutsutaan yleisesti skannerin ohjelmointirajapinneiksi, ovat ohjelmointirajapintoja, jotka palauttavat luettelon työtiloista ja niiden Power BI -kohteista (semanttiset mallit, raportit ja muut kohteet). Käsitteellisesti ne antavat samat tiedot (ja enemmänkin) kuin ryhmien ohjelmointirajapinnat tai työtilan cmdlet-komennot, jotka on kuvattu edellisessä osiossa. Tietojen noutamiseen käytettävä menetelmä on kuitenkin erilainen ja soveltuu paremmin vuokraajavaraston poimimiseen.

Muistiinpano

Huomaa, miten jotkut käyttäjät käyttävät termiä skannerin ohjelmointirajapinnat tai lauseen skannaamista vuokraajassa. Nämä termit tarkoittavat usein vuokraajaluettelon kääntämistä ja erottamista käyttäjän toimintotapahtumista. He saattavat viitata tai eivät ehkä viittaa metatietojen skannauksen ohjelmointirajapintojen käyttöön.

On kaksi ensisijaista syytä, miksi kannattaa harkita metatietojen skannauksen ohjelmointirajapintojen käyttöä REST-ohjelmointirajapinnan tai cmdlet-komennon Get-PowerBIWorkspace sijasta Get Groups as Admin (kuvattu aiemmin).

• Lisäävä tieto poiminta: Skannerin ohjelmointirajapinnat poimivat vain tiedot, jotka ovat muuttuneet sen edellisen suorituskertojen jälkeen. REST-ohjelmointirajapinta ja Get-PowerBIWorkspace cmdlet ovat synkronisia Get Groups as Admin toimintoja, jotka poimivat koko tietojoukon aina, kun niitä suoritetaan.
• Tarkempia tietoja: Skannerin ohjelmointirajapinnat voivat hakea eriytettyjä tietoja (kuten taulukoita, sarakkeita ja mittarilausekkeita), kunhan kaksi vuokraaja-asetusta myöntää oikeuden yksityiskohtaisia metatietoja varten. Sitä vastoin REST-ohjelmointirajapinnan ja Get-PowerBIWorkspace cmdlet-komennon käytettävissä olevien Get Groups as Admin tietojen pienin taso on kohdetyypin mukaan (esimerkiksi luettelo työtilan raporteista).

Skannerin ohjelmointirajapintojen käyttäminen vaatii enemmän vaivaa, koska sinun on kutsuttava ohjelmointirajapintojen sarja. Lisäksi ne suoritetaan asynkronisena prosessina . Asynkroninen prosessi suoritetaan taustalla, joten sinun ei tarvitse odottaa sen päättymistä. Saatat joutua tekemään yhteistyötä IT:n tai kehittäjän kanssa, kun on aika luoda ajoitettu tuotantovalmis komentosarja.

Seuraavassa on vaiheet, joita prosessisi tulee noudattaa, kun käytät skannerin ohjelmointirajapintoja.

1. Kirjaudu sisään: Kirjaudu sisään Power BI teenus käyttämällä Power BI -järjestelmänvalvojatiliä tai palvelun päänimeä, jolla on oikeus suorittaa järjestelmänvalvojan ohjelmointirajapintoja. Lisätietoja on tämän artikkelin aiemmassa kohdassa Todennusmenetelmän määrittäminen.
2. Työtilatunnukset: Lähetä pyyntö, jotta voit noutaa työtilan tunnusten luettelon. Kun se suoritetaan ensimmäisen kerran, sinulla ei ole muokkauspäivämäärää, joten se palauttaa täydellisen luettelon työtiloista. Yleensä ohitat muokkauspäivämäärän ja haet vain ne työtilat, jotka ovat muuttuneet sen jälkeen. Muokkauspäivämäärän on oltava viimeisten 30 päivän aikana.
3. Aloita metatietojen skannaus: Aloita kutsu , joka pyytää työtilan tietojen skannausta välittämällä vaiheessa 2 noudetut työtilatunnukset. Huomaa, että tämä on POST-ohjelmointirajapinta (GET-ohjelmointirajapinnan sijaan, joka on yleisempi valvontatietoja noudettaessa). POST-ohjelmointirajapinta on HTTP-pyyntö, joka luo tai kirjoittaa määritetyn resurssin tietoja. Tämä kysely määrittää poimittavan yksityiskohtaisuustason, kuten tietolähteen tiedot, semanttisen mallin rakenteen, semanttiset mallilausekkeet tai käyttäjät. Ohjelmointirajapinta palauttaa skannauksen tunnuksen lähettämisen yhteydessä. Se palauttaa myös skannauksen päivämäärän ja ajan, jotka sinun tulee tallentaa tilannevedoksen päivämääräksi.
4. Tarkista skannauksen tila: saat skannauksen tilan käyttämällä vaiheessa 3 saatua skannaustunnusta. Saatat joutua kutsumaan tätä ohjelmointirajapintaa useammin kuin kerran. Kun palautettu tila on Onnistui, voit siirtyä seuraavaan vaiheeseen. Skannaamiseen kuluva aika riippuu siitä, kuinka paljon tietoja pyydät.
5. Hae tulokset: Käytä vaiheessa 3 saatua skannaustunnusta saadaksesi skannauksen tuloksen ja poimiaksesi tiedot. Tämä vaihe on suoritettava 24 tunnin kuluessa siitä, kun vaihe 4 on suoritettu. Muista, että tilannevedosaikaleiman tulee korreloitua vaiheen 3 kanssa vaiheen 5 sijaan (jos viive on merkittävä). Näin saat tarkan tilannevedoksen aikaleiman. Tallenna tulokset haluamaasi tietojen tallennussijaintiin. Kuten tässä artikkelissa on jo kuvattu, suosittelemme, että tallennat raakatiedot niiden alkuperäisessä tilassa.
6. Valmistaudu seuraavaan prosessiin: Tallenna skannauksen aikaleima vaiheesta 3, jotta voit käyttää sitä vaiheessa 2, kun suoritat prosessin seuraavan kerran. Tällä tavoin poimit vain tiedot, jotka ovat muuttuneet sen ajan jälkeen. Jatkossa kaikki myöhemmät tietouutteet ovat lisääviä muutoksia täysien tilannevedosten sijaan.

Tarkistusluettelo – Vuokraajan varastotietojen käyttöä suunniteltaessa tärkeimmät päätökset ja toiminnot ovat seuraavat:

• Vahvista vaatimukset: Selvitä vuokraajaluettelon kääntämistarpeet ja tietojen analyyttiset vaatimukset.
• Valitse vuokraajavaraston poimintataajuus: Tarkista, kuinka usein tarvitset uuden vuokraajaluettelon (esimerkiksi joka viikko).
• Päätä, miten poimitaan vuokraajaluettelo: Tarkista, millä menetelmällä hankit vuokraajavaraston tiedot (ohjelmointirajapinta, cmdlet-komento tai metatietojen skannaamisen ohjelmointirajapinnat).
• Viimeistele soveltuvuusselvitys: Suunnittele pienen teknisen soveltuvuusselvityksen valmistumista. Sen avulla voit vahvistaa päätöksesi lopullisen ratkaisun luomisesta.

Käyttäjän ja ryhmän tietojen käyttäminen

Käyttäjän toimintatietoihin sisältyvien tunnistamistietojen (kuten sähköpostiosoitteen) lisäksi on arvokasta hakea lisätietoja, kuten sijaintitietoja tai organisaation tietoja. Microsoft Graphin avulla voit hakea tietoja käyttäjistä, ryhmistä, palvelun päänimistä ja käyttöoikeuksista. Microsoft Graph koostuu ohjelmointirajapinnoista ja asiakaskirjastoista, joiden avulla voit noutaa valvontatietoja monista eri palveluista.

Seuraavassa on joitakin tietoja Microsoft Entra -objekteista, joita voit käyttää.

• Käyttäjä: Microsoft Entra -tunnuksella oleva käyttäjätieto työpaikan, oppilaitoksen tai Microsoft-tilinä. Termiä toimialueen käyttäjä käytetään usein kuvaamaan organisaation käyttäjiä, kun taas muodollinen termi on käyttäjän päänimi (UPN). UpN on yleensä sama arvo kuin käyttäjän sähköpostiosoite (jos sähköpostiosoite kuitenkin muuttuu, upn ei muutu, koska se on muuttumaton). Saatavilla on myös yksilöivä Microsoft Graph -tunnus kullekin käyttäjälle. Käyttäjätili on usein liitetty yhteen henkilöön. Jotkin organisaatiot luovat käyttäjiä, jotka ovat palvelutilejä , joita käytetään automaattisissa toiminnoissa tai hallintatehtävissä.
• Palvelun päänimi: Erityyppiset käyttäjätiedot, jotka valmistellaan, kun luot sovelluksen rekisteröinnin. Palvelun päänimi on tarkoitettu valvomattomille ja automaattisille toiminnoille. Lisätietoja on tämän artikkelin aiemmassa kohdassa Todennusmenetelmän määrittäminen.
• Ryhmä: tämä on kokoelma käyttäjiä ja palvelun päänimiä. Voit yksinkertaistaa käyttöoikeuksien hallintaa useilla erityyppisillä ryhmillä. Lisätietoja on artikkelissa Ryhmien käyttöstrategia.

Muistiinpano

Kun tässä artikkelissa viitataan käyttäjiin ja ryhmiin, tämä termi sisältää myös palvelun päänimet. Tätä lyhyempää termiä käytetään lyhyyden vuoksi.

Käyttäjät ja ryhmät, jotka noudat, ovat tilannevedos , joka kuvaa nykyistä tilaa tiettynä ajankohtana.

Vihje

Lisätietoja käyttäjistä, palvelun päänimistä ja ryhmistä on artikkelissa Microsoft Entra -tunnuksen integrointi.

Analyyttiset määritteet

Jos käytät Power BI -vuokraajatason valvontaa, voit poimia ja tallentaa seuraavat määritteet Microsoft Graphista.

• Käyttäjien koko nimi: Useissa tietolähteissä on vain toiminnon suorittaneen tai rooliin määritetyn käyttäjän sähköpostiosoite. Käytä tätä määritettä, kun haluat näyttää koko nimen (näyttönimi) analyysiraporteissa. Koko nimen käyttäminen tekee raporteista käyttäjäystävällisempiä.
• Muut käyttäjän ominaisuudet: Muita käyttäjiä kuvaavia määritteitä voi olla käytettävissä Microsoft Entra -tunnuksella. Esimerkkejä analyyttisia arvoja analyyttisesti arvokkaista käyttäjäprofiilimääritteistä ovat työnimike, osasto, esimies, alue ja toimistosijainti.
• Käyttöoikeusryhmän jäsenet: Useimmat tietolähteet antavat ryhmän nimen (esimerkiksi Power BI:n toimintolokitietueet, jotka käyttöoikeusryhmä on määrittänyt työtilan rooliin). Ryhmän jäsenyyden noutaminen parantaa kykyäsi analysoida täysin, mitä yksittäinen käyttäjä tekee tai mihin hänellä on käyttöoikeus.
• Käyttöoikeudet: On hyödyllistä analysoida, mitkä käyttöoikeudet ( ilmainen, Power BI Pro tai käyttäjäkohtainen Power BI Premium (PPU) on määritetty käyttäjille. Näiden tietojen avulla voit tunnistaa, ketkä eivät käytä heidän käyttöoikeuttaan. Se auttaa myös analysoimaan kaikkia käyttäjiä (erillisiä käyttäjiä, joilla on käyttöoikeus) verrattuna aktiivisiin käyttäjiin (viimeisimmissä toimissa). Jos harkitset Power BI Premium -käyttöoikeuksien lisäämistä tai laajentamista, suosittelemme, että analysoit käyttäjän käyttöoikeustiedot yhdessä käyttäjien toimintatietojen kanssa kustannusanalyysin suorittamiseksi.
• Järjestelmänvalvojaroolien jäsenet: Voit koota luettelon Power BI -järjestelmänvalvojistasi (joka sisältää Power Platform -järjestelmänvalvojat ja yleiset järjestelmänvalvojat).

Lisätietoja Power BI -käyttöoikeustiedoista, jotka löytyvät Microsoft Graphin valvontatiedoista, on artikkelissa Tuotenimet ja palvelupaketin tunnisteet lisensointia varten.

Vihje

Jäsenten hakeminen ryhmistä voi olla yksi haastavimmista valvontatietojen saamisesta. Sinun on tehtävä transitiivinen haku , jotta kaikki sisäkkäisiä jäseniä ja sisäkkäisiä ryhmiä voidaan tasoittaa. Voit tehdä transitiivinen haun ryhmän jäsenille. Tämäntyyppinen haku on erityisen haastavaa, kun organisaatiossasi on tuhansia ryhmiä. Tässä tapauksessa voisi olla parempia vaihtoehtoja tietojen noutamiseen. Yksi vaihtoehto on poimia kaikki ryhmät ja ryhmän jäsenet Microsoft Graphista. Se ei välttämättä kuitenkaan ole käytännöllistä, kun Power BI:n suojauksessa käytetään vain pientä määrää ryhmiä. Toinen vaihtoehto on luoda viittausluettelo ryhmistä, joita käytetään missä tahansa Power BI -suojauksessa (työtilan roolit, sovelluksen käyttöoikeudet, kohdekohtainen jakaminen, rivitason suojaus ja muut). Voit sitten suorittaa viiteluettelon läpi, jos haluat hakea ryhmän jäsenet Microsoft Graphista.

Seuraavassa on joitakin muita määritteitä, jotka voit poimia ja tallentaa.

• Käyttäjätyyppi: Käyttäjät ovat joko jäseniä tai vieraita. Yleensä jäsenet ovat sisäisiä käyttäjiä, ja vieraat ovat ulkoisia (B2B) käyttäjiä. Käyttäjätyypin tallentamisesta on hyötyä, kun sinun on analysoitava ulkoisten käyttäjien toimia.
• Roolin muutokset: Kun suoritat suojauksen valvonnan, on hyödyllistä ymmärtää, milloin käyttäjä on muuttanut rooleja organisaatiossa (esimerkiksi siirryttäessä eri osastolle). Näin voit tarkistaa, ovatko niiden Power BI -suojausasetukset päivitetty – vai pitääkö niitä päivittää.
• Käytöstä poistetut käyttäjät: Kun käyttäjä poistuu organisaatiosta, järjestelmänvalvoja yleensä poistaa hänen tilinsä käytöstä. Voit luoda prosessin sen tarkistamiseksi, ovatko käytöstä poistetut käyttäjät työtilan järjestelmänvalvojia vai semanttisen mallin omistajia.

Vihje

Power BI:n toimintaloki sisältää tapahtuman, joka kirjaa, kun käyttäjä rekisteröityy kokeiluversion käyttöoikeuden käyttäjäksi. Voit yhdistää kyseisen tapahtuman käyttäjän käyttöoikeustietoihin (Microsoft Entra -tunnuksesta) kokonaiskuvan tuottamiseksi.

Käyttäjien ja ryhmien tietojen noutaminen

Voit noutaa käyttäjiä ja ryhmiä koskevia tietoja eri tavoilla.

Tekniikka	Kuvaus	Hyvä valinta manuaalisille valvontaprosesseille	Hyvä valinta automatisoituihin valvontaprosesseihin
Manuaalinen	Kaavioiden hallinta
Ohjelmallinen	Microsoft Graph -ohjelmointirajapinnat ja SDK:t
Ohjelmallinen	Az PowerShell -moduuli

Tämän osion loppuosassa esitellään kaikki taulukossa esitetyt menetelmät. Muut tekniikat, jotka on poistettu käytöstä ja joita ei tule käyttää uusissa ratkaisuissa, kuvataan tämän osion lopussa.

Muistiinpano

Ole varovainen, kun luet tietoja verkosta, koska monet työkalun nimet ovat samankaltaisia. Jotkin Microsoftin ekosysteemin työkalut sisältävät termin Graph nimessään, kuten Azure Resource Graph, GraphQL ja Microsoft Security Graph -ohjelmointirajapinta. Nämä työkalut eivät liity Microsoft Graphiin, ja ne eivät kuulu tämän artikkelin piiriin.

Microsoft Graph Explorer

Microsoft Graph Explorer on kehittäjätyökalu, jonka avulla voit tutustua Microsoft Graph -ohjelmointirajapintoihin. Se on yksinkertainen tapa päästä alkuun, koska se ei vaadi muita työkaluja tai määritystä tietokoneessasi. Voit kirjautua sisään tietojen noutamiseksi vuokraajasta tai noutaa mallitiedot oletusvuokraajalta.

Graph Explorerin avulla voit tehdä seuraavaa:

• Lähetä pyyntö manuaalisesti Microsoft Graph -ohjelmointirajapintaan, jotta voit tarkistaa, palauttaako se haluamasi tiedot.
• Katso, miten voit muodostaa URL-osoitteen, otsikot ja leipätekstin, ennen kuin kirjoitat komentosarjan.
• Tarkista tiedot epävirallisesti.
• Selvitä, mitkä käyttöoikeudet vaaditaan kullekin ohjelmointirajapinnalle. Voit myös antaa luvan uusiin käyttöoikeuksiin.
• Hanki komentosarjoja luotaessa käytettäviä koodikatkelmia.

Tämän linkin avulla voit avata Graph Explorerin.

Microsoft Graph -ohjelmointirajapinnat ja SDK:t

Voit noutaa käyttäjien ja ryhmien tietoja Microsoft Graph -ohjelmointirajapintojen avulla. Sen avulla voit myös noutaa tietoja palveluista, kuten Microsoft Entra -tunnuksesta, SharePoint Onlinesta, Teamsista, Exchangesta, Outlookista ja niin edelleen.

Microsoft Graph SDKt toimivat ohjelmointirajapinnan paketoijana pohjana olevien Microsoft Graph -ohjelmointirajapintojen lisäksi. SDK on ohjelmistokehityspaketti , joka niputtaa työkalut ja toiminnot yhteen. Microsoft Graph SDKt paljastavat kaikki Microsoft Graph -ohjelmointirajapinnat.

Voit halutessasi lähettää pyyntöjä suoraan ohjelmointirajapintoihin. Vaihtoehtoisesti voit lisätä yksinkertaistamiskerroksen käyttämällä haluamaasi kieltä ja jotakin SDK:ta. Lisätietoja on tämän artikkelin kohdassa Ohjelmointirajapintojen tai PowerShellin cmdlet-komentojen valitseminen.

Microsoft Graph SDKt tukevat useita kieliä, ja saatavilla on myös Microsoft Graph PowerShell -moduuleja. Muut SDK:t ovat käytettävissä Pythonille, C#:lle ja muille kielille.

Tärkeä

Microsoft Graph PowerShell -moduuli korvaa Azure AD:n PowerShell-moduulit ja MSOnline (MSOL) -moduulit, jotka ovat molemmat vanhentuneet. Sinun ei kannata luoda uusia ratkaisuja vanhentuneilla moduuleilla. Microsoft Graph PowerShell -moduuli sisältää monia ominaisuuksia ja etuja. Lisätietoja on artikkelissa Päivitys Azure AD PowerShellistä Microsoft Graph PowerShelliin.

Voit asentaa Microsoft Graph PowerShell -moduulit PowerShell-valikoimasta. Koska Microsoft Graph toimii useiden Microsoft 365 -palvelujen kanssa, asennat useita PowerShell-moduuleja.

Tässä ovat yleisimmät PowerShell-moduulit, jotka sinun on asennettava Power BI -vuokraajatason valvontaa varten.

• Todentaminen (sisäänkirjautumista varten)
• Käyttäjät
• Ryhmät
• Sovellukset (ja palvelun päänimet)
• Hakemistoobjektit (ja käyttöoikeustiedot)

Vihje

Microsoft päivittää Microsoft Graph PowerShell -moduulit säännöllisesti. Joskus esikatselumoduulit ovat käytettävissä ennen julkaisua tai beetapäätepisteenä. Haluat ehkä määrittää version, jota haluat käyttää, kun asennat ja päivität moduuleja. Kun tarkistat online-dokumentaatiota, huomaa, että nykyinen versionumero liitetään automaattisesti URL-osoitteen loppuun (joten ole varovainen, kun tallennat tai jaat URL-osoitteita).

Az PowerShell -moduuli

Voit myös käyttää Az PowerShell -moduulia käyttäjien ja ryhmien tietojen noutamiseen. Se keskittyy Azure-resursseihin.

Tärkeä

Az PowerShell -moduuli korvaa vanhentuneet AzureRM:n PowerShell-moduulit. Sinun ei kannata luoda uusia ratkaisuja vanhentuneilla moduuleilla.

Voit käyttää Invoke-AzRestMethod-cmdlet-komentoa , jos ohjelmointirajapinnalle ei ole vastaavaa cmdlet-komentoa. Se on joustava lähestymistapa, jonka avulla voit lähettää pyynnön mihin tahansa Microsoft Graph -ohjelmointirajapintaan käyttämällä Az PowerShell -moduulia.

Az-versiosta 7 alkaen Az cmdlet -komennot viittaavat nyt Microsoft Graph -ohjelmointirajapintaan. Siksi Az-moduuli toimii ohjelmointirajapinnan paketoijana Microsoft Graphin päällä. Az-moduuleissa on toiminnallisuuden alijoukko, joka sisältyy Microsoft Graph -ohjelmointirajapintoihin ja PowerShell-moduuleihin. Suosittelemme, että käytät uusia ratkaisuja Microsoft Graph PowerShell SDK:ta.

Vanhentuneet ohjelmointirajapinnat ja moduulit

Verkossa saattaa olla artikkeleita ja blogikirjoituksia, jotka ehdottavat vaihtoehtoisia vaihtoehtoja, joita ei esitetä tässä osiossa. Suosittelemme vahvasti, että et luo uusia ratkaisuja (ja/tai siirrä olemassa olevia ratkaisuja) minkään seuraavien ohjelmointirajapintojen tai moduulien avulla.

• AzureRM PowerShell -moduulit: Vanhentunut ja poistetaan käytöstä. Ne on korvattu Az PowerShell -moduulilla.
• Azure AD Graph -ohjelmointirajapinta ja Azure AD:n PowerShell-moduuli: Vanhentunut ja poistetaan käytöstä. Tämä muutos on seurausta siirtymisestä Azure AD Graphista Microsoft Graphiin (huomaa, että Graph näkyy molemmilla nimillä, mutta Microsoft Graph on tuleva suunta). Kaikki tulevat PowerShell-sijoitukset tehdään Microsoft Graph PowerShell SDK:ssa. (Microsoft Entra ID tunnetaan nyt nimellä Microsoft Entra ID.)
• MS Online (MSOL) PowerShell -moduuli: Vanhentunut ja poistetaan käytöstä. Kaikki tulevat PowerShell-sijoitukset tehdään Microsoft Graph PowerShell SDK:ssa.

Varoitus

Muista vahvistaa käyttämäsi vanhentuneen ohjelmointirajapinnan tai moduulin tila. Lisätietoja AzureRM :n käytöstä siirtymisestä on tässä ilmoituksessa.

Lisätietoja Microsoft Entra -tunnuksesta ja MSOL: sta on tässä eläköitymisilmoitusten kirjoituksessa.

Jos sinulla on kysyttävää tai tarvitset selvennystä tulevaan ohjelmallisen tietojen käytön suuntaan, ota yhteyttä Microsoft-tilitiimiisi.

Tarkistusluettelo – Kun suunnittelet käyttäjien ja ryhmien tietojen käyttöä, tärkeimmät päätökset ja toiminnot ovat seuraavat:

• Vahvista vaatimukset: Selvitä käyttäjiin, ryhmiin ja käyttöoikeuksiin liittyvien tietojen kääntämistarpeet.
• Priorisoi vaatimukset: Varmista tärkeimmät prioriteetit, jotta tiedät, mitä käyttää aluksi.
• Valitse tietojen poimimistiheys: Määritä, kuinka usein tarvitset uuden tilannevedoksen käyttäjien ja ryhmien tiedoista (esimerkiksi joka viikko tai joka kuukausi).
• Päätä, miten voit poimia tiedot Microsoft Graphin avulla: Selvitä, mitä menetelmää käytät tietojen noutamiseen.
• Viimeistele soveltuvuusselvitys: Suunnittele pienen teknisen soveltuvuusselvityksen (POC) valmistumista käyttäjien ja ryhmätietojen poimimiseksi. Sen avulla voit vahvistaa päätöksesi lopullisen ratkaisun luomisesta.

Tietojen käyttäminen Power BI REST -ohjelmointirajapinnoista

Alhaisemmalla prioriteetilla voit myös noutaa muita tietoja Power BI REST -ohjelmointirajapinnoilla.

Voit esimerkiksi noutaa tietoja:

• Kaikki organisaation sovellukset .
• Kaikki tuodut semanttiset mallit organisaatiossa.
• Kaikki organisaation käyttöönottoputket .
• Kaikki organisaation Premium-kapasiteetit.

Suojausvalvonnan aikana saatat haluta tunnistaa:

• Kohteet, joita on jaettu laajalti koko organisaation kanssa.
• Kohteet, jotka ovat käytettävissä julkisessa Internetissä käyttämällä Julkaise verkkoon -toimintoa.

Lisätietoja muista ohjelmointirajapintojen tyypeistä on tämän artikkelin aiemmassa kohdassa Käyttäjän ohjelmointirajapinnan tai järjestelmänvalvojan ohjelmointirajapinnan valitseminen.

Tarkistusluettelo – Kun suunnittelet tietojen käyttöä Power BI -ohjelmointirajapinnoista, tärkeimmät päätökset ja toiminnot ovat seuraavat:

• Hanki vaatimukset: Käännä analyysin vaatimukset sellaisina kuin ne tulevat esiin. Pidä kirjaa niistä keskeneräisten logien kanssa.
• Priorisoi vaatimukset: Määritä prioriteetit nouseville uusille vaatimuksille.

Vaihe 2: Edellytykset ja määritys

Vuokraajatason valvontaratkaisun suunnittelun ja toteuttamisen toisessa vaiheessa keskitytään edellytyksiä ja määrityksiä, jotka on tehtävä ennen ratkaisun kehittämisen aloittamista.

Tallennustilin luominen

Tässä vaiheessa olet päättänyt, mikä sijainti on raakatietojen tallennussijainti ja miten luodaan koostettuja tietoja. Näiden päätösten perusteella olet nyt valmis luomaan tallennustilin. Organisaation prosesseista riippuen siihen voi sisältyä pyynnön lähettäminen IT-organisaatioon.

Kuten aiemmin kuvattiin, suosittelemme käyttämään tekniikkaa, jonka avulla voit kirjoittaa raakatiedot muuttumattomaan tallennustilaan. Kun tiedot on kirjoitettu, niitä ei voi muuttaa eikä poistaa. Voit luottaa raakatietoihin, koska tiedät, että järjestelmänvalvoja, jolla on käyttöoikeus, ei voi muuttaa sitä millään tavalla. Kootut tiedot eivät kuitenkaan (yleensä) tarvitse tallentaa muuttumattomaan tallennustilaan. Kootut tiedot saattavat muuttua tai ne voidaan luoda uudelleen.

Tarkistusluettelo – Tallennustiliä luotaessa tärkeimpiä päätöksiä ja toimintoja ovat seuraavat:

• Luo tallennustili: Luo tai lähetä pyyntö tallennustilin luomista varten. Käytä raakadatan muuttumattomia tallennusasetuksia aina, kun se on mahdollista.
• Määritä käyttöoikeudet: Määritä, mitkä käyttöoikeudet tallennustilille tulisi määrittää.
• Testaa käyttö: Tee pieni testi varmistaaksesi, että voit lukea tallennustiliä ja kirjoittaa siihen.
• Varmista vastuut: Varmista, että olet selvillä siitä, kuka hallitsee tallennustiliä jatkuvasti.

Asentaa ohjelmistoja ja määrittää palveluita

Tässä vaiheessa olet tehnyt päätöksesi siitä, mitä teknologiaa käytetään valvontatietojen käyttöön. Näiden päätösten perusteella olet nyt valmis asentamaan ohjelmistoja ja määrittämään palveluita.

Määritä kullekin järjestelmänvalvojalle haluamasi kehitysympäristö. Kehitysympäristön avulla he voivat kirjoittaa ja testata komentosarjoja. Visual Studio Code on moderni työkalu komentosarjojen kehittämiseen, joten se on hyvä vaihtoehto. Visual Studio Codessa voi myös käyttää monia laajennuksia.

Jos olet päättänyt käyttää PowerShelliä (aiemmin kuvattu), asenna PowerShell Core ja tarvittavat PowerShell-moduulit:

• Jokaisen järjestelmänvalvojan/kehittäjän kone, joka kirjoittaa tai testaa komentosarjoja.
• Jokainen näennäiskone tai palvelin, joka suorittaa ajoitettuja komentosarjoja.
• Kukin verkkopalvelu (kuten Azure’i funktsioonid tai Azure Automation).

Jos olet valinnut jonkin Azure-palvelun (kuten Azure’i funktsioonid, Azure Automationin, Azure Data Factoryn tai Azure Synapse Analyticsin), sinun tulee valmistella ja määrittää nekin.

Tarkistusluettelo – Kun asennat ohjelmistoa ja määrität palveluita, tärkeimmät päätökset ja toiminnot ovat seuraavat:

• Määritä järjestelmänvalvoja- tai kehittäjäkoneet: Asenna tarvittaessa kehitystyössä käytettävät työkalut.
• Määritä palvelimet: Asenna tarvittaessa tarvittavat työkalut kaikkiin palvelimiin tai näennäiskoneisiin, joita arkkitehtuurissasi on.
• Määritä Azure-palvelut: Jos sovellettavissa, valmistele ja määritä kukin Azure-palvelu. Määritä käyttöoikeudet kullekin kehitystyötä tekevälle järjestelmänvalvojalle tai kehittäjälle.

Microsoft Entra -sovelluksen rekisteröinti

Tässä vaiheessa olet päättänyt , miten todennetaan. Suosittelemme, että rekisteröit Microsoft Entra -sovelluksen (palvelun päänimi). Sitä kutsutaan yleisesti sovelluksen rekisteröinniksi, ja sitä tulee käyttää automatisoitaville valvomattomille toiminnoille.

Lisätietoja sovelluksen rekisteröinnin luomisesta vuokraajatason valvontatietojen noutamista varten on artikkelissa Palvelun päänimen todentamisen käyttöönotto vain luku -oikeutetuille järjestelmänvalvojan ohjelmointirajapinnoille.

Tarkistusluettelo – Kun Microsoft Entra -sovellus rekisteröidään, tärkeimmät päätökset ja toiminnot ovat seuraavat:

• Tarkista, onko olemassa oleva sovelluksen rekisteröinti olemassa: Tarkista IT-valvojalta, onko olemassa oleva sovelluksen rekisteröinti käytettävissä järjestelmänvalvojan ohjelmointirajapintojen suorittamista varten. Jos on, määritä, käytetäänkö olemassa olevaa vai pitääkö uusi luoda.
• Luo uusi sovellusrekisteröinti: Luo sovelluksen rekisteröinti tarvittaessa. Harkitse sovelluksen nimen käyttämistä, kuten PowerBI-AdminAPIs-EntraApp, joka kuvaa selvästi sen tarkoitusta.
• Luo salaisuus sovelluksen rekisteröinnille: Kun sovellusrekisteröinti on olemassa, luo sille salaisuus. Määritä vanhentumispäivä sen perusteella, kuinka usein aiot kiertää salaisen koodin.
• Tallenna arvot turvallisesti: Tallenna salauskoodi, sovellustunnus (asiakastunnus) ja vuokraajatunnus, koska tarvitset niitä todentamiseen palvelun päänimen avulla. Käytä suojattua sijaintia, kuten organisaation salasanavarastoa. (Jos sinun on pyydettävä sovelluksen rekisteröintiä IT-osoitteesta, määritä, että nämä arvot on palautettava sinulle.)
• Luo käyttöoikeusryhmä: Luo (tai pyydä) käyttöoikeusryhmä, jota käytetään Power BI:ssä. Harkitse ryhmän nimen käyttämistä, kuten Power BI -järjestelmänvalvojan palvelun päänimiä, mikä tarkoittaa, että ryhmää käytetään vuokraajan laajuisten metatietojen käyttämiseen.
• Lisää palvelun päänimi käyttöoikeusryhmän jäseneksi: lisää uusi käyttöoikeusryhmä uuden käyttöoikeusryhmän jäseneksi sovellustunnuksen (asiakastunnuksen) avulla.
• Päivitä järjestelmänvalvojan ohjelmointirajapinnan vuokraaja-asetus Power BI:ssä: Lisää Power BI -hallintaportaalissa käyttöoikeusryhmä Salli palvelun päänimien käyttää Vain luku -tilassa olevia Power BI -järjestelmänvalvojan ohjelmointirajapintoja -vuokraaja-asetukseen.
• Ohita käyttöoikeuksien määrittäminen Azuressa: Älä delegoi sovelluksen rekisteröinnin käyttöoikeuksia (se saa käyttöoikeuden Power BI -vuokraajatason valvontatietoihin Power BI :n avulla Salli palvelun päänimien käyttää Vain luku -tilassa olevia Power BI -järjestelmänvalvojan ohjelmointirajapintojen vuokraaja-asetusta ).
• Päätä, tuleeko sovelluksen rekisteröinnin käyttää yksityiskohtaisia metatietoja: Määritä, haluatko poimia yksityiskohtaisia tietoja semanttisista mallitaulukoista, sarakkeista ja mittarilausekkeista, kun luot vuokraajavarastoa.
• Päivitä yksityiskohtaiset metatietojen vuokraaja-asetukset Power BI:ssä: Halutessasi voit lisätä Power BI -hallintaportaalissa käyttöoikeusryhmän Parannukset järjestelmänvalvojan ohjelmointirajapinnan vastauksiin yksityiskohtaisilla metatietovuokraajan asetuksista ja myös Järjestelmänvalvojan ohjelmointirajapinnan vastausten parantaminen DAX- ja koostelausekkeiden vuokraaja-asetuksista .
• Testaa palvelun päänimeä: Luo yksinkertainen komentosarja, jotta voit kirjautua sisään palvelun päänimellä, ja testaa, että se voi noutaa tietoja järjestelmänvalvojan ohjelmointirajapinnasta.
• Luo prosessi sovellusten rekisteröintisalaisuuksien hallitsemiseksi: Luo dokumentaatio ja prosessi salaisten koodien säännöllistä kiertämistä varten. Määritä, miten viestität turvallisesti uuden salaisen koodin järjestelmänvalvojille ja kehittäjille, jotka tarvitsevat sitä.

Power BI -vuokraajan asetusten määrittäminen

Power BI -hallintaportaalissa on useita vuokraaja-asetuksia, jotka koskevat vuokraajatason valvontatietojen purkamista.

Järjestelmänvalvojan ohjelmointirajapinnat

Vuokraajan asetuksia on kolme, jotka soveltuvat järjestelmänvalvojan ohjelmointirajapintojen suorittamiseen.

Tärkeä

Koska nämä asetukset myöntävät metatieto-käyttöoikeuden koko vuokraajalle (määrittämättä suoria Power BI -käyttöoikeuksia), sinun kannattaa hallita niitä tiukasti.

Salli palvelun päänimien käyttää Vain luku -tilassa olevia Power BI -järjestelmänvalvojan ohjelmointirajapintoja -vuokraaja-asetuksen avulla voit määrittää, mitkä palvelun päänimet voivat kutsua järjestelmänvalvojan ohjelmointirajapintoja. Tämän asetuksen avulla Microsoft Purview voi myös skannata koko Power BI -vuokraajan niin, että se voi täyttää tietoluettelon.

Muistiinpano

Sinun ei tarvitse erikseen määrittää muita Power BI -järjestelmänvalvojia kohtaan Salli palvelun päänimien käyttää Vain luku -tilassa olevia Power BI -järjestelmänvalvojan ohjelmointirajapintoja -vuokraaja-asetusta, koska heillä on jo vuokraajan laajuisten metatietojen käyttöoikeus.

Järjestelmänvalvojan ohjelmointirajapinnan vastausten ja yksityiskohtaisten metatietojen vuokraaja-asetuksen avulla voit määrittää, ketkä käyttäjät ja palvelun päänimet voivat noutaa yksityiskohtaisia metatietoja. Metatiedot noudetaan käyttämällä metatietojen skannauksen ohjelmointirajapintoja, ja se sisältää taulukoita, sarakkeita ja paljon muuta. Tämän asetuksen avulla Microsoft Purview voi myös käyttää Power BI:n semanttisten mallien rakennetason tietoja niin, että se voidaan tallentaa tietoluetteloon.

Järjestelmänvalvojan ohjelmointirajapinnan vastausten parantaminen DAX- ja koostelausekkeiden vuokraaja-asetuksella voit määrittää, ketkä käyttäjät ja palvelun päänimet voivat noutaa yksityiskohtaisia metatietoja. Metatiedot noudetaan metatietojen skannauksen ohjelmointirajapinnoista, ja ne voivat sisältää kyselyjä ja semanttisen mallin mittarilausekkeita.

Muistiinpano

Salli palvelun päänimien käyttää Vain luku -tilassa olevia Power BI -järjestelmänvalvojan ohjelmointirajapintoja -vuokraaja-asetus koskee erityisesti järjestelmänvalvojan ohjelmointirajapintojen käyttöä. Sen nimi on hyvin samankaltainen kuin vuokraaja-asetus, joka on tarkoitettu käyttäjien ohjelmointirajapintojen käyttöön (kuvaillaan seuraavaksi). Lisätietoja järjestelmänvalvojan ohjelmointirajapintojen ja käyttäjien ohjelmointirajapintojen eroista on tämän artikkelin aiemmassa kohdassa Valitse käyttäjän ohjelmointirajapinta tai järjestelmänvalvojan ohjelmointirajapinta .

Käyttäjien ohjelmointirajapinnat

Käytössä on yksi vuokraaja-asetus, joka koskee käyttäjän ohjelmointirajapintojen kutsumista. Tässä tilanteessa Power BI -käyttöoikeudet vaaditaan myös palvelun päänimelle (esimerkiksi työtilan roolille).

Salli palvelun päänimien käyttää Power BI -ohjelmointirajapintoja -vuokraaja-asetuksen avulla voit määrittää, millä palvelun päänimillä on käyttöoikeus REST-ohjelmointirajapintojen suorittamiseen (lukuun ottamatta järjestelmänvalvojan ohjelmointirajapintoja, jotka myönnetään eri vuokraaja-asetuksella yllä kuvatulla tavalla).

Ohjelmointirajapintoihin liittyy muitakin vuokraaja-asetuksia, joiden avulla voit käyttää upotuskäyttörajapintoja, suoratoiston ohjelmointirajapintoja, viedä ohjelmointirajapintoja ja suorituskyselyjen ohjelmointirajapintaa . Nämä ohjelmointirajapinnat eivät kuitenkaan kuulu tässä artikkelissa käsiteltyihin ohjelmointirajapintoihin.

Lisätietoja käyttötietojen vuokraaja-asetuksista on kohdassa Raporttitason valvonta.

Tarkistusluettelo – Kun määrität Power BI -vuokraajan asetuksia, tärkeimmät päätökset ja toiminnot ovat seuraavat:

• Varmista, että kukin palvelun päänimi on oikeassa ryhmässä: Varmista, että Power BI -järjestelmänvalvojan palvelujen päänimien ryhmä sisältää oikeat palvelun päänimet.
• Päivitä järjestelmänvalvojan ohjelmointirajapinnan vuokraaja-asetus Power BI:ssä: Lisää käyttöoikeusryhmä kohtaan Salli palvelun päänimien käyttää Vain luku -muotoisia Power BI -järjestelmänvalvojan ohjelmointirajapintoja -vuokraaja-asetusta, jolloin järjestelmänvalvojan ohjelmointirajapintojen avulla voidaan hakea koko vuokraajan laajuiset metatiedot.
• Päivitä yksityiskohtaiset metatietovuokraajan asetukset Power BI:ssä: Lisää tarvittaessa käyttöoikeusryhmä Parannukset järjestelmänvalvojan ohjelmointirajapinnan vastauksiin yksityiskohtaisilla metatietovuokraajan asetuksissa ja Järjestelmänvalvojan ohjelmointirajapinnan vastausten parantaminen DAX- ja koostelausekkeiden vuokraaja-asetuksissa .
• Vahvista, mitä käyttäjien ohjelmointirajapintoja käytetään: Tarkista, tarvitaanko vähintään yksi käyttäjän ohjelmointirajapinta (lisäksi järjestelmänvalvojan ohjelmointirajapintojen avulla).
• Päivitä käyttäjän ohjelmointirajapinnan vuokraaja-asetus Power BI:ssä: Lisää käyttöoikeusryhmä Salli palvelun päänimien käyttää Power BI -ohjelmointirajapintoja -vuokraaja-asetukseen, joka on tarkoitettu käyttäjän ohjelmointirajapinnoille.

Vaihe 3: Ratkaisun kehittäminen ja analysointi

Vuokraajatason valvontaratkaisun suunnittelun ja toteutuksen kolmannessa vaiheessa keskitytään ratkaisun kehittämiseen ja analytiikkaan. Tässä vaiheessa kaikki suunnittelu ja päätöksenteko on tapahtunut, ja olet täyttänyt edellytykset ja suorittanut määritykset. Olet nyt valmis aloittamaan ratkaisun kehittämisen, jotta voit suorittaa analyyseja ja saada merkityksellisiä tietoja valvontatiedoistasi.

Raakatietojen poimiminen ja tallentaminen

Tässä vaiheessa vaatimustesi ja prioriteettiesi on oltava selkeitä. Tärkeimmät tekniset päätökset on tehty valvontatietojen käytöstä ja valvontatietojen tallennussijainnista. Ensisijaiset työkalut on valittu ja edellytykset ja asetukset on määritetty. Kahden edellisen vaiheen aikana olet saattanut suorittaa yhden tai useamman pienen projektin (soveltuvuusselvitys) toteutettavuuden osoittamiseksi. Seuraava vaihe on määrittää prosessi, joka poimii ja tallentaa raakavalvontatiedot.

Kuten useimpien Microsoftin ohjelmointirajapintojen palauttamissa tiedoissa, valvontatiedot muotoillaan JSON-muotoon. JSON-muotoiltu tieto on kuvaavaa, koska se on ihmisen luettavissa olevaa tekstiä, joka sisältää rakennetta ja tietoa.

JSON edustaa tietoobjekteja, jotka koostuvat määrite–arvo-pareista ja matriiseista. Tämä on esimerkki, "state": "Active" jossa tilamääritteen arvo on aktiivinen. JSON-matriisi sisältää järjestetyn luettelon pilkulla eroteltuista elementeistä, jotka on suljettu hakasulkeisiin ([ ]). On tavallista etsiä sisäkkäisiä matriiseja JSON-tuloksista. Kun olet tutustunut JSON-tuloksen hierarkkiseen rakenteeseen, sinun on helppo ymmärtää tietorakennetta, kuten työtilan semanttisten mallien luettelo (matriisi).

Seuraavassa on joitakin huomioon otettavia seikkoja, kun poimit ja tallennat ohjelmointirajapinnoista noudettuja raakatietoja.

• Mitä nimeämiskäytäntöä käytetään? Tiedostopohjaisessa järjestelmässä nimeämiskäytäntö on välttämätön tiedosto-, kansio- ja Data Lake -vyöhykkeille. Tietokannassa nimeämiskäytäntö on välttämätön taulukoille ja sarakkeille.
• Mitä muotoa käytetään raakatietojen tallentamiseen? Kun Power BI esittelee edelleen uusia ominaisuuksia, uusia toimintoja ei enää ole olemassa. Tästä syystä suosittelemme, että poimit ja säilytät alkuperäiset JSON-tulokset. Älä jäsentä, suodata tai muotoile tietoja, kun ne on poimittu. Tällä tavalla voit käyttää alkuperäistä raakadataa valvotun valvontatietosi uudelleen luontiin.
• Mitä tallennussijaintia käytetään? Data Lake- tai Blob-säilöä käytetään yleisesti raakadatan tallentamiseen. Lisätietoja on tämän artikkelin kohdassa Määritä valvontatietojen tallennuspaikka.
• Kuinka paljon historiaa tallennat? Vie valvontatiedot sijaintiin, johon voit tallentaa historian. Tarkoituksena on kerätä vähintään kahden vuoden historia. Näin voit analysoida trendejä ja muutoksia oletusarvoisen 30 päivän säilytysajan jälkeen. Voit halutessasi tallentaa tiedot loputtomiin, tai ehkä päätät lyhyemmästä ajanjaksosta organisaatiosi tietojen säilytyskäytäntöjen mukaan.
• Miten seurataan, milloin prosessi on viimeksi suoritettu? Määritä määritystiedosto tai sitä vastaava arvo, jos haluat tallentaa aikaleimat, kun prosessi käynnistyy ja päättyy. Seuraavan kerran kun prosessi suoritetaan, se voi noutaa nämä aikaleimat. On erityisen tärkeää tallentaa aikaleimat, kun poimit tietoja käyttämällä metatietojen skannauksen ohjelmointirajapintoja.
• Miten voit käsitellä rajoittamista? Jotkin Power BI REST -ohjelmointirajapinnat ja Microsoft Graph -ohjelmointirajapinta toteuttavat rajoittamista. Saat 429-virheen (liian monta pyyntöä), jos ohjelmointirajapintapyyntösi rajoitetaan. Rajoittaminen voi olla yleinen ongelma suuremmille organisaatioille, joiden on noudettava suuri määrä tietoja. Epäonnistuneiden yritysten välttäminen rajoittamisen vuoksi riippuu tekniikasta, jota käytät tietojen käyttämiseen ja purkamiseen. Yksi vaihtoehto on kehittää komentosarviin logiikka, joka vastaa 429 Liian monta pyyntöä -virheeseen, kun yrität uudelleen odotusajan jälkeen.
• Tarvitaanko vaatimustenmukaisuuteen tarvittavat valvontatiedot? Monet organisaatiot käyttävät raakavalvontalokitietueita vaatimustenmukaisuuden valvontaan tai tietoturvatutkimuksiin vastaamiseen. Näissä tapauksissa suosittelemme, että tallennat raakatiedot muuttumattomaan tallennustilaan. Tällä tavalla järjestelmänvalvoja tai muu käyttäjä ei voi muuttaa tai poistaa tietoja, kun ne on kirjoitettu.
• Mitä tallennuskerroksia tarvitaan tarpeidesi tukemiseen? Parhaat raakatietojen tallennuspaikat ovat Data Lake -tallennustila (kuten Azure Data Lake Storage Gen2) tai objektisäilö (kuten Azure Blob Storage). Tiedostojärjestelmää voi käyttää myös, jos pilvipalvelut eivät ole vaihtoehto.

Tarkistusluettelo – Kun poimit ja tallennat raakatietoja, tärkeimmät päätökset ja toiminnot ovat seuraavat:

• Vahvista vaatimukset ja prioriteetit: Selvitä ensin poimimiesi tietojen vaatimukset ja prioriteetit.
• Vahvista poimittavan tiedon lähde: Tarkista kunkin tietotyypin lähde.
• Määritä prosessi tietojen poimimiseksi ja lataamiseksi raakadatavyöhykkeelle: Luo alkuperäinen prosessi, jolla voit poimia ja ladata raakatiedot niiden alkuperäisessä tilassa ilman muunnoksia. Testaa, että prosessi toimii tarkoitetulla tavalla.
• Luo aikataulu prosessien suorittamiseksi: Määritä toistuva aikataulu poiminta-, lataus- ja muunnosprosessien suorittamiseksi.
• Varmista, että tunnistetietoja hallitaan turvallisesti: Varmista, että salasanat, salasanat ja avaimet tallennetaan ja välitetään turvallisesti.
• Varmista, että suojaus on määritetty oikein: Varmista, että raakadatan käyttöoikeudet on määritetty oikein. Varmista, että järjestelmänvalvojat ja tarkastajat voivat käyttää raakatietoja.

Lisätietoja siitä, miten valvontaratkaisu kasvaa ajan mittaan, on tämän artikkelin kohdassa Toiminnan tehostaminen ja parantaminen .

Koostettujen tietojen luominen

Tässä vaiheessa raakatiedot poimitaan ja tallennetaan. Seuraava vaihe on luoda erillinen kultainen tietokerros valituille tiedoille. Sen tavoitteena on muuntaa ja tallentaa datatiedostot tähtirakenteeseen. Tähtirakenne koostuu dimensiotaulukoista ja faktataulukoista, ja se on tarkoituksella optimoitu analysointia ja raportointia varten. Kootun tietotason tiedostoista tulee Power BI -tietomallin lähde (kuvataan seuraavassa aiheessa).

Vihje

Kun odotat, että tietomallia on useampi kuin yksi, sijoittaminen keskitettyun kootettuun tietokerrokseen on erityisen hyödyllistä.

Tarkistusluettelo – Kun luot koottua tietotasoa, tärkeimmät päätökset ja toiminnot ovat seuraavat:

• Vahvista vaatimukset ja prioriteetit: Jos aiot käyttää muunnetuille tiedoille hopeanvälistä kerrosta, selvitä sen edellytykset ja tavoitteet, mitä sinun on saavutettava.
• Määritä prosessi, jolla raakatiedot muunnetaan ja ladataan valittuun tietovyöhykkeeseen: Luo prosessi tietojen muuntamiseksi ja lataamiseksi tähtirakenteeseen. Testaa, että prosessi toimii tarkoitetulla tavalla.
• Luo aikataulu prosessien suorittamiseksi: Määritä toistuva aikataulu valittuun tietotasoon täyttämiseksi.
• Varmista, että suojaus on määritetty oikein: Varmista, että valittujen tietojen käyttöoikeudet on määritetty oikein. Varmista, että tietomallin kehittäjät voivat käyttää koostettuja tietoja.

Tietomallin luominen

Aiheena on analyyttisen tietomallin määrittäminen. Tietomalli on kyselyyn perustuva tietoresurssi, joka on optimoitu analyysia varten. Joskus sitä kutsutaan semanttiseksi malliksi tai yksinkertaisesti malliksi. Valvontaratkaisussasi tietomalli otetaan todennäköisesti käyttöön Power BI:n semanttisena mallina.

Valvonnan ja valvonnan kontekstissa tietomalli hankkii tiedot valvotusta (kultaisesta) tietokerroksesta. Jos päätät olla luomatta koottua tietotasoa, tietomalli hankkii tiedot suoraan raakatiedoista.

Suosittelemme, että Power BI -tietomallisi toteuttaa tähtirakenteen. Kun lähdetiedot ovat kootut tietotasot, Power BI -tietomallin tähtirakenteen pitäisi peilata koostetun tietotason tähtirakennetta.

Vihje

Tähtirakenteen yleiskatsaus on kohdassa Tutustu tähtirakenteeseen ja sen merkitykseen Power BI:ssä.

Kuten kaikkien Power BI -projektien kohdalla, tietomallin luominen on toistuva prosessi. Voit lisätä uusia mittareita tarpeen mukaan. Voit myös lisätä uusia taulukoita ja sarakkeita, kun uusia valvontatapahtumia tulee saataville. Ajan myötä saatat jopa integroida uusia tietolähteitä.

Seuraavassa on joitakin hyödyllisiä dimensiotaulukoita, joita voit sisällyttää tietomalliin.

• Päivämäärä: Päivämäärämääritteiden joukko, joka mahdollistaa tietojen analysoimisen (osituksen ja kuutioinnin) päivän, viikon, kuukauden, vuosineljänneksen, vuoden ja muiden olennaisten ajanjaksojen mukaan.
• Aika: Jos sinun on analysoitava kellonajan mukaan ja valvontatietoja on erittäin paljon, harkitse aikaosan tallentamista päivämäärästä erillisenä. Tämä lähestymistapa voi auttaa parantamaan kyselyn suorituskykyä.
• Käyttäjät: Ominaisuuksia, jotka kuvaavat käyttäjiä (kuten osasto ja maantieteellinen alue), jotka voivat suodattaa monia valvontatietojen koehenkilöitä. Tavoitteena on poistaa kaikki käyttäjätiedot faktataulukoista ja tallentaa ne tähän dimensiotaulukkoon, jotta ne voivat suodattaa useita faktataulukoita. Voit tallentaa tähän taulukkoon myös palvelun päänimiä.
• Toimintotapahtumat: Määritteet, jotka ryhmittelevät ja kuvaavat toimintotapahtumia (toimintoja). Voit parantaa raportointiasi luomalla tietohakemiston, joka kuvaa kutakin toimintotapahtumaa. Voit myös luoda hierarkian, joka ryhmittelee ja luokittelee samankaltaisia toimintotapahtumia. Voit esimerkiksi ryhmitellä kaikki kohteen luontitapahtumat, poistaa tapahtumia ja niin edelleen.
• Työtilat: luettelo vuokraajan ja työtilan ominaisuuksien työtiloista, kuten tyyppi (henkilökohtainen tai vakio) ja kuvaus. Jotkin organisaatiot tallentavat lisätietoja työtiloista (mahdollisesti SharePoint-luettelon avulla). Voit integroida nämä tiedot tähän dimensiotaulukkoon. Sinun on päätettävä, tallentaako tämä dimensiotaulukko vain työtilan nykyisen tilan vai tallentaako se versiotietoja, jotka heijastavat merkittäviä työtilan muutoksia ajan mittaan. Kun esimerkiksi työtilan nimi muuttuu, näyttääkö historiallinen raportointi senhetkisen työtilan nimen tai työtilan nimen, joka oli tuolloin käytössä? Lisätietoja versioinnista on kohdassa Dimensioiden hitaasti muuttaminen.
• Kohdetyypit: Luettelo Power BI -kohdetyypeistä (semanttiset mallit, raportit ja muut).
• Kapasiteetit: luettelo vuokraajan Premium-kapasiteeteista.
• Yhdyskäytävät: luettelo vuokraajan tietoyhdyskäytäviä.
• Tietolähteet: Luettelo tietolähteistä, joita mikä tahansa semanttinen malli, tietovuo tai tietomartti käyttää.

Seuraavassa on joitakin hyödyllisiä faktataulukoita (koehenkilöitä), jotka voit sisällyttää tietomalliin.

• Käyttäjän toimet: Tämä on faktatietoja, jotka ovat peräisin alkuperäisistä JSON-tiedoista. Kaikki määritteet, joilla ei ole analyysiarvoa, poistetaan. Myös kaikki dimensiotaulukoihin (yllä) kuuluvat määritteet poistetaan.
• Vuokraajavarasto: tämä on tilannevedos kaikista vuokraajassa julkaistuista kohteista. Lisätietoja on tämän artikkelin kohdassa Vuokraajaluettelo .
• Semanttiset mallit: Sisältää käyttäjän toiminnan, joka sisältää semanttisia malleja (kuten semanttisen mallin muutoksia) tai liittyviä tietolähteitä.
• Semanttiset mallin päivitykset: Tallentaa tietojen päivitystoiminnot, mukaan lukien tiedot tyypistä (ajoitettu tai pyydettäessä), kesto, tila ja kuka käyttäjä aloitti toiminnon.
• Työtilaroolit: tämä on työtilan roolimääritysten tilannevedos tietystä ajasta.
• Käyttöoikeudet: Tämä on käyttäjien käyttöoikeuksien tilannevedos tietystä ajasta. Vaikka haluatkin ehkä tallentaa käyttöoikeuden Käyttäjät-dimensiotaulukkoon , tämä lähestymistapa ei tue lisenssimuutosten ja trendien analysointia ajan mittaan.
• Käyttäjäryhmän jäsenyydet: pisteestä-aikainen tilannevedos käyttöoikeusryhmälle määritetyistä käyttäjistä (ja palvelun päänimistä).
• Yhteisön toiminta: Sisältää yhteisöön liittyviä tietoja, kuten koulutustapahtumia. Voit esimerkiksi analysoida Power BI -käyttäjien toimia verrattuna koulutuksen osanottamiseen. Nämä tiedot voivat auttaa Center of Excellenceä tunnistamaan mahdollisia uusia mestareita.

Faktataulukoissa ei pitäisi olla sarakkeita, jotka raportin luojat suodattavat. Nämä sarakkeet kuuluvat sen sijaan liittyviin dimensiotaulukoihin. Tämä rakenne on kyselyille tehokkaampi, mutta sen lisäksi se edistää dimensiotaulukoiden uudelleenkäyttöä useilla faktoilla (tunnetaan nimellä porautuminen). Viimeinen seikka on tärkeä luoda hyödyllinen ja käyttäjäystävällinen tietomalli, joka on laajennettavissa lisättäessä uusia faktataulukoita (koehenkilöitä).

Esimerkiksi Käyttäjät-dimensiotaulukko liittyy jokaiseen faktataulukkoon. Sen tulee liittyä Käyttäjä-toimintojen faktataulukkoon (joka suoritti toiminnon), Vuokraajan varaston faktataulukkoon (joka loi julkaistun kohteen) ja kaikkiin muihin faktataulukoihin. Kun raportti suodattaa käyttäjän mukaan Käyttäjät-dimensiotaulukossa, kyseisen raportin visualisoinnit voivat näyttää faktoja kyseiselle käyttäjälle mistä tahansa asiaan liittyvästä faktataulukosta.

Kun suunnittelet malliasi, varmista, että määrite näkyy mallissa kerran ja vain kerran. Esimerkiksi käyttäjän sähköpostiosoitteen pitäisi näkyä vain Käyttäjät-dimensiotaulukossa. Se on olemassa myös muissa faktataulukoissa (dimensioavaimena mallisuhteen tukemiseksi). Piilota se kuitenkin jokaisessa faktataulukossa.

Suosittelemme, että luot tietomallin raporteista erillään. Semanttisen mallin ja sen raporttien erottaminen toisistaan johtaa keskitettyun semanttiseen malliin, joka voi palvella useita raportteja. Lisätietoja jaetun semanttisen mallin käyttämisestä on artikkelissa Hallittu omatoiminen BI-käyttöskenaario .

Harkitse rivitason suojauksen (RLS) määrittämistä, jotta muut käyttäjät – Center of Excellencen lisäksi tarkastajat ja järjestelmänvalvojat – voivat analysoida tietoja ja raportoida niistä. Voit esimerkiksi käyttää rivitason suojauksen sääntöjä, joiden avulla sisällöntuottajat ja kuluttajat voivat raportoida omista käyttäjän toiminnoistaan tai kehitystoimistaan.

Tarkistusluettelo – Kun luot tietomallia, tärkeimmät päätökset ja toiminnot ovat seuraavat:

• Tietomallin suunnitteleminen ja luominen: Suunnittele tietomalli tähtirakenteeksi. Vahvista, että suhteet toimivat tarkoitetulla tavalla. Kun kehität mallia, luot iteratiivisesti mittareita ja lisäät tietoja analyyttisten vaatimusten perusteella. Sisällytä tulevat parannukset keskeneräisyyksiin tarvittaessa.
• Määritä rivitason suojaus: Jos aiot tuoda tietomallin muiden yleisten käyttäjien saataville, määritä rivitason suojaus tietojen käytön rajoittamiseksi. Varmista, että RLS-roolit palauttavat oikeat tiedot.

Paranna tietomallia

Jos haluat analysoida sisällön käyttöä ja käyttäjien toimia tehokkaasti, suosittelemme, että täydennät tietomalliasi. Tietomallin parannuksia voidaan tehdä asteittain ja toituttavasti ajan mittaan, kun löydät mahdollisuuksia ja uusia vaatimuksia.

Luo luokituksia

Yksi tapa parantaa mallia ja kasvattaa tietoihisi tulee lisätä luokituksia tietomalliin. Varmista, että näitä luokituksia käytetään johdonmukaisesti raporteissasi.

Voit halutessasi luokitella käyttäjiä heidän käyttötasonsa perusteella tai luokitella sisältöä sen käyttötason perusteella.

Käyttäjän käytön luokitus

Harkitse seuraavia käyttäjien käyttöön luokituksia.

• Usein käytetty: toiminta kirjattiin viime viikolla ja yhdeksässä viimeisessä 12 kuukaudessa.
• Aktiivinen käyttäjä: kuluneen kuukauden aikana kirjatut toiminnot.
• Satunnainen käyttäjä: toiminta on kirjattu viimeisten yhdeksän kuukauden aikana, mutta ei toimintaa viimeisen kuukauden aikana.
• Passiivinen käyttäjä: Mitään toimia ei kirjata viimeisten yhdeksän kuukauden aikana.

Vihje

On hyödyllistä tietää, keitä satunnaiset tai passiiviset käyttäjäsi ovat, etenkin silloin, kun heillä on Pro- tai PPU-käyttöoikeudet (joihin liittyy kustannuksia). On myös hyödyllistä tietää, ketkä ovat yleisimpiä ja aktiivisimpia käyttäjiä. Harkitse kutsumista toimistoajalle tai osallistua koulutukseen. Aktiivisimmat sisällöntekijäsi saattavat olla ehdokkaita liittymään mestarien verkostoosi.

Sisällön käytön luokitus

Katso seuraavat sisällön käytön luokitukset.

• Usein käytetty sisältö: toiminta kirjattiin viime viikolla ja yhdeksän viimeisen 12 kuukauden aikana.
• Aktiivisesti käytetty sisältö: viimeisen kuukauden aikana tallennettu toiminta.
• Toisinaan käytetty sisältö: Viimeisen yhdeksän kuukauden aikana kirjattu toiminta, mutta ilman toimintaa viimeisen kuukauden aikana.
• Käyttämätön sisältö: Ei kirjattua toimintaa viimeisten yhdeksän kuukauden aikana.

Käyttäjätyypin luokitus

Harkitse seuraavia käyttäjätyypin luokituksia.

• Sisällöntekijä: viimeisen kuuden kuukauden aikana tallennettu toiminto, joka on luonut, julkaissut tai muokannut sisältöä.
• Sisällön katselu: viimeisen kuuden kuukauden aikana tallennettu toiminta, joka on tarkastellut sisältöä, mutta ei mitään sisällönluontitoimintoja.

Harkitse suorakulmioita ja trendejä

Päätä, tuleeko käyttäjien tai sisällön käyttöluokituksen määrittää vain aktiviteetin vastikään tapahtuneen luokituksen perusteella. Saatat myös haluta harkita keskimääräistä tai suosittua käyttöä ajan kuluessa.

Otetaan joitakin esimerkkejä, jotka osoittavat, miten yksinkertainen luokituslogiikka saattaisi johtaa todellisuuteen väärin.

• Esimies tarkasteli yhtä raporttia tällä viikolla. Sitä viikkoa ennen esimies ei kuitenkaan ollut tarkastellut raportteja viimeisten kuuden kuukauden aikana. Tätä esimiestä ei kannata pitää usein käyttäjänä pelkän viimeaikaisen käytön perusteella.
• Raportin tekijä julkaisee uuden raportin joka viikko. Kun analysoit usein käytettyjen käyttäjien käyttöä, raportin luojan säännöllinen toiminta vaikuttaa positiiviselta. Tarkempaa tutkimusta käyttäen huomaat kuitenkin, että tämä käyttäjä on julkistanut uuden raportin (uudella raportin nimellä) aina, kun hän muokkaa raporttia. Raportin tekijälle olisi hyödyllistä saada enemmän koulutusta.
• Johtaja tarkastelee raporttia satunnaisesti, joten hänen käyttöluokituksensa muuttuu usein. Sinun täytyy ehkä analysoida tietyntyyppisiä käyttäjiä, kuten johtajia, eri tavalla.
• Sisäinen tarkastaja tarkastelee kriittisiä raportteja kerran vuodessa. Sisäinen tarkastaja saattaa vaikuttaa passiivislta käyttäjältä, koska sen käyttö on epäsäännöllistä. Joku voi poistaa Pro- tai PPU-käyttöoikeutensa. Tai joku voi uskoa, että raportti pitäisi poistetaan käytöstä, koska sitä käytetään harvoin.

Vihje

Voit laskea keskiarvoja ja trendejä KÄYTTÄMÄLLÄ DAX-aikatietofunktioita. Jos haluat oppia käyttämään näitä funktioita, käy läpi DAX-aikatietofunktioiden käyttö Power BI Desktopin malleissa -oppimismoduulia.

Tarkistusluettelo – Kun luot luokittelevia käyttötietoja, tärkeimmät päätökset ja toiminnot ovat seuraavat:

• Konsensus luokitusmääritelmistä: Keskustele luokitusmääritelmistä asiaankuuluvien sidosryhmien kanssa. Varmista, että päätöksiä tehtäessä on sopimus.
• Luo dokumentaatio: Varmista, että luokitusmääritykset sisältyvät sisällöntuottajien ja kuluttajien dokumentaatioon.
• Luo palautesilmukka: Varmista, että käyttäjät voivat esittää kysymyksiä tai ehdottaa muutoksia luokitusmääritelmiin.

Analyysiraporttien luominen

Tässä vaiheessa valvontatiedot on poimittu ja tallennettu, ja olet julkaissut tietomallin. Seuraava vaihe on analyysiraporttien luominen.

Keskity tärkeimpiin tietoihin, jotka ovat merkityksellisimpiä kullekin yleisölle. Valvontaraporteillesi saattaa olla useita käyttäjäryhmiä. Jokainen yleisö on kiinnostunut erilaisista tiedoista ja eri tarkoituksiin. Seuraavassa on esimerkiksi seuraavat yleisöt, joita saatat tarvita raporttien yhteydessä:

• Johdon sponsori
• Center of Excellence
• Power BI -järjestelmänvalvojat
• Työtilan järjestelmänvalvojat
• Premium-kapasiteetin järjestelmänvalvojat
• Yhdyskäytävän järjestelmänvalvojat
• Power BI -kehittäjät ja sisällöntekijät
• Tilintarkastajat

Seuraavassa on joitakin yleisimpiä analyyttisia vaatimuksia, joista haluat ehkä aloittaa luodessasi valvontaraportteja.

• Tärkeimmät sisältönäkymät: Yrityssponsori- ja johtajatiimit saattavat olla ennen kaikkea kiinnostuneita yhteenvetotiedoista ja trendeistä ajan mittaan. Työtilan järjestelmänvalvojat, kehittäjät ja sisällöntekijät ovat kiinnostuneempia yksityiskohdista.
• Tärkeimmät käyttäjätoiminnot: Your Center of Excellence on kiinnostunut siitä, ketkä käyttävät Power BI:tä, miten ja milloin. Premium-kapasiteetin järjestelmänvalvojasi ovat kiinnostuneita siitä, ketkä käyttävät kapasiteettia sen kunnon ja vakauden varmistamiseen.
• Vuokraajavarasto: Power BI -järjestelmänvalvojat, työtilan järjestelmänvalvojat ja tarkastajat ovat kiinnostuneita siitä, mitä sisältöä on olemassa, missä se on, historiatiedot ja sen suojausasetukset.

Tämä luettelo ei ole all-inclusive-luettelo. Sen tarkoitus on tarjota ideoita siihen, miten voit luoda analyyttisia raportteja, jotka kohdistuvat tiettyihin tarpeisiin. Lisätietoja on tämän artikkelin kohdassa Tietotarpeet ja Valvonnan yleiskatsaus. Nämä resurssit sisältävät useita ideoita siitä, miten voit käyttää valvontatietoja, ja tietotyypeistä, joita voit esittää raporteissasi.

Vihje

Vaikka on houkuttelevaa esittää paljon tietoja, sisällytä vain tiedot, joiden pohjalta olet valmis toimimaan. Varmista, että jokaisella raporttisivulla on selkeä sen tarkoitus, mitä toimia tulisi suorittaa ja kuka sen suorittaa.

Jos haluat oppia luomaan analyyttisia raportteja, käy läpi Tehokkaiden raporttien suunnittelu Power BI:ssä - oppimispolkua.

Tarkistusluettelo – Kun suunnittelet analyyttisia valvontaraportteja, tärkeimpiä päätöksiä ja toimintoja ovat muun muassa seuraavat:

• Tarkistusvaatimukset: Priorisoi raporttien luominen tunnettujen tarpeiden ja erityisten kysymysten perusteella, joihin tulee vastata.
• Vahvista yleisösi: Selvitä, ketkä käyttävät valvontaraportteja ja mikä niiden tarkoitus on.
• Luo ja ota käyttöön raportteja: Luo ensimmäinen ydinraporttijoukko. Laajenna ja paranna niitä vähitellen ajan mittaan.
• Raporttien jakaminen sovelluksessa: Harkitse sellaisen sovelluksen luomista, joka sisältää kaikki valvonta- ja valvontaraporttisi.
• Varmista, kenellä on raporttien käyttöoikeudet: Varmista, että raportit (tai sovellus) tarjotaan oikeiden käyttäjäjoukon käyttöön.
• Luo palautesilmukka: Varmista, että raportin käyttäjät voivat antaa palautetta, ehdotuksia tai ilmoittaa ongelmista.

Tee tietoihin perustuva toiminto

Tietojen valvonta on arvokasta, koska se auttaa sinua ymmärtämään, mitä Power BI -vuokraajassasi tapahtuu. Vaikka se saattaa tuntua ilmeiseltä, valvontatiedoista oppimiesi tietojen eksplisiittinen toimiminen voi helposti jäädä huomiotta. Tästä syystä suosittelemme, että määrität jonkun, joka on vastuussa mitattavissa olevien parannusten seurannasta, sen sijaan, että tarkistat vain raporttien tarkastelun. Tällä tavoin voit edistyä asteittain ja mitattavissa olevalla tavalla Power BI:n käyttöönotossa ja maturiteettitasolla .

Voit suorittaa monia erilaisia toimintoja tavoitteidesi ja valvontatiedoista oppimiesi tietojen perusteella. Tämän osion loppuosa sisältää useita ideoita.

Sisällön käyttö

Seuraavassa on joitakin toimintoja, joita voit suorittaa sisällön käyttötavan perusteella.

• Sisältöä käytetään usein (päivittäin tai viikoittain): Varmista, että kaikki tärkeät sisällöt sertifioidaan. Varmista, että omistajuus on selkeä ja että ratkaisua tuetaan riittävästi.
• Suuri määrä työtilan näkymiä: Kun työtilan näkymiä ilmenee paljon, tutki, miksi Power BI -sovellukset eivät ole käytössä.
• Sisältöä käytetään harvoin: Ota yhteyttä kohdekäyttäjiin ja selvitä, täyttääkö ratkaisu heidän vaatimuksensa vai onko hänen vaatimuksensa muuttunut.
• Päivitystoimintoa esiintyy useammin kuin näkymiä: Ota yhteyttä sisällön omistajaan, jotta ymmärrät, miksi semanttinen malli päivitetään säännöllisesti ilman semanttisen mallin tai siihen liittyvien raporttien viimeaikaista käyttöä.

Käyttäjän toimet

Seuraavassa on joitakin toimintoja, joita voit suorittaa käyttäjätoimintojen perusteella.

• Uuden käyttäjän ensimmäinen julkaisutoiminto: Tunnista, milloin käyttäjätyyppi muuttuu kuluttajasta luojaksi, jonka voit tunnistaa, kun hän julkaisee sisältöä ensimmäistä kertaa. Se on loistava tilaisuus lähettää heille vakiosähköposti, joka sisältää ohjeita ja linkkejä hyödyllisiin resursseihin.
• Ole yhteydessä yleisimpiin sisällöntekijöihin: Kutsu aktiivisimmat luojasi liittymään mestariverkostoosi tai osallistumaan käytäntöyhteisöön.
• Käyttöoikeuksien hallinta: Tarkista, tarvitsevatko passiiviset luojat edelleen Pro- vai PPU-käyttöoikeuden.
• Käyttäjän kokeiluversion aktivointi: Kokeiluversion käyttöoikeuden aktivointi voi pyytää sinua määrittämään käyttäjälle pysyvän käyttöoikeuden ennen kokeilujakson päättymistä.

Käyttäjien koulutusmahdollisuudet

Seuraavassa on joitakin käyttäjien koulutusmahdollisuuksia, joita voit tunnistaa valvontatiedoista.

• Sama sisällöntekijä on julkaissut suuren määrän semanttisia malleja: Opeta käyttäjille jaettuja semanttisia malleja ja miksi on tärkeää välttää semanttisten mallien kaksoiskappaleiden luomista.
• Liiallinen jakaminen henkilökohtaisesta työtilasta: Ota yhteyttä käyttäjään, joka jakaa tietoja paljon omasta työtilastaan. Opeta heille vakiotyötiloja.
• Merkittävät raporttinäkymät henkilökohtaisesta työtilasta: Ota yhteyttä käyttäjään, joka omistaa sisältöä, jolla on suuri määrä raporttinäkymiä. Opeta heille, miten vakiotyötilat ovat parempia kuin henkilökohtaiset työtilat.

Vihje

Voit myös parantaa koulutussisältöäsi tai dokumentaatiotasi tarkastelemalla kysymyksiä, joihin sisäinen Power BI -yhteisösi vastaa ja jotka on lähetetty tukipalveluun.

Suojaus

Seuraavassa on joitakin suojaustilanteita, joita haluat ehkä aktiivisesti valvoa.

• Liian monta käyttäjää on määritetty Fabric-järjestelmänvalvojan rooliin.
• Liian monta työtilan järjestelmänvalvojaa (kun Jäsen-, Osallistuja- tai Katselija-työtilarooli riittäisi).
• Semanttisille malleille määritetyt liian suuret muodostamisoikeudet (kun lukuoikeus riittäisi).
• Kohdekohtaisten käyttöoikeuksien suuri käyttö, kun Power BI -sovelluksen käyttöoikeudet tai työtilan Katselija-rooli olisivat parempi vaihtoehto sisällön kuluttajille.
• Miten sisältö jaetaan ulkoisten käyttäjien kanssa.

Lisätietoja on artikkelissa Suojauksen suunnittelun artikkelit.

Hallinto ja riskienhallinta

Seuraavassa on joitakin tilanteita, joita voit kohdata. Harkitse tällaisten tilanteiden eksplisiittistä etsimistä valvontaraporteistasi, jotta olet valmis toimimaan nopeasti.

• Suuri määrä raporttinäkymiä (ja pohjana olevia semanttisia malleja), joita ei tueta.
• Tuntemattoman tai käyttämättömän tietolähteen merkittävä käyttö.
• Tiedostojen sijainnit, jotka eivät vastaa hallintoohjeita lähdetiedostojen sijainnin osalta.
• Työtilan nimet eivät vastaa hallintovaatimuksia.
• Luottamuksellisuustunnisteita käytetään tietojen suojaamiseen.
• Yhdenmukaiset tietojen päivittämisen virheet.
• Merkitsevä ja toistuva tulostuksen käyttö.
• tilausten odottamaton tai liiallinen käyttö.
• Henkilökohtaisten yhdyskäytävien odottamaton käyttö.

Kussakin tilanteessa toteutettavat erityistoimet riippuvat hallintokäytännöistäsi. Lisätietoja on artikkelissa Fabric-käyttöönoton toteutussuunnitelma .

Tarkistusluettelo – Kun suunnittelet mahdollisia valvontatietoihin perustuvia toimintoja, tärkeimmät päätökset ja toiminnot ovat seuraavat:

• Selvitä odotukset: Luo auditointiraportteja, joissa on selkeät odotukset siitä, mitä toimintoja odotetaan.
• Selvitä, kuka vastaa toiminnoista: Varmista, että roolit ja vastuut on määritetty.
• Automaation luominen: Automatisoi mahdollisuuksien mukaan toistettavissa olevat tunnetut toiminnot.
• Käytä seurantajärjestelmää: Seuraa havaittua tilannetta järjestelmän avulla, mukaan lukien yhteydenotto, seuraava suunniteltu toiminto, sen vastuuhenkilö, ratkaisu ja tila.

Vaihe 4: Ylläpidä, paranna ja valvo

Vuokraajatason valvontaratkaisun suunnittelun ja toteuttamisen neljännessä vaiheessa keskitytään ylläpitoon, parannuksiin ja valvontaan. Tässä vaiheessa valvontaratkaisusi on tuotantokäytössä. Olet nyt ensisijaisesti huolissasi ratkaisun ylläpitämisestä, parantamisesta ja valvonnasta.

Toiminnallinen toiminta ja parannus

Valvontaprosesseja pidetään yleensä tuotannossa, kun ensimmäinen kehitys ja testaus on valmis, ja prosessi on automatisoitu. Tuotannossa suoritettavilla automatisoiduilla valvontaprosesseilla on suuremmat odotukset (kuin manuaaliset prosessit) laadun, luotettavuuden, vakauden ja tuen suhteen.

Tuotantotason valvontaprosessi on operationalisoitu. Operatiivinen ratkaisu sisältää usein monia seuraavista ominaisuuksista.

• Suojattu: Tunnistetiedot tallennetaan ja niitä hallitaan turvallisesti. Komentosarjat eivät sisällä salasanoja tai avaimia salaamattomana tekstinä.
• Ajoitus: Käytössä on luotettava aikataulutusjärjestelmä.
• Muutostenhallinta: Muutostenhallintakäytäntöjen ja useiden ympäristöjen avulla varmistetaan tuotantoympäristön suojaus. Saatat työskennellä myös kehitys- ja testiympäristöissä tai vain kehitysympäristössä.
• Tuki: Ratkaisua tukeva tiimi on määritetty selkeästi. Tiimin jäseniä on koulutettu, ja he ymmärtävät operatiiviset odotukset. Varmuuskopiojäsenet on tunnistettu ja ristiinkoulutus tapahtuu tarvittaessa.
• Ilmoitus: Kun jokin menee vikaan, hälytykset ilmoittavat tukitiimille automaattisesti. Mielellään ilmoitukset sisältävät sekä lokit että sähköpostin (pelkän sähköpostin sijaan). Lokista on hyötyä kirjattujen virheiden ja varoitusten analysoimisessa.
• Kirjaaminen: Prosessit kirjataan, joten valvontatietojen päivittymisen aikana on historia. Kirjattujen tietojen tulee tallentaa alkamisaika, päättymisaika ja prosessin suorittaneen käyttäjän tai sovelluksen käyttäjätiedot.
• Virheenkäsittely: Komentosarjat ja prosessit käsittelevät ja kirjaavat virheitä hallitusti (esimerkiksi poistutaanko välittömästi, jatketaanko vai yritetäänkö uudelleen). Ilmoitusten lähettäminen tukitiimille virheen tapahtuessa.
• Koodausstandardit: Käytetään hyviä koodaustekniikoita, jotka toimivat hyvin. Esimerkiksi silmukoita vältetään tarkoituksella, paitsi tarvittaessa. Yhtenäisiä koodausstandardeja, kommentteja, muotoiluja ja syntakseja käytetään, jotta ratkaisua on helpompi ylläpitää ja tukea.
• Uudelleenkäyttö ja modulaarisuus: Kopiointi-, koodi- ja määritysarvojen (kuten ühendusstring tai sähköpostiosoitteiden ilmoitukset) minimoimiseksi modulaarisia, jotta muut komentosarjat ja prosessit voivat käyttää niitä uudelleen.

Vihje

Sinun ei tarvitse tehdä kaikkea ennen kaikkea mainittua kerralla. Kun saat kokemusta, voit parantaa ratkaisua asteittain niin, että siitä tulee täydellinen ja vankka. Huomaa, että useimmat verkosta löytyvät esimerkit ovat yksinkertaisia ja kertaluonteisia komentosarjakatkelmia, jotka eivät ehkä ole tuotannon laatuisia.

Tarkistusluettelo – Kun suunnittelet valvontaratkaisun operationalisointia ja parantamista, tärkeimmät päätökset ja toiminnot ovat seuraavat:

• Arvioi olemassa olevien ratkaisujen taso: Selvitä, onko olemassa olevia automatisoituja valvontaratkaisuja parannettava ja vakautettava mahdollisuuksia.
• Tuotantotason standardien luominen: Päätä, mitä standardeja haluat käyttää automaattisia valvontaprosesseja varten. Ota huomioon parannukset, jotka voit realistisesti lisätä ajan kuluessa.
• Luo parannussuunnitelma: Tarkoituksena on parantaa tuotannon valvontaratkaisujen laatua ja vakautta.
• Määritä, onko erillinen kehitysympäristö tarpeellinen: Arvioi riskin taso ja luottavuus tuotantotietoihin. Päätä, milloin luodaan erilliset kehitys- ja tuotantoympäristöt (ja testiympäristöt).
• Harkitse tietojen säilytysstrategiaa: Selvitä, onko sinun otettava käyttöön tietojen säilytysprosessi, joka poistaa tietoja tietyn ajan kuluttua, vai pyynnöstä.

Dokumentaatio ja tuki

Dokumentaatio ja tuki ovat kriittisiä kaikissa tuotantotason ratkaisuissa. On hyödyllistä luoda useita erilaisia dokumentaatiotyyppejä kohderyhmän ja tarkoituksen mukaan.

Tekninen dokumentaatio

Tekninen dokumentaatio on tarkoitettu ratkaisun luoneelle tekniselle työryhmälle, joka vähitellen parantaa ja laajentaa ratkaisua ajan mittaan. Se on myös hyödyllinen resurssi tukitiimille.

Teknisten ohjeiden tulee sisältää seuraavat:

• Yhteenveto arkkitehtuurin osista ja edellytyksistä.
• Kuka omistaa ja hallitsee ratkaisua.
• Kuka tukee ratkaisua?
• Arkkitehtuurikaavio.
• Suunnittelupäätöksiä, kuten tavoitteita, syitä tiettyjen teknisten valintojen tekemiseen ja rajoituksia (kuten kustannuksia tai osaamista).
• Suojauspäätökset ja -valinnat.
• Käytetyt nimeämiskäytännöt.
• Koodaus sekä tekniset standardit ja ohjeet.
• Muuta hallintavaatimuksia.
• Käyttöönotto-, asennus- ja asennusohjeet.
• Tunnetut teknisen velan alueet (alueet, joita voidaan parantaa, jos siihen on mahdollisuus).

Tukidokumentaatio

Valvontaratkaisusi kriittisyyden tasosta riippuen sinulla voi olla tukipalvelu tai tukitiimi, jos ongelmia ilmenee kiireellisesti. Ne saattavat olla käytettävissä koko päivän, joka päivä.

Tukidokumentaatiota kutsutaan joskus teabebaas tai runbookiksi. Nämä ohjeet on tarkoitettu mikrotuelle tai tukitiimille, ja sen tulee sisältää seuraavat:

• Vianmääritysohjeita, jos jokin menee vikaan. Esimerkiksi tietojen päivittämisen epäonnistuessa.
• Jatkuvasti suoritettavat toimet. Jotkin manuaaliset vaiheet on esimerkiksi suoritettava säännöllisesti, kunnes ongelma on ratkaistu.

Sisällöntekijän dokumentaatio

Saat enemmän arvoa valvontaratkaisustasi tarjoamalla käyttö- ja käyttöönottoanalytiikkaa organisaation muille tiimeille (tarvittaessa rivitason suojauksen avulla).

Sisällöntekijän dokumentaatio on tarkoitettu omatoimisille sisällöntekijöille, jotka luovat raportteja ja tietomalleja, jotka hankkivat valvotut tiedot. Se sisältää tietoja tietomallista, myös yleisiä tietomäärityksiä.

Tarkistusluettelo – Kun suunnittelet dokumentaatiota ja valvontaratkaisusi tukea, tärkeimmät päätökset ja toiminnot ovat seuraavat:

• Vahvista, keiden odotetaan tukevan ratkaisua: Selvitä, ketkä tukevat tuotantotasoisina (tai joilla on raportin jatkojalostusriippuvuuksia).
• Varmista tukiryhmän valmius: Varmista, että tukiryhmä on valmis tukemaan valvontaratkaisua. Selvitä, onko valmiudessa puutteita, joihin on puututtava.
• Järjestä ristiinkoulutus: Järjestä tiedonsiirtoistuntoja tai ristiinkoulutusistuntoja tukitiimille.
• Selventää tukitiimin odotuksia: Varmista, että odotukset vastauksesta ja ratkaisusta on selvästi dokumentoitu ja ilmoitettu. Päätä, pitääkö kaikkia kutsua valvontaratkaisuun liittyvien ongelmien nopeaan ratkaisemiseen.
• Luo teknisiä asiakirjoja: Luo teknisen arkkitehtuurin ja suunnittelun päätöksiä koskevia asiakirjoja.
• Luo tukidokumentaatio: Päivitä tukipalvelun tietokanta sisältämään tietoja siitä, miten ratkaisua tuetaan.
• Dokumentaation luominen sisällöntekijöille: Luo dokumentaatio, joka auttaa omatoimisen sisällöntekijöitä käyttämään tietomallia. Niiden käytön yhdenmukaisuuden parantamiseksi kuvataan yleisiä tietomääritelmiä.

Ota ilmoitukset käyttöön

Haluat ehkä lisätä hälytyksiä valvontatietojen tiettyjen ehtojen perusteella. Voit esimerkiksi lisätä ilmoituksen, kun joku poistaa yhdyskäytävän tai kun Power BI -järjestelmänvalvoja muuttaa vuokraaja-asetusta.

Lisätietoja on artikkelissa Vuokraajatason valvonta.

Jatkuva hallinta

Sinun on suoritettava koko valvontaratkaisun jatkuva hallinta. Sinun on ehkä laajennettava tai muutettava valvontaratkaisuasi, kun:

• Organisaatio löytää uusia tietovaatimuksia.
• Uudet valvontatapahtumat näkyvät Power BI REST -ohjelmointirajapinnoista saamissasi raakatiedoissa.
• Microsoft tekee muutoksia Power BI REST -ohjelmointirajapintoihin.
• Työntekijät tunnistavat tapoja parantaa ratkaisua.

Tärkeä

Rikkovat muutokset ovat harvinaisia, mutta ne voivat tapahtua. On tärkeää, että käytettävissäsi on joku, joka voi nopeasti tehdä vianmäärityksen tai päivittää valvontaratkaisun tarvittaessa.

Tarkistusluettelo – Kun suunnittelet valvontaratkaisun jatkuvaa hallintaa, tärkeimmät päätökset ja toiminnot ovat seuraavat:

• Määritä tekninen omistaja: Varmista, että koko valvontaratkaisulla on selkeä omistajuus ja vastuu.
• Varmista, että varmuuskopio on olemassa: Varmista, että siellä on varmuuskopioinnin tekninen omistaja, joka voi osallistua, jos syntyy kiireellinen ongelma, jota tuki ei voi ratkaista.
• Säilytä seurantajärjestelmä: Varmista, että sinulla on tapa siepata uusia pyyntöjä ja miten voit priorisoida välittömiä prioriteetteja sekä lyhyen, keskipitkän ja pitkän aikavälin (keskeneräisiä) prioriteetteja.

Liittyvä sisältö

Tämän sarjan seuraavassa artikkelissa on tietoja vuokraajatason valvonnasta.