Serverless或许没有你想象中的安全

科技云报道原创。

随着云计算技术的进一步成熟，Serverless已成为引领云计算下一个十年的技术热点。

Serverless能够帮助开发者无需关注服务器、按照实际使用付费且可以享受服务自动弹性伸缩，将更多的精力放到业务逻辑本身。据Gartner预测，2025年将有50%以上的全球企业采用Serverless架构。尽管采用Serverless已成为大势所趋，但Serverless框架是否真的安全？有人认为，使用Serverless云服务相当于把基础架构托管给了云服务商，一切云服务安全都由云服务商来负责，采用Serverless甚至会比现有的基础云服务更安全。

事实真的如此吗？

Serverless面临的安全风险

Serverless面临的主要挑战是云服务商只负责云的安全性，而不是云中的安全性。这意味着Serverless应用程序不仅仍然面临传统应用程序面临的风险和漏洞，例如：跨站点脚本、访问控制中断、数据库注入、敏感数据泄露、不安全的反序列化等，而且还面临着Serverless架构特有的安全挑战。

风险一：增加攻击面

Serverless函数使用来自各种事件源的输入数据，包括 HTTP API、云存储、IoT设备连接和队列。这大大增加了攻击面，因为其中一些部分可能包含不受信任的消息格式，标准应用程序层保护可能无法正确检查这些格式。如果暴露了用于获取输入数据（例如协议、向量和函数）的连接链接，则可以将其用作攻击点。

风险二：安全配置错误

由于云服务提供商提供的设置和功能配置不安全，Serverless应用程序容易受到网络攻击。

例如，DoS攻击经常发生在Serverless应用程序中，这是由于函数和主机之间的超时设置配置错误，其中低并发限制用作对应用程序的攻击点。攻击者还可以通过插入函数调用来利用函数链接，其中他们延长函数事件的执行时间比预期更长，从而允许DoW攻击并增加Serverless函数的成本。

此外，使用公共存储库（如GitHub和S3存储桶）中未受保护的功能也会由于敏感数据泄露而造成DoW攻击。这是因为攻击者利用公开的函数，其中包含代码中硬编码的未受保护的机密和密钥。

风险三：身份验证中断

Serverless应用程序是无状态的，在其体系结构中使用微服务会使独立函数的移动部分面临身份验证失败的风险。

例如，如果在具有数百个Serverless函数的应用程序中仅对一个函数的身份验证处理不当，则会影响应用程序的其余部分。攻击者可以专注于一个功能，通过不同的方法访问系统，如自动暴力破解等。

风险四：特权过大功能的威胁

Serverless生态系统依赖于许多独立的函数，每个函数都有自己的角色和权限。职能之间的大量交互有时可能导致职能在其权利上享有过多的特权。例如，不断访问数据库并更新其他函数的功能可能是一个巨大的风险，因为它对参与者可见。

风险五：使用已知漏洞的组件

Serverless应用程序通常使用JavaScript（或TypeScript）或Python语言。Python或 JavaScript的开发人员通常使用大量第三方组件来完成不同的任务。这些组件可能存在漏洞，使用它们会使Serverless应用程序容易受到攻击。

保护Serverless安全性的最佳实践

当然，面对Serverless面临的安全风险，企业可以采用多种Serverless应用程序安全最佳实践，其中包括：

不要仅仅依赖WAF保护

拥有WAF很重要，但它不应该是保护Serverless应用程序的唯一防线。如果仅依靠WAF保护，安全性可能会有很大的漏洞。

因为WAF只能检查HTTP流量，这意味着WAF只会保护API网关触发的函数，它不会针对其他事件触发器类型提供保护。如果函数从不同的事件源触发，比如：通知（物联网、短信和电子邮件；代码修改；数据库更改；流数据处理；云存储事件等，则WAF无济于事。

使用自定义函数权限

事实上，Serverless应用程序中超过90%的权限已被过度许可。尽管在考虑Serverless应用功能级别时，设置权限可能会令人望而生畏，但不应使用一刀切的方法。一个常见的Serverless安全错误是设置更宽松且功能更大的策略，未能最小化单个权限和功能角色会使攻击面大于应有的范围。

DevSecOps团队必须与编写函数的开发人员坐下来，查看每个函数的用途并创建适当的函数级别权限。确定每个函数的用途后，可以为每个函数创建合适的权限策略和唯一角色。庆幸的是，整个过程可以使用各种自动化工具来助力。

进行代码审核

Black Duck Software调查了企业中常用的1000个应用程序，发现其中96%都使用了开源软件。研究人员还发现，60%的软件都包含安全漏洞，其中一些漏洞已经存在了四年以上。这使得代码所有权和真实性成为一项严重的安全风险。

随着开源软件的盛行，单个Serverless函数可能包含来自不同外部源的数千行代码。因此，想要提高Serverless的安全性，执行代码安全审计至关重要。

保持对CI/CD的控制

代码漏洞可以通过严格的CI/CD来缓解，即使它听起来很难。

攻击者可能会通过各种方式溜进来，甚至会在不被发现的情况下潜入企业内部造成严重破坏。若要确保不会发生这种情况，必须创建一个策略和策略，以便在生成期间执行代码分析，然后再上线，并确保每个函数都已通过CI/CD。

通过AI密切关注所有攻击指标

每天只有几百个函数都可以在日志中生成数十亿个事件，因此很难确定哪些事件是重要的。即使熟悉Serverless应用特有的攻击模式，也不可能扫描所有攻击模式，这就是为什么必须使用AI工具来增加Serverless的安全性、效率和可见性。

使函数超时

所有函数都应具有严格的运行时配置文件，但通常不直观地创建适当的Serverless函数超时。函数的最长持续时间可以特定于该函数。DevSecOps 团队需要考虑配置的超时与实际超时。大多数开发人员将超时设置为允许的最大值，因为未使用的时间不会产生额外的费用。

但是，这种方法可能会产生巨大的安全风险，因为如果攻击者成功注入代码，他们就有更多的时间来造成损害。较短的超时意味着它们可以更频繁地攻击，这被称为“土拨鼠日”攻击，但它也使攻击更加明显。因此，作为Serverless安全性最佳做法，是必须使函数超时。

减少对第三方的依赖

开发人员通常从第三方派生组件，最好检查其来源是否可靠以及它们所引用的链接是否安全，采取此预防措施可避免意外漏洞，务必检查开源平台中使用的组件的最新版本。

大多数开发人员更喜欢在现代应用中使用开源组件，这使得检测任何问题或跟踪代码中的漏洞变得更加困难。最好使用最新版本并及时获得更新，并提前做好准备。

为此，可以定期检查开发论坛上的更新，使用自动依赖项工具，并避免使用依赖项过多的第三方软件。

处理凭证

建议将敏感数据存储在安全的位置，并使其可访问性极其有限，必须特别注意API密钥等凭据。同时，应将环境变量设置为运行时间评估设置，然后在配置文件中部署时间。

最好的方法是定期轮换密钥，即使被黑客入侵，可以确保切断对黑客的访问。每个组件、开发人员和项目都必须具有单独的密钥，并加密敏感数据和环境变量。

保护软件开发生命周期

软件开发生命周期定义了构建应用程序、在整个生命周期中对其进行管理以及简化开发过程。但是，不安全的应用程序可能会带来巨大的业务风险。易受攻击的应用程序可能会导致个人数据丢失，并对企业业务声誉造成无法弥补的损害。

在开发阶段集成安全性可确保授权并确保Serverless应用程序的正常工作，它还涉及不断审查弱点条件，并确保应用程序与安全实践集成。

地理考虑

开发人员应记住，在部署应用模块时，某些地理注意事项可能会对Serverless安全性产生负面影响。从不同地理位置部署的代码可能会产生与代码相关的问题。例如，纽约的开发人员将使用US-East-1时区，而来自亚洲的开发人员将在部署设置中使用完全不同的时区。

结语

毫无疑问，新机遇伴随着独特的挑战。Serverless架构引入了一种新的应用程序开发范例，但是企业在处理应用程序基础结构时，也必须承担额外的安全责任。

因此，在采用Serverless时，需要更谨慎和明智地尝试安全应用程序最佳实践。

【关于科技云报道】

专注于原创的企业级内容行家——科技云报道。成立于2015年，是前沿企业级IT领域Top10媒体。获工信部权威认可，可信云、全球云计算大会官方指定传播媒体之一。深入原创报道云计算、大数据、人工智能、区块链等领域。

生成海报

免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。