随着“云原生”成为新一代云计算技术的内核,业界对其关注点正在迅速从“概念”转向“落地实践”。在诸多云安全技术中,微隔离被视为云原生安全的一项必备“基础能力”。那么,在云原生环境中微隔离技术又该如何落地呢?

       下面我们将以国内某大型股份制银行(下简称“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文件,业务部门是不可能给我们机会一次次试错的……”。

编写yaml文件下发安全策略

       从此刻起,S行的网络管理人员才开始意识到,当微隔离的管理规模达到一定程度,原本“体验”层面的问题就会变成关乎“落地成败”的关键因素。

       可行性评估,除了“有用”还要“可用”

       初探微隔离所“踩的坑”,使S行开始理解东西向访问控制与过去管理防火墙的不同,与其说微隔离是一种访问控制技术,还不如说它是一套策略管理体系,覆盖策略从设计、到定义、再到运维的全流程。

       因此,S行的网络管理人员很快便将目光投向了专业的微隔离产品。相较开源方案,专业微隔离产品的设计更加贴合客户运维管理的实际,提供了诸如连接可视化分析、策略仿真模式、策略批量生成、策略审阅发布等完整的策略管理框架。

       不得不说,市场上有过大规模微隔离交付案例的厂商并不多,所以S行很快就选定了我们进行测试。

       测试初期,对微隔离产品的环境适应性考察是必不可少的,比如对容器平台的支持、跨平台的统一纳管、虚拟机和容器的同台管理等,当然这些基础能力测试均顺利通过。然而,作为一个将来要部署进银行核心网的产品,还必须要经过几轮严酷的“大考”,S行内部称之为“非功能验证”。

       首先,产品要在极为严苛、甚至极端的环境中验证可靠性。例如,在大规模策略执行和高连接速率的情况下,验证工作负载的性能衰减是否在可接受范围。又如,在规模上万点的K8S集群中,模拟超过一半的容器同时重启,验证安全策略是否能及时更新并下发。再如,计算中心集群大范围宕机时,工作负载是否可被备份集群接管,安全策略是否能依然有效。

       其次,产品还需适应并满足银行内部的种种运维规范。这大概同样是金融用户的习惯做法。例如,针对产品部署安装、所需的依赖库、所需分配的系统权限、可能存储于本地的数据文件等,均会被提出具体的要求,不满足的则必须进行优化整改。

       正如行业内的一句俗话“能服务银行客户,就能服务所有客户”。

       五步法落地,策略管理紧密契合业务

       经过长达数月的反复验证和试运行,S行最终选定了我们的方案,并以“五步法”为指引正式开始了微隔离系统的实施。

       所谓“五步法”,是指定义、分析、设计、防护和运维5个关键步骤,它既是行业公认的零信任理念落地方法,也是我们总结出的一套切实可行的微隔离实施方案。

微隔离实施“五步法”

       定义阶段,要完成系统的部署和工作负载纳管。首先,为了满足S行超3万点规模的统一管理需求,我们在计算中心的部署上进行了充分的性能和可用性保障设计,将一个8机计算中心集群拆分部署于同城的两个双活数据中心中,并实现了工作负载就近接入、双集群A/A备份的效果。其次,为了充分发挥云原生的特性,我们并未选择基于Agent的“轻代理”方式,而是采用了基于DaemonSet的“无代理”模式部署,通过自动化的守护容器部署,省去了在各节点安装Agent的繁冗,也实现了S行力求的“原生化部署运行”。

S行云原生环境微隔离解决方案示意图

       分析阶段,要对工作负载进行分组和标签化管理,为安全策略与IP解耦打下基础。很多用户认为“分组打标签”就会引发新的工作量,而在云原生环境中,容器自身的标签体系是可以被复用的。在S行的实施中,我们便是通过容器Namespace的名称作为分组,并利用app label的键值作为各容器角色标识的。

       设计阶段,本质上是要回答安全策略怎么做的问题,所以需要梳理出东西向访问的基线。对于像S行这种管理水平较高的用户,业务容器上线时业务开发部门就需要提交应用的访问需求,这些信息可以从CMDB系统中直接获得。除此之外,在过去云平台中的防火墙、安全组中,可能运行着一些访问控制策略,这些策略经过分析选择,也可以通过工具自动化的导入微隔离系统。当然,对于仍未覆盖的少部分策略,我们可以利用连接可视化分析能力,与业务部门逐条确认。

       防护阶段,安全策略需要下发并执行。微隔离策略的下发并非“一蹴而就”,而是要经过一定时间的效果仿真和试运行,因此专业微隔离系统通常具有多种策略生效模式,例如“仅定义不下发”的建设模式、“仅下发不阻断”的测试模式或“完全执行”的防护模式。S行的业务容器投产前会先后运行于开发、测试、投产验证和生产环境,而微隔离能力是在最初的开发环境便开始生效的,在开发和测试环境策略仅工作于建设模式,在投产验证环境策略工作于测试模式,而在真正进入生产环境时,策略已完成了充分的仿真验证并正式切换为防护模式。

       至此,微隔离实施的主要工作已基本完成,系统将进入运维阶段。目前,S行正在积极尝试将微隔离系统与ITSM、SOC等外部系统打通,实现智能化的策略变更和优化。

       基于以上技术实践,我们给正在进行微隔离规划的用户一些建议:

       微隔离技术的内涵并非单纯的访问控制,而是通过一整套策略管理体系框架,实现东西向流量的精细管理,因此微隔离系统的策略管理能力应被重点考量;云原生环境的工作负载规模指数级放大,给微隔离系统带来多重挑战,用户在实施微隔离初期便应充分预见未来的扩容需求、可用性要求和运维规范的遵从;微隔离通过标签实现策略与IP解耦,其使用了更为有效和高效的控制逻辑。通过制定合理的安全目标,探究与既有运维流程的结合方式,即可使微隔离加速落地。