安全数据中心的服务器上的全盘加密毫无意义吗?

信息安全 加密 linux 磁盘加密 dm-crypt
2021-08-18 15:57:37

我正在与几个人就全盘加密提供多少保护进行辩论。 dm-crypt正在用于加密我的公司要求在静态时加密的数据。托管数据的 Linux 服务器驻留在安全的数据中心内,未经授权的物理访问风险很小,更不用说有人实际窃取服务器了。

我的论点是,在这种情况下,在遵守法律条文的同时,他们几乎没有采取任何行动来实际降低与未加密数据相关的风险。实际上,从逻辑的角度来看,它们与根本没有实施加密的情况完全相同。我很好奇,如果这一系列的想法是正确的,想法?

为了使问题更适合我的具体情况,关于人身保护,周围的控制通常非常健全。我并不是说风险被消除了,但它被认为是低的。与处理驱动器一样,销毁控制运行非常有效,风险被认为很低。从逻辑访问的角度来看,服务器面向 Internet,位于防火墙后面,逻辑访问受到良好控制(但许多人可以访问),并且它们没有被虚拟化。此外,服务器 24x7 运行,它们唯一的重新启动时间是在更改后或安装新服务器期间需要它。

我担心的是,如果内部人员流氓,或者未经授权的用户利用逻辑安全漏洞,那么与使用其他一些可用的字段或文件级加密工具相比,完整的数据加密无法保护数据。而我正在辩论的人认为情况并非如此。

4个回答

您显然错过了两件通用的事情:

  • 在磁盘故障的情况下,对静态数据进行加密可以解决在您无法再访问的媒体上存在潜在敏感数据的问题。它使处理有故障的驱动器变得更容易、更便宜(而且问题更少)

  • 全盘加密还使攻击者更难从驱动器上的“空白”空间(通常包含以前有效数据的痕迹)中检索数据

如果您使用的是虚拟机:

  • 加密分区可以减少对管理程序安全性的依赖:如果某个驱动器的原始内容以某种方式“泄漏”到另一个 VM(如果将驱动器空间重新分配给另一个 VM 并且没有清零,则可能发生这种情况),那VM 将不太可能访问实际数据(它还需要获取解密密钥)。

如果解密密钥与加密数据以明文形式存储在同一媒体上,则加密毫无意义。如果您有一组规则,要求对数据进行加密,但允许将密钥以明文形式存储在同一媒体上,那么这些规则就有缺陷。如果你遇到过这样一套有缺陷的规则,你应该指出这个缺陷。

如果密钥未与数据存储在同一介质上。那么加密确实是有目的的。然而,这确实引发了关于服务器在启动时从何处获取密钥的问题。有几个选项:

  • 需要在引导过程中输入密码。这对于服务器来说不是很实用。
  • 从密钥服务器获取解密密钥。如果服务器被盗,这可以防止数据被解密,它只需要密钥服务器只响应来自数据中心内的请求。
  • Secret 跨多个磁盘共享密钥。对于服务器被盗的情况不做任何事情。但是,如果您有一个偶尔更换单个磁盘的 RAID,它可以保证保留在保修期内退回的磁盘上的任何数据都经过正确加密。将新磁盘添加到 RAID 时,此技术的实现必须执行以下操作:
    • 为这个单独的磁盘生成一个加密密钥。
    • 生成新的主密钥。
    • Secret 在所有磁盘上共享新的主密钥。
    • 在每个磁盘上写入在新主密钥下加密的磁盘加密密钥。

上述三种方法可以结合使用。如果将它们结合起来,则可以使用盲 RSA 来实现密钥服务器。

存在对硬盘固件的攻击。谷歌搜索hard drive firmware attack会返回一些关于 NSA 做了什么或能做什么的结果,这可能与你不太相关;但即使是爱好者也可以修改驱动器的固件。这家伙甚至在他的硬盘上安装了一个 linux 内核——不,运行 linux 的不是 PC,而是硬盘控制器本身。

如果有人获得了对您磁盘固件的访问权限(例如,有人从您的数据中心租了一台服务器一个月,然后将其归还;数据中心公司擦除了驱动器,然后将该服务器分配给您),他们可能拥有驱动器固件执行类似“每当写入磁盘的块包含特殊模式时,在接下来的 5 分钟内,在每个root:$1$以几乎检测不到。您的/etc/shadow文件对您来说看起来很正常,除非在您的攻击者从您的 Web 服务器请求一个名称包含触发模式的文件后的 5 分钟时间窗口内,该文件将其写入其错误日志。

不太可能?当然。不可能的?当然不。假设这可能发生是偏执狂吗?可能是的,这取决于您的数据有多有趣。但是,加密你的驱动器可以保护你免受这种攻击,而且除了几个 cpu 周期外,它不会花费你任何东西。而且,如果有任何法律或法规要遵循,在发生安全漏洞的情况下,我当然不想解释为什么我认为这无关紧要。

考虑一下您所说的“安全”数据中心是什么意思。

一般来说,我不认为任何东西对坚定且资源充足的攻击者都是安全的。诚然,拥有 18 英寸的钢筋混凝土、双重人员陷阱和武装保安可以提供相当多的保护,但这种保护很少只适合您。在大多数托管设施中,唯一能保护您免受拥有 500 美元和足够知识的人可以在与您相同的设施中租用机架空间,这是一个带有三针不倒翁的可疑安全铁丝笼。

偶尔,自然和人为的灾难会导致洪水泛滥、断电、毒害供水以及做各种不寻常的事情,导致保安人员和技术人员不上班或回家与家人团聚——我的意思是是数据中心只提供了可能没有许多客户想象的那么高的安全级别。

重新考虑您对处置承包商丢失驱动器的低风险的立场。

销毁证书也使您有权......您支付给他们的 20 美元用于销毁实际上并未被销毁的驱动器?

您参观过您的驱动器处置设施吗?检查他们的招聘程序?看到他们的保障了吗?确保你在这方面坚如磐石,因为它是最明显的漏洞之一——监护权的改变。

所以,这根本不是你问的,你实际问的内部威胁怎么样。

好的,内部人员可以通过您的 FDE 访问并看到未加密的文件。在您的 FDE 场景中,它不会阻止或减缓内部人员获取数据的速度。

它会做的是让你的内部威胁通过你的 FDE,这将允许你记录、监控和识别罪魁祸首,或者至少是嫌疑人。能够识别您的攻击者是一个安全层。

但是,我很确定漏斗不是 FDE 的主要用途。即使您确实有 FDE,您仍然可以在 FDE 之上实现另一个文件级或其他数据加密。您仍然可以使用操作系统的访问控制。

FDE 可防止无法通过 FDE 访问的内部人员。它可以防止服务器技术人员更换驱动器并拿走数据。它可以防止服务器设施的员工从您设施的运输容器中提取一个等待运输给您的销毁承包商的设备。

FDE 还允许您在另一个级别阻止内部威胁,如果您隔离您的场或使用细粒度访问 - 假设您的内部人员只能访问某些服务器等。FDE 将阻止他们简单地复制他们没有的驱动器通过 FDE 访问。

简而言之,FDE 保护驱动器上的数据不被物理访问。您可以尝试尽可能多地控制物理访问,但驱动器总是会发现自己存在一些漏洞(被内部人员窃取、被内部人员复制、在内部人员接触的地方转移监管、因灾难而无人看管等)。如果人们接触到驱动器,FDE 就是对它的防御层。

大卫