注

学习了一下 Uber 的跨云平台密钥管理方案，简单翻译了一下，英文不错的师傅可以直接翻到文末的原文链接看原文。

引言

在Uber，该公司运行着超过5,000个微服务、5,000个数据库以及每天超过500,000个分析任务，为全球数百万用户提供服务。超过150,000个密钥在这些大型分布式系统中的多个利益相关者之间促进身份验证。这还包括超过400个第三方供应商集成和400个SaaS应用程序。

随着全行业网络攻击不断增加，凭证泄露成为主要原因之一。为此，Uber开始构建一个集中化、自动化和可扩展的密钥管理方案。为了应对密钥扩散、影子IT vaults和不安全的密钥共享问题，并在必要时促进密钥轮换，Uber启动了一项构建密钥管理平台的转型之旅。公司组建了一组内部 leaders，定义了Uber的密钥管理标准和具有前瞻性的方案（图1）。本文将分享Uber如何构建其密钥管理平台，解决关键挑战并为密钥管理设立新标准。

图1：密钥管理平台愿景

解决密钥扩散问题

密钥散布在代码、配置和其他未加密系统中，会使攻击者更容易找到并利用它们。Uber部署了预防和补救两种策略来解决潜在的密钥扩散问题。

开发人员在日常工作中会进行代码更新。为防止密钥进入代码库，Uber引入了一个CLI工具，作为Git中的预提交钩子运行。该工具可阻止包含密钥的提交，在开发过程最早阶段，在它们到达代码库之前就阻止泄漏。通过提前发现密钥暴露，减少了事件响应的需求，最小化了开发人员必须撤销和轮换泄露密钥的情况。

Uber的补救策略同时涉及实时和定期扫描方法：

实时扫描：Uber构建了一个系统，在变更和事件发生后立即进行扫描。这包括代码变更（如拉取请求和推送提交）、Slack对话以及构建系统的日志。
定期扫描：公司还定期扫描代码库、文件系统和容器镜像。这些扫描有助于检测可能在早期阶段遗漏的任何残留密钥，确保不会长期暴露密钥。

在上述任一情况下，如果检测到密钥，自动化系统会识别所有者并生成具有适当优先级的工单，通知他们该问题。所有者需要撤销密钥并从任何暴露位置删除它。一旦完成补救措施，工单即被关闭，确保风险已得到解决。Uber继续在系统扩展过程中添加新的扫描目标。通过这套系统，可以检测并补救开发人员意外泄露到密钥vaulys外部的密钥。目前，公司正致力于在IDE中启用安全协助工具，以便在开发周期早期阶段一旦添加可能的密钥就立即通知开发人员。

整合密钥vault

Uber的密钥管理标准描述了管理密钥的几个方面，涵盖了密钥存储、轮换和泄漏响应等领域。该标准规定所有密钥必须存储在由单一团队，密钥团队管理的经批准的密钥vault中。这导致了两个主要工作领域。密钥团队，直在本地运行HashiCorp Vault，但团队并未在云端运行密钥vault。团队为每个云供应商和企业网络内部设置了具有适当安全控制的密钥vault，并致力于弃用其他团队运营的vault。

另一个工作领域是将密钥从自定义密钥vault和数据库迁移到密钥团队管理的现有密钥vault之一。这使一个团队能够统一管理并确保所有密钥vault均满足安全基线，同时减轻其他团队管理自己密钥vault的负担。

在开始这项工作时，Uber遇到了迁移和广泛密钥分发的挑战。迁移范围涉及由不同团队的数百名工程师开发的工作负载使用的密钥。公司实施了各种集成（如使用Kubernetes External Secrets Operator）并支持从现有自定义密钥vault到集中管理的密钥vault的无缝迁移。这确保了进行迁移的中央团队以外的团队无需进行代码更改。

Uber还发现，一个团队拥有的数据管道所需的密钥被分发给并可被Piper（一个数据工作流编排系统）启动的所有管道访问。数据平台和CICD基础设施的其他部分也存在类似模式。公司引入了对这些管道启动的容器内密钥访问的监控，以识别并将密钥归属于访问它们的特定管道。这使得可以将密钥适当地限定到特定管道/工作负载，从而确保密钥仅分发给需要它的管道。在启用该功能后，分发到工作负载的密钥减少了多达90%（图2）。

通过这一举措，Uber将Uber内不同团队拥有的25个跨多个云的密钥vault合并为由单一团队管理的6个。管理6个vault使得单个团队能够运营，同时限制了特定部署环境的影响范围，以防其中一个vault卷入可靠性或安全事件。

图2：启用功能前（黄色）和启用后（绿色）分发到数据管道容器的密钥数量

密钥管理平台

将密钥vault整合到一个团队的所有权下，使Uber能够标准化并管理公司内使用的所有密钥。这为构建跨多个vault的中央管理和治理层密钥管理平台奠定了基础。在整合密钥vault的过程中，公司意识到需要解决的一些常见模式问题：

描述有助于整体密钥治理和自动化的密钥属性的元数据模型
在不同云密钥管理器和HashiCorp Vault上执行CRUD操作
为Uber员工提供在他们开发和运维的系统中使用密钥的简单抽象API、CLI和Web UI
能够为不同目的生成密钥清单，如响应安全事件
所有密钥的统一访问控制模型
支持轮换策略和自动轮换密钥

Uber开发了一个元数据模型（如图3所示），成为其密钥管理平台的基石。

图3：密钥元数据模型和影响级别定义

为每个密钥确定的关键属性包括：

密钥提供者：负责生成密钥并将其安装到适当资源中的系统
部署平台：将密钥分发给工作负载的系统，使其能够访问所需资源
密钥影响级别：表示密钥的关键性及其被破坏可能带来的后果

Uber构建了一个跟踪密钥清单及其元数据的组件。公司利用一组启发式方法在中央回填不足的元数据（例如，根据密钥保护的资源推导影响级别）。对于无法回填的部分，从拥有这些密钥的团队中众包收集缺失的元数据。

随着时间推移，Uber围绕密钥清单/元数据组件构建了新组件，逐渐发展成为密钥管理平台。这包括：

与平台交互的用户界面（Web UI、API和CLI）
用于密钥轮换、删除、撤销的密钥生命周期管理工作流
密钥的访问管理
支持第三方供应商和SaaS集成的扩展
跟踪关键密钥治理指标以及新功能推出进度的密钥洞察仪表板

接下来的两节描述了作为密钥管理平台的一部分启用的关键功能。

实现密钥自动轮换和删除

在Uber这样复杂多样的技术栈中，构建大规模自动轮换密钥的能力是一项挑战。

Uber有多个部署容器化工作负载的平台：Up和Kubernetes用于无状态服务，Odin用于有状态/存储服务，Athena用于Apache Flink流处理作业，YARN用于批处理分析工作负载，以及其他如Piper和DSW。公司严重依赖与部署平台的集成，在容器启动时分发密钥。这种架构将密钥技术栈与工作负载内的任何逻辑解耦，使系统能够独立扩展并通过与部署平台的集成构建功能。是的，目前Uber确实有多个部署平台，而Kubernetes迁移计划正在进行中。

Uber有数百种密钥类型（如云凭证、OAuth密钥、数据库用户名/密码、SaaS密钥）。某些密钥类型可以通过API以编程方式生成和删除，而其他则不行。有些不支持密码无缝轮换，因为它们在任何时候只支持一个有效密码，这意味着当密码轮换时，使用该密码的服务可能会停机。为解决这个问题，需要考虑诸如将用户名和密码对视为单个密钥并创建新对作为轮换的原子操作等技术。

图4：从密钥管理平台编排密钥轮换

为支持密钥轮换及其整体生命周期管理，Uber设计了两组API：密钥提供者API和部署平台API。密钥提供者API具有Generate（新版本）、Revoke（禁用密钥）和Rollback（重新启用先前版本）等功能。另一方面，面向部署平台的API提供了指示推出（特定工作负载的密钥）的功能，以及支持密钥获取（在启动工作负载前）的API。一个基于Cadence工作流的名为密钥生命周期管理器的协调器组件管理状态并将这些API按序列连接起来，支持密钥的自动轮换（图4）。

基于密钥清单，Uber优先考虑为某些密钥类型和部署平台启用自动轮换，根据与密钥相关的风险（如它们保护的资源）和密钥数量（表明缺乏自动化时的手动工作量）逐个启用这些API集成。

该系统平均每月为20,000个密钥自动编排轮换，无需人工干预。然而，由于密钥类型多样化以及需要在数百个密钥提供者之间进行的大量集成，为所有密钥启用自动轮换是一项挑战。构建和维护这些集成所需的工作使得在许多情况下难以实现完全自动化。因此，Uber正在转向无密钥认证并探索替代认证机制，以减少对传统密钥的依赖。

随着通过密钥管理平台引入高级密钥访问监控，Uber识别出了无所有权或使用模式的孤立密钥。公司扩展了密钥生命周期管理器来运行一系列检查（所有权、它保护的资源是否存在以及使用密钥的工作负载）并安全地停用这些密钥。

促进与第三方供应商的密钥交换

Uber管理着与各种第三方（3P）供应商的集成，使用密钥进行身份验证或数据交换。在与管理这些集成的团队讨论密钥与第三方供应商交换的问题后，公司意识到需要在3P和Uber之间安全交换密钥，而不向人类暴露它们，并将它们安全地部署到Uber的生产系统中。

Uber设计了SSX（安全密钥交换）系统，以安全高效地在Uber的3P供应商和Uber之间共享密钥。Uber员工可以通过提供两个关键信息来启动密钥交换：3P供应商联系信息（电子邮件）和与供应商API集成的Uber内部服务名称（图5）。

图5：与SSX交互的序列图

SSX通过向供应商的电子邮件发送一次性密码（OTP）验证供应商身份，并允许供应商在SSX用户界面中输入密钥来促进这一交换。一旦供应商完成这些步骤，SSX负责将密钥安全地直接传输到内部密钥vault，无需Uber员工参与。

Uber进一步通过构建与前一节描述的部署平台的集成，扩展了系统以处理从密钥vault到最终目的地的密钥传递。该集成提供了两个关键功能，以确保与3P供应商API集成的Uber微服务的可靠性：

在将密钥部署到服务之前，自动运行预定义的健全性测试
如果新密钥值破坏了集成，服务可以回退到现有密钥值

Uber内的服务所有者可以灵活使用这些功能中的任何一个，以消除手动测试负担并确保与3P API的服务集成可靠性。

到目前为止，SSX已促成了不同3P供应商与Uber之间数百个密钥的交换。

在全公司范围内扩展计划

管理密钥管理平台的团队由10名工程师组成。如果没有全公司的强力支持，加速新功能的采用，实现上述章节描述的重大改进是不可能的。以下关键变化使Uber能够在全公司范围内扩展该计划。

全公司技术计划

Uber早期通过数据识别了密钥管理领域的关键问题，并提出了方向性目标和建议。公司咨询了各部门工程领导以收集反馈。支持数据和展示密钥管理的当前状态促成了项目提案的推进，使不同部门的工程师能够协调一致，并激励他们致力于项目成功。

与关键利益相关者的设计合作

Uber确定了公司内真正关心安全和密钥的关键利益相关者作为设计合作伙伴。管理Uber客户数据和支付信息的部门在安全话题上有很强的动力。公司与他们密切合作，了解他们的观点并设计解决方案。SSX（安全密钥交换）系统就是从这种合作中构想出的解决方案之一。Uber还与拥有不同领域专业知识的多个平台团队合作：服务部署、云基础设施和数据/存储。这促使公司与多个内部系统建立集成，提高了构建整体密钥管理平台的效益。

数据驱动的功能优先级和采用

在确定的范围内，Uber使用从构建密钥清单收集的数据来评估风险和投资回报，从而确定功能和全公司采用策略的优先级。例如：对于密钥的自动轮换，公司首先投资于云凭证，因为它们保护了Uber的一些关键资源，且云采用随着时间推移而增长。因此，优先考虑为云凭证构建自动轮换支持。

结论

以下是构建和加强密钥管理平台并建立其集成的关键经验：

集中化密钥管理。对于拥有多云基础设施和技术复杂性的公司，集中化的密钥管理方法对确保一致的安全措施至关重要。这种策略在防止密钥泄漏和保护密钥vault等领域尤为重要。
正确保护密钥。在大型企业中正确保护密钥是一项多方面的挑战。这涉及成熟的一系列能力，从自动化流程到访问控制。如果所有这些都失败，导致密钥泄漏或被破坏，那么重要的是准备好大规模轮换密钥。
基于风险的优先级。并非所有密钥都具有相同的风险级别。基于暴露和影响，有些密钥比其他密钥更关键。例如，云和第三方密钥风险更高，因为它们用于向外部系统进行身份验证，使它们成为更严格安全控制的优先考虑对象。

在Uber开发密钥管理平台的同时，CyberArk和Akeyless等供应商也推出了基于类似原则管理跨多个云供应商密钥的可比解决方案。

安全领域的工作永远不会完成。行业正朝着无密钥架构发展，并使密钥管理更接近机器/工作负载身份管理（2024年Gartner报告）。展望未来，Uber将继续改进现有集成并构建新功能，以提高其基础设施的安全状况。

通过构建密钥清单，Uber能够收集有关密钥类型及其在公司使用方式的宝贵见解。公司正在通过在特定领域消除对密钥的需求，如利用SPIRE促成的工作负载身份联合的云集成，向无密钥方向迈出重大一步。

密钥轮换期间的自动化失败会给支持Uber业务的技术堆栈的可靠性带来风险。目前，公司正致力于通过改进与部署平台的集成，将密钥更新视为类似于代码更改部署，从而实现部署安全。Uber还使用各种SaaS应用支持其内部运营。将平台与Uber内部SaaS应用管理流程集成并支持SaaS密钥轮换是另一个主要投资领域。