Използване на Microsoft SQL Server сигурно с Power Apps
Има различни начини за свързване и удостоверяване на SQL Server с Power Apps. Тази статия очертава концепции, които могат да бъдат полезни при избора как да се свържете към SQL Server с подход за защита, който отговаря на изискванията за приложението.
Важно
Функцията за защитени неявни връзки беше пусната през януари 2024 г. Microsoft силно препоръчва всички приложения, които в момента използват неявни връзки, да преобразуват в защитени неявни връзки и да отменят връзките, споделени с крайните потребители.
Разлика между явни, скрити и защитени имплицитни връзки
Връзка към SQL Server се създава всеки път, когато създавате приложение, използващо свързване на Power Apps към SQL Server. Когато такива приложения се публикуват и споделят с други, приложението и връзката се внедряват на тези потребители. С други думи, и приложението, и връзката са видими за потребителите, с които се споделят приложенията.
Методът за удостоверяване, използван за такива връзки, може да бъде явен или неявен. Можем също да кажем, че такава връзка се споделя явно или неявно.
- Явно споделена връзка означава, че крайният потребител на приложението трябва да се удостовери в SQL Server със собствени явни идентификационни данни. Обикновено това удостоверяване се случва зад кулисите като част от Microsoft Entra ръкостискане за удостоверяване на Windows. Потребителят дори не забелязва кога се извършва удостоверяването.
- Неявно споделена връзка означава, че потребителят неявно използва идентификационните данни на акаунта, който производителят на приложения използва, за да се свърже и удостовери с източника на данни по време на създаването на приложението. Идентификационните данни на крайния потребител не се използват за удостоверяване. Всеки път, когато крайният потребител стартира приложението, той използва идентификационните данни, с които авторът е създал приложението.
- Защитената имплицитно споделена връзка се отнася до сценарий, при който крайният потребител на приложението имплицитно използва идентификационните данни на акаунта, който създателят на приложението е използвал за свързване и удостоверяване към източник на данни, докато създава приложението. Това означава, че собствените идентификационни данни на крайния потребител не се използват за удостоверяване. Вместо това, когато потребителят стартира приложението, той използва идентификационните данни, с които авторът на приложението го е създал. Важно е да се отбележи, че на крайния потребител не се предоставя директен достъп до връзката и приложението позволява достъп само до ограничен набор от действия и таблици.
Следните четири типа удостоверяване на връзката могат да се използват със SQL Server за Power Apps:
| Тип удостоверяване | Метод за свързване на Power Apps |
|---|---|
| Microsoft Entra Цялостен | Явно |
| Удостоверяване в SQL Server | Имплицитно / сигурно Имплицитно |
| Удостоверяване в Windows | Имплицитно / сигурно Имплицитно |
| Удостоверяване на Windows (несподелено) | Явно |
Рискове при неявно споделяне на връзка
Всички нови приложения автоматично използват новите защитени неявни връзки. Въпреки това, с приложения, които използват по-старите "имплицитни връзки", както приложението, така и неговите връзки се внедряват за крайни потребители, това означава, че крайните потребители могат да създават нови приложения въз основа на тези връзки.
Когато авторът използва защитени неявни връзки, това означава, че не се споделя връзка и никой краен потребител не получава обекта на връзката. Това елиминира риска авторът на крайния потребител да използва повторно връзка за създаване на ново приложение. Вместо това приложението работи с прокси връзка, която е наясно с приложението и комуникира само с това конкретно приложение. Прокси връзката позволява ограничени действия (създаване, четене, актуализиране, изтриване) и достъп до конкретни таблици в приложението, които са дефинирани при публикуването на приложението. Следователно на крайния потребител се предоставят само разрешени действия и достъп.
Простата имплицитна връзка в по-стария стил всъщност разпределя обект на връзката на крайния потребител. Ако например създадете приложение, което филтрира данните, които не искате потребителите да виждат. Но филтрираните данни присъстват в базата данни. Но разчитате на филтъра, който сте конфигурирали, за да сте сигурни, че крайните потребители няма да виждат определени данни.
Отново, с прости неявни връзки в по-стар стил, след като разположите приложението, крайните потребители могат да използват връзката, разположена с вашето приложение, във всички нови приложения, които създават. В новите приложения потребителите могат да видят данните, които сте филтрирали във вашето приложение. Важно е да използвате новите защитени скрити връзки.
Важно
След като по-стара имплицитно споделена връзка бъде внедрена за крайните потребители, ограниченията, които може да сте поставили в приложението, което сте споделили (като филтри или достъп само за четене), вече не са валидни за новите приложения, създадени от крайните потребители. Крайните потребители ще имат всички права, които удостоверяването позволява като част от неявно споделена връзка. Следователно, когато преобразувате приложение за използване на защитени неявни връзки, трябва също да отмените връзките, които сте споделили с него. Администраторите могат да получат отчет за приложения с имплицитно споделени връзки с инструментариума на COE.
Защита на клиенти и сървъри
Не можете да разчитате защитата на данните чрез филтриране или други операции от страна на клиента да е сигурна. Приложенията, които изискват защитено филтриране на данни, трябва да гарантират, че идентификацията и филтрирането стават на сървъра.
Използвайте услуги като Microsoft Entra ID, вместо да разчитате на филтрите, проектирани в приложенията, когато става въпрос за самоличност и сигурност на потребителя. Тази конфигурация гарантира, че филтрите от страна на сървъра работят според очакванията.
Следващите илюстрации обясняват как моделите на защита в приложенията се различават между моделите на защита от страна на клиента и от страна на сървъра.
В модела на приложение за защита на клиента [1] потребителят се удостоверява в приложението само от страна на клиента. Тогава [2] приложението изисква информация за услугата и [3] услугата връща информацията единствено въз основа на заявката за данни.
В модел на защита от страна на сървъра [1] потребителят първо се удостоверява в услугата, така че потребителят е известен на услугата. Тогава, [2] когато се осъществи извикване от приложението, услугата [3] използва известната самоличност на текущия потребител, за да филтрира данните по подходящ начин, и [4] връща данните.
Описаните по-горе сценарии за неявно споделяне в отдели са комбинация от тези два модела. Потребителят трябва да влезе в услугата Power Apps , като използва Microsoft Entra идентификационни данни. Това поведение е моделът на приложението за защита на сървъра. Потребителят е известен чрез самоличността Microsoft Entra в услугата. Следователно приложението е ограничено до групата потребители, с които Power Apps официално споделя приложението.
Неявната споделена връзка със SQL Server е моделът на приложението за защита на клиента. SQL Server знае само, че се използва конкретно потребителско име и парола. Всяко филтриране от страна на клиента например може да се заобиколи с ново приложение, използващо същото потребителско име и парола.
За да филтрирате сигурно данните от страна на сървъра, използвайте вградени функции за защита в SQL Server, като например защита на ниво ред за редове и отхвърляне на разрешения за конкретни обекти (като колони) за конкретни потребители. Този подход използва самоличността на Microsoft Entra потребителя за филтриране на данните на сървъра.
Някои съществуващи корпоративни услуги са използвали подход, при който самоличността на потребителя се улавя в слоя от бизнес данни по същия начин, както този на Microsoft Dataverse. В този случай бизнес слоят може да използва или да не използва защитата на ниво ред в SQL Server и директно да отказва функции. В противен случай често се случва защитата да се активира чрез съхранени процедури или изгледи.
Бизнес слойът (от страна на сървъра) използва известна потребителска Microsoft Entra самоличност, за да извика съхранена процедура като принципал на SQL Server и да филтрира данните. Въпреки това Power Apps в момента не се свързва със съхранени процедури. Бизнес слой може също да извика изглед, който използва самоличността Microsoft Entra като принципал на SQL Server. В този случай използвайте Power Apps, за да се свържете с изгледите, така че данните да се филтрират от страна на сървъра. Излагането само на изгледи на потребителите може да изисква потоци на Power Automate за актуализации.