密钥安全那些事

借着此次上海公安数据库疑似泄密事件,好好梳理下项目中是如何确保密钥安全。密钥大多指 Key-Value 键值对、公私钥、Token 等,从早期的代码中硬编码,到配置文件硬编码,再到各种的配置中心的诞生,例如:携程 Apollo 或者 HashiCorp Vault。不断的演变进化中,安全性与灵活性也极大的提高。

硬编码时代:密钥控制权将完全由开发者决定,一旦代码泄露则密钥也一并泄露,即便泄露不是源代码,而是编译后的 Class 文件,Jar、War 包等也是可以轻松反编译得到源码,所以是最不可靠的方案,实际项目中应绝对禁止,且应在 CI 流程中加入 Checkmarx SAST 检测告警,以避免疏忽大意而导致泄露。配置文件只可存放用于测试的配置,例如连接本地数据库的用户密码,在 CI 流程中进行动态替换,这样一来,密钥则可交由运维人员来管理,与开发者完全隔离。

微服务时代:随着配置项的增多,管理职权分离后,密钥如何存储,更新,授权,管理等一些列问题也孕育而生。携程 Apollo 则是一个较好的解决方案,目前也是国内项目大多数的选择。自身的稳定性,灵活性都还做的不错,有着不错的 Web UI,与 Spring Boot 集成也非常简单。

云原生时代:随着 Kubernetes 的加入,DevOps 发生了较大的变化,对容器而言,推荐使用 Secret 和 ConfigMap 来存放密钥和键值对。同时众多角色的加入,如何安全存放密钥、安全使用密钥以及更好的与基础平台整合,对密钥管理又提出了更高要求。HashiCorp Vault 则是不二之选,通过一套复杂的加密机制可以确保在公有云上能够安全的存储机密信息,在 CD 流程中拉取密钥挂载到容器中使用,对服务来说可以做到完全透明,缺点是无法实时更改。

当然除了密钥需要正确保管外,环境有效隔离才是最后一道屏障,面对层出不穷的数据泄密事件,无论是有意还是无意,黑客行为,或许应该思考本身是否有必要收集和存储?去中心化的互联网架构或许是未来的出路?

docs:

https://www.vaultproject.io/docs/what-is-vault

本文链接地址:https://dorole.com/2202/

来自:Dorole's Blog

发布者

Steve

编程/摄影

《密钥安全那些事》上有1条评论

  1. Pingback: key security – FENQ

发表回复

您的电子邮箱地址不会被公开。

:wink: :-| :-x :twisted: :) 8-O :( :roll: :-P :oops: :-o :mrgreen: :lol: :idea: :-D :evil: :cry: 8) :arrow: :-? :?: :!: