Security and Roles

BDR拡張機能はスーパーユーザーのみが作成できますが、必要に応じて、pgextwlist拡張機能をセットアップし、非スーパーユーザーがBDRを作成できるように構成することもできます。

BDRのデフォルトとPostgreSQLには、スーパーユーザアクセスは必要ありません。また、推奨もされてデフォルトBDRん。

    • bdr_superuser *-すべてのBDRテーブルと機能にアクセスできる最高特権ロール。

    • bdr_read_all_stats * BDRの状態を理解するのに十分な、テーブル、ビュー、および関数への読み取り専用アクセス権を持つロール。

    • bdr_monitor *-現時点ではbdr_read_all_statsと同じで、後で拡張ます。

    • bdr_application * BDRを実行するアプリケーションに必要な最小限の特権。

    • bdr_read_all_conflicts -``bdr.conflict_history``のすべて*の競合をビューできます。

これらのBDRロールは、 BDR拡張機能がインストールされるときに作成されます。詳細については、以下の[BDRデフォルトロール]を参照してください。

BDRを管理するには、管理者がユーザデータにアクセスする必要はありません。

競合を保護するための準備については、ここで説明されていますb_tran_1。

競合は、 BDR.conflict_history_summaryビューを使用して監視できます。

カタログ表

システムカタログと情報スキーマテーブルは、 BDRによって常にレプリケーションから除外されます。

さらに、拡張機能が所有するテーブルはレプリケーションから除外されます。

BDRFunctionsと演算子

すべてのBDR関数はbdrスキーマで公開されます。これらの関数の呼び出しは、bdrをsearch_pathに入れるのではなく、スキーマで修飾する必要があります。

すべてのBDR演算子はpg_catalogスキーマを介して利用できるため、ユーザーは問題なくsearch_pathからpublicスキーマを除外できます。

カタログオブジェクトに対する権限の付与

管理者は、テーブル、ビュー、関数などのカタログオブジェクトに対する明示的な権限を付与しないでください。 [BDRDefault Roles]で文書化されたロールの1つを付与することにより、それらのオブジェクトへのアクセスを管理します。

この要件は、結合のいずれかの側のノードがまったく同じバージョンのBDR （したがってBDRcatalog）を持たない場合でも、ノードグループに参加できる柔軟性の結果です。

より正確には、個々のカタログオブジェクトに対する特権が明示的に付与されている場合、結合されているノードから抽出された対応するGRANTステートメントが結合しているノードに適用されない可能性があるため、bdr.join_node_group()プロシージャは失敗する可能性があります

ロール管理

ユーザーはPostgreSQLインスタンスのグローバルオブジェクトBDRが実行され、bdr.role_replicationがオンになっているデータベースで実行された場合、.CREATE USERおよびCREATE ROLEコマンドは自動的に複製されます。ただし、これらのコマンドが同じPostgreSQLインスタンスの他のデータベースで実行される場合、それらのユーザーがBDRデータベースに対する権限を持っている場合でも、それらは複製されません。

新しいBDRノードがBDRグループに参加すると、bdr_init_physicalを使用してノードが追加されない限り、既存のユーザーは自動的にコピーされません。これは意図的なものであり、重要なセキュリティ機能です。 PostgreSQLでは、ユーザーは複数のデータベースにアクセスできますが、デフォルトでは任意のデータベースにアクセスできます。 BDRは、どのユーザーがどのデータベースにアクセスするかを知らないため、どのノードを新しいノードにコピーするかを安全に決定できません。

PostgreSQLでは、次のコマンドですべてのユーザーをダンプできます。

pg_dumpall --roles-only > roles.sql

その後、ファイルroles.sqlを編集して、不要なユーザーを削除してから、新しく作成されたノードで再実行できます。IDおよびアクセス管理ソリューション（IAM）によっては他のメカニズムも可能ですが、現時点では自動化されていません。

ロールとレプリケーション

ユーザが実行したDDLの変更は、各ノードで同じユーザとして適用されます。

テーブルへのDMLの変更は、ターゲットノードのテーブル所有ユーザとして複製されます。ただし、強制ではありませんが、各ノードの同じユーザがテーブルを所有することをお勧めします。

テーブルAがノード1のユーザXに所有され、ノード2のユーザYに所有されている場合、ユーザYがユーザXより高い特権を持っている場合、これは権限エスカレーションと見なされる可能性があります。セキュリティ管理者がこのシチュエーションを計画および監査できるようにする

行単位セキュリティポリシーが有効になっているテーブルでは、適用時にポリシーを再適用せずに変更が複製されます。これは、FORCE ROW LEVEL SECURITYが指定されている場合でも、asNO FORCE ROW LEVEL SECURITYに適用される変更と同等です。すべてのノードの行セキュリティポリシーが同一であるか、少なくとも互換性があることが推奨されますが、強制されません。

bdr_superuserはBDRのレプリケーションを制御し、レプリケーションセットからテーブルを追加または削除できることに注意してください。 bdr_superuserは、個々のテーブルに対する特権を必要とせず、持つことも推奨されません。レプリケーションセット関数へのアクセスを制限する必要がある場合、これらの関数の制限バージョンをSECURITY DEFINER関数として実装し、適切なユーザーにGRANTedすることができます。

接続ロール

新しいBDRノードを割り当てる場合、bdr.create_nodeのlocal_dsn引数とjoin_target_dsn ofbdr.join_node_groupのDSNで指定されたユーザは、データベースオブジェクトの参照、作成、および管理に頻繁に使用されます。

BDRは、これらのDSNでSUPERUSER権限を持つロールを使用する場合でも、権限エスカレーション攻撃を防ぐために慎重に記述されています。

攻撃対象をさらに減らすために、上記のDSNでより制限されたユーザを指定できます。少なくとも、このようなユーザは、次の規定が満たされるように、すべてのノードで権限を付与する必要があります。

  • ユーザがREPLICATION属性を持っている

  • データベースに対するCREATEパーミッションが付与されます

  • bdr_superuserロールを継承します

  • 直接または経由して、複製するすべてのデータベースオブジェクトを所有している 所有者のロールからの許可。

すべてのノードが結合されると、DMLおよびDDLレプリケーションを引き続き許可するために、アクセス許可がさらに次のように削減される場合があります。

  • ユーザにはREPLICATION属性があります。

  • bdr_superuserロールを継承します。

特権の制限

BDRは追加の制限を実施し、TRIGGERまたはREFERENCES特権のみに依存するDDLの使用を効果的に防止します。次のサブセクションでこれらについて説明します。

GRANT ALLは引き続きTRIGGERとREFERENCESの両方の権限を付与するため、ALLではなく、GRANT SELECT, INSERT, UPDATE, DELETE, TRUNCATEなどの権限を明示的に指定することをお勧めします。

外部キー特権

ALTER TABLE ... ADD FOREIGN KEYがサポートされるのは、ユーザが被参照先テーブルに対するSELECT権限を持っている場合、または被参照テーブルでRLS制限が有効になっていて、現在のユーザがバイパスできない場合のみです。

したがって、REFERENCES権限は、 BDRを使用した外部キーの作成を許可するには不十分です。 REFERENCES権限のみに依存することは、テーブルスキャンではなくトリガーを使用してバリデーションチェックを実行するため、通常は有用ではありません。

トリガー

PostgreSQLでは、トリガーはテーブルの所有者とTRIGGER権限を付与された人の両方が作成できます。テーブル以外の所有者から付与されたトリガーは、セキュリティの問題を引き起こす可能性のあるBDRのパーミッション所有者として実行されPostgreSQL。

BDRは、誰がテーブルにトリガーを作成できるかについてより厳しいルールを使用することにより、この問題を軽減します。

  • スーパーユーザ

  • bdr_superuser

  • テーブルの所有者は、 PostgreSQLと同じルールに従ってトリガーを作成できます。 （トリガーによって使用されるファンクションに対するEXECUTE権限が必要です）。

  • テーブルに対するTRIGGER権限を持つユーザーは、次の場合にのみトリガーを作成できます。 それらは、同じ所有者が所有するファンクションを使用してトリガーを作成します テーブルで、標準のPostgreSQLルールを満たします（ここでもEXECUTEが必要です） ファンクションに対する権限）。したがって、テーブルとファンクションの両方が同じ所有者を持ち、 所有者は、テーブルに対するTRIGGER権限とEXECUTEの両方をユーザに与えることにしました ファンクションに対する権限、そのユーザが作成することは問題ないと想定されます。 このファンクションを使用したそのテーブルのトリガー。

  • テーブルに対するTRIGGER権限を持つユーザーは、次を使用してトリガーを作成できます。 EXECUTEがある場合、SECURITY DEFINER句で定義されている関数 それらの権限。この句により、ファンクションは常にコンテキストで実行されます 標準のPostgreSQLとBDRの両方におけるファンクション自分自身の所有者の。

上記のロジックは、 PostgreSQLでは、トリガーの所有者はそれを作成したユーザではなく、そのトリガーが使用するファンクションの所有者であるという事実に基づいています。

同じルールが既存のテーブルに適用され、既存のテーブルにテーブルの所有者が所有していないトリガーがあり、SECURITY DEFINER関数を使用しない場合、それをレプリケーションセットに追加することはできません。

これらのチェックはBDR 3.6.19で追加されました。以前のバージョンの動作に依存するアプリケーションは、edbdr.backwards_compatibilityを30618（またはそれ以下）に設定して、以前のバージョンのように動作させることができます。

BDRレプリケーションの適用では、システムレベルのデフォルトのsearch_pathのみが使用されます。レプリカトリガー、ストリームトリガー、およびインデックス式関数は、適用時に実行すると失敗する他のsearch_path設定を想定する場合があります。これが発生し保証にするには、defaultsearch_pathのみ（常にスキーマ.objectnameなどのオブジェクトへの完全修飾参照を使用）を使用してオブジェクト参照を明確に解決するか、ALTER FUNCTION … SET search_path = …を使用してファンクションの検索パスを設定します影響を受ける機能用。

BDRデフォルト/事前定義ロール

BDR拡張機能のインストール時に、 BDR定義済みロールが作成されますBDR拡張機能がデータベースから削除された後も、ロールは引き続き存在するため、必要に応じて手動で削除する必要があります。これにより、同じPostgreSQLインスタンス上の複数のデータベースでBDRを問題なく使用できます。

GRANT ROLE DDLステートメントはBDRレプリケーションに参加しないため、クラスターの各ノードでこれを実行必要があることに注意してください。

bdr_superuser

  • スキーマBDRのすべてのテーブルのすべての特権

  • スキーマBDRのすべてのルーチンのすべての特権

bdr_read_all_stats

SELECT権限

  • bdr.conflict_history_summary

  • bdr.ddl_epoch

  • bdr.ddl_replication

  • bdr.global_consensus_journal_details

  • bdr.global_lock

  • bdr.global_locks

  • bdr.local_consensus_state

  • bdr.local_node_summary

  • bdr.node

  • bdr.node_catchup_info

  • bdr.node_conflict_resolvers

  • bdr.node_group

  • bdr.node_local_info

  • bdr.node_peer_progress

  • bdr.node_slots

  • bdr.node_summary

  • bdr.replication_sets

  • bdr.sequences

  • bdr.state_journal_details

  • bdr.stat_relation

  • bdr.stat_subscription

  • bdr.subscription

  • bdr.subscription_summary

  • bdr.tables

  • bdr.worker_errors

EXECUTE権限

  • bdr.bdr_version

  • bdr.bdr_version_num

  • bdr.conflict_resolution_to_string

  • bdr.conflict_type_to_string

  • bdr.decode_message_payload

  • bdr.get_global_locks

  • bdr.get_raft_status

  • bdr.get_relation_stats

  • bdr.get_slot_flush_timestamp

  • bdr.get_sub_progress_timestamp

  • bdr.get_subscription_stats

  • bdr.peer_state_name

  • bdr.show_subscription_status

bdr_monitor

bdr_read_all_statsからのすべての特権、プラス

EXECUTE権限

  • bdr.monitor_group_versions

  • bdr.monitor_group_raft

  • bdr.monitor_local_replslots

bdr_application

EXECUTE権限

  • column_timestampsデータ型のすべての関数

  • CRDTデータ型のすべての関数

  • bdr.alter_sequence_set_kind

  • bdr.create_conflict_trigger

  • bdr.create_transform_trigger

  • bdr.drop_trigger

  • bdr.get_configured_camo_partner

  • bdr.global_lock_table

  • bdr.is_camo_partner_connected

  • bdr.is_camo_partner_ready

  • bdr.logical_transaction_status

  • bdr.ri_fkey_trigger

  • bdr.seq_nextval

  • bdr.seq_currval

  • bdr.seq_lastval

  • bdr.trigger_get_committs

  • bdr.trigger_get_conflict_type

  • bdr.trigger_get_origin_node_id

  • bdr.trigger_get_row

  • bdr.trigger_get_type

  • bdr.trigger_get_xid

  • bdr.wait_for_camo_partner_queue

  • bdr.wait_slot_confirm_lsn

上記の関数の多くには、使用する前に追加の特権が必要であることに注意してください。例、bdr.alter_sequence_set_kindを正常に実行には、テーブルの所有者である必要がありファンクション。

bdr_read_all_conflicts

BDRは、競合をbdr.conflict_historyテーブルに記録します。競合はテーブル所有者のみに表示されるため（のみ）、競合履歴を読み取るために追加の特権は必要ありません。 * all テーブルの競合を見ることができるユーザがいると便利な場合は、オプションでそのユーザにロール bdr_read_all_conflicts *を付与できます。

検証

BDRは、次のツールとアプローチを使用して検証されています。

コベリティ

Coverity Scanは、次のルールとコーディング標準を使用して、脆弱性に対するカバレッジを提供するBDRスタックを検証するために使用されています。

  • MISRA C

  • ISO 26262

  • ISO / IEC TS 17961

  • OWASPトップ10

  • CERT C

  • CWEトップ25

  • AUTOSAR

CISベンチマーク

CIS PostgreSQL Benchmark v1、2019年12月19日は、 BDRスタックの検証に使用されています。TPAexecでオプションとして使用可能なcis_policy.yml構成を使用すると、スコア付きテストで次の結果が得られます。

:header:, Result, Description

1.4

PASS

systemdサービスファイルが有効になっていることを確認する

1.5

PASS

データクラスターが正常に初期化されたことを確認する

2.1

PASS

ファイル権限マスクが正しいことを確認します

2.2

PASS

PostgreSQLグループメンバシップが正しいことを確認します

3.1.2

PASS

ログの宛先が正しく設定されていることを確認します

3.1.3

PASS

ログ収集機構が有効になっていることを確認します

3.1.4

PASS

ログファイルの宛先ディレクトリが正しく設定されていることを確認します

3.1.5

PASS

ログファイルのファイル名パターンが正しく設定されていることを確認します

3.1.6

PASS

ログファイルの権限が正しく設定されていることを確認します

3.1.7

PASS

'log_truncate_on_rotation'が有効になっていることを確認します

3.1.8

PASS

ログファイルの最大有効期間が正しく設定されていることを確認します

3.1.9

PASS

ログファイルの最大サイズが正しく設定されていることを確認します

3.1.10

PASS

正しいsyslog機能が選択されていることを確認します

3.1.11

PASS

PostgreSQLメッセージのプログラム名前が正しいことを確認してください

3.1.14

PASS

'debug_print_parse'が無効になっていることを確認します

3.1.15

PASS

'debug_print_rewritten'が無効になっていることを確認します

3.1.16

PASS

'debug_print_plan'が無効になっていることを確認します

3.1.17

PASS

'debug_pretty_print'が有効になっていることを確認します

3.1.18

PASS

'log_connections'が有効になっていることを確認します

3.1.19

PASS

'log_disconnections'が有効になっていることを確認します

3.1.21

PASS

'log_hostname'が正しく設定されていることを確認します

3.1.23

PASS

'log_statement'が正しく設定されていることを確認します

3.1.24

PASS

'log_timezone'が正しく設定されていることを確認します

3.2

PASS

PostgreSQL Audit Extension（pgAudit）が有効になっていることを確認します

4.1

PASS

sudoが正しく構成されていることを確認します

4.2

PASS

過度の管理者権限が取り消されていることを確認します

4.3

PASS

過剰なファンクション権限が取り消されていることを確認します

4.4

PASS

テスト済み過剰なDML特権が取り消されていることを確認します

5.2

Not Tested

' ホスト ' TCP / IPソケットを介したログインが正しく構成されていることを確認します

6.2

PASS

'バックエンド'ランタイムパラメータが正しく構成されていることを確認します

6.7

Not Tested

FIPS 140-2OpenSSL暗号化が使用されていることを確認します

6.8

PASS

SSLが有効になっていて正しく構成されていることを確認します

7.3

PASS

WALアーカイビングが構成され機能していることを確認します

NA

手動で監査した場合、テスト5.2は合格できますが、自動化可能なテストはありません。

テスト6.7は、CentOSを使用したデフォルトの展開で成功しますが、Debianバリアントの追加パッケージソフトが必要です。