云原生(Serverless)安全-devsecops初探全图谱

本文基于serverless，主要针对中小项目，寻求具有普惠性质的安全方案。因为作者对腾讯云的实践经验多，解决的策略建议也以腾讯云为例，阿里云同理，可能只是功能的名字不同而已，但是其效果相同。

新时代、新安全：云原生安全的新特点

云原生（Serverless）将我们带进入了新时代，也就是下一代的计算平台。

传统的安全是基于边界防护的网络安全架构，是以职能区分、以人为主的防护策略安全，这已经不太能满足云原生的安全需求，云原生时代物理安全边界逐渐模糊，需要基于动态工作负载完成安全防护，变成了人人有责、无处不在的云原生安全体系。

传统安全主要是在右侧，云原生最大的特点是要求安全左移也就是安全前置，在开发的过程中就要考虑安全，将安全投资更多的放到开发安全，包括安全编码、供应链(软件库、开源软件等)安全、镜像及镜像仓库安全等，因此传统策略很多已经不再适用，对人员的安全意识和安全技能产生了额外要求。

很多技术人员认为技术才能保障安全，其实意识才是安全的最大保障。想想建国初期人人抓特务，想想朝阳区人民群众。

云原生改变了设施，我们不再是直接对CVM等传统硬件设施进行管理，而是部署于“执行环境”即屏蔽了传统硬件设施的“软资产”，如果说传统设施是有形资产的话，云原生的设施是“无形资源”。

因此云原生的安全应该主要由服务商来承担，内嵌于云平台，交付给我们的是基础安全的环境，我们只需要聚焦于业务相关的、少量的和高级的防护。云服务商可以使用超大型、大规模的安全策略和机制作用在整体的云原生上，我们是云原生环境的单个客户，平均下来单个企业安全成本很低的同时达到良好的效果。

我认为，云原生重塑了云服务商的安全体系的商业模式。

比如，腾讯云的API网关触发器的云函数，基础安全主要应该由API网关和云函数侧来负责，客户是需要重视并灵活使用安全配置提升安全系数，防御腾讯整体安全下的漏网之鱼。

云原生安全和传统安全并不同

新安全、新要求：云原生的安全架构和要求

安全有了新特点，那么他必然有独特的新要求。

项目的安全是为了保障在其商业价值实现过程中不被阻断。我们首先要明确一点：不能简单的追求安全的高度，安全本身也要高效和普惠，要降低中小企业安全负担，大负担、高成本的云安全是不适用的。

应该根据实际情况， 用合理的代价和恰当的方式让项目更安全，因此对于中小项目，必须在技术、成本和效果上有自己的取舍。比如业务开发周期都被疯狂压缩的项目中，是很难照顾并嵌入安全的。

安全方案不能一味追求技术和全面，能够被应用、可落地安全方案才是好方案。

安全方案要四化：框架化、轻量化、模块化、精细化。

框架化：安全功能尽量整合到框架中或提供成库。安全左移强制要求开发人员必须参与并进行编码，而开发人员更注重能给项目进度带来实质帮助的业务开发（除非公司绩效对安全进行考评，且与进度权重相同），因此在保证安全机制可以应用的前提下，给开发人员减负降低安全时间成本，安全的工作量越大越难落地，越容易产生偷懒情况。

轻量化：方案越重、上手难度越大越难以实施，聚焦核心需求的轻量方案更好落地。

精细化：serverless不同于传统安全，安全的管理必须精细到各个函数或API才能有效的进行安全防护，在serverless中，一篮子安全管理就是没安全。

模块化：安全应该可以便捷动态的开启和关闭，若安全机制较大的阻碍了进度（如测试的推进），会导致人员的抵制及项目商业价值的实现，因此模块化的安全就显得比较重要。

新要求、新技能-安全左移

左移的必要性：云原生就是用完即走，资源配置动态化和快速快速消亡化， 时间达到了毫秒级， 这就要求安全的检测和反应近乎于实时，外置和后置的安全很难达到这种要求，因此安全需要做到代码内置。

开发团队不仅要考虑高效地构建产品，还在构建时实施安全性，因此安全性从一开始就成为开发流程不可分割的组成部分，最初的设计到集成、测试、部署直至软件交付。对于项目成员来说就是人人为云安全负责， 也就是DevSecOps。

建议：安全性应该嵌入框架，融合到项目管理和项目进度中并为其预估工作量，不预留工作量会让成员抵触安全，并让安全流于形式，后期嵌入和追加安全的代价高昂，会让是否要安全成为两难的决策。

DevSecOps=Sec+DevOps, “左移”是 DevSecOps 的一种说法： 它鼓励软件工程师将安全性从DevOps（交付）流程的右侧（末尾）移至左侧（开头）。

新技能、新风险-云原生特有的风险

云原生的框架模式注重以服务为基础的细粒度拆分，serverless显著增加了服务的数量，打造了以服务为基础的新型应用模式，serverless未来也一定是细粒度拆分为主流（请注意，这里不是内涵腾讯云哈），但这个也给云原生带来了新的风险。

1. 服务商风险：云服务商对serverless的防护还很薄弱，有以下原因造成。

• Serverless目前是小弟弟级别的新生事务，各服务商将其重点放在DevOps工具链、生态环境、市场推广、行业技术培训、甚至是营收上（听说鹅厂的serverless为了营收要疯了？），对安全的需求他们认为不是当前的迫切，因此并非他们当前的重点工作（未来安全一定是重中之重）。
• 业界对serverless的防护尚无成熟的方案，属于摸着石头过河。
• 服务商都是在摸啊摸的，对外的安全培养更不行了，搜到的信息也就是跟专业安全厂商互通下有无、开个研讨会、搞个报告。

比如好像是20年还是21年的腾讯云的一个安全宣讲中提到“云原生安全是他们一个重点研究方向，未来他们会将云安全能力接入云函数”，潜台词就是现在还没有接入（到目前为止是否接入无明确信息确认）。当前云函数安全还是很薄弱，腾讯云现有云安全尚无消息确认已经应用在云函数。

腾讯云的serverless安全

2. Key的泄露：云原生应用对资源和设施的管理和使用基本都是基于Key，因此针对云原生的攻击首先的变化就是对key的攻击。根据统计，用户的api key无意泄露在github等网站其实是很常见的，因此有黑客专门去这些网站扫描无意提交的key信息。云服务商为了应对这种新攻击，基本都与GitHub这些主流的网站进行合作，主动扫描发现这些泄露的key并及时通知其客户消除风险。

北卡罗莱纳州立大学的一篇研究报告则直接指出，“我们在涉及到的10万开源项目中发现，凭证泄漏问题不是一次性偶然问题，而是每天都在发生的，有数千新的、不重复的机密凭证公布到了网站”

3. 云原生配置风险： Serverless使用的资产是品类多、动态的、用完即走的， 各种安全配置分散在各个产品中，缺乏统一管理和运维平台，难以做到管理和检查，从而导致配置安全和隐患，配置安全这个是容易被忽略的。多产品联动已经足够困难，更棘手的是，不少项目会跨厂商联动，比如组合了阿里云、腾讯云、高德开放平台、百度云等的产品，造成难度系数陡增。

不认真进行安全配置 就如同买了高昂的防盗门但出门却把钥匙插门锁上一样。亚马逊报告称数据泄露70%是权限配置不当造成的， 因此云安全提升了额外要求，就是云产品的配置学习， 这个也是最容易忽略出错的。

3. 资产多：采用云原生的时候，资产比较隐蔽变化也快，这个需要云服务商多多工作，同时跨厂商的使用让复杂度也更提升

4. API风险：serverless是细粒度的服务，他的安全重点也就是API安全，如API异常调用、越权操作、违规调用。

5. 内部审计风险：云服务商的Serverless无法保障细粒度的操作的记录和安全性，如更新代码人员、部署新服务人员、删除函数人员等，或要想实现付出的成本很高昂。

6. 功能天然风险：当前包括腾讯云的云函数在内的主流serverless云服务商，都提供了镜像部署和代码部署两种方式。在安全方面，镜像部署面临更多的安全风险（如镜像安全风险、镜像仓库安全风险）。

7. 安全变量风险：若将配置或敏感信息保存在环境变量，一旦被突破这些信息直接泄露、被修改甚至被利用。建议：少用或不用环境变量， 因此复杂的环境配置而导致必须用镜像部署的， 应该考虑将各种环境变量配置使用配置文件

8. 攻击面广：serverless中微服务模式部署有着其先天的优势而一定成为主流，但微服务随之带来了新的风险，可供攻击的面也更广泛；建议：采用“零信任”的理念来处理每次的访问的安全防御。

9. 环境变量风险：使用环境变量替代配置文件虽然存储更简单，但是使用环境变量本就是不安全行为，攻击者进入运行环境，可以轻易获取、修改环境变量信息，引发信息泄露。 腾讯云的文档做的就不好，竟然有把数据库的账号密码配置在环境变量

腾讯云的云函数文档

10. 资源权限管控风险：传统的基础设施是静态的，serverless中基础设施的出现和使用是函数级动态的，因此每个函数与资源的权限映射会非常多，如何高效进行角色和权限的管控是个复杂问题，很多开发者暴力为所有函数配置单一角色和权限，这一行为极大增加函数使用风险。

11. 跨函数调用数据清理不及时引入数据泄露风险：在运行过程中，调用结束后没有及时清除暂存的配置参数、账号信息或其他业务敏感信息，后续调用的函数访问时，可能存在越权和获取机密数据的情况。在“单实例多并发”或“请求多并发”功能的加持下，这个风险又会额外增加。建议：函数执行时，不要偷懒直接复用当前已经存在的文件、内存变量、配置信息等，而是每次都应该视为全新使用，有临时存储的需求时，必须检测操作的成功与否，以免误用历史信息。

12. 缺乏serverless专有安全解决方案：现在的安全工具和安全体系是基于云场景中的虚拟机或容器底座，基于web应用或传统框架进行设计开发和应用的。在servless上这些无法直接匹配或使用。

13. 钱包攻击：传统攻击以阻塞业务为目标，serverless的安全性让攻击者无法阻塞其业务，只能转而进行钱包攻击。

建议：

1. 凭证保护：不要将AccessKey嵌入代码中，嵌入代码中的凭证容易被人忽视，经验丰富的开发者会将其写入数据库或者独立的文件中，使得其管理起来更方便。
2. 异常调用保护：核心流程制定好API调用顺序，检测是否顺序调用，如果不是则为异常调用，异常的可以不返回任何数据，以节省开支或迷惑攻击者。
3. 对IP调用次数和来源地限制，很多攻击者会使用国外IP进行攻击，若无海外客户，其实直接屏蔽海外IP可以规避一些问题。
4. 短时间 高频次访问 也为异常访问
5. 低负载：灵活使用云服务商产品，比如在腾讯云的云函数，我们的监测可以通过cls来进行，这就不需要额外浪费自己的资源且降低系统的性能压力。
6. 不常用的函数限制其并发额。
7. 环境变量替代配置文件：我们应该将各项配置放在专门的配置文件，提供集中的、不断优化的安全防护，绝对不能偷懒放在环境变量。

关于平台依赖性：很多人将平台耦合作为项目风险。虽然业务代码追求平台松耦合，但Serverless的安全首先靠云服务商做第一道，再靠各产品的安全配置，serverless的安全很难通过外挂形态解决，而是寻求云集成方法，因此有着很强的平台依赖性。

与云原生平台深度的耦合，提供新型云原生信息基础设施的防护、检测和响应能力，并将云原生技术赋能于这些安全产品、应用和解决方案；因此虽然这是风险，但我认为根本不是目前应该考虑的风险，真正云原生的项目还处于起步期，更重要的是培养人员新的安全意识，探索可落地的安全方案和机制。当前只有较少的项目将一个平台的特性充分发挥出来了，在这种还很缺乏意识、高效、深度、使用前提下， 讲究跨平台是不理智的。

不能一味追求接耦合平台，除非有大神将主流云服务商的平台安全机制进行封装。

新风险、新原则-云原生安全设计原则

以devops为代表的研发运营体系，专注敏捷迭代。传统安全侧重以人为主的防护策略，已经不能满足云原生实例频繁启停的生命周期变化及海量的东西向流量交互，我们需要新的安全设计原则。

一个基础、一个中心、六个基本点：

一个基础：我们在上面了解了云原生是特有风险，因此要以云原生的思路为基础构建安全运营体系，而不是传统的体系直接搬过来。

一个中心：以服务为中心构建安全防护措施，我们防护的是服务，不是硬件设施也无硬件设施。

六个基本点：

1. 零信任：最小权限原则实施权限管控：给函数不同角色，实现函数层面访问控制，每个函数都不应当信任其接受的参赛，具体“零信任”介绍见下方。
2. 安全左移：云原生安全运营的基本前提，业务部署前提前风险检查，
3. 持续监控和响应：应该为系统添加强大的实时监控和响应能力，以高效预测风险，精准感知威胁，提升响应效率，尽可能多的监控多个资源
4. 数据驱动：安全运营的基本要求， 打造云上安全数据湖，打通割裂的安全产品数据
5. 工作负载可观测：运用可视化工具发现和记录快速变化的应用行为，为自动化的安全检测提供详细准确的运行状态数据，为自动化的云原生安全提供充足的决策依据。
6. 账号安全：设置余额提醒 限制资源配额

新放心-良好的防御DDoS攻击

上面说的都是云原生的隐患，我们来说说云原生比传统的安全优势。

在网络攻击中，以攻击带宽或CPU资源的DDoS攻击是使用最广、最泛滥的攻击方式，我们将此攻击单独进行说明。

DDoS攻击的防御：

DDoS基本是低端的买流量攻击，只是不断发生请求，不会大量机器联动进行顺序攻击。在腾讯安全发布的《2021年上半年全球DDoS威胁报告》中统计的六种攻击手法，除了仅占用了5%比例的”其他”外，主流手法对serverless而言并不会怎么生效，有天然的防御优势。

攻击目的防御：

DDoS的一般攻击并不分析业务 只是通过发送大量请求，来达到攻击带宽或CPU的目的。

1. CPU攻击：DDoS攻击中通过发送大量的协议请求，主机被迫进行处理，虽然单个处理所需CPU很小，但是大批量时，CPU就会居高不小，从而导致CPU无效处理业务代码。传统服务器我们购买的是CPU，算力是有上限的，serverless我们购买的是分配到业务代码中的有效算力，云服务商自行负责承担其他算力，我们不需要关心攻击造成的非业务的算力浪费，因此不会惧怕CPU攻击。
2. 带宽攻击：传统服务器的带宽很昂贵且是固定的，DDoS向服务器传送大量的请求占据全部带宽，从而让正常的业务数据被丢包无法传入。serverless云服务商负责提供并保证足够的带宽，我们仅关注入参和出参的数据量而已，因此带宽攻击是难以奏效的。

域名防御：

DDoS是以IP、域名为重要目标进行拒绝服务攻击，因此防御DDoS的重要一条就是不能直接用IP，因此最近最出名的“某游戏”被攻击后难以防御的一个重要原因是他们客户端直接使用IP连接了服务器。

以腾讯云的云函数为例，每个云函数配置的API网关触发器本身会分配一个腾讯云的二级域名，对于APP和小程序来说我们可以直接使用这些域名。当我们使用这些域名的时候， DDoS攻击是落在这些域名上，这些域名由腾讯云管理，那么他们在承担响应的安全，因此大多的攻击方式并不会进入到我们的serverless中。

DoW攻击：

传统的DDoS攻击难以奏效，且好像并未针对serverless进行攻击手法特别优化。

因此当前针对serverless的攻击更多是传统攻击手段中的“模拟业务流量的高级攻击”，且攻击带宽和CPU改为DoW攻击。

DoW攻击(拒绝钱包攻击)，其目的是耗尽账户账单金额。 因为serverless多按照次数等付费，这个特性让产生的费用没有特定限制，如果攻击者掌握了事件触发器，在未受保护情况下，函数调用会极速扩展，随之产生的费用也爆发式增长，最终倒是账户受到重大损失。

虽然有着良好的防DDoS攻击天然优势，我们不能因此就麻痹大意，防御建议：

1. 除了被客户直接使用的域名外(如WEB网站），尽量使用腾讯云提供的域名
2. 触发器的配置以最小原则，能不配置的就不配置，如API网关触发，能只配POST的就只配POST，能用POST就不要GET。 API网关触发里url、协议都全匹配才能成功调用，不成功的调用不收费，
3. 保护好API KEY，千万不要在客户端进行保存，不要使用静态KEY，转而使用最小权限和有时效的临时KEY，以规避KEY泄露而导致被通过SDK调用，云平台的任何安全措施基本都无法抵御这种攻击。
4. 增加API网关鉴权，虽然鉴权其实无法规避模拟业务流量的这种高级攻击，但是时效的限制起码可以很大提升攻击的门槛， 大部分的团伙就是租用第三方攻击工具发起攻击的，鉴权就可以把这些攻击全部直接过滤掉。
5. 应该监测异常调用，如API的调用顺序等，胡乱顺序的调用必然是异常的，此时不应该给予返回信息，一来返回数据会产生额外费用，二来会让攻击者感知到攻击的效果，注意：通过API网关触发的云函数，即便我们直接终止了程序的执行，依然会返回一定的数据
6. 我们对ddos攻击要做的是减少数据库读取量，读取数据库是攻击重点，对方不会攻击静态页面等功能，没有战略价值。企业负责业务安全和数据安全，token多存储在数据库 这对ddos来说，本身校验token需要读取数据库占用数据库资源，那么这个操作对于攻击来说就已经生效了。
7. 高级校验：利用cls对api接口调用次序进行验证，不正常的调用顺序就是非法的。
8. 业务安全：网站核心接口保护（购物车 支付 订单）做好判断鉴权。攻击针对复杂接口 核心接口
9. 用日志cls可以做安全功能，节省数据库。cls本身也是数据库 支持sql
10. 云函数使用的是腾讯云整体带宽，可以说不会阻塞，传统的你要求奶奶的去求服务商帮忙，云函数反正是腾讯云负责，轻松躺平即可。但是也有弊端，流量上限无限，因此我们需要限制独享内存，这样不单限制了并发上限，也限制了流量上限，保证了这个函数占用的服务资源不会扩散从而影响整体。每个函数做好限制，可以异常情况不返回数据，降低损失。购买攻击是要花钱的，他们的花费比我们的损失大的时间，攻击就不可能继续存在
11. 每个函数配置最低的内存空间，配合独占内存进行安全防御
12. 采用零信任机制，处理好模拟业务流量的高级攻击。
13. 双域名策略，随时紧急切换到备用域名的备用环境

遭遇攻击 只返回正常业务，所有鉴别出错的都不返回任何信息。只要不触发云服务商的丢包就不怕，cls鉴别IP自己取消返回，还不影响自己的数据库性能（必须配合bot头日志输出）

零信任-serverless最强大的盾，没有之一

他是抵御模拟业务流量攻击的利器，零信任不是产品、不是体系架构，他是一种理念，使用方法取决于你自己。

一句话了解零信任：一切都不是安全的。

最初的零信任框架模型是由著名研究机构Forrester的首席分析师John Kindervag在2010年提出的，在Google的BeyondCorp项目中得到了应用后发展到国内。

零信任的核心思想可以概括为：一切都不是安全的，也就是永不信任，始终验证，授权时则必须最小授权，阻止权限突破。

如腾讯云中涉及cos的使用、API网关的使用，不管他的角色和操作是不是合法的，只通过CAM的策略机制分配一个最低权限的临时key使用。

零信任的范畴大，涉及面广，因此在serverless中应用零信任，需要对其进行收缩修改，直接使用成本太高且不见得实用。

Google的零信任体系的基础设施是身份，根据身份做权限管控持续的不信任，在Serverless中零信任的基础设施是函数级的业务，我们根据此函数的业务给与最低权限和最小的资源。

以腾讯云的云函数调用为例实现0信任：

1. 能用临时key的绝不用静态key：腾讯云虽然推荐使用子用户来实现安全，但是子用户属于静态的安全，绝非真正的安全， 任何人获取了此用户的key和sec后就可以获取全部权限，
2. 临时key要给最低资源，资源的权限拆分成读写执行细分权限，权限给与最小权限。如：若我们每次调用的时候， 根据用户请求所属的领域， 给与一个最小权限(比如要执行函数A则只给予A函数的执行权限，要更新A函数则只给与A函数的执行权限， 这样可以防止逻辑错误等造成的后果蔓延及攻击) 动态生成一个”联合身份临时访问凭证”才能做到真正安全。
3. 能不给外网的就不给外网
4. 能不给固定IP就不给固定IP
5. 资源的访问，能用私有网络就要给私有网络。

框架落地建议：

腾讯云的”联合身份临时访问凭证”是腾讯云中实现“零信任”的核心，它是基于CAM的，他们复杂、繁琐、易出错真的不像是现代设计出来的，更像是上个时代的产物。

这个"联合身份临时访问凭证”的生成是需要代价的，若创建函数，则同时还需要赋予触发器权限或API网关权限， 腾讯云的CAM很复杂不单是语法复杂，其涉及产品关联复杂，对于没有云原生全栈经验的中小项目来说，其学习和开发成本不亚于一个核心开发，并且也容易在使用过程中遭遇权限限制阻碍项目进度， 说不准就会项目进行一半就抛弃CAM开始摆烂，因此将其应用也是一个很大的挑战。因此我们需要将其封装，提供适合项目的更便捷的无需学习的方法（如借鉴Linux的777的权限机制），这样就极低成本实现了0信任。

至此我们serverless的安全介绍就结束了，后面我会根据devops的路径的各个环节来说下如何落地。

本文借鉴引用的文章如下(包含且不仅含, 资料查询的较多,难以一一列举):

2020年全球DDoS威胁报告 - 腾讯云

2021年上半年全球DDoS威胁报告 - 腾讯云

2021年云原生架构安全白皮书 - 云原生产业联盟

零信任的发展及其在远程访问中的应用 - Omdia

云原生安全白皮书技术详解 - 中国信息通信研究院云大所副所长 栗蔚

如何构建云时代的云原生安全运营中心？- 耿琛 腾讯安全高级工程师

云原生安全云防火墙核心能力与最佳实践 - 周荃 腾讯安全云防火墙产品负责人