基于 AWS 的客户端 SDK 的访问管理

Question

我正在为我的产品开发客户端 SDK（基于 AWS）。工作流程如下：

1. SDK 的用户不知何故将数据上传到一些 S3 存储桶
2. 用户以某种方式将命令保存在 SQS 中的 some 队列中
3. EC2 上的一个工作人员轮询队列、执行操作并通过 SNS 发送通知。这一点似乎很清楚。

您可能已经注意到，这里有很多关于访问管理的一些不清楚的地方。是否有任何惯例可以为此类 SDK 的第 3 方用户提供对 AWS 服务（在本例中为 S3 和 SQS）的访问权限？

我现在看到的选项：

• 我们为 SDK 的用户创建 IAM 用户，这些用户可以访问一些 S3 资源和 SQS 的写入权限。
• 我们在 AWS 和 SDK 之间创建额外的服务器/层，将消息写入 SQS 而不是用户，并为 SDK 提供一次性的短期链接以将数据直接写入 S3。

第一个似乎没问题，但是我很犹豫我在这里遗漏了一些明显的问题。第二个似乎在可扩展性方面存在问题 - 如果这一层关闭，整个系统将无法工作。

附：

我已尽力解释这种情况，但我担心这个问题可能仍然缺乏一些背景。如果您想了解更多信息，请随时发表评论。

Answer 1

我建议您仔细查看Temporary Security Credentials，以限制客户仅在需要时访问他们需要的内容。

请记住，此类问题的任何解决方案都取决于您的规模、您的客户以及您可以向客户展示的内容。

在您的第一个选项中，让客户直接使用 IAM 或临时凭证会向他们展示 AWS 在幕后的知识（因为他们可以很容易地看到离开其系统的请求）。他们有可能使用这些凭证发出自己的 AWS 请求，超出您的代码可以验证和控制的范围。

您的第二个选项更好，因为它解决了这个问题 - 通过使您的服务器成为 AWS 的唯一联系点，允许您在将客户提供的数据发送到 AWS 之前执行输入验证等。它还可以让您轻松替换实施而不影响客户。关于可用性/可扩展性问题，这就是 EC2（和类似服务）的用途。

同样，所有这一切都取决于您的规模和客户。对于只有少量客户的玩具应用程序，为了让某些东西更快地工作（而不是为可能不会使用的东西构建和支付大量基础设施），更简单可能更好。