【数据安全】秘密管理指南——方法、开源工具、商业产品、挑战和问题

保密管理是个难题。有许多不同的方法和工具，以及该领域的新创新。因为我们非常关注CryptoMove的这一新兴领域，所以我们将这篇帖子作为一种资源，提供给任何正在思考或试图了解更多秘密管理的人。如果这是您感兴趣的领域，我们现在正在为CryptoMove的Tholos Key Vault运行私人测试版，我们正在招聘！

• 概述
• 一、无工具的默认秘密管理方法
• 二、为什么秘密管理很重要
• III、 机密管理的选项、工具和商业解决方案
• IV、 秘密管理的主要目标（双关语）
• 五、保密管理面临的挑战

一、默认秘密管理办法

通常，机密管理默认为最简单、最快的。当开发人员在AWS、GCP、Azure或其他云原生环境中共同开发映像时，这种情况并不少见。PEM文件、SSH密钥和其他配置机密以明文形式通过各种通信通道传递。一些最流行的“反模式”：

• Email
• Slack
• GitHub
• Hard-coding
• Clear text config files
• Unencrypted laptop filesystems

有很多例子表明，默认的“快速而简单”的秘密管理和共享方法导致了devops和云转换的问题。

二、为什么秘密管理很重要

由于基础设施和软件开发过程的变化，秘密正在广泛扩散。以下是企业转型影响大规模机密管理的几种方式：

• 云原生开发和多云基础设施。导致秘密激增。随着团队开发云原生应用程序，存储、计算、分析、日志记录和数十种其他服务的秘密变得非常重要，需要共享和管理。AWS仅拥有近100个服务（如果不超过100个的话），所有这些服务都需要通过秘密进行中介，包括API密钥、SSH密钥、令牌、证书和配置。
• 机器身份和机器对机器的通信与用户身份一样重要，甚至更重要。在传统的企业架构中，人类用户是关键。人的身份对于访问文档、电子表格、电子邮件和其他工具非常重要。然而，现代企业通常有数以万计的基于机器的身份，需要通过令牌、API密钥、证书和其他机密进行管理和中介。自动化和AI/ML将继续从人类用户身份向基于机器的身份转变。
• 基于DevOps流程和微服务的架构也导致了秘密的扩散。正在进行DevOps转换的团队行动迅速，并管理许多不同的基础设施环境和服务，以进行开发、测试、集成和部署。DevOps环境的秘密管理作为安全软件开发生命周期的一部分至关重要。
• 人工智能和数据分析也为这些管道带来了许多需要管理的秘密。
• 物联网、机器人和嵌入式设备的激增导致了秘密的激增，因为每个物联网端点都需要加密和证书。
• 企业中的区块链项目也会产生比应用程序中通常使用的更多的私钥。现在需要一个“企业钱包”来管理所有这些私钥。

许多主流的《全球2000强》和《财富》500强企业在这方面落后了，他们坚持使用专注于加密密钥的传统HSM，并在基于多云和服务的架构中努力管理机密。

但是，为什么HSM和传统的加密密钥管理产品不能用于现代秘密管理呢？

在某些情况下，还有用于加密、数据库甚至云服务的遗留密钥管理产品。许多团队遇到的困难是，当这些遗留工具用于devops和云基础设施相关密钥时，如API密钥、pem文件、微服务机密、令牌和其他密钥。我们看到了能力上的差距，由于各种原因，他们无法满足这些需求。以下是我们在与开发现代基于云的devops工作流的团队交谈时收集到的遗留密钥管理解决方案的一些挑战：

• 重点关注加密和PKI相关密钥和证书，而不是真正的API密钥
• 没有云原生架构
• 不是为DevOps流程构建的
• 缺乏使用多云服务生成和轮换动态机密的能力
• 缺乏容器和微服务的能力

CyberArk是一家老牌公司试图填补其产品漏洞的例子。他们实际上购买了一个名为Concur的开源秘密管理工具来增加这一功能。以下是CyberArk宣布收购Concur的方式：

CyberArk旨在利用收购Congur的成果，提供一个“企业级、自动化的特权账户安全和机密管理”平台，以确保DevOps生命周期和云原生环境的安全，从而彻底改变DevOps的安全性。这很好。由于DevOps实践，特权帐户凭据（SSH密钥、API密钥等）在整个IT基础设施中激增。CyberArk收购了Concur，试图训练和驾驭这匹软件开发的野马。

其他传统的密码和密钥管理以及加密供应商没有解决这一能力差距，因此他们在某种程度上落后于8球。

云基础设施和devops的秘密管理能力存在这种差距，这就是为什么许多公司在内部构建了自己的秘密管理工具，并有助于解释为什么有这么多开源方法——如下所示。这种针对秘密管理问题的多种开源解决方案的现象表明，对于现代开发组织来说，这是一个相当大的痛点。

III、 机密管理选项

目前还没有真正的行业标准，因为在这个领域一切都还很早。在CryptoMove，我们正在开发一种企业可扩展的秘密管理解决方案，该解决方案利用了移动目标防御技术。稍后会详细介绍。

由于缺乏太多现成的解决方案，许多公司都试图构建自己的秘密管理工具。以下是一些：

Square — Keywhiz

Keywhich是Square制造的一种工具，在生产中运行了一段时间。它具有许多用于存储和管理应用程序和基础结构机密的功能。Square对Keywhich的描述如下：

“Keywhich使管理机密变得更容易、更安全。群集中的Keywhich服务器将加密的机密集中存储在数据库中。客户端使用相互身份验证的TLS（mTLS）来检索他们可以访问的机密。经过身份验证的用户通过CLI管理Keywhich。为了启用工作流，Keywhich通过mTLS提供了自动化API。”

Pinterest — Knox

Pinterest还建立了自己的秘密管理工具并开源，称其为Knox（如在Fort Knox）。以下是Pinterest面临的问题，这些问题导致了Knox的创建：

“Pinterest有大量的密钥或秘密，比如签名cookie、加密数据、通过TLS保护我们的网络、访问我们的AWS机器、与第三方通信等等。如果这些密钥被泄露，请旋转（或更改我们的密钥）过去是一个困难的过程，通常涉及部署和可能的代码更改。Pinterest中的密钥/机密存储在git存储库中。这意味着它们被复制到我们公司的所有基础设施上，并出现在我们许多员工的笔记本电脑上。无法审核谁访问或谁有权访问密钥。诺克斯就是为了解决这些问题而建造的。”

根据Pinterest，Knox的目标是：

“便于开发人员访问/使用机密机密、密钥和凭据

机密、密钥和凭据的保密性

在出现折衷的情况下，提供钥匙旋转机制

创建审核日志以跟踪哪些系统和用户访问机密数据”

Lyft--Confident

Lyft的秘密管理方法产生了一种名为Confident的工具。Lyft在描述中简洁而甜蜜：“你的秘密守护者。将秘密存储在DynamoDB中，在休息时加密。”

在描述Lyft试图与Confident解决的问题时，Lyft解释说，有了所有新的内部和外部服务，追踪密钥和秘密变得非常困难：

“随着Lyft的发展，我们在基础设施中添加了许多服务。这些服务具有内部服务和外部服务的凭据、SSL密钥和其他类型的机密。这些服务中的每一个都有多个环境，为了使这些环境相互隔离，它们为每个环境都提供了这些机密的一个版本。在许多情况下，其中一些机密可能可以在几个服务之间共享。给定大量的服务，这将导致大量的凭据。

这些秘密的轮换可能是一个费力的过程，尤其是外部服务的凭据，因为大量外部服务没有轮换方法，而这些方法可以在没有一定停机时间和协调的情况下完成。机密轮换的协调在很早的时候就成为了一个困难而耗时的过程，我们知道随着我们增加更多的内部服务和更多的外部依赖，问题只会变得更糟。”

以下是《黑客新闻》对Confident的讨论，有很多有趣的反馈和赞美。

许多其他科技公司已经尝试或正在尝试创建自己的秘密管理工具。说出一家大型科技公司的名字，他们可能正在做这项工作。更主流的《财富》500强或《全球2000强》公司通常还没有意识到这个问题，但随着他们越来越多地转变基础设施和软件交付模式，他们很可能会遇到导致Keywhich、Confident、Knox等公司成立的同样问题。

其他开源解决方案

除了Lyft、Pinterest、Square内部构建的秘密管理工具之外，还有其他开源的秘密管理解决方案（以及我们在其他大型科技公司了解到的许多其他不向公众开放的解决方案）。其中包括Docker、Hashicorp的机密管理产品，Torus、Credstash、Sneaker等工具，以及AWS、Azure和谷歌的可用于机密管理的通用工具，其复杂程度各不相同。

Docker机密

Docker秘密管理是一种较新的秘密管理工具。巧合的是，它是由一些在Square Keywhich工作的重叠人员设计的。以下是Docker如何描述这个问题，以及为什么传统的静态秘密管理工具或加密密钥管理产品无法处理这些问题：

“构建更安全的应用程序的一个关键因素是与其他应用程序和系统进行安全的通信，这通常需要凭据、令牌、密码和其他类型的机密信息，通常被称为应用程序机密。我们很高兴推出Docker secrets，这是一个容器本机解决方案，可以增强容器的Trusted Delivery组件通过将秘密分发直接集成到容器平台中来实现安全性。

有了容器，应用程序现在可以在多个环境中动态和可移植。这使得现有的秘密分发解决方案不足，因为它们主要是为静态环境设计的。不幸的是，这导致了对应用程序机密管理不善的增加，使得人们很容易找到不安全的、自主开发的解决方案，例如将机密嵌入到GitHub等版本控制系统中，或者其他同样糟糕的事后解决方案。”

以下是Docker secret如何工作的架构图：

以下是Docker机密如何用于管理环境变量以及AWS凭据的示例。更多关于Docker机密的文档可在此处获取。

Vault by Hashicorp

Hashicorp是一家拥有许多产品的开源软件公司，最出名的可能是其Vagrant和Terraform等产品，还有一款名为Hashicorp Vault的秘密管理产品。New Stack在这里发布了一个关于Hashicorp Vault优缺点的良好概述，其中讨论了在外部工具中管理秘密与环境变量相比的一些好处，在Hashicorp生态系统中运行良好，以及API集成的好处。

Hashicorp Vault和《新堆栈》中的Keywhich之间还有一个有趣的比较：

虽然以上所有内容都很好——就像软件的典型情况一样——但Vault的设计中进行了某些权衡，并且存在一些局限性。虽然将Vault作为一项服务运行有很多好处，但这确实会增加基础架构成本，并带来管理该基础架构的相关痛苦。此外，并非Vault的所有优点都适用于所有使用情况。例如，动态生成的机密只能与数量有限的其他服务集成。此外，Keywhich by Square是该领域另一个值得关注的大玩家。Vault和Keywhich之间最大的根本区别在于，虽然Vault通过API公开秘密，但Keywhich使用FUSE文件系统。Vault在比较中写了一篇不错且相当客观的文章。最后，如果您使用的是Chef或相关工具，最初使用他们的集成解决方案可能比将其连接到Vault更容易。

由于维护和维护Hashicorp Vault基础设施的复杂性，有相当多的指南和教程。许多公司最终聘请顾问或签订专业服务合同，作为其Hashicorp Vault推出的一部分。这里有一个方便的最佳实践指南和教程：

你有没有安装过Hashicorp Vault，并想知道：“我真的在保护我的组织吗？”你并不孤单。虽然安装Vault很容易，但确保其配置正确以提高生产效率和安全性可能是一项具有挑战性的任务。我建立了相当多的指南和网络研讨会，最近也经常与Vault合作。这使我创建了自己的Vault最佳实践列表。

其他工具包括T-Mobile创建的一个名为“T-Vault”的工具，该工具使用了与Hashicorp Vault的一些集成，并添加了各种企业功能。一位CISO最近在一篇帖子中评论了Hashicorp Vault与CryptoMove的Tholos Vault的比较：

如果你正在使用或正在考虑使用Hashicorp Vault，你应该看看Cryptomove。作为一家早期的初创公司，该产品似乎非常成熟。不断移动密钥和数据的概念非常有趣，我无法在LinkedIn上发表一篇简短的帖子。

Torus

Torus 是另一个秘密管理工具。它采取托管的方式，同时开放客户资源。这里有一个有趣的HN关于Torus的讨论。

Credstash

Credstash是一个非常有趣的分布式凭证管理系统，它建立在AWS KMS之上。以下是它如何描述它试图解决的问题，以及它对秘密管理工具箱的轻量级方法：

软件系统通常需要访问某些共享凭据。例如，您的web应用程序需要访问数据库密码或某些第三方服务的API密钥。

一些组织构建了完整的凭据管理系统，但对我们大多数人来说，管理这些凭据通常是事后才想到的。在最好的情况下，人们使用像ansible vault这样的系统，这做得很好，但会导致其他管理问题（如主密钥存储在哪里/如何存储）。许多凭证管理方案相当于SCP将机密文件发送给车队，或者在最坏的情况下，将机密刻录到SCM中（对密码进行github搜索）。

CredStash是一个非常简单、易于使用的凭据管理和分发系统，它使用AWS密钥管理服务（KMS）进行密钥封装和主密钥存储，使用DynamoDB进行凭据存储和共享。

Sneaker

Sneaker是一款使用AWS KMS和S3创建轻量级机密管理功能的工具：

sneaker是一种使用S3和密钥管理服务（KMS）在AWS上存储敏感信息的实用程序，以提供耐用性、机密性和完整性。秘密存储在S3上，使用AES-256-GCM和一次性KMS生成的数据密钥进行加密。

这里对各种开源秘密管理解决方案和工具进行了非常全面和有用的比较。除了工具的比较之外，这位提供微服务和云架构咨询的作者还提出了一个思考秘密最佳实践的好方法：

• 任何秘密都不应该以明文形式写入磁盘——永远
• 任何秘密都不应该以明文形式通过网络传输——永远
• 所有机密生命周期和访问事件都应记录在不可篡改的审核日志中
• 秘密分发应由权威委托人（如容器/服务调度程序）协调，或与调度程序建立密切信任关系
• 如果没有颠覆性的努力，操作员对秘密明文的访问应该受到限制——如果不是不可能的话
• 秘密版本控制或滚动应该比揭示明文更容易实现
• 与秘密管理和分发相关的所有基础设施组件都应相互验证
• 安全的系统配置应该比高级的、可能不安全的配置更容易
• 机密到服务或容器的附件应该受到丰富（可插入）访问控制机制的保护——基于角色的访问控制是一个优势
• 应该做任何可以使秘密价值最小化的事情

每当一个空间中出现这么多开源项目时，这都是一个很好的迹象，表明许多开发人员、安全专业人员和软件组织都遇到了一个常见的问题。开源解决方案和工具往往是最先出现的。

云供应商方法

云基础设施供应商注意到，他们的用户和客户正在努力进行机密管理，并已开始开发自己的通用解决方案，如AWS secrets Manager、Azure Key Vault和下文所述的其他解决方案。在某些方面，这些产品让人想起亚马逊的Whole Foods 365“Lacroix杀手”或西夫韦著名的苏打水和其他自有品牌产品的“精选”品牌。在我们生活的云世界中，期望此类产品和其他产品的云通用版本出现似乎是合理的。

AWS

AWS Secrets Manager是一种工具，使AWS用户能够管理机密和凭据，而不是将其保存在磁盘上或使用KMS支持的凭据管理开源解决方案之一，如Sneaker。以下是AWS产品经理关于Secrets manager应该如何工作的视频：

https://youtu.be/Y3Gn_iP3FlE

reddit上有一个关于AWS Secrets Manager和开源解决方案之一Hashicorp Vault之间比较的方便讨论。AWS Secrets Manager的一些限制（根据Reddit上Hashicorp的一位人士的说法）包括：管理员缺乏零知识、动态秘密生成、一键式/API调用证书生成、SSH CA授权、加密即服务、跨区域/云/数据中心复制、用于多人审批的控制组、可插拔架构等等。

AWS参数存储。AWS参数存储可以是另一种管理机密的方式，而无需使用secrets Manager。以下是如何设置AWS参数库进行机密管理的指南。

AWS-KMS。AWS KMS并不是一个真正的秘密管理工具，尽管使用KMS可以用加密来包装秘密，这就是上面引用的一些开源解决方案对KMS所做的。

Azure

Azure密钥库是一项服务，使客户能够在一个地方管理其云应用程序的所有机密（密钥、证书、连接字符串、密码等）。它与Azure中秘密的来源和目的地开箱即用地集成，但也可以由Azure之外的应用程序使用。

它是AWS KMS和AWS Secrets Manager的结合，两者都支持Azure中的加密服务，并管理非加密机密和凭据。以下是Microsoft如何描述Azure密钥库旨在解决的问题：

Azure密钥保管库有助于解决以下问题

• 机密管理-Azure密钥库可用于安全存储和严格控制对令牌、密码、证书、API密钥和其他机密的访问
• 密钥管理--Azure密钥库也可以用作密钥管理解决方案。Azure密钥库可以轻松创建和控制用于加密数据的加密密钥。
• 证书管理--Azure密钥库也是一项服务，可以让您轻松地设置、管理和部署公共和私有安全套接字层/传输层安全（SSL/TLS）证书，以便与Azure和您的内部连接资源一起使用。
• 由硬件安全模块支持的存储机密--机密和密钥可以由软件或FIPS 140保护–2级验证HSM

以下是微软产品经理在Azure Key Vault上的视频，描述了它的工作原理：

https://youtu.be/fVSYaFhMA5Y

谷歌

谷歌有加密密钥管理服务，但缺少秘密管理器产品。在谷歌云中，最接近的方法是使用KMS将机密进行加密，然后使用其他GCP服务将机密存储在其他地方。以下是谷歌关于如何做到这一点的文档。此外，这里还有一个有趣的教程，介绍如何使用谷歌云平台服务的组合在无服务器应用程序架构中存储机密。谷歌也有一个关于如何存储秘密的通用指南，从存储到代码本身（这是个好主意吗？）。

专注于这一领域的新兴创业公司

除了开源工具和云供应商产品外，还有一些初创公司专注于在密钥和机密管理领域构建产品。

• Envkey是YCombinator最近推出的一家初创公司。它具有良好的UI和UX，比大多数更专注于CLI和API的机密管理产品要好。
• UnboundTech （原名Dyadic）总部位于以色列。他们使用多方计算进行密钥管理，并得到包括花旗银行和高盛在内的战略投资者的支持。
• Fortanix 称其技术为“SDKMS”或软件定义的密钥管理系统。它与Equinix数据中心公司高度集成，基于英特尔SGX技术（也得到英特尔作为战略投资者的支持）。

CryptoMove如何适应这一切？

在CryptoMove，我们从移动任何类型数据的目标数据保护技术开始。随着底层技术的产品化，我们已经看到了各种用例的原型，从保护密钥、机密、文件、数据库，甚至是无人机群中的直播视频或数据，到相机或传感器等嵌入式设备，再到机器人。

然而，在与《财富》100强中的许多早期设计和研发合作伙伴以及国土安全部、NIST等联邦机构合作后，我们意识到，到目前为止，CryptoMove最常见的第一个用例是试图将我们的技术应用于密钥和机密管理。有了这些学习，我们花了一年多的时间与数百个安全团队、devops团队、开发人员、CISO和其他人进行了交谈，以了解现有关键和机密管理工具和流程的痛点，尤其是应用于多云、微服务和物联网基础设施的痛点。

根据我们所了解的情况，我们一直在开发一款云原生SaaS机密管理产品，我们称之为CryptoMove Tholos（Tholos在希腊语中是Vault的意思），其背后隐藏着移动目标数据保护技术。更多信息可以在我们的网站上找到，我们将继续写博客。

IV、 密钥和机密管理人员及金库的重要目标

无论是商业解决方案、开源项目还是自主开发的工具，密钥和机密管理器以及密钥库都有一些共同的目标。

• 秘密管理。当然，秘密生成、轮换、撤销、分配和共享的基本任务很重要。在拥有许多内部和外部服务的现代软件组织中，这些过程通常是费力的。重要的是，秘密管理工具可以使与处理秘密相关的过程变得简单和有组织。
• 身份验证和机器标识。重要的是，机密管理工具具有全面且可访问的API。在现代devops和云原生工作流中，机密管理最常见的用例是对应用程序组件和服务进行身份验证。特别是在服务和业务流程日益自动化的情况下，通过机密管理进行机器对机器身份验证和身份验证至关重要。
• 秘密的存储。这是一个实际上没有太多创新的领域。如今，大多数机密工具都专注于库存以及生成和轮换策略。就密钥和秘密存储而言，最常见的做法是将密钥放入数据库、存储或其他后端，并进行加密。在这里，移动目标防御、碎片化和密钥秘密的分散或分布式存储可能是一种有趣的方法。
• 机密管理基础设施的可靠性。秘密不仅应该有良好的组织、库存、可访问和存储，而且还应该在一个高度可用和有弹性的系统中进行管理。

V.devops/云转换中的机密管理面临的挑战

正如Square、Lyft、Pinterest、T-Mobile和其他公司的例子所示，秘密管理是许多组织遇到的一个问题。除了管理基于云和服务的系统的机密的一般问题之外，组织在机密方面面临的具体挑战是什么？

• 优先级。在一些组织中，仅仅优先考虑机密管理是一项挑战。问题是否会发生并不总是很清楚，尤其是如果安全团队更多地参与公司安全和端点安全，而不是安全软件开发生命周期。许多组织仍然在HSM是唯一选择的框架中运作，加密密钥通常是唯一真正考虑的秘密。通常，这是由于基于云或服务的转换仍处于早期阶段。
• 多基础设施方法。跨基础设施的保密管理可能是一项挑战。组织是否会使用AWS Secrets Manager来管理与Azure存储相关的机密？还是AWS相关机密的Azure密钥库？一些开源密钥和机密管理解决方案可能是一种多云方法，以及企业SaaS保险库。
• 可扩展性和协调性。自动调整机密管理基础设施的规模非常重要，尤其是在服务大规模运行的情况下。机密管理工具还应该与devops堆栈的其他部分以及安全堆栈中的其他工具协调良好。
• IAM集成。秘密管理工具应该与各种身份验证选项集成，如Okta、OneLogin、Active Directory、AWS IAM角色等。在CryptoMove，我们已经与之前列出的一些以及我们喜欢的Auth0进行了集成。
• UX/UI。好的API对机密管理很重要，但正如我们交谈过的许多团队所看到的，好的UI和UX也非常重要。并不是所有的密钥和机密都可以通过编程生成，尤其是在某些遗留系统中。为管理员和策略创建提供一个坚实的接口非常重要。由于一些开源工具并没有过多地关注UI，某些开发人员已经尝试在顶部制作自己的UI。它们并不总是得到完全支持，但可以通过一点创造性的GitHub搜索找到。
• 信任的根源。如何启动秘密管理系统本身一直是一个经典的“海龟”问题。在去年的2017年谜机大会上，网飞公司就如何处理海龟问题进行了精彩的讨论。最终，会有一些信任的根源，无论是HSM、用于解封的Shamir秘密共享、多方计算，还是可能的其他方法。

https://youtu.be/15H5uCj1hlE

• 谁拥有它？DevOps还是Security？组织中秘密管理的责任和所有权往往不是一个容易回答的问题。通常，devops团队和实际工程师正在处理与测试、集成和部署相关的工具和流程。安全团队通常参与体系结构、监控、跟踪和安全意识。开发人员会管理自己的秘密吗，还是安全团队应该管理这些秘密？两者兼而有之？我们已经看到一些组织在秘密管理中大量涉及安全，而有些组织则不然。
• 发现。仅仅知道所有的秘密在哪里是一个非常困难的问题。许多组织都在围绕机密进行资产盘点，这使得了解机密攻击表面并对其进行风险建模变得困难。
• 审计和使用情况跟踪。了解何时使用和访问机密在事件响应场景中很有帮助，也有助于发现内部威胁。之前在Square建立Docker机密管理器的工程师们讨论了“加密锚定”的想法，以使这里的过滤更加困难。以下是加密锚定的视频解释：

https://youtu.be/lrGbK6fE7bI

Developers who worked on secrets management at Square & Docker explain their approach

基础设施设置和管理。任何在开发过程中使用少量云服务或内部服务的组织都有秘密需要管理。但并非所有组织在维护和维护机密管理基础设施方面都拥有相同水平的资源。应该如何设置？作为SaaS服务？单独在不同的环境和基础设施中？需要团队还是服务？这些都是重要的问题，可能取决于项目和组织类型。

思考机密管理时要问的问题

与任何技术转型浪潮一样，在秘密管理之旅的各个阶段都有一个成熟的组织模型。无论组织处于成熟度模型和云原生/devops转换的哪个阶段，在设计、实施、升级或优化机密管理工作流程和基础设施时，都需要考虑一些有用的问题。

• 秘密现在在哪里？他们今天是如何管理的？
• 我们想要管理哪些秘密？云服务？云原生应用程序？容器和微服务？数据分析和数据湖？传统数据库？物联网？加密或区块链应用程序的私钥？
• 用户将是谁？安保团队？Devs？管理员？
• 如何管理机密管理基础设施？有一个敬业的团队吗？作为服务托管？
• 是否需要UI或API？两者的结合？
• 什么是多云或多基础设施机密管理策略？云服务提供商的工具应该管理自己的秘密吗？一个组织是否应该通过多种工具传播秘密？基础设施？
• 现在还有哪些其他工具在管理秘密？有吗？目前团队中是否有秘密管理策略或意识？
• 秘密的备份和恢复策略是什么？
• 组织应该利用开源工具还是以商业企业为中心的工具，或者两者结合？
• 秘密是如何保密的？除了管理，秘密实际上是如何得到保护的？在存储中？在数据库中？其他方式？
• 谁应该有权接触这些秘密？这可能是一个复杂的问题，对于不同的工作流程或机密，答案各不相同。
• 什么政策应该适用于秘密管理？如何跟踪版本？撤销？基于时间的政策？

随着向云原生、服务和物联网基础设施的转型，机密管理是一个复杂而新兴的问题。从Square、Pinterest、Lyft等许多最先进的科技公司可以看出，每一个现代软件组织在机密管理方面都会遇到困难。

机密管理令人兴奋的是，它位于数据安全和应用程序安全的交叉点，为思考风险管理和威胁建模攻击表面开辟了新的途径。如果操作得当，大规模的秘密管理可以加速围绕云和服务转换的业务流程变化。

有一点是明确的——在秘密管理方面，我们正处于曲线的早期，未来还有很大的创新空间。