【问题标题】:How to protect encryption key from server admin?如何保护服务器管理员的加密密钥?
【发布时间】:2017-01-19 07:34:49
【问题描述】:

场景

  • 使用从未存储在应用服务器或数据库服务器中的密钥在数据库中对数据进行加密
  • 在登录时输入密钥并通过$_COOKIE['key'] 变量存储以保持持久性(因此用户不必在每次页面加载时都输入它)
  • 数据通过$_COOKIE['key']解密
  • $_COOKIE['key'] 在浏览器退出时被销毁

威胁

Rouge 服务器管理员窥探 PHP 文件,发现密钥存储在 $_COOKIE['key']。他注入了像email_me($_COOKIE['key']); 这样的恶意代码。他在获得密钥后清除了恶意代码。

问题

有没有办法保护自己免受这种情况的影响?

【问题讨论】:

  • 您可以在客户端执行解密。即服务器将返回您仍然加密的数据。

标签: php security encryption cryptography passwords


【解决方案1】:

您可以让服务器管理员更难获取密钥,但他们总是可以。

让我们考虑将加密和解密移动到客户端。现在,服务器将无法获取密钥,因此服务器管理员应该无法解密数据。这并不完全正确,因为服务器管理员可以操纵页面 JavaScript,以便将密钥发送到服务器或根本不加密任何内容。

客户端可以确定服务器管理员无法窃取其数据的唯一方法是使用开源且管理员无法即时更改的客户端软件。因此,网页和自动更新应用程序是不可能的。

【讨论】:

  • cannot be changed on-the-fly by an admin 如果管理员有 root 权限,这怎么可能?
  • 服务器管理员可以从内存中读取密钥(例如,如果您使用加密的循环设备),管理员可以重放(和修改)TCP 流以与任何客户端对话并伪造答案。
  • @IMB 正如我所说,这对于网页来说是无法避免的,但是在客户端机器上运行的实际应用程序通常会经过多个眼睛。当然,在这种情况下,构建应用程序的人可能会引入一些恶意代码。如果软件是开源的,并且构建管道会产生可重现的构建,那么您至少能够检测到对客户端代码的恶意操作。
  • @grochmal 理想情况下,数据在客户端上进行加密和解密,同时通过 MAC 验证进行完整性检查。客户端会检测到错误的响应(他们之前没有加密的东西)。当然,没有什么可以阻止由服务器管理员触发的拒绝服务。
  • @IMB 相信你的管理员,给他们丰厚的报酬,为SysAdmin day做点什么。
【解决方案2】:

如果密钥本身是一个问题,您可以使用像 Azure 中的 Keyvault 这样的加密预言机,它永远不会释放其中包含的密钥,而是自己对发送给它们的数据执行加密。

当然,只要管理员可以访问加密预言机,他们就可以访问数据,但之后就不行,而且他们永远不会拥有密钥。这在某些情况下会有所帮助,这就是 Azure Keyvault 等服务的全部意义所在。此外,您无需向所有管理员授予对加密服务的实际访问权限。

另一种缓解措施(检测性控制,而不是预防性控制)是 IT 和应用程序级别的审计日志记录。如果做得好,即使是管理员也无法隐藏他们访问数据的事实,这再次有助于降低一些风险,至少可以提供不可否认性。

您可以做的另一件事是适当的变更管理,控制谁有权访问(尤其是写访问)您的源代码。这对于 PHP 等脚本语言可能会变得很困难,因为您无法真正签署代码,但您仍然可以拥有良好的流程来审查代码并将其发布到生产环境中。

所以说到底,这可能不是一个技术问题,您可以在流程方面做很多事情。

【讨论】:

  • 管理员不会得到密钥,但会得到所有解密的数据。
  • 这是正确的,但只是以一种更受控、更审计、有时限的方式,这在某些情况下是显着的差异(而在其他情况下可能不是)。
  • 归结为应用程序用户天生信任“应用程序开发人员”的抽象概念。然而,这究竟意味着什么是非常重要的。我是否也天生信任开发公司的清洁人员,因为他们可以访问生产服务器并且根本没有逻辑访问控制?还是我只信任一小部分生产管理员,他们在受控、经过审计的环境中工作,并通过精心设计的流程来防止(内部)滥用?这会有所不同。
  • 我曾经在一家银行工作过,HSM(硬件加密)总是在星期四晚上关闭大约 20-30 分钟。原来,清洁工为了更好地清洁货架,拔掉了网线。星期四是服务器机房清洁日。
猜你喜欢
  • 1970-01-01
  • 2015-11-25
  • 1970-01-01
  • 2019-08-04
  • 1970-01-01
  • 2021-12-22
  • 2020-10-15
  • 2019-02-05
  • 1970-01-01
相关资源
最近更新 更多