如果我的服务器被盗，PostgreSQL 数据库的安全性如何？
如果我有一台服务器，其中包含 PostgreSQL 中的绝密数据数据库，并且我的密码几乎不可能被猜到（由各种奇怪字符组成的 128 个字符串，由手工生成）。服务器密码实际上也是无法猜测的。
除了猜测密码之外，从该数据库中获取数据有多容易？
假设：
- 服务器上仅存在数据库。 PHP 脚本或类似内容中没有密码
- 窃取服务器的人是服务器/数据库/硬盘驱动器恢复专家
- 我没有使用任何硬盘驱动器加密或任何不符合标准的保护措施
- 我使用 Ubuntu Hardy（最新稳定版本），
我试图了解有人物理访问我的服务器硬盘所涉及的风险。
If I have a server with a database of top secret data in PostgreSQL and my password is practically impossible to guess (128 character string of all sorts of weird chars, generated by hand). The server password is also practically unguessable.
Aside from a password guessing, how easy is it to get the data out of this database?
Assumptions:
- Only the DB exists on the server. There is no password in a PHP script or anything like that
- The person who stole the server is a server / DB / hard-drive recovery expert
- I'm not using any hard-drive encryption or anything out of the norm for protection
- I'm using Ubuntu Hardy (latest stable version)
I'm trying to understand the risks involved with somebody gaining physical access to my server's hard-drives.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
“标准的想法是，当有人坐在服务器上时，服务器就受到了损害，故事就结束了。如果他们抓住硬盘并将其带到实验室进行打开和分析，事情只会变得更糟。”
同上。
一旦攻击者拥有永久的物理访问权限（即，他将您的硬盘放在公文包中走出大楼），一切就都完成了——假设数据最终会受到损害。从这里开始，场景就是延迟策略的成本与减缓攻击者速度的能力。
如果攻击者是内部人员或仅具有临时访问权限，情况会略有不同。在这些情况下，你也许能够足够减慢他的速度，或者强制追究责任，使攻击变得不可行。
硬盘驱动器加密是一种延迟策略 - 它将提供与算法强度、密钥强度以及锁定密钥访问的密码强度（或插入单独存储密钥的硬件的能力）相匹配的保护。即使使用加密，人们也认为这是一种拖延策略。攻击者迟早会通过密钥空间并找出可以解密系统的密钥。
防篡改是另一种选择 - 找到一种在某些条件下以电子方式擦除硬盘驱动器的方法（例如将其从机箱中物理移除）。
想象一下，一旦授予物理访问权限，攻击者就可以绕过您的密码（无论密码有多强），而无需诉诸暴力。我想到的第一个方法是使用大多数系统内置的“修复密码”技术来帮助已锁定和恢复的系统管理员。丢失密码。
任何和所有的保护都是有代价的——防篡改是昂贵的，因为你需要特殊的硬件。加密可以更便宜，但会影响启动时间。另外，我还看到了加密如何与应用程序一起发挥作用的一些令人讨厌的惊喜 - 除非您尝试使用它，否则您永远不会真正知道。
"The standard thought is when someone sits down at the server, it's compromised, end of story. Things only get worse if they grab the hard drive and take it to a lab for opening up and analysis."
Ditto.
Once an attacker has permanent physical access (i.e., he walked out of the building with your hard drive in his briefcase), the jig is up - assume that in time the data will be compromised. From there, the scenario is the cost of the delaying tactic vs. the ability to slow down the attacker.
It's a little different if the attacker is an insider, or had only temporary access. In those cases, you might be able to slow him down enough, or force accountability such that the attack becomes infeasible.
Hard drive encryption is a delaying tactic - it will give protection that matches the strength of the algorithm, strength of the key, and strength of the password locking access to the key (or the ability to insert hardware with the key stored separately). Even with encryption the assumption is that it's a delaying tactic. Sooner or later, the attacker will get through the key space and figure out what key decrypts the system.
Tamperproofing is another option - finding a way to electronically erase the hard drive under certain conditions (like physically removing it from the case).
Figure that once physical access is granted, the attacker can work around your passwords - however strong they are - without resorting to brute force. The first one that comes to mind is using the "fix the password" techniques that most systems have built in to help sys admins that have locked out & lost passwords.
Any and all protections come with a price - tamperproofing is expensive, since you need speciality hardware. Encryption can be cheaper, but it affects boot time. Also, I've seen some nasty surprises with how encryption plays with applications - you never really know until you try to use it.
标准的想法是，当有人坐在服务器上时，服务器就被入侵了，故事就结束了。如果他们抓住硬盘并将其带到实验室进行打开和分析，事情只会变得更糟。
我将从整个驱动器加密以及数据库中的每个字段加密开始。您可能会环顾四周，看看是否有一种方法可以对服务器上安装的硬盘驱动器硬件进行基于生物识别的访问。此外，您还想找到一个物理安全承包商并获取他们的配置建议；还雇佣警卫。
我的意思是，如果这是一个可能合理发生的场景...
编辑：
如果我有一个我想要进入的 Postgres DB 文件并且我有资源（即花费 4K 购买一些便宜的戴尔），我会使用 Beowulf配置并执行并行暴力破解。如果我开始拥有更多的钱并且可以配置几台插入的 NVidia 桌面超级计算机来真正开始暴力破解密码，事情就会变得更糟。
如果小偷确实想要进入它，并且您没有从第 0 天开始就计划好安全措施，那么您的数据库文件将像沙丁鱼罐头一样被打开。
The standard thought is when someone sits down at the server, it's compromised, end of story. Things only get worse if they grab the hard drive and take it to a lab for opening up and analysis.
I would begin with whole-drive encryption, as well as per-field encryption in the database. You might look around to see if there is a way to have a biometric-based access to the hard drive hardware installed on the server. Also, you want to dig up a physical security contractor and get their recommendations for configuration; also hire guards.
I mean, if this is a scenario that might reasonably happen...
edit:
If I had a Postgres DB file I wanted to get into and I had the resources (ie, spending 4K for some cheap Dells), I would use a Beowulf configuration and perform parallel brute-force cracking. Things get worse if I start to have more money and can configure, say, several of those sweet NVidia supercomputer-on-desktop machines plugged in to really start brute-forcing a password.
If the thief is serious about getting into it and you don't have security already planned from Day 0, your DB file is going to be opened like a sardine can.
如果您不加密硬盘驱动器/文件系统，那么您就很不走运，因为 Postgres 不提供本机加密。加密硬盘驱动器是保护被盗服务器的唯一真正方法。
基本上，您需要做的是加密硬盘驱动器或文件系统，并且在每次机器启动、Postgres 启动之前安装驱动器时，您都必须手动输入密码。
If you're not encrypting the hard drive/file system, you're pretty much out of luck, as Postgres doesn't offer native encryption. And encrypting the hard drive is the only real method of protection for a stolen server.
Basically, what you would need to do is encrypt the hard drive or filesystem, AND you would have to enter the password when you mount the drive, by hand, each time the machine starts, before Postgres fires up.
我不认为这是 PostgreSQL 或任何其他数据库地址的问题。即使数据库本身受到密码保护，所有数据都是纯文本形式，这才是真正重要的。没有什么可以阻止攻击者捕获原始数据库文件并通过字符串进行管道传输。针对此类攻击的最佳解决方案是使用加密的文件系统。这将要求您输入密码来安装分区。这也增加了开销。
I don't think this is a problem PostgreSQL, or any other database addresses. Even if the database its self is password protected all of the data is in plain text and thats what really matters. Nothing is stopping the attacker from cat'ing the raw database file and piping it though strings. The best solution for this type of attack is to use an encrypted file system. This would require you to type in a password to mount the partition. This also increases overhead.
对于发布的具体问题（以及我来寻找答案的问题），Postgresql 默认情况下存储未加密的表数据。环顾 .../pgsql/9.2/data/base/* 中的文件，我猜测这些表存储在 1.1 GB 块中，并且我可以使用 grep 在这些文件中成功找到 ASCII 字符串。通过检查文件可以看出，数据存储在列中。
根据这些信息，我相信我可以尝试并编写代码来对表进行逆向工程，以在我没有密码的服务器上创建副本。
因此，如果您需要防范物理介质被盗的风险，仅依靠强数据库密码并不能满足您的注意义务。
PostgreSQL 在线文档 提供用于在各个级别加密数据的一些选项，对于这个问题，这些选项似乎仅限于用于加密特定列或以某种方式加密底层媒体的模块，正如其他受访者所建议的那样。
For the specific question posted (and the one I came searching for an answer to), Postgresql by default stores table data unencrypted. Looking around in files in .../pgsql/9.2/data/base/* I would guess that these store tables in 1.1 gigabyte chunks, and I can successfully find ASCII strings in those files with grep. From inspection of the files it appears that the data is stored in columns.
From this information I believe that I could experiment and write code to reverse-engineer the tables to create a copy on a server which I do not have the password for.
Therefore relying on a strong database password alone does not meet your duty of care if you need to protect against the risk of the physical media being stolen.
PostgreSQL online docs provide some options for encrypting data at various levels, which for this problem seem to be limited to a module for encrypting specific columns or encrypting the underlying media in some way as other respondents have suggested.
一个好的开始是启用全盘加密。
您还可以在应用程序层进行加密。 （例如，在将数据发送到数据库之前对其进行加密，存储无法从数据库服务器访问的密钥）
A good start is to enable full disk encryption.
You can also encrypt at the application layer. (e.g. encrypt data before you send it to the database, store the key not accessible from the database server)