【问题标题】:Hide private keys etc from administrators对管理员隐藏私钥等
【发布时间】:2012-08-30 15:41:23
【问题描述】:

目前我参与开发一个基于 Java EE(更准确地说是 WebLogic 服务器)的系统,我想知道如何保护一些私人数据免受管理员的侵害。例如,系统的某些部分将遗留系统的凭据以纯文本形式存储在部署描述符中,这很糟糕,因为部署者可以读取应用程序配置文件(例如ejb-jar.xml)并窃取强大帐户的用户名和密码。我想关闭这个安全漏洞,但不知道怎么做。

现在我对保护这类数据很感兴趣:

  1. 登录
  2. 密码
  3. 对称加密的私钥

来自here 我发现我可以使用JCEKS 密钥库来保护此类信息,但我不明白如何使用它。我的应用程序仍应包含 kestore 密码和访问它的密钥密码。因此,depoyer 可以窃取密钥库和密钥的密码,找到我的安全存储并窃取凭证。显然,我可以从部署者帐户中撤销read 权限,但随后他可以反编译我的应用程序并开发他自己的类似应用程序(或编辑我的应用程序),只需将安全数据打印到某个文件或通过电子邮件发送......现在我被卡住了......

谁能给我一些链接来解释如何保护系统免受管理员的侵害? Weblogic 相关链接将是可取的。我完全理解不可能保护所有管理员,应该有一些 security administrator 负责密钥库管理等,但我想保护所有敏感数据免受其他人的侵害。

结果

jtahlbornslim 的答案都是正确的,但 slims 的答案更有趣。我认为在我的情况下,只接受签名的应用程序安装在服务器上是合适的。这个决定可以解决管理员对应用程序进行修改的问题。管理员将拥有来自密钥库和所有密钥的密码,但他们根本无权访问密钥库文件。只有特殊的安全管理员 ('rw') 和服务器 ('r') 才能访问密钥库文件。因此,每个人都将拥有密钥,但没有人(安全管理员除外)可以访问该盒子。

【问题讨论】:

    标签: java security jakarta-ee weblogic administration


    【解决方案1】:

    除非您在应用程序启动时输入登录凭据,否则无法解决此问题(假设管理员无法访问应用程序内存,这可能不是一个安全的假设)。 任何解决方案涉及与应用程序位于同一位置的密钥将导致管理员(具有应用程序文件系统访问权限)能够访问应用程序可访问的任何敏感数据。这类似于 DRM 问题(您不能给某人一个上锁的盒子和钥匙,并期望他们无法打开盒子)。

    【讨论】:

    • +1 是的。即使您在系统启动时输入登录凭据,如果服务器应用程序可以访问该密钥,那么管理员也可以。您需要能够信任您的管理员。
    • @slim - 实际上,我纠正了这一点。我的意思是在 application 启动时。这为本地管理员提供了相当不错的安全性,除非管理员可以访问应用程序内存(这是可能的)。
    • Root当然可以访问应用内存。
    • @slim - 是的。在几乎任何操作系统上,如果您的管理员可以成为运行 java 应用程序的用户,您可以执行诸如触发堆转储之类的操作。
    【解决方案2】:

    我认为这个问题的核心在于“管理员”的定义。

    您曾说过,您对有权访问密钥存储的“安全管理员”感到满意。

    传统上,UNIX 类型将“admin”视为“root”用户——有权访问机器上所有内容的用户。 Root 几乎可以做任何事情,包括偷看和戳应用程序内存,或读取/写入原始磁盘地址。如果服务器可以得到私钥,那么root也可以。

    如果您想定义一个具有更有限访问权限的“管理员”角色,那么可以,您可以在此类用户存在的地方设置一些东西。他们需要比服务器应用程序本身拥有更少的权限,因为应用程序至少可以做一件“管理员”不能做的事情(获取私钥)。

    这样的用户也可能无法安装应用程序(因为如果可以,他们可以创建并安装公开私钥的应用程序版本)。因此,您的“管理员”无法部署与私钥一起使用的组件。但是,他们可能会部署一个在该容器内运行的模块(只要容器不能为该模块提供私钥)。

    但是,它不仅仅是您要保护的密钥。真正的“秘密”是使用密钥加密的数据。所以我们仍然对上面的方法有问题。如果模块可以读取加密数据,那么具有与模块相同权限的“管理员”也可以。这包括任何可以安装该模块的人。

    您可以研究对模块进行签名的方法,这样“管理员”就无法创建自己的版本。

    不过,有一点是,启用不可信管理员所需的措施比简单地使用可信管理员变得更加昂贵(在时间和精力方面)。

    因此,您需要列出您所谓的“管理员”可以做的事情。根据这些事情是什么,很可能允许非 root 用户执行这些事情。在 UNIX 上,您可以使用 sudo 之类的工具来允许非 root 用户执行启动/停止服务器、读取日志、清理日志等操作。

    【讨论】:

    • 注意,这个问题似乎暗示相关用户有能力“部署”应用程序。
    • 关于签署应用程序的好主意!我会考虑的。
    【解决方案3】:

    可以将身份验证与应用程序的其余部分分开。

    例如,如果您通过 TLS 安全套接字与旧系统进行通信,您可以编写一个小的独立应用程序,该应用程序接受来自应用程序的未加密连接,然后建立与旧系统的安全、经过身份验证的连接,然后泵应用程序和遗留系统之间的数据。本质上,它是一个身份验证代理。然后,应用程序将不需要这些密钥。您可以以无权读取包含密钥的文件的用户身份安装和操作该应用程序,但该应用程序仍然可以与旧系统通信。

    当然,现在您遇到了如何向代理验证应用程序的问题。您可能会觉得机器足够安全,您根本不需要这样做——只要代理只侦听环回接口即可。如果没有,如果您可以改用 unix 域套接字,那么您可以使用文件系统权限控制访问:您可以以某个特定组中的某个用户身份运行应用程序,然后将对该套接字的访问限制为该组的成员。 Java 在标准库中没有 unix 域套接字支持,但您可以使用 junixsocketJUDS 添加它。

    【讨论】:

    • 我认为这里的问题是我们的最终目标是保护机密数据免受“管理员”的侵害;私钥只是访问它的一种方式。您有一种方法可以让应用程序在不需要密钥的情况下获取数据......但是与应用程序具有相同权限的管理员也可以。其实这个反对意见也影响了我的回答,所以我补充一下。
    • 也许吧。这种方法就像给某人 sudo 而不是 root 访问权限。有可能限制他们可以做的事情,并撤销他们做这件事的能力。我想如果他们自己掌握了钥匙,这些事情会更难做。
    猜你喜欢
    • 2013-08-04
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-01-26
    • 2015-03-27
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多