mli*_*ner 5 postgresql replication security
我经营一个非营利组织,致力于分享类似于维基百科的数据。
我们最近有一个客户想要我们的数据库的副本,我们意识到通过使用 PostgreSQL 的新逻辑复制,我们可以将我们的数据库表复制到他们控制的服务器上。
这对于完成我们共享数据的使命非常有用。它比提供慢速 API 好 100 倍。
我们为他们创建了一个这样的角色:
CREATE ROLE some_client WITH REPLICATION LOGIN PASSWORD 'long-password';
GRANT SELECT ON TABLE some_table TO some_client;
Run Code Online (Sandbox Code Playgroud)
我们为他们创建了一个 PUBLICATION,如下所示:
CREATE PUBLICATION testpublication FOR TABLE ONLY some_table;
Run Code Online (Sandbox Code Playgroud)
这样做有风险吗?我的分析是,这使他们可以选择访问他们正在复制到他们自己的服务器的表,但仅此而已。还有其他顾虑吗?如果有顾虑,是否有办法使这项工作发挥作用?我们有不想共享的表,但我们的大多数表只有公共数据。
请注意,订阅者仅需要 GRANT SELECT 来批量复制表中的初始数据。如果他们没有该 GRANT,他们仍然可以启动订阅,并且他们将能够看到任何新插入的行或任何更新行的新版本。完整功能需要 GRANT SELECT 的事实似乎是设计中的缺陷,因为拒绝 GRANT SELECT 访问权限并不会拒绝他们对所有数据的访问,而只是拒绝对已经存在且从未更新的子集的访问。这在某种程度上令人困惑,可能导致安全错误。
此外,没有细粒度的控制来控制哪些用户可以订阅数据库中的哪些出版物(至少我找不到)。任何可以连接到给定数据库的“WITH REPLICATION”用户都可以启动对该数据库中所有发布的订阅。结合前面讨论的限制(拒绝表上的 SELECT 不会拒绝表内容的所有可见性),这确实是有限制的。尽管可能不在您的用例中,但如果您只有一个外部方,或者所有外部方都需要访问同一事物。
级联逻辑复制是可能的。因此,您可以通过为您想要单独控制的每个出版物创建一个“无菌”数据库来获得一些细粒度的控制。在该无菌数据库中,您在主数据库中创建对发布的订阅(当然,使用某些内部角色连接到它,而不是外部用户的角色),并创建这些相同表的发布。然后,您将外部用户的 CONNECT 角色(或使用 pg_hba.conf 设置)仅授予无菌数据库,而不是主数据库。您可以使用单独的数据库服务器或同一数据库服务器中的单独数据库来执行此操作。它确实增加了存储需求以及内部重新发布数据的 CPU 开销,这令人烦恼。
为了让外部方连接以进行复制,您必须在防火墙上戳一个洞让他们进入。这样做可能会让您面临各种试图侵入您的数据库的不法分子。因此,请确保您对所有角色(而不仅仅是“some_client”)都拥有强密码(或某种更好形式的身份验证,例如客户端证书)。或者仅针对客户端的域或 IP 地址范围戳防火墙漏洞。或者确保 pg_hba 中除“some_client”之外的所有角色仅允许来自内部 IP 地址。或者以上所有。
最后,您将面临来自该客户端的意外(甚至故意)拒绝服务攻击。如果他们无法保持数据库正常运行并跟随您的出版物,则会导致您的数据库开始保留 pg_wal 文件,甚至可能会填满您的存储系统并导致停机。因此,您应该有某种方法来监视 pg_wal 大小,并准备好在复制槽没有跟上时强行删除它。
| 归档时间: |
|
| 查看次数: |
146 次 |
| 最近记录: |