主机安全加固

针对应用程序访问控制

权限的攻击针对应用程序访问控制权限的攻击在 Serverless 场景下也同样存在，例如函数对某资源的访问权限、 可以触发函数执行的事件等。下面以数据库举例，函数执行业务逻辑时不可避免会对数据库进行 CRUD 操作，在此期间，我们需要给予函数对数据库的读写权限。在不对数据库进行其它操作时，我们应当给 予只读权限或关闭其权限，如果此时开发者
将权限错误的更改为读写操作，攻击者会利用此漏洞对数据 库展开攻击，从而增加了攻击面。Serverless 应用可能会由许多函数组成，函数间的访问权限，函数与资源的权限映射可能会非常多， 高效率管理权限和角色成为了一项繁琐的问题，许多开发者可能暴力地为所有函数配置单一权限和角色， 那么进而会导致单一漏洞扩展至整个应用的风险，这也是当前面临的一大问题。

针对应用程序

数据泄漏的攻击在应用程序中，敏感数据信息泄漏、应用程序日志泄漏、应用程序访问密钥泄漏、应用程序未采用 HTTPS 协议进行加密等是一些常见的数据安全风险。通过调研发现，这些事件的产生多是由于开发者 的不规范操作引起，例如将密钥信息，数据库连接密码等敏感信息硬编码在应用程序中。
需要注意的是，在 Serverless 中以上这些威胁同样存在，但与传统应用程序不同的是：

1. 针对攻击数据源的不同，传统应用只是从单一服务器上获取敏感数据，而 Serverless 架构中攻
   击者可针对各种数据源进行攻击，例如云存储（AWS S3）或 DynamoDB 等，因此攻击面更广；
2. Serverless 应用由众多函数组成，无法像传统应用程序使用单个集中式配置文件存储的方式，
   因此开发人员多使用环境变量替代。虽然存储更为简单，但使用环境变量本是一个不安全的行为；
3. 传统的应用开发人员并不具备丰富的 Serverless 的密钥管理经验，不规范的操作易造成敏感数
   据泄露的风险；
   2018 年 6 月，著名开源 Serverless 平台 Apache OpenWhisk 曝出 CVE-2018-11756 漏洞 [29]，应用 程序含有漏洞的情形下，攻击者可能会利用漏洞覆盖被执行的 Serverless 函数源代码，并持续影响函数 后续的每次执行，如果攻击者对函数代码进行精心伪造，可进一步造成数据泄露、RCE（远程代码执行） 等风险。

针对平台账户的拒绝服务攻击

针对平台账户的攻击主要为 DoW（Denial of Wallet）攻击，顾名思义指拒绝钱包攻击的意思，为拒 绝服务 DoS 攻击的变种，目的为耗尽账户账单金额。
Serverless 具备一个重要特性为自动化弹性扩展，开发人员只需为函数调用次数付费，而函数弹性 扩展的事情交给了云厂商，这一特性是 Serverless 备受欢迎的原因之一，但为此特性产生的费用通常没
有一定的限制。如果攻击者掌握了事件触发器，并通过 API调用了大量函数资源，那么在未受保护情况 下函数将极速扩展，随之产生的费用也呈指数增长，最终会导致开发者的账户受到重大损失。
2018 年 2 月， NodeJS 的“aws-lambda-multipart-parser”库被曝出 ReDoS 漏洞（CVE-2018-75 60）[30],该漏洞可导致使用了该库的 AWS Lambda 函数运行超时，攻击者可利用此漏洞构造大量并发请 求从而耗尽服务器资源或对开发者账户造成 DoW攻击。

云原生安全防护思路

云原生安全设计原则

以 DevSecOps 为体系的敏捷开发体系下，开发安全和运营安全是一体化的。安全运营的负责人（一 般是 CIO或 CISO），则需要考虑如何在给定的安全预算前下，将整体的 IT安全防护能力最大化，本 节介绍了三个基本原则。

安全左移

在云原生安全建设的早期，运行时容器生命周期短、业务复杂，而且存在与操作系统虚拟化的环境， 现有的物理或虚拟化的安全设备无法工作，因而在这种困境下，增加运行时的安全投入无助于高整体 的安全水平。
国内外在过去两年出了安全左移（ Shift Left）的思路，即在云原生安全建设初步将安全投资更多 地放到开发安全，包括安全编码、供应链（软件库、开源软件）安全、镜像（仓库）安全等。这些方面 资源大多是白盒的，相应的安全投资相对较少；而且这些资源生命周期较长，如果能保证安全性，攻击 者在攻击运行时实例得手后更难持久化。

聚焦不变

当云原生安全体系大体完成了开发侧的安全建设后，安全团队必然还是要将目光移到运行时，因为 这部分永远是攻击者最常用的入侵环节。
然而，云原生运行时存在诸多挑战，例如容器存活时间短、编排业务繁多、服务网格业务交互模式 复杂，这些挑战来源于运行时的资源和行为快速变化，无法通过规则等固定的模式进行检测和处置。
既然运行时安全是重要且必要的，那就需要分析这些资源和行为的变化规律，只要规律模式是可预 测的，那就可以聚焦在这些不变的规律，从而找到异常和正常的边界。
具体地，容器对应的镜像、文件系统等，都是不变的，由相同或继承的镜像启动的容器的进程和其 行为是相似的，用于微服务的容器进程是少数且其行为是可预测的，可以通过学习进行画像的。

关注业务

微服务所承载的都是各位对外和对内的业务，无服务则更进一步，将容器、依赖库等简化，使得开 发者只需编写业务逻辑的代码即可，因而，云原生整个体系中最贴近最终价值的是处于最顶层的业务。
因而，安全团队在完成开发阶段和运营阶段安全机制的部署之后，应该重点关注业务安全，及时检 测针对业务的欺诈、滥用行为，如是公有云原生环境可对外第三方用户提供增值服务，获得更高的收益。

面向云原生全生命周期的安全防护

报告的开篇我们到，云原生安全包含了两层含义：“面向云原生环境的安全”和“具有云原生特 征的安全”。因此，做好云原生安全，则必然需要使用“具有云原生特性的安全”技术去实现“面向云 原生环境的安全”，采用原生安全的方式构建云原生安全防护体系。
云原生安全究其根本是要保证云原生应用的安全，因此，云原生安全防护体系的建设也要围绕云原 生应用的生命周期来进行构建，这同样也是敏捷开发中 DevSecOps 所倡导的应用安全模式。
图 4.1　云原生全生命周期的安全防护
云原生应用的整个生命周期，大致可以分为两个阶段：第一就是在开发 / 测试阶段（Development）， 完成应用源代码的编写、容器镜像的构建以及容器镜像的存储；第二是在生产环境中的上线运营阶段 （Operations），完成应用容器的部署、上线运行。
因此，云原生安全防护体系的核心就是覆盖应用的整个生命周期，保证云原生应用在镜像制作、镜 像存储、镜像传输、容器运行时的安全。

云原生安全加固

镜像安全检测与加固

源代码安全审计

针对容器镜像，采用分析工具与人工审计相结合的方式，根据供的应用开发过程文档，审阅系统 实现的技术方案，对架构的安全性进行审计和评估，分析系统防护薄弱点及可能存在的安全风险。
审计实施人员对系统重要业务场景进行风险分析并审计源代码，如转账、查询等涉及资金和用户敏 感信息的功能场景，在人工分析的过程中，实施人员会通过源代码安全审计工具，对全部代码进行自动 化审计，以保证源代码安全审计的全面性。
源代码安全审计过程中，除源代码脆弱性审计外，我们还会参照相关标准和规范，对业务实现的合 规性进行审计。

镜像扫描

漏洞的检测是对镜像进行安全加固的重要措施之一，这里的漏洞检测主要还是针对已知的 CVE进 行扫描分析。比如可以使用 Clair、Anchore 等开源工具，或者某些商业的漏洞扫描产品，也同样支持对 容器镜像的漏洞扫描。
除了漏洞之外，还有一些通过扫描镜像中的环境变量、操作命令以及端口开放信息来识别恶意镜像 的方案，但仍然需要使用者自己基于结果来判断，还不能直接给出一个明确的结果。

主机安全加固

主机基本安全加固

容器与宿主机共享操作系统内核，因此宿主机的配置对容器运行的安全有着重要的影响，比如宿主 机中安装有漏洞的软件可能会导致任意代码执行风险，端口无限制开放可能会导致任意用户访问风险， 防火墙未正确配置会降低主机的安全性，没有按照密钥的认证方式登录可能会导致暴力破解并登陆宿 主机。
从安全性考虑，容器主机应遵循如最小安装化，不应当安装额外的服务和软件以免增大安全风险； 配置交互用户登陆超时时间；关闭不必要的数据包转发功能；禁止 ICMP重定向；配置可远程访问地址 范围；删除或锁定与设备运行、维护等工作无关的账号、重要文件和目录的权限设置；关闭不必要的进 程和服务等安全加固原则。

参考资料

绿盟 云原生安全技术报告

友情链接

网络安全产业高质量发展三年行动计划 (2021-2023年)