如果我的服务器在 PostgreSQL 中有一个绝密数据数据库,而我的密码实际上是不可能猜到的(128 个各种奇怪字符的字符串,手工生成)。服务器密码实际上也无法猜测。
除了猜测密码之外,从这个数据库中获取数据有多容易?
假设:
- 服务器上只存在数据库。PHP脚本中没有密码或类似的东西
- 偷服务器的人是服务器/数据库/硬盘恢复专家
- 我没有使用任何硬盘加密或任何不规范的保护措施
- 我正在使用 Ubuntu Hardy(最新稳定版本)
我试图了解某人物理访问我的服务器硬盘驱动器所涉及的风险。
如果我的服务器在 PostgreSQL 中有一个绝密数据数据库,而我的密码实际上是不可能猜到的(128 个各种奇怪字符的字符串,手工生成)。服务器密码实际上也无法猜测。
除了猜测密码之外,从这个数据库中获取数据有多容易?
我试图了解某人物理访问我的服务器硬盘驱动器所涉及的风险。
“标准的想法是,当有人坐在服务器上时,它就被攻破了,故事就结束了。如果他们拿起硬盘驱动器并将其带到实验室进行开放和分析,情况只会变得更糟。”
同上。
一旦攻击者拥有永久的物理访问权限(即,他带着公文包中的硬盘走出大楼),夹具就起来了 - 假设数据会及时受到损害。从那里开始,场景是延迟策略的成本与减缓攻击者的能力。
如果攻击者是内部人员,或者只有临时访问权限,情况会有所不同。在这些情况下,您可能能够让他足够慢,或者强制问责,以使攻击变得不可行。
硬盘加密是一种延迟策略——它将提供与算法强度、密钥强度和密码锁定访问密钥强度相匹配的保护(或插入硬件并单独存储密钥的能力)。即使使用加密,也假设它是一种延迟策略。迟早,攻击者将通过密钥空间并找出解密系统的密钥。
防篡改是另一种选择 - 找到一种在某些条件下以电子方式擦除硬盘驱动器的方法(例如将其从机箱中物理移除)。
假设一旦授予物理访问权限,攻击者就可以绕过您的密码——无论它们有多强——而无需诉诸暴力。首先想到的是使用大多数系统内置的“修复密码”技术来帮助锁定和丢失密码的系统管理员。
任何和所有的保护都是有代价的——防篡改是昂贵的,因为你需要特殊的硬件。加密可能更便宜,但它会影响启动时间。此外,我还看到了加密如何与应用程序一起玩的一些令人讨厌的惊喜——除非你尝试使用它,否则你永远不会真正知道。
标准的想法是当有人坐在服务器上时,它就被攻陷了,故事就结束了。如果他们抓住硬盘驱动器并将其带到实验室进行打开和分析,情况只会变得更糟。
我将从整个驱动器加密以及数据库中的每个字段加密开始。您可能会环顾四周,看看是否有一种方法可以对安装在服务器上的硬盘驱动器硬件进行基于生物特征的访问。此外,您想找到一个物理安全承包商并获得他们的配置建议;还雇了警卫。
我的意思是,如果这是一个可能合理发生的场景......
编辑:
如果我有一个我想进入的 Postgres DB 文件并且我有资源(即,花费 4K 购买一些便宜的戴尔),我会使用 Beowulf 配置并执行并行蛮力破解。如果我开始有更多的钱,并且可以配置几台可爱的 NVidia 桌面超级计算机,以真正开始暴力破解密码,情况会变得更糟。
如果小偷很想进入它,而您从第 0 天起就没有计划好安全措施,那么您的数据库文件将像沙丁鱼罐头一样被打开。
如果您没有加密硬盘驱动器/文件系统,那么您就很不走运了,因为 Postgres 不提供本机加密。加密硬盘驱动器是保护被盗服务器的唯一真正方法。
基本上,您需要做的是加密硬盘驱动器或文件系统,并且您必须在安装驱动器时手动输入密码,每次机器启动时,在 Postgres 启动之前。
我不认为这是 PostgreSQL 或任何其他数据库地址的问题。即使数据库本身是受密码保护的,所有数据都是纯文本的,这才是真正重要的。没有什么可以阻止攻击者对原始数据库文件进行分类并将其通过字符串传输。此类攻击的最佳解决方案是使用加密文件系统。这将要求您输入密码来挂载分区。这也增加了开销。
对于发布的特定问题(以及我来寻找答案的问题),Postgresql 默认存储未加密的表数据。查看 .../pgsql/9.2/data/base/* 中的文件,我猜这些存储表是 1.1 GB 的块,我可以使用 grep 在这些文件中成功找到 ASCII 字符串。通过检查文件,数据似乎存储在列中。
根据这些信息,我相信我可以试验并编写代码来对表进行逆向工程,以在我没有密码的服务器上创建一个副本。
因此,如果您需要防止物理媒体被盗的风险,仅依靠强大的数据库密码并不能满足您的注意义务。
PostgreSQL 在线文档提供了一些用于在各个级别加密数据的选项,对于这个问题,这些选项似乎仅限于用于加密特定列或以某种方式加密底层媒体的模块,正如其他受访者所建议的那样。
一个好的开始是启用全盘加密。您还可以在应用层进行加密。(例如,在将数据发送到数据库之前加密数据,存储无法从数据库服务器访问的密钥)