Безпечне використання Microsoft SQL Server з Power Apps
Існує кілька способів підключення до SQL Server та здійснення автентифікації на ньому за допомогою Power Apps. У цій статті описуються поняття, які можуть стати в пригоді під час вибору способу підключення до SQL Server із застосуванням підходу до безпеки, що відповідає вимогам програми.
Важливо
Функція безпечних неявних з’єднань була випущена в січні 2024 року. Корпорація Майкрософт настійно рекомендує всім програмам, які зараз використовують неявні підключення, перейти на безпечні неявні з’єднання та відкликати підключення, надані кінцевим користувачам.
Різниця між явними, неявними та безпечними неявними з’єднаннями
Підключення до 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 не підключається до збережених процедур. Tшар бізнесу також може викликати представлення, яке використовує Microsoft Entra цей профіль як принципал SQL Server. У цьому разі використовуйте Power Apps для підключення до подань, щоб дані фільтрувалися на стороні сервера. Відображення для користувачів тільки подань може вимагати циклів Power Automate для оновлення.