BabsBBG/project-gatekeeper

## 真实背景 Project Gatekeeper 模拟了一场虚构的电信收购案，以及随之而来的所有身份混乱。英国 ISP Helix Communications 收购了 Pulse Networks。一夜之间，身份攻击面扩大了一倍： - 400 多个 Pulse 身份 - 命名不一致，没有离职流程 - 旧账户未启用 MFA - 过期账户和权限过高的用户 - 未管理的承包商和合作伙伴访问权限 - 零检测或自动化响应 我构建了一个完整的身份安全框架来解决这个问题。分为六个阶段，14 条映射到 MITRE ATT&CK 的自定义 KQL 检测规则，10 次带有证据的实时攻击模拟，以及一个能在 **2.42 秒**内遏制受损账户的 SOAR playbook。 | 指标 | 之前 | 之后 | |---|---|---| | MFA 强制执行 | 0% | **100% 通过 CA001** | | 旧版身份验证 | 已启用 | **已阻止 - CA002** | | 特权角色 | 永久 Global Admin | **具有双重审批的 JIT** | | 自定义检测规则 | 无 | **14 条 KQL 规则** | | 事件响应 | 手动 - 数小时 | **SOAR - 不到 3 秒** | | Identity Secure Score | N/A | **32.04%** | ## 架构 ``` ┌------------------------------------------------------------------┐ │ HELIX COMMUNICATIONS TENANT │ │ │ │ ┌------------------┐ ┌----------------------------------┐ │ │ │ PULSE LEGACY │ │ CONDITIONAL ACCESS │ │ │ │ │---▶│ CA001 CA002 CA003 CA004 │ │ │ │ 400+ identities │ │ CA005 CA006 CA007 │ │ │ │ No MFA · Stale │ │ 7 policies · all enforced │ │ │ └------------------┘ └----------------┬-----------------┘ │ │ │ │ │ ┌-------------------┐ ┌---------------▼-----------------┐ │ │ │ PIM GATE │ │ IDENTITY LIFECYCLE │ │ │ │ │ │ │ │ │ │ JIT · 4hr max │ │ Joiner → TAP + Groups + Email │ │ │ │ Dual approval │ │ Mover → Group update + Notify │ │ │ │ Zero standing │ │ Leaver → Disable + Revoke + │ │ │ └-------------------┘ │ Strip + Notify │ │ │ └-----------------------------------┘ │ │ │ │ ┌------------------------------------------------------------┐ │ │ │ ITDR DETECTION LAYER │ │ │ │ Entra ID Protection · 14 KQL Rules · Sentinel │ │ │ └------------------------------┬---------------------------- ┘ │ │ │ High severity incident │ │ ┌------------------------------▼---------------------------- ┐ │ │ │ HLX-SOAR-HighRiskResponse │ │ │ │ Revoke Sessions → Disable Account → HLX-Offboarding │ │ │ │ → Leaver Workflow → SOC Email 2.42 seconds │ │ │ └----------------------------------------------------------- ┘ │ └-------------------------------------------------------------------┘ ``` ## 阶段 1 - 身份基线 **目标：** 了解 Pulse 带来了什么，并在任何旧版身份接触 Helix 环境之前锁定基础。 ### 安全组 七个组：IT Admins、NOC Engineers、Corporate Staff、Field Ops、Break-Glass、PIM Approvers 和 Pulse Legacy Users。HLX-IT-Admins 可分配角色，这是阶段 3 中 PIM 的必要条件。  ### 应急账户 两个账户（`bg-01`、`bg-02`）具有永久的 Global Administrator 权限。凭据离线存储，日常不使用。排除在所有 CA 策略和所有 SOAR 自动化之外。   ### 通过 PowerShell 批量创建用户 使用 Microsoft Graph PowerShell 在一个脚本中创建了 16 个用户。每个 Pulse 旧版账户（以 `pls-` 为前缀）在创建时都带有一个已记录的缺陷：未启用 MFA、账户过期、权限过高或未授权。   ### 许可和身份验证方法 为所有用户分配了 M365 E5 许可证。强化了身份验证方法：启用了 Microsoft Authenticator、FIDO2 和 Temporary Access Pass。禁用了短信和语音通话。  ### SSPR 为所有用户启用了自助密码重置，需要两种方法。   ### Pulse 旧版缺陷修复 - 禁用了 `pls-jakub.kiwior` - 过期账户，自收购完成以来无任何活动 - 移除了 `pls-reiss.nelson` 继承的 AI Reader 和 Directory Readers 角色 - 在任何治理框架之外分配的   ## 阶段 2 - Conditional Access 架构 **目标：** 控制谁可以登录、从哪里登录以及在什么条件下登录，跨越两个具有不同风险状况的合并组织。 ### 命名位置 五个定义网络拓扑的位置。Helix-NOC-Floor 是受信任的。两个 Pulse 位置是已知的但不受信任，它们会产生额外的审查。  ### 七项 CA 策略 | 策略 | 范围 | 控制 | |---|---|---| | CA001 | 所有用户 | 要求 MFA - 应急账户除外 | | CA002 | 所有用户 | 阻止旧版身份验证 (ActiveSync, 其他客户端) | | CA003 | 所有用户 - 高/中登录风险 | 要求 MFA + 每次重新验证 | | CA004 | 所有用户 - 高用户风险 | MFA + 强制密码更改 | | CA005 | HLX-IT-Admins | MFA + 4 小时会话，永不持久化 | | CA006 | 访客/承包商用户 | MFA + 1 小时会话 | | CA007 | Pulse-Partner-Network 位置 | MFA + 2 小时会话 | 所有策略最初都在仅报告模式下启动，一旦环境稳定便转入强制执行模式，这是标准的企业部署实践。      ## 阶段 3 - 特权身份管理 **目标：** 零常设权限。每个管理员角色都是实时激活的，需要提供理由，并在必要时需要 IT Admin 层级之外人员的批准。 ### 角色设置 | 角色 | 最长持续时间 | MFA | 批准 | |---|---|---|---| | Global Administrator | 4 小时 | 必需 | 必需 - HLX-PIM-Approvers | | Security Administrator | 8 小时 | 必需 | 非必需 | | Privileged Role Administrator | 4 小时 | 必需 | 必需 - HLX-PIM-Approvers |  ### 合格分配 Odegaard → Global Admin。Rice → Security Admin。Saliba → Privileged Role Admin。默认情况下均未激活。每次提权都是一个深思熟虑、可审计的行为。  ### 职责分离 HLX-PIM-Approvers 由 Jurrien Timber 和 Kai Havertz 组成，他们是 Corporate 员工，而不是 IT Admins。他们无法批准自己的请求，因为他们根本没有需要批准的请求。   ### 访问审查 Global Administrator 合格分配由 Timber 每月审查。无响应自动移除。  ### 实时激活模拟 Odegaard 请求 Global Admin → Timber 从 IT Admin 层级之外批准。捕获了完整的审计追踪。   ## 阶段 4 - 身份生命周期：JML 工作流 **目标：** 用几秒钟内响应的自动化生命周期工作流取代手动帮助台工单，而不是几天。 ### 入职 触发条件：用户被添加到 `HLX-New-Joiners`。任务：生成 Temporary Access Pass，分配默认组，发送欢迎电子邮件。TAP 允许新用户在没有现有凭据的情况下注册 MFA，打破了原本需要打帮助台电话的循环依赖。   ### 调动 触发条件：部门属性更改。任务：移除以前的组，添加新组，通知经理。   ### 离职 触发条件：用户被添加到 `HLX-Offboarding`。任务：禁用账户，撤销所有会话，移除所有组，剥离许可证，在最后一天之前和当天通知经理。    离职工作流还可作为**紧急遏制触发器**。阶段 6 中的 SOAR playbook 会将受损账户添加到 HLX-Offboarding，立即链接到完整的离职流程。 ## 阶段 5 - ITDR：威胁检测 **目标：** 构建可捕获 Pulse 特定威胁的检测规则，然后用实时证据证明它们有效。 ### 14 条自定义 KQL 规则 - 映射 MITRE ATT&CK 所有 14 条规则均作为 Sentinel 计划分析部署，并在 [`/kql-queries/`](kql-queries/) 中提供。 | 规则 | 威胁 | 严重程度 | 战术 | 技术 | |---|---|---|---|---| | HLX-DETECT-001 | 应急账户访问 | **高** | 初始访问 | T1078 | | HLX-DETECT-002 | 不可能旅行 | **高** | 初始访问 | T1078 | | HLX-DETECT-003 | 密码喷洒 | **高** | 凭据访问 | T1110.003 | | HLX-DETECT-004 | 在 PIM 之外分配角色 | **高** | 权限提升 | T1098.003 | | HLX-DETECT-005 | Pulse 旧版账户活动 | 中 | 初始访问 | T1078.004 | | HLX-DETECT-006 | MFA 疲劳 / 推送轰炸 | 中 | 防御规避 | T1621 | | HLX-DETECT-007 | 迁移后的旧版身份验证 | 中 | 防御规避 | T1550 | | HLX-DETECT-008 | 非工作时间 NOC 访问 | 中 | 初始访问 | T1078 | | HLX-DETECT-009 | 大规模组成员身份更改 | **高** | 权限提升 | T1098.001 | | HLX-DETECT-010 | 绕过离职工作流 | 中 | 防御规避 | T1098 | | HLX-DETECT-011 | 时间窗口外的 PIM 激活 | **高** | 权限提升 | T1078.004 | | HLX-DETECT-012 | Pulse 账户不可能旅行 | **高** | 初始访问 | T1078 | | HLX-DETECT-013 | Pulse伙伴网络异常 | 中 | 初始访问 | T1078 | | HLX-DETECT-014 | 风险告警关联 | **高** | 初始访问 | T1078 |  ### 10 次实时攻击模拟 每次模拟都在 Helix 租户中生成了真实的日志条目。14 条规则中有 12 条捕获了 Advanced Hunting 和 Entra 审计日志证据。 **模拟 1 - 凭据收集**（规则 1、5） 针对所有四个 Pulse 旧版账户启动了攻击模拟训练。真实的网络钓鱼活动 — 记录了真实的登录活动。   **模拟 2 - 密码喷洒**（规则 2） 从同一个浏览器和 IP 手动对四个 Pulse 账户循环进行失败的登录。多次失败尝试，多个目标，短时间窗口，典型的喷洒模式。  **模拟 3 - 在 PIM 之外分配角色**（规则 4） 完全绕过 PIM 直接将 Security Reader 分配给 Pulse 旧版用户。审计日志捕获了该分配。随后立即移除了该角色。  **模拟 4 - 大规模组成员身份更改**（规则 9） 同时向 HLX-IT-Admins 添加了三个用户。审计日志显示了在单个 15 分钟窗口内的批量添加，这正是规则 9 针对的模式。   **模拟 5 - 应急账户访问**（规则 13） 从隐身窗口以 bg-01 身份登录。CA 策略正确显示未应用，应急账户排除生效。Identity Protection 标记了不熟悉的 IP 并中断了流程，但登录最终还是完成了。这是正确的行为，紧急访问绝不能自动阻止。     **模拟 6 - 绕过离职工作流**（规则 10） 直接禁用了 pls-reiss.nelson，而没有先将其添加到 HLX-Offboarding。审计日志显示 AccountEnabled 更改为 false，且之前没有离职组条目。随后尝试登录已禁用的账户，确认出现 50057 错误。   **模拟 7 - MFA 疲劳**（规则 6） 反复以 Bukayo Saka 身份登录，并每次拒绝 MFA 推送。登录日志显示了中断 → 中断 → 中断 → 成功的模式，这正是推送轰炸在日志中的样子。   **模拟 8 - 旧版身份验证**（规则 7） PowerShell 向 Exchange MAPI 端点发送了 Basic Auth HTTP 请求。401 未授权，CA002 在协议层将其阻止。  **模拟 9 - 不可能旅行**（规则 1、12） 在尼日利亚以 pls-oleksandr.zinchenko 身份登录，随后立即通过 VPN 从美国和比利时登录。几分钟内登录了三个国家。登录日志和 Advanced Hunting 均捕获了该模式。  **模拟 10 - PIM 激活异常**（规则 11） Odegaard 激活了 Global Administrator。捕获了带有时间戳的完整 PIM 审计日志，这是规则 11 查询窗口外激活的证据。  **VPN 风险登录**（基线证据 - 规则 1、5） 开启了检测工作的第一次外部 VPN 测试。Identity Protection 标记了登录，CA003 强制执行了 MFA，风险登录仪表板首次被填充。    ## 阶段 6 - 响应自动化与治理 **目标：** 闭环从检测到响应的过程。证明整个系统可以端到端工作。 ### 启用所有 CA 策略 不再有仅报告。所有 7 项策略均已强制执行。  ### 访问审查 Global Admin 每月审查 - Timber 批准了 Odegaard。为外部身份配置了 Pulse 旧版季度审查。   ### 部署 Sentinel 创建了 Log Analytics 工作区。连接了 Entra ID、MDI 和 M365 Defender 数据连接器。所有 14 条 KQL 规则均作为计划分析部署，并具有 MITRE ATT&CK 战术和技术映射。    ### SOAR Playbook：HLX-SOAR-HighRiskResponse **触发器：** HTTP webhook - 实验室实现。生产环境使用 Sentinel 事件自动化规则。 ``` Incident fires │ ▼ Break-glass check - IS break-glass -▶ P1 alert only, no action │ │ NOT break-glass ▼ Sessions revoked (Graph API) │ ▼ Account disabled (Entra ID) │ ▼ Added to HLX-Offboarding │ ▼ Leaver workflow fires — groups, licences, notifications │ ▼ SOC alert email │ ▼ Full containment — 2.42 seconds ```  ### 实时测试 - pls-oleksandr.zinchenko 通过 PowerShell webhook 触发 Playbook。所有步骤在 2.42 秒内执行完毕。     ### 应急账户排除测试 bg-01 提交至 playbook。账户未被触碰。发送了 P1 告警。   ### 最终 Secure Score 在激活完整控制栈后，收购后为 32.04%。该分数反映了将 400 多个 Pulse 账户纳入 MFA 注册计算的结果，随着旧版用户完成注册和控制措施的持续成熟，预计该分数将攀升至 70% 以上。  ## 我吸取的深刻教训 **生命周期工作流需要 Entra ID Governance** - 这是在 E5 之上的一个单独的试用许可证。我激活了免费试用，它立即解锁了。直到你在概览页面遇到 401 错误时才会注意到这一点。 **试用租户中的访问审查** - 尽管分配了正确的许可证且超过 24 小时，My Access 门户有时仍不会为审查者显示 PIM 审查。带有直接链接的电子邮件通知有效。配置是正确的。 **试用工作区中的 Sentinel 实体提取不可靠** - 内置的 Entities - Get Accounts 操作对于分析规则生成和手动创建的事件始终返回空结果。切换到 HTTP webhook 触发器并直接传递 UPN。在具有足够引入历史的生产 Sentinel 工作区中，原生触发器可正常工作。无论触发方法如何，响应链逻辑（撤销、禁用、离职、通知）都得到了充分验证。 ## 复现此项目 ``` # 前提条件：Terraform CLI、Azure CLI、M365 E5 trial tenant az login az account set --subscription "your-subscription" cd terraform terraform init terraform plan terraform apply ``` Terraform 涵盖：所有 Entra ID 组、所有 21 个用户、所有 7 项 CA 策略、所有 5 个命名位置、所有 PIM 合格分配、Log Analytics 工作区、Sentinel 以及作为计划分析的所有 14 条 KQL 分析规则。 通过其他方法部署的资源已记录在 [`/terraform/README.md`](terraform/README.md) 中： - 生命周期工作流 - Entra ID 门户，定义在 [`/scripts/`](scripts/) 中 - Logic Apps SOAR - ARM 模板在 [`/logic-apps/`](logic-apps/) 中 ## 仓库结构 ``` project-gatekeeper/ ├-- Phase 1/ # 15 screenshots ├-- Phase 2/ # 11 screenshots ├-- Phase 3/ # 11 screenshots ├-- Phase 4/ # 7 screenshots ├-- Phase 5/ # 25 screenshots + 10 simulations ├-- Phase 6/ # 14 screenshots ├-- kql-queries/ # 14 KQL detection rules ├-- terraform/ # Full IaC — Entra ID + Azure │ └-- modules/ │ ├-- identity-baseline/ │ ├-- conditional-access/ │ ├-- pim/ │ └-- sentinel/ ├-- scripts/ │ └-- New-GatekeeperUsers.ps1 ├-- logic-apps/ │ └-- hlx-soar-playbook.json └-- README.md ``` ## 认证对齐 | 领域 | 认证 | |---|---| | 在 Microsoft Entra ID 中实施身份 | SC-300 | | 实施身份验证和访问管理 | SC-300 | | 计划和实施身份治理 | SC-300 | | 管理身份和访问 | AZ-500 | | 管理安全运营 | AZ-500 |

标签：ECS, KQL, PB级数据处理, SOAR, Terraform, 安全运维, 微软Entra ID, 身份安全