Security 如何为守护进程或服务提供加密密钥？

我正试图找出一个解决“鸡和蛋”问题的方法，我在一个新的项目中遇到了这个问题，我正在为一个新的企业工作

有问题的系统正在处理信用卡数据，因此卡号等需要加密存储在数据库中。为了符合PCI要求，我们为每个“商户”使用唯一的密钥对加密数字，因此，如果一个商户受到威胁，则不可能访问另一个商户的持卡人数据

当涉及到人与系统的交互时，这是很好的，因为人可以输入密码短语来解锁私钥，然后解密数据，但是当涉及到需要访问数据的自动化服务时（即在以后处理事务）如何最好地向服务/守护进程提供凭据存在一个问题

系统的一些背景知识：

• 卡号是用非对称密钥对加密的
• 私钥受密码短语保护
• 然后使用“主”密钥对该密码短语进行加密
• 解锁主私钥的密码短语随后被授予权限的操作员知道（实际上，他们使用自己的密钥对加密了密钥副本，而他们只知道密码短语）
• 守护进程将作为自己的用户和组在linux系统上运行

为了让守护进程能够解密数据，我考虑了以下几点：

• 设置密码短语文件，其工作原理与
• 将文件存储在守护程序用户的主目录中
• 将文件的权限设置为0600
• 设置文件完整性监视系统（如Tripwire），以通知安全组（或类似组织）对文件或权限的任何更改
• 禁用守护程序用户的登录，因为它仅用于进程

鉴于上述情况，我想知道这是否足够。很明显，弱点在于系统管理员——在安全系统上受信任的管理员（即2名）很少——因为他们可以提升权限（即root权限）然后更改文件的所有权或权限，以便能够读取密码短语-但是，这很可能再次通过监控文件的校验和更改、FIM校验和等来缓解

---

那么，我是不是走错了路，还是有其他关于如何处理的建议？

不确定这会有多大帮助，因为你的目标是遵守PCI-DSS，你需要说服的人是你的QSA

大多数QSA公司乐于以咨询的身份工作，并帮助您找到合适的解决方案，而不是单纯以评估的身份工作，因此尽早让他们参与进来，并与他们合作，以获得他们乐于签署为合规的解决方案

也许值得让他们记录为什么它是足够的，这样如果你在将来改变QSA，你可以与你一起推理，以防主题再次出现

---

基于上述解决方案，他们可能会提到的一件事是用于密钥管理的拆分知识。听上去，单个管理员拥有访问密钥所需的所有知识，而PCI（3.6.6）要求对手动明文密钥管理过程进行拆分知识和双重控制。

我们与QSA讨论了这一点（这可能是自审计以来关系中最有价值的部分）他建议我们使用一个运营商帐户（只有用户知道密码）来解锁服务帐户的详细信息。这有点像一个嵌套的俄罗斯玩偶设置，但它似乎可以工作，这意味着我们可以根据需要轻松地旋转关键点。