ios - 在 iOS 客户端与后端服务器上管理对 AWS 服务的访问

Question

在设计 iOS 时将与 AWS 交互的应用程序(例如 S3 、 CloudFront 等)，在客户端和服务器上管理对这些服务的访问有哪些优缺点？

“管理访问”是指将私有(private)内容上传到 S3、通过 Cloudfront 下载私有(private)内容。

当然，无论哪一方处理访问都需要存储 AWS访问 key 和访问 secret 。安全是其中一个问题。

我同样对这种设计选择对任一实现的性能和灵 active 的影响感兴趣。

最后，是否有关于实现客户端和服务器都直接与 AWS 交互的混合方法的论据？ ，或者实现通常与其中一个一起使用，而不是两者一起使用？

Answer 1

虽然在很多情况下您可能希望以任何一种方式执行此操作，但几乎没有任何情况下您会希望直接从客户端执行此操作，因为您提到了 ios:

通过服务器端将数据上传到 AWS 的优点:

1. 安全

   正如在另一个答案中已经提到的那样，如果不法分子和黑客试图破坏内容，最初拥有经过身份验证的请求将为您省去很多麻烦。如果数据是私有(private)的并且您真正致力于保护隐私，那么如果系统经过身份验证，则更容易防止任何数据泄露。

2. 速率限制、用户配额等

   经过身份验证的系统的额外优势是您可以对来自特定来源的请求进行速率限制，例如用户、组、IP 等(如果您打算围绕同一系统架构构建多个应用程序，则应用程序级别配额)。当您直接在客户端工作时，构建这种智能并不那么容易。

3. 审计追踪

   如果您需要跟踪谁上传了什么、何时、从何处以及更多此类信息，如果您直接在您的服务器上获得初始请求，这将再次更容易跟踪。

4. 失败时的异常处理

   在 QA 测试期间，很可能会出现您无法轻易预测到的故障，或者遗漏关键错误。处理这些服务器端效率更高，因为它在您的控制之下。当客户端出现任何此类问题时，您将受制于能够升级应用程序的客户。如果您正在处理此服务器端，则可以轻松地为许多此类错误放置/部署额外的检查，从而限制错误的范围。

5. 是时候上线了

   同样，如其他答案中所述，您的更新可能需要一段时间才能获得批准。这大大降低了您对关键问题的响应能力，并且在严重问题(数据泄露/隐私泄露)导致重大损失(财务/用户信任/负面评级等)的情况下很难缓解

我认为您希望将数据直接从客户端上传到 AWS 的唯一情况是

• 上传大量数据，非常非常频繁，没有直接处理。

  如果上传一次需要一定的带宽和网络资源，上传两次需要双倍的资源(一次从client --> server，然后从server --> AWS)。因此，如果您频繁上传大量数据(每天想想 TB)，那么您最终只会浪费大量资源，只是将数据从一个点复制到另一个点。在这种情况下，将数据直接推送到 S3 是有意义的。但要让这种方法发挥作用，您节省的成本应该足够多，足以克服对安全和隐私的担忧，而对于大多数应用程序而言，情况并非如此。

• 你在一个有围墙的花园里

  基本上，该应用程序仅适用于某些预先确定的用户，该应用程序根本不适用于其他任何人(假设您开发此应用程序是为了在公司内部使用)。从本质上讲，这意味着对最终用户使用您的应用的动机有 100% 的信心。

---

编辑:OP 在评论中提问

How about server providing signed URL/cookies, and client uses these to upload to S3 or download from Cloudfront. Client still directly interacts with AWS but requires permissions controlled by server.

乍一看，我觉得这很可行。这blog post提供了许多关于使用签名 url 的用例(例如提供通配符签名 url 以供阅读)(尽管示例位于 .NET 中)，更多信息可在 AWS docs 上找到。 .

由于您要处理签名服务器端，您可以轻松处理我之前在帖子中提到的每一点(速率限制、用户配额、审计跟踪等都是可行的，因为请求最初会到服务器)。作为this answer提到，

Signing URLs helps control who can access a given file and how long they can access it for.

总的来说，这应该适用于相当多的用例。