文章总结： 本文详细分析了Azure云环境中三种高危IAM权限（RoleAssignment/Write、RoleDefinition/Write、FederatedIdentityCredentials/Write）的滥用手法，通过实战演示展示攻击者如何利用这些权限从普通账户提升至订阅管理权限。文章提供了完整的实验环境搭建步骤和具体攻击命令，最后给出遵循最小权限、定期审计、监控异常和流程化变更等防御建议。 综合评分： 85 文章分类： 云安全,渗透测试,红队,漏洞分析,安全建设

现在谁说了算？接管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身份访问权限的三种手法》