Roles and replication#
DDLおよびDMLレプリケーションとユーザー#
ユーザーが実行したDDL変更は、各ノードでその同じユーザーとして適用されます。
テーブルへのDML変更は、ターゲットノード上のテーブル所有ユーザーとして複製されます。
デフォルトでは、 PGDはノード全体に同じ所有者で新しいテーブルをレプリケートします。
異なるテーブルの所有権#
そのテーブルは、各ノードで同じユーザーが所有することをお勧めします。これはデフォルトの動作ですが、オーバーライドできます。その場合、考慮すべきことがいくつかあります。
テーブルAがノード1のユーザーXが所有し、ノード2のユーザーYが所有している状況を考えます。ユーザーYがユーザーXよりも高い特権を持っている場合、これは特権エスカレーションと見なされる場合があります。
ノードにはさまざまなユースケースがある可能性があるため、このシナリオを許可します。しかし、私たちはそれに対して警告します。テーブルの所有者が異なるノードに異なる場合、セキュリティ管理者にこの構成の計画と監査を手伝ってもらうことをお勧めします。
レプリケーションと行レベルのセキュリティ#
行レベルのセキュリティポリシーが有効になっているテーブルでは、適用時にポリシーを強化せずに変更がレプリケートされます。この動作は、
FORCE ROW LEVEL SECURITY が指定されている場合でも、
NO FORCE ROW LEVEL SECURITY
として適用される変更と同等です。これは希望するものでない場合は、すべての行のレプリケートを回避するrow_filterを指定します。すべてのノードの行セキュリティポリシーが同一または少なくとも互換性があることをお勧めしますが、強制はしません。
bdr_superuserのロールとレプリケーション#
ユーザーbdr_superuserは、PGDのレプリケーションを制御し、レプリケーションセットから任意のテーブルを追加または削除できます。
bdr_superuserは、個々のテーブルに対する特権を必要とせず、お勧めしません。レプリケーションセットファンクションへのアクセスを制限する必要がある場合は、これらのファンクションの制限バージョンをSECURITY DEFINER
ファンクションとして実装し、適切なユーザーに付与できます。
特権制限#
PGDは追加の制限を適用し、 TRIGGERまたはREFERENCES特権のみに依存するDDLの使用を効果的に防止します。
GRANT ALL
は引き続きTRIGGERとREFERENCES特権の両方を付与するため、特権を明示的に記述することをお勧めします。たとえば、
ALL の代わりにGRANT SELECT, INSERT, UPDATE, DELETE, TRUNCATE
を使用します。
外部キー特権#
ALTER TABLE ... ADD FOREIGN KEY
は、ユーザーが参照されるテーブルに対するSELECT特権を持っている場合、または参照先テーブルで現在のユーザーがバイパスできないRLS制限が有効になっている場合にのみサポートされます。
これは、 REFERENCES特権だけではPGDで外部キーを作成するのに十分でないことを意味します。 REFERENCES特権のみに依存すると、テーブルスキャンではなくトリガーを使用して検証チェックが実行されるため、通常は役立ちません。通常、コストが高すぎるため、正常に使用できません。