小编Chr*_*ers的帖子

首先介绍一下背景。

LedgerSMB 项目是一个在 PostgreSQL 上运行的开源财务会计软件项目。我们在用户定义的函数中实现了大量的业务逻辑，它们充当程序对象方法和数据库行为之间的主要映射工具。目前我们使用数据库用户作为身份验证用户，部分是出于选择（这允许集中的安全逻辑，以便可以编写其他工具并重用授予用户的权限），部分是必要的（在我们从 SQL-Ledger 分叉之后，有用于在该代码库上改进安全性的选项并不多）。

这让我们可以访问 PostgreSQL 可以访问的合理数量的单点登录选项，从 LDAP 到 Kerberos 5。我们甚至可以在涉及密码的地方使用 PAM。它还允许我们在与其他应用程序集成或允许其他客户端界面时重用权限。对于财务会计应用程序来说，这似乎是一场胜利。

有明显的成本。对于 Web 应用程序，我们可以支持的 http 身份验证类型非常有限。例如，DIGEST 完全出局了。BASIC 可以工作，我们可以很容易地实现 KRB5（我计划支持它并在 1.4 中开箱即用）。非常强大的身份验证措施无法直接对此进行适当管理，尽管我们可能会在必要时将它们填充（例如 BASIC + 客户端 SSL 证书，其 cn 与用户名和特定的根 ca 匹配）。

与此同时，我们遇到了相当多的批评，主要来自开发人员，偶尔来自 dba 的批评，他们告诉我应用程序应该是安全屏障，而不是数据库。我的观点仍然是，较小的安全边界通常更好，业务逻辑和安全逻辑的重用是相辅相成的，我觉得重用业务逻辑而不在同一级别重用安全逻辑是危险的的程序。

我在这里错过了任何主要的权衡吗？有没有我没有考虑的问题？

我正在使用 PostgreSQL，但我认为大多数高端数据库必须具有一些类似的功能，而且，它们的解决方案可能会启发我的解决方案，所以不要考虑这个特定于 PostgreSQL 的解决方案。

我知道我不是第一个尝试解决这个问题的人，所以我认为这里值得一问，但我正在尝试评估建模会计数据的成本，以便从根本上平衡每笔交易。会计数据是仅附加的。此处的总体约束（以伪代码编写）可能大致如下：

CREATE TABLE journal_entry (
    id bigserial not null unique, --artificial candidate key
    journal_type_id int references  journal_type(id),
    reference text, -- source document identifier, unique per journal
    date_posted date not null,
    PRIMARY KEY (journal_type_id, reference)
);

CREATE TABLE journal_line (
    entry_id bigint references journal_entry(id),
    account_id int not null references account(id),
    amount numeric not null,
    line_id bigserial not null unique,
    CHECK ((sum(amount) over (partition by entry_id) = 0) -- this won't work
);

显然，这样的检查约束永远不会起作用。它按行操作，可能会检查整个数据库。所以它总是会失败并且做起来很慢。

所以我的问题是对这种约束进行建模的最佳方法是什么？到目前为止，我基本上已经研究了两个想法。想知道这些是否是唯一的，或者是否有人有更好的方法（除了将其留给应用程序级别或存储过程）。

1. 我可以借用会计界关于原始分录和最终分录（普通日记帐与总分类帐）之间差异的概念的一页。在这方面，我可以将其建模为附加到日志条目的日志行数组，对数组强制执行约束（在 PostgreSQL 术语中，从 …

我正在研究必须在数据库中以可逆加密格式存储虚拟机的 root 密码的可能性。原因是有时机器需要本地登录，但不鼓励这样做，我们需要能够查找 root 密码。当然，访问权限将受到严格限制，只有少数管理员。除非无法通过网络访问 vm，否则这些将不会被使用。在这方面同步用户和密码会带来类似的问题，即如果网络出现故障，sudoer 如何使用保证的最新密码登录？

计划要旋转的密钥的最佳方法是什么？我应该使用每个管理员都有的密码吗？这在我心中引起了一些危险信号。有没有办法安全地管理密钥，以便管理员可以设置自己的密码？也许使用公钥加密并使用每个管理员的公钥加密对称密钥？

在这里，我只是在寻找有关加密敏感数据的密钥管理的解决方案的一般概述。如果我无法弄清楚如何从该级别实施，我可以提出更多问题。

下面是我正在处理的一个项目的一个非常精简的版本。

CREATE TABLE cidr_block (
    id serial not null unique,
    block_def cidr primary key,
    dhcp_server_id int not null references computer_system (id),
    ...
);
CREATE TABLE ip_addr (
    computer_id int not null references computer_system (id),
    mac_addr macaddr not null unique,
    ip_addr inet not null unique,
);

这是一个网络配置数据库。现在，预计大多数（但不是全部）ip_addr.ip_addr 记录将位于 cidr_block.block_def 块中。其他可能是外部链接到客户位置的 vpn 接口可能不是。没有简单的声明性方法来确保两个表之间适用行的 fkey。所以我想知道：

1. 在适当的地方使用触发器来创建 fkey 链接是否更可取？

2. 仅仅在预期的地方加入就足够了吗？如果给一台计算机分配了一个错误的 IP 地址，它就不会从 dhcp 服务器获得一个，我们很快就会知道这一点。（写入触发通知，触发相关 dhcp 服务器上的更新）

3. 还有其他更好的方法吗？