Zdieľať cez

Plánovanie implementácie služby Power BI: Auditovanie na úrovni nájomníka

  • Článok

Poznámka

Tento článok je súčasťou série článkov k plánovaniu implementácie služby Power BI. Táto séria sa zameriava predovšetkým na prostredie služby Power BI v rámci služby Microsoft Fabric. Úvod do série nájdete v téme Plánovanie implementácie služby Power BI.

Článok o plánovaní auditu na úrovni nájomníka je primárne zameraný na:

  • Správcovia služby Power BI: správcovia, ktorí sú zodpovední za dohľad nad službou Power BI v organizácii. Správcovia služby Power BI možno budú musieť spolupracovať s IT, zabezpečením, interným auditom a ďalšími relevantnými tímami.
  • Centrum excelentnosti, IT a tím BI: Tímy, ktoré tiež zodpovedajú za dohľad nad službou Power BI. Možno budú musieť spolupracovať so správcami služby Power BI a inými relevantnými tímami.

Dôležité

Odporúčame, aby ste pozorne dodržiavali plán vydania služby Power BI a dozvedeli sa o budúcich vylepšeniach možností auditovania a monitorovania.

Cieľom riešenia auditu na úrovni nájomníka je zaznamenávať a analyzovať údaje pre všetkých používateľov, aktivity a riešenia nasadené do nájomníka služby Power BI. Tieto údaje auditovania na úrovni nájomníka sú cenné na mnohé účely, čo vám umožňuje analyzovať úsilie o prijatie, porozumieť vzorom používania, vzdelávať používateľov, podporovať používateľov, zmierňovať riziká, zlepšovať dodržiavanie súladu, spravovať náklady na licencie a monitorovať výkon.

Vytvorenie komplexného riešenia na auditovanie, ktoré je bezpečné a pripravené na produkciu, je významný projekt, ktorý si vyžaduje čas. Predstavte si pod tým analytické nástroje analytických nástrojov (BI v službe BI). Informácie o tom, prečo sú údaje auditovania také cenné, nájdete v téme Prehľad auditovania a monitorovania.

Auditovanie na úrovni zostavy, ktoré je zamerané na tvorcov zostáv, nájdete v téme Auditovanie na úrovni zostavy.

Informácie o auditovaní položiek údajov zameraných na tvorcov údajov nájdete v téme Auditovanie na úrovni údajov.

Zvyšok tohto článku sa zameriava na auditovanie na úrovni nájomníka.

Tip

Hlavným zameraním tohto článku je pomôcť vám naplánovať vytvorenie komplexného riešenia auditovania. Keďže obsah v tomto článku je usporiadaný do štyroch fáz, budete potrebovať informácie v rámci viacerých fáz. Vo fáze 1 napríklad nájdete informácie o plánovaní používania objektu služby a informácie vo fáze 2 o predpokladoch a nastavení.

Preto odporúčame, aby ste si najprv prečítali celý tento článok, aby ste sa zoznámili s tým, čo sa vás týka. Potom by ste mali byť dobre pripravení na plánovanie a vytváranie riešení auditovania opakovaným spôsobom.

Ak plánujete vytvoriť riešenie auditovania na úrovni nájomníka, plánujete vynaložiť čas na nasledujúce štyri fázy.

Fáza 1: Plánovanie a rozhodnutia

Prvá fáza sa zameriava na plánovanie a rozhodovanie. Je veľa požiadaviek a priorít, aby ste zvážili, preto odporúčame, aby ste strávili dostatok času na pochopenie tém uvádzaných v tejto časti. Cieľom je správne počiatočné rozhodnutia tak, aby následné fázy plynulo bežali.

Diagram postupu popisujúci fázu 1, ktorá sa zameriava na plánovanie a rozhodnutia na vytvorenie riešenia auditovania na úrovni nájomníka.

Požiadavky a priority

V počiatočnej fáze je cieľom identifikovať najdôležitejšie informácie. Zamerajte sa na to, čo je najdôležitejšie, a na to, ako budete merať vplyv vo svojej organizácii. Snažte sa definovať podnikové požiadavky a nie požiadavky orientované na technológiu.

Tu je niekoľko otázok, na ktoré by ste mali odpovedať.

  • Na ktoré kľúčové otázky potrebujete odpovedať? Existuje veľké množstvo údajov na auditovanie, ktoré môžete preskúmať. Najúčinnejší spôsob, ako pristupovať k auditovania, je zamerať sa na zodpovedanie konkrétnych otázok.
  • Aké sú vaše ciele v oblasti prijatia a kultúry údajov? Napríklad máte cieľ zvýšiť počet tvorcov samoobslužného BI obsahu v organizácii. V takom prípade budete musieť merať aktivity používateľa súvisiace s vytváraním, upravovaním a publikovaním obsahu.
  • Aké okamžité riziká sú prítomné? Môžete napríklad vedieť, že v minulosti došlo k nadmernému zdieľanie obsahu. Školenie používateľov bolo odvtedy vylepšené a vy teraz chcete priebežne auditovať nastavenia zabezpečenia a aktivity.
  • Existujú aktuálne kľúčové ukazovatele výkonu (KPI) alebo ciele organizácie? Môžete mať napríklad kľúčový ukazovateľ výkonu organizácie, ktorý súvisí s digitálnou transformáciou alebo s tým, že sa stávate väčšou organizáciou riadenou údajmi. Údaje auditovania na úrovni nájomníka vám môžu pomôcť zmerať, či je implementácia služby Power BI v súlade s týmito cieľmi.

Tip

Overte požiadavky na auditovanie a nastavte priority pomocou svojho výkonného sponzora a Centra excelentnosti. Extrahovanie údajov z auditovania a začatie vytvárania zostáv na základe množstva zaujímavých údajov je lákavé. Je však nepravdepodobné, že by ste mali odvodiť vysokú hodnotu z vášho riešenia auditovania, keď nebude podnietená otázkami, ktoré potrebujete odpovedať a akcie, ktoré plánujete vykonať.

Ďalšie nápady o spôsoboch používania údajov auditovania nájdete v téme Prehľad auditovania a monitorovania.

Kontrolný zoznam – pri identifikácii požiadaviek a priorít zahŕňajú kľúčové rozhodnutia a akcie:

  • Identifikácia požiadaviek: Zhromažďovanie a dokumentácia kľúčových obchodných požiadaviek na auditovanie nájomníka služby Power BI.
  • Uprednostnite požiadavky: Nastavte priority pre požiadavky a klasifikujte ich ako okamžité, krátkodobé, dlhodobé a dlhodobé (nevybavené).
  • Vytvorte plán s bezprostrednými prioritami: vytvorte plán, aby ste mohli začať zhromažďovať údaje tak, aby bol k dispozícii vtedy, keď ich potrebujete.
  • Pravidelne prehodnocuje požiadavky: Vytvorte plán na pravidelné prehodnocovanie požiadaviek (napríklad dvakrát za rok). Overte, či riešenie auditovania a monitorovania spĺňa uvedené požiadavky. Podľa potreby aktualizujte položky akcií v pláne.

Potreby údajov

Po zadefinovaní požiadaviek a priorít (uvedených vyššie) ste pripravení identifikovať údaje, ktoré budete potrebovať. V tejto časti sú popísané štyri kategórie údajov.

Väčšina údajov, ktoré budete potrebovať, pochádza z rozhraní API správcu, ktoré poskytujú množstvo metaúdajov o nájomníkovi služby Power BI. Ďalšie informácie nájdete v časti Výber používateľského rozhrania API alebo rozhrania API správcu ďalej v tomto článku.

Údaje o aktivite používateľa

Vytvorte si najprv prioritu na získanie údajov o aktivitách používateľov. Aktivity používateľa, ktoré sa nazývajú aj udalosti alebo operácie, sú užitočné na najrôznejšie účely.

Tieto údaje sa najčastejšie označujú ako denník aktivity alebo denník udalostí. Technicky platí, že existuje niekoľko spôsobov, ako získať údaje o aktivite používateľa (denník aktivity je jednou z metód). Ďalšie informácie o prijatých rozhodnutiach a aktivitách nájdete neskôr v tomto článku v téme Prístup k údajom o aktivite používateľov.

Tu sú niektoré bežné otázky, na ktoré môžu odpovedať údaje o aktivite používateľa.

  • Vyhľadanie najpoužívaných používateľov a najaktívnejšom obsahu
    • Aký obsah sa zobrazuje najčastejšie a ktorí používatelia?
    • Aké sú denné, týždenné a mesačné trendy na zobrazenie obsahu?
    • Sú zobrazenia zostáv trendy nahor alebo nadol?
    • Koľko používateľov je aktívnych?
  • Vysvetlenie správania používateľov
    • Aký typ zabezpečenia sa najčastejšie používa (aplikácie, pracovné priestory alebo zdieľanie na položku)?
    • Používajú používatelia prehliadače alebo mobilné aplikácie najčastejšie?
    • Ktorí tvorcovia obsahu najčastejšie publikujú a aktualizujú obsah?
    • Ktorý obsah sa publikuje alebo aktualizuje, kedy a podľa ktorých používateľov?
  • Identifikácia príležitostí na vzdelávanie a školenie používateľov
    • Kto vykonáva (príliš veľa) zdieľanie zo svojho osobného pracovného priestoru?
    • Kto exportuje veľké množstvo?
    • Kto pravidelne sťahuje obsah?
    • Kto publikuje mnoho nových sémantických modelov – predtým známych ako množiny údajov?
    • Kto predplatné vo veľkej miere používa?
  • Zlepšenie úsilia v oblasti riadenia a dodržiavania súladu
    • Kedy sa zmenia nastavenia nájomníka a podľa ktorého správcu služby Power BI?
    • Kto sa spustila skúšobná verzia služby Power BI?
    • K akému obsahu sa pristupujú externí používatelia, kto, kedy a ako?
    • Kto pridali alebo aktualizovali označenie citlivosti?
    • Aké percento zobrazení zostavy je založené na certifikovaných sémantických modeloch?
    • Aké percento sémantických modelov podporuje viac ako jednu zostavu?
    • Kedy sa brána alebo zdroj údajov vytvorí alebo aktualizuje a ktorý používateľ?

Ďalšie informácie o spôsoboch používania týchto údajov nájdete v téme Vysvetlenie vzorov používania.

Dôležité

Ak ešte neextrahujete a neukladáte údaje o aktivitách používateľov, musíte to nastaviť ako naliehavú prioritu. Uistite sa aspoň, že extrahujete nespracované údaje a uložíte ich na bezpečné miesto. Týmto spôsobom budú údaje k dispozícii, keď budete pripravení na ich analýzu. História je k dispozícii 30 dní alebo 90 dní v závislosti od zdroja, ktorý používate.

Ďalšie informácie nájdete v časti Prístup k údajom o aktivite používateľa ďalej v tomto článku.

Inventár nájomníkov

Druhou prioritou je často načítanie údajov na vytvorenie inventára nájomníka. Niekedy sa označuje ako súpis pracovných priestorov, metaúdaje pracovného priestoru alebo metaúdaje nájomníka.

Inventár nájomníka je snímka v danom časovom okamihu. Popisuje, čo bolo publikované v nájomníkovi. Inventár nájomníka neobsahuje skutočné údaje ani skutočné zostavy. Ide skôr o metaúdaje, ktoré opisujú všetky pracovné priestory a ich položky (napríklad sémantické modely a zostavy).

Tu sú niektoré bežné otázky, na ktoré môže inventár nájomníka odpovedať.

  • Informácie o tom, koľko obsahu máte a kde
    • Ktoré pracovné priestory majú najviac obsahu?
    • Aký typ obsahu sa publikuje v každom pracovnom priestore (najmä keď rozdeľujete pracovné priestory zostáv a pracovné priestory údajov)?
    • Aké závislosti existujú medzi položkami (napríklad tokmi údajov, ktoré podporujú mnoho sémantických modelov, alebo sémantickým modelom, ktorý je zdrojom pre iné zložené modely)?
    • Aký je pôvod údajov (závislosti medzi položkami Power BI vrátane externých zdrojov údajov)?
    • Existujú osirelé zostavy (ktoré sú odpojené od ich sémantického modelu)?
  • Porozumenie pomeru sémantických modelov k zostavám
    • Koľko sémantického modelu sa vyskytuje?
    • Existujú duplicitné alebo veľmi podobné sémantické modely?
    • Existujú možnosti na konsolidáciu sémantických modelov?
  • Vysvetlenie trendov medzi bodmi v čase
    • Zvyšuje sa v priebehu času počet zostáv?
    • Zvyšuje sa v priebehu času počet sémantických modelov?
  • Vyhľadanie nepoužívaého obsahu
    • Ktoré zostavy sa nepoužijú (alebo sú využívané)?
    • Ktoré sémantické modely sa nevyužívajú (alebo sú využívané nedostatočne)?
    • Existujú možnosti, ako odísť do dôchodku obsah?

Inventár nájomníkov vám pomôže použiť aktuálne názvy pri analýze historických aktivít. Snímka položiek vo vašom nájomníkovi obsahuje názvy všetkých položiek v danom okamihu. Je užitočné použiť na historické vytváranie zostáv aktuálne názvy položiek. Ak bola napríklad zostava premenovaná pred tromi mesiacmi, denník aktivity v tom čase zaznamená starý názov zostavy. S správne definovaným dátovým modelom môžete použiť najnovší inventár nájomníka na vyhľadanie položky podľa jej aktuálneho názvu (a nie jej bývalého názvu). Ďalšie informácie nájdete v časti Vytvorenie dátového modelu ďalej v tomto článku.

Ďalšie informácie o spôsoboch používania súpisu nájomníka nájdete v téme Princípy publikovaného obsahu.

Tip

Na vytvorenie úplného obrazu budete často používať skombinovanie udalostí aktivity používateľa (ako je popísané v predchádzajúcej časti) a inventára nájomníkov. Týmto spôsobom zvýšite hodnotu všetkých údajov.

Keďže inventár nájomníka predstavuje snímku v danom časovom okamihu, budete sa musieť rozhodnúť, ako často chcete extrahovať a ukladať metaúdaje. Týždenná snímka je užitočná na porovnávanie dvoch bodov v čase. Ak napríklad chcete preskúmať nastavenia zabezpečenia pracovného priestoru, budete potrebovať predchádzajúcu snímku zásob nájomníka, udalosti denníka aktivity a aktuálnu snímku zásob nájomníka.

Existujú dva hlavné spôsoby vytvorenia súpisu nájomníka. Ďalšie informácie o daných rozhodnutiach a aktivitách nájdete neskôr v tomto článku v téme Prístup k inventáru údajov nájomníka.

Údaje používateľov a skupín

S rastom analytických potrieb pravdepodobne určíte, že chcete do komplexného riešenia auditovania zahrnúť údaje o používateľoch a skupinách. Na načítanie údajov môžete použiť microsoft Graph, ktorý je hlavný zdroj informácií o používateľoch a skupinách služby Microsoft Entra (predtým známych ako Azure Active Directory).

Údaje získané z rozhraní REST API služby Power BI obsahujú e-mailovú adresu popisujúcu používateľa alebo názov skupiny zabezpečenia. Tieto údaje sú snímkou v danom časovom bode.

Tu sú niektoré bežné otázky, na ktoré dokáže Microsoft Graph odpovedať.

  • Identifikácia používateľov a skupín
    • Aké je celé meno používateľa (navyše k e-mailovej adrese), oddeleniu alebo polohe pochádzajúce z používateľského profilu?
    • Kto sú členmi skupiny zabezpečenia?
    • Kto je vlastníkom skupiny zabezpečenia (na spravovanie členov)?
  • Získanie ďalších informácií o používateľovi
    • Ktoré licencie – Power BI Pro alebo Power BI Premium na používateľa – sa priraďujú používateľom?
    • Ktorí používatelia sa prihlasuje najčastejšie?
    • Ktorí používatelia sa v poslednom čase neprihliadli do služba Power BI?

Upozornenie

Niektoré staršie metódy (ktoré sú podrobne zdokumentované online) na prístup k údajom používateľov a skupín, sú zastarané a nemali by sa používať. Vždy, keď je to možné, použite Microsoft Graph ako hlavný zdroj údajov používateľov a skupín.

Ďalšie informácie a odporúčania o prístupe k údajom zo služby Microsoft Graph nájdete v časti Prístup k údajom používateľov a skupín ďalej v tomto článku.

Údaje o zabezpečení

Možno budete mať požiadavku na vykonávanie pravidelných auditov zabezpečenia.

Tu je niekoľko najčastejších otázok, na ktoré môžu odpovedať rozhrania REST API služby Power BI.

  • Identifikácia ľudí a aplikácií
    • Ku ktorým zostavám má používateľ, skupina alebo objekt služby prístup?
    • Ktorí používatelia, skupiny alebo objekty služby sú predplatitelia, ktorí majú prijímať zostavy s prihlásením na odber e-mailov?
  • Vysvetlenie povolení pre obsah
    • Ktoré roly pracovného priestoru sú priradené ktorým používateľom a skupinám?
    • Ktorí používatelia a skupiny sú priradené každej cieľovej skupine aplikácií služby Power BI?
    • Ktoré povolenia pre jednotlivé položky sú priradené, pre ktoré zostavy a pre ktorých používateľov?
    • Ktoré povolenia pre jednotlivé položky sa priraďujú, pre ktoré sémantické modely a pre ktorých používateľov?
    • Ktoré sémantické modely a údajovémarty majú definované zabezpečenie na úrovni riadkov (RLS)?
    • Ktoré položky sa zdieľajú s ľuďmi v celej organizácii?
    • Ktoré položky sa publikujú verejne na internete?
  • Vysvetlenie ďalších povolení
    • Kto má povolenie publikovať pomocou kanála nasadenia?
    • Kto má povolenie na správu brán a pripojení údajov?
    • Kto má povolenie na správu Kapacita Premium?

Dôležité

V čase, keď sa tento článok týka služby Power BI Premium alebo jej predplatných kapacity (skladové jednotky SKU P). Spoločnosť Microsoft v súčasnosti konsoliduje možnosti nákupu a vyradí skladové jednotky SKU služby Power BI Premium na kapacitu. Noví a existujúci zákazníci by namiesto toho mali zvážiť zakúpenie predplatného kapacity služby Fabric (skladové jednotky F SKU).

Ďalšie informácie nájdete v téme Dôležitá aktualizácia pre licencie Power BI Premium a Power BI Premium: najčastejšie otázky.

Tip

Ďalšie informácie o zabezpečení nájdete v článkoch o plánovaní zabezpečenia.

Tieto bežné otázky nie sú úplný zoznam. K dispozícii je široká ponuka rozhraní REST API služby Power BI. Ďalšie informácie nájdete v téme Používanie rozhraní REST API služby Power BI.

Ďalšie informácie o používaní rozhraní API správcu v porovnaní s rozhraniami API používateľa (vrátane toho, ako to ovplyvňuje povolenia vyžadované pre používateľa, ktorý extrahuje údaje) nájdete ďalej v tomto článku v téme Výber rozhrania API používateľa alebo rozhrania API správcu.

Kontrolný zoznam – pri identifikácii údajov, ktoré sú potrebné na auditovanie, ku kľúčovým rozhodnutiam a akciám patria:

  • Identifikujte konkrétne potreby údajov pre údaje o aktivite používateľa: Overte požiadavky, ktoré ste zhromaždili. Identifikujte, ktoré údaje auditovania sú potrebné na splnenie každej požiadavky na údaje o aktivite používateľa.
  • Identifikujte konkrétne potreby údajov pre údaje inventára nájomníkov: Overte požiadavky, ktoré ste zhromaždili. Identifikujte, ktoré údaje auditovania sú potrebné na zostavovanie súpisu nájomníkov.
  • Identifikujte konkrétne potreby údajov pre používateľov a údaje skupín: Overte požiadavky, ktoré ste zhromaždili. Identifikujte, ktoré údaje auditovania sú potrebné na splnenie každej požiadavky pre používateľov a údaje skupín.
  • Identifikujte konkrétne potreby údajov pre údaje zabezpečenia: Overte požiadavky, ktoré ste zhromaždili. Identifikujte, ktoré údaje auditovania sú potrebné na splnenie každej požiadavky na údaje zabezpečenia.
  • Overenie priorít: Overte poradie priorít, aby ste vedeli, čo je potrebné vyvíjať ako prvé.
  • Rozhodnite sa, ako často sa majú zaznamenávať aktivity: Rozhodnite sa, ako často sa majú zaznamenávať udalosti aktivity (napríklad raz za deň).
  • Rozhodnite sa, ako často sa majú zaznamenávať snímky: Rozhodnite sa, v akom intervale sa majú zaznamenávať údaje snímok, napríklad inventár nájomníka alebo používatelia a skupiny údajov.

Typ riešenia auditovania

Auditovanie na úrovni nájomníka sa vykonáva manuálne alebo pomocou automatizovaných procesov.

Väčšina nových procesov auditovania sa spúšťa ako manuálny proces, najmä počas vývoja a počas testovania. Proces manuálneho auditovania sa môže vyvíjať, aby sa stal automatizovaným procesom. Nie každý proces auditovania však musí byť plne automatizovaný.

Manuálne procesy auditovania

Manuálne auditovanie využíva skripty a procesy, ktoré používateľ spúšťa na vyžiadanie (zvyčajne správca služby Power BI). V prípade potreby používateľ spustí interaktívne dotazy na načítanie údajov auditovania.

Manuálny auditovanie je najvhodnejším riešením pre:

  • Nové skripty, ktoré sa vyvíjajú a testujú.
  • Príležitostné a jednorazové potreby auditovania.
  • Potreby prieskumného auditovania.
  • Nonessential auditing procesy, ktoré nevyžadujú úplnú podporu.

Automatizované procesy auditovania

Auditovanie údajov, ktoré sa pravidelne vyžadujú, by malo byť automatizované. Extrahuje sa a spracováva sa podľa pravidelného plánu a je známy ako automatizovaný proces. Niekedy sa označuje ako automatický proces.

Cieľom automatizovaného procesu je znížiť manuálne úsilie, znížiť riziko chýb, zvýšiť konzistenciu a odstrániť závislosť od jednotlivých používateľov, aby ju spustili.

Automatizované auditovanie je najvhodnejším riešením pre:

  • Auditovanie procesov, ktoré sa spúšťajú vo výrobe.
  • Automatické procesy, ktoré sa spúšťajú podľa pravidelného plánu.
  • Skripty, ktoré boli plne testované.
  • Základné procesy auditovania, ktoré majú iné zostavy (alebo iné procesy), ktoré sú na nich závislé ako zdroj údajov.
  • Auditovanie procesov, ktoré sú zdokumentované a podporované.

Typ procesu – manuálny alebo automatizovaný – môže mať vplyv na spôsob spracovania overovania. Správca služby Power BI môže napríklad použiť overovanie používateľa na proces manuálneho auditovania, ale pre automatizovaný proces použiť objekt služby. Ďalšie informácie nájdete v časti Určenie metódy overovania ďalej v tomto článku.

Tip

Ak existuje pravidelná a opakovaná potreba získať údaje auditovania, ktoré sa v súčasnosti spracovávajú manuálne, zvážte investovanie času na ich automatizáciu. Ak napríklad správca služby Power BI každý deň manuálne spustí skript na načítanie údajov z denníka aktivity služby Power BI, hrozí riziko, že táto osoba nebude na dovolenke.

Kontrolný zoznam – pri zvážení typu riešenia auditovania na vytvorenie sa ku kľúčovým rozhodnutiam a akciám patria:

  • Určte primárny účel každej novej požiadavky auditovania: Rozhodnite sa, či chcete pre každú novú požiadavku použiť manuálny alebo automatizovaný proces. Zvážte, či je toto rozhodnutie dočasné alebo trvalé.
  • Vytvorenie plánu na automatizáciu: Ak je vhodné pre konkrétnu požiadavku na auditovanie, vytvorte plán, ako ho automatizovať, kedy a kým.

Povolenia a povinnosti

V tomto bode by ste mali mať jasnú predstavu o tom, čo chcete dosiahnuť, a údaje, ktoré budete na začiatku potrebovať. Teraz je ten správny čas na rozhodovanie o povoleniach používateľa, ako aj rolách a povinnostiach.

Povolenia používateľa

Keď plánujete vytvoriť komplexné riešenie auditovania, zvážte povolenia používateľa pre iných používateľov, ktorí budú potrebovať prístup k údajom. Konkrétne rozhodnite, kto bude môcť získať prístup k údajom auditu a zobraziť ich.

Tu je niekoľko dôležitých informácií, ktoré treba vziať do úvahy.

Priamy prístup k údajom auditovania

Mali by ste sa rozhodnúť, kto bude mať priamy prístup k údajom auditovania. Existuje niekoľko spôsobov, ako nad tým premýšľať.

  • Kto by mal byť správcom služby Power BI? Správca služby Power BI má prístup ku všetkým metaúdajom nájomníka vrátane rozhraní API správcu. Ďalšie informácie o rozhodovaní o tom, kto by mal byť správcom služby Power BI, nájdete v téme Plánovanie zabezpečenia na úrovni nájomníka.
  • Kto môžete použiť existujúci objekt služby? Ak chcete na prístup k údajom auditovania použiť objekt služby (namiesto povolení používateľa), autorizovaným používateľom sa musí poskytnúť tajný kód, aby mohli vykonávať overovanie na základe hesla. Prístup k tajomstvám (a kľúčom) by mal byť veľmi prísne kontrolovaný.
  • Je potrebné prísne riadiť prístup? Niektoré odvetvia s požiadavkami na reguláciu a dodržiavanie súladu musia riadiť prístup prísnejšie ako iné odvetvia.
  • Existujú veľké objemy údajov aktivity? Ak sa chcete vyhnúť dosiahnutiu limitov obmedzovania rozhrania API, možno budete musieť prísne kontrolovať, kto má povolenie priamo pristupovať k rozhraniam API, ktoré vytvárajú údaje auditovania. V tomto prípade je užitočné zabezpečiť, aby nedošlo k duplicitným alebo prekrývajúcim sa snahám.
Prístup k extrahovaným nespracovaným údajom

Mali by ste sa rozhodnúť, kto si môže zobraziť nespracované údaje, ktoré sa extrahujú a zapisujú do ukladacieho priestoru. Prístup k nespracovaným údajom je najčastejšie obmedzený na správcov a audítorov. Centrum excelentnosti (CENTER of Excellence, CE) môže tiež vyžadovať prístup. Ďalšie informácie nájdete v časti Určenie miesta uloženia údajov auditu ďalej v tomto článku.

Prístup k spravovaným analytickým údajom

Mali by ste sa rozhodnúť, kto bude môcť zobraziť spravované a transformované údaje, ktoré sú pripravené na analýzu. Tieto údaje by mali byť vždy k dispozícii správcom a audítorom. Niekedy je dátový model k dispozícii iným používateľom v organizácii, a to najmä vtedy, keď vytvárate sémantický model služby Power BI so zabezpečením na úrovni riadkov. Ďalšie informácie nájdete v časti Plánovanie vytvorenia zostavených údajov ďalej v tomto článku.

Roly a povinnosti

Keď sa rozhodnete, ako fungujú povolenia používateľa, ste v dobrej pozícii, aby ste mohli začať premýšľať o rolách a povinnostiach. Odporúčame, aby ste sa zapojiť správnych ľudí na začiatku, najmä keď sa do vytvárania komplexného riešenia auditovania zapoja viacerí vývojári alebo tímy.

Rozhodnite sa, ktorí používatelia alebo tím budú zodpovední za nasledujúce aktivity.

Rola Typy zodpovedností Rola, ktorú zvyčajne vykonáva
Komunikácia so zainteresovanými stranami Komunikačné aktivity a zhromažďovanie požiadaviek. CE v spolupráci s IT. Môže zahŕňať aj výber ľudí z kľúčových organizačných jednotiek.
Rozhodnite sa pre priority a smerujte podľa požiadaviek Rozhodovacie činnosti súvisiace s komplexným auditovaním riešenia vrátane toho, ako plniť požiadavky. Tím, ktorý dohliada na Službu Power BI v organizácii, ako je napríklad CE. Do kritických rozhodnutí alebo na eskalovanie otázok by sa mohol zapojiť výkonný sponzor alebo riadiaci výbor pre riadenie údajov.
Extrahovanie a ukladanie nespracovaných údajov Vytváranie skriptov a procesov na prístup k údajom a ich extrahovanie. Zahŕňa aj zápis nespracovaných údajov do úložiska. Pracovníci dátového inžiniera, zvyčajne v IT a v spolupráci s CE.
Vytvorenie spravovaných údajov Čistenie, transformácia údajov a vytvorenie vytvorených údajov v návrhu hviezdicovej schémy. Pracovníci dátového inžiniera, zvyčajne v IT a v spolupráci s CE.
Vytvorenie dátového modelu vytvorenie analytického dátového modelu založeného na vytvorených údajoch, Tvorcovia obsahu Power BI, zvyčajne v IT alebo CE.
Vytváranie analytických zostáv Vytváranie zostáv na analýzu vytvorených údajov. Prebiehajúce zmeny v zostavách na základe nových požiadaviek a vtedy, keď budú k dispozícii nové údaje auditovania. Tvorcovia zostáv Power BI, zvyčajne v IT alebo CE.
Analyzujte údaje a postupujte podľa výsledkov. Analyzujte údaje a postupujte ako odpoveď na údaje auditu. Tím, ktorý dohliada na Power BI v organizácii, zvyčajne CE. V závislosti od výsledkov auditu a akcie môže zahŕňať aj iné tímy. Iné tímy môžu zahŕňať zabezpečenie, dodržiavanie súladu, právne postupy, riadenie rizík alebo riadenie zmien.
Testovanie a overenie Testovanie s cieľom zabezpečiť splnenie požiadaviek auditovania a presnosť prezentovaných údajov. Tvorcovia obsahu služby Power BI v spolupráci s tímom, ktorý dohliada na službu Power BI v organizácii.
Zabezpečenie údajov Nastavte a spravujte zabezpečenie pre každú vrstvu úložiska vrátane nespracovaných údajov a vytvorených údajov. Spravujte prístup k sémantickým modelom vytvoreným na analýzu údajov. Správca systému pre systém, ktorý ukladá údaje, v spolupráci s tímom, ktorý dohliada na službu Power BI v organizácii.
Plánovanie a automatizácia Prevádzkujte riešenie a naplánujte proces pomocou nástroja, ktorý si vyberiete. Pracovníci dátového inžiniera, zvyčajne v IT a v spolupráci s CE.
Podpora riešenia Monitorovať riešenie auditu vrátane spustení úloh, chýb a podpory technických problémov. Tím, ktorý spracováva podporu systému Power BI, zvyčajne IT alebo CE.

Mnohé z vyššie uvedených rolí a povinností sa môžu zlúčiť, ak ich bude vykonávať ten istý tím alebo tá istá osoba. Niektoré z týchto rolí môžu vykonávať napríklad správcovia služby Power BI.

Je tiež možné, že rôzni ľudia vykonávajú rôzne úlohy, v závislosti od okolností. Akcie budú kontextové v závislosti od údajov auditu a navrhovanej akcie.

Zvážte niekoľko príkladov.

  • Príklad č. 1: Údaje auditu ukazujú, že niektorí používatelia často exportuje údaje do Excelu. Vykonané akcie: CE kontaktuje konkrétnych používateľov, aby pochopili ich potreby a naučili ich lepšie alternatívy.
  • Príklad 2: Údaje auditu zobrazujú, že prístup externého používateľa sa vyskytuje neočakávane. Vykonané akcie: Správca IT systému aktualizuje príslušné nastavenia ID Microsoft Entra pre prístup externého používateľa. Správca služby Power BI aktualizuje nastavenie nájomníka týkajúce sa prístupu externého používateľa. CE aktualizuje dokumentáciu a školenia pre tvorcov obsahu, ktorí spravujú zabezpečenie. Ďalšie informácie nájdete v téme Stratégia pre externých používateľov.
  • Príklad 3: Údaje auditu ukazujú, že viaceré dátové modely definujú rovnakú mierku inak (k dispozícii v rozhraniach API na skenovanie metaúdajov, ak to umožňujú podrobné nastavenia nájomníka metaúdajov). Akcia prijatá: Výbor pre riadenie údajov začína projekt s definovaním spoločných definícií. CE aktualizuje dokumentáciu a školenia pre tvorcov obsahu, ktorí vytvárajú dátové modely. CE podľa potreby tiež spolupracuje s tvorcami obsahu na aktualizácii svojich modelov. Ďalšie informácie o načítavaní podrobných metaúdajov nájdete neskôr v tomto článku v téme Prístup k inventáru údajov nájomníka.

Poznámka

Nastavenie procesov extrakcie údajov je zvyčajne jednorazovou námahou s príležitostnými vylepšeniami a riešením problémov. Analýza a konanie na údajoch je priebežné úsilie, ktoré si pravidelne vyžaduje neustále úsilie.

Kontrolný zoznam – pri zvažovaní povolení a povinností zahŕňajú kľúčové rozhodnutia a akcie:

  • Identifikujte, ktoré tímy sú zapojené: Určte, ktoré tímy sa zapoja do tvorby komplexných riešení a podpory riešenia auditovania.
  • Rozhodnite sa o povoleniach používateľa: Určte, ako sa nastavia povolenia používateľa na prístup k údajom auditu. Vytvorte dokumentáciu kľúčových rozhodnutí pre neskoršie referencie.
  • Rozhodnite sa o rolách a povinnostiach: Uistite sa, že očakávania budú jasné, kto robí čo, najmä keď sa zapoja viaceré tímy. Vytvorte dokumentáciu pre roly a povinnosti, ktorá zahŕňa očakávané akcie.
  • Priradenie rolí a zodpovedností: Priraďte konkrétne roly a povinnosti konkrétnym ľuďom alebo tímom. V prípade potreby aktualizujte popisy jednotlivých úloh o ľudské zdroje.
  • Vytvorenie školiaceho plánu: Vytvorte plán školení personálu, ak potrebujú nové zručnosti.
  • Vytvorenie plánu krížového trénovania: Zabezpečte, aby pre kľúčové roly boli zavedené krížové trénovanie a zálohovanie.

Technické rozhodnutia

Ak plánujete riešenie auditovania na úrovni nájomníka, musíte vykonať niekoľko dôležitých technických rozhodnutí. Ak chcete zlepšiť konzistentnosť, vyhnúť sa prepracovaniu a zlepšovať zabezpečenie, odporúčame, aby ste tieto rozhodnutia konali čo najskôr.

Prvá fáza plánovania zahŕňa prijímanie nasledujúcich rozhodnutí.

Vyberte technológiu na prístup k údajom auditu

Prvé, čo je potrebné sa rozhodnúť , ako získať prístup k údajom auditu.

Najjednoduchším spôsobom, ako začať, je použiť vopred vytvorené zostavy, ktoré sú k dispozícii v pracovnom priestore na monitorovanie správcom.

Keď potrebujete získať priamy prístup k údajom a vytvoriť vlastné riešenie, použijete rozhranie API (rozhranie aplikačného programu). Rozhrania API sú navrhnuté tak, aby si vymieňali údaje cez internet. Rozhrania POWER BI REST API podporujú žiadosti o údaje pomocou protokolu HTTP. Ľubovoľný jazyk alebo nástroj môže vyvolať rozhrania Power BI REST API, ak je schopná odoslať požiadavku HTTP a dostať odpoveď JSON.

Tip

Rutiny typu cmdlet prostredia PowerShell používajú na prístup k údajom auditu rozhrania Power BI REST API. Ďalšie informácie nájdete v časti Výber rozhraní API alebo rutín typu cmdlet prostredia PowerShell ďalej v tomto článku.

Táto časť sa zameriava na vašu voľbu technológie. Informácie o zdroji na prístup ku konkrétnym typom údajov auditu nájdete neskôr v tomto článku v časti Rozhodnutia o zdroji údajov.

Možnosti platformy

Prístup k údajom auditu môžete získať mnohými rôznymi spôsobmi. V závislosti od technológie, ktorú si vyberiete, sa môžete prikloniť k preferovanému jazyku. Možno budete musieť urobiť konkrétne rozhodnutie o tom, ako naplánovať spustenie skriptov. Technológie sa vo svojej vzdelávacej krivke a jednoduchosti začiatkov veľmi líšia.

Tu je niekoľko technológií, ktoré môžete použiť na načítanie údajov pomocou rozhraní REST API služby Power BI.

Technológie Dobrá voľba pre procesy manuálneho auditovania Dobrá voľba pre automatizované procesy auditovania
Spravovanie monitorovanie pracovného priestoru Spravovanie monitorovanie pracovného priestoru je dobrou voľbou pre procesy manuálneho auditovania.
Vyskúšať Vyskúšajte to– je to dobrá voľba pre procesy manuálneho auditovania.
PowerShell Prostredie PowerShell je dobrou voľbou pre manuálne procesy auditovania. Prostredie PowerShell je dobrou voľbou pre automatizované procesy auditovania.
Power BI Desktop Aplikácia Power BI Desktop je dobrou voľbou pre procesy manuálneho auditovania.
Power Automate Služba Power Automate je dobrou voľbou pre automatizované procesy auditovania.
Preferovaná služba Azure Preferovaná služba Azure je dobrou voľbou pre automatizované procesy auditovania.
Preferovaný nástroj alebo jazyk Preferovaný nástroj alebo jazyk je dobrou voľbou pre procesy manuálneho auditovania. Preferovaný nástroj alebo jazyk je dobrou voľbou pre automatizované procesy auditovania.
Prehľadávanie denníka auditu Microsoft Purview Prehľadávanie denníka auditu Microsoft Purview je dobrou voľbou pre procesy manuálneho auditovania.
Defender for Cloud Apps Defender for Cloud Apps je dobrou voľbou pre procesy manuálneho auditovania.
Microsoft Sentinel Microsoft Sentinel je dobrou voľbou pre automatizované procesy auditu.

Zvyšok tejto časti obsahuje stručný úvod ku každej z možností uvedených v tabuľke.

Spravovanie monitorovanie pracovného priestoru

Pracovný priestor na monitorovanie správcu obsahuje preddefinované zostavy a sémantické modely v služba Power BI. Je to pohodlný spôsob, ako môžu správcovia služby Fabric a globálni správcovia zobraziť nedávne údaje auditu a pomôcť im pochopiť aktivity používateľov.

Vyskúšať si dokumentáciu o rozhraní API

Try-to je interaktívny nástroj, ktorý vám umožní zažiť rozhranie REST API služby Power BI priamo v dokumentácii spoločnosti Microsoft. Ide o jednoduchý spôsob, ako preskúmať rozhrania API, pretože nevyžadujú ďalšie nástroje ani nastavenia v počítači.

Funkciu Try-it môžete použiť na:

  • Manuálne odošlite požiadavku rozhraniu API, aby ste zistili, či vráti požadované informácie.
  • Pred napísaním skriptu zistite, ako je VYTVORENÁ URL adresa.
  • Skontrolovať údaje neformálnym spôsobom.

Poznámka

Ak chcete používať službu Try-it, musíte mať licenciu a overeného používateľa služby Power BI. Sleduje štandardný model povolení, čo znamená, že rozhrania API používateľa sa spoliehajú na povolenia používateľa a rozhrania API správcu vyžadujú povolenia správcu služby Power BI. Pomocou funkcie Try-it nie je možné vykonať overenie pomocou objektu služby.

Keďže je interaktívna, jej pokus je najvhodnejším postupom na učenie, prieskum a nové manuálne procesy auditovania.

PowerShell a Azure Cloud Shell

Skripty prostredia PowerShell môžete vytvárať a spúšťať viacerými spôsobmi.

Tu je niekoľko bežných možností.

  • Visual Studio Code: moderný a ľahký editor zdrojového kódu. Ide o voľne dostupný nástroj typu open-source, ktorý je podporovaný na viacerých platformách vrátane systémov Windows, macOS a Linux. Visual Studio Code môžete používať s mnohými jazykmi vrátane prostredia PowerShell (pomocou rozšírenia prostredia PowerShell).
  • Azure Data Studio: nástroj na vytváranie skriptov a poznámkových blokov. Je zostava založená na visual studiu Code. Azure Data Studio je k dispozícii nezávisle alebo v nástroji SQL Server Management Studio (SSMS). Existuje mnoho rozšírení vrátane rozšírenia pre prostredie PowerShell.
  • Azure Cloud Shell: Alternatíva k lokálnej práci s prostredím PowerShell. K službe Azure Cloud Shell môžete získať prístup z prehliadača.
  • Azure Functions: Alternatíva k lokálnej práci s prostredím PowerShell. Azure Functions je služba Azure, ktorá umožňuje písať a spustiť kód v bezserverovom prostredí. Prostredie PowerShell je jedným z niekoľkých jazykov, ktoré podporuje.

Dôležité

Odporúčame vám na novú vývojovú prácu použiť najnovšiu verziu prostredia PowerShell (PowerShell Core). Mali by ste prestať používať prostredie Windows PowerShell (ktoré sa nedá spustiť v prostredí PowerShell Core) a namiesto toho používať jeden z moderných editorov kódu, ktoré podporujú verziu PowerShell Core. Pri odkazovaní na mnohé online príklady, ktoré používajú prostredie Windows PowerShell (verzia 5.1), dbajte na to, že nepoužívajú najnovšie (a lepšie) prístupy kódu.

Prostredie PowerShell môžete použiť niekoľkými rôznymi spôsobmi. Ďalšie informácie o tomto technickom rozhodnutí nájdete v časti Výber rozhraní API alebo rutín typu cmdlet prostredia PowerShell ďalej v tomto článku.

K dispozícii je mnoho online zdrojov na používanie prostredia PowerShell a často sa dá nájsť skúsených vývojárov, ktorí môžu vytvárať a spravovať riešenia prostredia PowerShell. Prostredie PowerShell je dobrou voľbou v prípade vytvárania manuálnych aj automatizovaných procesov auditovania.

Power BI Desktop

Keďže aplikácia Power BI Desktop sa môže pripojiť k rozhraniam API, môžete byť v pokušení použiť ju na vytvorenie riešenia auditovania. Dôjde však k niekoľkým výrazným nevýhodám a komplikáciám.

  • Hromadia sa história: Keďže denník aktivity služby Power BI poskytuje až 30 dní údajov, vytvorenie celého riešenia auditovania zahŕňa nahromadenie množiny súborov v priebehu času, ktoré uchovávajú všetky historické udalosti. Hromadenie historických súborov je jednoduchšie dosiahnuť s inými nástrojmi.
  • Bezpečné spracovanie poverení a kľúčov: Mnoho riešení, ktoré online nájdete z prispievateľov z komunity, nie je zabezpečených, pretože poverenia a kľúče s pevným kódom sú vo formáte obyčajného textu v rámci dotazov power query. Tento prístup je jednoduchý, neodporúča sa, pretože tieto hodnoty môže čítať každý, kto získa váš súbor aplikácie Power BI Desktop. V aplikácii Power BI Desktop nie je možné bezpečne uložiť heslo (pri používaní overovania používateľa) ani tajný kód (pri použití objektu služby), pokiaľ:
    • Použite vlastný konektor, ktorý bol vyvinutý pomocou súpravy SDK Power Query. Vlastný konektor môže napríklad čítať dôverné hodnoty zo služby Azure Key Vault alebo inej služby, ktorá bezpečne ukladá zašifrovanú hodnotu. K dispozícii sú aj rôzne možnosti vlastného konektora od globálnej komunity Power BI.
    • Použite možnosť ApiKeyName, ktorá funguje dobre v aplikácii Power BI Desktop. Nie je však možné uložiť hodnotu kľúča v služba Power BI.
  • Typy požiadaviek: Môžu sa vyskytnúť určité obmedzenia týkajúce sa toho, čo môžete spustiť v aplikácii Power BI Desktop. Power Query napríklad nepodporuje každý typ požiadavky rozhrania API. Napríklad pri používaní funkcie Web.Contents sa podporujú iba žiadosti GET a POST. Pri auditovaní zvyčajne odosielate žiadosti o získanie.
  • Možnosť obnovenia: Ak chcete úspešne obnoviť sémantický model v služba Power BI, musíte postupovať podľa konkrétnych vývojových vzorov doplnku Power Query. Táto možnosť musí byť napríklad prítomná pri používaní lokality Web.Contents, RelativePath aby služba Power BI mohla správne overiť umiestnenie zdroja údajov bez generovania chyby v služba Power BI.

Vo väčšine prípadov odporúčame používať Power BI Desktop len na dva účely. Mali by ste ho použiť na:

  • Vytvorte dátový model na základe existujúcich zostáv (namiesto toho, aby ste ich použili na na začiatku extrahovanie údajov auditovania).
  • Vytvorte analytické zostavy na základe dátového modelu.
Power Automate

Power Automate môžete so službou Power BI používať mnohými spôsobmi. V súvislosti s auditovaním môžete použiť službu Power Automate na odosielanie žiadostí do rozhraní REST API služby Power BI a potom extrahované údaje ukladať v umiestnení, ktoré ste si vybrali.

Tip

Ak chcete odoslať požiadavky do rozhraní REST API služby Power BI, môžete použiť vlastný konektor pre službu Power Automate na bezpečné overenie a extrahovanie údajov auditu. Prípadne môžete použiť službu Azure Key Vault na odkazovanie na heslo alebo tajný kód. Obe možnosti sú lepšie ako ukladanie hesiel a kódov vo formáte obyčajného textu v rámci postupu Power Automate.

Ďalšie nápady na spôsoby používania služby Power Automate získate vyhľadaním služby Power BI v šablónach služby Power Automate.

Preferovaná služba Azure

Existuje niekoľko služieb Azure, ktoré môžu odosielať požiadavky do rozhrania Power BI REST API. Preferovanú službu Azure môžete použiť napríklad takto:

Vo väčšine prípadov môžete kombinovať výpočtovú službu, ktorá spracováva logiku extrakcie údajov so službou úložiska, ktorá ukladá nespracované údaje (a prípadne spravované údaje). Dôležité informácie týkajúce sa prijímania rozhodnutí o technickej architektúre sú popísané ďalej v tomto článku.

Preferovaný nástroj alebo jazyk

Ak chcete odoslať žiadosti rozhraniam REST API služby Power BI, môžete použiť preferovaný nástroj a preferovaný jazyk. Je to dobrý prístup, ak má váš tím odborné znalosti s konkrétnym nástrojom alebo jazykom, ako napríklad:

  • Python
  • C# v rozhraní .NET Framework. Voliteľne môžete použiť súpravu .NET SDK služby Power BI, ktorá sa správa ako obal nad rozhraniami REST API služby Power BI, s cieľom zjednodušiť niektoré procesy a zvýšiť produktivitu.
  • JavaScript

Portál na správu dodržiavania súladu Microsoft Purview (predtým Centrum dodržiavania súladu pre Microsoft 365) obsahuje používateľské rozhranie, ktoré vám umožňuje zobrazovať a prehľadávať denníky auditu. Zjednotené denníky auditu zahŕňajú Službu Power BI a všetky ostatné služby, ktoré podporujú zjednotené denníky auditu služby Microsoft 365.

Údaje zachytené v zjednotenom denníku auditu sú presne rovnaké údaje, ktoré sú obsiahnuté v denníku aktivity služby Power BI. Keď v portál na správu dodržiavania súladu Microsoft Purview vykonáte prehľadávanie denníka auditu, pridá vašu žiadosť do frontu. Príprava údajov môže trvať niekoľko minút (alebo dlhšie v závislosti od množstva údajov).

Tu je niekoľko bežných spôsobov, ako používať nástroj na vyhľadávanie denníka auditu. Môžete vykonávať nasledujúce činnosti:

  • Ak chcete zobraziť udalosti radu dátumov, vyberte vyťaženie služby Power BI.
  • Vyhľadajte jednu alebo viac konkrétnych aktivít, ako napríklad:
    • Odstránenie zostavy služby Power BI
    • Pridanie správcu prístupu k osobnému pracovnému priestoru v službe Power BI
  • Zobrazenie aktivít jedného alebo viacerých používateľov.

Pre správcov s dostatočnými povoleniami je dobrým riešením pre procesy manuálneho auditovania nástroj prehľadávania denníka auditu v portál na správu dodržiavania súladu Microsoft Purview. Ďalšie informácie nájdete portál na správu dodržiavania súladu Microsoft Purview ďalej v tomto článku.

Používateľské rozhranie služby Defender for Cloud Apps

Defender for Cloud Apps je k dispozícii pre správcov na portáli Microsoft Defender XDR (portál Microsoft 365). Obsahuje používateľské rozhranie na zobrazenie a vyhľadávanie denníkov aktivity pre rôzne cloudové služby vrátane služby Power BI. Okrem iných udalostí, ako je napríklad aktivita prihlásenia používateľa z ID Microsoft Entra, zobrazuje rovnaké udalosti denníka, ktoré pochádzajú z portál na správu dodržiavania súladu Microsoft Purview.

Rozhranie denníka auditu v službe Defender for Cloud Apps je dobrou voľbou pre procesy manuálneho auditovania. Ďalšie informácie nájdete v časti Defender for Cloud Apps ďalej v tomto článku.

Microsoft Sentinel a KQL

Microsoft Sentinel je služba Azure, ktorá umožňuje zhromažďovať, zisťovať, skúmať a reagovať na incidenty a hrozby zabezpečenia. Službu Power BI možno nastaviť v službe Microsoft Sentinel ako konektor údajov, aby sa denníky auditu streamovali zo služby Power BI do služby Microsoft Sentinel Azure Log Analytics (ktorá je súčasťou služby Azure Monitor ). Na analýzu udalostí denníka aktivity, ktoré sú uložené v službe Azure Log Analytics, môžete použiť jazyk Kusto Query Language (KQL).

Použitie kľúčového ukazovateľa výkonu na vyhľadávanie údajov v službe Azure Monitor je dobrou možnosťou na zobrazenie časti denníka auditu. To je tiež dobrou voľbou pre procesy manuálneho auditovania. Ďalšie informácie nájdete v časti Microsoft Sentinel ďalej v tomto článku.

Dôležité informácie týkajúce sa platformy

Tu je niekoľko dôležitých informácií o tom, ako by ste mohli získať prístup k údajom auditu.

  • Vykonávate manuálny alebo automatizovaný proces auditovania? Určité nástroje sa silne zhodujú s manuálnym spracovaním alebo automatizovaným spracovaním. Používateľ napríklad vždy interaktívne spúšťa funkciu Try-it, takže je vhodný iba pre manuálne procesy auditu.
  • Ako vykonáte overenie? Nie všetky možnosti podporujú všetky možnosti overovania. Funkcia Try-it napríklad podporuje iba overovanie používateľov.
  • Ako budete poverenia bezpečne ukladať? Rôzne technológie majú rôzne možnosti ukladania poverení. Ďalšie informácie nájdete v časti Určenie metódy overovania ďalej v tomto článku.
  • S ktorou technológiou sa už váš tím vyzná? Ak je k dispozícii nástroj, ktorý preferuje váš tím a ktorý vám nerobí problém, začnite tam.
  • Aký je váš tím schopný podporovať? Ak nasadený riešenie podporuje iný tím, zvážte, či je daný tím schopný ho adekvátne podporovať. Predpokladajme tiež, že vaše interné tímy môžu podporovať vývoj, ktorý robia konzultanti.
  • Aký nástroj chcete schváliť? Niektoré nástroje a technológie môžu vyžadovať schválenie. Mohlo by to byť spôsobené nákladmi. Môže to byť tiež spôsobené politikami zabezpečenia IT.
  • Aké máte prednosť pred plánovaním? Niektoré technológie sa rozhodnú za vás. Inokedy to bude ďalšie rozhodnutie, ktoré musíte urobiť. Ak sa napríklad rozhodnete písať skripty prostredia PowerShell, môžete naplánovať ich spustenie rôznymi spôsobmi. A naopak, ak používate cloudovú službu, ako napríklad Azure Data Factory, plánovanie je vstavané.

Odporúčame vám, aby ste si pred výberom technológie na prístup k údajom auditu prečítali zvyšok tohto článku.

Kontrolný zoznam – pri rozhodovaní o tom, ktorá technológia sa má použiť na prístup k údajom auditu, ku kľúčovým rozhodnutiam a akciám patria:

  • Diskutujte so svojimi IT pracovníkmi: Porozprávajte sa so svojimi IT tímami, aby ste zistili, či existujú určité nástroje, ktoré sú schválené alebo preferované.
  • Preskúmajte možnosti pomocou malého testovania konceptu (POC): Vyskúšajte si technické testovanie konceptu. Najskôr sa zamerajte na učenie. Potom sa zamerajte na svoje rozhodnutie, ktoré budete používať do budúcnosti.

Určenie metódy overovania

Spôsob, akým plánujete nastaviť overovanie, je kritickým rozhodnutím. Keď začnete s auditovaním a monitorovaním, často ide o jeden z najťažších aspektov. Mali by ste dôkladne zvážiť dostupné možnosti na vykonanie informovaného rozhodnutia.

Dôležité

Informujte sa o tejto záležitosti so svojimi IT tímami a tímami zabezpečenia. Nájdite si čas a naučte sa základy fungovania zabezpečenia v aplikácii Microsoft Entra ID.

Nie každé rozhranie API na internete vyžaduje overenie. Všetky rozhrania REST API služby Power BI však vyžadujú overenie. Keď pristupujete k údajom auditovania na úrovni nájomníka, proces overovania spravuje platforma identity Microsoft. Predstavuje vývoj služby identity Microsoft Entra, ktorá je založená na štandardných protokoloch v odvetví.

Tip

Slovník termínov platformy Microsoft identity je zdroj, ktorý vám pomôže oboznámiť sa so základnými pojmami.

Pred načítavaním údajov auditu je potrebné najprv vykonať overenie, čo sa nazýva prihlásenie. Koncepty overovania a oprávnenia sú samostatné, no predsa súvisiace. Proces overovania overuje identitu toho, kto žiada. Proces oprávnenia udelí (alebo popiera) prístup k systému alebo zdroju tým, že overí, na čo má používateľ alebo objekt služby povolenie.

Keď používateľ alebo objekt služby vykoná overenie, na server prostriedkov sa vydá prístupový token microsoft Entra, ako je napríklad rozhranie REST API služby Power BI alebo rozhranie Microsoft Graph API. Prístupový token predvolene uplynie po jednej hodine. V prípade potreby je možné požiadať o token obnovenia.

Existujú dva typy prístupových tokenov:

  • Tokeny používateľa: vydané v mene používateľa so známou identitou.
  • Tokeny len na úrovni aplikácie: Vydané v mene aplikácie Microsoft Entra (objekt služby).

Ďalšie informácie nájdete v téme Objekty aplikácie a objektu služby v aplikácii Microsoft Entra ID.

Poznámka

Aplikácia Microsoft Entra je konfigurácia identity, ktorá umožňuje automatizovanému procesu integráciu s id Microsoft Entra ID. V tomto článku sa označuje ako registrácia aplikácie. Výraz objekt služby sa v tomto článku tiež bežne používa. Tieto pojmy sú podrobnejšie popísané ďalej v tejto časti.

Tip

Najjednoduchším spôsobom overenia je použitie rutiny typu cmdlet Pripojenie-PowerBIServiceAccount z modulu správy služby Power BI. V článkoch a blogových príspevkoch online sa môžu zobraziť ďalšie rutiny typu cmdlet súvisiace s overovaním. Existujú Login-PowerBI napríklad rutiny typu cmdlet a Login-PowerBIServiceAccount , ktoré sú aliasmi pre Connect-PowerBIServiceAccount rutinu typu cmdlet. K dispozícii je aj rutina typu cmdlet Disconnect-PowerBIServiceAccount , ktorú môžete použiť na explicitné odhlásenie na konci procesu.

V nasledujúcej tabuľke sú popísané dve možnosti overovania.

Typ overenia Popis Určené pre Dobrá voľba pre procesy manuálneho auditovania Dobrá voľba pre automatizované procesy auditovania
Overovanie používateľa Prihláste sa ako používateľ pomocou hlavného mena používateľa (e-mailovej adresy) a hesla. Príležitostné, interaktívne použitie Overenie používateľa je dobrou voľbou pre manuálne procesy auditovania
Overenie objektom služby Prihláste sa ako objekt služby pomocou tajného kódu (kľúča) priradeného k registrácii aplikácie. Prebiehajúce, plánované a automatické operácie Overovanie objektom služby je dobrou voľbou pre automatizované procesy auditovania

Každá možnosť overovania je podrobnejšie popísaná v nasledujúcej časti.

Overovanie používateľa

Overenie používateľa je užitočné v nasledujúcich situáciách.

  • Manuálne procesy auditovania: Chcete spustiť skript pomocou povolení používateľa. Povolenia môžu byť na jednej z dvoch úrovní, v závislosti od typu požiadavky rozhrania API:
    • Spravovanie povolenia pre rozhrania API správcu: Ak chcete odoslať žiadosť rozhraniu API správcu, musíte použiť povolenia správcu služby Power BI.
    • Povolenia používateľa pre používateľské rozhrania API: Ak chcete odoslať žiadosť používateľskému rozhraniu API, musíte použiť svoje povolenia používateľa služby Power BI. Ďalšie informácie nájdete v téme Výber používateľského rozhrania API alebo rozhrania API správcu.
  • Interaktívne prihlásenie: Chcete sa prihlásiť interaktívne, čo vyžaduje zadanie e-mailovej adresy a hesla. Ak chcete používať funkciu Try-it , ktorá sa nachádza v dokumentácii rozhrania Microsoft API, musíte sa napríklad interaktívne prihlásiť.
  • Sledovanie používateľov s metaúdajmi nájomníka: Keď jednotliví používatelia a správcovia odošlú žiadosti o rozhranie API, možno budete chcieť auditovať používateľov. Pri overovaní pomocou objektu služby (popísaného ďalej) je ID používateľa zachytené denníkom aktivity ID aplikácie. Ak overujú viacerí správcovia pomocou rovnakého objektu služby, môže byť ťažké zistiť, ktorý správca získal prístup k údajom.
  • Zdieľané konto správcu: Niektoré tímy IT používajú zdieľané konto správcu. V závislosti od toho, ako sa implementuje a bude riadiť, nemusí to byť najvhodnejší postup. Namiesto zdieľaného konta by ste mali zvážiť použitie služby Microsoft Entra Privileged Identity Management (PIM), ktorá môže používateľovi udeliť príležitostné a dočasné práva správcu služby Power BI.
  • Rozhrania API, ktoré podporujú iba overovanie používateľa: Môže sa stať, že budete musieť použiť rozhranie API, ktoré nepodporuje overovanie objektom služby. V dokumentácii si každé rozhranie API všimne, či ho môže volať objekt služby.

Dôležité

Vždy, keď je to možné, odporúčame pre automatizované procesy používať overovanie objektom služby.

Overenie objektom služby

Väčšina organizácií má jedného nájomníka služby Microsoft Entra, takže podmienky registrácie aplikácie a objektu služby sa zvyknú používať zameniteľne. Pri registrácii aplikácie Microsoft Entra existujú dve súčasti.

  • Registrácia aplikácie:Registrácia aplikácie je globálne jedinečná. Je to globálna definícia registrovanej aplikácie Microsoft Entra, ktorú môžu používať viacerí nájomníci. Registrácia aplikácie je tiež známa ako klientska aplikácia alebo herec. Termín klientska aplikácia zvyčajne znamená počítač používateľa. To však nie je situácia pri registrácii aplikácií. Na portáli Azure sa aplikácie Microsoft Entra nachádzajú na stránke Registrácie aplikácií v ID Microsoft Entra.
  • Objekt služby:objekt služby je lokálnou reprezentáciou registrácie aplikácie, ktorá sa používa v konkrétnom nájomníkovi. Objekt služby je odvodený od registrovanej aplikácie Microsoft Entra. V prípade organizácií s viacerými nájomníkmi služby Microsoft Entra môže na rovnakú registráciu aplikácie odkazovať viac ako jeden objekt služby. Objekty služby na portáli Azure portal nájdete na stránke podnikových aplikácií v identifikátore Microsoft Entra ID.

Keďže objekt služby je lokálne vyjadrenie, termín overovanie objektom služby je najčastejším spôsobom odkazovania na prihlásenia.

Tip

Správca spoločnosti Microsoft Entra vám môže povedať, kto má povolené vytvárať aplikáciu a udeliť súhlas s registráciou aplikácie vo vašej organizácii.

Overovanie objektom služby je užitočné v nasledujúcich situáciách.

  • Automatizované procesy auditovania: Chcete podľa plánu spustiť automatický proces.
  • Do služba Power BI sa netreba prihlasovať: Stačí sa pripojiť a extrahovať údaje. Objekt služby sa nemôže prihlásiť do služba Power BI.
  • Zdieľaný prístup k údajom: Vy (osobne) nie ste správcom služby Power BI, ale máte oprávnenie používať objekt služby. Objekt služby má povolenie na spúšťanie rozhraní API správcu na načítanie údajov na úrovni nájomníka (alebo iných konkrétnych povolení).
  • Používanie viacerými správcami: Chcete povoliť viacerým správcom alebo používateľom používať rovnaký objekt služby.
  • Technické blokovania: Existuje technické blokovanie, ktoré bráni použitiu overenia používateľa. Medzi bežné technické blokovania patria:
    • Viacfaktorové overovanie (MFA): Automatizované procesy auditovania (ktoré sú spustené automaticky) nie je možné overiť pomocou používateľského konta, keď je povolené viacfaktorové overovanie.
    • Synchronizácia hash hesla: Microsoft Entra ID vyžaduje synchronizáciu hash hesla pre používateľské konto na overenie. Niekedy môže túto funkciu zakázať IT alebo tím kybernetickej bezpečnosti.
Účel registrácie a konvencie pomenovania aplikácie

Každá registrácia aplikácie by mala mať jasný názov, ktorý popisuje jej účel a cieľovú skupinu (kto môže používať registráciu aplikácie).

Zvážte implementáciu konvencie pomenovania, ako napríklad: <Vyťaženie> – <účel> – <cieľová skupina> – <typ objektu.>

Tu sú časti konvencie pomenovania.

  • Vyťaženie: Zvyčajne ekvivalentom zdroja údajov (napríklad údajov služby Power BI alebo údajov služby Microsoft Graph).
  • Účel: Podobný úrovni povolení (napríklad Čítanie verzus ReadWrite). Ako je popísané nižšie, účel vám pomôže dodržiavať princíp najmenších oprávnení pri vytváraní samostatných registrácií aplikácie, ktoré dokážu iba čítať údaje.
  • Cieľová skupina: Voliteľné. V závislosti od vyťaženia a účelu cieľová skupina umožňuje určiť zamýšľaných používateľov registrácie aplikácie.
  • Pre prehľadnosť je zahrnutý typ objektu:EntraApp .

Konvencia pomenovania môže byť konkrétnejšia, ak máte viacero nájomníkov alebo viacero prostredí (ako je napríklad vývoj a produkcia).

V nasledujúcej tabuľke sú uvedené príklady registrácie aplikácií, ktoré možno použiť na extrahovanie údajov auditovania na úrovni nájomníka:

Názov registrácie aplikácie Účel Cieľovú
PowerBIData-Read-Spravovanie APIs-EntraApp Extrahovanie metaúdajov pre celého nájomníka na auditovanie a spravovanie služby Power BI. Spravovanie rozhrania API sú vždy iba na čítanie a nemusia mať udelené povolenia v aplikácii Microsoft Entra ID (iba nastavenie nájomníka služby Power BI). Správcovia služby Power BI a Centrum excelentnosti
PowerBIData-ReadWrite-PowerBI Spravovanie istrators-EntraApp Spravovanie nájomníka služby Power BI. Na vytvorenie alebo aktualizáciu prostriedkov sa vyžaduje povolenie na čítanie a zápis. Správcovia služby Power BI a Centrum excelentnosti
GraphData-Read-PowerBI Spravovanie istrators-EntraApp Extrahovanie údajov používateľov a skupín na auditovanie a správu služby Power BI. Vyžaduje sa povolenie na čítanie. Správcovia služby Power BI a Centrum excelentnosti

Spravovanie viacerých registrácií aplikácie na rôzne účely si vyžaduje väčšie úsilie. Môžete však využiť niekoľko výhod.

  • Pozrite si, na čo je registrácia aplikácie určená a prečo: Keď sa zobrazí ID klienta z registrácie aplikácie v údajoch auditovania, budete mať predstavu o tom, na čo sa aplikácia použila a prečo. To je významná výhoda vytvárania samostatných registrácií aplikácie (namiesto použitia iba jednej na všetky účely).
  • Pozrite sa, kto má používať registráciu aplikácie: Keď sa zobrazí ID klienta z registrácie aplikácie, ktoré sa zobrazí v údajoch auditovania, budete mať predstavu o tom, kto ju používal.
  • Zabránenie prekročeniu povolení: Postupujte podľa princípu najmenších oprávnení tým, že poskytujete samostatné registrácie aplikácií rôznym množinám ľudí, ktorí majú rôzne potreby. Môžete sa vyhnúť prepísaniu povolení tak, že použijete registráciu aplikácie iba na čítanie, keď povolenia na zápis nie sú potrebné. Môžete mať napríklad vysoko schopných samoobslužných používateľov, ktorí chcú zhromažďovať údaje o svojich sémantických modeloch. Potrebujú prístup k objektu služby s povolením na čítanie . keďže môžu existovať satelitné členy Centra excelentnosti, ktorí pracujú pre finančný tím, ktorí programovo spravujú sémantické modely; Potrebujú prístup k objektu služby s povolením na zápis .
  • Vedieť, kto by mal byť v držbe tajného kódu: Tajomstvo každej registrácie aplikácie by sa malo zdieľať iba s ľuďmi, ktorí ho potrebujú. Keď sa tajný kód otočí (ako je popísané ďalej v tejto časti), vplyv je menší, keď použijete samostatné registrácie aplikácie pre rôzne potreby. Je to užitočné, keď potrebujete otočiť tajný kód, pretože používateľ opustí organizáciu alebo zmení roly.
Povolenia na registráciu aplikácie

Existujú dva hlavné spôsoby, ako môže registrácia aplikácie získať prístup k údajom a zdrojom. Zahŕňa povolenia a súhlas.

  • Povolenia len na úrovni aplikácie: prístup a oprávnenia spracováva objekt služby bez prihláseného používateľa. Táto metóda overovania je užitočná pre scenáre automatizácie. Pri používaní povolení len na úrovni aplikácie je dôležité pochopiť, že povolenia nie sú priradené v aplikácii Microsoft Entra ID. Namiesto toho sa povolenia priraďujú jedným z dvoch spôsobov:
    • Na spustenie rozhraní API správcu: Niektoré nastavenia nájomníka služby Power BI umožňujú prístup ku koncovým bodom pre rozhrania API správcu (vrátia metaúdaje auditovania v rámci celého nájomníka). Ďalšie informácie nájdete v časti Nastavenie nastavení nájomníka služby Power BI ďalej v tomto článku.
    • Pre spúšťanie rozhraní API používateľa: platia povolenia pre pracovný priestor a položku služby Power BI. Štandardné povolenia Power BI riadia, aké údaje je možné vrátiť objektu služby pri spúšťaní rozhraní API používateľa (ktoré vracajú údaje auditovania na základe povolení používateľa alebo objektu služby, ktorý vyvoláva rozhranie API).
  • Delegované povolenia: používajú sa povolenia založené na rozsahu. Objekt služby pristupuje k údajom v mene aktuálne prihláseného používateľa. Znamená to, že objekt služby nemá prístup k nič viac, než má prihlásený používateľ prístup. Nezabúdajte, že ide o iný koncept, než bol popísaný v minulosti pri overení iba používateľ. Keďže na správne spracovanie kombinácie povolení používateľov a aplikácií sa vyžaduje vlastná aplikácia, delegované povolenia sa pre scenáre auditovania zriedka používajú. Táto koncepcia je zvyčajne nepochopená a jej výsledkom je množstvo registrácií aplikácií, ktoré sa predvídajú s povoleniami.

Dôležité

V tomto článku sa dôraz kladie len na overenie používateľa alebo overovanie len na úrovni aplikácie. Delegované povolenia (s interaktívnym používateľom a objektom služby) môžu hrať dôležitú rolu pri programovom vkladaní obsahu služby Power BI. Dôrazne vás však neodporúča nastavovať delegované povolenia na extrahovanie údajov auditovania. Každé rozhranie API obmedzuje, ako často ho možno spustiť (s obmedzením na mieste), takže nie je praktické mať rôzni používatelia priamy prístup k nespracovaným údajom auditu. Namiesto toho odporúčame extrahovať nespracované údaje auditu raz (centralizovaným procesom) a potom sprístupniť spravované údaje auditu oprávneným používateľom zo služby.

Ďalšie informácie nájdete nižšie v tomto článku v časti Registrácia aplikácie Microsoft Entra.

Registračné tajomstvá aplikácie

Pri registrácii aplikácie je často priradený tajný kód . Tajný kľúč sa používa ako kľúč na overovanie a má dátum uplynutia platnosti. Preto je potrebné naplánovať, ako pravidelne otáčať kľúč a ako oznámiť nový kľúč oprávneným používateľom.

Musíte sa tiež starať o to, kde bezpečne uložiť tajomstvo. Trezor hesiel organizácie, napríklad Azure Key Vault, je výbornou voľbou.

Tip

Namiesto použitia tajného kódu môžete použiť spravovanú identitu. Spravovaná identita eliminuje potrebu spravovania poverení. Ak plánujete na extrahovanie údajov použiť služby, ako napríklad Azure Functions alebo Azure Data Factory, spravovaná identita je dobrou možnosťou na preskúmanie.

Bezpečné spravovanie prihlasovacích údajov

Bez ohľadu na to, či používate overovanie používateľa alebo overovanie objektom služby, jedným z najväčších problémov je spôsob bezpečného spravovania hesiel, tajných kódov a kľúčov.

Výstraha

Prvým pravidlom je pravidlo, ktoré mnohí porušujú: heslá a kľúče by sa nikdy nemali zobrazovať vo formáte obyčajného textu v skripte. Pre jednoduchosť to robí veľa článkov, blogov a príkladov online. Je to však zlý postup, ktorému by ste sa mali vyhnúť. Ktokoľvek, kto získa skript (alebo súbor), môže potenciálne získať prístup k rovnakým údajom, ku ktorým má autor prístup.

Tu je niekoľko bezpečných metód, ktoré môžete použiť na správu hesiel, tajné kódy a kľúče.

  • Integrácia so službou Azure Key Vault alebo iným systémom trezora hesiel organizácie vždy, keď je to možné.
  • Použite poverenia a zabezpečené reťazce v skriptoch prostredia PowerShell. Poverenia fungujú na overenie používateľa aj pre overovanie objektom služby. Prihlasovacie údaje však nie je možné použiť, ak je pre používateľské konto povolené viacfaktorové overovanie.
  • Výzva na zadanie hesla v skripte PowerShell alebo použitie interaktívneho overovania v prehliadači.
  • Použite modul Správa tajných kódov pre prostredie PowerShell publikované spoločnosťou Microsoft. Hodnoty môže ukladať pomocou lokálneho trezora. Dokáže sa tiež integrovať so vzdialenou službou Azure Key Vault, čo je užitočné, ak je vo vašej organizácii viacero správcov, ktorí pracujú s tými istými skriptami.
  • Vytvorte vlastný konektor pre aplikáciu Power BI Desktop, aby bolo možné bezpečne spracovať poverenia. Niektoré vlastné konektory sú k dispozícii od členov komunity (zvyčajne v GitHube).

Tip

Odporúčame vám, aby ste si poradili so svojimi tímami IT a zabezpečenia, aby ste pomohli vybrať najlepšiu metódu, alebo overiť, či vaše riešenie spravuje poverenia bezpečným spôsobom.

Knižnica overenia spoločnosti Microsoft

Podpora knižnice overenia Azure AD (ADAL) sa skončila v decembri 2022. V budúcnosti by ste mali používať knižnicu overenia spoločnosti Microsoft (MSAL). Tím zabezpečenia vo vašej organizácii by mal byť oboznámený s touto významnou zmenou.

Hoci pre odborníkov v službe Power BI nie je dôležité, aby dôkladne porozumeli prechodu na službu MSAL, mali by ste sa riadiť nasledujúcimi odporúčaniami.

  • Najnovšiu verziu modulu správy služby Power BI použite pri overovaní pomocou rutiny typu cmdlet prostredia PowerShell pre Pripojenie-PowerBIServiceAccount. Prepnite sa z ADAL na MSAL vo verzii 1.0.946 (26. februára 2021).
  • Pri overovaní priamo v skripte použite koncový bod Microsoft Entra V2. Koncový bod Microsoft Entra V2 používa funkciu MSAL, zatiaľ čo koncový bod Microsoft Entra V1 používa ADAL.
  • Ukončite používanie rozhraní API a modulov, ktoré sú zastarané. Ďalšie informácie nájdete v časti Zastarané rozhrania API a moduly ďalej v tomto článku.
  • Ak nájdete riešenie komunity online, uistite sa, že na overovanie používa službu MSAL a nie nástroj ADAL.

Kontrolný zoznam – pri rozhodovaní o spravovaní overovania, kľúčové rozhodnutia a akcie zahŕňajú:

  • Rozhodnite sa, ktorý typ overenia použiť: Určite, či je overovanie používateľa alebo overovanie objektom služby najvhodnejšie v závislosti od typu riešenia auditovania, ktoré plánujete vytvoriť.
  • Plánovanie potrebných registrácií aplikácií: Zvážte svoje požiadavky, vyťaženia a cieľovú skupinu (používatelia každej registrácie aplikácie). Naplánujte si počet registrácií aplikácií, ktoré potrebujete vytvoriť na podporu týchto potrieb.
  • Vytvorenie konvencie pomenovania pre registráciu aplikácií: Nastavte konvenciu pomenovania, ktorá uľahčuje pochopenie zamýšľaného účelu a zamýšľaných používateľov každej registrácie aplikácie.
  • Plánujte, ako bezpečne spravovať poverenia: Zvážte spôsoby bezpečného spravovania hesiel, tajomstiev a kľúčov. Zvážte, aká dokumentácia a školenia môžu byť potrebné.
  • Potvrďte použitie funkcie MSAL: Určte, či existujú existujúce manuálne alebo automatizované riešenia auditovania, ktoré využívajú službu ADAL. Ak je to potrebné, vytvorte plán na prepísanie týchto riešení tak, aby používali novšiu knižnicu overenia MSAL.

Výber rozhrania API používateľa alebo rozhrania API správcu

Pri plánovaní načítania údajov auditovania je dôležité použiť správny typ rozhrania API.

Existujú dva typy rozhraní API, ktoré je potrebné vziať do úvahy.

  • Rozhrania API používateľa: Spoliehanie sa na povolenia prihláseného používateľa (alebo objektu služby) na odosielanie žiadostí do rozhrania API. Jedným zo spôsobov, ako napríklad vrátiť zoznam sémantických modelov v pracovnom priestore, je s rozhraním API používateľa. Povolenie na čítanie sémantických modelov možno udeliť buď rolou pracovného priestoru, alebo povoleniami pre jednotlivé položky. Existujú dva spôsoby, ako spustiť rozhrania API používateľov:
    • Overenie používateľa: Prihlásený používateľ musí mať povolenie na prístup k pracovnému priestoru alebo položke.
    • Overovanie objektom služby: Objekt služby musí mať povolenie na prístup k pracovnému priestoru alebo položke.
  • rozhrania API služby Spravovanie: Načítanie metaúdajov z nájomníka. Niekedy sa označuje ako rozsah organizácie. Ak chcete napríklad vrátiť zoznam všetkých sémantických modelov v nájomníkovi, použijete rozhranie API správcu. Rozhrania API správcu možno spustiť dvoma spôsobmi:
    • Overenie používateľa: Prihlásený používateľ musí byť správcom služby Power BI, aby sa mohli spúšťať rozhrania API správcu.
    • Overenie objektom služby: Objekt služby musí mať povolenie na spúšťanie rozhraní API správcu (bez toho, aby sa spoliehali na povolenia zabezpečenia, ako to robí rozhranie API používateľa).

Tip

Všetky rozhrania API správcu patria do skupiny operácií Spravovanie. Každé rozhranie API s príponou As Spravovanie je správcom rozhrania API. Všetky zostávajúce rozhrania API sú používateľské rozhrania API.

Zoberme si príklad, v ktorom potrebujete získať zoznam sémantických modelov. V nasledujúcej tabuľke je uvedených šesť možností rozhrania API, ktoré môžete použiť. Štyri možnosti sú používateľské rozhrania API a dve možnosti sú rozhrania API správcu. Rozsah a počet vrátených položiek sa líšia v závislosti od vami vybratého rozhrania API.

Názov rozhrania API Typ rozhrania API Rozsah Počet sémantických modelov
Získať množinu údajov Používateľ Osobný pracovný priestor Jednu
Získať množiny údajov Používateľ Osobný pracovný priestor Všetko
Načítať množinu údajov v skupine Používateľ Jeden pracovný priestor Po jednom za predpokladu, že prihlásený používateľ má povolenie na čítanie sémantického modelu
Načítanie množín údajov v skupine Používateľ Jeden pracovný priestor Všetko za predpokladu, že prihlásený používateľ má povolenie na čítanie každého sémantického modelu
Načítanie množín údajov v skupine ako Spravovanie Správca Jeden pracovný priestor Všetko
Získanie množín údajov ako Spravovanie Správca Celý nájomník Všetko

Poznámka

Niektoré názvy rozhrania API zahŕňajú výraz Skupina ako odkaz na pracovný priestor. Tento výraz pochádzal z pôvodného modelu zabezpečenia služby Power BI, ktorý sa spoliehal na skupiny v Microsoft 365. Hoci sa model zabezpečenia služby Power BI v priebehu rokov výrazne zmenil, existujúce názvy rozhraní API zostávajú nezmenené, aby sa predišlo porušeniu existujúcich riešení.

Informácie o nastaveniach nájomníka nájdete v časti Nastavenie nastavení nájomníka služby Power BI ďalej v tomto článku.

Kontrolný zoznam – kľúčové rozhodnutia a akcie zahŕňajú:

  • Pozrite si požiadavky na údaje: Zhromažďovanie a zdokumentovanie kľúčových obchodných požiadaviek pre riešenie auditovania. Na základe potrebného typu údajov určte, či je vhodný rozsah používateľov alebo rozsah organizácie.
  • Testovanie výsledkov: Vykonajte niekoľko experimentov. Otestujte presnosť výsledkov, ktoré vrátia rôzne rozhrania API.
  • Kontrola povolení: V prípade všetkých existujúcich riešení auditovania potvrďte, že povolenia sú správne priradené správcom služby Power BI a objektom služby. V prípade nových riešení auditovania potvrďte, ktorá metóda overovania sa použije.

Výber rozhraní API alebo rutín typu cmdlet prostredia PowerShell

Kľúčovým rozhodnutím je použitie rutín typu cmdlet prostredia PowerShell, keď sú k dispozícii pre konkrétne údaje, ktoré chcete načítať. Toto rozhodnutie je dôležité, ak ste sa rozhodli, že prostredie PowerShell je jednou z technológií, ktoré budete používať na prístup k údajom auditu.

Prostredie PowerShell je riešenie automatizácie úloh. Pojem PowerShell je kolektívny pojem, ktorý odkazuje na jazyk skriptovania, aplikáciu command-line shell a architektúru správy konfigurácie. PowerShell Core je najnovšia verzia prostredia PowerShell, ktorá funguje v systémoch Windows, Linux a macOS.

Rutina typu cmdlet prostredia PowerShell je príkaz, ktorý vykoná akciu. Modul PowerShell je balík s členmi prostredia PowerShell, ako sú napríklad rutiny typu cmdlet, poskytovatelia, funkcie, pracovné postupy, premenné a aliasy. Stiahnete a nainštalujete moduly.

Modul PowerShell vytvorí vrstvu abstrakcie cez rozhrania API. Napríklad rutina typu cmdlet Get-PowerBIActivityEvent načíta (alebo načíta) udalosti auditu pre nájomníka služby Power BI. Táto rutina typu cmdlet prostredia PowerShell načíta údaje z rozhrania Get Activity Events REST API. Vo všeobecnosti je jednoduchšie začať používať rutiny typu cmdlet, pretože zjednodušuje prístup k základným rozhraniam API.

Ako rutiny typu cmdlet prostredia PowerShell je k dispozícii len podmnožina rozhraní API. Keďže budete naďalej rozširovať celé riešenie auditovania, je pravdepodobné, že budete používať kombináciu rutín typu cmdlet a rozhraní API. Zvyšok tejto časti vám pomôže rozhodnúť sa, akým spôsobom budete mať prístup k údajom.

Moduly prostredia PowerShell

Spoločnosť Microsoft publikovala dva moduly PowerShell, ktoré obsahujú rutiny typu cmdlet súvisiace so službou Power BI. Sú to modul Správa služby Power BI a modul Brána údajov. Tieto moduly PowerShell fungujú ako obal rozhrania API nad základnými rozhraniami Power BI REST API. Pomocou týchto modulov PowerShell môžete jednoduchšie zapisovať skripty.

Tip

Okrem modulov publikovaných spoločnosťou Microsoft sú k dispozícii aj voľne dostupné moduly a skripty prostredia PowerShell, ktoré publikujú (zvyčajne v službe GitHub) členovia komunity, partneri služby Power BI a členovia komunity Microsoft Most Valued Professionals (GP).

Začatie riešenia komunity môže zohrávať dôležitú úlohu pri budovaní vášho komplexného riešenia auditovania. Ak sa rozhodnete používať voľne dostupné riešenie, nezabudnite ho plne otestovať. Oboznámte sa s tým, ako funguje, aby ste mohli efektívne spravovať svoje riešenie v priebehu času. Vaše IT oddelenie môže mať kritériá na používanie verejne dostupných riešení komunity.

Modul Správa služby Power BI

Modul Správa služby Power BI je súhrnný modul, ktorý obsahuje konkrétne moduly služby Power BI na správu, kapacity, pracovné priestory a ďalšie. Ak chcete získať všetky moduly, môžete si nainštalovať modul súhrnu, alebo si môžete nainštalovať konkrétne moduly. Všetky moduly správy Power BI sú podporované v prostredí Windows PowerShell aj v prostredí PowerShell Core.

Dôležité

Odporúčame, aby ste prestali používať prostredie Windows PowerShell (ktoré sa nedá spustiť v prostredí PowerShell Core). Namiesto toho použite jeden z moderných editorov kódu, ktorý podporuje PowerShell Core. Windows PowerShell ISE (integrované skriptové prostredie) má iba možnosť spustenia prostredia PowerShell verzie 5.1, ktorá sa už neaktualizuje. Windows PowerShell je v súčasnosti zastaraný, preto odporúčame používať PowerShell Core na novú vývojovú prácu.

Tu je niekoľko bežne používaných rutín typu cmdlet, ktoré môžete použiť na načítanie údajov auditovania.

Modul správy Cmdlet Účel
Profil Pripojenie-PowerBIServiceAccount Overenie používateľa služby Power BI alebo objektu služby.
Správca Get-PowerBIActivityevent Zobrazte alebo extrahujte udalosti denníka aktivity služby Power BI pre nájomníka.
Pracovné priestory Get-PowerBIWorkspace Kompilujte zoznam pracovných priestorov.
Zostavy Get-PowerBIReport Kompilujte zoznam zostáv pre pracovný priestor alebo nájomníka.
Údaje Get-PowerBIDataset Kompilujte zoznam sémantických modelov pre pracovný priestor alebo nájomníka.
Profil Vyvolať–PowerBIRestMethod Odoslanie požiadavky rozhrania REST API (príkaz). Táto rutina typu cmdlet je dobrou možnosťou, pretože môže vyvolať akékoľvek rozhranie REST API služby Power BI. Je tiež dobrou voľbou, ak chcete použiť jednoduchšiu formu overenia pomocou Connect-PowerBIServiceAccount rutiny typu cmdlet a vyvolať rozhranie API, ktoré nemá zodpovedajúcu rutinu typu cmdlet prostredia PowerShell. Ďalšie informácie nájdete v časti Dôležité informácie o používaní rutín typu cmdlet prostredia PowerShell ďalej v tejto časti.

Tip

Na správu a publikovanie obsahu sú k dispozícii aj ďalšie rutiny typu cmdlet. Tento článok sa však zameriava na načítanie údajov auditovania.

Modul Správa služby Power BI si môžete stiahnuť z galérie Prostredia PowerShell. Najjednoduchší spôsob inštalácie modulov je použitie prostredia PowerShellZískať.

Odporúčame vám nainštalovať modul súhrnu Správa služby Power BI. Týmto spôsobom sú k dispozícii všetky rutiny typu cmdlet, ktoré budete potrebovať. Minimálne budete potrebovať modul Profil (na overenie) a všetky konkrétne moduly, ktoré obsahujú rutiny typu cmdlet, ktoré chcete použiť.

Výstraha

Moduly udržiavajte aktuálne v každom serveri, počítači používateľa a cloudovej službe (napríklad v službe Azure Automation), kde používate prostredie PowerShell. Ak sa moduly pravidelne neaktualizujú, mohli by sa vyskytnúť nepredvídateľné chyby alebo problémy. Niektoré nástroje (napríklad Visual Studio Code) pomáhajú moduly aktualizovať. Upozorňujeme, že pri inštalácii alebo aktualizácii novšej verzie modulu služba PowerShellGet automaticky neodinštaluje staršie verzie modulu. Nainštalujú sa novšie verzie spolu so staršími verziami. Odporúčame vám skontrolovať nainštalované verzie a pravidelne odinštalovať staršie verzie.

Modul Brána údajov

Modul Brána údajov obsahuje rutiny typu cmdlet, ktoré načítavajú údaje z lokálnej brány údajov a jej zdrojov údajov. Modul Brána údajov je podporovaný len v prostredí PowerShell Core. Nie je podporovaná v prostredí Windows PowerShell.

Na rozdiel od modulu Správa služby Power BI (ako bolo uvedené vyššie), modul Brána údajov neobsahuje žiadne rutiny typu cmdlet pre správcov. Mnohé rutiny typu cmdlet (a zodpovedajúce rozhrania API brány) vyžadujú, aby mal používateľ práva správcu brány.

Upozornenie

Objekt služby nie je možné priradiť ako správcu brány (ani keď je objekt služby členom skupiny zabezpečenia). Preto plánujete pri načítavaní informácií o bránach údajov použiť prihlasovacie údaje používateľa.

Tu je niekoľko rutín typu cmdlet z modulu Brána údajov, ktoré môžete použiť na načítanie údajov auditovania.

Cmdlet Účel
Pripojenie-DataGatewayServiceAccount Overenie používateľa služby Power BI (zvyčajne vyžaduje, aby používateľ patrí do roly správcu brány).
Get-DataGatewayCluster Kompilujte zoznam klastrov brán.
ZdrojÚdajov Get-DataGatewayClusterDataSource Kompilujte zoznam zdrojov údajov pre klaster brány.
Get-DataGatewayInstaller Overte, ktorí používatelia majú povolené inštalovať a registrovať brány v organizácii.

Modul Brána údajov si môžete stiahnuť z galérie prostredia PowerShell.

Techniky na použitie prostredia PowerShell

Prostredie PowerShell môžete použiť niekoľkými rôznymi spôsobmi. Rozhodnutie, ktoré vykonáte, je dôležité.

Nasledujúca tabuľka popisuje tri rôzne techniky používania prostredia PowerShell.

Technika Popis Príklad
Na zjednodušenie overovania a priame volanie rozhraní API môžete použiť rutiny typu cmdlet prostredia PowerShell. Odporúčaný prístup Pri tejto technike je rovnováha jednoduchosti a flexibility. Rutina typu cmdlet Invoke-PowerBIRestMethod je k dispozícii v module Profil spravovania služby Power BI. Táto rutina typu cmdlet sa často označuje ako Švajčiarsky armádny nôž , pretože ju môžete použiť na volanie ľubovoľného rozhrania REST API služby Power BI. Výhodou tohto postupu je, že overovanie môžete zjednodušiť a potom zavolať ktorékoľvek z rozhraní REST API služby Power BI. Dôrazne odporúčame, aby ste používali túto metódu. Po overení pomocou rutiny typu cmdlet Pripojenie-PowerBIServiceAccount použite rutinu typu cmdlet Invoke-PowerBIRestMethod na načítanie údajov z preferovaného rozhrania API (napríklad získať používateľov kanála ako Spravovanie).
Rutiny typu cmdlet použite v čo najväčšej možnej miere z prostredia PowerShell na overovanie aj na načítanie údajov. Pri tejto technike sa prostredie PowerShell používa vo veľkej miere. Prostredie PowerShell sa používa na koordinovanie spustenia skriptu a moduly PowerShell sa používajú vždy, keď je to možné na prístup k údajom. To vytvára väčšiu závislosť od prostredia PowerShell z viacerých aspektov. Po overení pomocou rutiny typu cmdlet Pripojenie-PowerBIServiceAccount použite na načítanie údajov rutinu typu cmdlet (napríklad Get-PowerBIActivityEvent).
Na koordinovanie spustenia procesu použite prostredie PowerShell. Moduly prostredia PowerShell sa používajú čo najmenej. Pri tejto technike závisí prostredie PowerShell ako nástroj menej, pretože jeho primárnym použitím je koordinovanie vyvolávania volaní API. Na prístup k rozhraniam API sa používa iba jeden všeobecný modul PowerShell (nepoužíva sa žiadny z modulov modulov správy služby Power BI). Po overení pomocou knižnice overenia spoločnosti Microsoft (MSAL) zavolajte preferované rozhranie API (napríklad Získať používateľov kanála ako Spravovanie) pomocou všeobecnej rutiny typu cmdlet Invoke-RestMethod na načítanie údajov.

Prvá technika vo vyššie uvedenej tabuľke opisuje prístup, ktorý vyrovnáva jednoduché používanie s flexibilitou. Tento prístup poskytuje najlepšiu rovnováhu pre potreby väčšiny organizácií, preto sa odporúča. Niektoré organizácie môžu mať existujúce politiky IT a preferencie zamestnancov, ktoré ovplyvňujú spôsob, akým sa rozhodnete používať prostredie PowerShell.

Tip

Rutinu typu cmdlet Invoke-ASCmd prostredia PowerShell môžete použiť na vytvorenie a spustenie skriptov DAX, XMLA a TMSL . Tieto prípady použitia však nie sú súčasťou tohto článku. Ďalšie informácie o dotazovaní dynamických zobrazení správy (DMV) nájdete v téme Auditovanie na úrovni údajov.

Technickí používatelia (a správcovia) môžu používať moduly správy služby Power BI na načítanie údajov alebo automatizáciu niektorých aspektov správy obsahu.

  • Pre správcov: Nastavte -Scope parameter tak, aby Organization mal prístup k entitám v rámci celého nájomníka (napríklad na načítanie zoznamu všetkých pracovných priestorov).
  • Pre technických používateľov: Nastavte -Scope parameter na Individual (alebo parameter vynecháte) na prístup k entitám, ktoré patria k používateľovi (napríklad na načítanie zoznamu pracovných priestorov , ku ktorým má používateľ povolenie na prístup).

Uvažujme o scenári, v ktorom potrebujete získať zoznam sémantických modelov. Ak sa rozhodnete pracovať priamo s rozhraniami API, musíte zadať rozhranie API, ktoré sa má volať. Ak sa však rozhodnete použiť rutinu typu cmdlet Get-PowerBIDataset , môžete nastaviť -Scope parameter tak, aby načítal zoznam sémantických modelov pre konkrétneho používateľa alebo celého nájomníka. Výber závisí od vášho rozhodnutia o používaní prostredia PowerShell (popísané v predchádzajúcej tabuľke).

Nasledujúca tabuľka popisuje, ako sa parametre použité v rutine typu cmdlet prostredia PowerShell prekladajú do volaní prostredia PowerShell rozhrania API.

Parametre rutín typu cmdlet Rozhranie API, ktoré používa rutina typu cmdlet Typ rozhrania API Rozsah Načítané položky
-DatasetID {DatasetID}
-Scope Individual		 Získať množinu údajov Používateľ Osobný pracovný priestor Jeden sémantický model
-Scope Individual Získať množiny údajov Používateľ Osobný pracovný priestor Všetky sémantické modely
-DatasetID {DatasetID}
-GroupID {WorkspaceID}		 Načítať množinu údajov v skupine Používateľ Jeden pracovný priestor Jeden sémantický model za predpokladu, že prihlásený používateľ má povolenie na čítanie sémantického modelu
-GroupID {WorkspaceID} Načítanie množín údajov v skupine Používateľ Jeden pracovný priestor Všetky sémantické modely za predpokladu, že prihlásený používateľ má povolenie na prístup k pracovnému priestoru a na čítanie sémantického modelu
-GroupID {WorkspaceID}
-Scope Organization		 Načítanie množín údajov v skupine ako Spravovanie Správca Jeden pracovný priestor Všetky sémantické modely
-Scope Organization Získanie množín údajov ako Spravovanie Správca Celý nájomník Všetky sémantické modely
Dôležité informácie o používaní rutín typu cmdlet prostredia PowerShell

Rutiny typu cmdlet prostredia PowerShell služby Power BI sa používajú jednoduchšie, pretože abstraktujú zložitosť volaní rozhrania REST API.

Tu je niekoľko spôsobov, ako rutiny typu cmdlet zjednodušujú prístup k údajom auditovania.

  • Overovanie: Najjednoduchší spôsob overenia v skripte PowerShell je použitie Connect-PowerBIServiceAccount rutiny typu cmdlet.
  • Jednoduchosť: Je jednoduchšie začať, pretože techniky na načítanie údajov auditovania sú jednoduché. Zoberme si, že keď používate rutinu typu cmdlet Get-PowerBIActivityEvent , načítate údaje auditu za jeden deň . Ak však priamo zavoláte rozhranie REST API na získanie udalostí aktivity, načítate hodinu údajov auditu. Takže ak používate rozhranie REST API na načítanie údajov auditu za jeden deň, musíte použiť slučku na volanie rozhrania API 24-krát a extrahovať každú hodinu dňa.
  • Stránkovanie veľkých množín výsledkov: Veľké množiny výsledkov sa efektívne načítavajú stránkovaním. Stránkovanie zahŕňa načítanie jedného bloku výsledkov naraz. Rutiny typu cmdlet automaticky spravujú stránkovanie za vás. Ak však priamo používate rozhrania REST API, váš skript musí skontrolovať pokračový token, aby ste zistili, či prídu ďalšie výsledky. Skript by mal pokračovať v načítavaní blokov výsledkov, kým sa neprijmú žiadne pokračovacie tokeny. Príklad použitia pokračového tokenu nájdete v téme Rozhranie REST API aktivít udalostí.
  • Vypršania platnosti prístupového tokenu: Po overení sa vráti prístupový token. Predvolene uplynie jeho platnosť po jednej hodine. Rutiny typu cmdlet za vás riešia uplynutie platnosti prístupového tokenu. Týmto spôsobom nemusíte zapisovať logiku, aby ste mohli požiadať o token obnovenia.
  • Formátovanie: Údaje vrátené rutinou typu cmdlet sa formátujú o niečo krajšie ako údaje vrátené rozhraním REST API. Výstup je prehľadnejší. V prípade automatizovaných procesov auditovania to pravdepodobne nebude problém. Pre manuálne procesy auditovania však môže byť užitočné krajšie formátovanie.
Dôležité informácie o priamom používaní rozhraní REST API

Niekedy máte výhody priameho volania rozhrania REST API služby Power BI.

  • K dispozícii je oveľa viac rozhraní API: K dispozícii je viac rozhraní REST API ako rutiny typu cmdlet prostredia PowerShell. Nepredzerajte však flexibilitu rutiny typu cmdlet Invoke-PowerBIRestMethod , ktorú môžete použiť na volanie ľubovoľného z rozhraní REST API služby Power BI.
  • Frekvencia aktualizácií: Spoločnosť Microsoft aktualizuje rozhrania REST API častejšie než moduly PowerShell. Ak sa napríklad do odpovede rozhrania API Načítať množinu údajov pridá nový atribút, môže trvať nejaký čas, kým sa sprístupní vo výsledkoch rutiny typu cmdlet Get-PowerBIDataset .
  • Menej závislosti jazyka alebo nástroja: Keď používate rozhrania REST API priamo (namiesto rutiny typu cmdlet), nemusíte používať prostredie PowerShell. Alebo sa môžete rozhodnúť použiť prostredie PowerShell iba na zostáv a koordinovať volanie mnohých rozhraní API v skripte. Odstránením (alebo odstránením) akejkoľvek závislosti v prostredí PowerShell môžete niekedy v budúcnosti prepísať svoju logiku v inom jazyku. Ak má váš IT alebo tím pre vývojárov silné preferencie pre nástroje a jazyky, je potrebné brať do úvahy menej závislosti.

Bez ohľadu na spôsob, ktorý sa rozhodnete použiť, rozhrania REST API sa môžu v priebehu času meniť. Keď sa technológia ďalej vyvíja, rozhrania API (a moduly PowerShell) sa môžu zastarať a nahradiť. Preto odporúčame, aby ste cieľavedome vytvárali skripty, ktoré sa dajú jednoducho udržiavať a odolne voči zmenám.

Kontrolný zoznam – kľúčové rozhodnutia a akcie zahŕňajú:

  • Konzultácia s IT prostredím o používaní prostredia PowerShell: Obráťte sa na príslušné it tímy a zistite, či existujú interné požiadavky alebo preferencie týkajúce sa používania prostredia PowerShell.
  • Rozhodnite sa, ako chcete použiť prostredie PowerShell: určite, ktoré techniky prostredia PowerShell použiť a či chcete zámerne zvýšiť alebo znížiť závislosť od prostredia PowerShell. Zvážte, či je potrebná interná komunikácia alebo školenie.
  • Inovujte na prostredie PowerShell Core: Research pomocou prostredia PowerShell Core. Určte, či je potrebné aktualizovať počítače správcu. Zvážte, ktoré existujúce skripty je potrebné testovať. Určiť, či správcovia alebo vývojári potrebujú ďalšie školenia, aby mohli inovovať svoje zručnosti.
  • Určite, ktoré moduly prostredia PowerShell sa majú použiť: Zvážte, či sa budú používať moduly Správy služby Power BI alebo modul Brána údajov.
  • Rozhodnite sa, či sú povolené projekty komunity: Určite, či máte povolené používanie modulov PowerShell online (namiesto modulov publikovaných spoločnosťou Microsoft). Poraďte sa s IT a zistite, či existujú kritériá pre projekty komunity získané online.
  • Objasnite, ako podporovať projekty komunity: Ak sú povolené projekty komunity PowerShell, zvážte, kto bude zodpovedný za ich podporu, keď sa použijú interne.
  • Dokončite malú kontrolu koncepcie (POC): Experimentujte s technickým testovaním konceptu. Potvrďte preferované klientske nástroje a metódu prístupu k údajom.
  • Určite, ako podporovať pokročilých používateľov: Zvážte, ako budete podporovať technických používateľov, ktorí vytvárajú automatizáciu sami pomocou používateľských rozhraní API.

Určenie miesta uloženia údajov auditu

Keď plánujete vytvoriť komplexné riešenie auditovania, musíte sa rozhodnúť, kam uložiť nespracované údaje (a spravované údaje, ktoré sú popísané v nasledujúcej časti). Vaše rozhodnutia o úložisku údajov súvisia s vašimi preferenciami, ktoré sa týkajú spôsobu spracovávania integrácie údajov.

Keď extrahujete nespracované údaje auditovania, používajte ich jednoducho. Pri prvom extrahovaní údajov odporúčame nevyberať konkrétne atribúty, vykonávať transformácie ani formátovanie. Namiesto toho extrahujte všetky dostupné atribúty a uložte údaje v ich pôvodnom stave.

Tu je niekoľko dôvodov, prečo je ukladanie nespracovaných údajov v ich pôvodnom stave najvhodnejším postupom.

  • Všetky údaje, ktoré sú k dispozícii v histórii: Nové atribúty a nové typy udalostí budú postupne k dispozícii. Uloženie všetkých nespracovaných údajov je dobrý spôsob, ako zabezpečiť, aby ste mali vždy prístup ku všetkým údajom, ktoré boli v čase extrahovania k dispozícii. Ak si uvedomíte, že sú k dispozícii nové atribúty údajov, aj keď vám to trvá čas, čo môžu byť týždne alebo mesiace, v minulosti je ich možné analyzovať, pretože ste ich zachytili v nespracovaných údajoch.
  • Odolný voči zmene: Ak sa formát nespracovaných údajov zmení, proces extrahovania údajov nebude ovplyvnený. Keďže niektoré údaje auditovania sú citlivé na čas, je dôležité zabezpečiť, aby ste navrhli proces extrakcie údajov, ktorý nesklame, keď dôjde k zmene v zdroji.
  • Roly a povinnosti: Za vytváranie procesov na prístup, extrahovanie a ukladanie nespracovaných údajov auditu môžu byť zodpovední rôzni členovia tímu (napríklad dátoví inžinieri alebo globálni správcovia). Zjednodušenie procesu extrakcie údajov uľahčuje spoluprácu viacerých tímov.

Tu je niekoľko možností uloženia nespracovaných údajov.

  • Úložisko dátového jazera alebo objektu: cloudová služba, napríklad OneLake, ktorá sa špecializuje na ukladanie súborov ľubovoľnej štruktúry. Je to ideálna voľba na uloženie nespracovaných údajov auditu. V architektúre dátového jazera by sa mali nespracované údaje ukladať do bronzovej vrstvy.
  • Systém súborov: Systém súborov (napríklad Windows alebo Linux) je bežnou voľbou pri ukladaní nespracovaných údajov auditu.
  • Databáza: Údaje JSON je možné uložiť do relačnej databázy, ako je napríklad databáza Azure SQL. Je to však menej bežné ako ukladanie údajov v dátovom jazere alebo systéme súborov. Je to spôsobené tým, že dotazovanie a udržiavanie údajov JSON môže byť náročné a nákladné, najmä keď objemy údajov rastú.

Tip

Ak používate dátové jazero, úložisko objektov alebo systém súborov, odporúčame, aby ste údaje uložili tak, aby ste ich mohli jednoducho usporiadať a zabezpečiť. Tiež je dôležité prečítať si, či údaje obsahujú udalosti (ktoré sú zvyčajne pripojené) alebo či ide o snímku v určitom bode v čase (ktorá vyžaduje výber dátumu na analýzu).

Zoberme si príklad zahŕňajúci nespracované údajové zóny dátového jazera. Oblasť má hierarchiu priečinkov na ukladanie údajov denníka aktivity: Raw > ActivityLog > YYYY > MM. Priečinky sú rozdeľované podľa rokov a mesiacov. Súbor uložený v priečinku month má nasledujúci formát: PBIActivityLog-YYYYMMDD-YYYYMMDDTTTT.json. YYYYMMDD predstavuje skutočné údaje a YYYYMMDTTTT predstavuje časová pečiatka extrakcie. Zahrnutím časovej pečiatky extrakcie môžete určiť, ktorý súbor je najnovší (v prípade, že bude potrebné údaje znova extrahovať). Ak napríklad extrahujete údaje o 9:00 (UTC) 25. apríla 2023 na aktivitu 23. apríla 2023, názov súboru bude PBIActivityLog-20230523-202305250900.

Dôrazne odporúčame, aby ste používali technológiu, ktorá umožňuje zapisovať nespracované údaje do nemenného úložiska. Nemenné úložisko zaručuje, že po napísaní údajov ich nemožno prepísať ani odstrániť. Tento rozdiel je pre audítorov dôležitý a umožňuje vám dôverovať, že nespracované údaje sú spoľahlivé.

Mali by ste tiež zvážiť bezpečné ukladanie nespracovaných údajov. Zvyčajne prístup k nespracovaným údajom vyžaduje len veľmi málo používateľov. Prístup k nespracovaným údajom sa zvyčajne poskytuje na základe potrieb, zvyčajne pre dátových inžinierov a správcov systému. Vaši interní audítori možno budú potrebovať prístup. Členovia tímu, ktorí sú zodpovední za vytváranie spravovaných údajov (ako je popísané ďalej), tiež vyžadujú prístup k nespracovaným údajom.

Tu je niekoľko dôležitých informácií, ktoré vám pomôžu vybrať nespracované úložisko údajov.

  • Je to manuálny alebo automatizovaný proces auditovania? Automatizovaný proces auditovania má zvyčajne prísnejšie požiadavky na spôsob a miesto uloženia údajov.
  • Je oblasť veľmi citlivá? V závislosti od typu údajov a jeho citlivosti môže mať vaša organizácia požiadavku na to, ako a kde sú uložené. Údaje auditu služby Power BI obsahujú identifikáciu informácií o používateľovi a IP adresy, a preto by mali byť uložené v zabezpečenej oblasti.
  • Existuje preferovaná technológia úložiska? V rámci organizácie sa môže používať existujúca technológia úložiska, takže ide o logickú voľbu.
  • Pristupuje používateľ priamo k úložisku? Dôležitý je model zabezpečenia. Prístup k nespracovaným údajom je zvyčajne udelený len veľmi málo používateľov. Prístup k spravovaným údajom sa zvyčajne sprístupní tvorcom obsahu služby Power BI, ktorí sú zodpovední za vytvorenie centralizovaného dátového modelu (sémantického modelu, ktorý slúži ako vrstva na vytváranie zostáv).
  • Máte požiadavky na pobyt údajov? Niektoré organizácie majú zákonné alebo regulačné požiadavky na pobyt údajov na ukladanie údajov v konkrétnej oblasti údajov.
  • Ako budú údaje usporiadané? Používanie architektúry medailónu je bežnou praxou, najmä v implementáciách dátového jazera a údenia jazera. Cieľom je uložiť údaje vo vrstvách bronzových, strieborných a zlatých. Bronzová vrstva obsahuje pôvodné nespracované údaje. Strieborná vrstva obsahuje overené a deduplicated údaje použité na transformácie. Zlatá vrstva obsahuje vybrané a vysoko upresnené údaje pripravené na analýzu.

Kontrolný zoznam – pri plánovaní umiestnenia na ukladanie nespracovaných údajov, ku kľúčovým rozhodnutiam a akciám patria:

  • Konzultácia s IT: Obráťte sa na príslušné it tímy a zistite, či sú spustené existujúce procesy na extrahovanie nespracovaných údajov auditu. Ak áno, zistite, či máte prístup k existujúcim údajom. Ak sa vyžaduje nový proces extrahovania údajov, určte, či existujú preferencie alebo požiadavky na miesta, kde by sa mali údaje ukladať.
  • Rozhodnite sa, kam sa majú uložiť nespracované údaje: Určte najlepšiu polohu a štruktúru úložiska na ukladanie nespracovaných údajov.
  • Určenie požiadaviek na umiestnenia údajov: Zistite, či existujú právne alebo regulačné požiadavky na miesta uloženia údajov.
  • Vytvorenie štruktúry priečinkov a konvencie pomenovania: Určite, akú konvenciu pomenovania sa majú použiť pre nespracované údajové súbory vrátane štruktúry priečinkov. Tieto podrobnosti zahrňte do technickej dokumentácie.
  • Zvážte, ako bude fungovať zabezpečenie pre nespracované údaje: Keď navrhnete nespracované miesto úložiska údajov, zvážte, kto bude musieť získať prístup k údajom a ako bude udelený prístup.

Plánovanie vytvorenia zostáv

Vytvorené údaje podporujú analýzu a sú navrhnuté tak, aby boli používateľsky príjemné. Musíte urobiť niekoľko rozhodnutí o tom, ako a kde sa budú vytvorené údaje vytvárať. Technológia, ktorú sa rozhodnete uložiť spravované údaje, môže byť niektorá z technológií uvedených v predchádzajúcej časti.

Cieľom spravovaných údajov je transformovať údaje na prehľadnejší formát, ktorý je optimalizovaný na analýzu a vytváranie zostáv. Tvorí zdroj údajov dátového modelu Power BI, čo znamená, že na analýzu používania služby Power BI vo vašej organizácii používate dátový model Power BI. Platí sprievodný materiál k základnému dátovému modelu: Mali by ste prijať návrh hviezdicovej schémy, ktorý je optimalizovaný z hľadiska výkonu a použiteľnosti.

Môžete sa rozhodnúť vytvárať spravované údaje rôznymi spôsobmi. Musíte sa rozhodnúť, ako vykonať integráciu údajov a do akej miery vykonať upstream na použitie transformácií, ktoré pripravujú údaje na načítanie do hviezdicovej schémy.

Dátové jazero

V dátovom jazere môžete použiť transformácie a vytvoriť spravované údajové súbory. Na vytvorenie údajov by ste mali použiť zlatú vrstvu, aby sa logicky oddelili od nespracovaných údajov uložených v bronzovej vrstve. Oddelenie údajov vo vrstvách tiež zjednodušuje nastavenie rôznych povolení prístupu používateľov.

Dátové jazero môžete použiť na transformáciu a vytvorenie údajov v nasledujúcich prípadoch:

  • Očakávate, že bude k dispozícii viacero dátových modelov služby Power BI, ktoré slúžia na tvorbu zostáv (čo odôvodňuje vytvorenie prostrednej striebornej vrstvy).
  • Musíte podporovať viacerých samoobslužných tvorcov obsahu, ktorí potrebujú prístup k údajom auditu na úrovni nájomníka.
  • Máte existujúce nástroje a procesy, ktoré chcete použiť na transformáciu a načítanie údajov.
  • Chcete minimalizovať prípravu údajov, ktorú je potrebné vykonať (a potenciálne duplikovať) v rámci jedného alebo viacerých dátových modelov služby Power BI.
Dátový model služby Power BI

Možno budete môcť dokončiť všetky transformácie v službe Power BI. Power Query môžete použiť na prístup k údajom zo nespracovaného stavu a ich transformáciu do spravovaného formátu.

Dátový model Power BI použite v prípadoch, keď:

  • Chcete zjednodušiť klientsku architektúru a načítať dátový model priamo zo nespracovaných údajov. (Prírastkové obnovenie môže pomôcť skrátiť trvanie obnovenia.)
  • Uprednostňujete, aby všetky transformácie fungovali pri načítavaní dátového modelu.
  • Očakávate, že pre údaje auditu na úrovni nájomníka budete mať jeden centralizovaný dátový model. Všetky zostavy (alebo iné dátové modely) môžu ako zdroj používať centralizovaný sémantický model služby Power BI.
  • Chcete používateľovi poskytnúť prístup len k centralizovanému sémantickému modelu služby Power BI (a nie k žiadnym zdrojovým údajom).

Tip

Keď vytvárate spravované údaje, nastavte ich tak, aby ste mohli jednoducho znova spustiť proces pre predchádzajúce rozsahy dátumov. Ak napríklad zistíte, že v denníkoch auditu sa pred tromi mesiacmi objavil nový atribút, mali by ste ho vedieť analyzovať od jeho prvého vzniku. Možnosť opätovného načítanie spravovanej histórie údajov je jedným z niekoľkých dôvodov, prečo je dôležité uložiť nespracované údaje v ich pôvodnom stave (popísané vyššie v tomto článku).

Ďalšie informácie o tom, aké tabuľky dimenzií a tabuľky faktov môžete zahrnúť do hviezdicovej schémy, nájdete ďalej v tomto článku v časti Vytvorenie dátového modelu .

Kontrolný zoznam – pri plánovaní vytvárania spravovaných údajov, ku kľúčovým rozhodnutiam a akciám patria:

  • Rozhodnite sa, kde by sa mali transformácie vykonať: Zvážte, ako ďaleko je potrebné vykonať transformáciu na pozadí a kde je to vhodné do vášho plánu pre celú architektúru.
  • Rozhodnite sa, ktorý nástroj použijete na transformáciu údajov do hviezdicovej schémy: Potvrďte, ktoré nástroje a služby sa použijú na transformáciu nespracovaných údajov do spravovaných údajov.
  • Rozhodnite sa, kde by sa mali ukladať spravované údaje: Určte najlepšou voľbou pre uloženie nespracovaných údajov, ktoré boli transformované do formátu hviezdicovej schémy. Rozhodnite sa, či je medzikrok strieborná vrstva užitočná v architektúre od konca po koniec.
  • Vytvorenie konvencie pomenovania: Určite, akú konvenciu pomenovania sa majú použiť pre spravované údajové súbory a priečinky (ak sa používajú). Zahrňte podrobnosti do technickej dokumentácie.
  • Zvážte, ako bude fungovať zabezpečenie pre spravované údaje: Pri navrhovaní spravovaného umiestnenia úložiska údajov zvážte, kto bude musieť získať prístup k údajom a ako bude priradené zabezpečenie.

Rozhodnutia o zdroji údajov

V tomto bode by ste mali mať prehľad o požiadavkách, potrebách údajov a povoleniach. Prijali sa kľúčové technické rozhodnutia. Teraz je potrebné urobiť niekoľko rozhodnutí o prístupe, ako získate určité typy údajov.

Prístup k údajom aktivity používateľa

Údaje o aktivite používateľa služby Power BI, ktoré sa niekedy označujú ako denník aktivity alebo denníky auditu, obsahujú množstvo informácií, ktoré vám pomôžu pochopiť, čo sa deje v nájomníkovi služby Power BI. Ďalšie informácie o identifikácii potrieb vašich údajov nájdete vyššie v tomto článku v časti Údaje o aktivite používateľa.

Power BI integruje svoje denníky so zjednoteným denníkom auditu Microsoft Purview (predtým známym ako zjednotený denník auditu služby Microsoft 365). Táto integrácia je výhodou, pretože znamená, že každá služba v službe Microsoft 365 nemusí implementovať svoj vlastný jedinečný spôsob zapisovania do denníka. Predvolene je zapnutá.

Dôležité

Ak ešte neextrahujete údaje o aktivite používateľa, musíte to nastaviť ako naliehavú prioritu. Údaje o aktivite používateľa sú k dispozícii za posledných 30 alebo 90 dní (v závislosti od zdroja). Aj keď nie ste pripravení vykonávať hĺbkovú analýzu, je dôležité začať extrahovať a ukladať údaje čo najskôr. Týmto spôsobom budete mať na analýzu k dispozícii cennú históriu.

Údaje o aktivite používateľa môžete načítať viacerými spôsobmi.

Technika Popis K dispozícii sú predvolené dni histórie Dobrá voľba pre procesy manuálneho auditovania Dobrá voľba pre automatizované procesy auditovania Dobrá voľba na nastavenie upozornenia Dobrá voľba na rýchle začatie
Manuálne (používateľské rozhranie) portál na správu dodržiavania súladu Microsoft Purview 90 portál na správu dodržiavania súladu Microsoft Purview je dobrou voľbou pre procesy manuálneho auditovania. portál na správu dodržiavania súladu Microsoft Purview je dobrou voľbou, ako rýchlo začať.
Manuálne (používateľské rozhranie) Defender for Cloud Apps 30 Defender for Cloud Apps je dobrou voľbou pre procesy manuálneho auditovania. Defender for Cloud Apps je dobrou voľbou na nastavenie upozornenia.
Programový Denník aktivity služby Power BI (rozhranie API alebo rutina typu cmdlet prostredia PowerShell) 30 Denník aktivity služby Power BI (API alebo rutina typu cmdlet prostredia PowerShell) je dobrou voľbou pre automatizované procesy auditovania. Denník aktivity služby Power BI (rozhranie API alebo rutina typu cmdlet prostredia PowerShell) je dobrou voľbou, ako rýchlo začať.
Programový Rozhranie API aktivity správy služieb Office 365 7 Rozhranie Office 365 Management Activity API je dobrou voľbou pre automatizované procesy auditovania.
Programový Microsoft Sentinel (Azure Monitor) 30 Microsoft Sentinel (Azure Monitor) je dobrou voľbou pre automatizované procesy auditovania. Microsoft Sentinel (Azure Monitor) je dobrou voľbou na nastavenie upozornenia.

V zostávajúcej časti sa uvádza každá z techník uvedených v tabuľke.

portál na správu dodržiavania súladu Microsoft Purview

Nástroj na vyhľadávanie auditu v portál na správu dodržiavania súladu Microsoft Purview (predtým známy ako Centrum dodržiavania súladu pre Microsoft 365) je pohodlné miesto na zobrazenie aktivít a upozornení. Tento nástroj nevyžaduje vytvorenie skriptu na extrahovanie a sťahovanie údajov. Ak chcete zobraziť všetky záznamy denníka auditu na určitú dobu, môžete si vybrať vyťaženie služby Power BI. Výsledky môžete tiež zúžiť výberom konkrétnych aktivít a používateľov. Manažér vás napríklad požiada, aby ste zistili, kto predchádzajúci deň odstránil pracovný priestor, aby sa mohli rýchlo obrátiť na osobu, ktorá by prediskutovala situáciu.

Posledných 90 dní histórie je k dispozícii v časti Audit (štandardné) . Pomocou kapacity Audit (Premium) umožňuje dlhodobé uchovávanie údajov (voliteľne) ponechať denníky auditu dlhšie. Keďže dlhodobé uchovávanie sa vzťahuje len na používateľov s licenciou E5, vylučuje záznamy auditu pre používateľov bez E5 a hosťovských používateľov. Preto odporúčame, aby ste sa spoliehali iba na predvolenú 90-dňovú históriu, aby sa zaistilo zachytenie všetkých aktivít.

Na prístup k denníkom auditu v portál na správu dodržiavania súladu Microsoft Purview sa musia spĺňať licenčné požiadavky. Na prístup k denníkom auditu sa vyžadujú aj zvýšené povolenia Exchange Online.

Tip

Správcovia služby Power BI predvolene nemajú povolenie na prístup k zjednotenému prehľadávaniu denníka auditu v portál na správu dodržiavania súladu Microsoft Purview. Keďže obsahuje údaje pre mnohé služby služby Microsoft 365, ide o rolu s vysokými oprávneniami. Vo väčšine organizácií sú tieto povolenia vyhradené pre malý počet správcov IT. Pre správcov služby Power BI sú k dispozícii aj ďalšie možnosti, ktoré sú popísané ďalej v tejto časti.

Používateľské rozhranie v portál na správu dodržiavania súladu Microsoft Purview je užitočné pre procesy manuálneho auditovania a príležitostné skúmania činností používateľa.

Defender for Cloud Apps

Portál v službe Defender for Cloud Apps je pohodlné miesto na zobrazenie aktivít a upozornení bez nutnosti vytvoriť skript na extrahovanie a sťahovanie údajov. Umožňuje tiež zobraziť údaje z denníka aktivity služby Power BI a prihlásenia používateľov.

Defender for Cloud Apps obsahuje používateľské rozhranie na zobrazovanie a vyhľadávanie denníkov aktivity pre rôzne cloudové služby vrátane Power BI. Zobrazuje rovnaké udalosti denníka, ktoré pochádzajú zo zjednoteného denníka auditu Microsoft Purview a zahŕňa aj iné udalosti, ako napríklad aktivitu prihlásenia používateľa z id Microsoft Entra ID.

Rovnako ako portál na správu dodržiavania súladu Microsoft Purview (ako je popísané v predchádzajúcej časti), defender for Cloud Apps má prehľadávateľné používateľské rozhranie. Možnosti filtra sú však iné. Okrem štandardnej 30-dňovej histórie môžete použiť Defender for Cloud Apps na zobrazenie až šiestich mesiacov histórie denníka aktivity (v sedemdňových prírastkoch).

Na prístup k službe Defender for Cloud Apps sa musia spĺňať licenčné požiadavky. Vyžadujú sa aj samostatné povolenia .

Tip

Správcovia služby Power BI predvolene nemajú povolenie na prístup k defender for Cloud Apps. V službe Defender for Cloud Apps existuje rola služby Power BI. Pridanie správcov služby Power BI do tejto roly je dobrý spôsob, ako im udeliť prístup k obmedzenej množine údajov.

Používateľské rozhranie v službe Defender for Cloud Apps je užitočné v prípade manuálnych procesov auditovania a jednorazového skúmania aktivít používateľov.

Denník aktivity služby Power BI

Denník aktivity služby Power BI pochádza zo zjednoteného denníka auditu. Obsahuje iba aktivity používateľa súvisiace s služba Power BI.

Tip

V prípade organizácií, ktoré plánujú extrahovať aktivity používateľov, odporúčame začať s denníkom aktivity služby Power BI. Je to najjednoduchší zdroj na programový prístup.

K denníku aktivity služby Power BI môžete získať prístup dvoma možnosťami.

Informácie o tom, ktorú možnosť použiť, nájdete v časti Výber rozhraní API alebo rutín typu cmdlet prostredia PowerShell vyššie v tomto článku.

Tip

Príklady prístupu k denníku aktivity služby Power BI pomocou prostredia PowerShell nájdete v téme Prístup k denníku aktivity služby Power BI.

Údaje denníka aktivity služby Power BI sú k dispozícii pre všetkých správcov služby Power BI, správcov Power Platformy a globálnych správcov. K údajom je možné získať prístup zo zjednoteného denníka auditu, ktorý je k dispozícii pre určité roly Exchange Online. Ďalšie informácie nájdete v téme Sledovanie aktivít používateľa v službe Power BI.

Odporúčame, aby ste použili denník aktivity služby Power BI, keď máte v úmysle načítať len záznamy denníka auditu služby Power BI.

Poznámka

V údajoch denníka auditu sa pracovné priestory označujú ako priečinky. V rozhraní REST API služby Power BI sa pracovné priestory označujú ako skupiny.

Rozhranie API aktivity správy služieb Office 365

Zo zjednoteného denníka auditu môžete extrahovať údaje pre iné služby, napríklad SharePoint Online, Teams, Exchange Online, Dynamics 365 a Power BI. Ak je vaším cieľom implementovať riešenie auditovania a monitorovania pre viaceré služby, odporúčame použiť rozhranie Office 365 Management Activity API. Keďže toto rozhranie API vracia údaje z mnohých služieb, označuje sa ako rozhranie API zjednoteného auditovania (alebo zjednotený denník auditu). Je jedným z rozhraní API pre riadenie služieb Office 365.

Skôr než vytvoríte nové riešenie, odporúčame vám kontaktovať IT oddelenie a zistiť, či sú k dispozícii existujúce záznamy auditu Služby Power BI. Je možné, že proces už extrahuje a ukladá údaje. Taktiež je možné, že získate povolenie na prístup k týmto údajom, a nie na vytvorenie nového riešenia.

K údajom môžete získať prístup dvomi spôsobmi.

Dôležité

Rutina Search-UnifiedAuditLog typu cmdlet nie je správne škálovaná a vyžaduje, aby ste implementovali stratégiu slučiek, aby ste prekonali limit 5 000 riadkov. Z týchto dôvodov je vhodná pre príležitostné dotazy alebo pre malé organizácie, ktoré majú nízku aktivitu. Ak potrebujete len údaje služby Power BI, odporúčame použiť rutinu typu cmdlet Get-PowerBIActivityEvent .

Vo všeobecnosti je začatie práce s rozhraním API aktivity spravovania služieb Office 365 náročnejšie ako používanie denníka aktivity služby Power BI (ako bolo popísané vyššie). Dôvodom je, že rozhranie API vracia objekty BLOB obsahu a každý objekt BLOB obsahu obsahuje jednotlivé záznamy auditu. Vo veľkých organizáciách môžu denne existovať tisíce objektov BLOB obsahu. Keďže zákazníci a aplikácie tretích strán toto rozhranie API vo veľkej miere používajú, spoločnosť Microsoft implementuje obmedzenie, aby zaistila, že ich používanie služby nebude mať negatívny vplyv na ostatných (známych ako problém s hlučným susedom ). Načítavanie veľkých objemov histórie preto môže byť výzvou vo väčších organizáciách. Ďalšie informácie nájdete v tomto článku o riešení problémov.

Ak chcete používať toto rozhranie API, musíte vykonať overenie pomocou objektu služby, ktorému bolo udelené povolenie na načítanie údajov z rozhrania API aktivity správy služieb Office 365.

Tip

Správcovia služby Power BI predvolene nemajú povolenie na prístup k rozhraniu API aktivity správy služieb Office 365. Keďže obsahuje údaje pre mnohé služby služby Microsoft 365, prístup vyžaduje roly správcu s vysokými oprávneniami alebo auditu. Vo väčšine organizácií sú tieto roly vyhradené pre malý počet správcov IT. Denník aktivity služby Power BI je určený na použitie pre správcov služby Power BI.

Načítanie údajov auditu pomocou programovania z rozhrania API aktivity správy služieb Office 365 je dobrou voľbou, keď IT potrebuje extrahovať a ukladať denníky auditu z rôznych služieb (mimo služby Power BI).

Microsoft Sentinel

Microsoft Sentinel je služba Azure, ktorá umožňuje zhromažďovať, zisťovať, skúmať a reagovať na incidenty a hrozby zabezpečenia. Power BI môžete nastaviť v službe Microsoft Sentinel ako konektor údajov. Po pripojení sa denníky auditu (ktoré obsahujú podmnožinu údajov) streamujú zo služby Power BI do služby Azure Log Analytics, ktorá je funkciou služby Azure Monitor.

Tip

Azure Log Analytics je založená na rovnakej architektúre, ktorú používajú denníky udalostí sémantického modelu na úrovni pracovného priestoru. Ďalšie informácie o denníkoch udalostí sémantických modelov nájdete v téme Auditovanie na úrovni údajov.

Keďže ide o samostatnú službu Azure, každému správcovi alebo používateľovi, ktorého chcete spustiť dotazy jazyka Kusto Query Language (KQL), musia byť udelené povolenia v službe Azure Log Analytics (Azure Monitor). Ak majú povolenie, môžu dotazovať údaje auditu uložené v tabuľke PowerBIActivity . Majte však na pamäti, že vo väčšine prípadov udelíte používateľom prístup k spravovaným údajom v zlatej vrstve, a nie k nespracovaným údajom v bronzovej vrstve.

KQL sa používa na analýzu udalostí denníka aktivity uložených v službe Azure Log Analytics. Ak máte skúsenosti s jazykom SQL, nájdete mnoho podobností s KQL.

Existuje niekoľko spôsobov prístupu k udalostiam uloženým v službe Azure Log Analytics. Môžeš použiť:

  • Vopred vytvorená aplikácia šablóny Log Analytics pre sémantické modely Power BI.
  • Konektor aplikácie Power BI Desktop pre Azure Data Explorer (Kusto).
  • Používanie webových dotazov v prieskumníkovi Azure Data Explorer.
  • Akýkoľvek nástroj dotazov, ktorý môže odosielať dotazy KQL.

Výstraha

Uvedomte si, že v službe Azure Monitor je uložená iba podmnožina údajov denníka aktivity služby Power BI. Ak plánujete vykonať komplexnú analýzu používania a prijatia služby Power BI v organizácii, odporúčame na načítanie údajov o aktivite použiť iné možnosti (popísané vyššie v tejto časti).

Obdobie histórie, ktoré môžete načítať, závisí od politiky uchovávania údajov pre pracovný priestor Azure Log Analytics. Pri rozhodovaní o tom, koľko údajov sa majú uchovávať, zvážte náklady a prístup k nespracovaným údajom.

Microsoft Sentinel a Azure Monitor sú vhodné možnosti, keď IT už investíciu v službe Microsoft Sentinel, úroveň zachytených podrobností vyhovuje vašim potrebám a aktivity, ako napríklad zisťovanie hrozieb, sú prioritou. Keďže však služba Microsoft Sentinel nezachytí všetky údaje o aktivite služby Power BI, nepodporuje vykonanie komplexnej analýzy používania a prijatia služby Power BI.

Dôležité informácie o údajoch o aktivite používateľov

Tu je niekoľko dôležitých informácií, ktoré vám pomôžu vybrať zdroj údajov o aktivite používateľa.

  • Bude to manuálny alebo automatizovaný proces auditovania? Možnosti používateľského rozhrania fungujú dobre pri procesoch manuálneho auditovania a príležitostných jednorazových dotazoch, najmä ak potrebujete preskúmať konkrétnu aktivitu. Automatizovaný proces auditovania, ktorý extrahuje údaje o aktivite používateľa podľa plánu, bude tiež potrebný na podporu analýzy historických údajov.
  • Ako často potrebujete údaje o aktivite používateľa? V prípade automatizovaných procesov auditovania plánujete extrahovať údaje, ktoré sú aspoň jeden deň pred aktuálnym dátumom, prostredníctvom koordinovaného svetového času (UTC) namiesto miestneho času. Ak sa napríklad proces spustí v piatok ráno (čas UTC), mali by ste extrahovať údaje zo stredy. Existuje niekoľko dôvodov, prečo by ste mali extrahovať údaje s jednodenovým oneskorením.
    • S vašimi súbormi sa bude pracovať jednoduchšie, keď vždy extrahujete celých 24 hodín naraz, čím sa zabráni čiastočným výsledkom dňa.
    • Minimalizujete riziko chýbajúcich niektorých udalostí auditu. Zvyčajne sa udalosti auditu doruvajú do 30 minút. Niekedy môže trvať až 24 hodín, kým sa niektoré udalosti dostanú do zjednoteného denníka auditu.
  • Potrebujete viac ako údaje služby Power BI? Zvážte najefektívnejší spôsob prístupu k tomu, čo potrebujete.
  • Kto vyvinie riešenie? Plánujeme investovať nejaký čas na vybudovanie riešenia. Vytvorenie skriptu pripraveného na produkciu môže trvať značné úsilie.

Kontrolný zoznam – pri plánovaní prístupu k údajom aktivity používateľa, ku kľúčovým rozhodnutiam a akciám patria:

  • Objasnite rozsah potrieb: Určte, či potrebujete získať prístup len k záznamom auditu služby Power BI alebo k údajom auditu pre viaceré služby.
  • Konzultácia s IT: Zistite, či IT aktuálne extrahuje denníky auditu a či je možné získať prístup k nespracovaným údajom, aby ste nemuseli vytvárať nové riešenie.
  • Rozhodnite sa pre zdroj údajov: Určte najlepší zdroj, ktorý sa má použiť na prístup k údajom aktivity používateľa.
  • Dokončite testovanie konceptu: Plánujete dokončiť malú technickú kontrolu koncepcie (POC). Použite ho na overenie svojich rozhodnutí o tom, ako sa bude zostaviť konečné riešenie.
  • Sledovanie ďalších potrieb údajov: Údaje denníka aktivity môžete korelovať s inými zdrojmi a zlepšiť tak hodnotu údajov. Sledujte tieto príležitosti tak, ako vznikajú, aby sa mohli pridať do rozsahu vášho projektu.

Prístup k údajom zásob nájomníka

Inventár nájomníka je neoceniteľnou a nevyhnutnou súčasťou vyspelého riešenia na auditovanie a monitorovanie. Pomôže vám pochopiť, ktoré pracovné priestory a obsah (sémantické modely, zostavy a ďalšie položky) v službe Power BI existujú, a je to vynikajúci doplnok k údajom o aktivite používateľa (ako je popísané v predchádzajúcej časti). Ďalšie informácie o identifikácii potrieb vašich údajov nájdete v časti Inventár nájomníkov vyššie v tomto článku.

Aktivity používateľa (predtým popísané) sú auditované udalosti; ide o záznam akcií, ktoré používateľ v konkrétnom dátume a čase vykonali. Inventár nájomníkov je však iný. Inventár nájomníka je snímka v danom časovom okamihu. Popisuje aktuálny stav všetkých publikovaných položiek v služba Power BI v čase, keď ste ho extrahovali.

Poznámka

Dokumentácia k rozhraniu REST API služby Power BI odkazuje na publikované položky ako na artefakty.

Tip

Pre mnohé organizácie je vhodné extrahovať inventár nájomníka každý týždeň v rovnakom čase.

Na správnu analýzu toho, čo sa deje v nájomníkovi služby Power BI, potrebujete údaje o aktivite používateľa aj inventár nájomníka. Ich kombinácia vám umožní pochopiť, koľko obsahu máte a kde sa nachádza. Taktiež vám umožňuje vyhľadať nepoužívaný alebo nedostatočne využitý obsah (pretože v denníku aktivity sa v ňom nebudú vyskytnúť žiadne udalosti). Inventár nájomníka vám tiež pomôže zostaviť zoznam aktuálnych názvov všetkých položiek, čo je užitočné pri zmene názvov položiek.

Ďalšie informácie o hodnote zásob nájomníka nájdete vyššie v tomto článku v časti Inventár nájomníka.

Tip

Rozhranie Get Unused Artefakty môžete použiť ako Spravovanie rozhranie API na vyhľadávanie položiek, ktoré za posledných 30 dní nemajú žiadne aktivity používateľa. Toto časové obdobie však nie je možné prispôsobiť. Môžete mať napríklad kritický obsah, ktorý sa používa iba štvrťročne. Kombináciou súpisu nájomníka s údajmi o aktivite používateľa môžete nájsť nepoužívané položky spôsobmi, ktoré môžete prispôsobiť.

Údaje inventára nájomníka môžete získať dvomi rôznymi spôsobmi.

Technika Popis Najvhodnejšie pre Dobrá voľba pre procesy manuálneho auditovania Dobrá voľba pre automatizované procesy auditovania
Programový Rozhranie Get Groups as Admin API alebo rutina Get-PowerBIWorkspace typu cmdlet prostredia PowerShell môžu poskytovať zoznam pracovných priestorov pre celého nájomníka. Voliteľne možno zahrnúť jednotlivé položky (napríklad sémantické modely a zostavy) na pracovný priestor. Menšie organizácie alebo nízky objem údajov Rutina typu cmdlet prostredia PowerShell načítať skupiny ako Spravovanie rozhrania API alebo rutina typu cmdlet prostredia PowerShell v službe Get-PowerBIWorkspace je dobrou voľbou pre procesy manuálneho auditovania. Rutina typu cmdlet prostredia PowerShell načítať skupiny ako Spravovanie rozhrania API alebo rutina typu cmdlet prostredia PowerShell v službe Get-PowerBIWorkspace je dobrou voľbou pre automatizované procesy auditovania.
Programový Množina asynchrónnych rozhraní API správcu, súhrnne známych ako metaúdaje na skenovanie rozhraní API alebo rozhraní API skenera, môže vrátiť zoznam pracovných priestorov a jednotlivých položiek. Voliteľne môžete zahrnúť aj podrobné metaúdaje (napríklad tabuľky, stĺpce a výrazy mierok). Organizácie s vysokým objemom údajov alebo potreba získať podrobné výsledky. Rozhrania API na skenovanie metaúdajov sú dobrou voľbou pre automatizované procesy auditovania.

V zostávajúcej časti sa uvádza každá z techník uvedených v tabuľke.

Rutina typu cmdlet pre skupiny rozhraní API alebo pracovných priestorov

Ak chcete načítať zoznam pracovných priestorov, môžete použiť jedno z niekoľkých rozhraní REST API, napríklad rozhranie Get Groups ako Spravovanie rozhranie API (pomocou nástroja, ktorý ste si vybrali). Výsledky zahŕňajú ďalšie metaúdaje, ako napríklad popis a to, či je pracovný priestor uložený v kapacite Premium.

Poznámka

Rozhranie API s názvom zahŕňa skupinu výrazov ako odkaz na pracovný priestor. Tento výraz pochádzal z pôvodného modelu zabezpečenia služby Power BI, ktorý sa spoliehal na skupiny v Microsoft 365. Hoci sa model zabezpečenia služby Power BI v priebehu rokov výrazne zmenil, existujúce názvy rozhraní API zostávajú nezmenené, aby sa predišlo porušeniu existujúcich riešení.

Rozhranie Get Groups as Admin REST API obsahuje užitočný $expand parameter. Tento parameter vám umožňuje voliteľne rozbaliť výsledky tak, aby obsahovali zoznam položiek publikovaných v pracovnom priestore (napríklad sémantické modely a zostavy). Do parametra users môžete tiež preniesť typ $expand údajov, aby mohli zahrnúť používateľov priradených k role pracovného priestoru.

Môžete tiež použiť rutinu typu cmdlet prostredia PowerShell v prostredí Get-PowerBIWorkspace . Pochádza z modulu Pracovné priestory správy služby Power BI. Pri nastavovaní parametra -Scopeorganizationfunguje ako rozhranie Get Groups as Admin API. Rutina typu cmdlet tiež prijíma -Include parameter (ktorý je ekvivalentom $expand parametra v rozhraní REST API) na zahrnutie položiek publikovaných v pracovnom priestore (napríklad sémantické modely a zostavy).

Tip

Zadaním parametrov môžete rutinu typu cmdlet používať rôznymi spôsobmi. Táto časť sa zameriava na načítanie inventára v rámci celého nájomníka. Ďalšie informácie o používaní parametra -Scope nájdete vyššie v tomto článku v časti Výber rozhrania API používateľa alebo rozhrania API správcu.

Ak chcete pomôcť vybrať, ktorú možnosť použiť, pozrite si časť Výber rozhraní API alebo rutín typu cmdlet prostredia PowerShell vyššie v tomto článku.

Rozhranie Get Groups as Admin REST API alebo rutina Get-PowerBIWorkspace typu cmdlet prostredia PowerShell sú najvhodnejšie na manuálne procesy auditovania a jednorazové skúmania. Väčšie organizácie s vysokým objemom údajov zvyčajne hľadajú tieto možnosti, ktoré sú náročné na používanie. Rozhranie REST API a rutina typu cmdlet vždy extrahujú celú množinu údajov, takže ich spustenie môže trvať dlho. Je teda tiež pravdepodobné, že väčšie organizácie budú mať obmedzenia počtu žiadostí povolených za hodinu (známe ako obmedzenie, ktoré sa vykonáva s cieľom chrániť zdravie služby). Rozhrania API na skenovanie metaúdajov (popísané ďalej) poskytujú spoľahlivejšiu a škálovateľnejšiu alternatívu.

Rozhrania API na skenovanie metaúdajov

Rozhrania API na skenovanie metaúdajov, bežne nazývané rozhrania API skenera, sú množinou rozhraní API, ktoré vracajú zoznam pracovných priestorov a ich položiek v službe Power BI (sémantické modely, zostavy a ďalšie položky). Koncepčne poskytujú rovnaké údaje (a ešte viac) ako rozhrania API skupín alebo rutinu typu cmdlet pracovného priestoru, ktoré sú popísané v predchádzajúcej časti. Metóda, ktorú používate na načítanie údajov, je však odlišná a vhodnejšia na extrahovanie zásob nájomníka.

Poznámka

Všimnite si, ako niektorí ľudia používajú rozhrania API skenera výrazov alebo frázu, ktorá kontroluje nájomníka. Tieto pojmy často používajú na to, aby znamenali vytvorenie súpisu nájomníkov a ich odlíšenie od udalostí aktivít používateľa. Môžu alebo nemusia mať doslova odkaz na použitie rozhraní API na skenovanie metaúdajov.

Existujú dva hlavné dôvody, prečo by ste mali zvážiť použitie rozhraní API na skenovanie metaúdajov namiesto Get Groups as Admin rozhrania REST API alebo Get-PowerBIWorkspace rutiny typu cmdlet (ako bolo popísané vyššie).

  • Extrahovanie prírastkových údajov: Rozhrania API skenera extrahujú len údaje, ktoré sa od posledného spustenia zmenili. Rozhranie REST API a Get-PowerBIWorkspace rutina typu cmdlet sú naopak Get Groups as Admin synchrónne operácie, ktoré extrahujú celú množinu údajov pri každom spustení.
  • Väčšia úroveň podrobností: Rozhrania API skenera môžu načítať podrobné údaje (ako napríklad tabuľky, stĺpce a výrazy mierky) za predpokladu, že povolenie udeľujú dve nastavenia nájomníka pre podrobné metaúdaje. A naopak, najnižšia úroveň podrobností, ktoré sú k dispozícii v Get Groups as Admin rozhraní REST API a Get-PowerBIWorkspace rutine typu cmdlet, je podľa typu položky (napríklad zoznam zostáv v pracovnom priestore).

Používanie rozhraní API skenera vyžaduje väčšie úsilie, pretože potrebujete volať rad rozhraní API. Okrem toho sa spúšťajú ako asynchrónny proces. Asynchrónny proces sa spustí na pozadí, a preto nemusíte čakať, kým sa dokončí. Možno budete musieť spolupracovať s IT alebo vývojárom, keď je čas vytvoriť skript pripravený na produkciu, ktorý bude naplánovaná.

Tu je postupnosť krokov, ktoré by mal váš proces dodržiavať pri používaní rozhraní API skenera.

  1. Prihlásenie: Prihláste sa do služba Power BI pomocou konta správcu služby Power BI alebo objektu služby, ktorý má povolenie na spúšťanie rozhraní API správcu. Ďalšie informácie nájdete v časti Určenie metódy overovania vyššie v tomto článku.
  2. Načítanie ID pracovného priestoru: Odošlite požiadavku na načítanie zoznamu ID pracovných priestorov. Pri prvom spustení nemáte dátum úpravy, takže sa vráti úplný zoznam pracovných priestorov. Dátum úpravy zvyčajne odovzdáte, ak chcete načítať iba pracovné priestory, ktoré sa od tohto okamihu zmenili. Dátum úpravy musí byť v priebehu posledných 30 dní.
  3. Spustenie kontroly metaúdajov: Zadajte volanie s cieľom požiadať o preskenovanie informácií o pracovnom priestore zadaním ID pracovného priestoru načítaných v kroku 2. Všimnite si, že ide o rozhranie POST API (namiesto rozhrania GET API, ktoré je pri načítavaní údajov auditu bežnejšie). ROZHRANIE API POST je požiadavka HTTP, ktorá vytvára alebo zapisuje údaje pre zadaný prostriedok. Tento dotaz určuje úroveň podrobností, ktoré sa budú extrahovať, ako sú napríklad podrobnosti o zdroji údajov, sémantická schéma modelu, výrazy sémantického modelu alebo používatelia. Pri odoslaní rozhranie API vráti ID pre skenovanie. Vráti tiež dátum a čas skenovania, ktoré by ste mali zaznamenať ako dátum snímky.
  4. Kontrola stavu skenovania: Na získanie stavu skenovania použite ID skenovania získané v kroku 3. Toto rozhranie API možno budete musieť zavolať viackrát. Keď je vrátený stav úspešný, môžete prejsť na ďalší krok. Čas potrebný na kontrolu závisí od množstva údajov, ktoré požadujete.
  5. Získanie výsledkov: Pomocou ID kontroly získaného v kroku 3 môžete získať výsledok kontroly a extrahovať údaje. Tento krok musíte urobiť do 24 hodín od dokončenia kroku 4. Majte na pamäti, že časová pečiatka snímky by mala byť v korelácii s krokom 3 a nie s krokom 5 (v prípade významného oneskorenia). Týmto spôsobom budete mať presnú časovú pečiatku snímky. Uložte výsledky do preferovaného umiestnenia ukladacieho priestoru údajov. Ako už bolo popísané v tomto článku, odporúčame uložiť nespracované údaje v ich pôvodnom stave.
  6. Pripravte sa na ďalší proces: Zaznamenajte časová pečiatku skenovania z kroku 3, aby ste ju mohli použiť v kroku 2 pri ďalšom spustení procesu. Týmto spôsobom budete extrahovať len údaje, ktoré sa od tohto okamihu zmenili. Postupne budú všetky následné údajové extrahované údaje namiesto celých snímok prírastkové zmeny.

Kontrolný zoznam – pri plánovaní prístupu k údajom inventára nájomníka sú tu zahrnuté kľúčové rozhodnutia a akcie:

  • Potvrdenie požiadaviek: Objasnite potreby na vytvorenie súpisu nájomníkov a analytické požiadavky na údaje.
  • Rozhodnite sa o frekvencii extrahovania zásob nájomníka: Potvrďte, ako často budete potrebovať nový inventár nájomníkov (napríklad každý týždeň).
  • Rozhodnite sa, ako extrahovať inventár nájomníka: Potvrďte, ktorá metóda sa použije na získanie údajov inventára nájomníka (rozhrania API, rutiny typu cmdlet alebo skenovanie metaúdajov).
  • Dokončite testovanie konceptu: Plánujete dokončiť malú technickú kontrolu koncepcie (POC). Použite ho na overenie svojich rozhodnutí o tom, ako sa bude zostaviť konečné riešenie.

Prístup k údajom používateľov a skupín

Okrem identifikačných údajov (napríklad e-mailovej adresy), ktoré sú zahrnuté v údajoch o aktivite používateľa, je cenné načítať aj ďalšie informácie, ako napríklad informácie o mieste alebo podrobnosti organizácie. Microsoft Graph môžete použiť na načítanie údajov o používateľoch, skupinách, objektoch služby a licenciách. Microsoft Graph obsahuje množinu rozhraní API a klientskych knižníc, ktoré umožňujú načítať údaje auditu zo širokej škály služieb.

Tu je niekoľko podrobností o objektoch služby Microsoft Entra, ku ktorým máte prístup.

  • Používateľ: identita, ktorá v konte Microsoft Entra ID existuje ako pracovné, školské konto alebo konto Microsoft. Pojem používateľ domény sa často používa na popis používateľov organizácie, zatiaľ čo formálnym výrazom je hlavné meno používateľa (UPN). Hlavné meno používateľa je zvyčajne rovnaké hodnoty ako e-mailová adresa používateľa (ak sa však e-mailová adresa zmení, hlavné meno používateľa sa nezmení, pretože je nemenné). Pre každého používateľa je k dispozícii aj jedinečné ID služby Microsoft Graph. Používateľské konto je často spojené s jednou osobou. Niektoré organizácie vytvárajú používateľov, ktorí sú kontami služby a používajú sa na automatizované aktivity alebo na administratívne úlohy.
  • Objekt služby: Iný typ identity, ktorý sa zriade pri vytváraní registrácie aplikácie. Objekt služby je určený na automatické a automatizované aktivity. Ďalšie informácie nájdete v časti Určenie metódy overovania vyššie v tomto článku.
  • Skupina: Kolekcia používateľov a objektov služby. Existuje niekoľko typov skupín , ktoré môžete použiť na zjednodušenie spravovania povolení. Ďalšie informácie nájdete v téme Stratégia používania skupín.

Poznámka

Keď sa tento článok vzťahuje na používateľov a skupiny, tento výraz zahŕňa aj objekty služby. Tento kratšiy výraz sa používa pre stručnosť.

Používatelia a skupiny údajov, ktoré načítate, je snímka , ktorá popisuje aktuálny stav v danom časovom okamihu.

Tip

Ďalšie informácie o používateľoch, objektoch služby a skupinách nájdete v téme Integrácia s ID aplikácie Microsoft Entra.

Analytické atribúty

Na auditovanie na úrovni nájomníka služby Power BI môžete extrahovať a ukladať nasledujúce atribúty z Microsoft Graphu.

  • Celé meno používateľov: Mnohé zdroje údajov obsahujú iba e-mailovú adresu používateľa, ktorý vykonal aktivitu alebo kto bol priradený k role. Tento atribút použite, ak chcete zobraziť celý názov (zobrazovaný názov) v analytických zostavách. Pomocou celého názvu sú zostavy prehľadnejšie.
  • Ďalšie vlastnosti používateľa: V identifikátore Microsoft Entra ID môžu byť k dispozícii ďalšie popisné atribúty o používateľoch. Niektoré príklady vstavaných atribútov používateľského profilu, ktoré majú analytickú hodnotu, zahŕňajú pracovnú pozíciu, oddelenie, manažéra, oblasť a polohu balíka office.
  • Členovia skupiny zabezpečenia: Väčšina zdrojov údajov poskytuje názov skupiny (napríklad záznamy denníka aktivity služby Power BI, ku ktorým bola priradená rola pracovného priestoru). Získanie členstva v skupine zlepšuje vašu schopnosť plnú analýzu toho, čo jednotlivý používateľ robí, alebo ku ktorému má prístup.
  • Používateľské licencie: Je užitočné analyzovať, ktoré používateľské licencie, či už bezplatná, Power BI Pro alebo Power BI Premium na používateľa, sú priradené používateľom. Tieto údaje vám môžu pomôcť identifikovať, kto nepoužíva licenciu. Pomáha vám tiež analyzovať všetkých používateľov (rôznych používateľov s licenciou) v porovnaní s aktívnymi používateľmi (s nedávnymi aktivitami). Ak uvažujete o pridávaní alebo rozširovaní licencií Power BI Premium, odporúčame vám analyzovať údaje používateľských licencií spolu s údajmi o aktivite používateľa, aby ste mohli vykonať analýzu nákladov.
  • Členovia rolí správcu: Môžete zostaviť zoznam správcov služby Power BI (ktorý zahŕňa správcov Power Platformy a globálnych správcov).

Autoritatívny odkaz na informácie o licencii služby Power BI, ktoré môžete nájsť v údajoch auditu z aplikácie Microsoft Graph, nájdete v téme Názvy produktov a identifikátory plánu služieb na licencovanie.

Tip

Získanie členov zo skupín môže byť jedným z najnáročnejších aspektov získania údajov auditu. Budete musieť vykonať tranzitívne vyhľadávanie , aby ste zlúčili všetky vnorené členy a vnorené skupiny. Môžete vykonať tranzitívne vyhľadávanie členov skupiny. Tento typ vyhľadávania je obzvlášť náročný, keď vo vašej organizácii existujú tisíce skupín. V takom prípade by sa mohlo zvážiť lepšie alternatívy na načítanie údajov. Jednou z možností je extrahovať všetky skupiny a členov skupiny z Microsoft Graphu. Nemusí to však byť praktické, keď sa na zabezpečenie služby Power BI používa len malý počet skupín. Ďalšou možnosťou je vytvoriť referenčný zoznam skupín, ktoré používajú všetky typy zabezpečenia služby Power BI (roly pracovného priestoru, povolenia aplikácie, zdieľanie na položku, zabezpečenie na úrovni riadkov a ďalšie). Potom môžete vytvoriť slučku cez zoznam odkazov a načítať členov skupiny zo služby Microsoft Graph.

Tu je niekoľko ďalších atribútov, ktoré môžete extrahovať a ukladať.

  • Typ používateľa: Používatelia sú členmi alebo hosťami. Najčastejšie sú členmi interní používatelia a hostia externí (B2B). Uloženie typu používateľa je užitočné, keď potrebujete analyzovať aktivity externých používateľov.
  • Zmeny rolí: Pri vykonávaní auditu zabezpečenia je užitočné pochopiť, kedy používateľ zmenil roly v organizácii (napríklad pri prenose na iné oddelenie). Týmto spôsobom môžete overiť, či sa ich nastavenia zabezpečenia služby Power BI aktualizovali alebo mali aktualizovať.
  • Zakázaní používatelia: Keď používateľ odíde z organizácie, zvyčajne správca zakáže svoje konto. Môžete vytvoriť proces na kontrolu toho, či sú zakázaní používatelia správcami pracovného priestoru alebo sémantickými vlastníkmi modelu.

Tip

Denník aktivity služby Power BI zahŕňa udalosť, ktorá zaznamenáva, keď sa používateľ zaregistruje do skúšobnej licencie. Túto udalosť môžete skombinovať s údajmi používateľskej licencie (ktoré pochádzajú z id Microsoft Entra) a vytvoriť úplný obrázok.

Načítanie údajov používateľov a skupín

Údaje o používateľoch a skupinách môžete načítať rôznymi spôsobmi.

Technika Popis Dobrá voľba pre procesy manuálneho auditovania Dobrá voľba pre automatizované procesy auditovania
Manuálne Graph Explorer Program Graph Explorer je dobrou voľbou pre procesy manuálneho auditovania.
Programový Rozhrania Microsoft Graph API a súpravy Microsoft Graph Rozhrania Microsoft Graph API a súpravy SDK sú dobrou voľbou pre automatizované procesy auditovania.
Programový Modul Az PowerShell Modul Az PowerShell je dobrou voľbou pre automatizované procesy auditovania.

V zostávajúcej časti sa uvádza každá z techník uvedených v tabuľke. Ďalšie techniky, ktoré sú zastarané a nemali by sa používať v prípade nových riešení, sú popísané na konci tejto časti.

Poznámka

Pri čítaní informácií online buďte opatrní, pretože mnohé názvy nástrojov sú podobné. Niektoré nástroje v ekosystéme spoločnosti Microsoft zahŕňajú v názve výraz Graph , napríklad Azure Resource Graph, GraphQL a Microsoft Security Graph API. Tieto nástroje nesúvisia so službou Microsoft Graph a nie sú súčasťou obsahu tohto článku.

Microsoft Graph Explorer

Microsoft Graph Explorer je nástroj pre vývojárov, ktorý vám umožní získať informácie o rozhraniach Microsoft Graph API. Je to jednoduchý spôsob, ako začať, pretože nevyžaduje žiadne iné nástroje ani nastavenie v počítači. Ak chcete načítať údaje z nájomníka, môžete sa prihlásiť alebo načítať vzorové údaje z predvoleného nájomníka.

Prieskumníka Graph môžete použiť na:

  • Manuálne odošlite požiadavku rozhraniu Microsoft Graph API, aby ste skontrolovali, či vráti požadované informácie.
  • Pred napísaním skriptu si pozrite, ako vytvoriť URL adresu, hlavičky a telo.
  • Skontrolovať údaje neformálnym spôsobom.
  • Určte, ktoré povolenia sa vyžadujú pre každé rozhranie API. Môžete tiež poskytnúť súhlas s novými povoleniami.
  • Získajte úryvky kódu, ktoré sa majú použiť pri vytváraní skriptov.

Pomocou tohto prepojenia otvoríte prieskumníka Graph Explorer.

Rozhrania Microsoft Graph API a súpravy Microsoft Graph

Microsoft Graph API sa používa na načítanie údajov používateľov a skupín. Môžete ju použiť aj na načítanie údajov zo služieb ako Microsoft Entra ID, SharePoint Online, Teams, Exchange, Outlook a ďalšie.

Súpravy Microsoft Graph SDK fungujú ako obal rozhrania API nad základnými rozhraniami API služby Microsoft Graph. Súprava SDK je súprava na vývoj softvéru, ktorá spolu spája nástroje a funkcie. Súpravy Microsoft Graph SDK sprístupňujú celú množinu rozhraní Microsoft Graph API.

Požiadavky môžete odosielať priamo do rozhraní API. Prípadne môžete pridať vrstvu zjednodušenia pomocou preferovaného jazyka a jednej zo súprav SDK. Ďalšie informácie nájdete v časti Výber rozhraní API alebo rutín typu cmdlet prostredia PowerShell vyššie v tomto článku.

Súpravy Microsoft Graph SDK podporujú niekoľko jazykov a k dispozícii sú aj moduly Microsoft Graph PowerShell . Ostatné súpravy SDK sú k dispozícii pre jazyk Python, C#a iné jazyky.

Dôležité

Modul Microsoft Graph PowerShell nahradí moduly Azure AD PowerShell a moduly MSOnline (MSOL), ktoré sú už zastarané. Nemali by ste vytvárať nové riešenia so zastaranými modulmi. Modul Microsoft Graph PowerShell ponúka mnoho funkcií a výhod. Ďalšie informácie nájdete v téme Inovácia z prostredia Azure AD PowerShell na prostredie Microsoft Graph PowerShell.

Moduly prostredia Microsoft Graph PowerShell si môžete nainštalovať z galérie prostredia PowerShell. Keďže microsoft Graph spolupracuje s mnohými službami služby Microsoft 365, nainštalujete mnoho modulov prostredia PowerShell.

Ak chcete vykonať auditovanie na úrovni nájomníka služby Power BI, musíte si nainštalovať tieto najbežnejšie moduly prostredia PowerShell.

Tip

Microsoft pravidelne aktualizuje moduly Microsoft Graph PowerShell. Ukážky modulov sú niekedy sprístupnené na predbežnom vydaní alebo v koncovom bode beta. Možno budete chcieť určiť verziu, ktorá vás zaujíma, keď nainštalujete a aktualizujete moduly. Pri kontrole online dokumentácie si tiež všimnite, že na koniec URL adresy sa automaticky pripojí aktuálne číslo verzie (preto pri ukladaní alebo zdieľaní URL adries buďte opatrní).

Modul Az PowerShell

Na načítanie údajov používateľov a skupín môžete použiť aj modul Az PowerShell. Zameriava sa na zdroje služby Azure.

Dôležité

Modul Az PowerShell nahrádza moduly AzureRM PowerShell, ktoré sú zastarané. Nemali by ste vytvárať nové riešenia so zastaranými modulmi.

Rutinu cmdlet Invoke-AzRestMethod môžete použiť, ak neexistuje zodpovedajúca rutina typu cmdlet pre rozhranie API. Ide o flexibilný prístup, ktorý vám umožňuje odoslať žiadosť ľubovoľnému rozhraniu Microsoft Graph API pomocou modulu Az PowerShell.

Od verzie 7 rozhrania Az odkazujú rutiny typu cmdlet Az na rozhranie Microsoft Graph API. Modul Az preto funguje ako obal rozhrania API v hornej časti služby Microsoft Graph. Moduly Az majú podmnožinu funkcií, ktoré sú obsiahnuté v moduloch Microsoft Graph API a PowerShell. Pre nové riešenia odporúčame použiť súpravu Microsoft Graph PowerShell SDK.

Zastarané rozhrania API a moduly

Môžete nájsť články a blogové príspevky online, ktoré navrhne alternatívne možnosti, ktoré nie sú uvedené v tejto časti. Dôrazne odporúčame, aby ste nevytvárli nové riešenia (a/alebo migrovali vaše existujúce riešenia) pomocou ktoréhokoľvek z nasledujúcich rozhraní API alebo modulov.

  • Moduly AzureRM PowerShell: Zastarané a se vyradia. Boli nahradené modulom Az PowerShell.
  • Modul Azure AD Graph API a azure AD PowerShell: Už sa nepoužíva a končí sa. Táto zmena je výsledkom migrácie zo služby Azure AD Graph na microsoft Graph (všimnite si, že funkcia Graph sa zobrazuje v oboch názvoch, ale služba Microsoft Graph je budúcim smerom). Všetky budúce investície do prostredia PowerShell sa uskutočnia v súprave Microsoft Graph PowerShell SDK. (Microsoft Entra ID je teraz známe ako Microsoft Entra ID.)
  • Modul PowerShell MS Online (MSOL): Už sa nepoužíva a bude vyradený. Všetky budúce investície do prostredia PowerShell sa uskutočnia v súprave Microsoft Graph PowerShell SDK.

Výstraha

Nezabudnite potvrdiť stav všetkých zastaraných rozhraní API alebo modulu, ktoré aktuálne používate. Ďalšie informácie o odchode služby AzureRM do dôchodku nájdete v tomto oznámení.

Ďalšie informácie o službe Microsoft Entra ID a aplikácii MSOL nájdete v tomto príspevku o oznámení o dôchodkoch.

Ak máte otázky alebo potrebujete vysvetlenie budúceho smerovania programového prístupu k údajom, obráťte sa na tím konta Microsoft.

Kontrolný zoznam – pri plánovaní prístupu k údajom používateľov a skupín zahŕňajú kľúčové rozhodnutia a akcie:

  • Potvrdenie požiadaviek: Objasnite potreby pri kompilovaní údajov súvisiacich s používateľmi, skupinami a licenciami.
  • Uprednostnenie požiadaviek: Potvrďte, aké sú hlavné priority, aby ste najprv vedeli, na čo vynaložiť čas.
  • Rozhodnite sa o frekvencii extrahovania údajov: Určite, ako často budete potrebovať novú snímku používateľov a zoskupených údajov (napríklad každý týždeň alebo každý mesiac).
  • Rozhodnite sa, ako extrahovať údaje pomocou služby Microsoft Graph: Určte, ktorú metódu použijete na načítanie údajov.
  • Dokončite testovanie konceptu: Plánujete dokončiť malú technickú kontrolu koncepcie (POC) na extrahovanie údajov používateľov a skupín. Použite ho na overenie svojich rozhodnutí o tom, ako sa bude zostaviť konečné riešenie.

Prístup k údajom z rozhraní REST API služby Power BI

Pravdepodobne ako nižšiu prioritu môžete načítať aj iné údaje pomocou rozhraní REST API služby Power BI.

Môžete napríklad načítať údaje o:

Počas auditu zabezpečenia možno budete chcieť identifikovať:

Ďalšie informácie o iných typoch rozhraní API nájdete vyššie v tomto článku v téme Výber rozhrania API používateľa alebo rozhrania API správcu.

Kontrolný zoznam – pri plánovaní prístupu k údajom z rozhranie API služby Power BI sú k hlavným rozhodnutiam a akciám zahrnuté:

  • Získanie požiadaviek: Kompilujte analytické požiadavky tak, ako vznikajú. Sledujte ich vo svojich nevybavených.
  • Uprednostnite požiadavky: Nastavte priority pre nové požiadavky, ktoré nastanú.

Fáza 2: Požiadavky a nastavenie

Druhá fáza plánovania a implementácie riešenia auditovania na úrovni nájomníka sa zameriava na požiadavky a nastavenie, ktoré je potrebné vykonať pred začatím vývoja riešení.

Diagram postupu popisujúci fázu 2, ktorá sa zameriava na požiadavky a nastavenie na vytvorenie riešenia auditovania na úrovni nájomníka.

Vytvorenie konta úložiska

V tomto momente ste sa rozhodli , kde uložiť nespracované údaje a ako vytvoriť spravované údaje. Na základe týchto rozhodnutí ste teraz pripravení vytvoriť konto úložiska. V závislosti od procesov vašej organizácie môže zahŕňať odoslanie žiadosti do IT.

Ako sme už uviedli skôr, odporúčame používať technológiu, ktorá umožňuje zapisovať nespracované údaje do nemenného úložiska. Po napísaní údajov ich nemožno zmeniť ani odstrániť. Potom môžete mať istotu v nespracované údaje, pretože viete, že správca s prístupom ich v žiadnom prípade nemôže zmeniť. Spravované údaje však nemusia byť (zvyčajne) uložené v nemennom úložisku. Spravované údaje sa môžu zmeniť alebo môžu byť znovu generované.

Kontrolný zoznam – kľúčové rozhodnutia a akcie, ktoré môžete vykonať pri vytváraní konta úložiska, zahŕňajú:

  • Vytvorenie konta úložiska: Vytvorte alebo odošlite žiadosť na vytvorenie konta úložiska. Použite nemenné nastavenia úložiska pre nespracované údaje vždy, keď je to možné.
  • Nastavenie povolení: určte, ktoré povolenia by mali byť nastavené pre konto úložiska.
  • Prístup na testovanie: Vykonajte malý test, aby ste mali istotu, že môžete čítať konto úložiska a zapisovať doň.
  • Potvrďte zodpovednosť: Skontrolujte, či máte jasnú predstavu o tom, kto bude priebežne spravovať konto úložiska.

Inštalácia softvéru a nastavenie služieb

V tomto momente ste sa rozhodli, ktorú technológiu použiť na prístup k údajom auditu. Na základe týchto rozhodnutí ste teraz pripravení na inštaláciu softvéru a nastavenie služieb.

Nastavte preferované vývojové prostredie pre každého správcu. Vývojové prostredie im umožní písať a testovať skripty. Visual Studio Code je moderný nástroj na vývoj skriptov, takže je to dobrá voľba. Okrem toho je k dispozícii mnoho rozšírení na prácu s visual Studio Code.

Ak ste sa rozhodli používať prostredie PowerShell (vyššie popísané) a chcete nainštalovať PowerShell Core a potrebné moduly PowerShell do:

  • Počítač každého správcu alebo vývojára, ktorý bude písať alebo testovať skripty auditovania.
  • Každý virtuálny počítač alebo server, ktorý bude spúšťať plánované skripty.
  • Každá online služba (napríklad Azure Functions alebo Azure Automation).

Ak ste sa rozhodli používať akékoľvek služby Azure (napríklad Azure Functions, Azure Automation, Azure Data Factory alebo Azure Synapse Analytics), mali by ste ich zriadiť a nastaviť.

Kontrolný zoznam – pri inštalácii softvéru a nastavovaní služieb patria kľúčové rozhodnutia a akcie:

  • Nastavenie správcu/vývojárskych počítačov: Ak je to vhodné, nainštalujte potrebné nástroje, ktoré sa použijú na vývoj.
  • Nastavenie serverov: V prípade potreby nainštalujte potrebné nástroje na všetky servery alebo virtuálne počítače, ktoré sa nachádzajú vo vašej architektúre.
  • Nastavenie služieb Azure: Ak je to možné, zriadiť a nastaviť každú službu Azure. Priraďte povolenia každému správcovi alebo vývojárovi, ktorý bude robiť vývojovú prácu.

Registrácia aplikácie Microsoft Entra

V tomto momente ste sa rozhodli , ako ju overiť. Odporúčame vám zaregistrovať aplikáciu Microsoft Entra (objekt služby). Bežne sa označuje ako registrácia aplikácie, mala by sa používať pre automatické operácie, ktoré budete automatizovať.

Ďalšie informácie o tom, ako vytvoriť registráciu aplikácie na načítanie údajov auditovania na úrovni nájomníka, nájdete v téme Povolenie overovania objektom služby pre rozhrania API správcu určené iba na čítanie.

Kontrolný zoznam – pri registrácii aplikácie Microsoft Entra zahŕňajú kľúčové rozhodnutia a akcie:

  • Skontrolujte, či existuje existujúca registrácia aplikácie: Overte pomocou IT, či je na spustenie rozhrania API správcu k dispozícii existujúca registrácia aplikácie. Ak áno, určte, či sa má použiť existujúci, alebo či sa má vytvoriť nový.
  • Vytvorenie novej registrácie aplikácie: Vytvorte registráciu aplikácie podľa potreby. Zvážte použitie názvu aplikácie, ako je napríklad PowerBI-Spravovanie APIs-EntraApp, ktorá jasne popisuje jej účel.
  • Vytvorenie tajného kódu registrácie aplikácie: Po tom, ako existuje registrácia aplikácie, vytvorte preň tajný kód. Nastavte dátum uplynutia platnosti na základe toho, ako často plánujete otočiť tajný kód.
  • Bezpečné ukladanie hodnôt: Uložte tajný kód, ID aplikácie (ID klienta) a ID nájomníka, pretože ich budete potrebovať na overenie pomocou objektu služby. Použite zabezpečené umiestnenie, napríklad trezor hesla organizácie. (Ak potrebujete požiadať o vytvorenie registrácie aplikácie z IT, zadajte, že potrebujete tieto hodnoty, ktoré sa vám vrátia.)
  • Vytvorenie skupiny zabezpečenia: Vytvorte (alebo požiadajte) skupinu zabezpečenia, ktorá sa použije pre službu Power BI. Zvážte použitie názvu skupiny, ako sú napríklad objekty služby správcu služby Power BI, čo znamená, že skupina sa použije na prístup k metaúdajom pre celého nájomníka.
  • Pridajte objekt služby ako člena skupiny zabezpečenia: Pomocou ID aplikácie (ID klienta) pridajte nový (alebo existujúci) objekt služby ako člena novej skupiny zabezpečenia.
  • Aktualizácia nastavenia nájomníka rozhrania API správcu v službe Power BI: Na portáli na správu služby Power BI pridajte skupinu zabezpečenia do nastavenia nájomníka Povoliť objektom služby používať rozhrania API na správu služby Power BI určené len na čítanie.
  • Vynechajte povolenia na priraďovanie v Azure: Nedelegujte žiadne povolenia na registráciu aplikácie (získate prístup k údajom auditu na úrovni nájomníka služby Power BI prostredníctvom nastavenia nájomníka povoliť objektom služby Power BI používať nastavenia nájomníka rozhrania API správcu služby Power BI určeného iba na čítanie).
  • Rozhodnite sa, či má registrácia aplikácie pristupovať k podrobným metaúdajom: Určte, či chcete extrahovať podrobné informácie o tabuľkách, stĺpcoch a výrazoch mierok týkajúcich sa sémantických modelov pri vytváraní súpisu nájomníkov.
  • Aktualizácia podrobných nastavení nájomníka metaúdajov v službe Power BI: Voliteľne môžete na portáli na správu služby Power BI pridať skupinu zabezpečenia do odpovedí rozhrania API na vylepšenie správcu s podrobným nastavením nájomníka metaúdajov , ako aj nastavenia nájomníka Na vylepšenie rozhrania API správcu pomocou jazyka DAX a výrazov mashup.
  • Testovanie objektu služby: Vytvorte jednoduchý skript na prihlásenie pomocou objektu služby a otestujte, či dokáže načítať údaje z rozhrania API správcu.
  • Vytvorte proces správy registračných kódov aplikácie: Vytvorte dokumentáciu a proces na pravidelné otáčanie tajomstvá. Zistite, ako budete bezpečne komunikovať nové tajomstvo všetkým správcom a vývojárom, ktorí ho potrebujú.

Nastavenie nájomníka služby Power BI

Na portáli na správu služby Power BI sa nachádza niekoľko nastavení nájomníka, ktoré sú relevantné na extrahovanie údajov auditovania na úrovni nájomníka.

rozhrania API Spravovanie

Existujú tri nastavenia nájomníka, ktoré sú relevantné pre spustenie rozhraní API správcu.

Dôležité

Keďže tieto nastavenia udeľujú prístup metaúdajom celému nájomníkovi (bez priradenia priamych povolení služby Power BI), mali by ste ich prísne ovládať.

Nastavenie nájomníka Povoliť objektom služby používať rozhrania API správcu Power BI určené iba na čítanie vám umožňuje nastaviť, ktoré objekty služby môžu volať rozhrania API správcu. Toto nastavenie tiež umožňuje službe Microsoft Purview prehľadávať celého nájomníka služby Power BI, aby mohol vyplniť katalóg údajov.

Poznámka

Nemusíte explicitne priraďovať iných správcov služby Power BI k nastaveniu nájomníka Povoliť objektom služby používať nastavenia nájomníka rozhrania API na správu služby Power BI určené iba na čítanie, pretože už majú prístup k metaúdajom pre celého nájomníka.

Odpoveď na vylepšenie rozhrania API správcu s podrobným nastavením nájomníka metaúdajov umožňuje nastaviť, ktorí používatelia a objekty služby môžu načítať podrobné metaúdaje. Metaúdaje sa načítavajú pomocou rozhraní API na skenovanie metaúdajov a zahŕňajú tabuľky, stĺpce a ďalšie. Toto nastavenie tiež umožňuje službe Microsoft Purview získať prístup k informáciám na úrovni schémy o sémantických modeloch služby Power BI, aby ich bolo možné uložiť do katalógu údajov.

Nastavenie nájomníka Vylepšiť reakcie rozhrania API správcu pomocou jazyka DAX a výrazov mashup umožňuje nastaviť, ktorí používatelia a objekty služby môžu načítať podrobné metaúdaje. Metaúdaje sa načítavajú z rozhraní API na skenovanie metaúdajov a môžu obsahovať dotazy a výrazy mierky sémantického modelu.

Poznámka

Nastavenie nájomníka Povoliť objektom služby používať nájomníka rozhrania API správcu Služby Power BI určené iba na čítanie sa týka prístupu k rozhraniam API správcu. Názov je veľmi podobný nastaveniam nájomníka, ktoré je určené na prístup k rozhraniam API používateľov (ako je popísané ďalej). Ďalšie informácie o rozdiele medzi rozhraniami API správcu a rozhraniami API používateľov nájdete vyššie v tomto článku v téme Výber rozhrania API používateľa alebo rozhrania API správcu.

Rozhrania API používateľov

Existuje jedno nastavenie nájomníka, ktoré sa vzťahuje na volanie používateľských rozhraní API. V takejto situácii sa povolenia služby Power BI vyžadujú aj pre objekt služby (napríklad pre rolu pracovného priestoru).

Nastavenie Povoliť objektom služby používať rozhranie API služby Power BI nájomníka umožňuje nastaviť, ktoré objekty služby majú prístup k spúšťaniu rozhraní REST API (okrem rozhraní API správcu, ktorým sa udeľuje iné nastavenie nájomníka popísané vyššie).

S rozhraniami API súvisia aj ďalšie nastavenia nájomníka, ktoré umožňujú prístup k rozhraniam API na vkladanie, rozhrania API streamovania, rozhrania API na export a rozhranie API na vykonanie dotazov . Tieto rozhrania API však nie sú súčasťou tohto článku.

Ďalšie informácie o nastaveniach nájomníka pre metriky používania nájdete v téme Auditovanie na úrovni zostavy.

Kontrolný zoznam – pri nastavovaní nastavení nájomníka služby Power BI zahŕňajú kľúčové rozhodnutia a akcie:

  • Overte, či je každý objekt služby v správnej skupine: Potvrďte, že skupina objektov služby správcu služby Power BI obsahuje správne objekty služby.
  • Aktualizácia nastavenia nájomníka rozhrania API správcu v službe Power BI: Pridajte skupinu zabezpečenia do nastavenia nájomníka Povoliť objektom služby používať rozhrania API správcu služby Power BI určené iba na čítanie, čo umožňuje použitie rozhraní API správcu na načítanie metaúdajov platné pre celého nájomníka.
  • Aktualizujte podrobné nastavenia nájomníka metaúdajov v službe Power BI: Ak je to potrebné, pridajte skupinu zabezpečenia do časti Zlepšenie odpovedí rozhrania API správcu s podrobnými nastaveniami nájomníka metaúdajov a nastavením nájomníka na vylepšenie rozhraní API správcu pomocou jazyka DAX a výrazov mashup.
  • Potvrďte, ku ktorým používateľským rozhraniam API sa bude pristupovať: Overte, či bude potrebné jedno alebo viacero rozhraní API používateľa (okrem toho pomocou rozhraní API správcu).
  • Aktualizácia nastavenia nájomníka rozhrania API používateľa v službe Power BI: Pridajte skupinu zabezpečenia do nastavenia Povoliť objektom služby používať rozhranie API služby Power BI nájomníka, ktoré je určené pre používateľské rozhrania API.

Fáza 3: Vývoj riešení a analýza

Tretia fáza plánovania a implementácie riešenia auditovania na úrovni nájomníka sa zameriava na vývoj a analýzu riešení. V tomto bode došlo k celému plánovaniu a rozhodovaniu a splnili ste predpoklady a dokončili ste nastavenie. Teraz ste pripravení začať vývoj riešení, aby ste mohli vykonávať analýzu a získať prehľady z údajov auditovania.

Diagram postupu popisujúci fázu 3, ktorá sa zameriava na vývoj a analýzu riešenia auditovania na úrovni nájomníka.

Extrahovanie a ukladanie nespracovaných údajov

V tomto bode by mali byť vaše požiadavky a priority jasné. Vykonali sa kľúčové technické rozhodnutia o tom, ako získať prístup k údajom auditu a miesta uloženia údajov auditu. Vybrali sa preferované nástroje a nastavili sa predpoklady a nastavenia. Počas predchádzajúcich dvoch fáz ste mohli dokončiť jeden alebo viac malých projektov (dôkaz koncepcie), aby ste mohli dokázať uskutočniteľnosť. Ďalším krokom je nastavenie procesu na extrahovanie a ukladanie nespracovaných údajov auditovania.

Podobne ako v prípade údajov vrátených väčšinou rozhraní Microsoft API, auditovanie údajov sa formátuje ako JSON. Údaje vo formáte JSON sú samopopisné, pretože ide o text čitateľný ľuďmi, ktorý obsahuje štruktúru a údaje.

JSON predstavuje objekty údajov, ktoré sa skladajú z párov atribút-hodnota a polí. Príkladom je príklad, "state": "Active" kde hodnota atribútu stav je Aktívna. Pole JSON obsahuje zoradený zoznam prvkov oddelených čiarkou a ktoré sú uvedené v zátvorkách ([ ]). Vo výsledkoch JSON sa bežne vyskytujú vnorené polia. Keď sa oboznámite s hierarchickou štruktúrou výsledku JSON, je jednoduché pochopiť štruktúru údajov, ako je napríklad zoznam (pole) sémantických modelov v pracovnom priestore.

Tu je niekoľko dôležitých informácií o extrahovaní a ukladaní nespracovaných údajov načítaných z rozhraní API.

  • Čo konvencie pomenovania sa použije? Pre systém založený na súboroch je potrebná konvencia pomenovania pre súbory, priečinky a zóny dátového jazera. V prípade databázy je pre tabuľky a stĺpce potrebná konvencia pomenovania.
  • Aký formát sa použije na uloženie nespracovaných údajov? So službou Power BI neustále zavádzame nové funkcie, objavia sa nové aktivity , ktoré v súčasnosti neexistujú. Z tohto dôvodu odporúčame extrahovať a uchovávať pôvodné výsledky JSON. Počas extrahovania údaje nefiltrujte ani neformátujte. Takto môžete vygenerovať spravované údaje auditu použitím pôvodných nespracovaných údajov.
  • Aké umiestnenie úložiska sa použije? Ukladací priestor dátového jazera alebo objektu BLOB sa bežne používa na ukladanie nespracovaných údajov. Ďalšie informácie nájdete v časti Určenie miesta uloženia údajov auditu vyššie v tomto článku.
  • Koľko histórie budete ukladať? Exportujte údaje auditu do umiestnenia, do ktorého môžete ukladať históriu. Plánujem nahromadiť aspoň dva roky histórie. Týmto spôsobom môžete analyzovať trendy a zmeny po uplynutí predvoleného 30-dňového obdobia uchovávania údajov. Môžete sa rozhodnúť ukladať údaje na neurčito alebo sa môžete rozhodnúť pre kratšie obdobie v závislosti od politík uchovávania údajov vo vašej organizácii.
  • Ako budete sledovať, kedy sa proces spustil naposledy? Nastavte konfiguračný súbor alebo ekvivalent na zaznamenanie časových pečiatok po spustení a dokončení procesu. Pri ďalšom spustení procesu môže načítať tieto časové pečiatky. Je obzvlášť dôležité, aby ste pri extrahovaní údajov pomocou rozhraní API na skenovanie metaúdajov ukladali časové pečiatky.
  • Ako spracujete obmedzenie? Niektoré rozhrania REST API služby Power BI a rozhranie Microsoft Graph API obmedzujú obmedzenia. Ak je požiadavka rozhrania API limitená, zobrazí sa chyba 429 (príliš veľa požiadaviek). Obmedzenie môže byť bežným problémom pre väčšie organizácie, ktoré potrebujú načítať veľké množstvo údajov. To, ako sa vyhnete neúspešným pokusom z dôvodu obmedzenia, závisí od technológie, ktorú používate na prístup k údajom a extrahovanie týchto údajov. Jednou z možností je vytvoriť v skriptoch logiku, ktorá reaguje na chybu "Príliš veľa požiadaviek" opakovaním po uplynutí doby čakania.
  • Sú na dodržiavanie súladu potrebné údaje auditu? Mnohé organizácie používajú nespracované záznamy denníka auditu na vykonávanie auditov súladu alebo na reagovanie na vyšetrovanie zabezpečenia. V týchto prípadoch dôrazne odporúčame uložiť nespracované údaje do nemenného úložiska. Týmto spôsobom ich po napísaní nemôžu zmeniť ani odstrániť správca ani iný používateľ.
  • Aké ukladacie vrstvy sú potrebné na podporu vašich požiadaviek? Medzi najlepšie miesta na uloženie nespracovaných údajov patrí dátové jazero (napríklad Azure Data Lake Storage Gen2) alebo úložisko objektov (napríklad Azure Blob Storage). Systém súborov možno použiť aj v prípade, že cloudové služby nie sú možnosťou.

Kontrolný zoznam – pri extrahovaní a ukladaní nespracovaných údajov zahŕňajú kľúčové rozhodnutia a akcie:

  • Potvrďte požiadavky a priority: Objasnite požiadavky a priority pre údaje, ktoré budete extrahovať ako prvé.
  • Potvrďte zdroj údajov, ktorý sa má extrahovať: Overte zdroj pre každý požadovaný typ údajov.
  • Nastavte proces na extrahovanie údajov a ich načítanie do nespracovaného pásma údajov: Vytvorte počiatočný proces na extrahovanie a načítanie nespracovaných údajov v ich pôvodnom stave bez akýchkoľvek transformácií. Otestujte, či proces funguje podľa potreby.
  • Vytvorte plán na spustenie procesov: Nastavte opakovaný plán na spustenie procesov extrahovania, načítania a transformácie.
  • Overte, či sa poverenia spravujú bezpečne: Skontrolujte, či sú heslá, tajné kódy a kľúče uložené a oznámené bezpečnými spôsobmi.
  • Potvrdenie správneho nastavenia zabezpečenia: Overte, či sú povolenia na prístup správne nastavené pre nespracované údaje. Zabezpečte, aby správcovia a audítori mali prístup k nespracovaným údajom.

Ďalšie informácie o tom, ako sa riešenie auditovania a monitorovania postupne zväčšuje, nájdete v časti Sfunkčnenie a zlepšenie ďalej v tomto článku.

Vytvorenie spravovaných údajov

V tomto bode sa nespracované údaje extrahujú a ukladajú. Ďalším krokom je vytvorenie samostatnej zlatej vrstvy údajov pre spravované údaje. Jeho cieľom je transformovať a ukladať údajové súbory vo hviezdicovej schéme. Hviezdicová schéma sa skladá z tabuliek dimenzií a tabuliek faktov a je zámerne optimalizovaná na analýzu a vytváranie zostáv. Súbory z tejto spravovanej vrstvy údajov sa stanú zdrojom dátového modelu Power BI (ako je popísané v ďalšej téme).

Tip

Ak očakávate, že bude k dispozícii viac ako jeden dátový model, je užitočné investovať do centralizovanej vrstvy údajov.

Kontrolný zoznam – pri vytváraní spravovanej vrstvy údajov sa ku kľúčovým rozhodnutiam a akciám patria:

  • Potvrdenie požiadaviek a priorít: Ak máte v úmysle použiť sprostredkovateľskú striebornú vrstvu pre transformované údaje, objasnite požiadavky a ciele toho, čo potrebujete dosiahnuť.
  • Nastavte proces transformácie nespracovaných údajov a ich načítania do vytvorenej zóny údajov: Vytvorte proces na transformáciu a načítanie údajov do hviezdicovej schémy. Otestujte, či proces funguje podľa potreby.
  • Vytvorenie plánu na spustenie procesov: Nastavte opakovaný plán na vyplnenie vytvorenej vrstvy údajov.
  • Potvrdenie správneho nastavenia zabezpečenia: Overte, či sú správne nastavené povolenia na prístup pre spravované údaje. Uistite sa, že vývojári dátového modelu majú prístup k spravovaným údajom.

Vytvorenie dátového modelu

Téma je o nastavení analytického dátového modelu. Dátový model je zdroj údajov s možnosťou dotazu optimalizovaný na analýzu. Niekedy sa označuje ako sémantický model alebo jednoducho model. Pre vaše riešenie auditovania a monitorovania bude dátový model pravdepodobne implementovaný ako sémantický model služby Power BI.

V súvislosti s auditovaním a monitorovaním dátový model pochádza z spravovanej (zlatej) vrstvy údajov. Ak sa rozhodnete nevytvoriť spravovanú vrstvu údajov, dátový model získava údaje priamo zo nespracovaných údajov.

Odporúčame, aby váš dátový model Power BI implementovali návrh hviezdicovej schémy. Keď sú zdrojové údaje spravovanou vrstvou údajov, hviezdicová schéma dátového modelu Power BI by mala odrážať spravovanú hviezdicu vrstvy údajov.

Tip

Prehľad návrhu hviezdicovej schémy nájdete v téme Vysvetlenie hviezdicovej schémy a jej dôležitosti pre službu Power BI.

Podobne ako pri každom projekte služby Power BI, aj vytváranie dátového modelu predstavuje iteračný proces. Nové mierky môžete pridať podľa potreby. Môžete tiež pridať nové tabuľky a stĺpce, keď budú k dispozícii nové udalosti auditu. Časom by ste dokonca mohli integrovať nové zdroje údajov.

Tu je niekoľko užitočných tabuliek dimenzií, ktoré môžete zahrnúť do dátového modelu.

  • Dátum: Množina atribútov dátumu na povolenie analýzy (rozdeľovanie a rozdelenie) údajov podľa dní, týždňov, mesiacov, štvrťrokov, rokov a ďalších relevantných časových období.
  • Čas: Ak potrebujete analyzovať podľa dennej doby a máte veľmi veľký objem údajov auditu, zvážte uloženie časti času oddelene od dátumu. Tento prístup môže pomôcť zlepšiť výkon dotazu.
  • Používatelia: Atribúty, ktoré popisujú používateľov (napríklad oddelenie a geografickú oblasť), ktoré môžu filtrovať mnoho subjektov auditovania údajov. Cieľom je odstrániť z tabuliek faktov všetky podrobnosti o používateľovi a uložiť ich v tejto tabuľke dimenzií, aby mohli filtrovať mnohé tabuľky faktov. V tejto tabuľke môžete ukladať aj objekty služby.
  • Udalosti aktivity: Atribúty, ktoré zoskupujú a popisujú udalosti aktivity (operácie). Na vylepšenie vytvárania zostáv môžete vytvoriť slovník údajov, ktorý popisuje každú udalosť aktivity. Môžete tiež vytvoriť hierarchiu, ktorá zoskupuje a klasifikuje podobné udalosti aktivity. Môžete napríklad zoskupovať všetky udalosti vytvorenia položiek, odstraňovať udalosti a podobne.
  • Pracovné priestory: zoznam pracovných priestorov vo vlastnostiach nájomníka a pracovného priestoru, ako je napríklad typ (osobný alebo štandardný) a popis. Niektoré organizácie zaznamenávali ďalšie podrobnosti o pracovných priestoroch (pravdepodobne používajú zoznam SharePointu). Tieto podrobnosti môžete integrovať do tejto tabuľky dimenzií. Musíte sa rozhodnúť, či táto tabuľka dimenzií uchováva len aktuálny stav pracovného priestoru alebo či ukladá údaje s verziami, ktoré odrážajú významné zmeny pracovného priestoru v priebehu času. Napríklad, keď sa názov pracovného priestoru zmení, zobrazuje sa v historických výkazoch aktuálny názov pracovného priestoru alebo názov pracovného priestoru, ktorý bol v tom čase aktuálny? Ďalšie informácie o tvorbe verzií nájdete v téme Pomaly sa meniace dimenzie.
  • Typy položiek: zoznam typov položiek služby Power BI (sémantické modely, zostavy a ďalšie).
  • Kapacity: Zoznam kapacít Premium v nájomníkovi.
  • Brány: zoznam brán údajov v nájomníkovi.
  • Zdroje údajov: zoznam zdrojov údajov, ktoré používajú akýkoľvek sémantický model, tok údajov alebo údajový graf.

Tu je niekoľko užitočných tabuliek faktov (subjektov), ktoré môžete zahrnúť do dátového modelu.

  • Aktivity používateľov: údaje faktov, ktoré pochádzajú z pôvodných údajov JSON. Odstránia sa všetky atribúty, ktoré nemajú analytickú hodnotu. Odstránia sa aj všetky atribúty, ktoré patria do tabuliek dimenzií (uvedených vyššie).
  • Inventár nájomníka: Snímka všetkých položiek publikovaných v nájomníkovi v určitom čase. Ďalšie informácie nájdete v časti Inventár nájomníkov vyššie v tomto článku.
  • Sémantické modely: zahŕňa aktivitu používateľa zahŕňajúcu sémantické modely (napríklad zmeny sémantických modelov) alebo súvisiace zdroje údajov.
  • Obnovenia sémantického modelu: ukladá operácie obnovenia údajov vrátane podrobností o type (plánovanom alebo na požiadanie), trvaní, stave a používateľovi, ktorý spustil operáciu.
  • Roly pracovného priestoru: Snímka priradení roly pracovného priestoru v čase.
  • Používateľské licencie: snímka používateľských licencií v konkrétnom čase. Možno budete v pokušení uložiť používateľskú licenciu v tabuľke dimenzií Používatelia , tento prístup nebude podporovať analýzu zmien licencií a trendov v priebehu času.
  • Členstvá v skupine používateľov: Snímka používateľov (a objektov služby) priradených k skupine zabezpečenia v určitom bode v čase.
  • Aktivity komunity: zahŕňa fakty týkajúce sa komunity, ako napríklad školenia. V porovnaní s návštevnosťou školenia môžete napríklad analyzovať aktivity používateľov služby Power BI. Tieto údaje by mohli centru excelentnosti pomôcť identifikovať potenciálnych nových šampiónov.

Tabuľky faktov by nemali obsahovať stĺpce, ktoré budú tvorcovia zostáv filtrovať. Namiesto toho tieto stĺpce patria do súvisiacich tabuliek dimenzií. Nielenže je tento návrh efektívnejší pre dotazy, ale tiež podporuje opätovné použitie tabuliek dimenzií viacerými faktami (známymi ako prechod na detaily). Posledný bod je dôležitý na vytvorenie užitočného a používateľsky príjemného dátového modelu, ktorý je rozšíriteľný po pridaní nových tabuliek faktov (subjektov).

Napríklad tabuľka dimenzií Používatelia bude súvisieť so každou tabuľkou faktov. Mala by súvisieť s tabuľkou faktov Aktivity používateľa (ktorá vykonávala aktivitu), tabuľkou faktov inventára nájomníka (ktorá vytvorila publikovanú položku) a všetkými ostatnými tabuľkami faktov. Keď zostava filtruje podľa používateľa v tabuľke dimenzií Používatelia , vizuály v tejto zostave môžu zobrazovať fakty pre daného používateľa zo ľubovoľnej súvisiacej tabuľky faktov.

Pri navrhovaní modelu sa uistite, že atribút je v modeli viditeľný raz a len raz. E-mailová adresa používateľa by napríklad mala byť viditeľná len v tabuľke dimenzií Používatelia . Bude existovať aj v iných tabuľkách faktov (ako kľúč dimenzie na podporu modelového vzťahu). Mali by ste ho však skryť v každej tabuľke faktov.

Odporúčame, aby ste vytvorili dátový model oddelene od zostáv. Oddelením sémantického modelu a jeho zostáv sa vytvorí centralizovaný sémantický model, ktorý môže slúžiť mnohým zostavách. Ďalšie informácie o používaní zdieľaného sémantického modelu nájdete v scenári používania spravovaného samoobslužného BI .

Zvážte nastavenie zabezpečenia na úrovni riadkov (RLS), aby ostatní používatelia, okrem Centra excelentnosti, audítori a správcovia, mohli analyzovať údaje auditovania a zostavy. Pravidlá zabezpečenia na úrovni riadkov by ste napríklad mohli použiť na to, aby tvorcovia obsahu a spotrebitelia mohli vytvárať zostavy o svojich aktivitách používateľov alebo vývoji.

Kontrolný zoznam – pri vytváraní dátového modelu sú tu kľúčové rozhodnutia a akcie:

  • Naplánovanie a vytvorenie dátového modelu: Navrhnite dátový model ako hviezdicovú schému. Overte, či vzťahy fungujú podľa potreby. Pri vývoji modelu opakovane vytvárate mierky a pridávate ďalšie údaje na základe analytických požiadaviek. V prípade potreby môžete zahrnúť budúce vylepšenia nevybavených.
  • Nastavenie zabezpečenia na úrovni riadkov: Ak plánujete sprístupniť dátový model ostatným všeobecným používateľom, nastavte zabezpečenie na úrovni riadkov na obmedzenie prístupu k údajom. Overte, či roly zabezpečenia na úrovni riadkov vracajú správne údaje.

Vylepšenie dátového modelu

Na efektívnu analýzu používania obsahu a aktivít používateľov sa odporúča obohatiť váš dátový model. Vylepšenia dátového modelu sa môžu vykonávať postupne a opakovane v priebehu času pri zisťovaní príležitostí a nových požiadaviek.

Vytváranie klasifikácií

Jedným zo spôsobov, ako vylepšiť model a zvýšiť hodnotu údajov, je pridať klasifikácie do dátového modelu. Uistite sa, že tieto klasifikácie sú používané zostavami konzistentne.

Môžete klasifikovať používateľov na základe ich úrovne používania alebo klasifikovať obsah na základe jeho úrovne používania.

Klasifikácia používania používateľa

Zvážte nasledujúce klasifikácie na používanie používateľmi.

  • Častý používateľ: aktivita zaznamenaná za posledný týždeň a v deviatich z posledných 12 mesiacov.
  • Aktívny používateľ: Aktivita zaznamenaná za posledný mesiac.
  • Príležitostný používateľ: Aktivita zaznamenaná za posledných deväť mesiacov, ale bez aktivity za posledný mesiac.
  • Neaktívny používateľ: Za posledných deväť mesiacov sa nezaznamenali žiadne aktivity.

Tip

Je užitočné vedieť, kto sú príležitostní alebo neaktívni používatelia, a to najmä vtedy, keď majú licencie na Verziu alebo Premium na používateľa (ktoré zahŕňajú náklady). Je tiež užitočné vedieť, kto sú vašimi najčastejšími a najaktívnejšími používateľmi. Zvážte ich pozvanie do úradných hodín alebo na školenie. Najaktívnejší tvorcovia obsahu môžu byť kandidátmi na pripojenie k sieti šampiónov.

Klasifikácia používania obsahu

Zvážte nasledujúce klasifikácie používania obsahu.

  • Často používaný obsah: Aktivita zaznamenaná v poslednom týždni a v deviatich z posledných 12 mesiacov.
  • Aktívne používaný obsah: Aktivita zaznamenaná v uplynulom mesiaci.
  • Príležitostne použitý obsah: Aktivita zaznamenaná za posledných deväť mesiacov, ale bez aktivity za posledný mesiac.
  • Nepoužitý obsah: Za posledných deväť mesiacov sa nezaznamenali žiadne aktivity.
Klasifikácia typu používateľa

Zvážte nasledujúce klasifikácie typu používateľa.

  • Tvorca obsahu: Aktivita zaznamenaná za posledných šesť mesiacov, ktorá vytvorila, publikovala alebo upravila obsah.
  • Zobrazovač obsahu: Aktivita zaznamenaná za posledných šesť mesiacov, ktorá zobrazovala obsah, ale bez aktivít vytvárania obsahu.

Mali by ste sa rozhodnúť, či by klasifikácie používania používateľov alebo obsahu mali byť založené len na nedávnom výskyte aktivity. Môžete tiež zvážiť faktoring v priemere alebo trendy používania v priebehu času.

Predstavte si niekoľko príkladov, ktoré ukazujú, ako môže jednoduchá logika klasifikácie skresľovať realitu.

  • Manažér si tento týždeň zobrazil jednu zostavu. Avšak, pred týmto týždňom, manažér nemal zobraziť žiadne správy za posledných šesť mesiacov. Tohto manažéra by ste nemali považovať za často používaného používateľa len na základe nedávneho používania.
  • Tvorca zostavy každý týždeň publikuje novú zostavu. Pri analýze používania častými používateľmi sa zdá byť bežná aktivita tvorcu zostavy pozitívna. Po ďalšom skúmaní však zistíte, že tento používateľ znova publikoval novú zostavu (s novým názvom zostavy) pri každej úprave zostavy. Bolo by užitočné, ak by autor zostavy mal viac školení.
  • Vedúci pracovník vníma zostavu sporadicky, a tak sa ich klasifikácia používania často mení. Možno budete musieť analyzovať určité typy používateľov, ako sú napríklad vedúci pracovníci, inak.
  • Interný audítor si raz za rok prezrite kritické správy. Interný audítor sa môže z dôvodu zriedkavého používania javiť ako neaktívny používateľ. Niekto môže vykonať kroky na odstránenie licencie Pro alebo služby Premium na používateľa. Alebo by sa niekto mohol domnievať, že zostava by sa mala odísť do dôchodku, pretože sa používa zriedkavo.

Tip

Priemery a trendy môžete vypočítať pomocou funkcií časovej inteligencie jazyka DAX. Ak sa chcete naučiť používať tieto funkcie, študijný modul Používanie funkcií časovej inteligencie jazyka DAX v modeloch aplikácie Power BI Desktop.

Kontrolný zoznam – pri vytváraní klasifikácie údajov o používaní zahŕňajú kľúčové rozhodnutia a akcie:

  • Získať konsenzus o definíciách klasifikácie: Prediskutujte definície klasifikácie s príslušnými zainteresovanými stranami. Uistite sa, že pri rozhodovaní existuje dohoda.
  • Vytvorenie dokumentácie: Zabezpečte, aby definície klasifikácie boli súčasťou dokumentácie pre tvorcov obsahu a spotrebiteľov.
  • Vytvorenie slučky pripomienok: Uistite sa, že používatelia môžu klásť otázky alebo navrhovať zmeny definícií klasifikácie.

Vytváranie analytických zostáv

V tomto bode sa údaje auditovania extrahovali a uložili a publikovali ste dátový model. Ďalším krokom je vytvorenie analytických zostáv.

Zamerajte sa na kľúčové informácie, ktoré sú najrelevantnejšie pre jednotlivé cieľové skupiny. V zostavách auditovania môžete mať viacero účastníkov. Každá cieľová skupina bude mať záujem o rôzne informácie a na rôzne účely. Cieľové skupiny, ktoré môžete používať vo svojich zostavách, zahŕňajú:

  • Sponzor projektu
  • Centrum excelentnosti
  • Správcovia služby Power BI
  • Správcovia pracovného priestoru
  • Správcovia kapacity Premium
  • Správcovia brány
  • Vývojári a tvorcovia obsahu v službe Power BI
  • Audítorov

Tu je niekoľko najbežnejších analytických požiadaviek, s ktorými môžete začať pri vytváraní zostáv auditovania.

  • Zobrazenia najlepšieho obsahu: Váš výkonný sponzor a vedúce tímy by mohli zaujímať predovšetkým súhrnné informácie a trendy v priebehu času. Podrobnosti budú viac zaujímať vašich správcov pracovného priestoru, vývojárov a tvorcov obsahu.
  • Aktivity pre najaktívnejších používateľov: Vaše Centrum excelentnosti bude zaujímať, kto používa službu Power BI, ako a kedy. Správcovia kapacity Premium budú zaujímať, kto kapacitu využíva na zabezpečenie jej stavu a stability.
  • Inventár nájomníkov: Správcovia služby Power BI, správcovia pracovného priestoru a audítori budú mať záujem o informácie o tom, čo obsah existuje, kde, kde sa nachádza, pôvod a nastavenia zabezpečenia.

Tento zoznam nie je all-inclusive. Jeho cieľom je poskytnúť vám nápady, ako vytvoriť analytické zostavy zamerané na konkrétne potreby. Ďalšie informácie nájdete vyššie v tomto článku v časti Potreby údajov a Prehľad auditovania a monitorovania. Medzi tieto zdroje patrí množstvo nápadov na používanie auditovania údajov a typy informácií, ktoré by ste mali prezentovať vo svojich zostavách.

Tip

Hoci prezentovanie veľkého množstva údajov je lákavé, uveďte iba informácie, s ktorými ste pripravení konať. Uistite sa, že každá strana zostavy má jasnú predstavu o jej účele, o tom, aké kroky je potrebné vykonať a kým.

Ak sa chcete naučiť vytvárať analytické zostavy, prepracujte sa cez študijný program Navrhovanie efektívnych zostáv v službe Power BI .

Kontrolný zoznam – pri plánovaní analytických zostáv auditovania zahŕňajú kľúčové rozhodnutia a akcie:

  • Požiadavky na revíziu: Uprednostnite vytváranie zostáv na základe známych potrieb a konkrétnych otázok, na ktoré by mali byť zodpovedané.
  • Potvrďte cieľové skupiny: Objasnite, kto bude používať zostavy auditovania a aký bude ich zamýšľaný účel.
  • Vytváranie a nasadzovanie zostáv: Vytvorte prvú množinu základných zostáv. postupne ich rozširovať a zdokonaľovať.
  • Distribúcia zostáv v aplikácii: Zvážte vytvorenie aplikácie, ktorá zahŕňa všetky vaše zostavy auditovania a monitorovania.
  • Overenie, kto má prístup k zostavám: Zabezpečte, aby boli zostavy (alebo aplikácia) k dispozícii pre správnu množinu používateľov.
  • Vytvorenie slučky spätnej väzby: Uistite sa, že existuje spôsob, ako môžu používatelia zostavy poskytnúť pripomienky, návrhy alebo hlásiť problémy.

Vykonanie akcie na základe údajov

Auditovanie údajov je cenné, pretože vám pomáha pochopiť, čo sa deje v nájomníkovi služby Power BI. Aj keď by sa to mohlo zdať zrejmé, explicitne konať na základe toho, čo sa učíte z údajov auditu možno ľahko prehliadnuť. Z tohto dôvodu odporúčame namiesto iba kontroly zostáv auditu priradiť niekoho, kto je zodpovedný za sledovanie merateľných vylepšení. Týmto spôsobom môžete postupne dosiahnuť postupné merateľné pokroky v osvojenia a úrovni splatnosti so službou Power BI.

Na základe svojich cieľov a toho, čo sa naučíte z údajov auditovania, môžete vykonať mnoho rôznych akcií. V zostávajúcej časti tejto časti nájdete niekoľko nápadov.

Používanie obsahu

Tu je niekoľko akcií, ktoré môžete vykonať na základe spôsobu používania obsahu.

  • Obsah sa často používa (denne alebo týždenne): Overte, či je certifikovaný dôležitý obsah. Potvrďte, že vlastníctvo je jasné a riešenie je adekvátne podporované.
  • Veľký počet zobrazení pracovného priestoru: Ak sa vyskytne vysoký počet zobrazení pracovného priestoru, preskúmajte, prečo sa aplikácie Power BI nepoužívajú.
  • Obsah sa používa zriedkavo: Obráťte sa na cieľových používateľov a zistite, či riešenie spĺňa ich potreby alebo či sa ich požiadavky zmenili.
  • Aktivita obnovenia sa vykonáva častejšie ako zobrazenia: Obráťte sa na vlastníka obsahu, aby ste pochopili, prečo sa sémantický model pravidelne obnovuje bez akéhokoľvek nedávneho použitia sémantického modelu alebo súvisiacich zostáv.

Aktivity používateľov

Tu je niekoľko akcií, ktoré môžete vykonať na základe aktivít používateľov.

  • Prvá akcia publikovania novým používateľom: Identifikujte, kedy sa typ používateľa zmení zo spotrebiteľa na tvorcu, ktorý môžete identifikovať pri prvom publikovaní obsahu. Je to skvelá príležitosť na odoslanie štandardného e-mailu, ktorý poskytuje usmernenie a prepojenia na užitočné zdroje.
  • Spolupráca s najčastejšími tvorcami obsahu: Pozvať najaktívnejších tvorcov, aby sa pripojili k sieti šampiónov alebo sa zapojili do komunity postupov.
  • Správa licencií: Overte, či neaktívni tvorcovia stále potrebujú licenciu Pro alebo Premium na používateľa.
  • Aktivácia skúšobnej verzie používateľa: Aktivácia skúšobnej verzie môže zobraziť výzvu na priradenie trvalej licencie používateľovi pred skončením jeho skúšobnej verzie.

Príležitosti na školenie používateľov

Tu je niekoľko príležitostí na školenie používateľov, ktoré by ste mohli identifikovať z údajov auditovania.

  • Veľký počet sémantických modelov publikovaných rovnakým tvorcom obsahu: Učenie používateľov o zdieľaných sémantických modeloch a dôvodoch, prečo je dôležité vyhnúť sa vytváraniu duplicitných sémantických modelov.
  • Nadmerné zdieľanie z osobného pracovného priestoru: Obráťte sa na používateľa, ktorý robí veľa zdieľania zo svojho osobného pracovného priestoru. Naučte sa ich o štandardných pracovných priestoroch.
  • Významné zobrazenia zostavy z osobného pracovného priestoru: Obráťte sa na používateľa, ktorý vlastní obsah s vysokým počtom zobrazení zostavy. Naučte sa, ako sú štandardné pracovné priestory lepšie ako osobné pracovné priestory.

Tip

Obsah školenia alebo dokumentáciu môžete tiež zlepšiť kontrolou otázok zodpovedaných vašou internou komunitou služby Power BI a problémami odoslanými na oddelenie technickej podpory.

Zabezpečenie

Tu je niekoľko situácií zabezpečenia, ktoré možno budete chcieť aktívne monitorovať.

Ďalšie informácie nájdete v článkoch o plánovaní zabezpečenia.

Riadenie a zmiernenie rizika

Tu je niekoľko situácií, s ktorými sa môžete stretnúť. Zvážte explicitné vyhľadanie týchto typov situácií v zostavách auditovania, aby ste boli pripravení konať rýchlo.

  • Vysoký počet zobrazení zostáv (a základných sémantických modelov), ktoré nie sú odporučené.
  • Značné využitie neznámych alebo neschválených zdrojov údajov.
  • Umiestnenia súborov, ktoré nie sú v súlade s pokynmi na riadenie, kde by sa mali nachádzať zdrojové súbory.
  • Názvy pracovných priestorov nie sú v súlade s požiadavkami na riadenie.
  • Označenia citlivosti sa používajú na ochranu informácií.
  • Konzistentné zlyhania obnovenia údajov.
  • Významné a opakované použitie tlače.
  • Neočakávané alebo nadmerné používanie predplatných.
  • Neočakávané použitie osobných brán.

Konkrétne akcie, ktoré sa majú vykonať v každej situácii, budú závisieť od vašich politík riadenia. Ďalšie informácie nájdete v téme Riadenie v pláne prijatia služby Fabric.

Kontrolný zoznam – pri plánovaní možných akcií, ktoré sú založené na údajoch auditovania, ku kľúčovým rozhodnutiam a akciám patria:

  • Objasnite očakávania: Vytvorte zostavy auditovania s jasným súborom očakávaní, aké akcie sa očakávajú.
  • Objasnite, kto bude zodpovedný za akcie: Zabezpečte priradenie rolí a povinností.
  • Vytvorenie automatizácie: Ak je to možné, automatizujte známe akcie, ktoré sa dajú opakovať.
  • Použitie systému sledovania: Použite systém na sledovanie pozorovanej situácie vrátane vykonaného kontaktu, ďalšej plánovanej akcie, osoby zodpovednej za riešenie a stavu.

Fáza 4: Údržba, vylepšenie a monitorovanie

Štvrtá fáza plánovania a implementácie riešenia auditovania na úrovni nájomníka sa zameriava na údržbu, vylepšenia a monitorovanie. V tomto momente sa vaše riešenie auditovania používa v produkčnom prostredí. Teraz sa zaoberáte predovšetkým udržiavaním, vylepšovaním a monitorovaním riešenia.

Diagram postupu popisujúci fázu 4, ktorá sa zameriava na udržiavanie, vylepšenie a monitorovanie riešenia auditovania na úrovni nájomníka.

Využiť a zlepšiť prevádzku

Procesy auditovania sa zvyčajne považujú za spustené v produkcii po dokončení počiatočného vývoja a testovania a vy ste proces automatizovali. Automatizované procesy auditovania, ktoré sa spúšťajú vo výrobe, majú väčšie očakávania (než manuálne procesy) týkajúce sa kvality, spoľahlivosti, stability a podpory.

Bol spustený proces auditovania na úrovni produkcie. Prevádzkové riešenie zvyčajne zahŕňa mnohé z nasledujúcich charakteristík.

  • Zabezpečené: Poverenia sú uložené a spravované bezpečne. Skripty neobsahujú heslá ani kľúče vo formáte obyčajného textu.
  • Plánovanie: Je zavedený spoľahlivý plánovací systém.
  • Správa zmien: Na zabezpečenie ochrany produkčného prostredia sa používa používanie postupov spravovania zmien a viacerých prostredí. Môžete tiež pracovať s vývojovými a testovacími prostrediami alebo len s vývojovým prostredím.
  • Podpora: Tím, ktorý riešenie podporuje, je jasne definovaný. Členovia tímu boli vyškolení a rozumejú operačným očakávaniam. Identifikovali sa členovia zálohy a v prípade potreby sa uskutoční krížové školenie.
  • Upozornenie: Ak sa vyskytne chyba, upozornenia automaticky upozornia tím podpory. Ak je to možné, upozorňovanie zahŕňa denníky aj e-maily (nie iba e-mail). Denník je užitočný na analýzu zaznamenaných chýb a upozornení.
  • Zapisovanie do denníka: Procesy sa zapisujú do denníka, aby sa zobrazila história aktualizácií údajov auditovania. Zaznamenané informácie by mali zaznamenávať čas začatia, koncový čas a identitu používateľa alebo aplikácie, ktorá spustila proces.
  • Spracovanie chýb: Skripty a procesy spracovať a zapisovať do denníka chyby (napríklad či sa majú okamžite ukončiť, pokračovať alebo počkať a skúsiť znova). Oznámenia o upozornení sa odošlú tímu podpory, keď sa vyskytne chyba.
  • Kódovacie štandardy: Dobre fungujú techniky kódovania, ktoré fungujú dobre. Napríklad slučky sa účelovo vyhýbajú, okrem prípadov potreby. Na údržbu a podporu riešenia sa používajú konzistentné štandardy kódovania, komentáre, formátovanie a syntax.
  • Opätovné použitie a modularizácia: Na minimalizovanie duplikácie, hodnôt kódu a konfigurácie (ako sú napríklad reťazec pripojenia alebo e-mailové adresy na oznámenia) sa vytvárajú moduly, aby ich mohli použiť iné skripty a procesy.

Tip

Nemusíte robiť všetko, čo je uvedené vyššie, naraz. Postupne ako získavate skúsenosti, môžete prírastkovo zlepšiť riešenie tak, aby bolo úplné a robustné. Väčšina príkladov, ktoré online nájdete, sú jednoduché jednorazové úryvky skriptov, ktoré nemusia mať kvalitu produkcie.

Kontrolný zoznam – pri plánovaní prevádzky a zlepšovania riešenia auditovania sú kľúčové rozhodnutia a akcie:

  • Posúdenie úrovne existujúcich riešení: Určte, či existujú príležitosti na zlepšenie a stabilizáciu existujúcich riešení auditovania, ktoré sú automatizované.
  • Vytvorenie štandardov na úrovni produkcie: Rozhodnite sa, aké štandardy chcete mať pre svoje automatizované procesy auditovania. Faktor vylepšení, ktorý môžete reálne pridávať v priebehu času.
  • Vytvorte plán na zlepšenie: Plán na zlepšenie kvality a stability riešení auditovania výroby.
  • Určenie, či je potrebné samostatné vývojové prostredie: Vyhodnoťte úroveň rizika a spoliehanie sa na produkčné údaje. Rozhodnite sa, kedy chcete vytvoriť samostatné vývojové a produkčné (a testovacie) prostredia.
  • Zoberme si stratégiu uchovávania údajov: Určte, či potrebujete implementovať proces uchovávania údajov, ktorý vymaže údaje po určitom čase alebo na požiadanie.

Dokumentácia a podpora

Dokumentácia a podpora sú dôležité pre všetky riešenia na úrovni produkcie. V závislosti od cieľovej skupiny a účelu je vhodné vytvoriť niekoľko typov dokumentácie.

Technická dokumentácia

Technická dokumentácia je zameraná na technický tím, ktorý vybudoval riešenie a ktorý bude postupne zlepšovať a rozširovať riešenie. Je to zároveň užitočný zdroj pre tím podpory.

Technická dokumentácia by mala obsahovať:

  • Súhrn súčastí a predpokladov architektúry.
  • Kto riešenie vlastní a spravuje.
  • Kto riešenie podporuje.
  • Diagram architektúry.
  • návrhy rozhodnutí vrátane cieľov, dôvodov, prečo sa vykonali určité technické rozhodnutia, a obmedzení (napríklad náklady alebo zručnosti).
  • Rozhodnutia a možnosti zabezpečenia.
  • Použité konvencie pomenovania.
  • Kódovacie a technické normy a usmernenia.
  • Požiadavky na spravovanie zmien.
  • Pokyny na nasadenie, nastavenie a inštaláciu.
  • Známe oblasti technického dlhu (oblasti, ktoré možno zlepšiť, ak existuje príležitosť tak urobiť).

Dokumentácia k podpore

V závislosti od úrovne kritickosti pre vaše riešenie auditovania by ste mohli mať technickú podporu alebo tím podpory v prípade, že sa vyskytnú naliehavé problémy. Možno budú k dispozícii každý deň.

Dokumentácia podpory sa niekedy označuje ako vedomostná databáza alebo súbor súborov. Táto dokumentácia je zameraná na vašu technickú podporu alebo tím podpory a mala by obsahovať tieto informácie:

  • Pokyny na riešenie problémov v prípade problémov. Napríklad v prípade zlyhania obnovenia údajov.
  • opatrenia, ktoré treba vykonať priebežne. Môžu existovať napríklad manuálne kroky, ktoré niekto musí robiť pravidelne, kým sa problém nevyrieši.

Dokumentácia tvorcu obsahu

Z riešenia auditovania môžete odvodiť väčšiu hodnotu tým, že poskytujete analýzu používania a prijatia iným tímom v celej organizácii (v prípade potreby sa vynucuje zabezpečenie na úrovni riadkov).

Dokumentácia tvorcu obsahu je zameraná na samoobslužných tvorcov obsahu, ktorí vytvárajú zostavy a dátové modely, ktoré získavajú spravované údaje auditovania. Obsahuje informácie o dátovom modeli vrátane bežných definícií údajov.

Kontrolný zoznam – pri plánovaní dokumentácie a podpore vášho riešenia auditovania sa ku kľúčovým rozhodnutiam a akciám patria:

  • Potvrďte, kto má dané riešenie podporovať: Určite, kto bude podporovať riešenia auditovania, ktoré sa považujú za produkčnú úroveň (alebo majú závislosti zostáv po prúde).
  • Skontrolujte pripravenosť tímu podpory: Overte, či je tím podpory pripravený podporiť riešenie auditovania. Identifikujte, či existujú nejaké medzery v pripravenosti, ktoré treba riešiť.
  • Usporiadajte pre krížové školenie: Vykonajte relácie prenosu vedomostí alebo krížové školenia pre tím podpory.
  • Objasnite očakávania tímu podpory: Ubezpečte sa, že očakávania v súvislosti s odpoveďou a riešením budú jasne zdokumentované a oznámené. Rozhodnite sa, či bude treba volať niekoho, aby mohol rýchlo vyriešiť problémy súvisiace s riešením auditovania.
  • Vytvorenie technickej dokumentácie: Vytvorte dokumentáciu o technickej architektúre a rozhodnutiach o návrhu.
  • Vytvorenie dokumentácie podpory: Aktualizujte technickú databázu vedomostí technickej podpory tak, aby obsahovala informácie o tom, ako dané riešenie podporovať.
  • Vytvorenie dokumentácie pre tvorcov obsahu: Vytvorte dokumentáciu, ktorá pomáha samoobslužným tvorcom používať dátový model. Popíšte bežné definície údajov a zlepšite konzistentnosť ich používania.

Povolenie upozorňovania

Pravdepodobne budete chcieť upozorniť na základe konkrétnych podmienok v údajoch auditovania. Upozornenie môžete napríklad upozorniť, keď niekto odstráni bránu alebo keď správca služby Power BI zmení nastavenie nájomníka.

Ďalšie informácie nájdete v téme Monitorovanie na úrovni nájomníka.

Prebiehajúce spravovanie

Je potrebné vykonávať priebežnú správu celého riešenia auditovania. Možno bude potrebné rozšíriť alebo zmeniť riešenie auditovania v prípadoch, keď:

  • Organizácia zisťuje nové požiadavky na údaje.
  • Nové udalosti auditu sa zobrazia v nespracovaných údajoch, ktoré môžete presne zobraziť z rozhraní REST API služby Power BI.
  • Spoločnosť Microsoft vykoná zmeny v rozhraniach POWER BI REST API.
  • Zamestnanci identifikujú spôsoby, ako zlepšiť riešenie.

Dôležité

Porušenie zmien je zriedkavé, ale môžu sa vyskytnúť. Je dôležité, aby ste mali k dispozícii niekoho, kto môže v prípade potreby rýchlo riešiť problémy alebo aktualizovať riešenie auditovania.

Kontrolný zoznam – pri plánovaní priebežného riadenia riešenia auditovania sú ku kľúčovým rozhodnutiam a akciám zahrnuté:

  • Priradenie technického vlastníka: Zabezpečte jasné vlastníctvo a zodpovednosť za celé riešenie auditovania.
  • Overte, či existuje záloha: Skontrolujte, či existuje záložný technický vlastník, ktorý sa môže zapojiť, ak sa vyskytne naliehavý problém, ktorý podpora nemôže vyriešiť.
  • Majte systém sledovania: Zabezpečte, aby ste získali spôsob na zaznamenanie nových požiadaviek a spôsob na určenie priorít okamžitej priority, ako aj krátkodobých, strednodobých a dlhodobých (nevybavených).

Súvisiaci obsah

V nasledujúcom článku v tejto sérii získate informácie o monitorovaní na úrovni nájomníka.