可通过不同的方式使用 Power Apps 连接到 SQL Server 并对其进行身份验证。 本文概述了一些概念，这些概念有助于选择如何使用符合应用要求的安全方法连接到 SQL Server。
重要
安全隐式连接功能于 2024 年 1 月发布。 Microsoft强烈建议当前使用隐式连接的所有应用转换为安全隐式连接，并撤销与最终用户共享的连接。
显式连接、隐式连接和安全隐式连接之间的差异
每当使用连接到 SQL Server 的 Power Apps 创建应用时，就会创建到 SQL Server 的连接。 当此类应用发布并与他人共享时，应用和连接将部署到这些用户。 换句话说，应用和连接都对共享应用的用户可见。
用于此类连接的身份验证方法可以是 显式 的或 隐式的。 还可以说此类连接是显式或隐式共享的。
- 显式共享连接意味着应用程序的最终用户必须使用自己的显式凭据向 SQL Server 进行身份验证。 通常，此身份验证在后台作为 Microsoft Entra 或 Windows 身份验证握手的一部分在后台进行。 用户甚至不会注意到身份验证何时进行。
- 隐式共享连接意味着用户在创建应用期间隐式使用应用创建者用来连接和向数据源进行身份验证的帐户的凭据。 最终用户的凭据 不 用于进行身份验证。 每当最终用户运行应用时，他们都会使用作者创建应用的凭据。
- 安全隐式共享连接是指应用最终用户隐式使用应用创建者在创建应用时用于连接和向数据源进行身份验证的帐户凭据的情况。 这意味着最终用户自己的凭据不用于进行身份验证。 相反，当用户运行应用时，他们使用的是创建应用的凭据。 请务必注意，最终用户没有提供对连接的直接访问权限，并且应用仅允许访问一组有限的作和表。
以下四种连接身份验证类型可用于适用于 Power Apps 的 SQL Server：
| 身份验证类型 | Power Apps 连接方法 |
|---|---|
| Microsoft Entra 集成方案 | Explicit |
| SQL Server 身份验证 | 隐式/安全隐式 |
| Windows 身份验证 | 隐式/安全隐式 |
| Windows 身份验证（非共享） | Explicit |
隐式连接共享风险
所有新应用程序都会自动使用新的安全隐式连接。 但是，对于使用较旧的“隐式连接”的应用，应用及其连接都部署到最终用户，这意味着 最终用户可以根据这些连接创作新应用程序。
当作者使用 安全隐式连接时，这意味着没有共享任何连接，也没有最终用户收到连接对象。 这消除了最终用户作者重用连接以创建新应用的风险。 相反，该应用适用于知道应用的代理连接，并且仅与该特定应用通信。 代理连接允许有限的作（创建、读取、更新、删除）以及访问在发布应用时定义的应用中的特定表。 因此，仅向最终用户授予经过授权的作和访问权限。
旧样式的简单隐式连接实际上将连接对象分发给最终用户。 例如，如果创建一个应用来筛选出不希望用户看到的数据。 但是，筛选出的数据存在于数据库中。 但你依赖于配置的筛选器，以确保最终用户看不到特定数据。
同样，在部署应用后，使用旧样式的简单隐式连接，最终用户可以在他们创建的任何新应用中使用与应用一起部署的连接。 在新应用中，用户可以在应用程序中查看筛选出的数据。 使用新的安全隐式连接非常重要。
重要
将较旧的隐式共享连接部署到最终用户后，你可能在共享的应用（如筛选器或只读访问权限）中施加的限制不再对新应用最终用户创建有效。 最终用户将拥有身份验证允许作为隐式共享连接的一部分的任何权限。 因此，将应用转换为使用安全隐式连接时， 还必须 撤销与应用共享的连接。 管理员可以通过 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 流进行更新。