Alexu
发布于 2025-04-17 / 2 阅读
0
0

防止开发者获取用户信息的web系统方案设计

PowerRich 是一个致力于保护用户隐私的EMS数据平台,通过采用零知识架构方案来确保用户数据的安全性,并通过第三方安全认证用户密钥安全。在该架构下,PowerRich 平台仅存储用户数据的加密版本,针对普通用户,由平台进行密钥托管,针对Enterprise用户,用户可以选择自己管理或交由第三方平台管理软件U盾。这种设计保证了即使在最坏的情况下,平台也无法访问用户的原始数据。

方案一:

1. 核心设计原则

  • 密钥存储在客户端:用户的加密密钥仅存储在浏览器或本地设备中,不上传到服务器。

  • 前端加密:所有敏感数据在前端完成加密后再发送到服务器。

  • 零知识架构:开发者和服务器无法访问用户的加密密钥或解密后的敏感数据。


2. 用户注册与密钥管理

(1)用户注册流程

  1. 用户注册时,输入账号(手机号/email) + password,系统不强制要求上传密钥。

  2. 用户可以选择以下两种方式之一生成加密密钥:

    1. 自动生成密钥:前端生成一个随机密钥(如AES-256密钥)。

    2. 导入密钥:用户手动输入或上传自己的密钥。

  3. 密钥生成后,存储在客户端(如浏览器的localStorageIndexedDB或密码管理器中)。

  4. 密钥不会上传到服务器,也不会以任何形式暴露给开发者。

(2)密钥备份与恢复

  • 提供密钥导出功能,允许用户将密钥下载为文件(如Base64编码的文本文件)。

  • 提醒用户妥善保管密钥文件,丢失密钥将导致数据无法解密。

  • 提供密钥导入功能,允许用户在其他设备上恢复密钥。


3. 前端加密与解密流程

(1)加密流程

  1. 用户输入敏感数据(如密码、文件内容等)。

  2. 前端从客户端存储中读取用户的加密密钥。

  3. 使用加密库(如WebCrypto API或第三方库如CryptoJS)对数据进行加密(如AES-GCM模式)。

  4. 将加密后的数据发送到服务器存储。

    1. 加密后的数据无法被服务器解密,因为密钥不在服务器上。

(2)解密流程

  1. 用户请求访问敏感数据。

  2. 前端从服务器获取加密后的数据。

  3. 前端从客户端存储中读取用户的加密密钥。

  4. 使用加密库对数据进行解密。

  5. 显示解密后的数据给用户。


4. 后端存储与传输安全

(1)后端存储

  • 后端仅存储加密后的数据,无法解密。

  • 数据存储格式示例:

    • { "userId": "12345", "encryptedData": "U2FsdGVkX1+3vGJ7dKZzwerq...", "encryptedData2": "U2FsdGssVkX1+3vGJ7dsfdKZz..." }

(2)传输安全

  • 所有数据通过HTTPS传输,确保传输过程中的安全性。

  • 前端和后端之间的通信应尽量减少敏感信息暴露。


5. 密钥存储与安全性

(1)客户端存储方案

  • localStorage:简单易用,但容易受到XSS攻击。

  • IndexedDB:更安全,适合存储较大的数据。

  • 浏览器密码管理器:用户可以手动将密钥保存为密码。

  • 硬件安全模块(HSM):如果用户设备支持(如WebAuthn),可以将密钥存储在硬件中。

(2)密钥保护措施

  • 使用加密算法(如PBKDF2或Argon2)将密钥加密后存储。

  • 要求用户设置一个强密码,用于解锁密钥。

  • 防止XSS攻击:对所有输入进行严格的验证和转义。


6. 用户权限与身份验证

(1)用户登录

  • 用户登录时,后端验证用户身份并返回一个JWT或会话令牌。

  • 登录过程与密钥管理完全分离,确保即使登录信息泄露,也无法获取密钥。

(2)多设备支持

  • 如果用户需要在多个设备上访问数据,必须在每个设备上导入相同的密钥。

  • 不建议通过服务器同步密钥,避免服务器接触到密钥。


7. 用户体验优化

  • 密钥丢失提醒:明确告知用户,丢失密钥将导致数据无法恢复。

  • 数据迁移支持:允许用户重新生成密钥并重新加密数据。

  • 性能优化:对于大文件加密,采用分块加密和异步处理。


11. 总结

通过将用户的加密密钥存储在客户端,所有敏感数据在前端完成加密后再传输到服务器,可以实现真正的零知识架构。这种设计确保了开发者和服务器无法访问用户的敏感数据,同时提供了灵活的密钥管理和强大的安全性。


方案二:

使用AWS/aliyun的KMS管理

用户账号相关

注册登录+ 验证码(或短信验证)+ 有效期10min

用户注册:

Password: 前端加密:-> 后端md5 + salt + hash -> 落库 ->在KMS注册与用户相关的KEY

信封解密

数据流安全分析

  1. 注册过程数据流

前端 --(HTTPS)--> API网关 --(明文)--> 应用服务器 --(仅内存明文)--> KMS
                                   |
                                   v
                               数据库(只存加密数据)
  1. 登录过程设计考量

  • 故意不涉及解密:登录只需验证密码哈希

  • 减少密钥使用:降低KMS调用成本和攻击面

  • 权限最小化:登录流程无需Decrypt权限

为什么开发者无法解密

  • 缺少KMS解密权限:IAM策略显式拒绝

  • 无法获取数据密钥明文encrypted_key需KMS解密

  • 即使有数据库访问权:只能获得加密数据块

  • 所有敏感操作都有审计日志, 每次解密操作都有记录可查

系统可用性保障

密钥轮换不影响现有数据

  • 旧数据:仍能用旧密钥解密(KMS保留所有版本)

  • 新数据:自动使用新密钥加密

这种方式可以对开通加密的用户进行单独加密,其他用户还是用明文存储。


评论