背景

等保：所在公司有大量等保需求，厂商方案成本过高，尤其是众多小型项目，因此寻求一种纯软件的方式来实现，本来打算开源软件堆起来做个SOC封装个界面完事，但是实际交付后发现和业务的耦合性过低，安全策略很难把所有点都覆盖，所以希望做一个能借助等保使业务产生足够执行力的方案。

零信任：部分厂商零信任产品就是API网关，确实，信任边界需要一个从网络、网关、服务逐步推进取消的过程。但是安全和业务结合加深的话，势必会缩小潜在市场，增加交付成本，可能需要一种新的产品形态，既减小信任范围，同时能够和业务解耦。

碰撞：刚刚完成对自研产品的集中式架构改为托管式架构的工作，在业务推广中颇有成效，安全代理的稳定性已经被业务所信任，把安全的事情代理出去，业务不用分心出来担心安全问题，已成为共识，同时又保持合适的粘性，持续的体现价值，是本方案的底层目标。

需求分析

对等保要求的分析，相信其他文章已经说得非常详细，本文不再赘述。将相关要求和保护对象抽象为以下内容：

核心需求：

1. 表中“安全的方式”即满足等保的要求
2. 信任对象仅为参与者自身和物理绑定的可信硬件，其他任何关系（不同参与者之间、相同参与者之间）均不可信

设计思想

1. 以零信任代理的方式实现不同参与者之间的通信，封装为“代理流量”，所有流量访问关系在安全服务中心注册最小化开通，流量经过SSL双向认证保障完整性、机密性
2. 增强传统网关，支持透明转发“代理流量”，或普通流量转换“代理流量”，并支持“零信任负载均衡（类似暗网）”实现网络冗余和抗DDOS
3. 扩展服务端零信任代理，支持自适应主机安全、SSL卸载后的流量检测、API网关、运维审计
4. 为了支撑以上设计，安全服务中心需具有1中的通信注册（类似IAM），以及KM、PKI、SOC的功能

架构设计

一、系统总览

等保一体机主要组件

二、Operator Agent设计

双因素认证：

1. SSL证书，用于双向认证中的客户端认证，账号首次建立后邮件发送密文文件，初始化密码Center随机生成并保存，有效期24小时，每次登录后重新加密
2. 账号密码认证，由上级安全管理员创建，首次登录后强制修改密码

别名访问：

本系统注册别名*.sec由Agent写入系统代理PAC，所有本系统内各参与者互访的流量都通过Agent代理，别名解析由安全管理中心提供定制DNS解析服务。

业务流程：

三、Server Agent设计

Server的信任属性来自于Server运行服务的属性，它和人不一样，附加属性会带来风险，就像金库管理员如果是个机器人，那拥有打开金库权限的同时，他可以不被允许做其他任何事情，家庭、朋友甚至上厕所，尽可能实现最小化原则。安全管理员需要定义一个角色，限定这个角色的所有权限和关系网络，让服务自己来注册认领。

常规架构下，由运维人员部署服务，让某台机器的某个进程或服务成为一个角色；如果是容器架构，根据app name即可确定服务角色，或是定位其源自于hub上的特定镜像，甚至是源自于gitlab上的特定仓库。

Server Agent的单点故障问题，需要上层Gateway的负载均衡功能来解决。

四、Gateway Module设计

软件逻辑类似常规LB或Nginx，这里只给出网络架构图：

通过这种零信任负载均衡设计，解决网络冗余与高可用的同时，还能保障网络边界发生灾备切换时，比如DDOS攻击场景，业务层的会话保持也不受影响。利用Client的安全SDK还可以将CC攻击天生免疫。

五、Client SDK设计

主要实现定制的HTTP DNS解析和从PKI获取客户端证书，选配即可，不展开说。

六、Center设计

安全服务中心的需求已经比较明确，这里直接给出产品原型设计

关于开源

GitHub项目地址：https://github.com/userlxd/GlobalZT

代码只开了个头，设计先行开源，希望各位读者可以提出对设计的意见和建议，避免作者个人的思维局限。MVP版本计划于2020年12月25日发布，非工作时间编码，争取不鸽。

联系方式： 邮箱[email protected] 微信lllolllll