Serverless 架构是否存在安全隐患?

1）多样化的函数调用源传统应用的输入来源相对比较单一，主要是用户的直接输入，安全编码实践可以很好地抵御这种安全威胁，但是在 Serverless 架构下能够触发函数执行的事件源头远不限于用户输入，主要有如下多种方式：云存储事件、NoSQL 数据库事件、SQL 数据、库事件、流处理事件、代码提交事件、HTTP API 调用、消息队列事件... 2）函数认证由于 Serverless 是面向微服务的系统设计，因此系统中会出现近百个职责不同的互相独立函数（通常称之为纳米服务）。部分函数会通过 Web API 暴露服务，服务在被不用的调用源调用时，可能有不同的认证模式，这使得函数的认证模式差异特别大，如果管理不善，很容易由于服务认证漏洞出现问题。相对于传统应用的一个应用一种单一认证的模式，Serverless 架构下的认证显然更具有挑战性。 3）Serverless 应用部署配置云服务，尤其是 Serverless 架构下的云服务提供了很多用户定制化的配置，通过这些配置可以满足客户高度个性化的需求，但是不正确的配置可能导致一些潜在的安全威胁。例如，使用云存储的服务可能会暴露一些敏感信息给没有获得授权的用户，因此建议尽量将函数设计成无状态服务。 4）权限和角色。传统应用的权限通常是针对访问者的角色，而不是针对软件组件，为了方便管理赋予较高的权限的情况比较普遍。但是在 Serverless 模式下每一个函数都可能有独立的角色和权限，考虑到 Serverless 函数的数量庞大，Serverless 函数必须只拥有执行业务逻辑所必须的最小权限集合，权限管控的难度一下子提高很多。 5）监控和日志传统应用有一系列成熟的日志管理和分析工具，但是 Serverless 应用的日志管理和分析工具十分稀缺，针对微服务内部函数之间调用链的监控工具也并不多，因此很容易出现不完善的监控和日志问题。需要注意如下：日志可访问权限设置是否合理、日志管理和分析工具是否满足函数日志处理要求、每一个函数的执行日志、监控是否完善、监控和日志相关的告警机制是否完善。 6）第三方依赖安全通常，Serverless 函数应该是执行单个离散操作的一小段代码任务。功能通常取决于第三方软件包、开放源代码库甚至是通过API调用执行任务来使用第三方远程Web服务。但是，当依赖的第三方依赖存在缺陷时，即使最安全的Serverless 函数也可能变得脆弱。传统应用中第三方依赖数量相对 Serverless 架构下较少，依赖关系相对也比较简单，因此问题没有函数那么严重。 7）应用机密信息存储安全传统模式下每个应用通常只需要 1 个文件存储机密信息，但是在 Serverless 模式下单个文件来存储机密信息就不可能，如果每个函数用一个文件则肯定存在安全隐患，因此需要使用环境变量的形式来存储。 8）拒绝服务攻击和预算透支。传统应用的访问入口比较单一，非常方便对入口流量进行管控，但是新模式下应用的流量入口很多，因此面临的拒绝服务攻击形势更严峻。 在过去的十年中，拒绝服务（DoS）攻击的频率和数量急剧增加。此类攻击已成为几乎每家拥有在线业务的公司所面临的主要风险之一。 9）函数执行流程控制。传统应用通常只存在进程内的执行过程，因此几乎不需要关注内部执行流程控制。函数之间业务逻辑操纵可以帮助攻击者颠覆应用程序逻辑。使用这种技术，攻击者可能绕过访问控制，提升用户权限或挂载DoS攻击。而且，设计可能会假设函数仅在特定情况下并且仅由授权的调用者调用。 10）异常处理和错误消息传统应用开发通常不需要逐行调试，但是在函数开发过程中却是常态。当前 Serverless 函数的调试并没有传统应用开发那么方便，因此，开发者会打出大量的调试日志信息，如果在发布上线时忘记清理，那么就有可能暴露一些不必要的信息。 11）过时的遗留代码、资源和事件触发器。传统应用代码管控比较集中，便于发现遗留的无用代码、不再需要访问的资源等，但是函数代码管理分散、访问资源的入口很多。与其他类型的现代软件应用程序类似，随着时间的推移，一些无服务器功能及其相关云资源可能已过时应停用，这种情况在 Serverless 模式下则可能造成不安全的威胁。应用程序组件应定期清除进行以减少不必要的成本并减少可避免的攻击面。 12）交叉执行数据持久性传统应用由于生命周期远远长于函数，因此平台可以通过轮询等机制定时清理资源避免错误复用，但是在函数执行情况下这种时间间隙几乎不存在。无服务器平台为应用程序开发人员提供本地磁盘存储，环境变量和RAM 内存，以便以类似于任何现代软件堆栈的方式执行计算任务。为了使无服务器平台高效处理新调用并避免冷启动，云提供者可能会在随后的函数调用中重用执行环境（例如容器）。

当然存在安全隐患，但是安全的问题都是相对的，任何一款产品都会存在安全隐患，Serverless同样存在，如果自己的应用本身就存在一些问题的话，部署Serverless上面也是会存在的。比如说sql的注入问题、xss问题等等

对于Serverless应用而言,SQL注入、命令注入、XSS等传统漏洞风险在Serverless应用中同样存在。 - 服务商风险：云服务商对serverless的防护还很薄弱， - Key的泄露：云原生应用对资源和设施的管理和使用基本都是基于Key，因此针对云原生的攻击首先的变化就是对key的攻击 - 云原生配置风险： Serverless使用的资产是品类多、动态的、用完即走的， 各种安全配置分散在各个产品中，缺乏统一管理和运维平台，难以做到管理和检查，从而导致配置安全和隐患，配置安全这个是容易被忽略的。多产品联动已经足够困难，更棘手的是，不少项目会跨厂商联动，比如组合了阿里云、腾讯云、高德开放平台、百度云等的产品，造成难度系数陡增。 - API风险：serverless是细粒度的服务，他的安全重点也就是API安全，如API异常调用、越权操作、违规调用。