如何在AWS中安全存储敏感数据？适用服务及架构方案咨询

核心需求对齐 #

你需要存储用户提交的第三方服务访问唯一凭证，要求存储在RDS等数据库时，所有具备数据库访问权限的IAM用户仅能获取密文，无法拿到明文内容，同时你需要使用密钥代用户调用第三方服务。

可选技术方案对比 #

以下针对你提到的几个实现方向做逐一说明：

• 前端加密（不适合当前场景）：前端加密的密钥要么存储在前端代码中、要么需要用户额外记忆，你后端需要代调用第三方服务时无法正常解密获取明文，且前端加密逻辑容易被逆向破解，完全无法满足你的需求。
• 后端自行实现加密（不推荐）：自己编写加密逻辑、维护加密密钥的成本极高，很容易出现逻辑漏洞，后续的密钥轮转、权限控制都需要自行开发，出安全问题的风险高。
• AWS KMS（密钥管理服务，核心基础能力）：KMS本身不存储业务敏感数据，仅作为加密根信任节点存储客户主密钥（CMK），你可以调用KMS生成数据密钥加密业务数据，自己存储密文，所有加密解密的权限通过IAM控制，安全能力由AWS兜底。
• AWS Secrets Manager（专门的凭证托管服务，可选）：底层基于KMS实现加密，自带凭证版本管理、访问审计、自动轮转能力，但是单条凭证有单独的使用成本，用户量大的话成本会高于RDS存储密文的方案。

推荐架构（完全匹配你的需求） #

组成服务清单 #

• 必选服务：AWS KMS + 现有RDS实例 + 后端业务服务 + IAM权限配置
• 可选优化：Secrets Manager（仅当你需要对单个凭证做独立审计、自动轮转正时使用）

具体实现步骤（最推荐的KMS+RDS方案，成本最低、安全合规） #

1. 先在KMS中创建客户托管CMK（客户主密钥），不要使用AWS托管的默认密钥，方便你自主控制权限。给该CMK配置IAM策略，仅允许你的后端业务服务对应的IAM角色拥有kms:Decrypt和kms:GenerateDataKey权限，其余所有IAM用户、角色（包括AWS账号管理员）都不配置这两个权限。
2. 用户提交第三方密钥时，后端服务先调用KMS的GenerateDataKey接口，获取一对明文数据密钥、密文数据密钥。
3. 后端用明文数据密钥加密用户提交的第三方密钥明文，得到密文密钥。
4. 将用户ID、密文密钥、密文数据密钥三个字段存入RDS，明文数据密钥使用后立即从内存中销毁，不存储在任何位置。
5. 需要代用户调用第三方服务时，后端先从RDS取出对应用户的密文数据密钥，调用KMS的Decrypt接口解密得到明文数据密钥，再用明文数据密钥解密密文密钥，拿到明文后调用第三方服务，调用完成后立即销毁内存中的明文内容。

方案合规性说明 #

• 所有存储在RDS中的内容都是密文，任何具备RDS访问权限的IAM用户即便导出全量数据库数据，拿到的也只有密文密钥和密文数据密钥，没有KMS CMK的解密权限完全无法还原明文，完全满足你的要求。
• 所有加密逻辑使用AWS原生服务实现，不需要自己开发加密算法，避免人为安全漏洞。
• KMS CMK支持自动轮转，不需要你手动维护根密钥更新，也不会影响已存储的存量密文解密。

可选Secrets Manager方案说明 #

如果你的用户规模不大，或者需要对每个用户的密钥做单独的访问审计、自动轮转，可以不用将密钥存在RDS，直接将用户的第三方密钥存入Secrets Manager，用用户ID关联对应的Secret名称，Secrets Manager底层加密使用你自己创建的KMS CMK，同样仅给后端服务开放Secret访问权限，也能达到和上面方案一致的安全效果，缺点是单条Secret每月有固定成本，用户量过万的话成本会明显高于RDS存储方案。

避坑提醒 #

• 不要把任何加密密钥硬编码在代码、配置文件中，所有密钥访问权限都通过IAM角色控制。
• 后端解密得到的明文密钥仅在内存中保留到第三方服务调用完成，不要打印在日志中、不要存入临时文件。
• 不要用RDS的透明数据加密（TDE）代替该方案，TDE仅加密存储层，具备RDS查询权限的用户仍然可以直接查到明文内容，不符合你的需求。

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