参考文章参考
https://cloud.tencent.com/developer/news/833071
一,什么是零信任
零信任就是对于网络中所有的业务流量默认认为都是危险不可信任的，而让其信任的最终方式是通过不断的认证，例如身份认证、终端环境认证、操作认证等方式来实现。
对于零信任的理解，总结以下几个要点：
- 网络中充满了威胁，不管是外部网络，还是内部员工，像以前对暗号那样，在没有充分展示可信信息之前，都是不能允许访问需求资源。
- 对于不同的对象，展示可信信息的方式也大相径庭。例如对于人来说，可信信息包括账号认证、生物特征认证等；对于终端来说，可信信息包括系统安全性检测、系统脆弱性检测等。
- 风险、信任是零信任中最重要的要素，风险代表着访问对象威胁性，信任代表着访问对象安全性。两者判断方式是通过持续性的认证、检测来实现，例如在用户访问信息资源时，当出现异常操作时，进行身份认证。
- 每个访问者遵循最小权限原则，对应用系统的访问操作需要精细化到具体操作步骤，例如请求提交、文档修改
零信任核心原则
企业基于持续验证，动态授权和全局防御三个核心原则构建自己的零信任网络。
二,为什么使用零信任
随着数字化转型不断加速，新兴技术与创新业务不断打破企业原有安全边界，企业信息安全面临着前所未有的挑战。
- 访问者身份及接入终端的多样化、复杂化打破了网络的边界，传统的访问管控方式过于单一。在用户一次认证后，整个访问过程不再进行用户身份合规性检查，无法实时管控访问过程中的违规和异常行为。
- 业务上云后各种数据的集中部署打破了数据的边界，同时放大了静态授权的管控风险，数据滥用风险变大。高低密级数据融合导致权限污染，被动抬高整体安全等级，打破安全和业务体验的平衡。
- 资源从分散到云化集中管理，按需部署。由于当前安全管控策略分散、协同水平不高，云端主机一旦受到攻击，攻击将难以快速闭环，很难形成全局防御。
- 零信任是应对上述挑战的重要方法。采用零信任方案可以统一身份管理，构筑身份边界，实时感知风险，实现动态和细粒度授权。
三,如何实现零信任
零信任架构
实现零信任技术选型
- SDP
- IAM
- MSG
目前实现主要包括上述技术组合实现.
核心业务流,控制流和数据流如下:
零信任核心落地难点
零信任核心领域概念
- 身份(人的身份和设备身份)
- 资源
- 权限
- 告警
- 策略
1.1 身份
身份包括人的身份,设备的身份.
主要对人的身份,设备的身份进行定义.
人的身份包括但不限于:
- 账号
- 验证码
- 生物特征
核心能力包括:
身份的持续识别和验证
1.2 资源
资源指企业的应用权限,包括四层协议,七层协议.
四层协议指企业服务器,主机或者跳板机.
七层协议指企业web资源,包括比如oa系统,HR系统等.
1.3 策略
策略一边和身份挂钩,一边又和资源挂钩.策略是定义访问客体对访问主体的访问规则.
策略本质是一个表达式.
1.4 告警
告警是指 访问行为出现异常.比如异常访问.越权访问.数据来源主要包括
- 身份异常
- 策略执行异常
产品设计
技术实现难点
- SPA包
- 四层协议代理
- 规则引擎的选型
- 网关的选型
- 身份认证框架的选型
- 身份信息的同步
SPA包
1,SPA包版本
版本一UDP协议
版本二,基于https协议,需要修改第一个https client hello数据包
2,SPA数据包内容和结构
SPA数据包客户端主要完成三步⼯作：
- ⽣成密钥、
- ⽣成SPA认证包也就是我们⼀直讨论的单数据包
- 发送UDP SPA认证包。
SPA服务端主要完成两步⼯作：
监听和解析。
接下来我们仔细描述⼀下这两个组件是如何⼯作的
SPA客户端
第一步,⾸先要⽣成密钥:
第一种方式,⽤HMAC⽣成密钥：
获取⽤户指定的的HMAC摘要类型（默认是SHA-256） 获取对应摘要⻓度为hmac_klen
⽣成hmac_klen⻓度的随机字符串作为key
将key进⾏base64编码。
第二种方式,使⽤Rijndael⽣成密钥：
获取⽤户指定的klen,⽣成klen⻓度的随机字符串作为key,将key进⾏base64编码
第二步,SPA客户端便要⽣成SPA认证包
第一位,⽣成access_buf,通常格式为（allow_ip+":"+access_str(allow_ip:请求认证的
IP，access_str:请求开放的服务/端⼝)）。
第二位,构造认证消息（message），格式化为（随机字符串+”:”+base64编码的⽤户 名+”:”+时间戳+”:”+版本信息+”:”+SPA类型值+”:”+base64编码的access_buf+”:”
+base64编码的NAT信息（可选）+”:”+base64编码的server_auth字段（可 选）+”:”+认证超时时间（可选））。
第三位,通过⽤户指定的digest_type(default:SHA256)计算message的摘要数据
第四位,将salt、message和digest组合，格式化为（“Salted__”+message+”:”
+digest)
第五位,根据之前⽣成的密钥对4进⾏Rijndael算法加密。
第六位,对密⽂进⾏base64编码，并截断编码中的等号。
第七位,计算Rijndael密⽂的HMAC摘要。
第八位,将HMAC摘要编码为base64格式并截断等号。
第九位,将HMAC摘要追加到Rijndael密⽂后，并添加等号。
详细结构参考下图:
最后⼀步SPA客户端便要将该数据包发出：
确定发送数据spa_data，
若是Rijndael加密形式则忽略前10个字节，
若是GPG加密， 则忽略前2个字节（去掉salt）。
随机⽣成源端⼝，随机⽣成⽬的端⼝（可选）。 发送spa_data。
SPA服务端
解析数据包:
SPA服务端使用libpacp获取到数据包后，需要对该数据包进行拆解和解析：
第一步,获取报文的来源和目的地址。
第二步,匹配数据段前10（或2）字节是否和预留salt一样，相同则丢弃此数据包。
第三步,检测数据段是否为base64编码格式，否则丢弃。
第四步,从第一个stanza开始检查，若来源IP在允许访问的IP范围内，则进行后续操作。
第五步,还原加盐密文，头部添加salt。
第六步,取出数据段中的HMAC摘要，重新计算message密文的HMAC摘要，验证是否一致。用这种方式来匹配客户端对应的stanza。
第七步,检测message加密类型，并解密。
第八步,检测是否收到重放攻击报文。
第九步,查看SPA中是否存在timeout字段，没有则用access.conf中设置的认证超时字段。
第十步,查看SPA中的时间戳，与本机比对，差值不得超过设定值（default:120s）。
第十一步,若在access.conf中的REQUIRE_USERNAME字段被设置，需确保username在SPA中可被匹配。
第十二步,生成并配置iptables规则。
四层协议代理
四层协议主要是客户端和服务端进行验证的流程
客户端主要做两件事:
第一,提供基于https的接口,
第二,sock5认证
技术实现,widows终端基于WFP过滤和sock5协议,Mac客户端调研再实现.
服务端:提供基于sock5协议.
规则引擎选型
规则引擎解析主要基于aviator框架