你在这里问了几个问题，所以我将提供几个答案和一些澄清。

我会将 AES 密钥 (DEK) 存储在基于 HSM 的密钥管理服务（即 Azure Key Vault / AWS KMS）中，并将检索密钥以加密/解密我的 Nodejs 服务器上的数据。

这通常不是您想要做的。如果您使用的是 HSM，则目标是让钥匙留在HSM 内，永远不要离开。实现此目的的一种常见方法是将密钥加密密钥 (KEK) 存储在 HSM 中，并将加密的数据加密密钥 (DEK) 存储在其他位置。对于 Azure Key Vault，这些可能是可检索的机密。我敢肯定亚马逊也有类似的东西。然后，当您需要使用 DEK 时，将其传递给 HSM，在 HSM 中使用 KEK 对其进行解密，然后返回给您。

1) 我应该为每个用户创建不同的 AES 数据加密密钥吗？如果是这样，这背后的原因是什么？只是另一层复杂性？

是的。原因是如果一个密钥被泄露，所有的数据都没有，只有用这个密钥加密的数据。（换句话说，一个客户的数据。）此外，它消除了许多应用程序缺陷（除了与密钥检索特别相关的缺陷）允许一个客户意外访问另一个客户的数据的能力。

2）如何最好地保护密钥免受攻击，例如当服务器被黑客攻击和跟踪/监控时？

保护您的服务器。并遵循此处的其他建议，例如仅在需要时公开密钥。

3）更好的做法是在服务器启动时检索密钥，然后将密钥存储在服务器的内存中，或者每次服务器需要为用户加密数据时检索密钥？

最好在执行所需执行的加密或解密操作所需的最短时间内公开密钥。每次服务器启动时都检索它们听起来有些过分。无论是在用户登录时检索它们，还是等到需要执行实际的加密操作才最有意义，这取决于您的判断。同样，在合理范围内，窗口越小越好。

从技术上讲，当密钥在 HSM 上时，您一开始就不应该那么快地将其取出。

如果可能，要求 HSM 需要特殊身份验证才能显式抛出密钥。

HSM 不仅用于安全存储密钥，而且通常它们还可以执行加密操作，如签名、解密/加密等。

因此，根据您的 HSM 是否允许您这样做，设置一个只能使用密钥操作的“基本用户级别”和一个实际上可以访问密钥的“管理级别”。

这样一来，服务器将无法首先看到密钥，并且 HSM 将充当黑匣子。