本文帮助你（作为开发人员）保护开发环境，以便你可以实施 零信任原则 （显式验证，使用最低特权访问，假定违规）。 它提供 安全企业 DevOps 环境 电子书中的内容，并重点介绍了分支安全性和信任工具、扩展和集成的最佳做法。
开发人员效率依赖于你能够根据自己的意愿选择工作方式和地点，以实现业务成果的最大化。 需要具有根或管理员访问权限的强大可自定义计算机。 但是，开发人员需求可能会违反合规性法规，并且需要审核和控制私人员工环境访问和存储。
未管理的计算机连接到组织网络时，会对安全团队、采购部门和治理委员会构成挑战。 为开发人员提供默认和加固的开发环境这种最优情境可能会引起双方的不满。 当员工从任何地方连接时，易受攻击 Wi-Fi 网络是网络攻击的开放大门。 硬件盗窃和丢失是主要问题。
漏洞扩展到开发环境集成。 具有丰富扩展性的开发工具在其市场中可能存在无人维护的集成。 恶意扩展可能会危及开发人员工具并导致公司范围的违规。
在下图中，请注意开发人员环境如何连接到 DevOps 工具环境以影响 Git 分支。 它通过连接到开源包和应用程序扩展来扩大环境图面。 扩展在依赖项和扩展应用程序漏洞中存在漏洞。
为 DevOps 团队成员提供灵活性和控制，同时防止恶意攻击是安全办公室面临的一项根本挑战。 DevOps 可以使用云环境控制开发人员环境（请参阅 Azure VM 和 GitHub Enterprise Cloud Docs的受信任启动），并使用容器保护开发人员环境（请参阅 GitHub Codespaces 文档）。
此外，开发人员还可以实现以下零信任措施来帮助保护开发人员环境：
- 配置最小特权。
- 限制谁可以使用分支安全性更改和批准代码。
- 仅采用受信任的工具、扩展和集成。
最低权限的最佳做法
开发人员通常认为他们可以在其环境中捕获恶意软件、网络钓鱼和漏洞。 大规模开发环境的威胁面使得对于开发人员而言，保持全面的系统知识是不现实的。 组织在攻击入侵拥有管理员访问权限的所有系统的开发人员环境后检测到违规时，会失去宝贵的修正时间。
若要修正导致不良参与者以软件开发人员角色为目标的潜在访问机会，请考虑以下适用于应用的零信任最低特权 安全最佳做法。
- 为 DevOps 实现最低特权和实时访问。 确保团队成员在最短所需的时间内仅保持对环境的最小访问权限。 实施策略以涵盖主要设备上的管理员访问权限、DevOps 工具、发布管道、代码存储库、环境、机密存储和数据库。 对于 DevOps 团队，基本要求是 与组织身份存储的连接。 使用身份联合与 SaaS 环境集成，以避免在非 Microsoft 平台上重复创建身份，并减少暴露风险。
- 不要将个人访问令牌用于源代码访问。 DevOps 团队的安全做法包括访问基于 SaaS 的 DevOps 工具、代码存储库（通过 SSH、HTTPS 或个人访问令牌）。 对于访问SaaS环境，请明确访问原则，说明其如何决定哪些人员可以下载或克隆系统代码存储库，以及从哪些设备（本地、云端和容器）进行操作。 例如，OneDrive 可以阻止或限制 非托管设备访问。
- 使用企业身份对 GitHub Enterprise Managed User （EMU） 用户帐户进行标准化和同步。 使用 企业托管用户，可以通过标识提供者（IdP）控制企业成员的用户帐户。 在组织标识存储中，显式定义 GitHub 用户名、电子邮件和显示名称。 然后，用户可以轻松识别协作者。
- 对于开发人员可以通过以下三种方式连接到 SaaS 环境（通过 HTTPS 使用标识、使用个人访问令牌、使用 SSH 密钥），请与组织身份存储建立连接。 使用 GitHub（除 GitHub EMU 帐户外），您的身份始终是公共的。 通过单一登录（SSO）进行受控访问需要与组织标识存储建立连接。
- 使用 SSH 证书颁发机构（CA）为成员提供已签名的 SSH 证书，以便使用 Git 安全地访问资源。 SSH 证书是一种允许一个 SSH 密钥对另一个 SSH 密钥进行签名的机制。 GitHub Enterprise Cloud 支持 SSH 证书，使组织能够更好地控制成员访问存储库的方式。 管理员可以上传其 SSH CA 公钥，并颁发证书供成员用于 Git 身份验证。 证书只能访问属于组织的存储库。 管理员可以要求成员在访问其存储库时使用证书。
- 使用 Git 凭据管理器强化对代码的访问。 Visual Studio（VS）等工具具有内置 标识支持。 VS Code 依赖于 Git 凭据管理器。
分支安全性的最佳做法
当不良参与者获得对代码存储库的访问权限时，他们可以研究系统安全性并修改代码，而无需团队注意到。 若要防止未经授权的代码存储库访问，请实施 分支策略 来建立对代码更改的控制（请参阅下图所示的示例）。
若要修正潜在的存储库访问机会，请考虑以下分支安全最佳做法。
- 使用代码评审保护分支，使 DevOps 团队能够控制代码更改和审核进展。 上图中的分支策略阐明了一种受控的更改流程，该流程提供了一条清晰的指挥链和蓝图，用于处理代码更改。 在分支策略的不同方法中，一个共同点是受保护的分支充当用于发布到生产环境的新版本的来源。
- 让 Git 存储库的管理员控制审批授权。 分支策略的控制机制位于 审批工作流中。 在接受更改之前，受保护的分支需要验证、评审和审批。 一个选项是创建分支保护规则来强制实施工作流。 例如，对于合并到受保护分支中的所有拉取请求，需要通过审批评审或状态检查。 分支策略 可帮助团队保护重要的开发分支。 这些策略强制实施团队的代码质量和更改管理标准。
信任工具、扩展和集成的最佳做法
集成开发人员环境（IDE）中的可扩展性非常高效，它本质上是一项授权的功能。 依赖于在特定 IDE 市场中应用和策展扩展的功能来设计最佳工作环境。
若要修正安全 IDE，请考虑以下工具、扩展和集成最佳做法。
- 确保仅集成来自受信任平台和发布者的工具。 例如， VS Code 市场 有数千个扩展，让你的生活更加轻松。 但是，当团队采用新工具或扩展时，最重要的方面可以验证发布者的可信度。
- 设置安全做法来控制扩展的使用，以限制开发人员环境的攻击面。 大多数 IDE 扩展都需要批准某些权限才能正常运行，通常作为对系统具有读取权限的文件来分析代码。 扩展需要连接到云环境才能正常运行（在指标工具中很常见）。 在 IDE 上批准额外功能可让组织面临更多威胁。
- 在开发人员计算机上，跟踪已用扩展的数量和成熟度，以了解潜在的攻击面。 仅使用 已验证发布者提供的 VS Code 市场扩展。 使用 VS Code 安装应用程序扩展时，请定期检查使用命令行代码
--list-extensions --show-versions运行的扩展。 充分了解在开发人员环境中运行的可扩展组件。
后续步骤
- 在开发人员工作流中嵌入零信任安全性 有助于快速安全地进行创新。
- 保护 DevOps 平台环境有助于你在 DevOps 平台 环境中实施零信任原则，并重点介绍机密和证书管理的最佳做法。
- 安全用于零信任的 DevOps 环境 描述了使用零信任方法保护 DevOps 环境的最佳做法，用于防止不良参与者破坏开发人员框、使用恶意脚本感染发布管道，以及通过测试环境访问生产数据。
- 使用 Azure DevOps 加速和保护您的代码，通过工具为开发人员提供最快速、最安全的代码到云端的体验。
- 配置 Azure 以信任 GitHub 的 OIDC 作为联邦身份。 OpenID Connect（OIDC）允许 GitHub Actions 工作流 访问 Azure 中的资源，而无需将 Azure 凭据存储为长期存在的 GitHub 机密。