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