无服务安全性的策略、工具和实践

不可否认，我们在得益于无服务器带来的效率、可扩展性、以及成本优势等功能与便利的同时，必须保证无服务器应用的安全性。在本文中，我将向您介绍如何使用AWS Lambda和相关工具，来开发无服务器功能，以及那些行之有效的无服务器安全策略和优秀实践。

总体而言，无服务器的安全性处置方法可分为两类：运行时(runtime)安全和静态(static)安全。

运行时安全

毫不夸张地说，无服务器的相关功能一旦开始运行并被调用，其安全隐患就出现了。特别是涉及到有用户输入信息时，暴露的攻击面会更大。例如：恶意用户可能通过SQL注入的方式，窃取甚至删除后台的数据。同样，跨站点脚本(XSS)攻击可以将脚本注入到运行在无服务器的微虚拟机(microVM)上。如此，就算无服务器已执行完了所提供的功能(或是超时了)，microVM仍会spin down，而此时XSS攻击便可以在无服务器环境中站稳脚跟，通过启动其他进程来兴风作浪。

我们既可以将无服务器的安全保护作为一个功能性层面来运行，也可以将其作为并行的进程来运行。而此类保护既可以验证用户输入的完整性，又能够监控文件、进程和连接是否存在着任何异常或恶意行为。

不过，在函数每一次被调用时，安全保护都被激活。这往往会增加运行时间，特别是在无服务器的情况下，每次就会增加100ms的运行成本。而且，如果需要加载较大的代码包，那么此类延迟的增加，就会对整体性能造成较大的负面影响。话虽如此，对于那些金融服务和关键性基础设施的应用而言，由于安全性比性能更为重要，因此运行时安全对于它们的无服务功能来说，是必不可少的。

实际上，无服务器功能已经自带了不少安全机制。例如：恶意攻击无法在运行时中更改函数的代码，毕竟它仅能作为一个实例被执行。同时，无服务器功能通常运行在AWS Lambda等云端服务上，而云服务提供商自身已经提供了免受DDoS攻击、DNS攻击、TCP SYN攻击、以及会话劫持攻击的能力。因此，用户只需遵循编程时的各种优秀实践，并保持每个函数在逻辑上尽量简单，即可达到运行时安全的效果。毕竟，随着应用的迭代，代码量的逐渐增多，功能性超时也会随之增加。因此，我们需要持续通过运行时安全，来保护无服务器的各项功能。

静态安全

静态安全是从执行前的检查阶段，以及执行后的取证分析阶段，来保护无服务器的各项功能。

具体而言，执行前的检查可遵循如下安全检查列表(其中，前三点是无服务器安全性特有的要求)：

1. 为每项功能分配一个角色，以定义其对于资源的访问权限。建议做法是：授予必要且最低的访问权限。

2. 为了避免由于错误的配置所导致的安全漏洞，请将所有资源都组织到同一个应用之中。

3. 在访问规则上，应当设置为：每个资源都需要用单独的凭据来访问，并对凭据进行安全管理。

4. 严格地限制功能发布、路由更改、以及负载分布的变更等权限。

5. 持续扫描功能库，并及时修复发现的漏洞。

为了将上述安全措施集成到CI/CD流程中，光靠人工干预显然是不够的，我们需要通过安全自动化的规模性能力，来保护各项功能与资源。

第二阶段则是通过一系列来自云提供商的工具，在执行后进行取证分析。例如，我们可以使用AWS CloudWatch、AWS X-Ray、AWS Security Hub、AWS GuardDuty、以及最新的Amazon Detective，来监控和分析AWS Lambda无服务器的各项功能。

无服务器功能的开发工具与实践

由于AWS Lambda具有对Java、Go、PowerShell、Python、Node.js、C#和Ruby的原生支持，因此在以下的示例中，我们将使用Python、Node.js或Ruby语言，通过基于Web的AWS控制台，来创建一项无服务器功能(如下面的屏幕截图所示)。值得注意的是，AWS提供的用于编写函数的文本编辑器，并不适合创建那些会用到多个文件、软件库、以及依赖项的大型函数。

当然，您也可以选择使用AWS的命令行界面(CLI)工具，在本地开发和提交各项功能。您可以参考这里，来进一步了解AWS CLI的安装和配置。

同时，您可以把在本地开发好的所有源代码文件，放入一个zip文件，然后上传到AWS CLI中(如下所示)。

我们需要通过更强大的开发工具，以及专用的开发环境，来开发更为复杂的服务，以及在CI/CD管道中引入可扩展的自动化静态安全。这里罗列了各种强大的、适合开发人员的AWS工具。此外，Lumigo网站也提供了一些较为实用的工具，具体请参见–https://lumigo.io/blog/comparison-of-lambda-deployment-frameworks/。

无服务器框架(Serverless Framework，SLS)是目前最受欢迎的开发工具，它在GitHub上获得了超过38,000颗星。AWS无服务器应用程序模型(Serverless Application Model，SAM)则是另一款十分流行的工具。它们都能够让开发人员在serverless.yml文件中，构建无服务器项目。此类项目可以被转换为CloudFormation模板。AWS将它用来创建各种所需的资源。具体而言，SLS和SAM能够提供：

1. 基础架构即代码(Infrastructure-as-code)定义了CloudFormation中的资源，其中包括：无服务器功能、API网关、Amazon S3存储等。

2. 本地功能性测试。

3. 多阶段性的CI/CD管道集成。

4. 完全开源的修改潜力。

此外，SLS还提供了1000多个现有插件的列表。这些插件不但可以极大地改善和简化无服务器的功能开发，还可以按需被编写出新的插件。以下代码段便是一个小型插件的示例：

在开发人员能够使用SLS，来创建有效的无服务器项目时，无服务器栈(Serverless Stack)为他们提供了宝贵的分步说明。同时，作为一套出色的初学者教程，该资源方便了开发人员获取有关无服务器开发的工作流，以及如何使用AWS基本组件的经验。

构建安全的无服务器功能

以下便是我们在开发安全的无服务器应用时，值得遵循的六项优秀实践与规则：

1. 通过将资源定义与函数区分开来，让您的代码库井然有序。您可以利用不同资源作为参数，而不是经过硬编码的字符串。同时，您可以通过共享代码，来尽量减小程序包的大小。

如下两个示例，演示了良好的代码库组织结构。其中，第一个展示了共享库的多项功能：

第二个例子是由无服务器栈提供的：

2.遵循最小特权原则，将身份和访问管理(IAM)中的角色限制为单个功能级别上。

3.使用诸如AWS SSM代理之类的服务，来管理好密钥。

4.单个无服务器功能仅能执行一项任务。如果某个函数的输出需要进一步处理的话，请将该输出保存到数据存储库中，并由该保存动作来触发新的函数。记住：不要使用当前函数去调用另一个函数。

5.尽量少用远程连接。无论多么复杂，函数的大部分都应该在本地处理其输入，然后返回对应的结果。注意：远程连接不但会增加延迟，而且可能导致在调试和扩展时出现问题。

6.尽量少用依赖性。最好将它们放置在前文提到的共享层中，并持续执行安全扫描。

这些便是我想在本文中和您讨论的，各种无服务安全性的策略、工具和实践。