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