即使在“野外”安装时，哪种 DBMS 适合保持模式私有？
我有一个连接到数据库服务器的应用程序服务器。 我希望能够为用户提供安装程序，并在一定程度上放心地相信数据库模式是安全的。
我知道，如果不控制安装它的计算机，我将不得不接受一些风险 - 一个拥有正确工具和知识的坚定的人可以直接查看内存并提取信息。
最初，我认为我的重点领域只是将凭据添加到安装程序，而无需在十六进制编辑器中轻松查看它们。
然而，当我开始研究时，我了解到对于 PostGreSQL，即使我静默安装数据库并且不向用户提供凭据 - 他们也可以简单地更改基于文本的配置文件（pg_hba.conf），并且重新启动服务器，无需凭据即可完全访问数据库。
这种情况在其他 DBMS 中是否安全？ 在这种情况下，大多数商业产品如何保护其架构？ 大多数产品都会使用嵌入式数据库吗？
编辑：我假设（可能是错误的）某些产品依赖于用户实际上从未直接接触过的数据库。 我当然从来没有见过他们，因为他们的设计方式是用户不需要的——可能使用嵌入式数据库。
I have an application server which connects to a database server. I would like to be able to supply users with installers and, with a moderate degree of comfort, trust that the database schema is secure.
I understand that there are some risks that I will just have to accept with not controlling the computer on which it installed - a determined person with the right tools and knowledge could look directly at memory and pull out information.
Initially I thought my area of focus would simply be on adding the credentials to the installer without them being trivially viewed in a hex editor.
However, as I began to research, I learned that for PostGreSQL, even if I install the database silently and don't provide the credentials to the user -- they can simply change a text-based configuration file (pg_hba.conf), and restart the server, enabling full access to the database without credentials.
Is this scenario secured in other DBMS? How do most commercial products protect their schemas in this scenario? Would most products use embedded databases?
Edit: I assume (perhaps wrongly so) that some products rely on databases that the user never actually touches directly. And I of course never see them because they have designed it in such a way that the user does not need to - probably using an embedded database.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
当某人可以物理访问运行此 DBMS 的计算机时，嵌入式 DBMS 如何阻止某人修改其存储（此非嵌入式硬件上下文中的文件）？ 通过模糊实现安全是一个有风险的主张。
How an embedded DBMS can stop someone to tinker with its storage (files in this non-embedded hardware context) when such person has physical access to the machine where this DBMS is running? Security through obscurity is a risky proposition.
这个想法将会遇到与 DRM 相同的问题。 您无法阻止有决心的人访问，并且只会给您的客户带来普遍的痛苦和折磨。 只是不要这样做。
SQLite 将其整个数据库格式包装到一个文件中，您可以想象就地对其进行加密和解密。 当然，缺陷在于用户现在需要密钥才能使用数据库，而唯一可能发生的方法就是将其提供给他们，也许是通过在编译时对其进行硬编码（通过模糊实现安全性）或电话家庭计划（有很多理由说明为什么这是一个坏主意）。 另外，现在他们会恨你，因为你挫败了任何有用的备份系统的尝试，并且他们的启动性能很糟糕。
此外，没有人真正关心模式。 我不想向您透露这一点，但模式设计并不是一个难题，当然也永远不会成为合法的竞争优势（除了知识表示和数据仓库等一些特定领域之外）。 模式通常从一开始就不值得保护。
如果这对您来说真的很重要，请改用托管应用程序。
This idea will suffer from the same problems as DRM. You can't prevent access by the determined, and you will only cause general pain and suffering for your customers. Just don't do it.
SQLite wraps its entire database format into a single file, and you could conceivably encrypt and decrypt it in-place. The flaw, of course, is that users need the key to use the database now, and the only way that can happen is if you give it to them, perhaps by hard-coding it in at compile-time (security by obscurity) or a phone-home scheme (whole host of reasons why this one's a bad idea). Plus now they'll hate you because you've thwarted any attempt at a useful backup system and they get terrible performance to boot.
Besides, nobody actually cares about schemas. Hate to break it to you, but schema design isn't a hard problem, and certainly never a legitimate competitive advantage (outside of maybe a few specific areas like knowledge representation and data warehousing). Schemas are generally not worth protecting in the first place.
If it's really that important to you, do a hosted application instead.
我不相信大多数商业产品会采取任何措施来保护其架构。
I don't believe most commercial products do anything to protect their schemas.
您想解决什么问题？ 没有什么可以阻止 DBA* 对标准数据库做任何他想做的事情，正如其他人指出的那样，它积极敌对地干扰特定于站点的需求，例如备份和数据库升级。 您最多可以加密数据库的内容，但即便如此，您也必须提供应用程序实际运行所需的解密密钥，并且有动机且充满敌意的 DBA 可能会破坏它。
毫无疑问，军事和情报界拥有数据库，甚至连模式都是高度机密的，但我不知道它们是受到技术手段的保护还是只是受持枪大人的保护。
(*) DBA 或系统管理员能够修改 pg_hba.conf 等文件。
What problem are you trying to solve? Nothing can stop the DBA* from doing whatever he wants to standard databases, and as others have pointed out it's actively hostile to interfere with site-specific needs like backups and database upgrades. At most you can encrypt the contents of your database, but even then you have to provide a decryption key for your application to actually run and a motivated and hostile DBA can probably subvert it.
The military and intelligence communities undoubtably have databases where even the schema is highly classified, but I don't know if they're protected by technical means or just large men with guns.
(*) DBA or system administrator able to modify files like pg_hba.conf.
大多数商业产品不保护其模式。 他们属于两个阵营之一：
要么他们将企业级数据库用于产品的关键组件（例如工资系统），在这种情况下，不会尝试隐藏架构/数据。 在大多数情况下，客户无论如何都需要控制数据库 - 配置数据库的备份方式、能够创建集群环境等。
另一种情况是，如果您的“数据库”只不过是一个小设置或桌面应用程序的存储文件（例如 FireFox 中的历史记录和书签数据库）。 在这种情况下，您应该只使用嵌入式数据库（例如 SQLite，与 FireFox 相同）并添加流加密层（有一个名为 SEE 的官方版本），或者只使用嵌入式数据库并忘记加密层，因为用户首先需要安装自己的数据库工具才能读取该文件。
Most commerical products do not protect their schemas. They fall into one of two camps:
Either they are making use of an enterprise class database for a key component of the product (such as a payroll system), in which case there is no attempt made to hide the schema/data. In most of these cases the customer needs control over the database anyway - to configure how the database is backed up, to be able to make a clustered environment, etc.
The other case is if your "database" is nothing but a small settings or storage file for a desktop application (ex. the history and bookmark databases in FireFox). In that case you should just use an embedded database (like SQLite, same as FireFox) and add a streaming encryption layer (there is an official version of this called SEE), or just use the embedded database and forget about the encryption layer, since the user will need to have to install their own database tools to read the file in the first place.
据我所知，没有任何商业产品可以“保护”其架构。 您希望架构受到什么保护？
请考虑以下几点：
毕竟，唯一可以保护 RDBMS 中任何内容的人是数据库服务器管理员。 您希望架构免受此人的攻击吗？
如果我是一名客户，并且我的架构中有我的数据，我不仅希望而且期望能够直接查看和使用它。
您真的需要保护您的关系设计吗？ 真的有那么有趣吗？ 你发明了一些值得隐藏的东西吗？ 我真的不这么认为。 如果您有的话，我提前表示歉意。
编辑：附加评论：
我不关心我使用的产品的大多数数据库内部结构。 这是我认为他们中的大多数人不采取任何行动来保护自己的另一个原因。 其中大多数都没有那么有趣。
一方面，我坚信用户不需要了解或关心数据库的内部结构。 但在同一层面上，作为开发人员，我认为不值得尝试保护它们。 对用户隐藏它们，是的。 保护它们不被直接访问，在大多数情况下，不会。 并不是因为我认为保护您的架构是错误的。 因为我认为这是一件非常难做的事情，而且不值得你作为一个开发者花时间。
但最终，与任何与安全相关的主题一样，唯一正确的答案是所涉及的风险与实施安全措施的成本。
当前的嵌入式或服务器风格的数据库引擎并不是为了轻松隐藏数据库模式而设计的，因此，对于大多数人来说，这样做的开发成本远远大于所涉及的风险。
但你的情况可能有所不同。
As far as I remember, there are no commercial products that "protect" their schemas. What do you want the schema to be protected against?
Consider the following points:
After all, the only person who can protect anything in a RDBMS is the database server administrator. And you want the schema to be protected against this person?
If I was a costumer and I had my data inside your schema, I would not only like, but expect, to be able to see and consume it directly.
Do you really need to protect your relational design? Is it really that interesting? Have you invented something worth hiding? I really don't think so. And I apologize in advance if you have.
EDIT: Additional comment:
I don't care about most database internals for the products I use. That's another reason I think most of them don't take any action to protect them. Most of them are not that interesting.
On one side, I strongly believe that users should not need to know or to care about the internals of the database. But at the same level, as a developer, I don't think it is worth trying to protect them. Hiding them from the user, yes. Protect them against direct access, in most cases, no. And not because I think it is wrong to protect your schema. It is because I think it is a very hard thing to do, and it is not worth your time as a developer.
But at the end, as with any security related topic, the only right answer is about what are the risks involved vs the costs of implementing the security measure.
Current database engines, embedded or server-style, are not designed to easily hide the schema of the database, and therefore, the development cost of doing it is much greater than the risk involved, for most people.
But your case might be different.