Szolgáltatásnévprofilok több-bérlős alkalmazásokhoz a Power BI Embeddedben
Ez a cikk ismerteti, hogyan képezheti le és kezelheti az egyes ügyfelek adatait egy független szoftverszolgáltató vagy bármely más Power BI Embedded alkalmazástulajdonos azáltal, hogy szolgáltatásnév-profilokat használ ügyfeleik Power BI-beágyazási megoldásának részeként. A szolgáltatásnévprofilok lehetővé teszik, hogy az ISV méretezhető alkalmazásokat hozzon létre, amelyek jobb ügyféladat-elkülönítést tesznek lehetővé, és szigorúbb biztonsági határokat szabnak az ügyfelek között. Ez a cikk a megoldás előnyeit és korlátait ismerteti.
Feljegyzés
A Power BI-ben a bérlő szó néha egy Microsoft Entra-bérlőre hivatkozhat. Ebben a cikkben azonban a több-bérlős kifejezést használjuk egy olyan megoldás leírására, amelyben egy szoftveralkalmazás egyetlen példánya több ügyfelet vagy szervezetet (bérlőt) szolgál ki, amelyek az adatok fizikai és logikai elkülönítését igénylik. A Power BI alkalmazáskészítője például külön munkaterületet foglalhat le az egyes ügyfeleinek (vagy bérlőinek) az alábbiak szerint. Ezek az ügyfelek nem feltétlenül Microsoft Entra-bérlők, ezért ne keverje össze az itt használt több-bérlős alkalmazást a Microsoft Entra több-bérlős alkalmazással.
A szolgáltatás képviselő profilja egy szolgáltatás képviselője által létrehozott profil. Az ISV-alkalmazás szolgáltatásnév-profil használatával hívja meg a Power BI API-kat, amint azt a jelen cikk ismerteti.
Az ISV-alkalmazás szolgáltatásnév minden ügyfélhez vagy bérlőhöz másik Power BI-profilt hoz létre. Amikor egy ügyfél felkeresi az ISV-alkalmazást, az alkalmazás a megfelelő profillal hoz létre egy beágyazási jogkivonatot , amely a jelentés böngészőben való megjelenítésére szolgál.
A szolgáltatásnévprofilok használatával az ISV-alkalmazás több ügyfelet is üzemeltethet egyetlen Power BI-bérlőn. Minden profil egy ügyfelet jelöl a Power BI-ban. Más szóval minden profil létrehoz és kezel Egy adott ügyfél adataihoz tartozó Power BI-tartalmat.
Feljegyzés
Ez a cikk azon szervezeteknek szól, amelyek szolgáltatásfőszereplői profilok használatával szeretnének több-bérlős alkalmazást beállítani. Ha szervezete már rendelkezik olyan alkalmazással, amely támogatja a több-bérlős használatot, és át szeretne migrálni a szolgáltatásnévprofil-modellbe, olvassa el az Áttelepítés a szolgáltatásnévprofil-modellbe című témakört.
A Power BI-tartalom beállítása a következő lépésekkel jár:
- Profil létrehozása
- Profilengedélyek beállítása
- Munkaterület létrehozása minden ügyfél számára
- Jelentések és szemantikai modellek importálása a munkaterületre
- A szemantikai modell kapcsolati adatainak beállítása az ügyfél adataihoz való csatlakozáshoz
- Engedélyek eltávolítása a szolgáltatási névazonosítóról (nem kötelező, de elősegíti a méretezhetőséget)
- Jelentés beágyazása az alkalmazásba
A fenti lépések teljes mértékben automatizálhatók a Power BI REST API-kkal.
Előfeltételek
A szolgáltatásnév-profilok létrehozása előtt a következőkre van szükség:
- A szolgáltatásnév beállításához kövesse a Power BI-tartalom szolgáltatásnévvel való beágyazásának első három lépését.
- Power BI-bérlői rendszergazdai fiókból engedélyezze a profilok létrehozását a bérlői környezetben ugyanazzal a biztonsági csoporttal, amelyet a szolgáltatási főszereplő létrehozásakor használt.
Profil létrehozása
Profilok hozhatók létre, frissíthetők és törölhetők a Profiles REST API használatával.
Például profil létrehozásához:
POST https://api.powerbi.com/v1.0/myorg/profiles HTTP/1.1
Authorization: Bearer eyJ0eXAiOiJK…UUPA
Content-Type: application/json; charset=utf-8
{"displayName":"ContosoProfile"}
A szolgáltatási azonosító a profiljai listájának lekéréséhez meghívhatja a GET Profiles REST API-t is. Példa:
GET https://api.powerbi.com/v1.0/myorg/profiles HTTP/1.1
Authorization: Bearer eyJ0eXA…UUPA
Profilengedélyek
Bármely API, amely felhasználói engedélyt ad a Power BI-elemekhez, profilengedélyt is adhat a Power BI-elemekhez. A Csoportfelhasználói API hozzáadása például profilengedély megadására használható egy munkaterületen.
A profilok használatakor az alábbi szempontokat fontos megérteni:
- A profil az azt létrehozó szolgáltatásnévhez tartozik, és csak az adott szolgáltatásnév használhatja.
- A profil tulajdonosa nem módosítható a létrehozás után.
- A profilok nem önálló identitások. A Power BI REST API-k meghívásához szüksége van a Szolgáltatásnév Microsoft Entra-jogkivonatára .
Az ISV-alkalmazások úgy hívják meg a Power BI REST API-kat, hogy megadja a szolgáltatásnév Microsoft Entra-jogkivonatát az Engedélyezés fejlécben, és a profilazonosítót az X-PowerBI-Profile-Id fejlécben. Példa:
GET https://api.powerbi.com/v1.0/myorg/groups HTTP/1.1
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUz.....SXBwasfg
X-PowerBI-Profile-Id: 5f1aa5ed-5983-46b5-bd05-999581d361a5
Munkaterület létrehozása
A Power BI-munkaterületek Power BI-elemek, például jelentések és szemantikai modellek üzemeltetésére szolgálnak.
Minden profilnak a következőnek kell lennie:
Legalább egy Power BI-munkaterület létrehozása
POST https://api.powerbi.com/v1.0/myorg/groups HTTP/1.1 Authorization: Bearer eyJ0eXA…ZUiIsg Content-Type: application/json; charset=utf-8 X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306 { "name": "ContosoWorkspace" }
Hozzáférési engedélyek megadása a munkaterülethez. A szolgáltatásnévprofilnak rendszergazdai hozzáféréssel kell rendelkeznie a munkaterülethez.
Munkaterület hozzárendelése kapacitáshoz
POST https://api.powerbi.com/v1.0/myorg/groups/f313e682-c86b-422c-a3e2-b1a05426c4a3/AssignToCapacity HTTP/1.1 Authorization: Bearer eyJ0eXAiOiJK…wNkZUiIsg Content-Type: application/json; charset=utf-8 X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306 { "capacityId": "13f73071-d6d3-4d44-b9de-34590f3e3cf6" }
További információ a Power BI-munkaterületekről.
Jelentések és szemantikai modellek importálása
A Power BI Desktop segítségével előkészítheti az ügyfél adataihoz vagy mintaadataihoz kapcsolódó jelentéseket. Ezután az Importálás API-val importálhatja a tartalmat a létrehozott munkaterületre.
POST https://api.powerbi.com/v1.0/myorg/groups/f313e682-c86b-422c-a3e2-b1a05426c4a3/imports?datasetDisplayName=ContosoSales HTTP/1.1
Authorization: Bearer eyJ...kZUiIsg
Content-Type: multipart/form-data; boundary="8b071895-b380-4769-9c62-7e586d717ed7"
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306
Fiddler-Encoding: base64
LS04YjA3MTg5NS1iMzgwLTQ3...Tg2ZDcxN2VkNy0tDQo=
Adathalmazparaméterek használatával hozzon létre egy szemantikai modellt, amely képes csatlakozni a különböző ügyfelek adatforrásaihoz. Ezután az Update parameters API használatával határozza meg, hogy mely ügyfelek adataihoz csatlakozik a szemantikai modell.
A szemantikai modell kapcsolatának beállítása
Az ISV-k általában kétféleképpen tárolják ügyfeleik adatait:
Mindkét esetben arra kell törekednie, hogy egybérlős szemantikai modellekhez jusson el (minden ügyfélhez egy szemantikai modell) a Power BI-ban.
Külön adatbázis minden ügyfélhez
Ha az ISV-alkalmazás minden ügyfélhez külön adatbázissal rendelkezik, hozzon létre egybérlős szemantikai modelleket a Power BI-ban. Adja meg az egyes szemantikai modellek kapcsolati adatait, amelyek az egyező adatbázisra mutatnak. Az alábbi módszerek egyikével elkerülheti, hogy több azonos jelentést hozzon létre különböző kapcsolati adatokkal:
Szemantikai modellparaméterek: Hozzon létre egy szemantikai modellt a kapcsolat részleteiben szereplő paraméterekkel (például SQL Server név, SQL-adatbázis neve). Ezután importáljon egy jelentést egy ügyfél munkaterületére, és módosítsa a paramétereket az ügyfél adatbázis-adatainak megfelelően.
Datasource API frissítése: Hozzon létre egy .pbix-t, amely mintatartalommal rendelkező adatforrásra mutat. Ezután importálja a .pbix-t egy ügyfél munkaterületére, és módosítsa a kapcsolat részleteit az Update Datasource API használatával.
Egyetlen több-bérlői adatbázis
Ha az ISV-alkalmazás egy adatbázist használ az összes ügyfél számára, az ügyfeleket a következőképpen válassza el különböző szemantikai modellekre a Power BI-ban:
Hozzon létre egy jelentést olyan paraméterekkel, amelyek csak a megfelelő ügyfél adatait kérik le. Ezután importáljon egy jelentést egy ügyfél munkaterületére, és módosítsa a paramétereket , hogy csak a megfelelő ügyfél adatait kérje le.
Jelentés beágyazása
A telepítés befejezése után beágyazhat ügyféljelentéseket és egyéb elemeket az alkalmazásba egy beágyazási jogkivonat használatával.
Amikor egy ügyfél felkeresi az alkalmazást, a megfelelő profillal hívja meg a GenerateToken API-t. A létrehozott beágyazási jogkivonat használatával beágyazhat egy jelentést vagy más elemet az ügyfél böngészőjébe.
Beágyazási jogkivonat létrehozása:
POST https://api.powerbi.com/v1.0/myorg/GenerateToken HTTP/1.1
Authorization: Bearer eyJ0eXAiOi…kZUiIsg
Content-Type: application/json; charset=utf-8
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306
{
"datasets": [
{
"id": "3b1c8f74-fbbe-45e0-bf9d-19fce69262e3"
}
],
"reports": [
{
"id": "3d474b89-f2d5-43a2-a436-d24a6eb2dc8f"
}
]
}
Tervezési szempontok
Profilalapú több-bérlős megoldás beállítása előtt vegye figyelembe a következő problémákat:
- Méretezhetőség
- Automatizálás és üzemeltetés összetettsége
- Multi-Geo igények
- Költséghatékonyság
- Row level security
Méretezhetőség
Ha az adatokat külön szemantikai modellekre választja el az egyes ügyfelek számára, minimalizálja a nagy szemantikai modellek szükségességét. Ha a kapacitás túlterhelődik, kiürítheti a nem használt szemantikai modelleket, hogy memóriát szabadítjon fel az aktív szemantikai modellek számára. Ez az optimalizálás egyetlen nagy szemantikai modell esetében lehetetlen. Több szemantikai modell használatával szükség esetén több Power BI-kapacitásra is elkülönítheti a bérlőket.
Profilok nélkül a szolgáltatásazonosító 1000 munkaterületre korlátozódik. A korlát leküzdése érdekében a szolgáltatásnév több profilt is létrehozhat, ahol minden profil legfeljebb 1000 munkaterületet érhet el vagy hozhat létre. Több profillal az ISV-alkalmazás elkülönítheti az egyes ügyfelek tartalmát különböző logikai tárolók használatával.
Ha egy szolgáltatás-alkalmazásprofil hozzáféréssel rendelkezik egy munkaterülethez, a szülő-szolgáltatás-alkalmazás hozzáférése a munkaterülethez eltávolítható a méretezhetőségi problémák elkerülése érdekében.
Még ezekkel az előnyökkel is érdemes figyelembe vennie az alkalmazás lehetséges méretet. Például a profil által elérhető munkaterületelemek száma korlátozott. Egy profilnak ma ugyanazok a korlátai vannak, mint egy normál felhasználónak. Ha az ISV-alkalmazás lehetővé teszi a végfelhasználók számára a beágyazott jelentések személyre szabott másolatának mentését, az ügyfél profiljának hozzáférése lesz az összes felhasználó összes létrehozott jelentéséhez. Ez a modell végül meghaladhatja a korlátot.
Automatizálás és üzemeltetési összetettség
A Power BI profilalapú elkülönítésével több száz vagy több ezer elemet kell kezelnie. Ezért fontos meghatározni azokat a folyamatokat, amelyek gyakran fordulnak elő az alkalmazás életciklus-felügyeletében, és gondoskodni kell arról, hogy megfelelő eszközökkel rendelkezzen a műveletek nagy méretekben történő végrehajtásához. Néhány ilyen művelet a következők:
- Új bérlő hozzáadása
- Jelentés frissítése néhány vagy az összes bérlőhöz
- A szemantikai modell sémájának frissítése néhány vagy az összes bérlő esetében
- Specifikus bérlők számára készült nem tervezett testreszabások
- Szemantikai modellfrissítések gyakorisága
Egy új bérlő profiljának és munkaterületének létrehozása például gyakori feladat, amely teljes mértékben automatizálható a Power BI REST API-val.
Multi-Geo igények
A Power BI Embedded Multi-Geo támogatása azt jelenti, hogy azok az isv-k és szervezetek, amelyek a Power BI Embedded használatával építenek alkalmazásokat az elemzések alkalmazásba való beágyazásához, mostantól a világ különböző régióiban is üzembe helyezhetik az adataikat. A különböző régiókban lévő különböző ügyfelek támogatásához rendelje hozzá az ügyfél munkaterületét egy kapacitáshoz a kívánt régióban. Ez a feladat egy egyszerű művelet, amely nem jár többletköltséggel. Ha azonban több régióból származó adatokat igénylő ügyfelekkel rendelkezik, a bérlői profilnak az összes elemet több olyan munkaterületre kell duplikálnia, amelyek különböző regionális kapacitásokhoz vannak rendelve. Ez a duplikáció növelheti a költségek és a felügyelet összetettségét.
Megfelelőségi okokból előfordulhat, hogy továbbra is több Power BI-bérlőt szeretne létrehozni különböző régiókban. További információ a multi-geo-ról.
Költséghatékonyság
A Power BI Embeddedet használó alkalmazásfejlesztőknek Power BI Embedded-kapacitást kell vásárolniuk. A profilalapú elkülönítési modell jól működik a kapacitásokkal, mert:
A kapacitáshoz egymástól függetlenül hozzárendelhető legkisebb objektum egy munkaterület (például nem rendelhet hozzá jelentést). Az ügyfelek profilok szerinti elkülönítésével különböző munkaterületeket kap – ügyfélenként egyet. Így teljes rugalmasságot kap az egyes ügyfelek teljesítményigényeinek megfelelően történő kezeléséhez, valamint a kapacitáskihasználtság optimalizálásához fel- vagy leskálázással. A nagy és alapvető ügyfeleket például nagy mennyiséggel és volatilitással kezelheti egy külön kapacitásban, hogy egységes szolgáltatási szintet biztosítson, míg a kisebb ügyfeleket egy másik kapacitásba csoportosítva optimalizálja a költségeket.
A munkaterületek elkülönítése azt is jelenti, hogy a szemantikai modelleket el kell választani a bérlők között, hogy az adatmodellek kisebb adattömbökben legyenek, nem pedig egyetlen nagy szemantikai modellben. Ezek a kisebb modellek lehetővé teszik a memóriahasználat hatékonyabb kezelését. A kis, nem használt szemantikai modellek inaktivitás után kiüríthetők a jó teljesítmény fenntartása érdekében.
Kapacitás vásárlásakor vegye figyelembe a párhuzamos frissítések számának korlátját, mivel a frissítési folyamatok további kapacitást igényelhetnek, ha több szemantikai modellel rendelkezik.
Sorszintű biztonság
Ez a cikk bemutatja, hogyan hozhat létre külön szemantikai modellt a profilok használatával az egyes ügyfelek számára. Alternatív megoldásként az ISV-alkalmazások egyetlen nagy szemantikai modellben tárolhatják ügyfeleik adatait, és sorszintű biztonság (RLS) használatával védhetik az egyes ügyfelek adatait. Ez a megközelítés kényelmes lehet olyan ISV-k számára, amelyek viszonylag kevés ügyfelet és kis- és közepes méretű szemantikai modellt tartalmaznak, mivel:
- Csak egy jelentést és egy szemantikai modellt kell karbantartani
- Az új ügyfelek előkészítési folyamata egyszerűsíthető
Az RLS használata előtt azonban győződjön meg arról, hogy tisztában van a korlátozásokkal. Az összes ügyfél összes adata egy nagy Power BI szemantikai modellben található. Ez a szemantikai modell egyetlen kapacitásban fut, saját skálázással és egyéb korlátozásokkal.
Még ha szolgáltatásnévprofilokat is használ az ügyfelek adatainak elkülönítéséhez, akkor is használhatja az RLS-t egyetlen ügyfél szemantikai modelljén belül, hogy különböző csoportok számára hozzáférést biztosítson az adatok különböző részeihez. Az RLS használatával például megakadályozhatja, hogy az egyik részleg tagjai hozzáférjenek egy másik részleg adataihoz ugyanabban a szervezetben.
Szempontok és korlátozások
- A szolgáltatásnévprofilok csak a Power BI REST API-n, a Power BI .NET SDK-n, valamint az XMLA-végponton és a táblázatos objektummodellen (TOM) keresztül támogatottak az Analysis Services 16.0.139.27-es vagy újabb verziójának használatakor. A Szolgáltatásnév profilok nem támogatottak a Power BI-ban az XMLA-végponton vagy a táblázatos objektummodellen (TOM) keresztül a régebbi ügyfélkódtárakkal.
- Az Azure Analysis Services (AAS) élő kapcsolat módban nem támogatja a szolgáltatásnév-profilokat.
- Az egyetlen szolgáltatásnév legfeljebb 100 000 profillal rendelkezhet.
A Power BI kapacitáskorlátozásai
- Minden kapacitás csak a megvásárolt termékváltozatnak megfelelően használhatja a lefoglalt memóriát és a virtuális magokat. Az egyes termékváltozatokhoz javasolt szemantikai modellmérethez tekintse meg a prémium szintű nagy szemantikai modelleket.
- 10 GB-nál nagyobb szemantikai modell használatához használjon prémium szintű kapacitást, és engedélyezze a Nagy szemantikai modellek beállítást.
- A kapacitáson egyidejűleg futtatható frissítések számához hivatkozzon az erőforrás-kezelésre és az optimalizálásra.
Szolgáltatási főazonosítók kezelése
Szolgáltatási főelv módosítása
A Power BI-ban egy profil az azt létrehozó szolgáltatásnévhez tartozik. Ez azt jelenti, hogy egy profil nem osztható meg más tagokkal. Ezzel a korlátozással, ha bármilyen okból módosítani szeretné a szolgáltatásnevet, újra létre kell hoznia az összes profilt, és hozzáférést kell biztosítania az új profiloknak a megfelelő munkaterületekhez. Az ISV-alkalmazásnak gyakran mentenie kell egy megfeleltetést egy profilazonosító és egy ügyfélazonosító között, hogy szükség esetén a megfelelő profilt választhassa ki. Ha módosítja a szolgáltatásnevet, és újra létrehozza a profilokat, az azonosítók is megváltoznak, és előfordulhat, hogy frissítenie kell a leképezést az ISV-alkalmazás adatbázisában.
Szolgáltatásnév törlése
Figyelmeztetés
Legyen nagyon óvatos a szolgáltatásnév törlésekor. Nem szeretné véletlenül elveszíteni az összes társított profil adatait.
Ha törli a szolgáltatási főazonosítót az Active Directoryban, a Power BI összes profilja törlődik. A Power BI azonban nem törli azonnal a tartalmat, így a bérlői rendszergazda továbbra is hozzáférhet a munkaterületekhez. Legyen óvatos, amikor egy éles rendszerben használt szolgáltatási főelemet töröl, különösen akkor, ha ezzel a szolgáltatási főelemmel profilokat hozott létre a Power BI-ban. Ha töröl egy profilokat létrehozó szolgáltatásnevet, vegye figyelembe, hogy újra létre kell hoznia az összes profilt, hozzáférést kell biztosítania az új profiloknak a megfelelő munkaterületekhez, és frissítenie kell a profilazonosítókat az ISV-alkalmazás adatbázisában.
Adatok elkülönítése
Ha az adatokat szolgáltatásnév-profilok választják el egymástól, a profil és az ügyfél közötti egyszerű leképezés megakadályozza, hogy egy ügyfél egy másik ügyfél tartalmát lássa. Egyetlen szolgáltatási főfelhasználó használatához szükséges, hogy a szolgáltatási főfelhasználó hozzáférjen az összes profil különböző munkaterületeihez.
Az elkülönítés növelése érdekében rendeljen hozzá egy külön szolgáltatásközponti azonosítót minden bérlőhöz, ahelyett, hogy egyetlen szolgáltatásközponti azonosító több munkaterülethez fér hozzá különböző profilokkal. A különálló szolgáltatásnevek hozzárendelésének számos előnye van, például:
- Az emberi hiba vagy a hitelesítő adatok szivárgása nem teszi lehetővé több bérlő adatainak nyilvánosságra hozását.
- A tanúsítvány rotációja minden bérlő esetében külön végezhető el.
A több szolgáltatásnév használata azonban magas felügyeleti költséggel jár. Csak akkor válassza ezt az elérési utat, ha további elkülönítésre van szüksége. Ne feledje, hogy a végfelhasználók számára megjelenítendő adatok konfigurációja a beágyazási jogkivonat létrehozásakor van meghatározva, amely egy csak háttérbeli folyamat, amelyet a végfelhasználók nem láthatnak vagy módosíthatnak. Egy bérlőspecifikus profillal történő beágyazási jogkivonat kérése létrehoz egy beágyazási jogkivonatot az adott profilhoz, ami lehetővé teszi az ügyfelek elkülönítését a használat során.
Egy jelentés, több szemantikai modell
Bérlőnként általában egy jelentés és egy szemantikai modell van. Ha több száz jelentéssel rendelkezik, több száz szemantikai modellje lesz. Előfordulhat, hogy egy jelentésformátum különböző szemantikai modellekkel (például különböző paraméterekkel vagy kapcsolati adatokkal) rendelkezik. Minden alkalommal, amikor a jelentés új verziójával rendelkezik, frissítenie kell az összes bérlő összes jelentését. Bár ezt automatizálhatja, egyszerűbben kezelhető, ha csak egy példánya van a jelentésnek. Hozzon létre egy munkaterületet, amely tartalmazza a beágyazandó jelentést. A munkamenet során kapcsolja össze a jelentést a bérlőspecifikus szemantikai modellel. További részletekért olvassa el a dinamikus kötéseket .
Tartalom testreszabása és létrehozása
Amikor tartalmat hoz létre, alaposan gondolja át, hogy kinek van engedélye a szerkesztésére. Ha lehetővé teszi, hogy egy bérlőben több felhasználó szerkesszen, könnyen túlléphetik a szemantikai modell korlátait. Ha úgy dönt, hogy szerkesztési képességet ad a felhasználóknak, monitorozza a tartalomlétrehozásukat, és szükség szerint vertikálisan felskálázza őket. Ugyanebből az okból nem javasoljuk, hogy ezt a képességet a tartalom személyre szabásához használja, ahol minden felhasználó elvégezhet kisebb módosításokat egy jelentésen, és mentheti saját maga számára. Ha az ISV-alkalmazás lehetővé teszi a tartalom személyre szabását, fontolja meg a munkaterület adatmegőrzési szabályzatainak bevezetését a felhasználóspecifikus tartalmakhoz. A megőrzési szabályzatok megkönnyítik a tartalom törlését, ha a felhasználók új helyre lépnek, elhagyják a vállalatot, vagy nem használják a platformot.
Rendszer által felügyelt identitás
Szolgáltatásnév helyett egy felhasználó által hozzárendelt vagy rendszer által hozzárendeltfelügyelt identitással hozhat létre profilokat. A felügyelt identitások csökkentik a titkos kódok és tanúsítványok szükségességét.
Legyen óvatos a rendszer által felügyelt identitás használatakor, mert:
- Ha egy rendszer által hozzárendelt felügyelt identitás véletlenül ki van kapcsolva, akkor elveszíti a hozzáférést a profilokhoz. Ez a helyzet hasonló ahhoz az esethez, amikor egy szolgáltatásnevet törölnek.
- A rendszer által hozzárendelt felügyelt identitás egy Azure-beli erőforráshoz (webalkalmazáshoz) csatlakozik. Ha törli az erőforrást, az identitás törlődik.
- Ha több erőforrást használ (különböző webalkalmazásokat különböző régiókban), akkor több identitást kell külön kezelni (mindegyik identitásnak saját profilja lesz).
A fenti szempontok miatt javasoljuk, hogy felhasználó által hozzárendelt felügyelt identitást használjon.
Példa
Ha például szolgáltatásnévprofilokat szeretne használni a több-bérlős környezetek Power BI- és App-Owns-Data-beágyazással való kezelésére, töltse le az alkalmazás tulajdonában lévő több-bérlős adattárat a Power BI Fejlesztői táborból (külső webhelyről).