当前位置:主页 > 查看内容

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

发布时间:2021-04-07 00:00| 位朋友查看

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

【51CTO.com快译】不可否认,我们在得益于无服务器带来的效率、可扩展性、以及成本优势等功能与便利的同时,必须保证无服务器应用的安全性。在本文中,我将向您介绍如何使用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.尽量少用依赖性。最好将它们放置在前文提到的共享层中,并持续执行安全扫描。

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

原文标题:Examining Serverless Security Strategies, Tools, and (Current) Best Practices,作者: Selvam Thangaraj

【51CTO译稿,合作站点转载请注明原文译者和出处为51CTO.com】


本文转载自网络,原文链接:https://www.51cto.com/
本站部分内容转载于网络,版权归原作者所有,转载之目的在于传播更多优秀技术内容,如有侵权请联系QQ/微信:153890879删除,谢谢!

推荐图文

  • 周排行
  • 月排行
  • 总排行

随机推荐