calwong88/entra-conditional-access-framework

# Entra Conditional Access 框架 一个适用于生产环境的 Microsoft Entra ID Conditional Access (CA) 策略框架，在混合身份实验室环境中构建并验证。本仓库记录了分层 Zero Trust 访问模型背后的设计决策、策略配置、验证测试和推出规划。 ## 项目目标 本项目演示了： - 分层 Conditional Access 架构（基线 → 角色 → 基于风险 → 会话控制） - 适用于变更管理和审计的文档规范 - 在生产环境推出前使用 Entra What If 工具进行验证的方法论 - 对策略交互、评估顺序和“拒绝优先”语义的认识 - 运维考量：break-glass 设计、排除模式、推出顺序 ## 实验室环境 - **Tenant:** Microsoft Entra ID (P2 试用版) - **身份模型:** 混合 — 本地 Active Directory 通过 Entra Connect 同步到云 Tenant - **基础设施:** 域控制器、Entra Connect 服务器和托管在本地 Hyper-V 环境中的客户端 VM - **用户群体:** 11 个云和同步用户，按运维角色分组（管理员、最终用户、承包商、高管、IT 支持人员、访客） - **许可证:** 为所有测试用户分配了 Entra ID P2，以启用基于风险的策略、PIM 和 Identity Protection ## 策略框架 策略遵循结构化的命名约定： ``` CA[number]-[scope]-[category]-[action]-v[version] ``` 示例：`CA001-Global-BaseProtection-BlockLegacyAuth-v1.0` 此约定支持随着框架扩展进行可排序、可搜索、可审计的策略管理。 | Policy | Scope | Category | Action | Status | |--------|-------|----------|--------|--------| | CA001 | Global | Base Protection | 阻止传统身份验证 | ✅ 已构建，已验证 | | CA002 | Global | Base Protection | 要求所有用户使用 MFA | ✅ 已构建，已验证 | | CA003 | Global | Location-Based | 阻止高风险国家/地区 | 🔨 进行中 | | CA010 | Admins | Auth Strength | 要求防网络钓鱼的 MFA | ⏳ 计划中 | | CA011 | Guests | Resource Restriction | 阻止访问管理门户 | ⏳ 计划中 | | CA012 | Contractors | Device Trust | 要求设备合规 | ⏳ 计划中 | | CA020 | Global | Risk-Based | 登录风险 MFA | ⏳ 计划中 | | CA021 | Global | Risk-Based | 用户风险密码更改 | ⏳ 计划中 | | CA030 | Admins | Session Control | 登录频率 | ⏳ 计划中 | 每个策略在 `policies/` 目录下都有各自的文档文件，涵盖目的、配置、用户影响、排除项、验证和推出计划。 ## 仓库结构 ``` . ├── README.md # This file ├── policies/ # Per-policy documentation ├── personas/ # User persona model and group design ├── diagrams/ # Architecture and flow diagrams ├── screenshots/ # Supporting validation evidence ├── exports/ # JSON exports of CA policies (policy-as-code) └── LICENSE ``` ## 设计原则 **Break-glass 优先。** 每个策略都排除了指定的紧急访问账户，该账户由专用安全组（`CA-Exclude-BreakGlass`）保护。break-glass 账户没有 MFA 依赖，允许在框架其余部分失效时进行恢复。 **默认为仅报告模式。** 所有策略均以仅报告模式部署，通过登录日志监控意外影响，并在验证后才予以执行。这是 Microsoft 推荐的推出模式，并反映在每个策略的推出计划中。 **基于角色的作用域。** 策略不直接针对“所有用户”，而是通过分配的安全组（`CA-Persona-Admins`、`CA-Persona-Contractors` 等）确定作用域。这创建了明确的、可审计的成员身份，并支持运维中的临时例外工作流。 **纵深防御。** 策略是分层的而非重叠的。CA001（阻止传统身份验证）和 CA002（要求 MFA）协同工作：传统身份验证被 CA001 彻底阻止，而 CA002 要求所有现代身份验证登录使用 MFA。当策略发生冲突时，阻止始终优于授予——这是 CA 评估的核心原则。 ## 遇到的陷阱 实际细节——这些是在构建实验室过程中遇到的问题，仅从文档中看并不明显： - **Entra 中存在五种重叠的 MFA 强制执行机制：** Security Defaults、每用户 MFA（传统）、Conditional Access、Authentication Methods Registration Campaign 和 Identity Protection MFA Registration Policy。禁用其中一个并不会禁用其他的。实验室 break-glass 设置需要禁用或限定所有五种机制的作用域。 - **在新的 Tenant 中，Registration Campaign 默认为“Microsoft 托管”。** 除非明确排除，否则它会提示 break-glass 账户注册 Authenticator。这对于 break-glass 设计来说是一个关键的陷阱。 - **What If 工具的“此策略不适用的原因”输出**是一个强大的验证信号——它不仅确认策略未触发，还确认了未触发的原因（例如，“Client app”不匹配）。在此框架中作为标准验证证据使用。 ## 状态 工作进行中。目前正在实施基线层。预计完成时间：2026 年 5 月 22 日。 ## 作者 Calvin Wong —— 正在攻读 SC-300（Microsoft Identity and Access Administrator）认证，拥有 Azure 管理、云安全（CompTIA Security+）和 IT 服务管理（ITIL 4）背景。目标向 IAM 工程师角色发展。 [[LinkedIn URL](https://www.linkedin.com/in/calvinkmwong/)] · [其他相关链接]

标签：Active Directory, Entra Connect, Homebrew安装, Hyper-V, IAM, Identity Protection, MFA, Microsoft Entra ID, PIM, Plaso, Streamlit, StruQ, Terraform 安全, 企业安全, 变更管理, 基于风险的身份验证, 多因素认证, 安全基线, 实验室环境, 教学环境, 文档规范, 旧版身份验证阻止, 条件访问, 混合身份, 策略框架, 策略部署, 网络安全, 网络资产管理, 访问控制, 身份与访问管理, 隐私保护, 零信任架构