百度零信任架构落地经验分享——7层零信任方案

1. 概要

为了提升内网的健壮度、简化内部复杂的端口策略，百度近几年启动了零信任架构的探索，并于近期完成了办公网7层零信任的落地工作。落地零信任网关会通常会遇到几个关键问题，比如技术方案上，需要保证网关的稳定性、请求的响应延迟；运营方案上，要设计灰度流程，解决来自业务线的阻力、跟业务线建立信任感等等。

然而，百度零信任架构落地的难度不止于此。任何问题一旦达到一定规模，解决的难度就会直线上升。按照最极端的情况考虑，百度零信任架构需要支持数万员工同时在线办公、接入数万个业务系统、收敛数十万条端口策略，因此难度很大。项目组最终克服诸多建设困难，对上述问题进行拆解、一一击破，成功完成了办公网7层零信任的实施，并取得了不错的落地效果。

考虑到上述经验具备可复制的特点，项目组对办公网7层零信任落地过程进行了完整的总结。本文会按照项目背景、产品设计、系统架构设计、运营和灰度方案、常见问题处置手册几个章节，详细讲解落地方案。如有疑问，请在百度安全公众号下留言咨询。

2. 背景介绍

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

1. 解决办公安全问题

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

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

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

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

百度近几年也开启了零信任建设的探索，从风险程度和投入产出比考虑，我们目前聚焦在办公网零信任架构的实现上。在启用零信任架构之前，百度办公网到生产网的访问控制策略主要依赖4层控制能力。由于百度内部业务体量庞大而且需求多样化，经过十几年的积累，当前的访问控制策略已经变得难以维护，因此不得不采取一些折中策略。在这个场景下，一旦办公网被入侵，攻击者就可以对生产网海量开放业务发起攻击，并可能进一步造成数据泄露等安全风险。

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

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

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

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

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

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

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

3. 零信任建设规划

在设计项目目标时候需要兼顾安全目标(比如业务覆盖率)、业务体验(比如稳定性)和用户侧的体验(比如访问是否卡顿)。从公司现状出发，项目组将办公网零信任最终目标制定为:

1. 业务功能: 提供便捷的、稳定的使用体验，允许在公网使用零信任系统

2. 稳定性: 办公类业务系统全部发布到零信任网关，能够支撑全员同时在线办公，全年无重大线上事故

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

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

4. 项目方案

4.1 技术方案选型

零信任的核心功能是流量代理，给每一个请求赋予用户身份信息。从用户流量来看，百度办公网主要流量为7层请求(比如Web浏览器)，次要流量为4层请求(比如MySQL、SSH)，因此一个完整的零信任方案需要同时支持4、7层的流量代理。目前百度采用的是混合零信任架构方案，通过两种代理方案分别解决不同的安全问题、扬长避短。

4层流量代理

常见内网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层流量代理

7层流量以浏览器访问为主，处理难度要低于4层流量。通常情况下，业务将域名CNAME指向7层网关就可以实现接入。网关可以基于OpenResty、APISIX、Envoy等开源组件实现，跟IAM进行打通，实现透明的SSO认证等安全能力。

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

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

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

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

方案对比

百度现状

目前百度采用的是混合零信任架构方案，已投入生产环境使用。对于4层流量我们通过自研客户端托管流量，替换VPN、提供细粒度的访问控制能力；对于7层流量，我们要求业务发布到7层网关进行访问，提供透明的安全能力、收敛安全风险。本文是百度零信任架构落地经验分享的第一篇，重点讲解7层方案，4层方案请留意后续的公众号文章。

4.2 业务场景分析

本文重点讲解7层方案，针对建设目标，我们设计出办公网7层零信任系统最小化功能集合

4.3 关键组件

根据我们调研情况，甲乙方绝大多数7层零信任网关都是基于OpenResty方案实现。百度办公网7层零信任网关采用持安零信任产品，也是基于上述架构。对于百度而言，采用商业产品ROI更高，同时可以撬动外部资源推进项目建设，更快的解决安全风险。目前，我们的零信任主要有如下组件:

5. 项目难点分析

对于百度而言，落地零信任有如下几个关键困难：

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

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

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

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

我们将工程架构设计难题拆解为网关高可用方案、参数调优、业务接入方式几块，下面我们来挨个探讨。

业务容灾、高可用和低延迟

对于网关高可用方案，我们按照如下原则进行设计:

1. 业务容灾能力

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

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

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

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

3. 业务访问体验

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

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

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

系统参数调优与压力测试

百度内部办公流量比较丰富，比较典型的有在线系统办公、抢会议室、视频流、内部网盘系统等等，分别代表了低延迟、大流量、大文件上传等可能对系统造成压力的场景。

针对上述场景，我们需要进行全链路的参数调优工作

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

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

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

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

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

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

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

智能DNS接入方案

我们设计的方案是通过智能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。另外，如果用户没有百度域名，零信任网关提供泛域名供用户注册使用。最终详细方案如下:

其他稳定性的风险

除了上述几点，这些非技术事项也需要重点关注，否则也可能会出现P0级别事故:

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

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

7. 难点二: 用户体验

考虑到所有办公业务系统都需要接入零信任，在产品流程设计上需要对用户透明，尽可能让用户感知不到零信任的存在。对于业务管理员，也尽量只提供简单、主要的功能，否则用户体验和运营成本会很高。

体验问题拆解

站在用户角度出发，我们对体验问题进行了分析，详情如下

典型设计方案举例

我们重点关注高频使用场景，以下是百度业务系统权限申请和审批的设计方案。其中审批流与内部IM系统直接打通，在IM内部、手机上均可操作。

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

百度内部有较多无负责人或者处于维护状态的业务系统，一旦出现问题无法及时处理；对于ERP、知识库等重要业务系统，出现问题将是全员级别的故障。考虑到任何线上的系统都会出现问题，所以我们一定要做好兜底安全措施和风险控制方案，下面我们来挨个进行探讨。

业务系统划分

我们将百度内部业务系统划分为如下三类，并设计不同的沟通和接入方案

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

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

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

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

用户灰度方案

我们搭建了单独的DNS服务器，针对灰度范围内的域名解析到零信任网关，同时使用桌管软件下发配置，将目标用户的DNS设置为灰度DNS服务器。这里有两个点需要注意：

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

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

业务灰度流程

大致流程: QA+项目组初步测试 -> 安全平台灰度 -> 核心用户灰度 -> 正式接入，不断滚动发布新的域名，形成流水线运作模式

在一期落地过程中，我们使用上述方法灰度了数百个重要域名，累计沟通了接近1000个用户。最终大概有400个用户(转化率40%) 深入参与了灰度测试，业务方也认可了我们的灰度方式和灰度报告。

正式接入方案

业务应答话术

在与业务沟通接入时，业务可能会有如下问题。考虑到百度业务体量庞大，我们需要提前给运营同学准备好话术，才能更好的应对业务的问题、保证响应时效。

风险控制措施

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

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

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

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

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

10. 写在最后

对于多数公司来说，7层流量要远远多于4层流量，因此优先建设7层零信任网关通常是投入产出比最高的选择。当我们把流量入口收敛到零信任网关，可以很好的缓解内网攻击面庞大、漏洞修复成本较高的问题。另外，接入零信任网关的业务，每个请求都会有用户的身份信息，即使发生了攻击行为也可以很快的定位出攻击者盗用的身份，并进行应急处置。

百度目前还在零信任落地的第一阶段，未来我们还会继续发布后续阶段的落地经验，请大家留意公众号后续的文章。如有疑问，欢迎大家在公众号留言咨询，如在北京可约现场交流。