密钥安全那些事

借着此次上海公安数据库疑似泄密事件,好好梳理下项目中是如何确保密钥安全。密钥大多指 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

API网关那些事

一个典型的Web架构中,网关是一个很容易被忽略的东西,或者透明般存在,而在云原生的微服务架构中,网关被赋予了更多职责,也变得更为重要。

1、反向代理时代
说到反向代理,不得不提Nginx,开源版的Nginx也仅起到反向代理的作用,常用来根据Host,Path来路由到不同的服务,做Stream负载均衡,SSL终结等,流量基本是透传,所以在后端看来几乎透明。且通过配置文件进行管理,一旦服务多了,难以维护。优势也就占用资源少,性能强悍。

2、边缘网关时代
在云原生时代,微服务众多,接入设备复杂多样化,一些重复度高的动作就必须抽取出来,而这些琐碎放到网关在合适不过了,以Apigee Edge为例,支持公有云、混合云、私有云部署,不仅做到API管理,还支持客户端管理,顶级层级为APP(Mobile or Web),可配置访问凭证,第二层级为Products,可配置环境(SIT or PROD),授权给APP访问,第三层级为API Proxies,即下面详解的API管理,绑定到Products,三层按顺序均为一对多关系,可参考OAuth2授权模式之密码模式。

API Proxy主要抽象出几个概念:

1、代理端点(Proxy Endpoints)
2、目标端点(Target Endpoints)
3、策略(Policies)
4、资源(Resources)

代理端点用来定义一个API,并对外暴露,主要与客户端打交道,目标端点则可以是后端微服务,也可以是公网上的另一个API,API支持环境区分部署,版本管理。

策略则是Apigee精华所在,策略是对请求做处理的最小单元,例如定义一个策略对参数进行校验、再定义一个对user&app token校验等,甚至执行js&java lib进行加解密等更为复杂的逻辑。策略通过Flow(处理流)来规定执行条件和执行顺序,一旦命中则跳过后续Flow。多个Flow又可以组成Shared Flows,以便复用。同样Flow也支持环境区分部署,版本管理。

资源则是放置js脚本或者java lib的地方,供策略调用。策略支持分环境来部署,支持版本切换,而这一切都是动态实时的,无需重启reload。

这样一来,到达backend的请求就已经是符合要求的了,可以省去很多的判断。

这里继续介绍一下策略,策略实质上是通过xml来定义,可分以下几种:
1、流量管理,例如Quota、Spike Arrest等,内置了数十种对流量进行管理的策略。
2、安全管理,例如Basic Authentication、OAuth、LDAP、JWT、HMAC等,同样内置了十分丰富,涵盖大部分场景。
3、协调与扩展,例如内置的XML&JSON格式互转。其中用的比较多的主要以下三个,可以非常灵活的将多个backend请求组合成一个API。
3.1、AssignMessage 请求管理
3.2、ServiceCallout 外部服务调用
3.3、ExtractVariables 解析响应

Apigee使用几个月来,初期学习成本比较高,但很多配置都是复用的,后续维护并不算太难。当然有了如此强大的功能,还有配套的trace工具,可视化的看到每一个请求的执行情况、入参和出参、请求头、策略命中与结果等,非常人性化,Apigee简单介绍到此,更详细请查阅官方文档,后续再对比一些开源方案。

文档地址:https://docs.apigee.com/api-platform/get-started/get-started