没有user_impersonation的Azure资源管理应用编程接口，可能吗？

Question

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

目前，只为management.azure.com列出了一个权限，它是management.azure.com/user_impersonation (预览)。这种委派用户模拟可能是一个严重的问题，并可能导致恶意应用程序接管帐户。

考虑这样一种场景:具有全局管理员角色的用户同意并授权应用程序的访问令牌。应用程序可以使用令牌，并对azure租户做任何它想做的事情。

另一种情况是，特权用户将参与者角色分配给多个订阅。此用户授权的令牌可被应用程序滥用，以修改任何订阅中的资源。

与可以手工选择权限(user.read)的图形(graph.microsoft.com)应用编程接口不同，资源管理应用编程接口只有一个选项- user_impersonation！

你可能会问，为什么特权用户会授权操作，而人们却会犯错。我们的工作是通过设计来阻止或最小化这种风险。那么，让app在azure中管理资源并最小化安全风险的最好方法是什么呢？

Answer 1

感谢@juunas的提纲和技巧。感谢@Gaurav试图回答我的问题。我可以修改订阅上的azure资源，而不必在management.azure.com api上授予user_impersonation权限。以下是步骤-

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

2)添加API权限(可选)。您不需要添加management.azure.com。

​

​

3)转到Azure资源(基于您的需求的订阅、资源组或管理组级别)，并将IAM/RBAC角色添加到已注册的应用程序。我在订阅级别为TestPermissions应用程序分配了贡献者角色。

​

​

4)在client credential grant flow之后请求oauth2访问令牌。您可以在POST请求的主体中提供client_id和client_secret，也可以将其作为授权基本base64编码头提供(这就是我所做的)。保存访问令牌以供将来使用(直到其过期)。

注意:我不能同时添加多个受众(范围)。如果您想为graph api获取一个令牌，您可以通过将范围更改为http://graph.microsoft.com/.default来请求一个单独的令牌

​

​

5)使用上一步捕获的访问令牌与azure资源管理器进行交互。对于每个对https://management.azure.com的请求，您将需要在Authorization header (此处未显示)中添加jwt承载令牌。在本例中，我为我的一个即付即用订阅创建了一个名为TestCreateRG003的新资源组。

​

​

6)让我们验证/验证资源是否已在Azure中创建或更新。答对了，他们来了！应用程序可以读取/修改(基于RBAC) azure资源，而无需授予模拟权限。

​

​

Answer 2

确实，通过授予该权限，您正在允许应用程序以您的身份行事，并拥有所有带来的权限。

我所看到的当需要限制时使用的主要方式是：

• 在您的Azure AD
• 中注册应用程序授予服务主体必要的角色(例如，特定资源上的读者)
• 在应用程序

中设置租户id、客户端id、客户端密钥等

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

Answer 3

让我看看我是否能回答这个问题。

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

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

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