在后端，如果我使用 HSM（或者甚至在物理服务器上拥有主密钥），我需要使用该密钥进行操作。这意味着应用服务器将调用 HSM（或密钥服务器）。对 HSM 的调用进行身份验证的通常做法是什么？仔细阅读，它通常通过 HSM 签署/知道的密钥对完成。但是，如果应用服务器遭到入侵，那么攻击者可以只中继消息并使用 HSM 执行操作并获取有效数据。我相信当服务器本身受到损害时，这是可以预料的，并且是正常的。
我知道使用 HSM 背后的主要思想是保护密钥。但是，在识别对 HSM/密钥服务器的受损访问方面是否付出了很多思考/努力？
这可以通过多种方式实现。对 HSM 最简单的访问控制是物理按钮。因此，如果恶意软件破坏了主机，仍然需要有人亲自到场才能按下按钮，以便 HSM 执行任何操作。
然后，您将拥有一系列不同的访问保护，从“外部”验证主机服务器中的软件到要求输入 PIN（如果服务器发现自己受到威胁，它会自行删除）。
HSM 还可以限制对密钥的操作。例如，只允许密钥用于签名而不是解密。或者对正在签名或解密的输入数据要求特定格式。
HSM 可以强制执行的另一件事是速率限制，既适用于身份验证尝试，也适用于操作。通常解密的服务器假设每 15 分钟 1 条消息可以设置为将速率限制为每 10 分钟最多 1 条消息，这将降低来自受感染服务器的 HSM 访问的有用性。
但是，HSM 的主要目标不是限制对 HSM 本身的访问。HSM 的主要目标是确保密钥本身永远不会离开 HSM。在这里，它的范围从仅允许通过简单接口访问的简单 HSM，但它不具有任何防止物理危害/攻击的功能，而规模的另一端是非常先进的 HSM，甚至可以抵抗攻击如果对手在很长一段时间内对 HSM 的物理访问不受监控。
打个比方：
想象一下自己：如果有人能够使用你的车钥匙一次，这有关系吗？你的车受损了吗？不，因为您的车钥匙没有被复制。对手获得了对您汽车的一次性访问权限。一旦您收回对汽车钥匙的控制权，汽车钥匙就完全安全且使用安全。
但是，如果有人复制了车钥匙，它就会受到影响，需要更换。
想象一下与加密密钥相同的事情。某些加密密钥可能很难或难以替换，并且如果替换过程涉及受损密钥，则替换它的过程本身可能容易受到永久性不可撤销的损害。（例如：攻击者使用泄露的密钥启动对他自己的密钥的替换过程。如果密钥管理系统是分布式的且不受管理，则公司或个人将永久失去对该记录的访问权限）。
这里，HSM 还可以包含防止对启动替换过程（撤销证书等）的相应数据进行签名的功能，除非输入了服务器不知道的特定 PIN。