初探下一代网络隔离与访问控制

概述

安全域隔离是企业安全里最常见而且最基础的话题之一，目前主要的实现方式是网络隔离（特别重要的也会在物理上实现隔离）。对于很小的公司而言，云上开个 VPC 就实现了办公网和生产网的基础隔离，但对于有自建的 IDC、网络基础设施甚至自己构建云基础设施的大型公司而言，网络隔离是一项基础而复杂的安全建设。基础在这里的意思并非没有技术含量，而是强调其在安全体系里处于一个根基的位置，根基做不好，上层建设都不牢靠。

隔离的目标是为了抑制风险传播的最大范围，使受害范围限定在某个安全域内，类似于船坞的隔离模式，一个仓进水不会沉船。从攻击的角度看，网络隔离可以阻拦攻击者单点得手后的横向扩散，防御者视角更具体的思路可以参考《互联网企业安全高级指南》一书有关纵深防御的章节。

网络隔离通常分为（1）IDC 隔离以及（2）办公网隔离，除此之外，还有（3）办公网跟 IDC 之间的访问控制。受限于安全策略的敏感性，本文不会披露过于详细的策略或实现方案。

IDC 隔离

以下先从 IDC 隔离说起，安全做的没有特点的公司通常是这么分的：办公网内部没有任何隔离，生产网内部也没有任何隔离。

甚至有些市值好几百亿美元的公司也这么分。这样分的结果是对运维比较便利，但从安全来说相当于什么也没做。比较普遍的做法如下图所示（某电商公司的例子）：

首先会在 IDC 整体上区分公有云和私有云，其次在私有云内部区分生产和测试环境，然后是办公网跟 IDC 的隔离。当然这个粒度是比较粗的，实际在每个安全域内部还有更细的划分，安全域之间设置运维和数据通道，数据在安全域之间流转时需要脱敏和审计。再来看另一个大型互联网公司安全域的例子：

里面更细粒度的定义了 OA-IDC 之间的通道，即图中标示为内部运营网的部分，例如通常运维的堡垒机就属于内部运营网，思路还是把运维通道，数据通道，测试环境都放在了内部运营网，可以理解为整体上就是 OA-测试（内部运营通道）-生产，3 大安全域。

除了国内主要的互联网公司，再看一个国际电商和云计算巨头的例子：

办公网包含测试环境，通过发布系统与生产环境隔离，生产环境中除了密钥管理等强制合规性需求外，基本没有做太多隔离，推测是为了网络资源的弹性考虑，staging 可以理解为是 CI 末端的一个预发布环境，在全球范围内会跟云计算一样区分 Region（北美、亚太……Region 之间几乎不互通），AZ（Availability Zone，可用区，可以理解为是同一个 IDC 内有用相同的灾备等级）的隔离概念。

基本上上述例子可以代表全球范围内绝大部分互联网和云计算公司的安全域隔离方法论了。于是，我们吸收各家的优点，整理出一个相对通用的安全域划分示例，如下图所示：

在大多数公司，如果安全工作做得认真到位，没有太激进或者技术引领之类的需求基本上也算 OK 了。只不过网络隔离这件事天生跟弹性计算是对立的，隔离的越细致，对于快速扩容、服务编排、资源回收都是不利的。在海量 IDC 运维环境下，会给追求全自动化资源管理的理念引入障碍。

另一方面，虽然明确定义了很多诸如生产测试分离之类的规则，但在实际的日常使用中往往会有很多问题。互联网公司的研发不是传统的瀑布模型，也不一定都有专职的且供应量足够的测试人员，尤其对于扩展中的业务很多流程和规则往往处于模糊地带，测试环境也未必能满足所有的测试需求，例如全链路压测等，这些问题带来的挑战是安全隔离对业务需求产生阻碍，但是业务又不能中断，所以会有很多变相操作，例如直接去生产环境测试，从而跳过了安全预设的场景和规则，最后使得隔离看起来有点虚幻。

笔者细数了一下网络隔离诞生于上个世纪，是自网络安全开始就有的概念，产生于一个互联网并不发达也没有海量 IDC 的时代，所以这种模式可能有点局部（并非全部和绝对）过时了。直到发现 Google 的模式，阐述了一种全新的思路：不使用基于网络的隔离，而是用应用级别的隔离来实现访问控制，如下图所示：

我们从几个层面详细分析这一方案。

首先 Google 这个规模的 IDC 管理的理念是必须通过自动化管理实现，人肉是不可能的，当然人肉审批 ACL 策略也是不可能的。集群全部通过自动化管理的前提是高度的弹性计算能力：所有机器的安装初始化，上线，应用实例部署，到自动擦除数据下线，回收资源都是自动化的，所以过度的隔离也会抑制生产能力。以前这些自动化工作都通过 sshd 服务来，且需要 root 权限，Google 认为这是一个巨大的安全隐患，所以重新设计了一个 admin 服务运行于所有的 VM、容器实例，这个 admin 服务本质上是一个 RPC 服务，支持认证、ACL 驱动和审计，并且只需要完成工作的最小权限。相当于原来通过 SSH 管道执行的命令变成了通过 admin 服务的一堆 RPC 调用指令，每个参数都可审计。这是 Google 这套机制的背景之一。

第二点，这套机制能 work 的前提是：Google 的 IDC 内网只有 RPC 协议，没有像其他公司一样的 mysql，ssh，rpc，http 等各种协议，所以只对 RPC 服务做访问控制就相当于给所有的攻击面做访问控制，但是对于有着各种复杂协议的普适性 IDC 内网场景来说，这一点前提是不 ready，不能说没有用，但显然其他协议仍然有攻击面，仍然可用于内网渗透和横向拓展。这也是 Google 自研技术栈比较深导致的跟大多数公司基础设施不太一样的地方，所以看官可能也察觉到这不是一个放之四海皆准的方案。

第三点，这套机制的工作原理，可以参考图中右半部分。服务调用通过 RPC 鉴权：譬如某类型的前台服务 A 只能访问某个类型的后台服务 B，也可以衍生出业务 X 的前台服务 A 只能访问业务 X 的后台服务 B，而不能访问业务 Y 的后台服务 B。测试跟生产分离，也只需要将测试和生产定义成不同的业务大类。从攻击者的立场来看，假如你搞定了内网的一台机器，你拿出扫描器去扫其他机器，虽然路由可达，但是因为不具有对应的 RPC 权限，所以没有对其他应用的访问 token，相当于被隔离。

不过可惜的是，前置条件 IDC 内网收敛为一种 RPC 协议这一条绝大多数公司都不符合，所以这种形式的可落地改进方案还有待讨论，但是笔者认为这代表了未来的方向，对于超大规模 IDC 自适应的安全隔离无法通过简单的划分安全域和手工 ACL 审批来实现。

办公网隔离

笔者在《互联网企业安全高级指南》中描述过一种 OA 网络的划分方法，如下图所示：

首先把 IT 应用（假如在内网的话）跟桌面用户划开，桌面用户根据职能部门划动态 VLAN，这种一种传统的安全域方式。策略收敛比较到位的话也能起到不错的效果。

Google 的 BeyondCorp（ https://cloud.google.com/beyondcorp/ ）不走寻常路，本质上是办公应用云化和移动化后的产物。

图示的是 BeyondCorp 这套机制，通过识别当前设备状态，使用动态的访问控制策略决定当前设备能访问哪些 OA 应用。这套机制跟传统的 OA 安全域最本质的区别是：

• Bird 传统的访问控制策略都是基于 IP/MAC 的。

• BeyondCorp 模型是基于设备/账号的。

• 传统的模型访问控制是静态的，后者则是动态的。

• 传统的模型是 ACL，BeyondCorp 则有点风控的意味。

对于企业来说，如果移动办公程度非常高，那么应用云端化和 SSO 这些都是现成的，只需要梳理资产，改造 gateway 支持风控引擎就可以实现 BeyondCorp。而对很多非高度移动化的公司而言，如果传统的安全域划分、网络监控、终端安全管理都做的非常到位的情况下，强制改造成 BeyondCorp 的成本是非常高的，笔者倾向于认为 ROI 可能不足以支撑安全团队的绩效。

OA 和 IDC 之间

有几个必要的通道：

1. SSH 远程访问通道，通过跳板机，全程审计，权限回收。

2. 数据安全环境：数据开发，BI 报表等，一切需要接触数据仓库的开发运营人员的工作集散地，通常这里会有一些类似虚拟化桌面的审计。

3. 数据传输通道：因为各种原因 debug、测试需要上传/回传数据，只能在指定的传输通道进行，必须符合脱敏跟审计的要求。

4. 代码发布渠道：通常大型互联网公司都有自己的一套发布系统，甚至还有跟 R&D 同学本机磁盘映射的方案，所以这个通道的安全都在发布系统上做。

5. 基础设施管理通道：运维通道的特殊版本，可能会集成一些运维管理工具或自动化平台，需要能够触达全部的 IDC 资源。

总结

对于大部分企业来说传统的安全域划分方法仍然够用，至少几年内没有太大的问题，但对于 IDC 规模超大的企业来说，弹性计算和安全会成为对立面，如果需要走 Google 的模式需要高度的集群管理自动化，较高的服务治理水平，高度统一的技术栈和极度收敛的内网协议。

如果 OA 网络需要 BeyondCorp 模式，需要办公云化和移动化程度比较高。退一步回到一家公司整体的安全建设上，如果其他地方还有很多短板，在网络隔离上追求极致不是一个正确的策略，相较而言应该将资源（对于较大的安全团队而言也包括自研的资源）都投入到优先级更高的地方，譬如基础设施的攻击缓解能力。

站在一个高 P 的视角，追求技术的领先是一件本分的事情，而对于安全负责人来说，风险管理和 ROI 永远是安全工作的核心，也因此在 2017 年底这个时间点看对于绝大多数公司来说 Google 模式是没有复制的必要的，不幸的是笔者所在的公司恰好具备了这方面的基础条件，所以安全团队俨然一副在路上的架势。）

作者简介

赵彦，现任美团集团安全部高级总监，负责集团旗下全线业务的信息安全与隐私保护。加盟美团前，曾任华为云安全首席架构师，奇虎 360 企业安全技术总监、久游网安全总监、绿盟科技安全专家等职务。白帽子时代是 Ph4nt0m Security Team 的核心成员，互联网安全领域第一代资深从业者。

关于美团安全

美团安全部的大多数核心人员，拥有多年互联网以及安全领域实践经验，很多同学参与过大型互联网公司的安全体系建设，其中也不乏全球化安全运营人才，具备百万级 IDC 规模攻防对抗的经验。安全部也不乏 CVE“挖掘圣手”，有受邀在 Black Hat 等国际顶级会议发言的讲者，当然还有很多漂亮的运营妹子。

目前，美团安全部涉及的技术包括渗透测试、Web 防护、二进制安全、内核安全、分布式开发、大数据分析、安全算法等等，同时还有全球合规与隐私保护等策略制定。我们正在建设一套百万级 IDC 规模、数十万终端接入的移动办公网络自适应安全体系，这套体系构建于零信任架构之上，横跨多种云基础设施，包括网络层、虚拟化/容器层、Server 软件层（内核态/用户态）、语言虚拟机层（JVM/JS V8）、Web 应用层、数据访问层等，并能够基于“大数据+机器学习”技术构建全自动的安全事件感知系统，努力打造成业界最前沿的内置式安全架构和纵深防御体系。

随着美团的高速发展，业务复杂度不断提升，安全部门面临更多的机遇和挑战。我们希望将更多代表业界最佳实践的安全项目落地，同时为更多的安全从业者提供一个广阔的发展平台，并提供更多在安全新兴领域不断探索的机会。