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

2023/10/11 11:56
阅读数 58

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层零信任网关通常是投入产出比最高的选择。当我们把流量入口收敛到零信任网关,可以很好的缓解内网攻击面庞大、漏洞修复成本较高的问题。另外,接入零信任网关的业务,每个请求都会有用户的身份信息,即使发生了攻击行为也可以很快的定位出攻击者盗用的身份,并进行应急处置。
百度目前还在零信任落地的第一阶段,未来我们还会继续发布后续阶段的落地经验,请大家留意公众号后续的文章。如有疑问,欢迎大家在公众号留言咨询,如在北京可约现场交流。

本文分享自微信公众号 - 百度安全实验室(BaiduX_lab)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部