A Microsoft SQL Server használata biztonságos módon a Power Apps-szolgáltatással

Többféle módon is kapcsolatba lehet kapcsolódni és hitelesítést végezni az SQL Server felé a Power Apps használatával. A cikk olyan fogalmakat ismertet, amelyek hasznosak lehetnek annak megválasztásában, hogyan kapcsolódhat SQL Server kiszolgálóhoz az alkalmazása követelményeinek megfelelő biztonsági megközelítés segítségével.

Fontos

Ez a cikk az összes relációs adatbázisra és implicit kapcsolatra érvényes.

A explicit és az implicit kapcsolatok közötti különbség

Az SQL Server kiszolgálóhoz minden alkalommal létrejön egy kapcsolat, amikor alkalmazást a Power Apps használatával, amely kapcsolódik SQL-kiszolgálóhoz. Amikor ilyen alkalmazásokat közzétesznek és megosztanak másokkal, az alkalmazást és a kapcsolat is telepítve van az adott felhasználók számára. Más szavakkal, az alkalmazás és a kapcsolat—is látható a felhasználók számára, akikkel meg van osztva.

Az ilyen kapcsolatokhoz használt hitelesítési módszer explicit vagy implicit lehet. Azt is meg lehet mondani, hogy az ilyen kapcsolat explicit vagy implicit módon van megosztva.

• Az explicit módon megosztott kapcsolat azt jelenti, hogy az alkalmazás végfelhasználójának a saját explicit hitelesítő adataival kell hitelesítést végeznie az SQL-kiszolgáló felé. Ez a hitelesítés általában a színfalak mögött történik a Windows-hitelesítési kézfogás részeként Microsoft Entra . A felhasználó észre sem veszi, hogy hitelesítés történik.
• Az implicit módon megosztott kapcsolat azt jelenti, hogy a felhasználó implicit módon az alkalmazáskészítő által az alkalmazás létrehozásakor használt fiók hitelesítő adatait használja a hitelesítéshez az adatforrás felé. A végfelhasználó hitelesítő adatait a rendszer nem használja hitelesítésre. Minden alkalommal, amikor a végfelhasználó futtatja az alkalmazást, a szerző által létrehozott hitelesítő adatokat használja.

A következő négy kapcsolat-hitelesítéstípus használható az SQL kiszolgálóhoz a Power Apps esetében:

Hitelesítési típus	a Power Apps-kapcsolat módszer
Microsoft Entra Integrált	Explicit
SQL-kiszolgáló hitelesítése	Implicit
Windows-hitelesítés	Implicit
Windows-hitelesítés (nem megosztott)	Explicit

Implicit kapcsolatmegosztás kockázatai

Mivel az alkalmazást és a kapcsolatait is telepítik a végfelhasználók számára, ez azt jelenti, hogy a végfelhasználók a kapcsolatok alapján új alkalmazásokat hozhatnak létre.

Tegyük fel például, hogy egy olyan alkalmazást hozott létre, amely kiszűrte az adatokat ,amelyeket nem szeretné, hogy a felhasználók lássanak. A szűrt adatok jelen vannak az adatbázisban. Azonban a beállított szűrőre támaszkodik, hogy a végfelhasználók ne lássanak bizonyos adatokat.

Az alkalmazás telepítése után a végfelhasználók az alkalmazással létrehozott kapcsolatot használhatják bármely új alkalmazásban, amit létrehoznak. Az új alkalmazásokban a felhasználók láthatják az alkalmazásában kiszűrt adatokat.

Fontos

Miután implicit módon megosztott kapcsolatot telepítettek a végfelhasználók számára, az esetlegesen a megosztott alkalmazásban Ön által létrehozott korlátozások (például szűrők vagy csak olvasási hozzáférés) már nem érvényesek az új alkalmazások végfelhasználói számára. A végfelhasználók az implicit módon megosztott kapcsolat részeként minden olyan jogosultságot meg fognak, amit a hitelesítés lehetővé tesz.

Az implicit kapcsolat gyakorlati felhasználása

Az implicit és az explicit hitelesítési módszereknek is vannak gyakorlati felhasználási lehetőségei. Érdemes megfontolni a biztonsági modellt és a fejlesztés egyszerűségét, amikor megközelítést választ. Általános szabályként használjon explicit hitelesítési módszert minden olyan helyzethez, ahol az üzleti követelményei alapján az adatokat sor vagy oszlop alapján kell korlátozni.

Az explicit kapcsolat használatának egy esete például, hogy értékesítési vezető, akinek csak az árengedményeket vagy az alapköltségi adatokat szabad látnia ugyanabban a táblában, amelyben egy másik értékesítési szakembernek a terméket és az árat kell látnia.

Előfordulhat azonban, hogy nem minden adatot azonos módon kell biztosítani. Egy alkalmazás adott felhasználók vagy felhasználócsoportok számára van megosztva és telepítve. Az ezen csoporton kívüli személyek nem férnek hozzá az alkalmazáshoz vagy a kapcsolathoz. Ezért ha egy csoportban mindenki jogosult az összes adat megtekintésére az adatbázisban, az implicit módú megosztás jól működik.

Példa az implicit kapcsolat használati esetére, például egy olyan osztályra, ahol projektek kisebb méretű adatbázisát követik nyomon. Az adatbázis a teljes vállalatra vonatkozó információkat tartalmazhat, például a részlegek munkajegyeit vagy a vállalati naptárat. Ebben az esetben az implicit módon megosztott kapcsolaton további alkalmazások építését érdemes megfontolni, felvéve az összes adatot elérhető lehet az összes felhasználó számára, aki hozzáférést kap.

A Power Apps használatával létrehozott alkalmazásokat úgy tervezték, hogy azok a végfelhasználók számára elérhetőek legyenek. Ez a fajta helyzet azért gyakori, mert az implicit kapcsolatokhoz kapcsolódó fejlesztési költség alacsony.

A részlegalapú alkalmazások nagyvállalati szintű és feladat szempontjából kritikus alkalmazásokká is fejlődhetnek. Ezekben az esetekben fontos megérteni, hogy, ha részlegalapú alkalmazások nagyvállalati szintűre fejlődése esetén hagyományos vállalati biztonságot kell beépíteni. Ez a megközelítés nagyobb terhet jelent az alkalmazásfejlesztés terén, de vállalati méretű helyzetekben fontos.

Ügyfél- és kiszolgálóbiztonság

Nem támaszkodhat az adatok szűrésen vagy más ügyféloldali műveleteken keresztüli biztosítására. Az adatok biztonságos szűrését igénylő alkalmazásoknak gondoskodniuk kell arról, hogy a felhasználó azonosítása és szűrése egyaránt a kiszolgálón történjen.

Használjon olyan szolgáltatásokat, mint az ID, ahelyett, hogy az alkalmazásokban tervezett szűrőkre támaszkodna, Microsoft Entra amikor a felhasználói identitásról és biztonságról van szó. Ez a konfiguráció biztosítja, hogy a kiszolgálóoldali szűrők a várakozások szerint működjenek.

Az alábbi ábra bemutatja, hogy a biztonsági minták miként térnek el az ügyfél- és kiszolgálóoldali biztonsági modellek esetén.

Az ügyfélbiztonsági alkalmazásminta esetén [1] a felhasználó csak az ügyfél oldalán hitelesíti az alkalmazást. Ezután [2] az alkalmazás információkat kér a szolgáltatástól, és [3] a szolgáltatás csak az adatkérésen alapuló adatokat adja eredményül.

A kiszolgálóoldali biztonsági mintában [1] a felhasználó először hitelesít a szolgáltatás felé, hogy a felhasználó ismert legyen a szolgáltatás számára. Ezt követően [2] amikor az alkalmazásból hívás történik, a szolgáltatás [3] az aktuális felhasználó ismert identitásával megfelelően szűri az adatokat, és [4] visszaadja az adatokat.

A fenti implicit részlegszintű megosztási forgatókönyvek az alábbi két minta kombinációjára épülnek. A felhasználónak hitelesítő adatokkal kell bejelentkeznie a Power Apps szolgáltatásba Microsoft Entra . Ez a viselkedés a kiszolgálóbiztonságot használó alkalmazás mintája. A felhasználó a Microsoft Entra szolgáltatás identitása alapján ismert. Az alkalmazás tehát csak arra a felhasználói csoportra korlátozódik, amellyel a Power Apps hivatalosan megosztotta az alkalmazást.

Az SQL kiszolgálóval való implicit megosztott kapcsolat azonban az ügyfél alapú biztonság alkalmazásmintája. Az SQL kiszolgáló csak azt tudja, hogy egy felhasználónevet és jelszót használnak. Bármely ügyféloldali szűrés új alkalmazással megkerülhető ugyanazzal a felhasználónévvel és jelszóval.

Az adatok biztonságos szűréséhez a kiszolgálóoldalon használja az SQL Server beépített biztonsági szolgáltatásait, például sorszintű biztonságot a sorokhoz, valamint az egyes felhasználókra (például oszlopokra) vonatkozó megtagadás engedélyeket. Ez a megközelítés a felhasználói identitást használja a Microsoft Entra kiszolgálón lévő adatok szűrésére.

Egyes meglévő vállalati szolgáltatások olyan megközelítést alkalmaznak, amelyben a felhasználói identitást a rendszer az üzleti adat rétegben ugyanúgy rögzíti, mint ahogy a Microsoft Dataverse. Ebben az esetben az üzleti réteg használhatja az SQL Server sorszintű biztonságát, és közvetlenül tilthat szolgáltatásokat. Ha nem gyakran ez annak a következménye, hogy a biztonság tárolt eljárásokkal vagy nézetekkel van engedélyezve.

Az üzleti réteg (a kiszolgálóoldalon) egy ismert felhasználói Microsoft Entra identitást használ egy tárolt eljárás meghívásához SQL Server rendszerbiztonsági tagként és az adatok szűréséhez. A tárolt eljárásokhoz azonban a Power Apps jelenleg nem kapcsolódik. Az üzleti réteg meghívhat egy olyan nézetet is, amely az Microsoft Entra identitást SQL Server rendszerbiztonsági tagként használja. Ebben az esetben a nézetekhez való kapcsolódáshoz használja Power Apps-t az adatok kiszolgálóoldali szűrés érdekében. Ha csak a nézeteket jelenít meg a felhasználóknak, akkor Power Automate folyamatokra lehet szükség a frissítésekhez.

Kapcsolódó információk

A vászonalkalmazások csatlakozóinak áttekintése