1. 概要

2. 背景介绍

Forrester分析师John Kindervag在2010年提出了零信任架构的理念，经过十余年的发展该理念已被广泛接受，技术方案也相对成熟。目前零信任分为这几种流派：

1. 解决办公安全问题

     （1）提供SaaS化的零信任网关服务

     （2）提供身份服务和账号风控能力

     （3）提供私有化部署完整解决方案(准入、零信任网关、桌管等能力)

2. 解决IDC微隔离问题，基于云原生方案或者SDN方案进行细粒度控制

经过调研，我们发现零信任架构可以提供如下安全能力：

     （1）加密访问: 提供透明的加密访问能力

     （2）认证鉴权: 提供透明的SSO认证能力，以及域名级别访问控制能力

     （3）操作审计: 谁在什么时间点请求了哪个内网服务

     （4）安全防护: 提供WAF能力、用户异常访问动作序列等风控能力

     （5）数据防泄露: 检测响应里是否有敏感数据，对文件进行标记

因此，结合风险现状和零信任的安全价值，我们认为目前最好的方案就是建设办公网零信任网关，收敛绝大多数访问入口，并根治这个安全风险。

3. 零信任建设规划

3. 安全能力: 已接入的业务系统完成加固，包括HTTPS、最小化访问权限、WAF防护、风控能力等等

针对上述目标，我们计划分3个阶段进行落地:

常见内网4层流量有MySQL、SSH等场景，此种场景下需要对流量进行封装、改包才能实现代理功能。要实现透明改包能力，需要通过内核驱动透明劫持请求流量，然后根据是否为内网域名来决定是否转发到零信任网关。流量劫持的技术目前比较成熟，有如下实现方案:

     1. Windows可基于Windivert、WFP或者tap实现

     2. Mac可以基于utun或者网络扩展实现

     3. Linux可以基于ebpf、ldpreload或者netfilter l7 chain实现

4层代理的主要目标是替换现有VPN通道。与VPN相比，零信任通道可以解决如下问题:

     1. 用户体验问题，通过短连接方式+CDN节点，解决小运营商、弱网环境等访问体验差的问题

     2. 访问控制问题，支持按照ABAC、RBAC等模式进行管控，还可以根据入网设备、身份、环境、进程、访问目标动态调整访问权限

开发4层流量代理客户端难度还是比较大的，主要难点在于支持不同的终端，与各类桌管和安全软件兼容，以及确保客户端的覆盖率等等。受限于篇幅，本文不在4层方案上展开讲解，请留意后续公众号文章。

7层代理的主要目标是收敛HTTP(S)业务的安全风险，解决如下安全问题:

     1. 业务低成本实现SSO认证、加密访问、认证鉴权等安全能力

     2. 统一访问入口、收敛生产网端口开放策略，通过减少生产网攻击面来提升内网的健壮度

开发7层代理的难度相对较低，但也要做好各类风险控制措施，我们将会在后续章节详细讲解完整方案。

方案对比

1. 首先是工程架构方面。百度的零信任架构需要支撑数万员工同时在线办公、接入数万个域名；对于在线协同编辑文档、定点抢会议室几个场景，对连接数和访问延迟都有较高的要求。

2. 其次是用户体验方面。大部分员工并不知道零信任是什么，产品流程设计上需要对用户透明，否则用户体验和运营成本会很高。

3. 最后是业务沟通接入方面。百度存在大量无人维护的历史业务，经常会有找不到负责人的情况；对于内部重要的业务，需要做好实际风险控制，并与业务方建立信任感。

6. 难点一: 工程架构设计

     a. 支持多机房保活。设计异地灾备、自动降级和熔断措施等能力

     b.不依赖任何外部服务。要假设服务(MySQL、redis、SSO等等)都会出现故障，比如访问超时、服务挂掉、数据全部丢失，需要设计完善的兜底措施。

     c. 有完善的应急预案（包括用户侧、业务系统、依赖服务三个部分）。针对各类故障有设计完善的SOP，对每一个动作都要有完成时间预估，确保风险可控；每季度模拟故障演练，确保人员操作熟练、流程成熟运行（核心人员要保持稳定）

2. 业务可扩展能力，支持随时扩容和缩容，最大化资源使用效率

     a. 就近访问保证体验。基于用户网络接入方式和地域，自动选择接入节点

     b. 主动识别线上问题。模拟用户访问，设计全链路的监控能力

最终我们详细架构设计如下:

     1. 网络层。百度采用内部的LB进行流量分发，需要提前与负责的同学沟通业务流量情况。

     2. 操作系统层。在内存充足的情况下，需要调大文件描述符上限、连接数上限(net.core.somaxconn)、缓冲区大小(tcp_rmem/tcp_wmem)等等，可根据压力测试结果进行调整。

     3. 应用层。对于nginx worker、数据库集群等组件也要提高上述配置。

 对于压力测试方案，我们建议采取如下方案：

     1. 测试目标: 挑选典型场景的沙盒环境进行，定位当前硬件配置下网关的抗压能力和瓶颈点，并根据实际情况进行优化。

     2. 测试方法: 既要进行全链路压力测试，也要针对单个组件进行测试。

     3. 测试周期: 建议测试3-14天，并持续观察系统稳定性，以及错误日志的情况。

智能DNS接入方案

      1. 不影响IDC内部访问，最小化对业务的影响

      2. 出现问题可以快速回滚DNS配置，DNS TTL设置为60秒，加上终端的缓存3-5分钟能可以生效

      3. 除兼容性问题以外，业务可以免改造接入

      4. 可以按照办公区就近接入不同的网关，提升访问体验

以bind为例，关于智能DNS通常有如下几种实现方案：

      1. 实现基于view + match-clients划分区域，让不同的源IP返回不同的解析结果

      2. 使用Response Policy Zone方案实现单个域名劫持

      3. 调整DNS主备关系，让办公网DNS服务器变成主节点

从长期投入产出比看，我们推荐方案1。另外，如果用户没有百度域名，零信任网关提供泛域名供用户注册使用。最终详细方案如下:

其他稳定性的风险

      1. HTTPS证书有效性。项目组把百度内部域名合并到了一张证书，并设置了到期前自动提醒。不过域名越多，证书就会越大，请求时带宽损耗比例也会相应增大，因此可根据项目实际情况进行调整。

      2. 云上资源的续费和释放保护。项目组使用了独立的百度云账户，并对重要的系统资源设置了释放保护，避免日常运维时误操作。

7. 难点二: 用户体验

8. 难点三: 业务接入沟通

     1. 办公基础设施: 邀请核心用户参与灰度测试，之后跟业务沟通接入

     2. 部门级别业务系统: 按照体系推进

     3. 其他小流量域名: 邮件通知后，如管理员无反馈则进行接入

针对前两类业务，我们都需要进行灰度发布来控制风险。第三类一般由业务自行绑定host进行灰度测试。

用户灰度方案

      1. 由于DNS服务器在内网，所以需要同时下发一个内网DNS和一个公网DNS，且顺序需要是内网DNS在前，否则用户在脱离内网环境后可能会无法办公

      2. 灰度DNS服务器稳定性要求等同于内网生产环境DNS

业务灰度流程

      1. 影响面控制。在流量低峰期接入，降低影响面；但是也不能太晚，太晚了可能找不到业务值班人

      2. 快速响应。出现问题第一时间跟进排查

      3. 值班信息公示。不是所有的问题都可以通过监控主动发现，业务侧、用户侧需要有联系到项目组的途径

9. 常见业务兼容性问题和解决方案

这里我们总结了常见的业务兼容性问题和解决方案，供大家查询使用