无服务器体系架构：应用安全范式转换

所谓范式转换（ParadigmShift）指思维习惯和价值观的长期变化和转移。而无服务器（Serviceless）系统架构打破了人们的习惯思维，使服务器看不见，使整个开发部署过程更加安全高效，为所有开发部署运维人员带来了软件架构和应用部署的新大陆。然而，无服务器的架构方法并不能解决所有的问题，相反，它也会导致一系列新的安全问题和挑战。

如果你问软件开发人员什么是软件架构，你可能会得到各种各样的答案：蓝图或计划、概念模型或整体情况。毫无疑问，架构或缺乏架构与软件的成败有关。良好的架构有助于扩展Web或移动应用程序，而糟糕的架构可能导致严重问题，势必需要重写、花费高昂成本。

无服务器系统架构最大的安全优势之一是，它可以帮助开发者摆脱运行后端应用所需服务器设备的设置和管理更新。无服务器系统架构提供商负责这些任务，然后以服务的形式为开发者提供所需的功能，如数据库、身份验证等。

然而，尽管开发人员不再需要对无服务器云提供商处理的许多安全任务负责，但他们仍然需要负责为具有服务器逻辑的应用程序编写强大的代码，并确保这些应用程序代码没有应用程序层漏洞。现在看来，这项任务不会很快消失。

至于云供应商方面，将负责提供用于运行这些代码的服务器，并在必要时对服务器进行缩放。执行完毕后，承担这些功能的容器会立刻停用，并且执行过程以100毫秒为单位进行度量，用户只需为运行代码过程中所消耗的资源付费，一些人将这种模式叫做功能就是服务（FaaS）。

此外，任何与应用程序本身或云服务相关的配置也需要安全保护。因为任何错误的设置和云服务的错误配置都可能成为无服务器系统架构的攻击入口，导致敏感机密信息泄露和潜在的中间人攻击（MiTM）提供入口点。同样，该任务也是应用程序所有者的责任。

云供应商将在无服务器的世界里与您分担安全责任。下图显示了共享无服务器安全责任模型：

应用程序所有者：是云内的所有者（Owner"in"theCloud）负责。包括客户端、云数据、传输数据（包括在公共或不可信网络上流动的信息，以及在私人网络中流动的数据，如企业或企业局域网）、应用程序、身份和访问管理、云服务配置等。

虽然无服务器系统结构简单高效，但也引入了一系列新问题和应用挑战：

1.攻击面不断增加

例如，无服务器功能消耗来自各种事件源的数据HTTPAPIs、消息队列（messagequeues）、云存储和物联网（IoT）设备通信等。而且务器系统架构几乎不同Web在环境中，开发人员知道哪些消息不应该被理解和信任（GET/POST参数、HTTP标头等。).这大大增加了无服务器系统结构的潜在攻击面，特别是消息使用协议和复杂的消息架构时，其中许多不能通过标准的应用程序层进行保护Web检查应用防火墙)。

2.攻击面的复杂性

有些人可能很难理解无服务器系统架构中的攻击，因为这样的系统架构相对较新。许多软件开发人员和架构师没有获得足够的安全风险经验，以及保护此类应用程序所需的适当保护措施。

3.整体系统复杂性

无服务器系统架构的可视化和监控仍然比监控标准软件环境更复杂。在侦察攻击阶段，威胁实施者试图打破网络防御和弱点，这也是检测可疑行为并关闭网络安全解决方案的关键。由于无服务器架构停留在云环境中，本地实时网络安全解决方案是多余的，这意味着可能会错过早期攻击的发现迹象。虽然无服务器系统通常提供日志记录功能，但可能不适合安全监控或审计。

4.安全试验不足

无服务器系统架构的安全测试比测试标准应用程序更复杂，特别是当这些应用程序与远程第三方服务或后端云服务（如NoSQL数据库、云存储或流处理服务)交互。此外，自动扫描工具不适用于扫描无服务器应用程序。

传统的安全防护措施不适用：由于无服务器系统架构的组织无法访问物理（或虚拟）服务器或其操作系统，因此无法部署基于主机的端点保护、入侵防御等传统保护层Web防火墙或应用程序RASP（实时应用程序自我保护)解决方案——它是一种新型的应用安全保护技术。它将保护程序像疫苗一样注入应用程序，并与应用程序集成，可以实时检测和阻断安全攻击，使应用程序具有自我保护能力。当应用程序遇到特定的漏洞和攻击时，可以自动重新配置，无需人工干预。

这是最后一个（即传统的安全全防护措施不适用）要求在无服务器系统架构的应用程序安全方面进行大范式转换。根据定义，在无服务器系统架构中，您只能控制应用程序的代码，这几乎是您所拥有的唯一东西。这意味着，如果您需要保护您的无服务器代码，唯一的选择是确保您编写了安全代码，并将其集成到应用程序中。

这实际上并不是一件坏事——无服务器计算迫使软件架构师和开发人员以将安全性构建其中的方式来解决安全问题，而不是在发生问题时再去进行安全防护。很显然，这是一种更为积极主动的方式。（来源：安全牛）