将敏感信息存入DynamoDB前是否需要对Pin字段额外加密？

DynamoDB原生提供的静态加密仅保护存储介质层面的数据安全，也就是AWS底层物理磁盘丢失、销毁、未授权访问场景下的数据不泄露，所有合法获得DynamoDB表读权限的身份（包括内部运维账号、误配置权限的服务角色），都可以直接读取到字段明文。

是否需要自行做字段级加密 #

是否需要在存入前加密、读取后解密，完全取决于你的安全等级要求：

• 如果你的合规要求、安全策略要求仅允许处理用户Pin查看请求的专属服务才能拿到Pin明文，其余所有角色（哪怕有DynamoDB读权限）都无法获取Pin内容，就必须做字段级的自行加解密
• 如果你已经对DynamoDB表的读权限做了极严格的最小权限管控，且不需要应对权限误配置、数据导出泄露等额外风险，也可以选择不做

自行加解密的实际意义 #

这个操作的价值非常明确，属于深度防御的关键手段：

1. 即使出现DynamoDB权限配置错误，未授权身份拿到的也是密文，不会直接泄露敏感数据
2. 全表备份、离线导出的数据集里Pin字段也是加密状态，避免备份数据泄露风险
3. 可以满足等保、PCI-DSS等合规标准对敏感个人信息的加密存储要求

其他相关注意事项 #

• 密钥要做独立权限管控，不要把加密密钥存在DynamoDB或者代码配置里，使用专门的密钥管理服务存储，密钥的解密权限要和DynamoDB的读权限完全隔离，仅授予处理Pin查看请求的专属服务解密权限
• 加解密逻辑必须部署在可信服务端，绝对不要放到前端执行，前端仅负责展示解密后的明文，不要接触密钥或加解密过程
• 所有Pin字段的解密、查看操作都要留全量审计日志，记录请求用户ID、操作时间、来源IP、操作结果等信息，方便后续溯源排查
• 不要将Pin字段设为表的分区键、排序键，也不要为该字段创建二级索引，避免加密后索引失效，同时减少敏感数据的扩散范围
• 加密算法选择业界标准的AES-256-GCM这类对称加密算法即可，不要自己实现加密逻辑，直接使用编程语言官方提供的标准加密库
• 用户触发Pin查看操作时，要做额外的身份校验，比如二次验证码、操作密码验证，避免用户账号被盗后Pin被直接窃取

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