安全地将 Microsoft SQL Server 和 Power Apps 配合使用

使用 Power Apps 连接 到 SQL Server 并向其进行身份验证的方法有多种。 本文概述了可能有助于选择如何使用符合应用要求的安全方法连接到 SQL Server 的概念。

重要

本文适用于所有关系数据库以及隐式连接。

显式和隐式连接的区别

每当您使用 Power Apps 创建连接到 SQL Server 的应用时，都会创建到 SQL Server 的连接。 当发布并与其他人共享此类应用时，应用和连接都会部署到这些用户。 换句话说，应用和连接都对与之共享应用的用户可见。

用于此类连接的身份验证方法可以是显式或隐式。 我们也可以说这种连接是显式或隐式共享的。

• 显式共享连接意味着应用程序的最终用户必须使用他们自己的显式凭据向 SQL Server 进行身份验证。 通常，这种身份验证在幕后发生，是 Microsoft Entra 或 Windows 身份验证握手过程的一部分。 用户甚至不会注意到身份验证何时发生。
• 隐式共享连接表示用户隐式使用应用制造商在创建应用期间用于连接以及向数据源进行身份验证的帐户凭据。 最终用户的凭据不用于进行身份验证。 每次最终用户运行应用时，他们都会使用作者创建应用所使用的凭据。

以下四种连接身份验证类型可与适用于 Power Apps 的 SQL Server 一起使用：

身份验证类型	Power Apps 连接方法
Microsoft Entra Integrated	显式
SQL Server 身份验证	隐式
Windows 身份验证	隐式
Windows 身份验证（非共享）	显式

隐式连接共享风险

由于向最终用户部署了应用及其连接都，因此这意味着最终用户可以根据这些连接创建新应用。

例如，假设您创建了一个应用，该应用筛选掉了您不希望用户看到的数据。 筛选掉的数据存在于数据库中。 但是您依赖于您配置的筛选器来确保最终用户不会看到某些数据。

部署此应用后，最终用户可以在他们创建的任何新应用中使用与应用一起部署的连接。 在新应用中，用户可以看到您在应用程序中筛选掉的数据。

重要

向最终用户部署隐式共享连接后，您可能在共享的应用中设置的限制（例如筛选器或只读访问权限）对最终用户创建的新应用不再有效。 在进行隐式共享连接的过程中，最终用户将拥有身份验证所允许的任何权限。

隐式连接的实际使用

存在对隐式和显式身份验证方法都有有效的用例。 在选择您的方法时，请考虑安全模型和开发的便利性。 作为一般规则，对于必须在行或列基础上限制数据的业务需求的任何情况，请使用显式身份验证方法。

对于显式连接用例的示例，考虑一个销售经理，他应该只被允许查看同一表中的价格折扣或基本成本数据，而另一个销售专业人员需要查看产品和价格。

但是，并非需要以相同的方式保护所有数据。 应用被共享并部署到特定用户或用户组。 该组之外的人员无权访问该应用或连接。 因此，如果组中的每个人都被授权查看数据库中的所有数据，那么隐式共享方法非常适用。

对于隐式连接用例的示例，请考虑一个部门，该部门拥有一个他们正在跟踪的项目的小型数据库。 该数据库可能包括诸如部门工单或整个公司的公司日历之类的信息。 在这种情况下，只要获得访问权限的所有用户都可以访问所有数据，就可以鼓励在隐式共享连接之上构建更多应用。

使用 Power Apps 创建的应用旨在让最终用户易于使用。 这种情况很常见，因为与隐式连接相关的开发成本很低。

基于部门的应用可以发展为企业范围的任务关键应用。 在这些方案中，重要的是要了解随着部门应用向企业范围转移，它需要内置传统的企业安全性。 这种方法对于应用构建工作来说成本更高，但在公司范围内的方案中很重要。

客户端和服务器安全

您不能依靠筛选或其他客户端操作来保证数据的安全性。 需要安全筛选数据的应用程序必须确保用户识别和筛选都发生在服务器上。

在用户标识和安全方面，请使用 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 流进行更新。

另请参阅

画布应用的连接器概述