源海拾贝 | 基于零信任的等保一体机方案

阅读量    30463 | 评论 2

分享到: QQ空间 新浪微博 微信 QQ facebook twitter

 

背景

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

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

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

 

需求分析

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

参与者 本文代号 位置 需求描述
运维人员所持PC Operator 通信(互联网、内网) 需要以安全的方式登录Server以进行运维操作
客户终端 Client 通信(互联网) 需要以安全的方式通过Gateway访问Server
网关 Gateway 边界 需要以安全的方式实现流量转发、负载均衡
业务服务 Server 计算环境、通信(内网) Server环境入侵检测、风险发现、审计 Server和Server之间以安全的方式的互相调用
安全服务平台 Center 管理中心 设置以上各参与者之间的通信白名单 数据汇总和可视化展现 PDDR自动化流程

核心需求:

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

 

设计思想

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

 

架构设计

一、系统总览

等保一体机主要组件

组件 部署位置 用途
Operator Agent 运维人员所持PC 运维、安全、审计等人员通过Agent实现Server运维和对安全服务服务中心的管理
Server Agent 业务服务器 业务服务器主动与其他Server或互联网通信的正向代理 业务服务器被其他组件访问的反向代理 检测主机安全信息、事件、流量
安全服务中心 任意 授权组件之间互访权限,安全日志的汇总,向安全管理人员提供配置界面、大屏
Gateway Module Gateway 透明转发代理流量,或转换普通流量为代理流量
Client SDK 客户终端 访问服务的正向代理

二、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,这里只给出网络架构图:

层级 目标 会话状态 高可用
业务层 客户端 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

分享到: QQ空间 新浪微博 微信 QQ facebook twitter
|推荐阅读
|发表评论
|评论列表
加载更多