1. 首页 > 头条 > 行业热门

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

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

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

运行时安全

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

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

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

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

静态安全

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. 本地功能性测试。

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

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

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

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

构建安全的无服务器功能

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

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

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

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

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

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

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

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

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

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

本网站的文章部分内容可能来源于网络和网友发布,仅供大家学习与参考,如有侵权,请联系站长进行删除处理,不代表本网站立场,转载者并注明出处:https://www.jmbhsh.com/xingyeremen/33891.html

联系我们

QQ号:***

微信号:***

工作日:9:30-18:30,节假日休息