背景
等保:所在公司有大量等保需求,厂商方案成本过高,尤其是众多小型项目,因此寻求一种纯软件的方式来实现,本来打算开源软件堆起来做个SOC封装个界面完事,但是实际交付后发现和业务的耦合性过低,安全策略很难把所有点都覆盖,所以希望做一个能借助等保使业务产生足够执行力的方案。
零信任:部分厂商零信任产品就是API网关,确实,信任边界需要一个从网络、网关、服务逐步推进取消的过程。但是安全和业务结合加深的话,势必会缩小潜在市场,增加交付成本,可能需要一种新的产品形态,既减小信任范围,同时能够和业务解耦。
碰撞:刚刚完成对自研产品的集中式架构改为托管式架构的工作,在业务推广中颇有成效,安全代理的稳定性已经被业务所信任,把安全的事情代理出去,业务不用分心出来担心安全问题,已成为共识,同时又保持合适的粘性,持续的体现价值,是本方案的底层目标。
需求分析
对等保要求的分析,相信其他文章已经说得非常详细,本文不再赘述。将相关要求和保护对象抽象为以下内容:
参与者 | 本文代号 | 位置 | 需求描述 |
---|---|---|---|
运维人员所持PC | Operator | 通信(互联网、内网) | 需要以安全的方式登录Server以进行运维操作 |
客户终端 | Client | 通信(互联网) | 需要以安全的方式通过Gateway访问Server |
网关 | Gateway | 边界 | 需要以安全的方式实现流量转发、负载均衡 |
业务服务 | Server | 计算环境、通信(内网) | Server环境入侵检测、风险发现、审计 Server和Server之间以安全的方式的互相调用 |
安全服务平台 | Center | 管理中心 | 设置以上各参与者之间的通信白名单 数据汇总和可视化展现 PDDR自动化流程 |
核心需求:
- 表中“安全的方式”即满足等保的要求
- 信任对象仅为参与者自身和物理绑定的可信硬件,其他任何关系(不同参与者之间、相同参与者之间)均不可信
设计思想
- 以零信任代理的方式实现不同参与者之间的通信,封装为“代理流量”,所有流量访问关系在安全服务中心注册最小化开通,流量经过SSL双向认证保障完整性、机密性
- 增强传统网关,支持透明转发“代理流量”,或普通流量转换“代理流量”,并支持“零信任负载均衡(类似暗网)”实现网络冗余和抗DDOS
- 扩展服务端零信任代理,支持自适应主机安全、SSL卸载后的流量检测、API网关、运维审计
- 为了支撑以上设计,安全服务中心需具有1中的通信注册(类似IAM),以及KM、PKI、SOC的功能
架构设计
一、系统总览
等保一体机主要组件
组件 | 部署位置 | 用途 |
---|---|---|
Operator Agent | 运维人员所持PC | 运维、安全、审计等人员通过Agent实现Server运维和对安全服务服务中心的管理 |
Server Agent | 业务服务器 | 业务服务器主动与其他Server或互联网通信的正向代理 业务服务器被其他组件访问的反向代理 检测主机安全信息、事件、流量 |
安全服务中心 | 任意 | 授权组件之间互访权限,安全日志的汇总,向安全管理人员提供配置界面、大屏 |
Gateway Module | Gateway | 透明转发代理流量,或转换普通流量为代理流量 |
Client SDK | 客户终端 | 访问服务的正向代理 |
二、Operator Agent设计
双因素认证:
- SSL证书,用于双向认证中的客户端认证,账号首次建立后邮件发送密文文件,初始化密码Center随机生成并保存,有效期24小时,每次登录后重新加密
- 账号密码认证,由上级安全管理员创建,首次登录后强制修改密码
别名访问:
本系统注册别名*.sec由Agent写入系统代理PAC,所有本系统内各参与者互访的流量都通过Agent代理,别名解析由安全管理中心提供定制DNS解析服务。
业务流程:
三、Server Agent设计
Server的信任属性来自于Server运行服务的属性,它和人不一样,附加属性会带来风险,就像金库管理员如果是个机器人,那拥有打开金库权限的同时,他可以不被允许做其他任何事情,家庭、朋友甚至上厕所,尽可能实现最小化原则。安全管理员需要定义一个角色,限定这个角色的所有权限和关系网络,让服务自己来注册认领。
常规架构下,由运维人员部署服务,让某台机器的某个进程或服务成为一个角色;如果是容器架构,根据app name即可确定服务角色,或是定位其源自于hub上的特定镜像,甚至是源自于gitlab上的特定仓库。
Server Agent的单点故障问题,需要上层Gateway的负载均衡功能来解决。
四、Gateway Module设计
软件逻辑类似常规LB或Nginx,这里只给出网络架构图:
层级 | 源 | 目标 | 会话状态 | 高可用 |
---|---|---|---|---|
业务层 | 客户端 | Server | 由代理层解决会话保持、高可用 | |
代理层 | 客户端SDK | Server Agent | 有 | 不可用时重试至Server BackUp |
通信层 | 客户端SDK | Gateway Module | 无 | 不可用时重试至GW BackUp |
通过这种零信任负载均衡设计,解决网络冗余与高可用的同时,还能保障网络边界发生灾备切换时,比如DDOS攻击场景,业务层的会话保持也不受影响。利用Client的安全SDK还可以将CC攻击天生免疫。
五、Client SDK设计
主要实现定制的HTTP DNS解析和从PKI获取客户端证书,选配即可,不展开说。
六、Center设计
安全服务中心的需求已经比较明确,这里直接给出产品原型设计
关于开源
GitHub项目地址:https://github.com/userlxd/GlobalZT
代码只开了个头,设计先行开源,希望各位读者可以提出对设计的意见和建议,避免作者个人的思维局限。MVP版本计划于2020年12月25日发布,非工作时间编码,争取不鸽。
联系方式: 邮箱userlxd@qq.com 微信lllolllll
发表评论
您还未登录,请先登录。
登录