内网安全面临严峻威胁和管理挑战
在当今数字化时代，企业面临着日益复杂和多样化的网络安全威胁。云计算和移动设备的普及增加了网络边界的复杂性和模糊性，使传统的边界防护措施疲于应对更复杂的安全攻击手段。比如边界防护难以防止内部员工或恶意攻击者通过获取合法访问权限，绕过边界防护设施，直接访问企业内部网络。
随着近几年攻防对抗演习、安全建设工作和行业安全交流的大力推行，越来越多的行业单位和机构已经认识到传统边界防护的薄弱，将安全治理工作的重心转移到内网安全领域。由于内部网络远比边界网络的情况更加复杂，安全管理员面对理解门槛和运营难度更高的内网安全问题时，难以开展工作。在实际管理工作过程中出现的挑战主要体现在以下几个方面：
欠缺对业务的深入理解而难以梳理安全建设思路
随着数字化转型的推进，传统的柜台业务已发展为完全的线上服务或线上线下双线共存的业务形态，带来大量的软件应用开发和部署，数据中心里业务系统的数量爆发性地增长，安全管理对象激增。与此同时，网络空间规划不合理的弊病在数据中心规模化的过程中一并暴露，导致安全管理问题更加复杂。而安全管理人员关于新系统的业务重要性、敏感性、复杂程度、内在通信逻辑、对外暴露面等各个方面的理解却未能一同增长，难以梳理安全管理工作的分类和优先级，安全建设的推进因而迟滞。
难以发现内网异常行为并有效处置
内网攻击具有隐蔽性和内部知识的特点，攻击者往往可以利用已存在的合法访问权限，在内部网络中进行活动，从而隐匿其攻击行为。内网攻击行为通常是低调和渐进式的，攻击者往往会在长时间内悄悄地进行活动，以避免被发现。他们可能利用合法的身份、弱密码和漏洞来持续地渗透、侦察和利用内部系统。这种渐进性的攻击行为使得难以及时发现攻击迹象，从而降低了处置的效果。另外，内网攻击行为具有高度的变化性，攻击者可以使用多种技术和工具来隐藏其攻击行为，例如横向移动、欺骗、隐蔽通信等。这使得传统的安全监控和检测系统难以有效应对。对于大型组织而言，内部网络通常庞大而复杂，更是让防护工作难以开展。
许多组织已经采用诸如HIDS之类的主机安全产品来守护内网安全，对这类渗透攻击的识别的确做出了积极贡献，但这类产品主要用于事中发现，缺少事前防护和事后处置的能力。而EDR这类带有主动防御能力的产品不能友好适配业务服务器的特性，其提供的自动处置能力对业务连续性可能造成负面影响。安全管理员缺少能有效、高效处置已知威胁的手段。
业务部署形态各异和业务迁移让管理策略难以统一且不可持续
由于业务系统的上线时期、功能作用不同，其部署的形态可能有所区别。传统的选择是将应用部署在虚拟机或物理服务器上，随着云计算、大数据的普及，大量应用系统已采用云化部署的方式。在部分行业内还不乏采用了更先进的容器化部署方案的组织，业务系统被拆分为众多细小的微服务，物理位置变得愈发分散。在大型网络中心内，混合部署环境是常态，不同业务环境的安防和运维内容不同，安全策略需要针对性地适配。而且随着业务云化、容器化的加深，安全策略需要随着业务部署形态的改变而调整，这对于安全管理员而言无疑是巨大的负担。
微隔离技术介绍
应对内网防护挑战的一个有效工具是微隔离。
自Gartner在2015年提出微隔离以来，对其核心能力的要求聚焦在东西向流量的隔离上（当然对南北向隔离也能发挥作用），一是有别于防火墙的隔离作用，二是满足云计算环境中的真实需求。微隔离顾名思义是细粒度更小的网络隔离技术，能够应对传统环境、虚拟化环境、混合云环境、容器环境下对于东西向流量隔离的需求，重点用于阻止攻击者进入企业数据中心网络内部后的横向平移。微隔离平台从以下几个方面解决内网流量管控的问题：
直观展示业务访问关系，帮助梳理安全构建工作
以多视角拓扑图展现工作负载之间、业务系统之间的访问关系，提供统计和分析数据，辅助梳理业务应用的暴露面、访问基线和管理优先级。
细粒度管控访问，提供异常访问处置能力
按业务系统、组件角色等多维度标签对工作负载进行分组管理，基于标签可配置工作负载、业务应用之间的隔离策略，填补区域内管控的空白。对偏离访问基线的异常流量进行告警和记录，可从网络侧对攻击事件进行处置，隔绝失陷工作负载的网络，切断恶意连接。
统一策略应对异构部署架构，自适应策略降低运维负担
提供可统一用于纳管对象的策略，计算引擎实现策略转换对接异构的底层环境，将管理员的工作重心从环境适配牵引到业务层面。随着环境变化自动调整策略，保证策略作用的一致性和稳定性，减少人工参与。
从系统架构的角度来看，微隔离技术可以通过三种方式实现：软件定义网络（SDN）、虚拟层防火墙、基于主机探针**。**
软件定义网络路线
随着SDN的引入，基础设施技术也得到了改进，使得组织能够选择在微隔离中部署和使用SDN控制器。这种选择可以通过与SDN控制器API对接的第三方安全工具实现，也可以通过直接进行SDN编程来实现。这一方法对那些在网络工程中投资于SDN，并希望从单一供应商获取SDN技术的组织尤为有吸引力。
然而，这套基于基础设施技术的实现方案更适合相对静态的私有云部署，而无法有效保护有可移动性、可扩展性的工作负载，比如基于动态混合云环境的工作负载。这种类型的微隔离可能会引入阻塞点，降低网络性能，使网络工程复杂化。
虚拟化层防火墙路线
在VMware的NSX中模拟了SDN控制器的功能，可以实现虚拟化层面的微隔离。对于大规模使用VMware的组织非常适用，能保持用户一致的使用习惯和操作流程。然而，这也局限于特定的虚拟化平台，不适合那些同时使用混合云和虚拟化技术的组织，无法跨环境提供保护。
基于主机探针路线
让控制端驻于工作负载上，直接使用主机防火墙，利用其成熟、灵活、完备的访问控制能力，最大程度发挥已有资源的效能。将安全策略与管控对象在物理层面直接绑定，保证了策略可随着工作负载的移动而迁移，对于动态环境的适配是最佳选择。而且探针可兼容适配不同类型的工作负载，轻松适配异构环境。
相较于其他技术路线，基于主机探针的技术实现相对复杂，需要解决大量探针管理、策略分发、动态调整等问题。但其带来的收益也更为可观。
Agent-based技术架构
在三种技术形态之中，基于Agent的实现方案占据主流位置，是国内外厂商的首选。其整体架构包含主机探针、计算引擎和控制台。
轻量的主机探针可一键安装在物理服务器、虚拟机、云主机和容器上，在混合的IT环境中也可直接适配，管理员无需关注底层部署架构，只用关注业务逻辑。主机探针以低资源消耗的状态持续采集网络流量数据，接收管控中心的指令并向主机防火墙写入网络策略，以及实时监控异常访问。
计算引擎负责策略计算以及可视化渲染。将标签形式定义的策略转换成IP、端口、协议的形式写入主机防火墙中；在工作负载的IP、标签发生变化后，自适应调整防火墙策略以满足相适应的流量管控要求。计算流量数据在拓扑图里的展示逻辑，以及与策略的适配性，为业务梳理提供依据。
控制台在web端呈现。以易读直观的方式呈现业务访问关系和网络策略，提供策略配置和管理能力，让管理员高效简便地管控网络访问。
相较于另外两种技术路线，Agent-based架构主要具备两个方面的优势：
（1）支持混合异构环境下工作负载的统一管控，用形式一致的网络策略进行管理，极大减轻策略运维负担；
（2）分布式网络管控能力，不存在唯一的网络堵点，流量处理效率高，对通信效果的影响可忽略不计。
网络拓扑可视化
数据中心业务流量的可视化展示对于管理员深入理解业务，为后续流量管控提供依据有重要意义。
框架设计
网络拓扑图涉及流量数据存储、数据加工、前端渲染等各环节，模块框架如下图所示：
用户界面层分为拓扑图可视化模块和交互模块。拓扑图可视化模块将从后端获取到的数据，利用可视化库如G6.js及前端框架如React渲染成带有节点（物理机、虚拟机、容器）以及节点之间连线（TCP/UDP访问）的拓扑图，支持视图切换、子图钻取、画布缩放等功能。交互模块负责数据展示、数据过滤、工作负载属性修改等与后端数据交互的功能。
应用层主要进行数据处理和检索，为用户界面层提供数据和API。数据处理模块负责对探针上报的数据在存储之前进行处理，包括策略匹配、聚合等，以及在策略变更时，自适应更新存量数据的策略匹配情况。数据检索模块为用户界面层的交互操作提供API和逻辑实现，如流量数据过滤、视图变换、信息展示等。
基础设施层通过引入数据库及缓存、消息队列等中间件，实现系统各功能模块的解耦，提供数据复用能力，同时提高系统响应效率。
重难点问题和解决思路
数据中心工作负载数量可能非常庞大，导致拓扑图需渲染大量节点和连线，给系统内部的数据存储、检索和传输，以及前端浏览器的性能都造成巨大的压力。如何有效应对大规模数据，给管理员提供流畅的使用体验，是需要重点解决的问题。
在数据库选择方面，要考虑高性能、可扩展的数据库。比如MongoDB。MongoDB是一个功能强大、灵活且易于使用的数据库管理系统，适用于各种类型的应用程序，尤其适合需要处理大量非结构化数据和需要高可用性、可扩展性的场景，其在数据分片方面的优良特性，让检索效率更高。若使用传统的MySQL存储，则会存在查询效率低下、分库分表实现复杂等问题。
而在数据结构方面，为了减轻存储压力，应对数据进行适当的聚合，比如源IP、目的IP、目的端口、协议、进程等五元组相同的流量数据被聚合在同一条记录上并计数。同时建立合适的索引，进一步提高查询效率。
为降低系统内部的网络访问开销，可使用分布式内存缓存，如Guava Cache + Redis。Guava Cache是一个功能丰富且易于使用的缓存库，它能够帮助开发人员简化内存缓存的管理和使用，并提供灵活的配置选项和并发支持，以提升应用程序的性能和响应速度。Redis的发布/订阅模式提供了一种简单而强大的消息通信机制，具有实时性、扩展性和解耦性的优势。二者结合保证在高可用环境下各节点内存数据一致。
在UI层可以通过特殊的技巧来优化性能表现。
（1）通过减少非必要图元的渲染来提升性能。拓扑图由各类图元构成，图元可以是节点、连线或标签等。在执行界面交互时，展示关键图元并隐藏其他图元，可降低性能压力。比如拖拽画布时，只显示节点图元而隐藏连线图元。
（2）通过视图的设计，将拓扑图拆分成若干子拓扑图的组合，子拓扑图内部的细节需下钻之后展示，以此减少同一界面中图元的数量。
（3）为避免数量过大导致页面卡顿不可用，可对渲染数量做边界限制，并引导使用者进行筛选以降低渲染数量。
流量信息采集
主机探针将工作负载的出入站流量上报至计算引擎，用于流量可视化和策略计算。区别于流量型分析产品，微隔离关注的是访问关系，即IP、端口、协议、进程等信息，并不解析数据包内容。当前主流的流量采集方式有如下几种。
网络连接快照
对于一个工作负载，固定时间间隔使用 Netlink 从内核获取当前NetWork NameSpace的网络连接信息，生成快照。前后两次快照的差异代表在这段时间内产生的新连接。这种方式实现简单，但缺点是数据精度不高，如果采样频率过低，采样间隔之间的流量会丢失。
PCAP抓包
PCAP (Packet Capture) 是一种网络数据包捕获技术，用于在计算机网络中捕获、分析和存储网络数据包。具有实时、灵活、安全等诸多优点，缺点是抓包粒度只能到主机端口，不能抓取进程信息。需要再根据端口关联与监听端口绑定的进程，来获取进程数据。
NFLOG
NFLOG（Netfilter Logging）是一个Linux内核功能，它允许用户空间程序捕获和处理网络数据包。NFLOG通常与Netfilter（Linux防火墙框架）一起使用，用于在数据包经过网络堆栈时将特定的数据包流量传递到用户空间程序进行进一步处理。在Netfilter的链表中写入NFLOG规则，将满足指定条件的流量记录成日志信息，再读取并向服务端上传日志数据，实现流量采集效果。其弊端同样是无法直接获取进程信息，需要通过其他途径关联。
ETW
ETW（Event Tracing for Windows）是一种在Windows操作系统中实现高性能事件日志记录和跟踪的机制。它提供了一种可靠的方式来收集和分析系统和应用程序生成的事件数据，以帮助开发人员进行故障排除、性能分析和系统监控。ETW机制基于事件提供者（Event Provider）和事件消费者（Event Consumer）的模型。事件提供者是生成事件数据的组件，可以是操作系统、应用程序、驱动程序或其他软件组件。事件消费者则是收集和处理事件数据的组件，可以是日志记录器、跟踪工具、分析工具或自定义应用程序。网络连接事件是ETW支持的众多事件类型中的一种，可用于微隔离平台的流量数据输入。
东西向流量管控
数据中心内部东西向流量隔离采用覆盖（Overlay）模式，以基于IP的基础网络技术为主，在对基础网络不做大规模修改的条件下，实现微隔离在网络上的承载，并与其他网络业务分离。
主机防火墙
基于主机探针的微隔离平台并不提供软件防火墙，而是借助主机防火墙实现网络控制效果，下面介绍两个主流系统平台的防火墙。
iptables是Linux系统上的一个强大的防火墙工具，可以通过配置iptables规则来控制网络流量的传输和访问。通过在iptables“四表五链”中设置不同规则来实现不同的访问控制效果，如放行、拦截、转发、包修改等。所谓四表指的是：raw、mangle、nat、filter，五链指的是 PREROUTING，INPUT，FORWARD，OUTPUT，POSTROUTING链。
Windows Filtering Platform（WFP）是Windows操作系统中的一个网络包过滤框架。它提供了一种在操作系统级别进行网络流量过滤和检测的机制，通过其提供的API向防火墙内核写入控制策略，实现对网络流量的细粒度管控。
流量管控技术要点
在云化和容器化普遍的现代数据中心里，工作负载的IP不再是一个稳定属性，以IP为直接管理媒介的传统访问控制方式采用静态策略，当工作负载扩容、缩容或漂移的时候，原有的策略不再适用新的业务环境，由人工调整运维策略负担巨大，难以持续管理。微隔离平台在IP之上增加一层Overlay，暴露给使用者的是标签、分组等代表工作负载身份的属性，基于这些属性配置的策略经计算引擎转换成防火墙可识别的IP形式策略。这样的做法带来两方面好处：
（1）由于使用自然语言描述的标签，策略含义容易理解；
（2）工作负载业务性质发生改变后，调整标签、分组即可继承控制策略，显著降低运营成本。
当然，这样一层转换设计对系统的计算能力提出了高要求，策略转换的稳定性、效率要有严格保障。
为了进一步减轻对存量业务的策略构建以及后续运营的负担，系统应当具备根据所采集的流量批量、快速、自动生成策略的能力。首先，应能将访问行为一致的流量聚合在一起，对原始流量数据进行归纳压缩，如应用服务器对数据库集群各节点的多条访问流量，可聚合为应用服务器访问数据库集群这一条访问关系。然后，系统能根据聚合流量推荐合适的策略形式并最终生成策略，免去管理员手动配置策略参数的繁冗工作。
不完整的策略可能导致业务故障，因此在策略真正生效之前应当有模拟测试阶段。系统将流量与策略进行匹配比对，对偏离策略的流量进行标记，而不对其进行拦截，管理员由此调整策略以确保完美贴合业务要求。直到策略调校完善后再真正以阻断效果运行。
策略自适应指的是通过对工作负载IP、标签、分组等属性的持续监控，当属性发生变化时可自动计算相适应的新策略，及时调整防火墙管控行为。主要场景有：
（1）由于网络运维的需要或容器漂移现象导致工作负载IP发生变化，主机探针通过定时获取系统IP或监听IP变更事件，发现IP变化并将其上报给计算引擎，后者向相关工作负载重新下发新的策略。
（2）虚机迁移或集群扩缩容，系统根据工作负载标签的变化计算新的策略，实现策略的及时调整。
微隔离平台一般以接管主机防火墙的模式运行，防火墙中已存在的规则将被执行优先级更高的微隔离策略屏蔽，这样的做法将防火墙管理权限集中收回到微隔离平台，达到统一管理及防止私自篡改的目的。但这样的模式也可能导致原本用于特殊业务目的的规则失效，反而影响业务，比如对流量进行转发的特殊规则被屏蔽后导致流量无法正常转发。因此系统应能检测防火墙中已有的规则并分析是否可能和微隔离策略有冲突隐患，这一特性可能依赖识别规则库，效果取决于规则库的丰富程度。
但也不乏需要在保证原有规则发挥作用的前提下执行微隔离管控逻辑的情况，系统应额外提供防火墙兼容模式，通过调整规则的优先级或写入位置来实现规则共存。典型的场景是运行Kubernetes（k8s）的宿主机，其防火墙被k8s规则重度占用，缺少兼容模式将无法在保证容器正常通信的同时管控宿主机的网络服务。
落地实践案例
在业界已有不少微隔离实践方案，帮助企业单位清扫了业务不可视的障碍，建立起可靠的内网防护围栏。下面以某证券单位的实践过程和效果为例，深入了解内网拓扑可视化和控制技术产生的重要价值。
项目实施需求
实施对象包含生产及测试环境共近1万台主机，涉及虚拟化平台、云平台、本地数据中心，涵盖Linux和Windows主流操作系统。在部署微隔离平台之前，内网隔离手段主要依靠防火墙，实现区域间隔离，隔离粒度粗，同属一个网络区域的业务系统和工作负载之间没有做任何隔离控制。安全管理员希望实现细粒度的管控效果，对工作负载和业务系统级别的流量进行限制。
实施过程
在评估实施方案阶段，发现资产管理混乱，不清楚工作负载所属业务系统，缺少基本的先验知识会导致后续策略配置受阻。所以优先梳理工作负载所属的业务系统，通过流量数据定位有紧密联系的工作负载，通过和运维部门、业务部门的协作明确归属关系，在微隔离平台中对工作负载按照业务部门、安全等级、业务系统等多层级进行分组。
所有工作负载经过3周的流量学习，工作负载之间的访问关系绘制基本稳定。基于流量学习的结果主要完成两方面的分析：定位互联网暴露系统、定位空闲端口。从流量方向可找到与互联网直接相连的业务系统，优先对这部分系统进行管控。筛选出存在无流量端口的工作负载，核实这部分资产是否有风险敞口过大的问题，可通过策略屏蔽不应开放的端口。
基于主动学习到的IP、端口、协议等信息，协同业务部门对采集到的访问关系进行核对，判断是否符合正常的业务要求。基于工作负载的分组、标签配置访问控制策略，定义受信的访问基线。由于管理对象数量庞大，分阶段完成策略配置，第一阶段仅对存在高危攻击风险的端口进行管控，在后续阶段逐步完善所有业务端口的策略配置。
以告警模式运行策略，对偏离基线的访问进行告警反馈，优化调整策略以保证完整贴合业务流量。在这个阶段流量不被阻断，以防不完整的策略影响业务连续性。经过1个月的模拟测试，将策略切换至阻断状态，真正对流量进行受信管控。
建立业务变更和上下线的线下申报流程，审批通过后，在业务系统发生变更之前调整策略，再实施变更，以保证流量管控效果和业务访问要求的同步。
实施效果总结
通过在混合环境下实施细粒度的微隔离管控，结合流量可视化能力完成资产从无序到有序的梳理、对内网隔离工作划分执行优先级，配置系统级别、工作负载级别、端口级别的细粒度策略，有效阻断横向移动路径，提升纵深防御能力。
-完-
