基于KMS客户端加密的S3预签名URL大文件下载安全方案咨询

1. 适用该场景的可行解决方案 #

• 后端代理流式解密方案
  从根源规避前端凭证泄露风险，KMS凭证全程仅保存在后端服务中。前端发起下载请求后，后端先通过预签名URL拉取S3上的加密文件，同步调用KMS完成解密，再将明文文件流式返回给浏览器。大文件场景下可以通过分片拉取、分片解密的方式控制后端内存占用，不会产生文件缓存积压。
• 信封加密分离解密权限方案
  上传阶段采用信封加密逻辑：后端调用KMS生成数据密钥，将明文数据密钥返回给前端用于本地加密文件，前端将加密后的文件密文、KMS加密过的数据密钥一同上传到S3存储。下载阶段前端通过预签名URL拿到密文和加密后的数据密钥，仅将加密后的数据密钥传给后端请求解密，后端返回明文数据密钥给前端完成本地文件解密，全程前端不会接触到任何AWS服务凭证。
• 临时凭证前端解密方案
  若必须在浏览器端完成完整解密逻辑，不要使用永久AKSK凭证，由后端通过STS服务生成临时凭证返回给前端使用，凭证权限、有效期做严格限制。

2. 浏览器端使用AWS SDK的凭证防泄露方案 #

不存在可以完全阻止用户通过F12调试工具获取前端运行时数据的方案，只能通过限制凭证权限、缩短有效期的方式降低泄露后的风险，同时提升凭证获取门槛，具体可实施的操作如下：

• 禁止在前端静态资源中硬编码任何永久AWS凭证，不管是打包阶段替换还是写在前端配置文件中，所有静态资源中存储的凭证都可以被直接扒取。
• 所有前端使用的AWS凭证必须通过STS生成，做三重限制：
  • 有效期设置为1-5分钟，泄露后几乎没有可利用的时间窗口
  • 权限最小化：仅授予指定KMS密钥的解密权限，不开放其他任何AWS服务的操作权限
  • 增加调用限制：绑定请求用户的IP、前端来源域名，非指定场景下拿到凭证也无法调用AWS接口
• 前端拿到凭证后仅存储在闭包变量中，不要持久化到localStorage、sessionStorage、Cookie等存储位置，解密任务完成后立刻将凭证变量赋值为null触发垃圾回收。
• 对前端解密相关的代码做混淆、反调试处理，提升普通用户通过调试工具抓取内存中凭证的门槛。

安全等级要求较高的场景优先选择后端代理解密方案，从根源上避免AWS凭证流出后端可信环境。

内容的提问来源于stack exchange，提问作者futurexv