安全控制：DevOps 安全性

  • 项目

DevOps 安全性涵盖 DevOps 过程中与安全工程和运营相关的控制，包括在部署阶段之前部署关键安全检查（如静态应用安全测试、漏洞管理），以确保整个 DevOps 流程的安全；它还包括常见主题，例如威胁建模和软件供应安全。

DS-1：执行威胁建模

CIS 控制 v8 ID NIST SP 800-53 r4 ID PCI-DSS ID v3.2.1
16.10、16.14 SA-15 6.5、12.2

安全原则：执行威胁建模以识别潜在威胁并枚举缓解控制措施。 确保威胁建模具有以下用途：

  • 在生产运行时阶段保护应用程序和服务。
  • 保护生成工件、基础 CI/CD 管道和其他用于生成、测试和部署的工具环境。 威胁建模至少应包括以下几方面：
  • 定义应用程序的安全要求。 确保在威胁建模中充分满足这些要求。
  • 分析应用程序组件、数据连接及其关系。 确保此分析还包括应用程序范围之外的上游和下游连接。
  • 列出应用程序组件、数据连接以及上游和下游服务可能面临的潜在威胁和攻击途径。
  • 确定可用于缓解枚举威胁的适用安全控制，并识别可能需要制定额外处理计划的任何控制漏洞（例如安全漏洞）。
  • 枚举和设计可以缓解所识别漏洞风险的控制。

Azure 指南：使用威胁建模工具（例如 Microsoft 威胁建模工具）和嵌入的 Azure 威胁模型模板来推动威胁建模过程。 使用 STRIDE 模型枚举内部和外部的威胁，并确定合适的控制。 确保威胁建模过程包括 DevOps 过程中的威胁场景，例如采用错误配置的访问控制策略通过不安全的生成工件存储库注入恶意代码。

如果使用威胁建模工具不适用，则至少应使用基于调查问卷的威胁建模过程来识别威胁。

确保在应用程序或威胁态势发生重大安全影响变化时，记录并更新威胁建模或分析结果。

Azure 实现和其他上下文：

AWS 指南：使用威胁建模工具（例如 Microsoft 威胁建模工具）和嵌入的 Azure 威胁模型模板来推动威胁建模过程。 使用 STRIDE 模型枚举内部和外部的威胁，并确定合适的控制。 确保威胁建模过程包括 DevOps 过程中的威胁场景，例如采用错误配置的访问控制策略通过不安全的生成工件存储库注入恶意代码。

如果使用威胁建模工具不适用，则至少应使用基于调查问卷的威胁建模过程来识别威胁。

确保在应用程序或威胁态势发生重大安全影响变化时，记录并更新威胁建模或分析结果。

AWS 实现和其他上下文：

GCP 指南：使用威胁建模工具（如 Microsoft 威胁建模工具）和嵌入的 Azure 威胁模型模板来推动威胁建模过程。 使用 STRIDE 模型枚举内部和外部的威胁，并确定合适的控制。 确保威胁建模过程包括 DevOps 过程中的威胁场景，例如采用错误配置的访问控制策略通过不安全的生成工件存储库注入恶意代码。

如果使用威胁建模工具不适用，则至少应使用基于调查问卷的威胁建模过程来识别威胁。

确保在应用程序或威胁态势发生重大安全影响变化时，记录并更新威胁建模或分析结果。

GCP 实现和其他上下文：

客户安全利益干系人 (了解) 的详细信息：

DS-2：确保软件供应链安全性

CIS 控制 v8 ID NIST SP 800-53 r4 ID PCI-DSS ID v3.2.1
16.4、16.6、16.11 SA-12、SA-15 6.3、6.5

安全原则：确保企业的 SDLC (软件开发生命周期) 或流程包含一组安全控制，以管理内部和第三方软件组件， (包括应用程序具有依赖项的专有软件) 开源软件。 定义限制条件，防止将易受攻击组件或恶意组件集成和部署到环境中。

软件供应链安全控制至少应包括以下方面：

  • 通过确定服务/资源开发、生成、集成和部署阶段所需的上游依赖项，正确管理软件物料清单 (SBOM) 。
  • 当上游有可用的修补程序时，对内部和第三方软件组件进行盘存和跟踪来发现已知的漏洞。
  • 使用静态和动态应用程序测试评估软件组件中的漏洞和恶意软件，以发现未知的漏洞。
  • 确保使用适当的方法缓解漏洞和恶意软件的威胁。 这可能包括源代码本地修复或上游修复、功能排除和/或应用补偿控制（如果直接缓解不可用）。

如果在生产环境中使用第三方闭源组件，则可能无法看见其安全状况。 应考虑其他控制，例如访问控制、网络隔离和终结点安全性，以便在出现与组件相关的恶意活动或漏洞时将影响降至最低。

Azure 指南：对于 GitHub 平台，请通过以下功能或工具确保软件供应链的安全性GitHub Advanced Security或 GitHub 的本机功能：- 使用 Dependency Graph 通过咨询数据库扫描、清点和识别项目的所有依赖项和相关漏洞。

  • 使用 Dependabot 确保跟踪和修正易受攻击的依赖项，并确保存储库自动与其所依赖的包和应用程序的最新版本保持一致。
  • 在从外部获取代码时，使用 GitHub 的本机代码扫描功能扫描源代码。
  • 使用 Microsoft Defender for Cloud 在 CI/CD 工作流中集成容器映像的漏洞评估。 对于 Azure DevOps，可使用第三方扩展实现类似的控制，用于盘存、分析和修正第三方软件组件及其漏洞。

Azure 实现和其他上下文：

AWS 指南：如果使用 CODECommit 或 CodePipeline 等 AWS CI/CD 平台，请使用 CodeGuru Reviewer 确保软件供应链的安全性，以便通过 CI/CD 工作流扫描源代码 (，) Java 和 Python。 CodeCommit 和 CodePipeline 等平台还支持第三方扩展实现类似的控制，以清点、分析和修正第三方软件组件及其漏洞。

如果通过 GitHub 平台管理源代码，请通过GitHub Advanced Security或 GitHub 的本机功能中的以下功能或工具确保软件供应链的安全性：

  • 通过 Advisory Database 使用依赖项关系图扫描、盘存和识别你项目的所有依赖项和相关漏洞。
  • 使用 Dependabot 确保跟踪和修正易受攻击的依赖项，并确保存储库自动与其所依赖的包和应用程序的最新版本保持一致。
  • 在从外部获取代码时，使用 GitHub 的本机代码扫描功能扫描源代码。
  • 如果适用，请使用 Microsoft Defender for Cloud 在 CI/CD 工作流中集成容器映像的漏洞评估。

AWS 实现和其他上下文：

GCP 指南：使用软件交付盾执行端到端软件供应链安全分析。 这包括保证 OSS (开放源代码软件) 服务，用于访问和合并已由 Google 验证和测试的 OSS 包，以及使用 Google 的安全管道生成的经验证的 Java 和 Python 包。 定期扫描、分析和测试这些包是否存在漏洞。 此类功能可以作为 CI/CD 工作流的一部分集成到 Google Cloud Build、Cloud Deploy、Artifact Registry、Artifact Analysis 中。

如果通过 GitHub 平台管理源代码，请通过GitHub Advanced Security或 GitHub 的本机功能中的以下功能或工具确保软件供应链的安全性：

  • 通过 Advisory Database 使用依赖项关系图扫描、盘存和识别你项目的所有依赖项和相关漏洞。
  • 使用 Dependabot 确保跟踪和修正易受攻击的依赖项，并确保存储库自动与其所依赖的包和应用程序的最新版本保持一致。
  • 在从外部获取代码时，使用 GitHub 的本机代码扫描功能扫描源代码。
  • 如果适用，请使用 Microsoft Defender for Cloud 在 CI/CD 工作流中集成容器映像的漏洞评估。

GCP 实现和其他上下文：

客户安全利益干系人 (了解) 的详细信息：

DS-3：安全 DevOps 基础结构

CIS 控制 v8 ID NIST SP 800-53 r4 ID PCI-DSS ID v3.2.1
16.7 CM-2、CM-6、AC-2、AC-3、AC-6 2.2、6.3、7.1

安全原则：确保 DevOps 基础结构和管道遵循跨环境（包括生成、测试和生产阶段）的安全最佳做法。 这通常包括以下范围的安全控制：

  • 用于存储源代码、生成的包和映像、项目生成工件和业务数据的生成工件存储库。
  • 托管 CI/CD 管道的服务器、服务和工具。
  • CI/CD 管道配置。

Azure 指南：在将 Microsoft 云安全基准应用于 DevOps 基础结构安全控制措施时，确定以下控制措施的优先级：

  • 保护项目和基础环境，确保 CI/CD 管道不会成为插入恶意代码的途径。 例如，查看 CI/CD 管道以识别 Azure DevOps 的核心区域（如组织、项目、用户、管道 (生成 & 发布) 、Connections和生成代理）中的任何错误配置，以识别任何错误配置，例如开放访问、弱身份验证、不安全的连接设置等。 对于 GitHub，请使用类似的控件来保护组织权限级别。
  • 确保 DevOps 基础结构在开发项目中一致地部署。 使用 Microsoft Defender for Cloud (（例如合规性仪表板、Azure Policy、云态势管理) 或你自己的合规性监视工具）大规模跟踪 DevOps 基础结构的合规性。
  • 在管道中配置 Azure AD、本机服务和 CI/CD 工具中的标识/角色权限和权利策略，从而确保对管道的更改已获得授权。
  • 通过使用 Azure 托管标识和实时访问等功能，避免向开发人员或测试人员等人员帐户提供永久的“长期”特权访问。
  • 从 CI/CD 工作流作业中使用的代码和脚本中删除密钥、凭据和机密，并将其保存在密钥存储或 Azure 密钥保管库中。
  • 如果运行自承载生成/部署代理，请遵循 Microsoft 云安全基准控制措施，包括网络安全、态势和漏洞管理以及终结点安全性，以保护环境。

注意：请参阅日志记录和威胁检测、DS-7 以及态势和漏洞管理部分，使用 Azure Monitor 和 Microsoft Sentinel 等服务为 DevOps 基础结构启用治理、合规性、操作审核和风险审核。

Azure 实现和其他上下文：

AWS 指南：在将 Microsoft 云安全基准应用于 DevOps 基础结构（如 GitHub、CodeCommit、CodeArtifact、CodePipeline、CodeBuild 和 CodeDeploy）的安全控制措施时，优先考虑以下控件：

  • 请参阅本指南和 AWS 架构良好的框架安全支柱，以保护 AWS 中的 DevOps 环境。
  • 保护项目和底层支持基础结构，确保 CI/CD 管道不会成为插入恶意代码的途径。
  • 确保在整个开发项目中一致地部署和维持 DevOps 基础结构。 使用 AWS Config 或你自己的合规性检查解决方案大规模跟踪 DevOps 基础结构的合规性。
  • 使用 CodeArtifact 安全地存储和共享用于应用程序开发的软件包。 可以将 CodeArtifact 与常用的生成工具和包管理器（如 Maven、Gradle、npm、yarn、pip 和 twine）配合使用。
  • 在管道中的 AWS IAM、本机服务和 CI/CD 工具中配置标识/角色权限和权限策略，以确保对管道的更改获得授权。
  • 从 CI/CD 工作流作业中使用的代码和脚本中删除密钥、凭据和机密，并将其保存在密钥存储或 AWS KMS 中
  • 如果运行自承载生成/部署代理，请遵循 Microsoft 云安全基准控制措施，包括网络安全、态势和漏洞管理以及终结点安全性，以保护环境。 使用 AWS Inspector 对 EC2 或容器化环境中的漏洞进行漏洞扫描，作为生成环境。

注意：请参阅日志记录和威胁检测、DS-7 以及 和 态势和漏洞管理部分，使用 AWS CloudTrail、CloudWatch 和 Microsoft Sentinel 等服务为 DevOps 基础结构启用治理、合规性、操作审核和风险审核。

AWS 实现和其他上下文：

GCP 指南：在将 Microsoft 云安全基准应用于 DevOps 基础结构安全控制措施时，确定以下控件的优先级：

  • 保护项目和基础环境，确保 CI/CD 管道不会成为插入恶意代码的途径。 例如，查看 CI/CD 管道以识别 Google Cloud Build、Cloud Deploy、Artifact Registry、Connections 和 Build Agent 等服务中的任何错误配置，以识别任何错误配置，例如开放访问、弱身份验证、不安全的连接设置等。 对于 GitHub，请使用类似的控件来保护组织权限级别。
  • 确保 DevOps 基础结构在开发项目中一致地部署。 使用 Google Cloud Security Command Center (大规模跟踪 DevOps 基础结构的合规性，例如合规性仪表板、组织策略、单个威胁记录和识别错误配置) 或你自己的合规性监视工具。
  • 在云标识/AD 本机服务中配置标识/角色权限和权利策略，并在管道中配置 CI/CD 工具，以确保对管道的更改获得授权。
  • 避免使用 Google 托管标识等功能提供对开发人员或测试人员等人工帐户的永久“长期”特权访问。
  • 从 CI/CD 工作流作业中使用的代码和脚本中删除密钥、凭据和机密，并将其保存在密钥存储或 Google 机密管理器中。
  • 如果运行自承载生成/部署代理，请遵循 Microsoft 云安全基准控制措施，包括网络安全、态势和漏洞管理以及终结点安全性，以保护环境。

注意：请参阅日志记录和威胁检测、DS-7 以及态势和漏洞管理部分，使用 Azure Monitor、Microsoft Sentinel 或 Google Cloud 的运营套件等服务以及 Chronicle SIEM 和 SOAR 为 DevOps 基础结构启用治理、合规性、操作审核和风险审核。

GCP 实现和其他上下文：

客户安全利益干系人 (了解) 的详细信息：

DS-4：将静态应用程序安全测试集成到 DevOps 管道

CIS 控制 v8 ID NIST SP 800-53 r4 ID PCI-DSS ID v3.2.1
16.12 SA-11 6.3、6.5

安全原则：确保静态应用程序安全测试 (SAST) 模糊测试、交互式测试、移动应用程序测试是 CI/CD 工作流中的门控控件的一部分。 可根据测试结果设置限制，防止易受攻击的包提交到存储库、生成到包中或部署到生产中。

Azure 指导：将 SAST 集成到管道 (例如，在基础结构即代码模板中) 以便可以在 CI/CD 工作流中自动扫描源代码。 Azure DevOps Pipeline 或 GitHub 可以将以下工具和第三方 SAST 工具集成到工作流中。

  • GitHub CodeQL（用于源代码分析）。
  • Microsoft BinSkim Microsoft BinSkim Binary Analyzer（用于 Windows 和 * nix 二进制分析）。
  • Azure DevOps 凭据扫描程序 (Microsoft 安全 DevOps 扩展) 和 GitHub 本机机密扫描，以在源代码中扫描凭据。

Azure 实现和其他上下文：

AWS 指南：将 SAST 集成到管道中，以便在 CI/CD 工作流中自动扫描源代码。

如果使用 AWS CodeCommit，请使用 AWS CodeGuru Reviewer 进行 Python 和 Java 源代码分析。 AWS Codepipeline 还可以支持将第三部分 SAST 工具集成到代码部署管道中。

如果使用 GitHub，则可以将以下工具和第三方 SAST 工具集成到工作流中。

  • GitHub CodeQL（用于源代码分析）。
  • Microsoft BinSkim Microsoft BinSkim Binary Analyzer（用于 Windows 和 * nix 二进制分析）。
  • GitHub 本机机密扫描，用于在源代码中扫描凭据。
  • 用于 Python 和 Java 源代码分析的 AWS CodeGuru 审阅者。

AWS 实现和其他上下文：

GCP 指南：将 SAST (（如软件交付盾牌、项目分析) ）集成到管道 (例如，在基础结构中将代码模板) 以便可以在 CI/CD 工作流中自动扫描源代码。

云生成、云部署、项目注册表等服务支持与软件交付盾牌和项目分析的集成，后者可以扫描 CI/CD 工作流中的源代码和其他项目。

GCP 实现和其他上下文：

客户安全利益干系人 (了解) 的详细信息：

DS-5：将动态应用程序安全测试集成到 DevOps 管道

CIS 控制 v8 ID NIST SP 800-53 r4 ID PCI-DSS ID v3.2.1
16.12 SA-11 6.3、6.5

安全原则：确保动态应用程序安全测试 (DAST) 是 CI/CD 工作流中门控控件的一部分。 可根据测试结果设置限制，防止漏洞生成到包中或部署到生产中。

Azure 指南：将 DAST 集成到管道中，以便可以在 Azure DevOps 或 GitHub 中的 CI/CD 工作流集中自动测试运行时应用程序。 自动化渗透测试（包含手动辅助验证）也应是 DAST 的一部分。

Azure DevOps 管道或 GitHub 支持将第三方 DAST 工具集成到 CI/CD 工作流中。

Azure 实现和其他上下文：

AWS 指南：将 DAST 集成到管道中，以便可以在 AWS CodePipeline 或 GitHub 中的 CI/CD 工作流集中自动测试运行时应用程序。 自动化渗透测试（包含手动辅助验证）也应是 DAST 的一部分。

AWS CodePipeline 或 GitHub 支持将第三方 DAST 工具集成到 CI/CD 工作流中。

AWS 实现和其他上下文：

GCP 指南：将 DAST (（例如云 Web 安全扫描程序) ）集成到管道中，以便可以在 Google Cloud Build、Cloud Deploy 或 GitHub 等服务中设置的 CI/CD 工作流中自动测试运行时应用程序。 云 Web 安全扫描程序可用于识别托管在应用引擎、Google Kubernetes 引擎 (GKE) 和计算引擎上的工作负载 Web 应用程序中的安全漏洞。 自动化渗透测试（包含手动辅助验证）也应是 DAST 的一部分。

Google Cloud Build、Google Cloud Deploy、Artifact Registry 和 GitHub 还支持将第三方 DAST 工具集成到 CI/CD 工作流中。

GCP 实现和其他上下文：

客户安全利益干系人 (了解) 的详细信息：

DS-6：在整个 DevOps 生命周期内加强工作负载的安全性

CIS 控制 v8 ID NIST SP 800-53 r4 ID PCI-DSS ID v3.2.1
7.5、7.6、7.7、16.1、16.7 CM-2、CM-6、AC-2、AC-3、AC-6 6.1、6.2、6.3

安全原则：确保在开发、测试和部署阶段的整个生命周期内保护工作负载。 使用 Microsoft 云安全基准评估 (控制措施，例如网络安全、标识管理、特权访问等) ，这些控制措施可以默认设置为护栏，或在部署阶段之前左移。 具体而言，请确保在 DevOps 过程中实施以下控制：在 CI/CD 工作流、基础结构管理（基础结构即代码）和测试中使用 Azure 或第三方工具实现部署的自动化，以减少人为错误和攻击面。

  • 确保 VM、容器映像和其他生成工件免受恶意操纵。
  • 在 CI/CD 工作流中进行部署之前，扫描工作负载生成工件（也就是容器映像、依赖项、SAST 和 DAST 扫描）
  • 在生产环境中部署漏洞评估和威胁检测功能，并在运行时持续使用这些功能。

Azure 指南：Azure VM 指南：

  • 使用 Azure 共享映像库共享和控制组织内不同用户、服务主体或 AD 组对映像的访问。 请使用 Azure 基于角色的访问控制 (Azure RBAC) 来确保只有授权用户才能访问自定义映像。
  • 定义 VM 的安全配置基线，以消除不必要的凭据、权限和包。 通过自定义映像、Azure 资源管理器模板和/或Azure Policy来宾配置来部署和强制实施配置基线。

Azure 容器服务指南：

  • 使用 Azure 容器注册表 (ACR) 创建专用容器注册表，其中可以通过 Azure RBAC 限制精细访问，以便只有经过授权的服务和帐户可以访问专用注册表中的容器。
  • 使用 Defender for Containers 对专用Azure 容器注册表中的映像进行漏洞评估。 此外，可以使用 Microsoft Defender for Cloud 将容器映像扫描作为 CI/CD 工作流的一部分集成。

对于 Azure 无服务器服务，请采用类似的控制措施，以确保在部署之前将安全控制“左移”到阶段。

Azure 实现和其他上下文：

AWS 指南：使用 Amazon Elastic Container Registry 共享和控制组织中不同用户和角色对映像的访问。 使用 AWS IAM 确保只有经过授权的用户才能访问自定义映像。

为 EC2 AMI 映像定义安全配置基线，以消除不必要的凭据、权限和包。 通过自定义 AMI 映像、CloudFormation 模板和/或 AWS 配置规则部署和强制实施配置基线。

使用 AWS Inspector 对 VM 和容器化环境进行漏洞扫描，保护它们免受恶意操纵。

对于 AWS 无服务器服务，请将 AWS CodePipeline 与 AWS AppConfig 结合使用，采用类似的控件，以确保安全控制在部署前“左移”到阶段。

AWS 实现和其他上下文：

GCP 指南：Google Cloud 包括用于保护计算资源和 Google Kubernetes Engine (GKE) 容器资源的控件。 Google 包括受防护的 VM，可强化 VM 实例。 它提供启动安全性、监视完整性并使用虚拟受信任的平台模块 (vTPM) 。

使用 Google Cloud Artifact Analysis 扫描容器或 OS 映像中的漏洞，以及按需或自动在管道中自动扫描其他类型的项目。 使用容器威胁检测持续监视 Container-Optimized OS 节点映像的状态。 该服务会评估所有更改和远程访问尝试，以近乎实时地检测运行时攻击。

使用项目注册表设置安全的专用生成项目存储，以控制谁可以使用注册表原生 IAM 角色和权限访问、查看或下载项目，并在 Google 安全可靠的基础结构上获得一致的运行时间。

对于 GCP 无服务器服务，请采用类似的控制措施，以确保在部署之前将安全控制“左移”到阶段。

GCP 实现和其他上下文：

客户安全利益干系人 (了解) 的详细信息：

DS-7：在 DevOps 中启用日志记录和监视

CIS 控制 v8 ID NIST SP 800-53 r4 ID PCI-DSS ID v3.2.1
8.2、8.5、8.9、8.11 AU-3、AU-6、AU-12、SI-4 10.1、10.2、10.3、10.6

安全原则：确保日志记录和监视范围包括 DevOps (中使用的非生产环境和 CI/CD 工作流元素，以及) 的任何其他开发过程。 如果未正确监视生产环境，针对这些环境的漏洞和威胁会给生产环境带来巨大的风险。 还应监视 CI/CD 生成、测试和部署工作流中的事件，以识别 CI/CD 工作流作业中的任何偏差。

Azure 指南：在非生产和 CI/CD 工具环境中启用和配置审核日志记录功能， (Azure DevOps 和 GitHub) 在整个 DevOps 过程中使用。

还应监视从 Azure DevOps 和 GitHub CI/CD 工作流生成的事件，包括生成、测试和部署作业，以识别任何异常结果。

通过日志记录流或 API 将上述日志和事件引入 Microsoft Sentinel 或其他 SIEM 工具，以确保正确监视安全事件并会审以进行处理。

Azure 实现和其他上下文：

AWS 指南：在整个 DevOps 过程中使用 AWS CodePipeline、AWS CodeBuild、AWS CodeDeploy、AWS CodeDeploy、AWS CodeStar) 等非生产和 CI/CD 工具 (环境中启用并配置审核日志记录功能的 AWS CloudTrail。

还应监视从 AWS CI/CD 环境生成的事件 (，例如 AWS CodePipeline、AWS CodeBuild、AWS CodeDeploy、AWS CodeStar) 和 GitHub CI/CD 工作流（包括生成、测试和部署作业），以识别任何异常结果。

通过日志记录流或 API 将上述日志和事件引入 AWS CloudWatch、Microsoft Sentinel 或其他 SIEM 工具，以确保正确监视安全事件并会审以进行处理。

AWS 实现和其他上下文：

GCP 指南：在非生产和 CI/CD 工具环境中为云生成、Google Cloud 部署、项目注册表和 GitHub 等产品启用和配置审核日志记录功能，这些功能可在整个 DevOps 过程中使用。

还应监视从 GCP CI/CD 环境 (生成的事件，例如 Cloud Build、Google Cloud Deploy、Artifact Registry) 和 GitHub CI/CD 工作流（包括生成、测试和部署作业），以识别任何异常结果。

通过日志记录流或 API 将上述日志和事件引入 Microsoft Sentinel、Google Cloud 安全命令中心、Chronicle 或其他 SIEM 工具，以确保正确监视安全事件并会审以便处理。

GCP 实现和其他上下文：

客户安全利益干系人 (了解) 的详细信息：