百度零信任架构落地经验分享——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.1 技术方案选型零信任的核心功能是流量代理，给每一个请求赋予用户身份信息。从用户流量来看，百度办公网主要流量为 7 层请求(比如 Web 浏览器)，次要流量为 4 层请求(比如 MySQL、SSH)，因此一个完整的零信任方案需要同时支持 4、7 层的流量代理。目前百度采用的是混合零信任架构方案，通过两种代理方案分别解决不同的安全问题、扬长避短。4 层流量代理常见内网 4 层流量有 MySQL、SSH 等场景，此种场景下需要对流量进行封装、改包才能实现代理功能。要实现透明改包能力，需要通过内核驱动透明劫持请求流量，然后根据是否为内网域名来决定是否转发到零信任网关。流量劫持的技术目前比较成熟，有如下实现方案:
Windows 可基于 Windivert、WFP 或者 tap 实现
Mac 可以基于 utun 或者网络扩展实现
Linux 可以基于 ebpf、ldpreload 或者 netfilter l7 chain 实现
4 层代理的主要目标是替换现有 VPN 通道。与 VPN 相比，零信任通道可以解决如下问题:1. 用户体验问题，通过短连接方式+CDN 节点，解决小运营商、弱网环境等访问体验差的问题
开发 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 层零信任网关通常是投入产出比最高的选择。当我们把流量入口收敛到零信任网关，可以很好的缓解内网攻击面庞大、漏洞修复成本较高的问题。另外，接入零信任网关的业务，每个请求都会有用户的身份信息，即使发生了攻击行为也可以很快的定位出攻击者盗用的身份，并进行应急处置。
百度目前还在零信任落地的第一阶段，未来我们还会继续发布后续阶段的落地经验，请大家留意公众号后续的文章。如有疑问，欢迎大家在公众号留言咨询，如在北京可约现场交流。
版权声明: 本文为 InfoQ 作者【百度安全】的原创文章。
原文链接:【http://xie.infoq.cn/article/f055180a7c98c469f5fdf0b08】。文章转载请联系作者。
有AI更安全 2018-11-08 加入
百度安全官方技术账号
评论