机密蔓生的危害及其治理

当我们讨论信息安全时，不论是身份认证、权限控制、数据加密，一个绕不过去的核心问题就是对机密的管理。何谓机密？所谓机密就是用以代表某个特定身份来执行认证与授权管理的信息，举例来说，数据库的账号密码是机密，调用 API 的令牌(Token)是机密，用来认证服务器与客户端身份的证书是机密，加解密关键数据的密钥也是机密。对机密的管理和保护必然是信息安全体系中的核心，是重中之重，外部攻击者一旦获取到机密信息就可以冒充合法程序和用户，对系统安全和数据安全造成严重威胁。

机密蔓生的问题

何谓机密蔓生(Secret Sprawl)？其实在传统的研发场景中我们经常能够看到这样的问题：生产环境的数据库用户名密码被以明文形式编码在配置文件中，或是保存在生产环境中某个不设防的配置管理服务中；某个应用调用云服务接口所用的令牌被硬编码在代码里，随后不小心被程序员上传到一个公共的 Github 仓库中等等。

机密蔓生描述的就是这样的问题，系统机密信息被零散地以不同形式保存在许多彼此不相关的地方，我们即不知道哪些系统保存了哪些机密，也不知道哪些机密被哪些系统哪些人获取了。即使我们发现某个机密信息流失在外，我们也无法回溯该机密信息是何人申请使用，何人泄漏，我们也无法确信立即从生产环境中吊销该机密不会导致生产环境的故障，因为我们不知道哪些系统正在使用这些机密。

机密蔓生引发了一连串的严重问题，导致我们既不能事前防备机密泄漏，也无法事后快速响应进行损害管制。

针对机密蔓生的治理

治理机密蔓生问题最有效的手段就是集中管理机密。

DevOps 运动、持续交付(CI)以及基础设施即代码(Infrastructure as Code)都强调要建立生产环境的单一事实来源(Single Source Of Truth)，也就是生产环境的一切都源自于同一个源头，最佳实践是源自于某一个 Git 仓库中的代码。坚持对生产环境的变更只能通过对这个 Git 仓库提交代码变更来实现，我们可以把对一个复杂系统的治理限制为对有限个代码仓库的变更管理。

管理机密问题，杜绝机密蔓生也是一样的思路，建立机密的单一事实来源，这个单一事实来源可以是目前公有云平台普遍提供的密钥管理服务(KMS)，也可以是像 HashiCorp Vault 这样的开源、多云平台的软件。坚持所有的机密信息都是从单一事实来源获取，并且使用工具链确保单一事实来源中管理的机密发生变更时能够及时通知相关的合法应用更新机密信息，同时对谁有权使用什么样的机密、谁正在使用这些机密，某个机密是谁申请的这些信息进行集中管理，可以有效治理机密蔓生问题。