Plánování implementace Power BI: Auditování na úrovni tenanta

  • Článek

Poznámka:

Tento článek je součástí řady článků o plánování implementace Power BI. Tato série se zaměřuje především na úlohy Power BI v Rámci Microsoft Fabric. Úvod do série najdete v tématu Plánování implementace Power BI.

Tento článek o plánování auditu na úrovni tenanta je primárně zaměřený na:

  • Správci Power BI: Správci, kteří jsou zodpovědní za dohled nad Power BI v organizaci. Správci Power BI můžou potřebovat spolupracovat s IT, zabezpečením, interním auditem a dalšími relevantními týmy.
  • Center of Excellence, IT a BI team: Týmy, které jsou také zodpovědné za dohled nad Power BI. Možná budou muset spolupracovat se správci Power BI a dalšími relevantními týmy.

Důležité

Doporučujeme pečlivě sledovat plán verze Power BI, abyste se dozvěděli o budoucích vylepšeních možností auditování a monitorování.

Účelem řešení auditu na úrovni tenanta je zachytit a analyzovat data pro všechny uživatele, aktivity a řešení nasazená v tenantovi Power BI. Tato data auditování na úrovni tenanta jsou cenná pro mnoho účelů, což vám umožní analyzovat úsilí o přijetí, porozumět vzorům využití, informovat uživatele, podporovat uživatele, zmírnit rizika, zlepšit dodržování předpisů, spravovat náklady na licence a monitorovat výkon.

Vytvoření komplexního řešení auditování, které je zabezpečené a připravené pro produkční prostředí, je významný projekt, který nějakou dobu trvá. Představte si ho jako vytváření business intelligence na business intelligence (BI v BI). Informace o tom, proč jsou data auditování tak cenná, najdete v tématu Přehled auditování a monitorování.

Auditování na úrovni sestavy, které je cílem tvůrců sestav, najdete v tématu Auditování na úrovni sestavy.

Informace o auditování datových prostředků, které jsou cílem tvůrců dat, najdete v tématu Auditování na úrovni dat.

Zbývající část tohoto článku se zaměřuje na auditování na úrovni tenanta.

Tip

Hlavním cílem tohoto článku je pomoct vám s plánováním vytvoření uceleného řešení auditování. Vzhledem k tomu, že obsah v tomto článku je uspořádaný do čtyř fází, budete potřebovat informace napříč několika fázemi. Například ve fázi 1 najdete informace o plánování použití instančního objektu a informace ve fázi 2 o požadavcích a nastavení.

Proto doporučujeme, abyste si nejprve přečetli celý článek, abyste se seznámili s tím, co se týká. Pak byste měli být dobře připraveni naplánovat a sestavit řešení auditování iterativním způsobem.

Když plánujete vytvořit řešení auditování na úrovni tenanta, naplánujte si čas na následující čtyři fáze.

Fáze 1: Plánování a rozhodování

První fáze se zaměřuje na plánování a rozhodování. Existuje mnoho požadavků a priorit, které je potřeba vzít v úvahu, takže doporučujeme věnovat dostatek času, abyste porozuměli tématům představených v této části. Cílem je učinit dobrá počáteční rozhodnutí, aby podřízené fáze běžely hladce.

Vývojový diagram popisující fázi 1, který se zaměřuje na plánování a rozhodování při vytváření řešení auditování na úrovni tenanta

Požadavky a priority

V počáteční fázi je cílem zjistit, co je nejdůležitější. Zaměřte se na to, co je nejdůležitější, a na tom, jak budete měřit dopad ve vaší organizaci. Snažte se definovat obchodní požadavky místo technologických požadavků.

Tady jsou některé otázky, na které byste měli odpovědět.

  • Na jaké klíčové otázky potřebujete odpovědět? Existuje velký objem dat auditování, která můžete prozkoumat. Nejúčinnějším způsobem, jak přistupovat k auditování, je zaměřit se na zodpovězení konkrétních otázek.
  • Jaké jsou vaše cíle přijetí a kultury dat? Možná máte například cíl zvýšit počet samoobslužných tvůrců obsahu BI v organizaci. V takovém případě budete muset měřit aktivity uživatelů související s vytvářením, úpravami a publikováním obsahu.
  • Jaká okamžitá rizika jsou přítomna? Můžete například vědět, že v minulosti došlo k nadměrnému sdílení obsahu. Uživatelská školení byla od té doby vylepšená a nyní chcete průběžně auditovat nastavení zabezpečení a aktivity.
  • Existují aktuální klíčové ukazatele výkonu (KPI) nebo organizační cíle? Možná máte například klíčový ukazatel výkonu organizace, který souvisí s digitální transformací nebo se stává organizací řízenou daty. Data auditování na úrovni tenanta vám můžou pomoct změřit, jestli je implementace Power BI v souladu s těmito cíli.

Tip

Ověřte požadavky na audit a nastavte priority s vaším vedoucím sponzorem a centrem excellence. Je lákavé extrahovat data auditování a začít vytvářet sestavy založené na mnoha zajímavých datech. Je ale nepravděpodobné, že byste z řešení auditování odvozovat vysokou hodnotu, pokud není řízena otázkami, na které potřebujete odpovědět, a akce, které máte v úmyslu provést.

Další informace o způsobech použití dat auditování najdete v tématu Přehled auditování a monitorování.

Kontrolní seznam – Při identifikaci požadavků a priorit patří klíčová rozhodnutí a akce:

  • Identifikace požadavků: Shromážděte a zdokumentujte klíčové obchodní požadavky pro auditování tenanta Power BI.
  • Stanovení priorit požadavků: Nastavte priority pro požadavky, klasifikujte je jako okamžité, krátkodobé, střednědobé a dlouhodobé (backlog).
  • Vytvořte plán pro okamžité priority: Vytvořte plán, abyste mohli začít shromažďovat data, aby byla dostupná, když je potřebujete.
  • Pravidelně reassess requirements: Create a plan to reassess requirements on a regular basis (například dvakrát za rok). Ověřte, jestli auditování a monitorování řešení splňuje stanovené požadavky. Podle potřeby aktualizujte položky akcí v plánu.

Potřeby na data

Jakmile definujete požadavky a priority (popsané výše), jste připraveni identifikovat data, která budete potřebovat. V této části jsou popsány čtyři kategorie dat.

Většina dat, která budete potřebovat, pochází z rozhraní API pro správu, která poskytují řadu metadat o tenantovi Power BI. Další informace najdete v části Volba uživatelského rozhraní API nebo rozhraní API pro správu dále v tomto článku.

Data o aktivitách uživatelů

Nastavte si jako první prioritu získání dat o aktivitách uživatelů. Aktivity uživatelů, které se také označují jako události nebo operace, jsou užitečné pro širokou škálu účelů.

Nejčastěji se tato data označují jako protokol aktivit nebo protokol událostí. Technicky vzato existuje několik způsobů, jak získat data o aktivitách uživatelů (protokol aktivit je jednou metodou). Další informace o rozhodnutích a aktivitách, které se týkají, najdete v části Přístup k datům o aktivitách uživatelů dále v tomto článku.

Tady je několik běžných otázek, na které můžou odpovědět data o aktivitách uživatelů.

  • Vyhledání nejlepších uživatelů a hlavního obsahu
    • Jaký obsah se zobrazuje nejčastěji a podle kterých uživatelů?
    • Jaké jsou denní, týdenní a měsíční trendy pro zobrazení obsahu?
    • Zobrazují se zobrazení sestavy v trendu nahoru nebo dolů?
    • Kolik uživatelů je aktivních?
  • Vysvětlení chování uživatelů
    • Jaký typ zabezpečení se nejčastěji používá (aplikace, pracovní prostory nebo sdílení jednotlivých položek)?
    • Používají uživatelé nejčastěji prohlížeče nebo mobilní aplikace?
    • Kteří tvůrci obsahu nejčastěji publikují a aktualizují obsah?
    • Jaký obsah se publikuje nebo aktualizuje, kdy a podle kterých uživatelů?
  • Identifikace příležitostí pro vzdělávání a školení uživatelů
    • Kdo sdílení z osobního pracovního prostoru (příliš mnoho)?
    • Kdo provádí značné množství exportu?
    • Kdo pravidelně stahuje obsah?
    • Kdo publikuje mnoho nových sémantických modelů– dříve označovaných jako datové sady?
    • Kdo používá předplatná hodně?
  • Zlepšení úsilí o zásady správného řízení a dodržování předpisů
    • Kdy se změní nastavení tenanta a podle kterého správce Power BI?
    • Kdo spustili zkušební verzi Power BI?
    • K jakému obsahu mají přístup externí uživatelé, kdo, kdy a jak?
    • Kdo přidání nebo aktualizace popisku citlivosti?
    • Jaké procento zobrazení sestavy vychází z certifikovaných sémantických modelů?
    • Jaké procento sémantických modelů podporuje více než jednu sestavu?
    • Kdy je brána nebo zdroj dat vytvořený nebo aktualizovaný a podle kterého uživatele?

Další informace ozpůsobch

Důležité

Pokud data aktivit uživatelů ještě extrahujete a neukládáte, udělejte to jako urgentní prioritu. Alespoň se ujistěte, že extrahujete nezpracovaná data a uložíte je do zabezpečeného umístění. Díky tomu budou data dostupná, až budete připraveni je analyzovat. Historie je dostupná po dobu 30 nebo 90 dnů v závislosti na používaném zdroji.

Další informace najdete v části Přístup k datům o aktivitách uživatelů dále v tomto článku.

Inventář tenanta

Druhou prioritou je často načtení dat pro vytvoření inventáře tenanta. Někdy se označuje jako inventář pracovního prostoru, metadata pracovního prostoru nebo metadata tenanta.

Inventář tenanta je snímek v daném časovém okamžiku. Popisuje, co je publikováno v tenantovi. Inventář tenanta neobsahuje skutečná data ani skutečné sestavy. Jedná se spíše o metadata, která popisují všechny pracovní prostory a jejich položky (například sémantické modely a sestavy).

Tady jsou některé běžné otázky, na které může inventář tenanta odpovědět.

  • Porozumíte tomu, kolik obsahu máte a kde
    • Které pracovní prostory mají největší obsah?
    • Jaký typ obsahu se publikuje v každém pracovním prostoru (zejména při oddělení pracovních prostorů sestav a datových pracovních prostorů)?
    • Jaké závislosti existují mezi položkami (například toky dat, které podporují mnoho sémantických modelů, nebo sémantický model, který je zdrojem pro jiné složené modely)?
    • Jaký je rodokmen dat (závislosti mezi položkami Power BI, včetně externích zdrojů dat)?
    • Existují osamocené sestavy (které jsou odpojené od sémantického modelu)?
  • Vysvětlení poměru sémantických modelů k sestavám
    • Kolik sémantických modelů se používá?
    • Existují duplicitní nebo velmi podobné sémantické modely?
    • Existují příležitosti ke konsolidaci sémantických modelů?
  • Principy trendů mezi body v čase
    • Zvyšuje se počet sestav v průběhu času?
    • Zvyšuje se počet sémantických modelů v průběhu času?
  • Vyhledání nepoužívaného obsahu
    • Které sestavy se nepoužívají (nebo jsou nevyužité)?
    • Které sémantické modely se nepoužívají (nebo nevyužité)?
    • Existují příležitosti k vyřazení obsahu?

Inventář tenanta vám pomůže při analýze historických aktivit používat aktuální názvy. Snímek položek ve vašem tenantovi obsahuje názvy všech položek v daném okamžiku. Pro historické vytváření sestav je užitečné použít názvy aktuálních položek. Pokud se například sestava přejmenovala před třemi měsíci, protokol aktivit v té době zaznamenává starý název sestavy. Pomocí správně definovaného datového modelu můžete pomocí nejnovějšího inventáře tenanta vyhledat položku podle aktuálního názvu (nikoli podle předchozího názvu). Další informace najdete v tématu Vytvoření datového modelu dále v tomto článku.

Další informace o způsobech použití inventáře tenanta najdete v tématu Vysvětlení publikovaného obsahu.

Tip

Často použijete kombinování událostí aktivity uživatelů (popsané v předchozí části) a inventáře tenanta k vytvoření kompletního obrázku. Tímto způsobem vylepšíte hodnotu všech dat.

Vzhledem k tomu, že inventář tenanta je snímek v daném časovém okamžiku, budete se muset rozhodnout, jak často se mají extrahovat a ukládat metadata. Týdenní snímek je užitečný pro porovnání mezi těmito dvěma body v čase. Pokud například chcete prozkoumat nastavení zabezpečení pracovního prostoru, budete potřebovat předchozí snímek inventáře tenanta, události protokolu aktivit a aktuální snímek inventáře tenanta.

Inventář tenanta můžete sestavit dvěma hlavními způsoby. Další informace o rozhodnutích a aktivitách, které se týkají, najdete v části Data inventáře tenanta Accessu dále v tomto článku.

Uživatelé a data skupin

S růstem analytických potřeb pravděpodobně zjistíte, že chcete do komplexního řešení auditování zahrnout data o uživatelích a skupinách. K načtení dat můžete použít Microsoft Graph, což je autoritativní zdroj informací o uživatelích a skupinách Microsoft Entra ID (dříve označované jako Azure Active Directory).

Data načtená z rozhraní REST API Power BI obsahují e-mailovou adresu pro popis uživatele nebo název skupiny zabezpečení. Tato data jsou snímkem v daném časovém okamžiku.

Tady jsou některé běžné otázky, na které může Microsoft Graph odpovědět.

  • Identifikace uživatelů a skupin
    • Jaké je celé uživatelské jméno (kromě e-mailové adresy), oddělení nebo umístění zdrojového z profilu uživatele?
    • Kdo jsou členy skupiny zabezpečení?
    • Kdo vlastník skupiny zabezpečení (pro správu členů)?
  • Získání dalších informací o uživateli
    • Které licence – Power BI Pro nebo Power BI Premium na uživatele (PPU) – jsou přiřazené uživatelům?
    • Kteří uživatelé se nejčastěji přihlašují ?
    • Kteří uživatelé se nedávno nepřihlásili k služba Power BI?

Upozorňující

Některé starší metody (které jsou široce zdokumentované online) pro přístup k datům uživatelů a skupin jsou zastaralé a neměly by se používat. Kdykoli je to možné, použijte Microsoft Graph jako autoritativní zdroj dat uživatelů a skupin.

Další informace a doporučení týkající se přístupu k datům z Microsoft Graphu najdete v části Přístup k datům uživatelů a skupin dále v tomto článku.

Data zabezpečení

Je možné, že budete potřebovat provádět pravidelné audity zabezpečení.

Tady jsou některé běžné otázky, na které můžou rozhraní REST API Power BI odpovědět.

  • Identifikace lidí a aplikací
    • Ke kterým sestavám má uživatel, skupina nebo instanční objekt přístup?
    • Kteří uživatelé, skupiny nebo instanční objekty mají odběratele dostávat sestavy s e-mailovým předplatným?
  • Vysvětlení oprávnění k obsahu
  • Vysvětlení dalších oprávnění

Důležité

Někdy se tento článek týká Power BI Premium nebo jejích předplatných kapacity (SKU P). Mějte na paměti, že Microsoft v současné době konsoliduje možnosti nákupu a vyřazuje Power BI Premium na skladové položky kapacity. Místo toho by měli noví a stávající zákazníci zvážit nákup předplatných kapacity Fabric (SKU F).

Další informace najdete v tématu Důležité aktualizace týkající se licencování Power BI Premium a nejčastějších dotazů k Power BI Premium.

Tip

Další informace o zabezpečení najdete v článcích o plánování zabezpečení.

Tyto běžné otázky nejsou vyčerpávajícím seznamem; k dispozici je široká škála rozhraní REST API Power BI. Další informace najdete v tématu Použití rozhraní REST API Power BI.

Další informace o používání rozhraní API pro správu a uživatelských rozhraní API (včetně toho, jak ovlivňuje oprávnění požadovaná pro uživatele, který extrahuje data), najdete v části Volba uživatelského rozhraní API nebo rozhraní API pro správu dále v tomto článku.

Kontrolní seznam – Při identifikaci dat potřebných k auditování patří klíčová rozhodnutí a akce:

  • Identifikace konkrétních potřeb dat o aktivitách uživatelů: Ověřte požadavky, které jste shromáždili. Určete, která data auditování jsou nezbytná ke splnění jednotlivých požadavků na data aktivit uživatelů.
  • Identifikace konkrétních potřeb dat inventáře tenanta: Ověřte požadavky, které jste shromáždili. Určete, která data auditování jsou nezbytná ke kompilaci inventáře tenanta.
  • Určení konkrétních potřeb dat pro uživatele a skupiny: Ověřte požadavky, které jste shromáždili. Určete, která data auditování jsou nezbytná ke splnění každého požadavku na data uživatelů a skupin.
  • Identifikace konkrétních potřeb dat zabezpečení: Ověřte požadavky, které jste shromáždili. Určete, která data auditování jsou nezbytná ke splnění jednotlivých požadavků na data zabezpečení.
  • Ověřte priority: Ověřte pořadí priorit, abyste věděli, co se má vytvořit jako první.
  • Rozhodněte se, jak často se mají zaznamenávat aktivity: Rozhodněte se, jak často se mají zaznamenávat události aktivit (například jednou denně).
  • Rozhodněte se, jak často se mají snímky zachytávat: Rozhodněte se, jaký interval se má zachytit data snímků, například inventář tenanta nebo data uživatelů a skupin.

Typ řešení auditování

Auditování na úrovni tenanta se provádí ručně nebo pomocí automatizovaných procesů.

Většina nových procesů auditování začíná jako ruční proces, zejména při vývoji a při testování. Proces ručního auditování se může vyvíjet tak, aby se stal automatizovaným procesem. Ne každý proces auditování ale musí být plně automatizovaný.

Ruční procesy auditování

Ruční auditování závisí na skriptech a procesech, které uživatel spouští na vyžádání (obvykle správce Power BI). V případě potřeby uživatel interaktivně spouští dotazy, aby načetl data auditování.

Ruční auditování je nejvhodnější pro:

  • Nové skripty, které se vyvíjejí a testují.
  • Občas je potřeba jednorázové auditování.
  • Požadavky na průzkumné auditování
  • Žádné procesy auditování, které nevyžadují úplnou podporu.

Automatizované procesy auditování

Auditování dat, která jsou potřeba opakovaně, by se měla automatizovat. Extrahuje se a zpracovává podle běžného plánu a označuje se jako automatizovaný proces. Někdy se označuje jako bezobslužný proces.

Cílem automatizovaného procesu je snížit ruční úsilí, snížit riziko chyb, zvýšit konzistenci a eliminovat závislost na jednotlivém uživateli, aby ho spustil.

Automatizované auditování je nejvhodnější pro:

  • Auditování procesů, které běží v produkčním prostředí
  • Bezobslužné procesy, které běží podle běžného plánu.
  • Skripty, které byly plně testovány.
  • Základní procesy auditování, které mají jiné sestavy (nebo jiné procesy), které na něm závisejí jako zdroj dat.
  • Procesy auditování, které jsou zdokumentované a podporované.

Typ procesu ( ručního nebo automatizovaného) může mít vliv na způsob zpracování ověřování. Například správce Power BI může pro ruční proces auditování použít ověřování uživatelů, ale pro automatizovaný proces použít instanční objekt. Další informace naleznete v tématu Určení metody ověřování dále v tomto článku.

Tip

Pokud existují běžná opakovaná data, je potřeba získat data auditování, která jsou aktuálně zpracována ručně, zvažte investice času na automatizaci. Pokud například správce Power BI každý den spustí skript, který načítá data z protokolu aktivit Power BI, hrozí riziko, že tato osoba bude na dovolené nemocná nebo pryč.

Kontrolní seznam – Při zvažování typu řešení auditování pro vývoj patří klíčová rozhodnutí a akce:

  • Určení primárního účelu pro každý nový požadavek auditování: Rozhodněte se, jestli se má pro každý nový požadavek použít ruční nebo automatizovaný proces. Zvažte, jestli je toto rozhodnutí dočasné nebo trvalé.
  • Vytvořte plán pro automatizaci: Pokud je to vhodné pro konkrétní požadavek na auditování, vytvořte plán, jak ho automatizovat, kdy a kým.

Oprávnění a odpovědnosti

V tomto okamžiku byste měli mít jasnou představu o tom, co chcete udělat, a data, která budete zpočátku potřebovat. Teď je vhodná doba k rozhodování o uživatelských oprávněních a rolích a zodpovědnostech.

Uživatelská oprávnění

Při vytváření komplexního řešení auditování zvažte uživatelská oprávnění pro ostatní uživatele, kteří budou potřebovat přístup k datům. Konkrétně se rozhodněte, kdo bude mít povolený přístup k datům auditování a zobrazit je.

Tady je několik aspektů, které je potřeba vzít v úvahu.

Přímý přístup k datům auditování

Měli byste se rozhodnout, kdo má přímý přístup k datům auditování. Existuje několik způsobů, jak se o tom zamyslet.

  • Kdo by měl být správcem Power BI? Správce Power BI má přístup ke všem metadatům tenanta, včetně rozhraní API pro správu. Další informace o rozhodování, kdo by měl být správcem Power BI, najdete v tématu Plánování zabezpečení na úrovni tenanta.
  • Kdo může použít existující instanční objekt? Pokud chcete pro přístup k datům auditování použít instanční objekt (místo uživatelských oprávnění), musí být autorizovaným uživatelům poskytnut tajný klíč, aby mohli provádět ověřování založené na heslech. Přístup k tajným kódům (a klíčům) by měl být velmi úzce řízený.
  • Musí být přístup přísně řízen? Některá odvětví s zákonnými požadavky a požadavky na dodržování předpisů musí řídit přístup těsněji než jiná odvětví.
  • Existují velké objemy dat aktivit? Abyste se vyhnuli dosažení limitů omezování rozhraní API, možná budete muset pečlivě řídit, kdo má povolený přímý přístup k rozhraním API, která vytvářejí data auditování. V tomto případě je užitečné zajistit, aby nedošlo k duplikování nebo překrývání.
Přístup k extrahovaným nezpracovaným datům

Měli byste se rozhodnout, kdo může zobrazit nezpracovaná data extrahovaná a zapsaná do umístění úložiště. Nejčastěji je přístup k nezpracovaných dat omezen na správce a auditory. Centrum efektivity (COE) může také vyžadovat přístup. Další informace najdete v tématu Určení, kam se mají data auditu ukládat dál v tomto článku.

Přístup ke kurátorovaným analytickým datům

Měli byste se rozhodnout, kdo může zobrazit kurátorovaná a transformovaná data, která jsou připravená k analýze. Tato data by měla být vždy zpřístupněna správcům a auditorům. Někdy je datový model zpřístupněn jiným uživatelům v organizaci, zejména při vytváření sémantického modelu Power BI se zabezpečením na úrovni řádků. Další informace najdete v tématu Plánování vytvoření kurátorovaných dat dále v tomto článku.

Role a odpovědnosti

Jakmile se rozhodnete, jak uživatelská oprávnění fungují, máte dobrou pozici, abyste mohli začít přemýšlet o rolích a zodpovědnostech. Doporučujeme, abyste v rané fázi zahrnovali správné lidi, zejména pokud se do vytváření kompletního řešení auditování zapojí více vývojářů nebo týmů.

Rozhodněte se, kteří uživatelé nebo tým budou zodpovědní za následující aktivity.

Role Typy odpovědností Role obvykle prováděná pomocí
Komunikace se zúčastněnými stranami Shromažďování komunikačních aktivit a požadavků COE ve spolupráci s IT. Může také zahrnovat výběr lidí z klíčových obchodních jednotek.
Rozhodování o prioritách a určení směru požadavků Rozhodovací aktivity související s komplexním řešením auditování, včetně toho, jak splnit požadavky. Tým, který dohlíží na Power BI v organizaci, jako je COE. Vedoucí sponzor nebo řídící výbor pro řízení dat by se mohl zapojit do důležitých rozhodnutí nebo eskalovat problémy.
Extrahování a ukládání nezpracovaných dat Vytváření skriptů a procesů pro přístup k datům a jejich extrahování Zahrnuje také zápis nezpracovaných dat do úložiště. Pracovníci přípravy dat, obvykle v OBLASTI IT a ve spolupráci s COE.
Vytvoření kurátorovaných dat Čištění, transformace a vytváření kurátorovaných dat v návrhu hvězdicového schématu Pracovníci přípravy dat, obvykle v OBLASTI IT a ve spolupráci s COE.
Vytvoření datového modelu Vytvoření analytického datového modelu založeného na kurátorovaných datech Tvůrci obsahu Power BI obvykle v IT nebo COE.
Vytváření analytických sestav Vytváření sestav pro analýzu kurátorovaných dat Průběžné změny sestav založených na nových požadavcích a dostupnosti nových dat auditování Tvůrci sestav Power BI obvykle v IT nebo COE.
Analýza dat a reakce na výsledky Analyzujte data a zareagujte na data auditu. Tým, který dohlíží na Power BI v organizaci, obvykle COE. V závislosti na výsledcích auditu a akci můžou zahrnovat i další týmy. Mezi další týmy patří zabezpečení, dodržování předpisů, právní, řízení rizik nebo správa změn.
Testování a ověření Otestujte, jestli jsou splněné požadavky na auditování a že jsou prezentovaná data přesná. Tvůrci obsahu Power BI ve spolupráci s týmem, který dohlíží na Power BI v organizaci.
Zabezpečení dat Nastavte a spravujte zabezpečení pro každou vrstvu úložiště, včetně nezpracovaných dat a kurátorovaných dat. Umožňuje spravovat přístup k sémantickým modelům vytvořeným pro analýzu dat. Správce systému pro systém, který ukládá data, ve spolupráci s týmem, který dohlíží na Power BI v organizaci.
Plánování a automatizace Zprovoznění řešení a naplánování procesu pomocí zvoleného nástroje Pracovníci přípravy dat, obvykle v OBLASTI IT a ve spolupráci s COE.
Podpora řešení Monitorujte řešení auditu, včetně spuštění úloh, chyb a podpory technických problémů. Tým, který zpracovává podporu systému Power BI, což je obvykle IT nebo COE.

Mnoho výše uvedených rolí a zodpovědností je možné konsolidovat, pokud je provede stejný tým nebo stejná osoba. Správci Power BI můžou například provádět některé z těchto rolí.

Je také možné, že různí lidé provádějí různé role v závislosti na okolnostech. Akce budou kontextové v závislosti na datech auditu a navrhované akci.

Zvažte několik příkladů.

  • Příklad 1: Data auditu ukazují, že někteří uživatelé často exportují data do Excelu. Podniknutá akce: COE kontaktuje konkrétní uživatele, aby porozuměli jejich potřebám a naučili je lepší alternativy.
  • Příklad 2: Data auditu ukazují, že přístup externího uživatele probíhá neočekávaně. Provedené akce: Správce IT systému aktualizuje příslušná nastavení ID Microsoft Entra pro přístup externího uživatele. Správce Power BI aktualizuje nastavení tenanta související s přístupem externího uživatele. CoE aktualizuje dokumentaci a školení pro tvůrce obsahu, kteří spravují zabezpečení. Další informace najdete v tématu Strategie pro externí uživatele.
  • Příklad 3: Data auditu ukazují, že několik datových modelů definuje stejnou míru jinak (k dispozici v rozhraních API pro kontrolu metadat, pokud je to povoleno podrobným nastavením tenanta metadat). Přijatá akce: Výbor pro zásady správného řízení dat zahájí projekt, který definuje společné definice. CoE aktualizuje dokumentaci a školení pro tvůrce obsahu, kteří vytvářejí datové modely. COE také pracuje s tvůrci obsahu a podle potřeby aktualizuje jejich modely. Další informace o načítání podrobných metadat najdete v tématu Data inventáře tenanta Accessu dále v tomto článku.

Poznámka:

Nastavení procesů extrakce dat je obvykle jednorázovým úsilím s občasnými vylepšeními a řešením potíží. Analýza a akce na datech je průběžné úsilí, které vyžaduje opakované úsilí.

Kontrolní seznam – Při zvažování oprávnění a zodpovědností zahrnují klíčová rozhodnutí a akce:

  • Určete, které týmy jsou zapojeny: Určete, které týmy budou zapojeny do kompletního vytváření a podpory řešení auditování.
  • Rozhodněte se o uživatelských oprávněních: Určete, jak budou uživatelská oprávnění nastavena pro přístup k datům auditu. Vytvořte dokumentaci klíčových rozhodnutí pro pozdější referenci.
  • Rozhodněte se o rolích a zodpovědnostech: Zajistěte, aby očekávání byla jasná pro toho, kdo co dělá, zejména pokud se účastní více týmů. Vytvořte dokumentaci pro role a odpovědnosti, která zahrnuje očekávané akce.
  • Přiřazení rolí a zodpovědností: Přiřaďte konkrétním lidem nebo týmům konkrétní role a zodpovědnosti. Podle potřeby aktualizujte popisy jednotlivých pracovních míst pomocí lidských zdrojů.
  • Vytvoření plánu školení: Vytvořte plán pro pracovníky školení, pokud vyžadují nové dovednosti.
  • Vytvořte plán křížového trénování: Ujistěte se, že jsou pro klíčové role zavedeny křížové trénování a zálohy.

Technická rozhodnutí

Při plánování řešení auditování na úrovni tenanta budete muset provést některá důležitá technická rozhodnutí. Pokud chcete zlepšit konzistenci, vyhněte se přepracování a vylepšete zabezpečení, doporučujeme, abyste tato rozhodnutí udělali co nejdříve.

První fáze plánování zahrnuje následující rozhodnutí.

Výběr technologie pro přístup k datům auditu

První věc, kterou musíte rozhodnout, je , jak získat přístup k datům auditu.

Nejjednodušší způsob, jak začít, je použít předem připravené sestavy dostupné v pracovním prostoru monitorování správce.

Pokud potřebujete přistupovat k datům přímo a vytvořit vlastní řešení, použijete rozhraní API (aplikační programové rozhraní). Rozhraní API jsou navržená k výměně dat přes internet. Rozhraní REST API Power BI podporují požadavky na data pomocí protokolu HTTP. Jakýkoli jazyk nebo nástroj může vyvolat rozhraní REST API Power BI, když dokáže odeslat požadavek HTTP a přijmout odpověď JSON.

Tip

Rutiny PowerShellu používají rozhraní REST API Power BI pro přístup k datům auditu. Další informace najdete v tématu Volba rozhraní API nebo rutin PowerShellu dále v tomto článku.

Tato část se zaměřuje na vaši volbu technologií. Informace o zdroji pro přístup ke konkrétním typům dat auditu najdete v části Rozhodnutí o zdroji dat dále v tomto článku.

Možnosti platformy

Existuje mnoho různých způsobů přístupu k datům auditu. V závislosti na zvolené technologii se můžete přiklonit k preferovanému jazyku. Možná budete také muset rozhodnout, jak naplánovat spouštění skriptů. Technologie se značně liší ve své křivkě učení a snadném zahájení práce.

Tady jsou některé technologie, které můžete použít k načtení dat pomocí rozhraní REST API Power BI.

Technologie Dobrá volba pro ruční procesy auditování Dobrá volba pro automatizované procesy auditování
pracovní prostor monitorování Správa Správa pracovní prostor monitorování je dobrou volbou pro ruční procesy auditování.
Vyzkoušet Try-it je dobrou volbou pro ruční auditování procesů.
PowerShell PowerShell je dobrou volbou pro ruční procesy auditování. PowerShell je dobrou volbou pro automatizované procesy auditování.
Power BI Desktop Power BI Desktop je dobrou volbou pro ruční procesy auditování.
Power Automate Power Automate je dobrou volbou pro automatizované procesy auditování.
Upřednostňovaná služba Azure Upřednostňovaná služba Azure je dobrou volbou pro automatizované procesy auditování.
Upřednostňovaný nástroj nebo jazyk Upřednostňovaný nástroj nebo jazyk je dobrou volbou pro ruční procesy auditování. Upřednostňovaný nástroj nebo jazyk je dobrou volbou pro automatizované procesy auditování.
Prohledávání protokolu auditování Microsoft Purview Hledání v protokolu auditu Microsoft Purview je dobrou volbou pro procesy ručního auditování.
Defender pro cloudové aplikace Defender for Cloud Apps je dobrou volbou pro ruční procesy auditování.
Microsoft Sentinel Microsoft Sentinel je dobrou volbou pro automatizované procesy auditování.

Zbývající část této části obsahuje stručný úvod ke každé z možností uvedených v tabulce.

pracovní prostor monitorování Správa

Pracovní prostor monitorování správce obsahuje předdefinované sestavy a sémantické modely v služba Power BI. Je to pohodlný způsob, jak správci prostředků infrastruktury a globální správci zobrazit nedávná data auditu a pomoct jim pochopit aktivity uživatelů.

Vyzkoušení v dokumentaci k rozhraní API

Try-it je interaktivní nástroj, který umožňuje vyzkoušet rozhraní REST API Power BI přímo v dokumentaci Microsoftu. Je to snadný způsob, jak prozkoumat rozhraní API, protože nevyžaduje jiné nástroje ani žádné nastavení na vašem počítači.

Try-it můžete použít k:

  • Ručně odešlete požadavek do rozhraní API, abyste zjistili, jestli vrací požadované informace.
  • Přečtěte si, jak se adresa URL vytvoří před napsáním skriptu.
  • Zkontrolujte data neformálním způsobem.

Poznámka:

Abyste mohli použít Try-it, musíte být licencovaný a ověřený uživatel Power BI. Řídí se standardním modelem oprávnění, což znamená, že uživatelská rozhraní API spoléhají na uživatelská oprávnění a rozhraní API pro správu vyžadují oprávnění správce Power BI. Pomocí instančního objektu se nemůžete ověřit pomocí try-it.

Protože je interaktivní, try-it je nejvhodnější pro učení, zkoumání a nové procesy ručního auditování.

PowerShell a Azure Cloud Shell

Skripty PowerShellu můžete vytvářet a spouštět několika způsoby.

Tady je několik běžných možností.

  • Visual Studio Code: Moderní jednoduchý editor zdrojového kódu. Je to volně dostupný opensourcový nástroj, který je podporovaný na několika platformách, včetně Windows, macOS a Linuxu. Visual Studio Code můžete používat s mnoha jazyky, včetně PowerShellu (pomocí rozšíření PowerShellu).
  • Azure Data Studio: Nástroj pro vytváření skriptů a poznámkových bloků Je založená na editoru Visual Studio Code. Azure Data Studio je k dispozici nezávisle nebo s APLIKACÍ SQL Server Management Studio (SSMS). Existuje mnoho rozšíření, včetně rozšíření pro PowerShell.
  • Azure Cloud Shell: Alternativa k práci s PowerShellem místně. Ke službě Azure Cloud Shell se dostanete z prohlížeče.
  • Azure Functions: Alternativa k práci s PowerShellem místně. Azure Functions je služba Azure, která umožňuje psát a spouštět kód v bezserverovém prostředí. PowerShell je jedním z několika jazyků, které podporuje.

Důležité

Pro všechny nové vývojové práce doporučujeme používat nejnovější verzi PowerShellu (PowerShell Core). Měli byste přestat používat Windows PowerShell (který nemůže spustit PowerShell Core) a místo toho použít některý z moderních editorů kódu, které podporují PowerShell Core. Při odkazech na řadu online příkladů, které používají Windows PowerShell (verze 5.1), je potřeba věnovat pozornost, protože nemusí používat nejnovější (a lepší) přístupy ke kódu.

PowerShell můžete použít několika různými způsoby. Další informace o tomto technickém rozhodnutí najdete v tématu Volba rozhraní API nebo rutin PowerShellu dále v tomto článku.

K dispozici je mnoho online prostředků pro použití PowerShellu a často je možné najít zkušené vývojáře, kteří můžou vytvářet a spravovat řešení PowerShellu. PowerShell je dobrou volbou pro vytváření ručních i automatizovaných procesů auditování.

Power BI Desktop

Vzhledem k tomu, že se Power BI Desktop může připojit k rozhraním API, může být lákavé ho použít k sestavení řešení auditování. Existují však některé významné nevýhody a složitosti.

  • Shromažďování historie: Vzhledem k tomu, že protokol aktivit Power BI poskytuje až 30 dnů dat, vytvoření celého řešení auditování zahrnuje shromáždění sady souborů v průběhu času, ve které se ukládají všechny historické události. Shromažďování historických souborů je jednodušší provádět s jinými nástroji.
  • Bezpečné zpracování přihlašovacích údajů a klíčů: Mnoho řešení, která najdete online od blogerů komunity, nejsou zabezpečená, protože v dotazech Power Query pevně zakódují přihlašovací údaje a klíče v prostém textu. I když je tento přístup snadný, nedoporučuje se, protože každý, kdo získá váš soubor Power BI Desktopu, může číst hodnoty. Heslo (při ověřování uživatele) ani tajný klíč (při použití instančního objektu) nemůžete bezpečně uložit v Power BI Desktopu, pokud:
    • Použijte vlastní konektor vyvinutý pomocí sady Power Query SDK. Vlastní konektor může například číst důvěrné hodnoty ze služby Azure Key Vault nebo jiné služby, která bezpečně ukládá zašifrovanou hodnotu. Existují také různé možnosti vlastního konektoru od globální komunity Power BI.
    • Použijte možnost ApiKeyName, která funguje dobře v Power BI Desktopu. Hodnotu klíče ale není možné uložit do služba Power BI.
  • Typy požadavků: U toho, co můžete spustit v Power BI Desktopu, můžete narazit na určitá omezení. Power Query například nepodporuje každý typ požadavku rozhraní API. Například při použití funkce Web.Contents se podporují pouze požadavky GET a POST. U auditování obvykle odesíláte požadavky GET.
  • Možnost aktualizace: Pokud chcete úspěšně aktualizovat sémantický model v služba Power BI, musíte postupovat podle konkrétních vývojových vzorů Power Query. Tato možnost musí být například RelativePath k dispozici při použití web.Contents, aby Power BI mohl správně ověřit umístění zdroje dat bez generování chyby v služba Power BI.

Ve většině případů doporučujeme používat Power BI Desktop jenom pro dva účely. Měli byste ho použít k:

  • Sestavte datový model založený na existujících kurátorovaných datech (místo toho, abyste ho používali k počátečnímu extrahování dat auditování).
  • Vytvářejte analytické sestavy založené na datovém modelu.
Power Automate

Power Automate můžete s Power BI používat mnoha způsoby. Pokud jde o auditování, můžete pomocí Power Automate odesílat požadavky do rozhraní REST API Power BI a následně ukládat extrahovaná data do umístění podle vašeho výběru.

Tip

Pokud chcete odesílat požadavky do rozhraní REST API Power BI, můžete k bezpečnému ověření a extrahování dat auditu použít vlastní konektor pro Power Automate. Alternativně můžete použít Azure Key Vault k odkazování na heslo nebo tajný klíč. Obě možnosti jsou lepší než ukládání hesel a tajných kódů ve formátu prostého textu v toku Power Automate.

Další nápady na způsoby použití Power Automate najdete v šablonách Power Automate v Power BI.

Upřednostňovaná služba Azure

Existuje několik služeb Azure, které můžou odesílat požadavky do rozhraní REST API Power BI. Můžete použít upřednostňovanou službu Azure, například:

Ve většině případů můžete kombinovat výpočetní službu, která zpracovává logiku pro extrakci dat pomocí služby úložiště, která ukládá nezpracovaná data (a kurátorovaná data, pokud je to vhodné). Aspekty rozhodování o technické architektuře jsou popsány dále v tomto článku.

Upřednostňovaný nástroj a/nebo jazyk

K odesílání požadavků do rozhraní REST API Power BI můžete použít preferovaný nástroj a upřednostňovaný jazyk. Je to dobrý přístup, když má váš tým zkušenosti s konkrétním nástrojem nebo jazykem, například:

  • Python
  • C# v rozhraní .NET Framework. Volitelně můžete použít sadu Power BI .NET SDK, která funguje jako obálka nad rozhraními REST API Power BI, aby se zjednodušily některé procesy a zvýšily produktivitu.
  • JavaScript

Portál dodržování předpisů Microsoft Purview (dříve Centrum dodržování předpisů Microsoftu 365) zahrnuje uživatelské rozhraní, které umožňuje zobrazit a prohledat protokoly auditu. Jednotné protokoly auditu zahrnují Power BI a všechny ostatní služby, které podporují jednotné protokoly auditu Microsoftu 365.

Data zachycená v jednotném protokolu auditu jsou přesně stejná data obsažená v protokolu aktivit Power BI. Když v Portál dodržování předpisů Microsoft Purview provedete prohledávání protokolu auditu, přidá se vaše žádost do fronty. Příprava dat může trvat několik minut (nebo déle, v závislosti na objemu dat).

Tady je několik běžných způsobů použití nástroje pro prohledávání protokolu auditování. Můžete provádět následující akce:

  • Výběrem úlohy Power BI zobrazíte události pro řadu kalendářních dat.
  • Vyhledejte jednu nebo více konkrétních aktivit, například:
    • Odstranění sestavy Power BI
    • Přidání přístupu správce k osobnímu pracovnímu prostoru v Power BI
  • Umožňuje zobrazit aktivity jednoho nebo více uživatelů.

Pro správce s dostatečnými oprávněními je nástroj pro vyhledávání protokolu auditování v Portál dodržování předpisů Microsoft Purview dobrou volbou pro ruční procesy auditování. Další informace najdete v části Portál dodržování předpisů Microsoft Purview dále v tomto článku.

Uživatelské rozhraní Defenderu for Cloud Apps

Defender for Cloud Apps je k dispozici správcům na portálu Microsoft Defender XDR (portál Microsoft 365). Zahrnuje uživatelské rozhraní pro zobrazení a vyhledávání protokolů aktivit pro různé cloudové služby, včetně Power BI. Zobrazuje stejné události protokolu, které pocházejí z Portál dodržování předpisů Microsoft Purview, kromě dalších událostí, jako je přihlašovací aktivita uživatele z Microsoft Entra ID.

Rozhraní protokolu auditu v Defenderu pro Cloud Apps je dobrou volbou pro ruční procesy auditování. Další informace najdete v části Defender for Cloud Apps dále v tomto článku.

Microsoft Sentinel a KQL

Microsoft Sentinel je služba Azure, která umožňuje shromažďovat, zjišťovat, zkoumat a reagovat na bezpečnostní incidenty a hrozby. Power BI je možné nastavit v Microsoft Sentinelu jako datový konektor, aby se protokoly auditu streamovaly z Power BI do Microsoft Sentinel Azure Log Analytics (což je součást služby Azure Monitor ). Pomocí dotazovací jazyk Kusto (KQL) můžete analyzovat události protokolu aktivit uložené ve službě Azure Log Analytics.

Použití KQL k prohledávání dat ve službě Azure Monitor je dobrou volbou pro zobrazení části protokolu auditu. Je to také dobrá možnost pro ruční procesy auditování. Další informace najdete v microsoft Sentinelu dále v tomto článku.

Aspekty platformy

Tady je několik důležitých informací o tom, jak můžete přistupovat k datům auditu.

  • Implementujete ruční nebo automatizovaný proces auditování? Některé nástroje silně odpovídají ručnímu zpracování nebo automatizovanému zpracování. Uživatel například vždy spouští funkci Try-it interaktivně, takže se hodí jenom pro ruční procesy auditování.
  • Jak se ověří? Ne všechny možnosti podporují všechny možnosti ověřování. Funkce Try-it například podporuje pouze ověřování uživatelů.
  • Jak bezpečně uložíte přihlašovací údaje? Různé technologie mají různé možnosti ukládání přihlašovacích údajů. Další informace naleznete v tématu Určení metody ověřování dále v tomto článku.
  • S jakou technologií už váš tým pracuje? Pokud je k dispozici nástroj, který váš tým preferuje a je pohodlný, začněte tam.
  • Co je váš tým schopný podporovat? Pokud nasazené řešení bude podporovat jiný tým, zvažte, jestli je tento tým schopný ho adekvátně podporovat. Vezměte také v úvahu, že interní týmy můžou podporovat vývoj, který provádějí konzultanti.
  • Jaký nástroj máte ke schválení použít? Některé nástroje a technologie mohou vyžadovat schválení. Příčinou můžou být náklady. Příčinou můžou být také zásady zabezpečení IT.
  • Jaká je vaše předvolba pro plánování? Některé technologie pro vás dělají rozhodnutí. Jindy to bude další rozhodnutí, které musíte udělat. Pokud se například rozhodnete psát skripty PowerShellu, můžete je naplánovat různými způsoby. Naopak pokud používáte cloudovou službu, jako je Azure Data Factory, je plánování integrované.

Než zvolíte technologii pro přístup k datům auditu, doporučujeme projít si zbývající část tohoto článku.

Kontrolní seznam – Při rozhodování o tom, kterou technologii použít pro přístup k datům auditu, patří klíčová rozhodnutí a akce:

  • Prodiskutujte s pracovníky IT: Obraťte se na it týmy a zjistěte, jestli existují určité nástroje, které jsou schválené nebo preferované.
  • Prozkoumejte možnosti s malým testováním konceptu (POC): Experimentujte s technickým POC. Nejprve se zaměřte na učení. Pak se zaměřte na vaše rozhodnutí, co se má dál používat.

Určení metody ověřování

Jak plánujete nastavit ověřování, je důležité rozhodnutí. Často se jedná o jeden z nejobtížnějších aspektů, když začnete s auditováním a monitorováním. Měli byste pečlivě zvážit dostupné možnosti pro informované rozhodnutí.

Důležité

V této věci se obraťte na it a bezpečnostní týmy. Chvíli se seznamte se základy toho, jak funguje zabezpečení v Microsoft Entra ID.

Ne každé rozhraní API na internetu vyžaduje ověření. Všechna rozhraní REST API Power BI ale vyžadují ověřování. Při přístupu k datům auditování na úrovni tenanta se proces ověřování spravuje platformou Microsoft Identity Platform. Je to vývoj služby Microsoft Entra identity, která je založená na standardních protokolech odvětví.

Tip

Glosář termínů platformy Microsoft Identity Platform je prostředek, který vám pomůže seznámit se se základními koncepty.

Před načtením dat auditu je nutné nejprve ověřit, což se označuje jako přihlášení. Koncepty ověřování a autorizace jsou oddělené, ale souvisí. Proces ověřování ověřuje identitu, která žádost provádí. Proces autorizace uděluje (nebo zakazuje) přístup k systému nebo prostředku tím, že ověří, k čemu má uživatel nebo instanční objekt oprávnění.

Když se uživatel nebo instanční objekt ověří, vydá se přístupový token Microsoft Entra na server prostředků, jako je rozhraní REST API Power BI nebo rozhraní Microsoft Graph API. Ve výchozím nastavení vyprší platnost přístupového tokenu po jedné hodině. V případě potřeby je možné požádat o obnovovací token.

Existují dva typy přístupových tokenů:

  • Tokeny uživatele: Vydáno jménem uživatele se známou identitou.
  • Tokeny pouze pro aplikace: Vydáno jménem aplikace Microsoft Entra (instanční objekt).

Další informace naleznete v tématu Aplikace a instanční objekty v Microsoft Entra ID.

Poznámka:

Aplikace Microsoft Entra je konfigurace identity, která umožňuje automatizovanému procesu integrovat se službou Microsoft Entra ID. V tomto článku se označuje jako registrace aplikace. Instanční objekt se také běžně používá v tomto článku. Tyto termíny jsou podrobněji popsány dále v této části.

Tip

Nejjednodušší způsob, jak provést ověření, je použít rutinu Připojení-PowerBIServiceAccount z modulu správy Power BI. Další rutiny související s ověřováním se můžou zobrazit v článcích a blogových příspěvcích online. Existují například Login-PowerBI rutiny a Login-PowerBIServiceAccount aliasy pro Connect-PowerBIServiceAccount rutiny. K dispozici je také rutina Disconnect-PowerBIServiceAccount , pomocí které se můžete explicitně odhlásit na konci procesu.

Následující tabulka popisuje dvě možnosti ověřování.

Typ ověřování Popis Určeno pro Dobrá volba pro ruční procesy auditování Dobrá volba pro automatizované procesy auditování
Ověřování uživatele Přihlaste se jako uživatel pomocí hlavního názvu uživatele (e-mailové adresy) a hesla. Občasné interaktivní použití Ověřování uživatelů je dobrou volbou pro ruční procesy auditování.
Ověřování instančního objektu Přihlaste se jako instanční objekt pomocí tajného kódu (klíče) přiřazeného k registraci aplikace. Probíhající, naplánované, bezobslužné operace Ověřování instančního objektu je dobrou volbou pro automatizované procesy auditování.

Jednotlivé možnosti ověřování jsou podrobněji popsány v následující části.

Ověřování uživatele

Ověřování uživatelů je užitečné v následujících situacích.

  • Procesy ručního auditování: Chcete spustit skript pomocí uživatelských oprávnění. Oprávnění můžou být na jedné ze dvou úrovní v závislosti na typu požadavku rozhraní API:
    • oprávnění Správa istrator pro rozhraní API pro správu: K odeslání žádosti do rozhraní API pro správu musíte použít oprávnění správce Power BI.
    • Uživatelská oprávnění pro uživatelská rozhraní API: K odeslání požadavku do uživatelského rozhraní API musíte použít uživatelská oprávnění Power BI. Další informace najdete v tématu Volba uživatelského rozhraní API nebo rozhraní API pro správu.
  • Interaktivní přihlášení: Chcete se přihlásit interaktivně, což vyžaduje zadání e-mailové adresy a hesla. Například se musíte interaktivně přihlásit, abyste mohli používat prostředí Try-it , které najdete v dokumentaci k rozhraní MICROSOFT API.
  • Sledovat, kdo přistupoval k metadatům tenanta: Když jednotliví uživatelé a správci odesílají požadavky rozhraní API, můžete chtít auditovat, kdo jsou tito jednotlivci. Při ověřování pomocí instančního objektu (popsaného dále) je ID uživatele zachycené protokolem aktivit ID aplikace. Pokud se pomocí stejného instančního objektu ověřuje více správců, může být obtížné zjistit, který správce k datům přistupoval.
  • Sdílený účet správce: Některé IT týmy používají sdílený účet správce. V závislosti na tom, jak se implementuje a řídí, nemusí být osvědčeným postupem. Místo sdíleného účtu byste měli zvážit použití služby Microsoft Entra Privileged Identity Management (PIM), která může uživateli udělit občasná a dočasná práva správce Power BI.
  • Rozhraní API, která podporují pouze ověřování uživatelů: Občas budete muset použít rozhraní API, které nepodporuje ověřování instančním objektem. V dokumentaci každé rozhraní API zjistíte, jestli ho instanční objekt může volat.

Důležité

Kdykoli je to možné, doporučujeme pro automatizované procesy použít ověřování instančního objektu.

Ověřování instančního objektu

Většina organizací má jednoho tenanta Microsoft Entra, takže termíny registrace aplikace a instanční objekt se obvykle používají zaměnitelně. Při registraci aplikace Microsoft Entra existují dvě komponenty.

  • Registrace aplikace:Registrace aplikace je globálně jedinečná. Jedná se o globální definici registrované aplikace Microsoft Entra, kterou může používat více tenantů. Registrace aplikace se také označuje jako klientská aplikace nebo objekt actor. Termín klientská aplikace obvykle znamená uživatelský počítač. To ale není situace pro registrace aplikací. Na webu Azure Portal najdete aplikace Microsoft Entra na stránce Registrace aplikací v Microsoft Entra ID.
  • Instanční objekt:Instanční objekt je místní reprezentace registrace aplikace pro použití ve vašem konkrétním tenantovi. Instanční objekt je odvozený od registrované aplikace Microsoft Entra. Pro organizace s více tenanty Microsoft Entra může na stejnou registraci aplikace odkazovat více než jeden instanční objekt. Na webu Azure Portal najdete instanční objekty na stránce Podnikové aplikace v Microsoft Entra ID.

Vzhledem k tomu, že instanční objekt je místní reprezentace, představuje ověřování instančního objektu nejběžnější způsob, jak odkazovat na přihlášení.

Tip

Váš správce Microsoft Entra vám může sdělit, kdo může vytvořit a udělit souhlas s registrací aplikace ve vaší organizaci.

Ověřování instančního objektu je užitečné v následujících situacích.

  • Automatizované procesy auditování: Chcete spustit bezobslužný proces podle plánu.
  • K služba Power BI se nemusíte přihlašovat: Stačí se připojit a extrahovat data. Instanční objekt se nemůže přihlásit k služba Power BI.
  • Sdílený přístup k datům: Vy (osobně) nejste správcem Power BI, ale máte oprávnění používat instanční objekt. Instanční objekt má oprávnění ke spouštění rozhraní API pro správu k načtení dat na úrovni tenanta (nebo jiných konkrétních oprávnění).
  • Použijte více správců: Chcete povolit více správcům nebo uživatelům používat stejný instanční objekt.
  • Technické blokování: Existuje technický blok, který brání použití ověřování uživatelů. Mezi běžné technické překážky patří:
    • Vícefaktorové ověřování (MFA): Automatizované procesy auditování (bezobslužné) se nedají ověřit pomocí uživatelského účtu, pokud je povolené vícefaktorové ověřování.
    • Synchronizace hodnot hash hesel: Microsoft Entra ID vyžaduje synchronizaci hodnot hash hesel pro ověření uživatelského účtu. Někdy může IT nebo tým kybernetické bezpečnosti tuto funkci zakázat.
Účel registrace aplikace a zásady vytváření názvů

Každá registrace aplikace by měla mít jasný název, který popisuje jeho účel a cílovou skupinu (která může registraci aplikace používat).

Zvažte implementaci konvence vytváření názvů, například: <Úloha> – <Účel> – <Cílová cílová skupina> – <Typ objektu>

Tady jsou části konvence vytváření názvů.

  • Úloha: Obvykle odpovídá zdroji dat (například datům Power BI nebo datům Microsoft Graphu).
  • Účel: Podobá se úrovni oprávnění (například Read versus ReadWrite). Jak je popsáno níže, účel vám pomůže dodržovat zásadu nejnižších oprávnění při vytváření samostatných registrací aplikací, které můžou číst pouze data.
  • Cílová skupina: Nepovinná. V závislosti na úloze a účelu vám cílová skupina umožňuje určit zamýšlené uživatele registrace aplikace.
  • Typ objektu:EntraApp je zahrnuta pro přehlednost.

Zásady vytváření názvů můžou být konkrétnější, pokud máte více tenantů nebo více prostředí (například vývoj a produkční prostředí).

Následující tabulka uvádí příklady registrací aplikací, které je možné použít k extrakci dat auditování na úrovni tenanta:

Název registrace aplikace Účel Cílovou skupinu
PowerBIData-Read-Správa APIs-EntraApp Extrahujte metadata celého tenanta pro auditování a správu Power BI. Správa rozhraní API jsou vždy jen pro čtení a nemusí mít udělená oprávnění v Microsoft Entra ID (pouze nastavení tenanta Power BI). Správci Power BI a Center of Excellence
PowerBIData-ReadWrite-PowerBI Správa istrators-EntraApp Správa tenanta Power BI K vytvoření nebo aktualizaci prostředků vyžaduje oprávnění ke čtení a zápisu. Správci Power BI a Center of Excellence
GraphData-Read-PowerBI Správa istrators-EntraApp Extrahujte data uživatelů a skupin pro auditování a správu Power BI. Vyžaduje oprávnění ke čtení. Správci Power BI a Center of Excellence

Správa více registrací aplikací pro různé účely zahrnuje větší úsilí. Můžete ale těžit z několika výhod.

  • Podívejte se, k čemu je registrace aplikace určená a proč: Když se v datech auditování zobrazí ID klienta z registrace aplikace, budete mít představu o tom, k čemu byla použita a proč. To je významná výhoda při vytváření samostatných registrací aplikací (místo použití jenom jedné pro všechny účely).
  • Zjistěte, kdo má registraci aplikace používat: Když se v datech auditování zobrazí ID klienta z registrace aplikace, budete mít představu o tom, kdo ji používal.
  • Vyhněte se nadměrnému zřízení oprávnění: Můžete postupovat podle principu nejnižších oprávnění tím, že poskytnete samostatné registrace aplikací různým sadám lidí, kteří mají různé potřeby. Pokud oprávnění k zápisu nepotřebujete, můžete se vyhnout nadměrnému zřízení oprávnění pomocí registrace aplikace jen pro čtení. Můžete mít například některé vysoce schopné samoobslužné uživatele, kteří chtějí shromažďovat data o jejich sémantických modelech; potřebují přístup k instančnímu objektu s oprávněním ke čtení . vzhledem k tomu, že pro finanční tým, který programově spravuje sémantické modely, mohou existovat satelitní členové Centra efektivity; potřebují přístup k instančnímu objektu s oprávněním k zápisu .
  • Vědět, kdo by měl mít tajný kód: Tajný kód pro každou registraci aplikace by se měl sdílet jenom s lidmi, kteří ho potřebují. Při obměně tajného kódu (popsaného dále v této části) je dopad menší, když použijete samostatné registrace aplikací pro různé potřeby. To je užitečné, když potřebujete tajný kód otočit, protože uživatel opustí organizaci nebo změní role.
Oprávnění registrace aplikací

Existují dva hlavní způsoby, jak může registrace aplikace přistupovat k datům a prostředkům. Zahrnuje oprávnění a souhlas.

  • Oprávnění pouze pro aplikace: Přístup a autorizace zpracovává instanční objekt bez přihlášeného uživatele. Tato metoda ověřování je užitečná pro scénáře automatizace. Při použití oprávnění jen pro aplikace je důležité pochopit, že oprávnění nejsou přiřazená v MICROSOFT Entra ID. Oprávnění se přiřazují jedním ze dvou způsobů:
    • Pro spouštění rozhraní API pro správu: Určitá nastavení tenanta Power BI umožňují přístup ke koncovým bodům pro rozhraní API pro správu (které vracejí metadata auditování v rámci celého tenanta). Další informace najdete v tématu Nastavení tenanta Power BI dále v tomto článku.
    • Pro spouštění uživatelských rozhraní API platí oprávnění k pracovnímu prostoru Power BI a položkám. Standardní oprávnění Power BI určují, jaká data se dají vrátit do instančního objektu při spouštění uživatelských rozhraní API (které vracejí data auditování na základě oprávnění uživatele nebo instančního objektu, který vyvolává rozhraní API).
  • Delegovaná oprávnění: Používají se oprávnění založená na oboru. Instanční objekt přistupuje k datům jménem uživatele, který je aktuálně přihlášený. Znamená to, že instanční objekt nemá přístup k ničemu nad rámec toho, k čemu má přihlášený uživatel přístup. Mějte na paměti, že se jedná o jiný koncept než ověřování pouze uživatelem, které jsme popsali dříve. Vzhledem k tomu, že se ke správnému zpracování kombinace uživatelských a aplikačních oprávnění vyžaduje vlastní aplikace, delegovaná oprávnění se zřídka používají pro scénáře auditování. Tento koncept je běžně nepochopený, což vede k mnoha registracím aplikací, které jsou nadměrně zřízenými oprávněními.

Důležité

V tomto článku je fokus pouze na ověřování uživatelů nebo ověřování jen pro aplikace. Delegovaná oprávnění (s interaktivním uživatelem a instančním objektem) můžou hrát důležitou roli při programovém vkládání obsahu Power BI. Důrazně vás ale nedoporučujeme nastavit delegovaná oprávnění pro extrahování dat auditování. Každé rozhraní API omezuje, jak často se dá spouštět (s omezováním), takže není praktické mít různé uživatele přímo přistupující k nezpracovaným datům auditu. Místo toho doporučujeme extrahovat nezpracovaná data auditu jednou (s centralizovaným procesem) a pak zpřístupnit kurátorovaná data auditu oprávněným uživatelům v podřízené části.

Další informace najdete v části Registrace aplikace Microsoft Entra dále v tomto článku.

Tajné kódy registrace aplikací

Registrace aplikace má často přiřazený tajný kód . Tajný klíč se používá jako klíč pro ověřování a má datum vypršení platnosti. Proto je potřeba naplánovat, jak klíč pravidelně obměňovat a jak informovat o novém klíči autorizovaným uživatelům.

Musíte se také zabývat tím, kde bezpečně uložit tajný kód. Trezor hesel organizace, například Azure Key Vault, je skvělou volbou.

Tip

Jako alternativní přístup k používání tajného kódu můžete použít spravovanou identitu. Spravovaná identita eliminuje potřebu spravovat přihlašovací údaje. Pokud chcete k extrakci dat použít služby, jako jsou Azure Functions nebo Azure Data Factory, je vhodná možnost prošetřit spravovanou identitu.

Zabezpečená správa přihlašovacích údajů

Bez ohledu na to, jestli používáte ověřování uživatelů nebo ověřování instančního objektu, je jedním z největších problémů způsob bezpečné správy hesel, tajných kódů a klíčů.

Upozornění

První pravidlo je pravidlo, které mnoho lidí porušuje: hesla a klíče by se ve skriptu nikdy neměly zobrazovat ve formátu prostého textu. Mnohočlánkůch Je to ale špatný postup, kterému byste se měli vyhnout. Každý, kdo získá skript (nebo soubor), může potenciálně získat přístup ke stejným datům, ke kterým má autor přístup.

Tady je několik bezpečných metod, které můžete použít ke správě hesel, tajných kódů a klíčů.

  • Integrace se službou Azure Key Vault nebo jiným systémem trezoru hesel organizace, kdykoli je to možné.
  • Ve skriptech PowerShellu používejte přihlašovací údaje a zabezpečené řetězce. Přihlašovací údaje fungují pro ověřování uživatelů i ověřování instančního objektu. Přihlašovací údaje ale nemůžete použít, pokud je pro uživatelský účet povolené vícefaktorové ověřování.
  • Výzva k zadání hesla ve skriptu PowerShellu nebo použití interaktivního ověřování v prohlížeči
  • Použijte modul Správa tajných kódů pro PowerShell, který publikoval Microsoft. Může ukládat hodnoty pomocí místního trezoru. Může se také integrovat se vzdáleným trezorem klíčů Azure Key Vault, což je užitečné, když ve vaší organizaci existuje více správců, kteří pracují se stejnými skripty.
  • Vytvořte vlastní konektor pro Power BI Desktop, aby mohl bezpečně zpracovávat přihlašovací údaje. Některé vlastní konektory jsou dostupné od členů komunity (obvykle na GitHubu).

Tip

Doporučujeme, abyste se s it týmy a týmy zabezpečení poradili, abyste zvolili nejlepší metodu nebo ověřili, že vaše řešení spravuje přihlašovací údaje zabezpečeným způsobem.

Identity a ověřování Microsoftu

Podpora knihovny Azure AD Authentication Library (ADAL) skončila v prosinci 2022. V budoucnu byste měli použít knihovnu Microsoft Authentication Library (MSAL). Bezpečnostní tým ve vaší organizaci by měl být obeznámen s touto významnou změnou.

I když není pro odborníky v Power BI důležité, aby důkladně porozuměli přechodu na MSAL, měli byste dodržovat následující doporučení.

  • Při ověřování pomocí rutiny powershellu Připojení-PowerBIServiceAccount použijte nejnovější verzi modulu Pro správu Power BI. Přepnul z knihovny ADAL na MSAL ve verzi 1.0.946 (26. února 2021).
  • Koncový bod Microsoft Entra V2 použijte při ověřování přímo ve skriptu. Koncový bod Microsoft Entra V2 používá knihovnu MSAL, zatímco koncový bod Microsoft Entra V1 používá knihovnu ADAL.
  • Ukončete používání rozhraní API a modulů, které jsou zastaralé. Další informace najdete v tématu Zastaralé rozhraní API a moduly dále v tomto článku.
  • Pokud najdete komunitní řešení online, ujistěte se, že místo knihovny ADAL používá knihovnu MSAL k ověřování.

Kontrolní seznam – Při rozhodování o správě ověřování patří klíčová rozhodnutí a akce:

  • Rozhodněte se, jaký typ ověřování se má použít: Určete, jestli je nejvhodnější ověřování uživatelů nebo ověřování instančního objektu v závislosti na typu řešení auditování, které plánujete vytvořit.
  • Naplánujte, jaké registrace aplikací potřebujete: Zvažte své požadavky, úlohy a cílovou skupinu (uživatelé každé registrace aplikace). Naplánujte, kolik registrací aplikací potřebujete k podpoře těchto potřeb.
  • Vytvoření konvence vytváření názvů pro registrace aplikací: Nastavte konvenci vytváření názvů, která usnadňuje pochopení zamýšleného účelu a zamýšlených uživatelů každé registrace aplikace.
  • Naplánujte, jak bezpečně spravovat přihlašovací údaje: Zvažte způsoby bezpečné správy hesel, tajných kódů a klíčů. Zvažte, jaká dokumentace a školení můžou být nezbytné.
  • Potvrďte použití knihovny MSAL: Určete, jestli existují nějaká řešení ručního nebo automatizovaného auditování, která spoléhají na knihovnu ADAL. V případě potřeby vytvořte plán pro přepsání těchto řešení tak, aby používala novější knihovnu ověřování MSAL.

Volba uživatelského rozhraní API nebo rozhraní API pro správu

Při plánování načítání dat auditování je důležité použít správný typ rozhraní API.

Je potřeba zvážit dva typy rozhraní API.

  • Uživatelská rozhraní API: Při odesílání požadavků do rozhraní API se spoléhají na oprávnění přihlášeného uživatele (nebo instančního objektu). Jedním ze způsobů, jak například vrátit seznam sémantických modelů v pracovním prostoru, je s uživatelským rozhraním API. Oprávnění ke čtení sémantických modelů je možné udělit buď rolí pracovního prostoru, nebo oprávněními pro jednotlivé položky. Existují dva způsoby spouštění uživatelských rozhraní API:
    • Ověřování uživatele: Přihlášený uživatel musí mít oprávnění pro přístup k pracovnímu prostoru nebo položce.
    • Ověřování instančního objektu: Instanční objekt musí mít oprávnění pro přístup k pracovnímu prostoru nebo položce.
  • rozhraní API Správa: Načtěte metadata z tenanta. Někdy se označuje jako obor organizace. Pokud například chcete vrátit seznam všech sémantických modelů v tenantovi, použijete rozhraní API pro správu. Rozhraní API pro správu můžete spustit dvěma způsoby:
    • Ověřování uživatele: Přihlášený uživatel musí být správcem Power BI, aby bylo možné spouštět rozhraní API pro správu.
    • Ověřování instančního objektu: Instanční objekt musí mít oprávnění ke spouštění rozhraní API pro správu (bez nutnosti spoléhat se na oprávnění zabezpečení, jako je uživatelské rozhraní API).

Tip

Všechna rozhraní API pro správu patří do skupiny operací Správa. Jakékoli rozhraní API, které má příponu As Správa, je rozhraní API pro správu. Všechna zbývající rozhraní API jsou uživatelská rozhraní API.

Představte si příklad, ve kterém potřebujete získat seznam sémantických modelů. V následující tabulce je uvedeno šest možností rozhraní API, které můžete použít k tomu. Čtyři možnosti jsou uživatelská rozhraní API a dvě možnosti jsou rozhraní API pro správu. Rozsah a počet vrácených položek se liší v závislosti na zvoleném rozhraní API.

Název rozhraní API Typ rozhraní API Scope Počet sémantických modelů
Získání datové sady Uživatelská Osobní pracovní prostor Jeden
Získání datových sad Uživatelská Osobní pracovní prostor Všechny
Získání datové sady ve skupině Uživatelská Jeden pracovní prostor Jedno, pokud má přihlášený uživatel oprávnění ke čtení sémantického modelu
Získání datových sad ve skupině Uživatelská Jeden pracovní prostor Vše, pokud má přihlášený uživatel oprávnění ke čtení každého sémantického modelu
Získání datových sad ve skupině jako Správa správce Jeden pracovní prostor Všechny
Získání datových sad jako Správa správce Celý tenant Všechny

Poznámka:

Mezi názvy rozhraní API patří termín Skupina jako odkaz na pracovní prostor. Tento termín pochází z původního modelu zabezpečení Power BI, který spoléhal na skupiny Microsoftu 365. I když se model zabezpečení Power BI v průběhu let výrazně vyvinul, stávající názvy rozhraní API zůstanou beze změny, aby nedocházelo k přerušení stávajících řešení.

Informace o nastavení tenanta najdete v části Nastavení tenanta Power BI dále v tomto článku.

Kontrolní seznam – Při volbě, jestli se má použít uživatelské rozhraní API nebo rozhraní API pro správu, zahrnují klíčová rozhodnutí a akce:

  • Projděte si požadavky na data: Shromážděte a zdokumentujte klíčové obchodní požadavky pro řešení auditování. Na základě typu potřebných dat určete, jestli je obor uživatele nebo obor organizace vhodný.
  • Otestujte výsledky: Proveďte nějaké experimentování. Otestujte přesnost výsledků vrácených různými rozhraními API.
  • Kontrola oprávnění: U všech existujících řešení auditování ověřte, že jsou oprávnění správně přiřazená správcům a instančním objektům Power BI. U nových řešení auditování ověřte, jakou metodu ověřování se použije.

Volba rozhraní API nebo rutin PowerShellu

Klíčovým rozhodnutím je, jestli použít rutiny PowerShellu, když jsou dostupné pro konkrétní data, která chcete načíst. Toto rozhodnutí je důležité, pokud jste se rozhodli, že PowerShell je jednou z technologií, které použijete pro přístup k datům auditu.

PowerShell je řešení automatizace úloh. Pojem PowerShell je souhrnný termín, který odkazuje na skriptovací jazyk, aplikaci příkazového řádku a architekturu pro správu konfigurace. PowerShell Core je nejnovější verze PowerShellu, která běží ve Windows, Linuxu a macOS.

Rutina PowerShellu je příkaz, který provede akci. Modul PowerShellu je balíček, který obsahuje členy PowerShellu, jako jsou rutiny, poskytovatelé, funkce, pracovní postupy, proměnné a aliasy. Stáhnete a nainstalujete moduly.

Modul PowerShellu vytvoří vrstvu abstrakce přes rozhraní API. Například rutina Get-PowerBIActivityEvent načte (nebo získá) události auditu pro tenanta Power BI. Tato rutina PowerShellu načte data z rozhraní REST API Get Activity Events . Obecně je jednodušší začít používat rutiny, protože zjednodušuje přístup k podkladovým rozhraním API.

Jako rutiny PowerShellu jsou k dispozici pouze podmnožina rozhraní API. S tím, jak budete dál rozšiřovat celé řešení auditování, je pravděpodobné, že budete používat kombinaci rutin a rozhraní API. Zbývající část této části vám pomůže rozhodnout se, jakým způsobem budete přistupovat k datům.

Moduly PowerShellu

Microsoft publikoval dva moduly PowerShellu, které obsahují rutiny související s Power BI. Jedná se o modul správy Power BI a modul Brány dat. Tyto moduly PowerShellu fungují jako obálka rozhraní API nad podkladovými rozhraními REST API Power BI. Použití těchto modulů PowerShellu může usnadnit psaní skriptů.

Tip

Kromě modulů publikovaných Microsoftem jsou volně dostupné moduly a skripty PowerShellu publikované (obvykle na GitHubu) členy komunity Power BI, partnery a specialisty Microsoftu pro většinu hodnotných odborníků (MVP).

Počínaje komunitním řešením může hrát důležitou roli při vytváření kompletního řešení auditování. Pokud se rozhodnete použít volně dostupné řešení, nezapomeňte ho plně otestovat. Seznamte se s tím, jak funguje, abyste mohli efektivně spravovat řešení v průběhu času. Vaše IT oddělení může mít kritéria pro používání veřejně dostupných komunitních řešení.

Modul Správy Power BI

Modul Správy Power BI je souhrnný modul, který obsahuje konkrétní moduly Power BI pro správu, kapacity, pracovní prostory a další. Pokud chcete získat všechny moduly, můžete nainstalovat kumulativní modul nebo můžete nainstalovat konkrétní moduly. Všechny moduly pro správu Power BI jsou podporované v prostředí Windows PowerShell i PowerShell Core.

Důležité

Doporučujeme ukončit používání Prostředí Windows PowerShell (které nemůže spustit PowerShell Core). Místo toho použijte jeden z moderních editorů kódu, které podporují PowerShell Core. Integrované skriptovací prostředí (ISE) windows PowerShellu je schopné používat jenom PowerShell verze 5.1, která se už neaktualizuje. Windows PowerShell je teď zastaralý, proto doporučujeme používat PowerShell Core pro všechny nové vývojové práce.

Tady je několik běžně používaných rutin, které můžete použít k načtení dat auditování.

Modul pro správu Rutina Účel
Profil Připojení-PowerBIServiceAccount Ověření uživatele nebo instančního objektu Power BI
správce Get-PowerBIActivityEvent Zobrazte nebo extrahujte události protokolu aktivit Power BI pro tenanta.
Pracovní prostory Get-PowerBIWorkspace Zkompilujte seznam pracovních prostorů.
Sestavy Get-PowerBIReport Zkompilujte seznam sestav pro pracovní prostor nebo tenanta.
Data Get-PowerBIDataset Zkompilujte seznam sémantických modelů pro pracovní prostor nebo tenanta.
Profil Invoke-PowerBIRestMethod Odeslání požadavku rozhraní REST API (příkaz) Tato rutina je dobrou volbou, protože může vyvolat libovolnou z rozhraní REST API Power BI. Je také dobrou volbou, když chcete použít jednodušší formu ověřování pomocí Connect-PowerBIServiceAccount rutiny a mít možnost vyvolat rozhraní API, které nemá odpovídající rutinu PowerShellu. Další informace najdete v tématu Důležité informace o používání rutin PowerShellu dále v této části.

Tip

Pro správu a publikování obsahu jsou k dispozici další rutiny. Tento článek se ale zaměřuje na načítání dat auditování.

Modul Správy Power BI si můžete stáhnout z Galerie prostředí PowerShell. Nejjednodušším způsobem instalace modulů je použití modulu PowerShellGet.

Doporučujeme nainstalovat kumulativní modul správy Power BI. Tímto způsobem jsou k dispozici všechny rutiny, které budete potřebovat. Minimálně potřebujete modul Profile (pro ověřování) a všechny konkrétní moduly, které obsahují rutiny, které chcete použít.

Upozornění

Nezapomeňte udržovat moduly aktuální na všech serverech, uživatelských počítačích a cloudových službách (jako je Azure Automation), kde používáte PowerShell. Pokud se moduly neaktualizují pravidelně, může dojít k nepředvídatelným chybám nebo problémům. Některé nástroje (například Visual Studio Code) vám pomůžou udržovat moduly aktualizované. Mějte také na paměti, že Modul PowerShellGet při instalaci nebo aktualizaci novější verze modulu automaticky neodinstaluje starší verze modulu. Instaluje novější verze společně se staršími verzemi. Doporučujeme zkontrolovat nainstalované verze a pravidelně odinstalovat starší verze.

Modul Brány dat

Modul Brána dat obsahuje rutiny, které načítají data z místní brány dat a jejích zdrojů dat. Modul Brána dat se podporuje jenom v PowerShellu Core. Windows PowerShell nepodporuje.

Na rozdíl od modulu správy Power BI (dříve popsaného) modul Brána dat neobsahuje žádné rutiny pro správu. Mnoho rutin (a odpovídajících rozhraní API brány) vyžaduje, aby uživatel má oprávnění správce brány.

Upozorňující

Instanční objekt není možné přiřadit jako správce brány (i když je instanční objekt členem skupiny zabezpečení). Proto naplánujte použití přihlašovacích údajů uživatele při načítání informací o branách dat.

Tady je několik rutin z modulu Brána dat, které můžete použít k načtení dat auditování.

Rutina Účel
Připojení-DataGatewayServiceAccount Ověřte uživatele Power BI (obvykle vyžaduje, aby uživatel patří do role správce brány).
Get-DataGatewayCluster Zkompilujte seznam clusterů bran.
Get-DataGatewayClusterDataSource Zkompilujte seznam zdrojů dat pro cluster brány.
Get-DataGatewayInstaller Ověřte, kteří uživatelé mají povoleno instalovat a registrovat brány v organizaci.

Modul Brány dat si můžete stáhnout z Galerie prostředí PowerShell.

Techniky použití PowerShellu

PowerShell můžete použít několika různými způsoby. Rozhodnutí, které uděláte, je důležité.

Následující tabulka popisuje tři různé techniky použití PowerShellu.

Technika Popis Příklad
Pomocí rutin PowerShellu můžete zjednodušit ověřování a přímo volat rozhraní API. Doporučený přístup Díky této technice existuje vyváženost jednoduchosti a flexibility. Rutina Invoke-PowerBIRestMethod je k dispozici v modulu Profil správy Power BI. Tato rutina se často označuje jako švýcarský armádní nůž , protože ji můžete použít k volání libovolného rozhraní REST API Power BI. Výhodou použití této techniky je zjednodušení ověřování a následné volání libovolného rozhraní REST API Power BI. Důrazně doporučujeme použít tuto techniku. Po ověření pomocí rutiny Připojení-PowerBIServiceAccount použijte rutinu Invoke-PowerBIRestMethod k načtení dat z upřednostňovaného rozhraní API (například Get Pipeline Users As Správa).
Rutiny z PowerShellu používejte co nejvíce, a to jak pro ověřování, tak pro načítání dat. S touto technikou se PowerShell používá široce. PowerShell se používá ke koordinaci spuštění skriptu a moduly PowerShellu se používají, kdykoli je to možné pro přístup k datům. Tím se vytvoří větší závislost na PowerShellu z několika aspektů. Po ověření pomocí rutiny Připojení-PowerBIServiceAccount použijte k načtení dat rutinu (například Get-PowerBIActivityEvent).
Ke koordinaci spuštění procesu použijte PowerShell. Moduly PowerShellu se používají co nejméně. S touto technikou je méně závislé na PowerShellu jako nástroj, protože jeho primárním použitím je orchestrace volání rozhraní API. Pro přístup k rozhraním API se používá jenom jeden obecný modul PowerShellu (nepoužívá se žádný z modulů z modulů správy Power BI). Po ověření pomocí knihovny Microsoft Authentication Library (MSAL) volejte upřednostňované rozhraní API (například Get Pipeline Users As Správa) pomocí obecné rutiny Invoke-RestMethod k načtení dat.

V předchozí tabulce první technika popisuje přístup, který vyrovnává snadné použití s flexibilitou. Tento přístup poskytuje nejlepší rovnováhu pro potřeby většiny organizací, což je důvod, proč se doporučuje. Některé organizace můžou mít stávající zásady IT a předvolby zaměstnanců, které ovlivňují, jak se rozhodnete používat PowerShell.

Tip

Pomocí rutiny PowerShellu Invoke-ASCmd můžete vytvářet a spouštět skripty DAX, XMLA a TMSL . Tyto případy použití ale nejsou určené pro tento článek. Další informace o dotazování zobrazení dynamické správy (DMV) naleznete v tématu Auditování na úrovni dat.

Technickí uživatelé (a správci) můžou pomocí modulů správy Power BI načítat data nebo automatizovat určité aspekty správy obsahu.

  • Správci: Nastavte -Scope parametr pro přístup k Organization entitám v celém tenantovi (například pro načtení seznamu všech pracovních prostorů).
  • Pro technické uživatele: Nastavte -Scope parametr tak, aby Individual (nebo vynechal parametr) pro přístup k entitám, které patří uživateli (například k načtení seznamu pracovních prostorů , ke kterým má uživatel oprávnění pro přístup).

Představte si scénář, ve kterém potřebujete získat seznam sémantických modelů. Pokud se rozhodnete pracovat přímo s rozhraními API, musíte určit, které rozhraní API se má volat. Pokud se ale rozhodnete použít rutinu Get-PowerBIDataset , můžete parametr nastavit -Scope tak, aby načetl seznam sémantických modelů specifických pro uživatele nebo celého tenanta. Volba, kterou provedete, závisí na vašem rozhodnutí, jak používat PowerShell (probíraný v předchozí tabulce).

Následující tabulka popisuje, jak se parametry použité v rutině PowerShellu překládají na volání powershellového rozhraní API.

Parametry rutiny Rozhraní API, které rutina používá Typ rozhraní API Scope Načtené položky
-DatasetID {DatasetID}
-Scope Individual		 Získání datové sady Uživatelská Osobní pracovní prostor Jeden sémantický model
-Scope Individual Získání datových sad Uživatelská Osobní pracovní prostor Všechny sémantické modely
-DatasetID {DatasetID}
-GroupID {WorkspaceID}		 Získání datové sady ve skupině Uživatelská Jeden pracovní prostor Jeden sémantický model za předpokladu, že přihlášený uživatel má oprávnění ke čtení sémantického modelu
-GroupID {WorkspaceID} Získání datových sad ve skupině Uživatelská Jeden pracovní prostor Všechny sémantické modely za předpokladu, že přihlášený uživatel má oprávnění pro přístup k pracovnímu prostoru a čtení sémantického modelu
-GroupID {WorkspaceID}
-Scope Organization		 Získání datových sad ve skupině jako Správa správce Jeden pracovní prostor Všechny sémantické modely
-Scope Organization Získání datových sad jako Správa správce Celý tenant Všechny sémantické modely
Důležité informace o používání rutin PowerShellu

Rutiny PowerShellu v Power BI se snadněji používají, protože abstrahují některé složitosti volání rozhraní REST API.

Tady je několik způsobů, jak rutiny zjednodušují přístup k datům auditování.

  • Ověřování: Nejjednodušší způsob, jak se ověřit ve skriptu PowerShellu, je použít rutinu Connect-PowerBIServiceAccount .
  • Jednoduchost: Je jednodušší začít, protože techniky načítání dat auditování jsou jednoduché. Vezměte v úvahu, že když použijete rutinu Get-PowerBIActivityEvent , načtete data auditu jeden den . Když ale přímo zavoláte rozhraní REST API pro získání událostí aktivit, načtete jednu hodinu dat auditu. Pokud tedy použijete rozhraní REST API k načtení jednoho dne dat auditu, musíte k volání rozhraní API 24krát použít smyčku, která extrahuje každou hodinu dne.
  • Stránkování velkých sad výsledků: Velké sady výsledků se efektivně načítají stránkováním. Stránkování zahrnuje načtení jednoho bloku výsledků najednou. Rutiny automaticky spravují stránkování za vás. Pokud však přímo používáte rozhraní REST API, musí skript zkontrolovat token pokračování, abyste zjistili, jestli se mají zobrazit nějaké další výsledky. Skript by měl pokračovat v načítání bloků výsledků, dokud nebude přijat žádný token pokračování. Příklad použití tokenu pro pokračování najdete v tématu Rozhraní REST API událostí aktivit.
  • Vypršení platnosti přístupového tokenu: Po ověření se vrátí přístupový token. Ve výchozím nastavení vyprší po jedné hodině. Rutiny za vás zpracovávají vypršení platnosti přístupového tokenu. Tímto způsobem nemusíte psát logiku pro vyžádání obnovovacího tokenu.
  • Formátování: Data vrácená rutinou jsou trochu hezčí než data vrácená rozhraním REST API. Výstup je uživatelsky přívětivější. U automatizovaných procesů auditování to pravděpodobně není problém. Pro ruční auditování ale může být užitečné lepší formátování.
Důležité informace o přímém používání rozhraní REST API

Někdy existují výhody pro přímé volání rozhraní REST API Power BI.

  • K dispozici je mnoho dalších rozhraní API: K dispozici je více rozhraní REST API než rutiny PowerShellu. Nepřehlédněte ale flexibilitu rutiny Invoke-PowerBIRestMethod , kterou můžete použít k volání některého z rozhraní REST API Power BI.
  • Frekvence aktualizací: Microsoft aktualizuje rozhraní REST API častěji, než aktualizuje moduly PowerShellu. Pokud se například do odpovědi rozhraní Get Dataset API přidá nový atribut, může nějakou dobu trvat, než se zpřístupní ve výsledcích rutiny Get-PowerBIDataset.
  • Méně závislosti na jazyce nebo nástroji: Pokud používáte přímo rozhraní REST API (místo rutiny), nemusíte používat PowerShell. Nebo se můžete rozhodnout použít PowerShell jenom k orchestraci volání mnoha rozhraní API ve skriptu. Odebráním (nebo zabráněním) jakékoli závislosti na PowerShellu můžete v budoucnu logiku přepsat v jiném jazyce. Pokud má váš IT nebo vývojářský tým silné předvolby pro nástroje a jazyky, může být důležité vzít v úvahu méně závislostí.

Bez ohledu na to, kterou metodu zvolíte, se rozhraní REST API můžou v průběhu času měnit. Když se technologie vyvíjí, můžou být rozhraní API (a moduly PowerShellu) zastaralá a nahrazená. Proto doporučujeme účelně vytvářet skripty, které jsou jednoduché pro zachování a odolnost proti změnám.

Kontrolní seznam – Při volbě, jestli se má přistupovat k rozhraním REST API přímo nebo pomocí rutin PowerShellu, zahrnují klíčová rozhodnutí a akce:

  • Poraďte se s IT oddělením o používání PowerShellu: Obraťte se na příslušné IT týmy a zjistěte, jestli existují interní požadavky nebo předvolby týkající se použití PowerShellu.
  • Rozhodněte se, jak chcete použít PowerShell: Určete, které techniky PowerShellu použít, a určete, jestli chcete záměrně zvýšit nebo snížit závislost na PowerShellu. Zvažte, jestli je nutná interní komunikace nebo školení.
  • Upgrade na PowerShell Core: Zdroje informací pomocí PowerShellu Core Určete, jestli je potřeba aktualizovat počítače správce. Zvažte, které existující skripty je potřeba otestovat. Určete, jestli správci nebo vývojáři potřebují další školení k upgradu svých dovedností.
  • Určete, které moduly PowerShellu použít: Zvažte, jestli se použijí moduly správy Power BI nebo modul Brány dat.
  • Rozhodněte se, jestli jsou projekty komunity povolené: Určete, jestli máte (nebo dokonce doporučeno) používat moduly PowerShellu dostupné online (versus moduly publikované Microsoftem). Obraťte se na IT a zjistěte, jestli existují kritéria pro projekty komunity získané online.
  • Vysvětlit, jak podporovat projekty komunity: Pokud jsou projekty komunity PowerShellu povolené, zvažte, kdo bude zodpovědný za jejich podporu, jakmile budou interně používány.
  • Dokončení malého testování konceptu (POC): Experimentujte s technickým POC. Potvrďte upřednostňované klientské nástroje a metodu přístupu k datům.
  • Určete, jak podporovat pokročilé uživatele: Zvažte, jak budete podporovat technické uživatele, kteří sami vytvářejí automatizaci pomocí uživatelských rozhraní API.

Určení, kam se mají ukládat data auditu

Když plánujete vytvořit ucelené řešení auditování, budete se muset rozhodnout, kam se mají ukládat nezpracovaná data (a kurátorovaná data, která jsou popsána v další části). Vaše rozhodnutí o úložišti dat souvisí s vašimi předvolbami pro zpracování integrace dat.

Když extrahujete nezpracovaná data auditování, mějte je jednoduché. Při počátečním extrahování dat doporučujeme nevybírejte konkrétní atributy, provádět transformace ani použít formátování. Místo toho extrahujte všechny dostupné atributy a uložte data do původního stavu.

Tady je několik důvodů, proč je osvědčeným postupem ukládání nezpracovaných dat v původním stavu.

  • Všechna data dostupná v historii: Nové atributy a nové typy událostí budou v průběhu času k dispozici. Uložení všech nezpracovaných dat je dobrý způsob, jak zajistit, abyste měli vždy přístup k jakýmkoli datům, která byla k dispozici v době, kdy jste je extrahovali. I když vám to zabere čas , což může být týdny nebo měsíce, abyste si uvědomili, že jsou k dispozici nové atributy dat, je možné je analyzovat historicky, protože jste je zachytili v nezpracovaných datech.
  • Odolnost proti změnám: Pokud se nezpracovaný formát dat změní, nebude to mít vliv na proces extrahování dat. Vzhledem k tomu, že některá data auditování jsou citlivá na čas, je důležité zajistit, abyste navrhli proces extrakce dat, který nebude neúspěšný, když dojde ke změně ve zdroji.
  • Role a zodpovědnosti: Za vytváření procesů pro přístup, extrakci a ukládání nezpracovaných dat auditu můžou odpovídat různí členové týmu (například datoví inženýři nebo globální správci). Zjednodušení procesu extrakce dat usnadňuje spolupráci více týmů.

Tady je několik možností pro ukládání nezpracovaných dat.

  • Data Lake nebo úložiště objektů: Cloudová služba, jako je OneLake , která se specializuje na ukládání souborů jakékoli struktury. Je to ideální volba pro ukládání nezpracovaných dat auditu. V architektuře datového jezera by se nezpracovaná data měla ukládat do bronzové vrstvy.
  • Systém souborů: Systém souborů (například Windows nebo Linux) je běžnou volbou pro ukládání nezpracovaných dat auditu.
  • Databáze: Data JSON je možné ukládat do relační databáze, jako je Azure SQL Database. Je ale méně běžné než ukládání dat do data lake nebo systému souborů. Důvodem je to, že dotazování a údržba dat JSON může být náročné a nákladné, zejména s rostoucími objemy dat.

Tip

Pokud používáte datové jezero, úložiště objektů nebo systém souborů, doporučujeme ukládat data způsobem, který je snadno uspořádaný a zabezpečený. Je také důležité si uvědomit, jestli data obsahují události (které se obvykle připojují) nebo jestli se jedná o snímek k určitému bodu v čase (který vyžaduje výběr data k analýze).

Představte si příklad zahrnující nezpracovanou datovou zónu datového jezera. Zóna má hierarchii složek pro ukládání dat protokolu aktivit: Raw > ActivityLog > YYYY > MM. Složky jsou rozdělené podle roku a měsíce. Soubor uložený ve složce měsíce používá následující formát: PBIActivityLog-YYYYMMDD-YYYYMMDDTTTT.json. YYYYMMDD představuje skutečná data a YYYYMMDTTTT představuje časové razítko extrakce. Zahrnutím časového razítka extrakce můžete určit, který soubor je nejnovější (v případě, že potřebujete data znovu extrahovat). Pokud například extrahujete data v 9:00 (UTC) 25. dubna 2023 pro aktivitu 23. dubna 2023, bude název souboru PBIActivityLog-20230523-202305250900.

Důrazně doporučujeme použít technologii, která umožňuje zapisovat nezpracovaná data do neměnného úložiště. Neměnné úložiště zaručuje, že po zápisu dat není možné je přepsat ani odstranit. Toto rozlišení je pro auditory důležité a umožňuje důvěřovat, že nezpracovaná data jsou spolehlivá.

Musíte také zvážit, jak bezpečně ukládat nezpracovaná data. Obvykle velmi málo uživatelů vyžaduje přístup k nezpracovaných datům. Přístup k nezpracovaným datům se obvykle poskytuje na základě potřeb, obvykle pro datové inženýry a správce systému. Interní auditoři můžou také potřebovat přístup. Členové týmu, kteří zodpovídají za vytváření kurátorovaných dat (popsaných dále), také vyžadují přístup k nezpracovaných datům.

Tady je několik aspektů, které vám pomůžou zvolit nezpracované úložiště dat.

  • Jedná se o ruční nebo automatizovaný proces auditování? Automatizovaný proces auditování obvykle má přísnější požadavky na způsob a umístění uložených dat.
  • Je oblast předmětu obzvláště citlivá? V závislosti na typu dat a na tom, jak citlivá jsou, může mít vaše organizace požadavek na to, jak a kde jsou uložená. Data auditu Power BI obsahují identifikaci informací o uživateli a IP adresách, takže by měla být uložena v zabezpečené oblasti.
  • Existuje upřednostňovaná technologie úložiště? Může existovat existující technologie úložiště, která se používá v rámci organizace, takže je to logická volba.
  • Budou uživatelé přistupovat k úložišti přímo? Model zabezpečení je důležitým aspektem. Obvykle je přístup k nezpracovaným datům udělený jen velmi málo uživatelům. Přístup k kurátorovaným datům je obvykle zpřístupněn tvůrcům obsahu Power BI, kteří zodpovídají za vytvoření centralizovaného datového modelu (sémantický model, který slouží jako vrstva pro vytváření sestav).
  • Máte požadavky na rezidenci dat? Některé organizace mají zákonné nebo zákonné požadavky na rezidenci dat pro ukládání dat v konkrétní oblasti dat.
  • Jak budou data uspořádána? Použití architektury medailonu je běžným postupem, zejména v implementacích data lake a lakehouse. Cílem je ukládat data do bronzových, stříbrných a zlatých datových vrstev. Bronzová vrstva obsahuje původní nezpracovaná data. Stříbrná vrstva obsahuje ověřená a odstraněná data používaná pro transformace. Zlatá vrstva obsahuje kurátorovaná a vysoce zpřesněná data, která jsou připravená k analýze.

Kontrolní seznam – Při plánování umístění pro ukládání nezpracovaných dat patří klíčová rozhodnutí a akce:

  • Poraďte se s IT oddělením: Obraťte se na příslušné IT týmy a zjistěte, jestli existují spuštěné procesy pro extrakci nezpracovaných dat auditu. Pokud ano, zjistěte, jestli máte přístup k existujícím datům. Pokud se vyžaduje nový proces extrakce dat, určete, jestli existují předvolby nebo požadavky na to, kam se mají data ukládat.
  • Rozhodněte se, kam se mají ukládat nezpracovaná data: Určete nejlepší umístění a strukturu úložiště pro ukládání nezpracovaných dat.
  • Určení požadavků na rezidenci dat: Zjistěte, jestli existují zákonné nebo zákonné požadavky, pro které je možné data uložit.
  • Vytvoření struktury složek a zásady vytváření názvů: Určete, jaké zásady vytváření názvů se mají použít pro nezpracované datové soubory, včetně struktury složek. Tyto podrobnosti uveďte do technické dokumentace.
  • Zvažte, jak bude fungovat zabezpečení nezpracovaných dat: Při návrhu umístění nezpracovaného úložiště dat zvažte, kdo bude potřebovat přístup k datům a jak bude udělen přístup.

Plánování vytváření kurátorovaných dat

Kurátorovaná data podporují analýzu a jsou navržená tak, aby byla uživatelsky přívětivá. Musíte se rozhodnout, jak a kde se budou kurátorovaná data vytvářet. Technologie, kterou se rozhodnete uložit kurátorovaná data, můžou být některé z technologií uvedených v předchozí části.

Cílem kurátorovaných dat je transformovat data do přívětivějšího formátu, který je optimalizovaný pro analýzu a vytváření sestav. Tvoří zdroj dat datového modelu Power BI, takže použijete datový model Power BI k analýze využití Power BI ve vaší organizaci. Základní pokyny k datovému modelu platí: Měli byste přijmout návrh hvězdicového schématu, který je optimalizovaný pro výkon a použitelnost.

Kurátorovaná data můžete vytvářet různými způsoby. Musíte se rozhodnout, jak provést integraci dat a jak daleko upstream použít transformace, které připraví data na načtení do hvězdicového schématu.

Datové jezero

Transformace můžete použít a vytvořit kurátorované datové soubory v datovém jezeře. Pro kurátorovaná data byste měli použít zlatou vrstvu, aby byla logicky oddělená od nezpracovaných dat uložených v bronzové vrstvě. Oddělení dat ve vrstvách také zjednodušuje nastavení různých uživatelských přístupových oprávnění.

Data Lake můžete transformovat a kurátorovat v následujících případech:

  • Očekáváte, že bude existovat několik datových modelů Power BI, které slouží k vytváření sestav (což odůvodňuje vytvoření zprostředkující stříbrné vrstvy).
  • Potřebujete podporovat více samoobslužných tvůrců obsahu, kteří potřebují přístup k datům auditu na úrovni tenanta.
  • Máte existující nástroje a procesy, které chcete použít k transformaci a načtení dat.
  • Chcete minimalizovat přípravu dat, která je potřeba provést (a potenciálně duplikovat) v jednom nebo několika datových modelech Power BI.
Datový model Power BI

Možná budete moct dokončit všechny transformace v Power BI. Power Query slouží k přístupu k datům z nezpracovaného stavu a jejich transformaci na kurátorovaný formát.

Datový model Power BI použijte, když:

  • Chcete zjednodušit komplexní architekturu a načíst datový model přímo z nezpracovaných dat. (Přírůstková aktualizace může pomoct zkrátit dobu trvání aktualizace.)
  • Vaše preference spočívá v tom, že při načítání datového modelu provedete veškerou práci transformace.
  • Očekáváte, že pro data auditu na úrovni tenanta budete mít jeden centralizovaný datový model. Všechny sestavy (nebo jiné datové modely) můžou jako zdroj používat centralizovaný sémantický model Power BI.
  • Chcete uživatelům poskytnout přístup jenom k centralizované sémantickému modelu Power BI (a ne k žádnému ze zdrojových dat).

Tip

Když vytvoříte kurátorovaná data, nastavte je způsobem, abyste mohli proces snadno spustit pro dřívější rozsahy kalendářních dat. Pokud například zjistíte, že se v protokolech auditu před třemi měsíci objevil nový atribut, budete ho chtít analyzovat, protože se poprvé objevil. Schopnost znovu načíst kurátorované historie dat je jedním z několika důvodů, proč je důležité ukládat nezpracovaná data v původním stavu (popsané výše v tomto článku).

Další informace o tom, jaké tabulky dimenzí a tabulky faktů můžete zahrnout do hvězdicového schématu, najdete v části Vytvoření datového modelu dále v tomto článku.

Kontrolní seznam – Při plánování vytváření kurátorovaných dat patří klíčová rozhodnutí a akce:

  • Rozhodněte se, kde se mají transformace provádět: Zvažte, jak daleko se má transformace provádět směrem nahoru a kde se hodí do vašeho plánu pro celou architekturu.
  • Rozhodněte se, jaký nástroj použít k transformaci dat na hvězdicové schéma: Ověřte, které nástroje a služby se použijí k transformaci nezpracovaných dat na kurátorovaná data.
  • Rozhodněte se, kde mají být uložena kurátorovaná data: Určete nejlepší volbu pro ukládání nezpracovaných dat, která jsou transformována do formátu hvězdicového schématu. Rozhodněte se, jestli je v komplexní architektuře užitečná zprostředkující stříbrná vrstva.
  • Vytvoření konvence vytváření názvů: Určete, jaké zásady vytváření názvů se mají použít pro kurátorované datové soubory a složky (pokud jsou k dispozici). Uveďte podrobnosti do technické dokumentace.
  • Zvažte, jak bude fungovat zabezpečení kurátorovaných dat: Při návrhu kurátorovaného umístění úložiště dat zvažte, kdo bude potřebovat přístup k datům a jak bude přiřazeno zabezpečení.

Rozhodnutí o zdroji dat

V tomto okamžiku byste měli mít jasné informace o požadavcích, potřebách dat a oprávněních. Byla provedena klíčová technická rozhodnutí. Teď musíte učinit určitá rozhodnutí o přístupu, abyste získali určité typy dat.

Přístup k datům aktivit uživatelů

Data aktivit uživatelů Power BI, která se někdy označují jako protokol aktivit nebo protokoly auditu, obsahují řadu informací, které vám pomůžou pochopit, co se děje ve vašem tenantovi Power BI. Další informace o identifikaci potřeb vašich dat najdete v části Údaje o aktivitách uživatelů dříve v tomto článku.

Power BI integruje své protokoly s jednotným protokolem auditu Microsoft Purview (dříve označovaný jako jednotný protokol auditu Microsoftu 365). Tato integrace je výhodou, protože to znamená, že každá služba v Microsoftu 365 nemusí implementovat vlastní jedinečný způsob protokolování. Ve výchozím nastavení je zapnuté.

Důležité

Pokud data o aktivitách uživatelů ještě extrahujete, udělejte to jako urgentní prioritu. Data o aktivitách uživatelů jsou k dispozici za posledních 30 nebo 90 dnů (v závislosti na zdroji). I když nejste připraveni provádět hloubkovou analýzu, je důležité začít extrahovat a ukládat data co nejdříve. Díky tomu bude k dispozici cenná historie k analýze.

Máte několik možností, jak načíst data aktivit uživatelů.

Technika Popis Dostupné výchozí dny historie Dobrá volba pro ruční procesy auditování Dobrá volba pro automatizované procesy auditování Dobrá volba pro nastavení upozorňování Dobrá volba pro rychlé zahájení práce
Ruční (uživatelské rozhraní) Portál pro dodržování předpisů Microsoft Purview 90 Portál dodržování předpisů Microsoft Purview je dobrou volbou pro ruční procesy auditování. Portál dodržování předpisů Microsoft Purview je dobrou volbou pro rychlé zahájení práce.
Ruční (uživatelské rozhraní) Defender pro cloudové aplikace 30 Defender for Cloud Apps je dobrou volbou pro ruční procesy auditování. Defender for Cloud Apps je dobrou volbou pro nastavení upozorňování.
Programová Protokol aktivit Power BI (rozhraní API nebo rutina PowerShellu) 30 Protokol aktivit Power BI (rozhraní API nebo rutina PowerShellu) je dobrou volbou pro automatizované procesy auditování. Protokol aktivit Power BI (rozhraní API nebo rutina PowerShellu) je dobrou volbou, abyste mohli rychle začít.
Programová Rozhraní API aktivity správy Office 365 7 Rozhraní API aktivity správy Office 365 je dobrou volbou pro automatizované procesy auditování.
Programová Microsoft Sentinel (Azure Monitor) 30 Microsoft Sentinel (Azure Monitor) je dobrou volbou pro automatizované procesy auditování. Microsoft Sentinel (Azure Monitor) je dobrou volbou pro nastavení upozorňování.

Zbývající část této části představuje všechny techniky uvedené v tabulce.

Portál pro dodržování předpisů Microsoft Purview

Nástroj pro vyhledávání auditu v Portál dodržování předpisů Microsoft Purview (dříve označovaný jako Centrum dodržování předpisů Microsoftu 365) je vhodným místem pro zobrazení aktivit a upozornění. Tento nástroj nevyžaduje, abyste vytvořili skript pro extrakci a stažení dat. Můžete zvolit úlohu Power BI, abyste zobrazili všechny záznamy protokolu auditu pro určitý časový rozsah. Výsledky můžete také zúžit výběrem konkrétních aktivit a uživatelů. Například manažer vás požádá, abyste zjistili, kdo dříve pracovní prostor odstranil, aby mohl rychle kontaktovat osobu a prodiskutovat danou situaci.

U auditování (Standard) je k dispozici posledních 90 dnů historie. Díky auditování (Premium) vám dlouhodobé uchovávání umožňuje (volitelně) uchovávat protokoly auditu déle. Vzhledem k tomu, že dlouhodobé uchovávání se vztahuje pouze na licencované uživatele E5, vylučuje záznamy auditu pro uživatele, kteří nejsou uživateli E5 a uživateli typu host. Proto doporučujeme spoléhat se pouze na výchozí 90denní historii, abyste zajistili, že se zachytí veškerá aktivita.

Existují licenční požadavky pro přístup k protokolům auditu v Portál dodržování předpisů Microsoft Purview. Pro přístup k protokolům auditu se vyžadují také zvýšená oprávnění Exchange Online.

Tip

Ve výchozím nastavení nemají správci Power BI oprávnění pro přístup k jednotnému prohledávání protokolu auditování v Portál dodržování předpisů Microsoft Purview. Protože obsahuje data pro mnoho služeb Microsoftu 365, je to role s vysokými oprávněními. Ve většině organizací jsou tato oprávnění vyhrazená pro malý počet správců IT. Správcům Power BI jsou k dispozici další možnosti, které jsou popsány dále v této části.

Uživatelské rozhraní v Portál dodržování předpisů Microsoft Purview je užitečné pro ruční procesy auditování a občasné šetření uživatelských aktivit.

Defender pro cloudové aplikace

Portál v Programu Defender for Cloud Apps je vhodným místem pro zobrazení aktivit a upozornění, aniž byste museli vytvářet skript pro extrakci a stahování dat. Umožňuje také zobrazit data z protokolu aktivit Power BI a přihlašování uživatelů.

Defender for Cloud Apps obsahuje uživatelské rozhraní pro zobrazení a vyhledávání protokolů aktivit pro různé cloudové služby, včetně Power BI. Zobrazí stejné události protokolu, které pocházejí z sjednoceného protokolu auditu Microsoft Purview, a obsahuje další události, jako je přihlašovací aktivita uživatele z Microsoft Entra ID.

Podobně jako Portál dodržování předpisů Microsoft Purview (popsané v předchozí části) má Defender for Cloud Apps prohledávatelné uživatelské rozhraní. Možnosti filtru se ale liší. Kromě standardní 30denní historie můžete pomocí Defenderu for Cloud Apps zobrazit až šest měsíců historie protokolu aktivit (v sedmidenních přírůstcích).

Existují licenční požadavky pro přístup k Defenderu for Cloud Apps. Vyžadují se také samostatná oprávnění .

Tip

Ve výchozím nastavení nemají správci Power BI oprávnění pro přístup k Defenderu for Cloud Apps. V Programu Defender for Cloud Apps je role Power BI. Přidání správců Power BI do této role je dobrým způsobem, jak jim udělit přístup k omezené sadě dat.

Uživatelské rozhraní v Defenderu pro Cloud Apps je užitečné pro ruční procesy auditování a jednorázové šetření aktivit uživatelů.

Protokol aktivit Power BI

Protokol aktivit Power BI pochází z jednotného protokolu auditu. Obsahuje pouze aktivity uživatelů související s služba Power BI.

Tip

Pro organizace, které plánují extrahovat aktivity uživatelů, doporučujeme začít protokolem aktivit Power BI. Je to nejjednodušší zdroj pro programový přístup.

Máte dvě možnosti pro přístup k protokolu aktivit Power BI.

Informace o tom, kterou možnost použít, najdete v části Volba rozhraní API nebo rutin PowerShellu v dřívější části tohoto článku.

Tip

Příklady přístupu k protokolu aktivit Power BI pomocí PowerShellu najdete v protokolu aktivit Power BI.

Data protokolu aktivit Power BI jsou dostupná všem správcům Power BI, správcům Power Platform a globálním správcům. K datům je možné přistupovat z jednotného protokolu auditu, který je dostupný pro určité role Exchange Online. Další informace najdete v tématu Sledování aktivit uživatelů v Power BI.

Protokol aktivit Power BI doporučujeme použít, pokud chcete načíst jenom záznamy protokolu auditu Power BI.

Poznámka:

V datech protokolu auditu se pracovní prostory označují jako složky. V rozhraní REST API Power BI se pracovní prostory označují jako skupiny.

Rozhraní API aktivity správy Office 365

Data můžete extrahovat z jednotného protokolu auditu pro jiné služby, jako jsou SharePoint Online, Teams, Exchange Online, Dynamics 365 a Power BI. Pokud je vaším cílem implementovat řešení auditování a monitorování pro více služeb, doporučujeme používat rozhraní API aktivity správy Office 365. Vzhledem k tomu, že toto rozhraní API vrací data z mnoha služeb, označuje se jako sjednocené rozhraní API pro auditování (nebo jednotný protokol auditu). Je to jedno z rozhraní API pro správu Office 365.

Než vytvoříte nové řešení, doporučujeme, abyste se obrátili na IT oddělení a zjistili, jestli jsou dostupné existující záznamy auditu Power BI. Je možné, že proces už extrahuje a ukládá data. Je také možné, že místo vytvoření nového řešení získáte oprávnění pro přístup k datům.

K datům se dostanete jedním ze dvou způsobů.

Důležité

Rutina Search-UnifiedAuditLog není dobře škálovat a vyžaduje, abyste implementovali strategii smyčky pro překonání limitu 5 000 řádků. Z těchto důvodů se hodí pro občasné dotazy nebo pro malé organizace, u které dochází k nízké aktivitě. Pokud potřebujete jenom data Power BI, doporučujeme místo toho použít rutinu Get-PowerBIActivityEvent .

Obecně platí, že začínáme s rozhraním API aktivity správy Office 365 je náročnější než používání protokolu aktivit Power BI (popsané výše). Je to proto, že rozhraní API vrací objekty blob obsahu a každý objekt blob obsahu obsahuje jednotlivé záznamy auditu. U velkých organizací může existovat tisíce objektů blob obsahu za den. Vzhledem k tomu, že zákazníci a aplikace třetích stran toto rozhraní API silně využívají, Microsoft implementuje omezování, aby se zajistilo, že jejich používání služby negativně neovlivní ostatní (označuje se jako problém hlučného souseda ). Načítání velkých objemů historie proto může být ve větších organizacích výzvou. Další informace najdete v tomto článku o řešení potíží.

Pokud chcete toto rozhraní API používat, musíte se ověřit pomocí instančního objektu, kterému bylo uděleno oprávnění k načtení dat z rozhraní API aktivity správy Office 365.

Tip

Ve výchozím nastavení nemají správci Power BI oprávnění pro přístup k rozhraní API aktivit správy Office 365. Protože obsahuje data pro mnoho služeb Microsoftu 365, přístup vyžaduje správce s vysokými oprávněními nebo role auditu. Ve většiněorganizacích Protokol aktivit Power BI je určený pro použití správci Power BI.

Načítání dat auditu prostřednictvím kódu programu z rozhraní API aktivit správy Office 365 je dobrou volbou, když IT potřebuje extrahovat a ukládat protokoly auditu z různých služeb (mimo Power BI).

Microsoft Sentinel

Microsoft Sentinel je služba Azure, která umožňuje shromažďovat, zjišťovat, zkoumat a reagovat na bezpečnostní incidenty a hrozby. Power BI můžete v Microsoft Sentinelu nastavit jako datový konektor. Při připojení se protokoly auditu (obsahující podmnožinu dat) streamují z Power BI do Azure Log Analytics, což je funkce služby Azure Monitor.

Tip

Azure Log Analytics je založená na stejné architektuře, kterou používají protokoly událostí sémantického modelu na úrovni pracovního prostoru. Další informace o protokolech sémantických událostí modelu najdete v tématu Auditování na úrovni dat.

Vzhledem k tomu, že se jedná o samostatnou službu Azure, musí mít každý správce nebo uživatel, který chcete spouštět dotazy dotazovací jazyk Kusto (KQL), udělená oprávnění v Azure Log Analytics (Azure Monitor). Když mají oprávnění, můžou se dotazovat na data auditu uložená v tabulce PowerBIActivity . Mějte ale na paměti, že ve většině případů uživatelům udělíte přístup ke kurátorovaným datům ve zlaté vrstvě místo nezpracovaných dat v bronzové vrstvě.

KQL slouží k analýze událostí protokolu aktivit uložených v Azure Log Analytics. Pokud máte zkušenosti s SQL, najdete mnoho podobností s KQL.

K událostem uloženým ve službě Azure Log Analytics můžete přistupovat několika způsoby. Můžete použít:

  • Předem připravená aplikace šablony Log Analytics pro sémantické modely Power BI
  • Konektor Power BI Desktopu pro Azure Data Explorer (Kusto).
  • Webové prostředí dotazů v Azure Data Exploreru
  • Jakýkoli dotazovací nástroj, který může odesílat dotazy KQL.

Upozornění

Mějte na paměti, že ve službě Azure Monitor se ukládá jenom podmnožina dat protokolu aktivit Power BI. Pokud plánujete provádět komplexní analýzu využití a přijetí Power BI v organizaci, doporučujeme k načtení dat aktivit použít další možnosti (popsané výše v této části).

Doba trvání historie, kterou můžete načíst, závisí na zásadách uchovávání dat pro pracovní prostor Služby Azure Log Analytics. Při rozhodování o tom, kolik dat se má zachovat, zvažte náklady a přístup k nezpracovaných datům.

Microsoft Sentinel a Azure Monitor jsou dobré možnosti, když IT už investovalo s Microsoft Sentinelem, úroveň podrobností zachycených podle vašich potřeb a aktivity, jako je detekce hrozeb, jsou prioritou. Vzhledem k tomu, že Microsoft Sentinel nezachytává všechna data aktivit Power BI, nepodporuje komplexní analýzu využití a přijetí Power BI.

Důležité informace o datech aktivit uživatelů

Tady je několik aspektů, které vám pomůžou zvolit zdroj dat o aktivitách uživatelů.

  • Bude to ruční nebo automatizovaný proces auditování? Možnosti uživatelského rozhraní dobře fungují pro ruční procesy auditování a občasné jednorázové dotazy, zejména pokud potřebujete prozkoumat konkrétní aktivitu. K podpoře historické analýzy dat bude potřeba také automatizovaný proces auditování, který extrahuje data aktivit uživatelů podle plánu.
  • Jak často potřebujete data o aktivitách uživatelů? V případě automatizovaných procesů auditování naplánujte extrakci dat, která jsou alespoň jeden den před aktuálním datem, a to pomocí koordinovaného univerzálního času (UTC) místo místního času. Pokud se například proces spustí v pátek ráno (čas UTC), měli byste extrahovat data z středy. Existuje několik důvodů, proč byste měli extrahovat data s latencí jednoho dne.
    • Soubory budou jednodušší, když vždy extrahujete plných 24 hodin najednou, což zabrání částečným výsledkům dne.
    • Minimalizujete riziko chybějících událostí auditu. Události auditu obvykle přicházejí do 30 minut. Občas může trvat až 24 hodin, než dorazí do sjednoceného protokolu auditu.
  • Potřebujete víc než data Power BI? Zvažte nejúčinnější způsob, jak získat přístup k tomu, co potřebujete.
    • Pokud potřebujete jenom data o aktivitách uživatelů Power BI, použijte protokol aktivit Power BI.
    • Pokud potřebujete protokoly auditu z více služeb, použijte rozhraní API aktivity správy Office 365 pro přístup k jednotnému protokolu auditu.
  • Kdo bude řešení vyvíjet? Naplánujte si nějaký čas na sestavení řešení. Vytvoření skriptu připraveného pro produkční prostředí může vyžadovat značné úsilí.

Kontrolní seznam – Při plánování přístupu k datům aktivit uživatelů patří klíčová rozhodnutí a akce:

  • Objasnění rozsahu potřeb: Určete, jestli potřebujete přístup jenom k záznamům auditu Power BI, nebo k datům auditu pro více služeb.
  • Konzultace s IT: Zjistěte, jestli IT aktuálně extrahuje protokoly auditu a jestli je možné získat přístup k nezpracovaným datům, abyste nemuseli vytvářet nové řešení.
  • Rozhodněte se o zdroji dat: Určete nejlepší zdroj, který se má použít pro přístup k datům aktivit uživatelů.
  • Dokončení testování konceptu: Naplánujte dokončení malého technického testování konceptu (POC). Použijte ho k ověření vašich rozhodnutí o tom, jak bude konečné řešení sestaveno.
  • Sledování dalších potřeb dat: Data protokolu aktivit můžete korelovat s jinými zdroji a zlepšit tak hodnotu dat. Mějte přehled o těchto příležitostech, jakmile se objeví, aby je bylo možné přidat do rozsahu projektu.

Přístup k datům inventáře tenanta

Inventář tenanta je neocenitelným a nezbytným součástí vyspělého řešení auditování a monitorování. Pomáhá pochopit, které pracovní prostory a obsah (sémantické modely, sestavy a další položky) existují v Power BI, a je to vynikající doplněk k datům o aktivitách uživatelů (popsaných v předchozí části). Další informace o identifikaci potřeb vašich dat najdete v části Inventář tenanta dříve v tomto článku.

Aktivity uživatelů (dříve popsané) jsou auditované události; jedná se o záznam akcí, které uživatel provedl v určitém datu a čase. Inventář tenanta se ale liší. Inventář tenanta je snímek v daném časovém okamžiku. Popisuje aktuální stav všech publikovaných položek v služba Power BI v okamžiku, kdy jste ho extrahovali.

Poznámka:

Dokumentace k rozhraní REST API Power BI odkazuje na publikované položky jako artefakty.

Tip

Mnoho organizací je užitečné extrahovat inventář tenanta najednou každý týden.

Abyste mohli správně analyzovat, co se děje ve vašem tenantovi Power BI, potřebujete data o aktivitách uživatelů i inventář tenanta. Když je zkombinujete, budete moct pochopit, kolik obsahu máte a kde se nachází. Umožňuje také najít nepoužitý nebo nevyužitý obsah (protože v protokolu aktivit nebudou žádné události). Inventář tenanta vám také pomůže zkompilovat seznam aktuálních názvů pro všechny položky, což je užitečné při změně názvů položek.

Další informace o hodnotě inventáře tenanta najdete v části Inventář tenanta dříve v tomto článku.

Tip

Nepoužité artefakty můžete použít jako rozhraní API Správa k vyhledání položek, které v posledních 30 dnech nemají žádnou aktivitu uživatele. Toto časové období ale nemůžete přizpůsobit. Můžete mít například kritický obsah, který se používá jenom čtvrtletně. Když zkombinujete inventář tenanta s daty aktivit uživatelů, můžete nepoužívané položky najít způsoby, které si můžete přizpůsobit.

Data inventáře tenanta můžete získat dvěma různými způsoby.

Technika Popis Nejvhodnější pro Dobrá volba pro ruční procesy auditování Dobrá volba pro automatizované procesy auditování
Programová Rozhraní Get Groups as Admin API nebo rutina PowerShellu Get-PowerBIWorkspace může poskytnout seznam pracovních prostorů pro celého tenanta. Volitelně je možné zahrnout jednotlivé položky (například sémantické modely a sestavy) na pracovní prostor. Menší organizace nebo nízký objem dat Rutina Get Groups as Správa API nebo Get-PowerBIWorkspace PowerShell je dobrou volbou pro procesy ručního auditování. Skupiny Get jako rozhraní API Správa nebo rutina PowerShellu Get-PowerBIWorkspace je dobrou volbou pro automatizované procesy auditování.
Programová Sada asynchronních rozhraní API pro správu, souhrnně označovaná jako rozhraní API pro prohledávání metadat nebo rozhraní API skeneru, může vrátit seznam pracovních prostorů a jednotlivých položek. Volitelně je možné zahrnout i podrobná metadata (například tabulky, sloupce a výrazy měr). Organizace s velkým objemem dat nebo nutností získat podrobné výsledky Rozhraní API pro kontrolu metadat jsou dobrou volbou pro automatizované procesy auditování.

Zbývající část této části představuje všechny techniky uvedené v tabulce.

Rutina rozhraní API nebo pracovních prostorů skupin

Pokud chcete načíst seznam pracovních prostorů, můžete použít jedno z několika rozhraní REST API, jako je získání skupin jako rozhraní API Správa (pomocí nástroje podle vašeho výběru). Výsledky zahrnují další metadata, jako je popis a jestli je pracovní prostor uložený v kapacitě Premium.

Poznámka:

Pojmenované rozhraní API obsahuje skupinu termínů jako odkaz na pracovní prostor. Tento termín pochází z původního modelu zabezpečení Power BI, který spoléhal na skupiny Microsoftu 365. I když se model zabezpečení Power BI v průběhu let výrazně vyvinul, stávající názvy rozhraní API zůstanou beze změny, aby nedocházelo k přerušení stávajících řešení.

Rozhraní Get Groups as Admin REST API obsahuje užitečný $expand parametr. Tento parametr umožňuje volitelně rozbalit výsledky tak, aby zahrnoval seznam položek publikovaných do pracovního prostoru (například sémantické modely a sestavy). Datový typ můžete také předat users parametru $expand , aby zahrnoval uživatele, kteří jsou přiřazeni k roli pracovního prostoru.

Můžete také použít rutinu Get-PowerBIWorkspace PowerShellu. Je z modulu Pracovních prostorů správy Power BI. Když nastavíte -Scope parametr organization, funguje jako Get Groups as Admin rozhraní API. Rutina také přijímá -Include parametr (což je ekvivalent parametru $expand v rozhraní REST API), aby zahrnoval položky publikované v pracovním prostoru (například sémantické modely a sestavy).

Tip

Předáním parametrů můžete rutinu použít různými způsoby. Tato část se zaměřuje na načtení inventáře v rámci celého tenanta. Další informace o použití parametru -Scope najdete v části Volba uživatelského rozhraní API nebo rozhraní API pro správu výše v tomto článku.

Nápovědu k volbě, kterou možnost použít, najdete v části Výběr rozhraní API nebo rutin PowerShellu výše v tomto článku.

Rozhraní Get Groups as Admin REST API nebo rutina PowerShellu Get-PowerBIWorkspace je nejvhodnější pro ruční procesy auditování a jednorázové šetření. Větší organizace s velkým objemem dat obvykle tyto možnosti obtížně používají. Rozhraní REST API a rutina vždy extrahují úplnou sadu dat, takže jejich spuštění může trvat dlouhou dobu. Je tedy také pravděpodobné, že větší organizace budou mít omezení počtu povolených požadavků za hodinu (označuje se jako omezování, které se provádí za účelem ochrany stavu služby). Rozhraní API pro prohledávání metadat (popsaná dále) poskytují spolehlivější a škálovatelnou alternativu.

Rozhraní API pro kontrolu metadat

Rozhraní API pro prohledávání metadat, běžně označovaná jako rozhraní API skeneru, jsou sada rozhraní API, která vracejí seznam pracovních prostorů a jejich položek Power BI (sémantické modely, sestavy a další položky). Koncepčně poskytují stejná data (a další) jako rozhraní API skupiny nebo rutinu pracovního prostoru, která jsou popsána v předchozí části. Metoda, kterou použijete k načtení dat, se ale liší a je vhodnější pro extrakci inventáře tenanta.

Poznámka:

Všimněte si, jak někteří uživatelé používají rozhraní API skeneru termínů nebo frázi prohledání tenanta. Tyto termíny často používají k kompilaci inventáře tenanta a k odlišení od událostí aktivity uživatelů. Můžou nebo nemusí doslova odkazovat na použití rozhraní API pro skenování metadat.

Existují dva hlavní důvody, proč byste měli zvážit použití rozhraní API pro prohledávání metadat místo Get Groups as Admin rozhraní REST API nebo Get-PowerBIWorkspace rutiny (popsané výše).

  • Přírůstkové extrahování dat: Rozhraní API skeneru extrahují pouze data, která se změnila od posledního spuštění. Get Groups as Admin Rozhraní REST API a Get-PowerBIWorkspace rutina jsou naopak synchronní operace, které při každém spuštění extrahují úplnou sadu dat.
  • Podrobnější úroveň podrobností: Rozhraní API skeneru můžou načítat podrobné podrobnosti (jako jsou tabulky, sloupce a výrazy měr), přičemž dvě nastavení tenanta poskytují oprávnění pro podrobná metadata. Naopak nejnižší úroveň podrobností dostupná v Get Groups as Admin rozhraní REST API a Get-PowerBIWorkspace rutina je podle typu položky (například seznam sestav v pracovním prostoru).

Použití rozhraní API skeneru zahrnuje větší úsilí, protože potřebujete volat řadu rozhraní API. Také se spouštějí jako asynchronní proces. Asynchronní proces běží na pozadí, takže nemusíte čekat, až se dokončí. Možná budete muset spolupracovat s IT nebo vývojářem, když je čas vytvořit skript připravený pro produkční prostředí, který se naplánuje.

Tady je posloupnost kroků, které by váš proces měl následovat při použití rozhraní API skeneru.

  1. Přihlášení: Přihlaste se k služba Power BI pomocí účtu správce Power BI nebo instančního objektu, který má oprávnění ke spouštění rozhraní API pro správu. Další informace naleznete v tématu Určení metody ověřování dříve v tomto článku.
  2. Získejte ID pracovního prostoru: Odešlete žádost o načtení seznamu ID pracovních prostorů. Při prvním spuštění nebudete mít datum změny, takže se vrátí úplný seznam pracovních prostorů. Obvykle předáte datum změny, abyste načetli jenom pracovní prostory, které se od tohoto bodu v čase změnily. Datum změny musí být v posledních 30 dnech.
  3. Zahájení kontroly metadat: Zahájení volání, které požádá o kontrolu informací pracovního prostoru předáním ID pracovních prostorů načtených v kroku 2. Všimněte si, že se jedná o rozhraní POST API (místo rozhraní GET API, což je častější při načítání dat auditu). Rozhraní POST API je požadavek HTTP, který vytváří nebo zapisuje data pro zadaný prostředek. Tento dotaz určuje úroveň podrobností, která se extrahuje, například podrobnosti o zdroji dat, sémantické schéma modelu, výrazy sémantického modelu nebo uživatele. Po odeslání rozhraní API vrátí ID kontroly. Vrátí také datum a čas kontroly, které byste měli zaznamenat jako datum snímku.
  4. Zkontrolujte stav kontroly: Pomocí ID kontroly získaného v kroku 3 získejte stav kontroly. Možná budete muset toto rozhraní API volat vícekrát. Když je vrácený stav Úspěšný, můžete přejít k dalšímu kroku. Doba potřebnou ke kontrole závisí na tom, kolik dat požadujete.
  5. Získejte výsledky: Pomocí ID kontroly získaného v kroku 3 získejte výsledek kontroly a extrahujte data. Tento krok musíte provést do 24 hodin od dokončení kroku 4. Mějte na paměti, že časové razítko snímku by mělo být korelováno s krokem 3 místo kroku 5 (pokud dojde k významnému zpoždění). Tímto způsobem budete mít přesné časové razítko snímku. Uložte výsledky do upřednostňovaného umístění úložiště dat. Jak už bylo popsáno v tomto článku, doporučujeme uložit nezpracovaná data v původním stavu.
  6. Příprava na další proces: Zaznamená časové razítko kontroly z kroku 3, abyste ho mohli použít v kroku 2 při příštím spuštění procesu. Tímto způsobem extrahujete pouze data, která se od tohoto bodu v čase změnila. V budoucnu budou všechny následné extrahování dat přírůstkové změny, nikoli úplné snímky.

Kontrolní seznam – Při plánování přístupu k datům inventáře tenanta zahrnují klíčová rozhodnutí a akce:

  • Potvrzení požadavků: Zpřehledněte potřeby kompilace inventáře tenanta a analytických požadavků na data.
  • Rozhodněte se o frekvenci extrakce inventáře tenanta: Ověřte, jak často budete potřebovat nový inventář tenanta (například každý týden).
  • Rozhodněte se, jak extrahovat inventář tenanta: Ověřte, kterou metodu použijete k získání dat inventáře tenanta (rozhraní API, rutina nebo rozhraní API pro prohledávání metadat).
  • Dokončení testování konceptu: Naplánujte dokončení malého technického testování konceptu (POC). Použijte ho k ověření vašich rozhodnutí o tom, jak bude konečné řešení sestaveno.

Přístup k datům uživatelů a skupin

Kromě identifikačních informací (například e-mailové adresy), které jsou součástí dat o aktivitách uživatelů, je užitečné načíst další informace, jako je umístění nebo podrobnosti o organizaci. Pomocí Microsoft Graphu můžete načíst data o uživatelích, skupinách, instančních objektech a licencích. Microsoft Graph se skládá ze sady rozhraní API a klientských knihoven, které umožňují načítat data auditu z široké škály služeb.

Tady jsou některé podrobnosti o objektech Microsoft Entra, ke kterým máte přístup.

  • Uživatel: Identita, která existuje v Microsoft Entra ID jako pracovní, školní nebo microsoft účet. Uživatel domény se často používá k popisu uživatelů organizace, zatímco formální termín je hlavní název uživatele (UPN). Hlavní název uživatele (UPN) je obvykle stejná hodnota jako e-mailová adresa uživatele (pokud se ale změní e-mailová adresa, hlavní název uživatele (UPN) se nezmění, protože je neměnný). Pro každého uživatele je také jedinečné ID Microsoft Graphu. Uživatelský účet je často přidružený k jedné osobě. Některé organizace vytvářejí uživatele, kteří jsou účty služeb používané pro automatizované aktivity nebo úlohy správy.
  • Instanční objekt: Jiný typ identity, který se zřizuje při vytváření registrace aplikace. Instanční objekt je určený pro bezobslužné automatizované aktivity. Další informace naleznete v tématu Určení metody ověřování dříve v tomto článku.
  • Skupina: Kolekce uživatelů a instančních objektů. Existuje několik typů skupin , které můžete použít ke zjednodušení správy oprávnění. Další informace najdete v tématu Strategie použití skupin.

Poznámka:

Pokud tento článek odkazuje na uživatele a skupiny, zahrnuje tento termín také instanční objekty. Tento kratší termín se používá pro stručnost.

Data uživatelů a skupin, která načtete, jsou snímky , které popisují aktuální stav v daném bodu v čase.

Tip

Další informace o uživatelích, instančních objektech a skupinách naleznete v tématu Integrace s Microsoft Entra ID.

Analytické atributy

V případě auditování na úrovni tenanta Power BI můžete extrahovat a ukládat následující atributy z Microsoft Graphu.

  • Celé jméno uživatelů: Mnoho zdrojů dat obsahuje jenom e-mailovou adresu uživatele, který provedl aktivitu nebo kdo je přiřazen k roli. Tento atribut použijte, pokud chcete zobrazit úplný název (zobrazovaný název) v analytických sestavách. Když použijete celé jméno, sestavy budou uživatelsky přívětivější.
  • Další vlastnosti uživatele: Další popisné atributy o uživatelích mohou být k dispozici v Microsoft Entra ID. Mezi příklady předdefinovaných atributů profilů uživatelů, které mají analytickou hodnotu, patří pracovní pozice, oddělení, manažer, oblast a umístění kanceláře.
  • Členové skupiny zabezpečení: Většina zdrojů dat poskytuje název skupiny (například protokol aktivit Power BI zaznamenává, že skupina zabezpečení byla přiřazena k roli pracovního prostoru). Načtení členství ve skupině zlepšuje schopnost plně analyzovat, co jednotlivý uživatel dělá nebo má přístup.
  • Uživatelské licence: Je užitečné analyzovat, které uživatelské licence ( bezplatné, Power BI Pro nebo Power BI Premium na uživatele (PPU) jsou přiřazené uživatelům. Tato data vám můžou pomoct zjistit, kdo licenci nepoužívá. Pomůže vám také analyzovat všechny uživatele (jedinečné uživatele s licencí) a aktivní uživatele (s nedávnými aktivitami). Pokud zvažujete přidání nebo rozšíření licencí Power BI Premium, doporučujeme analyzovat data uživatelských licencí společně s daty o aktivitách uživatelů a provádět analýzu nákladů.
  • Členové rolí správce: Seznam správců Power BI můžete zkompilovat (včetně správců Power Platform a globálních správců).

Autoritativní referenční informace o licencích Power BI, které najdete v datech auditu z Microsoft Graphu, najdete v tématu Názvy produktů a identifikátory plánů služeb pro licencování.

Tip

Načítání členů ze skupin může být jedním z nejnáročnějších aspektů získávání dat auditu. Budete muset provést přechodné vyhledávání , abyste zploštěli všechny vnořené členy a vnořené skupiny. Můžete provést přechodné hledání členů skupiny. Tento typ vyhledávání je obzvláště náročný, pokud ve vaší organizaci existují tisíce skupin. V takovém případě můžete zvážit lepší alternativy k načtení dat. Jednou z možností je extrahovat všechny skupiny a členy skupiny z Microsoft Graphu. To ale nemusí být praktické, pokud se pro zabezpečení Power BI používá jenom malý počet skupin. Další možností je předem vytvořit referenční seznam skupin, které používají jakýkoli typ zabezpečení Power BI (role pracovního prostoru, oprávnění aplikace, sdílení jednotlivých položek, zabezpečení na úrovni řádků a další). Pak můžete procházet referenčním seznamem a načíst členy skupiny z Microsoft Graphu.

Tady jsou některé další atributy, které můžete extrahovat a uložit.

  • Typ uživatele: Uživatelé jsou členy nebo hosty. Nejčastěji jsou členy interními uživateli a hosté jsou externími uživateli (B2B). Ukládání typu uživatele je užitečné, když potřebujete analyzovat aktivity externích uživatelů.
  • Změny rolí: Když provádíte audit zabezpečení, je užitečné pochopit, kdy uživatel změnil role v organizaci (například při přenosu do jiného oddělení). Tímto způsobem můžete ověřit, jestli byla jejich nastavení zabezpečení Power BI (nebo by se měla aktualizovat).
  • Zakázaní uživatelé: Když uživatel opustí organizaci, obvykle správce zakáže svůj účet. Můžete vytvořit proces, který zkontroluje, jestli jsou zakázaní uživatelé správci pracovního prostoru nebo sémantické vlastníky modelu.

Tip

Protokol aktivit Power BI obsahuje událost, která zaznamenává, když se uživatel zaregistruje ke zkušební licenci. Tuto událost můžete zkombinovat s uživatelskými licenčními daty (zdroji z Microsoft Entra ID) a vytvořit tak kompletní obrázek.

Načtení dat uživatelů a skupin

Data o uživatelích a skupinách můžete načítat různými způsoby.

Technika Popis Dobrá volba pro ruční procesy auditování Dobrá volba pro automatizované procesy auditování
Ruční Průzkumník grafů Graph Explorer je dobrou volbou pro ruční procesy auditování.
Programová Rozhraní Microsoft Graph API a sady SDK Rozhraní Microsoft Graph API a sady SDK jsou dobrou volbou pro automatizované procesy auditování.
Programová Modul Az PowerShellu Modul Az PowerShell je dobrou volbou pro automatizované procesy auditování.

Zbývající část této části představuje všechny techniky uvedené v tabulce. Další techniky, které jsou zastaralé a neměly by se používat pro nová řešení, jsou popsány na konci této části.

Poznámka:

Při čtení informací online buďte opatrní, protože mnoho názvů nástrojů je podobné. Některé nástroje v ekosystému Microsoftu zahrnují termín Graph v jejich názvu, jako je Azure Resource Graph, GraphQL a rozhraní Microsoft Security Graph API. Tyto nástroje nesouvisejí s Microsoft Graphem a nejsou určené pro tento článek.

Microsoft Graph Explorer

Microsoft Graph Explorer je vývojářský nástroj, který umožňuje získat informace o rozhraních Microsoft Graph API. Je to jednoduchý způsob, jak začít, protože nevyžaduje žádné další nástroje ani nastavení na vašem počítači. Můžete se přihlásit a načíst data z tenanta nebo z výchozího tenanta načíst ukázková data.

Pomocí Graph Exploreru můžete:

  • Ručně odešlete požadavek do rozhraní Microsoft Graph API a zkontrolujte, jestli vrací požadované informace.
  • Než napíšete skript, podívejte se, jak vytvořit adresu URL, hlavičky a text.
  • Zkontrolujte data neformálním způsobem.
  • Určete, která oprávnění se vyžadují pro každé rozhraní API. Můžete také poskytnout souhlas s novými oprávněními.
  • Získejte fragmenty kódu, které se mají použít při vytváření skriptů.

Pomocí tohoto odkazu otevřete Graph Explorer.

Rozhraní Microsoft Graph API a sady SDK

Pomocí rozhraní Microsoft Graph API můžete načítat data uživatelů a skupin. Můžete ho také použít k načtení dat ze služeb, jako je Microsoft Entra ID, SharePoint Online, Teams, Exchange, Outlook a další.

Sady Microsoft Graph SDK fungují jako obálka rozhraní API nad podkladovými rozhraními Microsoft Graph API. Sada SDK je sada sdk pro vývoj softwaru, která seskupuje nástroje a funkce dohromady. Sady Microsoft Graph SDK zpřístupňují celou sadu rozhraní Microsoft Graph API.

Můžete se rozhodnout odesílat žádosti přímo do rozhraní API. Případně můžete přidat vrstvu zjednodušení pomocí preferovaného jazyka a jedné ze sad SDK. Další informace najdete v tématu Výběr rozhraní API nebo rutin PowerShellu výše v tomto článku.

Sady Microsoft Graph SDK podporují několik jazyků a existují také moduly Microsoft Graph PowerShellu . Další sady SDK jsou k dispozici pro Python, C# a další jazyky.

Důležité

Modul Microsoft Graph PowerShell nahrazuje moduly Azure AD PowerShell a moduly MSOnline (MSOL), které jsou zastaralé. Neměli byste vytvářet nová řešení s zastaralými moduly. Modul Microsoft Graph PowerShell má mnoho funkcí a výhod. Další informace najdete v tématu Upgrade z Azure AD PowerShellu na Microsoft Graph PowerShell.

Moduly Microsoft Graph PowerShellu můžete nainstalovat z Galerie prostředí PowerShell. Vzhledem k tomu, že Microsoft Graph funguje s mnoha službami Microsoftu 365, existuje mnoho modulů PowerShellu, které instalujete.

V případě auditování na úrovni tenanta Power BI tady jsou nejběžnější moduly PowerShellu, které budete muset nainstalovat.

Tip

Microsoft pravidelně aktualizuje moduly Microsoft Graph PowerShellu. Někdy se moduly Preview zpřístupní v předběžné verzi nebo v beta koncovém bodu. Při instalaci a aktualizaci modulů můžete chtít zadat verzi, kterou vás zajímá. Při kontrole online dokumentace také mějte na paměti, že aktuální číslo verze se automaticky připojí na konec adresy URL (proto při ukládání nebo sdílení adres URL buďte opatrní).

Modul Az PowerShellu

K načtení dat uživatelů a skupin můžete použít také modul Az PowerShell. Zaměřuje se na prostředky Azure.

Důležité

Modul Az PowerShell nahrazuje moduly AzureRM PowerShellu, které jsou zastaralé. Neměli byste vytvářet nová řešení s zastaralými moduly.

Rutinu Invoke-AzRestMethod můžete použít, pokud neexistuje odpovídající rutina pro rozhraní API. Je to flexibilní přístup, který umožňuje odeslat požadavek do libovolného rozhraní Microsoft Graph API pomocí modulu Az PowerShell.

Počínaje Az verze 7 teď rutiny Az odkazují na rozhraní Microsoft Graph API. Modul Az proto funguje jako obálka rozhraní API nad Microsoft Graphem. Moduly Az mají podmnožinu funkcí obsažených v rozhraních Microsoft Graph API a modulech PowerShellu. Pro nová řešení doporučujeme použít sadu Microsoft Graph PowerShell SDK.

Zastaralá rozhraní API a moduly

Články a blogové příspěvky můžete najít online, které navrhují alternativní možnosti, které nejsou uvedené v této části. Důrazně doporučujeme nevytvořovat nová řešení (nebo migrovat stávající řešení) pomocí některého z následujících rozhraní API nebo modulů.

  • Moduly AzureRM PowerShellu: Zastaralé a budou vyřazeny. Nahradili je modulem Az PowerShell.
  • Rozhraní Azure AD Graph API a modul Azure AD PowerShell: Zastaralé a vyřazené. Tato změna je výsledkem migrace z Azure AD Graphu do Microsoft Graphu (všimněte si, že Graph se zobrazuje v obou názvech, ale Microsoft Graph je budoucí směr). Veškeré budoucí investice do PowerShellu budou provedeny v sadě Microsoft Graph PowerShell SDK. (Id Microsoft Entra se teď označuje jako Microsoft Entra ID.)
  • Modul PowerShellu MS Online (MSOL): Zastaralé a bude vyřazeno. Veškeré budoucí investice do PowerShellu budou provedeny v sadě Microsoft Graph PowerShell SDK.

Upozornění

Nezapomeňte potvrdit stav jakéhokoli zastaralého rozhraní API nebo modulu, který právě používáte. Další informace o vyřazení AzureRM najdete v tomto oznámení.

Další informace o Microsoft Entra ID a MSOL naleznete v tomto příspěvku o vyřazení.

Pokud máte dotazy nebo potřebujete objasnit budoucí směr programového přístupu k datům, obraťte se na svůj tým účtů Microsoft.

Kontrolní seznam – Při plánování přístupu k datům uživatelů a skupin patří klíčová rozhodnutí a akce:

  • Potvrzení požadavků: Objasněte si potřeby kompilace dat souvisejících s uživateli, skupinami a licencemi.
  • Stanovení priorit požadavků: Ověřte, jaké jsou hlavní priority, abyste věděli, na co se má čas nejprve věnovat.
  • Rozhodněte se o frekvenci extrakce dat: Určete, jak často budete potřebovat nový snímek dat uživatelů a skupin (například každý týden nebo každý měsíc).
  • Rozhodněte se, jak extrahovat data pomocí Microsoft Graphu: Určete, jakou metodu použijete k načtení dat.
  • Dokončení testování konceptu: Naplánujte dokončení malého technického testování konceptu (POC) pro extrakci dat uživatelů a skupin. Použijte ho k ověření vašich rozhodnutí o tom, jak bude konečné řešení sestaveno.

Přístup k datům z rozhraní REST API Power BI

Možná jako nižší prioritu můžete také načíst další data pomocí rozhraní REST API Power BI.

Můžete například načíst data o:

Během auditu zabezpečení můžete chtít identifikovat:

Další informace o dalších typech rozhraní API najdete v části Volba uživatelského rozhraní API nebo rozhraní API pro správu výše v tomto článku.

Kontrolní seznam – Při plánování přístupu k datům z API Power BI patří klíčová rozhodnutí a akce:

  • Získání požadavků: Kompilace analytických požadavků při jejich vzniku Sledujte je v backlogu.
  • Stanovení priorit požadavků: Nastavte priority pro nové požadavky, které vznikají.

Fáze 2: Požadavky a nastavení

Druhá fáze plánování a implementace řešení auditování na úrovni tenanta se zaměřuje na předpoklady a nastavení, které je potřeba provést před zahájením vývoje řešení.

Vývojový diagram popisující fázi 2, který se zaměřuje na požadavky a nastavení pro vytvoření řešení auditování na úrovni tenanta

Vytvoření účtu úložiště

V tomto okamžiku jste se rozhodli o umístění pro ukládání nezpracovaných dat a o tom, jak vytvořit kurátorovaná data. Na základě těchto rozhodnutí teď můžete vytvořit účet úložiště. V závislosti na procesech vaší organizace to může zahrnovat odeslání žádosti it.

Jak jsme popsali dříve, doporučujeme použít technologii, která umožňuje zapisovat nezpracovaná data do neměnného úložiště. Po zápisu dat je nelze změnit ani odstranit. Pak můžete mít důvěru v nezpracovaná data, protože víte, že správce s přístupem je nemůže žádným způsobem změnit. Kurátorovaná data ale nemusí být (obvykle) uložená v neměnném úložišti. Kurátorovaná data se můžou změnit nebo je můžete znovu vygenerovat.

Kontrolní seznam – Při vytváření účtu úložiště zahrnují klíčová rozhodnutí a akce:

  • Vytvoření účtu úložiště: Vytvoření nebo odeslání žádosti o vytvoření účtu úložiště Pro nezpracovaná data používejte neměnná nastavení úložiště, kdykoli je to možné.
  • Nastavit oprávnění: Určete, která oprávnění mají být nastavena pro účet úložiště.
  • Testovací přístup: Proveďte malý test, abyste měli jistotu, že můžete číst a zapisovat do účtu úložiště.
  • Potvrďte odpovědnosti: Ujistěte se, že máte jistotu, kdo bude účet úložiště průběžně spravovat.

Instalace softwaru a nastavení služeb

V tuto chvíli jste se rozhodli, jakou technologii použít pro přístup k datům auditu. Na základě těchto rozhodnutí jste teď připraveni nainstalovat software a nastavit služby.

Nastavte upřednostňované vývojové prostředí pro každého správce. Vývojové prostředí jim umožní psát a testovat skripty. Visual Studio Code je moderní nástroj pro vývoj skriptů, takže je to dobrá volba. K dispozici je také mnoho rozšíření pro práci se sadou Visual Studio Code.

Pokud jste se rozhodli (předchozí popis) použít PowerShell, měli byste nainstalovat PowerShell Core a potřebné moduly PowerShellu na:

  • Počítač každého správce nebo vývojáře, který bude psát nebo testovat skripty auditování.
  • Každý virtuální počítač nebo server, který bude spouštět naplánované skripty.
  • Každá online služba (například Azure Functions nebo Azure Automation).

Pokud jste se rozhodli používat jakékoli služby Azure (například Azure Functions, Azure Automation, Azure Data Factory nebo Azure Synapse Analytics), měli byste je zřídit a nastavit také.

Kontrolní seznam – Při instalaci softwaru a nastavení služeb patří klíčová rozhodnutí a akce:

  • Nastavení počítačů pro správce nebo vývojáře: Pokud je to možné, nainstalujte potřebné nástroje, které se použijí pro vývoj.
  • Nastavení serverů: Pokud je to možné, nainstalujte potřebné nástroje na všechny servery nebo virtuální počítače, které se nacházejí ve vaší architektuře.
  • Nastavení služeb Azure: Pokud je to možné, zřiďte a nastavte každou službu Azure. Přiřaďte oprávnění každému správci nebo vývojáři, kteří budou pracovat na vývoji.

Registrace aplikace Microsoft Entra

V tuto chvíli jste se rozhodli , jak se ověřit. Doporučujeme zaregistrovat aplikaci Microsoft Entra (instanční objekt). Běžně se označuje jako registrace aplikace, měla by se používat pro bezobslužné operace, které budete automatizovat.

Další informace o tom, jak vytvořit registraci aplikace pro načtení dat auditování na úrovni tenanta, najdete v tématu Povolení ověřování instančního objektu pro rozhraní API pro správu jen pro čtení.

Kontrolní seznam – Při registraci aplikace Microsoft Entra patří klíčová rozhodnutí a akce:

  • Zkontrolujte, jestli existuje existující registrace aplikace: Ověřte u IT, jestli je pro účely spouštění rozhraní API pro správu dostupná existující registrace aplikace. Pokud ano, určete, jestli má být použit existující nebo zda má být vytvořen nový.
  • Vytvoření nové registrace aplikace: V případě potřeby vytvořte registraci aplikace. Zvažte použití názvu aplikace, jako je PowerBI-Správa APIs-EntraApp, který jasně popisuje jeho účel.
  • Vytvořte tajný kód pro registraci aplikace: Jakmile registrace aplikace existuje, vytvořte pro ni tajný kód. Nastavte datum vypršení platnosti na základě toho, jak často chcete tajný kód otočit.
  • Bezpečně uložte hodnoty: Uložte tajný klíč, ID aplikace (ID klienta) a ID tenanta, protože je budete potřebovat k ověření pomocí instančního objektu. Použijte umístění, které je zabezpečené, například trezor hesel organizace. (Pokud potřebujete požádat o vytvoření registrace aplikace z IT, zadejte, že se vám tyto hodnoty vrátí.)
  • Vytvořte skupinu zabezpečení: Vytvořte (nebo požádejte) skupinu zabezpečení, která se použije pro Power BI. Zvažte použití názvu skupiny, jako jsou instanční objekty správce Power BI, což značí, že se skupina použije pro přístup k metadatům celého tenanta.
  • Přidejte instanční objekt jako člena skupiny zabezpečení: Pomocí ID aplikace (ID klienta) přidejte nový (nebo existující) instanční objekt jako člena nové skupiny zabezpečení.
  • Aktualizace nastavení tenanta rozhraní API správce v Power BI: Na portálu pro správu Power BI přidejte skupinu zabezpečení do nastavení tenanta Povolit instančním objektům používat rozhraní API pro správu Power BI jen pro čtení.
  • Přeskočení přiřazování oprávnění v Azure: Nelegujte žádná oprávnění na registraci aplikace (získá přístup k datům auditu na úrovni tenanta Power BI prostřednictvím instančních objektů povolit, aby používaly nastavení tenanta pro správu Power BI jen pro čtení).
  • Rozhodněte se, jestli má registrace aplikace přistupovat k podrobným metadatům: Určete, jestli chcete při sestavování inventáře tenanta extrahovat podrobné informace o sémantických tabulkách modelu, sloupcích a výrazech měr.
  • Aktualizujte podrobná nastavení tenanta metadat v Power BI: Volitelně můžete na portálu pro správu Power BI přidat skupinu zabezpečení k vylepšení odpovědí rozhraní API pro správu s podrobným nastavením tenanta metadat a také vylepšit odpovědi rozhraní API pro správu pomocí nastavení tenanta DAX a mashup expressions .
  • Otestujte instanční objekt: Vytvořte jednoduchý skript pro přihlášení pomocí instančního objektu a otestujte, že může načítat data z rozhraní API pro správu.
  • Vytvořte proces pro správu tajných kódů registrace aplikací: Vytvořte dokumentaci a proces, který bude pravidelně obměňovat tajné kódy. Určete, jak bezpečně sdělíte nový tajný kód všem správcům a vývojářům, kteří ho potřebují.

Nastavení tenanta Power BI

Portál pro správu Power BI obsahuje několik nastavení tenantů, která jsou relevantní pro extrahování dat auditování na úrovni tenanta.

rozhraní API Správa

Existují tři nastavení tenanta, která jsou relevantní pro spouštění rozhraní API pro správu.

Důležité

Vzhledem k tomu, že tato nastavení udělují přístup k metadatům pro celého tenanta (bez přiřazení přímých oprávnění Power BI), měli byste je přesně řídit.

Nastavení tenanta Povolit instančním objektům používat rozhraní API pro správu Power BI jen pro čtení umožňuje nastavit, které instanční objekty můžou volat rozhraní API pro správu. Toto nastavení také umožňuje Službě Microsoft Purview prohledávat celého tenanta Power BI, aby mohl naplnit katalog dat.

Poznámka:

Nemusíte explicitně přiřazovat další správce Power BI k nastavení tenanta Povolit instančním objektům používat nastavení tenanta rozhraní API pro správu Power BI jen pro čtení, protože už mají přístup k metadatům celého tenanta.

Vylepšení odpovědí rozhraní API pro správu pomocí podrobného nastavení tenanta metadat umožňuje nastavit, kteří uživatelé a instanční objekty mohou načíst podrobná metadata. Metadata se načítají pomocí rozhraní API pro skenování metadat a zahrnují tabulky, sloupce a další. Toto nastavení také umožňuje službě Microsoft Purview získat přístup k informacím na úrovni schématu o sémantických modelech Power BI, aby je mohl uložit do katalogu dat.

Vylepšení odpovědí rozhraní API pro správu pomocí nastavení tenanta DAX a mashup expressions umožňuje nastavit, kteří uživatelé a instanční objekty mohou načíst podrobná metadata. Metadata se načítají z rozhraní API pro prohledávání metadat a mohou obsahovat dotazy a sémantické výrazy míry modelu.

Poznámka:

Nastavení klienta Povolit instančním objektům používat rozhraní API pro správu Power BI jen pro čtení je konkrétně přístup k rozhraním API pro správu. Jeho název je velmi podobný nastavení tenanta, které je určené pro přístup k uživatelským rozhraním API (popsané dále). Další informace o rozdílu mezi rozhraními API pro správu a uživatelskými rozhraními API najdete v části Volba uživatelského rozhraní API nebo rozhraní API pro správu výše v tomto článku.

Uživatelská rozhraní API

Existuje jedno nastavení tenanta, které platí pro volání uživatelských rozhraní API. V takovém případě se pro instanční objekt vyžaduje také oprávnění Power BI (například role pracovního prostoru).

Nastavení povolit instančním objektům používat API Power BI s tenanta umožňuje nastavit, které instanční objekty mají přístup ke spouštění rozhraní REST API (s výjimkou rozhraní API pro správu, která jsou udělena jiným nastavením tenanta popsaného výše).

Existují další nastavení tenanta související s rozhraními API, která umožňují přístup k rozhraním API pro vkládání, rozhraním API pro streamování, exportu rozhraní API a rozhraní API pro spouštění dotazů . Tato rozhraní API ale nejsou určená pro tento článek.

Další informace o nastavení tenanta pro metriky využití najdete v tématu Auditování na úrovni sestavy.

Kontrolní seznam – Při nastavování nastavení tenanta Power BI zahrnují klíčová rozhodnutí a akce:

  • Ověřte, že je každý instanční objekt ve správné skupině: Ověřte, že skupina instančních objektů správce Power BI obsahuje správné instanční objekty .
  • Aktualizujte nastavení tenanta rozhraní API pro správu v Power BI: Přidejte skupinu zabezpečení do objektů služby Povolit instančním objektům používat nastavení tenanta rozhraní API pro správu Power BI jen pro čtení, které umožňuje pomocí rozhraní API pro správu načítat metadata pro celou tenanta.
  • Aktualizujte podrobná nastavení tenanta metadat v Power BI: V případě potřeby přidejte skupinu zabezpečení do odpovědí rozhraní API pro vylepšení správy s podrobným nastavením tenanta metadat a vylepšení odpovědí rozhraní API pro správu pomocí nastavení tenanta DAX a mashupových výrazů .
  • Ověřte, která uživatelská rozhraní API budou přístupná: Ověřte, jestli bude potřeba jedno nebo více uživatelských rozhraní API (kromě rozhraní API pro správu).
  • Aktualizujte nastavení tenanta uživatelského rozhraní API v Power BI: Přidejte skupinu zabezpečení do nastavení Povolit instančním objektům používat nastavení API Power BI s tenanta, které je určené pro uživatelská rozhraní API.

Fáze 3: Vývoj a analýzy řešení

Třetí fáze plánování a implementace řešení auditování na úrovni tenanta se zaměřuje na vývoj a analýzu řešení. V tomto okamžiku došlo ke všemu plánování a rozhodování a splnili jste požadavky a dokončili jste nastavení. Teď jste připraveni začít s vývojem řešení, abyste mohli provádět analýzy a získávat přehledy z dat auditování.

Vývojový diagram popisující fázi 3, který se zaměřuje na vývoj řešení a analýzu řešení auditování na úrovni tenanta

Extrahování a ukládání nezpracovaných dat

V tuto chvíli by vaše požadavky a priority měly být jasné. Klíčová technická rozhodnutí se týkají přístupu k datům auditu a umístění pro ukládání dat auditu. Byly vybrány upřednostňované nástroje a byly nastaveny požadavky a nastavení. Během předchozích dvou fází jste možná dokončili jeden nebo více malých projektů (testování konceptu), aby bylo možné prokázat proveditelnost. Dalším krokem je nastavení procesu pro extrakci a uložení nezpracovaných dat auditování.

Stejně jako u dat vrácených většinou rozhraní API Microsoftu se data auditování naformátují jako JSON. Data formátovaná ve formátu JSON se popisují sama, protože jde o čitelný text, který obsahuje strukturu a data.

JSON představuje datové objekty, které se skládají z párů atributů a polí. Příkladem je například "state": "Active" hodnota atributu stavu Aktivní. Pole JSON obsahuje uspořádaný seznam prvků oddělených čárkou a který je uzavřený v hranatých závorkách ([ ]). Ve výsledcích JSON je běžné najít vnořené pole. Jakmile se seznámíte s hierarchickou strukturou výsledku JSON, je jednoduché pochopit datovou strukturu, jako je seznam (pole) sémantických modelů v pracovním prostoru.

Tady je několik důležitých informací o extrahování a ukládání nezpracovaných dat načtených z rozhraní API.

  • Jaké zásady vytváření názvů se použijí? Pro systém založený na souborech je potřeba zásady vytváření názvů pro soubory, složky a zóny data lake. Pro databázi je nutná konvence vytváření názvů pro tabulky a sloupce.
  • Jaký formát se použije k ukládání nezpracovaných dat? S tím, jak Power BI nadále zavádí nové funkce, se objeví nové aktivity , které dnes neexistují. Z tohoto důvodu doporučujeme extrahovat a zachovat původní výsledky JSON. Neprovádějte analýzu, filtrování ani formátování dat během extrahování. Tímto způsobem můžete použít původní nezpracovaná data k opětovnému vygenerování kurátorovaných dat auditu.
  • Jaké umístění úložiště se použije? Úložiště data Lake nebo blob se běžně používá k ukládání nezpracovaných dat. Další informace naleznete v tématu Určení, kam se mají ukládat data auditu dříve v tomto článku.
  • Kolik historie uložíte? Exportujte data auditu do umístění, kam můžete uložit historii. Naplánujte nashromáždění aspoň dva roky historie. Díky tomu můžete analyzovat trendy a změny nad rámec výchozího 30denního období uchovávání. V závislosti na zásadách uchovávání dat pro vaši organizaci se můžete rozhodnout, že data budou uložena neomezeně dlouho, nebo se můžete rozhodnout o kratším období.
  • Jak budete sledovat, kdy se proces naposledy spustil? Nastavte konfigurační soubor nebo ekvivalent pro zaznamenání časových razítek při spuštění a dokončení procesu. Při příštím spuštění procesu může tato časová razítka načíst. Je zvlášť důležité ukládat časová razítka při extrahování dat pomocí rozhraní API pro skenování metadat.
  • Jak zvládnete omezování? Některá rozhraní REST API Power BI a rozhraní Microsoft Graph API implementují omezování. Pokud je váš požadavek rozhraní API omezený, zobrazí se chyba 429 (příliš mnoho požadavků). Omezování může být běžným problémem u větších organizací, které potřebují načíst velký objem dat. Jak se vyhnout neúspěšným pokusům kvůli omezování závisí na technologii, kterou používáte pro přístup k datům a jejich extrahování. Jednou z možností je vývoj logiky ve skriptech, které reagují na chybu 429 Příliš mnoho požadavků opakovaným pokusem po čekací době.
  • Jsou data auditu potřebná pro dodržování předpisů? Mnoho organizací používá nezpracované záznamy protokolu auditu k provádění auditů dodržování předpisů nebo k reakci na šetření zabezpečení. V těchto případech důrazně doporučujeme ukládat nezpracovaná data do neměnného úložiště. Po zápisu dat je tak nelze změnit ani odstranit správcem nebo jiným uživatelem.
  • Jaké vrstvy úložiště jsou nezbytné pro podporu vašich požadavků? Nejlepším místem pro ukládání nezpracovaných dat je datové jezero (například Azure Data Lake Storage Gen2) nebo úložiště objektů (například Azure Blob Storage). Systém souborů se dá použít také v případě, že cloudové služby nejsou volbou.

Kontrolní seznam – Při extrahování a ukládání nezpracovaných dat patří klíčová rozhodnutí a akce:

  • Potvrďte požadavky a priority: Vyjasněte si požadavky a priority dat, která extrahujete jako první.
  • Potvrďte zdroj dat, který se má extrahovat: Ověřte zdroj pro každý typ dat, který potřebujete.
  • Nastavte proces, který extrahuje data a načte je do zóny nezpracovaných dat: Vytvořte počáteční proces pro extrakci a načtení nezpracovaných dat v původním stavu bez jakýchkoli transformací. Otestujte, že proces funguje podle očekávání.
  • Vytvořte plán pro spuštění procesů: Nastavte opakovaný plán pro spouštění procesů extrakce, načítání a transformace.
  • Ověřte, že jsou přihlašovací údaje spravovány bezpečně: Ověřte, že jsou hesla, tajné kódy a klíče uložené a komunikované zabezpečenými způsoby.
  • Ověřte, že je správně nastavené zabezpečení: Ověřte, jestli jsou pro nezpracovaná data správně nastavená přístupová oprávnění. Zajistěte, aby správci a auditoři měli přístup k nezpracovaných datům.

Další informace o tom, jak se v průběhu času zvyšuje auditování a monitorování řešení, najdete v části Zprovoznění a vylepšení dále v tomto článku.

Vytvoření kurátorovaných dat

V tomto okamžiku se nezpracovaná data extrahují a ukládají. Dalším krokem je vytvoření samostatné zlaté datové vrstvy pro kurátorovaná data. Jejím cílem je transformovat a ukládat datové soubory do hvězdicového schématu. Hvězdicové schéma se skládá z tabulek dimenzí a tabulek faktů a záměrně je optimalizované pro analýzu a vytváření sestav. Soubory ve kurátorované datové vrstvě se stanou zdrojem datového modelu Power BI (popsaného v dalším tématu).

Tip

Pokud očekáváte, že existuje více datových modelů, je obzvláště užitečné investovat do centralizované kurátorované datové vrstvy.

Kontrolní seznam – Při vytváření kurátorované datové vrstvy patří klíčová rozhodnutí a akce:

  • Potvrďte požadavky a priority: Pokud chcete pro transformovaná data použít zprostředkující stříbrnou vrstvu, upřesněte požadavky a cíle, které potřebujete k dosažení.
  • Nastavte proces, který transformuje nezpracovaná data a načte je do kurátorované zóny dat: Vytvořte proces transformace a načtení dat do hvězdicového schématu. Otestujte, že proces funguje podle očekávání.
  • Vytvořte plán pro spuštění procesů: Nastavte opakovaný plán pro naplnění kurátorované datové vrstvy.
  • Ověřte, že je správně nastavené zabezpečení: Ověřte, jestli jsou pro kurátorovaná data správně nastavená přístupová oprávnění. Zajistěte, aby vývojáři datového modelu měli přístup ke kurátorovaným datům.

Vytvoření datového modelu

Toto téma se týká nastavení analytického datového modelu. Datový model je prostředek dat s možností dotazování optimalizovaný pro analýzu. Někdy se označuje jako sémantický model nebo jednoduše jako model. U vašeho řešení auditování a monitorování se datový model pravděpodobně implementuje jako sémantický model Power BI.

V kontextu auditování a monitorování datový model zdrojuje data z kurátorované (zlaté) datové vrstvy. Pokud se rozhodnete nevytvořovat kurátorovaná datová vrstva, datový model zdrojuje data přímo z nezpracovaných dat.

Doporučujeme, aby datový model Power BI implementoval návrh hvězdicového schématu. Pokud jsou zdrojová data kurátorovaná datová vrstva, hvězdicové schéma datového modelu Power BI by mělo zrcadlit kurátorované hvězdicové schéma datové vrstvy.

Tip

Přehled návrhu hvězdicového schématu najdete v tématu Vysvětlení hvězdicového schématu a důležitosti pro Power BI.

Stejně jako u každého projektu Power BI je vytvoření datového modelu iterativní proces. Podle potřeby můžete přidat nové míry. Můžete také přidat nové tabulky a sloupce, jakmile budou k dispozici nové události auditu. Časem můžete dokonce integrovat nové zdroje dat.

Tady je několik užitečných tabulek dimenzí, které můžete zahrnout do datového modelu.

  • Datum: Sada atributů data umožňující analýzu dat (dělení a dělení dat) podle dne, týdne, měsíce, čtvrtletí, roku a dalších relevantních časových období.
  • Čas: Pokud potřebujete analyzovat podle denní doby a máte velmi velký objem dat auditu, zvažte uložení časové části odděleně od data. Tento přístup může pomoct zlepšit výkon dotazů.
  • Uživatelé: Atributy, které popisují uživatele (například oddělení a geografickou oblast), které můžou filtrovat mnoho subjektů dat auditování. Cílem je odebrat všechny podrobnosti o uživatelích z tabulek faktů a uložit je do této tabulky dimenzí, aby mohli filtrovat mnoho tabulek faktů. Instanční objekty můžete uložit také v této tabulce.
  • Události aktivit: Atributy, které seskupují a popisují události aktivit (operace). Pokud chcete vylepšit vytváření sestav, můžete vytvořit datový slovník, který popisuje každou událost aktivity. Můžete také vytvořit hierarchii, která seskupí a klasifikuje podobné události aktivity. Můžete například seskupit všechny události vytváření položek, odstranit události atd.
  • Pracovní prostory: Seznam pracovních prostorů ve vlastnostech tenanta a pracovního prostoru, jako je typ (osobní nebo standardní) a popis. Některé organizace zaznamenávají další podrobnosti o pracovních prostorech (pravděpodobně pomocí sharepointového seznamu). Tyto podrobnosti můžete integrovat do této tabulky dimenzí. Musíte se rozhodnout, jestli tato tabulka dimenzí ukládá pouze aktuální stav pracovního prostoru, nebo jestli ukládá data s verzí, která odrážejí významné změny pracovního prostoru v průběhu času. Když se například změní název pracovního prostoru, zobrazí se v historických sestavách aktuální název pracovního prostoru nebo název pracovního prostoru, který byl v té době aktuální? Další informace o správě verzí najdete v tématu Pomalu se měnící dimenze.
  • Typy položek: Seznam typů položek Power BI (sémantické modely, sestavy a další).
  • Kapacity: Seznam kapacit Premium v tenantovi.
  • Brány: Seznam bran dat v tenantovi.
  • Zdroje dat: Seznam zdrojů dat, které používají jakýkoli sémantický model, tok dat nebo datový diagram.

Tady jsou některé užitečné tabulky faktů (předměty), které můžete zahrnout do datového modelu.

  • Aktivity uživatelů: Data faktů, která pocházejí z původních dat JSON. Všechny atributy, které nemají žádnou analytickou hodnotu, se odeberou. Odeberou se také všechny atributy, které patří do tabulek dimenzí (výše).
  • Inventář tenanta: Snímek všech položek publikovaných v tenantovi k určitému bodu v čase. Další informace najdete v části Inventář tenanta dříve v tomto článku.
  • Sémantické modely: Zahrnuje aktivitu uživatelů zahrnující sémantické modely (například sémantické změny modelu) nebo související zdroje dat.
  • Sémantické aktualizace modelu: Ukládá operace aktualizace dat, včetně podrobností o typu (plánovaném nebo na vyžádání), době trvání, stavu a o tom, který uživatel operaci zahájil.
  • Role pracovního prostoru: Snímek přiřazení rolí pracovního prostoru k určitému bodu v čase.
  • Uživatelské licence: Snímek uživatelských licencí k určitému bodu v čase. I když vás může být lákavé uložit uživatelskou licenci do tabulky dimenzí Users , tento přístup nebude podporovat analýzu změn licencí a trendů v průběhu času.
  • Členství ve skupinách uživatelů: Snímek uživatelů (a instančních objektů) přiřazený ke skupině zabezpečení k určitému bodu v čase.
  • Aktivity komunity: Zahrnuje fakta týkající se komunity, jako jsou školicí akce. V porovnání s účastí na školení můžete například analyzovat aktivity uživatelů Power BI. Tato data by mohla centru efektivity pomoct identifikovat potenciální nové šampiony.

Tabulky faktů by neměly obsahovat sloupce, které budou tvůrci sestav filtrovat. Místo toho tyto sloupce patří do souvisejících tabulek dimenzí. Tento návrh je nejen efektivnější pro dotazy, ale podporuje také opakované použití tabulek dimenzí několika fakty (označované jako přechod k podrobnostem). Tento poslední bod je důležitý k vytvoření užitečného a uživatelsky přívětivého datového modelu, který je rozšiřitelný při přidávání nových tabulek faktů (předmětů).

Tabulka dimenzí Uživatelé bude například souviset s každou tabulkou faktů. Měla by souviset s tabulkou faktů Aktivity uživatele (kdo aktivitu provedl), tabulkou faktů inventáře tenanta (která vytvořila publikovanou položku) a všemi ostatními tabulkami faktů. Když uživatel v tabulce dimenzí Uživatelé vyfiltruje sestavu, můžou vizuály v této sestavě zobrazovat fakta pro daného uživatele z jakékoli související tabulky faktů.

Při návrhu modelu se ujistěte, že je atribut v modelu viditelný jen jednou a pouze jednou. Například e-mailová adresa uživatele by měla být viditelná pouze v tabulce dimenze Uživatelé . Bude existovat také v jiných tabulkách faktů (jako klíč dimenze pro podporu relace modelu). Měli byste ho ale skrýt v každé tabulce faktů.

Doporučujeme vytvořit datový model oddělený od sestav. Oddělení sémantického modelu a jeho sestav vede k centralizovanému sémantickému modelu, který může obsluhovat mnoho sestav. Další informace o použití sdíleného sémantického modelu najdete ve scénáři použití spravované samoobslužné služby BI .

Zvažte nastavení zabezpečení na úrovni řádků (RLS) tak, aby ostatní uživatelé mimo centrum efektivity, auditoři a správci mohli analyzovat a hlásit data auditování. Pravidla zabezpečení na úrovni řádků můžete například použít k tomu, aby tvůrci obsahu a uživatelé mohli hlásit své vlastní aktivity uživatelů nebo úsilí o vývoj.

Kontrolní seznam – Při vytváření datového modelu patří klíčová rozhodnutí a akce:

  • Plánování a vytvoření datového modelu: Návrh datového modelu jako hvězdicového schématu Ověřte, že relace fungují podle očekávání. Při vývoji modelu iterativní vytváření měr a přidávání dalších dat na základě analytických požadavků. V případě potřeby zahrňte do backlogu budoucí vylepšení.
  • Nastavení zabezpečení na úrovni řádků: Pokud chcete datový model zpřístupnit ostatním obecným uživatelům, nastavte zabezpečení na úrovni řádků, abyste omezili přístup k datům. Ověřte, že role RLS vrací správná data.

Vylepšení datového modelu

Pokud chcete efektivně analyzovat využití obsahu a aktivity uživatelů, doporučujeme rozšířit datový model. Vylepšení datového modelu je možné provádět postupně a itertivně v průběhu času při zjišťování příležitostí a nových požadavků.

Vytváření klasifikací

Jedním ze způsobů, jak model vylepšit a zvýšit hodnotu dat, je přidat do datového modelu klasifikace. Zajistěte, aby vaše sestavy tyto klasifikace používaly konzistentně.

Můžete se rozhodnout klasifikovat uživatele na základě jejich úrovně využití nebo klasifikovat obsah na základě jeho úrovně použití.

Klasifikace využití uživatelů

Zvažte následující klasifikace využití uživatelů.

  • Časté uživatele: Aktivita zaznamenána v posledním týdnu a za devět posledních 12 měsíců.
  • Aktivní uživatel: Aktivita zaznamenaná za poslední měsíc
  • Občasný uživatel: Aktivita zaznamenaná za posledních devět měsíců, ale bez aktivity za poslední měsíc.
  • Neaktivní uživatel: V posledních devíti měsících nebyla zaznamenána žádná aktivita.

Tip

Je užitečné vědět, kdo jsou příležitostní nebo neaktivní uživatelé, zejména v případě, že mají licence Pro nebo PPU (které zahrnují náklady). Je také užitečné vědět, kdo jsou nejčastější a nejaktivnější uživatelé. Zvažte pozvání, aby se připojili k pracovní době nebo se zúčastnili školení. Vaši nejaktivnější tvůrci obsahu můžou být kandidáti na připojení k síti šampionů.

Klasifikace využití obsahu

Zvažte následující klasifikace využití obsahu.

  • Často používaný obsah: Aktivita zaznamenána v posledním týdnu a za devět posledních 12 měsíců.
  • Aktivně používaný obsah: Aktivita zaznamenaná za poslední měsíc
  • Občas používaný obsah: Aktivita zaznamenaná za posledních devět měsíců, ale bez aktivity za poslední měsíc.
  • Nepoužitý obsah: V posledních devíti měsících nebyla zaznamenána žádná aktivita.
Klasifikace typů uživatelů

Zvažte následující klasifikace pro typ uživatele.

  • Tvůrce obsahu: Aktivita zaznamenaná za posledních šest měsíců, které vytvořily, publikovaly nebo upravily obsah.
  • Prohlížeč obsahu: Aktivita zaznamenaná za posledních šest měsíců, která zobrazila obsah, ale bez aktivity vytváření obsahu.

Měli byste se rozhodnout, jestli by klasifikace využití pro uživatele nebo obsah měly být založené jenom na tom, jak nedávno došlo k aktivitě. Zvažte také faktoring průměrného nebo trendového využití v průběhu času.

Představte si některé příklady, které ukazují, jak jednoduchá logika klasifikace může chybně reprezentovat realitu.

  • Manažer si tento týden zobrazil jednu sestavu. Před tímto týdnem ale manažer za posledních šest měsíců nezhlédl žádné sestavy. Tento manažer byste neměli považovat za častého uživatele na základě nedávného použití.
  • Tvůrce sestavy publikuje novou sestavu každý týden. Při analýze využití častými uživateli se zdá, že běžná aktivita autora sestavy je pozitivní. Při dalším šetření však zjistíte, že tento uživatel znovu publikuje novou sestavu (s názvem nové sestavy) při každé úpravě sestavy. Tvůrci sestav by bylo užitečné mít více školení.
  • Vedoucí pracovník zobrazí sestavu sporadicky, a proto se jejich klasifikace využití často mění. Možná budete muset analyzovat určité typy uživatelů, jako jsou vedoucí pracovníci, jinak.
  • Interní auditor vidí kritické sestavy jednou za rok. Může se zdát, že interní auditor je neaktivní uživatel, protože se používá jen zřídka. Někdo může podniknout kroky k odebrání licence Pro nebo PPU. Nebo se může někdo domnívat, že by se sestava měla vyřadit, protože se používá zřídka.

Tip

Průměry a trendy můžete vypočítat pomocí funkcí časového měřítka jazyka DAX. Pokud chcete zjistit, jak tyto funkce používat, projděte si výukové moduly s časovými měřítky jazyka DAX v modelech Power BI Desktopu.

Kontrolní seznam – Při vytváření klasifikací dat o využití patří klíčová rozhodnutí a akce:

  • Získejte konsensus o definicích klasifikace: Diskutujte o definicích klasifikace s příslušnými zúčastněnými stranami. Při rozhodování se ujistěte, že existuje shoda.
  • Vytvoření dokumentace: Ujistěte se, že definice klasifikace jsou součástí dokumentace pro tvůrce obsahu a uživatele.
  • Vytvořte smyčku zpětné vazby: Ujistěte se, že uživatelé můžou klást otázky nebo navrhovat změny definic klasifikace.

Vytváření analytických sestav

V tuto chvíli se data auditování extrahují a ukládají a publikovali jste datový model. Dalším krokem je vytvoření analytických sestav.

Zaměřte se na klíčové informace, které jsou pro každou cílovou skupinu nejrelevantní. Pro sestavy auditování můžete mít několik cílových skupin. Každá cílová skupina se bude zajímat o různé informace a pro různé účely. Mezi cílové skupiny, které můžete používat se sestavami, patří:

  • Výkonný sponzor
  • Center of Excellence
  • Správci Power BI
  • Správci pracovního prostoru
  • Správci kapacity Premium
  • Správci brány
  • Vývojáři a tvůrci obsahu Power BI
  • Auditoři

Tady jsou některé z nejběžnějších analytických požadavků, se kterými můžete začít při vytváření sestav auditování.

  • Zobrazení hlavního obsahu: Vedoucí a vedoucí týmy můžou mít v průběhu času převážně zájem o souhrnné informace a trendy. Vaši správci pracovního prostoru, vývojáři a tvůrci obsahu se budou více zajímat o podrobnosti.
  • Hlavní aktivity uživatelů: Centrum efektivity bude zajímat, kdo používá Power BI, jak a kdy. Vaši správci kapacity Premium se budou zajímat o to, kdo kapacitu používá, aby zajistili její stav a stabilitu.
  • Inventář tenanta: Vaši správci Power BI, správci pracovních prostorů a auditoři budou zajímat, co obsah existuje, kde, rodokmen a jeho nastavení zabezpečení.

Tento seznam není vše inkluzivní. Účelem je poskytnout vám představu o tom, jak vytvářet analytické sestavy, které cílí na konkrétní potřeby. Další důležité informace najdete v části Požadavky na data dříve v tomto článku a přehled auditování a monitorování. Mezi tyto zdroje informací patří mnoho nápadů, jak můžete použít data auditování, a typy informací, které můžete v sestavách prezentovat.

Tip

I když je lákavé prezentovat velké množství dat, uveďte jenom informace, na které jste připraveni reagovat. Ujistěte se, že každá stránka sestavy má jasný účel, jaká akce by měla být provedena a kým.

Pokud chcete zjistit, jak vytvářet analytické sestavy, projděte si efektivní sestavy návrhu ve studijním programu Power BI .

Kontrolní seznam – Při plánování sestav analytického auditování zahrnují klíčová rozhodnutí a akce:

  • Požadavky na kontrolu: Určete prioritu vytváření sestav na základě známých potřeb a konkrétních otázek, na které byste měli odpovědět.
  • Potvrďte cílové skupiny: Objasněte, kdo bude používat sestavy auditování a jaký bude jejich zamýšlený účel.
  • Vytváření a nasazování sestav: Vývoj první sady základních sestav Postupně je prodlužujte a vylepšujte postupně.
  • Distribuce sestav v aplikaci: Zvažte vytvoření aplikace, která zahrnuje všechny sestavy auditování a monitorování.
  • Ověřte, kdo má přístup k sestavám: Ujistěte se, že jsou sestavy (nebo aplikace) zpřístupněny správné sadě uživatelů.
  • Vytvořte smyčku zpětné vazby: Ujistěte se, že existuje způsob, jak uživatelům sestav poskytnout zpětnou vazbu nebo návrhy nebo nahlásit problémy.

Provedení akce na základě dat

Data auditování jsou cenná, protože vám pomáhají pochopit, co se děje ve vašem tenantovi Power BI. I když to může vypadat jako zřejmé, můžete snadno přehlédnout explicitně to, co se naučíte z dat auditu. Proto doporučujeme, abyste místo kontroly sestav auditování přiřadili někoho, kdo zodpovídá za sledování měřitelných vylepšení. Tímto způsobem můžete v Power BI provádět postupné měřitelné pokroky v přijetí a úrovni vyspělosti .

Na základě vašich cílů a toho, co se naučíte z dat auditování, můžete provádět mnoho různých akcí. Zbývající část této části obsahuje několik nápadů.

Využití obsahu

Tady jsou některé akce, které můžete provést na základě způsobu použití obsahu.

  • Obsah se často používá (denně nebo týdně): Ověřte, jestli je veškerý kritický obsah certifikovaný. Ověřte, že je vlastnictví jasné a že řešení je dostatečně podporované.
  • Vysoký počet zobrazení pracovního prostoru: Pokud dojde k vysokému počtu zobrazení pracovního prostoru, prozkoumejte, proč se aplikace Power BI nepoužívají.
  • Obsah se používá zřídka: Obraťte se na cílové uživatele a zjistěte, jestli řešení vyhovuje jejich potřebám, nebo jestli se změnily jejich požadavky.
  • Aktivita aktualizace se vyskytuje častěji než zobrazení: Obraťte se na vlastníka obsahu a zjistěte, proč se sémantický model pravidelně aktualizuje bez nedávného použití sémantického modelu nebo souvisejících sestav.

Aktivity uživatelů

Tady jsou některé akce, které můžete provést na základě aktivit uživatelů.

  • První akce publikování od nového uživatele: Určete, kdy se typ uživatele změní od uživatele na tvůrce, který můžete identifikovat při prvním publikování obsahu. Je to skvělá příležitost poslat jim standardní e-mail, který poskytuje pokyny a odkazy na užitečné zdroje informací.
  • Zapojení s nejčastějšími tvůrci obsahu: Pozvěte své nejaktivnější tvůrce, aby se připojili k síti šampionů nebo se zapojili do komunity praxe.
  • Správa licencí: Ověřte, jestli neaktivní tvůrci stále potřebují licenci Pro nebo PPU.
  • Aktivace zkušební verze uživatele: Aktivace zkušební licence vás může vyzvat k přiřazení trvalé licence uživateli před ukončením zkušební verze.

Příležitosti pro školení uživatelů

Tady je několik příležitostí pro školení uživatelů, které můžete identifikovat z dat auditování.

  • Velký počet sémantických modelů publikovaných stejným tvůrcem obsahu: Naučíte uživatele o sdílených sémantických modelech a proč je důležité vyhnout se vytváření duplicitních sémantických modelů.
  • Nadměrné sdílení z osobního pracovního prostoru: Obraťte se na uživatele, který provádí velké množství sdílení ze svého osobního pracovního prostoru. Naučíte je o standardních pracovních prostorech.
  • Významná zobrazení sestavy z osobního pracovního prostoru: Obraťte se na uživatele, který vlastní obsah s vysokým počtem zobrazení sestav. Naučíte je, jak jsou standardní pracovní prostory lepší než osobní pracovní prostory.

Tip

Můžete také vylepšit trénovací obsah nebo dokumentaci tím, že si projdete otázky zodpovězené interní komunitou Power BI a problémy odeslané na helpdesk.

Zabezpečení

Tady je několik situací zabezpečení, které můžete chtít aktivně monitorovat.

Další informace najdete v článcích o plánování zabezpečení.

Zásady správného řízení a zmírnění rizik

Tady je několik situací, se kterými se můžete setkat. Zvažte explicitní vyhledání těchto typů situací v sestavách auditování, takže jste připraveni rychle jednat.

  • Vysoký počet zobrazení pro sestavy (a základní sémantické modely), které nejsou schválené.
  • Významné použití neznámých nebo neschválené zdroje dat
  • Umístění souborů, která nejsou v souladu s pokyny pro zásady správného řízení pro umístění zdrojových souborů
  • Názvy pracovních prostorů nejsou v souladu s požadavky zásad správného řízení.
  • Popisky citlivosti se používají k ochraně informací.
  • Konzistentní selhání aktualizace dat
  • Významné a opakované použití tisku.
  • Neočekávané nebo nadměrné používání předplatných
  • Neočekávané použití osobních bran.

Konkrétní akce, které se mají provést v každé situaci, budou záviset na vašich zásadách správného řízení. Další informace najdete v tématu Zásady správného řízení v plánu přechodu na prostředky infrastruktury.

Kontrolní seznam – Při plánování potenciálních akcí na základě dat auditování patří klíčová rozhodnutí a akce:

  • Objasnění očekávání: Vytváření sestav auditování s jasnou sadou očekávání pro očekávané akce.
  • Zpřehledněte, kdo bude zodpovědný za akce: Ujistěte se, že jsou přiřazeny role a zodpovědnosti.
  • Vytvoření automatizace: Pokud je to možné, automatizujte známé akce, které se dají opakovat.
  • Použijte sledovací systém: Pomocí systému můžete sledovat pozorovanou situaci, včetně kontaktu, další plánované akce, zodpovědného, řešení a stavu.

Fáze 4: Údržba, vylepšení a monitorování

Čtvrtá fáze plánování a implementace řešení auditování na úrovni tenanta se zaměřuje na údržbu, vylepšení a monitorování. V tuto chvíli se vaše řešení auditování používá v produkčním prostředí. Teď se primárně zabýváte údržbou, vylepšováním a monitorováním řešení.

Vývojový diagram popisující fázi 4, který se zaměřuje na údržbu, vylepšení a monitorování řešení auditování na úrovni tenanta.

Zprovoznění a zlepšení

Procesy auditování se obvykle považují za spuštěné v produkčním prostředí , když se dokončí počáteční vývoj a testování a proces jste automatizovali. Automatizované procesy auditování běžící v produkčním prostředí mají větší očekávání (než ruční procesy) pro kvalitu, spolehlivost, stabilitu a podporu.

Byl zprovozněn proces auditování na úrovni produkčního prostředí. Zprovozněné řešení obvykle zahrnuje řadu následujících charakteristik.

  • Zabezpečení: Přihlašovací údaje se ukládají a spravují bezpečně. Skripty neobsahují hesla ani klíče ve formátu prostého textu.
  • Plánování: Je zaveden spolehlivý systém plánování.
  • Správa změn: Použití postupů správy změn a více prostředí slouží k zajištění ochrany produkčního prostředí. Můžete také pracovat s vývojovými a testovacími prostředími nebo jenom s vývojovým prostředím.
  • Podpora: Tým, který řešení podporuje, je jasně definovaný. Členové týmu jsou vyškoleni a rozumí provozním očekáváním. Členové zálohování jsou identifikováni a křížové trénování proběhne v případě potřeby.
  • Upozorňování: Když se něco nepovede, upozorní tým podpory automaticky. Pokud možno upozornění zahrnuje protokoly i e-maily (místo jenom e-mailu). Protokol je užitečný pro analýzu protokolovaných chyb a upozornění.
  • Protokolování: Procesy se protokolují, takže historie dat auditování byla aktualizována. Protokolované informace by měly zaznamenávat počáteční čas, koncový čas a identitu uživatele nebo aplikace, která proces spustila.
  • Zpracování chyb: Skripty a procesy řádně zpracovávají a protokolují chyby (například jestli se mají okamžitě ukončit, pokračovat nebo počkat a zkusit to znovu). Oznámení o upozorněních se posílají týmu podpory, když dojde k chybě.
  • Standardy kódování: Vhodné techniky kódování, které dobře fungují, se používají. Smyčky se například záměrně vyhýbají s výjimkou případů, kdy je to nutné. Používají se konzistentní standardy kódování, komentáře, formátování a syntaxe, aby bylo snazší udržovat a podporovat řešení.
  • Opakované použití a modularizace: Aby se minimalizovala duplicita, kód a konfigurační hodnoty (například připojovací řetězec nebo e-mailové adresy pro oznámení), aby je mohly opakovaně používat jiné skripty a procesy.

Tip

Nemusíte dělat všechno uvedené výše najednou. Když získáte zkušenosti, můžete postupně vylepšit řešení tak, aby se dokončilo a bylo robustní. Mějte na paměti, že většina příkladů, které najdete online, jsou jednoduché jednorázové fragmenty skriptů, které nemusí být v produkční kvalitě.

Kontrolní seznam – Při plánování zprovoznění a zlepšení řešení auditování zahrnují klíčová rozhodnutí a akce:

  • Posouzení úrovně existujících řešení: Určete, jestli existují příležitosti ke zlepšení a stabilizaci stávajících řešení auditování, která jsou automatizovaná.
  • Vytvoření standardů na úrovni produkce: Rozhodněte se, jaké standardy chcete mít pro vaše automatizované procesy auditování. Faktorem vylepšení, která můžete v průběhu času realisticky přidat.
  • Vytvořte plán pro zlepšení: Naplánujte zlepšení kvality a stability řešení pro auditování výroby.
  • Určete, zda je nezbytné samostatné vývojové prostředí: Posouzení úrovně rizika a závislost na produkčních datech. Rozhodněte se, kdy vytvořit samostatná vývojová a produkční (a testovací) prostředí.
  • Zvažte strategii uchovávání dat: Určete, jestli potřebujete implementovat proces uchovávání dat, který data vyprázdní po určité době, nebo na žádost.

Dokumentace a podpora

Dokumentace a podpora jsou důležité pro jakékoli řešení na úrovni produkčního prostředí. V závislosti na cílové cílové skupině a účelu je užitečné vytvořit několik typů dokumentace.

Technická dokumentace

Technická dokumentace se zaměřuje na technický tým, který řešení sestavil a který bude postupně řešení v průběhu času vylepšovat a rozšiřovat. Je to také užitečný zdroj pro tým podpory.

Technická dokumentace by měla zahrnovat:

  • Shrnutí komponent architektury a požadavků
  • Kdo vlastní a spravuje řešení.
  • Kdo řešení podporuje.
  • Diagram architektury
  • Rozhodnutí o návrhu, včetně cílů, důvodů, proč byly provedeny určité technické volby, a omezení (například náklady nebo dovednosti).
  • Rozhodnutí o zabezpečení a volby.
  • Používá se zásady vytváření názvů.
  • Kódování a technické standardy a pokyny.
  • Požadavky na správu změn
  • Pokyny k nasazení, nastavení a instalaci
  • Známé oblasti technického dluhu (oblasti, které je možné zlepšit, pokud je k tomu příležitost).

Podpůrná dokumentace

V závislosti na úrovni závažnosti vašeho řešení auditování může nastat naléhavé problémy technické podpory nebo tým podpory. Můžou být k dispozici celý den, každý den.

Dokumentace podpory se někdy označuje jako znalostní báze nebo runbook. Tato dokumentace je zaměřená na helpdesk nebo tým podpory a měla by zahrnovat:

  • Pokyny k řešení potíží s chybou v případě, že se něco nepovede Například pokud dojde k selhání aktualizace dat.
  • Akce, které se mají provést průběžně. Může například existovat několik ručních kroků, které musí někdo pravidelně provádět, dokud se problém nevyřeší.

Dokumentace k tvůrci obsahu

Z řešení auditování odvozujete větší hodnotu tím, že poskytnete analýzy využití a přijetí jiným týmům v celé organizaci (v případě potřeby se vynucuje zabezpečení na úrovni řádků).

Dokumentace k tvůrci obsahu je určená pro samoobslužné tvůrce obsahu, kteří vytvářejí sestavy a datové modely, které vytvářejí kurátorovaná data auditování. Obsahuje informace o datovém modelu, včetně běžných definic dat.

Kontrolní seznam – Při plánování dokumentace a podpory pro vaše řešení auditování zahrnují klíčová rozhodnutí a akce:

  • Ověřte, kdo má řešení podporovat: Určete, kdo bude podporovat řešení auditování, která se považují za produkční úroveň (nebo mají závislosti podřízené sestavy).
  • Zajištění připravenosti týmu podpory: Ověřte, že je tým podpory připravený na podporu řešení auditování. Zjistěte, jestli existují nějaké mezery připravenosti, které potřebují řešit.
  • Uspořádejte si křížové školení: Pro tým podpory proveďte relace přenosu znalostí nebo relace křížového trénování.
  • Objasnění očekávání týmu podpory: Ujistěte se, že jsou jasně zdokumentovaná a komunikovaná očekávání pro odpověď a řešení. Rozhodněte se, jestli někdo musí být na volání, aby rychle vyřešil problémy související s řešením auditování.
  • Vytvoření technické dokumentace: Vytvoření dokumentace k technické architektuře a rozhodování o návrhu
  • Vytvoření dokumentace podpory: Aktualizujte znalostní bázi helpdesku tak, aby obsahovala informace o tom, jak řešení podporovat.
  • Vytvoření dokumentace pro tvůrce obsahu: Vytvoření dokumentace, která pomáhá samoobslužným tvůrcům používat datový model. Popis běžných definic dat za účelem zlepšení konzistence jejich použití

Povolení upozorňování

Můžete chtít vyvolat výstrahy na základě konkrétních podmínek v datech auditování. Můžete například vyvolat upozornění, když někdo odstraní bránu nebo když správce Power BI změní nastavení tenanta.

Další informace najdete v tématu Monitorování na úrovni tenanta.

Průběžná správa

Potřebujete provádět průběžnou správu celého řešení auditování. Možná budete muset rozšířit nebo změnit řešení auditování v případech, kdy:

  • Organizace zjišťuje nové požadavky na data.
  • Nové události auditu se zobrazují v nezpracovaných datech, která přesně znáte z rozhraní REST API Power BI.
  • Microsoft provádí změny rozhraní REST API Power BI.
  • Zaměstnanci identifikují způsoby, jak řešení vylepšit.

Důležité

Zásadní změny jsou vzácné, ale mohou nastat. Je důležité, abyste měli k dispozici někoho, kdo může v případě potřeby rychle řešit problémy nebo aktualizovat řešení auditování.

Kontrolní seznam – Při plánování průběžné správy řešení auditování zahrnují klíčová rozhodnutí a akce:

  • Přiřazení technického vlastníka: Ujistěte se, že existuje jasné vlastnictví a odpovědnost za celé řešení auditování.
  • Ověřte, že existuje záloha: Ujistěte se, že existuje technický vlastník zálohy, který se může zapojit, pokud dojde k naléhavému problému, který podporu nedokáže vyřešit.
  • Udržujte systém sledování: Ujistěte se, že máte způsob, jak zachytit nové žádosti a způsob, jak stanovit prioritu okamžitých priorit, a také krátkodobé, střednědobé a dlouhodobé (backlogové) priority.

Související obsah

V dalším článku v této sérii se dozvíte o monitorování na úrovni tenanta.