3.2.2 使用云厂商的监控资源
现今各大云厂商均为Serverless配备了相应的监控资源，例如Azure Monitor、AWS CloudWatch、AWS CloudTrail等，使用云这些监控资源可以识别和报告异常行为，例如未授权访问、过度执行的函数、过长的执行时间等。
3.2.3 使用云厂商的账单告警机制
针对拒绝钱包服务（A denial-of-wallet，DoW）攻击，公有云厂商提供了账单告警机制进行缓解，如AWS开发者可通过在Lambda控制台为函数调用频度和单次调用费用设定阈值进行告警；或提供资源限额的配置，主流的云厂商已提供了以下资源选项供开发者配置：
（1）函数执行内存分配；
（2）函数执行所需临时的磁盘容量；
（3）函数执行的进程数和线程数；
（4）函数执行时常；
（5）函数接收载荷大小；
（6）函数并发执行数。
通过上述选项的合理配置可以在一定程度上缓解DoW攻击。
3.3 无计算服务被滥用的防护措施
针对Serverless被滥用的风险，我们可以采取以下方式进行防护。
（1）通过入侵检测系统（Intrusion Detection Systems，IDS）等安全设备监测木马在本机的出口流量，诸如“/pixel”“/utm.gif”“ga.js”等URL的流量应进行重点监测。
（2）确认自己的资产中是否有云厂商提供的Serverless函数业务，如果没有可以通过浏览器禁用相关云厂商的子域名。
（3）采取断网措施，从根源上直接禁止所有网络访问。
3.4 其他防护机制
由于云厂商通常缺乏一套自动化机制对现有Serverless应用中包含的函数、数据及可用API进行分类、追踪、评估等操作，因此开发者在不断完善应用的同时，可能疏于对应用数据及API的管理，从而导致攻击者利用敏感数据、不安全的API发起攻击。为了避免这种情况，开发者需要在应用的设计阶段对资产业务进行详细梳理。其中包括但不限于以下4个部分：
（1）确认应用中函数间的逻辑关系；
（2）确认应用的数据类型及数据的敏感性；
（3）评估Serverless数据的价值；
（4）评估可访问数据API的安全。
有了一个较为全面的应用全景图，便可在一定程度上降低应用被攻击的风险。
由于Serverless应用通常遵循微服务的设计模式，因此一套完整的工作流应由许多函数组成，而开发者可能部署了非常多的Serverless应用，在这些应用中，必定存在一些长时间不被调用的实例，为了避免被攻击者利用，应当定期对Serverless应用进行检测，清理非必要的实例，从而降低安全隐患。
开发者首先应当限制函数策略，给予其适当的访问权限，删除过于宽松的权限，这样即便攻击者拿到了访问凭证也无法对所有资源进行访问。
4 结语
由于应用架构的变化是带来新风险的主要原因，鉴于此，本文作者针对具体的风险提出了防护方法。其中，使用微服务治理框架Istio可以在一定程度上缓解应用架构带来的风险，此外，也介绍了Istio与API网关和WAF结合的业界方案，从而实现微服务应用的全流量防护。此外，作者较为系统地从Serverless应用及平台两方面对前述提到的Serverless风险进行了相应防护介绍。可以看出，与传统安全防护不同的是Serverless模式带来的是新型云原生下的应用安全场景。因而，我们需要适应云计算模式的不断变化，并不断总结新场景下的防护方法，才能最终将安全落实到底。
（原载于《保密科学技术》杂志2022年7月刊）