Amazon RDS for Oracle でのデータマスキング

本記事は 2026 年 7 月 2 日に公開された「Data masking in Amazon RDS for Oracle」を翻訳したものです。

Oracle データベースを Amazon Relational Database Service (Amazon RDS) for Oracle に移行する際、クラウドで再確立すべき重要な運用プラクティスの 1 つが、本番相当のデータで非本番環境を安全にリフレッシュすることです。オンプレミスでは、本番環境をクローンし、機密データをマスキングして開発者やテスターに引き渡すという標準的なプロセスがありました。データマスキングは機密情報を現実的な架空の値で恒久的に置き換えるため、テスト環境は本番環境と同じ構造、パターン、規模を維持できます。顧客情報への意図しないアクセスを避けつつ、意味のあるテストが可能になります。

Amazon RDS for Oracle ではオンプレミスと同レベルのインフラストラクチャ制御はできませんが、データマスキングの全体的なアプローチは同様です。Oracle の Data Masking and Subsetting Pack によるデータマスキングは Amazon RDS for Oracle でも動作するため、オンプレミス環境で使っていたデータガバナンスのワークフローをクラウドでも維持できます。

本記事では、Oracle Data Masking and Subsetting Pack を Amazon RDS for Oracle で使用する方法を説明します。Oracle Enterprise Manager (OEM) を使ったデータマスキングのセットアップ方法と自動化オプションを取り上げます。

クラウドでデータマスキングが重要な理由

コンプライアンス要件はクラウドでも変わらない: GDPR、HIPAA、PCI DSS への準拠要件は、オンプレミスと同様に RDS にも適用されます。
RDS DB スナップショット: マスキングせずに RDS DB スナップショットを下位環境に復元すると、非本番環境で機密データが露出します。さらに、開発やテスト用のデータベースは一般的にセキュリティグループの制限が緩く、AWS Identity and Access Management (IAM) ロールが多く、認証情報が共有されがちです。マスキングしておけば、こうした環境で意図しないアクセスが発生しても、実データの露出を防ぐのに役立ちます。
サードパーティによる開発には安全なデータが必要: 外部委託の開発チームは現実的なデータを必要とします。マスキング済みの RDS クローンなら、実際の顧客情報を露出させずに本番品質のデータセットを共有できます。
オンプレミスのワークフローの維持: すでにオンプレミスのデータのマスキングに Oracle Enterprise Manager を使用している場合は、RDS for Oracle でも同様のアプローチを使用できます。

Oracle Data Masking and Subsetting Pack

Oracle は Data Masking and Subsetting Pack を Oracle Enterprise Manager (OEM) Cloud Control のアドオンとしてライセンス提供しています。参照整合性の維持、機密データの検出、柔軟なデプロイといったデータマスキング機能を備えています。このパックは Oracle のデータ型、制約、リレーションシップをネイティブに理解するため、複雑な Oracle ワークロードに適しています。

RDS for Oracle での仕組み

Oracle Data Masking and Subsetting Pack は Oracle Enterprise Manager (OEM) Cloud Control を通じて動作し、RDS for Oracle DB インスタンスに管理対象ターゲットとして接続します。OEM は別の Amazon Elastic Compute Cloud (Amazon EC2) インスタンス上で稼働し、ネットワーク経由で RDS と通信します。RDS ホストへの OS レベルのアクセスは不要です。

RDS DB スナップショットの取得と復元: 本番の RDS for Oracle DB インスタンスの RDS DB スナップショットを取得し、新しい RDS for Oracle DB インスタンス (ターゲット/クローン) として復元します。
OEM の接続: Amazon EC2 上の OEM Cloud Control が RDS for Oracle DB インスタンス (ターゲット/クローン) に接続します。マスキングスクリプトは OEM で生成してダウンロードします。
マスキング: マスキングスクリプトをターゲット/クローンの RDS for Oracle DB インスタンス上で手動で実行し、機密データをその場で置き換えます。
結果: ターゲット/クローンの RDS for Oracle DB インスタンスにはマスキング済みデータが格納され、開発・テスト環境と共有できる状態になります。

前提条件

コストに関する考慮事項: 複数の RDS for Oracle DB インスタンス (Enterprise Edition) を実行するコストを考慮してください。

Amazon RDS for Oracle: Enterprise Edition (ソース/本番)。
Amazon RDS for Oracle: Enterprise Edition (ターゲット/クローン。本番の RDS DB スナップショットから復元)。
Oracle Enterprise Manager Cloud Control (13.5 または 24ai): ターゲット/クローンの RDS for Oracle DB インスタンスへのネットワーク接続を持つオンプレミス/Amazon EC2 インスタンスにインストールされていること。ターゲット/クローンの RDS for Oracle DB インスタンスでマスキングスクリプトを実行するための Oracle クライアント経由の接続。
Oracle Data Masking and Subsetting Pack のライセンス。
ターゲットの RDS for Oracle DB インスタンスに対する RDS 管理ユーザーのアクセス。

ステップ 1: Amazon EC2 に Oracle Enterprise Manager をデプロイする

RDS for Oracle DB インスタンスと同じ Virtual Private Cloud (VPC)、またはピアリングされた VPC に Amazon EC2 インスタンスを起動します。推奨構成は m5.xlarge 以上、100 GB 以上の Amazon Elastic Block Store ストレージ、Oracle Linux 8 または Red Hat Enterprise Linux (RHEL) 8 です。注: 100 GB 以上の EBS ストレージを持つ m5.xlarge EC2 インスタンスの実行には継続的な料金が発生します。AWS Pricing Calculator でコンピューティングとストレージのコストを確認してください。
Oracle Enterprise Manager Cloud Control 24ai (または 13.5) をインストールして設定します。

ステップ 2: RDS DB スナップショットを作成して復元する

マスキング対象の RDS DB インスタンスの RDS DB スナップショットを作成します。自動バックアップを使用してもかまいません。
RDS スナップショットを復元して、クローン/ターゲットの RDS DB インスタンスを作成します。
復元したクローン/ターゲットの RDS DB インスタンスのステータスが「available」になるまで待ちます。

ステップ 3: RDS DB インスタンスを OEM のターゲットとして登録する

オプショングループを使用する「Oracle Management Agent for Enterprise Manager Cloud Control」の説明に従って、OEM と RDS for Oracle の統合をセットアップします。

クローン/ターゲットの RDS for Oracle DB インスタンスを OEM の監視対象ターゲットとして登録する必要があります。

注: RDS for Oracle のマルチテナントまたはシングルテナント構成を使用している場合は、テナントデータベースが OEM のターゲットとして検出されていることを確認し、以降の手順にあるデータベース関連の操作はすべてテナントデータベースに対して実施してください。

以下の手順はすべて Enterprise Manager 24ai のコンソールを使用します。Enterprise Manager 13.5 での手順は「Data Masking and Subsetting」を参照してください。

ステップ 4: Application Data Model (ADM) を作成する

Application Data Model はすべてのマスキング操作の基盤です。スキーマ構造とテーブルのリレーションシップをマッピングし、機密性の高い列を特定します。

Enterprise > Quality Management > Application Data Models に移動します。
Create を選択します。
Create Application Data Model 画面で、次のプロパティを指定します。

ADM の Name を入力します。
ADM の Description を入力します。
Target Type には Database Instance を選択します。
Target Database には、ターゲット/クローンの RDS for Oracle DB インスタンスを選択します。
Database Named Credentials (role が normal の管理ユーザー) を選択します。
対象とする Schemas を選択します。
Relation Discovery Type には、Dictionary-Based または Non-Dictionary のいずれかを選択します。

Create を選択します。
ジョブのステータスが succeeded になるまで待ちます。OEM がテーブル、ビュー、主キー/外部キーのリレーションシップ、列のメタデータを検出します。

Screenshot of Oracle Enterprise Manager 24ai showing the Create Application Data Model dialog with fields for Name (DEMO1), Description (DATA MASKING DEMO), Target Type (Database Instance), Target Database (orcl-oem24-test1), Database Named Credentials (MASKING-DEMO-1), and Schemas (DEMO) selected.

Create Application Data Model 画面を表示した Oracle Enterprise Manager 24ai のスクリーンショット

ステップ 5: 機密データを検出する

前のステップで作成した ADM を選択します。
Discover Sensitive Columns を選択し、Schedule を選択します。
Create Sensitive Column Discovery Job 画面で、次のプロパティを指定します。

Database Named Credentials を選択します。
Applications にはスキーマを選択します。
Sensitive Types (Age、Credit Card Number、Date of Birth、Email ID など) を選択します。
Data Sample Size を指定します。

Submit を選択します。
ジョブのステータスが scheduled から succeeded に変わるまで待ちます。
機密列検出ジョブの結果を確認します。
検出された各列を確認し、Mark Sensitive、Mark Not Sensitive、Mark Undefined を選択して機密ステータスを必要に応じて調整します。

Screenshot of Oracle Enterprise Manager showing the Discover Sensitive Columns results for Application Data Model DEMO, displaying discovered sensitive columns including Date of Birth and EMAIL_ID marked as SENSITIVE with 100% data match quality.

Discover Sensitive Columns の結果を表示した Oracle Enterprise Manager のスクリーンショット

ステップ 6: マスキング定義を作成する

Enterprise > Quality Management > Data Masking Definitions に移動します。
Create を選択します。
Create Masking Definitions 画面で、次のプロパティを指定します。

定義の Name を入力します。
Application Data Model を選択します。
Associated Database を選択します。
Database Named Credentials を選択します。

Next を選択します。
機密性の高い列ごとに、次の手順を実施します。

Define Format and Add を選択します。
マスキングフォーマットを選択または定義します。
Add Format Entry を選択します。
Add を選択します。

Next を選択します。
Advanced Options 画面で、使用するオプションを選択します。
Next を選択します。
Review 画面で Create を選択します。

ステップ 7: スクリプトを生成してダウンロードする

Amazon RDS for Oracle はマネージドサービスであるため、OEM から RDS for Oracle DB インスタンスに対してマスキングジョブを直接スケジュールできません。OEM のジョブスケジューラはターゲットホストの OS レベルの認証情報を必要としますが、RDS では利用できません。代わりに、OEM でマスキングスクリプトを生成してダウンロードし、ターゲットの RDS for Oracle クローンに対して手動 (または自動化の仕組み) で実行します。

Masking Definition ページで、マスキング定義を選択します。
Actions を選択します。
Manage Masking Script を選択します。
Generate Masking Script を選択します。
Generate Masking Script 画面で、次のプロパティを指定します。

In-Data Masking Option を選択します。
Associated Database を選択します。
Database Named Credentials を選択します。

Generate を選択します。
ジョブのステータスが Script Generated に変わるまで待ちます。
Masking Definition を選択します。
Actions を選択します。
Manage Masking Script を選択します。
Download In-Database Masking Script を選択します。
生成されたスクリプトを確認します。

Amazon RDS for Oracle では、マネージドサービスのセキュリティのため、直接の ALTER SYSTEM コマンドが制限されています。OEM が生成するスクリプトにはこれらのコマンドが含まれており、RDS では失敗します。該当コマンドを NULL に置き換え、スクリプト末尾で RDS 固有の rdsadmin ユーティリティパッケージによる同等のコマンドを使用してください。RDS で承認された手段で同じフラッシュとチェックポイント操作を実現しつつ、マスキングスクリプトを正常に完了できます。

Replace:
EXECUTE IMMEDIATE 'alter system flush shared_pool';
EXECUTE IMMEDIATE 'alter system checkpoint';
With:
NULL;

RDS の同等のコマンドを、スクリプト末尾の「spool off」の前に追加します。

EXEC rdsadmin.rdsadmin_util.flush_shared_pool;
EXEC rdsadmin.rdsadmin_util.checkpoint;

ステップ 8: ターゲットのクローンでスクリプトを実行する

OEM のジョブスケジューラは RDS 上で直接実行できないため、ダウンロードしたマスキングスクリプトを SQL クライアント (SQL*Plus、SQLcl、SQL Developer) を使ってターゲットの RDS クローンに対して手動で実行します。

OEM/EC2 インスタンスから SQL*Plus または SQLcl でターゲット (クローン) の RDS for Oracle DB インスタンスに接続します。
ダウンロードしたマスキングスクリプトを実行します: @/path/to/downloaded/masking_script.sql
スクリプトが各テーブルを処理する際に出力されるステータスメッセージを確認して、実行の進捗をモニタリングします。
大規模なデータベースでは、切断の問題を避けるため、screen または nohup セッションでスクリプトを実行してください。

例

実行前:

データマスキング適用前の demo.customers テーブルの EMAIL 列と DATE_OF_BIRTH 列のデータを表示した SQL クエリ結果。

demo.customers table before masking, showing real email addresses and dates of birth in the EMAIL and DATE_OF_BIRTH columns

実行後:

マスキングされたメールアドレスと生年月日が表示された、demo.customers テーブルの EMAIL 列と DATE_OF_BIRTH 列のマスキング済みデータを表示した SQL クエリ結果。

SQL query result showing masked data from demo.customers table with columns EMAIL and DATE_OF_BIRTH, displaying masked email addresses and birth dates.

自動化に関する考慮事項

OEM のデータマスキングスクリプトはデフォルトで対話型であり、実行中に手動での入力が必要です。自動化するには、SQL*Plus や SQLcl への入力リダイレクトを使い、マスキングスクリプトをシェルスクリプトでラップします。スクリプトが必要とする入力を把握するため、自動化を実装する前にまず手動で実行してください。

アプローチの例

警告: ここで提供するスクリプトはデモ用です。組織のコーディングおよびセキュリティのベストプラクティスに従ってスクリプトを開発してください。

run_masking.sh スクリプト:

#!/bin/bash
# run_masking.sh
set -e

# Set Oracle environment from /etc/oratab
ORACLE_HOME=$(awk -F: '/^[^#]/{print $2; exit}' /etc/oratab)
export ORACLE_HOME
export PATH=$ORACLE_HOME/bin:$PATH
export LD_LIBRARY_PATH=$ORACLE_HOME/lib:${LD_LIBRARY_PATH:-}

RDS_ENDPOINT="<rds-instance-endpoint>:<port>/<service-name or pdb-name>"
SECRET_ID="<secrets_manager_arn>"

# Run masking script (note: when passing values to the sql script, use a blank line for the value if you are choosing the default)
{
aws secretsmanager get-secret-value \
--secret-id "$SECRET_ID" \
--region eu-central-1 \
--query SecretString --output text | \
jq -r '"CONNECT " + .username + "/" + .password + "@'"$RDS_ENDPOINT"'"'

cat <<SQLEOF
@masking202605251609.sql

N
N
3
USERS
SQLEOF
} | sqlplus -s /nolog

スクリプトをバックグラウンドで実行します。

nohup ./run_masking.sh > masking.log 2>&1

ワークフローを自動化するには、Amazon EventBridge Scheduler で AWS Step Functions ステートマシンの実行を開始します。AWS Step Functions がワークフロー全体をオーケストレーションします。

自動化フロー

自動化されたマスキングワークフローを示すアーキテクチャ図。

1. トリガー: Amazon EventBridge Scheduler が AWS Step Functions ステートマシンを開始します。

2. RDS DB スナップショットの復元: 本番の RDS DB スナップショットを一時的な RDS for Oracle DB インスタンスに復元します。復元した RDS for Oracle DB インスタンスのステータスが available になるまでポーリングします。

3. 認証情報の取得: Amazon EC2 が AWS Secrets Manager から Oracle のユーザー名とパスワードを取得します。

4. マスキングの実行: AWS Systems Manager の機能である Run Command が、Amazon EC2 上で SQL*Plus/SQLcl 経由のマスキングスクリプトを、復元した RDS for Oracle DB インスタンスに対して実行します。

5. マスキング済み RDS DB スナップショットの作成: マスキング済みデータベースの RDS DB スナップショットを取得します。

6. クロスアカウントでの共有/復元: マスキング済みの RDS DB スナップショットを開発/UAT アカウントと共有し、RDS DB スナップショットを復元します。

7. クリーンアップ: ステップ 10 のクリーンアップセクションを参照してください。

その他の考慮事項:

Amazon Simple Notification Service (Amazon SNS) で成功/失敗の通知を実装します。
RDS DB スナップショットの暗号化キーにターゲットアカウントがアクセスできることを確認します。

ステップ 9: マスキング済みデータを検証する

1. ターゲットの RDS for Oracle DB インスタンスに接続します。

2. 機密性の高い列が適切にマスキングされていること、参照整合性が維持されていること、行数が本番環境と一致していることを確認します。

ステップ 10: クリーンアップ

警告: リソースを削除する前に、次の点を確認してください。

ターゲットの RDS for Oracle DB インスタンスのマスキング済みデータが要件を満たしていること。
削除対象が正しい一時的な RDS for Oracle DB インスタンスであること (本番環境ではないこと)。
必要に応じて、RDS for Oracle DB インスタンスの最終スナップショットを作成すること。

不要になった一時的な RDS for Oracle DB インスタンスを削除します。
不要になった RDS DB スナップショットを削除します。

AWS ネイティブの代替手段 (概要)

AWS には、Oracle Data Masking and Subsetting Pack を追加しなくても利用できるクラウドネイティブなデータマスキングの選択肢があります。

AWS Glue Visual ETL: Detect Sensitive Data 変換は、RDS データベース間の ETL 処理中に 250 種類以上の個人を特定できる情報 (PII) を識別してマスキングできます。サーバーレスかつノーコードで、RDS for Oracle の各エディションで動作するように設計されています。詳細は「Copy and mask PII between Amazon RDS databases using visual ETL jobs in AWS Glue Studio」を参照してください。
AWS Database Migration Service (AWS DMS) のデータマスキング: 機密情報を保護しながら RDS for Oracle DB インスタンス間でデータをレプリケートする場合、AWS DMS が効率的なアプローチを提供します。バージョン 3.5.4 以降では、テーブルマッピングのデータマスキング変換ルールアクションで列の値を難読化または変更できます。ソースの RDS for Oracle DB インスタンスからターゲットへデータが移動する際に適用されます。個別のマスキングスクリプトやツールを必要とせずに、開発や QA といった非本番環境に最適なサニタイズ済みのデータベースコピーを作成できます。詳細は「Using data masking to hide sensitive information」を参照してください。

上記の AWS ネイティブアプローチはシンプルな PII マスキングシナリオに最適です。一方、参照整合性の維持、アプリケーションを考慮したマスキング、決定論的マスキング、フォーマットを維持する変換が必要な場合は、Oracle が Oracle Enterprise Manager (OEM) Cloud Control のアドオンとして Data Masking and Subsetting Pack を提供しています。

ベストプラクティス

マスキングは必ずコピーに対して行い、本番環境には行わない: マスキングは不可逆です。非本番環境のみをマスキングしてください。
マスキングルールを事前にテストする: マスキング済みデータがアプリケーションのロジックを壊さないことを確認します。
完全な Application Data Model を構築する: 適切に定義された ADM は、外部キーのリレーションシップと参照整合性を自動的に維持します。
一貫性のために決定論的マスキングを使用する: 同じ顧客が複数のデータベースに登場する場合、決定論的マスキングにより一貫したマスキング値を維持できます。
マスキング前にトリガーを無効化する: 開始前にトリガーとマテリアライズドビューのリフレッシュを無効にし、マスキング完了後に再度有効にします。
表領域をモニタリングする: マスキングは REDO と UNDO を生成します。一時表領域と UNDO 表領域に十分な空きがあることを確認してください。マスキング操作には追加のストレージも必要です。マスキング操作に必要な領域を計算してください。
マスキング内容を文書化する: どの列をどのようにマスキングしたかを記録しておきます。監査で必要になります。
ワークフローを自動化する: Amazon EventBridge と Step Functions で RDS DB スナップショットの復元後にマスキングを自動的に開始し、繰り返し実行できるリフレッシュパイプラインを構築します。
クリーンアップ: 不要になった一時的な RDS for Oracle DB インスタンスと RDS DB スナップショットを削除します。
マスキングされていない RDS DB スナップショットを保護する。RDS DB スナップショットには本番データの完全なコピーが含まれます。IAM ポリシーでスナップショットの復元や共有ができるユーザーを制限し、RDS DB インスタンスで AWS Key Management Service (AWS KMS) を使用して保管中のデータを保護します。AWS Organizations の組織外へのスナップショット共有を防ぐために、サービスコントロールポリシー (SCP) の使用を検討してください。
マスキングまでの時間を最小化する。スナップショットの復元からマスキング完了までの間、ターゲット環境にはマスキングされていない本番データが存在します。このリスクを軽減するには、次の対策を取ります。
- エンドツーエンドのワークフロー (復元 → 登録 → マスキング → 検証) を自動化し、人手による遅延なく完了させる。
- マスキングの検証が完了するまで、クローンの RDS DB インスタンスへの管理者以外のアクセスをブロックする。
- マスキングが確認されるまで、OEM の EC2 インスタンスからの接続のみを許可する専用のセキュリティグループを使用する。
OEM の EC2 インスタンスを保護する。このインスタンスにはデータベース認証情報が保存されており、RDS DB インスタンスへの管理者レベルの接続が可能です。次の対策で堅牢化してください。
- セキュリティグループを必要なポートのみに制限する。
- OS パッチを定期的に適用する。
- IMDSv2 を有効にして、サーバーサイドリクエストフォージェリ (SSRF) 攻撃による意図しない認証情報の漏洩を防ぐ。
- SSH の代わりに AWS Systems Manager Session Manager を使用する。
データベース認証情報をスクリプトに保存しない。ダウンロードしたマスキングスクリプトにはデータベース接続が必要ですが、認証情報は実行時に AWS Secrets Manager から取得すべきです。スクリプトファイルにハードコードしないでください。RDS の認証情報には自動ローテーションを設定します。
転送中の接続を暗号化する。OEM の EC2 インスタンス、SQL クライアント、RDS DB インスタンス間のすべての接続に、Oracle ネイティブネットワーク暗号化または Oracle Secure Sockets Layer を使用します。VPC 内での意図しない認証情報やデータの漏洩を防ぐのに役立ちます。

まとめ

本記事では、OEM Cloud Control を通じて Oracle Data Masking and Subsetting Pack を Amazon RDS for Oracle で使用する方法を説明しました。Application Data Model の作成と機密データの検出から、クローンした RDS for Oracle DB インスタンスでのマスキングスクリプトの生成と実行までを見てきました。

RDS DB スナップショットの取得と復元を OEM のマスキング機能と組み合わせることで、下位環境をプロビジョニングする際のコンプライアンス要件を満たしやすくなります。このアプローチにより、本番品質のテストデータを開発チームに安全に提供し、EventBridge と Step Functions でパイプラインを自動化できます。

RDS for Oracle Standard Edition を使用している場合や Data Masking and Subsetting Pack のライセンスがない場合は、AWS Glue や AWS DMS といった AWS ネイティブの代替手段により、追加の Data Masking and Subsetting Pack ライセンスなしでクラウドネイティブなマスキングが可能です。

著者について

この記事は Kiro が翻訳を担当し、Solutions Architect の Satoru Yagi がレビューしました。

Amazon Web Services ブログ