随着“云原生”成为新一代云计算技术的内核，业界对其关注点正在迅速从“概念”转向“落地实践”。在诸多云安全技术中，微隔离被视为云原生安全的一项必备“基础能力”。那么，在云原生环境中微隔离技术又该如何落地呢？
下面以国内某大型股份制银行（下简称“S行”）的真实案例，独家揭秘云原生环境下实施微隔离的技术实践。
容器平台投产，微隔离需求凸显
2018年，随着银行业务进入场景金融的新阶段，金融服务应用亟需被更为敏捷的承载和交付。作为金融科技创新的先行者，S行率先开始了对云原生技术的探索尝试，并于2020年上线了服务全行业务的云原生体系平台。当前，S行正通过老业务“应转尽转”、新应用100%原生化的技术战略，加速云原生技术应用。
云安全是S行进行云原生能力建设的重要组成部分，其针对云原生设计了覆盖基础设施、计算环境、应用API、开发过程和业务数据等全环节、全要素的安全架构，并力求实现安全能力组件化、服务化，使其能够随业务而生，充分融入设计开发和业务操作的过程当中。
在规模庞大的数据中心内部进行安全域分隔和网络控制，是银行业的长期通行做法。随着数据中心架构几代演变，S行在历史上尝试过多种网络隔离控制方案，例如从最初的域间防火墙方案、到上云初期的虚拟防火墙方案、再到后来利用SDN技术的服务链编排方案等。
当然，随着容器平台的投产，上述方案几乎彻底失效。究其原因，首当其冲的便是容器网络中的IP地址已失去其本身的秩序，而基于IP的静态策略自然不再有效。由此开始，S行正式踏上了微隔离技术的探索之路。
首选原生方案，可行性低落地难
在技术调研初期，S行对于微隔离的考量指标有两点。首先，自然是安全策略要与IP地址解耦，否则策略无法依靠人工运维。第二，期望云平台的安全能力能够通过“云原生化运行”，从而便于将安全能力作为组件或服务的形式提供。
于是，原生于K8S的Network Policy方案自然的成为了第一选择。
经过初步的实测验证，尽管Network Policy在操作体验上差强人意，但方案至少满足了两点核心诉求，因此很快进入到规模化的试运行阶段。而后面的经历，却让S行的网络管理人员大跌眼镜，以下引用他们的几句原话。
“初期测试的时候是在几个小规模的模拟环境里，作策略也就无需考虑太多。而到了真实环境中，容器规模瞬间放大了几十倍，连业务开发人员也说不清究竟谁该访问谁，这时微隔离策略要怎么做真就没人能说清了……”，网络人员抱怨的是开源Network Policy未提供诸如连接可视化等任何的策略辅助设计能力。
“在没有辅助的情况下，很难保证策略一次配置正确，但Network Policy的策略恰恰是即时生效的，这意味着搞不好就是一次业务中断，而回退或修改策略时又要重新编写yaml文件，业务部门是不可能给我们机会一次次试错的……”。
从此刻起，S行的网络管理人员才开始意识到，当微隔离的管理规模达到一定程度，原本“体验”层面的问题就会变成关乎“落地成败”的关键因素。
可行性评估，除了“有用”还要“可用”
初探微隔离所“踩的坑”，使S行开始理解东西向访问控制与过去管理防火墙的不同，与其说微隔离是一种访问控制技术，还不如说它是一套策略管理体系，覆盖策略从设计、到定义、再到运维的全流程。
因此，S行的网络管理人员很快便将目光投向了专业的微隔离产品。相较开源方案，专业微隔离产品的设计更加贴合客户运维管理的实际，提供了诸如连接可视化分析、策略仿真模式、策略批量生成、策略审阅发布等完整的策略管理框架。
不得不说，市场上有过大规模微隔离交付案例的厂商并不多，所以S行很快就选定了我们进行测试。
测试初期，对微隔离产品的环境适应性考察是必不可少的，比如对容器平台的支持、跨平台的统一纳管、虚拟机和容器的同台管理等，当然这些基础能力测试均顺利通过。然而，作为一个将来要部署进银行核心网的产品，还必须要经过几轮严酷的“大考”，S行内部称之为“非功能验证”。
首先，产品要在极为严苛、甚至极端的环境中验证可靠性。例如，在大规模策略执行和高连接速率的情况下，验证工作负载的性能衰减是否在可接受范围。又如，在规模上万点的K8S集群中，模拟超过一半的容器同时重启，验证安全策略是否能及时更新并下发。再如，计算中心集群大范围宕机时，工作负载是否可被备份集群接管，安全策略是否能依然有效。
其次，产品还需适应并满足银行内部的种种运维规范。这大概同样是金融用户的习惯做法。例如，针对产品部署安装、所需的依赖库、所需分配的系统权限、可能存储于本地的数据文件等，均会被提出具体的要求，不满足的则必须进行优化整改。
正如行业内的一句俗话“能服务银行客户，就能服务所有客户”。
五步法落地，策略管理紧密契合业务
经过长达数月的反复验证和试运行，S行最终选定了我们的方案，并以“五步法”为指引正式开始了微隔离系统的实施。
所谓“五步法”，是指定义、分析、设计、防护和运维5个关键步骤，它既是行业公认的零信任理念落地方法，也是我们总结出的一套切实可行的微隔离实施方案。
定义阶段，要完成系统的部署和工作负载纳管。首先，为了满足S行超3万点规模的统一管理需求，我们在计算中心的部署上进行了充分的性能和可用性保障设计，将一个8机计算中心集群拆分部署于同城的两个双活数据中心中，并实现了工作负载就近接入、双集群A/A备份的效果。其次，为了充分发挥云原生的特性，我们并未选择基于Agent的“轻代理”方式，而是采用了基于DaemonSet的“无代理”模式部署，通过自动化的守护容器部署，省去了在各节点安装Agent的繁冗，也实现了S行力求的“原生化部署运行”。
分析阶段，要对工作负载进行分组和标签化管理，为安全策略与IP解耦打下基础。很多用户认为“分组打标签”就会引发新的工作量，而在云原生环境中，容器自身的标签体系是可以被复用的。在S行的实施中，我们便是通过容器Namespace的名称作为分组，并利用app label的键值作为各容器角色标识的。
设计阶段，本质上是要回答安全策略怎么做的问题，所以需要梳理出东西向访问的基线。对于像S行这种管理水平较高的用户，业务容器上线时业务开发部门就需要提交应用的访问需求，这些信息可以从CMDB系统中直接获得。除此之外，在过去云平台中的防火墙、安全组中，可能运行着一些访问控制策略，这些策略经过分析选择，也可以通过工具自动化的导入微隔离系统。当然，对于仍未覆盖的少部分策略，我们可以利用连接可视化分析能力，与业务部门逐条确认。
防护阶段，安全策略需要下发并执行。微隔离策略的下发并非“一蹴而就”，而是要经过一定时间的效果仿真和试运行，因此专业微隔离系统通常具有多种策略生效模式，例如“仅定义不下发”的建设模式、“仅下发不阻断”的测试模式或“完全执行”的防护模式。S行的业务容器投产前会先后运行于开发、测试、投产验证和生产环境，而微隔离能力是在最初的开发环境便开始生效的，在开发和测试环境策略仅工作于建设模式，在投产验证环境策略工作于测试模式，而在真正进入生产环境时，策略已完成了充分的仿真验证并正式切换为防护模式。
至此，微隔离实施的主要工作已基本完成，系统将进入运维阶段。目前，S行正在积极尝试将微隔离系统与ITSM、SOC等外部系统打通，实现智能化的策略变更和优化。
基于以上技术实践，我们给正在进行微隔离规划的用户一些建议：
1. 微隔离技术的内涵并非单纯的访问控制，而是通过一整套策略管理体系框架，实现东西向流量的精细管理，因此微隔离系统的策略管理能力应被重点考量；
2. 云原生环境的工作负载规模指数级放大，给微隔离系统带来多重挑战，用户在实施微隔离初期便应充分预见未来的扩容需求、可用性要求和运维规范的遵从；
3. 微隔离通过标签实现策略与IP解耦，其使用了更为有效和高效的控制逻辑。通过制定合理的安全目标，探究与既有运维流程的结合方式，即可使微隔离加速落地。
【来源：网络】
