Share via

Power BI-implementáció tervezése: Bérlőszintű naplózás

  • Cikk

Feljegyzés

Ez a cikk a Power BI implementációtervezési cikksorozatának része. Ez a sorozat elsősorban a Microsoft Fabricen belüli Power BI-számítási feladatokra összpontosít. A sorozat bemutatása: Power BI implementációtervezés.

Ez a bérlőszintű naplózástervezési cikk elsősorban a következőket célozza:

  • Power BI-rendszergazdák: Azok a rendszergazdák, akik a Power BI felügyeletéért felelősek a szervezetben. Előfordulhat, hogy a Power BI-rendszergazdáknak együtt kell működniük az informatikai, biztonsági, belső auditálási és egyéb releváns csapatokkal.
  • Kiválósági központ, informatikai és BI-csapat: Azok a csapatok, amelyek a Power BI felügyeletéért is felelősek. Előfordulhat, hogy együtt kell működniük a Power BI-rendszergazdákkal és más releváns csapatokkal.

Fontos

Javasoljuk, hogy szorosan kövesse a Power BI kiadási tervét , hogy megismerje a naplózási és monitorozási képességek jövőbeli fejlesztéseit.

A bérlői szintű naplózási megoldás célja a Power BI-bérlőn üzembe helyezett összes felhasználó, tevékenység és megoldás adatainak rögzítése és elemzése. A bérlői szintű naplózási adatok számos szempontból értékesek, így elemezheti a bevezetési erőfeszítéseket, megismerheti a használati mintákat, taníthatja a felhasználókat, támogathatja a felhasználókat, csökkentheti a kockázatokat, javíthatja a megfelelőséget, kezelheti a licencköltségeket, és figyelheti a teljesítményt.

Egy biztonságos és éles üzemre kész, teljes körű naplózási megoldás létrehozása jelentős projekt, amely időt vesz igénybe. Gondoljon rá úgy, mint üzleti intelligencia kiépítésére az üzleti intelligencián (BI on BI). További információ arról, hogy miért olyan értékesek a naplózási adatok, tekintse meg a naplózás és a figyelés áttekintését.

A jelentésszintű naplózást, amely a jelentéskészítőkre irányul, tekintse meg a jelentésszintű naplózást.

Az adat-létrehozóknak szánt adategységek naplózásához lásd az adatszintű naplózást.

A cikk további része a bérlőszintű naplózásra összpontosít.

Tipp.

A cikk elsődleges célja egy végpontok közötti naplózási megoldás létrehozásának megtervezése. Mivel a cikkben szereplő tartalom négy fázisba van rendezve, több fázisban is szüksége lesz információra. Az 1. fázisban például a szolgáltatásnév használatának tervezésével, a 2. fázisban pedig az előfeltételekkel és a beállítással kapcsolatos információk találhatók.

Ezért azt javasoljuk, hogy először olvassa el ezt a teljes cikket, hogy megismerkedjen az érintettekkel. Ezután jól fel kell készülnie arra, hogy iteratív módon tervezze meg és hozza létre a naplózási megoldást.

Ha bérlőszintű naplózási megoldást tervez létrehozni, tervezzen időt tölteni a következő négy fázisban.

1. fázis: Tervezés és döntések

Az első fázis a tervezésre és a döntéshozatalra összpontosít. Számos követelményt és prioritást kell figyelembe venni, ezért azt javasoljuk, hogy töltsön elegendő időt az ebben a szakaszban ismertetett témakörök megértéséhez. A cél az, hogy jó kezdeti döntéseket hozhassunk, hogy az alsóbb rétegbeli fázisok zökkenőmentesen fussanak.

Az 1. fázist leíró folyamatábra, amely a bérlőszintű naplózási megoldás kialakításának tervezésére és döntéseire összpontosít.

Követelmények és prioritások

A kezdeti fázisban a cél a legfontosabbak azonosítása. Koncentráljon a legfontosabb dolgokra, és arra, hogyan fogja mérni a szervezetre gyakorolt hatást. Törekedjen az üzletközpontú követelmények meghatározására a technológiaközpontú követelmények helyett.

Íme néhány kérdés, amire válaszolnia kell.

  • Milyen fontos kérdésekre kell válaszolnia? Nagy mennyiségű naplózási adatot vizsgálhat meg. A naplózás megközelítésének leghatékonyabb módja a konkrét kérdések megválaszolása.
  • Mik a bevezetési és adatkultúra céljai? Lehet például, hogy célja az önkiszolgáló BI-tartalomkészítők számának növelése a szervezetben. Ebben az esetben meg kell mérnie a tartalom létrehozásával, szerkesztésével és közzétételével kapcsolatos felhasználói tevékenységeket.
  • Milyen közvetlen kockázatok állnak fenn? Előfordulhat például, hogy a tartalom túlmegosztása a múltban történt. A felhasználói betanítás azóta tovább bővült, és most folyamatosan szeretné naplózni a biztonsági beállításokat és tevékenységeket.
  • Vannak aktuális fő teljesítménymutatók (KPI-k) vagy szervezeti célok? Lehet például, hogy rendelkezik egy szervezeti KPI-vel, amely kapcsolódik a digitális átalakításhoz, vagy adatvezéreltebb szervezetté válik. A bérlőszintű naplózási adatok segíthetnek annak mérésében, hogy a Power BI-implementáció összhangban van-e ezekkel a célokkal.

Tipp.

Ellenőrizze a naplózási követelményeket, és állítsa be a prioritásokat a vezető szponzorral és a Kiválósági Központtal. Csábító a naplózási adatok kinyerése és a jelentések létrehozása sok érdekes adat alapján. Azonban nem valószínű, hogy magas értéket fog kinyerni a naplózási megoldásból, ha nem a megválaszolandó kérdések és a végrehajtandó műveletek vezérlik.

A naplózási adatok használatának módjával kapcsolatos további ötletekért tekintse meg a naplózás és a figyelés áttekintését.

Ellenőrzőlista – A követelmények és prioritások azonosításakor a legfontosabb döntések és műveletek a következők:

  • Követelmények azonosítása: Gyűjtse össze és dokumentálja a Power BI-bérlő naplózásának legfontosabb üzleti követelményeit.
  • Követelmények rangsorolása: Határozza meg a követelmények prioritását, és sorolja be őket azonnali, rövid távú, közép- és hosszú távú (hátralékként).
  • Tervezze meg az azonnali prioritásokat: Hozzon létre egy tervet az adatok gyűjtésének megkezdéséhez, hogy szükség esetén rendelkezésre álljon.
  • A követelmények rendszeres újraértékelése: Hozzon létre egy tervet a követelmények rendszeres újraértékeléséhez (például évente kétszer). Ellenőrizze, hogy a naplózási és monitorozási megoldás megfelel-e a megadott követelményeknek. Szükség esetén frissítse a terv műveletelemeit.

Adatigények

Miután definiálta a követelményeket és a prioritásokat (korábban leírtuk), készen áll a szükséges adatok azonosítására. Ebben a szakaszban négy adatkategóriát sorolunk fel.

A szükséges adatok többsége a felügyeleti API-kból származik, amelyek számos metaadatot biztosítanak a Power BI-bérlőről. További információ: Felhasználói API vagy rendszergazdai API kiválasztása a cikk későbbi részében.

Felhasználói tevékenység adatai

A felhasználói tevékenységek adatainak lekérése az első prioritás. A felhasználói tevékenységek, amelyeket eseményeknek vagy műveleteknek is neveznek, számos célra hasznosak.

Ezeket az adatokat leggyakrabban tevékenységnaplónak vagy eseménynaplónak nevezzük. Technikailag a felhasználói tevékenység adatainak lekérése többféleképpen is lehetséges (a tevékenységnapló egy módszer). Az érintett döntésekkel és tevékenységekkel kapcsolatos további információkért tekintse meg az Access felhasználói tevékenységadatait a cikk későbbi részében.

Íme néhány gyakori kérdés, amelyekre a felhasználói tevékenység adatai válaszolhatnak.

  • A legnépszerűbb felhasználók és a legnépszerűbb tartalmak megkeresése
    • Milyen tartalmakat tekint meg leggyakrabban és mely felhasználók?
    • Mik a tartalmak megtekintésének napi, heti és havi trendjei?
    • A jelentésnézetek felfelé vagy lefelé trendelnek?
    • Hány felhasználó aktív?
  • A felhasználói viselkedés ismertetése
    • Milyen típusú biztonságot használnak leggyakrabban (alkalmazások, munkaterületek vagy elemenkénti megosztások)?
    • A felhasználók leggyakrabban böngészőket vagy mobilalkalmazásokat használnak?
    • Mely tartalomkészítők a legaktívabban teszik közzé és frissítik a tartalmakat?
    • Milyen tartalmakat tesznek közzé vagy frissítenek, mikor és mely felhasználók?
  • Felhasználói oktatási és képzési lehetőségek azonosítása
    • Ki végez (túl sok) megosztást a személyes munkaterületéről?
    • Ki végez jelentős mennyiségű exportálást?
    • Ki tölt le rendszeresen tartalmat?
    • Ki tesz közzé számos új szemantikai modellt– korábban adatkészleteket?
    • Ki használja nagy mértékben az előfizetéseket?
  • Az irányítási és megfelelőségi erőfeszítések javítása
    • Mikor változnak a bérlői beállítások, és melyik a Power BI-rendszergazda?
    • Ki indította el a Power BI próbaverziót?
    • Milyen tartalmakhoz férnek hozzá külső felhasználók, kik, mikor és hogyan?
    • Ki adott hozzá vagy frissített egy bizalmassági címkét?
    • A jelentésnézetek hány százaléka hiteles szemantikai modelleken alapul?
    • A szemantikai modellek hány százaléka támogat több jelentést?
    • Mikor jön létre vagy frissül egy átjáró vagy adatforrás, és melyik felhasználó?

Az adatok felhasználási módjairól további információt a használati minták ismertetése című témakörben talál.

Fontos

Ha még nem nyeri ki és tárolja a felhasználói tevékenységek adatait, ezt sürgős prioritásként kell kezelnie. Legalább győződjön meg arról, hogy kinyeri a nyers adatokat, és biztonságos helyen tárolja. Így az adatok akkor lesznek elérhetők, ha készen áll az elemzésre. Az előzmények a használt forrástól függően 30 napig vagy 90 napig érhetők el.

További információ: Access felhasználói tevékenység adatai a jelen cikk későbbi részében.

Bérlői leltár

A második prioritás gyakran az adatok lekérése a bérlői leltár létrehozásához. Néha nevezik munkaterület-leltárnak, munkaterület metaadatainak vagy bérlői metaadatoknak.

A bérlői leltár egy pillanatkép egy adott időpontban. Leírja a bérlőben közzétett elemet. A bérlői leltár nem tartalmazza a tényleges adatokat vagy a tényleges jelentéseket. Ehelyett az összes munkaterületet és azok elemeit (például szemantikai modelleket és jelentéseket) leíró metaadatok.

Íme néhány gyakori kérdés, amelyekre a bérlői leltár válaszolhat.

  • Annak megismerése, hogy mennyi tartalommal rendelkezik, és hol
    • Mely munkaterületek rendelkeznek a legtöbb tartalommal?
    • Milyen típusú tartalmat tesznek közzé az egyes munkaterületeken (különösen a jelentéskészítési munkaterületek és adat-munkaterületek elkülönítésekor)?
    • Milyen függőségek léteznek elemek között (például számos szemantikai modellt támogató adatfolyamok vagy más összetett modellek forrásaként szolgáló szemantikai modell) között?
    • Mi az adatsor (a Power BI-elemek közötti függőségek, beleértve a külső adatforrásokat is)?
    • Vannak árva jelentések (amelyek nincsenek leválasztva a szemantikai modelljükről)?
  • A szemantikai modellek és a jelentések arányának megismerése
    • Mennyi szemantikai modell újrafelhasználása történik?
    • Vannak ismétlődő vagy nagyon hasonló szemantikai modellek?
    • Van lehetőség a szemantikai modellek konszolidálására?
  • Az időpontok közötti trendek megismerése
    • Idővel nő a jelentések száma?
    • Idővel nő a szemantikai modellek száma?
  • Nem használt tartalom keresése
    • Mely jelentések nincsenek használatban (vagy nincsenek kihasználva)?
    • Mely szemantikai modellek nincsenek használatban (vagy nem használnak kihasználatlanokat)?
    • Van lehetőség a tartalom kivonására?

A bérlői leltár segítségével az aktuális neveket használhatja az előzménytevékenységek elemzésekor. A bérlő elemeinek pillanatképe az adott időpontban található összes elem nevét tartalmazza. Hasznos lehet az aktuális elemnevek használata az előzményjelentéshez. Ha például egy jelentést három hónappal ezelőtt átneveztek, akkor az akkori tevékenységnapló rögzíti a régi jelentés nevét. Egy megfelelően definiált adatmodellel a legújabb bérlői leltár használatával megkereshet egy elemet az aktuális neve alapján (a korábbi név helyett). További információ: Adatmodell létrehozása a cikk későbbi részében.

A bérlői leltár használatának módjairól további információt a közzétett tartalom ismertetése című témakörben talál.

Tipp.

A teljes kép létrehozásához gyakran kombinálja a felhasználói tevékenység eseményeit (az előző szakaszban leírtakat) és a bérlői leltárt. Így az összes adat értékét növelheti.

Mivel a bérlői leltár pillanatkép egy adott időpontban, el kell döntenie, hogy milyen gyakran kell kinyerni és tárolni a metaadatokat. A heti pillanatképek hasznosak a két időpont közötti összehasonlításhoz. Ha például egy munkaterület biztonsági beállításait szeretné megvizsgálni, szüksége lesz az előző bérlői leltár pillanatképére, a tevékenységnapló eseményeire és az aktuális bérlői leltár pillanatképére.

A bérlői leltár készítésének két fő módja van. Az érintett döntésekkel és tevékenységekkel kapcsolatos további információkért tekintse meg az Access bérlői leltáradatait a cikk későbbi részében.

Felhasználók és csoportok adatai

Az elemzési igények növekedésével valószínűleg meg fogja állapítani, hogy a felhasználókra és csoportokra vonatkozó adatokat szeretné belefoglalni a végpontok közötti naplózási megoldásba. Az adatok lekéréséhez használhatja a Microsoft Graphot, amely mérvadó forrás a Microsoft Entra ID (korábbi nevén Azure Active Directory) felhasználóival és csoportjaival kapcsolatos információkhoz.

A Power BI REST API-kból lekért adatok tartalmazzák a felhasználó vagy egy biztonsági csoport nevét leíró e-mail-címet. Ezek az adatok pillanatképek egy adott időpontban.

Íme néhány gyakori kérdés, amelyekre a Microsoft Graph válaszolni tud.

  • Felhasználók és csoportok azonosítása
    • Mi a felhasználói profilból származó teljes felhasználónév (az e-mail-cím mellett), a részleg vagy a hely?
    • Kik a biztonsági csoportok tagjai?
    • Ki a biztonsági csoport tulajdonosa (a tagok kezeléséhez)?
  • További felhasználói adatok beszerzése
    • Mely licencek – a Power BI Pro vagy a Felhasználónkénti Power BI Premium (PPU) – vannak hozzárendelve a felhasználókhoz?
    • Mely felhasználók jelentkeznek be leggyakrabban?
    • Mely felhasználók nem jelentkeznek be nemrég a Power BI szolgáltatás?

Figyelmeztetés

A felhasználók és csoportok adatainak elérésére szolgáló régebbi módszerek (amelyek széles körben dokumentálva vannak az interneten) elavultak, és nem használhatók. Amikor csak lehetséges, használja a Microsoft Graphot a felhasználók és a csoportok adatainak mérvadó forrásaként.

További információkért és javaslatokért az adatok Microsoft Graph-ból való eléréséről a cikk későbbi részében az Access felhasználói és csoportadatait ismertető cikkben olvashat.

Biztonsági adatok

Előfordulhat, hogy rendszeres biztonsági naplózást kell végeznie.

Íme néhány gyakori kérdés, amelyekre a Power BI REST API-k válaszolhatnak.

Fontos

Ez a cikk időnként a Power BI Premiumra vagy annak kapacitás-előfizetésére (P termékváltozatokra) hivatkozik. Vegye figyelembe, hogy a Microsoft jelenleg összevonja a vásárlási lehetőségeket, és visszavonul a Power BI Premium kapacitásonkénti termékváltozataitól. Az új és a meglévő ügyfeleknek érdemes megfontolni a Fabric-kapacitás-előfizetések (F SKU-k) megvásárlását.

További információ: Fontos frissítés a Power BI Premium licenceléséhez és a Power BI Premiumhoz – gyakori kérdések.

Tipp.

A biztonsággal kapcsolatos további szempontokért tekintse meg a biztonsági tervezéssel kapcsolatos cikkeket.

Ezek a gyakori kérdések nem teljes lista; a Power BI REST API-k széles választéka érhető el. További információ: A Power BI REST API-k használata.

A rendszergazdai API-k és a felhasználói API-k használatáról (beleértve az adatokat kinyerő felhasználó számára szükséges engedélyeket is) a jelen cikk későbbi, felhasználói API-k vagy rendszergazdai API-k kiválasztása című szakaszában talál további információt.

Ellenőrzőlista – A naplózáshoz szükséges adatok azonosításakor a legfontosabb döntések és műveletek a következők:

  • A felhasználói tevékenység adatainak konkrét adatigényeinek azonosítása: Ellenőrizze az összegyűjtött követelményeket. Határozza meg, hogy mely naplózási adatok szükségesek a felhasználói tevékenység adataira vonatkozó minden követelmény teljesítéséhez.
  • A bérlői leltáradatok konkrét adatigényeinek azonosítása: Ellenőrizze az összegyűjtött követelményeket. A bérlői leltár összeállításához szükséges naplózási adatok azonosítása.
  • A felhasználók és csoportok adatainak konkrét adatigényeinek azonosítása: Ellenőrizze az összegyűjtött követelményeket. Határozza meg, hogy mely naplózási adatok szükségesek a felhasználók és csoportok adatainak minden követelményének teljesítéséhez.
  • A biztonsági adatok konkrét adatigényeinek azonosítása: Ellenőrizze az összegyűjtött követelményeket. Határozza meg, hogy mely naplózási adatok szükségesek a biztonsági adatokra vonatkozó követelmények teljesítéséhez.
  • Prioritások ellenőrzése: Ellenőrizze a prioritások sorrendjét, hogy tudja, mit kell először fejlesztenie.
  • Határozza meg, hogy milyen gyakran rögzítse a tevékenységeket: Döntse el, milyen gyakran rögzítse a tevékenységeseményeket (például naponta egyszer).
  • Határozza meg, hogy milyen gyakran készítsen pillanatképeket: Döntse el, hogy milyen időközönként rögzítse a pillanatképadatokat, például a bérlői leltárt vagy a felhasználók és a csoportok adatait.

A naplózási megoldás típusa

A bérlői szintű naplózás manuálisan vagy automatizált folyamatokkal történik.

A legtöbb új naplózási folyamat manuális folyamatként indul el, különösen a fejlesztés és a tesztelés során. A manuális naplózási folyamat automatikus folyamattá válhat. Azonban nem minden naplózási folyamatot kell teljesen automatizálni.

Manuális naplózási folyamatok

A manuális naplózás olyan szkriptekre és folyamatokra támaszkodik, amelyeket egy felhasználó (általában Power BI-rendszergazda) igény szerint futtat. Szükség esetén a felhasználó interaktívan futtat lekérdezéseket a naplózási adatok lekéréséhez.

A manuális naplózás a legmegfelelőbb a következő feladatokhoz:

  • Fejlesztés alatt álló és tesztelt új szkriptek.
  • Alkalmi, egyszeri naplózási igények.
  • Feltáró naplózási igények.
  • Nem alapvető naplózási folyamatok, amelyek nem igényelnek teljes támogatást.

Automatizált naplózási folyamatok

Az ismétlődően szükséges adatok naplózását automatizálni kell. A kinyerése és feldolgozása rendszeres ütemezés szerint történik, és automatizált folyamatnak is nevezik. Néha felügyelet nélküli folyamatnak is nevezik.

Az automatizált folyamatok célja a manuális munka csökkentése, a hibák kockázatának csökkentése, a konzisztencia növelése és az egyes felhasználóktól való függőség megszüntetése a futtatáshoz.

Az automatizált naplózás a legmegfelelőbb a következő műveletekhez:

  • Éles környezetben futó folyamatok naplózása.
  • Felügyelet nélküli folyamatok, amelyek rendszeres ütemezés szerint futnak.
  • Teljesen tesztelt szkriptek.
  • Alapvető naplózási folyamatok, amelyek adatforrásként más jelentésekkel (vagy más folyamatokkal) rendelkeznek.
  • Dokumentált és támogatott naplózási folyamatok.

A folyamat típusa – manuális vagy automatizált – hatással lehet a hitelesítés kezelésére. A Power BI-rendszergazdák például felhasználói hitelesítést használhatnak manuális naplózási folyamathoz, de egy egyszerű szolgáltatást használnak egy automatizált folyamathoz. További információ: A hitelesítési módszer meghatározása a cikk későbbi részében.

Tipp.

Ha rendszeres, ismétlődő, a jelenleg manuálisan kezelt naplózási adatok beszerzésére van szükség, érdemes lehet időt szánni az automatizálásra. Ha például egy Power BI-rendszergazda naponta manuálisan futtat egy szkriptet, hogy adatokat kérjen le a Power BI tevékenységnaplójából, fennáll annak a veszélye, hogy az adott személy beteg vagy szabadságon van.

Ellenőrzőlista – A fejlesztendő naplózási megoldás típusának mérlegelésekor a legfontosabb döntések és műveletek a következők:

  • Határozza meg az egyes új naplózási követelmények elsődleges célját: Döntse el, hogy manuális vagy automatizált folyamatot használ-e minden új követelményhez. Fontolja meg, hogy ez a döntés ideiglenes vagy végleges-e.
  • Hozzon létre egy tervet az automatizáláshoz: Ha egy adott naplózási követelménynek megfelelő, hozzon létre egy tervet, amelyből megtudhatja, hogyan automatizálhatja azt, mikor és ki által.

Engedélyek és felelősségek

Ezen a ponton tisztában kell lennie azzal, hogy mit szeretne elérni, és hogy milyen adatokra lesz szüksége. Itt az ideje, hogy döntéseket hozzon a felhasználói engedélyekről, valamint a szerepkörökről és a felelősségekről.

Felhasználói engedélyek

Amikor egy végpontok közötti naplózási megoldást tervez létrehozni, fontolja meg a felhasználói engedélyeket más felhasználók számára, akiknek hozzá kell férnie az adatokhoz. Pontosabban döntse el, hogy kik férhetnek hozzá és tekinthetik meg a naplózási adatokat.

Íme néhány megfontolandó szempont.

Közvetlen hozzáférés a naplózási adatokhoz

El kell döntenie, hogy ki férhet hozzá közvetlenül a naplózási adatokhoz. Többféleképpen is gondolhat rá.

  • Kinek kell Power BI-rendszergazdának lennie? A Power BI-rendszergazdák hozzáférhetnek az összes bérlői metaadathoz, beleértve a rendszergazdai API-kat is. A Power BI-rendszergazdák kiválasztásával kapcsolatos további információkért tekintse meg a bérlőszintű biztonsági tervezést.
  • Ki használhat meglévő szolgáltatásnevet? Ha szolgáltatásnévvel (felhasználói engedélyek helyett) szeretne hozzáférni a naplózási adatokhoz, titkos kulcsot kell megadnia a jogosult felhasználóknak, hogy jelszóalapú hitelesítést tudjanak végezni. A titkos kódokhoz (és kulcsokhoz) való hozzáférést szigorúan szabályozni kell.
  • Szigorúan kell szabályozni a hozzáférést? Bizonyos szabályozási és megfelelőségi követelményekkel rendelkező iparágaknak szigorúbban kell szabályozni a hozzáférést, mint más iparágakat.
  • Vannak nagy tevékenységadat-kötetek? Az API-szabályozás korlátainak elérése érdekében előfordulhat, hogy szigorúan szabályoznia kell, hogy ki férhet hozzá közvetlenül a naplózási adatokat létrehozó API-khoz. Ebben az esetben célszerű meggyőződni arról, hogy nincsenek ismétlődő vagy átfedésben lévő erőfeszítések.
Hozzáférés a kinyert nyers adatokhoz

El kell döntenie, hogy ki tekintheti meg a kinyert és egy tárolóhelyre írt nyers adatokat. A nyers adatokhoz való hozzáférés leggyakrabban a rendszergazdákra és az auditorokra korlátozódik. A Kiválósági Központhoz (COE) is hozzáférésre lehet szükség. További információ: A naplóadatok tárolásának helye a cikk későbbi részében.

Hozzáférés a válogatott elemzési adatokhoz

El kell döntenie, hogy ki tekintheti meg az elemzésre kész válogatott és átalakított adatokat. Ezeket az adatokat mindig elérhetővé kell tenni a rendszergazdák és az auditorok számára. Előfordulhat, hogy egy adatmodell elérhetővé válik a szervezet többi felhasználója számára, különösen akkor, ha sorszintű biztonságot tartalmazó Power BI szemantikai modellt hoz létre. További információkért lásd a cikk későbbi részében a válogatott adatok létrehozásának tervét.

Szerepkörök és felelősségi körök

Miután eldöntötte, hogyan működnek a felhasználói engedélyek, jó helyzetben van, hogy elkezdjen gondolkodni a szerepkörökről és a felelősségekről. Javasoljuk, hogy korai időben vonja be a megfelelő személyeket, különösen akkor, ha több fejlesztő vagy csapat is részt vesz a végpontok közötti naplózási megoldás elkészítésében.

Döntse el, hogy mely felhasználók vagy csapatok lesznek felelősek a következő tevékenységekért.

Szerepkör A felelősségi körök típusai A szerepkör általában a következő:
Kommunikáció az érdekelt felekkel Kommunikációs tevékenységek és követelmények összegyűjtése. COE az informatikai partnerséggel együttműködve. A fő üzleti egységekből is választhat személyeket.
Határozza meg a prioritásokat, és irányt adjon a követelményeknek A végpontok közötti naplózási megoldással kapcsolatos döntéshozatali tevékenységek, beleértve a követelmények teljesítésének módját is. A power BI-t felügyelő csapat a szervezetben, például a COE-ban. A vezető szponzor vagy az adatkezelési irányító bizottság is részt vehet a kritikus döntések meghozatalában vagy a problémák eszkalálásában.
A nyers adatok kinyerése és tárolása Szkriptek és folyamatok létrehozása az adatok eléréséhez és kinyeréséhez. Magában foglalja a nyers adatok tárolóba írását is. Az adatmérnöki személyzet általában az informatikai területen és a COE-val együttműködve.
A válogatott adatok létrehozása Adattisztítás, átalakítás és a válogatott adatok létrehozása csillagséma-kialakításban. Az adatmérnöki személyzet általában az informatikai területen és a COE-val együttműködve.
Adatmodell létrehozása Elemzési adatmodell létrehozása a válogatott adatok alapján. A Power BI-tartalomkészítő(k) általában az informatikai vagy a COE-ban.
Elemzési jelentések létrehozása Jelentések létrehozása a válogatott adatok elemzéséhez. A jelentések folyamatban lévő változásai az új követelmények alapján és az új naplózási adatok elérhetővé válásakor. Power BI-jelentéskészítő(k), általában az informatikai vagy a COE-ban.
Az adatok elemzése és az eredményekre való reagálás Elemezze az adatokat, és reagáljon a naplózási adatokra. A power BI-t felügyelő csapat a szervezetben, általában a COE-ban. A naplózási eredményektől és a művelettől függően más csapatok is lehetnek. Más csapatok lehetnek például a biztonság, a megfelelőség, a jogi, a kockázatkezelés vagy a változáskezelés.
Tesztelés és ellenőrzés Ellenőrizze, hogy teljesülnek-e a naplózási követelmények, és hogy a bemutatott adatok pontosak-e. Power BI-tartalomkészítő(k) a szervezet Power BI-t felügyelő csapatával együttműködve.
Az adatok védelme Állítsa be és kezelje az egyes tárolási rétegek biztonságát, beleértve a nyers adatokat és a válogatott adatokat is. Az adatok elemzéséhez létrehozott szemantikai modellekhez való hozzáférés kezelése. Az adatokat tároló rendszer rendszergazdája a Power BI szervezeten belüli felügyeletét ellátó csapattal együttműködve.
Ütemezés és automatizálás A megoldás üzembe helyezésével ütemezheti a folyamatot a választott eszközzel. Az adatmérnöki személyzet általában az informatikai területen és a COE-val együttműködve.
A megoldás támogatása Figyelje a naplózási megoldást, beleértve a feladatfuttatásokat, a hibákat és a technikai problémák támogatását. A Power BI rendszertámogatását kezelő csapat, amely általában informatikai vagy coe.

A fenti szerepkörök és felelősségek nagy része konszolidálható, ha ugyanazt a csapatot vagy személyt fogja ellátni. Előfordulhat például, hogy a Power BI-rendszergazdák végrehajtanak néhány szerepkört.

Az is lehetséges, hogy a körülményektől függően a különböző személyek különböző szerepköröket töltenek be. A műveletek környezeti jellegűek lesznek a naplózási adatoktól és a javasolt művelettől függően.

Vegyünk néhány példát.

  • 1. példa: A naplózási adatok azt mutatják, hogy egyes felhasználók gyakran exportálnak adatokat az Excelbe. Végrehajtott művelet: A COE kapcsolatba lép az adott felhasználókkal, hogy megértsék az igényeiket, és jobb alternatívákat tanítsanak nekik.
  • 2. példa: A naplózási adatok azt mutatják, hogy a külső felhasználók hozzáférése váratlan módon történik. Végrehajtott műveletek: Egy informatikai rendszergazda frissíti a külső felhasználók hozzáférésére vonatkozó Microsoft Entra-azonosító beállításait. A Power BI-rendszergazda frissíti a külső felhasználói hozzáféréssel kapcsolatos bérlői beállítást. A COE frissíti a biztonságot kezelő tartalomkészítők dokumentációját és képzését. További információ: Stratégia külső felhasználók számára.
  • 3. példa: A naplózási adatok azt mutatják, hogy több adatmodell eltérően határozza meg ugyanazt a mértéket (a metaadat-ellenőrzési API-kból érhető el, ha a metaadat-bérlő részletes beállításai engedélyezik). Végrehajtott művelet: Az adatszabályozási bizottság elindít egy projektet a közös definíciók meghatározásához. A COE frissíti az adatmodelleket létrehozó tartalomkészítők dokumentációját és betanítását. A COE a tartalomkészítőkkel együttműködve szükség szerint frissíti a modelljeit. A részletes metaadatok lekéréséről a cikk későbbi részében, az Access bérlőleltár-adataiban talál további információt.

Feljegyzés

Az adatkinyerési folyamatok beállítása általában egyszeri munka, alkalmankénti fejlesztésekkel és hibaelhárítással. Az adatok elemzése és az adatokon való működés folyamatos erőfeszítést igényel, amely ismétlődő erőfeszítéseket igényel.

Ellenőrzőlista – Az engedélyek és a felelősségek mérlegelésekor a legfontosabb döntések és műveletek a következők:

  • Határozza meg, hogy mely csapatok vesznek részt: Határozza meg, hogy mely csapatok vegyenek részt a naplózási megoldás végpontok közötti létrehozásában és támogatásában.
  • Felhasználói engedélyek meghatározása: Annak meghatározása, hogy a felhasználói engedélyek hogyan lesznek beállítva a naplózási adatokhoz való hozzáféréshez. A legfontosabb döntések dokumentációjának létrehozása későbbi referenciaként.
  • Szerepkörök és felelősségek meghatározása: Győződjön meg arról, hogy az elvárások egyértelműek, hogy ki mit csinál, különösen akkor, ha több csapat is részt vesz benne. Hozza létre a szerepkörök és a felelősségek dokumentációját, amely tartalmazza a várt műveleteket.
  • Szerepkörök és felelősségek hozzárendelése: Adott szerepkörök és felelősségek hozzárendelése adott személyekhez vagy csapatokhoz. Szükség esetén frissítse az egyes feladatleírásokat az Emberi erőforrások szolgáltatással.
  • Képzési terv létrehozása: Hozzon létre egy tervet a betanítási személyzet számára, ha új készségeket igényelnek.
  • Kereszttanúsítási terv létrehozása: Győződjön meg arról, hogy a kereszttanítás és a biztonsági másolatok a fő szerepkörökhöz is elérhetők.

Technikai döntések

Ha bérlőszintű naplózási megoldást tervez, fontos technikai döntéseket kell hoznia. A konzisztencia javítása, az átdolgozás elkerülése és a biztonság javítása érdekében javasoljuk, hogy a lehető leghamarabb hozza meg ezeket a döntéseket.

Az első tervezési fázis a következő döntések meghozatalát foglalja magában.

Válasszon ki egy technológiát a naplózási adatok eléréséhez

Az első dolog, amit el kell döntenie, hogy hogyan férhet hozzá a naplózási adatokhoz.

Első lépésként a legegyszerűbben a felügyeleti figyelési munkaterületen elérhető előre elkészített jelentéseket használhatja.

Ha közvetlenül kell hozzáférnie az adatokhoz, és saját megoldást kell létrehoznia, egy API-t (alkalmazásprogram-felületet) fog használni. Az API-k az interneten keresztüli adatcserére szolgálnak. A Power BI REST API-k HTTP protokollal támogatják az adatkéréseket. Bármely nyelv vagy eszköz meghívhatja a Power BI REST API-kat, ha képes HTTP-kérést küldeni és JSON-választ fogadni.

Tipp.

A PowerShell-parancsmagok a Power BI REST API-kat használják a naplózási adatok eléréséhez. További információ: Api-k vagy PowerShell-parancsmagok kiválasztása a cikk későbbi részében.

Ez a szakasz a technológiaválasztásra összpontosít. Az adott típusú naplózási adatok elérésének forrásával kapcsolatos megfontolásokért tekintse meg a cikk későbbi, adatforrásokkal kapcsolatos döntéseit.

Platformbeállítások

A naplózási adatok elérésének számos különböző módja van. A választott technológiától függően előfordulhat, hogy egy előnyben részesített nyelv felé hajol. Előfordulhat, hogy konkrét döntést kell hoznia a szkriptek futtatásának ütemezéséről is. A technológiák nagyban különböznek a tanulási görbéjükben és az első lépések egyszerűségében.

Az alábbiakban néhány technológiát használhat az adatok Power BI REST API-k használatával történő lekéréséhez.

Technológia Jó választás manuális naplózási folyamatokhoz Jó választás automatizált naplózási folyamatokhoz
Rendszergazda monitorozási munkaterület Rendszergazda monitorozási munkaterület jó választás manuális naplózási folyamatokhoz.
Kipróbálás Próbálja ki a manuális naplózási folyamatokat.
PowerShell A PowerShell jó választás manuális naplózási folyamatokhoz. A PowerShell jó választás az automatizált naplózási folyamatokhoz.
Power BI Desktop A Power BI Desktop jó választás manuális naplózási folyamatokhoz.
Power Automate A Power Automate jó választás automatizált naplózási folyamatokhoz.
Előnyben részesített Azure-szolgáltatás Az előnyben részesített Azure-szolgáltatás jó választás az automatizált naplózási folyamatokhoz.
Előnyben részesített eszköz/nyelv Az előnyben részesített eszköz/nyelv jó választás manuális naplózási folyamatokhoz. Az előnyben részesített eszköz/nyelv jó választás az automatizált naplózási folyamatokhoz.
Microsoft Purview naplókeresés A Microsoft Purview naplókeresése jó választás manuális naplózási folyamatokhoz.
Defender for Cloud Apps Felhőhöz készült Defender Az alkalmazások jó választás manuális naplózási folyamatokhoz.
Microsoft Sentinel A Microsoft Sentinel jó választás automatizált naplózási folyamatokhoz.

A szakasz további része röviden bemutatja a táblázatban bemutatott lehetőségeket.

Rendszergazda monitorozási munkaterület

A felügyeleti figyelési munkaterület előre definiált jelentéseket és szemantikai modelleket tartalmaz a Power BI szolgáltatás. A hálógazdák és a globális rendszergazdák kényelmesen megtekinthetik a legutóbbi naplózási adatokat, és könnyebben megérthetik a felhasználói tevékenységeket.

Try-it in API-dokumentáció

A Try-it egy interaktív eszköz, amellyel közvetlenül a Microsoft dokumentációjában tapasztalhatja meg a Power BI REST API-t. Ez egy egyszerű módja az API-k megismerésének, mivel nincs szükség más eszközökre vagy beállításokra a gépen.

A Try-it a következőre használható:

  • Manuálisan küldjön kérést egy API-nak annak megállapításához, hogy az visszaadja-e a kívánt információkat.
  • Megtudhatja, hogyan jön létre az URL-cím egy szkript írása előtt.
  • Ellenőrizze az adatokat informális módon.

Feljegyzés

A Try-it használatához licencelt és hitelesített Power BI-felhasználónak kell lennie. A standard engedélymodellt követi, ami azt jelenti, hogy a felhasználói API-k felhasználói engedélyekre támaszkodnak, a rendszergazdai API-k pedig Power BI-rendszergazdai engedélyeket igényelnek. A Try-it szolgáltatásnévvel nem hitelesíthető.

Mivel interaktív, a Try-it leginkább tanulási, feltárási és új manuális naplózási folyamatokhoz alkalmas.

PowerShell és Azure Cloud Shell

PowerShell-szkripteket többféleképpen is létrehozhat és futtathat.

Íme néhány gyakori lehetőség.

  • Visual Studio Code: Modern, könnyű forráskódszerkesztő. Ez egy szabadon elérhető nyílt forráskódú eszköz, amely több platformon is támogatott, beleértve a Windowst, a macOS-t és a Linuxot. A Visual Studio Code-ot számos nyelvvel használhatja, beleértve a PowerShellt is (a PowerShell-bővítmény használatával).
  • Azure Data Studio: Szkriptek és jegyzetfüzetek létrehozására szolgáló eszköz. A Visual Studio Code-ra épül. Az Azure Data Studio önállóan vagy az SQL Server Management Studióval (SSMS) érhető el. Számos bővítmény létezik, köztük egy PowerShell-bővítmény is.
  • Azure Cloud Shell: Alternatív megoldás a PowerShell helyi használatára. Az Azure Cloud Shell böngészőből érhető el.
  • Azure Functions: Alternatív megoldás a PowerShell helyi használatához. Az Azure Functions egy Azure-szolgáltatás, amellyel kódot írhat és futtathat kiszolgáló nélküli környezetben. A PowerShell a támogatott nyelvek egyike.

Fontos

Javasoljuk, hogy minden új fejlesztési munkához a PowerShell (PowerShell Core) legújabb verzióját használja. Hagyja abba a Windows PowerShell használatát (amely nem tudja futtatni a PowerShell Core-t), és ehelyett használja a PowerShell Core-t támogató modern kódszerkesztőket. Ügyeljen arra, hogy a Windows PowerShellt (5.1-es verzió) használó számos online példát említsen, mert előfordulhat, hogy nem a legújabb (és jobb) kódhasználatot használják.

A PowerShell többféleképpen is használható. A technikai döntésről a jelen cikk későbbi, API-k vagy PowerShell-parancsmagok kiválasztása című szakaszában olvashat bővebben.

A PowerShell használatához számos online forrás áll rendelkezésre, és gyakran találhat tapasztalt fejlesztőket, akik PowerShell-megoldásokat hozhatnak létre és kezelhetnek. A PowerShell jó választás manuális és automatizált naplózási folyamatok létrehozásához.

Power BI Desktop

Mivel a Power BI Desktop képes csatlakozni az API-khoz, előfordulhat, hogy a naplózási megoldás létrehozásához érdemes használnia. Vannak azonban jelentős hátrányok és összetettségek.

  • Előzmények halmozása: Mivel a Power BI tevékenységnaplója akár 30 napnyi adatot is biztosít, a teljes naplózási megoldás létrehozása magában foglalja az összes előzményesemény tárolására használt fájlok halmozását. Az előzményfájlok halmozása más eszközökkel egyszerűbben elvégezhető.
  • Hitelesítő adatok és kulcsok biztonságos kezelése: A közösségi bloggerek által online talált számos megoldás nem biztonságos, mert a Power Query-lekérdezésekben egyszerű szövegben rögzített hitelesítő adatokat és kulcsokat tartalmaznak. Bár ez a megközelítés egyszerű, nem ajánlott, mert bárki, aki beszerezi a Power BI Desktop-fájlt, elolvashatja az értékeket. A jelszót (felhasználói hitelesítés használata esetén) vagy titkos kulcsát (szolgáltatásnév használata esetén) nem tárolhatja biztonságosan a Power BI Desktopban, kivéve, ha:
    • Használjon egy egyéni összekötőt, amelyet a Power Query SDK-val fejlesztettek ki. Az egyéni összekötők például beolvashatják a bizalmas értékeket az Azure Key Vaultból vagy egy másik szolgáltatásból, amely biztonságosan tárolja a titkosított értéket. A globális Power BI-közösség különböző egyéni összekötői lehetőségeket is kínál.
    • Használja az ApiKeyName lehetőséget, amely jól működik a Power BI Desktopban. A kulcsérték azonban nem tárolható a Power BI szolgáltatás.
  • A kérések típusai: Előfordulhat, hogy a Power BI Desktopban futtatható elemekre vonatkozó korlátozásokba ütközik. A Power Query például nem támogatja az API-kérések minden típusát. A Web.Contents függvény használatakor például csak a GET és a POST kérések támogatottak. A naplózáshoz általában GET-kéréseket küld.
  • Frissítési képesség: A szemantikai modell Power BI szolgáltatás való sikeres frissítéséhez bizonyos Power Query-fejlesztési mintákat kell követnie. A Web.Contents használatakor például meg kell jelennie a RelativePath beállításnak, hogy a Power BI megfelelően ellenőrizze az adatforrás helyét anélkül, hogy hiba keletkezik a Power BI szolgáltatás.

A legtöbb esetben azt javasoljuk, hogy a Power BI Desktopot csak két célra használja. A következőre kell használnia:

  • Készítse el az adatmodellt a meglévő válogatott adatok alapján (ahelyett, hogy a naplózási adatok eredeti kinyeréséhez használták volna).
  • Elemzési jelentések létrehozása az adatmodell alapján.
Power Automate

A Power Automate sokféleképpen használható a Power BI-jal. A naplózással kapcsolatban a Power Automate használatával kéréseket küldhet a Power BI REST API-knak, majd a kinyert adatokat a kívánt helyen tárolhatja.

Tipp.

Ha kéréseket szeretne küldeni a Power BI REST API-knak, használhat egy egyéni összekötőt a Power Automate-hez a naplózási adatok biztonságos hitelesítéséhez és kinyeréséhez. Másik lehetőségként az Azure Key Vault használatával is hivatkozhat jelszóra vagy titkos kódra. Mindkét lehetőség jobb, mint a jelszavak és titkos kódok egyszerű szöveges tárolása a Power Automate-folyamaton belül.

A Power Automate használatával kapcsolatos egyéb ötletekért keresse meg a Power BI-t a Power Automate-sablonokban.

Előnyben részesített Azure-szolgáltatás

Számos Azure-szolgáltatás küldhet kéréseket a Power BI REST API-knak. Használhatja az előnyben részesített Azure-szolgáltatást, például:

A legtöbb esetben kombinálhat egy számítási szolgáltatást, amely kezeli az adatkinyerés logikáját egy olyan tárolási szolgáltatással, amely tárolja a nyers adatokat (és adott esetben a válogatott adatokat). A műszaki architektúra-döntések meghozatalával kapcsolatos szempontokat a cikk későbbi részében ismertetjük.

Előnyben részesített eszköz és/vagy nyelv

Az előnyben részesített eszköz és az előnyben részesített nyelv használatával kéréseket küldhet a Power BI REST API-knak. Ez egy jó megközelítés, ha a csapat szakértelemmel rendelkezik egy adott eszközzel vagy nyelvvel, például:

  • Python
  • C# a .NET-keretrendszeren. Igény szerint használhatja a Power BI .NET SDK-t, amely burkolóként működik a Power BI REST API-k tetején, hogy leegyszerűsítsen néhány folyamatot és növelje a termelékenységet.
  • JavaScript

A Microsoft Purview megfelelőségi portál (korábban a Microsoft 365 megfelelőségi központ) tartalmaz egy felhasználói felületet, amely lehetővé teszi az auditnaplók megtekintését és keresését. Az egyesített naplózási naplók közé tartozik a Power BI, valamint a Microsoft 365 egyesített naplózási naplóit támogató összes egyéb szolgáltatás.

Az egyesített naplózási naplóban rögzített adatok pontosan ugyanazok, mint amelyek a Power BI tevékenységnaplójában találhatók. Amikor naplókeresést végez a Microsoft Purview megfelelőségi portál, az hozzáadja a kérést az üzenetsorhoz. Az adatok előkészítése az adatok mennyiségétől függően néhány percet (vagy hosszabb időt) is igénybe vehet.

Az alábbiakban néhány gyakori módszert talál a naplókeresési eszköz használatára. A következőket teheti:

  • Válassza ki a Power BI számítási feladatát egy dátumsorozat eseményeinek megtekintéséhez.
  • Keressen egy vagy több konkrét tevékenységet, például:
    • Power BI-jelentés törlése
    • Rendszergazdai hozzáférés hozzáadása személyes munkaterülethez a Power BI-ban
  • Egy vagy több felhasználó tevékenységeinek megtekintése.

A megfelelő engedélyekkel rendelkező rendszergazdák számára a naplókeresési eszköz a Microsoft Purview megfelelőségi portál jó választás manuális naplózási folyamatokhoz. További információ: Microsoft Purview megfelelőségi portál a cikk későbbi részében.

Felhőhöz készült Defender Alkalmazások felhasználói felülete

Felhőhöz készült Defender Az alkalmazások a Microsoft Defender XDR (Microsoft 365 portál) rendszergazdái számára érhetők el. Tartalmaz egy felhasználói felületet a különböző felhőszolgáltatások tevékenységnaplóinak megtekintéséhez és kereséséhez, beleértve a Power BI-t is. Ugyanazokat a naplóeseményeket jeleníti meg, amelyek a Microsoft Purview megfelelőségi portál származnak, valamint más eseményeket is, például a Microsoft Entra ID felhasználói bejelentkezési tevékenységét.

Az Felhőhöz készült Defender Apps naplózási naplófelülete jó választás manuális naplózási folyamatokhoz. További információ: Felhőhöz készült Defender Alkalmazások a cikk későbbi részében.

Microsoft Sentinel és KQL

A Microsoft Sentinel egy Azure-szolgáltatás, amely lehetővé teszi a biztonsági incidensek és fenyegetések gyűjtését, észlelését, kivizsgálását és megválaszolását. A Power BI beállítható a Microsoft Sentinelben adatösszekötőként, hogy a naplók a Power BI-ból a Microsoft Sentinel Azure Log Analyticsbe (az Azure Monitor szolgáltatás egyik összetevőjébe) legyenek streamelve. A Kusto lekérdezésnyelv (KQL) használatával elemezheti az Azure Log Analyticsben tárolt tevékenységnapló-eseményeket.

A KQL használata az adatok keresésére az Azure Monitorban jó lehetőség az auditnapló egy részének megtekintésére. Ez a manuális naplózási folyamatokhoz is jó választás. További információ: Microsoft Sentinel a cikk későbbi részében.

Platformmal kapcsolatos szempontok

Íme néhány szempont a naplózási adatokhoz való hozzáféréssel kapcsolatban.

  • Manuális vagy automatizált naplózási folyamatot implementál? Egyes eszközök erősen igazodnak a manuális feldolgozáshoz vagy az automatizált feldolgozáshoz. Egy felhasználó például mindig interaktívan futtatja a Try-it funkciót, így csak manuális naplózási folyamatokhoz használható.
  • Hogyan fogja hitelesíteni? Nem minden beállítás támogatja az összes hitelesítési lehetőséget. A Try-it funkció például csak a felhasználói hitelesítést támogatja.
  • Hogyan tárolja biztonságosan a hitelesítő adatokat? A különböző technológiák különböző lehetőségeket kínálnak a hitelesítő adatok tárolására. További információ: A hitelesítési módszer meghatározása a cikk későbbi részében.
  • Milyen technológiával rendelkezik már a csapata? Ha van egy olyan eszköz, amelyet a csapata előnyben részesít, és kényelmesen használja, kezdjen ott.
  • Mire képes a csapata? Ha egy másik csapat támogatja az üzembe helyezett megoldást, gondolja át, hogy az adott csapat képes-e megfelelően támogatni azt. Vegye figyelembe azt is, hogy a belső csapatok támogathatják a tanácsadók által végzett fejlesztést.
  • Milyen eszközt kell használnia? Bizonyos eszközök és technológiák jóváhagyást igényelhetnek. Ennek oka lehet a költség. Ennek oka az informatikai biztonsági szabályzatok is lehetnek.
  • Mi a preferencia az ütemezéshez? Egyes technológiák meghozták a döntést. Máskor ez egy másik döntés, amit meg kell hoznia. Ha például PowerShell-szkripteket szeretne írni, többféleképpen ütemezheti a futtatásukat. Ezzel szemben, ha olyan felhőszolgáltatást használ, mint az Azure Data Factory, az ütemezés be van építve.

Javasoljuk, hogy tekintse át a cikk hátralévő részét, mielőtt kiválaszt egy olyan technológiát, amely hozzáfér az auditadatokhoz.

Ellenőrzőlista – Amikor eldönti, hogy melyik technológiát használja a naplózási adatok eléréséhez, a legfontosabb döntések és műveletek a következők:

  • Beszélje meg az informatikai csapatokkal: Beszéljen az informatikai csapatokkal, hogy megtudja, vannak-e jóváhagyott vagy előnyben részesített eszközök.
  • Fedezze fel a lehetőségeket egy kis elméleti bizonyítékkal (POC): Kísérletezzen egy technikai POC-val. Először a tanulásra koncentráljon. Ezután koncentráljon a döntésre, hogy mit használjon tovább.

A hitelesítési módszer meghatározása

A hitelesítés beállítása kritikus fontosságú döntés. Gyakran ez az egyik legnehezebb szempont a naplózás és a monitorozás első lépéseinél. Körültekintően mérlegelje a megalapozott döntéshozatalhoz rendelkezésre álló lehetőségeket.

Fontos

Ebben a kérdésben forduljon az informatikai és biztonsági csapatához. Szánjon időt arra, hogy megismerje a Microsoft Entra ID biztonságának alapjait.

Az interneten nem minden API igényel hitelesítést. Az összes Power BI REST API-nak azonban hitelesítésre van szüksége. A bérlőszintű naplózási adatok elérésekor a hitelesítési folyamatot a Microsoft Identitásplatform kezeli. Ez a Microsoft Entra identity szolgáltatás fejlődése, amely iparági szabvány protokollokra épül.

Tipp.

A kifejezések Microsoft Identitásplatform szószedete olyan erőforrás, amely segít az alapfogalmak megismerésében.

A naplózási adatok lekérése előtt először hitelesítenie kell magát, amelyet bejelentkezésnek nevezünk. A hitelesítés és az engedélyezés fogalmai különállóak, mégis kapcsolódnak egymáshoz. A hitelesítési folyamat ellenőrzi a kérést küldő személy identitását. Az engedélyezési folyamat hozzáférést biztosít (vagy tagad) egy rendszerhez vagy erőforráshoz annak ellenőrzésével , hogy a felhasználó vagy a szolgáltatásnév rendelkezik-e engedéllyel.

Amikor egy felhasználó vagy szolgáltatásnév hitelesít, egy Microsoft Entra hozzáférési jogkivonatot ad ki egy erőforrás-kiszolgálónak, például a Power BI REST API-t vagy a Microsoft Graph API-t. Alapértelmezés szerint egy hozzáférési jogkivonat egy óra elteltével lejár. Szükség esetén frissítési jogkivonat kérhető.

A hozzáférési jogkivonatoknak két típusa van:

  • Felhasználói jogkivonatok: Ismert identitással rendelkező felhasználó nevében kibocsátva.
  • Csak alkalmazásjogkivonatok: Egy Microsoft Entra-alkalmazás (szolgáltatásnév) nevében kiállítva.

További információ: Alkalmazás- és szolgáltatásnév-objektumok a Microsoft Entra-azonosítóban.

Feljegyzés

A Microsoft Entra-alkalmazások olyan identitáskonfigurációk, amelyek lehetővé teszik, hogy egy automatizált folyamat integrálható legyen a Microsoft Entra-azonosítóval. Ebben a cikkben alkalmazásregisztrációnak nevezzük. A szolgáltatásnév kifejezés is gyakran használatos ebben a cikkben. Ezeket a kifejezéseket a szakasz későbbi részében részletesebben ismertetjük.

Tipp.

A hitelesítés legegyszerűbb módja az Csatlakozás-PowerBIServiceAccount parancsmag használata a Power BI Management modulból. A hitelesítéssel kapcsolatos egyéb parancsmagok online cikkekben és blogbejegyzésekben is megjelenhetnek. Vannak például a parancsmagok és Login-PowerBIServiceAccount parancsmagokLogin-PowerBI, amelyek a parancsmag aliasaiConnect-PowerBIServiceAccount. Létezik a Disconnect-PowerBIServiceAccount parancsmag is, amellyel explicit módon kijelentkezhet egy folyamat végén.

Az alábbi táblázat a két hitelesítési lehetőséget ismerteti.

A hitelesítés típusa Leírás Rendeltetése: Jó választás manuális naplózási folyamatokhoz Jó választás automatizált naplózási folyamatokhoz
Felhasználói hitelesítés Jelentkezzen be felhasználóként a felhasználónév (e-mail-cím) és egy jelszó használatával. Alkalmi, interaktív használat A felhasználói hitelesítés jó választás manuális naplózási folyamatokhoz
Egyszerű szolgáltatás hitelesítése Jelentkezzen be szolgáltatásnévként egy alkalmazásregisztrációhoz hozzárendelt titkos kód (kulcs) használatával. Folyamatban lévő, ütemezett, felügyelet nélküli műveletek A szolgáltatásnév hitelesítése jó választás az automatizált naplózási folyamatokhoz

Az egyes hitelesítési lehetőségeket a következő szakaszban részletesebben ismertetjük.

Felhasználói hitelesítés

A felhasználói hitelesítés az alábbi helyzetekben hasznos.

  • Manuális naplózási folyamatok: Felhasználói engedélyekkel szeretne szkriptet futtatni. Az engedélyek az API-kérés típusától függően két szint egyikén lehetnek:
    • Rendszergazda a rendszergazdai API-khoz tartozó engedélyek: A Kérések rendszergazdai API-nak való elküldéséhez a Power BI rendszergazdai engedélyeit kell használnia.
    • Felhasználói engedélyek felhasználói API-khoz: A Power BI felhasználói engedélyekkel kell kérést küldenie egy felhasználói API-nak. További információ: Felhasználói API vagy rendszergazdai API kiválasztása.
  • Interaktív bejelentkezés: Interaktívan szeretne bejelentkezni, ehhez meg kell adnia az e-mail-címét és a jelszavát. A Microsoft API dokumentációjában található Try-it felület használatához például interaktív módon kell bejelentkeznie.
  • A bérlői metaadatok elérésének nyomon követése: Amikor egyes felhasználók és rendszergazdák API-kéréseket küldenek, érdemes lehet ellenőrizni, hogy kik azok az egyének. Amikor egy szolgáltatásnévvel hitelesít (a következő leírásban), a tevékenységnapló által rögzített felhasználói azonosító az alkalmazásazonosító. Ha több rendszergazda is ugyanazzal a szolgáltatásnévvel hitelesít, nehéz lehet megállapítani, hogy melyik rendszergazda fért hozzá az adatokhoz.
  • Megosztott rendszergazdai fiók: Egyes informatikai csapatok megosztott rendszergazdai fiókot használnak. Attól függően, hogy hogyan van implementálva és vezérelve, lehet, hogy nem ajánlott eljárás. Megosztott fiók helyett érdemes megfontolni a Microsoft Entra Privileged Identity Management (PIM) használatát, amely alkalmi és ideiglenes Power BI-rendszergazdai jogosultságokat biztosíthat egy felhasználó számára.
  • Olyan API-k, amelyek csak a felhasználói hitelesítést támogatják: Esetenként előfordulhat, hogy olyan API-t kell használnia, amely nem támogatja a szolgáltatásnév általi hitelesítést. A dokumentációban minden API megjegyzi, hogy egy szolgáltatásnév meghívhatja-e.

Fontos

Amikor csak lehetséges, javasoljuk, hogy szolgáltatásnév-hitelesítést használjon az automatizált folyamatokhoz.

Egyszerű szolgáltatás hitelesítése

A legtöbb szervezet egy Microsoft Entra-bérlővel rendelkezik, ezért az alkalmazásregisztráció és a szolgáltatásnév kifejezés általában felcserélhető. A Microsoft Entra-alkalmazás regisztrálásakor két összetevő található.

  • Alkalmazásregisztráció: Az alkalmazásregisztráció globálisan egyedi. Ez egy regisztrált Microsoft Entra-alkalmazás globális definíciója, amelyet több bérlő is használhat. Az alkalmazásregisztrációt ügyfélalkalmazásnakvagy aktornak is nevezik. Az ügyfélalkalmazás kifejezés általában egy felhasználói gépet jelent. Az alkalmazásregisztrációk esetében azonban nem ez a helyzet. Az Azure Portalon a Microsoft Entra-alkalmazások a Microsoft Entra ID Alkalmazásregisztrációk lapján találhatók.
  • Szolgáltatásnév: A szolgáltatásnév az alkalmazásregisztráció helyi reprezentációja az adott bérlőben való használatra. A szolgáltatásnév a regisztrált Microsoft Entra alkalmazásból származik. A több Microsoft Entra-bérlővel rendelkező szervezetek esetében ugyanarra az alkalmazásregisztrációra több szolgáltatásnév is hivatkozhat. Az Azure Portalon a szolgáltatásnevek a Nagyvállalati alkalmazások lapon, a Microsoft Entra ID-ban találhatók.

Mivel a szolgáltatásnév a helyi képviselet, a szolgáltatásnév-hitelesítés kifejezés a bejelentkezések leggyakoribb módja.

Tipp.

A Microsoft Entra rendszergazdája megadhatja, hogy ki hozhat létre és járulhat hozzá az alkalmazásregisztrációhoz a szervezetben.

A szolgáltatásnév hitelesítése a következő helyzetekben hasznos.

  • Automatizált naplózási folyamatok: Felügyelet nélküli folyamatot szeretne ütemezni.
  • Nem kell bejelentkeznie a Power BI szolgáltatás: Csak csatlakoznia kell és ki kell nyernie az adatokat. A szolgáltatásnév nem tud bejelentkezni a Power BI szolgáltatás.
  • Megosztott hozzáférés az adatokhoz: Ön (személyesen) nem Power BI-rendszergazda, de jogosult szolgáltatásnév használatára. A szolgáltatásnév jogosult rendszergazdai API-k futtatására a bérlőszintű adatok (vagy más konkrét engedélyek) lekéréséhez.
  • Több rendszergazda általi használat: Engedélyezni szeretné, hogy több rendszergazda vagy felhasználó ugyanazt a szolgáltatásnevet használja.
  • Technikai blokkolók: Létezik egy technikai blokkoló, amely megakadályozza a felhasználói hitelesítés használatát. A gyakori technikai blokkolók a következők:
    • Többtényezős hitelesítés (MFA): Az automatizált (felügyelet nélküli) naplózási folyamatok nem tudnak hitelesítést végezni felhasználói fiókkal, ha engedélyezve van a többtényezős hitelesítés.
    • Jelszókivonat-szinkronizálás: A Microsoft Entra-azonosítóhoz jelszókivonat-szinkronizálás szükséges egy felhasználói fiókhoz a hitelesítéshez. Előfordulhat, hogy az informatikai vagy a kiberbiztonsági csapat letiltja ezt a funkciót.
Alkalmazásregisztrációs cél és elnevezési konvenció

Minden alkalmazásregisztrációnak egyértelmű névvel kell rendelkeznie, amely leírja a célját és a célközönséget (akik használhatják az alkalmazásregisztrációt).

Fontolja meg egy elnevezési konvenció implementálását, például: <Számítási feladat> – <Cél> – <Célközönség> – <Objektum típusa>

Íme az elnevezési konvenció részei.

  • Számítási feladat: Általában egyenértékű egy adatforrással (például Power BI-adatokkal vagy Microsoft Graph-adatokkal).
  • Cél: Hasonló az engedélyek szintjéhez (például Olvasás vagy ReadWrite). Az alábbiakban leírtaknak megfelelően a cél segít követni a minimális jogosultság elvét, amikor olyan különálló alkalmazásregisztrációkat hoz létre, amelyek csak adatokat tudnak olvasni.
  • Célközönség: Nem kötelező. A számítási feladattól és a céltól függően a célközönség lehetővé teszi az alkalmazásregisztráció kívánt felhasználóinak meghatározását.
  • Objektumtípus:Az EntraApp az egyértelműség kedvéért megtalálható.

Az elnevezési konvenció pontosabb lehet, ha több bérlő vagy több környezet (például fejlesztés és éles környezet) van.

Az alábbi táblázat példákat mutat be a bérlőszintű naplózási adatok kinyerésére használható alkalmazásregisztrációkra:

Alkalmazásregisztráció neve Célja Célközönség
PowerBIData-Read-Rendszergazda APIs-EntraApp Bérlőszintű metaadatok kinyerése a Power BI naplózásához és felügyeletéhez. Rendszergazda API-k mindig írásvédettek, és előfordulhat, hogy nem rendelkeznek a Microsoft Entra-azonosítóban megadott engedélyekkel (csak Power BI-bérlői beállítás). Power BI-rendszergazdák és a Kiválósági Központ
PowerBIData-ReadWrite-PowerBI Rendszergazda istrators-EntraApp A Power BI-bérlő kezelése. Olvasási/írási engedélyeket igényel az erőforrások létrehozásához vagy frissítéséhez. Power BI-rendszergazdák és a Kiválósági Központ
GraphData-Read-PowerBI Rendszergazda istrators-EntraApp Felhasználók és csoportok adatainak kinyerése a Power BI naplózásához és felügyeletéhez. Olvasási engedélyeket igényel. Power BI-rendszergazdák és a Kiválósági Központ

Több alkalmazásregisztráció különböző célokra történő kezelése több erőfeszítést igényel. Azonban több előnye is lehet.

  • Megtudhatja, hogy az alkalmazásregisztráció mire szolgál , és miért: Amikor megjelenik az alkalmazásregisztráció ügyfélazonosítója a naplózási adatok között, fogalma lesz arról, hogy mire és miért használták. Ez jelentős előnye annak, ha külön alkalmazásregisztrációkat hoz létre (ahelyett, hogy csak egyet használ minden célra).
  • Megtudhatja, hogy ki használja az alkalmazásregisztrációt: Amikor megjelenik az alkalmazásregisztráció ügyfélazonosítója a naplózási adatok között, fogalma lesz arról, hogy ki használta.
  • Az engedélyek túlterjeszkedésének elkerülése: A minimális jogosultság elvét követve külön alkalmazásregisztrációkat biztosíthat különböző, különböző igényekkel rendelkező személyek számára. Ha nincs szükség írási engedélyekre, elkerülheti az engedélyek túlterjeszkedését, ha írási engedélyekre nincs szükség. Előfordulhat például, hogy vannak olyan magas képességű önkiszolgáló felhasználók, akik adatokat szeretnének gyűjteni a szemantikai modelljeikről; olvasási engedéllyel kell hozzáférniük egy szolgáltatásnévhez. mivel előfordulhat, hogy a Kiválósági Központ műholdas tagjai a pénzügyi csapatnak dolgoznak, akik programozott módon kezelik a szemantikai modelleket; írási engedéllyel kell hozzáférniük egy szolgáltatásnévhez.
  • Tudja meg, hogy kinek kell birtokában lennie a titkos kódnak: Az egyes alkalmazásregisztrációk titkos kódját csak a szükséges személyekkel szabad megosztani. Ha a titkos kód el van forgatva (ezt a szakasz későbbi részében ismertetjük), a hatás kisebb, ha külön alkalmazásregisztrációkat használ a különböző igényekhez. Ez akkor hasznos, ha a titkos kód elforgatására van szükség, mert egy felhasználó elhagyja a szervezetet, vagy szerepköröket módosít.
Alkalmazásregisztráció engedélyei

Az alkalmazásregisztrációk kétféleképpen férhetnek hozzá az adatokhoz és az erőforrásokhoz. Ez engedélyekkel és hozzájárulással jár.

  • Csak alkalmazásengedélyek: A hozzáférést és az engedélyezést a szolgáltatásnév kezeli bejelentkezés nélkül. Ez a hitelesítési módszer az automatizálási forgatókönyvekben hasznos. Ha csak alkalmazásengedélyeket használ, fontos tisztában lenni azzal, hogy az engedélyek nincsenek hozzárendelve a Microsoft Entra-azonosítóhoz. Ehelyett az engedélyek kétféleképpen vannak hozzárendelve:
    • Rendszergazdai API-k futtatása esetén: Bizonyos Power BI-bérlői beállítások lehetővé teszik a rendszergazdai API-k végpontjaihoz való hozzáférést (amelyek bérlőszintű naplózási metaadatokat adnak vissza). További információ: A Power BI-bérlő beállításainak beállítása a cikk későbbi részében.
    • Felhasználói API-k futtatásához: a Power BI-munkaterület és az elemengedélyek érvényesek. A standard Power BI-engedélyek szabályozzák, hogy mely adatok adhatók vissza a szolgáltatásnévnek felhasználói API-k futtatásakor (amelyek az API-t használó felhasználó vagy szolgáltatásnév engedélyei alapján ad vissza naplózási adatokat).
  • Delegált engedélyek: Hatóköralapú engedélyek vannak használatban. A szolgáltatásnév a jelenleg bejelentkezett felhasználó nevében fér hozzá az adatokhoz. Ez azt jelenti, hogy a szolgáltatásnév nem fér hozzá semmihez azon túl, amit a bejelentkezett felhasználó elérhet. Vegye figyelembe, hogy ez egy másik fogalom, mint a korábban ismertetett, csak felhasználói hitelesítés. Mivel a felhasználói és alkalmazásengedélyek kombinációjának megfelelő kezeléséhez egyéni alkalmazásra van szükség, a delegált engedélyeket ritkán használják naplózási forgatókönyvekhez. Ezt a fogalmat gyakran félreértik, ami sok olyan alkalmazásregisztrációt eredményez, amelyek engedélyekkel túlterjedtek.

Fontos

Ebben a cikkben csak a felhasználóhitelesítésre vagy az alkalmazásalapú hitelesítésre összpontosítunk. A delegált engedélyek (egy interaktív felhasználóval és a szolgáltatásnévvel) fontos szerepet játszhatnak a Power BI-tartalmak programozott beágyazásakor. Határozottan elriasztjuk azonban attól, hogy delegált engedélyeket állítson be a naplózási adatok kinyerése érdekében. Minden API korlátozza, hogy milyen gyakran futtatható (szabályozással), ezért nem praktikus, ha a különböző felhasználók közvetlenül férnek hozzá a nyers naplózási adatokhoz. Ehelyett azt javasoljuk, hogy egyszer (központosított eljárással) nyerje ki a nyers naplózási adatokat, majd tegye elérhetővé a feldolgozott naplózási adatokat az arra jogosult felhasználók számára.

További információ: Microsoft Entra-alkalmazás regisztrálása a cikk későbbi részében.

Alkalmazásregisztrációs titkos kódok

Az alkalmazásregisztrációk gyakran titkos kóddal vannak hozzárendelve. A titkos kód kulcsként használatos a hitelesítéshez, és lejárati dátummal rendelkezik. Ezért meg kell terveznie, hogyan kell rendszeresen elforgatni a kulcsot, és hogyan kell kommunikálni az új kulcsot a jogosult felhasználókkal.

Azzal is foglalkoznia kell, hogy hol tárolhatja biztonságosan a titkos kódot. Egy szervezeti jelszótároló, például az Azure Key Vault kiváló választás.

Tipp.

A titkos kulcsok használatának alternatív módszereként használhat felügyelt identitást. A felügyelt identitások nem igénylik a hitelesítő adatok kezelését. Ha olyan szolgáltatásokat kíván használni, mint az Azure Functions vagy az Azure Data Factory az adatok kinyeréséhez, a felügyelt identitás jó választás a vizsgálathoz.

Hitelesítő adatok biztonságos kezelése

Függetlenül attól, hogy felhasználóhitelesítést vagy egyszerű szolgáltatáshitelesítést használ- e, az egyik legnagyobb kihívás a jelszavak, titkos kódok és kulcsok biztonságos kezelése.

Figyelemfelhívás

Az első szabály az, amelyet sokan megsértenek: a jelszavak és kulcsok soha nem jelennek meg egyszerű szövegben egy szkriptben. Számos online cikk, blog és példa teszi ezt az egyszerűség kedvéért. Ez azonban egy rossz gyakorlat, amelyet el kell kerülni. Bárki, aki a szkriptet (vagy a fájlt) beszerezi, hozzáférhet ugyanazokhoz az adatokhoz, amelyekhez a szerző hozzáfér.

Az alábbiakban számos biztonságos módszert találhat a jelszavak, titkos kódok és kulcsok kezelésére.

  • Amikor csak lehetséges, integrálható az Azure Key Vaulttal vagy egy másik szervezeti jelszótároló-rendszerrel.
  • Használjon hitelesítő adatokat és biztonságos sztringeket a PowerShell-szkriptekben. A hitelesítő adatok a felhasználói hitelesítéshez és a szolgáltatásnév-hitelesítéshez is működnek. A hitelesítő adatokat azonban nem használhatja, ha a többtényezős hitelesítés engedélyezve van egy felhasználói fiókhoz.
  • Kérj jelszót a PowerShell-szkriptben, vagy használj interaktív hitelesítést egy böngészőben.
  • Használja a Microsoft által közzétett PowerShell titkos kódkezelési modulját. Értékeket tárolhat egy helyi tároló használatával. Integrálható egy távoli Azure Key Vaulttal is, ami akkor hasznos, ha a szervezet több rendszergazdája is ugyanazokkal a szkriptekkel dolgozik.
  • Hozzon létre egy egyéni összekötőt a Power BI Desktophoz, hogy biztonságosan kezelje a hitelesítő adatokat. Egyes egyéni összekötők a közösség tagjaitól (általában a GitHubon) érhetők el.

Tipp.

Javasoljuk, hogy konzultáljon az informatikai és biztonsági csapatokkal a legjobb módszer kiválasztásához, vagy ellenőrizze, hogy a megoldás biztonságosan kezeli-e a hitelesítő adatokat.

Microsoft Authentication Library

Az Azure AD Authentication Library (ADAL) támogatása 2022 decemberében megszűnt. A továbbiakban a Microsoft Authentication Library (MSAL) függvénytárat kell használnia. A szervezet biztonsági csapatának ismernie kell ezt a jelentős változást.

Bár nem fontos, hogy a Power BI-szakemberek mélyen megértsék az MSAL-ra való áttérést, az alábbi javaslatoknak kell megfelelniük.

  • A Power BI Management modul legújabb verzióját használja a Csatlakozás-PowerBIServiceAccount PowerShell-parancsmaggal végzett hitelesítéskor. ADAL-ról MSAL-re váltott az 1.0.946-os verzióban (2021. február 26.).
  • Használja a Microsoft Entra V2-végpontot, amikor közvetlenül a szkriptben hitelesít. A Microsoft Entra V2 végpont MSAL-t, míg a Microsoft Entra V1 végpont az ADAL-t használja.
  • Az elavult API-k és modulok használatának megszüntetése. További információ: Elavult API-k és modulok a cikk későbbi részében.
  • Ha online talál egy közösségi megoldást, győződjön meg arról, hogy az MSAL-t használja hitelesítésre az ADAL helyett.

Ellenőrzőlista – A hitelesítés kezelésének eldöntésekor a legfontosabb döntések és műveletek a következők:

  • Döntse el, hogy milyen típusú hitelesítést szeretne használni: Határozza meg, hogy a felhasználói hitelesítés vagy a szolgáltatásnév hitelesítése a legmegfelelőbb-e a létrehozni kívánt naplózási megoldás típusától függően.
  • Tervezze meg, hogy milyen alkalmazásregisztrációkra van szüksége: Vegye figyelembe a követelményeket, a számítási feladatokat és a célközönséget (az egyes alkalmazásregisztrációk felhasználóit). Tervezze meg, hogy hány alkalmazásregisztrációt kell létrehoznia ezeknek az igényeknek a támogatásához.
  • Elnevezési konvenció létrehozása az alkalmazásregisztrációkhoz: Állítson be egy elnevezési konvenciót, amely megkönnyíti az egyes alkalmazásregisztrációk rendeltetésének és felhasználóinak megértését.
  • A hitelesítő adatok biztonságos kezelésének megtervezése: Fontolja meg a jelszavak, titkos kódok és kulcsok biztonságos kezelését. Gondolja át, milyen dokumentációra és képzésre lehet szükség.
  • Ellenőrizze az MSAL használatát: Állapítsa meg, hogy vannak-e olyan meglévő manuális vagy automatizált naplózási megoldások, amelyek az ADAL-ra támaszkodnak. Szükség esetén hozzon létre egy tervet, amely átírja ezeket a megoldásokat az újabb MSAL hitelesítési kódtár használatára.

Felhasználói API vagy rendszergazdai API kiválasztása

A naplózási adatok lekérésének tervezésekor fontos a megfelelő API-típus használata.

Kétféle API-t kell figyelembe venni.

  • Felhasználói API-k: A bejelentkezett felhasználó (vagy szolgáltatásnév) engedélyeire támaszkodva küldjön kéréseket az API-nak. A szemantikai modellek listájának egy munkaterületen való visszaadásának egyik módja például egy felhasználói API. A szemantikai modellek olvasására vonatkozó engedély munkaterületi szerepkör vagy elemenkénti engedélyekkel adható meg. A felhasználói API-k kétféleképpen futtathatók:
    • Felhasználói hitelesítés: A bejelentkezett felhasználónak engedéllyel kell rendelkeznie a munkaterület vagy elem eléréséhez.
    • Szolgáltatásnév hitelesítése: A szolgáltatásnévnek engedéllyel kell rendelkeznie a munkaterület vagy elem eléréséhez.
  • Rendszergazda API-k: Metaadatok lekérése a bérlőről. Ezt néha szervezeti hatókörnek is nevezik. Ha például a bérlő összes szemantikai modelljének listáját szeretné visszaadni, egy rendszergazdai API-t használ. A rendszergazdai API-k kétféleképpen futtathatók:
    • Felhasználói hitelesítés: A bejelentkezett felhasználónak Power BI-rendszergazdának kell lennie a rendszergazdai API-k futtatásához.
    • Egyszerű szolgáltatáshitelesítés: A szolgáltatásnévnek rendszergazdai API-k futtatására vonatkozó engedéllyel kell rendelkeznie (anélkül, hogy a felhasználói API-hoz hasonló biztonsági engedélyekre támaszkodna).

Tipp.

Minden rendszergazdai API a Rendszergazda műveletcsoporthoz tartozik. Az As Rendszergazda utótagot tartalmazó API-k rendszergazdai API-k, a fennmaradó API-k pedig felhasználói API-k.

Vegyünk egy példát, ahol le kell szereznie a szemantikai modellek listáját. Az alábbi táblázat hat API-lehetőséget mutat be, amelyeket erre használhat. Négy lehetőség a felhasználói API-k, a két lehetőség pedig a rendszergazdai API-k. A visszaadott elemek hatóköre és száma a választott API-tól függően eltérő.

API-név Az API típusa Hatókör Szemantikai modellek száma
Adatkészlet lekérése User Személyes munkaterület Eggyel
Adathalmazok lekérése User Személyes munkaterület Mind
Adathalmaz lekérése a csoportban User Egy munkaterület Egy, feltéve, hogy a bejelentkezett felhasználó rendelkezik engedéllyel a szemantikai modell olvasására
Adathalmazok lekérése a csoportban User Egy munkaterület Mind, feltéve, hogy a bejelentkezett felhasználó rendelkezik engedéllyel az egyes szemantikai modellek olvasására
Adathalmazok beolvasása csoportba Rendszergazda Rendszergazda Egy munkaterület Mind
Adathalmazok lekérése Rendszergazda Rendszergazda Teljes bérlő Mind

Feljegyzés

Néhány API-név tartalmazza a Csoport kifejezést egy munkaterületre mutató hivatkozásként. Ez a kifejezés az eredeti Power BI biztonsági modellből származik, amely a Microsoft 365-csoportokra támaszkodott. Bár a Power BI biztonsági modellje jelentősen fejlődött az évek során, a meglévő API-nevek változatlanok maradnak a meglévő megoldások feltörésének elkerülése érdekében.

A bérlői beállításokról a jelen cikk későbbi részében, a Power BI-bérlői beállítások megadása című témakörben olvashat bővebben.

Ellenőrzőlista – Ha azt választja, hogy felhasználói API-t vagy rendszergazdai API-t szeretne-e használni, a legfontosabb döntések és műveletek a következők:

  • Tekintse meg az adatkövetelményeket: Gyűjtse össze és dokumentálja a naplózási megoldás legfontosabb üzleti követelményeit. A szükséges adatok típusától függően határozza meg, hogy a felhasználói hatókör vagy a szervezeti hatókör megfelelő-e.
  • Tesztelje az eredményeket: Kísérletezzen. Tesztelje a különböző API-k által visszaadott eredmények pontosságát.
  • Engedélyek áttekintése: Minden meglévő naplózási megoldás esetében ellenőrizze, hogy az engedélyek megfelelően vannak-e hozzárendelve a Power BI-rendszergazdákhoz és a szolgáltatásnevekhez. Új naplózási megoldások esetén ellenőrizze, hogy melyik hitelesítési módszert fogja használni.

API-k vagy PowerShell-parancsmagok kiválasztása

A legfontosabb döntés az, hogy PowerShell-parancsmagokat használ-e, amikor azok elérhetők a lekérni kívánt adatokhoz. Ez a döntés akkor fontos, ha úgy döntött, hogy a PowerShell az auditadatok elérésére használt technológiák egyike.

A PowerShell egy feladatautomatizálási megoldás. A PowerShell kifejezés egy gyűjtőkifejezés, amely a szkriptelési nyelvre, egy parancssori rendszerhéj-alkalmazásra és egy konfigurációkezelési keretrendszerre hivatkozik. A PowerShell Core a PowerShell legújabb verziója, amely Windows, Linux és macOS rendszeren fut.

A PowerShell-parancsmagok olyan parancsok, amelyek műveletet hajtanak végre. A PowerShell-modul olyan csomag, amely PowerShell-tagokat, például parancsmagokat, szolgáltatókat, függvényeket, munkafolyamatokat, változókat és aliasokat tartalmaz. Modulokat tölthet le és telepíthet.

A PowerShell-modul absztrakciós réteget hoz létre az API-k felett. A Get-PowerBIActivityEvent parancsmag például lekéri (vagy lekéri) egy Power BI-bérlő naplózási eseményeit. Ez a PowerShell-parancsmag lekéri az adatait a Tevékenységesemények lekérése REST API-ból. Általában egyszerűbb a parancsmagok használatával kezdeni, mert leegyszerűsíti a mögöttes API-khoz való hozzáférést.

Az API-knak csak egy részhalmaza érhető el PowerShell-parancsmagokként. A teljes naplózási megoldás bővítése során valószínűleg parancsmagok és API-k kombinációját fogja használni. A szakasz további része segít eldönteni, hogy milyen módon fog hozzáférni az adatokhoz.

PowerShell-modulok

A Microsoft közzétett két PowerShell-modult, amelyek a Power BI-hoz kapcsolódó parancsmagokat tartalmaznak. Ezek a Power BI Management modul és a Data Gateway modul. Ezek a PowerShell-modulok API-burkolóként működnek az alapul szolgáló Power BI REST API-k fölé. Ezek a PowerShell-modulok megkönnyítik a szkriptek írását.

Tipp.

A Microsoft által közzétett modulokon kívül a Power BI-közösség tagjai, partnerei és a Microsoft legértékesebb szakemberei (MVP-k) szabadon elérhető PowerShell-modulokat és szkripteket is közzétehet (általában a GitHubon).

A közösségi megoldástól kezdve fontos szerepet játszhat a végpontok közötti naplózási megoldás kialakításában. Ha szabadon elérhető megoldást használ, győződjön meg róla, hogy teljes mértékben teszteli. Ismerje meg, hogyan működik a megoldás, hogy idővel hatékonyan felügyelhesse a megoldást. Előfordulhat, hogy az informatikai részleg rendelkezik a nyilvánosan elérhető közösségi megoldások használatára vonatkozó feltételekkel.

Power BI Management modul

A Power BI Management modul egy összegző modul, amely konkrét Power BI-modulokat tartalmaz az adminisztrációhoz, a kapacitásokhoz, a munkaterületekhez és egyebekhez. A kumulatív modul telepítésével beszerezheti az összes modult, vagy telepíthet bizonyos modulokat. Az összes Power BI Felügyeleti modul támogatott a Windows PowerShell és a PowerShell Core rendszeren is.

Fontos

Javasoljuk, hogy hagyja abba a Windows PowerShell használatát (amely nem tudja futtatni a PowerShell Core-t). Ehelyett használja az egyik modern kódszerkesztőt, amely támogatja a PowerShell Core-t. A Windows PowerShell I Standard kiadás (integrált szkriptkörnyezet) csak a PowerShell 5.1-es verzióját képes futtatni, amely már nem frissül. A Windows PowerShell elavult, ezért javasoljuk, hogy minden új fejlesztési munkához használja a PowerShell Core-t.

Az alábbiakban számos gyakran használt parancsmagot talál, amelyekkel lekérheti a naplózási adatokat.

Felügyeleti modul Parancsmag Célja
Profil Csatlakozás-PowerBIServiceAccount Power BI-felhasználó vagy szolgáltatásnév hitelesítése.
Rendszergazda Get-PowerBIActivityEvent A bérlő Power BI-tevékenységnapló-eseményeinek megtekintése vagy kinyerése.
Munkaterületek PowerBIWorkspace lekérése Munkaterületek listájának fordítása.
Jelentések PowerBIReport lekérése A munkaterület vagy a bérlő jelentéseinek listája.
Adatok PowerBIDataset lekérése A munkaterület vagy a bérlő szemantikai modelljének listáját állíthatja össze.
Profil Invoke-PowerBIRestMethod REST API-kérés (parancs) küldése. Ez a parancsmag jó választás, mert a Power BI REST API-k bármelyikét meghívhatja. Akkor is jó választás, ha a parancsmag használatával Connect-PowerBIServiceAccount szeretné használni az egyszerűbb hitelesítési formát, és képes meghívni egy olyan API-t, amely nem rendelkezik megfelelő PowerShell-parancsmaggal. További információ: A PowerShell-parancsmagok használatának szempontjai a szakasz későbbi részében.

Tipp.

A tartalmak kezeléséhez és közzétételéhez más parancsmagok is elérhetők. A cikk középpontjában azonban a naplózási adatok beolvasása áll.

A Power BI Management modult a PowerShell-galéria töltheti le. A modulok telepítésének legegyszerűbb módja a PowerShellGet használata.

Javasoljuk, hogy telepítse a Power BI Management összesítő modulját. Így minden szükséges parancsmag elérhető. Legalább szüksége van a Profil modulra (hitelesítéshez) és minden olyan modulra, amely tartalmazza a használni kívánt parancsmagokat.

Figyelemfelhívás

Ügyeljen arra, hogy a modulokat naprakészen tartsa minden kiszolgálón, felhasználói gépen és felhőszolgáltatásban (például az Azure Automationben), ahol a PowerShellt használja. Ha a modulokat nem frissítik rendszeresen, kiszámíthatatlan hibák vagy problémák léphetnek fel. Egyes eszközök (például a Visual Studio Code) segítenek a modulok frissítésében. Vegye figyelembe azt is, hogy a PowerShellGet nem távolítja el automatikusan a modul régebbi verzióit egy újabb verzió telepítésekor vagy frissítésekor. A régebbi verziók mellett újabb verziókat is telepít. Javasoljuk, hogy ellenőrizze a telepített verziókat, és rendszeresen távolítsa el a régebbi verziókat.

Data Gateway-modul

A Data Gateway modul olyan parancsmagokat tartalmaz, amelyek adatokat kérnek le egy helyszíni adatátjáróból és annak adatforrásaiból. A Data Gateway modul csak a PowerShell Core-on támogatott. A Windows PowerShell nem támogatja.

A Power BI Management modultól (korábban ismertetett) eltérően a Data Gateway modul nem tartalmaz rendszergazdai parancsmagokat. Számos parancsmag (és a megfelelő átjáró API-k) megkövetelik, hogy a felhasználó rendelkezik átjáró-rendszergazdai jogosultságokkal.

Figyelmeztetés

Szolgáltatásnév nem rendelhető hozzá átjáróadminisztrátorként (még akkor sem, ha a szolgáltatásnév egy biztonsági csoport tagja). Ezért tervezze meg, hogy felhasználói hitelesítő adatokat használ az adatátjárókkal kapcsolatos információk lekéréséhez.

Az alábbi parancsmagok a Data Gateway-modulból származnak, amelyekkel lekérheti a naplózási adatokat.

Parancsmag Célja
Csatlakozás-DataGatewayServiceAccount Power BI-felhasználó hitelesítése (általában megköveteli, hogy a felhasználó az átjáró rendszergazdai szerepköréhez tartozjon).
Get-DataGatewayCluster Az átjárófürtök listájának fordítása.
Get-DataGatewayClusterDataSource Egy átjárófürt adatforrásainak listája.
Get-DataGatewayInstaller Ellenőrizze, hogy mely felhasználók telepíthetnek és regisztrálhatnak átjárókat a szervezetben.

A Data Gateway modult a PowerShell-galéria töltheti le.

A PowerShell használatának technikái

A PowerShell többféleképpen is használható. A döntés, amit hoz, fontos.

Az alábbi táblázat a PowerShell használatának három különböző módszerét ismerteti.

Technika Leírás Példa
A PowerShell-parancsmagok használatával egyszerűsítheti a hitelesítést, és közvetlenül meghívhatja az API-kat. Ajánlott megközelítés Ezzel a technikával egyensúlyban van az egyszerűség és a rugalmasság. Az Invoke-PowerBIRestMethod parancsmag a Power BI Felügyeleti profil modulból érhető el. Ezt a parancsmagot gyakran svájci katonai késnek is nevezik, mert bármely Power BI REST API meghívására használható. Ennek a technikának az előnye, hogy leegyszerűsítheti a hitelesítést, majd meghívhatja bármelyik Power BI REST API-t. Határozottan javasoljuk, hogy ezt a technikát használja. A Csatlakozás-PowerBIServiceAccount parancsmaggal végzett hitelesítés után az Invoke-PowerBIRestMethod parancsmaggal kérje le az adatokat az előnyben részesített API-ból (például folyamatfelhasználók lekérése Rendszergazda).
A PowerShell-parancsmagokat a lehető legnagyobb mértékben használja a hitelesítéshez és az adatok lekéréséhez. Ezzel a technikával a PowerShell széles körben használható. A PowerShell a szkript futtatásának koordinálására szolgál, a PowerShell-modulok pedig, amikor csak lehetséges, az adatok elérésére szolgálnak. Ez több szempontból is nagyobb függőséget hoz létre a PowerShell-lel kapcsolatban. A Csatlakozás-PowerBIServiceAccount parancsmaggal végzett hitelesítés után használjon egy parancsmagot (például Get-PowerBIActivityEvent) az adatok lekéréséhez.
Csak a PowerShell használatával koordinálja a folyamat futtatását. A PowerShell-modulokat a lehető legkisebb mértékben használják. Ezzel a technikával az eszköz kevésbé függ a PowerShell-től, mivel elsődleges használata az API-hívások meghívásának vezénylése. Az API-k eléréséhez csak egy általános PowerShell-modul használható (a Power BI Felügyeleti modulok egyik modulja sem használható). A Microsoft Authentication Library (MSAL) használatával végzett hitelesítés után hívja meg az előnyben részesített API-t (például folyamatfelhasználók lekérése Rendszergazda) az általános Invoke-RestMethod parancsmag használatával az adatok lekéréséhez.

A fenti táblázatban az első technika egy olyan megközelítést ír le, amely a könnyű használatot és a rugalmasságot egyensúlyba teszi. Ez a megközelítés biztosítja a legjobb egyensúlyt a legtöbb szervezet igényeihez, ezért ajánlott. Előfordulhat, hogy egyes szervezetek meglévő informatikai szabályzatokkal és személyzeti beállításokkal rendelkeznek, amelyek befolyásolják a PowerShell használatának módját.

Tipp.

Az Invoke-ASCmd PowerShell parancsmaggal DAX-, XMLA- és TMSL-szkripteket hozhat létre és hajthat végre. Ezek a használati esetek azonban nem tartoznak a jelen cikk hatókörébe. További információ a dinamikus felügyeleti nézetek (DMV-k) lekérdezéséről: Adatszintű naplózás.

A műszaki felhasználók (és rendszergazdák) a Power BI Felügyeleti moduljaival lekérhetik az adatokat, vagy automatizálhatják a tartalomkezelés bizonyos aspektusait.

  • Rendszergazdák számára: Állítsa be a -Scope paramétert úgy, hogy Organization a teljes bérlő entitásaihoz férhessen hozzá (például az összes munkaterület listájának lekéréséhez).
  • Műszaki felhasználók számára: Állítsa a -Scope paramétert Individual (vagy hagyja ki a paramétert) a felhasználóhoz tartozó entitásokhoz való hozzáféréshez (például azon munkaterületek listájának lekéréséhez, amelyek eléréséhez a felhasználó rendelkezik engedéllyel).

Fontolja meg azt a forgatókönyvet, amelyben le kell szereznie a szemantikai modellek listáját. Ha úgy dönt, hogy közvetlenül az API-kkal dolgozik, meg kell adnia, hogy melyik API-t hívja meg. Ha azonban a Get-PowerBIDataset parancsmagot használja, beállíthatja a -Scope paramétert a szemantikai modellek felhasználóspecifikus vagy bérlőszintű listájának lekéréséhez. A döntés attól függ, hogy miként használja a PowerShellt (az előző táblázatban).

Az alábbi táblázat azt ismerteti, hogy a PowerShell-parancsmagban használt paraméterek hogyan fordíthatók le az API PowerShell-hívásokra.

Parancsmag paraméterei A parancsmag által használt API Az API típusa Hatókör Lekért elemek
-DatasetID {DatasetID}
-Scope Individual		 Adatkészlet lekérése User Személyes munkaterület Egy szemantikai modell
-Scope Individual Adathalmazok lekérése User Személyes munkaterület Minden szemantikai modell
-DatasetID {DatasetID}
-GroupID {WorkspaceID}		 Adathalmaz lekérése a csoportban User Egy munkaterület Egy szemantikai modell, feltéve, hogy a bejelentkezett felhasználó rendelkezik engedéllyel a szemantikai modell olvasására
-GroupID {WorkspaceID} Adathalmazok lekérése a csoportban User Egy munkaterület Minden szemantikai modell, feltéve, hogy a bejelentkezett felhasználó rendelkezik engedéllyel a munkaterület eléréséhez és a szemantikai modell olvasásához
-GroupID {WorkspaceID}
-Scope Organization		 Adathalmazok beolvasása csoportba Rendszergazda Rendszergazda Egy munkaterület Minden szemantikai modell
-Scope Organization Adathalmazok lekérése Rendszergazda Rendszergazda Teljes bérlő Minden szemantikai modell
A PowerShell-parancsmagok használatának szempontjai

A Power BI PowerShell-parancsmagok használata egyszerűbb, mert a REST API-hívások összetettségének egy részét elvonják.

Íme néhány módszer arra, hogy a parancsmagok egyszerűbben férhessenek hozzá a naplózási adatokhoz.

  • Hitelesítés: A PowerShell-szkriptek hitelesítésének legegyszerűbb módja a Connect-PowerBIServiceAccount parancsmag használata.
  • Egyszerűség: Egyszerűbb az első lépésekhez, mert a naplózási adatok lekérésének módszerei egyszerűek. Vegye figyelembe, hogy a Get-PowerBIActivityEvent parancsmag használatakor egy napnyi naplózási adatot kell lekérni. Amikor azonban közvetlenül meghívja a Tevékenységesemények lekérése REST API-t, egy órányi naplózási adatot kér le. Így amikor a REST API-val kér le egy napi naplózási adatot, egy ciklus használatával 24 alkalommal kell meghívnia az API-t a nap minden órájának kinyeréséhez.
  • Nagy eredményhalmazok lapozása: A nagy eredményhalmazok hatékonyan kérhetők le lapozással. A lapozás magában foglalja az eredmények egy darabjának egyszerre történő lekérését. A parancsmagok automatikusan kezelik a lapozást. Ha azonban közvetlenül a REST API-kat használja, a szkriptnek ellenőriznie kell egy folytatási jogkivonatot annak megállapításához, hogy vannak-e további eredmények. A szkriptnek folytatnia kell az eredmények adattömbjeinek lekérését, amíg nem érkezik folytatási jogkivonat. A folytatási jogkivonat használatára példa: Tevékenységesemények REST API.
  • Hozzáférési jogkivonat lejárata: Hitelesítéskor a hozzáférési jogkivonat visszaadása történik. Alapértelmezés szerint egy óra elteltével lejár. A parancsmagok kezelik a hozzáférési jogkivonatok lejáratát. Így nem kell logikát írnia a frissítési jogkivonat kéréséhez.
  • Formázás: A parancsmag által visszaadott adatok kissé szebbek, mint a REST API által visszaadott adatok. A kimenet felhasználóbarátabb. Az automatizált naplózási folyamatok esetében ez valószínűleg nem jelent problémát. A manuális naplózási folyamatok esetében azonban hasznos lehet a szebb formázás.
A REST API-k közvetlen használatának szempontjai

A Power BI REST API-k meghívásának néha vannak előnyei.

  • Sokkal több API érhető el: Több REST API érhető el, mint a PowerShell-parancsmagok. Azonban ne hagyja figyelmen kívül az Invoke-PowerBIRestMethod parancsmag rugalmasságát, amellyel meghívhatja bármelyik Power BI REST API-t.
  • Frissítések gyakorisága: A Microsoft gyakrabban frissíti a REST API-kat, mint a PowerShell-modulokat. Ha például egy új attribútumot ad hozzá az Adathalmaz lekérése API-válaszhoz, eltarthat egy ideig, amíg elérhetővé válik a Get-PowerBIDataset parancsmag eredményei között.
  • Kevesebb nyelv-/eszközfüggőség: Ha közvetlenül (parancsmag helyett) használja a REST API-kat, nem kell a PowerShellt használnia. Vagy dönthet úgy is, hogy csak a PowerShellt használja számos API meghívására egy szkriptben. A PowerShell-függőségek eltávolításával (vagy elkerülésével) a jövőben egy másik nyelven is átírhatja a logikát. Ha az informatikai vagy fejlesztői csapat erős beállításokat biztosít az eszközök és a nyelvek iránt, a kisebb függőséget érdemes figyelembe venni.

Függetlenül attól, hogy melyik módszert választja, a REST API-k idővel változhatnak. Amikor egy technológia fejlődik, az API-k (és a PowerShell-modulok) elavulttá és lecserélhetők. Ezért azt javasoljuk, hogy szándékosan hozzon létre olyan szkripteket, amelyek egyszerűen karbantarthatók és rugalmasak a változásokhoz.

Ellenőrzőlista – Ha azt választja, hogy közvetlenül vagy PowerShell-parancsmagok használatával szeretné-e elérni a REST API-kat, a legfontosabb döntések és műveletek a következők:

  • A PowerShell használatával kapcsolatban forduljon az informatikai csapathoz, és állapítsa meg, hogy léteznek-e meglévő belső követelmények vagy beállítások a PowerShell használatára vonatkozóan.
  • Döntse el, hogyan szeretné használni a PowerShellt: Határozza meg, hogy mely PowerShell-technikákat használja, és hogy szándékosan szeretné-e növelni vagy csökkenteni a PowerShell-függőséget. Fontolja meg, hogy szükség van-e belső kommunikációra vagy képzésre.
  • Frissítés a PowerShell Core-ra: Kutatás a PowerShell Core használatával. Határozza meg, hogy frissíteni kell-e a rendszergazdai gépeket. Fontolja meg, hogy mely meglévő szkripteket kell tesztelni. Annak meghatározása, hogy a rendszergazdáknak vagy fejlesztőknek további képzésre van-e szükségük a készségeik fejlesztéséhez.
  • Határozza meg, hogy mely PowerShell-modulokat használja: Fontolja meg, hogy a Power BI Management-modulokat és/vagy a Data Gateway-modult fogja-e használni.
  • Döntse el, hogy a közösségi projektek engedélyezettek-e: Határozza meg, hogy engedélyezve van-e (vagy akár ajánlott) az interneten elérhető PowerShell-modulok használata (szemben a Microsoft által közzétett modulokkal). Konzultáljon az informatikai csapattal annak megállapításához, hogy vannak-e feltételek az online közösségi projektekhez.
  • Tisztázza, hogyan támogathatja a közösségi projekteket: Ha a PowerShell-alapú közösségi projektek engedélyezettek, fontolja meg, hogy ki lesz a felelős a támogatásukért, ha belsőleg használják őket.
  • Töltsön ki egy kis megvalósíthatósági igazolást (POC): Kísérletezzen egy technikai POC-val. Erősítse meg az előnyben részesített ügyféleszközöket és az adatok elérésének módját.
  • A speciális felhasználók támogatásának meghatározása: Fontolja meg, hogyan fogja támogatni azokat a technikai felhasználókat, akik önállóan hoznak létre automatizálást a felhasználói API-k használatával.

A naplózási adatok tárolásának helye

Amikor egy végpontok közötti naplózási megoldást tervez létrehozni, el kell döntenie, hogy hol tárolja a nyers adatokat (és a következő szakaszban tárgyalt válogatott adatokat). Az adattárolással kapcsolatos döntései az adatintegráció kezelésére vonatkozó beállításokhoz kapcsolódnak.

Ha nyers naplózási adatokat nyer ki, tartsa egyszerűnek. Javasoljuk, hogy az adatok első kinyerésekor ne válasszon ki konkrét attribútumokat, ne végezzen átalakításokat, és ne alkalmazzon formázást. Ehelyett bontsa ki az összes elérhető attribútumot, és tárolja az adatokat az eredeti állapotában.

A nyers adatok eredeti állapotban való tárolásának több oka is ajánlott eljárás.

  • Az előzményekben elérhető összes adat: Az új attribútumok és az új eseménytípusok idővel elérhetővé válnak. Az összes nyers adat tárolása jó módszer annak biztosítására, hogy a kinyeréskor mindig legyen hozzáférése a rendelkezésre álló adatokhoz. Még akkor is elemezhető, ha az új adatattribútumok rendelkezésre állásának felismerése akár heteket vagy hónapokat is igénybe vehet, mert a nyers adatokban rögzítette őket.
  • Rugalmas a változáshoz: Ha a nyers adatformátum megváltozik, az adatokat kinyerő folyamat nem lesz hatással. Mivel egyes naplózási adatok időérzékenyek, fontos, hogy olyan adatkinyerési folyamatot tervezzen, amely nem fog meghiúsulni, amikor változás történik a forrásban.
  • Szerepkörök és felelősségek: A különböző csapattagok (például adatmérnökök vagy globális rendszergazdák) felelősek lehetnek a nyers naplózási adatok elérésére, kinyerésére és tárolására szolgáló folyamatok létrehozásáért. Az adatkinyerési folyamat egyszerűsítése megkönnyíti a több csapat együttműködését.

Íme néhány lehetőség a nyers adatok tárolására.

  • Data lake vagy object storage: Egy felhőszolgáltatás, például a OneLake , amely bármilyen struktúra fájljainak tárolására specializálódott. Ideális választás a nyers naplózási adatok tárolásához. A data lake-architektúrában a nyers adatokat a bronz rétegben kell tárolni.
  • Fájlrendszer: A fájlrendszer (például Windows vagy Linux) gyakori választás a nyers naplózási adatok tárolására.
  • Adatbázis: JSON-adatok tárolhatók egy relációs adatbázisban, például az Azure SQL Database-ben. Ez azonban kevésbé gyakori, mint az adatok data lake-ben vagy fájlrendszerben való tárolása. Ennek az az oka, hogy a JSON-adatok lekérdezése és karbantartása nehézkessé és költségessé válhat, különösen az adatmennyiségek növekedésével.

Tipp.

Adattó, objektumtároló vagy fájlrendszer használata esetén azt javasoljuk, hogy könnyen rendszerezhető és biztonságos módon tárolja az adatokat. Azt is fontos tisztázni, hogy az adatok eseményekből állnak-e (amelyeket általában hozzáfűznek), vagy egy időponthoz kötött pillanatképről van-e szó (amihez meg kell jelölni egy elemezni kívánt dátumot).

Vegyünk egy példát, amely egy adattó nyers adatzónáját foglalja magában. A zóna mappahierarchiával rendelkezik a tevékenységnapló adatainak tárolásához: Raw > ActivityLog > YYYY > MM. A mappákat év és hónap szerint particionáltuk. A hónap mappában tárolt fájlok a következő formátumot használják: PBIActivityLog-YYYYMMDD-YYYYMMDDTTTT.json. Az YYYYMMDD a tényleges adatokat, az YYYYMMDDTTT pedig a kinyerési időbélyeget jelöli. A kinyerési időbélyeggel meghatározhatja, hogy melyik fájl a legújabb (abban az esetben, ha újra ki kell nyernie az adatokat). Ha például 2023. április 25-én 9 órakor (UTC) nyer ki adatokat a 2023. április 23-i tevékenységhez, a fájl neve PBIActivityLog-20230523-202305250900.

Határozottan javasoljuk, hogy olyan technológiát használjon, amely lehetővé teszi a nyers adatok nem módosítható tárolóba való írását. A nem módosítható tárolás garantálja, hogy az adatok írása után az adatok nem írhatók felül vagy törölhetők. Ez a megkülönböztetés fontos az auditorok számára, és lehetővé teszi, hogy megbízzanak abban, hogy a nyers adatok megbízhatóak.

Azt is figyelembe kell vennie, hogyan tárolhatja biztonságosan a nyers adatokat. Általában nagyon kevés felhasználónak kell hozzáférnie a nyers adatokhoz. A nyers adatokhoz való hozzáférést általában igény szerint biztosítják, jellemzően adatmérnökök és rendszergazdák számára. Előfordulhat, hogy a belső ellenőröknek hozzáférésre is szükségük lehet. A válogatott adatok létrehozásáért felelős csapattagok (a következő szakaszban leírtak) szintén hozzáférést igényelnek a nyers adatokhoz.

Az alábbiakban néhány szempontot figyelembe véve választhatja ki a nyers adattárolót.

  • Manuális vagy automatizált naplózási folyamat? Az automatizált naplózási folyamat általában szigorúbb követelményeket támaszt az adatok tárolási módjára és tárolására vonatkozóan.
  • Különösen érzékeny a téma? Az adatok típusától és az adatok bizalmasságától függően előfordulhat, hogy a szervezetnek meg kell felelnie annak tárolási módjára és tárolási helyére vonatkozó követelménynek. A Power BI naplózási adatai azonosítják a felhasználói adatokat és az IP-címeket, ezért biztonságos helyen kell tárolni őket.
  • Van előnyben részesített tárolási technológia? Előfordulhat, hogy egy meglévő tárolási technológia van használatban a szervezetben, ezért logikus választás.
  • A felhasználók közvetlenül érik el a tárterületet? A biztonsági modell fontos szempont. Általában nagyon kevés felhasználó kap hozzáférést a nyers adatokhoz. A válogatott adatokhoz való hozzáférés általában a Power BI-tartalomkészítők számára érhető el, akik a központosított adatmodell (a jelentéskészítés rétegeként szolgáló szemantikai modell) létrehozásáért felelősek.
  • Rendelkezik adattárolási követelményekkel? Egyes szervezetek jogi vagy szabályozási adattárolási követelményekkel rendelkeznek az adatok adott adatrégióban való tárolásához.
  • Hogyan lesznek rendszerezve az adatok? A medallion architektúra használata gyakori gyakorlat, különösen a Data Lake és a Lakehouse implementációiban. A cél az adatok tárolása bronz, ezüst és arany adatrétegekben. A bronz réteg tartalmazza az eredeti nyers adatokat. Az ezüstréteg az átalakításokhoz használt érvényesített és deduplikált adatokat tartalmazza. Az aranyréteg tartalmazza az elemzésre kész, válogatott, rendkívül finomított adatokat.

Ellenőrzőlista – Amikor a nyers adatok tárolásának helyét tervezi, a legfontosabb döntések és műveletek a következők:

  • Forduljon az informatikai csapathoz, és állapítsa meg, hogy léteznek-e olyan folyamatok, amelyek a nyers naplózási adatok kinyeréséhez futnak. Ha igen, megtudhatja, hogy hozzáfér-e a meglévő adatokhoz. Ha új adat kinyerési folyamatra van szükség, határozza meg, hogy vannak-e beállítások vagy követelmények az adatok tárolására.
  • Döntse el, hol tárolja a nyers adatokat: Határozza meg a legjobb tárolási helyet és struktúrát a nyers adatok tárolásához.
  • Az adatok tárolási követelményeinek meghatározása: Megtudhatja, hogy vannak-e jogi vagy szabályozási követelmények arra vonatkozóan, hogy hol tárolhatók az adatok.
  • Mappastruktúra és elnevezési konvenció létrehozása: Határozza meg, hogy milyen elnevezési konvenciót használjon a nyers adatfájlokhoz, beleértve a mappastruktúrát is. Adja meg ezeket a részleteket a műszaki dokumentációban.
  • Gondolja át, hogyan fog működni a nyers adatok biztonsága: A nyers adattárolási hely megtervezése során fontolja meg, hogy kinek kell hozzáférnie az adatokhoz, és hogyan fog hozzáférést biztosítani.

Válogatott adatok létrehozásának tervezése

A válogatott adatok támogatják az elemzést, és felhasználóbarátak. Meg kell hoznia néhány döntést a válogatott adatok létrehozásának módjáról és helyszínéről. A válogatott adatok tárolására kiválasztott technológia az előző szakaszban felsorolt technológiák bármelyike lehet.

A válogatott adatok célja, hogy az adatokat az elemzéshez és jelentéskészítéshez optimalizált, barátságosabb formátummá alakítsa. Ez egy Power BI-adatmodell adatforrása, ami azt jelenti, hogy Power BI-adatmodell használatával elemezheti a Power BI használatát a szervezetben. Alapvető adatmodell-útmutató: A teljesítményre és a használhatóságra optimalizált csillagséma-kialakítást kell alkalmaznia.

Különböző módokon hozhat létre válogatott adatokat. El kell döntenie, hogyan hajthatja végre az adatintegrációt , és milyen messze van az adatátalakulások alkalmazásához, amelyek előkészítik az adatokat egy csillagséma betöltésére.

Adattó

Átalakításokat alkalmazhat, és válogatott adatfájlokat hozhat létre egy adattóban. A válogatott adatokhoz aranyréteget kell használnia, hogy azok logikailag elkülönüljenek a bronzrétegben tárolt nyers adatoktól. Az adatok rétegekben való elkülönítése leegyszerűsíti a különböző felhasználói hozzáférési engedélyek beállítását is.

Adattó használata az adatok átalakításához és curate-hez a következő esetekben:

  • Arra számít, hogy több Power BI-adatmodell is lesz, amelyek jelentéskészítést szolgálnak ki (ami indokolja egy köztes ezüstréteg létrehozását).
  • Több önkiszolgáló tartalomkészítőt kell támogatnia, akiknek hozzáférésre van szükségük a bérlői szintű naplózási adatokhoz.
  • Rendelkezik olyan eszközökkel és folyamatokkal, amelyeket az adatok átalakításához és betöltéséhez szeretne használni.
  • Minimalizálni szeretné az adatelőkészítést, amelyet egy vagy több Power BI-adatmodellen belül el kell végezni (és esetleg duplikálni kell).
Power BI-adatmodell

A Power BI-ban az összes átalakítási munkát elvégezheti. A Power Query használatával elérheti és átalakíthatja az adatokat a nyers állapotából a válogatott formátumba.

Power BI-adatmodell használata a következő esetekben:

  • Egyszerűsíteni szeretné a végpontok közötti architektúrát, és közvetlenül a nyers adatokból töltené be az adatmodellt. (A növekményes frissítés segíthet csökkenteni a frissítés időtartamát.)
  • Az a cél, hogy az adatmodell betöltése közben az összes átalakítási munkát elvégezhesse.
  • A bérlői szintű naplózási adatokhoz egy központi adatmodellre lesz szüksége. Minden jelentés (vagy más adatmodell) használhatja a központosított Power BI szemantikai modellt forrásként.
  • Felhasználói hozzáférést csak a központosított Power BI szemantikai modellhez szeretne biztosítani (a forrásadatok egyikéhez sem).

Tipp.

A válogatott adatok létrehozásakor állítsa be úgy, hogy könnyen újrafuttassa a folyamatot a korábbi dátumtartományokhoz. Ha például azt észleli, hogy egy új attribútum jelent meg a naplókban három hónappal ezelőtt, érdemes elemezni, mivel az először megjelent. A válogatott adatelőzmények újbóli betöltésének lehetősége több oka is van annak, hogy fontos a nyers adatok eredeti állapotban való tárolása (a cikk korábbi részében leírtak szerint).

A csillagsémában szereplő dimenziótáblákról és ténytáblákról a jelen cikk későbbi, adatmodell létrehozása című szakaszában olvashat bővebben.

Ellenőrzőlista – A válogatott adatok létrehozásának tervezésekor a legfontosabb döntések és műveletek a következők:

  • Döntse el, hogy hol kell elvégezni az átalakításokat: Fontolja meg, hogy milyen messze kell elvégezni az átalakítási munkát, és hogy ez hol illeszkedik a teljes architektúra tervébe.
  • Döntse el, hogy milyen eszközt használjon az adatok csillagsé alakításához: Ellenőrizze, hogy mely eszközöket és szolgáltatásokat fogja használni a nyers adatok válogatott adatokká alakításához.
  • Döntse el, hogy hol tárolja a válogatott adatokat: Határozza meg a legjobb választást a csillagsémaformátummá átalakított nyers adatok tárolásához. Döntse el, hogy egy közbenső ezüstréteg hasznos-e a végpontok közötti architektúrában.
  • Elnevezési konvenció létrehozása: Határozza meg, hogy milyen elnevezési konvenciót használjon a válogatott adatfájlokhoz és mappákhoz (ha van ilyen). Adja meg a részleteket a műszaki dokumentációban.
  • Gondolja át, hogyan fog működni a válogatott adatok biztonsága: A válogatott adattárolási hely tervezésekor vegye figyelembe, hogy kinek kell hozzáférnie az adatokhoz, és hogyan lesz hozzárendelve a biztonság.

Adatforrás-döntések

Ezen a ponton egyértelműnek kell lennie a követelményekkel, az adatigényekkel és az engedélyekkel kapcsolatban. Kulcsfontosságú technikai döntések születtek. Most meg kell hoznia néhány döntést azzal kapcsolatban, hogyan szerezhet be bizonyos típusú adatokat.

Felhasználói tevékenység adatainak elérése

A Power BI felhasználói tevékenységadatai, amelyeket más néven tevékenységnaplóknak vagy auditnaplóknak is neveznek, számos információt tartalmaznak, amelyek segítenek megérteni a Power BI-bérlőben zajló eseményeket. Az adatigények azonosításával kapcsolatos további információkért tekintse meg a jelen cikk korábbi, felhasználói tevékenységre vonatkozó adatait .

A Power BI integrálja naplóit a Microsoft Purview egyesített naplójával (korábbi nevén a Microsoft 365 egyesített naplójával). Ez az integráció azért előnyös, mert azt jelenti, hogy a Microsoft 365 minden szolgáltatásának nem kell saját egyedi naplózási módszert alkalmaznia. Alapértelmezés szerint engedélyezve van.

Fontos

Ha még nem nyer ki felhasználói tevékenységadatokat, ezt sürgős prioritásként kell kezelnie. A felhasználói tevékenység adatai a legutóbbi 30 vagy 90 napra (a forrástól függően) érhetők el. Még ha nem is áll készen a részletes elemzésre, fontos, hogy a lehető leghamarabb megkezdje az adatok kinyerését és tárolását. Így értékes előzményeket lehet majd elemezni.

A felhasználói tevékenység adatainak lekérésére több lehetősége is van.

Technika Leírás Az előzmények alapértelmezett napja elérhető Jó választás manuális naplózási folyamatokhoz Jó választás automatizált naplózási folyamatokhoz Jó választás a riasztás beállításához Jó választás a gyors kezdéshez
Manuális (felhasználói felület) Microsoft Purview megfelelőségi portál 90 Microsoft Purview megfelelőségi portál jó választás manuális naplózási folyamatokhoz. Microsoft Purview megfelelőségi portál jó választás a gyors kezdéshez.
Manuális (felhasználói felület) Defender for Cloud Apps 30 Felhőhöz készült Defender Az alkalmazások jó választás manuális naplózási folyamatokhoz. Felhőhöz készült Defender Az alkalmazások jó választás a riasztások beállításához.
Szoftveres Power BI-tevékenységnapló (API- vagy PowerShell-parancsmag) 30 A Power BI-tevékenységnapló (API vagy PowerShell-parancsmag) jó választás az automatizált naplózási folyamatokhoz. A Power BI tevékenységnaplója (API vagy PowerShell-parancsmag) jó választás a gyors kezdéshez.
Szoftveres Office 365 Felügyeleti tevékenység API 7 Az Office 365 Felügyeleti tevékenység API jó választás az automatizált naplózási folyamatokhoz.
Szoftveres Microsoft Sentinel (Azure Monitor) 30 A Microsoft Sentinel (Azure Monitor) jó választás az automatizált naplózási folyamatokhoz. A Microsoft Sentinel (Azure Monitor) jó választás a riasztások beállításához.

A szakasz további részében a táblázatban bemutatott technikákat mutatjuk be.

Microsoft Purview megfelelőségi portál

A Microsoft Purview megfelelőségi portál (korábbi nevén Microsoft 365 megfelelőségi központ) naplózási keresőeszköze kényelmes hely a tevékenységek és riasztások megtekintéséhez. Ez az eszköz nem követeli meg, hogy szkriptet hozzon létre az adatok kinyeréséhez és letöltéséhez. Egy Power BI-számítási feladat kiválasztásával megtekintheti az összes naplórekordot egy adott ideig. Az eredményeket adott tevékenységek és felhasználók kiválasztásával is szűkítheti. Egy vezető például arra kéri, hogy derítse ki, ki törölte a munkaterületet korábban, hogy gyorsan kapcsolatba léphessenek a személlyel a helyzet megvitatása érdekében.

A legutóbbi 90 nap előzményei az Audit (Standard) szolgáltatással érhetők el. A Naplózás (Prémium) használatával a hosszú távú megőrzés lehetővé teszi (opcionálisan) a naplók hosszabb megőrzését. Mivel a hosszú távú megőrzés csak a licenccel rendelkező E5-felhasználókra vonatkozik, kizárja a nem E5-felhasználók és vendégfelhasználók naplózási rekordjait. Ezért azt javasoljuk, hogy csak az alapértelmezett 90 napos előzményre támaszkodjon, hogy minden tevékenység rögzítve legyen.

A Microsoft Purview megfelelőségi portál naplóinak eléréséhez licencelési követelmények vonatkoznak. Az auditnaplók eléréséhez emelt szintű Exchange Online-engedélyekre is szükség van.

Tipp.

A Power BI-rendszergazdák alapértelmezés szerint nem rendelkeznek engedéllyel az egyesített naplókeresés eléréséhez a Microsoft Purview megfelelőségi portál. Mivel számos Microsoft 365-szolgáltatás adatait tartalmazza, ez egy magas jogosultsági szintű szerepkör. A legtöbb szervezetben ezek az engedélyek kevés informatikai rendszergazda számára vannak fenntartva. A Power BI-rendszergazdák további lehetőségeket is igénybevehet, amelyeket a szakasz későbbi részében ismertetünk.

A Microsoft Purview megfelelőségi portál felhasználói felülete hasznos a manuális naplózási folyamatokhoz és a felhasználói tevékenységek alkalmi vizsgálatához.

Defender for Cloud Apps

A Felhőhöz készült Defender-alkalmazások portálja kényelmes hely a tevékenységek és riasztások megtekintésére anélkül, hogy létre kellene hoznia egy szkriptet az adatok kinyeréséhez és letöltéséhez. Emellett a Power BI tevékenységnaplójából és a felhasználói bejelentkezésekből is megtekintheti az adatokat.

Felhőhöz készült Defender Alkalmazások tartalmaz egy felhasználói felületet a különböző felhőszolgáltatások tevékenységnaplóinak megtekintéséhez és kereséséhez, beleértve a Power BI-t is. Ugyanazokat a naplóeseményeket jeleníti meg, amelyek a Microsoft Purview egyesített naplózási naplójából származnak, és más eseményeket is tartalmaz, például a Microsoft Entra ID-ból származó felhasználói bejelentkezési tevékenységet.

Az Microsoft Purview megfelelőségi portál (az előző szakaszban leírtakhoz hasonlóan) az Felhőhöz készült Defender Apps is kereshető felhasználói felülettel rendelkezik. A szűrési beállítások azonban eltérőek. A szokásos 30 napos előzmények mellett a Felhőhöz készült Defender-alkalmazások segítségével akár hat hónapos tevékenységnapló-előzményt is megtekinthet (hétnapos lépésekben).

A Felhőhöz készült Defender-alkalmazások eléréséhez licencelési követelmények vonatkoznak. Külön engedélyekre is szükség van.

Tipp.

A Power BI-rendszergazdák alapértelmezés szerint nem rendelkeznek engedéllyel az Felhőhöz készült Defender-alkalmazások eléréséhez. Power BI-szerepkör van a Felhőhöz készült Defender-alkalmazásokban. Ha Power BI-rendszergazdákat ad hozzá ehhez a szerepkörhöz, az jó módszer arra, hogy korlátozott számú adathoz biztosítson hozzáférést.

Az Felhőhöz készült Defender Apps felhasználói felülete hasznos a manuális naplózási folyamatokhoz és a felhasználói tevékenységek egyszeri vizsgálatához.

Power BI-tevékenységnapló

A Power BI tevékenységnaplója az egyesített naplóból származik. Csak a Power BI szolgáltatás kapcsolatos felhasználói tevékenységeket tartalmazza.

Tipp.

Azoknak a szervezeteknek, amelyek felhasználói tevékenységeket szeretnének kinyerni, javasoljuk, hogy a Power BI tevékenységnaplójával kezdjenek. Ez a legegyszerűbb forrás a programozott hozzáféréshez.

A Power BI tevékenységnaplójának eléréséhez két lehetősége van.

A használni kívánt beállításról a jelen cikk korábbi, API-k vagy PowerShell-parancsmagok kiválasztása című témakörben olvashat.

Tipp.

Példák a Power BI-tevékenységnapló PowerShell-lel való elérésére: Access the Power BI activity log.

A Power BI tevékenységnapló-adatai minden Power BI-rendszergazda, Power Platform-rendszergazda és globális rendszergazda számára elérhetők. Az adatok az egyes Exchange Online-szerepkörök számára elérhető egyesített naplózási naplóból érhetők el. További információ: Felhasználói tevékenységek nyomon követése a Power BI-ban.

Javasoljuk, hogy akkor használja a Power BI tevékenységnaplóját, ha csak a Power BI naplórekordjait szeretné lekérni.

Feljegyzés

A naplóadatokban a munkaterületeket mappáknak nevezzük. A Power BI REST API-ban a munkaterületeket csoportoknak nevezzük.

Office 365 Felügyeleti tevékenység API

Más szolgáltatások, például a SharePoint Online, a Teams, az Exchange Online, a Dynamics 365 és a Power BI egyesített naplózási naplójából is kinyerhet adatokat. Ha a cél egy naplózási és monitorozási megoldás megvalósítása több szolgáltatáshoz, javasoljuk, hogy használja az Office 365 Felügyeleti tevékenység API-t. Mivel ez az API számos szolgáltatásból ad vissza adatokat, egyesített naplózási API-nak (vagy egyesített naplózási naplónak) nevezzük. Ez az Office 365 Felügyeleti API-k egyike.

Mielőtt új megoldást hoz létre, javasoljuk, hogy forduljon az informatikai részleghez, és állapítsa meg, hogy elérhetők-e a meglévő Power BI-naplózási rekordok. Lehetséges, hogy egy folyamat már kinyeri és tárolja az adatokat. Az is lehetséges, hogy új megoldás létrehozása helyett engedélyt kaphat az adatok elérésére.

Az adatok kétféleképpen érhetők el.

  • Hívja meg közvetlenül az Office 365 Felügyeleti tevékenység API-t a választott eszközzel. Alapértelmezés szerint az API 24 órányi adatot ad vissza. Legfeljebb hét napnyi előzményt kérdezhet le.
  • Használja a Search-UnifiedAuditLog PowerShell-parancsmagot. Ez egy Exchange Online PowerShell-parancsmag. Legfeljebb 90 napos előzményt kérdezhet le.

Fontos

A Search-UnifiedAuditLog parancsmag nem skálázható megfelelően, és egy hurkolási stratégiát kell implementálnia az 5000 soros korlát leküzdése érdekében. Ezen okok miatt alkalmas alkalmi lekérdezésekhez, vagy alacsony aktivitású kis szervezetekhez. Ha csak Power BI-adatokra van szüksége, javasoljuk, hogy inkább a Get-PowerBIActivityEvent parancsmagot használja.

Általánosságban elmondható, hogy az Office 365 Felügyeleti tevékenység API használatának első lépései nagyobb kihívást jelentenek, mint a Power BI tevékenységnaplójának (korábban ismertetett) használata. Ennek az az oka, hogy az API tartalomblobokat ad vissza, és minden tartalomblob egyedi naplózási rekordokat tartalmaz. Nagy szervezetek esetén több ezer tartalomblob lehet naponta. Mivel az ügyfelek és a külső alkalmazások erősen használják ezt az API-t, a Microsoft szabályozást implementál annak érdekében, hogy a szolgáltatás használata ne legyen negatív hatással másokra (ez a zajos szomszéd probléma). Ezért a nagy mennyiségű előzmény lekérése kihívást jelenthet a nagyobb szervezetek számára. További információkért tekintse meg ezt a hibaelhárítási cikket.

Az API használatához hitelesítenie kell egy szolgáltatásnévvel, amely engedélyt kapott az adatok lekérésére az Office 365 Felügyeleti tevékenység API-ból.

Tipp.

Alapértelmezés szerint a Power BI-rendszergazdák nem rendelkeznek engedéllyel az Office 365 Felügyeleti tevékenység API eléréséhez. Mivel számos Microsoft 365-szolgáltatás adatait tartalmazza, a hozzáféréshez magas jogosultságú rendszergazdai vagy naplózási szerepkörre van szükség. A legtöbb szervezetben ezek a szerepkörök kevés informatikai rendszergazda számára vannak fenntartva. A Power BI-tevékenységnaplót a Power BI-rendszergazdák használják.

A naplózási adatok programozott lekérése az Office 365 Felügyeleti tevékenység API-ból jó választás, ha az informatikai cégnek ki kell nyernie és tárolnia a naplókat különböző szolgáltatásokból (a Power BI-on kívül).

Microsoft Sentinel

A Microsoft Sentinel egy Azure-szolgáltatás, amely lehetővé teszi a biztonsági incidensek és fenyegetések gyűjtését, észlelését, kivizsgálását és megválaszolását. A Power BI-t a Microsoft Sentinelben állíthatja be adatösszekötőként. Ha csatlakozik, a rendszer a power BI-ból az Azure Log Analyticsbe streameli az auditnaplókat (amelyek az adatok egy részét tartalmazzák). Ez az Azure Monitor képessége.

Tipp.

Az Azure Log Analytics a munkaterületszintű szemantikai modell eseménynaplói által használt architektúrán alapul. További információ a szemantikai modell eseménynaplóiról: Adatszintű naplózás.

Mivel ez egy külön Azure-szolgáltatás, minden olyan rendszergazdának vagy felhasználónak, aki Kusto lekérdezésnyelv (KQL) lekérdezéseket szeretne futtatni, engedélyeket kell kapnia az Azure Log Analyticsben (Azure Monitor). Ha rendelkeznek engedéllyel, lekérdezhetik a PowerBIActivity táblában tárolt naplózási adatokat. Ne feledje azonban, hogy a legtöbb esetben a bronz rétegben lévő nyers adatok helyett hozzáférést biztosít a felhasználóknak az aranyrétegben lévő válogatott adatokhoz.

A KQL használatával elemezheti az Azure Log Analyticsben tárolt tevékenységnapló-eseményeket. Ha rendelkezik SQL-tapasztalattal, számos hasonlóságot talál a KQL-vel.

Az Azure Log Analyticsben tárolt események többféleképpen is elérhetők. A következőket használhatja:

  • Az előre összeállított Log Analytics for Power BI Szemantikai modellek sablonalkalmazás.
  • Power BI Desktop-összekötő az Azure Data Explorerhez (Kusto).
  • Webes lekérdezési élmény az Azure Data Explorerben.
  • Minden olyan lekérdezési eszköz, amely képes KQL-lekérdezéseket küldeni.

Figyelemfelhívás

Vegye figyelembe, hogy a Power BI tevékenységnapló-adatainak csak egy része van tárolva az Azure Monitorban. Ha átfogó elemzést tervez a Power BI használatáról és bevezetéséről a szervezetben, javasoljuk, hogy a tevékenységadatok lekéréséhez más lehetőségeket is használjon (a jelen szakaszban korábban leírtak szerint).

A lekérhető előzmények időtartama az Azure Log Analytics-munkaterület adatmegőrzési szabályzatától függ. Fontolja meg a nyers adatokhoz való hozzáférést és költségeket, amikor eldönti, hogy mennyi adatot szeretne megőrizni.

A Microsoft Sentinel és az Azure Monitor akkor jó választás, ha az informatikai cég már befektetést hajtott végre a Microsoft Sentinellel, a rögzített részletességi szint megfelel az igényeinek, és az olyan tevékenységek, mint a fenyegetésészlelés , prioritást élveznek. Mivel azonban a Microsoft Sentinel nem rögzíti az összes Power BI-tevékenységadatot, nem támogatja a Power BI használatának és bevezetésének átfogó elemzését.

Felhasználói tevékenység adataival kapcsolatos szempontok

Az alábbiakban néhány szempontot talál a felhasználói tevékenység adatainak forrásának kiválasztásához.

  • Manuális vagy automatizált naplózási folyamat lesz? A felhasználói felület beállításai jól működnek a manuális naplózási folyamatokhoz és az alkalmi egyszeri lekérdezésekhez, különösen akkor, ha egy adott tevékenység vizsgálatára van szükség. Az előzményadatok elemzésének támogatásához szükség lesz egy automatikus naplózási folyamatra is, amely ütemezés szerint nyeri ki a felhasználói tevékenység adatait.
  • Milyen gyakran van szüksége a felhasználói tevékenység adataira? Automatizált naplózási folyamatok esetén a helyi idő helyett a helyi idő helyett az aktuális dátum előtt legalább egy nappal elérhető adatok kinyerését tervezze meg az egyezményes világidő (UTC) használatával. Ha például a folyamat péntek reggel (UTC idő) fut, szerdától kell adatokat kinyernie. Több oka is van annak, hogy egy napos késéssel kell kinyernie az adatokat.
    • A fájlok egyszerűbben használhatók, ha mindig teljes 24 órát nyer ki egyszerre, így elkerülheti a részleges napi eredményeket.
    • Minimálisra csökkenti a naplózási események hiányának kockázatát. A naplózási események általában 30 percen belül érkeznek meg. Egyes események esetenként akár 24 órát is igénybe vehetnek az egyesített naplózási naplóba való megérkezéshez.
  • Többre van szüksége a Power BI-adatoknál? Fontolja meg a szükséges adatok elérésének leghatékonyabb módját.
  • Ki fogja fejleszteni a megoldást? Tervezze meg, hogy időt szán a megoldás kiépítésére. Jelentős erőfeszítést igényelhet egy éles használatra kész szkript létrehozása.

Ellenőrzőlista – A felhasználói tevékenység adatainak elérésekor a legfontosabb döntések és műveletek a következők:

  • Az igények hatókörének tisztázása: Annak meghatározása, hogy csak a Power BI-naplózási rekordokhoz kell-e hozzáférnie, vagy több szolgáltatás adatainak naplózása.
  • Konzultáljon az informatikai szolgáltatással: Megtudhatja, hogy az informatikai rendszer jelenleg kinyeri-e az auditnaplókat, és hogy lehetséges-e hozzáférést szerezni a nyers adatokhoz, hogy ne kelljen új megoldást létrehoznia.
  • Válasszon adatforrást: Határozza meg a felhasználói tevékenység adatainak eléréséhez leginkább használható forrást.
  • Fogalmi igazolás elvégzése: Tervezze meg egy kis technikai megvalósíthatósági igazolás (POC) elvégzését. Ezzel ellenőrizheti a végső megoldás létrehozásának módjával kapcsolatos döntéseket.
  • További adatigények nyomon követése: A tevékenységnapló adatait más forrásokkal is korrelálhatja az adatok értékének növelése érdekében. Nyomon követheti ezeket a lehetőségeket, amint felmerülnek, hogy hozzáadhassák őket a projekt hatóköréhez.

Bérlői leltáradatok elérése

A bérlői leltár egy érett naplózási és monitorozási megoldás felbecsülhetetlen és szükséges része. Segít megérteni, hogy milyen munkaterületek és tartalmak (szemantikai modellek, jelentések és egyéb elemek) léteznek a Power BI-ban, és kiválóan kiegészítik a felhasználói tevékenység adatait (az előző szakaszban leírtak szerint). Az adatigények azonosításával kapcsolatos további információkért tekintse meg a cikk korábbi, bérlői leltárát .

A felhasználói tevékenységek (korábban leírt) naplózási események; a felhasználó által egy adott időpontban és időpontban végrehajtott műveletek rekordja. A bérlői leltár azonban eltérő. A bérlői leltár egy pillanatkép egy adott időpontban. A Power BI szolgáltatás összes közzétett elemének aktuális állapotát ismerteti a kinyeréskor.

Feljegyzés

A Power BI REST API dokumentációja összetevőkként hivatkozik a közzétett elemekre.

Tipp.

Sok szervezet hasznosnak találja, ha a bérlői leltárt minden héten ugyanabban a napban nyeri ki.

A Power BI-bérlőben zajló események megfelelő elemzéséhez a felhasználói tevékenység adataira és a bérlői leltárra is szükség van. Ezek kombinálásával megtudhatja, hogy mennyi tartalommal rendelkezik, és hol található. Lehetővé teszi a nem használt vagy nem használt tartalmak megkeresését is (mivel a tevékenységnaplóban nem lesznek események). A bérlői leltár segítségével az összes elem aktuális nevének listáját is összeállíthatja, ami hasznos lehet az elemnevek módosításakor.

A bérlői leltár értékével kapcsolatos további információkért lásd a cikk korábbi, bérlői leltárát .

Tipp.

A Fel nem használt összetevők lekérése API-val Rendszergazda olyan elemeket kereshet, amelyek nem rendelkeznek felhasználói tevékenységekkel az elmúlt 30 napban. Ezt az időszakot azonban nem szabhatja testre. Előfordulhat például, hogy kritikus tartalommal rendelkezik, amelyet csak negyedévente használnak. A bérlői leltár és a felhasználói tevékenység adatainak kombinálásával testre szabható módon megtalálhatja a nem használt elemeket.

A bérlői leltáradatokat kétféleképpen szerezheti be.

Technika Leírás Leginkább a Jó választás manuális naplózási folyamatokhoz Jó választás automatizált naplózási folyamatokhoz
Szoftveres Az Get Groups as Admin API vagy a Get-PowerBIWorkspace PowerShell-parancsmag a teljes bérlő munkaterületeinek listáját biztosíthatja. Lehetőség van arra, hogy munkaterületenként külön elemeket (például szemantikai modelleket és jelentéseket) is tartalmazzon. Kisebb szervezetek vagy alacsony adatmennyiség A Csoportok lekérése Rendszergazda API-ként vagy a Get-PowerBIWorkspace PowerShell-parancsmagja jó választás manuális naplózási folyamatokhoz. A Csoportok lekérése Rendszergazda API-ként vagy a Get-PowerBIWorkspace PowerShell-parancsmagja jó választás az automatizált naplózási folyamatokhoz.
Szoftveres Az aszinkron rendszergazdai API-k (más néven metaadat-beolvasási API-k vagy scanner API-k) készlete a munkaterületek és az egyes elemek listáját is visszaadhatja. Igény szerint részletes metaadatokat (például táblákat, oszlopokat és mértékkifejezéseket) is tartalmazhat. Nagy adatmennyiségű és/vagy részletes eredményeket igénylő szervezetek A metaadat-ellenőrzési API-k jó választásnak számítanak az automatizált naplózási folyamatokhoz.

A szakasz további részében a táblázatban bemutatott technikákat mutatjuk be.

Csoportok API-k vagy munkaterületek parancsmagja

A munkaterületek listájának lekéréséhez számos REST API egyikét használhatja, például a Csoportok lekérése Rendszergazda API-ként (a választott eszközzel). Az eredmények további metaadatokat tartalmaznak, például a leírást és azt, hogy a munkaterület prémium szintű kapacitásban van-e tárolva.

Feljegyzés

Az elnevezett API egy munkaterületre mutató hivatkozásként tartalmazza a kifejezéscsoportot. Ez a kifejezés az eredeti Power BI biztonsági modellből származik, amely a Microsoft 365-csoportokra támaszkodott. Bár a Power BI biztonsági modellje jelentősen fejlődött az évek során, a meglévő API-nevek változatlanok maradnak a meglévő megoldások feltörésének elkerülése érdekében.

A Get Groups as Admin REST API tartalmazza a hasznos $expand paramétert. Ez a paraméter lehetővé teszi az eredmények kibontását, hogy azok tartalmazzák a munkaterületen közzétett elemek listáját (például szemantikai modelleket és jelentéseket). Az adattípust users a paraméternek $expand is átadhatja, hogy a munkaterületi szerepkörhöz hozzárendelt felhasználók is szerepeljenek.

A Get-PowerBIWorkspace PowerShell-parancsmagot is használhatja. A Power BI Felügyeleti munkaterületek modulból származik. A paraméter organizationbeállításakor az -Scope API-hoz Get Groups as Admin hasonlóan működik. A parancsmag emellett elfogadja a -Include paramétert (amely a REST API paraméterének $expand megfelelő) a munkaterületen közzétett elemek (például szemantikai modellek és jelentések) belefoglalásához.

Tipp.

A paraméterek átadásával a parancsmagot különböző módokon használhatja. Ez a szakasz egy bérlőszintű leltár lekérésére összpontosít. A paraméter használatáról a -Scope jelen cikk korábbi, felhasználói API- vagy rendszergazdai API-jának kiválasztása című témakörben talál további információt.

Ha segítségre van szüksége a használni kívánt beállítás kiválasztásához, olvassa el a jelen cikk korábbi, API-k vagy PowerShell-parancsmagok kiválasztása című témakört.

A Get Groups as Admin REST API vagy a Get-PowerBIWorkspace PowerShell-parancsmag a legjobban alkalmas manuális naplózási folyamatokhoz és egyszeri vizsgálatokhoz. A nagy adatmennyiséggel rendelkező nagyobb szervezetek általában nehezen használják ezeket a lehetőségeket. A REST API és a parancsmag mindig teljes adatkészletet nyer ki, így azok futtatása hosszú időt vehet igénybe. Ezért valószínű, hogy a nagyobb szervezetek az óránként engedélyezett kérések számának korlátozásába ütköznek (ezt szabályozásnak nevezzük, amely a szolgáltatás egészségének védelme érdekében történik). A metaadat-beolvasási API-k (a következő szakaszban ismertetett) megbízhatóbb és méretezhetőbb alternatívát nyújtanak.

Metaadatok vizsgálata API-k

A metaadat-ellenőrzési API-k, más néven scanner API-k olyan API-k, amelyek a munkaterületek és azok Power BI-elemeinek listáját (szemantikai modellek, jelentések és egyéb elemek) adnak vissza. Elméletileg ugyanazokat az adatokat (és egyebeket) adják meg, mint a Csoportok API-k vagy a munkaterület-parancsmag, amelyeket az előző szakaszban ismertetünk. Az adatok lekérésére használt módszer azonban eltérő, és jobban megfelel a bérlői leltár kinyeréséhez.

Feljegyzés

Figyelje meg, hogy egyes felhasználók hogyan használják a scanner API-kat vagy a bérlőt beolvasó kifejezést. Gyakran használják ezeket a kifejezéseket a bérlői leltár összeállítására, megkülönböztetve azt a felhasználói tevékenység eseményeitől. Lehet, hogy szó szerint hivatkoznak a metaadat-ellenőrző API-k használatára.

Két elsődleges oka van annak, hogy érdemes a metaadat-vizsgálati API-kat használni a Get Groups as Admin REST API vagy a Get-PowerBIWorkspace parancsmag helyett (ezt korábban ismertetjük).

  • Növekményes adat kinyerése: A képolvasó API-k csak a legutóbbi futtatás óta módosított adatokat nyerik ki. Ezzel szemben a Get Groups as Admin REST API és a Get-PowerBIWorkspace parancsmag szinkron műveletek, amelyek minden futtatáskor kinyerik a teljes adatkészletet.
  • Részletesebb részletességi szint: A képolvasó API-k részletes részleteket (például táblákat, oszlopokat és mértékkifejezéseket) képesek lekérni, így a részletes metaadatokhoz a két bérlői beállítás engedélyt ad. Ezzel szemben a REST API-val és a Get Groups as AdminGet-PowerBIWorkspace parancsmaggal elérhető legalacsonyabb részletességi szint elemtípus szerint van (például egy munkaterület jelentéseinek listája).

A scanner API-k használata nagyobb erőfeszítést igényel, mivel több API-t kell meghívnia. Emellett aszinkron folyamatként is futnak. Egy aszinkron folyamat fut a háttérben, így nem kell megvárnia, amíg befejeződik. Előfordulhat, hogy együtt kell működnie az informatikai csapattal vagy egy fejlesztővel, amikor létre kell hoznia egy üzemkész szkriptet, amely ütemezve lesz.

Az alábbiakban bemutatjuk, hogy a folyamatnak milyen lépéseket kell követnie a képolvasó API-k használatakor.

  1. Bejelentkezés: Jelentkezzen be a Power BI szolgáltatás egy Power BI-rendszergazdai fiók vagy egy rendszergazdai API-k futtatására jogosult szolgáltatásnév használatával. További információ: A hitelesítési módszer meghatározása a cikk korábbi részében.
  2. A munkaterület azonosítóinak lekérése: Kérés küldése a munkaterület-azonosítók listájának lekéréséhez. Az első futtatáskor nem lesz módosított dátum, ezért a munkaterületek teljes listáját adja vissza. Általában a módosított dátumot kell megadnia, hogy csak azokat a munkaterületeket kérje le, amelyek azóta megváltoztak. A módosított dátumnak az elmúlt 30 napon belül kell lennie.
  3. Metaadat-vizsgálat kezdeményezése: Hívás kezdeményezése a munkaterület adatainak vizsgálatához a 2. lépésben lekért munkaterület-azonosítók átadásával. Vegye figyelembe, hogy ez egy POST API (a GET API helyett, amely gyakoribb a naplózási adatok lekérésekor). A POST API egy HTTP-kérés, amely adatokat hoz létre vagy ír egy adott erőforráshoz. Ez a lekérdezés megadja a kinyerni kívánt részletességi szintet, például az adatforrás adatait, a szemantikai modell sémáját, a szemantikai modellkifejezéseket vagy a felhasználókat. A beküldéskor az API visszaadja a vizsgálat azonosítóját. Emellett visszaadja a vizsgálat dátumát és időpontját is, amelyet pillanatképdátumként kell rögzítenie.
  4. Ellenőrizze a vizsgálat állapotát: A vizsgálat állapotának lekéréséhez használja a 3. lépésben beszerzett vizsgálati azonosítót. Előfordulhat, hogy többször is meg kell hívnia ezt az API-t. Ha a visszaadott állapot sikeres, továbbléphet a következő lépésre. A vizsgálat időtartama attól függ, hogy mennyi adatot kér le.
  5. Az eredmények lekérése: Használja a 3. lépésben beszerzett vizsgálati azonosítót a vizsgálati eredmény lekéréséhez és az adatok kinyeréséhez. Ezt a lépést a 4. lépés befejezését követő 24 órán belül kell elvégeznie. Ne feledje, hogy a pillanatkép időbélyegének az 5. lépés helyett a 3. lépéssel kell korrelálnia (jelentős késés esetén). Így pontos pillanatkép időbélyeggel fog rendelkezni. Mentse az eredményeket az előnyben részesített adattárhelyen. A cikkben leírtaknak megfelelően javasoljuk, hogy a nyers adatokat az eredeti állapotában tárolja.
  6. Készüljön fel a következő folyamatra: Jegyezze fel a vizsgálat időbélyegét a 3. lépésből, hogy a 2. lépésben használhassa a folyamat következő futtatásakor. Így csak az azóta megváltozott adatokat fogja kinyerni. A további adatkivonatok a teljes pillanatképek helyett növekményes változások lesznek.

Ellenőrzőlista – A bérlői leltáradatokhoz való hozzáférés tervezésekor a legfontosabb döntések és műveletek a következők:

  • Követelmények megerősítése: A bérlői leltár összeállításának és az adatok elemzési követelményeinek tisztázása.
  • Döntse el a bérlői leltár kinyerési gyakoriságát: Győződjön meg arról, hogy milyen gyakran lesz szüksége új bérlői leltárra (például hetente).
  • Döntse el, hogyan kell kinyerni a bérlői leltárt: Ellenőrizze, hogy melyik módszert fogja használni a bérlői leltáradatok (API, parancsmag vagy metaadat-ellenőrző API-k) beszerzéséhez.
  • Fogalmi igazolás elvégzése: Tervezze meg egy kis technikai megvalósíthatósági igazolás (POC) elvégzését. Ezzel ellenőrizheti a végső megoldás létrehozásának módjával kapcsolatos döntéseket.

Felhasználói és csoportadatok elérése

A felhasználói tevékenység adataiban szereplő azonosító adatok (például e-mail-cím) mellett érdemes további információkat, például a tartózkodási helyet vagy a szervezeti adatokat is lekérni. A Microsoft Graph segítségével adatokat kérdezhet le a felhasználókról, csoportokról, szolgáltatásnevekről és licencekről. A Microsoft Graph API-k és ügyfélkódtárak készletéből áll, amelyek lehetővé teszik a naplózási adatok lekérését számos szolgáltatásból.

Íme néhány részlet az elérhető Microsoft Entra-objektumokról.

  • Felhasználó: A Microsoft Entra-azonosítóban munkahelyi, iskolai vagy Microsoft-fiókként létező identitás. A tartományfelhasználó kifejezést gyakran használják a szervezeti felhasználók leírására, míg a formális kifejezés a felhasználónév (UPN). Az UPN általában megegyezik a felhasználó e-mail-címével (ha azonban megváltozik egy e-mail-cím, az UPN nem változik, mert nem módosítható). Minden felhasználóhoz egyedi Microsoft Graph-azonosító tartozik. Gyakran előfordul, hogy egy felhasználói fiók egy személyhez van társítva. Egyes szervezetek olyan felhasználókat hoznak létre, akik szolgáltatásfiókok , amelyeket automatizált tevékenységekhez vagy rendszergazdai feladatokhoz használnak.
  • Szolgáltatásnév: Egy alkalmazásregisztráció létrehozásakor kiosztott identitástípus. A szolgáltatásnév felügyelet nélküli, automatizált tevékenységekre szolgál. További információ: A hitelesítési módszer meghatározása a cikk korábbi részében.
  • Csoport: Felhasználók és szolgáltatásnevek gyűjteménye. Az engedélyek kezelésének egyszerűsítéséhez számos csoporttípus használható. További információkért lásd a csoportok használatának stratégiáját.

Feljegyzés

Ha ez a cikk felhasználókra és csoportokra hivatkozik, ez a kifejezés a szolgáltatásnevekre is vonatkozik. Ez a rövidebb kifejezés a rövidség kedvéért használatos.

A lekért felhasználók és csoportok adatai egy pillanatképek , amelyek az aktuális állapotot írják le egy adott időpontban.

Tipp.

További információ a felhasználókról, a szolgáltatásnevekről és a csoportokról: Integráció a Microsoft Entra-azonosítóval.

Elemzési attribútumok

A Power BI bérlői szintű naplózásához kinyerheti és tárolhatja az alábbi attribútumokat a Microsoft Graphból.

  • Felhasználók teljes neve: Számos adatforrás csak a tevékenységet végző vagy szerepkörhöz rendelt felhasználó e-mail-címét tartalmazza. Ezt az attribútumot akkor használja, ha a teljes nevet (megjelenítendő nevet) szeretné megjeleníteni az elemzési jelentésekben. A teljes név használata felhasználóbarátabbá teszi a jelentéseket.
  • Egyéb felhasználói tulajdonságok: A felhasználókkal kapcsolatos egyéb leíró attribútumok a Microsoft Entra ID-ban érhetők el. Az elemzési értékkel rendelkező beépített felhasználóiprofil-attribútumok közé tartozik például a beosztás, a részleg, a vezető, a régió és az iroda helye.
  • Biztonsági csoport tagjai: A legtöbb adatforrás megadja a csoport nevét (például a Power BI tevékenységnapló-rekordjait, amelyek szerint egy biztonsági csoport egy munkaterületi szerepkörhöz lett hozzárendelve). A csoporttagság beolvasásával teljes mértékben elemezheti, hogy az egyes felhasználók mit csinálnak vagy milyen hozzáféréssel rendelkezik.
  • Felhasználói licencek: Hasznos elemezni, hogy mely felhasználói licencek – ingyenes, Power BI Pro vagy Felhasználónkénti Power BI Premium (PPU) – vannak hozzárendelve a felhasználókhoz. Ezek az adatok segíthetnek azonosítani, hogy ki nem használja a licencét. Emellett segít elemezni az összes felhasználót (licenccel rendelkező különálló felhasználókat) és az aktív felhasználókat (a legutóbbi tevékenységekkel). Ha a Power BI Premium-licencek hozzáadását vagy bővítését fontolgatja, javasoljuk, hogy a költségelemzéshez elemezze a felhasználói licencadatokat a felhasználói tevékenység adataival együtt.
  • A rendszergazdai szerepkörök tagjai: Összeállíthatja a Power BI-rendszergazdák listáját (beleértve a Power Platform rendszergazdáit és a globális rendszergazdákat).

A Microsoft Graph naplózási adataiban található Power BI-licencinformációk mérvadó hivatkozásáért lásd a licencelés termékneveit és szolgáltatáscsomag-azonosítóit.

Tipp.

A tagok csoportokból való lekérése a naplózási adatok lekérésének egyik legnehezebb aspektusa lehet. Az összes beágyazott tag és beágyazott csoport összesimításához tranzitív keresést kell végeznie. Tranzitív keresést végezhet a csoporttagok között. Az ilyen típusú keresés különösen nagy kihívást jelent, ha több ezer csoport van a szervezetben. Ebben az esetben érdemes lehet jobb alternatívát használni az adatok lekérésére. Az egyik lehetőség az, hogy kinyeri az összes csoportot és csoporttagot a Microsoft Graphból. Ez azonban nem feltétlenül praktikus, ha csak kis számú csoportot használnak a Power BI biztonságához. Egy másik lehetőség a Power BI-biztonság bármely típusa által használt csoportok (munkaterületi szerepkörök, alkalmazásengedélyek, elemenkénti megosztás, sorszintű biztonság stb.) által használt csoportok referencialistájának előzetes összeállítása. Ezután végighaladhat a referencialistán a csoporttagok Microsoft Graphból való lekéréséhez.

Íme néhány egyéb attribútum, amelyeket kinyerhet és tárolhat.

  • Felhasználó típusa: A felhasználók tagok vagy vendégek. A tagok általában belső felhasználók, a vendégek pedig külső (B2B) felhasználók. A felhasználói típus tárolása akkor hasznos, ha elemeznie kell a külső felhasználók tevékenységeit.
  • Szerepkörváltozások: Ha biztonsági auditot végez, érdemes tisztában lenni azzal, hogy egy felhasználó mikor változtatta meg a szerepköröket a szervezetben (például amikor egy másik részlegre továbbítja őket). Így ellenőrizheti, hogy frissítették-e a Power BI biztonsági beállításait.
  • Letiltott felhasználók: Amikor egy felhasználó elhagyja a szervezetet, a rendszergazda általában letiltja a fiókját. Létrehozhat egy folyamatot annak ellenőrzésére, hogy a letiltott felhasználók munkaterület-rendszergazdák vagy szemantikai modellek tulajdonosai-e.

Tipp.

A Power BI tevékenységnaplója tartalmaz egy eseményt, amely rögzíti, ha egy felhasználó regisztrál egy próbalicencet. Ezt az eseményt kombinálhatja a felhasználói licenc adataival (a Microsoft Entra ID-ból származtatva), hogy teljes képet készítsen.

Felhasználók és csoportok adatainak lekérése

A felhasználókra és csoportokra vonatkozó adatokat többféleképpen is lekérheti.

Technika Leírás Jó választás manuális naplózási folyamatokhoz Jó választás automatizált naplózási folyamatokhoz
Manuális Graph Explorer A Graph Explorer jó választás manuális naplózási folyamatokhoz.
Szoftveres Microsoft Graph API-k és SDK-k A Microsoft Graph API-k és SDK-k jó választásnak számítanak az automatizált naplózási folyamatokhoz.
Szoftveres Az PowerShell-modul Az Az PowerShell-modul jó választás az automatizált naplózási folyamatokhoz.

A szakasz további részében a táblázatban bemutatott technikákat mutatjuk be. A jelen szakasz végén további, elavult és új megoldásokhoz nem használható technikákat ismertetünk.

Feljegyzés

Ügyeljen arra, hogy online olvasson információkat, mert sok eszköznév hasonló. A Microsoft ökoszisztémájának egyes eszközei közé tartozik a Graph kifejezés a nevükben, például az Azure Resource Graph, a GraphQL és a Microsoft Security Graph API. Ezek az eszközök nem kapcsolódnak a Microsoft Graphhoz, és nem tartoznak a jelen cikk hatókörébe.

Microsoft Graph Explorer

A Microsoft Graph Explorer egy fejlesztői eszköz, amellyel megismerkedhet a Microsoft Graph API-kkal. Ez egy egyszerű módszer az első lépésekhez, mert nincs szükség más eszközökre vagy beállításokra a gépen. Bejelentkezhet, ha adatokat szeretne lekérni a bérlőről, vagy mintaadatokat szeretne lekérni egy alapértelmezett bérlőből.

A Graph Explorerrel a következőket végezheti el:

  • Manuálisan küldjön kérést egy Microsoft Graph API-nak, hogy ellenőrizze, hogy a kérés visszaadja-e a kívánt információkat.
  • Megtudhatja, hogyan hozhatja létre az URL-címet, a fejléceket és a törzset a szkript írása előtt.
  • Ellenőrizze az adatokat informális módon.
  • Határozza meg, hogy mely engedélyek szükségesek az egyes API-khoz. Új engedélyekhez is adhat hozzájárulást .
  • Szerezze be a szkriptek létrehozásakor használandó kódrészleteket.

Ezen a hivatkozáson megnyithatja a Graph Explorert.

Microsoft Graph API-k és SDK-k

A Microsoft Graph API-k segítségével lekérheti a felhasználók és a csoportok adatait. Segítségével adatokat is lekérhet olyan szolgáltatásokból, mint a Microsoft Entra ID, a SharePoint Online, a Teams, az Exchange, az Outlook stb.

A Microsoft Graph SDK-k API-burkolóként működnek a mögöttes Microsoft Graph API-k fölé. Az SDK egy szoftverfejlesztői készlet , amely eszközöket és funkciókat köt össze. A Microsoft Graph SDK-k a Microsoft Graph API-k teljes készletét teszik elérhetővé.

Dönthet úgy, hogy közvetlenül az API-knak küld kéréseket. Másik lehetőségként hozzáadhat egy egyszerűsítési réteget az előnyben részesített nyelv és az egyik SDK használatával. További információ: Api-k vagy PowerShell-parancsmagok kiválasztása a cikk korábbi részében.

A Microsoft Graph SDK-k számos nyelvet támogatnak, és a Microsoft Graph PowerShell-modulok is megtalálhatók. Más SDK-k python, C# és egyéb nyelvekhez is elérhetők.

Fontos

A Microsoft Graph PowerShell-modul felváltja az Azure AD PowerShell-modulokat és az MSOnline (MSOL) modulokat, amelyek mindkettő elavultak. Ne hozzon létre új megoldásokat elavult modulokkal. A Microsoft Graph PowerShell-modul számos funkcióval és előnnyel rendelkezik. További információ: Frissítés az Azure AD PowerShellről a Microsoft Graph PowerShellre.

A Microsoft Graph PowerShell-modulokat a PowerShell-galéria telepítheti. Mivel a Microsoft Graph számos Microsoft 365-szolgáltatással működik, számos PowerShell-modult telepít.

A Power BI bérlői szintű naplózásához az alábbi leggyakoribb PowerShell-modulokat kell telepítenie.

Tipp.

A Microsoft rendszeresen frissíti a Microsoft Graph PowerShell-modulokat. Előfordulhat, hogy az előzetes verziójú modulok kiadás előtti vagy bétavégponton érhetők el. A modulok telepítésekor és frissítésekor érdemes lehet megadnia a kívánt verziót. Ha áttekinti az online dokumentációt, vegye figyelembe, hogy az aktuális verziószám automatikusan hozzá van fűzve az URL-cím végéhez (ezért legyen óvatos az URL-címek mentésekor vagy megosztásakor).

Az PowerShell-modul

Az Az PowerShell-modullal felhasználókat és csoportadatokat is lekérhet. Az Azure-erőforrásokra összpontosít.

Fontos

Az Az PowerShell-modul lecseréli az elavult AzureRM PowerShell-modulokat. Ne hozzon létre új megoldásokat elavult modulokkal.

Az Invoke-AzRestMethod parancsmagot akkor használhatja, ha nincs megfelelő parancsmag egy API-hoz. Ez egy rugalmas megközelítés, amellyel bármilyen Microsoft Graph API-ra küldhet kérést az Az PowerShell-modul használatával.

Az Az 7-es verziójától kezdve az Az parancsmagok mostantól a Microsoft Graph API-ra hivatkoznak. Ezért az Az modul API-burkolóként működik a Microsoft Graph tetején. Az Az modulok a Microsoft Graph API-kban és a PowerShell-modulokban található funkciók egy részhalmazával rendelkeznek. Új megoldások esetén a Microsoft Graph PowerShell SDK használatát javasoljuk.

Elavult API-k és modulok

Az interneten olyan cikkeket és blogbejegyzéseket találhat, amelyek alternatív lehetőségeket javasolnak, amelyek ebben a szakaszban nem jelennek meg. Határozottan javasoljuk, hogy ne hozzon létre új megoldásokat (és/vagy migrálja a meglévő megoldásait) az alábbi API-k vagy modulok egyikével sem.

  • AzureRM PowerShell-modulok: Elavult, és ki lesznek állítva. Ezeket felváltotta az Az PowerShell-modul.
  • Azure AD Graph API és Azure AD PowerShell-modul: Elavult, és ki lesz állítva. Ez a változás az Azure AD Graph-ról a Microsoft Graphra való migrálás eredménye (vegye figyelembe, hogy a Graph mindkét névben megjelenik, de a Microsoft Graph a jövőbeli irány). Minden jövőbeli PowerShell-befektetés a Microsoft Graph PowerShell SDK-ban történik. (A Microsoft Entra-azonosítót mostantól Microsoft Entra-azonosítónak is nevezik.)
  • MS Online (MSOL) PowerShell-modul: Elavult, és megszűnik. Minden jövőbeli PowerShell-befektetés a Microsoft Graph PowerShell SDK-ban történik.

Figyelemfelhívás

Győződjön meg arról, hogy a jelenleg használt elavult API-k vagy modulok állapota nem áll le. Az AzureRM kivonásával kapcsolatos további információkért tekintse meg ezt a bejelentést.

A Microsoft Entra ID-ról és az MSOL-ról további információt ebben a nyugdíjazási közleményben talál.

Ha kérdése van, vagy tisztázni szeretné a programozott adatokhoz való hozzáférés jövőbeli irányát, forduljon a Microsoft-fiók csapatához.

Ellenőrzőlista – A felhasználók és csoportok adatainak elérésekor a legfontosabb döntések és műveletek a következők:

  • Követelmények megerősítése: A felhasználókkal, csoportokkal és licencekkel kapcsolatos adatok összeállításának igényeinek tisztázása.
  • Követelmények rangsorolása: Ellenőrizze a legfontosabb prioritásokat, hogy tudja, mire érdemes időt fordítania.
  • Döntse el az adatok kinyerésének gyakoriságát: Határozza meg, milyen gyakran lesz szüksége új pillanatképre a felhasználókról és a csoportok adatairól (például hetente vagy havonta).
  • Döntse el, hogyan nyerhet ki adatokat a Microsoft Graph használatával: Határozza meg, hogy melyik módszert fogja használni az adatok lekéréséhez.
  • A koncepció igazolásának befejezése: Tervezze meg egy kis technikai koncepcióigazolás (POC) elvégzését a felhasználók és a csoportok adatainak kinyeréséhez. Ezzel ellenőrizheti a végső megoldás létrehozásának módjával kapcsolatos döntéseket.

Adatok elérése Power BI REST API-kból

Alacsonyabb prioritásként más adatokat is lekérhet a Power BI REST API-kkal.

A következő adatok például lekérhetők:

Biztonsági audit során érdemes lehet azonosítani a következőt:

Az API-k egyéb típusairól a jelen cikk korábbi, felhasználói API-k vagy rendszergazdai API-k kiválasztása című témakörben olvashat bővebben.

Ellenőrzőlista – A Power BI API-kból való adatok elérésének tervezésekor a legfontosabb döntések és műveletek a következők:

  • Követelmények beszerzése: A felmerülő elemzési követelmények fordítása. Nyomon követheti őket a hátralékban.
  • Követelmények rangsorolása: Határozza meg a felmerülő új követelmények prioritásait.

2. fázis: Előfeltételek és beállítás

A bérlőszintű naplózási megoldás tervezésének és implementálásának második fázisa az előfeltételekre és a beállításra összpontosít, amelyeket a megoldásfejlesztés megkezdése előtt el kell végezni.

A 2. fázist leíró folyamatábra, amely a bérlőszintű naplózási megoldás létrehozásának előfeltételeire és beállítására összpontosít.

Storage-fiók létrehozása

Ezen a ponton úgy döntött, hogy helyet ad a nyers adatok tárolásának és a válogatott adatok létrehozásának. Ezen döntések alapján most már készen áll egy tárfiók létrehozására. A szervezet folyamatától függően előfordulhat, hogy kérést küld az informatikai szervezetnek.

A korábban ismertetett módon javasoljuk, hogy használjon olyan technológiát, amely lehetővé teszi a nyers adatok nem módosítható tárolóba való írását. Miután megírta az adatokat, azokat nem lehet módosítani vagy törölni. Ezután megbízhat a nyers adatokban, mert tudja, hogy egy hozzáféréssel rendelkező rendszergazda semmilyen módon nem módosíthatja azokat. A válogatott adatokat azonban nem (általában) nem módosítható tárolóban kell tárolni. Előfordulhat, hogy a válogatott adatok megváltoznak, vagy újragenerálhatók.

Ellenőrzőlista – Tárfiók létrehozásakor a legfontosabb döntések és műveletek a következők:

  • Tárfiók létrehozása: Tárfiók létrehozására szolgáló kérés létrehozása vagy elküldése. Ha lehetséges, használjon nem módosítható tárolási beállításokat a nyers adatokhoz.
  • Engedélyek beállítása: Határozza meg, hogy mely engedélyek legyenek beállítva a tárfiókhoz.
  • Hozzáférés tesztelése: Kis teszteléssel biztosíthatja a tárfiókba való olvasást és írást.
  • A felelősség megerősítése: Győződjön meg arról, hogy nem tudja, hogy ki fogja folyamatosan kezelni a tárfiókot.

Szoftverek telepítése és szolgáltatások beállítása

Ezen a ponton döntéseket hozott arról, hogy melyik technológiát használja a naplózási adatokhoz való hozzáféréshez. Ezen döntések alapján most már készen áll a szoftverek telepítésére és a szolgáltatások beállítására.

Állítsa be az előnyben részesített fejlesztési környezetet minden rendszergazda számára. A fejlesztői környezet lehetővé teszi a szkriptek írását és tesztelését. A Visual Studio Code egy modern eszköz szkriptek fejlesztéséhez, ezért jó választás. Emellett számos bővítmény érhető el a Visual Studio Code használatához.

Ha a PowerShell használatára vonatkozó (korábban ismertetett) döntést hozta, telepítse a PowerShell Core-t és a szükséges PowerShell-modulokat a következőre:

  • Minden olyan rendszergazda/fejlesztő gépe, aki naplószkripteket ír vagy tesztel.
  • Minden olyan virtuális gép vagy kiszolgáló, amely ütemezett szkripteket fog futtatni.
  • Minden online szolgáltatás (például az Azure Functions vagy az Azure Automation).

Ha az Azure-szolgáltatások (például az Azure Functions, az Azure Automation, az Azure Data Factory vagy az Azure Synapse Analytics) használatát választotta, akkor ezeket is ki kell építenie és be kell állítania.

Ellenőrzőlista – A szoftverek telepítésekor és a szolgáltatások beállításakor a legfontosabb döntések és műveletek a következők:

  • Rendszergazdai/fejlesztői gépek beállítása: Szükség esetén telepítse a fejlesztéshez szükséges eszközöket.
  • Kiszolgálók beállítása: Szükség esetén telepítse a szükséges eszközöket az architektúrában található kiszolgálókra vagy virtuális gépekre.
  • Azure-szolgáltatások beállítása: Szükség esetén minden Egyes Azure-szolgáltatás kiépítése és beállítása. Engedélyek hozzárendelése minden olyan rendszergazda/fejlesztő számára, aki fejlesztési munkát végez.

Microsoft Entra-alkalmazás regisztrálása

Ezen a ponton eldöntötte , hogyan kell hitelesíteni. Javasoljuk, hogy regisztráljon egy Microsoft Entra-alkalmazást (szolgáltatásnév). A gyakran alkalmazásregisztrációnak nevezett alkalmazást felügyelet nélküli műveletekhez kell használni, amelyeket automatizálni fog.

További információ arról, hogyan hozhat létre alkalmazásregisztrációt bérlőszintű naplózási adatok lekéréséhez: Egyszerű szolgáltatáshitelesítés engedélyezése írásvédett rendszergazdai API-khoz.

Ellenőrzőlista – A Microsoft Entra-alkalmazások regisztrálásakor a legfontosabb döntések és műveletek a következők:

  • Ellenőrizze, hogy létezik-e meglévő alkalmazásregisztráció: Ellenőrizze, hogy elérhető-e egy meglévő alkalmazásregisztráció rendszergazdai API-k futtatásához. Ha igen, határozza meg, hogy a meglévőt kell-e használni, vagy létre kell-e hozni egy újat.
  • Új alkalmazásregisztráció létrehozása: Szükség esetén alkalmazásregisztráció létrehozása. Érdemes lehet olyan alkalmazásnevet használni, mint a PowerBI-Rendszergazda APIs-EntraApp, amely egyértelműen leírja a célját.
  • Titkos kód létrehozása az alkalmazásregisztrációhoz: Ha az alkalmazásregisztráció már létezik, hozzon létre egy titkos kulcsot. Állítsa be a lejárati dátumot a titkos kód elforgatásának gyakorisága alapján.
  • Mentse biztonságosan az értékeket: Tárolja a titkos kulcsot, az alkalmazásazonosítót (ügyfél-azonosítót) és a bérlőazonosítót, mert szüksége lesz rájuk a szolgáltatásnévvel való hitelesítéshez. Használjon biztonságos helyet, például egy szervezeti jelszótárolót. (Ha alkalmazásregisztráció létrehozását kell kérnie az informatikai cégtől, adja meg, hogy szüksége van-e ezekre az értékekre.)
  • Biztonsági csoport létrehozása: Hozzon létre (vagy kérjen) egy biztonsági csoportot, amelyet a Power BI-hoz fog használni. Fontolja meg a csoportnév, például a Power BI rendszergazdai szolgáltatásnevek használatát, ami azt jelzi, hogy a csoport a bérlőszintű metaadatok eléréséhez lesz használva.
  • Adja hozzá a szolgáltatásnevet a biztonsági csoport tagjaként: Az alkalmazásazonosító (ügyfélazonosító) használatával adja hozzá az új (vagy meglévő) szolgáltatásnevet az új biztonsági csoport tagjaként.
  • Rendszergazdai API-bérlői beállítás frissítése a Power BI-ban: A Power BI felügyeleti portálján adja hozzá a biztonsági csoportot a csak olvasható Power BI rendszergazdai API-k bérlői beállításának engedélyezése szolgáltatásnevek számára.
  • Engedélyek hozzárendelésének kihagyása az Azure-ban: Ne delegáljon engedélyeket az alkalmazásregisztrációhoz (a Power BI-bérlőszintű naplózási adatokhoz a Power BI lehetővé teszi, hogy a szolgáltatásnevek írásvédett Power BI-rendszergazdai API-k bérlőbeállításait használják ).
  • Döntse el, hogy az alkalmazásregisztrációnak hozzá kell-e férnie a részletes metaadatokhoz: Határozza meg, hogy szeretne-e részletes információkat kinyerni a szemantikai modelltáblákról, oszlopokról és mértékkifejezésekről a bérlői leltár létrehozásakor.
  • Frissítse a metaadat-bérlő részletes beállításait a Power BI-ban: A Power BI felügyeleti portálján szükség esetén adja hozzá a biztonsági csoportot a Rendszergazdai API-válaszok továbbfejlesztéséhez részletes metaadat-bérlői beállítással, valamint a rendszergazdai API-válaszok továbbfejlesztése DAX és mashup kifejezések bérlőbeállításával.
  • A szolgáltatásnév tesztelése: Hozzon létre egy egyszerű szkriptet a bejelentkezéshez a szolgáltatásnév használatával, és ellenőrizze, hogy képes-e adatokat lekérni egy rendszergazdai API-ból.
  • Alkalmazásregisztrációs titkos kódok kezelésére szolgáló folyamat létrehozása: Dokumentáció és a titkos kódok rendszeres rotálására szolgáló folyamat létrehozása. Határozza meg, hogyan fogja biztonságosan továbbítani az új titkos kulcsokat azoknak a rendszergazdáknak és fejlesztőknek, akiknek szükségük van rá.

A Power BI-bérlő beállításainak megadása

A Power BI felügyeleti portálján számos bérlői beállítás található, amelyek relevánsak a bérlőszintű naplózási adatok kinyerése szempontjából.

Rendszergazda API-k

A rendszergazdai API-k futtatásához három bérlői beállítás szükséges.

Fontos

Mivel ezek a beállítások metaadat-hozzáférést biztosítanak a teljes bérlő számára (közvetlen Power BI-engedélyek hozzárendelése nélkül), szigorúan szabályoznia kell őket.

A csak olvasható Power BI rendszergazdai API-k bérlői beállításának engedélyezése szolgáltatásnevek számára lehetővé teszi, hogy megszűnjön, hogy mely szolgáltatásnevek hívhatnak rendszergazdai API-kat. Ez a beállítás lehetővé teszi a Microsoft Purview számára a teljes Power BI-bérlő vizsgálatát, hogy feltölthesse az adatkatalógust.

Feljegyzés

Nem kell explicit módon hozzárendelnie más Power BI-rendszergazdákat a csak olvasható Power BI rendszergazdai API-k bérlői beállításának engedélyezéséhez a szolgáltatásnevek számára, mert már rendelkeznek hozzáféréssel a bérlői szintű metaadatokhoz.

A rendszergazdai API-válaszok részletes metaadat-bérlői beállításával megadhatja, hogy mely felhasználók és szolgáltatásnevek tudják lekérni a részletes metaadatokat. A metaadatok lekérése a metaadat-ellenőrzési API-k használatával történik, és táblákat, oszlopokat és egyebeket is tartalmaz. Ez a beállítás lehetővé teszi a Microsoft Purview számára a Power BI szemantikai modellekkel kapcsolatos sémaszintű információk elérését is, hogy azokat az adatkatalógusban tárolhassa.

A Rendszergazdai API-válaszok továbbfejlesztése DAX- és egyesítőkifejezések bérlői beállításával beállíthatja, hogy mely felhasználók és szolgáltatásnevek tudják lekérni a részletes metaadatokat. A metaadatok lekérése a metaadat-ellenőrzési API-kból történik, és lekérdezéseket és szemantikai modell mértékkifejezéseket is tartalmazhat.

Feljegyzés

A szolgáltatásnevek írásvédett Power BI rendszergazdai API-k bérlői beállításának engedélyezése kifejezetten a rendszergazdai API-k eléréséről szól. A neve nagyon hasonlít a felhasználói API-k elérésére szolgáló bérlői beállításhoz (a következő leírásban). A rendszergazdai API-k és a felhasználói API-k közötti különbségről a jelen cikk korábbi, felhasználói API-k vagy rendszergazdai API-k kiválasztása című témakörben talál további információt.

Felhasználói API-k

A felhasználói API-k meghívására egyetlen bérlői beállítás vonatkozik. Ebben az esetben a szolgáltatásnévhez (például egy munkaterületi szerepkörhöz) Power BI-engedélyekre is szükség van.

A Power BI API-k bérlői beállításának engedélyezése szolgáltatásnevek számára lehetővé teszi, hogy megszűrje, mely szolgáltatásnevek rendelkeznek hozzáféréssel a REST API-k futtatásához (kivéve a rendszergazdai API-kat, amelyeket egy másik bérlői beállítás biztosít, a fent leírtak szerint).

Az API-khoz más bérlői beállítások is tartoznak, amelyek lehetővé teszik a beágyazási API-khoz, a streamelési API-khoz, az exportálási API-khoz és a lekérdezési API-k végrehajtásához való hozzáférést. Ezek az API-k azonban nem tartoznak a jelen cikk hatókörébe.

A használati metrikák bérlői beállításaival kapcsolatos további információkért lásd a jelentésszintű naplózást.

Ellenőrzőlista – A Power BI-bérlő beállításainak beállításakor a legfontosabb döntések és műveletek a következők:

  • Ellenőrizze, hogy az egyes szolgáltatásnevek a megfelelő csoportban találhatók-e: Győződjön meg arról, hogy a Power BI rendszergazdai szolgáltatásnevek csoportja tartalmazza a megfelelő szolgáltatásneveket.
  • Frissítse a rendszergazdai API-bérlői beállítást a Power BI-ban: Adja hozzá a biztonsági csoportot a Szolgáltatásnevek számára írásvédett Power BI rendszergazdai API-bérlői beállítás használatához, amely lehetővé teszi a rendszergazdai API-k használatát a bérlőszintű metaadatok lekéréséhez.
  • Frissítse a metaadat-bérlő részletes beállításait a Power BI-ban: Ha szükséges, adja hozzá a biztonsági csoportot a Rendszergazdai API-válaszok továbbfejlesztéséhez részletes metaadat-bérlői beállítással, valamint a rendszergazdai API-válaszok továbbfejlesztése DAX- és összefésülési kifejezések bérlőbeállításával.
  • Ellenőrizze, hogy mely felhasználói API-k lesznek elérhetők: Ellenőrizze, hogy szükség lesz-e egy vagy több felhasználói API-ra (a rendszergazdai API-k használata mellett).
  • Frissítse a felhasználói API-bérlői beállítást a Power BI-ban: Adja hozzá a biztonsági csoportot a szolgáltatásnevek számára a Power BI API-k bérlői beállításának használatához, amely a felhasználói API-k számára készült.

3. fázis: Megoldásfejlesztés és elemzés

A bérlőszintű naplózási megoldás tervezésének és implementálásának harmadik fázisa a megoldásfejlesztésre és az elemzésre összpontosít. Ezen a ponton minden tervezés és döntéshozatal megtörtént, és megfelelt az előfeltételeknek, és elvégezte a beállítást. Most már készen áll a megoldásfejlesztés megkezdésére, hogy elemzéseket végezhessenek, és elemzéseket nyerhessenek a naplózási adatokból.

A 3. fázist leíró folyamatábra, amely egy bérlőszintű naplózási megoldás megoldásfejlesztésére és elemzésére összpontosít.

A nyers adatok kinyerése és tárolása

Ezen a ponton a követelményeknek és a prioritásoknak egyértelműnek kell lenniük. A legfontosabb technikai döntések a naplózási adatok eléréséről és a naplózási adatok tárolásának helyéről szólnak. A rendszer kiválasztotta az előnyben részesített eszközöket, és beállította az előfeltételeket és a beállításokat. Az előző két fázisban egy vagy több kisebb projektet (megvalósíthatósági igazolást) is végrehajtott a megvalósíthatóság igazolásához. A következő lépés a nyers naplózási adatok kinyerésére és tárolására vonatkozó folyamat beállítása.

A legtöbb Microsoft API által visszaadott adatokhoz hasonlóan a naplózási adatok is JSON formátumban vannak formázva. A JSON-formátumú adatok önleírók, mert azok emberi olvasásra alkalmas szövegek, amelyek struktúrát és adatokat tartalmaznak.

A JSON attribútum-érték párokból és tömbökből álló adatobjektumokat jelöl. Például egy példa, "state": "Active" ahol az állapotattribútum értéke Aktív. A JSON-tömbök vesszővel elválasztott elemek rendezett listáját tartalmazzák, amelyek szögletes zárójelek ([ ]) közé vannak zárva. Gyakori, hogy beágyazott tömbök találhatók a JSON-eredményekben. Miután megismerkedett egy JSON-eredmény hierarchikus szerkezetével, egyszerűen megértheti az adatstruktúrát, például a munkaterület szemantikai modelljeinek listáját (tömbjét).

Íme néhány szempont az API-kból lekért nyers adatok kinyerése és tárolása során.

  • Milyen elnevezési konvenciót használunk? Fájlalapú rendszerek esetében a fájlok, mappák és data lake zónák elnevezésére van szükség. Az adatbázisok esetében elnevezési konvenciók szükségesek a táblákhoz és oszlopokhoz.
  • Milyen formátumot használ a rendszer a nyers adatok tárolására? Mivel a Power BI továbbra is új funkciókat vezet be, új tevékenységek jelennek meg, amelyek ma nem léteznek. Ezért azt javasoljuk, hogy bontsa ki és őrizze meg az eredeti JSON-eredményeket. A kinyerés során ne elemezje, ne szűrje és formázza az adatokat. Így az eredeti nyers adatokkal újragenerálhatja a válogatott naplózási adatokat.
  • Milyen tárolási helyet használ? A data lake- vagy blobtárolók általában nyers adatok tárolására szolgálnak. További információ: A cikk korábbi részében szereplő naplózási adatok tárolási helye.
  • Mennyi előzményt tárol? Exportálja a naplózási adatokat egy olyan helyre, ahol tárolhatja az előzményeket. Tervezze meg, hogy legalább két évnyi előzményt halmoz fel. Így elemezheti az alapértelmezett 30 napos megőrzési időszakon túli trendeket és változásokat. Dönthet úgy, hogy határozatlan ideig tárolja az adatokat, vagy a szervezet adatmegőrzési szabályzataitól függően rövidebb időszak mellett dönt.
  • Hogyan fogja nyomon követni, hogy a folyamat mikor futott utoljára? Konfiguráljon egy konfigurációs fájlt vagy annak megfelelőt az időbélyegek rögzítéséhez, amikor egy folyamat elindul és befejeződik. A folyamat következő futtatásakor lekérheti ezeket az időbélyegeket. Különösen fontos, hogy időbélyegeket tároljunk, amikor adatokat nyerünk ki a metaadat-ellenőrző API-k használatával.
  • Hogyan fogja kezelni a szabályozást? Néhány Power BI REST API és a Microsoft Graph API szabályozást implementál. Az API-kérés szabályozása esetén 429-es hiba (túl sok kérés) jelenik meg. A szabályozás gyakori problémát jelenthet a nagyobb szervezetek számára, amelyeknek nagy mennyiségű adatot kell lekérni. A szabályozás miatt meghiúsult kísérletek elkerülése az adatok eléréséhez és kinyeréséhez használt technológiától függ. Az egyik lehetőség az, hogy olyan logikát fejleszt a szkriptekben, amelyek a várakozási idő után újrapróbálkozva válaszolnak a 429-re vonatkozó "Túl sok kérés" hibára.
  • Szükség van a naplózási adatokra a megfelelőséghez? Számos szervezet a nyers naplózási naplórekordokat használja megfelelőségi auditok elvégzésére vagy biztonsági vizsgálatokra való válaszadásra. Ezekben az esetekben erősen javasoljuk, hogy a nyers adatokat nem módosítható tárolóban tárolja. Így az adatok megírása után a rendszergazda vagy más felhasználó nem módosíthatja vagy törölheti őket.
  • Milyen tárolási rétegek szükségesek a követelmények teljesítéséhez? A nyers adatok tárolásának legjobb helye a data lake (például az Azure Data Lake Storage Gen2) vagy az objektumtároló (például az Azure Blob Storage). Fájlrendszer is használható, ha a felhőszolgáltatások nem választhatók.

Ellenőrzőlista – A nyers adatok kinyerésekor és tárolásakor a legfontosabb döntések és műveletek a következők:

  • Követelmények és prioritások megerősítése: Tisztázza az elsőként kinyerni kívánt adatokra vonatkozó követelményeket és prioritásokat.
  • Ellenőrizze a kinyerni kívánt adatok forrását: Ellenőrizze az egyes adattípusok forrását.
  • Állítson be egy folyamatot az adatok kinyerésére és a nyers adatzónába való betöltésére: Hozza létre a kezdeti folyamatot a nyers adatok eredeti állapotában való kinyeréséhez és betöltéséhez, átalakítások nélkül. Ellenőrizze, hogy a folyamat a kívánt módon működik-e.
  • Ütemezés létrehozása a folyamatok futtatásához: Állítson be egy ismétlődő ütemezést a kinyerési, betöltési és átalakítási folyamatok futtatásához.
  • Ellenőrizze, hogy a hitelesítő adatok biztonságosan vannak-e kezelve: Győződjön meg arról, hogy a jelszavak, titkos kódok és kulcsok biztonságos módon vannak tárolva és kommunikálva.
  • Ellenőrizze, hogy a biztonság megfelelően van-e beállítva: Ellenőrizze, hogy a hozzáférési engedélyek megfelelően vannak-e beállítva a nyers adatokhoz. Győződjön meg arról, hogy a rendszergazdák és az auditorok hozzáférhetnek a nyers adatokhoz.

A naplózási és monitorozási megoldások időbeli növekedésével kapcsolatos további információkért lásd a cikk későbbi részében az üzembe helyezést és a fejlesztést .

A válogatott adatok létrehozása

Ezen a ponton a rendszer kinyeri és tárolja a nyers adatokat. A következő lépés egy külön arany adatréteg létrehozása a válogatott adatokhoz. Célja az adatfájlok átalakítása és tárolása csillagsémában. A csillagséma dimenziótáblákból és ténytáblákból áll, és szándékosan elemzésre és jelentéskészítésre van optimalizálva. A válogatott adatréteg fájljai egy Power BI-adatmodell forrásává válnak (ezt a következő témakörben ismertetjük).

Tipp.

Ha egynél több adatmodellre számít, különösen hasznos a központosított adatrétegbe való befektetés.

Ellenőrzőlista – A válogatott adatréteg létrehozásakor a legfontosabb döntések és műveletek a következők:

  • Erősítse meg a követelményeket és a prioritásokat: Ha egy közvetítő ezüstréteget kíván használni az átalakított adatokhoz, tisztázza azokat a követelményeket és célkitűzéseket, amelyeket el kell végeznie.
  • Állítson be egy folyamatot a nyers adatok átalakításához és a válogatott adatzónába való betöltéséhez: Hozzon létre egy folyamatot az adatok csillagséma átalakításához és betöltéséhez. Ellenőrizze, hogy a folyamat a kívánt módon működik-e.
  • Ütemezés létrehozása a folyamatok futtatásához: Állítson be egy ismétlődő ütemezést a válogatott adatréteg feltöltéséhez.
  • Ellenőrizze, hogy a biztonság megfelelően van-e beállítva: Ellenőrizze, hogy a hozzáférési engedélyek megfelelően vannak-e beállítva a válogatott adatokhoz. Győződjön meg arról, hogy az adatmodell fejlesztői hozzáférhetnek a válogatott adatokhoz.

Adatmodell létrehozása

A témakör egy elemzési adatmodell beállításáról szól. Az adatmodell az elemzéshez optimalizált lekérdezési képes adaterőforrás. Néha szemantikai modellnek vagy egyszerűen modellnek is nevezik. A naplózási és monitorozási megoldás esetében az adatmodell valószínűleg Power BI szemantikai modellként lesz implementálva.

A naplózás és a monitorozás kontextusában az adatforrások a válogatott (arany) adatrétegből származó adatokat származtatják. Ha úgy dönt, hogy nem hoz létre válogatott adatréteget, az adatforrás közvetlenül a nyers adatokból származtatja az adatokat.

Javasoljuk, hogy a Power BI-adatmodell csillagséma-kialakítást implementáljon. Ha a forrásadatok a válogatott adatréteg, a Power BI adatmodell csillagsémának tükröznie kell a válogatott adatréteg csillagsémát.

Tipp.

A csillagséma kialakításának áttekintését a csillagséma ismertetése és a Power BI fontossága című témakörben tekintheti meg.

Mint minden Power BI-projekt esetében, az adatmodellek létrehozása is iteratív folyamat. Szükség szerint új mértékeket is hozzáadhat. Új táblákat és oszlopokat is hozzáadhat az új naplózási események elérhetővé válásakor. Idővel akár új adatforrásokat is integrálhat.

Íme néhány hasznos dimenziótábla, amelyeket belefoglalhat az adatmodellbe.

  • Dátum: Dátumattribútumok készlete, amelyek lehetővé teszik az adatok nap, hét, hónap, negyedév, év és egyéb releváns időszakok szerinti elemzését (szeletelését és szeletelését).
  • Idő: Ha napközbeni elemzésre van szüksége, és nagyon nagy mennyiségű naplózási adattal rendelkezik, fontolja meg az időrész tárolását a dátumtól elkülönítve. Ez a megközelítés segíthet a lekérdezési teljesítmény javításában.
  • Felhasználók: A felhasználókat leíró attribútumok (például részleg és földrajzi régió), amelyek az adatok naplózásának számos témáját szűrhetik. A cél az, hogy eltávolítsa az összes felhasználói adatot a ténytáblákból, és ebben a dimenziótáblában tárolja őket, hogy számos ténytáblát szűrhessenek. A szolgáltatásnevek ebben a táblában is tárolhatók.
  • Tevékenységesemények: A tevékenységeseményeket (műveleteket) csoportosító és leíró attribútumok. A jelentéskészítés javítása érdekében létrehozhat egy adatszótárat, amely leírja az egyes tevékenységeseményeket. Létrehozhat egy hierarchiát is, amely csoportosítja és osztályozza a hasonló tevékenységeseményeket. Csoportosíthatja például az összes elemlétrehozási eseményt, törölheti az eseményeket stb.
  • Munkaterületek: A bérlői és munkaterület-tulajdonságok munkaterületeinek listája, például típus (személyes vagy standard) és leírás. Egyes szervezetek további részleteket rögzítenek a munkaterületekről (esetleg SharePoint-lista használatával). Ezeket a részleteket integrálhatja ebbe a dimenziótáblába. El kell döntenie, hogy ez a dimenziótábla csak a munkaterület aktuális állapotát tárolja-e, vagy olyan verziójú adatokat tárol, amelyek jelentős munkaterület-változásokat tükröznek. Ha például egy munkaterület neve megváltozik, az előzményjelentések az aktuális munkaterület nevét vagy az akkor aktuális munkaterületnevet jelenítik meg? További információ a verziószámozásról: Lassan változó dimenziók.
  • Elemtípusok: A Power BI-elemtípusok listája (szemantikai modellek, jelentések és egyebek).
  • Kapacitások: A bérlő prémium szintű kapacitásainak listája.
  • Átjárók: A bérlő adatátjáróinak listája.
  • Adatforrások: Bármely szemantikai modell, adatfolyam vagy adatmart által használt adatforrások listája.

Íme néhány hasznos ténytábla (tárgy), amelyeket belefoglalhat az adatmodellbe.

  • Felhasználói tevékenységek: Az eredeti JSON-adatokból származó tényadatok. A rendszer eltávolít minden olyan attribútumot, amely nem rendelkezik elemzési értékkel. A dimenziótáblákban (fent) szereplő attribútumok is törlődnek.
  • Bérlői leltár: Időponthoz kötött pillanatkép a bérlőben közzétett összes elemről. További információ: Bérlői leltár a cikk korábbi részében.
  • Szemantikai modellek: Szemantikai modelleket (például szemantikai modellek változásait) vagy kapcsolódó adatforrásokat érintő felhasználói tevékenységeket tartalmaz.
  • Szemantikai modellfrissítések: Adatfrissítési műveleteket tárol, beleértve a típusra (ütemezett vagy igény szerinti), időtartamra, állapotra és a műveletet kezdeményező felhasználóra vonatkozó adatokat.
  • Munkaterületi szerepkörök: A munkaterületi szerepkör-hozzárendelések időponthoz kötött pillanatképe.
  • Felhasználói licencek: A felhasználói licencek időponthoz kötött pillanatképe. Bár előfordulhat, hogy a felhasználói licencet a Felhasználók dimenziótáblában szeretné tárolni, ez a megközelítés nem támogatja a licencváltozások és trendek időbeli elemzését.
  • Felhasználói csoporttagságok: A biztonsági csoporthoz rendelt felhasználók (és szolgáltatásnevek) időponthoz kötött pillanatképe.
  • Közösségi tevékenységek: Közösségi jellegű tényeket, például képzési eseményeket tartalmaz. Elemezheti például a Power BI felhasználói tevékenységeit a betanítási részvételhez képest. Ezek az adatok segíthetnek a Kiválósági Központnak azonosítani a potenciális új bajnokokat.

A ténytáblák nem tartalmazhatnak olyan oszlopokat, amelyeket a jelentéskészítők szűrni fognak. Ehelyett ezek az oszlopok kapcsolódó dimenziótáblákhoz tartoznak. Ez a kialakítás nem csak a lekérdezések esetében hatékonyabb, hanem a dimenziótáblák több tény (más néven részletezés) általi újrafelhasználását is elősegíti. Ez az utolsó pont fontos egy hasznos és felhasználóbarát adatmodell létrehozásához, amely bővíthető új ténytáblák (témák) hozzáadásakor.

A Felhasználók dimenziótábla például minden ténytáblához kapcsolódik. Ennek a Felhasználói tevékenységek ténytáblához (a tevékenységet végrehajtóhoz), a bérlői leltár ténytáblához (a közzétett tétel létrehozója) és az összes többi ténytáblához kell kapcsolódnia. Ha egy jelentés egy felhasználó által szűr a Felhasználók dimenziótáblában, a jelentés vizualizációi bármilyen kapcsolódó ténytáblából megjeleníthetik az adott felhasználó tényeit.

A modell tervezésekor győződjön meg arról, hogy egy attribútum csak egyszer és egyszer látható a modellben. A felhasználói e-mail-címnek például csak a Felhasználók dimenziótáblában kell megjelennie. Más ténytáblákban is létezni fog (dimenziókulcsként a modellkapcsolatok támogatásához). Azonban minden ténytáblában el kell rejtenie.

Javasoljuk, hogy az adatmodellt a jelentésektől elkülönítve hozza létre. A szemantikai modellek és jelentéseinek leválasztása egy központosított szemantikai modellt eredményez, amely számos jelentést képes kiszolgálni. A megosztott szemantikai modell használatáról további információt a felügyelt önkiszolgáló BI használati forgatókönyvében talál.

Fontolja meg a sorszintű biztonság (RLS) beállítását, hogy más felhasználók – a Kiválósági Központon, az auditorokon és a rendszergazdákon kívül – elemezni és jelenteni tudják az adatok naplózását. Az RLS-szabályok használatával például lehetővé teheti a tartalomkészítők és a felhasználók számára, hogy jelentést tegyenek saját felhasználói tevékenységeikről vagy fejlesztési erőfeszítéseikről.

Ellenőrzőlista – Az adatmodell létrehozásakor a legfontosabb döntések és műveletek a következők:

  • Az adatmodell megtervezése és létrehozása: Az adatmodell tervezése csillagsémaként. Ellenőrizze, hogy a kapcsolatok a kívánt módon működnek-e. A modell fejlesztése során iteratív módon hozzon létre mértékeket, és adjon hozzá további adatokat az elemzési követelmények alapján. Szükség esetén a jövőbeni fejlesztéseket is belefoglalja a hátralékba.
  • RLS beállítása: Ha elérhetővé szeretné tenni az adatmodellt más általános felhasználók számára, állítsa be a sorszintű biztonságot az adathozzáférés korlátozásához. Ellenőrizze, hogy az RLS-szerepkörök a megfelelő adatokat adja-e vissza.

Az adatmodell továbbfejlesztése

A tartalomhasználat és a felhasználói tevékenységek hatékony elemzéséhez javasoljuk, hogy bővítse adatmodelljét. Az adatmodell fejlesztései fokozatosan és iteratív módon, a lehetőségek és az új követelmények felfedezése során végezhetők el.

Besorolások létrehozása

A modell továbbfejlesztésének és az adatok értékének növelésének egyik módja, ha besorolásokat ad hozzá az adatmodellhez. Győződjön meg arról, hogy a jelentések következetesen használják ezeket a besorolásokat.

Dönthet úgy, hogy a felhasználókat a használat szintje alapján sorolja be, vagy a tartalmat a használat szintje alapján osztályozza.

Felhasználói használat besorolása

Vegye figyelembe a következő besorolásokat a felhasználói használathoz.

  • Gyakori felhasználó: Az elmúlt héten és az elmúlt 12 hónapból kilencben rögzített tevékenység.
  • Aktív felhasználó: Az elmúlt hónapban rögzített tevékenység.
  • Alkalmi felhasználó: Az elmúlt kilenc hónapban rögzített tevékenység, de az elmúlt egy hónapban nem történt tevékenység.
  • Inaktív felhasználó: Az elmúlt kilenc hónapban nem rögzített tevékenység.

Tipp.

Hasznos tudni, hogy kik az alkalmi vagy inaktív felhasználók, különösen akkor, ha pro- vagy PPU-licencekkel rendelkeznek (amelyek költséggel járnak). Emellett hasznos tudni, hogy kik a gyakori és legaktívabb felhasználók. Fontolja meg, hogy meghívja őket a munkaidőbe való bekapcsolódásra, vagy vegyen részt a képzésen. A legaktívabb tartalomkészítők lehetnek a bajnokok hálózatához való csatlakozásra jelentkezők.

Tartalomhasználat besorolása

A tartalomhasználathoz vegye figyelembe az alábbi besorolásokat.

  • Gyakran használt tartalom: Az elmúlt héten és az elmúlt 12 hónapból kilencben rögzített tevékenység.
  • Aktívan használt tartalom: Az elmúlt hónapban rögzített tevékenység.
  • Alkalmanként használt tartalom: Az elmúlt kilenc hónapban rögzített tevékenység, de az elmúlt egy hónapban nem történt tevékenység.
  • Nem használt tartalom: Az elmúlt kilenc hónapban nem rögzített tevékenység.
Felhasználói típus besorolása

Vegye figyelembe a következő besorolásokat a felhasználói típushoz.

  • Tartalomkészítő: Az elmúlt hat hónapban rögzített tevékenység, amely tartalmat hozott létre, tett közzé vagy szerkesztett.
  • Tartalommegjelenítő: Az elmúlt hat hónapban rögzített tevékenység, amely megtekintette a tartalmat, de tartalomlétrehozási tevékenység nélkül.

El kell döntenie, hogy a felhasználók vagy tartalmak használati besorolásának csak a legutóbbi tevékenység alapján kell-e alapulnia. Érdemes lehet figyelembe venni az átlagos vagy a trendi használat időbeli alakulását is.

Vegyünk néhány példát, amelyek bemutatják, hogy az egyszerű besorolási logika mennyire tévesen mutatja be a valóságot.

  • Egy vezető ezen a héten megtekintett egy jelentést. A hét előtt azonban a vezető nem tekintett meg semmilyen jelentést az elmúlt hat hónapban. Ezt a kezelőt nem érdemes csak a legutóbbi használat alapján gyakori felhasználónak tekinteni.
  • A jelentéskészítő minden héten közzétesz egy új jelentést. Ha a gyakori felhasználók általi használatot elemzi, a jelentéskészítő rendszeres tevékenysége pozitívnak tűnik. A további vizsgálat során azonban azt tapasztalja, hogy ez a felhasználó minden alkalommal újra közzétesz egy új jelentést (új jelentésnévvel), amikor szerkeszti a jelentést. Hasznos lenne, ha a jelentés készítője több betanítást folytatna.
  • A vezetők szórványosan tekintenek meg egy jelentést, ezért a használatuk besorolása gyakran változik. Előfordulhat, hogy másképpen kell elemeznie bizonyos típusú felhasználókat, például vezetőket.
  • Egy belső auditor évente egyszer tekinti meg a kritikus jelentéseket. Előfordulhat, hogy a belső auditor inaktív felhasználónak tűnik a ritkán használt felhasználók miatt. Előfordulhat, hogy valaki lépéseket tesz a Pro- vagy PPU-licenc eltávolításához. Vagy előfordulhat, hogy valaki úgy gondolja, hogy egy jelentést ki kell vonni, mivel ritkán használják.

Tipp.

Az átlagokat és trendeket a DAX időintelligencia-függvények használatával számíthatja ki. Ha szeretné megtudni, hogyan használhatja ezeket a függvényeket, használja a DAX időintelligencia-függvények használatát a Power BI Desktop-modellek tanulási moduljában.

Ellenőrzőlista – A használati adatok besorolásának létrehozásakor a legfontosabb döntések és műveletek a következők:

  • Megegyezés a besorolási definíciókkal kapcsolatban: A besorolási definíciók megvitatása az érintett felekkel. A döntések meghozatalakor győződjön meg arról, hogy van megállapodás.
  • Dokumentáció létrehozása: Győződjön meg arról, hogy a besorolási definíciók szerepelnek a tartalomkészítők és a felhasználók dokumentációjában.
  • Visszajelzési ciklus létrehozása: Győződjön meg arról, hogy a felhasználók kérdéseket tehetnek fel, vagy módosításokat javasolnak a besorolási definíciókhoz.

Elemzési jelentések létrehozása

Ezen a ponton a naplózási adatok kinyerése és tárolása megtörtént, és közzétett egy adatmodellt. A következő lépés az elemzési jelentések létrehozása.

Koncentráljon az egyes célközönségek számára legrelevánsabb legfontosabb információkra. Előfordulhat, hogy több célközönsége is van a naplózási jelentésekhez. Minden közönséget különböző információk érdekelnek, és különböző célokra. A jelentésekhez kapcsolódó célközönségek a következők:

  • Vezetői szponzor
  • Kiválósági központ
  • Power BI-rendszergazdák
  • Munkaterület-rendszergazdák
  • Prémium szintű kapacitásgazdák
  • Átjárógazdák
  • Power BI-fejlesztők és tartalomkészítők
  • Ellenőrök

Íme néhány a leggyakoribb elemzési követelmények közül, amelyeket érdemes lehet kezdeni a naplózási jelentések létrehozásakor.

  • Legnépszerűbb tartalommegtekintések: Előfordulhat, hogy a vezető szponzor és a vezetői csapatok elsősorban az összefoglaló információk és trendek iránt érdeklődnek az idő múlásával. A munkaterület rendszergazdáit, fejlesztőit és tartalomkészítőit jobban érdeklik a részletek.
  • Legfontosabb felhasználói tevékenységek: A Kiválósági központ érdekli, hogy ki és hogyan használja a Power BI-t, hogyan és mikor. A prémium szintű kapacitásgazdák érdeklődnek, hogy ki használja a kapacitást az állapotának és stabilitásának biztosítása érdekében.
  • Bérlői leltár: A Power BI-rendszergazdák, munkaterület-rendszergazdák és auditorok tudni fogják, hogy milyen tartalmak léteznek, hol, hogyan, hogyan és milyen biztonsági beállításokat tartalmaznak.

Ez a lista nem minden. Célja, hogy ötleteket adjon az adott igényeknek megfelelő elemzési jelentések létrehozásának módjáról. További szempontokért tekintse meg a cikk korábbi, adatigényeit , valamint a naplózás és a figyelés áttekintését. Ezek az erőforrások számos ötletet tartalmaznak a naplózási adatok használatára, valamint a jelentésekben megjelenítendő információk típusaira.

Tipp.

Bár csábító, hogy sok adatot jelenítsen meg, csak olyan információkat tartalmazzon, amelyeket készen áll a cselekvésre. Győződjön meg arról, hogy minden jelentésoldal egyértelmű a céljáról, a végrehajtandó műveletekről és a személyekről.

Ha szeretné megtudni, hogyan hozhat létre elemzési jelentéseket, a Hatékony jelentések tervezése a Power BI képzési tervében.

Ellenőrzőlista – Az elemzési naplózási jelentések tervezésekor a legfontosabb döntések és műveletek a következők:

  • Követelmények áttekintése: Fontossági sorrendbe kell helyezni a jelentések létrehozását az ismert igények és a megválaszolandó konkrét kérdések alapján.
  • Győződjön meg a célközönség(ek)ről: Tisztázza, hogy ki fogja használni a naplózási jelentéseket, és hogy mi legyen a céljuk.
  • Jelentések létrehozása és üzembe helyezése: Az első alapjelentés-készlet fejlesztése. Az idő múlásával fokozatosan bővítheti és fejlesztheti őket.
  • Jelentések terjesztése egy alkalmazásban: Érdemes lehet olyan alkalmazást létrehozni, amely tartalmazza az összes naplózási és monitorozási jelentést.
  • Ellenőrizze, hogy kinek van hozzáférése a jelentésekhez: Győződjön meg arról, hogy a jelentések (vagy az alkalmazás) a megfelelő felhasználók számára vannak elérhetővé téve.
  • Visszajelzési ciklus létrehozása: Győződjön meg arról, hogy a jelentésfelhasználók visszajelzést, javaslatokat vagy jelentésproblémákat nyújthatnak.

Művelet végrehajtása az adatok alapján

Az adatok naplózása azért értékes, mert segít megérteni, hogy mi történik a Power BI-bérlőben. Bár nyilvánvalónak tűnhet, a naplózási adatokból tanultakra való explicit cselekvés könnyen figyelmen kívül hagyható. Ezért azt javasoljuk, hogy a naplójelentések áttekintése helyett olyan valakit rendeljen hozzá, aki felelős a mérhető fejlesztések nyomon követéséért. Így fokozatos, mérhető fejlődést érhet el a Power BI-val való bevezetésben és az érettség szintjén.

A célok és a naplózási adatokból tanultak alapján számos különböző műveletet hajthat végre. A szakasz többi része több ötletet is tartalmaz.

Tartalomhasználat

Íme néhány művelet, amelyet a tartalom használatán alapulva hajthat végre.

  • A tartalmat gyakran használják (naponta vagy hetente): Ellenőrizze, hogy a kritikus tartalmak minősítése van-e. Győződjön meg arról, hogy a tulajdonjog egyértelmű, és a megoldás megfelelően támogatott.
  • Nagy számú munkaterületnézet: Ha nagy számú munkaterületnézet fordul elő, vizsgálja meg, hogy miért nincsenek használatban a Power BI-alkalmazások.
  • Ritkán használnak tartalmat: Forduljon a célfelhasználókhoz, és állapítsa meg, hogy a megoldás megfelel-e az igényeiknek, vagy megváltoztak-e a követelmények.
  • A frissítési tevékenység gyakrabban fordul elő, mint a nézetek: Forduljon a tartalom tulajdonosához, hogy megértse, miért frissül rendszeresen egy szemantikai modell a szemantikai modell vagy a kapcsolódó jelentések legutóbbi használata nélkül.

Felhasználói tevékenységek

Íme néhány művelet, amelyeket felhasználói tevékenységek alapján hajthat végre.

  • Első közzétételi művelet egy új felhasználótól: Annak azonosítása, hogy egy felhasználó mikor vált át a felhasználóról a létrehozóra, amelyet ön azonosíthat, amikor először tesznek közzé tartalmat. Nagyszerű lehetőség arra, hogy egy szabványos e-mailt küldjön nekik, amely útmutatást és hasznos erőforrásokra mutató hivatkozásokat tartalmaz.
  • Együttműködés a leggyakoribb tartalomkészítőkkel: Kérje meg a legaktívabb alkotókat, hogy csatlakozzanak a bajnokok hálózatához, vagy vegyenek részt a gyakorlat közösségében.
  • Licenckezelés: Ellenőrizze, hogy az inaktív alkotóknak továbbra is pro- vagy PPU-licencre van-e szükségük.
  • Felhasználói próbaverzió aktiválása: A próbalicenc aktiválása arra kérheti, hogy rendeljen hozzá egy állandó licencet a felhasználóhoz a próbaidőszak lejárta előtt.

Felhasználói betanítási lehetőségek

Íme néhány felhasználói betanítási lehetőség, amelyet a naplózási adatokból azonosíthat.

  • Nagy számú szemantikai modell, amelyet ugyanaz a tartalomkészítő tett közzé: Megtanítja a felhasználókat a megosztott szemantikai modellekre, és hogy miért fontos elkerülni a duplikált szemantikai modellek létrehozását.
  • Túlzott megosztás személyes munkaterületről: Lépjen kapcsolatba egy olyan felhasználóval, aki sok megosztást végez a személyes munkaterületéről. Tanítsd meg őket a standard munkaterületekről.
  • Jelentős jelentésnézetek egy személyes munkaterületről: Lépjen kapcsolatba egy olyan felhasználóval, aki nagy számú jelentésnézetet tartalmazó tartalommal rendelkezik. Megtanítja nekik, hogyan jobbak a standard munkaterületek, mint a személyes munkaterületek.

Tipp.

A betanítási tartalmakat és a dokumentációt úgy is javíthatja, hogy áttekinti a belső Power BI-közösség által megválaszolt kérdéseket és a segélyszolgálatnak küldött problémákat.

Biztonság

Íme néhány biztonsági helyzet, amelyet érdemes lehet aktívan figyelni.

További információ: Biztonságtervezési cikkek.

Irányítás és kockázatcsökkentés

Íme néhány helyzet, amelyekkel találkozhat. Fontolja meg, hogy explicit módon keresi az ilyen típusú helyzeteket a naplózási jelentésekben, így készen áll a gyors cselekvésre.

  • A nem támogatott jelentések (és a mögöttes szemantikai modellek) nagy száma.
  • Ismeretlen vagy nem felügyelt adatforrások jelentős használata.
  • Azok a fájlhelyek, amelyek nem összhangban vannak a forrásfájlok helyének szabályozási irányelveivel.
  • A munkaterületnevek nem összhangban vannak az irányítási követelményekkel.
  • A bizalmassági címkék az információvédelemhez használatosak.
  • Konzisztens adatfrissítési hibák.
  • A nyomtatás jelentős és ismétlődő használata.
  • Az előfizetések váratlan vagy túlzott használata.
  • Személyes átjárók váratlan használata.

Az egyes helyzetekben végrehajtandó konkrét műveletek az ön irányítási szabályzataitól függnek. További információ: Irányítás a Háló bevezetésének ütemtervében.

Ellenőrzőlista – A naplózási adatokon alapuló lehetséges műveletek tervezésekor a legfontosabb döntések és műveletek a következők:

  • Az elvárások tisztázása: Hozzon létre naplózási jelentéseket a várt műveletekre vonatkozó egyértelmű elvárásokkal.
  • Tisztázza, hogy ki lesz a felelős a műveletekért: Győződjön meg arról, hogy a szerepkörök és a felelősségek ki vannak rendelve.
  • Automatizálás létrehozása: Ha lehetséges, automatizálja az ismétlődő ismert műveleteket.
  • Nyomkövetési rendszer használata: Egy rendszer használatával nyomon követheti a megfigyelt helyzetet, beleértve a kapcsolattartót, a következő tervezett műveletet, a felelőst, a megoldást és az állapotot.

4. fázis: Karbantartás, javítás és figyelés

A bérlőszintű naplózási megoldás tervezésének és implementálásának negyedik fázisa a karbantartásra, a fejlesztésekre és a monitorozásra összpontosít. Ezen a ponton a naplózási megoldás éles használatban van. Most elsősorban a megoldás karbantartásával, fejlesztésével és monitorozásával foglalkozik.

A 4. fázist leíró folyamatábra, amely egy bérlőszintű naplózási megoldás karbantartására, fejlesztésére és monitorozására összpontosít.

Működés és fejlesztés

A naplózási folyamatok általában éles környezetben futnak, amikor a kezdeti fejlesztés és tesztelés befejeződött, és ön automatizálta a folyamatot. Az éles környezetben futó automatizált naplózási folyamatok nagyobb elvárásokkal rendelkeznek (mint a manuális folyamatok) a minőség, a megbízhatóság, a stabilitás és a támogatás terén.

Az éles szintű naplózási folyamat üzembe lett állítva. Az üzembe helyezett megoldások gyakran az alábbi jellemzők közül sokat tartalmaznak.

  • Biztonságos: A hitelesítő adatok biztonságosan vannak tárolva és felügyelve. A szkriptek nem tartalmaznak jelszavakat vagy kulcsokat egyszerű szövegben.
  • Ütemezés: Megbízható ütemezési rendszer van érvényben.
  • Változáskezelés: A változáskezelési eljárások és több környezet használata biztosítja az éles környezet védelmét. Fejlesztési és tesztelési környezetekkel, vagy csak egy fejlesztési környezettel is dolgozhat.
  • Támogatás: A megoldást támogató csapat egyértelműen definiálva van. A csapattagokat betanították, és megértik az üzemeltetési elvárásokat. A biztonsági mentési tagokat azonosították, és szükség esetén kereszttanúsítás történik.
  • Riasztás: Ha hiba történik, a riasztások automatikusan értesítik a támogatási csapatot. A riasztások lehetőleg a naplókat és az e-maileket is tartalmazzák (nem csak e-maileket). A naplók hasznosak a naplózott hibák és figyelmeztetések elemzéséhez.
  • Naplózás: A rendszer naplózza a folyamatokat, így a naplózási adatok frissítésének előzményei vannak. A naplózott adatoknak rögzíteni kell a kezdési időpontot, a befejezési időt és a folyamatot futtató felhasználó vagy alkalmazás identitását.
  • Hibakezelés: A szkriptek és folyamatok elegánsan kezelik és naplózják a hibákat (például azt, hogy azonnal ki kell-e lépni, folytatni vagy várni, majd újra próbálkozni). Hiba esetén a rendszer riasztási értesítéseket küld a támogatási csapatnak.
  • Kódolási szabványok: Jó kódolási technikákat használnak, amelyek jól teljesítenek. A hurkok például szándékosan kerülhetők el, kivéve, ha szükséges. Konzisztens kódolási szabványokat, megjegyzéseket, formázást és szintaxist használ, hogy a megoldás könnyebben karbantartható és támogatott legyen.
  • Újrahasználat és modularizálás: A duplikációk minimalizálása érdekében a kód- és konfigurációs értékek (például kapcsolati sztring vagy értesítési e-mail-címek) modularizáltak, hogy más szkriptek és folyamatok újra felhasználhassák őket.

Tipp.

Nem kell mindent egyszerre elvégeznie. A tapasztalat megszerzése során fokozatosan fejlesztheti a megoldást, hogy teljessé és robusztussá váljon. Vegye figyelembe, hogy az interneten talált példák többsége egyszerű, egyszeri szkriptrészletek, amelyek nem feltétlenül éles minőségűek.

Ellenőrzőlista – A naplózási megoldás üzembe helyezésének és fejlesztésének tervezésekor a legfontosabb döntések és műveletek a következők:

  • A meglévő megoldások szintjének felmérése: Annak meghatározása, hogy vannak-e lehetőségek az automatizált naplózási megoldások fejlesztésére és stabilizálására.
  • Éles szintű szabványok létrehozása: Döntse el, hogy milyen szabványokat szeretne használni az automatizált naplózási folyamatokhoz. Vegye figyelembe azokat a fejlesztéseket, amelyeket reálisan adhat hozzá az idő múlásával.
  • Hozzon létre egy fejlesztési tervet: Tervezze meg az éles naplózási megoldások minőségének és stabilitásának javítását.
  • Határozza meg, hogy szükség van-e külön fejlesztési környezetre: Értékelje a kockázat szintjét és az éles adatokra való támaszkodást. Döntse el, mikor hoz létre külön fejlesztési és éles (és tesztelési) környezeteket.
  • Fontolja meg az adatmegőrzési stratégiát: Határozza meg, hogy szükség van-e olyan adatmegőrzési folyamat implementálására, amely bizonyos idő elteltével vagy kérésre törli az adatokat.

Dokumentáció és támogatás

A dokumentáció és a támogatás minden éles szintű megoldás esetében kritikus fontosságú. A célközönségtől és a céltól függően számos típusú dokumentációt érdemes létrehozni.

Technikai dokumentáció

A műszaki dokumentáció a megoldást létrehozó műszaki csapatra irányul, aki idővel fokozatosan fejleszti és bővíti a megoldást. A támogatási csapat számára is hasznos erőforrás.

A műszaki dokumentációnak tartalmaznia kell a következőket:

  • Az architektúra összetevőinek és előfeltételeinek összegzése.
  • Ki birtokolja és kezeli a megoldást.
  • Ki támogatja a megoldást.
  • Egy architektúradiagram.
  • Tervezési döntések, beleértve a célokat, bizonyos technikai döntések okait és a korlátokat (például a költségeket vagy a készségeket).
  • Biztonsági döntések és választási lehetőségek.
  • Használt elnevezési konvenciók.
  • Kódolás, műszaki szabványok és irányelvek.
  • Változáskezelési követelmények.
  • Üzembe helyezési, telepítési és telepítési utasítások.
  • A műszaki adósság ismert területei (olyan területek, amelyek javíthatók, ha erre lehetőség van).

Támogatási dokumentáció

A naplózási megoldás kritikussági szintjétől függően előfordulhat, hogy segélyszolgálattal vagy támogatási csapattal kell rendelkeznie, ha sürgős problémák merülnek fel. Lehet, hogy egész nap, minden nap elérhetők.

A támogatási dokumentációt néha tudásbázis vagy runbooknak is nevezik. Ez a dokumentáció az ügyfélszolgálatra vagy a támogatási csapatra irányul, és a következőket kell tartalmaznia:

  • Hibaelhárítási útmutató a hiba elhárításához. Például adatfrissítési hiba esetén.
  • Folyamatosan végrehajtandó műveletek. Előfordulhat például, hogy valakinek rendszeresen kell elvégeznie néhány manuális lépést, amíg meg nem oldja a problémát.

Tartalomkészítő dokumentáció

Több értéket nyer a naplózási megoldásból azáltal, hogy használati és bevezetési elemzéseket biztosít a szervezet más csapatainak (szükség esetén sorszintű biztonsággal).

A tartalomkészítő dokumentáció olyan önkiszolgáló tartalomkészítők számára készült, akik jelentéseket és adatmodelleket hoznak létre, amelyek a kiválasztott naplózási adatokat forrásként használják. Információkat tartalmaz az adatmodellről, beleértve a gyakori adatdefiníciókat is.

Ellenőrzőlista – A naplózási megoldás dokumentációjának és támogatásának tervezésekor a legfontosabb döntések és műveletek a következők:

  • Ellenőrizze, hogy ki támogatja a megoldást: Határozza meg, hogy ki támogatja az éles szintűnek (vagy alsóbb rétegbeli jelentésfüggőségnek minősülő) naplózási megoldásokat.
  • A támogatási csapat felkészültségének biztosítása: Ellenőrizze, hogy a támogatási csapat készen áll-e a naplózási megoldás támogatására. Állapítsa meg, hogy vannak-e olyan felkészültségi hiányosságok, amelyeket kezelni kell.
  • Képzések közötti rendezés: Tudásátadási vagy kereszttanítási munkamenetek szervezése a támogatási csapat számára.
  • A támogatási csapat elvárásainak tisztázása: Győződjön meg arról, hogy a válaszra és a megoldásra vonatkozó elvárások egyértelműen dokumentálva és kommunikálva vannak. Döntse el, hogy szükség van-e bárki meghívására a naplózási megoldással kapcsolatos problémák gyors megoldásához.
  • Műszaki dokumentáció létrehozása: Dokumentáció létrehozása a műszaki architektúráról és a tervezési döntésekről.
  • Támogatási dokumentáció létrehozása: Frissítse az ügyfélszolgálat tudásbázisát, hogy a megoldás támogatásával kapcsolatos információkat tartalmazzon.
  • Dokumentáció létrehozása tartalomkészítők számára: Dokumentáció létrehozása az önkiszolgáló létrehozók számára az adatmodell használatához. Ismertesse a gyakori adatdefiníciókat a használat konzisztenciájának javítása érdekében.

Riasztás engedélyezése

Előfordulhat, hogy a naplózási adatok adott feltételei alapján szeretne riasztásokat létrehozni. Riasztást állíthat be például, ha valaki töröl egy átjárót, vagy ha egy Power BI-rendszergazda módosít egy bérlői beállítást.

További információ: Bérlőszintű monitorozás.

Folyamatos felügyelet

A teljes naplózási megoldás folyamatos felügyeletét kell elvégeznie. Előfordulhat, hogy ki kell terjesztenie vagy módosítania kell a naplózási megoldást, ha:

  • A szervezet új adatkövetelményeket fedez fel.
  • Az új naplózási események a Power BI REST API-kból pontosan megadott nyers adatokban jelennek meg.
  • A Microsoft módosítja a Power BI REST API-kat.
  • Az alkalmazottak azonosítják a megoldás fejlesztésének módjait.

Fontos

A kompatibilitástörő változások ritkán fordulnak elő, de előfordulhatnak. Fontos, hogy rendelkezésre álljon valaki, aki gyorsan elháríthatja a problémákat, vagy szükség esetén frissítheti a naplózási megoldást.

Ellenőrzőlista – A naplózási megoldás folyamatos felügyeletének tervezésekor a legfontosabb döntések és műveletek a következők:

  • Műszaki tulajdonos hozzárendelése: Győződjön meg arról, hogy a teljes auditálási megoldásnak egyértelmű tulajdonjoga és felelőssége van.
  • Ellenőrizze, hogy létezik-e biztonsági másolat: Győződjön meg arról, hogy van egy biztonsági mentési műszaki tulajdonos, aki részt vehet, ha olyan sürgős probléma merül fel, amelyet a támogatás nem tud megoldani.
  • Nyomkövetési rendszer megőrzése: Győződjön meg arról, hogy rendelkezik az új kérések rögzítésének és az azonnali prioritások, valamint a rövid távú, közép- és hosszú távú (hátralékos) prioritások rangsorolásának módjával.

Kapcsolódó tartalom

A sorozat következő cikkében megismerheti a bérlői szintű monitorozást.