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

Question

我想找出解决方案，我遇到了一个项目，我正在为一个新的合资企业工作过的'鸡和蛋'问题。

该系统正在处理信用卡数据，因此需要将卡号等加密存储在数据库中。为了符合PCI要求，我们使用每个“商家”的唯一密钥对对数字进行加密，因此，如果一个商家遭到入侵，就不可能访问其他商户持卡人数据。

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

在系统上一点背景：

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

对于守护进程能够解密我正在考虑中的数据如下：

• 设置类似于如何.pgpass工作
• 在文件中存储的主目录守护口令文件用户
• 设置权限为0600的文件
• 设置一个文件完整性监测系统，诸如绊通知的任何变化的安全组（或类似）的文件或权限秒。
• 为守护进程用户禁用登录，因为它仅用于进程。

鉴于上述，我想知道这是否足够。显然，系统管理员面临的弱点是 - 这些（即2）在安全系统上值得信任 - 因为他们可以提升他们的权限（即以root身份），然后更改文件所有权或权限以便读取密码 - 但是再一次，这可能是通过监视文件校验和变化，FIM校验和等来缓解的。

那么，我是否正在处理这种错误的方式，或者是否存在其他有关如何处理此问题的建议？

Answer 1

不知道有多少帮助，因为您的目标是符合PCI-DSS，您需要说服的人是您的QSA。

大多数QSA公司都乐于以咨询的方式工作，并且帮助您找到合适的解决方案，而不是单纯以评估能力工作，因此尽早让他们参与并与他们合作，以获得他们乐意签署的解决方案兼容。

可能值得让他们记录为什么它也足够，以便如果您将来更改QSA，可以在主题再次出现的情况下采取推理。

基于上述解决方案，他们可能会提及的一件事是密钥管理的分解知识。这听起来像是一个单一的管理员拥有访问PCI（3.6.6）需要对手动明文密钥管理程序进行分离知识和双重控制的密钥所需的全部知识。