なぜ RDS for Oracle でデータマスキングが必要なのか
本番データベースの検証用コピーを開発チームや外部委託先に渡す場面は珍しくありません。ところが、氏名やメールアドレス、生年月日、クレジットカード番号といった機密情報をそのまま渡してしまうと、GDPR や HIPAA、PCI DSS といった規制への抵触や情報漏えいのリスクに直結します。とくに Amazon RDS for Oracle では、スナップショットから検証環境をすぐに復元できる手軽さがある反面、非本番環境ではセキュリティグループの制限が緩くなりがちで、機密データがそのまま露出する温床になりやすいという事情があります。
そこで有効なのがデータマスキングです。データマスキングとは、機密データを現実的な架空の値へ恒久的に置き換える処理を指します。置き換えは不可逆であり、マスキング後のデータからは元の値を復元できません。だからこそ、本番相当の分量と分布を保ったまま、安全に共有できるデータセットを用意できます。この記事では、Amazon RDS for Oracle 上で静的マスキングを実装する具体的な手順と、マネージドサービスならではの注意点を、実装目線で整理します。
静的マスキングの全体像と準備するもの
今回扱うのは、Oracle Enterprise Manager（OEM）Cloud Control と、そのアドオンである Oracle Data Masking and Subsetting Pack を用いた静的マスキングです。静的マスキングは、データベース内の値を実際に書き換えてしまう方式で、マスキング済みのコピーを配布する用途に向いています。実行時にだけ見え方を変える動的な方式とは異なり、書き換え後のデータは元に戻せない点が特徴です。
準備するものは大きく三つあります。ひとつ目はマスキング対象となる RDS for Oracle インスタンスで、本番スナップショットから復元したコピーを使います。ふたつ目は OEM Cloud Control を動かす Amazon EC2 インスタンスです。参考構成としては m5.xlarge 以上のサイズと 100 GB 以上の EBS ストレージ、Oracle Linux 8 もしくは Red Hat Enterprise Linux 8 が挙げられます。みっつ目が Data Masking and Subsetting Pack のライセンスです。このパックは Oracle Enterprise Edition のオプションとして提供され、OEM に含まれてはいるものの利用には別途ライセンスが必要になります。エディションとライセンスの要件は事前に確認しておきます。
マスキング定義を作成する（ADM から生成スクリプトまで）
マスキングの設計は OEM のコンソール上で進めます。流れは四つのステップに分かれます。
最初に Application Data Model（ADM）を作成します。ここではマスキング対象のスキーマを取り込み、テーブル間の外部キー関係や参照整合性を OEM に理解させます。完全な ADM を作っておくことで、後段のマスキングでも参照整合性が自動的に維持されます。
次に機密列の自動検出を実行します。OEM がメールアドレスやクレジットカード番号、生年月日、年齢といった典型的な機密属性を含む列を洗い出してくれるため、手作業で列を探す負担を減らせます。続いてマスキング定義を作成し、検出した列ごとにどのフォーマットへ置き換えるかを指定します。ここで複数の環境にわたって同じ入力を同じ出力へ変換する決定論的なマスキングを選んでおくと、データベースをまたいだ整合性を保てます。最後にマスキングスクリプトを生成します。生成されたスクリプトは SQL ファイルとしてダウンロードでき、これを実際のデータベースへ適用していきます。
RDS 固有のスクリプト書き換えと実行
ここが Amazon RDS for Oracle 特有の勘所です。RDS はマネージドサービスであるため、OS へのログインができず、OEM から対象データベースへジョブを直接スケジュール実行することもできません。さらに、生成されたマスキングスクリプトには共有プールのフラッシュやチェックポイントを ALTER SYSTEM で発行する箇所が含まれますが、こうした操作は RDS では直接実行できません。そのため、スクリプトをそのまま流すとエラーになります。
対処は二段構えです。まず、スクリプト内で EXECUTE IMMEDIATE を使って発行している共有プールのフラッシュとチェックポイントの行を、無害な NULL; に置き換えます。そのうえで、スクリプト末尾の spool off の直前に、RDS の管理パッケージを使った同等の処理を追記します。
-- 置き換え前（OEMが生成した箇所）
EXECUTE IMMEDIATE 'alter system flush shared_pool';
EXECUTE IMMEDIATE 'alter system checkpoint';
-- 置き換え後（RDSでは NULL に無効化）
NULL;
-- spool off の直前に追記する
EXEC rdsadmin.rdsadmin_util.flush_shared_pool;
EXEC rdsadmin.rdsadmin_util.checkpoint;実行は SQL*Plus または SQLcl から行います。認証情報をスクリプトに直書きするのは避け、AWS Secrets Manager から実行時に取得する形にしておくと安全です。大規模なデータベースではマスキングに時間がかかり、接続断で処理が止まるおそれがあるため、nohup や screen を使ってバックグラウンドで走らせておくと安心です。
# Secrets Manager から接続情報を取り出して SQL*Plus へ渡す例
RDS_ENDPOINT="<endpoint>:<port>/<service-name>"
SECRET_ID="<secrets_manager_arn>"
{
aws secretsmanager get-secret-value \
--secret-id "$SECRET_ID" --region eu-central-1 \
--query SecretString --output text | \
jq -r '"CONNECT " + .username + "/" + .password + "@'"$RDS_ENDPOINT"'"'
echo "@masking_script.sql"
} | sqlplus -s /nolog
# 接続断に強い形で実行する
nohup ./run_masking.sh > masking.log 2>&1 &安全に運用するためのベストプラクティス
マスキングは必ず本番から復元したコピーに対して実行し、本番データベースそのものには決して適用しません。処理を始める前にはトリガーとマテリアライズドビューのリフレッシュを無効化し、完了後に再び有効化します。これを怠ると、マスキング中の書き換えが意図しない副作用を生むことがあります。加えて、静的マスキングは大量の REDO と UNDO を発生させるため、UNDO 表領域と一時表領域に十分な空き容量があるかを事前に確認しておきます。マスキングが終わったら、対象列が正しく置き換わっているか、参照整合性が保たれているか、行数が一致しているかを検証し、何をどうマスキングしたかを監査向けに文書化します。
データそのものだけでなく、周辺のハードニングも重要です。復元元となる RDS スナップショットは AWS KMS で暗号化し、IAM ポリシーで復元や共有ができる主体を絞り込みます。組織外への共有を防ぐにはサービスコントロールポリシー（SCP）の活用が有効です。OEM を動かす EC2 はセキュリティグループで到達範囲を限定し、IMDSv2 を有効化したうえで、AWS Systems Manager Session Manager 経由で運用すると踏み台を減らせます。一連のマスキング処理は Amazon EventBridge と AWS Step Functions で自動化しておくと、復元からマスキング完了までの機密データ露出時間を最小化できます。
まとめ
Amazon RDS for Oracle でのデータマスキングは、OEM と Oracle Data Masking and Subsetting Pack を軸に、ADM の作成から機密列検出、マスキング定義、スクリプト生成という王道の流れで設計できます。ポイントは、マネージドサービスの制約に合わせて生成スクリプトの ALTER SYSTEM を rdsadmin パッケージへ置き換えることと、スナップショット暗号化や決定論的マスキング、トリガーの無効化といった運用面の作法を守ることです。非本番環境へ本番相当のデータを安全に届ける仕組みとして、ぜひ検証環境で手順を試してみてください。
