Posted inDatabase

PostgreSQL Dynamic Data Masking：開発・テスト環境での顧客データ流出を防ぐ

Database tutorial - IT technology blog
Database tutorial - IT technology blog

背景：顧客データ流出という悪夢

データ管理に携わっている方なら、ロジックのバグを修正するために本番環境のリアルなデータが必要になったり、テストチームが自動化テストのために多様なデータを求めたりする状況に直面したことがあるでしょう。しかし、データベースには電話番号やメールアドレス、口座残高などの機密情報が詰まっています。

そのデータをそのままローカルPCやステージング環境に持ち込むのは、セキュリティリスクという大きな賭けに出るようなものです。開発者のノートPCが紛失したり、バックアップファイルが不注意で保護されていないクラウド上に置かれたりすれば、顧客情報は瞬く間に売買されてしまいます。

以前、500GBを超えるデータベースを扱うFintechプロジェクトに携わったことがあります。ラボ環境にデータを同期するたびに、チームは午前中ずっと UPDATE スクリプトを書いてダミーデータで上書きしていました。この手動の方法ではトランザクションログが急増し、データベースが数十GBも肥大化するだけでなく、数千万件のレコードがあるテーブルに対してスクリプトが完了するまで何時間も待たされることになりました。

Dynamic Data Masking (DDM) は、この問題に対する救世主です。物理的なデータを変更する代わりに、DDMは「フィルター」のような役割を果たします。実データはディスク上にそのまま残りますが、権限に応じて、ユーザーにはマスキングされた文字列や完全に偽造されたデータのみが表示されます。

postgresql_anonymizer のインストール

PostgreSQLは、SQL Server Enterpriseのようにこの機能を標準ではサポートしていません。しかし、postgresql_anonymizer（通称 anon）エクステンションが、現在のマスキング処理におけるデファクトスタンダードとなっています。

1. Dockerでクイックスタート

最も手軽に試す方法は、エクステンションがあらかじめ統合された公式のDockerイメージを使用することです。

docker run -d --name pg_anon -e POSTGRES_PASSWORD=mysecretpassword -p 5432:5432 registry.gitlab.com/dalibo/postgresql_anonymizer

2. Linuxサーバーへのインストール

UbuntuやDebianを使用している場合は、PGDGリポジトリから直接インストールできます。

# Postgres 15 用のエクステンションをインストール
sudo apt-get install postgresql-15-anonymizer

次に、Postgresの起動時にこのエクステンションが自動的に読み込まれるよう、postgresql.conf ファイルを編集して設定する必要があります。

shared_preload_libraries = 'anon'

Postgresを再起動した後、データベース内でこのツールを有効化します。

CREATE EXTENSION anon CASCADE;
SELECT anon.init();

マスキングの設定：ラベルを貼ってデータを隠す

anon の仕組みは非常に直感的です。特定のカラムにセキュリティラベル（Security Label）を貼るだけで、そのカラムは選択したルールに従って隠蔽されます。

ステップ1：開発チーム用ユーザーの設定

まず、テスト環境専用のユーザーを作成します。このユーザーは、実データを閲覧する権限が制限されます。

CREATE ROLE dev_user LOGIN PASSWORD 'password123';
GRANT SELECT ON ALL TABLES IN SCHEMA public TO dev_user;

ステップ2：マスキングルールの適用

customers テーブルを保護する必要があると仮定しましょう。ここでは、最も一般的な3つの手法を適用します。

  1. Partial Masking（部分マスキング）： メールの最初の数文字だけを表示し、特定は可能ですが実際のアドレスは取得できないようにします。
  2. Faking（フェイキング）： 実名をランダムな名前に置き換えます（例：「田中 太郎」を「John Doe」に）。
  3. Destructive Masking（破壊的マスキング）： 電話番号の途中に記号を挿入します。
-- メールを隠蔽、最初と最後の2文字を保持
SECURITY LABEL FOR anon ON COLUMN customers.email
IS 'MASKED WITH FUNCTION anon.partial(email,2,$$******$$,2)';

-- 名前をランダムなダミーデータに置き換え
SECURITY LABEL FOR anon ON COLUMN customers.full_name
IS 'MASKED WITH FUNCTION anon.fake_first_name()';

-- 電話番号をマスキング
SECURITY LABEL FOR anon ON COLUMN customers.phone
IS 'MASKED WITH FUNCTION anon.partial(phone,3,$$****$$,2)';

ステップ3：匿名化モードの有効化

最後に、Postgresに対して dev_user にマスキングルールを適用するよう命令します。

SELECT anon.start_masking();
SECURITY LABEL FOR anon ON ROLE dev_user IS 'MASKED';

実行結果の確認

同じデータ行を2つの異なるアカウントでクエリした際の違いを比較してみましょう。

管理者（すべて表示される）：

-- 結果: "田中 太郎", "[email protected]", "09012345678"

開発ユーザー（データが加工されている）：

SET ROLE dev_user;
SELECT full_name, email, phone FROM customers LIMIT 1;
-- 結果: "Robert", "ta******om", "090****78"

数ヶ月前、あるERPシステムにこの方法を導入しました。データの難読化（obfuscation）のために丸一日かけてスクリプトを実行する代わりに、わずか15分でルールの設定が完了しました. 匿名化関数の処理にCPUを消費するため、マスキングされたユーザーのクエリパフォーマンスは5〜10%ほど低下しましたが、それと引き換えに絶対的な安心感を得ることができました。

運用における重要な注意点：

  • パフォーマンスの問題： マスキングは SELECT 実行時に行われます。WHERE や LIMIT なしで数百万行をクエリすると、fake_* 関数の処理によってサーバーのCPU使用率が急上昇します。
  • UNIQUE制約： Uniqueインデックスを持つカラムをマスキングする際は注意が必要です。フェイク関数が誤って重複した値を生成すると、結合（Join）クエリがビジネスロジックと異なる結果を返す可能性があります。
  • 安全なバックアップ機能： マスキングされたユーザーで pg_dump を実行すると、出力されるダンプファイルにはダミーデータのみが含まれます。これは、ビジネス機密を漏らすことなく外部のパートナー企業にデータベースを渡すための素晴らしい方法です。

データセキュリティは、必ずしも業務のスピードを遅らせる障壁である必要はありません。Dynamic Data Maskingを活用すれば、開発チームは高品質なデータを維持しつつ作業を進めることができ、管理者は夜ぐっすり眠れるようになるでしょう。

Share:
Tags: