mcpField
E
entra-permissions-management

entra-permissions-management

github.com/vinayaklatthe安全17877 次安装19 周前更新
代码仓库

关于 entra-permissions-management

Microsoft Entra Permissions Management 是用于管理多云身份权限的 CIEM 技能,适合希望发现过度授权并落实最小权限的团队。它统一分析 Azure、AWS 和 Google Cloud 中的权限与活动。

主要功能

  1. 01汇总 Azure、AWS 和 Google Cloud 权限
  2. 02按 Permission Creep Index 排序风险
  3. 03依据活动生成最小权限策略
  4. 04提供限时按需权限申请
  5. 05检测异常权限使用

适用场景

  1. 01找出高风险身份并安排整改
  2. 02收紧服务主体和工作负载身份权限
  3. 03为 CI/CD 服务主体生成策略
  4. 04为高权限角色设置临时授权

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/vinayaklatthe/microsoft-security-skills --skill entra-permissions-management

安装后在 Claude Code 中输入/entra-permissions-management确认已加载。

详细介绍

Microsoft Entra Permissions Management

Microsoft Entra Permissions Management 是一种云基础设施权限管理(CIEM)解决方案,可在一个统一视图中查看和控制 Microsoft Azure、AWS 和 Google Cloud 中身份、操作和资源的权限。

适用场景

发现并减少多云环境中过多、未使用和权限过高的云权限,逐步实现最小权限。适用于涵盖多个云的平台;如果只涉及 Azure RBAC,请选择 azure-role-selector。

将目标映射到相应的 CIEM 操作

如果目标是……使用说明
量化每个身份的权限过高程度权限蔓延指数(PCI)0-100;> 65 = 高风险
查找每个身份未使用的权限基于活动的权限调整报告比较 90 天内已授予与实际使用的权限
根据观察到的活动生成最小权限策略自动生成的策略(权限调整)按云中的每个身份生成
临时授予提升的权限按需权限请求基于审批,有时限
检测异常权限使用情况异常检测警报首次出现的操作、大量操作
发现权限过高的工作负载身份非人类身份报告服务主体、IAM 角色、GCP SA

经验法则: 从 PCI > 65 的身份和非人类身份报告入手。 服务主体和机器身份通常是已授予权限与实际使用权限之间差距最大的对象,而且在调整其权限时通常不会有异议。

方法

  1. 接入每个云 — 连接 Azure 订阅(单个或多个)、AWS 账户 (按账户或 AWS Organizations)和 GCP 项目。Permissions Management 通过只读角色收集 权限和活动数据。 验证:每个云账户的数据收集器状态均为绿色;活动事件在 24 小时内开始流入。

  2. 建立 90 天基线 — 不要根据 7 天的活动调整权限。季度业务 周期(月底结账、审计)需要完整覆盖。 验证:开始修正工作前,“数据收集周期”显示 ≥ 90 天。

  3. 按 PCI 排序,先处理前 20 个 — 从 PCI 最高的 20 个身份入手,而不是从未使用权限最长的 列表入手。PCI 按风险排序(已授予权限的范围 + 权限权重), 而不只是按数量排序。 验证:首个冲刺结束后,PCI 排名前 20 的列表累计减少 ≥ 50 分。

  4. 优先处理非人类身份 — 服务主体、AWS IAM 角色、GCP 服务 账户。移除未使用的权限不会引起它们抱怨,而且它们往往是 权限过高最严重的对象。 验证:非人类身份 PCI 分布逐月向左移动(降低)。

  5. 使用自动生成的策略调整权限 — 使用基于活动的策略生成器,而不是手动编写 JSON。审查差异,将策略应用于测试工作负载,然后 再应用于生产环境。

  6. 启用按需权限 — 对于权限很高但很少需要的权限, 将常驻访问权限改为按需请求流程,大幅降低常驻风险。

  7. 监控并发出警报 — 针对首次出现的操作和大量操作启用异常检测。 将警报流式传输到 Sentinel,以便 SOC 进行关联分析。

防护措施

  • 在积极调整权限规模之前,请确认活动基线覆盖了有代表性的时期(至少 90 天)。 少于这个时长会遗漏按季度或仅在月末运行的工作流,并导致服务中断。
  • 先在非生产工作负载中测试。 如果调整后的策略导致 CI/CD 流水线在 02:00 中断,那还不如保留过多权限。
  • 明确处理机器/工作负载身份——它们通常存在最大的未使用权限缺口,而且在调整权限规模时很少会有异议。 优先处理它们。
  • 与工作负载负责人协调整改。 调整服务帐户的权限规模却不通知负责人,会导致服务中断,并削弱他们对计划的信任。
  • 不要调整紧急访问角色的权限规模。 记录这些例外。
  • PCI 衡量的是风险分数,而不是权限数量。 不要只按权限数量比较身份——5 个未使用的高权限胜过 50 个未使用的低权限。

常见反模式

  • “收集 2 周数据后再调整权限规模”——会遗漏月末活动。导致服务中断。
  • “从最容易生成的报告开始”——虽能取得许多小成果,却无法降低风险。按 PCI 排序。
  • “先调整人类用户的权限规模,因为人数更多”——人类用户会反对,非人类身份不会。非人类身份通常拥有最多未使用权限。
  • “将自动生成的策略直接应用到生产环境”——先在工作负载中测试。
  • “数月内每次只接入一个云”——这会失去多云可见性,而这正是整个工作的重点。在同一个冲刺中接入所有云。
  • “只看 PCI 仪表板,不做整改”——只有可见性,没有行动。按月跟踪 PCI 变化量,将其作为关键绩效指标。

示例提示词

  • 将我们的 Azure、AWS 和 GCP 环境接入 Entra Permissions Management。
  • 按 Permission Creep Index 列出排名前 20 的身份,并提出整改顺序。
  • 根据 90 天的活动记录,为我们的 CI/CD 服务主体生成最小权限策略。
  • 找出 PCI > 65 的非人类身份,并调整排名前 5 个的权限规模。
  • 为提升权限的 AWS 角色设置按需权限请求。
  • 将 Permissions Management 异常警报流式传输到 Sentinel。

Microsoft Learn

评论

支持 Markdown