目前我参与开发基于Java EE的系统（更准确地说是WebLogic服务器），我想知道如何保护管理员的一些私人数据。例如，系统的某些部分将部署描述符中遗留系统的凭据存储为纯文本，这很糟糕，因为部署者可以读取应用程序配置文件（例如ejb-jar.xml）并窃取强大帐户的用户名和密码。我想关闭这个安全漏洞，但不知道如何。
现在我有兴趣保护这类数据：
从here我发现我可以使用JCEKS密钥库来保护这类信息，但我无法理解如何使用它。我的应用程序仍应包含kestore密码和访问它的密钥密码。因此，depoyer可以窃取密钥库和密钥的密码，找到我的安全存储空间并窃取凭证。显然，我可以从部署者帐户撤销read权限，但随后他可以反编译我的应用程序并开发自己的类似应用程序（或编辑我的应用程序），只需将安全数据打印到某个文件或通过电子邮件发送。 ..现在我被卡住了......
有人可以给我一些链接，可以解释如何保护系统免受管理员的侵害吗？ Weblogic相关链接将更可取。我完全理解，不可能保护所有管理员，并且应该有一些security administrator负责密钥库管理等等，但我想保护所有其他人的敏感数据。
结果
jtahlborn 和苗条的答案都是正确的，但苗条的答案更有趣。我认为在我的情况下，只接受已签名的应用程序以便在服务器上安装。这个decidion可以解决管理员进行修改的问题。管理员将拥有密钥库和所有密钥的密码，但他们根本无法访问密钥库文件。访问密钥库文件将只有特殊的安全管理员（'rw'）和服务器（'r'）。所以，每个人都有密钥，但没有人（安全管理员除外）可以访问该框。
答案 0 :(得分：6)
除非您在应用程序启动时输入登录凭据（假设管理员无法访问应用程序内存，这可能不是一个安全的假设），否则无法解决此问题。 任何解决方案，其中涉及与应用程序位于同一位置的密钥将导致管理员（具有应用程序文件系统访问权限）能够访问应用程序可访问的任何敏感数据。这类似于DRM问题（您不能给某人一个锁定的框和密钥，并期望他们无法打开该框）。
答案 1 :(得分：3)
我认为这个问题的核心在于“admin”的定义。
您已经说过，您对能够访问密钥库的“安全管理员”感到满意。
传统上，UNIX类型将“admin”视为“root”用户 - 有权访问计算机上所有内容的用户。 Root可以做任何事情，直到偷看和戳戳应用程序内存，或读取/写入原始磁盘地址。如果服务器可以获得私钥，那么root就可以了。
如果您想要定义具有更多限制访问权限的“管理员”角色，那么您可以设置存在此类用户的内容。他们需要的权限少于服务器应用程序本身，因为应用程序至少可以执行一项“管理员”无法执行的操作（获取私钥）。
这样的用户可能无法安装应用程序（因为如果可以的话，他们可以创建并安装暴露私钥的应用程序版本）。因此，您的“admin”无法部署使用私钥的组件。但是，它们可能会部署在该容器内运行的模块（只要容器无法将私钥提供给模块）。
但是，它不仅仅是您想要保护的密钥。真正的“秘密”是使用密钥加密的数据。所以我们仍然遇到上述方法的问题。如果模块可以读取加密数据，那么“admin”具有与模块相同的权限。这包括任何可以安装模块的人。
您可以调查对模块进行签名的方法，以便“管理员”无法创建自己的版本。
但是，有一点需要支持不值得信任的管理员所需的措施，而不是仅仅使用值得信赖的管理员，就会变得更加昂贵（在时间和精力方面）。所以，你需要列出你所谓的“管理员”可以做的事情。根据这些内容的不同，很可能允许非root用户执行这些操作。在UNIX上，您可以使用sudo之类的工具来允许非root用户执行诸如启动/停止服务器，读取日志，清理日志等操作。
答案 2 :(得分：1)
可以将身份验证与应用程序的其余部分分开。
例如，如果您通过TLS安全套接字与旧系统进行通信，则可以编写一个小型独立应用程序，该应用程序接受来自应用程序的未加密连接，然后与旧系统进行安全，经过身份验证的连接，以及泵应用程序和遗留系统之间的数据。从本质上讲，它是一个身份验证代理。然后，应用程序将不需要这些密钥。您可以以无权读取包含密钥的文件的用户身份安装和运行应用程序，但应用程序仍可以与旧系统进行通信。
当然，现在您遇到了如何向代理验证应用程序的问题。您可能觉得机器足够安全，根本不需要这样做 - 只要代理只侦听环回接口。如果没有，如果您可以使用unix域套接字，那么您可以使用文件系统权限来控制访问：您可以将应用程序作为某个特定组中的某个用户运行，然后将该套接字的访问权限限制为该组的成员。 Java在标准库中没有unix域套接字支持，但您可以使用junixsocket或JUDS添加它。