系统背景
敏感数据（即信用卡号或 SSN）必须在系统中存储一段时间，以服务于公司的持续运营。
任何人都可以插入敏感数据。只允许特定用户检索。
在保护应用程序和辅助服务方面采取的预防措施。（即 HTTPS 连接、安装常规安全更新、研究/安全身份验证/会话管理、后端 SSH、保护整个应用程序免受 XSS、SQLi 等攻击）
鼓励授权访问敏感数据的最终用户 PC 和网络上的安全实践，但可能无法从服务器端强制执行。
该应用程序是从头开始设计的。（不是追溯安全升级）
加密数据并不总是安全的
我认为任何安全专家都会告诉您加密机器上的敏感数据（即 SSN 或信用卡号），即使在生产过程中也是如此，因为即使采取了适当的预防措施和彻底的安全设计，总是存在某种风险，数据可能被泄露，服务器被黑，或者应用程序被利用。
我看到的加密问题是服务器还必须能够访问密钥。虽然我们可以将其存储在 SQL 数据库之外。这也可以备份在纸上而不是通常的电子档案上。除了 SQL 注入或备份盗窃之外，还有许多可能的攻击，在这种情况下，密钥也会被盗，从而破坏加密。
前段时间我为密钥管理设想了一个解决方案，但直到今天我才将其发布为一个请求专业反馈的问题。
解决方案，请求反馈。
当用户帐户被授权访问/导出敏感数据时：
需要重置密码，并进行非常高强度的检查。
为User生成一个非对称 (RSA) 密钥对。公钥以明文形式存储。
私有用户密钥使用从用户（强）密码派生的对称加密进行加密。
→ 要访问此用户的私人用户密钥，您需要猜测用户的密码。
像往常一样，密码是用 BCrypt 保存的，与 Key Derivation 完全分开。
敏感数据由未经授权的用户提交。
为Data生成一个非对称密钥对。公共数据密钥以明文形式存储。
使用每个授权用户的公共用户密钥对私有数据密钥进行加密。
敏感数据使用Data key加密。
→ 要访问敏感数据，需要确定私有Data key ，它不是直接存储的，但是如果你猜到Authorized User的密码就可以访问。
相同的数据密钥最多可重复使用 90 天。
当没有数据关联时，旧键将被清除。
当授权用户登录时。
使用 BCrypt 验证登录。
使用至少 72 位熵生成会话令牌并传递给浏览器。
私有用户密钥被临时解密（使用从密码派生的对称密钥），然后为当前会话重新加密。（使用从会话令牌派生的对称密钥）
→ 要访问敏感数据，可以猜测用户的密码，或者窃取会话令牌。
服务器端仅存储会话令牌的简单 SHA-256 哈希。
登录时，授权用户的浏览器将传递会话令牌，该会话令牌用于解密用户密钥，用于解密适当的数据密钥，然后可以在适当的地方提供敏感数据。
因此，假设服务器或数据库遭到入侵，攻击者需要执行以下操作才能访问敏感数据。
- 猜猜一小群授权人中较弱的密码之一，或
- 从授权个人 当前使用的机器上窃取会话密钥
- 或者，编辑操作软件以开始以纯文本形式存储数据（仅当入侵提供读+写访问权限时才有可能）
在我看来，这是可能的最可靠的安全实现。
A）这是推荐的吗？
B）这是在主流库或应用程序中实现的，还是这是一个相当独特的想法？