CIS 软件供应链安全指南v1.0(下)

admin 2022年11月1日12:21:09评论24 views字数 8025阅读26分45秒阅读模式


CIS 软件供应链安全指南v1.0(下)                                                     CIS 软件供应链安全指南v1.0(下)

4   制品

       本节包含了对由构建管道产生的制品、以及应用程序在构建过程本身中使用的那些制品管理的安全建议
       制品是软件的打包版本。它们被存储在包注册中心(或制品管理器)中,并且从它们被创建的那一刻起,过程中它们被复制和更新,直到部署相关的环境中持续保证安全。

4.1 验证
       本节包含了管理制品验证的安全建议
       当构建制品被推送到注册中心时,可能会发生许多不同的攻击:可能推送同名的恶意制品,可能通过网络窃取该制品,或者注册中心被黑客攻击,以及其他情况。本部分列举的各种验证方法,对保护制品非常重要。

4.1.1 确保所有的制品都是由构建管道自己签名
描述
       配置构建管道来对它产生的每个制品进行签名,并验证每个制品都有适当的签名。
说明
       加密签名可用于验证制品的真实性。用某个密钥创建的签名唯一且不可逆向,因此对作者来说是唯一的。这意味着使用简单的验证步骤就可以立即发现篡改签名制品的攻击者,因为签名将会改变。通过生成制品的构建管道对制品进行签名,以确保这些制品的完整性。
审计
       验证构建管道为它生成的每个新制品签名,并且为所有制品签名。
补救措施
       使用创建它的构建管道生成的每个制品签名。配置构建管道签名每个制品

4.1.2 确保制品在分发之前加密
描述
       制品分发之前加密制品,并确保只有可信的平台具有解密能力。
说明
       构建制品可能包含敏感数据,例如生产配置。为了保护它们,降低泄露的风险,建议在分发前对它们进行加密。加密使得数据不可读,因此即使攻击者获得了对这些制品的访问权,他们也无法在没有解密密钥的情况下从这些制品中获取敏感数据。
审计
       确保每个制品在交付之前都是加密的。
补救措施
       在分发之前加密每个制品

4.1.3 确保只有授权的平台能够解码制品
描述
       只向受信任和授权的平台授予制品的解密能力。
说明
       构建制品可能包含敏感数据,例如生产配置。为了保护它们并降低泄露的风险,建议在交付前对它们进行加密。这将使每一个没有解密密钥的未经授权的用户无法读取它们。通过实现这一点,防止数据泄漏或盗窃,解密功能变得过于敏感。确保只有受信任和授权的平台才能解密组织的包,降低了攻击者访问制品中的关键数据的可能性。
审计
       确保只有受信任和授权的平台具有组织制品的解密能力。
补救措施
       仅为受信任和授权的平台授予组织制品的解密能力。

4.2  访问制品
       本节包含制品访问管理的安全建议。
       制品通常存储在注册中心中,有些是外部的,有些是内部的。这些注册中心拥有控制访问和权限的用户实体。制品被认为是敏感的,因为它们被交付给客户,并且容易受到许多攻击:数据盗窃、依赖关系混淆、恶意包等等。这就是为什么他们的访问管理应该是严格和谨慎的。

4.2.1 确保认证某些制品的授权因素(factor anthorization)
描述
       软件认证用于验证某些软件使用的安全性,并在供应商和消费者之间建立信任。任何制品都可以被认证。限制特定的授权因素验证制品
说明
       制品认证是建立信任的有力工具。客户端使用软件证书来根据他们的安全策略来验证制品是安全使用的。因此,认证制品被认为是敏感的。如果一个制品是用于调试或内部使用的,或者它被破坏了,组织就不需要认证。攻击者同时获得认证因子和制品注册中心访问权可能能够认证他自己的制品并造成重大破坏。为了防止这些问题,可以限制哪些制品可以通过哪个平台进行认证,这样就可以最小化对证书的访问。
审计
       确保只有特定的制品可以由特定的方式进行认证。
补救措施
       限制哪个因素可以认证哪个制品

4.2.2 确保可以上传新制品的许可用户的数量被最小化
描述
       尽可能少的受信任用户有权上传制品,同时能力最小化。
说明
       制品可能包含敏感数据。即使是最简单的错误也可能导致与客户的信任问题和损害产品的完整性。为了减少这些风险,只允许受信任和合格的用户上传新的制品。这些用户不太可能犯错误。拥有尽可能少的这样的用户数量也将降低用户账户被黑客攻击的风险,这可能导致大规模的入侵或制品泄露。
审计
       确保只有可信和合格的用户可以上传新的制品,并且他们的数量是尽可能少。
补救措施
       只允许可信和合格的用户可以上传新的制品,并限制他们的数量。

4.2.3 确保用户对包注册中心的访问使用多因素身份验证(MFA)
描述
       对用户对包注册中心的访问强制多因素身份验证(MFA)。
说明
       缺省情况下,每个用户只通过密码认证到系统。如果用户的密码被泄露,用户帐户和所有相关的包都有数据被盗和恶意构建的危险。建议每个用户都开启多因素认证功能。这一额外步骤保证了帐户的安全,即使用户的密码被泄露,因为它增加了另一层身份验证。
审计
       对于使用的每个包注册中心,验证强制多因素认证,并且是唯一的认证方式。
补救措施
       对于正在使用的每个包注册中心,强制多因素身份验证作为唯一的身份验证方法。

4.2.4 确保包注册中心的用户不是本地管理
描述
       通过外部认证服务器而不是包注册中心本身来管理用户及其对包注册中心的访问。
说明
       除了组织的主要轻量级目录访问协议(LDAP)或活动目录(AD)服务器之外,一些包注册中心还提供了用于用户管理的工具。工具通常提供简单的身份验证和基于角色的权限,这可能不够细粒度。在组织中拥有多个用户管理工具可能会导致混乱和权限升级,因为将有更多的用户需要管理。为了避免用户升级他们的特权的情况,通过主身份验证服务器管理用户对包注册中心的访问,而不是在包注册中心本地。
审计
       对于每个包注册中心,验证它的用户访问不是由本地管理的,而是由组织的主认证服务器管理的。
补救措施
       对于每个包注册中心,使用组织的主认证服务器进行用户管理,不要进行本地管理。

4.2.5 确保撤销对制品的匿名访问
描述
       禁用对制品的匿名访问。
说明
       大多数制品代码库支持匿名用户,例如JFrog和Nexus。对于未经授权的用户,默认为只有读权限的用户,尽管可以添加更多权限。禁用“匿名用户”查看工件的选项,以保护私有制品不被暴露。这样,只有受信任和授权的成员才能访问制品
       注:只有登录和授权的用户才能访问制品。
审计
       对于正在使用的每个制品或包管理器,验证匿名访问是否被禁用。
补救措施
       在使用的每个制品或包管理器上禁用匿名访问选项。

4.3  包注册中心
       本节包含了对存储制品的包注册中心和制品的管理安全建议。
       包注册中心是存储组织制品的地方。为了保证制品的安全,您必须保证它存储的注册中心的安全。此外,您需要确保到达注册中心的每个制品都是可以安全使用的,并且不会将注册中心置于危险之中。

4.3.1 确保所有上传包注册中心的制品都有签名并得到验证
描述
       验证制品签名,然后再上传到包注册中心。
说明
       加密签名是一种验证制品真实性的工具。每个制品都应该有其创建者的签名,以便在到达客户之前确认它没有被破坏。在交付之前验证制品签名是另一层的保护,它确保签名没有被更改,这意味着没有人尝试或成功篡改制品。这在供应商和客户端之间建立了信任。
审计
       确保包注册中心中的每个制品的签名得到验证。
补救措施
       在将每个制品上传到包注册中心之前,对其进行签名验证。

4.3.2 确保已存在制品的所有版本都验证了它们的签名
描述
       验证已存在制品的所有版本的签名。
说明
       为了确保现有的和可信的制品的版本不是恶意的,或者不是由想要干扰供应链的人交付的,验证每个版本的签名是一个很好的实践。这样做可以降低使用可能导致破坏的受损制品的风险。
审计
       对于每个制品,在上传或使用它之前,确保它的所有版本都经过了签名和验证。
补救措施
       对于每个制品,在上传或使用制品之前,签名并验证每个版本。

4.3.3 确保审核包注册中心配置的变更
描述
       审核包注册中心配置的变更。
说明
       软件包注册中心是软件供应链中的一个关键组成部分。它存储具有潜在敏感数据的制品,这些数据最终将被部署到生产中并使用。必须仔细检查对包注册中心配置所做的每一个更改,以确保注册表的敏感数据不暴露。此检查还确保没有恶意的参与者对存储的工件执行修改。审计配置及其更改有助于降低此类风险。
审计
       验证对包注册中心配置的所有更改都被审计。
补救措施
       审核包注册中心配置的更改。

4.3.4 确保包注册表的webhook是安全的
描述
       使用包注册表的安全webhook。
说明
       webhook用于根据平台中的操作触发HTTP请求。通常,当包接收到更新时,包注册中心会提供webhook功能。因为webhook是一个HTTP POST请求,如果不通过SSL保护,它们可能是畸形的。为了防止潜在的黑客和入侵webhook或接受请求的注册中心或web server,只使用安全的webhook。
审计
       对于每个正在使用的webhook,确保它是安全的(HTTPS)。
补救措施
       对于正在使用的每个webhook,将其更改为安全的(通过HTTPS)。

4.4 起源追溯性
       本节包含了管理制品可追溯性的安全建议。这意味着确保组织和客户都知道这个制品从哪里来,例如一个SBOM,并且还要验证它来自正确的注册中心。

4.4.1 确保制品包含关于它们起源的信息
描述
       当交付制品时,确保它们有关于它们起源的信息。这可以通过提供SBOM或一些元数据文件来完成。
说明
       关于制品起源的信息可以用于验证目的。拥有这种信息允许用户决定提供制品的组织是否可信。在潜在漏洞或版本更新的情况下,这可以用于验证发布它的组织是实际的来源组织,而不是其他人。如果用户需要报告制品的问题,他们也会有一个可以联系的地址。对于每个制品,确保有关它的来源信息。
审计
       对于所提供的每个制品,提供关于其来源信息。
补救措施
       对于正在使用的每个制品,询问有关其来源信息。

4.4.2 确保不允许从外部注册中心拉取私有制品
描述
       代理注册中心如果与一个内部托管注册中心组合,代理注册中心可以将内部包的请求代理到一个公共注册中心。阻止从代理注册中心请求私有包的选项,以便只从托管注册中心拉取私有制品
说明
       当代理注册中心收到拉取私有包的请求时,它会在公共注册中心中查找它们。这可能会导致潜在的名称遮蔽,这意味着如果恶意包与内部包的名称相同,它将因此被拉取,这可能导致大规模的破坏或恶意代码在私有、闭环的环境中运行。为了保护内部环境不受此类事件的影响,建议阻止从代理和公共注册中心提取私有包的选项。
       注:与私有包名称相似的公共包将无法拉取。
审计
       对于正在使用的每个代理注册中心,确保内部包的拉取被阻止。
补救措施
       对于正在使用的每个代理注册中心,阻止提取内部包的选项。

5   部署

       本节包括发布过程、应用程序部署、与之相关的配置和文件管理的安全建议。
       这是软件供应链的最后一个阶段。之后,客户端已经使用了应用程序,并且它正在生产环境中运行。此阶段包含部署协调器、部署配置、清单文件和部署环境。为了将软件安全地交付给客户,确保所有这些安全是很重要的。

5.1部署配置
       本节包括管理部署配置的安全建议。这包括部署配置的文件、指令和访问管理。通常情况下,配置文件存储在版本控制系统中,因此也需要保护。

5.1.1 确保部署配置文件与源代码分离
描述
       部署配置文件通常存储在版本控制系统中。将部署配置文件与源代码存储库分离。
说明
       部署配置清单通常存储在版本控制系统中。将它们独立于源代码库存储在专门的存储库中有几个好处。首先,它为维护和版本控制历史记录添加了顺序。这使得跟踪代码或显示更改更容易,以及发现任何恶意代码或错误配置。第二,它有助于实现“最小特权原则”。因为可以为每个代码库配置不同的访问权限,所以很少有用户可以访问这种配置,这通常是敏感的。
审计
       确保每个部署配置文件与源代码分开存储。
补救措施
       每个部署配置文件与源代码分别存储在一个专用的代码库中。

5.1.2 确保跟踪部署配置的更改
描述
       审计并跟踪部署配置中的更改。
说明
       部署配置本质上是敏感的。最微小的错误都可能导致生产中的停机或bug,从而可能对产品的完整性和客户信任产生直接影响。错误配置也可能被恶意行为者用来攻击生产平台。正因为如此,配置中的每一个更改都需要检查,并且可能在错误或恶意更改的情况下“恢复”。 审计每个更改并跟踪它们有助于更快地检测和修复此类事件。
审计
       对于每个部署配置,确保对其所做的更改进行审计和跟踪。
补救措施
       对于每个部署配置,跟踪和审计所做的更改。

5.1.3确保扫描设备已到位,以识别和防止部署配置中的敏感数据
描述
       检测和防止敏感数据,如机密身份证号,密码等。
说明
       如果攻击者获得了对部署配置中的敏感数据的访问权,则可能会造成重大事件,因为这可能导致数据丢失和盗窃。重要的是要保证敏感数据的安全,不要在配置中公开它。为了防止可能的泄露,请在部署配置中设置识别和防止此类数据的扫描器。
审计
       对于每个部署配置文件,验证设置扫描器为识别和防止其中敏感数据的存在。
补救措施
       对于每个部署配置文件,设置扫描器以识别和防止其中的敏感数据。

5.1.4 确保部署配置的访问权限仅限于特定的成员
描述
       将部署配置的访问权限限制为仅可信任和合格的用户。
说明
       部署配置本质上是敏感的。最小的错误都可能导致生产停工或bug,这对产品的完整性和客户信任有直接影响。错误配置也可能被恶意行为者用来攻击生产平台。为了尽可能避免这种伤害,请确保只有受信任和合格的用户才能访问这些配置。这也将减少在攻击发生时可能影响环境的帐户数量。
       注:减少能够访问部署配置的用户数量意味着这些用户将失去直接更改配置的能力。
审计
       验证每个部署配置只有已知和授权的用户才能访问。
补救措施
       限制只有受信任和合格的用户才能访问部署配置。

5.1.5 确保扫描器已到位,以保护基础设施即代码(IaC)指令的安全
描述
       检测和防止基础设施即代码(IaC)文件中的错误配置或不安全指令,如terrraform文件。
说明
       基础设施即代码 (IaC)文件用于生产环境和应用程序部署。这些是软件供应链的敏感部分,因为它们总是与客户保持关联,因此可能会影响他们对产品的意见或信任。攻击者通常以这些环境为目标。检测和修复IaC文件中的错误配置和/或不安全指令降低了数据泄漏或数据盗窃的风险。保护IaC指令是很重要的,以防止部署、暴露资产或不适当配置的进一步问题,这些问题最终可能导致更容易的攻击和窃取组织数据的方法。
审计
       对于每个基础设施即代码(IaC)指令文件,验证扫描器设置为识别和防止错误配置和不安全指令。
补救措施
       对于每个基础设施即代码(IaC)指令文件,设置扫描器来识别和防止错误配置和不安全的指令。

5.1.6 确保验证部署配置清单
说明
       验证检查部署配置清单。
说明
       要确保使用的配置清单是受信任的,并且在到达平台之前没有被恶意行为者感染,必须对清单进行验证。这可以通过将清单文件的校验和与其在可信源中的校验和进行比较来实现。如果出现了差异,这是一个迹象,表明一个未知的参与者进行了干扰,可能添加了恶意的指令。如果使用了这个清单,它可能会损害环境和应用程序部署,这可能会导致大规模的破坏,并使组织暴露于数据泄漏等。
审计
       对每个使用中的部署配置清单,确保得到验证。
补救措施
       验证使用中每个部署配置清单。

5.1.7 确保部署配置清单固定在一个特定的、经过验证的版本
描述
       部署配置通常存储在版本控制系统中,并从那里拉取。将使用的配置固定到特定的、经过验证的版本或提交安全哈希算法(SHA)。避免引用未指定版本标签的配置。
说明
       部署配置清单通常存储在版本控制系统中,并由自动化平台,如Ansible,或Gitops平台,如ArgoCD从那里拉取。当从没有标签或提交指定SecureHash算法(SHA)的版本控制系统中拉取清单时,它将从最前面的修订版本,等同于“最新”版本,并拉取最新的更改。这增加了遇到新的、潜在的恶意配置的风险。如果攻击者将恶意配置推送到版本控制系统,那么下一个获取最靠前版本的用户也将获取该版本,从而面临被攻击的风险。为了避免这种风险,使用经过验证的版本的版本标签或提交SHA的可信提交,这将确保这是唯一拉取的版本。
       注:除非指定了部署配置的版本标签或提交安全哈希算法(SHA),否则不会拉取部署配置中的更改。这可能会减慢部署过程。
审计
       对于正在使用的每个部署配置清单,确保它限于特定的版本或提交安全哈希算法(SHA)。
补救措施
       对于正在使用的每个部署配置清单,限于特定的版本或提交SecureHash算法(SHA)。

5.2  部署环境
       这部分包含管理部署环境的安全建议。
       部署环境是编排器和部署应用程序的生产环境。它直接影响客户的体验和对产品的信任,这对组织本身有严重的影响。保护它的方法从访问管理到自动化。

5.2.1 确保部署是自动化的
描述
       自动化生产环境和应用程序的部署。
说明
       自动化生产环境和应用程序的部署降低了人为错误的风险,例如错误的配置或敏感数据的暴露,因为它需要更少的人为交互或干预。它还简化了环境的重新部署。最好使用“基础设施即代码”(IaC)实现自动化,因为它提供了环境创建配置和存储到版本控制平台更改的更多控制。
审计
       对于每个部署过程,确保它是自动化的。
补救措施
       自动化生产环境和应用程序的每个部署过程。

5.2.2 确保部署环境是可复现
描述
       验证部署环境,即部署应用程序的编排器和生产环境,是可复现的。这意味着如果配置没有更改,那么在每次部署中环境都是相同的。
说明
       一个可复现构建是在给定相同的输入数据时生成相同制品的构建,在本例中是相同的环境。确保在提供相同的输入时生成相同的环境有助于验证没有对其进行更改。这个操作允许组织相信它的部署环境是由安全的代码和配置构建的,这些代码和配置已经被审查和测试过,没有被污染或贸然更改过。
审计
       验证部署/生产环境是可复现的。
补救措施
       调整部署部署/生产环境的流程,使其在每次配置未更改时都构建相同的环境。

5.2.3 确保对生产环境的访问是有限制
描述
       将访问生产环境的权限限制在少数受信任和有资格的用户。
说明
       生产环境是一个非常敏感的环境。它直接影响客户的体验和对产品的信任,这对组织本身有严重的影响。由于这种敏感的特性,必须将对生产环境的访问限制为只有少数可信和合格的用户。这将减少错误的风险,如泄露秘密或配置错误。这种限制还减少了可能破坏生产环境而容易被劫持的帐户的数量。
       注:减少能够访问生产环境的用户数量意味着这些用户将失去对该环境进行直接更改的能力。
审计
       验证生产环境只对受信任和合格的用户可访问。
补救措施
       只允许具有信任和资质的用户访问生产环境。

5.2.4 确保不使用默认密码
描述
       禁止使用部署工具和组件的默认密码。
说明
       许多部署工具和组件都为首次登录提供了默认密码。此密码仅用于首次登录,登录后应立即修改。使用默认密码会增加被攻击的风险。确保部署工具和组件中没有使用默认密码非常重要。
审计
       对于每个部署工具,请确保密码不是默认密码。
补救措施
       每个部署工具都需要修改密码。
(完)

原文始发于微信公众号(安全行者老霍):CIS 软件供应链安全指南v1.0(下)

  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2022年11月1日12:21:09
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   CIS 软件供应链安全指南v1.0(下)http://cn-sec.com/archives/1382271.html

发表评论

匿名网友 填写信息