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

Question

对在2018年接触无服务器非常感兴趣。已经在几个分散的应用程序项目中实现了拉姆达的使用。然而，我还不明白如何才能防止第三方应用程序(甚至是竞争对手)滥用您的端点，从而提高您的使用成本。

我不是在说DDoS，也不是说所有的流量都来自一个IP，它可以发生在任何网络上，但特别是让第三方应用的客户直接打剩下的电话，这会导致你的使用成本上升，因为他们的应用是在你的上“打开”端点。

例如，：

我希望在AWS上创建一个端点，为我提供ETH/美元现价，如何防止另一个(或每个) dapp开发人员使用我的 Lambda端点，并给我的帐户带来过高的计费费用？

Answer 1

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

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

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

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

有了这些功能之一，您的Lambda功能只能由授权用户调用。如果没有这些措施之一，就没有办法防止你所关心的那种虐待行为。

Answer 2

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

考虑使用以下方法防止第三方应用程序对Lambda端点的执行“滥用”

要控制的一个因素是并发性，即每个帐户和每个函数支持的并发请求数。你是每个请求收费加每个请求的总内存分配，所以这是你想要控制的单位。为了防止逃跑的成本，你可以防止私奔--不管是由坏的参与者，还是由合法的第三方造成的软件错误。

来自管理并发

AWS的规模单位是一个并发执行(有关更多细节，请参见了解缩放行为)。然而，在所有场景中，无限期缩放并不是可取的。例如，出于成本原因，您可能希望控制并发，或者控制处理一批事件所需的时间，或者简单地将其与下游资源匹配。为了帮助这一点，Lambda在帐户级别和功能级别都提供了并发执行限制控制。

除了每个帐户和每个Lambda调用限制之外，您还可以通过将Lambda调用包装在AWS网关中，并创建和使用API 网关使用计划来控制Lambda的暴露。

在创建、测试和部署API之后，可以使用API网关使用计划将其扩展为客户的产品产品。您可以提供使用计划，允许指定的客户在协议下访问选定的API，根据请求费率和配额，可以满足他们的业务需求和预算限制。 什么是使用计划？使用计划规定谁可以访问一个或多个已部署的API阶段--以及h，以及调用方访问API的速度。使用API密钥标识API客户端，并使用可配置的节流和配额限制度量对API阶段的访问，这些限制是对单个客户端API密钥实施的。 throttling规定了对每个API键应用的请求速率限制。配额是在指定的时间间隔内使用给定的API键提交的最大请求数。可以根据使用计划配置配置各个API方法以要求API密钥授权。API阶段由API标识符和阶段名称标识。

使用API网关限制为每个客户创建网关使用计划，您可以控制API和Lambda访问，以防止无法控制的帐户计费。

Answer 3

@马特的回答是正确的，但不完整。

添加一个安全层是实现安全的必要步骤，但并不能保护您免受经过身份验证的调用者的攻击，正如@Rodrigo的答案所述。

实际上，我在我的一个lambda上遇到并解决了这个问题，这要感谢本文：https://itnext.io/the-everything-guide-to-lambda-throttling-reserved-concurrency-and-execution-limits-d64f144129e5。

基本上，我在我的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

当任何数据更改时，由第三方服务触发的web钩子调用refresh-cache lambda。例如，当导入dataset时，它将触发多达100个对refresh-cache的调用。这种行为完全是垃圾邮件给我的API，它反过来运行对其他服务的请求，以执行缓存失效。

添加这一行大大改善了情况，因为只有一个lambda实例一次运行(没有并发运行)，调用的次数除以10，而不是对refresh-cache的50个调用，它只触发3-4次调用，所有这些调用都正常工作(200次，而不是500次由于超时问题)。

总的来说，挺不错的。还不完美的工作流程，但向前迈进了一步。

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

在之前将reservedConcurrency限制应用于lambda：

​

您可以看到，大多数调用在超时(3000ms)下都会失败，只有少数几次成功，因为lambda还没有重载。

在之后将reservedConcurrency限制应用于lambda：

​

你可以看到所有的调用都成功了，而且速度更快。没有暂停。既省钱又省时。

使用reservedConcurrency不是解决这个问题的唯一方法，还有很多其他的方法，@Rodrigo在他的回答中说过。但这是一个可行的方法，它可能适合你的工作流程。它适用于Lambda级别，而不是applied (如果我正确理解文档)。