【数据安全】HashiCorp Vault被高估，Mozilla与KMS和Git的SOPS被严重低估

当我开始使用Kubernetes和Infrastructure as Code时，我很快发现我需要一个秘密管理解决方案，但当我在谷歌上搜索时，似乎没有就可以普遍应用于所有情况的最佳实践方法达成坚实的共识。因此，今年早些时候，我为自己设定了一个目标，即发现存在哪些应用程序和基础设施秘密管理解决方案，找出我认为最好的解决方案，并掌握它。在追求这个目标的同时，我得出的结论是，HashiCorp Vault被夸大了，而Mozilla与KMS和Git的SOPS被严重低估了。我认为SOPS被低估的主要原因有两个：

• 大多数人对云KMS是什么或做什么没有从技术到外行的理解。
• 这些人没有意识到，尽管过去没有安全的方式在Git中存储加密的秘密，但密码学从那时起就发生了变化，现在由于AWS KMS、Azure KeyVault或GCP KMS等云提供商KMS解决方案，在Git上安全存储加密的密钥成为可能。

Vault的大部分宣传都是有道理的，因为几十年来一直没有好的秘密管理解决方案，然后是Terraform制造商的Vault，它具有内置的秘密轮换功能，随着时间的推移得到了积极维护，拥有出色的文档、支持和社区，Vault是唯一一个满足我对理想的秘密管理方案的要求的解决方案。我说Vault被夸大了，因为我经常认为它被推荐为黄金标准，应该应用于所有机密管理场景。

理想的秘密管理解决方案要求

1. 通用（任何云和on-prem）
2. 通过REST API或独立于平台的CLI二进制文件与任何技术堆栈很好地集成。（如果它与Terraform、Ansible、Kubernetes和CICD Pipelines顺利集成，则会获得额外奖励）
3. 经得起未来考验
   1. 开源/免费（没有服务消失或价格上涨的风险）
   2. 大型社区或长期维护的历史（不要放弃软件，除非它可能是永恒的/功能完整的放弃软件，如Unix实用程序）
   3. 扩展良好并提供高可用性
4. 真正安全（我应该能够说服任何安全负责人，它足够防弹，可以通过安全审计。）
   1. 静止时的加密
   2. 传输中的加密
   3. 访问权限应可撤销
   4. 应预先研究漏洞，并采取应对措施。
5. 支持细粒度ACL+开发人员秘密创建自助服务选项
   1. 开发人员应该能够管理开发秘密，但不能管理产品秘密。
   2. 运维人员应该能够管理开发和生产机密。
   3. 项目级隔离：项目A的运作，不应该看到项目B的产品秘密。
6. 版本化机密（可以帮助转移和自动化、部署、回滚，以及支持机密和配置在配置文件和数据库连接字符串中交织在一起的技术债务场景。）

*注意：Mozilla SOPS也符合我的要求，但当时我没有意识到，因为我最初认为没有安全的方法来加密git机密。

在git repo中存储机密的安全挑战

• 许多工具都将解密密钥存储在用户的主目录或密钥环(keyring)中，这会导致加密数据和密钥位于同一台机器上。
• 在这种情况下，解密密钥受损在统计上是不可避免的（Vulnerabilities multiplied by clones of the repo multiplied by time）
• 撤销泄露的解密密钥是不可能的。如果你担心解密密钥可能已经被泄露，但泄露的可能性很低，那么由于git的分布式历史，撤销密钥不是一种选择。即使您可以清除git服务器的历史记录，并用新的加密密钥重新加密所有机密，仍然存在可以用旧密钥解密的repo的历史克隆。
• 如果怀疑有妥协，唯一可行的对策是轮换所有证书，这是一项昂贵的操作，管理层通常不愿意凭直觉放弃。
• 一些git加密工具是脚踏板解决方案：运行命令解密机密，然后在将其推送到repo之前忘记加密。

每当我发现一个秘密管理解决方案时，我注意到我可以将其分为4大类：

• 特定于单个云提供商（我出于原因1和3驳回了这些请求）
• 特定于单个技术堆栈（Ansible、Chef、Puppet、Salt、Jenkins）（我出于原因2和5驳回了这些）
• 加密的Git Repo（我驳回了这些原因4和5）
• 推出自己的秘密管理服务（有几个潜在的可行选项，但每个选项都有自己的复杂性，所以专注于其中一个是有意义的。Hashicorp的Vault是明显的赢家，因为它有很多功能、文档、大型社区以及长期支持和开发的记录。）

分析完成后，我花了一个月的业余时间在Vault服务器上工作，用于存储静态机密，以帮助我掌握Vault，我希望它安全、易于维护和易于使用。为了实现这一点，我尽了最大努力，启用TLS，将Vault配置、角色、策略和Kubernetes基础设施作为高可用的Vault/Culus群集的代码添加到git repo中，使用KMS自动解封，编写良好的自述文档，启用版本化的键值存储、LDAP身份验证、web GUI和Adobe称为Cryptr的第三方桌面GUI。在学习Vault时，我注意到它的使用有很多缺点：

1. 保险库仍然需要一个地方来存储它的秘密。（Vault将其基础结构作为代码机密存储在何处？KMS Auto Unsecal的HTTPS证书和IAM密码）
2. 保险库在很多方面都非常昂贵。（你必须为基础设施和存储付费。你可以从头开始设置它，写一个自述文件，并在一个小时内培训几个人如何使用它，这还不够简单，使用基础设施作为代码和git repo中的预制自述文件会有所帮助，但即使这样，仍有很多东西需要学习。运营人员需要花时间通过备份、升级和监控来维护它o花时间编写自定义包装脚本来验证和提取所需的数据。）
3. Vault让那些需要存储秘密的人的生活更加艰难，所以他们会避免使用它，这损害了它作为中央秘密库的目标。（开发人员需要学习几个新命令才能与Vault交互，或者依赖于速度较慢的Vault GUI。大多数现有的工具都是为与文件系统上的文件交互而设计的。因此，使用vimdiff等工具现在需要额外的步骤，包括登录、获取机密、将其转换为文件，以及在完成后删除文件。）
4. 默认实现有一个安全漏洞，该漏洞的安全代价很高。（如果有人获得了对Vault服务器的root访问权限，他们可以通过内存转储来获得主解密密钥。在Kubernetes或Cloud VM上托管Vault会带来更多获得root访问权限的机会。为了完全降低root访问的风险，您需要为计算机配备Intel Software Guard Extensions，并在SCONE Security Enclaves中的计算机上运行Vault服务器（在加密RAM中运行的容器）。增加这些将增加更多的基础设施和研究成本。Twistlock、Aqua或SysDig是部分缓解这种风险的替代选项。）

考虑到这些缺点，我决定更深入地研究，这项研究让我找到了Soluto的Kamus，在那里我被介绍了两个很酷的概念：GitOps和零信任秘密加密。这让我一跃成为加密技术的拉比。在旅程的最后，我想出了以下的心理图式。

密码学的简编进化

1.）对称加密密钥：

• 长密码用于加密和解密。

2.）非对称加密公私密钥对：

• 公钥加密数据，私钥解密用公钥加密的数据。

3.）HSM（硬件安全模块）：

• 确保私钥不会泄露。
• HSM很贵。
• HSM对用户或自动化都不友好。

4.）云KMS（密钥管理服务）：

• KMS是一种受信任的服务，代表客户对数据进行加密和解密，它基本上允许用户或机器使用其身份(identity )而不是加密/解密密钥对数据进行解密。（客户端根据KMS进行身份验证，KMS根据ACL检查其身份，如果客户端具有解密权限，则客户端可以在请求中向KMS发送加密数据，然后KMS将代表客户端解密数据，并通过安全TLS隧道将解密后的数据发送回客户端。）
• KMS很便宜。
• KMS是通过REST API公开的，这使得它们对用户和自动化都很友好。
• KMS是非常安全的，它们使它可以在十年内不泄露解密密钥。
• KMS加密技术的发明引入了3个杀手级功能：
  • 在应对已知漏洞时：在KMS之前解密密钥泄露：你不能撤销解密密钥，这意味着你需要轮换几个解密密钥，用新密钥重新加密所有数据，并尽最大努力清除旧的加密数据。在完成所有这些工作的同时，您需要与管理层进行斗争，以获得批准，从而导致多个生产系统停机，最大限度地减少所述停机时间，即使您做得很好，您也可能无法完全清除旧的加密数据，如git历史记录和备份。KMS之后，身份凭据会被泄露：身份凭据可以被吊销，当它们被吊销时，它们就毫无价值了。重新加密数据和清除旧的加密数据的噩梦消失了。您仍然需要轮换机密（身份凭据与解密密钥），但轮换行为变得足够便宜，可以作为预防措施进行自动化和调度。
  • 加密数据的管理从涉及分布式解密密钥的不可能的任务转变为管理集中式ACL的琐碎任务。现在可以轻松地撤销、编辑和分配对加密数据的细粒度访问；另外，由于云KMS、IAM和SSO身份联合会集成在一起，您可以利用预先存在的用户身份。
  • 加密锚定（Crypto Anchoring ）技术成为可能：
    • 可以将网络ACL应用于KMS，使其能够在您的环境中解密数据。
    • 可以监测KMS解密速率的基线，当发生异常速率时，可以触发警报和速率限制。
    • KMS的解密密钥可以通过HSM进行保护。
    • 解密密钥被泄露的机会几乎为零，因为客户端不直接与解密密钥交互。
    • 云提供商可以雇佣最优秀的安全专业人员，并实施昂贵的操作流程，这些流程是保持后端系统尽可能安全所必需的，因此后端密钥泄漏的机会也几乎为零。

我对高级加密技术的新理解使我意识到KMS可以用来防止解密密钥泄露。再加上无需对加密文件进行任何更改即可撤销解密权限的能力，使Git中真正安全的加密文件成为现实。我重新审视了一些我之前拒绝的基于Git的加密解决方案，发现Mozilla SOPS满足了我理想的秘密管理解决方案的所有标准。它还与CICD管道工具很好地集成：有一个SOPS Terraform Provider，Helm Secrets只是SOPS的包装器，您总是可以回退到：

Bash# sops --decrypt mysecret.yaml | kubectl apply -f -

（其中kubectl可以是任何接受标准输入的CLI实用程序（-））SOPS没有其他基于Git的加密解决方案的缺点：其他基于Gits的加密方案的一个亮点是，有人可能会意外地将解密的秘密推送到Git repo。使用SOPS，当你想编辑一个文件时，文件会在磁盘上加密，在RAM中解密，在那里你可以用vim编辑它，当你保存编辑后的文件时，它会在写入磁盘之前重新加密。同时，它确实提供了快速解密一些文件的灵活性，因此您可以使用vimdiff这样的工具。SOPS没有Vault的缺点：它不需要基础设施，而且和KMS一样便宜。你可以很容易地设置它，培训几个人，并在一小时内编写一个自述文件，下面是一个设置和使用的简单示例：

Bash# aws kms create-key --description "Mozilla SOPS” | grep Arn

"Arn": "arn:aws:kms:us-east-1:020522090443:key/4882a19d-5a98-40ae-a1ad-a60423afbddb",

Bash# cd $repo

Bash# vim .sops.yaml

（创建一个名为.sops.yaml的文件，其中包含以下2行文本）

creation_rules:
- kms: 'arn:aws:kms:us-east-1:020522090443:key/4882a19d-5a98-40ae-a1ad-a60423afbddb'

Bash# sops mysecret.yaml

这将打开vim编辑器，以便您可以键入要存储在秘密中的内容。这个简单的命令用于创建和编辑文件。

Bash# cat mysecret.yaml

会给你看一个加密的yaml

Bash# sops --decrypt mysecret.yaml

将向您显示解密的yaml SOPS将使用存储在 ~/.aws 中的AWS凭据对KMS进行身份验证，这样您就可以在没有密码的情况下进行加密和解密。SOPS还会递归地查找.SOPS.yaml文件，这样它就会自动发现关于应该如何加密和解密东西的元数据，这有两个重要的后果：

• 首先，用户不必学习大量的命令或标志。
• 其次，可以将一个额外的.sops.yaml文件添加到表示生产环境或不同项目的子文件夹中，该.sops.yaml文件可以具有不同的加密/解密密钥。

您可以为不同的Cloud IAM用户授予每个KMS密钥不同的权限，以实现细粒度的访问控制。如果你担心有人删除你的AWS KMS密钥，你可以配置SOPS，这样数据就可以由AWS、GCP或Azure KMS解决方案加密或解密，这样你就可以保留一个很少有人能访问的辅助备份KMS。

SOPS鼓励工作流程模式，让生活更轻松。

• Devs可以将加密后的秘密存储在使用它的代码版本旁边并与之同步。秘密管理突然获得了git的所有好处：可审核的更改管理、通过拉取请求进行的同行评审、对秘密的编辑差异都很有意义，因为只有编辑后的值才会在编辑时更新，而整个文件都会重新加密，这也降低了合并冲突的可能性。
• 一致性和标准化总是让自动化和CICD管道开发变得更容易，这让运营人员感到高兴。SOPS允许将代码、配置和机密存储在一致的位置，这使得GitOps工作流更容易实现。
• Hashicorp Vault将很难实现其成为组织集中秘密存储库的目标，因为用户会发现它很难使用，devops会发现维护起来很麻烦，管理层可能会发现它成本高昂。
• 另一方面，SOPS使用起来很轻松，易于学习，维护成本低廉，并支持使生活更轻松的工作流程模式！这些因素加在一起意味着，只要有人能向组织推销，就不会有采用的障碍，这意味着整个组织更有可能加强安全态势。

这就是为什么KMS和Git的SOPS被严重低估的原因。我想澄清一下，这篇文章的目的并不是说Vault不好，你应该使用SOPS和KMS。我写这篇文章有三个原因：一，我喜欢教书。第二，我想指出Vault的一些缺点。第三，KMS和SOPS是一个被严重低估的惊人组合：似乎没有人知道它，我在研究过程中从未遇到过对这两者的正确解释，根据谷歌趋势，与Vault相比，对SOPS的搜索并不多。

我想在这篇文章的结尾说，我衷心建议大家学习SOPS、KMS和Vault。如果Vault很难，为什么要学习它，而使用KMS的SOPS可以轻松地完成同样的事情？真正的原因有两个：一，Vault在PKI和机密轮换方面是同类中最好的，这两项都是满足许多政府和银行安全合规标准所必需的。第二，Vault每年都变得更容易使用：社区已经将其视为一个明显的赢家，并将Vault支持添加到了几个产品中：Jenkins、证书管理器和Kubernetes。尤其是Kubernetes，它与Vault配合得很好，许多痛点都被抽象化和自动化，使它们能够顺利地结合在一起。Vault团队也有着良好的记录，致力于通过改进文档、提供一些IaC和响应社区的需求，使Vault随着时间的推移更易于使用：在社区制作了自动解封解决方案、后端存储迁移解决方案和第三方web GUI之后；Vault的开发人员决定将这些功能移植到开源版本中。有鉴于此，如果将来Vault的Transit Secrets Engine（Vault的KMS解决方案）能够与Mozilla SOPS顺利集成，我也不会感到惊讶。