Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Существуют различные способы подключения и проверки подлинности к 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 | Explicit |
| Проверка подлинности SQL Server | Неявные и безопасные неявные |
| Проверка подлинности Windows | Неявные и безопасные неявные |
| Проверка подлинности Windows (не общий доступ) | Explicit |
Риски совместного доступа к неявным подключениям
Все новые приложения автоматически используют новые безопасные неявные подключения. Однако при использовании старых "неявных подключений" приложения и его подключений развертываются для конечных пользователей, это означает, что конечные пользователи могут создавать новые приложения на основе этих подключений.
Если автор использует безопасные неявные подключения, это означает, что подключение не предоставлено, а конечный пользователь не получает объект подключения. Это устраняет риск повторного использования подключения конечным пользователем для создания нового приложения. Вместо этого приложение работает с прокси-подключением, которое знает о приложении и взаимодействует только с этим конкретным приложением. Прокси-подключение позволяет выполнять ограниченные действия (создание, чтение, обновление, удаление) и доступ к определенным таблицам в приложении, определенным при публикации приложения. Поэтому пользователю предоставляются только авторизованные действия и доступ.
Более старый стиль простого неявного подключения фактически распределяет объект подключения для конечного пользователя. Например, если вы создаете приложение, которое фильтрует данные, которые не хотят видеть пользователи. Но отфильтрованные данные присутствуют в базе данных. Но вы полагаетесь на фильтр, настроенный для обеспечения того, чтобы конечные пользователи не видели определенные данные.
Опять же, с более старым стилем простых неявных подключений после развертывания приложения конечные пользователи могут использовать подключение, развернутые с приложением в любых новых приложениях, которые они создают. В новых приложениях пользователи могут просматривать отфильтрованные данные в приложении. Важно использовать новые безопасные неявные подключения.
Это важно
После развертывания более старого неявного общего подключения для конечных пользователей ограничения, которые могут быть установлены в общем приложении (например, фильтрах или доступе только для чтения), больше не допускаются для новых пользователей приложений. Конечные пользователи будут иметь какие-либо права на проверку подлинности в рамках неявного общего подключения. Таким образом, при преобразовании приложения для использования безопасных неявных подключений необходимо также отозвать соединения, к которым вы предоставили доступ. Администраторы могут получить отчет о приложениях с неявно общими подключениями с набором средств COE.
Безопасность клиента и сервера
Вы не можете полагаться на безопасность данных путем фильтрации или других клиентских операций, чтобы быть безопасными. Приложения, требующие безопасной фильтрации данных, должны гарантировать, что на сервере выполняется идентификация пользователей и фильтрация.
Используйте такие службы, как идентификатор Microsoft Entra, вместо того, чтобы полагаться на фильтры, разработанные в приложениях, когда речь идет об удостоверениях пользователей и безопасности. Эта конфигурация гарантирует, что фильтры на стороне сервера работают должным образом.
На следующих иллюстрациях объясняется, как шаблоны безопасности в приложениях отличаются между клиентскими и серверными моделями безопасности.
В шаблоне приложения безопасности клиента [1] пользователь проходит проверку подлинности только в приложении на стороне клиента. Затем [2] приложение запрашивает сведения о службе, а [3] служба возвращает сведения исключительно на основе запроса данных.
В шаблоне безопасности на стороне сервера пользователь сначала проходит проверку подлинности в службе, чтобы пользователь был известен службой. Затем [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.
См. также
Общие сведения о соединителях для приложений на основе холста