| Oracle® Database Advanced Securityガイド 12cリリース1 (12.1) B71313-13 |
|
 前 |
 次 |
Oracle Data Redactionは、他のOracle機能とともに使用できます。一部のOracle機能には、Oracle Data Redactionに関する制限がある場合があります。
内容は次のとおりです。
Oracle Data Redactionは、DMLおよびDDL操作に影響を与えます。特に、リダクションされた列を持つ表に対して非定型SQLを発行するユーザーがいる場合に、これが当てはまります。
次の点に注意してください。
Oracle Data Redactionは、結果は表示されませんが、DML文のRETURNING INTO句を問合せとして処理します。バッファに送信されるのは、RETURNING INTO句が通常のSQL問合せとして実行された場合に表示される結果で、DML文の一部として実行された場合の結果ではありません。アプリケーションがRETURNING INTOの値を格納したバッファ上でさらに処理を実行する場合、バッファ内でリダクションされた結果を検索することができないため、アプリケーションの変更を検討してください。
リダクションされた列がDMLまたはDDL操作のソースとして現れた場合、Oracle Data Redactionは、これをポリシーを回避する試みとみなし、EXEMPT REDACTION POLICYシステム権限がないかぎり、「ORA-28081: 権限が不十分です - コマンドはリダクション済のオブジェクトを参照しています。」エラーを表示して拒否します。内部ではOracle Data Pumpがこの種の操作を実行するため、リダクションされた列がある表のスキーマ・レベルのエクスポートを実行する必要があるユーザーには、EXEMPT REDACTION POLICYシステム権限の付与が必要になる可能性があります。
Oracle Data Redactionは、ネストした関数、インライン・ビュー、およびSELECT文のWHERE句と一緒に使用できます。
Oracle Data Redactionポリシーは次のように動作します。
ネストした関数は、最も内側からリダクションされます。たとえば、SELECT SUM(AVG(TO_NUMBER(((X))) FROM HR.EMPLOYEES WHERE ...では、最初にTO_NUMBERがリダクションされ、次にAVGが、最後にSUM関数がリダクションされます。
インライン・ビューは、最も外側からリダクションされます。たとえば、SELECT XYZ … AS SELECT A… AS SELECT B… AS SELECT C…では、最初にSELECT XYZがリダクションされ、次にAS SELECT A、その次にAS SELECT Bという順序でリダクションされます。AS SELECT Cは最後にリダクションされます。
WHERE句はリダクションされません。データ・リダクションでは、列のSELECTリストのデータのみがリダクションされます。
データベース・リンクを参照するデータベース・ビューでOracle Data Redactionポリシーを作成しないでください。
DBA_DB_LINKSデータ・ディクショナリ・ビューを問い合せることによって、既存のデータベース・リンクについての情報を検索できます。
関連項目:
データベース・リンクの詳細は、Oracle Database管理者ガイドを参照してください。
集計関数は、Oracle Data Redactionポリシーのパフォーマンス・オーバーヘッドに影響を与えることがあります。
Oracle Data Redactionは列の各行の値を動的に変更するため、集計関数を使用する特定のSQL問合せでは、行の値が静的であると仮定しているデータベース最適化を最大限に利用できません。
集計関数をコールするSQL問合せでは、リダクションが原因でパフォーマンス・オーバーヘッドが発生する可能性があります。
オブジェクト型を使用して、顧客アカウントなどの実世界のエンティティをモデル化できます。
オブジェクト型はユーザー定義の型です。オブジェクト型をリダクションすることはできません。これは、データベース・リダクションでは、オブジェクト型を構成できる可能性のある一部の方法を処理できないためです(ユーザー定義であるため)。オブジェクトで使用する型は、ALL_OBJECTSデータ・ディクショナリ・ビューのOBJECT_NAMEおよびOBJECT_TYPE列を問い合せることで検索できます。
Oracle Data Redactionポリシーが定義されている列で、XML生成関数を使用することはできません。
Oracle XML DB開発者ガイドで、この制限が適用されるSQL関数の種類について説明しています。この制限は、Oracle Data Redactionポリシーが有効化されているか無効化されているか、または問合せを行っているユーザーに対してアクティブかどうかに関係なく適用されます。
エディション化ビューはリダクションできません。
エディション化ビューはリダクションできないほかに、いずれのエディション化ビューの定義でも、リダクションされた列を使用することはできません。DBA_EDITIONSデータ・ディクショナリ・ビューを問い合せると、エディションに関する情報を検索できます。
マルチテナント環境では、Oracle Data Redactionポリシーは、現在のプラガブル・データベース(PDB)内のオブジェクトのみに適用されます。
データ・リダクション・ポリシーは、マルチテナント・コンテナ・データベース(CDB)には作成できません。これは、一般的にデータ・リダクション・ポリシーを作成するオブジェクトがPDBにあるためです。DBA_PDBSデータ・ディクショナリ・ビューを問い合せると、CDB内のすべてのPDBを検索できます。
VPD述語を含むVPDインライン・ビューは実際の値で動作するため、Oracle Virtual Private DatabaseポリシーはOracle Data Redactionの影響を受けません。
Oracle Data Redactionは、次の点でOracle Virtual Private Databaseとは異なります。
Oracle Data Redactionは、NULLリダクションのみをサポートするOracle Virtual Private Databaseよりも多くのリダクション機能を提供します。多くのアプリケーションでは、NULLリダクションを使用できないため、そのようなアプリケーションでは、データ・リダクションは有効な解決策です。
Oracle Virtual Private Databaseポリシーは静的、動的および文脈依存を使用できる一方、データ・リダクション・ポリシーは、静的および文脈依存のポリシー表現のみを使用できます。
データ・リダクションは、表またはビューに定義するポリシーを1つのみを許可する一方、オブジェクトには、複数の仮想プライベート・データベースのポリシーを定義できます。
データ・リダクションは、アプリケーション・ユーザーが、シノニムを使用するデータ・リダクション・ポリシーで保護されるオブジェクトへのアクセスを試みたときに実行されますが、(Oracle Virtual Private Databaseと違って)シノニム自体に直接ポリシーを作成することはできません。
Oracle Data Redactionは、アプリケーションに対するセキュリティの実装方法の点でOracle Database Real Application Securityとは異なります。
Oracle Data Redactionは、アプリケーション・セキュリティに包括的な認可フレームワークを提供している点で、Oracle Database Real Application Securityとは異なります。
Real Application Security内の列セキュリティは、Real Application Securityフレームワークを使用してアプリケーションで定義されるアプリケーション権限に基づきます。
関連項目:
カスタム・アプリケーション権限で表の列を保護する方法の詳細は、Oracle Database Real Application Security管理者および開発者ガイドを参照してください。
Oracle Database Vault環境で、Oracle Data Redactionを使用できます。
たとえば、オブジェクトがOracle Database Vaultレルムに含まれている場合、レルムの所有者または参加者の認証済リストに属していないユーザーは、ユーザーにEXEMPT REDACTION POLICY権限が付与されているかどうかにかかわらず、オブジェクト・データを表示できません。ユーザーがデータに対してDMLまたはDDL文を試みると、エラー・メッセージが表示されます。
Oracle Data PumpとともにOracle Data Redactionを使用した場合、DATAPUMP_EXP_FULL_DATABASEロールが与える影響、データ・リダクション・ポリシーを含むオブジェクトをエクスポートする際の影響、EXPDP access_methodパラメータを使用してデータをエクスポートする影響を考慮する必要があります。
内容は次のとおりです。
DATAPUMP_EXP_FULL_DATABASEロールには、強力なEXEMPT REDACTION POLICYシステム権限が含まれます。
デフォルトでは、DBAロールにDATAPUMP_EXP_FULL_DATABASEロールおよびDATAPUMP_IMP_FULL_DATABASEが付与されることに注意してください。
これによって、これらのロールを付与されたユーザーは、データ・リダクション・ポリシーから除外されます。このため、オブジェクトに定義されているデータ・リダクション・ポリシーでオブジェクトをエクスポートすると、保護されている表の実際のデータは、リダクションされずにData Pumpのターゲット・システムにコピーされます。DBAロールを含むこれらのロールを持つユーザーは、ターゲット・システム内の実際のデータを参照できます。
ただし、デフォルトでは、Data Pumpのソース・システムの任意の表およびビューに関連付けられたすべてのデータ・リダクション・ポリシーも(オブジェクト自体とともに)エクスポートおよびインポート操作に含まれ、ターゲット・システムのオブジェクトに適用されるため、ユーザーがターゲット・システム内のオブジェクトを問い合せると、データはリダクションされます。
Oracle Data Redactionポリシーがすでに定義されているオブジェクトをエクスポートできます。
内容は次のとおりです。
Oracle Data Redactionポリシーが定義されているオブジェクトをエクスポートする前に、Oracle Data Pumpで使用されるタイプ名を検索する必要があります。
これらのタイプを検索した後、これらのタイプをIMPDPユーティリティのINCLUDEディレクティブに対するパラメータとして使用して、その特定のタイプのメタデータのみをダンプ・ファイルに選択的にエクスポートできます。
タイプ名を検索するには、DATABASE_EXPORT_OBJECTSビューを問い合せます。
例:
SELECT OBJECT_PATH FROM DATABASE_EXPORT_OBJECTS WHERE OBJECT_PATH LIKE 'RADM_%';
次のような出力が表示されます。
OBJECT_PATH ------------ RADM_FPTM RADM_POLICY
データ・リダクション・ポリシーおよび完全リダクション設定に関連するデータ・ディクショナリ・メタデータのみをエクスポートできます。
この種のデータ・ポンプ・エクスポートは、開発、テストおよび本番の各データベース間でデータ・リダクション・ポリシーおよび設定の同じセットを使用する必要がある場合などに使用できます。content=metadata_onlyフラグが指定されているため、ダンプ・ファイルに実際のデータは含まれません。
データ・リダクション・ポリシーおよび完全リダクション設定に関連するデータ・ディクショナリ・メタデータのみをエクスポートするには、次のようなEXPDPユーティリティ・コマンドを入力します。
expdp system/password \
full=y \
COMPRESSION=NONE \
content=metadata_only \
INCLUDE=RADM_FPTM,RADM_POLICY\
directory=my_directory \
job_name=my_job_name \
dumpfile=my_data_redaction_policy_metadata.dmp
関連項目:
EXPDPユーティリティのINCLUDEパラメータの詳細は、Oracle Databaseユーティリティを参照してください。
メタデータ・フィルタの詳細は、Oracle Databaseユーティリティを参照してください。
Oracle Data Pumpによって、データ・リダクション・ポリシーのあるオブジェクトを含むスキーマからデータをエクスポートできます。
Oracle Data Pumpを使用して、新しいデータ・ポンプのデフォルト設定(direct_path)に基づいてデータベースの全体エクスポート操作を実行し、理解できないエラー・メッセージが返された場合、この項を使用して、エラーをより正確に理解できるような方法で操作を繰り返してください。
access_methodパラメータがdirect_pathに設定されたOracle Data Pump Export (EXPDP)ユーティリティを使用してデータをスキーマからエクスポートしようとするとき、このスキーマにデータ・リダクション・ポリシーが定義されているオブジェクトが含まれていると、次のエラー・メッセージが表示される場合があり、エクスポート操作は失敗します。
ORA-31696: unable to export/import TABLE_DATA:"schema.table" using client specified DIRECT_PATH method
この問題は、スキーマ・レベルのエクスポートを、EXP_FULL_DATABASEロールを付与されていないユーザーとして実行する場合にのみ発生します。EXP_FULL_DATABASEロールを必要とするフル・データベース・エクスポート時には発生しません。EXP_FULL_DATABASEロールにはEXEMPT REDACTION POLICYシステム権限が含まれており、これによりデータ・リダクション・ポリシーが無視されます。
潜在的な問題を見つけるには、EXPDP起動を再度試してください。ただし、access_methodパラメータをdirect_pathには設定しないでください。かわりに、automaticとexternal_tableのどちらかを使用してください。潜在的な問題とは、たとえば次のような権限の問題です。
ORA-28081: Insufficient privileges - the command references a redacted object.
関連項目:
データ・ポンプ・エクスポートの使用の詳細は、Oracle Databaseユーティリティを参照してください。
インポート操作中に、インポートされるデータを保護するデータ・リダクション・ポリシーを誤って削除しないように注意してください。
Oracle Data Pumpエクスポート(EXPDP)ユーティリティを使用してエクスポートされたソース表にOracle Data Redactionポリシーが存在しないシナリオを考えてみます。ただし、Oracle Data Pumpインポート(IMPDP)を使用してデータをインポートする宛先表には、Oracle Data Redactionポリシーが存在します。
IMPDPコマンドのCONTENTオプションによって異なります。 IMPDPコマンドでCONTENT=ALL またはCONTENT=METADATA_ONLYオプションを使用する場合、宛先表のデータ・リダクション・ポリシーは削除されます。データ・リダクション・ポリシーを再作成する必要があります。
IMPDPコマンドでCONTENT=DATA_ONLYを使用する場合、宛先表のデータ・リダクション・ポリシーは削除されません。
関連項目:
データ・ポンプ・エクスポートの使用の詳細は、Oracle Databaseユーティリティを参照してください
Oracle Enterprise Manager Data Masking and Subsetting Packを使用して、本番データベースの開発またはテスト・コピーを作成できます。
これを実行するには、このデータを一括でマスクして、出力後のマスクされたデータを開発またはテスト・コピーに配置します。
Oracle Enterprise Manager Data Masking and Subsetting Packですでにマスクされたデータを含む列をリダクションする場合は、データ・リダクション・ポリシーを本番以外のデータベースに適用してもかまいません。
データを開発およびテスト環境に移行する場合は、Oracle Enterprise Manager Data Masking and Subsetting Packを使用して、必ずデータ・セットをマスクしてください。データ・リダクションは、アプリケーション・コードを変更せずに、複数のアプリケーション間で一貫した方法で、起動時に本番アプリケーションをリダクションすることを主な目的として設計されています。
関連項目:
データ・マスキングおよびサブセッティングの詳細は、Oracle Data Masking and Subsettingガイドを参照してください。
