PostgreSQL／MySQL MCP｜本番ReadOnly接続・クエリログ・PIIマスキング（実務チェックリスト）

ミッションクリティカルなシステムにおいて、本番環境のデータベース（DB）に対する「直接的な参照」は、常にリスクと利便性のトレードオフを迫られます。不適切なクエリが1つ走るだけでサービスのレスポンスは悪化し、不用意な権限付与は重大な個人情報漏洩に直結します。

本記事では、PostgreSQLおよびMySQLを対象に、本番環境での安全なReadOnly（読み取り専用）接続の構築、監査に耐えうるクエリログの取得、そして個人情報（PII: Personally Identifiable Information）を保護するマスキングの実装手法について、実務レベルの知見を網羅します。

PostgreSQL / MySQL 本番環境におけるReadOnly接続の設計指針

本番DBへの参照を許可する際、最も避けるべきは「本番マスター機への直接接続」です。たとえ読み取り専用ユーザーであっても、巨大な集計クエリが走れば共有バッファの汚染やCPUリソースの枯渇を招き、更新処理（トランザクション）に遅延を発生させます。

リードレプリカを活用した物理的負荷分散

基本戦略は、物理的にインスタンスを分離するリードレプリカの導入です。AWS RDSやGoogle Cloud SQLなどのマネージドサービスでは標準機能として提供されています。

• PostgreSQL: ストリーミングレプリケーションを利用し、読み取り専用のスタンバイ機を作成します。
• MySQL: 非同期レプリケーション、または準同期レプリケーションを用いてリードレプリカを構築します。

ここで重要なのは、エンドポイントの分離です。アプリケーションの書き込み用（Writer）と、分析・調査用の読み取り用（Reader）で接続先を完全に分けることで、物理的な干渉を最小限に抑えます。大規模な分析が必要な場合は、DBから直接抽出するのではなく、モダンデータスタック（BigQuery等への同期）の構築を検討すべきです。

DBユーザー権限による論理的書き込み禁止設定

物理的な分離に加えて、DBレイヤーでの権限制御が二重の防御策となります。「ReadOnlyだと思っていた接続先が実はマスターだった」というヒューマンエラーを防ぐため、以下の設定を徹底します。

PostgreSQLの場合

PostgreSQL 14以降であれば、デフォルトで用意されている pg_read_all_data ロールを活用するのが効率的です。

-- 読み取り専用ロールの作成
CREATE ROLE readonly_user WITH LOGIN PASSWORD 'your_password';
GRANT pg_read_all_data TO readonly_user;
-- 特定のスキーマのみに制限する場合
REVOKE ALL ON SCHEMA secret_schema FROM readonly_user;

MySQLの場合

MySQLでは SELECT 権限のみを付与し、さらに read_only システム変数が ON になっているレプリカ機を使用します。

-- 読み取り専用ユーザーの作成
CREATE USER 'readonly_user'@'%' IDENTIFIED BY 'your_password';
GRANT SELECT ON . TO 'readonly_user'@'%';
FLUSH PRIVILEGES;

監査・トラブルシューティングのためのクエリログ運用実務

「いつ、誰が、どのようなクエリを実行したか」の証跡は、セキュリティ監査だけでなく、パフォーマンス改善においても不可欠です。しかし、すべてのクエリを記録するとログ出力自体のオーバーヘッドで性能が低下します。

PostgreSQLにおける pg_stat_statements と log_statement

PostgreSQLの実務において、統計情報の収集と個別のログ出力は分けて考えます。

• pg_stat_statements: クエリの実行回数、合計時間、平均時間などの統計を記録する必須のエクステンションです。パフォーマンス分析に極めて有効です。
• log_statement: 監査用には 'all' ではなく 'ddl' または 'mod'（変更系）を基本とし、参照専用ユーザーの動きを追う場合は、対象ユーザーのみ log_statement = 'all' を設定するのが現実解です。

MySQLにおけるスロークエリログと一般クエリログ

MySQLでは、slow_query_log を常時有効化し、閾値（long_query_time）を適切に設定（例: 1.0秒）するのが定石です。

参照専用接続の監査には general_log（一般クエリログ）が使われますが、これは全クエリを記録するため、非常に巨大なログファイルが生成されます。実務上は、マネージドサービスの監査ログ機能（RDSの「MariaDB監査プラグイン」互換機能など）を利用し、特定のユーザーイベントのみをフィルタリングして出力するのが推奨されます。

クラウドマネージド環境でのログ集約

DBサーバー内のディスクにログを溜め続けるのは避けなければなりません。AWS RDSであれば CloudWatch Logs、Google Cloud SQLであれば Cloud Logging へのエクスポート設定を有効にします。これにより、ログの長期保存と、特定条件でのアラート通知が可能になります。

PII（個人情報）マスキングの実装と運用

分析や調査のために開発者が本番DBを参照する場合、氏名やメールアドレス、クレジットカード番号などのPII（個人情報）をそのまま表示させるのは、コンプライアンス上のリスクが非常に高いです。これを技術的に解決するのが「マスキング」です。

動的データマスキング（DDM）の採用基準

データを物理的に書き換えるのではなく、クエリ実行時にリアルタイムで値を隠蔽するのが「動的データマスキング」です。以下の表で、主要な実装手法を比較します。

PostgreSQL：PostgreSQL Anonymizer の活用

PostgreSQL Anonymizer は、PostgreSQL内で直接データを匿名化するための強力なツールです。特定のロールに対してのみマスキングを適用する Static Masking や、クエリ時に変換する Dynamic Masking をサポートしています。

-- 読み取り専用ユーザーにマスキングを適用する例
ALTER ROLE readonly_user SET anon.masking = on;
SECURITY LABEL FOR anon ON COLUMN users.email
IS 'MASKED WITH FUNCTION anon.partial(email,2,

∗∗∗∗∗∗

,2)';

MySQL：ビュー（VIEW）による簡易マスキングとアクセス制御

MySQL（特に標準的なRDS構成）では、ビューを介してアクセスさせる手法が一般的です。元のテーブルへの SELECT 権限は剥奪し、マスキングを施したビューに対してのみ SELECT 権限を付与します。

-- マスキング用ビューの作成
CREATE VIEW v_users AS
SELECT
id,
CONCAT(LEFT(last_name, 1), '') AS last_name,
CONCAT(LEFT(email, 2), '@example.com') AS email,
created_at
FROM users;

-- ビューへの権限付与
GRANT SELECT ON my_db.v_users TO 'readonly_user'@'%';

このようなセキュアなデータアクセス構造は、次世代データ基盤におけるID連携や、顧客データの利活用においても基盤となる考え方です。

【比較】本番DB接続管理ソリューション

実務では、DB標準機能以外にプロキシツールを採用することも多くあります。特に、接続元のIP制限や一時的なアクセス権付与を自動化したい場合に有効です。

自社でインフラを管理するリソースが限られている場合は、まずはクラウド公式のProxyやIAM連携（RDS Proxy等）から着手し、監査要件が厳格化するにつれてTeleportのような商用製品を検討するのが、インフラ負債を抱えないための現実的な選択です。

実務チェックリスト：本番リリース前に確認すべき20項目

本番ReadOnly環境を運用開始する前に、以下の項目を最終確認してください。これらは多くの現場でトラブルの火種となるポイントを凝縮したものです。

接続・認証・ネットワーク

• [ ] 接続先はWriter（マスター）ではなく、Reader（レプリカ）のエンドポイントになっているか。
• [ ] 専用のDBユーザーを作成し、SELECT 以外の権限（INSERT, UPDATE, DELETE, DROP等）が剥奪されているか。
• [ ] パブリックネットワークからのアクセスが拒否され、VPNや特定のPrivate Service Connect経由に制限されているか。
• [ ] パスワード認証だけでなく、可能な限りIAM認証や証明書認証が導入されているか。
• [ ] 同時接続数制限（max_connections）が、本番稼働を阻害しない程度に絞られているか。

ロギング・監査

• [ ] スロークエリログが有効化されており、一定時間以上のクエリが記録されるようになっているか。
• [ ] ログの出力先がクラウドストレージ（S3/GCS）やログ管理サービスに転送設定されているか。
• [ ] ログの保存期間が、自社のセキュリティポリシー（例：1年間）を満たしているか。
• [ ] ログ内に平文のPIIが記録される場合の閲覧制限は策定されているか。
• [ ] 異常な大量クエリやエラーレートの急上昇を検知するアラートが設定されているか。

性能・可用性

• [ ] リードレプリカのスペックは、本番マスターと比較して極端に低くないか（レプリケーション遅延の原因となる）。
• [ ] 重いクエリによるCPU使用率のスパイクが、他のリードレプリカに影響を与えない構成になっているか。
• [ ] 長時間実行クエリを強制終了させる statement_timeout（PostgreSQL）または max_execution_time（MySQL）が設定されているか。
• [ ] レプリケーション遅延（Replication Lag）の監視メトリクスが設定されているか。
• [ ] 統計情報（ANALYZE）が適切に更新され、実行計画が最適化されているか。

データ保護（PIIマスキング）

• [ ] マスキング対象となるカラムのリスト（個人情報定義書）が最新の状態か。
• [ ] マスキングを適用したビュー、またはプロキシが期待通りに値を置換しているか。
• [ ] マスキングされたデータを用いた分析が、業務上成立するか（ハッシュ化のソルト値など）。
• [ ] 管理者権限（superuser）であっても、直接マスターを覗くことがルール化・制限されているか。
• [ ] 定期的に権限の見直し（不要になったユーザーの削除）を行う運用フローがあるか。

本番DBの管理は、一度設定して終わりではありません。ビジネスの成長に伴うデータ量の増加や、法規制（改正個人情報保護法など）の変化に合わせ、常にアーキテクチャをアップデートし続ける必要があります。本記事のチェックリストを、貴社のセキュアなDB運用に役立ててください。