我有一个连接到数据库服务器的应用程序服务器。我希望能够为用户提供安装程序，并以适度的舒适度相信数据库架构是安全的。
我知道，如果不控制安装它的计算机，我将不得不接受一些风险——一个拥有正确工具和知识的坚定的人可以直接查看内存并提取信息。
最初，我认为我的重点领域只是将凭据添加到安装程序，而无需在十六进制编辑器中轻松查看它们。
然而，当我开始研究时，我了解到对于 PostGreSQL，即使我静默安装数据库并且不向用户提供凭据——他们也可以简单地更改基于文本的配置文件 (pg_hba.conf)，并且重新启动服务器，无需凭据即可完全访问数据库。
这种情况在其他 DBMS 中是否安全？在这种情况下，大多数商业产品如何保护它们的模式？大多数产品会使用嵌入式数据库吗？
编辑：我假设（也许是错误的）某些产品依赖于用户从未真正直接接触过的数据库。我当然从来没有见过他们，因为他们以用户不需要的方式设计了它 - 可能使用嵌入式数据库。
据我记得，没有商业产品可以“保护”他们的模式。您希望保护架构免受什么影响？
考虑以下几点：
毕竟，唯一可以保护 RDBMS 中任何内容的人是数据库服务器管理员。并且您希望架构免受此人的侵害？
如果我是一名客户并且我的数据包含在您的架构中，我不仅希望而且希望能够直接查看和使用它。
你真的需要保护你的关系设计吗？真的那么有趣吗？你有没有发明一些值得隐藏的东西？我真的不这么认为。如果你有的话，我提前道歉。
编辑：附加评论：
我不关心我使用的产品的大多数数据库内部结构。这是我认为他们中的大多数人没有采取任何行动保护他们的另一个原因。他们中的大多数都不是那么有趣。
一方面，我坚信用户不需要知道或关心数据库的内部结构。但在同一级别，作为开发人员，我认为不值得尝试保护他们。对用户隐藏它们，是的。保护它们免受直接访问，在大多数情况下，不会。并不是因为我认为保护您的架构是错误的。这是因为我认为这是一件非常困难的事情，不值得你作为开发人员花时间。
但最后，与任何与安全相关的话题一样，唯一正确的答案是所涉及的风险与实施安全措施的成本是什么。
当前的数据库引擎，无论是嵌入式的还是服务器式的，都不能轻易地隐藏数据库的模式，因此，对于大多数人来说，这样做的开发成本要比所涉及的风险大得多。
但你的情况可能不同。
大多数商业产品不保护它们的模式。他们属于两个阵营之一：
他们要么将企业级数据库用于产品的关键组件（例如工资系统），在这种情况下，不会尝试隐藏模式/数据。在大多数情况下，客户无论如何都需要控制数据库 - 配置数据库的备份方式，能够创建集群环境等。
另一种情况是，如果您的“数据库”只是桌面应用程序的一个小设置或存储文件（例如 FireFox 中的历史和书签数据库）。在这种情况下，您应该只使用嵌入式数据库（如 SQLite，与 FireFox 相同）并添加流式加密层（有一个名为 SEE 的官方版本），或者只使用嵌入式数据库而忘记加密层，因为用户首先需要安装自己的数据库工具才能读取文件。
你想解决什么问题？没有什么可以阻止 DBA* 对标准数据库做任何他想做的事情，正如其他人指出的那样，干扰特定站点的需求（如备份和数据库升级）是非常不利的。您最多可以加密数据库的内容，但即便如此，您也必须为您的应用程序实际运行提供一个解密密钥，而一个积极而充满敌意的 DBA 可能会破坏它。
毫无疑问，军事和情报界拥有数据库，其中甚至架构都是高度机密的，但我不知道他们是否受到技术手段的保护，或者只是拥有枪支的大个子。
(*) DBA 或系统管理员能够修改 pg_hba.conf 等文件。
在这种情况下，大多数商业产品如何保护它们的模式？
我不相信大多数商业产品会做任何事情来保护他们的模式。
当某人可以物理访问运行此 DBMS 的机器时，嵌入式 DBMS 如何阻止某人修改其存储（此非嵌入式硬件上下文中的文件）？通过默默无闻的安全是一个冒险的提议。
这个想法将遭受与 DRM 相同的问题。您无法阻止有决心的人访问，您只会给您的客户带来普遍的痛苦和痛苦。只是不要这样做。
SQLite 将其整个数据库格式包装到一个文件中，您可以想象就地加密和解密它。当然，缺陷是用户现在需要密钥才能使用数据库，而唯一可能发生的方法是如果您将其提供给他们，可能是通过在编译时将其硬编码（通过默默无闻的安全性）或电话回家计划（这是一个坏主意的全部原因）。另外，现在他们会恨你，因为你挫败了任何有用的备份系统的尝试，而且他们的启动性能很差。
此外，没有人真正关心模式。讨厌打破它，但模式设计不是一个难题，当然也绝不是合法的竞争优势（除了知识表示和数据仓库等一些特定领域之外）。首先，模式通常不值得保护。
如果它对您来说真的那么重要，请改为使用托管应用程序。