Question

非常有兴趣在2018年与 Serverless 进行实践。已经在多个分散的应用项目中实施 AWS Lambda 的使用。但是，我还不了解如何防止滥用您的终端从第三方应用（甚至可能是竞争对手），来提高您的使用成本。

我不是在谈论DDoS，或者所有流量来自单个IP，这可能发生在任何网络上，但特别是让第三方应用的客户直接进行REST呼叫，这会导致您的使用成本上升，因为他们的应用程序支持你的“开放”端点。

例如：

我希望在AWS Lambda上创建一个端点，为我提供 current price of Ethereum ETH/USD. 什么会阻止其他（或每个） dapp开发人员使用我的 lambda端点并导致我帐户收取过多的结算费用？

Answer 1

当您部署对全世界开放的端点时，您将打开它以供使用，但也会被滥用。

AWS提供服务以避免常见的滥用方法，例如AWS Shield，它可以减轻DDoS等，但是，他们不知道您的Lambda函数是什么或不是滥用，正如您所要求的那样。

如果您的Lambda函数是私有的，那么您应该使用其中一个API网关安全机制来防止滥用：

IAM安全
API密钥安全性
自定义安全授权

有了其中一个，您的Lambda函数只能由授权用户调用。如果没有其中任何一个，就无法阻止您所关注的滥用类型。

Answer 2

无限制地访问您的公共Lambda函数 - 由不良参与者，或由合法第三方开发的不良软件，可能导致不必要的可计费公司资源使用，并可能降低应用程序性能。作为系统安全设计的一部分，您必须考虑限制和限制对Lambda客户端的访问的方法，以防止失控的函数调用和不受控制的成本。

考虑使用以下方法来防止执行＆＃34;滥用＆＃34;第三方应用程序的Lambda端点：

您要控制的一个因素是并发或每个帐户和每个功能支持的并发请求数。你是billed per request plus total memory allocation per request，所以这是你想要控制的单位。为了防止逃避成本，你可以防止逃跑的执行 - 由不良演员或合法的第三方造成的软件错误。

来自Managing Concurrency

AWS Lambda的比例单位是并发执行（请参阅了解扩展行为以获取更多详细信息）。但是，缩放无限期地在所有情况下都是不可取的。例如，你可以想要出于成本原因控制并发性，或者规范如何它需要您处理一批事件，或简单地匹配它使用下游资源。为了帮助解决这个问题，Lambda提供了一个帐户级别和帐户级别的并发执行限制控制功能水平。

除了每个帐户和每个Lambda调用限制，您还可以通过在AWS API网关中包装Lambda调用以及创建和使用API Gateway Usage Plans来控制Lambda暴露：

创建，测试和部署API后，您可以使用API网关   使用计划将其扩展为您的客户的产品。   您可以提供使用计划以允许指定的客户访问   选择的API符合商定的请求率和配额   他们的业务要求和预算限制。

什么是使用计划？使用计划规定谁可以访问一个或   更多部署的API阶段 - 以及h 很多以及调用者的速度有多快   可以访问API。该计划使用API密钥来标识API   客户端和计量表可通过可配置访问API阶段   在单个客户端API上强制执行的限制和配额限制   密钥。

t 限制规定了适用的请求率限制   每个API密钥。配额是带有的最大请求数   给定在指定时间间隔内提交的API密钥。您可以   配置单个API方法以要求API密钥授权   基于使用计划配置。 API阶段由a标识   API标识符和阶段名称。

使用API Gateway Limits为每位客户创建Gateway Usage Plans，您可以控制API和Lambda访问，以防止不受控制的帐户结算。

Answer 3

@Matt答案是正确的，但不完整。

添加安全层是实现安全性的必要步骤，但不能保护您免受身份验证的呼叫者的侵扰，如@Rodrigo的回答所述。

由于这篇文章https://itnext.io/the-everything-guide-to-lambda-throttling-reserved-concurrency-and-execution-limits-d64f144129e5

，我实际上在我的一个lambda上遇到并解决了该问题

基本上，我在serverless.yml文件中的函数中添加了一行，并由上述经过认证的第三方调用：

reservedConcurrency: 1

然后是整个功能：

refresh-cache:
    handler: src/functions/refresh-cache.refreshCache
    # XXX Ensures the lambda always has one slot available, and never use more than one lambda instance at once.
    #  Avoids GraphCMS webhooks to abuse our lambda (GCMS will trigger the webhook once per create/update/delete operation)
    #  This makes sure only one instance of that lambda can run at once, to avoid refreshing the cache with parallel runs
    #  Avoid spawning tons of API calls (most of them would timeout anyway, around 80%)
    #  See https://itnext.io/the-everything-guide-to-lambda-throttling-reserved-concurrency-and-execution-limits-d64f144129e5
    reservedConcurrency: 1
    events:
      - http:
          method: POST
          path: /refresh-cache
          cors: true

refresh-cache lambda由任何数据更改时由第三方服务触发的Webhook调用。导入数据集时，例如，它将触发多达100个对refresh-cache的调用。这种行为完全是在向我的API发出垃圾邮件，而我的API依次正在运行对其他服务的请求，以执行缓存无效化。

添加这一行可以大大改善这种情况，因为一次仅运行一个lambda实例（没有并发运行），因此调用次数除以〜10，而不是对refresh-cache的调用次数为50 ，它仅触发3-4次，所有这些呼叫均有效（由于超时问题，它的呼叫次数为200，而不是500）。

总体来说还不错。对于我的工作流程来说还不是很完美，但是向前迈了一步。

无关，但是我使用了https://epsagon.com/，它极大地帮助了我了解AWS Lambda上发生了什么。这是我得到的：

之前对lambda应用reservedConcurrency限制：

您可以看到大多数调用都因超时（30000ms）而失败，只有少数几个调用成功，因为lambda尚未过载。

之后对lambda应用reservedConcurrency限制：

您可以看到所有呼叫都成功了，而且速度更快。没有超时。既省钱又省时间。

使用reservedConcurrency不是解决此问题的唯一方法，还有许多其他方法，如@Rodrigo在其回答中所述。但这是一个可行的方法，可能适合您的工作流程。它适用于Lambda级别，而不适用于API Gateway（如果我正确理解了文档）。

如何防止第三方应用程序滥用AWS Lambda

3 个答案: