推荐语：这是百度安全团队写的应用层零信任落地的过程，很荣幸能有这个机会让我们的产品作为底层关键能力来去支撑百度项目的落地。文章写的非常好的，非常完整，从运营到实际落地过程中的问题都细细讲到了，也不禁想起并肩作战的日子，对于行业还是蛮有参考价值的，并且这应该也是行业最快并且是超大规模，在短短数月的时间内就实现了万级应用全集团的接入落地，非常有行业价值。团队非常专业，让我们有机会近距离学习，他们后续还会有系列文章，值得期待
以下为正文内容：
为了提升内网的健壮度、简化内部复杂的端口策略，百度近几年启动了零信任架构的探索，并于近期完成了办公网7层零信任的落地工作。落地零信任网关会通常会遇到几个关键问题，比如技术方案上，需要保证网关的稳定性、请求的响应延迟；运营方案上，要设计灰度流程，解决来自业务线的阻力、跟业务线建立信任感等等。然而，百度零信任架构落地的难度不止于此。任何问题一旦达到一定规模，解决的难度就会直线上升。按照最极端的情况考虑，百度零信任架构需要支持数万员工同时在线办公、接入数万个业务系统、收敛数十万条端口策略，因此难度很大。项目组最终克服诸多建设困难，对上述问题进行拆解、一一击破，成功完成了办公网7层零信任的实施，并取得了不错的落地效果。考虑到上述经验具备可复制的特点，项目组对办公网7层零信任落地过程进行了完整的总结。本文会按照项目背景、产品设计、系统架构设计、运营和灰度方案、常见问题处置手册几个章节，详细讲解落地方案。如有疑问，请在百度安全公众号下留言咨询。
Forrester分析师John Kindervag在2010年提出了零信任架构的理念，经过十余年的发展该理念已被广泛接受，技术方案也相对成熟。目前零信任分为这几种流派：1. 解决办公安全问题
（1）提供SaaS化的零信任网关服务
（2）提供身份服务和账号风控能力
（3）提供私有化部署完整解决方案(准入、零信任网关、桌管等能力)
2. 解决IDC微隔离问题，基于云原生方案或者SDN方案进行细粒度控制百度近几年也开启了零信任建设的探索，从风险程度和投入产出比考虑，我们目前聚焦在办公网零信任架构的实现上。在启用零信任架构之前，百度办公网到生产网的访问控制策略主要依赖4层控制能力。由于百度内部业务体量庞大而且需求多样化，经过十几年的积累，当前的访问控制策略已经变得难以维护，因此不得不采取一些折中策略。在这个场景下，一旦办公网被入侵，攻击者就可以对生产网海量开放业务发起攻击，并可能进一步造成数据泄露等安全风险。经过调研，我们发现零信任架构可以提供如下安全能力：
（1）加密访问: 提供透明的加密访问能力
（2）认证鉴权: 提供透明的SSO认证能力，以及域名级别访问控制能力
（3）操作审计: 谁在什么时间点请求了哪个内网服务
（4）安全防护: 提供WAF能力、用户异常访问动作序列等风控能力
（5）数据防泄露: 检测响应里是否有敏感数据，对文件进行标记因此，结合风险现状和零信任的安全价值，我们认为目前最好的方案就是建设办公网零信任网关，收敛绝大多数访问入口，并根治这个安全风险。
在设计项目目标时候需要兼顾安全目标(比如业务覆盖率)、业务体验(比如稳定性)和用户侧的体验(比如访问是否卡顿)。从公司现状出发，项目组将办公网零信任最终目标制定为:1. 业务功能: 提供便捷的、稳定的使用体验，允许在公网使用零信任系统
2. 稳定性: 办公类业务系统全部发布到零信任网关，能够支撑全员同时在线办公，全年无重大线上事故
3. 安全能力: 已接入的业务系统完成加固，包括HTTPS、最小化访问权限、WAF防护、风控能力等等
![]()
零信任的核心功能是流量代理，给每一个请求赋予用户身份信息。从用户流量来看，百度办公网主要流量为7层请求(比如Web浏览器)，次要流量为4层请求(比如MySQL、SSH)，因此一个完整的零信任方案需要同时支持4、7层的流量代理。目前百度采用的是混合零信任架构方案，通过两种代理方案分别解决不同的安全问题、扬长避短。常见内网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层流量以浏览器访问为主，处理难度要低于4层流量。通常情况下，业务将域名CNAME指向7层网关就可以实现接入。网关可以基于OpenResty、APISIX、Envoy等开源组件实现，跟IAM进行打通，实现透明的SSO认证等安全能力。7层代理的主要目标是收敛HTTP(S)业务的安全风险，解决如下安全问题: 1. 业务低成本实现SSO认证、加密访问、认证鉴权等安全能力
2. 统一访问入口、收敛生产网端口开放策略，通过减少生产网攻击面来提升内网的健壮度
开发7层代理的难度相对较低，但也要做好各类风险控制措施，我们将会在后续章节详细讲解完整方案。目前百度采用的是混合零信任架构方案，已投入生产环境使用。对于4层流量我们通过自研客户端托管流量，替换VPN、提供细粒度的访问控制能力；对于7层流量，我们要求业务发布到7层网关进行访问，提供透明的安全能力、收敛安全风险。本文是百度零信任架构落地经验分享的第一篇，重点讲解7层方案，4层方案请留意后续的公众号文章。本文重点讲解7层方案，针对建设目标，我们设计出办公网7层零信任系统最小化功能集合根据我们调研情况，甲乙方绝大多数7层零信任网关都是基于OpenResty方案实现。百度办公网7层零信任网关采用持安零信任产品，也是基于上述架构。对于百度而言，采用商业产品ROI更高，同时可以撬动外部资源推进项目建设，更快的解决安全风险。目前，我们的零信任主要有如下组件:![]()
1. 首先是工程架构方面。百度的零信任架构需要支撑数万员工同时在线办公、接入数万个域名；对于在线协同编辑文档、定点抢会议室几个场景，对连接数和访问延迟都有较高的要求。2. 其次是用户体验方面。大部分员工并不知道零信任是什么，产品流程设计上需要对用户透明，否则用户体验和运营成本会很高。3. 最后是业务沟通接入方面。百度存在大量无人维护的历史业务，经常会有找不到负责人的情况；对于内部重要的业务，需要做好实际风险控制，并与业务方建立信任感。
我们将工程架构设计难题拆解为网关高可用方案、参数调优、业务接入方式几块，下面我们来挨个探讨。 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。另外，如果用户没有百度域名，零信任网关提供泛域名供用户注册使用。最终详细方案如下:除了上述几点，这些非技术事项也需要重点关注，否则也可能会出现P0级别事故: 1. HTTPS证书有效性。项目组把百度内部域名合并到了一张证书，并设置了到期前自动提醒。不过域名越多，证书就会越大，请求时带宽损耗比例也会相应增大，因此可根据项目实际情况进行调整。
2. 云上资源的续费和释放保护。项目组使用了独立的百度云账户，并对重要的系统资源设置了释放保护，避免日常运维时误操作。
考虑到所有办公业务系统都需要接入零信任，在产品流程设计上需要对用户透明，尽可能让用户感知不到零信任的存在。对于业务管理员，也尽量只提供简单、主要的功能，否则用户体验和运营成本会很高。站在用户角度出发，我们对体验问题进行了分析，详情如下我们重点关注高频使用场景，以下是百度业务系统权限申请和审批的设计方案。其中审批流与内部IM系统直接打通，在IM内部、手机上均可操作。![]()
百度内部有较多无负责人或者处于维护状态的业务系统，一旦出现问题无法及时处理；对于ERP、知识库等重要业务系统，出现问题将是全员级别的故障。考虑到任何线上的系统都会出现问题，所以我们一定要做好兜底安全措施和风险控制方案，下面我们来挨个进行探讨。我们将百度内部业务系统划分为如下三类，并设计不同的沟通和接入方案 1. 办公基础设施: 邀请核心用户参与灰度测试，之后跟业务沟通接入
2. 部门级别业务系统: 按照体系推进
3. 其他小流量域名: 邮件通知后，如管理员无反馈则进行接入针对前两类业务，我们都需要进行灰度发布来控制风险。第三类一般由业务自行绑定host进行灰度测试。我们搭建了单独的DNS服务器，针对灰度范围内的域名解析到零信任网关，同时使用桌管软件下发配置，将目标用户的DNS设置为灰度DNS服务器。这里有两个点需要注意： 1. 由于DNS服务器在内网，所以需要同时下发一个内网DNS和一个公网DNS，且顺序需要是内网DNS在前，否则用户在脱离内网环境后可能会无法办公
2. 灰度DNS服务器稳定性要求等同于内网生产环境DNS大致流程: QA+项目组初步测试 -> 安全平台灰度 -> 核心用户灰度 -> 正式接入，不断滚动发布新的域名，形成流水线运作模式在一期落地过程中，我们使用上述方法灰度了数百个重要域名，累计沟通了接近1000个用户。最终大概有400个用户(转化率40%) 深入参与了灰度测试，业务方也认可了我们的灰度方式和灰度报告。在与业务沟通接入时，业务可能会有如下问题。考虑到百度业务体量庞大，我们需要提前给运营同学准备好话术，才能更好的应对业务的问题、保证响应时效。 1. 影响面控制。在流量低峰期接入，降低影响面；但是也不能太晚，太晚了可能找不到业务值班人
2. 快速响应。出现问题第一时间跟进排查
3. 值班信息公示。不是所有的问题都可以通过监控主动发现，业务侧、用户侧需要有联系到项目组的途径
这里我们总结了常见的业务兼容性问题和解决方案，供大家查询使用![]()
对于多数公司来说，7层流量要远远多于4层流量，因此优先建设7层零信任网关通常是投入产出比最高的选择。当我们把流量入口收敛到零信任网关，可以很好的缓解内网攻击面庞大、漏洞修复成本较高的问题。另外，接入零信任网关的业务，每个请求都会有用户的身份信息，即使发生了攻击行为也可以很快的定位出攻击者盗用的身份，并进行应急处置。百度目前还在零信任落地的第一阶段，未来我们还会继续发布后续阶段的落地经验，请大家留意【百度安全】公众号后续的文章。如有疑问，欢迎大家在公众号咨询，如在北京可约现场交流。
零信任架构实战系列：干掉密码，无密码化方案落地
零信任架构实战系列：如何选择零信任架构
零信任实战系列：远程办公实战（视频）
零信任架构远程办公实战
