文章总结： 文章深入分析了Azure云环境中三种高危IAM权限（RoleAssignment/Write、RoleDefinition/Write、FederatedIdentityCredentials/Write）的滥用手法，通过实战演示攻击者如何利用这些权限实现权限提升。核心发现显示单一写入权限即可获取订阅管理权，强调RBAC模型粒度不足的风险。防御建议包括遵循最小权限原则、定期审计角色分配、监控异常行为及建立变更审批流程。 综合评分： 92 文章分类： 云安全,渗透测试,红队,内网渗透,漏洞分析

现在谁说了算？接管Azure身份访问权限的三种手法

幻泉之洲

2026年4月10日 13:00 北京

在小说阅读器读本章

去阅读

在Azure云环境中，三种看似微不足道的IAM权限——角色分配写入、角色定义写入、联合身份凭证写入——可能成为攻击者获取上帝权限的后门。这篇文章带你亲身体验漏洞的威力，并提供防御思路。

我花了些时间深入研究微软Azure的身份和访问管理（IAM）机制。这篇文章会告诉你，几个看似不起眼的IAM权限，在现实环境里能捅出多大的篓子。这些不是理论，是我在实际攻防演练和HackTricks的Azure红队专家课程里亲眼所见的。搞不懂这些权限，你的云环境可能就是纸糊的。

我还会分享我的测试环境搭建过程。这样你自己也可以动手复现一下，看看攻击者是如何利用这些权限，从一个普通账户一步步拿到整个订阅的管理权。

说实话，HackTricks的AzRTE云课程教了我不少硬核技巧，如果你想搞明白云安全攻防，我建议你去看看他们的课。

在云上，IAM管的是“谁”能对“什么资源”执行“哪些操作”。它的核心是基于角色的访问控制。你可以直接用微软预置好的角色，也可以自己动手，定义一个包含特定权限的自定义角色。

下面这三个IAM权限，可以直接在Azure里用来提权：

• RoleAssignment/Write

  ：分配高权限角色。

• RoleDefinition/Write

  ：创建角色并关联权限。

• FederatedIdentityCredentials/Write

  ：创建或更新联合身份凭证。

我做这个实验，就是想让大家看清，一个配置不当或者理解有偏差的角色或权限，会让你的云环境变得多危险。搞清权限能干什么，太重要了。

搭建你的实验战场

在这个演示里，我们要创建几个自定义角色。每个角色只包含一种我们要测试的特定权限。

首先，在Azure里注册个账号，创建一个自己的租户。接着，你得有自己的订阅，然后在里面创建几个用户或服务主体，用来分配权限。

这些都搞定之后，打开：你的订阅 → 进入IAM → 添加一个自定义角色。

接着，创建一个带有你想要的自定义权限的角色。角色名字随便起。

进入权限→ 添加权限 → 找到 microsoft.authorization → 输入你想分配的权限。针对每个用户，依次输入 roleAssignments、roleDefinitions 或 federatedidentitycredentials。然后为它们勾选‘Write’权限。

你还可以把角色分配到特定范围，比如订阅、资源组或管理组。我这里给每个用户都分配了整个订阅范围的权限。

设置完成后，你只需要一个终端，以及对应角色用户的登陆凭证。你可以在订阅 → IAM 处验证。我这里为每个用户单独分配了不同的权限，他们都有各自的自定义角色，就像下面截图中标识的那样。

第一招：RoleAssignment/Write 权限滥用

为了展示攻击者怎么用这个权限，我会滥用 roleassignment/write 来给一个用户分配高权限角色，从而拿到密钥保管库里的秘密，在租户内提升自己的权限。我在自己的虚拟机上，用Azure CLI登陆租户。

az login (交互式登陆) az login -u -p -t (如果没设置MFA可能第一次会失败) az account show (显示当前登陆账户信息)

现在我们以TBrady用户的身份登陆，然后运行命令，列举Azure环境中的角色分配情况。

az role assignment list

我们会找到当前用户的分配记录：

看到了吗？因为我们创建的自定义角色，这个用户的 roleassignment/write 动作权限已经生效了。

为了查看这个具体角色的详细信息，我们运行：

az role definition list –name <我们的自定义角色名>

看定义就知道，这个动作允许该用户向任何资源（比如用户或主体）写入和分配任何角色。

现在，我们来亲自试一下，给自己加点特权！下面的命令会为一个指定用户创建一个角色分配，需要指定作用范围和要分配的角色。

注意：你得知道要分配角色的用户的Principal ID。

az role assignment create –assignee –role –scope

命令执行成功。现在，我们对 IAMTEST-fr 这个密钥保管库拥有了所有者权限。这个例子里我们是给自己加权限，实际上，给别的用户加也是一样的。

第二招：RoleDefinition/Write + RoleAssignment/Write 组合拳

这个权限组合，能让你给受控账户或用户“量身定制”包含过多权限的角色。我演示两种方法：一种是直接修改一个已分配的角色，权限会立刻生效；另一种是创建新角色再分配，但这需要 assignment/write 和 definition/write 两种权限，也就是刚才第一种方法演示过的。

方法一：创建一个全新的角色

我们以FTarkenton用户的身份通过交互式登录。

用下面的命令获取分配信息：

az role assignment list

再用下面的命令获取角色详情，看看它有哪些可执行动作。这个权限和上一个最大的区别是，你可以从零开始创建一个角色，并在某个作用域内分配权限。

然后，我们创建一个能够枚举密钥保管库的角色，并用正确的写入权限（roleassignments/write）把它分配出去。

分配的次生结果输出：

方法二：修改现有自定义角色

在更新角色定义之前，APeterson用户无法访问密钥保管库，他默认被分配了RoleDefinition/Write权限。

现在我们更新这个自定义角色，给它增加额外权限。这一更新会立刻应用到所有已被分配此角色的用户身上。在这个例子里，我们先把角色名导出到变量中。

现在再次查询保管库里的秘密，成功了。由于APeterson本身就被分配了这个角色，角色定义的更新直接在他身上生效了。更新角色定义会影响所有被应用该资源的用户。

第三招：FIC/Write 的隐身攻击

FederatedIdentityCredentials/Write 这个权限，允许攻击者为现有的托管身份添加他们自己的OpenID Connect联合身份凭证。这意味着，攻击者无需窃取密码或证书，就能以那个身份进行身份验证。这个攻击很隐蔽，因为它不涉及窃取机密信息，留下的痕迹也很少。要复现我这个方法，你需要一个GitHub账户和一个用于测试的代码仓库。

初始身份配置。

这是给托管身份分配的读取者角色：

我们首先用BMayfield登陆（稍后会切换到TBrady来分配读取者角色）：

我们列出了身份的更多信息，比如用户分配的托管身份的客户端ID，这个在后续工作流中会用到。

接着，我们为这个托管身份创建联合身份凭证，它将用于向我们的GitHub工作流程进行身份验证。

az identity federated-credential create –name “github-federated-identity” –identity-name testMI –resource-group bialystok-rg –issuer “https://token.actions.githubusercontent.com” –subject “repo:REPO/IAMTEST:ref:refs/heads/main” –audiences “api://AzureADTokenExchange”

然后，把保管库访问策略改成一个自定义策略，让托管身份能访问它。

一旦托管身份在订阅和密钥保管库上都拥有了正确的读取权限……大功告成。运行我们的工作流，就可以从密钥保管库里拿到秘密了。

现在，你就能通过这个被赋予权限的身份，获取秘密和其他所有好东西了。

写在最后：安全不只是配置

看完上面的演示，你觉得这只是配置问题吗？不完全是。

这三个权限本身的破坏力，说明Azure RBAC模型的粒度在某些场景下还是非常粗的。一个只有“写入”角色的权限，就可能打开潘多拉魔盒。

防御这种攻击，没有银弹。我的建议是：

• 遵循最小权限

  ：别给用户不需要的权限，尤其警惕批量分配范围（如整个订阅）的自定义角色。

• 审计是关键

  ：定期拉取并分析 az role assignment list --all 这类清单，重点检查那些拥有 RoleAssignment/Write 和 RoleDefinition/Write 的角色。Azure策略也可以用来限制这些高危权限的分配。

• 监控异常行为

  ：突然的角色分配、新自定义角色创建、联合身份凭证的增加，这些都应该触发告警。

• 流程化变更

  ：像创建自定义角色、分配高权限这类操作，必须要有工单和审批流程，别让工程师自己随手就配了。

说实话，云安全最大的挑战往往就是“便捷性”和“安全性”之间的角力。这些强大的权限让日常管理变得高效，但滥用起来也致命。理解每个权限背后的真实力量，是防御的第一步。希望这篇文章能帮你打开一扇窗，看清楚这些隐藏在控制台背后的风险。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：幻泉之洲 《现在谁说了算？接管Azure身份访问权限的三种手法》