最近几年，无服务器计算技术实现了显著的增长，同时也伴随着新解决方案生态系统的蓬勃发展。这些新的解决方案提供了可观察性、实时追踪、部署框架、以及应用安全性。
随着无服务器安全风险逐渐引发人们的关注，那些嘲笑者和愤世嫉俗者们所谓“FUD”——恐惧、不确定、怀疑——的习惯又一次发作，他们指出，尽管无服务器技术在软件快速部署和大幅降低TCO方面有着巨大的价值，但同时也带来了新的安全挑战。
不断演化发展的无服务器生态系统
衡量一项成熟技术的关键指标之一，是该技术的生态系统。是否拥有蓬勃发展的社区、广泛的文档、实践指南和工具，决定了企业组织是否会信任并采用新的技术。
最近，云安全联盟(Cloud Security Alliance，CSA)联合PureSec公司合作撰写了一份无服务器安全指南，这份指南从去年的版本中汲取了大部分的内容，同时增加了两个重要的风险等级。
这份题为《无服务器应用12个最严重的风险》的指南，是针对那些处理无服务器应用的安全和开发受众编写的，但内容并不仅限于指出这些风险的存在，还为所有主流平台提供了落地实践。我们对风险类别的定义如下：
风险1：功能事件-数据注入
无服务器技术可以采用不同事件源输入的数据，而且每个事件源都有自己特有的消息格式和编码机制。这些事件消息中，可能包含了受黑客控制的、或者不受信任的数据输入，这些是需要经过严格审查的。
风险2：认证失败
由于无服务器改善了面向微服务的系统设计，因此应用可能包含数十个甚至数百个功能。如果不谨慎执行的话，身份验证过程中就很容易出现错误。
风险3：不安全的无服务器部署配置
云提供商提供了很多设置选项，可以根据特定需求调整服务。开箱即用的设置不一定是最安全的选择。随着越来越多的企业组织迁移到云端，云配置出现漏洞也越来越普遍。
风险4：过度特权功能权限和角色
管理功能权限和角色，是企业组织在把应用部署到云端时，面临的最艰巨的安全挑战之一。有时候开发人员想走捷径，采用“通吃”的权限模型，这是很常见的。
风险5：功能监控和记录功能不足
虽然大多数云厂商都提供了非常强大的日志记录功能，但这些日志并不一定适合于在应用层提供完整的安全事件审计跟踪功能。
风险6：依赖于不安全的第三方
虽然第三方库的不安全性，并不是只有无服务器技术才有的缺点，但由于缺乏应用网络和行为安全控制能力，无服务器环境中检测出的恶意软件包要更加复杂一些。
风险7：不安全的应用秘密存储
应用秘密存储最常出现的问题之一，就是把这些秘密信息简单地保存成某个软件项目中的一个纯文本文件，或者是把这些秘密信息保存成一个作为环境变量的纯文本文件。
风险8：拒绝服务和财务资源枯竭
无服务器架构具有自动可扩展和高可用性等特点，但是，与任何其他类型的应用一样，无服务器需要采用良好的设计以避免出现瓶颈，是至关重要的。
风险9：无服务器业务逻辑操作
业务逻辑操作是很多软件中常常出现的问题。但是，无服务器应用有些特殊，它们通常遵循微服务设计的，其中包含的各种功能是链接在一起形成了一个逻辑整体的。如果执行不当的话，可能就会被攻击者篡改预期的逻辑。
风险10：不恰当的异常处理和详细错误消息
与标准应用的调试功能相比，无服务器应用的逐行调试功能是受到限制的，而且更复杂一些。因此，经常会出现很冗长的错误消息，这可能会导致敏感数据的泄漏。
风险11：遗留的/未使用的功能和云资源
随着时间的推移，无服务器功能和相关的云资源可能会过时，应该被淘汰掉。处理过时的组件，是为了减少不必要的成本，并消除可以避免的受攻击面。过时的无服务器应用组件，可能是那些不好的无服务器功能版本、未使用的云资源、不必要的事件源、未使用的角色或者身份、未使用的依存关系。
风险12：交叉执行数据持久性
无服务器平台为应用开发人员提供本地磁盘存储、环境变量和内存，用于执行任务。为了让无服务器平台能够高效处理新的调用，云提供商们可能会在后续的调用中重复利用这个执行环境。如果无服务器执行环境被反复用于后续的调用，属于不同的用户或不同的会话，那么就有可能遗留下来敏感的数据，并出现敏感数据泄露。
该指南的目的是提高人们的认识，帮助企业组织安全地进行无服务器方面的创新，而不是传播恐慌。任何平台都存在安全风险，无服务器也不例外。CSA提出这些问题的目的，是为了鼓励企业组织采用新的技术，同时避免风险和常见错误。
