Безопасное использование 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 и фильтрации данных. Тем не менее, Power Apps в настоящее время не подключается к хранимым процедурам. Бизнес-уровень также может вызывать представление, использующее идентификатор Microsoft Entra как субъекта SQL Server. В этом случае используйте Power Apps для подключения к представлениям, чтобы данные фильтровались на стороне сервера. Предоставление пользователям только представлений может потребовать обновление потоков Power Automate.