安全域隔离是企业安全里最常见而且最基础的话题之一，目前主要的实现方式是网络隔离（特别重要的也会在物理上实现隔离）。对于很小的公司而言，云上开个VPC就实现了办公网和生产网的基础隔离，但对于有自建的IDC、网络基础设施甚至自己构建云基础设施的大型公司而言，网络隔离是一项基础而复杂的安全建设。基础在这里的意思并非没有技术含量，而是强调其在安全体系里处于一个根基的位置，根基做不好，上层建设都不牢靠。
隔离的目标是为了抑制风险传播的最大范围，使受害范围限定在某个安全域内，类似于船坞的隔离模式，一个仓进水不会沉船。从攻击的角度看，网络隔离可以阻拦攻击者单点得手后的横向扩散，防御者视角更具体的思路可以参考《互联网企业安全高级指南》一书有关纵深防御的章节。
网络隔离通常分为（1）IDC隔离以及（2）办公网隔离，除此之外，还有（3）办公网跟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安全域最本质的区别是：
对于企业来说，如果移动办公程度非常高，那么应用云端化和SSO这些都是现成的，只需要梳理资产，改造gateway支持风控引擎就可以实现BeyondCorp。而对很多非高度移动化的公司而言，如果传统的安全域划分、网络监控、终端安全管理都做的非常到位的情况下，强制改造成BeyondCorp的成本是非常高的，笔者倾向于认为ROI可能不足以支撑安全团队的绩效。
有几个必要的通道：
对于大部分企业来说传统的安全域划分方法仍然够用，至少几年内没有太大的问题，但对于IDC规模超大的企业来说，弹性计算和安全会成为对立面，如果需要走Google的模式需要高度的集群管理自动化，较高的服务治理水平，高度统一的技术栈和极度收敛的内网协议。
如果OA网络需要BeyondCorp模式，需要办公云化和移动化程度比较高。退一步回到一家公司整体的安全建设上，如果其他地方还有很多短板，在网络隔离上追求极致不是一个正确的策略，相较而言应该将资源（对于较大的安全团队而言也包括自研的资源）都投入到优先级更高的地方，譬如基础设施的攻击缓解能力。
站在一个高P的视角，追求技术的领先是一件本分的事情，而对于安全负责人来说，风险管理和ROI永远是安全工作的核心，也因此在2017年底这个时间点看对于绝大多数公司来说Google模式是没有复制的必要的，不幸的是笔者所在的公司恰好具备了这方面的基础条件，所以安全团队俨然一副在路上的架势。）
赵彦，现任美团集团安全部高级总监，负责集团旗下全线业务的信息安全与隐私保护。加盟美团前，曾任华为云安全首席架构师，奇虎360企业安全技术总监、久游网安全总监、绿盟科技安全专家等职务。白帽子时代是Ph4nt0m Security Team的核心成员，互联网安全领域第一代资深从业者。
美团安全部的大多数核心人员，拥有多年互联网以及安全领域实践经验，很多同学参与过大型互联网公司的安全体系建设，其中也不乏全球化安全运营人才，具备百万级IDC规模攻防对抗的经验。安全部也不乏CVE“挖掘圣手”，有受邀在Black Hat等国际顶级会议发言的讲者，当然还有很多漂亮的运营妹子。
目前，美团安全部涉及的技术包括渗透测试、Web防护、二进制安全、内核安全、分布式开发、大数据分析、安全算法等等，同时还有全球合规与隐私保护等策略制定。我们正在建设一套百万级IDC规模、数十万终端接入的移动办公网络自适应安全体系，这套体系构建于零信任架构之上，横跨多种云基础设施，包括网络层、虚拟化/容器层、Server 软件层（内核态/用户态）、语言虚拟机层（JVM/JS V8）、Web应用层、数据访问层等，并能够基于“大数据+机器学习”技术构建全自动的安全事件感知系统，努力打造成业界最前沿的内置式安全架构和纵深防御体系。
随着美团的高速发展，业务复杂度不断提升，安全部门面临更多的机遇和挑战。我们希望将更多代表业界最佳实践的安全项目落地，同时为更多的安全从业者提供一个广阔的发展平台，并提供更多在安全新兴领域不断探索的机会。
美团安全部正在招募Web&二进制攻防、后台&系统开发、机器学习&算法等各路小伙伴。如果你想加入我们，欢迎简历请发至邮箱zhaoyan17@meituan.com
具体职位信息可参考这里：https://mp.weixin.qq.com/s/ynEq5LqQ2uBcEaHCu7Tsiw
美团安全应急响应中心MTSRC主页：security.meituan.com
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。