时间戳

首页 > 解决方案 > 桌面应用程序与 AWS S3 的集成：安全最佳实践

amazon-web-services - 桌面应用程序与 AWS S3 的集成：安全最佳实践

问题描述

我们正在开发一个桌面应用程序，它允许任何互联网用户将大型音频/视频文件上传到 AWS S3 并使用 AWS Transcribe 进行转录。计划是在文件成功转录后编写一个 lambda 函数来处理付款。我们希望避免编写自定义 API 网关端点来处理这些文件并在我们的自定义 API 网关端点中与 Amazon S3 集成。我们可以在桌面应用程序中混淆 AWS S3 AWSAccessKey 和 AWSSecretKey（将 AWS S3 与桌面应用程序集成时），但我不确定这是否是安全最佳实践。

我们需要考虑哪些安全最佳实践（在我们的桌面应用程序与 AWS S3 的集成中），这样我们才不会成为世界上所有不良行为者的“坐鸭”？桌面应用程序正在 .Net Core Blazor 6.0 中构建，如果这很重要的话。

标签： amazon-web-servicessecurityamazon-s3blazor

解决方案

正常的过程是：

  • 桌面应用程序通过您的后端（控制计费和访问）进行身份验证
  • 后端使用一组由 AWS Security Token Service (AWS STS) 创建的临时凭证进行响应
  • 桌面应用程序使用这些凭证直接与 AWS 服务通信

使用 AWS STS 生成临时凭证时，后端可以指定：

  • 授予的权限（例如，仅 Amazon Transcribe 和将文件上传/下载到 S3 的足够权限）
  • 临时凭证的持续时间（之后他们需要与您的后端重新进行身份验证）

不利的一面是后端不知道向 AWS 提交了哪些请求。这将使计费变得具有挑战性，因为它需要爬取 CloudTrail 日志来识别他们做了什么。StartTranscriptionJob()API 调用没有任何条件键来强制提供标签，这会使这更容易。

从安全的角度来看，这是相对安全的，因为该应用程序仅在有限的时间内具有有限的权限（但无法控制在这些限制内发出多少次请求）。

另一种方法是桌面应用程序通过 API 调用您的后端，传递要完成的工作。然后后端将代表桌面应用程序提交作业，从而跟踪使用情况并更好地控制应用程序可以做什么，例如限制请求的数量。

推荐阅读