为 Azure 应用程序配置实例管理访问密钥身份验证
对 Azure 应用程序配置资源的每个请求必须经过身份验证。 默认情况下，可以使用 Microsoft Entra 凭据或使用访问密钥对请求进行身份验证。 在这两种类型的身份验证方案中，Microsoft Entra ID 提供的安全性和易用性要优于访问密钥，并且 Azure AD 是 Microsoft 推荐的身份验证方法。 若要要求客户端使用 Microsoft Entra ID 对请求进行身份验证，可以禁止对 Azure 应用程序配置资源使用访问密钥。 如果要使用访问密钥来对请求进行身份验证，建议定期轮换一次访问密钥，以提高安全性。
启用访问密钥身份验证
访问密钥默认已启用，可以在代码中使用访问密钥来对请求进行身份验证。
若要在 Azure 门户中对 Azure 应用程序配置资源启用访问密钥身份验证，请执行以下步骤：
在 Azure 门户中导航到你的 Azure 应用程序配置资源。
在“设置”下找到“访问设置”设置。
将“启用访问密钥”切换开关设置为“已启用”。
验证是否已启用访问密钥身份验证
若要验证是否启用了访问密钥身份验证，可检查是否可以获取只读和读写访问密钥的列表。 只有启用了访问密钥身份验证，该列表才会存在。
若要在 Azure 门户中检查是否对某个 Azure 应用程序配置资源启用了访问密钥身份验证，请执行以下步骤：
在 Azure 门户中导航到你的 Azure 应用程序配置资源。
在“设置”下找到“访问设置”设置。
检查是否显示了访问密钥，以及是否启用了“启用访问密钥”的切换状态。
禁用访问密钥身份验证
禁用访问密钥身份验证会删除所有访问密钥。 如果任何运行中应用程序正在使用访问密钥进行身份验证，则在禁用访问密钥身份验证后，这些应用程序将开始失败。 只有那些使用 Microsoft Entra ID 完成了身份验证的请求才会成功。 有关使用 Microsoft Entra ID 的详细信息，请参阅使用 Microsoft Entra ID 授权访问 Azure 应用配置。 再次启用访问密钥身份验证会生成一组新的访问密钥，任何尝试使用旧访问密钥的应用程序仍将失败。
警告
如果任何客户端当前正在使用访问密钥访问 Azure 应用程序配置资源中的数据，Azure 建议先将这些客户端迁移到 Microsoft Entra ID，然后再禁用访问密钥身份验证。
若要在 Azure 门户中对 Azure 应用程序配置资源禁用访问密钥身份验证，请执行以下步骤：
在 Azure 门户中导航到你的 Azure 应用程序配置资源。
在“设置”下找到“访问设置”设置。
将“启用访问密钥”切换开关设置为“已禁用” 。
验证是否已禁用访问密钥身份验证
若要验证是否不再允许访问密钥身份验证，可以发出一个请求来列出 Azure 应用程序配置资源的访问密钥。 如果禁用了访问密钥身份验证，则不会列出任何访问密钥，即，列出操作将返回空列表。
若要在 Azure 门户中验证是否对某个 Azure 应用程序配置资源禁用了访问密钥身份验证，请执行以下步骤：
在 Azure 门户中导航到你的 Azure 应用程序配置资源。
在“设置”下找到“访问设置”设置。
检查是否没有显示访问密钥，以及“启用访问密钥”的切换状态是否为关闭。
允许或禁止访问密钥身份验证时所需的权限
若要修改 Azure 应用程序配置资源的访问密钥身份验证状态，用户必须拥有 Azure 应用程序配置资源的创建和管理权限。 提供这些权限的 Azure 基于角色的访问控制 (Azure RBAC) 角色包括 Microsoft.AppConfiguration/configurationStores/write 或Microsoft.AppConfiguration/configurationStores/* 操作。 具有此操作的内置角色包括：
这些角色不提供通过 Microsoft Entra ID 访问 Azure 应用程序配置资源中的数据的权限。 但是，它们包括 Microsoft.AppConfiguration/configurationStores/listKeys/action 操作权限，而此权限可授予对资源访问密钥的访问权限。 有了此权限，用户就可以使用访问密钥来访问该资源中的所有数据。
角色分配的范围必须指定为 Azure 应用程序配置资源级别或更高级别，使用户能够允许或禁止对资源进行访问密钥身份验证。 有关角色作用域的详细信息，请参阅了解 Azure RBAC 的作用域。
请慎重地将这些角色的分配限制为那些需要能够创建应用配置资源或更新其属性的用户。 使用最小特权原则确保用户拥有完成任务所需的最少权限。 有关使用 Azure RBAC 管理访问权限的详细信息，请参阅 Azure RBAC 最佳做法。
注意
经典订阅管理员角色“服务管理员”和“共同管理员”具有 Azure 资源管理器所有者角色的等效权限。 “所有者”角色包括所有操作，因此具有这些管理角色之一的用户也可以创建和管理应用程序配置资源。 有关详细信息，请参阅 Azure 角色、Azure AD 角色和经典订阅管理员角色。
注意
禁用访问密钥身份验证且应用配置存储的 ARM 身份验证模式为本地时，也会禁用在 ARM 模板中读取/写入键-值的功能。 这是因为，访问 ARM 模板中使用的 Microsoft.AppConfiguration/configurationStores/keyValues 资源需要使用本地 ARM 身份验证模式进行访问密钥身份验证。 建议使用直通 ARM 身份验证模式。 有关详细信息，请参阅部署概述。
访问密钥轮换
Azure 建议定期轮换访问密钥，以减轻泄露机密所带来的攻击介质的风险。 每个 Azure 应用配置资源都包含两个只读访问密钥和两个读写访问密钥，分别指定为主密钥和辅助密钥，以方便无缝机密轮换。 此设置使你能够在应用程序中交替访问密钥而不会导致任何故障。
可以使用以下过程轮换密钥：
如果在生产环境中同时使用这两个密钥，请更改代码，确保仅使用一个访问密钥。 在此示例中，假设你决定继续使用商店的主密钥。 代码中必须只有一个密钥，因为重新生成辅助密钥时，旧版本的密钥将立即停止工作，导致使用旧版本密钥的客户端出现 401 访问被拒绝的错误。
一旦主密钥成为唯一使用的密钥，即可重新生成辅助密钥。
接下来，更新你的代码以使用新生成的辅助密钥。 建议检查应用程序日志，以确认在继续下一步之前，应用程序的所有实例都已从使用主密钥转换为使用辅助密钥。
最后，可以通过重新生成主密钥来使原来的主密钥无效。 下次可以通过相同的过程将辅助密钥和主密钥作为访问密钥交替使用。
