Delfíni na vlnách: Komplexní přehled možností zabezpečení Power BI ve 30 minutách
Jakub Holubec: Dobrý den, dámy a pánové, vítám vás u dalšího dílu našeho podcastu delfíni na vlnách. Já jsem Jakub Holubec ze společnosti dolphin consulting a dneska je tady se mnou opět Petr Kolář. Ahoj Petře.
Petr Kolář: Ahoj Jakube.
Jakub Holubec: Dnešním tématem bude zabezpečení v Power BI, protože je to oblast, na kterou nám přichází ohromná spousta dotazů, a tak jsme se rozhodli toto téma trošku rozvést. Petře, začal bych techničtější stránkou. Jakým způsobem vypadá zabezpečení Power BI z pohledu platformy, architektury, nastavení tenantu a co všechno je nutné udělat, aby to prostředí bylo zabezpečené.
Petr Kolář: Power BI je součástí Fabric a zabezpečení má udělané stejně jako ostatní nástroje či součástí Fabricu. Z pohledu nastavení platformy je podstatné, jak důsledně je nastavený tenant. Aktuálně je v nastavení té sekce, která se týká Power BI, více než 100 různých voleb a některé z nich jsou velmi zásadní. Většina z nich je již nastavena od Microsoftu, ale stojí za to popřemýšlet o tom, jestli některé volby nezměnit a nepřestavět.
Jakub Holubec: Jakým způsobem to udělat? Co je potřeba nastudovat k tomu, aby to člověk mohl měnit?
Petr Kolář: U těch jednotlivých voleb přímo v nastavení Power BI administrátora jsou vždy vysvětlivky a jsou tam odkazy na nápovědy. Takže pokud se prochází ten seznam tak je z toho poměrně dobře zřejmé, co ty jednotlivé volby znamenají. Samozřejmě stojí za to prohledat dokumentaci a domyslet všechny důsledky veškerých nastavení. Je dobré, když se toho účastní někdo, kdo má s Power BI již zkušenost.
Jakub Holubec: Jasně, mohl by se zkusit vypíchnout jednu, dvě, tři opravdu podstatné věci, které si myslíš, že by se na ně měl člověk při nastavování zaměřit a nenechat je jenom tak, jak byly v originále?
Petr Kolář: Určitě nejenom to, co je důležité, ale i to, co se mění v čase. Tím, že Power BI se dostal přímo do rodiny v Fabric, tak i do všech nastavení se dostaly volby, které přímo souvisí s Fabric. To znamená například umožnění nebo zakázání uživatelům vytvářet Fabric Items. Bez nich se určitě dá v pohodě pracovat v Power BI prostředí a je možné všechny ty další položky, které souvisí s Fabric a nejsou přímo potřeba pro Power BI, nechat zakázané, dokud firma nepřejde na Fabric.
Nejzásadnější témata, která řešíme s klienty, jsou například kdo vůbec bude mít oprávnění zakládat workspace. Jestli to bude nějaká úzce vymezená skupina uživatelů, kteří budou vědět, co to vlastně znamená a komu, jak a co zpřístupnit. Určitě je důležité zvážit použití externích uživatelů a externích dat, a to ať už ve smyslu, jestli externí uživatelé můžou přistupovat k internímu reportingu a naopak. A co se týče přístupnosti dat také. Jestli můžeme čerpat data zvenčí, anebo interní data můžou být čerpána ven. To jsou, myslím, zásadní věci.
Jakub Holubec: Nejčastější věc, kterou určitě budou úplně všichni řešit v Power BI, je přístup k reportům. Jak zabezpečit, aby správní lidé mohli ke správným reportům, naopak aby lidé nemohli k reportům, na které nemají práva, a jak to udělat tak, aby se to co nejjednodušeji a nejlépe spravovalo?
Petr Kolář: Veškerý obsah, který je v Power BI, je dělen do workspace, do pracovních prostorů. Úplnou novinkou je, že Microsoft umožnil vytvářet složky uvnitř workspace a to až do deseti úrovní. Je to udělané dokonce tak, že pokud je reportní obsah rozdělen do složek a používá se deployment pipeline, to znamená kanály nasazení z devu do testu do produkce nebo dalších stage, takže přebírají tu složkovou strukturu.
No a uvnitř každého workspace jsou nastavení. Mám čtyři úrovně přístupu k danému workspace.
Roli administrátora má typicky ten, kdo přiděluje oprávnění dalším lidem a řeší ty nejdůležitější problémy. Nejběžnější rolí je Viewer, to znamená uživatel, který jen konzumuje obsah. K tomu se dá případně přidělit právo Build, což znamená, že může sestavovat svoje vlastní reporty nebo napojit svůj vlastní Excel na vypublikované datasety. Může mít také právo Reshare, aby mohl sdílet reporty někomu jinému, což může být ošemetné, pokud je do toho zabudována row-level security – to si řekneme asi později.
Mezitím jsou dvě role, Contributor a Member, což je pro standardní vývojáře reportů. Liší se tím, kdo z nich může aktualizovat a vytvářet aplikace a jakým způsobem může přebírat práci ostatních lidí a ovlivňovat ji. Takže ten přístup je řešen těmito čtyřmi rolemi.
Pokud se ve firmě rozhodne, že budou používány Power BI aplikace pro čtenáře reportů, což je určitě doporučovaná a preferovaná varianta, tak typicky pro ty jednotlivé role vytváříme AD skupiny, tzv. Security groups. Speciální skupina je vytvořena i pro čtenáře aplikací. Eventuálně uvnitř těchto aplikací lze vytvořit tzv. cílové skupiny, což znamená sady jednotlivých reportů, dashboardů a stránkovaných reportů pro nějakou skupinu lidí, a oni pak mají právo vidět příslušný obsah.
Jakub Holubec: Abych to tedy shrnul: Úplně primární nastavení jsou práva na workspace, abych mohl vůbec vidět reporty, které jsou v rámci toho workspace, ano?
Petr Kolář: Z pohledu vývojáře ano, z pohledu čtenáře je dobré buď použít tu variantu, že mám přístup do workspace a potom vidím veškerý obsah Power BI aplikace, anebo nemám žádný přístup do workspace a mám přístup jenom do aplikace a do příslušné cílové skupiny. Pak vidím jen to, co mi bylo přiřazeno.
Jakub Holubec: Jasně, takže řídím přístup buď k celému workspace, což dědí všech reporty, které tam jsou, nebo pomocí těch aplikací nastavím oprávnění jen některým reportům z daného workspace.
Petr Kolář: Ano, pomocí aplikace je doporučovaný a nejlepší způsob, protože pomáhá s nasazováním reportů a oddělováním toho, co se aktuálně publikováno v reportu, od toho, co už je vidět v aplikaci. Nemluvili jsme tu o přímém sdílení konkrétního datasetu, reportu nebo dashboardu, což se už moc nepoužívá, protože je to spojeno s velkou údržbou – udržovat, který konkrétní report kdo vidí, a v okamžiku, kdy se reporty třeba vymění, je potřeba to obstarávat.
Jakub Holubec: Když jsi zmínil ty foldery, tak je možné nastavovat zabezpečení ještě navíc na úrovni jednotlivých folderů, nebo je to jen organizační záležitost?
Petr Kolář: Toto nemá souvislost se zabezpečením.
Jakub Holubec: Takže jde jen o to, jak si zorganizuji reporty v rámci workspace, ale ne jak je takto zabezpečit.
Petr Kolář: Dá se nastavit, kdo má oprávnění vytvářet ty složky, ale nemá to apriori souvislost se security. Tato funkce je zatím v preview, takže složky jsou už vidět v Power BI Service a jsou vidět i v mobilní aplikaci, ale zatím například v Power BI Desktopu nejde publikovat přímo do složek. Ale je to věc, která se bude určitě rozvíjet, protože spousta klientů měla ve workspace mnoho obsahu a špatně se v tom orientovalo.
Jakub Holubec: Jaká je best practice z pohledu toho, na jaký detail workspace a případně další zabezpečovat? Většina firem má nastaveno, že se zabezpečuje na úrovni skupin v Active Directory. Takže zařazení uživatele do skupiny se děje na úrovni administrace a potom si Power BI jen přebírá tyto skupiny. Power BI ale ještě určtiě umožňuje ta práva dávat individuálně jednotlivým uživatelům a umožňuje i vytvářet vlastní skupiny uživatelů v rámci Power BI, nebo ne?
Petr Kolář: Základem, který se používá ve větších firmách, je, že jakmile se vytvoří workspace, automaticky se vytvářejí i ty Security groups pro jednotlivé role uživatelů, případně i pro Power BI aplikaci. Do nich je pak někomu konkrétnímu přidělen přístup, aby tam mohl přidávat konkrétní uživatelé a už to nutně nebylo v rukách nějakých Power BI administrátorů, ale měl to ve své moci business oddělení.To je ta nejjednodušší cesta. Z druhé strany, pokud se vytváří tyto AD skupiny automaticky, tak spousta z nich může být nenaplněná, jakože do nich není přidán vůbec nikdo. A pokud takových AD skupin máme desetitisíce nebo statisíce ve firmě, tak to samozřejmě zpomaluje celé řešení a dělá ho složitější. Souvisí to i s tím, jakou jmennou konvenci zvolíme pro jednotlivé workspace, pro jednotlivé AD skupiny.
Co se týče přidělávání oprávnění jednotlivých uživatelům, tak určitě je možné sdílet konkrétním uživatelům, ale s tím spojená ta maintenance. To znamená, pokud někdo je deaktivován uvnitř Active Directory, tak co se vlastně stane? Ztratí přístup hned nebo později? Když někdo přejde třeba do jiného týmu, ale zároveň má ještě týden-dva vidět data ze svéhoTop of FormBottom of Form předchozího týmu, aby pomáhal?
Takže role AD skupin je určitě klíčová pro sdílení reportů, toho, kdo co vlastně vidí, buď ve workspace nebo v Power BI aplikaci. A může být použita i pro takzvanou row-level security nebo object-level security pro statické role.
Ale pokud začneme mluvit o dynamické row-level security, tak ta už je řízená na úrovni konkrétních uživatelů a je potřeba mít někde uložený seznam konkrétních emailových adres a jejich konkrétních oprávnění. A kde je to uloženo, jakým způsobem je to obstaráváno, jak často se aktualizuje tenhleten seznam, i pro účely Power BI reportingu, to je otázka další.
Jakub Holubec: Teď jsme se bavili o zabezpečení celých reportů, tak bych přešel k zabezpečení dat. První otázka z této oblasti je, že každá firma má nějaké úrovně klasifikace dat podle toho, jak jsou tajná, veřejná, senzitivní a podobně. Podporuje tento způsob i Power BI?
Petr Kolář: Ano, Power BI podporuje úplně stejný způsob jako ostatní office aplikace. To znamená, že takzvané popisky citlivosti nebo-li sensitivity labels jsou definovány ve firemním Compliance Centru, tak stejně tak mohou být používány i pro platformu Power BI. Tyto popisky citlivosti se nastavují už i v Power BI Desktopu pro jednotlivé datové zdroje. Po vypublikováním Power BI sémantického modelu je možné pro ně nastavit popisky citlivosti, které dokonce mohou být i odlišné. A samozřejmě pokud se daný report duplikuje z vývoje do testu a nakonec do produkce, tak tam ty sensitivity labels mohou být na jiné úrovni a celé to funguje úplně stejně jako v Office. Nejzásadnější je, že jednak ty popisky citlivosti jsou vidět, když se dívám na report. Můžu se tam nastavit i watermarky a podobné věci, ale zásadní je, že pokud budou data exportována, tak ta vyexportovaná data v sobě mají ten popisek citlivosti, který říká, kdo vlastně ten soubor dat může otevřít a jakým způsobem ho může využívat. Tam je důležité si uvědomit, jaké soubory vlastně umí držet ten popisek citlivosti. Určitě to jsou excelové soubory, jsou to PDF soubory, ale třeba to není csv. Je tedy určitě dobré zapřemýšlet o tom, jestli povolíme vůbec exportovat ve formátu csv nebo ve formátu Wordu a podobně.
Jakub Holubec: Klasifikační skupiny se také přiřazují AD skupinám? Což znamená, že když jsem členem určité skupiny, mám práva jen na data s odpovídající klasifikací?
Petr Kolář: Ano, toto je záležitost Compliance Center, kde mohu definovat, kdo co může dělat v rámci jaké sensitivity label úrovně.
Jakub Holubec: Můžu tam tedy nastavit, kdo má jaká práva a jak se chová systém, když si otevřu report obsahující data s vyšší úrovní citlivosti, než na kterou mám práva?
Petr Kolář: Tak uživatel by ho vůbec neměl otevřít.
Jakub Holubec: Takže když se pokusím otevřít report s daty, na která nemám práva, systém mi zobrazí hlášku, že není možné tento report otevřít.
Petr Kolář: Sensitivity labels nejsou o přístupu k samotným reportům, ale o tom, co s těmi daty na reportu mohu dělat. To znamená, zda je mohu vyexportovat, v jaké podobě a co s nimi dále mohu dělat. Například jestli mohu data použít jako přílohu e-mailu, zda je mohu otevřít v Excelu a jestli je mohu sdílet prostřednictvím firemního nebo soukromého e-mailu.
Jakub Holubec: Vždycky mám report postavený na nějakém datasetu, a v tom datasetu je podstatně více dat – tabulek a sloupců, než co je v samotném reportu. Většinou to tak je, i když ne vždy. Mohu také řídit zabezpečení na této úrovni? Aby uživatel, který chce do reportu něco přidat nebo jej editovat, aby viděl jen ty skupiny dat, tabulek a sloupců, na které má práva?
Petr Kolář: Určitě ano, není to ale záležitost všech reportů. Řekl bych, že tak v polovině reportů toto téma řešíme. Je to o definování rolí zabezpečení, které mohou být jednoduše nastaveny v Power BI Desktop jako row-level security. Případně můžeme nastavit i object-level security, což se stále nastavuje pomocí externích toolů, například programu Tabular. Funguje to tak, že na úrovni každé tabulky mohu pomocí row-level security určit, který uživatel vidí které řádky. Toto zabezpečení se může přenášet i relačními vztahy do dalších tabulek.
Pro definici rolí používám DAXové výrazy, takže pro vyhodnocení, který řádek má uživatel vidět nebo nevidět, mohu libovolně vytahovat data z jiných tabulek a mít to komplexně nastavené, včetně struktur uživatelů a organizačních struktur.
Jakub Holubec: A to už se bavíme o row-level security, tedy o zabezpečení na úrovni řádku. Mě zajímalo, jestli můžu na úrovni objektů určit, že určitý uživatel nevidí například konkrétní sloupec.
Petr Kolář: Tomu se říká object-level security a nastavuje se to například v programu jako je Tabular. Jde o to, že mohu pro každou tabulku nebo jakýkoliv sloupec tabulky nastavit, jestli ho daná role vidí nebo nevidí. Pokud tedy uživatel nemá oprávnění vidět sloupec nebo tabulku, tak je skutečně nevidí. A pokud nějaký vizuál v reportu využívá ten daný sloupec nebo výpočet z něj, nemůže být vyhodnocen, čili vizuál ukáže, že nemůže být zobrazen, protože uživatel nemá přístup k danému sloupci nebo tabulce.
Jakub Holubec: Funguje na této úrovni i něco jako maskování, ve smyslu, že by uživatel sice viděl sloupec, ale neviděl by jeho obsah? Například aby šlo zamaskovat jméno a příjmení klienta?
Petr Kolář: To je potřeba udělat na úrovni databáze. Co jsme schopni na úrovni Power BI udělat je to, že nebudeme sloupce zakazovat pomocí object-level security, ale že jednoduše rozdělíme tabulku na více částí, které propojíme jedna ku jedné. A v některých tabulkách pomocí row-level security zakážeme vidět data z daného sloupce.
Typickým příkladem může být informace o uživatelích, kde mě zajímá e-mailová adresa, možná oprávnění těch lidí, možná nějaké necitlivé informace. Ale pokud budu mít o uživatelích i informace o jejich platu, odměnách a podobně, tak jsou to citlivější informace, které můžu mít v jiné tabulce, kde budu mít daleko restriktivněji nastavenou row-level security. Podstatné je u toho zvažovat, že pokud pomocí row-level security (RLS) zakážu přístup k datům, uživatel sice sloupec nebo tabulku vidí, ale nevidí v ní data. Může se stát, že nevidí žádná data, ale formálně nad tím budou fungovat vizuály, jejichž výstupy mohou být blank jako výsledek agregace nebo měření. Pokud ale zakážu přístup ke sloupečkům nebo tabulkám pomocí object-level security, může to způsobit, že vizuály budou ukazovat chybu, protože nemají co zobrazit, jelikož příslušný sloupec nevidí.
Jakub Holubec: V řadě firem bylo ještě před nějakými pěti a více lety naprosto běžné, že člověk, který vyvíjel reporty, pracoval na produkčních datech. Tudíž, i když měla společnost velmi dobře propracovanou politiku zabezpečení, ale vývojáři a administrátoři často viděli všechno. Za posledních pět let se to podle mě začalo hodně měnit a dnes se počítá s tím, že i vývojáři by měli vždy vidět jenom vývojová nebo testovací data, a ne ta ostrá data. A až v okamžiku, kdy je report přenesen na produkci, reální uživatelé vidí ostrá data. Jakým způsobem je tohle zabezpečené v Power BI?
Petr Kolář: Na datové úrovni je to řešeno v datových zdrojích. To znamená, že můžu mít databázové views, které obsahují developerská data, a jiné views, které obsahují produkční data. Uživatel Power BI, tedy vývojář reportu, se prostě napojuje na příslušná data, která má vidět. Často je potřeba zabezpečit, aby vývojáři nepracovali s produkčními daty a případně nepřetěžovali produkční databázi. Ve vývojářských nebo testovacích datech může být menší množství dat, což může pro vývoj reportu pomáhat. Jde jenom o to, jak dobře je to nasamplované. Pokud mají být data nějakým způsobem anonymizována, je opět dobré to řešit na úrovni databáze.
Je možné to pořešit i pomocí uživatelských přístupů, kde databáze pozná, kdo si žádá o data z prostředí Power BI, a ukáže mu buď produkční data, nebo anonymizovaná data. Z praktického pohledu vývojáře, který vytváří report, pracuji pouze s vývojářskými daty. Vypublikuje report, otestuji si jej ve svém vývojářském prostředí, jestli vše funguje správně, jestli se data vejdou do vizuálů a je to správně naformátované. Tento proces probíhá typicky ve vývojářském prostředí, čili v workspace Dev. Vytvořím si aplikace, abych viděl, jak to vypadá a jak je to z tohoto prostředí přístupné. Další skupina lidí má na starosti testování, protože vývojář svou vlastní práci nikdy nedokáže dokonale otestovat. Tester je speciální profese, která má specifické znalosti. Testeři mají přístup do testovacího workspace a testovací aplikace. Pokud testy projdou, report se pošle do produkce, kde je už nasdílen koncovým uživatelům.
Donedávna se používala pouze tři stadia, tedy Dev, Test a Produkce. Aktuálně je možné vytvořit až deset takovýchto stagů, ale je důležité pečlivě zvážit, aby to nebylo jen administrativní nebo technickou překážkou, ale aby to skutečně dávalo smysl. Postup je následující: Vývojář nemusí mít žádná oprávnění k prohlížení nebo zásahu do testovacího nebo produkčního prostředí, ani v případě hotfixů.
Jakub Holubec: Když vývojář dokončí svou práci ve vývojovém prostředí a přesune ji do testovacího, administrátoři musí provést změny, například přepnutí zdroje z vývojového na testovací., nebo je tento proces zajištěn automaticky v Power BI?
Petr Kolář: Existuje několik možností a nejstandardnější je použití Deployment Pipelines (kanálů nasazení), což je prémiová funkcionalita v Power BI. V rámci nasazování mezi jednotlivými stagy je možné nastavovat pravidla nasazení, která například jednoduše určí, který zdroj dat má být použitý v testovacím prostředí. Anebo lépe – celý tento proces se řeší pomocí parametrů. To znamená, že vývojář, který pracuje s vývojovými daty, se neodkazuje přímo na specifickou databázi nebo soubor Excel umístěný na SharePointu, ale uloží si definici zdroje (např. název databáze, instance, nebo základní URL adresu SharePointu) ve formě parametrů, které pak zakomponuje do dotazu v Power BI. Při nasazení reportu do dalšího stage se pak pravidlo nastaví tak, aby tento parametr nahradil jiným parametrem.
Je důležité poznamenat, že nelze kombinovat pravidla pro zdroje a pravidla pro parametry, proto je vhodné vše řešit pomocí parametrů. Protože běžný report může obsahovat parametry, zejména u větších zákazníků s rozsáhlejšími daty, je běžné, že při vývoji v Power BI Desktopu nemohu pracovat s příliš rozsáhlými daty, jako jsou desítky gigabajtů. Proto mohu nastavit, že při načítání dat z databáze uvidím každý desátý řádek nebo použiji filtr na Top 100 tisíc řádků. Tyto parametry mi umožňují nasamplovat data triviálním způsobem.
Při publikaci do cloudu pak změním tyto parametry tak, aby se načetla všechna dostupná data, což cloudové prostředí zvládne podle přidělené licence. Například, pokud mám licenci Pro nebo Premium, nastavím úroveň parametru podle těchto licencí.
Jakub Holubec: K reportům Power BI nemusím přistupovat jenom v prostředí Power BI, ale můžu je ještě embedovat do jiných aplikací, můžu je dodat do SharePointu nebo úplně zveřejnit… Jak funguje zabezpečení v tomto případě, když se report dostane mimo to standardní prostředí?
Petr Kolář: Pokud ho pošleme do jiné aplikace, která je součástí rodiny Office 365 nebo M365, tak platí stejná security. Uživatelé jsou identifikováni a ověřeni podle přihlašovacích údajů do daného prostředí a musí mít příslušnou licenci. Pokud máme licenci Premium, stačí free licence pro čtení reportů. Pokud tedy zobrazíme report v rámci Teams nebo na SharePointu, tak security funguje stejně jako v Power BI prostředí. Pokud bychom embodovali do jinách aplikací, je důležité security vyřešit. Jestli to jde pomocí credentials toho konkrétního uživatele, nebo se použije non-personal account. Také jsi zmínil vypublikování do veřejných webů, což je věc, kterou typicky ve firmách vypínáme, aby taková možnost nebyla. Pokud se report vypublikuje do veřejného webu jako je například SharePoint, tam není žádné zabezpečení a kdokoliv, kdo získá URL adresu reportu, se do něj může podívat. Tato možnost může dávat smysl například pro naše zákazníky z univerzitního prostředí, kteří chtějí zobrazovat informace veřejně, například na veřejných webových stránkách nebo ve svých prezentacích. Pro citlivá firemní data však tento přístup určitě není správný, a není to způsob, jakým bychom měli uvažovat, aby se ušetřilo na licencích pro přístup. Respektive nastavuje se, kteří uživatelé mají oprávnění toto dělat.
Jakub Holubec: Když už mám to prostředí krásně zabezpečené, tak to je vlastně ten začátek, který musím udělat vždycky. V případě provozu, bych měl sledovat, kteří uživatelé přistupují ke kterým reportům a ke kterým datům. Měl bych to vlastně celé auditovat, abych například v případě ISO auditu nebo jakéhokoliv dalšího GDPR, mohl ukázat přesně, kteří lidé kam přistupovali a kteří mají právo na přístup. Jak je tohle řešené v Power BI?
Petr Kolář: Co se týče senzitivity labelů, existuje služba Pure view. S její pomocí můžu sledovat, kolik firemního datového obsahu je v jaké úrovni zabezpečení, kdo k čemu přistupuje a jak se s takovými daty pracuje.
Co se týče obecného přístupu k reportům, i kdyby nebyly použity sensitivity labels, určité reporty jsou dostupné administrátorovi Power BI tenantu, takže do těchto reportů se může dívat. Nicméně tato jedna osoba typicky nemá čas na řešení takovýchto detailů. Ve větších firmách, v případě použití Premium licence, je možné definovat osoby do role Premium capacity managera nebo Fabric capacity managera. Díky tomu mohou sledovat pomocí aplikace od Microsoftu, kterou stačí nainstalovat a nastavit ID příslušné prémiové kapacity, co se v tam vlastně děje.
Také je možné vidět datové artefakty, jejich velikost, frekvenci refreshů a to, zda refreshe fungují. Dále lze sledovat, kdo má přístup k těmto artefaktům, a jestli je anonymizován přístup k reportům. Tato nastavení lze konfigurovat v Power BI tenantu. A dává to dostatečné informace o využití prémiové kapacity, identifikaci možných výkonnostních nedostatků nebo potenciálního kolapsu z důvodu přetížení dat nebo velkého počtu uživatelů. Co se týče podrobnějších auditu, prostředí Power BI nabízí širokou škálu API REST na nejrůznější informace. Mohu si tak stahovat info o tom, jaké workspaces mám, jaká data, reporty mám a o uživatelích a jejich aktivitách. To znamená, že mohu získat data o tom, kdo si jaké reporty prohlížel, co s nimi dělal. Skrze tyto konektory lze vytvořit robustní sklad informací o aktivitách v Power BI prostředí a na základě toho reportovat.
Důležitý rozdíl oproti nativní Microsoft aplikaci je v tom, že ta udržuje historii pouze po dobu 30 dní, někdy i 90 dní. V tomto případě je možné, že když budu data pravidelně tahat do azure databáze, tak mohu získat dlouhou historii a měřit adopci uživatelů, abych zjistil, zda opravdu začínají používat reporty, a také abych identifikoval nevyužívané reporty či datasety. To mi umožňuje provádět proaktivní řízení v této oblasti.
Jakub Holubec: V této souvislosti mě ještě napadá, že když jsme se bavili o labelování dat, tak to firmy dělají na úrovni data governance nástrojů, kde jsou právě nastavené bezpečnostní labely. Je možné toto labelování automaticky přenést do Power BI? Nebo když mám jen ta auditní data, tak jsem schopný je propojit vzájemně s data governance a sledovat z téhle úrovně, k jak klasifikovaným datům mi uživatelé přístupují.
Petr Kolář: Jsem schopen to propojit. Respektive ten člověk, který používá používá Power Bi, to musí nastavit v Power BI.
Jako uživatel mám přístup k nějakým datům a jsem zodpovědný za to, co s nimi udělám. V Power BI, když si načtu data typicky pomocí Power Query, tak nastavuji i tu senzitivitu dat.
Power BI mi pomáhá v tom, že když mám nastavené jednotlivé datové dotazy, které mohou být i na různých úrovních senzitivity, tak já můžu buď nastavit, že Power BI ignoruje tyto úrovně při svém zpracování, včetně DAX výpočtů pro obchodní data, a mohu provádět jakékoli operace. Naopak, pokud tyto úrovně respektuji, nemohu reálně provést DAX výpočet, který by kombinoval data Prime s organizational úrovní. V okamžiku, kdy report vypublikuji, tak tam nastavuji, jak má být tento report nebo dashboard v cloudu klasifikován, čímž je zajištěno, že odpovídá požadavkům na bezpečnost.
Jakub Holubec: Probrali jsme už docela dost, pokud jde o bezpečnostní aspekty. Ještě mě napadá, co jsme možná zapomněli, nebo co by bylo dobré zmínit?
Petr Kolář: Možná jsme zapomněli zmínit jedno důležité téma ohledně nastavení tenantu a to jsou mapy. Výchozím nastavením je používání map v tenantu zakázáno z několika důvodů. Jedním z hlavních důvodů je, že když na reportu používám data a mapy se mají automaticky zazoomovat podle těchto dat, tak se moje data posílají do cloudu, konkrétně do aplikace map jako jsou Bing Maps nebo TomTom Maps. To může být citlivé a nechtěné, a proto je to obvykle vypnuto.
Nicméně většina firem se nakonec rozhodne povolit používání map, protože má smysl zobrazovat data v různých grafických podobách na mapách. Proto je důležité pečlivě zvážit, jaké druhy map používat. Každý typ mapy nebo vizualizace umí provádět různé funkce, a je možné detailně nastavit, kdo má právo jakým způsobem tyto mapy používat.