云原生产业快速发展
数字经济大潮下传统行业的数字化转型，成为云原生产业发展的强劲驱动力，“新基建”带来的万亿级资本投入，也将在未来几年推动云原生产业的发展迈向新阶段。2019年我国云原生产业市场规模已达 350.2 亿元，通过使用云原生技术，76%的用户提升基础平台资源利用率并节约了成本，63%的用户提升了业务应用弹性伸缩效率和灵活性。已有部分用户将 IT 建设的重心转移到云原生上，云原生应用建设需求在逐渐增长，云原生技术在用户侧会有更广泛的落地应用。
云原生安全架构遵循原则
原则一
零信任/最小权限控制
NIST在2020年8月发布了最新的零信任架构，在零信任安全模型中，会假设环境中随时存在攻击者，不能存在任何的隐形信任，必须不断的分析和评估其资产、网络环境、业务功能等的安全风险，然后制定相应的防护措施来缓解这些风险。在零信任中，这些防护措施通常要保证尽可能减少对资源（比如数据、计算资源、应用和服务等）的访问，只允许那些被确定为需要访问的用户和资产访问，并且对每个访问请求的身份和安全态势进行持续的认证和授权。
零信任架构通过细粒度拆分、微边界的架构，并通过执行策略限制消除数据、资产、应用程序和服务的隐式信任，从而减轻了网络威胁横向扩散的可能性。零信任架构的最常见实现方法是依赖于加密概念的。首先要用硬件或者令牌来保护特定的密钥信息，并且能够用安全的方式和平台进行通信。
零信任架构通常由几个部分组成：
• 每个实体都能创建自己的标识
• 每个实体都能独立地认证其它实体（例如用公钥体系）
• 实体之间的通信是加密且不可篡改的
最小权限原则也非常重要，某种程度上说，是云原生架构中最重要的一方面，这个技术栈的所有层面在进行认证和授权的设计实现过程中，都需要考虑这个原则。
原则二
安全左移
在云原生安全建设的早期，运行时容器生命周期短、业务复杂，而且存在与操作系统虚拟化的环境现有的物理或虚拟化的安全设备无法工作，因而在这种困境下，增加运行时的安全投入无助于提高整体的安全水平。因而国内外在过去两年提出了安全左移（ Shift Left）的思路，即在云原生安全建设初期将安全投资更多地放到开发安全，包括安全编码、供应链（软件库、开源软件）安全、镜像及镜像仓库安全等。这些方面资源大多是白盒的，相应的安全投资相对较少；而且这些资源生命周期较长，如果能保证安全性，攻击者在攻击运行时实例得手后将更难持久化。
原则三
持续监控和响应
黑客攻击防不胜防，以防堵为主的传统安全理念不生效，除了事中防堵，还要有事前预防、事后迅速发现和解决、再之后的回溯分析的全方位防御能力。一切都是以持续监控和响应为基础。攻击来了迅速发现，快速响应，减小损失；快速收集数据，方便后续回溯分析。
原则四
可观测性
云原生的最终目标是通过自动化手段，实现敏捷的松耦合系统。因此，云原生安全也一定是符合这种自动化目标的，自动化的安全检测就需要有详细准确的运行状态数据作为支撑，为自动化的云原生安全提供充足的决策依据。工作负载的可视化恰恰天然地提供了这样的能力。
云原生架构下的大规模集群和海量灵活的微服务应用为工作负载可视化提出了全新的需求和挑战。容器化的基础设施使得应用本身变得更快、更轻，主机上应用的部署密度和变化频率较传统环境都有巨大的变化，需要可视化工具来发现和记录主机快速变化的应用行为；应用架构的微服务化，产生了包括服务和中间件在内的众多调用关系，通过可视化清晰地观察到这种调用关系，对于应用性能提升、故障定位、安全监测都有重要意义。
工作负载可视化包括资源可视化和应用可视化。从资源层面来看，一方面要包含传统的主机监控指标，比如对计算、存储网络等主机资源的监控，进程、磁盘IO、网络流量等系统指标的监控等；另一方面要涵盖云原生化资源监控，比如在资源层面要实现CPU、内存等在容器、Pod、 Service、 Tenant等不同层的识别和映射关系，在进程的监控上要能够精准识别到容器、甚至还要细粒度到进程的系统调用、内核功能调用等层面；在网络上，除了主机物理网络之外，还要包括Pod之间的虚拟化网络，甚至是应用之间的Mesh网络流量的观察。从应用层面来看，微服务架构下的应用，使得主机上的应用变的异常复杂，可视化监控既包括应用本身的平均延时，应用间的API调用链，调用参数等，同时还包括应用所承载的业务信息，比如业务调用逻辑、参数、订单数量，商品价格等信息。
云原生安全防护模型
整个云原生安全防护模型分为横向和纵向安全。横向安全主要是对应用户的业务开发流程，即从镜像的构建->镜像分发阶段；纵向主要指容器运行阶段的安全，包括基础环境的安全、云原生计算环境的安全、以及应用安全。
3.1
容器构建阶段安全
容器持续性安全的第一步，是构建安全的应用。这要求开发工程师具备一定的安全知识，从代码源头上减少可被攻击的风险。
（1）进行代码集成和测试之前，利用代码审计工具发现代码中潜在的漏洞。
（2）在构建镜像时，首先应确保基础镜像是从头开始编写的，或者是通过安全仓库下载的一个可信的基础镜像。然后，应通过去掉不必要的库和安装包，对镜像进行精简、加固，以减少可被攻击面。
（3）镜像构建完成后，应对镜像进行漏洞扫描以及时发现潜在的风险；同时，应该对Registry中的镜像进行周期性扫描，这些镜像中有可能存在近期新爆发的漏洞。
3.2
镜像分发阶段安全
在镜像传输阶段，进行适当的访问控制和镜像校验很有必要。
为保证镜像内容的可信，建议开启 Docker 的内容信任机制。Docker在1.8.0版本增加了Content Trust功能，大大提高了Docker的安全性。内容信任机制为向远程镜像仓库发送和接收的数据提供了数字签名的功能，这些签名允许验证镜像标签的完整性和镜像发布者。对Registry、编排工具等其他开发工具的应设置统一的访问控制策略，集成到类似LDAP这类的平台中。
3.3
运行阶段安全
基础设施安全
系统基础安全加固与配置。首先是尽可能确保主机在操作系统镜像的统一化、标准化，这是避免自底向上基础架构安全能力建设、安全风险治理成本指数化成本增长的基本举措；其次是针对统一标准化的操作系统镜像明确并落地基线安全能力的检测与管控，包括系统基础服务的安全配置、系统核心安全能力（比如HIDS、安全日志采集访问等）的部署等。
主机入侵检测。在主机层面临入侵的场景，必须要具备主机层面的入侵检测能力，通常在产品上以HIDS来落实这一需求，HIDS一般基于主机层日志、文件、进程、流量等信息来实现多维度互补的入侵检测能力。
云原生计算环境安全
网络安全。云原生网络环境建议与物理网络或云主机网络分离，这样云原生网络层就可以独立为单独的容器网络层，为该层网络更为细粒度的访问控制与安全防御提供了更好的条件。在云原生环境中，网络的隔离需求已经不仅仅是物理网络、租户网络等资源层面的隔离，而是变成了服务之间应用层面的隔离。就云原生网络隔离而言，一方面需要能够针对业务角色，从业务视角更细粒度的实现微服务之间的访问隔离，降低网络攻击在东西向上的横向移动；另一方面，隔离策略与访问控制策略，需要能够完全自动化的适应业务和网络的快速变化，实现快速高效的部署和生效。
编排及组件安全。对集群引擎和容器服务两类组件进行基线扫描。对于集群引擎组件，要支持弱口令、账号权限、身份鉴别、密码策略、访问控制、安全审计和入侵防范等安全配置的核查，生成结果报表并提供安全加固建议。对于容器服务组件，一是对用户启动容器的参数进行校验，避免用户使用不安全参数导致被利用，例如：特权容器，root用户启动，挂载主机敏感目录等；二是对容器应用涉及的文件权限和归属检测。
基于CNNVD、CVE等漏洞信息库进行组件的漏洞检测。对容器编排和集群软件进行扫描，发现已知的漏洞组件风险，编排软件应包含但不限于K8S、OpenShift等。
运行时安全。即对于运行时的环境，可以实时发现运行时容器中的入侵威胁，同时可以提供进一步的响应行为。例如对异常的容器行为监测、对容器逃逸行为的监测、以及对横向移动行为的检测等；同时能提供对容器的隔离、阻断等响应操作。
应用安全
微服务+容器的解决方案，使微服务的设计理念得到更好的落地。
容器平台使微服务的治理更加方便，促进了微服务设计理念的深化，企业得以更愿意去拆分更多的微服务，微服务可以和devops进行更好的集成，企业可以实现对细粒度的微服务的更便捷的管理，实现更合理的业务解耦。但随之而来带来的问题是微服务的访问安全性，以及交互更频繁的东西向访问的治理。
微服务的身份与安全是云原生应用安全中的基石。云原生基础架构应基于零信任理念，默认微服务之间没有信任，所有的微服务需要有身份和合理的权限配置，所有的互访均需要认证鉴权，进行合理控制。
作者 | 朱舒阳
视觉 | 谭 畅
统筹 | 邸雅楠
声明：本文来自中国光大银行科技创新实验室，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
