适用于 Borg 的 Binary Authorization:Google 如何验证代码出处并实施代码身份

Google 撰写了多份白皮书,介绍我们安全团队的内部开发项目(包括 BeyondCorpBeyondProd),这些项目可以帮助提高安全性。如需大致了解 Google 的安全性,请参阅我们的安全性基础架构设计白皮书。

在此白皮书中,我们介绍了 Google 的代码审核流程、代码出处1,以及强制执行机制的必要性。我们专注于开发特定的强制执行检查 - 适用于 Borg 的 Binary Authorization (BAB)。BAB 的目标是通过确保对 Google 平台上部署的正式版软件进行适当审核和授权来降低内部风险,尤其是在代码能够访问用户数据时。对于所有 Google 产品,我们重视对用户数据的保护,并力求让我们所采取的安全措施尽可能透明化。

此白皮书的内容截至 2019 年 12 月是正确无误的。本文档介绍的是截至文章撰写之时的现状。随着我们持续改善对客户的保护机制,Google Cloud 的安全政策和系统未来可能会发生变化。

面向首席信息官级别领导者的摘要

  • 内部风险是对用户数据安全的威胁。在 Google,我们希望尽可能降低 Google 员工以未经授权的方式(其中包括运行未经授权的作业)使用其组织知识或访问用户数据的可能性。
  • 适用于 Borg 的 Binary Authorization (BAB) 是一项内部部署时强制执行检查,它通过确保对 Google 平台上部署的正式版软件和配置进行适当审核和授权来最大限度地降低内部风险,尤其是在代码能够访问用户数据时。
  • BAB 可确保代码和配置部署满足特定的最低标准。
  • 除了强制执行外,BAB 还可用于非强制性审核模式,以便在不满足某些要求时发出警告。
  • 采用 BAB 有助于 Google 降低内部风险、防止潜在的攻击,以及支持 Google 生产系统的统一性。

最大限度地降低 Google 内部的风险

作为一家高度重视安全性的公司,我们采取了一些措施来降低内部风险 - Google 员工(或组织中的任何其他人)使用其组织知识或访问权限来执行恶意操作的可能性。此外,内部风险还包括攻击者盗用了 Google 内部人员的凭据以便实施攻击行为的情况。我们在内部风险防范方面投入了大量资源进行创新。在 Google,保护用户数据至关重要,我们力求为其提供全面的保护。我们的目标是防止 Google 员工在未经授权的情况下访问用户数据。

针对访问用户数据的授权

在 Google,我们的服务和员工有时必须访问用户数据。我们通过以下方式与用户数据进行交互:

  1. 作为最终用户:使用某项服务的员工直接向该服务进行身份验证,该服务会返回员工自己的数据。例如,登录到 Gmail 帐号的员工会看到自己的电子邮件。
  2. 作为角色的一部分:Google 员工的大部分工作都可以使用匿名化的用户数据成功完成。但在极少数情况下,我们的员工需要在工作(例如提供支持或进行调试)中访问用户数据。我们的目标是尽可能提高用户数据访问的透明度。为此,我们所采用的一种方法是使用 Access Transparency 功能;借助这项功能,Google Cloud 客户能够通过实时日志查看相关人员对其数据的合法访问情况。
  3. 作为服务的一部分(编程方式):为了完成任务,某项服务可能需要以编程方式大规模访问用户数据。例如,数据流水线将同时查询数千个用户的数据,以生成汇总的使用情况统计信息。出现此类需求时,系统会针对某个数据集(而不是单个用户的数据)授予访问权限。系统不会记录对每个用户的数据的访问情况。

本白皮书重点关注第三种情形中介绍的威胁模型。我们希望使运行访问用户数据的系统的管理员无法滥用其权限。

威胁模型

我们在本文中讨论的控制措施旨在通过防止单方面访问来保护用户数据。我们希望阻止 Google 员工在没有适当授权和正当理由的情况下独自直接或间接访问或以其他方式影响用户数据。无论操作者是怀有恶意、其帐号遭到盗用,还是意外获得授权,我们的控制措施都会阻止这些操作。

Google 的容器化基础架构

我们的基础架构使用名为 Borg 的集群管理系统实现了容器化管理。我们在多个集群中运行来自许多不同应用的数十万作业,每个集群包含多达数万台机器。尽管规模如此庞大,但我们的生产环境却具有相当高的同质性。因此,我们可以更轻松地控制和审核访问用户数据的接触点。

此外,通过使用容器,我们获得了显著的安全优势。容器是不可改变的,需要通过重新构建完整的映像来频繁地重新部署。此属性使我们能够在上下文中查看代码更改情况,并为部署到我们基础架构中的所有更改提供单一的关卡。

为了理解我们如何开发解决方案来限制服务以编程方式访问用户数据,首先必须理解服务如何在 Google 内部进入生产环境。

第 1 步:代码审核

我们的源代码存储在单一的中央代码库中,该代码库可让数千名员工将代码签入到单一位置。使用单一代码库可以简化源代码(特别是依赖于第三方代码的依赖项)管理。单一代码库还允许强制执行代码审核的单一关卡。在 Google,代码审核包括至少一名工程师(开发者除外)的检查和批准。我们的代码审核流程强制执行以下规则:对任何系统执行代码修改都必须得到该系统所有者的批准。代码一旦签入,就会进行构建。

从第三方或开放源代码导入更改内容时,我们会验证更改内容是否合适(例如,针对最新版进行验证)。但是,对于外部开发者对我们所使用的第三方或开放源代码所做的每一项更改,我们通常没有相同的审核控制措施。

第 2 步:可验证的构建

我们使用与 Bazel 非常相似的构建系统,该系统会构建和编译源代码,创建用于部署的二进制文件。我们的构建系统在独立且处于锁定状态的环境中运行,该环境与执行构建的员工是分开的。对于每次构建,该系统都会生成一个可验证的构建清单,该清单是一份经过签名的证书,其中完整描述了进入构建的源代码、任何二进制文件或其他构建工件的加密哈希以及所有构建参数。借助此清单,我们可以将二进制文件追溯到在其创建过程中使用的源代码,并进一步追溯到此清单所描述源代码的创建和提交过程。此外,该清单还让我们能够验证二进制文件没有被修改,因为对该文件的任何更改都会自动使其签名失效。

由于构建操作在理论上可以是任意代码,因此我们的构建系统已针对多租户进行了安全强化。换句话说,我们的构建系统旨在防止一项构建影响任何其他构建。该系统会阻止构建进行可能危害可验证的构建清单或该系统本身完整性的更改。构建完成后,系统会使用 Borg 部署更改的内容。

第 3 步:部署作业

构建完成后,二进制文件可以作为 Borg 作业部署到我们的容器化基础架构中。这些作业使用可能包含二进制文件或数据的软件包,其安装由 Borg 管理。Borg 配置指定要部署作业的要求:软件包、运行时参数、参数和标志。Borg 根据限制条件、优先级、配额以及配置中列出的任何其他要求来安排作业。部署后,Borg 作业可以与生产环境中的其他作业进行交互。

第 4 步:作业身份

Borg 作业以某种身份运行;此身份用于访问其他服务的数据存储或远程过程调用 (RPC) 方法。身份可以是角色帐号(例如服务)或用户帐号(例如员工的个人帐号)。多项作业可以使用同一身份运行。只有负责运行相关服务的人员才能使用特定身份部署或修改作业,这类人员通常是我们的网站可靠性工程师 (SRE)

Borg 启动作业时,会为作业预配加密凭据。作业在(使用应用层传输安全)发出其他服务的请求时,会使用这些凭据来证明其身份。如需让某项服务访问特定数据或其他服务,其身份必须具备必要的权限。我们来看一下 Google Cloud 的 Cloud Data Loss Prevention (Cloud DLP) API 之类的服务示例。为了让 DLP API 访问扫描数据,需要具备两个条件。首先,需要将 DLP API 配置为使用不同的身份(在本例中为角色帐号)运行。其次,针对 DLP API 所扫描数据的权限必须包含该角色帐号。如果没有有效的身份和正确的权限,服务将无法执行扫描操作。

我们的政策要求,任何拥有用户数据(或任何其他敏感信息)访问权限的角色帐号都必须受到 BAB 和其他安全系统的严格控制。无法访问敏感数据或资源的质量保证和开发作业可以在受到较少控制的情况下运行。

总结:作业的生命周期

总的来说,在我们的基础架构上运行作业的步骤如下:

  1. Google 开发者更改代码。随后,开发者将代码发送给一位或多位其他 Google 工程师进行审核。审核工作包括检查是否有适当的授权和日志记录。获得批准后,代码会签入。
  2. 由开发者触发后,构建系统会在沙盒环境中验证性地构建和封装二进制文件。此构建操作会生成一个软件包,构建系统随后会签署该软件包以进行验证。
  3. 该作业由有权管理以适当安全身份运行的作业的工程师部署在 Borg 上。
  4. 当 Borg 作业尝试访问用户数据等特权资源时,系统会验证该作业的身份以进行授权

现在,您已了解作业是如何在我们的生产环境中运行的,接下来让我们看看 BAB 所针对的威胁模型 - 阻止潜在的恶意内部人员运行未经授权的作业。为此,BAB 会验证是否在部署二进制文件之前执行了所有必要的安全检查。

本部分简要介绍了我们的容器化基础架构。如需理解我们针对用户以编程方式访问数据而采取的控制措施,您必须大致了解我们的生产环境。下一部分将详细介绍这些控制措施。

适用于 Borg 的 Binary Authorization (BAB)

几年来,我们一直在努力防止手动访问用户数据。相关的措施包括:将数据和作业管理权限仅授予在工作中需要使用该权限的一组 Google 员工。

BAB 旨在确保对 Google 内部部署的所有正式版软件和配置进行适当审核和授权,特别是在代码能够访问用户数据时。为此,BAB 提供了部署时强制执行服务以阻止未经授权的作业启动,并且提供了审核跟踪功能以跟踪启用了 BAB 的作业中使用的代码和配置。

验证

BAB 会验证二进制文件在部署时是否满足特定要求。例如,服务所有者可能要求其服务的二进制文件必须基于经过审核、签入、测试和授权的代码构建。我们将这些类型的检查称为部署时检查。BAB 还可以在二进制文件部署后执行检查 - 我们将这些类型的检查称为部署后检查。如需详细了解这些部署后验证,请参阅我们的强制执行模式部分。

如果更改代码,则系统会创建新的二进制文件。为了让新二进制文件中的更改生效,必须对其进行部署。BAB 允许进行多种部署时检查。这些检查的一些示例包括:

  • 二进制文件是否基于签入的代码构建

    代码是否已提交并签入到 Google 的源代码库中?对于要提交的代码,通常必须由另一位 Google 工程师进行审核。

  • 二进制文件是否以可验证的方式构建

    此二进制文件是否可以追溯到可审核的来源并且是否由获得批准的构建系统构建?

  • 二进制文件是否基于经过测试的代码构建

    二进制文件是否满足测试要求?

  • 二进制文件是否基于要在部署中使用的代码构建

    代码是否已提交到源代码库的相应区域,该区域对应于该特定 Borg 作业的相关项目或团队?

虽然这些要求是专门针对我们生产环境的,但您可以在 CI/CD(持续集成/持续部署)环境中根据自己的安全性、合规性或可靠性要求强制执行类似的要求。

服务专用政策

访问敏感数据的作业通常需要提交代码,但有一些出于正当商业原因的例外情况。敏感数据包括用户数据、雇佣和财务数据以及任何其他有必要知道的专有数据或商家数据。Google 内部的所有作业都必须有政策 - 即使不需要访问用户数据的 Borg 作业也会定义政策,但没有列出具体要求。

当服务所有者使用 BAB 时,会定义一项政策,其中包含对其服务的安全要求。用于实施其服务的所有角色帐号必须指定 BAB 政策。对于每个角色帐号,BAB 政策会定义要启动的预期作业以及作业的代码和配置要求。定义或修改政策本身是一种更改代码的操作,必须经过审核。

可以在 BAB 政策中强制执行的要求包括:

  • 代码是以可验证的方式构建的:以可验证的方式构建的代码是可审核的,但这并不一定意味着代码已经过审核,有时候代码甚至尚未提交。在可验证的构建中使用的代码至少在 18 个月内可以审核,即使没有提交也是如此。

  • 代码已提交:代码是从源代码库中指定的预期位置构建的。这通常意味着代码已经过审核。

  • 配置已提交:在部署期间提供的任何配置都会经历与常规代码一样的审核和提交流程。因此,如果没有进行审核,则无法修改命令行标志值、实参 (Argument) 和形参 (Parameter)。

强制执行 BAB 的系统和组件必须受到严格控制。这是通过实施最严格的要求以及额外的手动控制措施来实现的。

强制执行模式

BAB 会根据 Borg 作业指定的政策执行不同的操作。我们将这些操作称为强制执行模式,其中有三种模式:部署时强制执行、部署时审核和持续验证。定义政策时,服务所有者必须选择部署时强制执行或部署时审核。默认情况下,启用持续验证模式。后续部分将详细介绍每种模式。

部署时强制执行模式

提交新作业后,Borgmaster2 会“咨询”BAB,以确认该作业满足 BAB 政策中规定的要求。这项检查将充当准许控制器 - 如果满足要求,则 Borgmaster 将启动该作业。否则,即使发出请求的用户通过其他方式获得了授权,Borgmaster 也会拒绝该请求。

在强制执行模式下,如果 Borg 作业不满足其 BAB 政策规定的要求,则 BAB 将阻止该作业的部署。刚刚进入 BAB 的服务通常会从审核模式(下一部分会介绍)开始,然后升级到强制执行模式。

紧急响应过程

如果出现突发事件或故障,我们的首要任务是尽快恢复受影响的服务。在紧急情况下,可能需要运行尚未审核或签入的代码。因此,可以使用紧急响应标志替换强制执行模式。如果本来应该阻止部署的 BAB 出现故障,则紧急响应过程也会充当备用过程。使用紧急响应过程部署作业的开发者必须在其请求中提交正当理由。

在使用紧急响应过程的几秒钟内,BAB 会记录关联的 Borg 作业的详细信息。相应的日志会包含所使用的代码以及用户提供的正当理由。几秒钟后,审核跟踪信息会发送给我们的集中式安全团队。数小时内,审核跟踪信息会发送给拥有相应角色帐号的团队。紧急响应过程只应作为最后的办法来使用。

部署时审核模式

在审核模式下,如果 Borg 作业不满足政策要求,则 BAB 会记录日志但不会阻止其部署。此时,系统会提醒拥有相应角色帐号的团队。

在 Google,我们要求特定服务(例如访问用户数据的服务)使用强制执行模式。我们强烈建议一切服务所有者都使用强制执行模式,仅在启用新服务时使用审核模式。如需使用审核模式,服务所有者必须提供希望获得例外对待的正当理由。例如,如果服务的可靠性 SLO(服务等级目标)明显高于 BAB 提供的目标,则服务会使用审核模式。

尽管审核模式在微调初始政策时非常有用,但对于大多数服务而言并非实际稳定状态。使用审核模式时,服务所有者在发生违反政策数小时之后才会收到相应通知。这可能会导致通知流受到干扰,使得真正的安全问题被服务所有者造成的错误或政策配置错误所掩盖。使用强制执行模式时,服务所有者会在尝试启动不符合政策的作业时立即获得反馈。因此,他们的通知流会更加清晰。此外,BAB 中的强制执行模式会捕获意外错误,例如意外使用非预期角色启动作业。

持续验证

部署作业后,无论作业在部署时的强制执行情况如何,系统都会在其生命周期内对其持续进行验证。BAB 进程每天至少运行一次,以检查已启动(并且可能仍在运行)的任何作业是否符合其政策的任何更新内容。例如,持续验证模式会不断检查使用过期政策运行的作业或使用通过紧急响应过程部署的身份运行的作业。如果发现作业不符合更新的政策,则 BAB 将通知服务所有者,以便他们降低风险。

允许在全球范围内使用的软件包

在 Google,我们的许多服务广泛使用了一些软件包。我们通过集中方式允许使用这些软件包(称为在全球范围内管理的软件包),而不强制每项服务维护自己的版本。在编写 BAB 政策时,服务所有者可以为给定作业指定允许在全球范围内使用的软件包。对于广泛使用的软件包,还有一个全球默认机制,因此无需在每项服务的政策中单独列出这些软件包。这样,Google 就可以明确控制整个组织使用的常见系统组件,并确保在不涉及个别团队的情况下对这些组件进行适当审核和更新。虽然单个服务所有者可以在服务的 BAB 政策中明确允许这些软件包,但此机制便于所有者使用建议和支持的途径。

边缘用例

Google 对生产环境中部署的代码实施强大的安全控制措施,包括代码审核可验证的构建。BAB 会作为额外的控制措施和强制执行点,以确保这些安全控制措施得到妥善实施。

但是,BAB 并非在所有情况下都能得到有效利用。BAB 不支持以下边缘用例:使用非标准构建系统构建的代码;部署在非 Borg 环境中的代码;数据分析和机器学习代码(在选择最终生产参数之前,这些代码不适合进行人工代码审核)。在这些用例中,我们提供了其他各种安全措施,包括其他代码出处系统。不过,此代码仍受 Google 的一般安全控制措施约束。

实施适用于 Borg 的 Binary Authorization

为了实施 BAB,BAB 团队开发了多项新功能,包括紧急响应过程和审核模式。这些工具可让服务所有者尽可能轻松地自行尝试 BAB。如果您正考虑在自己的组织中部署类似 BAB 的内容,您可能需要做一些额外的工作来促成这种转换。本部分介绍了我们在实施计划中所做的组织和变更管理工作。

优势

BAB 具有三项优势,有助于构建在 Google 开发和采用的业务用例,这三项优势是:降低内部风险、增强代码身份、简化合规性。

降低内部风险

BAB 旨在防止任何个人在未经授权的情况下以编程方式访问用户数据。BAB 使得单个工程师或获得工程师凭据的攻击者更加难以在不被人发现的情况下以不当方式访问敏感数据。

增强代码身份

正如容器化基础架构部分所述,Borg 作业以某种身份(通常是角色帐号)运行。在授予对任何数据的访问权限之前,其他服务会使用此身份来验证适当的授权。但是,其他服务无法强制使用该数据,因此必须信任作业身份不会滥用其收到的数据。BAB 会将作业的身份与特定的代码相关联,从而确保只有指定的代码可用于行使作业身份的权限。这样可以实现从作业身份(信任身份及其具有相应权限的任何真人用户)到代码身份(信任一段特定的代码,这段代码经审核具有特定的语义并且在未经批准的情况下不能修改)的转换。

简化合规性

BAB 简化了之前的手动合规性任务。Google 的某些流程要求更严格地控制数据的处理方式。例如,我们的财务报告系统必须遵守《萨班斯-奥克斯利法案》(SOX)。在使用 BAB 之前,我们有一套系统,可帮助我们手动执行验证以确保合规性。在使用 BAB 后,许多检查都是根据服务的 BAB 政策自动执行的。通过自动执行这些检查,合规性团队可以扩大服务范围并对这些服务采取适当的控制措施。

启用服务

BAB 团队必须确保启用过程既简单又直接。最初,关于采用 BAB,Google 的服务所有者主要担心两点:

  • 如果 BAB 不够可靠,则实施它可能会阻止关键情况下的更改。
  • 由于频繁的代码签入和迭代过程,BAB 可能会导致服务的开发速度变慢。

为了解决服务所有者最初所担心的这些问题,BAB 团队开发了审核模式。通过使用此模式,BAB 团队能够向一些重要的早期用户证明 BAB 确实有效。为了进一步提高可靠性,BAB 团队开发了可用性 SLO 并为强制执行模式引入了紧急响应过程

向 BAB 启用现有服务时,服务所有者通常会先启用“仅限审核”模式。这有助于他们在启用强制执行模式之前识别并解决任何问题。在生产环境中使用 BAB 的任何作业的默认政策都是强制执行模式。如需部署作业,服务所有者必须提交一项政策,该政策至少要求提交代码并且以可验证的方式构建代码。服务所有者可以在不满足此最低标准的情况下部署其作业,但必须获得例外权限。如果服务需要访问更敏感的数据和/或服务,则所有者可能必须满足更严格的要求。定义初始政策可能比较困难,因此 BAB 团队创建了自动化工具来帮助服务所有者编写政策。这些工具会查看源代码库的哪些部分用于现有作业,并提供适当的政策建议。

向 BAB 启用新服务时,服务所有者会从头开始启用强制执行模式。服务所有者起草初始政策,然后迅速迭代,添加其他要求。政策本身会随着代码更改而得到管理,因此需要另一位 Google 工程师来审核任何更新的内容。

影响

采用 BAB 和容器化部署模型在安全性和可支持性方面为 Google 提供了许多优势:

  • BAB 有助于降低总体内部风险:通过要求代码先满足某些标准和变更管理做法,然后才能访问用户数据,BAB 可以降低独自操作的 Google 员工(或帐号被盗用的 Google 员工)以编程方式访问用户数据的可能性。
  • BAB 支持生产系统的统一性:通过使用容器化系统并在部署之前验证其 BAB 要求,我们的系统更易于调试、更可靠,并且拥有更清晰的变更管理。BAB 要求提供了生产系统需要的通用语言。
  • BAB 规定了数据保护的通用语言:BAB 会跟踪我们各个系统的一致性。有关此一致性的数据已在内部发布,其他团队可以查询这些数据。以这种方式发布 BAB 数据可让团队在相互交流数据保护时使用通用术语。这种通用语言可以减少跨团队处理数据时所需的往返工作。
  • BAB 允许以编程方式跟踪合规性要求:某些流程(例如财务报告流程)需要满足某些变更管理要求以确保合规性。通过使用 BAB,这些检查可以自动执行,从而节省时间并扩大覆盖范围。

BAB 是 Google 为降低内部风险而使用的若干项技术之一。

在您的组织中采用类似的控制措施

在 Google 内部实施 BAB 时,我们获得了许多重要的经验教训。进行这么大的更改似乎是一项艰巨的任务。在本部分中,我们将分享在此过程中获得的经验教训,希望您能够将 BAB 原则应用到您的组织。

努力建立更相似的容器化 CI/CD 流水线。

我们在代码开发中使用的工具的一致性和集成性使我们能够在 Google 内部采用 BAB。这项工作包括代码审核、可验证的构建、容器化部署以及用于访问权限控制的基于服务的身份。可验证的构建可让您检查二进制文件的构建方式;容器可让您将二进制文件与数据分开,并为您提供强制执行关卡以确保这些文件满足使用要求。这种方法简化了 BAB 的采用,并加强了 BAB 等解决方案能够提供的保证。

微服务的引入允许采用基于服务的身份(例如服务帐号),而不是基于主机的身份(例如 IP 地址)。通过转变为基于服务的身份,您可以更改管理服务之间身份验证和授权的方式。例如,如果您使用嵌入容器映像的身份令牌来证明身份,则代码出处所提供的保证就没有那么强了。如果您无法直接采用服务身份,则可以尝试更强有力地保护身份令牌作为临时措施。

确定您的目标,并根据您的要求定义政策。

构建政策驱动型发布流程(每次构建一个)。在 CI/CD 流水线中,您可能需要更早地实施某些部分的更改。例如,您可能需要开始进行正式的代码审核,然后才能在部署时强制执行审核。

政策驱动型发布流程的强大动力是合规性 - 如果您可以在政策中至少对某些合规性要求进行编码,则有助于自动执行测试并确保它们始终有效。您可以从一组基本要求开始,然后再逐步编写更高级的要求。

在开发初期强制执行政策。

如果事先没有了解某一款软件的预期运行位置以及该软件将会访问哪些数据,则很难针对该软件定义全面的政策。这就是为什么 BAB 政策会在部署代码以及代码访问数据时(而不是构建代码时)强制执行的原因。BAB 政策是根据运行时身份定义的,因此相同的代码可能会在不同的环境中运行,并受不同政策的约束。

除了其他访问机制以外,我们还使用 BAB 限制对用户数据的访问。通过这种方式使用 BAB,服务所有者可以进一步确保只有满足特定 BAB 要求的作业才能访问数据,从而有效地将代码视为身份。

确定如何登录现有服务所有者。

确定一些服务所有者,他们将立即看到强制执行的优势并愿意提供反馈。实现此目的的一种方法可以是在进行任何强制性更改之前请所有者自愿参与。

如果可能的话,请要求强制执行模式优先于审核模式,或通过限制审核模式的宽限期来实施强制执行模式。借助审核模式,所有者可以快速登录并更好地了解内部风险。审核模式的缺点是需要一段时间才能看到内部风险确实降低了。这种延迟会导致很难显示价值,以及很难说服其他人采用强制执行措施。当 BAB 团队为强制执行提供紧急响应过程时,服务所有者更愿意采用强制执行措施,从而获得一个在需要时能够派上用场的“安全舱口”。

跨团队招募更改代理。

我们为 BAB 部署创建适用于整个 Google 范围的授权书时,影响我们成功率的最大因素是寻找所有者来推动每个产品组的变化。我们得到他们的帮助后,成立了一个正式的变更管理团队来跟踪正在发生的变化。随后,我们确定了每个产品团队中负责的所有者,以实施更改的内容。

了解如何管理第三方代码。

我们在本文中介绍的许多 CI/CD 控制措施均布置在由一个组织开发、审核和维护您代码的位置。如果您遇到这种情况,请考虑如何在政策要求中添加第三方代码。例如,您最初可以不审核代码,同时妥善保存使用的所有第三方代码的代码库,并定期根据您的安全要求检查该代码。

总结

作为 Google 容器化基础架构和 CI/CD 流程的一部分,实施部署时强制执行检查使我们能够验证所部署的代码和配置是否满足特定的最低安全标准。这是一项关键的控制措施,可用来限制怀有潜在恶意的内部人员运行可能访问用户数据的未经授权作业。采用 BAB 后,Google 可以降低内部风险、防止可能的攻击,同时也支持生产系统的统一性。

其他参考信息

如需详细了解 Google 的整体安全性和容器化基础架构,请参阅以下资源:

备注

1 出处描述了组件、对组件所做的更改以及组件的来源。请参阅 https://csrc.nist.gov/glossary/term/Provenance

2 Borgmaster 是 Borg 的集中式控制器。它负责管理作业的时间安排,并与正在运行的作业通信。