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

Question

非常有兴趣在2018年动手使用Serverless。已经计划在多个分散式应用程序项目中实现对AWS Lambda的使用。但是，我还不了解如何防止第三方应用程序（可能甚至是竞争对手）滥用端点而增加使用成本。

我不是说DDoS，也不是说所有流量都来自单个IP，而这可能发生在任何网络上，但是特别是让第三方应用程序的客户直接拨打REST呼叫，这会导致使用成本增加，因为他们的应用程序会在您的“开放”端点上进行备份。

例如：

我希望在AWS Lambda上创建一个终端节点，以向我提供以太坊ETH / USD的当前价格。是什么会阻止另一个（或每个） dapp开发人员使用我的 lambda端点并导致我的帐户产生过多的账单费用？

Answer 1

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

AWS 提供了避免常见滥用方法的服务，例如缓解 DDoS 的 AWS Shield 等，但是，正如您所问的，他们不知道什么是或不是滥用您的 Lambda 函数。

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

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

使用其中之一，您的 Lambda 函数只能由授权用户调用。如果没有其中之一，就无法防止您担心的滥用类型。

Answer 2

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

考虑使用以下方法来防止第 3 方应用程序“滥用”您的 Lambda 终端节点：

您要控制的一个因素是并发性，即每个帐户和每个功能支持的并发请求数。您按请求收费，加上每个请求的总内存分配，因此这是您要控制的单位。为了防止失控成本，您可以防止失控执行 - 由不良行为者或由合法第 3 方引起的不良软件。

从管理并发

AWS Lambda 的规模单位是并发执行（有关更多详细信息，请参阅了解扩展行为）。但是，并非在所有场景中都需要无限扩展。例如，出于成本原因，您可能希望控制并发性，或者调节处理一批事件所需的时间，或者只是将其与下游资源进行匹配。为此，Lambda 提供了帐户级别和函数级别的并发执行限制控制。

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

创建、测试和部署 API 后，您可以使用 API Gateway 使用计划将它们扩展为面向客户的产品。您可以提供使用计划，以允许指定客户以商定的请求率和配额访问选定的 API，以满足他们的业务需求和预算限制。

什么是使用计划？使用计划规定了谁可以访问一个或多个已部署的 API 阶段，以及调用者可以访问 API 的数量和速度。该计划使用 API 密钥来识别 API 客户端，并使用对单个客户端 API 密钥实施的可配置节流和配额限制来衡量对 API 阶段的访问。

第t hrottling规定，被施加到每个API密钥的请求的速率限制。配额是在指定时间间隔内提交的具有给定 API 密钥的最大请求数。您可以根据使用计划配置将各个 API 方法配置为需要 API 密钥授权。API 阶段由 API 标识符和阶段名称标识。

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

Answer 3

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

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

由于这篇文章，我实际上刚刚在我的一个 lambda 上遇到并解决了这个问题：https : //itnext.io/the-everything-guide-to-lambda-throttling-reserved-concurrency-and-execution-limits -d64f144129e5

基本上，我在我的serverless.yml文件中添加了一行，在我的函数中被所述授权的 3rd 方调用：

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拉姆达是由第三方服务时，任何数据的变化引发了网络挂接调用。例如，在导入数据集时，它会触发多达 100 次调用refresh-cache. 这种行为完全是在向我的 API 发送垃圾邮件，而后者又向其他服务运行请求以执行缓存失效。

添加这一行大大改善了情况，因为一次只有一个 lambda 实例在运行（没有并发运行），调用次数除以 ~10，而不是 50 个调用refresh-cache，它只触发了 3-4 个，并且所有这些调用都有效（由于超时问题，200 而不是 500）。

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

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

在reservedConcurrency对 lambda应用限制之前：

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

reservedConcurrency对 lambda应用限制后：

您可以看到所有调用都成功了，而且速度要快得多。没有超时。既省钱又省时间。

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