他のバージョンの文書 16 | 15 | 14 | 13 | 12 | 11 | 10 | 9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

31.9. セキュリティ #

レプリケーション接続のために使われるロールには、REPLICATION属性が付与されている(もしくはスーパーユーザである)必要があります。 ロールに SUPERUSERBYPASSRLSがない場合は、パブリッシャーは行セキュリティポリシーを実行できます。 ロールが全てのテーブルの所有者を信頼していない場合、接続文字列にoptions=-crow_security=offを含めてください。 テーブルの所有者が行セキュリティポリシーを追加した場合、ポリシーが実行されるのではなく、レプリケーションが停止します。 接続のためのロールはpg_hba.confで設定され、 LOGIN属性を持つ必要があります。

テーブルの初期データをコピーできるためには、レプリケーション接続に使用されるロールは、パブリッシュされるテーブルに対してSELECT権限を持っていなければなりません。 (あるいはスーパーユーザでなければなりません。)

パブリケーションを作成するためには、ユーザはデータベース中のCREATE権限を持っていなければなりません。

テーブルをパブリケーションに追加するためには、ユーザはテーブルの所有権限を持っていなければなりません。 スキーマのすべてのテーブルをパブリケーションに追加するには、ユーザがスーパーユーザである必要があります。 自動的にすべてのテーブルにパブリッシュするパブリケーションを作成するには、ユーザはスーパーユーザでなければなりません。

現在、パブリケーションに権限はありません。 (接続可能な)サブスクリプションはすべて、パブリケーションにアクセスできます。 そのため、行フィルタや列リストを使用したり、テーブル全体をパブリケーションに追加しないなどして、特定のサブスクライバからの情報を隠したい場合は、同じデータベース内の他のパブリケーションが同じ情報にアクセスできる可能性があることに注意してください。 より細かいアクセス制御を可能にするために、パブリケーション権限が将来PostgreSQLに追加される可能性があります。

サブスクリプションを作成するためには、ユーザはpg_create_subscriptionロールの権限と、データベースのCREATE権限を持っていることが必要です。

サブスクリプション適用プロセスは、セッションレベルで、サブスクリプション所有者の権限で実行されます。 ただし、特定のテーブルに対して挿入、更新、削除または切捨て操作を実行すると、テーブルの所有者にロールを切り替え、テーブルの所有者の権限で操作が実行されます。 つまり、サブスクリプション所有者は、レプリケートされたテーブルを所有する各ロールに対してSET ROLEを実行できる必要があります。

サブスクリプションが run_as_owner = trueで構成されている場合、ユーザの切り替えは発生しません。 その代わり、すべての操作は、サブスクリプションの所有者の権限で実行されます。 この場合、サブスクリプションの所有者は、対象テーブルからのSELECTINSERTUPDATE、およびDELETE権限のみが必要であり、テーブル所有者に対するSET ROLE権限は不要です。 しかし、これはまた、レプリケーションが行われているテーブルを所有するユーザは、サブスクリプション所有者の権限で任意のコードを実行できることを意味します。 たとえば、所有するテーブルにトリガーを付加するだけで、これを実行できます。 通常、あるロールが別のロールの権限を自由に引き受けることは望ましくないので、データベース内のユーザーセキュリティが問題にならない場合以外は、このオプションを避けるべきです。

パブリッシャーでは、権限はレプリケーション接続の開始時に一度だけチェックされ、変更レコードが読み取られるたびに再チェックされません。

サブスクライバーでは、サブスクリプション所有者の権限は、適用時にトランザクションごとに再チェックされます。 同時に並行しているトランザクションによってサブスクリプションの所有権が変更されたときにワーカーがトランザクションを適用している場合、現在のトランザクションの適用は古い所有者の権限で継続されます。