无服务器架构使组织无需运行内部服务器即可大规模构建和部署软件。微服务等功能即服务(FaaS)模型的广泛应用也证明了无服务器架构的普及。无服务器架构不仅节省了大量成本，并且其可扩展性为组织的业务增长提供了更大的灵活性。
以下将概述组织确保无服务器架构的安全性应该考虑的关键领域。虽然适合组织生态系统的解决方案对其来说是独一无二的，但以下内容将为组织采用无服务器架构提供坚实的基础。
不断变化的攻击面
简而言之，软件环境的攻击面由未经授权的用户可以输入或提取数据的所有点组成。了解和监视这些点是有效提高无服务器安全性的关键。
无服务器系统由数十个、数百个甚至数千个组件组成，这为恶意攻击者和未授权用户提供了新的切入点，他们都在添加集成到生态系统中的每个新工具、服务或平台。每次扩展和修改架构时，其攻击面都会发生变化。
而且，由于无服务器架构的入口点繁多且拓扑复杂，无服务器攻击面是多层和多维的。因此其攻击面具有高度的复杂性和波动性，因此几乎不可能进行人工映射和监视。
无服务器架构的自动映射和监视
自动化监视和发现系统可以使组织更好地防范威胁。但组织的安全人员只能保护自己看到的内容，除非其监视工具可以随着系统的扩展增加其可见性范围，否则无服务器架构的大部分将会受到威胁。
在组织的无服务器架构中，很有可能会采用自动连续部署。这意味着组织攻击面上的薄弱点也在不断地自动生成。如果组织的监控和发现功能无法跟上威胁的发展，那么在新的细分市场中很容易受到攻击。
幸运的是，有一些平台可以实时映射和监视无服务器架构。其中许多功能还具有可以扩展的安全性，并确定未经授权的用户可以恶意操纵数据的位置。其中一些平台是专门为无服务器安全而设计的。
事件数据注入是最常见的无服务器安全风险
无服务器架构的最常见风险来自数据注入。自从第一个无服务器系统上线运营以来，注入漏洞已成为无服务器安全讨论的主要话题。
无服务器架构的每个组件和功能都需要来自大量来源的输入。这些可能是云存储事件、来自API网关的命令、消息队列事件、数据库更改、来自物联网遥测的信号，甚至是电子邮件。这一列表实际上是无限的，并且只受架构的规模和内容的限制。
可以说，规模越大，从中提取数据的资源就越丰富。这些不同的源类型均带有唯一的消息格式和编码方案。其中任何一个都可能包含不受信任或攻击者控制的输入数据。预测和消除这些恶意注入对于组织来说可能是一个艰巨的挑战。
投资于功能监视和日志记录以实现强大的无服务器安全性
在这种情况下的“投资”不一定指的是金融投资，投入的时间和精力更为重要，尽管如果发现堆栈不足，则可能会带来额外的成本。重大安全漏洞造成的成本影响远远超过组织在安全方面的成本支出。
许多云计算供应商提供了日志记录功能的基本形式。常见示例包括AWS CloudWatch或Azure Functions。尽管这些功能为组织的环境启用了基本的日志记录，但是它们的成本可能很高，并且一旦组织的无服务器架构扩展到一定规模或达到一定程度的复杂性时，它们可能无法满足组织的需求。
开箱即用的解决方案并不总是适合组织的需求。尽管它们具有基本功能，但可能缺乏在应用程序层进行全面安全事件审核的功能。组织的无服务器架构的规模和形态将根据组织的独特设计而定，有许多专家构建的平台和工具可用来弥补这些监视和日志记录的不足。
创建独特的逻辑并利用中间云存储服务
如上所述，在功能监视和日志记录投入一些时间和精力是值得的。在无服务器环境中使用功能日志记录要克服的主要障碍是，监视和日志记录存在于组织的数据中心范围之外。
通过让组织的工程师、无服务器开发人员和DevOps团队创建其架构所独有的日志记录逻辑，可以对此进行协调。组织将需要一种逻辑从各种云功能和服务中收集日志，并将其推送到远程安全信息和事件管理(SIEM)系统中。
一些在无服务器环境中特别重要的日志类型包括有关身份验证和授权、严重错误和故障、更改、恶意软件活动、网络活动和资源访问的报告。
无论组织使用哪种架构模型，这些报告都是至关重要的报告。但是，在复杂且不断变化的无服务器环境中，其监视和可见性可能很棘手。因此，需要创建可在单个存储库中隔离、提取和整理这些报告的逻辑，以便可以实时监视整个架构至关重要。
通过日志逻辑收集的日志需要存储在某个地方。这是中间云存储服务发挥重要作用的地方。通过使用一个外部系统来整理整个无服务器生态系统中的日志记录信息，组织将能够实时监视安全事件。
功能特权过多和身份验证失败
如果组织没有对功能和用户进行尽职调查和适当的审查，则无服务器架构中可能存在一些致命的弱点。
首先是可靠的身份验证。无服务器通常意味着面向微服务的架构设计。微服务架构可以包含数百个单独的功能。除了充当其他进程的代理外，许多无服务器功能还会使公共Web API暴露在外。这就是采用可靠的身份验证方案至关重要的原因。
随着无服务器生态系统的发展，采用的身份验证方案失败或效率低下，可能会为未经授权的用户创建无限数量的访问点。这本身是危险的，如果组织的功能特权过多，那将是灾难性的事件。
在具有数十甚至数百个组件的无服务器环境中，管理功能权限和角色感觉就像一场艰苦的战斗。工程师犯下的常见的安全错误之一是试图偷工减料，并采用包罗万象的权限模型。尽管这样可以节省时间，但它使无服务器环境中的所有内容都极易受到攻击。
如果这两个缺陷都是由于未遵循尽职调查而存在的，那么恶意攻击者或外部用户很容易访问到组织的系统。身份验证失败之后，就会出现漏洞，特权功能权限一旦进入就可能窍取重要数据。组织在设计、构建和部署过程中，如果深思熟虑，可以避免这两种情况。
无服务器安全性更多的注意事项
当然，还有其他考虑。例如，需要记住要停用过时的功能和云计算资源。这不仅有助于简化成本，而且原有和未使用的组件会在无服务器架构的攻击面增加不必要的维度。自动定期清理环境并删除未使用的角色、标识和依赖项。
避免重用执行环境也很重要。对于云计算提供商来说，在调用之间执行环境是很有诱惑力的。这使得他们的云平台在处理新的调用时更加高效。然而，当执行环境继续运行时，可能会留下有价值的敏感数据，因此组织需要确保提高效率不会以牺牲安全性为代价。
组织的无服务器环境是唯一的，因此实现无服务器安全性的方法也应该如此
这始终是最重要的考虑因素。无论是部署配置、权限模型还是日志记录工具，开箱即用的解决方案都将为组织提供更多的保护。组织构建的无服务器环境需要一种独特的安全方法。
