如何实现无服务器架构的安全

无服务器架构使组织无需运行内部服务器即可大规模构建和部署软件。微服务等功能即服务(FaaS)模型的广泛应用也证明了无服务器架构的普及。无服务器架构不仅节省了大量成本，并且其可扩展性为组织的业务增长提供了更大的灵活性。

以下将概述组织确保无服务器架构的安全性应该考虑的关键领域。虽然适合组织生态系统的解决方案对其来说是独一无二的，但以下内容将为组织采用无服务器架构提供坚实的基础。

不断变化的攻击面

简而言之，软件环境的攻击面由未经授权的用户可以输入或提取数据的所有点组成。了解和监视这些点是有效提高无服务器安全性的关键。

无服务器系统由数十个、数百个甚至数千个组件组成，这为恶意攻击者和未授权用户提供了新的切入点，他们都在添加集成到生态系统中的每个新工具、服务或平台。每次扩展和修改架构时，其攻击面都会发生变化。

而且，由于无服务器架构的入口点繁多且拓扑复杂，无服务器攻击面是多层和多维的。因此其攻击面具有高度的复杂性和波动性，因此几乎不可能进行人工映射和监视。

无服务器架构的自动映射和监视

自动化监视和发现系统可以使组织更好地防范威胁。但组织的安全人员只能保护自己看到的内容，除非其监视工具可以随着系统的扩展增加其可见性范围，否则无服务器架构的大部分将会受到威胁。

在组织的无服务器架构中，很有可能会采用自动连续部署。这意味着组织攻击面上的薄弱点也在不断地自动生成。如果组织的监控和发现功能无法跟上威胁的发展，那么在新的细分市场中很容易受到攻击。

幸运的是，有一些平台可以实时映射和监视无服务器架构。其中许多功能还具有可以扩展的安全性，并确定未经授权的用户可以恶意操纵数据的位置。其中一些平台是专门为无服务器安全而设计的。

事件数据注入是最常见的无服务器安全风险

无服务器架构的最常见风险来自数据注入。自从第一个无服务器系统上线运营以来，注入漏洞已成为无服务器安全讨论的主要话题。

无服务器架构的每个组件和功能都需要来自大量来源的输入。这些可能是云存储事件、来自API网关的命令、消息队列事件、数据库更改、来自物联网遥测的信号，甚至是电子邮件。这一列表实际上是无限的，并且只受架构的规模和内容的限制。

可以说，规模越大，从中提取数据的资源就越丰富。这些不同的源类型均带有唯一的消息格式和编码方案。其中任何一个都可能包含不受信任或攻击者控制的输入数据。预测和消除这些恶意注入对于组织来说可能是一个艰巨的挑战。

投资于功能监视和日志记录以实现强大的无服务器安全性

在这种情况下的“投资”不一定指的是金融投资，投入的时间和精力更为重要，尽管如果发现堆栈不足，则可能会带来额外的成本。重大安全漏洞造成的成本影响远远超过组织在安全方面的成本支出。

许多云计算供应商提供了日志记录功能的基本形式。常见示例包括AWS CloudWatch或Azure Functions。尽管这些功能为组织的环境启用了基本的日志记录，但是它们的成本可能很高，并且一旦组织的无服务器架构扩展到一定规模或达到一定程度的复杂性时，它们可能无法满足组织的需求。

开箱即用的解决方案并不总是适合组织的需求。尽管它们具有基本功能，但可能缺乏在应用程序层进行全面安全事件审核的功能。组织的无服务器架构的规模和形态将根据组织的独特设计而定，有许多专家构建的平台和工具可用来弥补这些监视和日志记录的不足。

创建独特的逻辑并利用中间云存储服务

如上所述，在功能监视和日志记录投入一些时间和精力是值得的。在无服务器环境中使用功能日志记录要克服的主要障碍是，监视和日志记录存在于组织的数据中心范围之外。

通过让组织的工程师、无服务器开发人员和DevOps团队创建其架构所独有的日志记录逻辑，可以对此进行协调。组织将需要一种逻辑从各种云功能和服务中收集日志，并将其推送到远程安全信息和事件管理(SIEM)系统中。

一些在无服务器环境中特别重要的日志类型包括有关身份验证和授权、严重错误和故障、更改、恶意软件活动、网络活动和资源访问的报告。

无论组织使用哪种架构模型，这些报告都是至关重要的报告。但是，在复杂且不断变化的无服务器环境中，其监视和可见性可能很棘手。因此，需要创建可在单个存储库中隔离、提取和整理这些报告的逻辑，以便可以实时监视整个架构至关重要。

通过日志逻辑收集的日志需要存储在某个地方。这是中间云存储服务发挥重要作用的地方。通过使用一个外部系统来整理整个无服务器生态系统中的日志记录信息，组织将能够实时监视安全事件。

（编辑：开发网_开封站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!