支柱名称：保护工程系统
模式名称：源代码访问的零信任
Microsoft采用零信任方法来保护其源代码，要求对所有代码更改进行标识验证检查。 关键措施包括针对拉取请求的多重身份验证，以及对生产分支的严格保护，从而减少未经授权的合并风险。
上下文和问题
源代码是任何组织中最有价值的资产之一。 在Microsoft，数以万计的存储库和数百万行代码支撑着全球数十亿美元的服务和产品。 这使得源代码成为攻击者的高价值目标，攻击者可以利用未经授权的访问来注入恶意更改、窃取知识产权或破坏客户信任。
从历史上看，存储库权限和分支策略等保护提供了控制基线。 但是，随着攻击者变得越来越复杂（利用被盗的凭据、自动化和供应链矢量），传统的访问控制已经不够了。 业内的事件表明，单个被入侵的帐户或未经检查的拉取请求如何对数百万用户产生深远影响。
为了应对这一问题，Microsoft实施了一种零信任方法来访问源代码，以帮助确保在没有经过严格、标识验证和可审计的检查之前，任何代码都不会投入生产。
解决方案
Microsoft的方法直接将零信任原则应用于工程系统。 这意味着对源代码的访问以及将更改合并到生产分支的能力需要持续验证、最低特权强制和强大的存在证明。
关键元素包括：
- 拉取请求的状态证明（PoP PR）： PoP PR 在 2024 年引入并跨 61,000 个存储库推出，可确保对受保护分支的每个拉取请求都由使用全新多重身份验证（MFA）验证的真实个人进行身份验证。
- 分层身份验证方法： 根据项目敏感度，工程师使用软件验证器（Windows Hello，人脸 ID）、硬件令牌（FIDO2 YubiKeys）或与安全访问工作站（SAW）关联的生产标识。
-
分支分类和执行：生产分支（
main、、masterdefault）会自动标记和保护，确保在整个企业中统一执行。 - 例外治理： 有限的、经过审查的并可审核的例外豁免（例如，自动化）通过高管批准在软件资产管理系统中进行跟踪。
通过将零信任检查嵌入软件开发生命周期，Microsoft防止未经授权的代码合并，降低特权提升的风险，并增强责任。
Guidance
组织可以使用以下可作的做法采用类似的模式：
| 用例 | 建议的操作 | 资源 |
|---|---|---|
| 条件性访问 | - 创建条件访问策略，要求访问经典部署模型的用户使用多重身份验证（MFA）。 | 要求使用条件访问进行 Azure 管理 MFA |
| 身份验证强度 | - 对高敏感度存储库使用 FIDO2 硬件令牌或安全访问工作站（SAW）绑定标识。 | 在 Microsoft Entra ID 中规划防钓鱼的无密码身份验证部署 |
| 自动化异常 | - 将豁免仅限于无法进行人工审查的情况；在治理系统中跟踪审批。 | 查看组织的审核日志 - GitHub Docs |
| 代码评审严格性 | - 在合并之前，至少需要两名审阅者并强制实施成功的生成策略。 | Git 分支策略和设置 - Azure DevOps |
| 默认安全管道 | - 集成 GitHub 高级安全性，以便进行机密扫描、依赖项管理和代码扫描。 | 关于 GitHub 高级安全性 |
好处
- 更强的供应链复原能力： 防止对生产代码进行未经授权的或自动更改。
- 改进了问责： 每个更改都可以跟踪到具有可审核日志的已验证个人。
- 可扩展保护： 集成到标准化的共享工具和规则集中，可为超过 100,000 名工程师提供尽可能少中断的保护。
折衷权衡
- 开发人员摩擦： 合并点的全新 MFA 可能会增加时间和感知到的不便。
- 基础结构投资： 需要硬件令牌、安全访问工作站（SAW），并与工程平台集成。
- 豁免管理： 自动化方案的治理需要持续监督。
- 采用曲线：团队必须调整工作流程，以适应更严格的执行和分支策略。
关键成功因素
若要跟踪成功，请测量以下内容：
- 受状态证明（PoP）策略保护的生产存储库的百分比。
- 每天完成的经过身份验证的拉取请求数，且未绕过策略。
- 减少未经授权的或异常代码合并尝试。
- 符合异常管理的内部审核要求。
- 工程师满意度和采用指标 与安全强制措施保持平衡。
概要
源代码访问的零信任有助于确保Microsoft最重要的知识产权（其源代码）更好地防范内部威胁、凭据泄露和自动攻击。 通过要求证明存在、强制实施分支分类和缩放零信任保护，Microsoft加强了整个软件供应链。
使用正确的做法，组织可以应用相同的方法：在每个代码合并中强制实施强标识检查，采用 MFA 和硬件支持的身份验证，并维护可审核的治理。 这些措施创建一个可复原的工程系统，用于维护开发人员的工作效率和安全性。
立即采用零信任进行源代码访问，并维护软件开发生命周期的完整性。