Django集成RSA加密如何实现多管理员解密查看用户数据

原生RSA设计为单公钥对应单私钥的非对称加解密对，天生不支持单密文多私钥解密。硬改RSA参数（如多素数构造、私钥分片共享）不仅存在已知安全漏洞，也不符合密码学合规要求，不建议使用。

工业界通用的落地方式是采用混合加密+多密钥封装机制，完全适配多授权方独立解密的业务需求，改造成本低、安全合规，具体实现流程如下：

一、用户提交数据加密流程 #

调整原有用用户公钥加密业务数据的逻辑（该逻辑本身存在矛盾：用户公钥加密的密文仅能由用户私钥解密，管理员天生无解密权限），按以下步骤执行：

• 用户提交测验、调研数据时，后端先生成一次性256位AES对称密钥（单次提交单次生成，绝不跨请求复用），使用AES-GCM模式（带完整性校验，可防篡改）加密全量业务明文，得到的业务密文存入业务表的encrypted_content字段。
• 拉取当前所有有权限查看该类提交数据的管理员RSA公钥，用每一位管理员的公钥，分别加密本次生成的临时AES密钥，得到N份（N为授权管理员数量）密钥密文，存入关联的encrypted_data_keys表，表字段至少包含：关联业务数据ID、管理员ID、对应公钥加密后的AES密钥串。
• 用户侧RSA密钥对仅用于身份校验：用户提交时用自身私钥对提交内容做签名，后端存储签名值，后续可校验数据确实为对应用户提交、未被篡改，无需参与业务数据加密流程。

二、自定义管理员门户解密流程 #

• 管理员登录自定义门户请求查看某条提交数据时，后端先做权限校验，确认当前管理员有该条数据的查看权限后，从encrypted_data_keys表中取出匹配当前管理员ID、对应数据ID的那份加密后的AES密钥返回给前端。
• 解密操作全程在前端完成：管理员私钥必须本地存储（可选择浏览器加密存储、硬件UKey存储，绝对禁止上传后端留存），前端调用本地私钥解密拿到临时AES密钥后，再解密encrypted_content字段的业务密文得到明文，供管理员查看、做数据分析。
• 后续做权限变更时无需改动原始业务密文：新增管理员时，用新管理员的公钥批量加密所有其有权限查看的历史数据对应的AES密钥，补存入encrypted_data_keys表即可；管理员失权时，直接删除表中对应该管理员的所有密钥记录，即可立刻回收其解密权限，运维成本极低。

三、可选替代方案（仅适合固定管理员组的高保密场景） #

如果你的管理员群体范围固定、不需要单管理员独立解密，可选择Shamir门限秘密共享方案：

• 生成一套全局统一的RSA加解密密钥对，将私钥通过门限算法拆分为M个分片，每个管理员持有一个分片。
• 用户提交数据时统一用全局公钥加密业务密文，解密时只要凑够预设阈值数量（比如5个管理员中凑够3个）的私钥分片参与计算，即可还原私钥解出明文。
• 该方案缺点是权限粒度粗，单管理员无法独立完成解密，不适合需要独立查看、分析数据的常规场景，仅适合需要多人审批才能解密的高保密等级业务。

Django落地注意事项 #

• 不要自行实现密码学算法，直接使用成熟的cryptography库完成加解密操作：RSA填充使用OAEP模式，AES使用GCM模式，避免自实现逻辑带来的填充漏洞、时序攻击风险。
• 临时生成的AES密钥仅在服务内存中参与计算，禁止明文落盘、禁止写入日志。
• 后端绝不存储任何管理员私钥、明文AES密钥，就算数据库被拖库，攻击者拿到的仅为业务密文和经管理员公钥加密的AES密钥，无对应私钥无法解密，满足数据安全合规要求。

避坑提醒：绝对不要采用“单个RSA私钥复制多份发给所有管理员”的实现方式。该方案下任意一个管理员的私钥泄露，全量加密数据都面临泄露风险；且无法做权限回收，管理员失权后必须更换整套RSA密钥对、重新加密全量历史数据，安全和运维成本极高。

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