云原生安全知识导入

学习目标：云原生基本介绍、云原生安全介绍、云原生的安全防护思路和体系、深信服的云原生防护产品、方案介绍。

更多详情请看

PPT： 云原生安全知识导入.pptx (16.09 MB, 下载次数: 25)

2022-12-15 11:46 上传

点击文件名下载附件

视频学习：点击跳转

一、云原生背景：技术变革、市场推动，呈现云原生安全新需求

（1）云原生技术在生产环境采纳率急速升高

       云原生的理念经过几年发展，不断丰富、落地、实践，云原生已经渡过了概念普及阶段，进入了快速发展期。云原生技术以其高效稳定、快速响应的特点驱动引领企业的业务发展，成为企业数字业务应用创新的原动力。过去几年中，以容器、微服务、DevOps、Serverless为代表的云原生技术正在被广泛采纳，2020 年 43.9%的国内用户已在生产环境中采纳容器技术，超过七成的国内用户已经或计划使用微服务架构进行业务开发部署等1，这使得用户对云原生技术的认知和使用进入新的阶段，技术生态也在快速的更迭。

（2）颠覆性技术架构变革带来全新安全隐患

       云原生技术架构充分利用了云计算弹性、敏捷、资源池和服务化特性，在改变云端应用的设计、开发、部署和运行模式的同时，也带来了新的安全要求和挑战。以容器、Serverless 为载体的云原生应用实例极大地缩短了应用生命周期；微服务化拆分带来应用间交互式端口的指数级增长以及组件间组合设计复杂度的陡升；多服务实例共享操作系统带来了单个漏洞的集群化扩散；独立的研发运营流程增加了软件全生命周期各个环节的潜在风险。云原生的特有属性带来了架构防护、访问控制、供应链、研发运营等领域全新的安全隐患和安全防护需求。

       服务实例应用周期变短增加监控和溯源难度。以容器、Serverless 为载体的云原生应用实例的生命周期极大缩短，容器秒级启动或消失的特性以及持续频繁的动态变化，增加了安全监控和保护的难度，准确捕捉容器间的网络流量和异常行为成为新挑战。

       组件爆发式增长为应用防护能力提出更高要求。微服务将单体架构拆分成多个服务，应用间的交互端口呈指数级增长、攻击面大幅增加，相较于单体应用架构集中在单个端口防护的简单易行，微服务化应用在端口防护、访问权限、授权机制等方面难度陡增。

       容器共享操作系统的进程级隔离环境增加逃逸风险。传统软件架构下，应用之间通过物理机或虚拟机进行隔离，可以将安全事件的影响限制在可控的范围内。在云原生环境下，多个服务实例共享操作系统，一个存在漏洞服务被攻陷可能会导致运行在同主机上其他服务受到影响，逃逸风险大大提高。

       独立研发运营对软件流转的全链条安全提出新要求。每个微服务应用都涉及相对独立的开发和测试流程，并通过 CI/CD（持续集成/持续交付）流水线将应用部署运行到开发测试和生产环境中。在业务应用全生命周期中，为各个环节的自动化安全防护能力提出了全新要求，不仅要避免各个环节的潜在风险，而且要提高应用的安全交付效率。

（3）传统的边界防护模型难以应对云原生安全风险

       谈及云原生安全，不少人还停留在传统安全意识和观念，关注 Web攻防和系统攻防，关注密码暴力破解和反弹 Shell。然而，安全总是具有“短板效应”，有时，一个简单的端口暴露、未授权访问没及时处理就为攻击者提供了不费吹灰之力长驱直入的机会。此外，云原生技术架构带来的风险，在未来数年内，会成为攻击者关注和利用的重点，进而发动针对云原生系统的攻击。传统基于边界的防护模型已不能完全满足云原生的安全需求，云原生关注快速开发和部署，这种特性要求进行防护模式的转变，从基于边界的防护模式迁移到更接近基于资源属性和元数据的动态工作负载的防护模式，从而有效识别并保护工作负载，以满足云原生技术架构的独特属性和应用程序的规模需求，同时适应不断变化的新型安全风险。

       安全防护模型的转变要求在应用程序生命周期中采用更高的自动化程度，并通过架构设计（例如零信任架构）来确保安全方案实施落地；在云原生系统建设初期，需要进行安全左移设计，将安全投资更多地放到开发安全，包括安全编码、供应链（软件库、开源软件等），安全、镜像及镜像仓库安全等。回顾安全发展史，安全始终是跟随 IT 基础设施和业务来发展的，即安全跟随其服务的对象而演进。进入云原生时代，物理安全边界逐渐模糊并变成了无处不在的云原生安全体系，从外到内，无论可视化、运维和安全管理，还是南北向和东西向网络、容器基础架构、微服务应用模式、身份安全、数据安全等，都给安全市场带来了更丰富的产品维度，衍生出更多元的发展机遇。

二、云原生环境的安全现状

（1）镜像安全问题很突出

公共镜像库的安全性无法保证--------（2019年有关研究报告显示，DockerHub中超过30%的官方镜像包含高危漏洞）

镜像被黑客植入木马、后门等恶意软件

镜像使用有漏洞的应用软件

（2）不安全的环境配置

容器配置不当引起的安全问题------（特权容器、敏感信息泄露等等）

编排应用配置不当引发的安全问题------（k8s的RBAC权限划分不当，存在安全隐患）

宿主机配置不当引发的安全问题--------（弱口令，基线等等）

（3）容器的应用漏洞

Docker 应用本身存在安全漏洞--------（CVE-2019-14271 runc容器逃逸漏洞）

编排应用存在的安全漏洞--------（kube-proxy边界绕过(CVE-2020-8558)）

宿机上的应用安全漏洞

（4）架构引发的安全问题

从容器逃逸到宿主机

调用有漏洞的系统调用

DDOS资源耗尽

（5）运行时安全

webshell、异常行为检测、提权等

三、云原生安全防护思路

（1）容器的生命周期

据统计，46%的容器生命周期小于1小时，11%的容器生命周期小于1分钟，容器环境中的短生命周期是云原生业务和编排机制造成的，这种特性给攻防双方都带来了变化。

从攻方的角度，以及从攻击性价比的角度，他们在早期会越来越多地攻击持久化的资源，特别是容器镜像和镜像仓库，这样攻击成本最低，而收益最高。一个被污染的镜像可以散布到更多的计算节点，而且可以持久化直到新版镜像发布上线。

（2）安全左移

在早期阶段，攻击者会更关注更为持久的资产，如代码、第三方库、镜像、仓库、编排系统、控制面、宿主机等。那么对于安全团队而言，早期投入和可用的安全技术都不会很多，做最简单的事情意义最大，此时可以考虑将安全控制向开发侧转移，也就是从运营安全转向开发安全。

因为在DevOps的闭环图中，开发在左侧，运营在右侧，所以又称为安全左移（Shift Left）。

安全左移需要考虑开发安全、软件供应链安全、镜像仓库、配置核查这四个部分。

开发安全：需要关注代码漏洞，比如使用代码检查工具进行静态代码分析或动态运行时分析，找到因缺少安全意识造成的漏洞；此外，应重点检查代码中是否包含用户凭证、存在密码硬编码等。

软件供应链安全：也就是项目使用到的第三方软件库的安全。现在大型软件项目中或多或少都用到了开源软件，所以开源软件的安全问题需要重视，可以使用代码检查工具或代码漏洞库进行持续的安全评估。

镜像仓库：当前的镜像仓库中很多容器镜像存在安全漏洞，因此应使用镜像漏洞扫描工具持续对自有仓库中的镜像进行持续评估，对有安全风险的镜像进行及时更新。

配置核查：比如暴露面核查、服务器配置加固等，这部分可以最大程度提升攻击者发现脆弱资产、利用漏洞的难度。

（3）聚焦不变

回到运营侧安全，容器环境中，无论是杀毒软件（AV），还是EDR或UEBA，都或多或少存在一些固有的缺陷，或不能用，或要做改造。例如，在做检测响应方面，安全机制应该多关注造成容器逃逸的攻击场景，特别是利用运行时环境、操作系统漏洞的攻击；而在行为分析方面，应该充分利用镜像的持久化特性，一般而言，从某个镜像启动的各容器的进程行为模式是相似的，那就完全可以将容器按照镜像进行聚合，针对聚合的容器集合再进行画像，那么这样的画像结果是一致、低偏差的。

（4）关注业务

在云原生环境中，开发者关注的是如何编写业务功能，而攻击者关注最多的也是是否能滥用业务功能，最典型的就是“薅羊毛”等黑产。

业务安全是离客户最近且价值最大的安全功能，然而云原生场景非常复杂，很难有统一的业务安全模型；此外，在微服务和服务网格的场景下，服务之间大部分通过API调用实现，这与当前Web应用存在大量人机交互完全不同，因而API安全在云原生场景下也存在很大的差异。从技术上看，要实现API和业务安全，第一步是获得API调用的可观测能力（visibility），当前有很多开源项目具有这样的能力，但其在开发、构建过程中的侵入性各有不同。

   

四、云原生安全体系

安全机制应该多关注造成容器逃逸的攻击场景

学习一下，感谢楼主分享

这个安全产品  OEM  哪一家的？

逐句地看完这个帖子以后，我的心久久不能平静，震撼啊!为什么会有如此好的帖子!我纵横社区多年，自以为再也不会有任何帖子能打动我，没想到今天看到了如此精妙绝伦的这样一篇帖子。