5 データ・サブセッティング
この章では、単一のタスクフローでデータ・マスキングとサブセッティングを実行する統合されたサブセットとマスク機能について説明し、そのプロセスを実証するためにいくつかのシナリオの概要を示します。データ・サブセッティング機能を使用するには、Oracle Data Masking and Subsetting Packライセンスが必要です。
注意:
データ・サブセット化は、Oracle Databaseバージョン10.1以上でのみサポートされています。この章の手順は、Oracle Enterprise Manager Cloud Control 12.1以上のみに適用されます。
データ・セブセット定義の作成
この項で説明する手順では、サブセット定義の作成後、そのプロパティを編集したりサブセット定義をエクスポートするなどのタスクを実行するサブセット・データベースを作成できます。
このインタフェースでは、サブセットの定義の作成時に、インラインまたはソースでマスキングを実行できます。
-
Enterprise Manager Cloud Controlユーザーの
EM_ALL_OPERATOR
注意:
次の権限を持っている場合、EM_ALL_OPERATOR権限は必要ありません。
ターゲット権限(すべてのターゲットに適用可能):
-
表示可能な任意のターゲットに接続
-
任意の場所でのコマンドの実行
-
任意のターゲットの表示
リソース権限:
-
ジョブ・システム
-
名前付き資格証明
-
Oracle Data Masking and Subsettingのリソース権限
-
-
データベース・ユーザーの
SELECT_ANY_DICTIONARY
権限 -
インプレース削除操作を実行するには、DBAユーザーは、
EXECUTE_ANY_TYPE
権限が付与されている必要があります。 -
仮想プライベート・データベース(VPD)・ポリシーを持つ表をサブセッティングするには、サブセッティングを実行するユーザーは
Exempt Access Policy
権限を付与されている必要があります。
データ・サブセット定義を作成するには:
-
「エンタープライズ」メニューから「クオリティ管理」を選択し、次に「データ・サブセッティング定義」を選択します。
-
「データ・サブセッティング定義」ページで「アクション」メニューを開き、「作成」を選択するか、または「作成」アイコンをクリックします。
-
データ・サブセット定義のプロパティを定義します。
-
表示された一般ポップアップで必要な情報を指定し、「続行」をクリックします。
アプリケーション・データ・モデルと関連付けられているいずれかのソース・データベースを選択できます。
サブセット定義内でマスキングを行う場合、マスク定義の作成時に使用した同じADMおよびターゲットを使用する必要があります。
-
ジョブ名、資格証明を指定し、表示される「アプリケーション詳細コレクションのスケジュール」ポップアップでスケジュールを指定して、「発行」をクリックします。
新しい資格証明を使用する場合は、「新規資格証明」オプションを使用します。それ以外の場合は、「優先資格証明」オプションまたは「名前付き資格証明」オプションを使用します。
容量の見積りの収集ジョブが実行され、データ・サブセット定義ページが表示されます。表に定義が表示され、「最新のジョブ・ステータス」列に、選択されているスケジュール・オプション、およびジョブを完了するために必要な時間に応じて、「スケジュール済」、「実行中」または「成功」が示されます。
-
-
表内の定義を選択し、「アクション」メニューを開き、「編集」を選択します。
「データベース・ログイン」ページが表示されます。
-
優先資格証明を設定していない場合は「名前付き資格証明」または「新規資格証明」を選択し、「ログイン」をクリックします。
-
「編集」ページの「アプリケーション」サブページで、アプリケーションを次のように「使用可能」リストから「選択済」リストへ移動します。
-
データのマスキングのみを行う(サブセット化は行わず)場合は、すべてのアプリケーションを選択します。
-
データのサブセット化のみを行う(マスキングは行わず)場合は、必要な適切なアプリケーションを選択します。
-
データのサブセット化およびマスキングを両方とも行う場合、マスキング定義で必要なアプリケーションを選択する必要があります。
アプリケーション・スイート、アプリケーションまたはアプリケーション・モジュールの名前はアプリケーション・データ・モデル内に保持されています。
-
-
「オブジェクト・ルール」タブをクリックします。
注意:
マスキングのみを行う場合は、すべての行が含まれるように「デフォルト・オブジェクト行」オプションを設定し、ステップ13に進みます。「列マスク・ルール」タブ、「ルール・パラメータ」タブおよび「オブジェクト・ルール」タブ上のその他の機能は、特にサブセッティングに関連があります。
ここでルールを追加し、サブセットに含めるデータを定義できます。
-
「アクション」を選択し、「作成」を選択して「オブジェクト・ルール」ポップアップを表示するか、「作成」アイコンをクリックします。
-
すべてのオブジェクト、特定のオブジェクトまたは特定のオブジェクト・タイプとルールを関連付けます。
-
「含める行」セクションで「すべてのオブジェクト」を選択する場合、行の割合部分で行のすべての行または一部の行を選択します。
-
オブジェクト・タイプとして「指定済」を選択した場合、選択したアプリケーションからの表がドロップダウン・リストに表示されます。
「含める行」セクションで行の割合部分ですべての行または一部の行を選択します。より細かいレベルで、region_id=6などのWhere句を指定できます。
選択した表がパーティション化されている場合は、「パーティションの追加/削除」をクリックし、サブセットに含める必要のあるオブジェクトのパーティションおよびサブパーティションを選択します。
-
「関連行を含む」セクションで、次のいずれかを実行します。
-
このルールは、親列および子列に影響を与えますが、参照整合性が保持され、サブセットの一部として子列も選択されます。
-
グローバル・ルールが「すべての行を含む」に設定されると、このオプションは使用不可になり、「行を含まない」に設定されると使用可能になります。このルールは、親列にのみ影響し、参照整合性が保持されます。
グローバル・ルールが「行を含まない」に設定されると、このオプションは使用不可になり、「すべての行を含む」に設定されると使用可能になります。
Oracle Data Masking and Subsettingリリース13.2では、ルール・スコープを「関連行を含む」に設定して、グローバル・スコープを「すべての行を含む」に設定、またその逆も設定できるようになりました。さらに、関連性のないすべての表は、グローバル・ルール「すべての行を含む」を使用して処理されます。
「関連行を含む」チェック・ボックスを無効にすると、参照整合性が保持されない場合があります。ただし、関連する表に追加のルールを指定して、参照整合性をリストアすることもできます。Where句を指定するかどうかによって、このチェック・ボックスを無効にできます。
-
-
Where句を指定する場合、次のステップに進みます。そうでない場合は、ステップ9に進みます。
-
たとえば、従業員IDの値をemployee_id=:emp_idとして指定する場合、デフォルトの100に問合せ値を入力できます。
-
「行」ボタンを選択して、employee_id=:emp_idを入力します。
-
「OK」をクリックしてルールを保存し、「オブジェクト・ルール」タブに戻ります。
これが新しいルールである場合、「バインド変数emp_idに対応するルール・パラメータは、サブセットを生成する前に作成する必要があります。」という警告が表示されます。
-
表ルールを選択して、「ルール・パラメータ」タブをクリックしてから「作成」をクリックします。
ルール・パラメータのプロパティ・ポップアップが表示されます。
-
「名前」にemp_id、「値」に100を入力します。
注意:
emp_idの前にあるコロン(:)はWhere句内にのみ存在し、新規ルール・パラメータの作成時には必要ありません。
-
「OK」をクリックしてプロパティを保存すると、「ルール・パラメータ」タブに表示されます。
-
ステップ10に進みます。
-
-
-
「OK」をクリックしてルールを保存し、「オブジェクト・ルール」タブに戻ります。
リスト内に新規ルールが表示されます。その下の表に、関連オブジェクトが表示されます。オブジェクトからの関連行は、サブセット・データベース内の参照整合性を維持するために、サブセットに含まれています。
-
「オブジェクト・ルール」タブの「関連オブジェクト」セクションで、サブセット内の祖先および子孫のレベルを制御することで、サブセットのサイズを管理できます。表内の各ノードにはチェック・ボックスがあります。デフォルトでは、チェック・マークで示されたように、すべてのノードはサブセットに含まれます。サブセットからノードを除外するには、チェック・ボックスを選択解除します。選択解除オプションは親行には無効になります(右側の結合列は親行および子行を識別します)。また、サブレットのコンテンツに次のような他の絞込みを行うこともできます。
-
「親オブジェクトの除外を許可」をクリックします。これにより、グレー表示されていたチェック・マークが有効になります。チェック・ボックスを選択解除することによって、サブセットから親行を選択して除外できます。
-
表内のノードを選択し、子孫の追加をクリックして、関連行を含めます。開いているダイアログで適切に選択して、「OK」をクリックします。
これらの絞込みを行うと、右側の列は、サブセットの容量の見積りへの影響を反映します。また、「関連オブジェクト」セクションは、祖先および子孫の表の処理順序を示し、各オブジェクトを含めることの影響が詳細に表示されます。絞込みが終了したら、「容量の見積もり」タブに移動して、サブセットの全体のサイズへの影響の、より詳細な粒度を表示します。
-
-
「オブジェクト・ルール」タブの「デフォルト・オブジェクト行」セクションで、サブセットに定義されたルールの影響を受けないオブジェクトを含めるか除外するかを選択します。
「すべての行を含む」オプションを選択すると、オブジェクトのすべての行がサブセットの一部として選択されます。
これは、グローバル・ルールで、サブセット全体に適用されます。すべてのルールの有効範囲が「指定しない」の場合、「すべての行を含む」オプションのみを選択できます。「オブジェクト・ルール」ポップアップで「関連行を含む」オプションの選択を解除すると、有効範囲が「なし」に設定されます。
注意:
列ルールを持つサブセット定義の場合は(ステップ12を参照)、対応するオブジェクトが含まれるように、オブジェクト・ルールを使用してください。必要に応じて、「デフォルト・オブジェクト行」オプションを使用して、オブジェクト・ルールの影響を受けないすべてのオブジェクトを含めることもできます。
-
オプション: インライン・マスキングをサブセット定義の一部として実行するには、「列マスク・ルール」タブをクリックします。
-
「作成」をクリックし、スキーマ内の列をフィルタ処理するための検索基準を入力します。通常これらは、CLOBやBLOBなどの垂直列です。
注意:
マスキング定義(ステップ13を参照)のかわりに列マスク・ルールを使用する場合、特定の表で選択できるのは10列までです。この制限は、エクスポート・メソッドに該当し、インプレース削除メソッドには該当しません。
「OK」をクリックします。
-
列の検索結果で行を1つ以上選択し、「マスキング・フォーマットの管理」をクリックします。
-
ポップアップ・ダイアログで、列に適用するマスキング・フォーマットと値を選択します。複数選択する場合は、1つのフォーマットがすべての列に対して適切であることが必要です。列を複数選択する場合は、選択する列のルール・フォーマットを選択された列に適用できることを確認してください。コンプライアンスに準拠するには、nullではなく、一意の列(フラグ)を使用します。
「OK」をクリックして、列にマスキング・フォーマットを適用します。
-
-
オプション: サブセッティング操作の一部にマスキング定義を含めるか、ソース・データでのみマスキングを実行するには、「データ・マスキング定義」 タブをクリックします。
-
「追加」をクリックします。
-
ポップアップ・ダイアログで、適切な定義を取得する検索基準を入力します。必要なラジオ・ボタン(「すべて」または「任意」)を必ず選択してください。インライン・マスキングでは、複合マスキングを除く、すべてのフォーマットがサポートされています。
注意:
エクスポート・メソッドを使用する場合、マスキング定義内のどの表のマスクされた列数も10を超えないようにする必要があります。この制限は、インプレース削除メソッドには該当しません。
「OK」をクリックします。
検索結果が「データ・マスキング」表に表示されます。
-
-
「容量の見積もり」タブをクリックします。
-
「推定サブセット・サイズMB」列の値に注意してください。容量の見積りは、オプティマイザ統計に依存し、ヒストグラム統計が存在する場合は、実際のデータの配分のみが計算されます。
-
新規ルールを追加する場合は常に、更新値の容量の見積りを再確認します。
-
「容量の見積もり」サブページのデータは、一番大きなアプリケーションが一番上に表示されるようにソートされています。
注意:
容量の見積りは、dbms_stats.gather_table_statsが使用されている場合にのみ正確です。また、データ・マスキングが使用されている場合、その影響は容量の見積りに反映されません。
Where句とそれに続くルール・パラメータ・プロパティを指定すると、「ルール・パラメータ」タブに含まれる値で容量の見積もりサブページが更新されます。
-
-
オプション: 「サブセット前/後スクリプト」タブをクリックします。
-
サブセット・データを選択する前にサブセット・データベースで実行するサブセット前スクリプトを指定できます。
-
サブセット・データをアセンブルした後にサブセット・データベースで実行するサブセット後スクリプトを指定できます。
-
どちらのスクリプト・タイプも、ソース・データベースで実行されます。
注意:
サブセット前またはサブセット後のスクリプトに定義されているPL/SQLブロックの末尾に「/」がついていることを確認してください。
-
-
「戻る」をクリックします。
定義が完了し、「データ・サブセッティング定義」表に表示されます。
これで、スクリプトの生成を続行できます。または、今後使用するために、スクリプトを保存することも可能です。どちらの場合でも、ダンプ・ファイルにデータをエクスポートするか、ターゲット・データベースからデータを削除するかを決定する必要があります。
ヒント:
たとえば、4TBの非常に大きなデータベースがあり、10%などの少量の行をエクスポートする場合、エクスポート・メソッドを使用すると利便性が高まります。インプレース削除メソッドを使用するには、3.6TBのデータが必要で、エクスポート・メソッドのように速くは行われません。
削除されるデータの量がデータ・サイズ全体の少量である場合は、インプレース削除メソッドをお薦めします。
インプレース削除をリモートで実行するか、それをスクリプト化する場合、EMCLI動詞があります。
サブセット・スクリプトの保存
サブセット・スクリプトを保存するためにジョブを準備して発行するには、次の手順に従います。
-
表内の定義を選択し、「アクション」メニューを開いて、サブセット・スクリプトの保存を選択します。サブセット・モード・ポップアップが表示されます。
-
サブセット・モデルの作成に使用したものと同じターゲット・データベースか、表スキーマやオブジェクトがこのデータベースに類似しているターゲット・データベースを選択します。
-
エクスポート・ファイルへサブセット・データを書き込む方法とターゲット・データベースからデータを削除する方法のどちらを使用してサブセットを作成するかを決定します。
データの削除を選択すると、本番データベースではなく本番データベースのクローン・コピーから不要なデータを削除することにより、インプレース・サブセットが作成されます。ルールを満たすデータのみが保持されます。このオプションは、本番データベースに対しては決して使用しないでください。
優先資格証明を設定していない場合は、名前付き資格証明または新規資格証明を選択します。
「ルール・パラメータ」タブからパラメータを定義した場合、それらのパラメータは下にある表に表示されます。パラメータの値は、「値」列の関連するフィールドをクリックすると変更できます。
-
「続行」をクリックして「パラメータ」ポップアップにアクセスします。ポップアップのコンテンツは、前のステップで、エクスポートと削除のどちらのオプションを選択したかに応じて異なります。
「エクスポート・ファイルへのサブセット・データの書込み」の場合は、必要な情報を指定し、「続行」をクリックしてジョブをスケジュールします。
-
エクスポート・ダンプを保存するサブセット・ディレクトリを指定します。ドロップダウン・リストは、アクセス権を持つディレクトリ・オブジェクトで構成されます。カスタムのディレクトリ・パスを選択することも可能です。外部ディレクトリを使用して処理を高速化する場合は、チェック・ボックスをクリックします。推奨されるデフォルト:
DATA_PUMP_DIR
。 -
デフォルトをオーバーライドする場合、適切な値を指定します。エクスポート・ファイルの名前を入力します。最大ファイル・サイズをMB単位で指定します。エクスポート・ジョブのために、アクティブな実行操作の最大スレッド数を指定します。これにより、リソース消費と経過時間のバランスを取ることができます。
-
サブセッティングされたデータのみをエクスポートするかサブセッティングされたデータとともにデータベース全体をエクスポートするかを指定します。
-
ダンプ・ファイルの圧縮および暗号化を有効にするかどうかを選択します。該当する場合は、暗号化パスワードを入力して確認します。デフォルトでは、ログ・ファイルの生成が選択されています。
「ターゲット・データベースからのデータの削除」の場合は、必要な情報を指定し、「続行」をクリックしてジョブをスケジュールします。
-
サブセット・スクリプトを保存するサブセット・ディレクトリを指定します。ドロップダウン・リストは、アクセス権を持つディレクトリ・オブジェクトで構成されます。カスタムのディレクトリ・パスを選択することも可能です。推奨されるデフォルト:
DATA_FILE_DIR
。 -
先に進むには選択したターゲットが本番データベースでないことを示すチェック・ボックスを有効にする必要があります。
-
-
「続行」をクリックします。進行状況インジケータにより、スクリプトの生成が追跡されます。完了すると、スクリプトの生成結果が「ファイル」表にリストされます。
-
「ダウンロード」をクリックします。表示される「ファイルのダウンロード」ポップアップで、「保存」をクリックします。
-
表示される「別名保存」ポップアップで、ファイルの場所にナビゲートし、「保存」をクリックします。
スクリプト(SubsetBundle.zip)を含むファイルが、デスクトップの指定された場所に表示されます。
保存したスクリプトを後から実行するには、次の手順に従います。
サブセット・テンプレートおよびダンプのインポートとエクスポート
サブセット・テンプレートは、アプリケーション、サブセット・ルール、ルール・パラメータおよび前処理スクリプトまたは後処理スクリプトから構成されるサブセットの詳細を含むXMLファイルです。サブセット定義を作成して、サブセット・データを書き込んでファイルをエクスポートするよう指定すると、エクスポート・ファイルは後で再利用してインポートできるテンプレートになります。テンプレートをインポートして、異なるデータベースでサブセット操作を実行します。
通常、ワークフローは、ADMの作成中に、まず以前にエクスポートした他のXMLファイルであるADMテンプレートをインポートします。その後、データ・サブセット定義の作成中に、関連するサブセット・テンプレートをインポートします。かわりに、サブセット・テンプレートの作成中に、既存のADMを選択(ADMのインポート・フローを省略)することもできます。
注意:
サブセット定義およびサブセット・ダンプのエクスポートおよびインポート操作をリモートで実行またはスクリプト化する場合に、これらの操作を実行するためのEMCLI動詞があります。
サブセット定義のインポート
デスクトップからのサブセット定義XMLファイルのインポート
-
「アクション」メニューから「インポート」を選択し、次に「デスクトップのファイル」を選択します。
-
表示されるポップアップで、次を行います。
-
サブセット定義の名前を指定します
-
サブセットが元にするADM
-
ソース・データベース。
-
サブセット定義のインポート元にするデスクトップ上の場所
-
「続行」をクリックします。
-
-
表示されるポップアップで、次を行います。
-
説明的なジョブ名を入力します(またはデフォルトを使用します)
-
資格証明を指定します。
-
ジョブをスケジュールします。
-
「発行」をクリックします。
-
ジョブが正常に実行されると、データ・サブセット定義ページにある表のサブセットのリストに、インポートされたサブセットが表示されます。
サブセット・ダンプのインポート
-
「アクション」メニューから「インポート」を選択し、次に「サブセット・ダンプ」を選択します。
-
表示されるポップアップで、次を行います。
-
ターゲット・データベースを選択します
-
データベースおよびホスト資格証明を指定し、「ログイン」をクリックします。
-
ダンプ・ファイルの場所を指定します。ターゲット・データベース上の選択したディレクトリ、またはターゲット上のカスタム・パスを指定できます。ダンプ・ファイルの元のエクスポート・アクションで外部の場所を使用した場合、その場所も指定する必要があります。
-
「続行」をクリックします。
-
-
表示されるポップアップで、次を行います。
-
メタデータとデータの両方をインポートするか、またはデータのみをインポートするかを選択します。データのみの場合、切り捨てるか、つまり、既存のデータをオーバーレイするか、既存のデータに追加するかどうかを示します。
-
タイプまたはオブジェクトの作成中にOID変換を有効にして新しいOIDを作成します。
新しいOIDを作成すると、オブジェクトを指すREF列でブレークが生じます。
-
ターゲット・データベースでデフォルト表領域を使用するか、既存の表領域から別の表領域へ再マップするかを指定します。
-
必要に応じて、表領域の再マッピングを実行します
-
宛先スキーマで既存の表を保持するか、宛先スキーマで既存の表を削除するかを指定します。
-
必要に応じて、スキーマの再マッピングを実行します
-
ログ・ファイル・オプションを選択します
-
「続行」をクリックします。
-
-
表示されるポップアップで、次を行います。
-
説明的なジョブ名を入力します(またはデフォルトを使用します)
-
ジョブをスケジュールします。
-
「発行」をクリックします。
-
ジョブは、ダンプ・ファイルを読み取り、選択したターゲット・データベースにデータをロードします。
ソフトウェア・ライブラリからのサブセット定義XMLファイルのインポート
-
「アクション」メニューから「インポート」を選択し、次に「ソフトウェア・ライブラリのファイル」を選択します。
-
表示されるソフトウェア・ライブラリからのデータ・サブセット定義のインポート・ポップアップで、次を行います。
-
左側で目的のサブセット定義XMLファイルを選択します
-
右側でADMプロパティを指定します。
-
「続行」をクリックします。
-
-
表示されるポップアップで、次を行います。
-
説明的なジョブ名を入力します(またはデフォルトを使用します)
-
資格証明を指定します。
-
ジョブをスケジュールします。
-
「発行」をクリックします。
-
ジョブが正常に実行されると、データ・サブセット定義ページにある表のサブセットのリストに、インポートされたサブセットが表示されます。
ターゲット・データベースのサブセット・バージョンの作成
サブセットが定義、分析および検証された後、サブセット操作を実行してソース・データのサブセット・バージョンを作成できます。
この手順は、次の条件を前提としています。
-
データベースのサブセット作成に必要なルールが含まれるサブセット定義がすでに存在しています。
-
ソースからデータを抽出し、ターゲット・データベースのサブセット・バージョンを作成するのに必要な権限があります。サブセット技術に応じて、様々なレベルのファイルまたはデータベース権限を作成できます。次の権限が必要となります。
-
ターゲット権限(すべてのターゲットに適用可能):
-
表示可能な任意のターゲットに接続
-
任意の場所でのコマンドの実行
-
任意のターゲットの表示
-
-
リソース権限:
-
ジョブ・システム
-
名前付き資格証明
-
Oracle Data Masking and Subsettingのリソース権限
注意:
Enterprise Manager Cloud Controlユーザーのための
EM_ALL_OPERATOR
権限には、前述のすべての権限が含まれています。 -
-
データベース・ユーザーの
SELECT_CATALOG_ROLE
-
データベース・ユーザーの
SELECT ANY DICTIONARY
権限 -
ターゲット・データベース・ユーザーのデータベースのDBA権限
-
-
また、インプレース削除操作を実行するには、DBAユーザーは、
EXECUTE_ANY_TYPE
権限が付与されている必要があります。
ターゲット・データベースのサブセット・バージョンを作成するには:
-
サブセット定義を選択し、これをソース・データベースに関連付けることにより、サブセット操作を作成します。
ソース・データベースに対してサブセット定義が検証され、スキーマの差異にフラグが設定されます。このアソシエーションは、アプリケーション開発者が作成した元のアソシエーションとは異なる可能性があります。
-
定義を編集し、定義されているスキーマをテスト・スキーマに再マップします。
データベースに接続するよう求められ、このデータベースは、サブセット定義に関連付けられます。これにより、ベンダーによって指定されたスキーマ名をデータベース内の実際のスキーマ名に再マップすることもできるようになります。
-
様々なサブセット作成技術の1つを選択します。
-
データ・ポンプ・ダンプ・ファイルとそれに続くデータ・ポンプ・インポート
-
インプレース削除(ルール条件に一致しない指定したデータベースの行が削除される)
-
移動中のサブセット作成またはリフレッシュ
適切なレスポンス・ファイル(SQLスクリプト、データ・ポンプ・スクリプトまたはOSスクリプト)が生成され、操作を続行するのに適した権限についてターゲット・システムが確認され、ターゲットのサイズが見積もられます。
-
-
分析を確認した後、サブセット・プロセスを発行します。
Enterprise Managerにより、サブセット・プロセスが実行され、実行の結果がまとめられます。
アプリケーション・データ・モデルによるサブセット定義の同期化
たとえば、ADMへの変更、参照関係の追加または表の削除で、失効したサブセット定義をレンダリングできます。「サブセット定義」ページには、この条件が明確に示され、サブセット名および無効なステータスの横にロック・アイコン表示されます。また、「アクション」メニューのほとんどのメニュー項目は無効になります。ステータスを有効に戻し、サブセット定義のロック解除するには、関連付けられたADMと定義を同期する必要があります。
サブセット定義での権限の付与
他のユーザーがアクセス権を持つことができるように、作成するサブセット定義で権限を付与できます。これを行うには、少なくともサブセット定義にデザイナ権限を持つEnterprise Manager管理者である必要があります。
テスト・データ管理領域内の権限の詳細は、「Oracle Data Masking and Subsettingのアクセス権」を参照してください。
インライン・マスキングおよびサブセット化について
機密データのマスキングと同時に、データベースのサイズを減らすことができます。これは、テスト用にマスクされた大きい本番データベースの格納に関連するハードウェアのコストを大幅に減らすと同時に、エクスポートされた本番データを曖昧にする、二重の役割を果たします。
注意:
インライン・マスキングは、Oracle Database 11g 以上のリリースでのみ使用可能です。
データ・マスキングをサブセット化と統合する利点は、次のとおりです。
-
単一のフローでテスト・システムを準備します
-
テストの目的で、大きいサイズのマスクされたデータベースを維持する必要がなくなります
-
ダンプ・ファイルの形式でエクスポートされたデータは、機密データを公開せずに、複数のデータベースにインポートできます
-
大きいデータ・チャンクを含む列を破棄する機能によって、サブセット化が強化されます
サブセットの作成中に、1つ以上のデータ・マスキング定義を選択できます。マスキング定義は、現在のサブセット定義と同じADMに基づいている必要があります。同時に、CLOB列およびBLOB列をNull (または、Fixed StringやFixed Numberなど、別のサポートされた形式)に設定するよう、列ルールを定義することによって、サブセット・サイズを大幅に減らすことができます。
次の2つの方法で、サブセットを生成します。
-
エクスポート・ダンプ: マスキング定義がサブセット・モデルの一部である場合、マッピング表は生成中に作成され、結果となるダンプには、マスクされた値が含まれます。
-
配置された削除: 本番データベースのクローニングされたコピーでサブセット化が実行されます。データ・マスキングがサブセット・モデルの一部である場合、事前生成されたマスキング・スクリプトがターゲット上で連続して実行されます。
インライン・マスキングの利点は、次のとおりです。
-
機密データは本番環境に残らないため、公開されません(エクスポート・ダンプ・オプション)。
-
一時的にデータをステージング領域に格納する必要がありません。
-
エクスポートされたデータは、後で複数の環境にインポートできます。
-
データのサブセットのみをエクスポートする表ルールを定義でき、列ルールを使用してさらにボリュームを減らして、大きい垂直列を削除できます。
-
同じデータを異なる方法でマスクし、異なるテスト・データベースにインポートできます。
-
プロビジョニング・フレームワークを使用して、機密ではないデータを含む、縮小された参照用の完全なデータベースの複数のコピーを作成する(配置された削除)か、またはダンプ・ファイルを複数のデータベースにインポート(エクスポート・ダンプ)できます。
「データ・サブセット定義の作成」の項では、サブセット定義を作成する際に、データのサブセット化およびデータ・マスキングも一緒に実行する手順を説明します。データ・マスキングおよびデータ・マスキングの定義の作成の詳細は、「データ・マスキング」を参照してください。
インライン・マスキングおよびサブセット化のシナリオ
後述のシナリオでは、機密列の詳細が取得される本番(またはテスト)データベース用に、アプリケーション・データ・モデル(ADM)が存在すると想定します。示すステップは、高レベルです。マスキング定義の作成の詳細は、「アプリケーション・データ・モデルおよびワークロードによるマスキング」、サブセット定義の作成および編集の詳細は、「データ・サブセット定義の作成」を参照してください。
ライフサイクル管理
この項では、アプリケーション・データ・モデル、データ・マスキングおよびデータ・サブセッティング定義のライフサイクル管理について説明します。
Enterprise Managerユーザーが削除または変更された場合、ユーザーはアプリケーション・データ・モデル、データ・マスキングおよびデータ・サブセッティングの定義をシステム内の別のユーザーに再割当てできます。ただし、ユーザーがアプリケーション・データ・モデル、データ・マスキングおよびデータ・サブセッティングの定義を別のユーザーに再割当てしない場合、これらの定義はSYSMANユーザーに再割当てされます。
システム内の別のユーザーへのアプリケーション・データ・モデル、データ・マスキングおよびデータ・サブセッティング定義の再割当てを試みたとき、再割当てされたユーザーがすでに同じ名前の定義を持っていた場合は、元の定義の名前が変更されます。
たとえば、ユーザーAがADM1というアプリケーション・データ・モデルを持ち、ユーザーBもADM1という名前のアプリケーション・データ・モデルを持っているとします。ユーザーBを削除し、その定義をユーザーAに割り当てることを選択した場合、元の定義ADM1は、ADM1_Bという名前に変更されます。同じ名前を持つ元の定義は、接尾辞"_"を付けられ、削除されるユーザー名を付加されます。再割当ての後、ユーザーAは、ADM1およびADM1_Bの両方の定義を持つことになります。