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

  • A+
所属分类:安全新闻

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

 

背景

等保:所在公司有大量等保需求,厂商方案成本过高,尤其是众多小型项目,因此寻求一种纯软件的方式来实现,本来打算开源软件堆起来做个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日发布,非工作时间编码,争取不鸽

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

本文来源于互联网

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: