通过

保护开发人员环境以实现零信任

  • 项目

本文帮助开发人员保护开发环境，以便可以实施零信任原则（显式验证、使用最低特权访问权限、假定违规）。 它包含来自我们的保护企业 DevOps 环境电子书的内容，并重点介绍了分支安全和信任工具、扩展和集成的最佳做法。

开发人员的速度依赖于你为实现业务成效最大化采取的工作方式和位置。 需要具有根或管理员访问权限的功能强大、可定制计算机。 但是，开发人员的需求可能与合规性法规，以及审核和控制私人员工环境访问权限和存储的需要相违。

连接到组织网络的非托管计算机对安全团队、采购和治理委员会提出了挑战。 最佳场景是为开发人员提供默认和强化的员工环境，但这种做法会让双方都不屑一顾。 当员工从任何地方进行连接时，易受攻击的 Wi-Fi 网络为网络攻击敞开大门。 硬件盗窃和丢失是主要问题。

漏洞扩展到开发环境集成。 具有丰富扩展性的开发工具在其市场中可能不会保持集成。 恶意扩展可能会危及开发人员工具，并导致公司范围的违规行为。

在下图中，请注意开发人员环境如何连接到 DevOps 工具环境以影响 Git 分支。 它通过连接到开源包和应用程序扩展来扩大环境面。 扩展在依赖项和扩展应用程序漏洞方面存在攻击途径。

关系图演示了上一电子书中所述的开发人员环境和安全威胁，此处链接的相关文章汇总了这些内容。

在为 DevOps 小组成员提供灵活性和控制的同时防止恶意攻击，这是安全办公室面临的根本挑战。 DevOps 可以使用云环境控制开发人员环境（请参阅 Azure VM 的受信任启动 和 GitHub Enterprise Cloud Docs），并使用容器保护开发人员环境（请参阅 GitHub Codespaces 文档）。

此外，开发人员还可以实施这些零信任措施，帮助保护开发人员环境：

  • 配置最低特权。
  • 通过分支安全性来限制可以更改和批准代码的人员。
  • 只采用受信任的工具、扩展和集成。

最低特权的最佳做法

开发人员通常认为可以在其环境中捕获恶意软件、网络钓鱼和漏洞。 庞大的开发人员环境威胁面使开发人员不可能保持无所不在的系统知识。 在攻击行为入侵了管理员有权访问所有系统的开发人员环境后，当组织检测到违规时，就会失去宝贵的修正时间。

若要修正导致黑客以软件开发人员角色为目标的潜在访问机会，请考虑以下零信任最低特权应用安全最佳做法。

  • 为 DevOps 实现最低特权访问和即时访问。 确保小组成员在所需的最短时间内仅保持对环境的最低访问权限。 实施策略,以涵盖主要设备、DevOps 工具、发布管道、代码存储库、环境、机密存储库和数据库上的管理员访问权限。 对于 DevOps 团队，基本要求是连接至组织标识存储区。 使用标识联合身份验证与 SaaS 环境集成，以避免第三方平台上的标识重复并减少暴露风险。
  • 不要将个人访问令牌用于源代码访问。 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 检查正在运行的扩展。 充分了解在开发人员环境中运行的可扩展组件。

后续步骤