我觉得我完全错过了Wildfly中新的JCEKS密钥库格式的要点。也许你可以纠正我的错误。
我们配置Wildfly的方式（例如，大部分互联网都指示我们这样做）：
- 我们将标准密钥存储条目放入一个带有密码（"jks_pw"）的标准Java密钥存储（"keystore.jks"）文件中
- 然后，我们创建一个JCEKS密钥库（"keystore.JCEKS"），其中包含密码、salt和循环计数（"JCEKS_s_n"）
- 然后，我们将"pks_pw"放入"keystore.jceks"
- 然后，我们将JCEKS密码/etc/（"JCEKS_s_n"）以纯文本形式添加到jboss-config（standalone.xml）中，定义一个条目
- 然后，我们将对存储在保险库中的JKS密码的引用添加到我们的jboss https连接器（standalone.xml）中，作为"password="$｛vault:：JKS::JKS:1｝"
这一切到底实现了什么？？？
如果我们只是使用一个JKS文件和一个嵌入standalone.xml中的密码，那么系统很容易受到的影响
- 攻击者获取standalone.xml和JKS文件的副本，在这种情况下，所有机密都是已知的
- 攻击者获取JKS文件的副本，在这种情况下，攻击者可以使用暴力或查找表攻击
如果我们以所描述的方式使用JCEKS容器，则系统易受以下因素影响：
- （SAME）攻击者获取standalone.xml，即JKS/JCEKS文件的副本，在这种情况下，所有机密都是已知的
- （SAME）攻击者获取JKS文件的副本，在这种情况下，攻击者可以使用暴力或查找表攻击
如果我们把实际的证书放在JCEKS文件中，这将是有意义的，在这种情况下，暴力和查找表攻击在第二种攻击情况下会更困难，但到目前为止，我还没有找到一种方法可以直接使用带有https连接器的JCEKS格式的密钥库。
真的，我非常关心这件事的唯一原因是，我们显然有使用"保险库"的安全要求，但这似乎毫无意义。
更新：值得注意的是，通过使用vault，您在jboss配置文件中使用了vault的"屏蔽"密码，但我不明白这意味着什么。显然，你的屏蔽密码+salt+轮次可以解锁JCEKS密钥库（源代码），所以我不确定屏蔽到底能实现什么。这似乎只是重定向的第三层。我一定是错过了什么。。。
JBoss指出"保险库"背后的安全机制是模糊的安全机制(https://developer.jboss.org/wiki/JBossAS7SecuringPasswords)
这有多安全？
- vault的默认实现使用Java KeyStore。它的配置使用基于密码的加密，这是一种隐蔽的安全性。这不是100%的安全性。它只解决了配置文件中明文密码的问题。总有一个薄弱环节。（正如mentallurg在评论中所建议的那样，密钥库密码是最薄弱的环节）
- 理想情况下，Vaults的第三方ISV稳健实现应提供必要的安全性
Vault使用未知密码，算法对密钥库密码执行对称加密。如果没有HSM，您将始终面临"数据源密码存储在哪里"的问题。因此，通常情况下，您会定义一个带有访问控制列表的属性文件，并将编码的密码存储在那里。
保险库只会增加获取安全密码的工作量，让攻击者要么读取内存中的密码，要么对保险库加密算法+密钥进行逆向工程。
重要的是要知道"保险库"背后的安全机制是模糊的安全机制，这意味着你只是在屏蔽敏感数据。这意味着，如果攻击者可以访问您的standalone.xml和密钥库，他可以轻松读取您的所有数据。vault"增加了努力"->攻击者不能直接看到它们，但需要付出一些（一点点）努力。