确保无服务器架构安全的“法门”

无服务器（Serverless）架构可以使企业无需内部服务器即可大规模构建和部署软件。无服务器架构可以理解为应用程序使用第三方Function和服务，而无需管理服务器。微服务等FaaS模型的盛行证明了无服务器架构的流行。对于企业来说，节省成本的影响是巨大的，该架构的大规模可伸缩性为企业业务增长和网络架构改造提供了灵活性。

本文将概述确保无服务器架构安全应考虑的关键领域。尽管每个企业拥有最适合自己的网络架构和生态系统解决方案，以下内容能够为企业提供一些在安全方面的建议。

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

无服务器系统由数十个、数百个甚至数千个组件组成，这就为恶意和未经授权的用户提供了新的攻击点。因为每一个新工具、服务或平台都会集成到IT系统中，而在每次扩展和改造IT架构时，这些点都会发生变化。

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

自动化监视和发现可以使企业IT系统防护领先于威胁。因为企业只能保护自己所能够看到的。除非您的监视工具可以随着系统的扩展而增加其可见性范围，否则一成不变的可见性将很快失效。

在企业的无服务器体系架构中，可能会采用自动连续部署方式。这意味着企业IT系统攻击面上的新弱点也在不断地自动形成。如果监视和发现工具无法跟上这些变化，新的分段将很容易受到攻击。

不过，可以利用平台来实时映射和监视无服务器架构。其中许多平台功能还具有扩展的安全功能，可以定位出哪些未经授权用户在恶意操纵数据。

无服务器架构中最常见风险来自数据注入攻击。可以说，自第一个无服务器系统上线以来，注入漏洞已成为无服务器安全风险的普遍特征。

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

可以说，规模越大，函数从中提取数据的资源就越丰富。

因此这里面就存在着一些问题。这些不同的源类型均带有唯一的消息格式和编码方案，这些中的任何一个都可以包含不受信任或被攻击者控制的输入。如何预测和消除这些恶意注入则是一个艰巨的挑战。

 企业需要投资于功能监视和日志记录，当然这里的“投资”不一定指金融投资，时间和精力更为重要，尽管堆栈不足可能会带来额外的成本，但不要被这些所拖累。重大安全漏洞所造成的成本影响远远超过了保护自身安全所投入的费用。

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

开箱即用的解决方案并不总是适合企业的需求。尽管它们具有一些基本的功能，但它们可能缺乏在应用层进行全面安全事件审核的功能。企业的无服务器体系架构的规模和形式是随自身独特需求而定的，企业必须注意到这一点。当下有许多企业定制化的平台和工具可用来弥补这些监视和日志记录的不足。

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

可以通过企业的工程师、无服务器开发人员和DevOps团队来创建企业IT架构所独有的日志记录逻辑，该逻辑可以从各种云功能和服务中收集日志，并将其推送到远程SIEM（安全信息和事件管理）系统中。

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

无论您使用哪种体系架构模型，这些中的许多都是重要报告。但是在复杂多变的无服务器环境中，监视和可见性会变得很棘手。创建可在单个存储库中隔离、提取和整理这些报告的逻辑，以便可以实时监视整个体系架构是至关重要的。

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

企业可以跟踪和监视跨架构的拓扑中的所有无服务器功能和包含攻击者和恶意/未经授权的输入，而不管其层级如何。

如果没有对功能和用户进行尽职调查和适当的审查，那么无服务器架构中可能存在致命的缺陷。

首先是健壮的身份认证。无服务器通常意味着面向微服务的体系架构设计。微服务架构可以包含数百个单独的功能，除了充当其他进程的代理外，许多无服务器功能还会使公共Web API暴露在外。这就是为什么应用可靠的身份认证方案是如此的重要。

随着无服务器生态系统的发展，身份认证方案可能会产生效率低下的结果，可能会为未经授权的用户创建无限数量的访问点。这样是非常危险的，但是如果您的功能也有特权过多的问题，那将是灾难性的。

在具有数十甚至数百个组件的无服务器环境中，管理功能权限和角色感觉就像是一场艰苦的战斗。工程师出现最常见的安全错误之一是为图省事并应用catch-all权限模型。尽管这样可以节省时间，但它将导致无服务器环境中的所有内容都面临被攻击的风险。

如果因未遵守尽职调查而出现以上两种缺陷，那么您的系统很容易被恶意外部用户攻击。失效的身份认证证会为攻击者敞开大门，而过度的功能权限会将敏感信息暴露于外。通过在设计、构建和部署过程中进行全面而周到的考虑，可以避免这两种情况的出现。

当然，还有其他方面的考虑。例如，切记要停用过时的功能和云资源。这样不仅有助于简化成本，而且也会减少旧有和未使用的组件所带来的攻击面。定期自动整理IT环境，并删除未使用的角色、身份和依赖项。

避免重用执行环境。对于云服务商来说，在两次调用之间保留执行环境可能非常具有吸引力，它可以使其平台在处理新的调用时效率更高。但是当执行环境被保留下来时，有价值的敏感数据也可能会被遗漏。因此在实现效率的同时绝不应牺牲安全性。

企业的无服务器环境是唯一的，因此实现无服务器安全性的方法也应是针对性的。这始终是最重要的考虑因素。无论是部署配置、权限模型还是日志记录工具，开箱即用的解决方案也只能为您提供有限的保护。记住，企业独特的IT环境需要的是独特的安全方法。