没有 user_impersonation 的 Azure 资源管理 API，可以吗？

Posted 2023-02-16

【中文标题】没有 user_impersonation 的 Azure 资源管理 API，可以吗？

【英文标题】：Azure Resource Management API without user_impersonation, is it possible?

【发布时间】：2020-02-29 04:03:15

【问题描述】：

我正在尝试在 azure 资源管理的上下文中找到有关应用权限的安全最佳实践。

目前，仅针对 management.azure.com 列出了一项权限，它是 management.azure.com/user_impersonation（预览版）。这种委派的用户模拟可能是一个严重的问题，它可能导致恶意应用程序接管帐户。

考虑这样一个场景：具有全局管理员角色的用户同意并授权访问令牌访问应用程序。应用程序可以使用令牌并使用 azure 租户为所欲为。

另一个场景，特权用户将贡献者角色分配给多个订阅。该用户授权的令牌可以被应用滥用来修改任何订阅中的资源。

与您可以手动选择权限 (user.read) 的图形 (graph.microsoft.com) api 不同，资源管理 api 只有一个选项 - user_impersonation！

您可能会争论为什么特权用户会授权该操作，但人们会犯错误。我们的工作是通过设计阻止或最小化此类风险。那么，让应用在 Azure 中管理资源并最大程度降低安全风险的最佳方式是什么？

【参考方案1】：

感谢@juunas 提供大纲和提示。感谢@Gaurav 尝试解决我的问题。我能够修改订阅上的 azure 资源，而无需在 management.azure.com api 上授予 user_impersonation。以下是步骤-

1) 注册一个应用程序（在我的例子中是 TestPermissions）

2) 添加 API 权限（可选）。您无需添加 management.azure.com。

3) 转到 Azure 资源（根据您的要求订阅、资源组或管理组级别）并将 IAM/RBAC 角色添加到已注册的应用程序。我在订阅级别为 TestPermissions 应用分配了 Contributor 角色。

4) 在client credential grant flow 之后请求一个 oauth2 访问令牌。您可以在 POST 请求的正文中提供 client_id 和 client_secret ，也可以将其作为 Authorization Basic base64 编码标头提供（这就是我所做的）。保存访问令牌以备将来使用（直到过期）。

注意：我无法同时添加多个受众（范围）。如果您想获取图形 api 的令牌，可以通过将范围更改为 http://graph.microsoft.com/.default 来请求单独的令牌

5) 使用上一步中捕获的访问令牌与 Azure 资源管理器进行交互。您需要在对https://management.azure.com 的每个请求的授权标头（此处未显示）中添加 jwt 不记名令牌。在此示例中，我正在为我的一个即用即付订阅创建一个名为 TestCreateRG003 的新资源组。

6) 让我们验证/验证资源是否在 Azure 中创建或更新。宾果游戏，他们来了！应用无需授予模拟权限即可读取/修改（基于 RBAC）Azure 资源。

【参考方案2】：

确实，通过授予该权限，您就允许该应用充当您，并拥有所带来的所有权限。

我见过的在需要限制时使用的主要方法是：

在 Azure AD 中注册应用 授予服务主体必要的角色（例如特定资源的读者） 在应用中设置租户ID、客户端ID、客户端密码等

这当然需要应用本身支持这种方法。 如果它只允许通过模拟使用，那么您需要信任或不使用它。

【讨论】：

我喜欢你的建议。您可能指的是不需要用户交互的客户端凭证 oauth2 流程，对吗？我将尝试一下并在这里分享反馈。模仿使工作变得容易，但正如您所提到的，这是一个信任问题以及您可以承担多少风险。

您的建议有效，感谢您的提示。我将在答案部分分享解决方案。再次感谢。

【参考方案3】：

让我看看我能不能回答这个问题。

当用户请求management.azure.com 的令牌时，此时所做的只是用户有权执行 Azure ARM API。这并不意味着他们可以使用 Azure ARM API 做所有可能的事情。

他们能做的事情是由Azure Role Based Access Control (RBAC)控制的。因此，如果用户处于Reader 角色中，则代表用户获得的令牌只能读取有关其 Azure 订阅中资源的信息。不允许他们在其 Azure 订阅中创建、更新或删除资源。

您需要做的是授予用户适当的 RBAC 角色，以最大程度地降低误用风险。

【讨论】：

您好 Gaurav- 感谢您花时间解决这个问题。您在用户的 RBAC 和 RBAC-管理组级别到资源级别的范围上是绝对正确的。我不太关心内置的读者角色。我指的是通常在 Azure AD 中注册应用程序的用户，他们往往是订阅所有者，或者他们是更高特权目录角色的成员，包括全局管理员（众神！）。他们点击精心制作的 url 进行测试或陷入网络钓鱼尝试的祈祷是什么？冒充特权帐户是令人担忧的原因。

同样的事情也可能发生在您的图形 api 示例中，对吧？管理员也可能犯错误。

Gaurav - 是的，它可能发生在任何委派的权限上。同样，如果应用程序可以读取目录信息，我不会太担心。