安全地将 Microsoft SQL Server 和 Power Apps 配合使用
使用 Power Apps 连接 到 SQL Server 并向其进行身份验证的方法有多种。 本文概述了可能有助于选择如何使用符合应用要求的安全方法连接到 SQL Server 的概念。
重要
安全隐式连接功能已于 2024 年 1 月发布。 Microsoft 强烈建议当前使用隐式连接的所有应用转换为安全隐式连接并撤销与最终用户共享的连接。
显式、隐式和安全隐式连接之间的区别
每当您使用 Power Apps 创建连接到 SQL Server 的应用时,都会创建到 SQL Server 的连接。 当发布并与其他人共享此类应用时,应用和连接都会部署到这些用户。 换句话说,应用和连接都对与之共享应用的用户可见。
用于此类连接的身份验证方法可以是显式或隐式。 我们也可以说这种连接是显式或隐式共享的。
- 显式共享连接意味着应用程序的最终用户必须使用他们自己的显式凭据向 SQL Server 进行身份验证。 通常,这种身份验证在幕后发生,是 Microsoft Entra 或 Windows 身份验证握手过程的一部分。 用户甚至不会注意到身份验证何时发生。
- 隐式共享连接表示用户隐式使用应用制造商在创建应用期间用于连接以及向数据源进行身份验证的帐户凭据。 最终用户的凭据不用于进行身份验证。 每次最终用户运行应用时,他们都会使用作者创建应用所使用的凭据。
- 安全隐式共享连接是指应用的最终用户隐式使用应用制作者在创建应用时用于连接以及向数据源进行身份验证的帐户凭据的应用场景。 这意味着最终用户自身的凭据不用于进行身份验证。 相反,当用户运行应用时,他们会使用作者创建应用所使用的凭据。 请务必注意,最终用户未获得对连接的直接访问,并且应用仅允许访问一组有限的操作和表。
以下四种连接身份验证类型可与适用于 Power Apps 的 SQL Server 一起使用:
身份验证类型 | Power Apps 连接方法 |
---|---|
Microsoft Entra Integrated | 显式 |
SQL Server 身份验证 | 隐式/安全隐式 |
Windows 身份验证 | 隐式/安全隐式 |
Windows 身份验证(非共享) | 显式 |
隐式连接共享风险
所有新应用程序都会自动使用新安全隐式连接。 但是,在使用较旧“隐式连接”的应用中,向最终用户部署了应用及其连接,这意味着最终用户可以根据这些连接创建新应用。
当作者使用安全隐式连接时,这意味着没有共享任何连接并且没有最终用户接收连接对象。 这会消除最终用户作者重复使用连接创建新应用的风险。 相反,应用与感知应用的代理连接结合使用,并仅与该特定应用通信。 代理连接允许对发布应用时定义的应用中的特定表进行有限操作(创建、读取、更新、删除)和访问。 因此,仅向最终用户授予已授权的操作和访问权限。
旧样式的简单隐式连接实际上会将连接对象分发给最终用户。 例如,如果您创建一个应用,该应用筛选掉您不希望用户看到的数据。 但是,筛选掉的数据存在于数据库中。 但是您依赖于您配置的筛选器来确保最终用户不会看到某些数据。
同样,对于旧样式的简单隐式连接,部署应用后,最终用户可以在他们创建的任何新应用中使用与应用一起部署的连接。 在新应用中,用户可以看到您在应用程序中筛选掉的数据。 使用新安全隐式连接非常重要。
重要
向最终用户部署较旧的隐式共享连接后,您可能在共享的应用中设置的限制(例如筛选器或只读访问权限)对最终用户创建的新应用不再有效。 在进行隐式共享连接的过程中,最终用户将拥有身份验证所允许的任何权限。 因此,当您将应用转换为使用安全隐式连接时,您还必须撤销与应用共享的连接。 管理员可以获取与 COE 工具包进行隐式共享连接的应用报表。
客户端和服务器安全
您不能依靠筛选或其他客户端操作来保证数据的安全性。 需要安全筛选数据的应用程序必须确保用户识别和筛选都发生在服务器上。
在用户标识和安全方面,请使用 Microsoft Entra ID 等服务,而不是依赖应用中设计的筛选器。 此配置可确保服务器端筛选器按预期方式工作。
下图说明了客户端和服务器端安全模型之间应用内的安全模式有何不同。
在客户端安全应用模式中,[1] 用户仅在客户端向应用程序进行身份验证。 然后 [2] 应用程序请求服务的信息,并且 [3] 服务仅根据数据请求返回信息。
在服务器端安全模式中,[1] 用户首先向服务进行身份验证,以便服务知道用户。 然后,[2] 从应用程序中进行调用时,服务 [3] 使用当前用户的已知身份来适当地筛选数据,然后 [4] 返回数据。
上面描述的隐式部门共享方案是这两种模式的组合。 用户必须使用 Microsoft Entra 凭据登录到 Power Apps 服务。 此行为是服务器安全应用模式。 在服务上使用 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 流进行更新。