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
A biztonságos implicit kapcsolatok funkció 2024 januárjában jelent meg. A Microsoft határozottan javasolja az implicit kapcsolatokat jelenleg használó összes alkalmazásnak, hogy konvertáljon biztonságos implicit kapcsolatokra, és vonja vissza a végfelhasználókkal megosztott kapcsolatokat.
Az explicit, implicit és biztonságos 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 biztonságos, implicit módon megosztott kapcsolat olyan forgatókönyvre utal, amelyben az alkalmazás végfelhasználója implicit módon annak a fióknak a hitelesítő adatait használja, amelyet az alkalmazás készítője az alkalmazás létrehozásakor a adatforrás való csatlakozáshoz és hitelesítéshez használt. Ez azt jelenti, hogy a rendszer nem használja a végfelhasználó saját hitelesítő adatait a hitelesítéshez. Ehelyett, amikor a felhasználó futtatja az alkalmazást, azokat a hitelesítő adatokat használja, amelyekkel az alkalmazás szerzője létrehozta azt. Fontos megjegyezni, hogy a végfelhasználó nem kap közvetlen hozzáférést a kapcsolathoz, és az alkalmazás csak korlátozott számú művelethez és táblához biztosít hozzáférést.
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 / Biztonságos implicit |
| Windows-hitelesítés | Implicit / Biztonságos implicit |
| Windows-hitelesítés (nem megosztott) | Explicit |
Implicit kapcsolatmegosztás kockázatai
Minden új alkalmazás automatikusan az új biztonságos implicit kapcsolatokat használja. A régebbi "implicit kapcsolatokat" használó alkalmazások esetében azonban az alkalmazás és annak kapcsolatai is telepítve vannak a végfelhasználók számára, ami azt jelenti, hogy a végfelhasználók új alkalmazásokat hozhatnak létre ezen kapcsolatok alapján.
Ha egy szerző biztonságos implicit kapcsolatokat használ, az azt jelenti, hogy nincs megosztva kapcsolat, és egyetlen végfelhasználó sem kapja meg a kapcsolatobjektumot. Ez kiküszöböli annak kockázatát, hogy a végfelhasználó szerzői újra felhasználják a kapcsolatot egy új alkalmazás létrehozásához. Ehelyett az alkalmazás olyan proxykapcsolattal működik, amely ismeri az alkalmazást, és csak az adott alkalmazással kommunikál. A proxykapcsolat korlátozott műveleteket (létrehozás, olvasás, frissítés, törlés) és hozzáférést biztosít az alkalmazás közzétételekor meghatározott táblákhoz. Ezért a végfelhasználó csak engedélyezett műveleteket és hozzáférést kap.
A régebbi stílusú egyszerű implicit kapcsolat valójában egy kapcsolatobjektumot oszt el a végfelhasználó számára. Ha például olyan alkalmazást hoz létre, amely kiszűri azokat az adatokat, amelyeket nem szeretne, hogy a felhasználók lássanak. A kiszűrt adatok azonban 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.
A régebbi stílusú egyszerű implicit kapcsolatok esetében az alkalmazás üzembe helyezése után a végfelhasználók az alkalmazással üzembe helyezett kapcsolatot bármely újonnan létrehozott alkalmazásban használhatják. Az új alkalmazásokban a felhasználók láthatják az alkalmazásában kiszűrt adatokat. Fontos az új biztonságos implicit kapcsolatok használata.
Fontos
Miután üzembe helyezett egy régebbi, implicit módon megosztott kapcsolatot a végfelhasználók számára, a megosztott alkalmazásban esetleg alkalmazott korlátozások (például szűrők vagy csak olvasási hozzáférés) már nem érvényesek a végfelhasználók által létrehozott új alkalmazásokra. 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. Ezért amikor biztonságos implicit kapcsolatok használatára konvertál egy alkalmazást, az alkalmazással megosztott kapcsolatokat is vissza kell vonnia. A rendszergazdák jelentést kaphatnak az implicit módon megosztott kapcsolatokkal rendelkező alkalmazásokról a COE eszközkészlettel.
Ü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 Microsoft Entra az ID, ahelyett, hogy az alkalmazásokban tervezett szűrőkre támaszkodna, 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 Microsoft Entra felhasználói identitás használatával szűri a kiszolgálón lévő adatokat.
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.