ScubaGear项目深度解析：Entra Id与PIM中的组嵌套机制研究

摘要

本文深入探讨了微软Entra Id（原Azure AD）及其特权身份管理（PIM）系统中的组嵌套机制。通过实际测试验证了不同类型安全组在常规Entra Id环境和PIM环境下的嵌套行为差异，揭示了权限继承路径中的关键特性与限制。

组类型定义与基础概念

在Entra Id生态系统中，安全组可分为两种核心类型：

1. 可分配角色的安全组（Type 1）：这类组可以直接被赋予Entra Id角色（如SharePoint管理员等特权角色）
2. 不可分配角色的安全组（Type 2）：这类组仅用于常规权限管理，不能直接关联Entra Id角色

特别值得注意的是，PIM组是指那些已被纳入特权身份管理系统的Entra Id组，它们会显示在PIM门户的"管理>组"界面中。

嵌套场景测试结果

经过系统化测试，我们得出以下关键发现：

常规Entra Id环境中的嵌套

• Type 2组嵌套：支持将常规Type 2组嵌套到另一个常规Type 2组中
• Type 1组嵌套：尝试嵌套时会收到明确错误提示："当前不支持对可分配角色的组进行嵌套"

PIM环境中的嵌套行为

1. 常规组→PIM组（合格分配）：

   • 对Type 1和Type 2组均支持
   • 这是Type 1组实现嵌套的唯一途径

2. 常规组→PIM组（活跃分配）：

   • 完全不支持两种类型
   • 触发相同错误提示

3. PIM组→PIM组（合格分配）：

   • 对两种类型均完全支持

4. PIM组→PIM组（活跃分配）：

   • 仅Type 2组支持
   • Type 1组会触发嵌套错误

深度嵌套与权限继承机制

测试证实可以建立最多四层深的组嵌套树结构。特别值得注意的是，即使用户所在的组本身不能直接分配角色（Type 2组），通过PIM的合格分配机制，用户仍可能继承特权角色：

1. 将Type 2组合格分配到已关联特权角色的PIM组
2. 用户成为该Type 2组成员后
3. 通过激活PIM组成员资格
4. 最终获得关联的特权角色访问权限

这种权限继承机制同样适用于深层嵌套结构。例如在"组A→组B→组C"的三层结构中，组C的成员通过激活上层PIM组分配，仍可获取最终的特权访问。

特殊场景：循环引用

测试发现PIM环境中可以创建组间的循环引用：

1. 将PIM组A合格分配到PIM组B
2. 再将PIM组B合格分配到PIM组A

这种结构虽然被系统允许，但在权限分析工具（如ScubaGear）中必须特别处理，避免递归逻辑导致的无限循环问题。

对权限管理工具的影响

基于这些发现，权限分析工具需要：

1. 实现递归组关系解析逻辑
2. 设置合理的递归深度限制（建议至少4层）
3. 特别处理循环引用场景
4. 区分Type 1和Type 2组的嵌套行为差异
5. 同时考虑PIM合格分配和活跃分配的嵌套规则

这些机制的正确实现对于准确识别实际拥有特权访问的用户至关重要，特别是那些通过多层嵌套间接获得权限的用户。

安全建议

1. 定期审计组嵌套结构，特别是PIM环境中的合格分配
2. 对深层嵌套（超过3层）保持特别关注
3. 使用专业工具分析实际权限继承路径
4. 避免创建不必要的循环引用
5. 对Type 2组的PIM分配保持警惕，虽然它们不能直接分配角色，但仍可能成为特权访问的"桥梁"

通过深入理解这些组嵌套机制，组织可以更有效地管理云环境中的特权访问，降低权限滥用的风险。