Database 如果我的服务器被盗，PostgreSQL数据库的安全性如何？

如果我的服务器上有一个PostgreSQL中的绝密数据数据库，而我的密码几乎不可能被猜到（128个字符的各种奇怪字符，由手工生成）。服务器密码实际上也是不可用的

除了猜测密码之外，从数据库中获取数据有多容易

假设：

服务器上只存在数据库。PHP脚本或类似的东西中没有密码

偷服务器的人是服务器/DB/硬盘恢复专家

我没有使用任何硬盘加密或任何超出标准的保护

我正在使用Ubuntu Hardy（最新稳定版本）

---

我试图了解某人物理访问我的服务器硬盘所涉及的风险。

标准的想法是，当有人坐在服务器旁时，这是一种妥协，故事结束了。如果他们抓起硬盘并把它带到实验室进行开放和分析，事情只会变得更糟

我将从整个驱动器加密以及数据库中的按字段加密开始。您可能会环顾四周，看看是否有一种方法可以对服务器上安装的硬盘硬件进行基于生物特征的访问。此外，您还希望找到一个物理安全承包商，并获得他们的配置建议；还雇佣警卫

我的意思是，如果这是一个可能合理发生的情况

编辑：

如果我有一个我想进入的Postgres DB文件，并且我有资源（例如，花费4K购买一些便宜的Dell），我会使用Beowulf配置并执行并行暴力破解。如果我开始有更多的钱，并且可以配置，比如说，在插入的台式机上配置一些可爱的NVidia超级计算机，以真正开始暴力强制输入密码，事情就会变得更糟

---

如果小偷真的想进入数据库，而您从第0天起就没有计划好安全措施，那么您的数据库文件将像沙丁鱼罐头一样打开。

我认为这不是问题PostgreSQL或任何其他数据库地址。即使数据库本身有密码保护，所有数据都是纯文本，这才是真正重要的。没有任何东西可以阻止攻击者对原始数据库文件进行分类，并通过字符串对其进行管道传输。针对此类攻击的最佳解决方案是使用加密文件系统。这将要求您键入密码以装载分区。这也增加了开销

如果你不加密硬盘/文件系统，那就太倒霉了，因为Postgres不提供本机加密。对硬盘进行加密是保护被盗服务器的唯一真正方法

基本上，您需要做的是加密硬盘驱动器或文件系统，并且每次机器启动时，在Postgres启动之前，您必须在装入驱动器时手动输入密码。

“标准的想法是，当有人坐在服务器旁时，它就被破坏了，故事结束了。如果他们抓住硬盘并将其带到实验室进行开放和分析，情况只会变得更糟。”

同上

一旦攻击者拥有永久的物理访问权限（即，他带着你的硬盘走出大楼，放在公文包里），问题就来了——假设数据会及时被泄露。从这里开始，情况就是延迟策略的成本与减慢攻击者速度的能力

如果攻击者是内幕人士，或者只有临时访问权限，则情况会有所不同。在这些情况下，您可能会让他放慢速度，或者强制追究责任，从而使攻击变得不可行

硬盘加密是一种延迟策略-它将提供与算法强度、密钥强度和密码强度相匹配的保护，以锁定对密钥的访问（或插入单独存储密钥的硬件的能力）。即使使用加密，也假设这是一种延迟策略。攻击者迟早会通过密钥空间，找出什么密钥解密系统

防篡改是另一种选择——在某些情况下（如从机箱中实际取出硬盘），找到一种以电子方式擦除硬盘的方法

请注意，一旦授予物理访问权限，攻击者就可以绕过您的密码（无论密码多么强大），而无需诉诸暴力。首先想到的是使用大多数系统内置的“修复密码”技术来帮助锁定和丢失密码的系统管理员

---

任何和所有的保护都是有价格的——防篡改是昂贵的，因为你需要特殊的硬件。加密可能更便宜，但它会影响启动时间。此外，我还看到了一些关于加密如何与应用程序一起使用的令人不快的惊喜——在你尝试使用它之前，你永远不会真正知道。

（也是我来寻找答案的那个），默认情况下，Postgresql存储未加密的表数据。查看…/pgsql/9.2/data/base/*中的文件，我猜这些表存储在1.1 GB的块中，我可以使用grep成功地在这些文件中找到ASCII字符串。通过检查文件，数据似乎存储在列中

根据这些信息，我相信我可以进行实验并编写代码，对表进行反向工程，以便在没有密码的服务器上创建副本

因此，如果您需要防范物理介质被盗的风险，仅依靠强大的数据库密码并不能满足您的注意义务

---

提供一些用于在不同级别加密数据的选项，对于此问题，这些选项似乎仅限于一个模块，用于加密特定列或以其他响应者建议的某种方式加密底层媒体。

一个良好的开端是启用全盘加密。 你也可以