我有一个用例，我需要加密数据库中的一条 PII 信息，然后可以由应用程序中的多个用户角色（例如，它所属的用户、客户服务、工程等）对其进行解密和访问。 .
这类事情的行业标准策略是什么？
更新：发布前请阅读：除了在下面发布我的想法的反馈（我真的很感激），还请提出一个策略。我相信这对当今试图加密任何共享资源的任何人都会非常有帮助。
这是我目前的想法，希望能更好地描述我所指的内容：
全面披露：以下信息也旨在就我提出的当前策略获得意见或同行评审
作为分层防御策略的一部分，我的标准是加密/解密策略至少有 3 个因素，这样，如果任何 2 个部分受到损害，数据仍然无法解密。
3 个因素：访问信息的软件、带有加密数据的数据库（DB1）、带有加密密钥的数据库（DB2）。
加密策略：
- 数据被输入到软件中
- A、比方说，生成128bit Key
- 数据使用该密钥加密
- 加密数据存储到数据库中（在上述 3 个因素中表示为 DB1）
- 128b 密钥使用软件中硬编码的主密钥进行加密
- 加密的 128b 密钥被存储到另一个数据库中（在上述 3 个因素中表示为 DB2）
解密策略是相反的..
关键是软件持有主密钥（因素 1），DB1 有加密的数据（因素 2），DB2 持有加密的加密密钥（是的，单词重复......也是因素 3），只能用主密钥解密钥匙。
在我的脑海中，如果其中任何一个被暴露，它就是无用的信息，不会泄露加密的 PII。
顺便说一句，这假设了可靠的加密算法，例如 AES（.. 最有可能的 AES 仅考虑到 DES、3DES 和 Blowfish 已被弃用）。
更新我意识到我并没有明确说明这三个因素将在哪里重新出现。所有 3 将在 3 台不同服务器上的不同托管环境中我们正在谈论一种大规模策略（也可以在小规模上工作），其中数据库本质上是独立的硬件实体。在我看来，这是一开始的假设。
更新 2这里的很多反馈都正确地表明该软件是这里的致命弱点。这也是我的大话。我想不出任何软件策略，如果软件受到损害，数据不会面临风险，因为该软件始终与数据库有一个开放的连接，并且包含查看/处理该数据的所有业务逻辑。即使在软件中实现 mydiamo，这仍然意味着如果有人控制了软件，数据就会受到损害。