Aurora PostgreSQL pg_columnmask データ移動シナリオ - Amazon Aurora

Aurora PostgreSQL pg_columnmask データ移動シナリオ

pg_columnmask の動作は、オペレーションがストレージ、論理、またはアプリケーションレイヤーのいずれで行われるかに応じて、データ移動オペレーションごとに異なります。ストレージレベルのオペレーション (クローン作成など) の動作は、論理オペレーション (pg_dump など) やアプリケーションレベルのオペレーション (FDW クエリなど) とは異なります。このセクションでは、レプリケーション、バックアップ、エクスポート、移行などの一般的なシナリオのマスキング動作と、それぞれのセキュリティへの影響について説明します。

Aurora Global Database とリードレプリカ

Aurora pg_columnmask ポリシーは、クラスターボリューム内のデータベースシステムテーブルに保存されます。すべてのレプリカが同じポリシーにアクセスし、一貫してマスクされた結果を返します。Aurora Global Database デプロイの場合、pg_columnmask ポリシーは他のデータベースシステムテーブルとともにセカンダリ AWS リージョンにレプリケートされるため、リージョン間で一貫したデータ保護が保証されます。フェイルオーバーシナリオ中、すべての pg_columnmask ポリシーはそのまま機能します。

データベースクローンとスナップショットの復元

Aurora Fast Clone およびスナップショット復元オペレーションでは、すべての pg_columnmask ポリシー、ロール、および設定がデータベースシステムテーブルの一部として保持されます。クローンまたは復元されたデータベースは、ソースクラスターから既存のすべてのポリシーを継承します。クローン作成または復元後、各データベースクラスターは独立した pg_columnmask ポリシーを維持します。

論理レプリケーション

初期同期中、論理レプリケーションは標準の SQL COPY オペレーションを使用し、pg_columnmask ポリシーはレプリケーションユーザーのアクセス許可に基づいて適用されます。進行中の CDC (変更データキャプチャ) 中、マスキングポリシーは適用されず、マスクされていないデータは WAL レコードを介してレプリケートされます。pg_create_subscription 権限を持つユーザーは、管理するシステムへのレプリケーションを設定することで、マスクされていないデータを流出する可能性があります。

Blue/Green デプロイ

スナップショットの復元中、pg_columnmask ポリシーは自動的に含まれます。グリーン環境は、ブルー環境のすべてのポリシーの同じコピーから始まります。ブルーからグリーンへのレプリケーション中、データはマスクされません。ブルークラスターでのその後のマスキングポリシーの変更 (DDL コマンド) は、グリーンクラスターにレプリケートされず、RDS ブルー/グリーンデプロイが無効になります。

ゼロ ETL ストリームと CDC ストリーム

データレプリケーションは pg_columnmask ポリシーの影響を受けません。ゼロ ETL は DDL レプリケーションをサポートしますが、pg_columnmask または RLS ポリシーはレプリケートしません。ゼロ ETL のレプリケートされたデータにはマスキングポリシーは適用されません。

AWS Database Migration Service

初期データ同期は、DMS タスク用に選択されたユーザーに基づいてマスクまたはマスク解除されます。CDC データは常にマスク解除されます。pg_columnmask 関連の内部 RLS ポリシーは移行できますが、pg_columnmask 対応以外のターゲットでは機能しません。

データエクスポート

pg_columnmask はエクスポートを他のクエリオペレーションと同様に扱います。マスキングは実行中のユーザーのアクセス許可に基づいて適用されます。これは、COPY、SELECT INTO、CREATE TABLE AS、Aurora PostgreSQL の S3 エクスポート機能などの SQL コマンドに適用されます。

注記

マスクされたユーザーがデータをエクスポートする場合、結果のファイルには、復元時にデータベースの制約に違反する可能性のあるマスクされた値が含まれます。

ビューとマテリアライズドビュー

ビューと連携させるときは、次の考慮事項に注意してください。

  • 通常のビュー – 常に INVOKER セマンティクスを使用します。現在のユーザーのマスキングポリシーは、ビューを作成したユーザーに関係なく、ビューのクエリ時に適用されます。

  • マテリアライズドビュー – 更新すると、更新を実行するユーザーのポリシーではなく、マテリアライズドビュー所有者のマスキングポリシーが適用されます。所有者にマスキングポリシーがある場合、マテリアライズドビューには常にマスクされたデータが含まれます。

データダンプと復元

pg_dump は通常のデータベースユーザーとして動作し、接続するユーザーのアクセス許可に基づいてマスキングポリシーを適用します。マスクされたユーザーがダンプを実行する場合、バックアップファイルにはマスクされたデータが含まれます。pg_columnmask ポリシーはデータベーススキーマの一部としてダンプに含まれます。復元を成功させるには、参照されるすべてのロールがターゲットデータベースに存在し、ターゲットに pg_columnmask 拡張機能がインストールされている必要があります。

注記

PostgreSQL 18 以降、pg_dump は、行レベルセキュリティ (RLS) ポリシーと pg_columnmask マスキングポリシーの両方をデータベースダンプから除外する —no-policies オプションをサポートしています。詳細については、「pg_dump」を参照してください。

外部データラッパー

外部データラッパーを使用する場合、リモートテーブルのマスキングポリシーは、ローカルクエリユーザーのアクセス許可ではなく、マッピングされたユーザーのソースサーバーに対するアクセス許可に基づいて適用され、FDW を介してマスクされたリモートデータにアクセスできますが、ローカルデータベースの外部テーブルで DDM または RLS ポリシーを直接作成することはできません。