Oracle Data Redactionのセキュリティの考慮事項

18 Oracle Data Redactionのセキュリティの考慮事項

Oracleでは、Oracle Data Redactionを使用する場合のガイドラインを提供しています。

Oracle Data Redactionの一般的なセキュリティのガイドライン
Oracle Data Redactionを使用するための一般的なセキュリティのガイドラインを理解することが重要です。
Oracle Data Redactionポリシーへの管理アクセスの制限
データ・リダクション・ポリシーを作成、表示および編集できるユーザーのリストを制限できます。
Oracle Data RedactionがSYS、SYSTEMおよびデフォルト・スキーマに与える影響
ユーザーSYSおよびSYSTEMはいずれも自動的にEXEMPT REDACTION POLICYシステム権限が付与されています。
SYS_CONTEXT属性を使用するポリシー式
アプリケーションによって移入されるSYS_CONTEXT属性に依存するポリシー式を記述するときは、注意してください。
マテリアライズド・ビューに対するOracle Data Redactionポリシー
マテリアライズド・ビューやその実表に対するOracle Data Redactionポリシーを作成できます。
ビューが無効な場合のREDACTION_COLUMNSデータ・ディクショナリ・ビューの動作
Oracle Data Redactionポリシーがビューの列に存在しているときに、そのビューが無効になっても、REDACTION_COLUMNSデータ・ディクショナリ・ビューではデータ・リダクション・ポリシーが参照可能なままになります。
ごみ箱が有効になっている場合のOracle Data Redactionポリシーの削除
Oracle Data Redactionポリシーを削除する前に、ごみ箱が有効になっているかどうかを確認する必要があります。

親トピック: Oracle Data Redactionの使用

18.1 Oracle Data Redactionの一般的なセキュリティのガイドライン

Oracle Data Redactionを使用するための一般的なセキュリティ上のガイドラインを理解することが重要です。

Oracle Data Redactionは、データベースに対して直接非定型な問合せを実行する権限を持つ通常のデータベース・ユーザーによって行われる攻撃に対する保護目的では使用できません。ユーザーが任意のSQL文またはPL/SQL文を発行できる場合、そのユーザーは実際の値にアクセスできます。
Oracle Data Redactionは、推論によって実際の値を判断しようと試みる非定型なSQL問合せを実行するユーザーに対する保護目的では使用できません。推論とは、問合せを繰り返し試行して実際のデータを見つけるように設計されたプロセスのことです。たとえば、列salaryがリダクションされている場合に、最高額の給与を得ているユーザーを検出するために、侵入者は次の問合せを使用できます:
```
SELECT FIRST_NAME, LAST_NAME, SALARY 
FROM HR.EMPLOYEES 
WHERE SALARY > 16000 
ORDER BY SALARY DESC;

FIRST_NAME           LAST_NAME                     SALARY
-------------------- ------------------------- ----------
Steven               King                               0
Neena                Kochhar                            0
Lex                  De Haan                            0
```
Oracle Data Redactionは、データベースおよびアプリケーションのコンテキスト値に依存します。アプリケーションの場合、コンテキスト値を適切に初期化するのは、アプリケーションの役割です。
Oracle Data Redactionは、SYSDBA管理権限を使用してログインしているユーザーには適用されません。
データ・リダクション・ポリシーの管理下から実際のデータをコピーしようとする特定のDDL文(CREATE TABLE AS SELECTやINSERT AS SELECT)は、デフォルトでブロックされますが、ユーザーにEXEMPT REDACTION POLICYシステム権限を付与することでこの動作を無効にできます。
Oracle Data Redactionは、日常のデータベース操作(バックアップおよびリカバリ、Oracle Data Pumpエクスポート/インポート、Oracle Data Guard操作、レプリケーションなど)には影響しません。

親トピック: Oracle Data Redactionのセキュリティの考慮事項

18.2 Oracle Data Redactionポリシーへの管理アクセスの制限

データ・リダクション・ポリシーを作成、表示および編集できるユーザーのリストを制限できます。

これを実現するには、DBMS_REDACTパッケージおよびADMINISTER REDACTION POLICY権限に対するEXECUTE権限を持つユーザーを制限し、REDACTION_POLICIESおよびREDACTION_COLUMNSビューに対するSELECT権限を持つユーザーを制限します。

また、EXEMPT REDACTION POLICY権限を制限することによって、リダクションから除外されるユーザーも制限できます。Oracle Database Vaultを使用して、権限ユーザーのアクセスを制限すると、レルムを使用してEXEMPT REDACTION POLICYの付与を制限できます。

18.3 Oracle Data RedactionがSYS、SYSTEMおよびデフォルト・スキーマに与える影響

ユーザーSYSおよびSYSTEMはいずれも自動的にEXEMPT REDACTION POLICYシステム権限が付与されています。

SYSTEMには、EXEMPT REDACTION POLICYシステム権限を含む、EXP_FULL_DATABASEロールが付与されています。

そのため、SYSおよびSYSTEMユーザーは、常に既存のOracle Data Redactionポリシーをバイパスでき、またデータ・リダクション・ポリシーが定義されている表(またはビュー)のデータを常に表示できます。

データ・リダクション・ポリシーはSYSが所有するオブジェクトには適用できません。

次のガイドラインに従ってください。

デフォルトのOracle Databaseスキーマには、データ・リダクション・ポリシーを作成しないでください。SYSおよびSYSTEMスキーマも同様です。
追加ロールにEXEMPT REDACTION POLICYシステム権限を付与すると、ユーザーにOracle Data Redactionのバイパスを許す場合があることに注意してください。権限受領者ロールが追加のロールに付与されている可能性があるからです。
デフォルトで付与されているロールからは、EXEMPT REDACTION POLICYシステム権限を取り消さないでください。

親トピック: Oracle Data Redactionのセキュリティの考慮事項

18.4 SYS_CONTEXT属性を使用するポリシー式

アプリケーションによって移入されるSYS_CONTEXT属性に依存するポリシー式を記述するときは、注意してください。

ユーザーが(アプリケーションを通じてではなく)なんらかの方法で直接接続した場合、SYS_CONTEXT属性は移入されません。ポリシー式でこのNULLシナリオを処理しないと、意図せずに実際のデータを問合せユーザーに開示してしまうことがあります。

たとえば、クライアント識別子の値がSUPERVISORであるユーザー以外のすべてのユーザーに問合せ結果をリダクションする目的でポリシー式を作成するとします。次の式では、CLIENT_IDENTIFIERの値がNULLである問合せユーザーに、意図せずに実際のデータが表示されます。

SYS_CONTEXT('USERENV', 'CLIENT_IDENTIFIER') IS NOT 'SUPERVISOR'

ポリシー式をより厳密にすると、クライアント識別子が設定されていない場合(NULL値である場合)、問合せ結果はリダクションされます。

SYS_CONTEXT('USERENV', 'CLIENT_IDENTIFIER') IS NOT 'SUPERVISOR' OR IS NULL

SQLでは、NULLとの比較は未定義であるため、FALSEになりますが、リダクションはポリシー式がTRUEに評価された場合にのみ実行されることに注意してください。

親トピック: Oracle Data Redactionのセキュリティの考慮事項

18.5 マテリアライズド・ビューに対するOracle Data Redactionポリシー

Oracle Data Redactionポリシーは、マテリアライズド・ビューやその実表に作成できます。

ただし、マテリアライズド・ビューの作成者(または、マテリアライズド・ビューのリフレッシュを実行するユーザー)は、データ・リダクション・ポリシーによってブロックされないようにしてください。つまり、マテリアライズド・ビューの作成操作やリフレッシュ操作を実行するユーザーは、データ・リダクション・ポリシーから除外する必要があります。ベスト・プラクティスは、新しいマテリアライズド・ビューを作成する場合に、それを実際の表のコピーとして扱い、個別のデータ・リダクション・ポリシーを作成してそれを保護することです。

親トピック: Oracle Data Redactionのセキュリティの考慮事項

18.6 ビューが無効な場合のREDACTION_COLUMNSデータ・ディクショナリ・ビューの動作

Oracle Data Redactionポリシーがビューの列に存在しているときに、そのビューが無効になっても、REDACTION_COLUMNSデータ・ディクショナリ・ビューではデータ・リダクション・ポリシーが参照可能なままになります。

たとえば、ビューは、そのビューのいずれかの列が参照する列が、そのビューが依存する表から削除されると無効になることがあります。

データ・リダクション・ポリシーは表が無効になったときに自動的に削除されることがないため、REDACTION_COLUMNSデータ・ディクショナリ・ビューでは、その列が引き続き参照可能になります。

データ・リダクション・ポリシーを削除するかどうかは、その後でビューが変更されたときに決定されます。

ビューが無効になったときに自動的にデータ・リダクション・ポリシーを削除するのではなく、このアプローチが採用された理由は、間違いが発生しにくいことと、基礎となる表から実際のデータを誤って表示してしまうリスクが少なくなるためです。

ビューの変更時点まで決定を遅らせることで、列が表にリストアされた後でビューを再コンパイルできるようになります。列が表にリストアされてビューが再コンパイルされると、ビューは有効になり、データ・リダクション・ポリシーが引き続き適用されます。

その一方、無効なビュー定義が有効なビュー定義(データ・リダクション・ポリシーが定義されていた列を含まなくなったもの)に置き換えられた場合、その時点でデータ・リダクション・ポリシーは自動的に削除されます。その後で、REDACTION_COLUMNSデータ・ディクショナリ・ビューは列を表示しなくなるように更新されます(その列が新しいビューの定義に含まれなくなったため)。

親トピック: Oracle Data Redactionのセキュリティの考慮事項

18.7 ごみ箱が有効になっている場合のOracle Data Redactionポリシーの削除

Oracle Data Redactionポリシーを削除する前に、ごみ箱が有効になっているかどうかを確認する必要があります。

ごみ箱機能が有効になっている場合にOracle Data Redactionポリシーが定義されている表またはビューを削除するか、または、ごみ箱を空にする前にREDACTION_COLUMNSまたはREDACTION_POLICIESデータ・ディクショナリ・ビューを問い合せると、BIN$... (BIN$1Xu5PSW5VaPgQxGS5AoAEA==$0など)のオブジェクト名が表示されます。

これは正常な動作です。これらのポリシーは、ごみ箱を空にすると削除されます。

ごみ箱が有効になっているかどうかを確認するには、SQL*PlusのSHOW PARAMETER RECYCLEBINコマンドを実行します。

関連項目

リサイクル・ビン内のオブジェクトのパージ

親トピック: Oracle Data Redactionのセキュリティの考慮事項