桌面应用程序与 AWS S3 的集成：安全最佳实践
Integration of Desktop application with AWS S3: Security best practices
我们正在开发一个桌面应用程序，它允许任何互联网用户转录上传大型 audio\video 文件到 AWS S3 并使用 AWS Transcribe 转录它。计划是在文件成功转录后编写一个 lambda 函数来处理付款。我们希望避免编写自定义 API 网关端点来处理这些文件并在我们的自定义 API 网关端点中与 Amazon S3 集成。我们可以在桌面应用程序中混淆 AWS S3 AWSAccessKey 和 AWSSecretKey（当将 AWS S3 与桌面应用程序集成时），但我不确定这是否是安全最佳实践。
我们需要考虑哪些安全最佳实践（在我们的桌面应用程序与 AWS S3 的集成中），这样我们才不会成为世界上所有坏人的“替罪羊”？如果重要的话，桌面应用程序正在 .Net Core Blazor 6.0 中构建。
正常的流程是：
- 桌面应用程序通过您的后端（控制计费和访问）
进行身份验证
- 后端使用由 AWS Security Token Service (AWS STS)
创建的一组 临时凭证 进行响应
- 桌面应用程序使用这些凭证直接与 AWS 服务通信
使用AWS STS生成临时凭证时，后端可以指定：
- 权限 授予（例如只有 Amazon Transcribe 和足够的权限 upload/download 他们的文件到 S3）
- 临时凭据的持续时间（之后他们需要通过您的后端重新进行身份验证）
缺点是后端不知道向 AWS 提交了哪些请求。这将使计费变得具有挑战性，因为它需要爬取 CloudTrail 日志以确定他们做了什么。 StartTranscriptionJob() API 调用没有任何 condition keys 来强制提供标签，这会使这更容易。
从安全的角度来看，它相对安全，因为该应用仅在有限的时间内拥有有限的权限（但无法控制在这些限制内发出多少次请求).
替代方法 是让桌面应用程序通过 API 调用您的后端，传递要完成的工作。然后后端将代表桌面应用程序提交作业，从而跟踪使用情况并更好地控制应用程序可以做什么，例如限制请求数量。
我们正在开发一个桌面应用程序，它允许任何互联网用户转录上传大型 audio\video 文件到 AWS S3 并使用 AWS Transcribe 转录它。计划是在文件成功转录后编写一个 lambda 函数来处理付款。我们希望避免编写自定义 API 网关端点来处理这些文件并在我们的自定义 API 网关端点中与 Amazon S3 集成。我们可以在桌面应用程序中混淆 AWS S3 AWSAccessKey 和 AWSSecretKey（当将 AWS S3 与桌面应用程序集成时），但我不确定这是否是安全最佳实践。
我们需要考虑哪些安全最佳实践（在我们的桌面应用程序与 AWS S3 的集成中），这样我们才不会成为世界上所有坏人的“替罪羊”？如果重要的话，桌面应用程序正在 .Net Core Blazor 6.0 中构建。
正常的流程是：
- 桌面应用程序通过您的后端（控制计费和访问） 进行身份验证
- 后端使用由 AWS Security Token Service (AWS STS) 创建的一组 临时凭证 进行响应
- 桌面应用程序使用这些凭证直接与 AWS 服务通信
使用AWS STS生成临时凭证时，后端可以指定：
- 权限 授予（例如只有 Amazon Transcribe 和足够的权限 upload/download 他们的文件到 S3）
- 临时凭据的持续时间（之后他们需要通过您的后端重新进行身份验证）
缺点是后端不知道向 AWS 提交了哪些请求。这将使计费变得具有挑战性，因为它需要爬取 CloudTrail 日志以确定他们做了什么。 StartTranscriptionJob() API 调用没有任何 condition keys 来强制提供标签，这会使这更容易。
从安全的角度来看，它相对安全，因为该应用仅在有限的时间内拥有有限的权限（但无法控制在这些限制内发出多少次请求).
替代方法 是让桌面应用程序通过 API 调用您的后端，传递要完成的工作。然后后端将代表桌面应用程序提交作业，从而跟踪使用情况并更好地控制应用程序可以做什么，例如限制请求数量。