从安全角度来看，迁移到无服务器环境有利也有弊。一方面，因性质使然，无服务器可以改善安全性。首先，您不必再为服务器打补丁。其次，无服务器计算的短暂性和无状态性让攻击者很难下手。最后，由于现在您的应用在云中采用大量的小功能块构造，您可以将每个计算单元视为一个单独的实体。
总之，无服务器架构让安全性在许多方面都变得更加简单，并且需要一种独特的、细化的方法。但是另一方面，无服务器也引发了其他变化，无服务器应用面临着独特的安全挑战，包括：
安全可视性
难以找到不同数据之间的关联
更多攻击点和攻击向量
每一个功能、API 和协议都是潜在的攻击点
边界侵蚀
无服务器应用导致边界变得更易渗透和分散化
更多管理权限
具有挑战性且耗时
无处部署安全控件
WAF、防火墙和 IDS 等传统网络或边界防护系统无处安放
更多功能和更多变化意味着更多风险
无服务器具有短暂性和分散性，这意味着更频繁的状态变更和更多的风险管理及安全审核要求
应用安全威胁始终存在，只是形式和行为有所不同。实现控制和安全性需要思维方式的彻底转变。人们应该少将防御重点放在特定事件上，多加关注这些重复性无状态攻击的整体模式。
那么，保护无服务器应用是谁人之责？
新技术的诞生总是会让人们忘记前车之鉴，导致安全告急。不管应用团队的做法是对是错，还是无关紧要，开发人员都将他们视为绊脚石，认为他们是导致延迟的祸首之一。无服务器也不例外。但不同的是，无服务器应用保护的责任归属还不明确。
传统 AppSec 方法耗时长、拖进程，抵消了无服务器的快速部署优势。如果开发人员等待安全人员为其打开端口、分配 IAM 角色或建立专属安全组，那么他们原本开发出的超高速方法就白费了。虽然安全专家也不想妨碍开发人员，但他们仍然需要控制策略和可视性，如何在不延缓进程的情况下联合 DevOps 实施安全控制成为他们的一大难题。这让所有人都陷入了困境。
保护无服务器应用，人人有责
保护无服务器应用离不开大家的共同努力，需要开发人员、DevOps 和 AppSec 的紧密合作。安全团队需要找到一个平衡点，既允许开发人员在能力范围之内实施最佳安全编码实践（自动化程度越高越好），又认真落实好自己的职责，在生命周期的早期阶段修复漏洞和解决问题，同时帮助开发人员确定问题的风险，即部署这一应用是否会危及业务安全。最后，创建跨职能团队，整合安全专家与开发团队的力量，实现与 DevOps 的紧密协作，确保安全问题不会抵消无服务器的速度优势。
对于相关最佳实践，以下是我的一点拙见，仅供参考：
- 绘制应用映射图，观察持续的信息流
- 在功能级别实施边界防护
- 针对每个功能创建合适的最小化角色
