Oracle® Database

Advanced Securityガイド

12c リリース1 (12.1)

B71313-13(原本部品番号:E50333-18)

2017年6月

Oracle Database Advanced Securityガイド, 12c リリース1 (12.1)

B71313-13

Copyright © 1996, 2017, Oracle and/or its affiliates.  All rights reserved.

原本著者: Patricia Huey

原本協力者: Rahil Mir、Paul Youn、Adam Lee、Preetam Ramakrishna、Gopal Mulagund、Rajbir Chahal、Min-Hank Ho、Michael Hwa、Sudha Iyer、Adam Lindsey、Supriya Kalyanasundaram、Lakshmi Kethana、Andrew Koyfman、Vikram Pesati、Andy Philips、Philip Thornton、Paul Needham、Peter Wahl

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

このリリースでの『Oracle Database Advanced Securityガイド』の変更点

- Oracle Database Advanced Security 12c リリース1 (12.1.0.2)における変更点

- 新機能

- データ・リダクション・ポリシーのOLS_LABEL_DOMINATESのサポート

- Oracle Key Vaultのキーストアおよび暗号化会議管理のサポート

- Oracle Database Advanced Security 12c リリース1 (12.1.0.1)における変更点

- 新機能

- 透過的データ暗号化およびその他のデータベース・コンポーネント用の新しいキーストアおよびキーストア管理機能

- 透過的データ暗号化の新しい管理権限

- 機密データへのアクセスを制限するOracle Data Redaction

- 非推奨となった機能

- 透過的データ暗号化鍵を管理するPKIの使用

- その他の変更

1 Oracle Advanced Securityの概要

- 透過的データ暗号化

- Oracle Data Redaction

第I部 透過的データ暗号化の使用

2 透過的データ暗号化の概要

- 透過的データ暗号化とは

- 透過的データ暗号化を使用する利点

- 透過的データ暗号化を構成できる者

- 透過的データ暗号化のタイプおよびコンポーネント

- 透過的データ暗号化のタイプおよびコンポーネントについて

- 透過的データ暗号化列暗号化の動作

- 透過的データ暗号化表領域暗号化の動作

- TDEマスター暗号化鍵の格納用のキーストアの動作

- TDEマスター暗号化鍵のキーストア格納について

- キーストア格納フレームワークの利点

- キーストアのタイプ

- サポートされる暗号化と整合性のアルゴリズム

3 透過的データ暗号化の構成

- ソフトウェア・キーストアの構成

- ソフトウェア・キーストアの構成について

- 手順1: sqlnet.oraファイルでのソフトウェア・キーストアの場所の設定

- sqlnet.oraファイルでのキーストアの場所について

- ソフトウェア・キーストアの場所用のsqlnet.oraファイルの構成

- 例: 通常のファイル・システム用のソフトウェア・キーストアの構成

- 例: 複数のデータベースでsqlnet.oraファイルを共有する場合のソフトウェア・キーストアの構成

- 例: Oracle Automatic Storage Management用のソフトウェア・キーストアの構成

- 例: Oracle Automatic Storage Managementディスク・グループ用のソフトウェア・キーストアの構成

- 手順2: ソフトウェア・キーストアの作成

- ソフトウェア・キーストアを作成することについて

- パスワードベースのソフトウェア・キーストアの作成

- 自動ログイン・ソフトウェア・キーストアまたはローカル自動ログイン・ソフトウェア・キーストアの作成

- 手順3: ソフトウェア・キーストアを開く

- ソフトウェア・キーストアを開くことについて

- ソフトウェア・キーストアを開く

- 手順4: ソフトウェアTDEマスター暗号化鍵の設定

- ソフトウェアTDEマスター暗号化鍵の設定について

- ソフトウェア・キーストアのTDEマスター暗号化鍵の設定

- 手順5: データの暗号化

- ハードウェア・キーストアの構成

- (外部の)ハードウェア・キーストアの構成について

- 手順1: sqlnet.oraファイルでのハードウェア・キーストアのタイプの設定

- 手順2: ハードウェア・セキュリティ・モジュールの構成

- 手順3: ハードウェア・キーストアを開く

- ハードウェア・キーストアを開くことについて

- ハードウェア・キーストアを開く

- 手順4: ハードウェア・キーストアのTDEマスター暗号化鍵の設定

- ハードウェア・キーストアのTDEマスター暗号化鍵の設定について

- まだ構成していない場合のTDEマスター暗号化鍵の設定

- 前に構成したTDEマスター暗号化鍵の移行

- 手順5: データの暗号化

- 表の列の暗号化

- 表の列の暗号化について

- TDE列暗号化で暗号化できるデータ型

- 透過的データ暗号化列暗号化の使用に関する制限

- 暗号化列を含む表の作成

- 暗号化列を含む表の作成について

- デフォルト・アルゴリズムを使用する暗号化列を含む表の作成

- アルゴリズムを使用しないまたは非デフォルト・アルゴリズムを使用する暗号化列を含む表の作成

- NOMACパラメータを使用したディスク領域の節約およびパフォーマンスの向上

- 例: CREATE TABLE文でのNOMACパラメータの使用

- 例: 表の整合性アルゴリズムの変更

- 外部表への暗号化列の作成

- 既存の表にある列の暗号化

- 既存の表にある列の暗号化について

- 既存の表への暗号化列の追加

- 暗号化されていない列の暗号化

- 列の暗号化の無効化

- 暗号化列に対する索引の作成

- 暗号化列へのSaltの追加

- 暗号化列からのSaltの削除

- 暗号化列を含む表に対する暗号化鍵またはアルゴリズムの変更

- 表領域の暗号化

- 透過的データ暗号化表領域暗号化の使用に関する制限

- 手順1: 表領域暗号化のCOMPATIBLE初期化パラメータの設定

- 表領域暗号化のためのCOMPATIBLE初期化パラメータの設定について

- 表領域暗号化のためのCOMPATIBLE初期化パラメータの設定

- 手順2: 表領域TDEマスター暗号化鍵の設定

- 手順3: 暗号化された表領域の作成

- 暗号化された表領域の作成について

- 暗号化された表領域の作成

- 例: 3DES168を使用する暗号化された表領域の作成

- 例: デフォルト・アルゴリズムを使用する暗号化された表領域の作成

- 透過的データ暗号化のデータの動的ビューおよびデータ・ディクショナリ・ビュー

4 キーストアおよびTDEマスター暗号化鍵の管理

- キーストアの管理

- パスワードベースのソフトウェア・キーストアのパスワードの変更

- パスワードベースのソフトウェア・キーストアのパスワードの変更について

- パスワードベースのソフトウェア・キーストアのパスワードの変更

- ハードウェア・キーストアのパスワードの変更

- パスワードベースのソフトウェア・キーストアのバックアップ

- パスワードベースのソフトウェア・キーストアのバックアップについて

- バックアップ・キーストアのバックアップ識別子文字列の作成

- V$ENCRYPTION_WALLETビューによるバックアップ操作の解釈方法

- パスワードベースのソフトウェア・キーストアのバックアップ

- ハードウェア・キーストアのバックアップ

- ソフトウェア・キーストアのマージ

- ソフトウェア・キーストアのマージについて

- 2つのソフトウェア・キーストアから3つ目の新しいキーストアへのマージ

- 1つのソフトウェア・キーストアの既存のソフトウェア・キーストアへのマージ

- 自動ログイン・ソフトウェア・キーストアの既存のパスワードベースのソフトウェア・キーストアへのマージ

- ソフトウェア・キーストア・マージ操作の取消し

- 新しいロケーションへのソフトウェア・キーストアの移動

- 自動ストレージ管理からのソフトウェア・キーストアの移動

- ソフトウェア・パスワード・キーストアとハードウェア・キーストア間の移行

- パスワードベースのソフトウェア・キーストアからハードウェア・キーストアへの移行

- 手順1: ハードウェア・キーストアとともに開くためにソフトウェア・キーストアを変換する

- 手順2: パスワードベースのソフトウェア・キーストアの移行のためにsqlnet.oraを構成する

- 手順3: ハードウェア・キーストアの移行を実行する

- ハードウェア・キーストアからパスワードベースのソフトウェア・キーストアへの移行

- ハードウェア・キーストアからの再移行について

- 手順1: 逆移行用にsqlnet.oraを構成する

- 手順2: 逆移行用にキーストアを構成する

- 手順3: ソフトウェア・キーストアとともに開くようにハードウェア・キーストアを構成する

- 移行後のキーストアの順序

- キーストアとOracle Key Vault間の移行

- キーストアを閉じる

- キーストアを閉じるについて

- ソフトウェア・キーストアを閉じる

- ハードウェア・キーストアを閉じる

- ASMボリュームに存在するソフトウェア・キーストアの使用

- 暗号化されたデータのバックアップおよびリカバリ

- キーストアの削除

- TDEマスター暗号化鍵の管理

- 後で使用するためのTDEマスター暗号化鍵の作成

- 後で使用するためのTDEマスター暗号化鍵の作成について

- 後で使用するためのTDEマスター暗号化鍵の作成

- 例: 1つのデータベースでのTDEマスター暗号化鍵の作成

- 例: すべてのPDBでのTDEマスター暗号化鍵の作成

- TDEマスター暗号化鍵のアクティブ化

- TDEマスター暗号化鍵のアクティブ化について

- TDEマスター暗号化鍵のアクティブ化

- 例: TDEマスター暗号化鍵のアクティブ化

- TDEマスター暗号化鍵の属性管理

- TDEマスター暗号化鍵の属性

- 使用中のTDEマスター暗号化鍵の検出

- レポート用のTDEマスター暗号化鍵のカスタム属性の作成

- カスタム属性タグの作成について

- カスタム属性タグの作成

- キーストアのTDEマスター暗号化鍵の設定および再設定

- キーストアのTDEマスター暗号化鍵の設定およびローテーションについて

- TDEマスター暗号化鍵の作成とバックアップおよびタグの適用

- TDEマスター暗号化鍵のローテーションについて

- TDEマスター暗号化鍵のローテーション

- TDEマスター暗号化鍵のエクスポートおよびインポート

- TDEマスター暗号化鍵のエクスポートおよびインポートについて

- TDEマスター暗号化鍵のエクスポートについて

- TDEマスター暗号化鍵のエクスポート

- 例: 副問合せを使用したTDEマスター暗号化鍵識別子のエクスポート

- 例: ファイルへのTDEマスター暗号化鍵識別子のリストのエクスポート

- 例: データベースのすべてのTDEマスター暗号化鍵のエクスポート

- TDEマスター暗号化鍵のインポートについて

- TDEマスター暗号化鍵のインポート

- 例: TDEマスター暗号化鍵のインポート

- キーストアのマージとTDEマスター暗号化鍵のエクスポートまたはインポートの相違点

- Oracle Key Vaultを使用したTDEマスター暗号化鍵の管理

- Oracle Databaseで使用するシークレットの格納

- キーストアへのOracle Databaseのシークレットの格納について

- ソフトウェア・キーストアへのOracle Databaseのシークレットの格納

- 例: ソフトウェア・キーストアへのHSMパスワードの追加

- 例: ソフトウェア・キーストアにシークレットとして格納されているHSMパスワードの変更

- 例: ソフトウェア・キーストアにシークレットとして格納されているHSMパスワードの削除

- ハードウェア・キーストアへのOracle Databaseのシークレットの格納

- 例: ハードウェア・キーストアへのOracle Databaseのシークレットの追加

- 例: ハードウェア・キーストアでのOracle Databaseのシークレットの変更

- 例: ハードウェア・キーストアでのOracle Databaseのシークレットの削除

- 自動ログイン・ハードウェア・セキュリティ・モジュールの構成

- 自動ログイン・ハードウェア・セキュリティ・モジュールの構成について

- 自動ログイン・ハードウェア・セキュリティ・モジュールの構成

- キーストアへのOracle GoldenGateのシークレットの格納

- キーストアへのOracle GoldenGateのシークレットの格納について

- Oracle GoldenGate Extractのクラシック・キャプチャ・モードのTDE要件

- Oracle GoldenGate用のTDEキーストア・サポートの構成

- 手順1: キーストアの共有シークレットを決定する

- 手順2: TDEによるOracle GoldenGateのサポートのためにOracle Databaseを構成する

- 手順3: TDE GoldenGate共有シークレットをキーストアに格納する

- 手順4: TDE Oracle GoldenGate共有シークレットをExtractプロセスに設定する

5 透過的データ暗号化を使用する場合の一般的な考慮事項

- 暗号化データの圧縮とデータ重複除外

- 透過的データ暗号化のセキュリティに関する考慮事項

- 透過的データ暗号化のセキュリティに関する一般的なアドバイス

- 透過的データ暗号化の列暗号化固有のアドバイス

- 平文の断片のセキュリティの管理

- 透過的データ暗号化のパフォーマンスと記憶域のオーバーヘッド

- 透過的データ暗号化のパフォーマンスのオーバーヘッド

- 透過的データ暗号化の記憶域のオーバーヘッド

- 透過的データ暗号化と組み合せて使用するためのアプリケーションの変更

- ALTER SYSTEMおよびorapkiとADMINISTER KEY MANAGEMENTとの対応

- PKI暗号化での透過的データ暗号化の使用

- ソフトウェア・マスター暗号化鍵とPKI鍵ペアとの併用

- PKI暗号化とTDEの表領域およびハードウェア・キーストア

- PKI鍵ペアのバックアップおよびリカバリ

6 他のOracle機能における透過的データ暗号化の使用

- 透過的データ暗号化とエクスポートおよびインポート操作の連携

- 暗号化データされたデータのエクスポートおよびインポートについて

- 暗号化された列のある表のエクスポートおよびインポート

- Oracle Data Pumpを使用してダンプ・セット全体を暗号化

- 透過的データ暗号化とOracle Data Guardとの連携

- 透過的データ暗号化とOracle Real Application Clustersとの連携

- Oracle Real Application Clustersでの透過的データ暗号化の使用について

- 非共有ファイル・システムを使用したOracle RACへのソフトウェア・キーストアの格納

- 透過的データ暗号化とSecureFilesとの連携

- 透過的データ暗号化およびSecureFilesについて

- 例: 特定の暗号化アルゴリズムを使用したSecureFiles LOBの作成

- 例: 列パスワードを指定したSecureFiles LOBの作成

- 透過的データ暗号化のマルチテナント環境での使用

- マルチテナント環境における透過的データ暗号化の使用について

- rootで実行される必要がある操作

- rootまたはPDBで実行可能な操作

- PDB向けのTDEマスター暗号化鍵のエクスポートおよびインポート

- PDB向けのTDEマスター暗号化鍵のエクスポートおよびインポートについて

- PDB向けのTDEマスター暗号化鍵のエクスポートまたはインポート

- 例: PDBからTDEマスター暗号化鍵をエクスポート

- 例: PDBにTDEマスター暗号化鍵をインポート

- 暗号化データのあるPDBをCDBでプラグおよびアンプラグ

- 暗号化データを含むPDBのアンプラグ

- 暗号化データを含むPDBのCDBへのプラグイン

- HSMに格納されたマスター鍵を含むPDBのアンプラグ

- HSMに格納されたマスター鍵を含むPDBのプラグ

- マルチテナント環境でのキーストアの開閉操作の機能

- マルチテナント環境のすべてのPDBのキーストアのステータスの確認

- 透過的データ暗号化とOracle Call Interfaceとの連携

- 透過的データ暗号化とエディションとの連携

- マルチデータベース環境で機能するように透過的データ暗号化を構成

7 透過的データ暗号化に関するよくある質問

- 透過的データ暗号化に関する透過の質問

- 透過的データ暗号化に関するパフォーマンスの質問

第II部 Oracle Data Redactionの使用

8 Oracle Data Redactionの概要

- Oracle Data Redactionとは

- Oracle Data Redactionを使用する状況

- Oracle Data Redactionを使用する利点

- Oracle Data Redactionのターゲットのユースケース

- データベース・アプリケーションにおけるOracle Data Redactionの使用

- 非定型データベース問合せにおけるOracle Data Redactionの考慮事項

9 Oracle Data Redactionの特徴と機能

- 全データをリダクションする完全データ・リダクション

- データのセクションをリダクションする部分データ・リダクション

- データのパターンをリダクションする正規表現

- ランダム値を生成するランダム・データ・リダクション

- データ型に基づいた完全、部分およびランダム・リダクションの比較

- Oracle組込みデータ型のリダクション機能

- ANSIデータ型のリダクション機能

- ユーザー定義データ型またはオラクル社提供の型のリダクション機能

- テストを目的にリダクションしない場合

10 Oracle Data Redactionポリシーの構成

- Oracle Data Redactionポリシーについて

- Oracle Data Redactionポリシーを作成できるユーザーは?

- データ・リダクション・ポリシーの計画

- DBMS_REDACT.ADD_POLICYプロシージャの一般的な構文

- データ・リダクション・ポリシーの条件を定義する式の使用

- データ・リダクション・ポリシーでの式の使用について

- ユーザー環境に基づくリダクション・ポリシーの適用

- データベース・ロールに基づくリダクション・ポリシーの適用

- Oracle Label Securityラベル優位に基づくリダクション・ポリシーの適用

- Application Expressセッション・ステートに基づくリダクション・ポリシーの適用

- すべてのユーザーへのリダクション・ポリシーの適用

- 完全データ・ポリシーの作成と完全リダクション値の変更

- 完全リダクション・ポリシーの作成

- 完全データ・リダクション・ポリシーの作成について

- 完全リダクション・ポリシーを作成する構文

- 例: 完全リダクション・ポリシー

- 例: 完全にリダクションされた文字値

- デフォルトの完全データ・リダクション値の変更

- デフォルトの完全データ・リダクション値の変更について

- DBMS_REDACT.UPDATE_FULL_REDACTION_VALUESプロシージャの構文

- デフォルトの完全データ・リダクション値の変更

- 部分リダクション・ポリシーの作成

- 部分リダクション・ポリシーの作成について

- 部分リダクション・ポリシーを作成する構文

- 固定文字形式を使用した部分リダクション・ポリシーの作成

- 固定文字形式の設定

- 例: 固定文字形式を使用した部分リダクション・ポリシー

- 文字データ型を使用した部分リダクション・ポリシーの作成

- 文字データ型の設定

- 例: 文字データ型を使用した部分リダクション・ポリシー

- 数値データ型を使用した部分リダクション・ポリシーの作成

- 数値データ型の設定

- 例: 数値データ型を使用した部分リダクション・ポリシー

- 日時データ型を使用した部分リダクション・ポリシーの作成

- 日時データ型の設定

- 例: 日時データ型を使用した部分リダクション・ポリシー

- 正規表現ベースのリダクション・ポリシーの作成

- 正規表現ベースのリダクション・ポリシーの作成について

- 正規表現ベースのリダクション・ポリシーを作成する構文

- 形式を使用した正規表現ベースのリダクション・ポリシー

- 正規表現の形式

- 例: 形式を使用した正規表現リダクション・ポリシー

- カスタム正規表現リダクション・ポリシー

- カスタム正規表現の設定

- 例: カスタム正規表現リダクション・ポリシー

- ランダム・リダクション・ポリシーの作成

- ランダム・リダクション・ポリシーを作成する構文

- 例: ランダム・リダクション・ポリシー

- リダクションを使用しないポリシーの作成

- リダクションを使用しないポリシーの作成の構文

- 例: リダクションを実行しない

- Oracle Data Redactionポリシーからのユーザーの除外

- Oracle Data Redactionポリシーの変更

- Oracle Data Redactionポリシーの変更について

- DBMS_REDACT.ALTER_POLICYプロシージャの構文

- DBMS_REDACT.ALTER_POLICY操作に必要なパラメータ

- チュートリアル: Oracle Data Redactionポリシーの変更

- 複数列のリダクション

- 1つの表またはビューのデータ・リダクション・ポリシーへの列の追加

- 例: 複数列のリダクション

- Oracle Data Redactionポリシーの有効化と無効化

- Oracle Data Redactionポリシーの無効化

- Oracle Data Redactionポリシーの有効化

- Oracle Data Redactionポリシーの削除

- チュートリアル: SQL式を使用したリダクションされた値を含むレポートの作成

- Oracle Data Redactionポリシーのデータ・ディクショナリ・ビュー

11 Oracle Enterprise ManagerでのOracle Data Redactionの使用

- Oracle Enterprise ManagerでのOracle Data Redactionの使用について

- Oracle Data Redactionのワークフロー

- Enterprise Managerでの機密列タイプの管理

- Enterprise Managerを使用したOracle Data Redaction形式の管理

- Enterprise Managerを使用したOracle Data Redaction形式の管理について

- カスタムOracle Data Redaction形式の作成

- カスタムOracle Data Redaction形式の編集

- Oracle Data Redaction形式の表示

- カスタムOracle Data Redaction形式の削除

- Enterprise Managerを使用したOracle Data Redactionポリシーの管理

- Enterprise Managerを使用したOracle Data Redactionポリシーの管理について

- Enterprise Managerを使用したOracle Data Redactionポリシーの作成

- Enterprise Managerを使用したOracle Data Redactionポリシーの編集

- Enterprise Managerを使用したOracle Data Redactionポリシーの詳細の表示

- Enterprise ManagerでのOracle Data Redactionポリシーの有効化または無効化

- Enterprise Managerを使用したOracle Data Redactionポリシーの削除

12 Oracle Data RedactionとOracle Database機能の併用

- Oracle Data Redactionと、DMLおよびDDL操作

- ネストした関数、インライン・ビューおよびWHERE句でのOracle Data Redaction

- Oracle Data Redactionとデータベース・リンク

- Oracle Data Redactionおよび集計関数

- Oracle Data Redactionおよびオブジェクト型

- Oracle Data RedactionおよびXML生成

- Oracle Data Redactionおよびエディション

- マルチテナント環境におけるOracle Data Redaction

- Oracle Data RedactionとOracle Virtual Private Database

- Oracle Data RedactionとOracle Database Real Application Security

- Oracle Data RedactionとOracle Database Vault

- Oracle Data RedactionとOracle Data Pump

- Oracle Data RedactionのためのOracle Data Pumpセキュリティ・モデル

- Oracle Data Redactionポリシーが定義されているオブジェクトのエクスポート

- Oracle Data Pumpで使用されるタイプ名の検索

- データ・リダクション・ポリシーに関連するデータ・ディクショナリ・メタデータのみのエクスポート

- IMPDPのINCLUDEパラメータを使用したオブジェクトのインポート

- EXPDPユーティリティのaccess_methodパラメータを使用したデータのエクスポート

- Oracle Data Redactionで保護されているオブジェクトへのデータのインポート

- Oracle Data RedactionとData Masking and Subsetting Pack

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

- Oracle Data Redactionの一般的な使用上のガイドライン

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

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

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

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

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

用語集

索引

はじめに

Oracle Advanced Security 12gリリース1 (12.1)の『Oracle Database Advanced Securityガイド』へようこそ。このガイドでは、Oracle Advanced Securityを実装、構成および管理する方法について説明します。

この章の内容は次のとおりです。

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

対象読者

『Oracle Database Advanced Securityガイド』は、Oracle Advanced Securityの実装、構成および管理に携わる次のようなユーザーとシステム担当者を対象としています。

- 実装の専門家

- システム管理者

- セキュリティ管理者

- データベース管理者(DBA)

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

サポートをご購入のOracleのお客様は、My Oracle Supportにアクセスして電子サポートを受けることができます。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info)か、聴覚に障害のあるお客様は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。

関連ドキュメント

詳細は、次のOracleドキュメントを参照してください。

- 『Oracle Database管理者ガイド』

- 『Oracle Databaseセキュリティ・ガイド』

ドキュメント・セットの多くのマニュアルでは、デフォルトのデータベースのサンプル・スキーマが使用されます。サンプル・スキーマの作成方法およびその使用方法の詳細は、『Oracle Databaseサンプル・スキーマ』を参照してください。

リリース・ノート、インストール関連ドキュメント、ホワイト・ペーパーまたはその他の関連ドキュメントは、OTN (Oracle Technology Network)から、無償でダウンロードできます。OTNを使用するには、オンラインでの登録が必要です。登録は、次の場所から無償で行えます。

http://www.oracle.com/technetwork/index.html

すでにOTNのユーザー名およびパスワードを取得している場合は、次の場所でOTN Webサイトのドキュメントのセクションに直接接続できます。

http://www.oracle.com/technetwork/documentation/index.html

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

このリリースでの『Oracle Database Advanced Securityガイド』の変更点

『Oracle Database Advanced Securityガイド』には、Oracle Databaseリリース1 (12.1.0.1)とリリース1 (12.1.0.2)の両方で変更点があります。

- Oracle Database Advanced Security 12c リリース1 (12.1.0.2)における変更点

- Oracle Database Advanced Security 12c リリース1 (12.1.0.1)における変更点

Oracle Database Advanced Security 12cリリース1 (12.1.0.2)における変更点

Oracle Database 12cリリース1 (12.1.0.2)の『Oracle Database Advanced Securityガイド』における変更点は次のとおりです。

- 新機能

新機能

このリリースの新機能は次のとおりです。

- データ・リダクション・ポリシーのOLS_LABEL_DOMINATESのサポート

- Oracle Key Vaultのキーストアおよび暗号化会議管理のサポート

データ・リダクション・ポリシーのOLS_LABEL_DOMINATESのサポート

このリリース以降、Oracle Data Redactionポリシーでパブリック・スタンドアロン・ファンクションOLS_LABEL_DOMINATESを使用できます。入力にVARCHAR2データ型を使用するSA_UTL.DOMINATESファンクションは、このファンクションで置き換えられます。

詳細は、「Oracle Label Securityラベル優位に基づくリダクション・ポリシーの適用」を参照してください。

Oracle Key Vaultのキーストアおよび暗号化会議管理のサポート

Oracle Key Vaultでは、企業全体でのソフトウェア・キーストアとTDE暗号化鍵、およびセキュリティ・オブジェクト(Javaキーストア(JKS)、Java Cryptography Extension (JCEKS)キーストアおよび資格証明ファイル)の集中管理が可能です。

詳細は、『Oracle Key Vault管理者ガイド』を参照してください。

Oracle Database Advanced Security 12cリリース1 (12.1.0.1)における変更点

Oracle Database 12cリリース1 (12.1.0.1)の『Oracle Database Advanced Securityガイド』における変更点は次のとおりです。

- 新機能

- 非推奨となった機能

- その他の変更

新機能

このリリースの新機能は次のとおりです。

- 透過的データ暗号化およびその他のデータベース・コンポーネント用の新しいキーストアおよびキーストア管理機能

- 透過的データ暗号化の新しい管理権限

- 機密データへのアクセスを制限するOracle Data Redaction

透過的データ暗号化およびその他のデータベース・コンポーネント用の新しいキーストアおよびキーストア管理機能

Oracle Database 12cリリース1 (12.1)では、透過的データ暗号化(TDE)およびその他のデーベース・コンポーネント用に統合鍵管理インタフェースが導入されています。これによって鍵管理タスクが簡単になり、コンプライアンスおよび追跡機能が向上するだけでなく、データベース管理者とセキュリティ管理者の職務分離性も向上します。

すべての鍵およびキーストア管理コマンドを実行するために、mkstoreまたはorapkiコマンドライン・ユーティリティ、Oracle Wallet Managerユーティリティ、およびALTER SYSTEM文にかわり、ADMINISTER KEY MANAGEMENT文を使用できるようになりました。

「透過的データ暗号化の概要」を参照してください。

透過的データ暗号化の新しい管理権限

セキュリティおよび職務権限の分離を向上するために、透過的データ暗号化の責任者にSYSKM管理権限を付与できるようになりました。

「透過的データ暗号化の概要」を参照してください。

機密データへのアクセスを制限するOracle Data Redaction

Oracle Data Redaction(データ・リダクション)により、権限の低いユーザーやアプリケーションからデータを偽装(マスク)できます。

たとえば、次のクレジット・カード番号があると仮定します。

- 5105 1051 0510 5100

- 5111 1111 1111 1118

- 5454 5454 5454 5454

データ・リダクションを使用して、先頭12桁を次のように偽装できます。

- **** **** **** 5100

- **** **** **** 1118

- **** **** **** 5454

データは起動時にリダクションされます(つまり、データは、ユーザーがデータを含むページにアクセスするときは非表示になるが、データベースでは非表示となっていない状態です)。これにより、機密データを通常どおりに処理することができ、バックエンドでの参照整合性やデータ制約は維持されます。部分的にデータをリダクションすることもでき、これにより、オリジナル・データの一部は、それ全体を固定値で置換するか、暗号化された値を持つデータで置換することで保持されます(クレジット・カード番号の末尾4桁など)。Oracle Data Redactionポリシーを企業のデータベース全体に適用することも可能です。

詳細は、「Oracle Data Redactionの概要」 を参照してください。

非推奨となった機能

次の機能は非推奨になっています。

- 透過的データ暗号化鍵を管理するPKIの使用

透過的データ暗号化鍵を管理するPKIの使用

透過的データ暗号化鍵を管理するPKIの使用は非推奨になりました。かわりに、ADMINISTER KEY MANAGEMENT SQL文を使用して、透過的データ暗号化鍵を管理します。

詳細は、「透過的データ暗号化とPKI暗号化の使用」を参照してください。

その他の変更点

可用性の向上のため、Oracle Advanced Securityが再パッケージ化されました。次の強力な認証機能は、現在Oracle Advanced Securityに含まれず、Oracle Databaseをインストールしたときにデフォルトで提供されます。

- シンJDBCクライアント・ネットワーク・サポート

- RADIUS認証

- Kerberos認証

- Secure Sockets Layer (SSL)認証

- 複数認証のサポート

これらの機能の詳細については、『Oracle Databaseセキュリティ・ガイド』を参照してください。

次の機能は、Oracle Advanced Securityに含まれており、このガイドで説明しています。

- 透過的データ暗号化

- Oracle Data Redaction

この変更に伴い、本ガイドの名前は、『Oracle Database Advanced Securityガイド』に変更されました。以前のリリースでは、『Oracle Database Advanced Security管理者ガイド』と呼ばれていました。

1 Oracle Advanced Securityの概要

Oracle Advanced Securityは、透過的データ暗号化およびOracle Data Redactionの2つの機能で構成されます。

内容は次のとおりです。

- 透過的データ暗号化

- Oracle Data Redaction

透過的データ暗号化

透過的データ暗号化(TDE)ではデータを暗号化できるため、許可された受信者のみが読み取ることができます。

暗号化を使用すると、保護されていない可能性のある環境内の機密データ(バックアップ・メディアに配置されて、外部の記憶域に送信されるデータなど)を保護できます。データベース表の個別の列を暗号化したり、表領域全体を暗号化することができます。

透過的データ暗号化を使用するには、アプリケーションを変更する必要はありません。TDEではアプリケーションは以前と同様にシームレスに動作を継続することができます。ディスクに書き込まれるときにデータは自動的に暗号化され、アプリケーションがアクセスするときにデータは復号化されます。キー管理機能が組み込まれているため、暗号化鍵の管理および保護などの複雑なタスクを行う必要はありません。

Oracle Data Redaction

Oracle Data Redactionでは、複数のリダクション・タイプを使用して列データのリダクション(マスク)を行うことができます。

実行できるリダクションのタイプは、次のとおりです。

- 完全リダクション。列データの内容をすべてリダクションします。問合せを行ったユーザーに返される、リダクションされた値は、列のデータ型によって異なります。たとえば、NUMBERデータ型の列はゼロ(0)でリダクションされ、文字データ型は空白でリダクションされます。

- 部分リダクション。列データの一部をリダクションします。たとえば、社会保障番号の大部分(最後の4桁以外)をアスタリスク(*)でリダクションできます。

- 正規表現。完全または一部のいずれのリダクションでも正規表現を使用できます。これにより、データの検索パターンに基づいてデータをリダクションできます。たとえば、正規表現を使用して、データ内の特定の電話番号または電子メール・アドレスをリダクションできます。

- ランダム・リダクション。問合せを行ったユーザーに表示されるリダクションされたデータは、列のデータ型に応じて、表示されるたびにランダムに生成された値として表示されます。

- リダクションなし。このオプションでは、リダクション・ポリシーが定義された表に対する問合せの結果に影響を与えずに、ポリシーの内部動作をテストできます。このオプションを使用して、リダクション・ポリシー定義を本番環境に適用する前にテストできます。

データ・リダクションでは、実行時、つまり、ユーザーがデータを表示する際にリダクションが行われます。この機能は、データが常に変化する動的本番システムに非常に適しています。データはリダクションされますが、Oracle Databaseはすべてのデータを通常どおり処理し、バックエンドの参照整合性制約を保持できます。データ・リダクションは、クレジットカード業界のセキュリティ基準(PCI DSS)やサーベンス・オクスリー法などの業界の規則の順守に役立ちます。

第I部 透過的データ暗号化の使用

第I部では、透過的データ暗号化を使用する方法について説明します。

内容は次のとおりです。

- 透過的データ暗号化の概要

- 透過的データ暗号化の構成

- キーストアおよびTDEマスター暗号化鍵の管理

- 透過的データ暗号化を使用する場合の一般的な考慮事項

- 他の Oracle機能における透過的データ暗号化の使用

2 透過的データ暗号化の概要

透過的データ暗号化を使用すると、データを暗号化できます。通常、クレジット・カード番号や社会保障番号などの機密データを暗号化します。

内容は次のとおりです。

- 透過的データ暗号化とは

- 透過的データ暗号化を使用する利点

- 透過的データ暗号化を構成できる者

- 透過的データ暗号化のタイプおよびコンポーネント

透過的データ暗号化とは

透過的データ暗号化(TDE)を使用すると、表および表領域に格納する機密データを暗号化できます。

暗号化されたデータは、アクセス時に、許可されているユーザーまたはアプリケーションに対して自動的に復号化されます。TDEは、記憶域メディアまたはデータ・ファイルが盗まれた場合に、メディアに格納されているデータ(保存データとも呼ぶ)を保護するために役立ちます。

Oracle Databaseの認証、認可および監査メカニズムは、データベース内のデータを保護するためのものであり、オペレーティング・システムのデータ・ファイルに格納されているデータの保護には使用されません。このようなデータ・ファイルを保護する目的では、透過的データ暗号化(TDE)を使用します。TDEを使用すると、データ・ファイルに格納されている機密データを暗号化できます。許可なく復号化されるのを防止するため、TDEにより暗号化鍵はデータベース外部のキーストアと呼ばれるセキュリティ・モジュールに格納されます。

Oracle Key VaultをTDE実装の一部として構成できます。これにより、企業内でTDEキーストア(Oracle Key VaultではTDEウォレットと呼ばれます)を集中管理できます。たとえば、ソフトウェア・キーストアをOracle Key Vaultにアップロードし、このキーストアの内容を他のTDE対応データベースで利用可能にすることができます。詳細は、Oracle Key Vault管理者ガイドを参照してください。

透過的データ暗号化を使用する利点

透過的データ暗号化(TDE)によって、機密データの暗号化とコンプライアンスの順守が保証され、暗号化操作を簡略化する機能が提供されます。

利点は次のとおりです。

- セキュリティ管理者としては、機密データが暗号化されるため、記憶域メディアまたはデータ・ファイルが盗まれた場合でも安全であることを確信できます。

- TDEを使用すると、セキュリティに関連した規制コンプライアンスの問題への対応に役立ちます。

- 許可されたユーザーまたはアプリケーションに対してデータを復号化するための補助表、トリガーまたはビューを作成する必要はありません。表内のデータは、データベース・ユーザーやアプリケーションに対して透過的に復号化されます。機密データを処理するアプリケーションでTDEを使用すると、アプリケーションをほとんどあるいはまったく変更せずに、強力なデータ暗号化を実現できます。

- データは、このデータにアクセスするデータベース・ユーザーおよびアプリケーションに対して透過的に復号化されます。データベース・ユーザーおよびアプリケーションは、アクセスするデータが暗号化された形式で格納されていることを認識する必要がありません。

- 本番システムでは表のオンライン再定義を使用して停止時間ゼロでデータを暗号化することができ、メンテナンス期間中にはデータをオフラインで暗号化することができます。(表のオンライン再定義の詳細は、Oracle Database管理者ガイドを参照してください。)

- 暗号化されたデータを処理するためにアプリケーションを変更する必要がありません。データベースは、データの暗号化および復号化を管理します。

- Oracle Databaseによって、TDEマスター暗号化鍵とキーストアの管理操作が自動化されます。ユーザーやアプリケーションがTDEマスター暗号化鍵を管理する必要はありません。

透過的データ暗号化を構成できる者

透過的データ暗号化(TDE)を構成するには、ADMINISTER KEY MANAGEMENTシステム権限が付与されている必要があります。

マウント段階でキーストアを開く必要がある場合は、SYSKM管理権限が付与されている必要があり、この権限には、ADMINISTER KEY MANAGEMENTシステム権限および必要な他の権限が含まれています。

ユーザーにSYSKM管理権限を付与する場合、ユーザーがパスワードを使用してSYSKMとしてデータベースに接続できるように、これに対するパスワード・ファイルを確実に作成してください。これにより、ユーザーはV$DATABASEビューの問合せなどの操作を実行できます。

TDEの列または表領域の暗号化を構成するには、SYSKMまたはADMINISTER KEY MANAGEMENT権限は必要ありません。表および表領域に対してTDEポリシーを作成するには、次の追加の権限が必要になります。

- CREATE TABLE

- ALTER TABLE

- CREATE TABLESPACE

透過的データ暗号化のタイプおよびコンポーネント

透過的データ暗号化は、個々の列または表領域全体に適用できます。

内容は次のとおりです。

- 透過的データ暗号化のタイプおよびコンポーネントについて

- 透過的データ暗号化列暗号化の動作

- 透過的データ暗号化表領域暗号化の動作

- TDEマスター暗号化鍵の格納用のキーストアの動作

- サポートされる暗号化と整合性のアルゴリズム

透過的データ暗号化のタイプおよびコンポーネントについて

機密データを列レベルまたは表領域レベルで暗号化できます。

列レベルでは、選択した表の列を使用してデータを暗号化できます。TDE表領域暗号化を使用すると、表領域に格納されているすべてのデータを暗号化できます。

TDE列暗号化とTDE表領域暗号化では、どちらも2層の鍵ベース・アーキテクチャを使用します。セキュリティ攻撃を試みている侵入者など、許可されていないユーザーは、データを復号化するTDEマスター暗号化鍵を持っていないかぎり、ストレージおよびバックアップ・メディアのデータを読み取れません。

透過的データ暗号化列暗号化の動作

透過的データ暗号化(TDE)列暗号化は、表の列に格納されている、クレジット・カード番号や社会保障番号などの機密データを保護します。

TDE列暗号化では、2層の鍵ベース・アーキテクチャを使用して、機密の表の列を透過的に暗号化および復号化します。TDEマスター暗号化鍵は、外部セキュリティ・モジュールに格納され、このモジュールは、Oracleソフトウェア・キーストアまたはハードウェア・キーストアにすることができます。このTDEマスター暗号化鍵はTDE表キーを暗号化および復号化し、TDE表キーは表の列のデータの暗号化および復号化を行います。

図2-1に、TDE列暗号化プロセスの概要を示します。

図2-1 TDE列暗号化の概要

図2-1に示すように、TDEマスター暗号化鍵は、データベースの外側にあって、適切な権限を付与されたユーザーのみがアクセスできる外部セキュリティ・モジュールに格納されます。この外部セキュリティ・モジュールの場合、Oracle Databaseは、Oracleソフトウェア・キーストア(以前のリリースではウォレット)またはハードウェア・セキュリティ・モジュール(HSM)・キーストアを使用します。このようにTDEマスター暗号化鍵を格納することで、不正使用を防止できます。

外部セキュリティ・モジュールを使用すると、通常のプログラム機能と暗号化操作が分離されるため、データベース管理者およびセキュリティ管理者に別個の責務を割り当てることができます。データベース管理者にはキーストア・パスワードを知らせずに、セキュリティ管理者にパスワードの提供を要求できるため、セキュリティが強化されます。

表に暗号化列が含まれる場合、暗号化列の数に関係なく、TDEは単一のTDE表キーを使用します。各TDE表キーは、TDEマスター暗号化鍵によって個別に暗号化されます。TDE表キーはすべて、ENC$データ・ディクショナリの表のcolklc列に置かれます。鍵は平文には格納されません。

透過的データ暗号化表領域暗号化の動作

透過的データ暗号化(TDE)表領域暗号化を使用すると、表領域全体を暗号化できます。

暗号化されている表領域に作成されるオブジェクトはすべて自動的に暗号化されます。TDE表領域暗号化は、表の複数の列に機密データが含まれている場合、または個々の列だけでなく表全体を保護する場合に有用です。暗号化が必要な列を判断するために、各表の列を詳細に分析する必要はありません。

また、TDE表領域暗号化は、バルク暗号化とキャッシュを利用して、高度なパフォーマンスを実現します。アプリケーションに対する実際のパフォーマンスの影響は異なることがあります。

TDE表領域暗号化では、暗号化された表領域内に格納されているデータ(REDOデータなど)がすべて暗号化されます。TDE表領域暗号化では、表領域の外部に格納されているデータは暗号化されません。たとえば、BFILEデータは、データベース外部に格納されるため暗号化されません。暗号化された表領域内でBFILE列を含む表を作成した場合、この特別な列は暗号化されません。

暗号化された表領域内のデータはすべて、暗号化された形式でディスク上に格納されます。データの表示または変更に必要な権限を付与されているユーザーに対しては、データが透過的に復号化されます。データベース・ユーザーやアプリケーションは、特定の表がディスク上で暗号化されているかどうかを認識する必要はありません。ディスク上のデータ・ファイルまたはバックアップ・メディアが盗まれた場合でも、データの安全性は損なわれません。

TDE表領域暗号化では、2層の鍵ベース・アーキテクチャを使用して、表領域を透過的に暗号化(および復号化)します。TDEマスター暗号化鍵は、外部セキュリティ・モジュール(ソフトウェア・キーストアまたはハードウェア・キーストア)に格納されます。このTDEマスター暗号化鍵はTDE表領域暗号化鍵の暗号化に使用され、TDE表領域暗号化鍵は表領域のデータの暗号化と復号化に使用されます。

図2-2に、TDE表領域暗号化プロセスの概要を示します。

図2-2 TDE表領域暗号化

注意:

暗号化データは、JOINやSORTなどの操作中も保護されます。これは、データを一時表領域に移動しても安全であることを意味します。UNDOログとREDOログのデータも保護されます。

TDE表領域暗号化を使用すると、暗号化された表領域のデータに対して索引レンジ・スキャンを実行することもできます。索引レンジ・スキャンは、TDE列暗号化では実行できません。

Oracle Databaseは、TDE表領域暗号化の次の機能を実装しています。

- TDE列暗号化とTDE表領域暗号化の両方に対して統合TDEマスター暗号化鍵を使用します。

- 統合TDEマスター暗号化鍵は再設定できます。これによってセキュリティが強化され、セキュリティ要件やコンプライアンス要件への対応が促進されます。

TDEマスター暗号化鍵の格納用のキーストアの動作

暗号化を制御するには、キーストアおよびTDEマスター暗号化鍵を使用します。

内容は次のとおりです。

- TDEマスター暗号化鍵のキーストア格納について

- キーストア格納フレームワークの利点

- キーストアのタイプ

TDEマスター暗号化鍵のキーストア格納について

Oracle Databaseは、鍵および資格証明を格納および管理する透過的データ暗号化用のキー管理フレームワークを提供します。

キー管理フレームワークには、TDEマスター暗号化鍵を安全に格納するキーストア、および様々なデータベース・コンポーネント用のキーストアおよびキー操作を安全かつ効率的に管理する管理フレームワークが含まれています。

Oracleキーストアにはそれまで使用されたTDEマスター暗号化鍵の履歴が格納されますが、これにより、TDEマスター暗号化鍵を変更したり、以前のTDEマスター暗号化鍵で暗号化されたデータを復号化することができます。

キーストア格納フレームワークの利点

キー管理フレームワークは、透過的データ暗号化にとって次の利点があります。

- データベース管理者と鍵を管理するセキュリティ管理者の間で責務を分離できます。キーストアおよび鍵操作の管理の責任を負うユーザーにADMINISTER KEY MANAGEMENTまたはSYSKM権限を付与できます。

- コンプライアンスを容易にします(暗号化鍵の追跡、およびキーストア・パスワード・ローテーションやTDEマスター暗号化鍵の再設定または更新操作などの要件の実装に役立つためです)。

- キーストア・バックアップ要件を容易にし、これの実施に役立ちます。バックアップとは、すべての重要なキーストア操作用に作成されたパスワードベースのソフトウェア・キーストアのコピーです。
すべての重要なキーストア操作用にキーストアのバックアップを作成する必要があります。このTDEマスター暗号化鍵の再設定またはキー更新を行う前に、TDEマスター暗号化鍵のバックアップを作成する必要もあります。

- ASMファイル・システムにキーストアを格納できるようにします。これは、データベース・インスタンスが統一ファイル・システム・ビューを共有するOracle Real Application Clusters (Oracle RAC)環境にとって特に有用です。

- ハードウェア・セキュリティ・モジュール(HSM)・キーストアからファイルシステム・ベースのソフトウェア・キーストアへの逆移行を可能にします。このオプションは、ソフトウェア・キーストアに移行する必要がある場合に有用です。

キーストアのタイプ

Oracle Databaseは、ソフトウェア・キーストアとハードウェア(HSMベースの)キーストアをサポートしています。

次のタイプのソフトウェア・キーストアを構成できます。

- パスワードベースのソフトウェア・キーストア: パスワードベースのソフトウェア・キーストアは、作成したパスワードを使用することで保護されます。鍵が取得または使用される前にこのタイプのキーストアを開く必要があります。

- 自動ログイン・ソフトウェア・キーストア: 自動ログイン・ソフトウェア・キーストアはシステム生成のパスワードによって保護されます。セキュリティ・マネージャによって明示的に開かれる必要はありません。自動ログイン・ソフトウェア・キーストアは、アクセスすると自動的に開きます。自動ログイン・ソフトウェア・キーストアは異なるシステム間で使用できます。使用する際、明示的に開く必要のあるキーストアで提供される特別なセキュリティが不要な環境の場合、自動ログイン・ソフトウェア・キーストアを使用できます。自動ログイン・ソフトウェア・キーストアは、無人シナリオに最適です。

- ローカル自動ログイン・ソフトウェア・キーストア: ローカル自動ログイン・ソフトウェア・キーストアは、作成されたコンピュータに対してローカルな自動ログイン・ソフトウェア・キーストアです。ローカル自動ログイン・キーストアは、作成されたコンピュータ以外では開けません。このタイプのキーストアは、無人操作をサポートしながら、追加のセキュリティが必要なシナリオ(つまり、このコンピュータに対する自動ログインの使用を制限すること)に対して通常使用されます。

ソフトウェア・キーストアは、ASMディスク・グループまたは通常のファイル・システムに格納できます。

ハードウェア・セキュリティ・モジュールとは、ハードウェア・キーストアに暗号化鍵を安全に格納する物理デバイスです。HSMはまた、暗号化と復号化の操作を実行するための計算領域(メモリー)も保護します。

HSMを使用する場合、TDEマスター暗号化鍵を使用する暗号化および復号化操作はすべて、HSMの内部で実行されます。これは、安全性の低いメモリーにTDEマスター暗号化鍵がさらされないことを意味します。

サポートされる暗号化と整合性のアルゴリズム

デフォルトでは、透過的データ暗号化(TDE)列暗号化では、192ビット長の暗号化鍵を使用するAdvanced Encryption Standard (AES192)が使用されます。

また、特に指定しないかぎり、暗号化の前に平文にsaltがデフォルトで追加されます。暗号化の対象となる索引付けされた列にはsaltを追加できません。索引付けされた列に対しては、SQL ENCRYPT句でNO SALTパラメータを選択します。

透過的データ暗号化(TDE)表領域暗号化の場合、128ビット長の暗号化鍵を使用するAdvanced Encryption Standard (AES128)がデフォルトで使用されます。また、常に、暗号化の前に平文にsaltが追加されます。

既存の暗号化列の暗号化アルゴリズムおよび暗号化鍵を変更するには、SQL ENCRYPT句で別のアルゴリズムを設定します。

表2-1に、サポートされる暗号化アルゴリズムを示します。

表2-1 透過的データ暗号化でサポートされる暗号化アルゴリズム

アルゴリズム

鍵サイズ

パラメータ名

Triple Encryption Standard (DES)

168ビット

3DES168

Advanced Encryption Standard(AES)

128ビット

AES128

AES

- 列レベル暗号化のデフォルトは192ビット

- 表領域の暗号化のデフォルトは128ビット

- AES192 (列レベルの暗号化)

- AES128 (表領域の暗号化)

AES

256ビット

AES256

TDE列暗号化の整合性保護のために、SHA-1ハッシュ・アルゴリズムが使用されます。格納に制限がある場合、NOMACオプションを使用します。

関連項目:

- SQL ENCRYPT句にNO SALTパラメータを選択する際の正しい構文の詳細は、アルゴリズムを使用しないまたは非デフォルト・アルゴリズムを使用する暗号化列を含む表の作成を参照してください。

- CREATE TABLE文でのNOMACオプションの詳細は、「ディスク領域の節約およびパフォーマンスの向上のためのNOMACパラメータの使用」を参照してください

- SQL ENCRYPT句で別のアルゴリズムを設定する場合の構文例は、暗号化列を含む表に対する暗号化鍵またはアルゴリズムの変更を参照してください。

第3章 透過的データ暗号化の構成

ソフトウェアおよびハードウェアのキーストアは、個々の表列または表領域全体の両方で使用するために構成できます。

内容は次のとおりです。

- ソフトウェア・キーストアの構成

- ハードウェア・キーストアの構成

- 表の列の暗号化

- 表領域の暗号化

- 透過的データ暗号化のデータの動的ビューおよびデータ・ディクショナリ・ビュー

ソフトウェア・キーストアの構成

ソフトウェア・キーストアとは、ソフトウェアのファイル・システム上にあるTDEマスター暗号化鍵のコンテナです。

内容は次のとおりです。

- ソフトウェア・キーストアの構成について

- 手順1: sqlnet.oraファイルでのソフトウェア・キーストアの場所の設定

- 手順2: ソフトウェア・キーストアの作成

- 手順3: ソフトウェア・キーストアを開く

- 手順4: ソフトウェアTDEマスター暗号化鍵の設定

- 手順5: データの暗号化

ソフトウェア・キーストアの構成について

ソフトウェア・キーストアとは、透過的データ暗号化マスター暗号化鍵を格納するコンテナです。

キーストアを構成する前に、まずsqlnet.oraファイルでその場所を定義する必要があります。1つのデータベースあたり1つのキーストアがあり、データベースは、sqlnet.oraファイルで定義したキーストアの場所を確認することで、このキーストアを探します。必要に応じて、キーストアのコピーなどの他のキーストアを作成したり、鍵が含まれているファイルをエクスポートすることができます。ただし、sqlnet.oraの場所で構成したキーストアを除去または削除したり、別のキーストアで置き換えることはできません。

sqlnet.oraファイルでソフトウェア・キーストアの場所を構成したら、データベース・インスタンスにログインしてキーストアを作成して開き、次にTDEマスター暗号化鍵を設定できます。これらの手順を完了したら、データの暗号化を開始できます。

手順1: sqlnet.oraファイルでのソフトウェア・キーストアの場所の設定

ソフトウェア・キーストアを構成するには、まずsqlnet.oraファイル内にその場所を指定します。

内容は次のとおりです。

- sqlnet.oraファイルでのキーストアの場所について

- ソフトウェア・キーストアの場所用のsqlnet.oraファイルの構成

- 例: 通常のファイル・システム用のソフトウェア・キーストアの構成

- 例: 複数のデータベースでsqlnet.oraファイルを共有する場合のソフトウェア・キーストアの構成

- 例: Oracle Automatic Storage Management用のソフトウェア・キーストアの構成

- 例: Oracle Automatic Storage Managementディスク・グループ用のソフトウェア・キーストアの構成

sqlnet.oraファイルでのキーストアの場所について

ソフトウェア・キーストアであろうと、ハードウェア・モジュール・セキュリティ(HSM)・キーストアであろうと、Oracle Key Vaultのキーストアであろうと、Oracle Databaseは、sqlnet.oraファイルを確認してキーストアのディレクトリ場所を探します。

sqlnet.oraファイルを編集して、作成する予定のキーストアのディレクトリ場所を定義する必要があります。このディレクトリが事前に存在していることを確認してください。このディレクトリは空であると理想的です。

Oracle Real Application Clusters (Oracle RAC)またはマルチテナント環境でsqlnet.oraファイルを編集する必要がある場合は、次の動作に注意してください。

- Oracle RAC環境: srvctlユーティリティを使用していて、sqlnet.ora構成ファイルに環境変数を含める場合は、各環境変数をオペレーティング・システムとsrvctl環境の両方に設定する必要があります。Oracle Automatic Storage Management (ASM)またはNFSなどの共有ファイル・システム上にキーストアを配置することをお薦めします。

- マルチテナント環境: キーストアの場所は、個々のプラガブル・データベース(PDB)用ではなくマルチテナントのコンテナ・データベース(CDB)全体に設定されます。

sqlnet.oraファイルで、ENCRYPTION_WALLET_LOCATIONパラメータを設定してキーストアの場所を指定する必要があります。どのキーストアを使用するかを決める場合、Oracle Databaseは、次の場所においてこの順序でキーストアの場所を検索します。

1. sqlnet.oraファイルでパラメータENCRYPTION_WALLET_LOCATIONによって指定されている場所にあるキーストアの使用を試行します。

2. ENCRYPTION_WALLET_LOCATIONパラメータが設定されていない場合は、パラメータWALLET_LOCATIONによって指定されている場所にあるキーストアの使用を試みます。

3. WALLET_LOCATIONパラメータも設定されていない場合は、Oracle Databaseは、デフォルトのデータベースの場所でキーストアを探します。この場所は、ORACLE_BASE/admin/DB_UNIQUE_NAME/walletまたはORACLE_HOME/admin/DB_UNIQUE_NAME/walletです。(DB_UNIQUE_NAMEは、初期化パラメータ・ファイルで指定されたデータベースの固有の名前です。)キーストアの場所がsqlnet.oraファイルに設定されていない場合、V$ENCRYPTION_WALLETビューにはデフォルトの場所が表示されます。キーストアの場所およびステータスは、V$ENCRYPTION_WALLETビューで確認できます。

デフォルトでは、sqlnet.oraファイルは、ORACLE_HOMEdbsディレクトリ、またはTNS_ADMIN環境変数によって設定されている場所にあります。正しいsqlnet.oraファイルを指すようにTNS_ADMIN環境変数が適切に設定されていることを確認してください。

関連項目:
TNS_ADMIN環境変数の設定例の詳細は、『SQL*Plusユーザーズ・ガイドおよびリファレンス』を参照してください

ソフトウェア・キーストアの場所用のsqlnet.oraファイルの構成

sqlnet.oraファイルを使用して、通常のファイル・システム用、複数データベースのアクセス用、およびOracle Automatic Storage Management (ASM)用にキーストアの場所を構成します。

- 通常のファイル・システムでソフトウェア・キーストアを作成するには、sqlnet.oraファイルを編集するときに次のフォーマットを使用します。

ENCRYPTION_WALLET_LOCATION=
(SOURCE=
(METHOD=FILE)
(METHOD_DATA=
(DIRECTORY=path_to_keystore)))

path_to_keystoreが環境変数を含むことになる場合、データベース・インスタンスが起動した環境で、データベースを起動する前に、この変数を設定します。srvctlユーティリティを使用してデータベースを起動する場合、次のコマンドを使用してsrvctl環境にも環境変数を設定します。

srvctl setenv database -db database_name -env "environment_variable_name=environment_variable_value"

例: 通常のファイル・システム用のソフトウェア・キーストアの構成

通常のファイル・システムにソフトウェア・キーストアを構成できます。

次の例では、データベース名がorclである通常のファイル・システム用にsqlnet.oraファイルにソフトウェア・キーストアの場所を構成する方法を示します。

ENCRYPTION_WALLET_LOCATION=
(SOURCE=
(METHOD=FILE)
(METHOD_DATA=
(DIRECTORY=/etc/ORACLE/WALLETS/orcl)))

例: 複数のデータベースでsqlnet.oraファイルを共有する場合のソフトウェア・キーストアの構成

複数のデータベースでsqlnet.oraファイルを共有するように構成できます。

次の例では、複数のデータベースでsqlnet.oraファイルを共有する場合にソフトウェア・キーストアの場所を構成する方法を示します。

ENCRYPTION_WALLET_LOCATION=
(SOURCE=
(METHOD=FILE)
(METHOD_DATA=
(DIRECTORY=/etc/ORACLE/WALLETS/$ORACLE_SID/)))

例: Oracle Automatic Storage Management用のソフトウェア・キーストアの構成

Automatic Storage Management (ASM)ファイル・システムにsqlnet.oraを構成できます。

次の例では、ASMファイル・システム用にsqlnet.oraファイルにソフトウェア・キーストアの場所を構成する方法を示します。

ENCRYPTION_WALLET_LOCATION=
(SOURCE=
(METHOD=FILE)
(METHOD_DATA=
(DIRECTORY=+disk1/mydb/wallet)))

例: Oracle Automatic Storage Managementディスク・グループ用のソフトウェア・キーストアの構成

Oracle Automatic Storage Management (ASM)ディスク・グループにsqlnet.oraを構成できます。

次のフォーマットは、ASMディスク・グループでソフトウェア・キーストアの場所を作成する場合にソフトウェア・キーストアを構成する方法を示しています。

ENCRYPTION_WALLET_LOCATION=
(SOURCE=
(METHOD=FILE)
(METHOD_DATA=
(DIRECTORY=+ASM_file_path_of_the_diskgroup)))

手順2: ソフトウェア・キーストアの作成

ソフトウェア・キーストアのディレクトリの場所を指定したら、キーストアを作成できます。

内容は次のとおりです。

- ソフトウェア・キーストアを作成することについて

- パスワードベースのソフトウェア・キーストアの作成

- 自動ログイン・ソフトウェア・キーストアまたはローカル自動ログイン・ソフトウェア・キーストアの作成

ソフトウェア・キーストアを作成することについて

3つの異なるタイプのソフトウェア・キーストアがあります。

パスワードベースのソフトウェア・キーストア、自動ログイン・ソフトウェア・キーストアおよびローカル自動ログイン・ソフトウェア・キーストアを作成できます。

問合せSELECT * FROM V$ENCRYPTION_WALLETを実行すると、自動ログイン・ソフトウェア・キーストアが自動的に開くため、注意してください。たとえば、パスワードベースのキーストアと自動ログイン・キーストアがあるとします。パスワードベースのキーストアが開いているときに、このパスワードベースのキーストアを閉じて、V$ENCRYPTION_WALLETビューを問い合せると、出力にキーストアが開いていることが示されます。ところが、これはV$ENCRYPTION_WALLETが自動ログイン・ソフトウェア・キーストアを開いて、自動ログイン・キーストアのステータスを表示したことによるものです。

関連項目:

ソフトウェア・キーストアの詳細は、キーストアのタイプを参照してください。

パスワードベースのソフトウェア・キーストアの作成

パスワードベースのソフトウェア・キーストアには、キーストアに格納される鍵と資格証明を保護するために使用するユーザー・パスワードが必要です。

1. 「手順1: sqlnet.oraファイルでのソフトウェア・キーストアの場所の設定」で説明した手順が完了していることを確認します。

2. ADMINISTER KEY MANAGEMENTまたはSYSKM権限が付与されたユーザーとして、データベース・インスタンスにログインします。
マルチテナント環境では、rootとしてログインします。例:

sqlplus c##sec_admin as syskm
Enter password: password
Connected.

SQL*Plusがすでに開かれていて、この間にsqlnet.oraファイルを変更した場合、SQL*Plusに再接続します。データベース・セッションはsqlnet.oraの変更が有効になる前に変更される必要があります。

3. ADMINISTER KEY MANAGEMENT SQL文を実行してキーストアを作成します。
構文は次のとおりです。

ADMINISTER KEY MANAGEMENT CREATE KEYSTORE 'keystore_location' IDENTIFIED BY software_keystore_password;

ここでは次のように指定します。

- keystore_locationは、自動ログイン・キーストアを作成するパスワードベースのキーストアのキーストア・ディレクトリの場所に対するパスです(/etc/ORACLE/WALLETS/orclなど)。keystore_location設定は一重引用符(' ')で囲みます。この場所を見つけるには、V$ENCRYPTION_WALLETビューのWRL_PARAMETER列を問い合せます。(キーストアがデフォルトの場所に作成されていない場合、V$ENCRYPTION_WALLETビューのSTATUS列はNOT_AVAILABLEになります。)

- software_keystore_passwordは、セキュリティ管理者が作成するキーストアのパスワードです。

たとえば、/etc/ORACLE/WALLETS/orclディレクトリにキーストアを作成する場合、次のようになります。

ADMINISTER KEY MANAGEMENT CREATE KEYSTORE '/etc/ORACLE/WALLETS/orcl' IDENTIFIED BY password;

keystore altered.

この文を実行すると、キーストアとなるewallet.p12ファイルがキーストアの場所に生成されます。

自動ログイン・ソフトウェア・キーストアまたはローカル自動ログイン・ソフトウェア・キーストアの作成

パスワードベースのキーストアの別の方法として、自動ログイン・ソフトウェア・キーストアまたはローカル自動ログイン・ソフトウェア・キーストアのいずれかを作成できます。

これらのキーストアの両方は、システム生成パスワードを持っています。これらは、PKCS#12ベースのファイルでもあります。自動ログイン・ソフトウェア・キーストアは、このキーストアがあるコンピュータとは違うコンピュータから開くことができますが、ローカル自動ログイン・ソフトウェア・キーストアは、このキーストアが作成されたコンピュータからしか開けません。自動ログイン・キーストアとローカル自動ログイン・キーストアの両方は、パスワードベースのソフトウェア・キーストアから作成されます。

1. 「手順1: sqlnet.oraファイルでのソフトウェア・キーストアの場所の設定」で説明した手順が完了していることを確認します。

2. ADMINISTER KEY MANAGEMENTまたはSYSKM権限が付与されたユーザーとして、データベース・インスタンスにログインします。
マルチテナント環境では、rootとしてログインします。例:

sqlplus c##sec_admin as syskm
Enter password: password
Connected.

SQL*Plusがすでに開かれていて、この間にsqlnet.oraファイルを変更した場合、SQL*Plusに再接続します。データベース・セッションはsqlnet.oraの変更が有効になる前に変更される必要があります。

3. パスワードベースのソフトウェア・キーストアの作成に記載されているように、パスワードベースのソフトウェア・キーストアを作成します。

4. ADMINISTER KEY MANAGEMENT SQL文を実行してキーストアを作成します。
構文は次のとおりです。

ADMINISTER KEY MANAGEMENT CREATE [LOCAL] AUTO_LOGIN KEYSTORE FROM KEYSTORE 'keystore_location' IDENTIFIED BY software_keystore_password;

ここでは次のように指定します。

- LOCALでは、ローカル自動ログイン・ソフトウェア・キーストアを作成できます。そうでない場合、キーストアに他のコンピュータからアクセスできるようにするときは、この句を省略します。

- keystore_locationは、自動ログイン・キーストアを作成するパスワードベースのキーストアのディレクトリの場所に対するパスです(/etc/ORACLE/WALLETS/orclなど)。この設定は一重引用符(' ')で囲みます。この場所を確認するには、V$ENCRYPTION_WALLETビューのWRL_PARAMETER列を問い合せます。

- software_keystore_passwordは、自動ログイン・キーストアを作成するパスワードベースのキーストアです。

たとえば、パスワードベースのキーストアの自動ログイン・ソフトウェア・キーストアを/etc/ORACLE/WALLETS/orclディレクトリに作成するには、次のようにします。

ADMINISTER KEY MANAGEMENT CREATE AUTO_LOGIN KEYSTORE FROM KEYSTORE '/etc/ORACLE/WALLETS/orcl' IDENTIFIED BY password;

keystore altered.

この文を実行した後、cwallet.ssoファイルがキーストアの場所に表示されます。ewallet.p12ファイルがパスワードベースのウォレットです。

注意:

自動ログイン・キーストア(.ssoファイル)の作成後は、PKCS#12ウォレット(ewallet.p12ファイル)は削除しないでください。将来、TDEマスター暗号化鍵を再生成またはキー更新するには、PKCS#12ウォレットが必要です。デフォルトでは、このファイルは、$ORACLE_HOME/admin/ORACLE_SID/walletディレクトリにあります。

透過的データ暗号化が自動ログイン・キーストアを使用するのは、このキーストアが正しい場所(ENCRYPTION_WALLET_LOCATION、WALLET_LOCATIONまたはデフォルトのキーストアの場所)にあり、かつ、暗号化されたキーストアを開くためのSQLがまだ実行されていない場合のみです。(自動ログイン・キーストアにはシステム生成のパスワードがあり、暗号化されていることに注意してください。)

関連項目:

キーストアの削除

手順3: ソフトウェア・キーストアを開く

作成したキーストアの種類に応じて、使用する前にキーストアを手動で開く必要があります。

内容は次のとおりです。

- ソフトウェア・キーストアを開くことについて

- ソフトウェア・キーストアを開く

ソフトウェア・キーストアを開くことについて

キーストアでTDEマスター暗号化鍵を作成するか、これにアクセスする前に、パスワードベースのソフトウェア・キーストアを手動で開く必要があります。

自動ログイン・ソフトウェア・キーストアまたはローカル自動ログイン・ソフトウェア・キーストアは手動で開く必要はありません。これらのキーストアは、必要時に(暗号化操作で鍵にアクセスする必要がある場合に)自動的に開かれます。必要に応じて、これらのタイプのどのキーストアでも明示的に閉じることができます。V$ENCRYPTION_WALLETビューのSTATUS列を問い合せることで、キーストアが開いているか、閉じているか、開いていてもマスター鍵がないか、開いていても不明なマスター鍵があるかといったステータスを確認できます。

キーストアを開くと、手動で閉じるまでキーストアは開いたままになります。データベース・インスタンスを再起動するたびに、パスワード・キーストアを手動で開いて暗号化と復号化の操作を再有効化する必要があります。

関連項目:

マルチテナント環境でのキーストアの開閉操作の機能

ソフトウェア・キーストアを開く

ソフトウェア・キーストアを開くには、SET KEYSTORE OPEN句を含むADMINISTER KEY MANAGEMENT文を使用する必要があります。

1. 手順2: ソフトウェア・キーストアの作成に記載されている手順を完了したことを確認します。

2. ADMINISTER KEY MANAGEMENTまたはSYSKM権限が付与されたユーザーとして、データベース・インスタンスにログインします。

マルチテナント環境の場合、キーストアをPDBで開く前に、まずrootで開く必要があります。たとえば、rootにログインするには、次のようにします。

sqlplus c##sec_admin as syskm
Enter password: password
Connected.

利用可能なPDBを検索するには、DBA_PDBSデータ・ディクショナリ・ビューを問い合せます。現在のPDBを確認するには、show con_nameコマンドを実行します。

3. ADMINISTER KEY MANAGEMENT文を実行します。

次の構文を使用します。

ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY software_keystore_password [CONTAINER = ALL | CURRENT];

ここでは次のように指定します。

- software_keystore_passwordは、「手順2: ソフトウェア・キーストアの作成」でキーストアを作成するために使用したものと同じパスワードです。

- CONTAINERは、マルチテナント環境で使用するために用意されています。このCDBのすべてのPDBでキーストアを設定するには、ALLを入力するか、現在のPDBでキーストアを設定するには、CURRENTを入力します。
例:

ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY password;

keystore altered.

キーストアが開いていても、TDEマスター暗号化鍵をまだ作成していない場合は(後で説明します)、V$ENCRYPTION_WALLETビューのSTATUS列によってOPEN_NO_MASTER_KEYステータスが知らされます。

手順4: ソフトウェアTDEマスター暗号化鍵の設定

キーストアが開いたら、それに対してTDEマスター暗号化鍵を設定できます。

内容は次のとおりです。

- ソフトウェアTDEマスター暗号化鍵の設定について

- ソフトウェア・キーストアのTDEマスター暗号化鍵の設定

ソフトウェアTDEマスター暗号化鍵の設定について

TDEマスター暗号化鍵はキーストアに格納されます。

この鍵によって、TDE表キーおよび表領域暗号化鍵が保護されます。デフォルトでは、TDEマスター暗号化鍵は、透過的データ暗号化(TDE)によって生成される鍵です。V$ENCRYPTION_WALLETビューのSTATUS列を問い合せることで、キーストアに、設定されているマスター鍵がないかどうか、または不明なマスター鍵がないかどうかを確認できます。

マルチテナント環境では、rootまたはPDBからTDEマスター暗号化鍵を作成および管理できます。

注意:

後で使用するためにTDEマスター暗号化鍵を作成でき、その後それらを手動で有効にできます。詳細は、後で使用するためのTDEマスター暗号化鍵の作成を参照してください。

ソフトウェア・キーストアのTDEマスター暗号化鍵の設定

TDEマスター暗号化鍵をソフトウェア・キーストアに設定するには、SET KEY句を含むADMINISTER KEY MANAGEMENT文を使用する必要があります。

1. パスワード・ソフトウェア・キーストアの場合、手順3: ソフトウェア・キーストアを開くに記載されている、鍵を開くための手順を完了したことを確認します。
自動ログイン・ソフトウェア鍵またはローカル自動ログイン・ソフトウェア鍵は、作成された後で自動的に開きます。パスワードベースのソフトウェア・キーストアは、TDEマスター暗号化鍵を設定する前に開かれている必要があります。自動ログイン・ソフトウェア・キーストアが開いている場合、それを閉じてパスワードベースのソフトウェア・キーストアを開く必要があります。パスワードベースのキーストアと自動ログイン・キーストアの両方が構成済の場所に存在し、パスワードベースのキーストアが開いている場合、自動ログイン・キーストアにもTDEマスター暗号化鍵が自動的に書き込まれます。

2. ADMINISTER KEY MANAGEMENTまたはSYSKM権限が付与されたユーザーとして、データベース・インスタンスにログインします。
マルチテナント環境で、rootまたはPDBにログインします。たとえば、PDBとしてログインするには次を実行します。

sqlplus sec_admin@hrpdb as syskm
Enter password: password
Connected.

利用可能なPDBを検索するには、DBA_PDBSデータ・ディクショナリ・ビューを問い合せます。現在のPDBを確認するには、show con_nameコマンドを実行します。

3. データベースがREAD WRITEモードでオープンしていることを確認します。
OPEN_MODEがREAD WRITEに設定されている場合、TDEマスター暗号化鍵を設定できます。マルチテナント環境以外の環境に関するステータスを検索するには、V$DATABASE動的ビューのOPEN_MODE列を問い合せます。マルチテナント環境を使用している場合は、V$PDBSビューを問合せます。(これらのビューにアクセスできない場合は、SYSDBAとして接続し、問合せを再試行します。このタイプの問合せに対してSYSKMとして接続するには、これに対するパスワード・ファイルを作成する必要があります。詳細は、Oracle Database管理者ガイドを参照してください。)

4. SYSKM管理権限を使用して接続し、ADMINISTER KEY MANAGEMENT SQL文を実行してソフトウェア管理キーストアを設定します。

ADMINISTER KEY MANAGEMENT SET KEY [USING TAG 'tag'] IDENTIFIED BY keystore_password [WITH BACKUP [USING 'backup_identifier']] [CONTAINER = ALL | CURRENT];

ここでは次のように指定します。

- tagは、定義する関連の属性および情報です。この設定は一重引用符(' ')で囲みます。

- passwordは、「手順2: ソフトウェア・キーストアの作成」でキーストアを作成したときに作成した必須キーストア・パスワードです。

- WITH BACKUPを使用すると、キーストアのバックアップが作成されます。パスワードベースのキーストアの場合、このオプションを使用する必要があります。オプションでUSING句を使用し、バックアップの簡単な説明を追加できます。この説明は一重引用符(' ')で囲みます。この識別子は名前付きキーストア・ファイルに付加されます(たとえば、emp_key_backupがバックアップ識別子になっているewallet_time_stamp_emp_key_backup.p12)。オペレーティング・システムで使用されているファイル命名規則に従ってください。

- CONTAINERは、マルチテナント環境で使用するために用意されています。このCDBのすべてのPDBで鍵を設定するには、ALLを入力し、現在のPDBで設定するには、CURRENTを入力します。

例:

ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY keystore_password WITH BACKUP USING 'emp_key_backup';

keystore altered.

手順5: データの暗号化

ソフトウェア・キーストアの構成が完了すると、データの暗号化を開始できます。

個別の表の列または表領域全体のデータを暗号化できます。

- データの暗号化の詳細は、次のトピックを参照してください。

- 表の列の暗号化

- 表領域の暗号化

ハードウェア・キーストアの構成

ハードウェア・キーストアは暗号化鍵を保存するために設計された、ハードウェア・セキュリティ・モジュール(HSM)内にあります。

内容は次のとおりです。

- (外部の)ハードウェア・キーストアの構成について

- 手順1: sqlnet.oraファイルでのハードウェア・キーストアのタイプの設定

- 手順2: ハードウェア・セキュリティ・モジュールの構成

- 手順3: ハードウェア・キーストアを開く

- 手順4: ハードウェア・キーストアのTDEマスター暗号化鍵の設定

- 手順5: データの暗号化

(外部の)ハードウェア・キーストアの構成について

ハードウェア・キーストアは、暗号化鍵のために安全な記憶域を提供する独立したサーバーまたはデバイスです。

外部のキーストアは、Oracle Databaseの外部にあります。Oracle Databaseは外部のキーストアと相互に接続できますが、Oracleインタフェースの外部でキーストアを操作できません。Oracle Databaseは外部キーストアに鍵を作成するように要求できますが、この鍵を外部データベースに格納する方法を定義することはできません。(反対に、TDEを使用して作成されたソフトウェア・キーストアの場合、Oracle Databaseでは完全に制御できます。すなわち、SQL文を使用してこのタイプのキーストアを操作できます。)外部キーストアの例には、ハードウェア・セキュリティ・モジュールやOracle Key Vaultキーストアがあります。複数のデータベースの外部キーストアは、Oracle Key Vaultなどを使用して集中管理できます。

ハードウェア・セキュリティ・モジュール(ハードウェア・キーストア)のキーストアを構成するには、まずsqlnet.oraファイルにキーストア・タイプを含め、ハードウェア・キーストアを構成して開き、ハードウェア・キーストアTDEマスター暗号化鍵を設定します。要するに、1つのデータベースあたり1つのハードウェア・キーストアがあり、データベースは、sqlnet.oraファイルで定義したキーストア・タイプを確認することで、このキーストアを探します。

ハードウェア・キーストアを構成すると、データの暗号化を開始する準備ができます。

手順1: sqlnet.oraファイルでのハードウェア・キーストアのタイプの設定

ハードウェア・キーストアを構成する前に、sqlnet.oraファイルを変更する必要があります。

デフォルトでは、このファイルは、ORACLE_HOMEdbsディレクトリ、またはTNS_ADMIN環境変数によって設定されている場所にあります。

- sqlnet.oraファイルの次の設定を使用して、ハードウェア・キーストアのタイプ(HSM)を定義します。

ENCRYPTION_WALLET_LOCATION=
(SOURCE=
(METHOD=HSM))

関連項目:

- Oracle Databaseがキーストアの場所を探す方法の詳細は、sqlnet.oraファイルでのキーストアの場所についてを参照してください。

- これらの2つのキーストア・タイプ間の移行のためにsqlnet.oraファイルを構成する方法の詳細は、ソフトウェア・パスワード・キーストアとハードウェア・キーストア間の移行を参照してください。

手順2: ハードウェア・セキュリティ・モジュールの構成

サード・パーティのハードウェア・セキュリティ・モジュールを構成するには、PKCS#11ライブラリを正しい場所にコピーして、ベンダーの指示に従う必要があります。

1. 手順1: sqlnet.oraファイルでのハードウェア・キーストアのタイプの設定に記載されている手順を完了したことを確認します。

2. PKCS#11ライブラリを正しいパスにコピーします。
ハードウェア・セキュリティ・モジュール・ベンダーから関連のPKCS#11ライブラリの提供を受けているはずです。一度にサポートされるのは、1つのPKCS#11ライブラリのみです。新しいベンダーのHSMを使用する場合は、PKCS#11ライブラリを以前のベンダーのものから新しいベンダーのものに置き換える必要があります。

このライブラリを適切な場所にコピーして、Oracle Databaseがこのライブラリを見つけられるようにします。

- UNIXシステム: 次の構文を使用して、このディレクトリにライブラリをコピーします。

/opt/oracle/extapi/[32,64]/hsm/{VENDOR}/{VERSION}/libapiname.so

- Windowsシステム: 次の構文を使用して、このディレクトリにライブラリをコピーします。

%SYSTEM_DRIVE%\oracle\extapi\[32,64]\hsm\{VENDOR}\{VERSION}\libapiname.dll

ここでは次のように指定します。

- [32,64]には、提供されるバイナリが32ビットか64ビットかを指定します。

- VENDORは、ライブラリを提供しているベンダー名を表します。

- VERSIONは、ライブラリのバージョンを表します。なるべく、number.number.numberの形式を使用してください。

- apinameには、特に決まった形式はありません。ただし、構文に示すように、apinameの前にはlibという語を付ける必要があります。

3. ベンダーの指示に従ってハードウェア・セキュリティ・モジュールを設定してください。

ハードウェア・セキュリティ・モジュール管理インタフェース、およびHSMベンダーが提供する指示に従って、ハードウェア・セキュリティ・モジュールを設定します。ハードウェア・セキュリティ・モジュールと相互作用するためにデータベースが使用する必要があるユーザー・アカウントおよびパスワードを作成します。このプロセスは、Oracle Databaseと通信するハードウェア・キーストアを作成および構成します。

手順3: ハードウェア・キーストアを開く

ハードウェア・セキュリティ・モジュールを構成したら、使用する前にハードウェア・キーストアを開く必要があります。

内容は次のとおりです。

- ハードウェア・キーストアを開くことについて

- ハードウェア・キーストアを開く

ハードウェア・キーストアを開くことについて

暗号化または復号化を実行する前に、ハードウェア・キーストアがデータベースにアクセスできるようにするために、ハードウェア・キーストアを開く必要があります。

V$ENCRYPTION_WALLETビューのSTATUS列を問い合せることで、キーストアが開いているか、閉じているか、開いていてもTDEマスター暗号化鍵がないか、開いていても不明なマスター暗号化鍵があるかといったステータスを確認できます。

関連項目:

マルチテナント環境でのキーストアの開閉操作の機能

ハードウェア・キーストアを開く

ハードウェア・キーストアを開くには、SET KEYSTORE OPEN句を含むADMINISTER KEY MANAGEMENT文を使用します。

1. 手順2: ハードウェア・セキュリティ・モジュールの構成で説明した手順が完了していることを確認します。

2. ADMINISTER KEY MANAGEMENTまたはSYSKM権限が付与されたユーザーとして、データベース・インスタンスにログインします。
マルチテナント環境の場合、キーストアをPDBで開く前に、まずrootで開く必要があります。たとえば、rootにログインするには、次のようにします。

sqlplus sec_admin as syskm
Enter password: password
Connected.

利用可能なPDBを検索するには、DBA_PDBSデータ・ディクショナリ・ビューを問い合せます。現在のPDBを確認するには、show con_nameコマンドを実行します。

SQL*Plusがすでに開かれていて、この間にsqlnet.oraファイルを変更した場合、SQL*Plusに再接続します。データベース・セッションはsqlnet.oraの変更が有効になる前に変更される必要があります。

3. 次の構文を使用して、ADMINISTER KEY MANAGEMENT SQL文を実行します。

ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "user_id:password" [CONTAINER = ALL | CURRENT];

ここでは次のように指定します。

- user_idは、HSM管理インタフェースを使用してデータベース用に作成されたユーザーIDです。

- passwordは、HSM管理インタフェースを使用してユーザーIDに対して作成されたパスワードです。
user_id:password文字列を二重引用符(" ")で囲み、user_idとpasswordをコロン(:)で区切ります。

- CONTAINERは、マルチテナント環境で使用するために用意されています。このCDBのすべてのPDBでキーストアを設定するには、ALLを入力するか、現在のPDBでキーストアを設定するには、CURRENTを入力します。

例:

ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "psmith:password";

keystore altered.

4. データベース・インスタンスを再起動するたびにこの手順を繰り返します。

手順4: ハードウェア・キーストアのTDEマスター暗号化鍵の設定

ハードウェア・キーストアを開いた後で、ハードウェア・キーストアのTDEマスター暗号化鍵を設定できます。

内容は次のとおりです。

- ハードウェア・キーストアのTDEマスター暗号化鍵の設定について

- まだ構成していない場合のTDEマスター暗号化鍵の設定

- 前に構成したTDEマスター暗号化鍵の移行

ハードウェア・キーストアのTDEマスター暗号化鍵の設定について

ハードウェア・キーストア内に格納されたTDEマスター暗号化鍵を作成する必要があります。

Oracle Databaseは、TDEマスター暗号化鍵を使用して、ハードウェア・セキュリティ・モジュール内部のTDE表キーまたは表領域暗号化鍵の暗号化または復号化を行います。

透過的データ暗号化用にソフトウェア・キーストアをまだ構成していない場合、まだ構成していない場合のTDEマスター暗号化鍵の設定の手順に従います。TDE用にソフトウェア・キーストアをすでに構成している場合、前に構成したTDEマスター暗号化鍵の移行の説明に従ってそれをハードウェア・セキュリティ・モジュールに移行する必要があります。

現在のTDEマスター・キーとともに、Oracleウォレットでは、TDEマスター・キーをローテーションするキーの更新操作のたびに生成される履歴TDEマスター・キーを保持します。これらのTDEマスター・キーにより、履歴TDEマスター・キーのいずれかを使用して、以前に作成されたOracleデータベースのバックアップをリストアすることができます。

まだ構成していない場合のTDEマスター暗号化鍵の設定

透過的データ暗号化用にソフトウェア・キーストアをまだ構成していない場合は、この手順を完了する必要があります。

マルチテナント環境では、rootまたはPDBからTDEマスター暗号化鍵を作成および管理できます。

注意:

後で使用するためにTDEマスター暗号化鍵を作成でき、その後それらを手動で有効にできます。詳細は、後で使用するためのTDEマスター暗号化鍵の作成を参照してください。

1. 手順3: ハードウェア・キーストアを開くに記載されている手順を完了したことを確認します。

2. ADMINISTER KEY MANAGEMENTまたはSYSKM権限が付与されたユーザーとして、データベース・インスタンスにログインします。
マルチテナント環境で、rootまたはPDBにログインします。例:

sqlplus sec_admin@hrpdb as syskm
Enter password: password
Connected.

利用可能なPDBを検索するには、DBA_PDBSデータ・ディクショナリ・ビューを問い合せます。現在のPDBを確認するには、show con_nameコマンドを実行します。

3. データベースがREAD WRITEモードでオープンしていることを確認します。
OPEN_MODEがREAD WRITEに設定されている場合、TDEマスター暗号化鍵を設定できます。マルチテナント環境以外の環境に関するステータスを検索するには、V$DATABASE動的ビューのOPEN_MODE列を問い合せます。マルチテナント環境を使用している場合は、V$PDBSビューを問合せます。(これらのビューにアクセスできない場合は、SYSDBAとして接続し、問合せを再試行します。このタイプの問合せに対してSYSKMとして接続するには、これに対するパスワード・ファイルを作成する必要があります。詳細は、Oracle Database管理者ガイドを参照してください。)

4. 次のSQL文を実行します。

ADMINISTER KEY MANAGEMENT SET KEY [USING TAG 'tag'] [FORCE KEYSTORE] IDENTIFIED BY [EXTERNAL STORE | "user_id:password"] [CONTAINER = ALL | CURRENT];

ここでは次のように指定します。

- tagは、定義する関連の属性および情報です。この設定は一重引用符(' ')で囲みます。

- FORCE KEYSTOREは、キーストアが閉じている場合に、キーストア操作を有効にします。

- IDENTIFIED BYは次のいずれかの設定にできます。

- EXTERNAL STOREは、外部ストアに格納されたキーストア・パスワードを使用して、キーストア操作を実行します。

- user_id:password: user_idは、ハードウェア・キーストア用に作成されたユーザーIDです。passwordは、ハードウェア・キーストア用に作成されたパスワードです。user_id:password文字列を二重引用符(" ")で囲み、user_idとpasswordをコロン(:)で区切ります。

- CONTAINERは、マルチテナント環境で使用するために用意されています。このCDBのすべてのPDBでキーストアを設定するには、ALLを入力するか、現在のPDBでキーストアを設定するには、CURRENTを入力します。

例:

ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY "psmith:password";

keystore altered.

前に構成したTDEマスター暗号化鍵の移行

ソフトウェア・キーストアを以前に構成した場合は、前に構成したTDEマスター暗号化鍵を移行する必要があります。

Oracle Data PumpやOracle Recovery Managerなどのツールでは、ソフトウェア・キーストアを使用してエクスポートまたはバックアップされたデータに対して復号化と暗号化の操作を実行するために、古いソフトウェア・キーストアにアクセスする必要があります。ソフトウェア・パスワード・キーストアとハードウェア・キーストア間の移行の説明に従って、ソフトウェア・キーストアからハードウェア・キーストアに移行できます。

現在のTDEマスター・キーとともに、Oracleウォレットでは、TDEマスター・キーをローテーションするキーの更新操作のたびに生成される履歴TDEマスター・キーを保持します。これらのTDEマスター・キーにより、履歴TDEマスター・キーのいずれかを使用して、以前に作成されたOracleデータベースのバックアップをリストアすることができます。

手順5: データの暗号化

ハードウェア・キーストアの構成が完了すると、データの暗号化を開始できます。

表の個別の列または表領域全体を暗号化できます。

- データの暗号化の詳細は、次のトピックを参照してください。

- 表の列の暗号化

- 表領域の暗号化

表の列の暗号化

透過的データ暗号化を使用すると、データベース表の個々の列を暗号化できます。

内容は次のとおりです。

- 表の列の暗号化について

- TDE列暗号化で暗号化できるデータ型

- 透過的データ暗号化列暗号化の使用に関する制限

- 暗号化列を含む表の作成

- 既存の表にある列の暗号化

- 暗号化列に対する索引の作成

- 暗号化列へのSaltの追加

- 暗号化列からのSaltの削除

- 暗号化列を含む表に対する暗号化鍵またはアルゴリズムの変更

表の列の暗号化について

表の個々の列を暗号化できます。

個々の列または表領域全体のどちらを暗号化するかは、表のデータ型によって決まります。また、TDE列暗号化をサポートしていない機能もいくつかあります。

関連項目:

- TDE列暗号化で暗号化できるデータ型

- 透過的データ暗号化列暗号化の使用に関する制限

TDE列暗号化で暗号化できるデータ型

Oracle Databaseでは、TDE列暗号化で使用できる特定のセットのデータ型をサポートしています。

様々なデータ型が使用されるデータ列を暗号化することができます。

サポートされるデータ型は次のとおりです。

- BINARY_DOUBLE

- BINARY_FLOAT

- CHAR

- DATE

- INTERVALDAYTOSECOND

- INTERVALYEARTOMONTH

- NCHAR

- NUMBER

- NVARCHAR2

- RAW (レガシーまたは拡張)

- TIMESTAMP (TIMESTAMP WITH TIME ZONEおよびTIMESTAMP WITH LOCAL TIME ZONEを含む)

- VARCHAR2 (レガシーまたは拡張)

暗号化列のサイズが列のデータ型で許容されるサイズより大きい場合は、列を暗号化できません。

表3-1に、各種データ型の最大許容サイズを示します。

表3-1 各データ型の最大許容サイズ

データ型

最大サイズ

CHAR

1932バイト

VARCHAR2 (レガシー)

3932バイト

VARCHAR2 (拡張)

32,699バイト

NVARCHAR2 (レガシー)

1966バイト

NVARCHAR2 (拡張)

16,315バイト

NCHAR

966バイト

RAW (拡張)

32,699バイト

注意:

TDE表領域暗号化には、これらのデータ型制限はありません。詳細は、「表領域の暗号化」を参照してください。

透過的データ暗号化列暗号化の使用に関する制限

TDEの暗号化はSQLレイヤーで行われます。SQLレイヤーをバイパスするOracle Databaseユーティリティは、TDEの列暗号化サービスを使用できません。

TDE列暗号化は、次のデータベース機能と併用しないでください。

- Bツリー以外の索引タイプ

- 索引内のレンジ・スキャン検索

- 同期チェンジ・データ・キャプチャ

- トランスポータブル表領域

また、TDE列暗号化では、外部キー制約で使用される列は暗号化できません。

サポートされていないこれらの機能を使用する必要があるアプリケーションは、DBMS_CRYPTO PL/SQLパッケージを使用して暗号化を実行できます。

透過的データ暗号化は、ディスクまたは他のメディアに格納されているデータを保護します。転送中のデータは保護対象外です。ネットワーク上のデータを暗号化するには、Oracle Databaseセキュリティ・ガイドに記載されているネットワーク暗号化ソリューションを使用します。

関連項目:

- 透過的データ暗号化とエクスポートおよびインポート操作の連携

- TDE列暗号化で暗号化できるデータ型

- DBMS_CRYPTO PL/SQLパッケージの詳細は、Oracle Database PL/SQLパッケージおよびタイプ・リファレンスを参照してください。

- CREATE TABLE文を使用して作成されるID列の詳細は、Oracle Database SQL言語リファレンスを参照してください。

暗号化列を含む表の作成

暗号化された列がある新しい表を作成できます。Oracle Databaseには、暗号化を定義するために使用できる様々なアルゴリズムが用意されています。

内容は次のとおりです。

- 暗号化列を含む表の作成について

- デフォルト・アルゴリズムを使用する暗号化列を含む表の作成

- アルゴリズムを使用しないまたは非デフォルト・アルゴリズムを使用する暗号化列を含む表の作成

- NOMACパラメータを使用したディスク領域の節約およびパフォーマンスの向上

- 例: CREATE TABLE文でのNOMACパラメータの使用

- 例: 表の整合性アルゴリズムの変更

- 外部表への暗号化列の作成

暗号化列を含む表の作成について

CREATE TABLE SQL文を使用して、暗号化列を持つ表を作成できます。

暗号化列を含むリレーショナル表を作成するには、CREATE TABLE SQL文でデータベース列を定義するときにSQL ENCRYPT句を指定します。

デフォルト・アルゴリズムを使用する暗号化列を含む表の作成

TDEでは、192ビット長の鍵を使用するAES暗号化アルゴリズム(AES192)がデフォルトで使用されます。

アルゴリズムを指定しないで表の列を暗号化すると、その列はAES192アルゴリズムを使用して暗号化されます。

暗号化の前にTDEは、saltを平文に追加します。saltを追加すると、攻撃者が総当たり攻撃によってデータを盗むことがより困難になります。また、TDEにより整合性をチェックするために、データにメッセージ認証コード(MAC)が追加されます。デフォルトでは、SHA-1整合性アルゴリズムが使用されます。

- 列を暗号化する表を作成するには、ENCRYPT句を含むCREATE TABLE SQL文を使用します。
たとえば、デフォルト・アルゴリズムを使用して表の列を暗号化するには、次のようにします。

CREATE TABLE employee (
first_name VARCHAR2(128),
last_name VARCHAR2(128),
empID NUMBER,
salary NUMBER(6) ENCRYPT);

この例では、暗号化列を含む新しい表を作成しています(salary)。この列は、デフォルトの暗号化アルゴリズム(AES192)を使用して暗号化されます。saltおよびMACはデフォルトで追加されます。この例では、ウォレットがオープン状態であり、マスター鍵が設定されていると想定しています。

注意:

1つの表に複数の暗号化列がある場合、これらのすべての列で暗号化アルゴリズムと整合性アルゴリズムの同じペアが使用される必要があります。

saltは列レベルで指定されます。つまり、表の暗号化列には、saltが使用される暗号化列とsaltが使用されない暗号化列が混在していてもかまいません。

アルゴリズムを使用しないまたは非デフォルト・アルゴリズムを使用する暗号化列を含む表の作成

CREATE TABLE SQL文を使用して、暗号化列を持つ表を作成します。

暗号化の前に、デフォルトでTDEは、saltを平文に追加します。saltを追加すると、攻撃者が総当たり攻撃によってデータを盗むことがより困難になります。ただし、暗号化列を索引付けする場合、NO SALTパラメータを使用する必要があります。

- デフォルト以外のアルゴリズムの暗号化列、またはアルゴリズムなしの暗号化列を使用する表を作成するには、次のようにCREATE TABLE SQL文を実行します。

- アルゴリズムを使用しない場合は、ENCRYPT NO SALT句を含めます。

- デフォルト以外のアルゴリズムを使用する場合は、ENCRYPT USING句を使用し、その後に一重引用符で囲んだ次のいずれかのアルゴリズムを続けます。

- 3DES168

- AES128

- AES192 (デフォルト)

- AES256

次の例では、empID列およびsalary列の暗号化設定の指定方法を示します。

CREATE TABLE employee (
first_name VARCHAR2(128),
last_name VARCHAR2(128),
empID NUMBER ENCRYPT NO SALT,
salary NUMBER(6) ENCRYPT USING '3DES168');

この例では、次のようになります。

- empID列は暗号化されますが、saltを使用しません。表のすべての暗号化列は、同じ暗号化アルゴリズムを使用する必要があるため、empID列とsalary列の両方は、3DES168暗号化アルゴリズムを使用します。

- salary列は、3DES168暗号化アルゴリズムを使用して暗号化されます。アルゴリズムを指定する文字列は、一重引用符(' ')で囲む必要があることに注意してください。salary列では、デフォルトでsaltが使用されます。

NOMACパラメータを使用したディスク領域の節約およびパフォーマンスの向上

TDEで実行するチェックはバイパスできます。この場合、暗号化された値ごとに20バイトのディスク領域を節約できます。

表の行および暗号化列の数が多い場合、TDEチェックをバイパスすることで、かなりの量のディスク領域になることがあります。さらに、処理サイクルが節約され、TDEに関連するパフォーマンス・オーバーヘッドが減少します。

TDEでは、デフォルトでSHA-1整合性アルゴリズムが使用されます。表のすべての暗号化列で同じ整合性アルゴリズムが使用される必要があります。表の列ですでにSHA-1アルゴリズムを使用している場合は、NOMACパラメータによって同じ表の別の列を暗号化することはできません。

- 暗号化および復号化操作での整合性チェックをバイパスするには、CREATE TABLE文およびALTER TABLE文でNOMACパラメータを使用します。

関連項目:

透過的データ暗号化のパフォーマンスと記憶域のオーバーヘッド

例: CREATE TABLE文でのNOMACパラメータの使用

CREATE TABLE SQL文を使用し、NOMACパラメータを使用して表の列を暗号化できます。

例3-1では、暗号化列を含む表を作成しています。empID列は、NOMACパラメータを使用して暗号化されます。

例3-1 CREATE TABLE文でのNOMACパラメータの使用

CREATE TABLE employee (
first_name VARCHAR2(128),
last_name VARCHAR2(128),
empID NUMBER ENCRYPT 'NOMAC' ,
salary NUMBER(6));

例: 表の整合性アルゴリズムの変更

ALTER TABLE SQL文を使用して、データベース表の整合性アルゴリズムを変更できます。

例3-2に、表内の暗号化列の整合性アルゴリズムを変更する方法を示します。暗号化アルゴリズムを3DES168に、整合性アルゴリズムをSHA-1に設定しています。2番目のALTER TABLE文では、整合性アルゴリズムをNOMACに設定しています。

例3-2 表の整合性アルゴリズムの変更

ALTER TABLE EMPLOYEE REKEY USING '3DES168' 'SHA-1';

ALTER TABLE EMPLOYEE REKEY USING '3DES168' 'NOMAC';

外部表への暗号化列の作成

外部表の機能を使用すると、データベース表内のデータであるかのように、外部ソースのデータにアクセスできます。

外部表は、ORACLE_DATAPUMPアクセス・ドライバを使用して更新できます。

- 外部表の特定の列を暗号化するには、列を定義するときにENCRYPT句を使用します。
列は、システム生成鍵によって暗号化されます。たとえば、次のCREATE TABLE SQL文は、3DES168アルゴリズムを使用してssn列を暗号化します。

CREATE TABLE emp_ext (
first_name,
....
ssn ENCRYPT USING '3DES168',
....

外部表を新しい場所に移動することを予定している場合、列の暗号化にランダム生成の鍵は使用できません。これは、新しい場所ではランダム生成の鍵が使用できないためです。

このような場合は、列を暗号化する際にパスワードを指定する必要があります。データを移動した後で、同じパスワードを使用して、新しい場所の暗号化列データへのアクセスに必要な鍵を再生成できます。

表パーティション交換でもパスワードベースのTDE表キーが必要になります。

例3-3では、TDE表キーを作成するためのパスワードを使用して外部表を作成しています。

例3-3 パスワード生成TDE表キーを使用した新しい外部表の作成

CREATE TABLE emp_ext (
first_name,
last_name,
empID,
salary,
ssn ENCRYPT IDENTIFIED BY password
)  ORGANIZATION EXTERNAL
(
TYPE ORACLE_DATAPUMP
DEFAULT DIRECTORY "D_DIR"
LOCATION('emp_ext.dat')
)
REJECT LIMIT UNLIMITED
AS SELECT * FROM EMPLOYEE;

既存の表にある列の暗号化

既存の表にある列を暗号化できます。新しい表の場合、暗号化の定義に使用する様々なアルゴリズムを選択できます。

内容は次のとおりです。

- 既存の表にある列の暗号化について

- 既存の表への暗号化列の追加

- 暗号化されていない列の暗号化

- 列の暗号化の無効化

既存の表にある列の暗号化について

ALTER TABLE SQL文では、既存の表にある列を暗号化できます。

既存の表に暗号化列を追加したり、既存の列を暗号化または復号化するには、ADD句またはMODIFY句を含むALTER TABLE SQL文を使用します。

既存の表への暗号化列の追加

既存の表の列を暗号化したり、異なるアルゴリズムを使用したり、NO SALTを使用して列を索引付けすることができます。

- 既存の表に暗号化列を追加するには、ALTER TABLE ADD文を使用して、ENCRYPT句で新しい列を指定します。

例3-4では、employeeという既存の表に暗号化列ssnを追加しています。ssn列は、デフォルトのAES192アルゴリズムを使用して暗号化されます。saltおよびMACはデフォルトで追加されます。

例3-4 既存の表への暗号化列の追加

ALTER TABLE employee ADD (ssn VARCHAR2(11) ENCRYPT);

暗号化されていない列の暗号化

ALTER TABLE MODIFY文を使用して、既存の暗号化されていない列を暗号化できます。

- 暗号化されていない既存の列を暗号化するには、ALTER TABLE MODIFY文を使用して、ENCRYPT句で、暗号化されてない列を指定します。

次の例では、employee表のfirst_name列を暗号化しています。first_name列は、デフォルトのAES192アルゴリズムを使用して暗号化されます。saltはデフォルトでデータに追加されます。別のアルゴリズムを使用して列を暗号化できます。列を索引付けする場合、NO SALTを指定する必要があります。NOMACパラメータを使用して、整合性チェックをバイパスすることもできます。

ALTER TABLE employee MODIFY (first_name ENCRYPT);

次の例では、NOMACパラメータを使用してemployee表のfirst_name列を暗号化しています。

ALTER TABLE employee MODIFY (first_name ENCRYPT 'NOMAC');

列の暗号化の無効化

互換性やパフォーマンスの理由から、暗号化を無効にすることが必要になる場合があります。

- 列の暗号化を無効にするには、ALTER TABLE MODIFYコマンドを使用し、DECRYPT句を指定します。

例3-5では、employee表のfirst_name列を復号化しています。

例3-5 列の暗号化の無効化

ALTER TABLE employee MODIFY (first_name DECRYPT);

暗号化列に対する索引の作成

暗号化された列に対して索引を作成できます。

索引付け対象の列は、saltなしで暗号化されている必要があります。saltを使用して列が暗号化されている場合、ORA-28338: 索引付けされた列は、saltを使用して暗号化できませんエラーが発生します。

- 暗号化列に索引を作成する場合は、ENCRYPT NO SALT句を含むCREATE INDEX文を使用します。

例3-6に、saltなしで暗号化された列に対して索引を作成する方法を示します。

例3-6 saltなしで暗号化された列に対する索引の作成

CREATE TABLE employee (
first_name VARCHAR2(128),
last_name VARCHAR2(128),
empID NUMBER ENCRYPT NO SALT,
salary NUMBER(6) ENCRYPT USING '3DES168');

CREATE INDEX employee_idx on employee (empID);

暗号化列へのSaltの追加

ソルトは、暗号化される前のデータに追加されるランダムな文字列で、暗号化されたデータのセキュリティを強化する方法です。

Saltにより、同じ平文データが常に同じ暗号化テキストに変換されることがなくなります。saltを追加すると、侵入者がデータを盗むために使用する一般的な方法の1つである暗号化テキストのパターン一致を排除できます。saltを追加するには、暗号化されたデータ値ごとに16バイトの追加記憶域が必要です。

- 暗号化列に対してsaltを追加または削除するには、ALTER TABLE MODIFY SQL文を使用します。

たとえば、saltを使用してfirst_name列を暗号化するとします。first_name列が以前にsaltなしで暗号化されていた場合は、ALTER TABLE MODIFY文によって、saltを使用して列が再暗号化されます。

ALTER TABLE employee MODIFY (first_name ENCRYPT SALT);

暗号化列からのSaltの削除

ALTER TABLE SQL文を使用して、暗号化列からsaltを削除できます。

- 暗号化列からsaltを削除するには、ALTER TABLE SQL文でENCRYPT NO SALT句を使用します。

たとえば、first_name列からsaltを削除するとします。saltを使用して暗号化された列に索引を付ける必要がある場合は、索引を付ける前に、この文を使用してsaltを削除します。

ALTER TABLE employee MODIFY (first_name ENCRYPT NO SALT);

暗号化列を含む表に対する暗号化鍵またはアルゴリズムの変更

ALTER TABLE SQL文を使用して、暗号化列で使用される暗号化鍵またはアルゴリズムを変更できます。

各表では、その列に1つのTDE表キーのみ指定できます。TDE表キーはALTER TABLE文を使用して再生成できます。このプロセスでは、新しい鍵を生成し、以前の鍵を使用して表のデータを復号化し、新しい鍵を使用してデータを再暗号化し、表のメタデータを新しい鍵情報で更新します。新しいTDE表キーに対して別の暗号化アルゴリズムを使用することもできます。

- 暗号化列を含む表の暗号化鍵またはアルゴリズムを変更するには、ALTER TABLE SQL文でREKEYまたはREKEY USING句を使用します。

例:

ALTER TABLE employee REKEY;

例3-7では、3DES168アルゴリズムを使用してemployee表に対するTDE表キーを再生成しています。

例3-7 暗号化された表の列の暗号化鍵およびアルゴリズムの変更

ALTER TABLE employee REKEY USING '3DES168';

表領域の暗号化

オンラインとオフラインの両方の表領域およびデータベースで暗号化操作を実行できます。

内容は次のとおりです。

- 透過的データ暗号化表領域暗号化の使用に関する制限

- 手順1: 表領域暗号化のCOMPATIBLE初期化パラメータの設定

- 手順2: 表領域TDEマスター暗号化鍵の設定

- 手順3: 暗号化された表領域の作成

透過的データ暗号化表領域暗号化の使用に関する制限

表領域を暗号化する際は、透過的データ暗号化の使用に関する制限事項に注意する必要があります。

次の制約に注意してください:

- 透過的データ暗号化(TDE)表領域暗号化では、SQLレイヤーでデータを暗号化および復号化するTDE列暗号化とは対照的に、読取りおよび書込み操作時にデータを暗号化または復号化します。このことは、データ型制限や索引タイプ制限など、TDE列暗号化に適用される制限のほとんどが、TDE表領域暗号化には適用されないことを意味します。

- インポートおよびエクスポート操作を実行するには、Oracle Data Pumpを使用します。

関連項目:

Oracle Data Pumpの詳細は、『Oracle Databaseユーティリティ』を参照してください。

手順1: 表領域暗号化のCOMPATIBLE初期化パラメータの設定

暗号化された表領域を作成する前に、COMPATIBLE初期化パラメータを設定する必要があります。

内容は次のとおりです。

- 表領域暗号化のためのCOMPATIBLE初期化パラメータの設定について

- 表領域暗号化のためのCOMPATIBLE初期化パラメータの設定

表領域暗号化のためのCOMPATIBLE初期化パラメータの設定について

11.2.0.0の最小限のCOMPATIBLE設定により、すべての表領域暗号化機能が有効になります。

互換性を11.1.0.0ではなく11.2.0.0に設定することで、次の追加機能を使用できます。

- 11.2.0.0に設定することにより、データベースでは、データの暗号化にサポートしている4つのアルゴリズム(3DES168、AES128、AES192およびAES256)の任意のものを使用できます。

- 11.2.0.0に設定することにより、ソフトウェア・キーストアからハードウェア・キーストアに鍵を移行できます(TDEマスター暗号化鍵がハードウェア・キーストア用に構成されていることを確認します)。

- 11.2.0.0に設定することにより、TDEマスター暗号化鍵を再設定およびローテーションできます。

このパラメータを11.2.0.0に設定すると、変更は元に戻せないことに注意してください。表領域暗号化を使用するには、互換性設定が最低でも11.1.0.0であることを確認します。

関連項目:

- COMPATIBLEパラメータの詳細は、Oracle Database SQL言語リファレンスを参照してください。

- 初期化パラメータ・ファイルの詳細は、Oracle Database管理者ガイドを参照してください。

表領域暗号化のためのCOMPATIBLE初期化パラメータの設定

COMPATIBLE初期化パラメータを設定するには、データベース・インスタンスの初期化パラメータを編集する必要があります。

1. データベース・インスタンスにログインします。
マルチテナント環境の場合、PDBにログインします。例:

sqlplus sec_admin@hrpdb
Enter password: password
Connected.

利用可能なPDBを検索するには、DBA_PDBSデータ・ディクショナリ・ビューを問い合せます。現在のPDBを確認するには、show con_nameコマンドを実行します。

2. COMPATIBLEパラメータの現在の設定を確認します。
例:

SHOW PARAMETER COMPATIBLE

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
compatible                           string      11.0.0.0
noncdbcompatible                     BOOLEAN     FALSE

3. COMPATIBLEパラメータを変更する必要がある場合、この手順の残りのステップを実行します。
値は、11.2.0.0以上である必要があります。

4. データベース・インスタンスの初期化パラメータ・ファイルを特定します。

- UNIXシステム: このファイルは、ORACLE_HOME/dbsディレクトリにあり、initORACLE_SID.ora (initmydb.oraなど)という名前です。

- Windowsシステム: このファイルは、ORACLE_HOME\databaseディレクトリにあり、initORACLE_SID.ora (initmydb.oraなど)という名前です。

5. 初期化パラメータ・ファイルを新しいCOMPATIBLE設定を使用するよう編集します。
例:

compatible=11.2.0.0.0

6. SQL*Plusで、SYSDBA管理権限を持つユーザーとして接続し、データベースを停止します。
例:

CONNECT /AS SYSDBA
SHUTDOWN

7. 正しいCOMPATIBLE設定を使用して初期化パラメータ・ファイルを編集します。
例:

COMPATIBLE = 12.1.0.0

8. SQL*Plusで、SYSDBA管理権限を持つユーザーとして接続していることを確認し、データベースを起動します。
例:

CONNECT /AS SYSDBA
STARTUP

表領域の暗号化を使用している場合は、データベース・マウントでキーストアを開きます。キーストアは、暗号化された表領域のデータにアクセスする前に開いている必要があります。

STARTUP MOUNT;
ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY keystore_password;
ALTER DATABASE OPEN;

手順2: 表領域TDEマスター暗号化鍵の設定

TDEマスター暗号化鍵が構成されていることを確認する必要があります。

- 次のようにTDEマスター暗号化鍵を設定します。

- ソフトウェアTDEマスター暗号化鍵の場合は、手順4: ソフトウェアTDEマスター暗号化鍵の設定を参照してください。

- ハードウェアTDEマスター暗号化鍵の場合は、手順4: ハードウェア・キーストアのTDEマスター暗号化鍵の設定を参照してください。

手順3: 暗号化された表領域の作成

COMPATIBLE初期化パラメータを設定したら、暗号化された表領域の作成は完了です。

内容は次のとおりです。

- 暗号化された表領域の作成について

- 暗号化された表領域の作成

- 例: 3DES168を使用する暗号化された表領域の作成

- 例: デフォルト・アルゴリズムを使用する暗号化された表領域の作成

暗号化された表領域の作成について

暗号化された表領域を作成するには、CREATE TABLESPACE SQL文を使用します。

暗号化された表領域を作成するには、CREATE TABLESPACEシステム権限が必要です。

既存の表領域を変更して、それを暗号化済にすることはできません。ただし、Oracle Data Pumpを使用して、暗号化された表領域にデータをインポートすることはできます。CREATE TABLE...AS SELECT...やALTER TABLE...MOVE...などのSQL文を使用して、暗号化された表領域にデータを移動することもできます。CREATE TABLE...AS SELECT...文は、既存の表から表を作成します。ALTER TABLE...MOVE...文は、暗号化された表領域に表を移動します。

セキュリティ上の理由から、NO SALTオプションを使用して表領域を暗号化することはできません。

表領域が暗号化されたかどうかを確認するために、DBA_TABLESPACESデータ・ディクショナリ・ビューおよびUSER_TABLESPACESデータ・ディクショナリ・ビューのENCRYPTED列を問い合せることができます。

関連項目:

これらのデータ・ディクショナリ・ビューの詳細は、『Oracle Databaseリファレンス』を参照してください

暗号化された表領域の作成

暗号化された表領域を作成するには、ENCRYPTION USING句を含むCREATE TABLESPACE文を使用する必要があります。

1. CREATE TABLESPACEシステム権限が付与されたユーザーとして、データベース・インスタンスにログインします。
マルチテナント環境の場合、PDBにログインします。例:

sqlplus sec_admin@hrpdb as syskm
Enter password: password
Connected.

利用可能なPDBを検索するには、DBA_PDBSデータ・ディクショナリ・ビューを問い合せます。現在のPDBを確認するには、show con_nameコマンドを実行します。

2. 暗号化句を使用してCREATE TABLESPACE文を実行します。
例:

CREATE TABLESPACE encrypt_ts
DATAFILE '$ORACLE_HOME/dbs/encrypt_df.dbf' SIZE 1M
ENCRYPTION USING 'AES256'
DEFAULT STORAGE (ENCRYPT);

ここでは次のように指定します。

- ENCRYPTION USING 'AES256'には、暗号化アルゴリズムおよび暗号化鍵の長さを指定します。この設定は一重引用符(' ')で囲みます。鍵長は、アルゴリズムの名前に含まれています。暗号化アルゴリズムを指定しない場合は、デフォルトの暗号化アルゴリズムAES128が使用されます。次のアルゴリズムから選択します。

- 3DES168

- AES128

- AES192

- AES256

- DEFAULT STORAGE句のENCRYPTは、表領域を暗号化します。

関連項目:

CREATE TABLESPACE文の構文の詳細は、Oracle Database SQL言語リファレンスを参照してください。

例: 3DES168を使用する暗号化された表領域の作成

CREATE TABLESPACE SQL文を使用して、暗号化された表領域を作成できます。

例3-8では、3DESアルゴリズムを使用して暗号化された、securespace_1という表領域を作成します。鍵長は168ビットです。

例3-8 3DES168を使用する暗号化された表領域の作成

CREATE TABLESPACE securespace_1
DATAFILE '/home/user/oradata/secure01.dbf'
SIZE 150M
ENCRYPTION USING '3DES168'
DEFAULT STORAGE(ENCRYPT);

例: デフォルト・アルゴリズムを使用する暗号化された表領域の作成

CREATE TABLESPACE SQL文を使用して、デフォルト・アルゴリズムを使用する暗号化された表領域を作成できます。

例3-9では、securespace_2という表領域を作成します。暗号化アルゴリズムが指定されていないため、デフォルトの暗号化アルゴリズム(AES128)が使用されます。鍵長は128ビットです。

既存の表領域は暗号化できません。

例3-9 デフォルト・アルゴリズムを使用する暗号化された表領域の作成

CREATE TABLESPACE securespace_2
DATAFILE '/home/user/oradata/secure01.dbf'
SIZE 150M
ENCRYPTION
DEFAULT STORAGE(ENCRYPT);

透過的データ暗号化のデータの動的ビューおよびデータ・ディクショナリ・ビュー

Oracle Databaseには、透過的データ暗号化データに関する詳細情報を検索するために問い合せできる、一連の動的ビューおよびデータ・ディクショナリ・ビューが用意されています。

表3-2に、これらの動的ビューおよびデータ・ディクショナリ・ビューを示します。

表3-2 透過的データ暗号化の関連ビュー

ビュー

説明

ALL_ENCRYPTED_COLUMNS

現在のユーザーがアクセスできる表内の暗号化列に関する暗号化情報が表示されます。

DBA_ENCRYPTED_COLUMNS

データベースにあるすべての暗号化列の暗号化情報が表示されます。

USER_ENCRYPTED_COLUMNS

現在のユーザーのスキーマにある暗号化された表の列の暗号化情報が表示されます。

DBA_TABLESPACE_USAGE_METRICS

永続、一時、およびUNDO表領域を含むすべてのタイプの表領域についての表領域使用状況メトリックを示します

V$CLIENT_SECRETS

様々な機能(クライアント)用のキーストアに格納された文字列(シークレット)のプロパティが一覧表示されます。

マルチテナント環境では、PDB内のこのビューを問い合せると、現在のPDB用に作成またはアクティブ化された鍵に関する情報が表示されます。rootでこのビューを問い合せると、すべてのPDBの鍵に関するこの情報が表示されます。

V$ENCRYPTED_TABLESPACES

暗号化された表領域に関する情報が表示されます。

V$ENCRYPTION_KEYS

ADMINISTER KEY MANAGEMENT文でローテーションされた鍵とともに使用されたときには、TDEマスター暗号化鍵についての情報を表示します。

マルチテナント環境では、PDB内のこのビューを問い合せると、現在のPDB用に作成またはアクティブ化された鍵に関する情報が表示されます。rootでこのビューを問い合せると、すべてのPDBの鍵に関するこの情報が表示されます。

V$ENCRYPTION_WALLET

TDEのキーストアのステータスおよびキーストアの場所に関する情報が表示されます。

V$WALLET

TDEのマスター暗号化鍵として使用できるPKI証明書のメタデータ情報が表示されます。

関連項目:

これらのビューの詳細は、Oracle Databaseリファレンスを参照してください。

4 キーストアおよびTDEマスター暗号化鍵の管理

キーストアおよびTDEマスター暗号化鍵の設定を変更および管理して、Oracle Databaseで使用されるシークレットを格納し、Oracle GoldenGateのシークレットをキーストアに格納できます。

内容は次のとおりです。

- キーストアの管理

- TDEマスター暗号化鍵の管理

- Oracle Databaseで使用するシークレットの格納

- キーストアへのOracle GoldenGateのシークレットの格納

キーストアの管理

キーストアでは、パスワードの変更、キーストアのバックアップ、キーストアのマージ、キーストアの移動などのメンテナンス作業を実行できます。

内容は次のとおりです。

- パスワードベースのソフトウェア・キーストアのパスワードの変更

- ハードウェア・キーストアのパスワードの変更

- パスワードベースのソフトウェア・キーストアのバックアップ

- ハードウェア・キーストアのバックアップ

- ソフトウェア・キーストアのマージ

- 新しいロケーションへのソフトウェア・キーストアの移動

- 自動ストレージ管理からのソフトウェア・キーストアの移動

- ソフトウェア・パスワード・キーストアとハードウェア・キーストア間の移行

- キーストアとOracle Key Vault間の移行

- キーストアを閉じる

- ASMボリュームに存在するソフトウェア・キーストアの使用

- 暗号化されたデータのバックアップおよびリカバリ

- キーストアの削除

関連項目:

- ソフトウェア・キーストアの構成

- ハードウェア・キーストアの構成

パスワードベースのソフトウェア・キーストアのパスワードの変更

Oracle Databaseでは、パスワードベースのソフトウェア・キーストアのパスワードを簡単に変更できます。

内容は次のとおりです。

- パスワードベースのソフトウェア・キーストアのパスワードの変更について

- パスワードベースのソフトウェア・キーストアのパスワードの変更

パスワードベースのソフトウェア・キーストアのパスワードの変更について

パスワードベースのソフトウェア・キーストアのパスワードは、変更(ローテーション)のみ可能です。

このパスワードは、サイトのセキュリティ・ポリシーやコンプライアンス・ガイドライン、およびその他のセキュリティ要件に従って、いつでも変更できます。パスワードを変更するコマンドの一部として、WITH BACKUP句を指定する必要があるため、常に現在のキーストアのバックアップが作成されます。パスワードの変更操作中、暗号化や復号化などの透過的データ暗号化操作は正常に動作し続けます。

このパスワードはいつでも変更できます。このパスワードは、安全性が損なわれた可能性があると思われる場合には変更することをお薦めします。

パスワードベースのソフトウェア・キーストアのパスワードの変更

パスワードベースのソフトウェア・キーストアのパスワードを変更するには、ADMINISTER KEY MANAGEMENT文を使用する必要があります。

1. ADMINISTER KEY MANAGEMENTまたはSYSKM権限が付与されたユーザーとして、データベース・インスタンスにログインします。
マルチテナント環境では、rootとしてログインします。例:

sqlplus c##sec_admin as syskm
Enter password: password
Connected.

2. 次のSQL文を実行します。

ADMINISTER KEY MANAGEMENT ALTER KEYSTORE PASSWORD IDENTIFIED BY
old_password SET new_password [WITH BACKUP [USING 'backup_identifier']];

ここでは次のように指定します。

- old_passwordは、変更する現在のキーストア・パスワードです。

- new_passwordは、キーストア用に設定する新しいパスワードです。

- WITH BACKUPは、パスワードを変更する前に、現在のキーストアのバックアップを作成します。この句を含める必要があります。

- backup_identifierは、作成されるバックアップのオプション識別子文字列を指定します。backup_identifierは、バックアップ・ファイルの名前に追加されます。backup_identifierは、一重引用符(' ')で囲みます。この識別子は名前付きキーストア・ファイルに付加されます(ewallet_time_stamp_emp_key_pwd_change.p12など)。

次の例は、現在のキーストアをバックアップしてから、キーストアのパスワードを変更します。

ADMINISTER KEY MANAGEMENT ALTER KEYSTORE PASSWORD IDENTIFIED BY
old_password SET new_password WITH BACKUP USING 'pwd_change';

keystore altered.

ハードウェア・キーストアのパスワードの変更

ハードウェア・キーストアのパスワードを変更するには、ADMINISTER KEY MANAGEMENT文を使用する必要があります。

1. ADMINISTER KEY MANAGEMENTまたはSYSKM権限が付与されたユーザーとして、データベース・インスタンスにログインします。
マルチテナント環境では、rootとしてログインします。例:

sqlplus c##sec_admin as syskm
Enter password: password
Connected.

2. ハードウェア・キーストアを閉じます。
例:

ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY "psmith:password";

「ハードウェア・キーストアを閉じる」を参照してください。

3. ハードウェア・セキュリティ・モジュール管理インタフェースから、新しいハードウェア・セキュリティ・モジュール・パスワードを作成します。

4. SQL*Plusでハードウェア・キーストアを開きます。

ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "psmith:new_password";

「手順3: ソフトウェア・キーストアを開」を参照してください。

パスワードベースのソフトウェア・キーストアのバックアップ

パスワードベースのソフトウェア・キーストアをバックアップする際、バックアップのタイプを説明するバックアップの識別子文字列をオプションで作成できます。

内容は次のとおりです。

- パスワードベースのソフトウェア・キーストアのバックアップについて

- バックアップ・キーストアのバックアップ識別子文字列の作成

- V$ENCRYPTION_WALLETビューによるバックアップ操作の解釈方法

- パスワードベースのソフトウェア・キーストアのバックアップ

パスワードベースのソフトウェア・キーストアのバックアップについて

サイトのセキュリティ・ポリシーや要件に従って、パスワードベースのソフトウェア・キーストアをバックアップする必要があります。

キーストアのバックアップには、元のキーストアに格納されているすべての鍵が含まれます。Oracle Databaseでは、バックアップ・キーストアに作成時のタイムスタンプ(UTC)の接頭辞が付けられます。識別子文字列を指定すると、その文字列がタイムスタンプとキーストア名の間に挿入されます。

バックアップ操作が完了すると、元のキーストアの鍵は「backed up」とマークされます。鍵のステータスは、V$ENCRYPTION_WALLETデータ・ディクショナリ・ビューを問い合せて確認できます。

自動ログイン・ソフトウェア・キーストアやローカル自動ログイン・ソフトウェア・キーストアはバックアップできません。ADMINISTER KEY MANAGEMENT文での操作を使用して、新しいキーを直接それらに追加することはできません。これらのキーストア内の情報は読み取られるのみのため、バックアップは不要です。

キーストアをまだバックアップしていない場合は、TDEマスター暗号化鍵の作成時にADMINISTER KEY MANAGEMENT文にBACKUP句を含めることができます。これにより、キーストアがバックアップされ、TDEマスター暗号化鍵が作成されます。(手順4: ソフトウェアTDEマスター暗号化鍵の設定にこの実行方法が示されています。)

バックアップ・キーストアのバックアップ識別子文字列の作成

ソフトウェア・パスワード・キーストアのバックアップ・ファイル名は、パスワードベースのソフトウェア・キーストアの名前から導出されます。

Oracle Databaseでは、ソフトウェア・キーストア・パスワード・ファイル名に、ファイル作成時のタイムスタンプ(UTCフォーマット)の接頭辞が付けられます。識別子文字列を指定すると、その文字列がタイムスタンプとキーストア名の間に挿入されます。

- バックアップ・キーストアのバックアップ識別子文字列を作成するには、BACKUP KEYSTORE句を含む次の構文のADMINISTER KEY MANAGEMENT SQL文を使用します。

ewallet_creation-time-stamp-in-UTC_user-defined-string.p12

バックアップ識別子(user_defined_string)を作成する場合は、オペレーティング・システムのファイル命名規則に従います。たとえば、UNIXシステムでは、この設定にスペースが入らないようにします。

例4-1に、ユーザーが指定したバグ番号の文字列を使用するバックアップ・キーストアの作成方法と、そのキーストアがファイル・システムにどのように表示されるかを示します。

例4-1 バックアップ・キーストアのバックアップ識別子文字列の作成

ADMINISTER KEY MANAGEMENT BACKUP KEYSTORE USING 'BUG12966094' IDENTIFIED BY keystore_password;

結果のキーストア・ファイル:

ewallet_2013041513244657_BUG12966094.p12

V$ENCRYPTION_WALLETビューによるバックアップ操作の解釈方法

V$ENCRYPTION_WALLETビューでは、BACKUP列に、ADMINISTER KEY MANAGEMENT文またはADMINISTER KEY MANAGEMENT BACKUP KEYSTORE文のWITH BACKUP句でキーストアのコピーが作成されているかどうかが示されます。

鍵またはシークレットを変更した場合、コピーが作成されてから鍵自体が変更されるため、行う変更は前にバックアップされたコピーには反映されません。前のキーストアには変更のコピーが存在しないため、以前にBACKUPがYESに設定されていた場合でも、BACKUP列はNOに設定されます。したがって、BACKUP列がYESの場合、カスタム属性タグの追加といったバックアップを必要とする操作を実行すると、BACKUP列の値はNOに変更されます。

パスワードベースのソフトウェア・キーストアのバックアップ

パスワードベースのソフトウェア・キーストアをバックアップするには、BACKUP KEYSTORE句を含むADMINISTER KEY MANAGEMENT文を使用する必要があります。

1. ADMINISTER KEY MANAGEMENTまたはSYSKM権限が付与されたユーザーとして、データベース・インスタンスにログインします。
マルチテナント環境では、rootとしてログインします。例:

sqlplus c##sec_admin as syskm
Enter password: password
Connected.

2. 次のSQL文を実行します。

ADMINISTER KEY MANAGEMENT BACKUP KEYSTORE [USING 'backup_identifier']
IDENTIFIED BY software_keystore_password [TO 'keystore_location'];

ここでは次のように指定します。

- USING backup_identifierは、バックアップを識別するために指定できるオプション文字列です。この識別子は、一重引用符(' ')で囲みます。この識別子は名前付きキーストア・ファイルに付加されます(ewallet_time-stamp_emp_key_backup.p12など)。

- software_keystore_passwordは、キーストアのパスワードです。

- keystore_locationは、バックアップ・キーストアが格納されるパスです。keystore_locationを指定しない場合、バックアップは元のキーストアと同じディレクトリに作成されます。このロケーションは、一重引用符(' ')で囲みます。

次の例は、ソフトウェア・キーストアをソース・キーストアと同じロケーションにバックアップします。

ADMINISTER KEY MANAGEMENT BACKUP KEYSTORE USING 'hr.emp_keystore' IDENTIFIED BY
password TO '/etc/ORACLE/KEYSTORE/DB1/';

keystore altered.

この文を実行すると、ewallet_identifier.p12ファイル(ewallet_time-stamp_hr.emp_keystore.p12など)がキーストア・ロケーションに作成されます。

ハードウェア・キーストアのバックアップ

Oracle Databaseを使用してハードウェア・キーストアをバックアップすることはできません。

ハードウェア・キーストアの鍵をバックアップする方法の詳細は、HSMベンダーの指示を参照してください。

ソフトウェア・キーストアのマージ

2つのキーストアをマージして3番目のキーストアを作成したり、1つのキーストアを既存のキーストアにマージしたり、自動ログイン・ソフトウェア・キーストアをパスワードベースのソフトウェア・キーストアにマージするなど、ソフトウェアのキーストアは様々な方法でマージできます。

内容は次のとおりです。

- ソフトウェア・キーストアのマージについて

- 2つのソフトウェア・キーストアから3つ目の新しいキーストアへのマージ

- 1つのソフトウェア・キーストアの既存のソフトウェア・キーストアへのマージ

- 自動ログイン・ソフトウェア・キーストアの既存のパスワードベースのソフトウェア・キーストアへのマージ

- ソフトウェア・キーストア・マージ操作の取消し

ソフトウェア・キーストアのマージについて

ソフトウェア・キーストアの任意の組合せをマージできます。ただし、マージ後のキーストアはパスワードベースのソフトウェア・キーストアにする必要があります(これによって構成キーストアとはパスワードを別にすることができます)。

マージしたキーストアを使用するには、マージ前にいずれかの構成キーストアがすでに開いていた場合でも、マージしたキーストアを作成後に明示的に開く必要があります。

2つのソース・キーストアの共通鍵が、マージしたキーストアに追加されるか上書きされるかは、ADMINISTER KEY MANAGEMENTマージ文の記述方法に応じて異なります。たとえば、キーストア1とキーストア2をマージしてキーストア3を作成する場合、キーストア1の鍵はキーストア3に追加されます。キーストア1をキーストア2にマージする場合、キーストア2の共通鍵は上書きされません。

ADMINISTER KEY MANAGEMENTマージ文は、使用中の構成済キーストアには影響しません。ただし、必要に応じて、マージしたキーストアを新しい構成済データベース・キーストアとして使用できます。sqlnet.oraファイルによって構成された場所にあるデータベースのキーストアとして新しく作成したキーストアを使用する場合、キーストアを再度開く必要があることに注意してください。

関連項目:

- ソフトウェア・パスワード・キーストアとハードウェア・キーストア間の移行

- 手順3: ソフトウェア・キーストアを開く

2つのソフトウェア・キーストアから3つ目の新しいキーストアへのマージ

2つの既存のキーストアが変更されないように2つのソフトウェア・キーストアを3つ目の新しいキーストアにマージできます。

1. ADMINISTER KEY MANAGEMENTまたはSYSKM権限が付与されたユーザーとして、データベース・インスタンスにログインします。

マルチテナント環境では、rootとしてログインします。例:

sqlplus c##sec_admin as syskm
Enter password: password
Connected.

2. 次のSQL文を実行します。

ADMINISTER KEY MANAGEMENT MERGE KEYSTORE 'keystore1_location'
[IDENTIFIED BY software_keystore1_password] AND KEYSTORE 'keystore2_location'
[IDENTIFIED BY software_keystore2_password]
INTO NEW KEYSTORE 'keystore3_location'
IDENTIFIED BY software_keystore3_password;

ここでは次のように指定します。

- keystore1_locationは、マージ後も変更されないまま残される1つ目のキーストアのディレクトリの場所です。このパスは、一重引用符(' ')で囲みます。

- IDENTIFIED BY句は、1つ目のキーストアがパスワードベースのキーストアの場合は必要です。software_keystore1_passwordは、1つ目のキーストアの現在のパスワードです。

- keystore2_locationは、2つ目のキーストアのディレクトリの場所です。このパスは、一重引用符(' ')で囲みます。

- IDENTIFIED BY句は、2つ目のキーストアがパスワードベースのキーストアの場合は必要です。software_keystore2_passwordは、2つ目のキーストアの現在のパスワードです。

- keystore3_locationは、マージされた新しいキーストアのディレクトリの場所を指定します。このパスは、一重引用符(' ')で囲みます。その場所に既存のキーストアがすでに存在する場合は、コマンドが終了してエラーが発生します。

- software_keystore3_passwordは、マージ後のキーストアの新しいパスワードです。

次の例は、自動ログイン・ソフトウェア・キーストアをパスワードベースのキーストアとマージして、マージしたパスワードベースのキーストアを新しいロケーションに作成します。

ADMINISTER KEY MANAGEMENT MERGE KEYSTORE '/etc/ORACLE/KEYSTORE/DB1'
AND KEYSTORE '/etc/ORACLE/KEYSTORE/DB2'
IDENTIFIED BY existing_password_for_keystore_2
INTO NEW KEYSTORE '/etc/ORACLE/KEYSTORE/DB3'
IDENTIFIED BY new_password_for_keystore_3;

keystore altered.

1つのソフトウェア・キーストアの既存のソフトウェア・キーストアへのマージ

MERGE KEYSTORE句を含むADMINISTER KEY MANAGEMENT文を使用して、1つのソフトウェア・キーストアを他の既存のソフトウェア・キーストアにマージできます。

- このタイプのマージを実行するには、2つのソフトウェア・キーストアから3つ目の新しいキーストアへのマージの手順に従いますが、次のSQL文を使用してください。

ADMINISTER KEY MANAGEMENT MERGE KEYSTORE 'keystore1_location'
[IDENTIFIED BY software_keystore1_password]
INTO EXISTING KEYSTORE 'keystore2_location'
IDENTIFIED BY software_keystore2_password
[WITH BACKUP [USING 'backup_identifier]];

ここでは次のように指定します。

- keystore1_locationは、マージ後も変更されないまま残される1つ目のキーストアのディレクトリの場所です。このパスは、一重引用符(' ')で囲みます。

- IDENTIFIED BY句は、1つ目のキーストアがパスワードベースのキーストアの場合は必要です。software_keystore1_passwordは、1つ目のキーストアのパスワードです。

- keystore2_locationは、1つ目のキーストアがマージされる2つ目のキーストアのディレクトリの場所です。このパスは、一重引用符(' ')で囲みます。

- software_keystore2_passwordは、2つ目のキーストアのパスワードです。

- WITH BACKUPを使用すると、ソフトウェア・キーストアのバックアップが作成されます。オプションでUSING句を使用し、バックアップの簡単な説明を追加できます。この説明は一重引用符(' ')で囲みます。この識別子は、名前付きキーストア・ファイルに付加されます(たとえば、emp_key_backupがバックアップ識別子になっているewallet_time-stamp_emp_key_backup.p12)。オペレーティング・システムで使用されているファイル命名規則に従ってください。

マージ操作で生成されるキーストアは、常にパスワードベースのキーストアです。

自動ログイン・ソフトウェア・キーストアの既存のパスワードベースのソフトウェア・キーストアへのマージ

自動ログイン・ソフトウェア・キーストアを既存のパスワードベースのソフトウェア・キーストアにマージできます。

- ADMINISTER KEY MANAGEMENT MERGE KEYSTORE SQL文を使用して、自動ログイン・ソフトウェア・キーストアを既存のパスワードベースのソフトウェア・キーストアにマージします。

例4-2に、自動ログイン・ソフトウェア・キーストアをパスワードベースのソフトウェア・キーストアにマージする方法を示します。また、マージするキーストアを作成する前に、2つ目のキーストアのバックアップを作成します。

例4-2 自動ログイン・ソフトウェア・キーストアからパスワード・キーストアへのマージ

ADMINISTER KEY MANAGEMENT MERGE KEYSTORE '/etc/ORACLE/KEYSTORE/DB1'
INTO EXISTING KEYSTORE '/etc/ORACLE/KEYSTORE/DB2'
IDENTIFIED BY password WITH BACKUP;

ここでは次のように指定します。

- MERGE KEYSTOREは、自動ログイン・キーストアを指定する必要があります。

- EXISTING KEYSTOREは、パスワードのキーストアを表します。

ソフトウェア・キーストア・マージ操作の取消し

キーストア・マージ操作を直接取り消すことはできません。

キーストアを(新規作成するのではなく)既存のキーストアにマージする場合、ADMINISTER KEY MANAGEMENT文にWITH BACKUP句を指定して、その既存のキーストアのバックアップを作成する必要があります。後でマージを取り消す必要があると判断した場合、マージしたソフトウェア・キーストアを、バックアップしたものと置き換えることができます。

たとえば、キーストアAをキーストアBにマージするとします。WITH BACKUP句を使用することで、マージ操作の開始前にキーストアBのバックアップを作成します。(元のキーストアAは変更されません。)マージ操作を取り消すには、キーストアBから作成したバックアップに戻ります。

- ADMINISTER KEY MANAGEMENT MERGE KEYSTORE SQL文を使用して、マージ操作を実行します。

- たとえば、既存のキーストアへのマージ操作を実行する場合、次のようにします。

ADMINISTER KEY MANAGEMENT MERGE KEYSTORE '/etc/ORACLE/KEYSTORE/DB1'
INTO EXISTING KEYSTORE '/etc/ORACLE/KEYSTORE/DB2'
IDENTIFIED BY password WITH BACKUP USING "merge1";

新しいキーストアをバックアップ・キーストア(この場合、ewallet_time-stamp_merge1.p12という名前)に置き換えます。

- 自動ログイン・キーストアをパスワードベースのキーストアにマージするには、ADMINISTER KEY MANAGEMENT MERGE KEYSTORE SQL文を使用します。

新しいロケーションへのソフトウェア・キーストアの移動

ソフトウェア・キーストアを新しいロケーションに移動するには、キーストアをバックアップして閉じ、sqlnet.oraファイルを編集してから、キーストアを新しいロケーションに物理的に移動する必要があります。

Oracle Key Vaultを使用している場合は、Key VaultがTDEマスター鍵を直接管理するTDE直接接続を構成できます。この場合、キーストアを新しいロケーションに手動で移動する必要はありません。TDE直接接続の使用の詳細は、『Oracle Key Vault管理者ガイド』を参照してください。

1. ADMINISTER KEY MANAGEMENTまたはSYSKM権限が付与されたユーザーとして、データベース・インスタンスにログインします。
マルチテナント環境で、rootまたはプラガブル・データベース(PDB)にログインします。たとえば、hrpdbというPDBにログインするには、次のようにします。

sqlplus sec_admin@hrpdb as syskm
Enter password: password
Connected.

利用可能なPDBを検索するには、DBA_PDBSデータ・ディクショナリ・ビューを問い合せます。現在のPDBを確認するには、show con_nameコマンドを実行します。

2. ソフトウェア・キーストアのバックアップ・コピーを作成します。
「パスワードベースのソフトウェア・キーストアのバックアップ」を参照してください。

3. ソフトウェア・キーストアを閉じます。
例:

ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE; -- For an auto-login software keystore

ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY software_keystore_password; -- For a password-based software keystore

4. データベース・セッションを終了します。
たとえば、SQL*Plusにログインしている場合は、次のようにします。

EXIT

5. キーストアを移動する新しいロケーションを示すように、sqlnet.oraファイルをバックアップしてから手動で編集します。
詳細は、「手順1: sqlnet.oraファイルでのソフトウェア・キーストアの場所の設定」を参照してください。

6. オペレーティング・システムの移動コマンド(mvなど)を使用して、キーストアとそのすべての鍵を、新しいディレクトリの場所に移動します。

自動ストレージ管理からのソフトウェア・キーストアの移動

ADMINISTER KEY MANAGEMENT文を使用して、自動ストレージ管理からソフトウェア・キーストアを移動できます。

1. ADMINISTER KEY MANAGEMENTまたはSYSKM権限が付与されたユーザーとして、データベース・インスタンスにログインします。

マルチテナント環境では、rootとしてログインします。例:

sqlplus c##sec_admin as syskm
Enter password: password
Connected.

利用可能なPDBを検索するには、DBA_PDBSデータ・ディクショナリ・ビューを問い合せます。現在のPDBを確認するには、show con_nameコマンドを実行します。

2. 次の構文を使用して、ファイル・システム上のターゲット・キーストアを初期化します。

ADMINISTER KEY MANAGEMENT CREATE KEYSTORE targetKeystorePath IDENTIFIED BY targetKeystorePassword;

ここでは次のように指定します。

- targetKeystorePathは、ファイル・システム上のターゲット・キーストアへのディレクトリ・パスです。

- targetKeystorePasswordは、キーストアに対して作成するパスワードです。

例:

ADMINISTER KEY MANAGEMENT CREATE KEYSTORE '/etc/ORACLE/KEYSTORE/DB1/' IDENTIFIED BY "targetKeystorePassword";

3. キーストアをASMから、先ほど作成したターゲット・キーストアにコピーします。

この手順では、キーストアをASMからファイル・システムに次のようにマージする必要があります。

ADMINISTER KEY MANAGEMENT MERGE KEYSTORE srcKeystorePath IDENTIFIED BY srcKeystorePassword INTO EXISTING KEYSTORE targetKeystorePath IDENTIFIED BY targetKeystorePassword WITH BACKUP USING backupIdentifier;

ここでは次のように指定します。

- srcKeystorePathは、ソース・キーストアへのディレクトリ・パスです。

- srcKeystorePasswordは、ソース・キーストアのパスワードです。

- targetKeystorePathは、ターゲット・キーストアへのパスです。

- targetKeystorePasswordは、ターゲット・キーストアのパスワードです。

- backupIdentifierは、バックアップ・ファイル名に追加されるバックアップ識別子です。

例:

ADMINISTER KEY MANAGEMENT MERGE KEYSTORE '+DATAFILE' IDENTIFIED BY "srcPassword" INTO EXISTING KEYSTORE '/etc/ORACLE/KEYSTORE/DB1/' IDENTIFIED BY "targetKeystorePassword" WITH BACKUP USING "bkup";

ソフトウェア・パスワード・キーストアとハードウェア・キーストア間の移行

パスワードベースのソフトウェア・キーストアとハードウェア・キーストアとの間で移行できます。

内容は次のとおりです。

- パスワードベースのソフトウェア・キーストアからハードウェア・キーストアへの移行

- ハードウェア・キーストアからパスワードベースのソフトウェア・キーストアへの移行

- 移行後のキーストアの順序

パスワードベースのソフトウェア・キーストアからハードウェア・キーストアへの移行

パスワードベースのソフトウェア・キーストアからハードウェア・キーストアへ移行することができます。

内容は次のとおりです。

- 手順1: ハードウェア・キーストアとともに開くためにソフトウェア・キーストアを変換する

- 手順2: パスワードベースのソフトウェア・キーストアの移行のためにsqlnet.oraを構成する

- 手順3: ハードウェア・キーストアの移行を実行する

手順1: ハードウェア・キーストアとともに開くためにソフトウェア・キーストアを変換する

Oracle Data PumpやOracle Recovery Managerなどのツールでは、ソフトウェア・キーストアを使用してエクスポートまたはバックアップされたデータに対して復号化と暗号化の操作を実行するために、古いソフトウェア・キーストアにアクセスする必要があります。

- ADMINISTER KEY MANAGEMENT SQL文を使用して、ハードウェア・キーストアとともに開くためにソフトウェア・キーストアを変換します。

- ソフトウェア・キーストアのパスワードをハードウェア・キーストアのパスワードとして設定するには、次の構文を使用します。

ADMINISTER KEY MANAGEMENT ALTER KEYSTORE PASSWORD
IDENTIFIED BY software_keystore_password
SET "user_id:password" WITH BACKUP [USING 'backup_identifier'];

ここでは次のように指定します。

- software_keystore_passwordは、ソフトウェア・キーストアの作成時に使用したものと同じパスワードです。

- user_id:passwordは、HSMのパスワードと同じ新しいソフトウェア・キーストアのパスワードです。

- WITH BACKUPを使用すると、ソフトウェア・キーストアのバックアップが作成されます。オプションでUSING句を使用し、バックアップの簡単な説明を追加できます。この説明は一重引用符(' ')で囲みます。この識別子は、名前付きキーストア・ファイルに付加されます(たとえば、emp_key_backupがバックアップ識別子になっているewallet_time-stamp_emp_key_backup.p12)。オペレーティング・システムで使用されているファイル命名規則に従ってください。

- ソフトウェア・キーストアの自動ログイン・キーストアを作成するには、次の構文を使用します。

ADMINISTER KEY MANAGEMENT CREATE [LOCAL] AUTO_LOGIN KEYSTORE
FROM KEYSTORE 'keystore_location'
IDENTIFIED BY software_keystore_password;

ここでは次のように指定します。

- LOCALでは、ローカル自動ログイン・ソフトウェア・キーストアを作成できます。そうでない場合、キーストアに他のコンピュータからアクセスできるようにするときは、この句を省略します。

- keystore_locationは、sqlnet.oraファイルに構成されているキーストアのキーストア・ディレクトリの場所へのパスです。

- software_keystore_passwordは、構成されているソフトウェア・キーストアの既存のパスワードです。

手順2: パスワードベースのソフトウェア・キーストアの移行のためにsqlnet.oraを構成する

キーストアの移行後、必要時にソフトウェア・キーストアで作成された鍵にアクセスできるように、ソフトウェア・キーストアとハードウェア・キーストアの両方の操作を開くことができます。

ソフトウェア・キーストアをハードウェア・キーストアと一緒に開くには、ソフトウェア・キーストアのパスワードがハードウェア・キーストアと同じであることが必要です。あるいは、ソフトウェア・キーストア用に自動ログイン・キーストアを作成できます。

ソフトウェア・キーストアからハードウェア・キーストアに移行している場合は、METHOD=HSM設定を使用するようにsqlnet.oraファイルを編集する必要があります。

関連項目:

sqlnet.oraファイルでのキーストアの場所について

- sqlnet.oraファイルで次の形式を使用します。

ENCRYPTION_WALLET_LOCATION=
(SOURCE=(METHOD=HSM)(METHOD_DATA=
(DIRECTORY=path_to_keystore)))

path_to_software_keystoreは、前に構成したソフトウェア・キーストアへのパスです。ENCRYPTION_WALLET_LOCATIONパラメータにHSMとDIRECTORYの両方のロケーションがある場合、以前にソフトウェア・キーストアとハードウェア・キーストアの使用を切り換えたことがあり、また、将来簡単に元に戻すことができることを示します。

注意:

ENCRYPTION_WALLET_LOCATIONパラメータ設定にDIRECTORY値が存在する場合、削除しないようにしてください。

ハードウェア・キーストアにはDIRECTORY値は必要ありませんが、Oracle Databaseでは、この値を使用して、ハードウェア・セキュリティ・モジュールを対象に移行を行う場合にソフトウェア・キーストアを特定します。

例4-3に、sqlnet.oraファイルを編集して、ソフトウェア・キーストアをハードウェア・セキュリティ・モジュールベースのキーストアに(またはその逆に)設定する方法を示します。

例4-3 サンプルENCRYPTION_WALLET_LOCATIONエントリ

ENCRYPTION_WALLET_LOCATION=
(SOURCE=(METHOD=HSM)(METHOD_DATA=
(DIRECTORY=/app/wallet)))

手順3: ハードウェア・キーストアの移行を実行する

ADMINISTER KEY MANAGEMENT SQL文を使用して、ハードウェア・キーストアの移行を実行できます。

ソフトウェア・キーストアからハードウェア・キーストアに移行するには、ADMINISTER KEY MANAGEMENT SET KEY SQL文でMIGRATE USING keystore_password句を使用して、ソフトウェア・キーストアのTDEマスター暗号化鍵で既存のTDE表キーおよび表領域暗号化鍵を復号化してから、ハードウェア・キーストアの新しく作成したTDEマスター暗号化鍵でそれらを再暗号化する必要があります。

移行の完了後、データベースを再起動したり、ハードウェア・キーストアを手動で再度開く必要はありません。移行プロセスにより、キーストアの鍵がメモリーに自動的にリロードされます。

- 移行のためにADMINISTER KEY MANAGEMENT SQL文を実行する場合、次の構文を使用します。

ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY IDENTIFIED BY "user_id:password" MIGRATE USING software_keystore_password [WITH BACKUP [USING 'backup_identifier']];

ここでは次のように指定します。

- user_id:passwordは、(透過的データ暗号化の構成の)手順2: ハードウェア・セキュリティ・モジュールの構成の手順3で作成したユーザーIDおよびパスワードです。この設定は二重引用符(" ")で囲み、user_idとpasswordをコロン(:)で区切ります。

- software_keystore_passwordは、ソフトウェア・キーストアの作成時に使用したものか、手順1: ハードウェア・キーストアとともに開くためにソフトウェア・キーストアを変換するで変更したものと同じパスワードです。

- USINGでは、バックアップの簡単な説明を追加できます。この説明は一重引用符(' ')で囲みます。この識別子は、名前付きキーストア・ファイルに付加されます(たとえば、emp_key_backupがバックアップ識別子になっているewallet_time-stamp_emp_key_backup.p12)。オペレーティング・システムで使用されているファイル命名規則に従ってください。

注意:

公開鍵によって暗号化された列がデータベースに含まれている場合は、その列が復号化されてから、HSMベースの透過的データ暗号化によって生成されたAES対称鍵を使用して再暗号化されます。

ハードウェア・キーストアからパスワードベースのソフトウェア・キーストアへの移行

ハードウェア・キーストアは、ソフトウェア・キーストアに移行できます。

内容は次のとおりです。

- ハードウェア・キーストアからの再移行について

- 手順1: 逆移行用にsqlnet.oraを構成する

- 手順2: 逆移行用にキーストアを構成する

- 手順3: ソフトウェア・キーストアとともに開くようにハードウェア・キーストアを構成する

ハードウェア・キーストアからの再移行について

ハードウェア・キーストア・ソリューションからソフトウェア・キーストアの使用に切り換える場合、キーストアの逆移行を使用できます。

以前のバックアップ・ファイルがハードウェア・セキュリティ・モジュールのTDEマスター暗号化鍵に依存している場合は、切換え完了後に、ハードウェア・セキュリティ・モジュールを保持しておく必要があります。

初めにソフトウェア・キーストアからハードウェア・セキュリティ・モジュールに移行し、前に構成したTDEマスター暗号化鍵の移行の説明に従ってソフトウェア・キーストアを再構成済の場合は、HSMパスワードと同じパスワードの既存のキーストアがすでに存在します。逆移行では、このキーストアを、新しいパスワードで新しいソフトウェア・キーストアとして動作するように構成します。既存のキーストアが自動ログイン・ソフトウェア・キーストアで、その自動ログイン・キーストアのパスワードベースのソフトウェア・キーストアがある場合、パスワードベースのキーストアを使用してください。パスワードベースのキーストアを使用できない場合、自動ログイン・キーストアを新しく作成した空のパスワードベースのキーストアにマージし、その新しく作成したパスワードベースのキーストアを使用します。

既存のキーストアがない場合、ENCRYPTION_WALLET_LOCATIONパラメータを使用して、sqlnet.oraファイルにキーストア・ロケーションを指定する必要があります。逆移行を実行する場合、鍵が失われないように前のキーストアに移行する必要があります。

関連項目:

ソフトウェア・キーストアのマージ

手順1: 逆移行用にsqlnet.oraを構成する

最初にsqlnet.oraファイルを編集する必要があります。

- sqlnet.oraファイルに次の構成を設定します。

ENCRYPTION_WALLET_LOCATION=
(SOURCE=(METHOD=FILE)(METHOD_DATA=
(DIRECTORY=path_to_keystore)))

path_to_keystoreを、宛先キーストアのディレクトリの場所に置き換えます。

関連項目:

sqlnet.oraファイルでのキーストアの場所について

手順2: 逆移行用にキーストアを構成する

キーストアに対して逆移行を実行するには、SET ENCRYPTION KEY句とREVERSE MIGRATE句を含むADMINISTER KEY MANAGEMENT文を使用できます。

1. ADMINISTER KEY MANAGEMENTまたはSYSKM権限が付与されたユーザーとして、データベース・インスタンスにログインします。
マルチテナント環境では、rootとしてログインします。例:

sqlplus c##sec_admin as syskm
Enter password: password
Connected.

2. 次のSQL文を実行します。

ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY IDENTIFIED BY software_keystore_password REVERSE MIGRATE USING "user_id:password" [WITH BACKUP [USING 'backup_identifier']];

ここでは次のように指定します。

- software_keystore_passwordは、既存のキーストアまたは新しいキーストアのパスワードです。

- user_id:passwordは、(透過的データ暗号化の構成の)手順2: ハードウェア・セキュリティ・モジュールの構成の手順3で作成したユーザーIDおよびパスワードです。前のハードウェア・セキュリティ・モジュール・ソフトウェア・キーストアが新しいキーストアの場合、逆移行コマンドを発行する前に、user_id:passwordと同じパスワードであることを確認する必要があります。この設定は二重引用符(" ")で囲みます。

- WITH BACKUPを使用すると、ソフトウェア・キーストアのバックアップが作成されます。オプションでUSING句を含めることで、バックアップの簡単な説明を追加できます。この説明は一重引用符(' ')で囲みます。この識別子は、名前付きキーストア・ファイルに付加されます(たとえば、emp_key_backupがバックアップ識別子になっているewallet_time-stamp_emp_key_backup.p12)。オペレーティング・システムで使用されているファイル命名規則に従ってください。

例:

ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY IDENTIFIED BY password REVERSE MIGRATE USING "psmith:password" WITH BACKUP;

keystore altered.

3. オプションで、キーストア・パスワードを変更します。
詳細は、パスワードベースのソフトウェア・キーストアのパスワードの変更を参照してください。

手順3: ソフトウェア・キーストアとともに開くようにハードウェア・キーストアを構成する

移行の完了後、データベースを再起動したり、ソフトウェア・キーストアを手動で再度開く必要はありません。移行プロセスにより、キーストアの鍵がメモリーに自動的にリロードされます。

以前の鍵は、暗号化されたバックアップで使用されているか、Oracle Data PumpやOracle Recovery Managerなどのツールによって使用されている可能性が高いため、逆移行の後でもハードウェア・キーストアが必要な場合があります。HSMをソフトウェア・キーストアとともに開くことができるように、ハードウェア・キーストア資格証明をキーストアにキャッシュする必要があります。HSM資格証明を移行後のキーストアに格納する方法の詳細は、自動ログイン・ハードウェア・セキュリティ・モジュールの構成を参照してください。

移行後のキーストアの順序

移行の実行後、キーストアの順序はプライマリまたはセカンダリのいずれかになります。

V$ENCRYPTION_WALLET動的ビューのWALLET_ORDER列は、キーストアがプライマリ(現在のTDEマスター暗号化鍵を保持)またはセカンダリ(前のTDEマスター暗号化鍵を保持)のいずれであるかを示します。WRL_TYPE列は、キーストアのロケータのタイプを示します(sqlnet.oraファイルの場合のFILEなど)。2つのキーストアがまとめて構成されておらず、以前に移行を一度も実行したことがない場合、WALLET_ORDER列にはSINGLEが表示されます。

表4-1では、移行後のキーストアの順序の仕組みについて説明します。

表4-1 移行後のキーストア順序

実行された移行のタイプ

WRL_TYPE

WALLET_ORDER

説明

ソフトウェア・キーストアからHSMへの移行

HSM

FILE

PRIMARY

SECONDARY

HSMとソフトウェア・キーストアの両方が構成されます。TDEマスター暗号化鍵は、HSMまたはソフトウェア・キーストアのいずれかに格納できます。

TDEマスター暗号化鍵は、まずHSMで検索されます。

TDEマスター暗号化鍵がプライマリ・キーストア(HSM)にない場合、ソフトウェア・キーストアで検索されます。

すべての新しいTDEマスター暗号化鍵は、プライマリ・キーストア(この場合はHSM)に作成されます。

HSMからソフトウェア・キーストアへの逆移行

FILE

HSM

PRIMARY

SECONDARY

HSMとソフトウェア・キーストアの両方が構成されます。TDEマスター暗号化鍵は、HSMまたはソフトウェア・キーストアのいずれかに格納できます。

TDEマスター暗号化鍵は、まずソフトウェア・キーストアで検索されます。

TDEマスター暗号化鍵がプライマリ(ソフトウェア)キーストアに存在しない場合、HSMで検索されます。

すべての新しいTDEマスター暗号化鍵は、プライマリ・キーストア(この場合はソフトウェア・キーストア)に作成されます。

キーストアとOracle Key Vault間の移行

Oracle Key Vaultを使用して、ソフトウェアおよびハードウェアの両方のキーストアをOracle Key Vault間で移行できます。これにより、キーストアを集中管理し、必要に応じて、企業内の他のTDE対応データベースとキーストアを共有できます。

Oracle Key Vaultでは、仮想ウォレットと呼ばれるコンテナにキーストアをアップロードし、前にアップロードしたOracleキーストアの内容から新しい仮想ウォレットを作成できます。たとえば、5つの鍵を格納するキーストアを前にアップロードしたとします。これらの鍵の3つのみで構成される新しい仮想ウォレットを作成できます。次に、このキーストアを別のTDE対応データベースにダウンロードできます。このプロセスでは、元のキーストアは変更されません。

Oracle Key Vaultでは、Oracleキーストアに加えて、資格証明ファイルやJavaキーストアなどの他のセキュリティ・オブジェクトを企業全体で安全に共有できます。これにより、パスワードを忘れたり、キーストアを間違って削除したことによる鍵およびキーストアの紛失を防ぐことができます。Oracle Key Vaultは、TDE以外の製品、Oracle Real Application Security、Oracle Active Data GuardおよびOracle GoldenGateとともに使用できます。Oracle Key Vaultでは、暗号化されたデータをOracle Data PumpおよびOracle Transportable Tablespacesを使用して簡単に移動できます。

関連項目:

『Oracle Key Vault管理者ガイド』

キーストアを閉じる

ソフトウェアおよびハードウェア・キーストアは手動で閉じることができます。

内容は次のとおりです。

- キーストアを閉じるについて

- ソフトウェア・キーストアを閉じる

- ハードウェア・キーストアを閉じる

関連項目:

- 手順3: ソフトウェア・キーストアを開く

- 手順3: ハードウェア・キーストアを開く

キーストアを閉じるについて

キーストアを開いた後は、データベース・インスタンスを終了するまで開いたままになります。

データベース・インスタンスを再起動すると、必要に応じて(TDEマスター暗号化鍵にアクセスする必要がある場合)自動ログイン・ソフトウェア・キーストアおよびローカル自動ログイン・ソフトウェア・キーストアが自動的に開きます。ただし、パスワードベースのソフトウェア・キーストアおよびハードウェア・キーストアは、自動的に開きません。使用する前には手動で再度開く必要があります。

ソフトウェア・キーストアまたはハードウェア・キーストアを閉じると、データベースのすべての暗号化操作と復号化操作が無効になります。したがって、データベース・ユーザーやアプリケーションは、キーストアが再度開くまで、暗号化データに関係する操作を実行できません。

キーストアを閉じた後に再度開くと、キーストアの内容がデータベースにリロードされます。したがって、内容が変更されると(移行中など)、データベースには最新のキーストアの内容が格納されます。

キーストアが開いているか、閉じているかのステータスは、V$ENCRYPTION_WALLETビューのSTATUS列を問い合せて、確認できます。

キーストアにアクセスできない場合、次のデータ操作は失敗します。

- 暗号化列からのデータの選択(SELECT)

- 暗号化列に対するデータの挿入(INSERT)

- 暗号化列による表の作成(CREATE)

- 暗号化された表領域の作成(CREATE)

関連項目:

「マルチテナント環境でのキーストアの開閉操作の機能」

ソフトウェア・キーストアを閉じる

パスワードベースのソフトウェア・キーストア、自動ログイン・ソフトウェア・キーストアおよびローカル自動ログイン・ソフトウェア・キーストアを手動で閉じることができます。

アクセス時に自動的に開かれる自動ログイン・キーストアの場合、それを新しいロケーションに移動した場合に手動で閉じる必要があります。構成を自動ログイン・キーストアからパスワードベースのキーストアに変更する場合、これを行います(自動ログイン・キーストアは移動してから閉じます)。

1. ADMINISTER KEY MANAGEMENTまたはSYSKM権限が付与されたユーザーとして、データベース・インスタンスにログインします。
マルチテナント環境では、まずrootでキーストアを閉じる必要があります。その後、PDBのすべてのキーストアが同様に閉じられます。たとえば、rootにログインするには、次のようにします。

sqlplus sec_admin as syskm
Enter password: password
Connected.

利用可能なPDBを検索するには、DBA_PDBSデータ・ディクショナリ・ビューを問い合せます。現在のPDBを確認するには、show con_nameコマンドを実行します。

2. ADMINISTER KEY MANAGEMENT SQL文を実行します。

- パスワードベースのソフトウェア・キーストアの場合、次の構文を使用します。

ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE [IDENTIFIED BY software_keystore_password] [CONTAINER = ALL | CURRENT];

ここでは次のように指定します。

- software_keystore_passwordは、キーストアを作成したユーザーのパスワードです。

- CONTAINERは、マルチテナント環境で使用するために用意されています。このマルチテナント・コンテナ・データベース(CDB)のすべてのPDBでキーストアを閉じる場合はALL、現在のPDBの場合はCURRENTを入力します。このADMINISTER KEY MANAGEMENT文をrootで実行すると、CONTAINERがALLに設定されているかCURRENTに設定されているかにかかわらず、すべてのPDBのすべてのキーストアが閉じられます。

- 自動ログイン・ソフトウェア・キーストアまたはローカル自動ログイン・ソフトウェア・キーストアの場合、次のSQL文を使用します。

ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE;

この文ではパスワードを指定する必要はありません。

キーストアを閉じると、暗号化および復号化のすべての操作が無効化されます。データを暗号化または復号化しようとしたり、暗号化データにアクセスしようとすると、エラーが発生します。

関連項目:

「手順3: ソフトウェア・キーストアを開く」

ハードウェア・キーストアを閉じる

ハードウェア・キーストアを閉じるには、SET KEYSTORE CLOSE句を含むADMINISTER KEY MANAGEMENT文を使用する必要があります。

1. ADMINISTER KEY MANAGEMENTまたはSYSKM権限が付与されたユーザーとして、データベース・インスタンスにログインします。
マルチテナント環境では、rootとしてログインします。例:

sqlplus c##sec_admin as syskm
Enter password: password
Connected.

2. 次のSQL文を実行します。

ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY "user_id:password" [CONTAINER = ALL | CURRENT];

ここでは次のように指定します。

- user_id:passwordは、ユーザーIDと、「手順2: ハードウェア・セキュリティ・モジュールを構成する」の手順3で作成されるパスワードです。この設定は二重引用符(" ")で囲み、user_idとpasswordをコロン(:)で区切ります。

- CONTAINERは、マルチテナント環境で使用するために用意されています。このCDBのすべてのPDBでキーストアを閉じる場合はALL、現在のPDBの場合はCURRENTを入力します。このADMINISTER KEY MANAGEMENT文をrootで実行すると、CONTAINERがALLに設定されているかCURRENTに設定されているかにかかわらず、すべてのPDBのすべてのキーストアが閉じられます。

例:

ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY "psmith:password";

関連項目:

「手順3: ハードウェア・キーストアを開く」

ASMボリュームに存在するソフトウェア・キーストアの使用

自動ストレージ管理(ASM)ディスク・グループにソフトウェア・キーストアを格納できます。

- sqlnet.oraファイルを編集して、ENCRYPTION_WALLET_LOCATION設定でDIRECTORY設定を構成するときに、ASMファイル命名規則を使用して指定されたASMディスク・グループの場所を使用します。つまり、ASMファイル名用のプラス記号(+)表記法を使用する必要があります。

例:

ENCRYPTION_WALLET_LOCATION=
(SOURCE=(METHOD=FILE)(METHOD_DATA=
(DIRECTORY=+disk1/mydb/wallet)))

通常のファイル・システムとASMファイル・システムの間でソフトウェア・キーストアを移動またはマージする必要がある場合は、「ソフトウェア・キーストアのマージ」で説明するものと同じキーストア・マージ文を使用できます。

ASM環境でキーストアを管理するには、ASMCMDユーティリティを使用します。

関連項目:

- ソフトウェア・キーストアの場所用のsqlnet.oraファイルの構成

- ASMCMDユーティリティの使用の詳細は、『Oracle Databaseストレージ管理者ガイド』を参照してください。

暗号化されたデータのバックアップおよびリカバリ

ソフトウェア・キーストアの場合、TDEマスター暗号化鍵がないと暗号化されたデータにアクセスできません。

TDEマスター暗号化鍵はキーストアに格納されるため、ソフトウェア・キーストアを安全な場所に定期的にバックアップすることをお薦めします。新しいTDEマスター暗号化鍵を設定するか、キーストアへの書込みを行う操作を実行するたびに、キーストアのバックアップ・コピーを作成する必要があります。

ソフトウェア・キーストアを暗号化データと同じ場所にバックアップしないでください。ソフトウェア・キーストアは別にバックアップします。自動ログイン・キーストアを使用している場合は、開くときにパスワードが要求されないため、特に注意してください。バックアップ・テープの紛失に備えて、悪意のあるユーザーが暗号化データとキーストアの両方を取得できないようにすることが大切です。

Oracle Recovery Manager (Oracle RMAN)によるデータベース・バックアップでは、ソフトウェア・キーストアはバックアップされません。Oracle Secure Backupなどのメディア・マネージャをOracle RMANと併用している場合は、Oracle Secure Backupによって、自動オープン・キーストア(cwallet.ssoファイル)がバックアップ対象から自動的に除外されます。ただし、暗号化キーストア(ewallet.p12ファイル)が自動的に除外されることはありません。次のexcludeデータ・セット文をOracle Secure Backup構成に追加することをお薦めします。

exclude name *.p12

この設定は、暗号化キーストアをバックアップ・セットから除外するようにOracle Secure Backupに指定します。

TDEマスター暗号化鍵を格納しているソフトウェア・キーストアを喪失した場合は、キーストアのバックアップを適切な場所にコピーすることで、暗号化データへのアクセスをリストアできます。TDEマスター暗号化鍵を最後に再設定した後に、リストアしたキーストアをアーカイブした場合、追加アクションは必要はありません。

リストアしたソフトウェア・キーストアに最新のTDEマスター暗号化鍵が含まれていない場合、データベースの状態をTDEマスター暗号化鍵が再設定された時点までロールバックすることで、その時点までの古いデータをリカバリできます。TDEマスター暗号化鍵の再設定後に暗号化列に対して行われた変更はすべて失われます。

関連項目:

データベースのリカバリ方法の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

キーストアの削除

キーストアは、特に透過的データ暗号化を構成した後およびキーストアが使用されているときには、削除しないことをお薦めします。

キーストアが使用中かどうかは、キーストアを開いた後にV$ENCRYPTION_WALLETビューのWRL_PARAMETER列を問い合せることで確認できます。

キーストアを削除してはいけない理由は、キーストアには、データベースで使用されるすべての鍵のリストが格納されているためです。キーストアを削除するとそれらの鍵が削除され、暗号化データが失われてしまう可能性があります。キーストアを削除すると、Oracle Databaseの通常の機能も妨げられる可能性があります。キーストアにあるTDEマスター暗号化鍵は、オフライン化された表領域、Oracle Recovery Manager、Oracle Secure Backupといった他のOracle Database機能にも使用されるため、データベース内のすべてのデータを復号化済の場合でもキーストアを削除しないようにしてください。

キーストアをハードウェア・セキュリティ・モジュールに移行した後であっても、元のキーストアは削除しないでください。元のキーストアにある鍵は、たとえば、オフラインで暗号化された表領域をリカバリする際など、後で必要になります。暗号化されていないオンラインのデータがない場合であっても、鍵はまだ使用されている場合があります。

ソフトウェア自動ログイン(または自動ログイン・ローカル)・キーストアの場合は例外です。このタイプのキーストアを使用しない場合は、安全なディレクトリに移動するのが理想です。自動ログイン・キーストアは、それが特定のパスワードベースのソフトウェア・キーストアに由来し、そのキーストアを利用できることがわかっている場合のみ、削除してください。キーストアは、利用可能で既知である必要があります。

TDEマスター暗号化鍵の管理

TDEマスター暗号化鍵は、いくつかの方法で管理できます。

内容は次のとおりです。

- 後で使用するためのTDEマスター暗号化鍵の作成

- TDEマスター暗号化鍵のアクティブ化

- TDEマスター暗号化鍵の属性管理

- レポート用のTDEマスター暗号化鍵のカスタム属性の作成

- キーストアのTDEマスター暗号化鍵の設定および再設定

- TDEマスター暗号化鍵のエクスポートおよびインポート

- Oracle Key Vaultを使用したTDEマスター暗号化鍵の管理

後で使用するためのTDEマスター暗号化鍵の作成

後でアクティブ化するTDEマスター暗号化鍵を作成することができます。

内容は次のとおりです。

- 後で使用するためのTDEマスター暗号化鍵の作成について

- 後で使用するためのTDEマスター暗号化鍵の作成

- 例: 1つのデータベースでのTDEマスター暗号化鍵の作成

- 例: すべてのPDBでのTDEマスター暗号化鍵の作成

後で使用するためのTDEマスター暗号化鍵の作成について

ADMINISTER KEY MANAGEMENT文のCREATE KEY句によって、後でアクティブ化できるTDEマスター暗号化鍵を作成できます。

その後、その鍵を同じデータベースでアクティブ化したり、別のデータベースにエクスポートしてそこでアクティブ化できます。

このTDEマスター暗号化鍵の作成方法は、マルチテナント環境でTDEマスター暗号化鍵を再作成する必要がある場合に便利です。CREATE KEY句では、単一のSQL文を使用して、マルチテナント環境内のすべてのPDBに新しいTDEマスター暗号化鍵を作成できます。新しいTDEマスター暗号化鍵の作成時間は、現在使用中のTDEマスター暗号化鍵をアクティブ化するよりも遅くなります。そのため、最新の作成済TDEマスター暗号化鍵をできるだけ早くアクティブ化するようにすべてのPDBに注意を喚起するために、この作成時間を使用できます。

後で使用するためのTDEマスター暗号化鍵の作成

後で使用するTDEマスター暗号化鍵を作成する前に、キーストアが開かれている必要があります。

1. ADMINISTER KEY MANAGEMENTまたはSYSKM権限が付与されたユーザーとして、データベース・インスタンスにログインします。
マルチテナント環境では、rootとしてログインします。例:

sqlplus c##sec_admin as syskm
Enter password: password
Connected.

2. キーストアが開いていることを確認します。
V$ENCRYPTION_WALLETビューのSTATUS列を問い合せると、キーストアが開いているかどうかを確認できます。キーストアを開く必要があることが判明した場合は、次の項を参照してください。

- 手順3: ソフトウェア・キーストアを開く

- 手順3: ハードウェア・キーストアを開く

3. 次のSQL文を実行します。

ADMINISTER KEY MANAGEMENT CREATE KEY [USING TAG 'tag'] IDENTIFIED BY keystore_password [WITH BACKUP [USING 'backup_identifier']] [CONTAINER = (ALL|CURRENT)];

ここでは次のように指定します。

- tagは、定義する関連の属性および情報です。この設定は一重引用符(' ')で囲みます。

- keystore_passwordは、元のキーストア作成時に使用した必須のキーストア・パスワードです。大文字と小文字が区別されます。

- WITH BACKUPは、鍵と同じ場所(V$ENCRYPTION_WALLETビューのWRL_PARAMETER列で識別されます)にTDEマスター暗号化鍵をバックアップします。すべてのデータベース・インスタンスの鍵の場所を確認するには、GV$ENCRYPTION_WALLETビューを問い合せます。
パスワードベースのソフトウェア・キーストアをバックアップする必要があります。自動ログイン・ソフトウェア・キーストアやローカル自動ログイン・ソフトウェア・キーストアをバックアップする必要はありません。オプションで、USING backup_identifier句を含めることで、バックアップの説明を追加できます。backup_identifierは、一重引用符(' ')で囲みます。

- CONTAINERは、マルチテナント環境で使用するために用意されています。このCDBのすべてのPDBで暗号化鍵を設定する場合はALL、現在のPDBの場合はCURRENTを入力します。

4. 必要に応じて、TDEマスター暗号化鍵をアクティブ化します。
TDEマスター暗号化鍵のアクティブ化を参照してください。

例: 1つのデータベースでのTDEマスター暗号化鍵の作成

ADMINISTER KEY MANAGEMENT CREATE KEY USING TAG文を使用して、1つのデータベースにTDEマスター暗号化鍵を作成できます。

例4-4に、1つのデータベースにTDEマスター暗号化鍵を作成する方法を示します。この文を実行すると、タグ定義で指定したTDEマスター暗号化鍵が、そのデータベースのキーストアに作成されます。新しく作成した鍵の識別子については、V$ENCRYPTION_KEYSビューのTAG列を問い合せることができます。最も最近作成された鍵(この文で作成した鍵)を確認するには、CREATION_TIME列を問い合せます。この鍵は、必要に応じて別のデータベースにエクスポートすることや、TDEマスター暗号化鍵のアクティブ化の説明に従って後からローカルでアクティブ化できます。

例4-4 1つのデータベースでのTDEマスター暗号化鍵の作成

ADMINISTER KEY MANAGEMENT CREATE KEY USING TAG
'source:admin@source;target:db1@target'
IDENTIFIED BY password WITH BACKUP;

keystore altered.

例: すべてのPDBでのTDEマスター暗号化鍵の作成

ADMINISTER KEY MANAGEMENT CREATE KEY USING TAG SQL文では、すべてのPDBにTDEマスター暗号化鍵を作成します。

例4-5に、マルチテナント環境のすべてのPDBにTDEマスター暗号化鍵を作成する方法を示します。この文を実行すると、TDEマスター暗号化鍵が各PDBに作成されます。それらの鍵の識別子は次のように確認できます。

- PDBにログインして、V$ENCRYPTION_KEYSビューのTAG列を問い合せます。

- rootでログインして、GV$ENCRYPTION_KEYSビューのINST_IDおよびTAG列を問い合せます。

また、最も最近作成された鍵(この文で作成した鍵)を確認するには、それらのビューのCREATION_TIME列を確認します。鍵の作成後、各PDBで鍵を個々にアクティブ化できます。

例4-5 すべてのPDBでのTDEマスター暗号化鍵の作成

ADMINISTER KEY MANAGEMENT CREATE KEY USING TAG
'scope:all pdbs;description:Create Key for ALL PDBS'
IDENTIFIED BY password WITH BACKUP CONTAINER=ALL;

keystore altered.

TDEマスター暗号化鍵のアクティブ化

TDEマスター暗号化鍵はアクティブ化すると、使用できます。

内容は次のとおりです。

- TDEマスター暗号化鍵のアクティブ化について

- TDEマスター暗号化鍵のアクティブ化

- 例: TDEマスター暗号化鍵のアクティブ化

TDEマスター暗号化鍵のアクティブ化について

ADMINSTER KEY MANAGEMENTのUSE KEY句を使用することで、以前に作成済またはインポート済のTDEマスター暗号化鍵をアクティブ化できます。

鍵をアクティブ化すると、使用できるようになります。鍵を使用して、すべての列の鍵とすべての表領域暗号化鍵を保護できます。ロジカル・スタンバイ・データベースをデプロイしている場合、TDEマスター暗号化鍵を再作成後にエクスポートしてから、スタンバイ・データベースにインポートする必要があります。プライマリ・データベースとスタンバイ・データベースの両方でTDEマスター暗号化鍵を使用するように選択できます。これを行うには、TDEマスター暗号化鍵を、ロジカル・スタンバイ・データベースへのインポート後にアクティブ化する必要があります。

TDEマスター暗号化鍵のアクティブ化

TDEマスター暗号化鍵をアクティブ化するには、キーストアを開き、USE KEY句を含むADMINISTER KEY MANAGEMENTを使用する必要があります。

1. ADMINISTER KEY MANAGEMENTまたはSYSKM権限が付与されたユーザーとして、データベース・インスタンスにログインします。
マルチテナント環境では、rootとしてログインします。例:

sqlplus c##sec_admin as syskm
Enter password: password
Connected.

2. キーストアが開いていることを確認します。
V$ENCRYPTION_WALLETビューのSTATUS列を問い合せると、キーストアが開いているかどうかを確認できます。キーストアを開く必要があることが判明した場合は、次の項を参照してください。

- 手順3: ソフトウェア・キーストアを開く

- 手順3: ハードウェア・キーストアを開く

3. V$ENCRYPTION_KEYSビューのKEY_ID列を問い合せて、鍵の識別子を確認します。
例:

SELECT KEY_ID FROM V$ENCRYPTION_KEYS;

KEY_ID
----------------------------------------------------
ARaHD762tUkkvyLgPzAi6hMAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

4. 次のSQL文を実行します。

ADMINISTER KEY MANAGEMENT USE KEY 'key_identifier' [USING TAG 'tag']
IDENTIFIED BY keystore_password [WITH BACKUP [USING 'backup_identifier']];

ここでは次のように指定します。

- key_identifierは、V$ENCRYPTION_KEYSビューのKEY_ID列を問い合せて確認する鍵の識別子です。この設定は一重引用符(' ')で囲みます。

- tagは、定義する関連の属性および情報です。この設定は一重引用符(' ')で囲みます。

- keystore_passwordは、元のキーストア作成時に使用した必須のキーストア・パスワードです。

- WITH BACKUPは、鍵と同じ場所(V$ENCRYPTION_WALLETビューのWRL_PARAMETER列で識別されます)にTDEマスター暗号化鍵をバックアップします。すべてのデータベース・インスタンスの鍵の場所を確認するには、GV$ENCRYPTION_WALLETビューを問い合せます。
パスワードベースのソフトウェア・キーストアをバックアップする必要があります。自動ログイン・ソフトウェア・キーストアやローカル自動ログイン・ソフトウェア・キーストアをバックアップする必要はありません。オプションで、USING backup_identifier句を含めることで、バックアップの説明を追加できます。backup_identifierは、一重引用符(' ')で囲みます。

- CONTAINERは、マルチテナント環境で使用するために用意されています。このCDBのすべてのPDBで暗号化鍵を設定する場合はALL、現在のPDBの場合はCURRENTを入力します。

例: TDEマスター暗号化鍵のアクティブ化

ADMINISTER KEY MANAGEMENT SQL文を使用して、TDEマスター暗号化鍵をアクティブ化できます。

例4-6に、以前にインポート済のTDEマスター暗号化鍵をアクティブ化してそのタグを更新する方法を示します。この鍵は、現在のデータベースのタイムスタンプとタイムゾーンでアクティブ化されます。

例4-6 TDEマスター暗号化鍵のアクティブ化

ADMINISTER KEY MANAGEMENT USE KEY
'ARaHD762tUkkvyLgPzAi6hMAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'
USING TAG 'quarter:second;description:Activate Key on standby'
IDENTIFIED BY password WITH BACKUP;

keystore altered.

TDEマスター暗号化鍵の属性管理

マスター暗号化鍵の属性には、TDEマスター暗号化鍵についての情報が保存されます。

内容は次のとおりです。

- TDEマスター暗号化鍵の属性

- 使用中のTDEマスター暗号化鍵の検出

TDEマスター暗号化鍵の属性

マスター暗号化鍵の属性には、TDEマスター暗号化鍵についての詳細情報が含まれます。

次のタイプの情報が含まれます。

- 鍵のタイムスタンプ情報: 通常、内部セキュリティ・ポリシーおよびコンプライアンス・ポリシーによって、鍵のローテーション頻度が決まります。ライフタイムの終わりに達したら鍵を期限切れにして、新しい鍵を生成する必要があります。鍵の作成時間やアクティブ化時間などのタイムスタンプ属性は、鍵の古さを正確に判断して鍵を自動生成するために役立ちます。
V$ENCRYPTION_KEYSビューには、CREATION_TIMEやACTIVATION_TIMEなどの列が含まれます。V$ENCRYPTION_KEYSビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

- 鍵の所有者情報: 鍵の所有者属性は、鍵を作成またはアクティブ化したユーザーを判断するために役立ちます。これらの属性は、セキュリティ、監査、および追跡において重要な場合があります。また、鍵の所有者属性には、鍵がスタンドアロンTDE操作に使用されるか、マルチテナント環境で使用されるかといった、鍵の使用情報が含まれます。
V$ENCRYPTION_KEYSビューには、CREATOR、CREATOR_ID、USER、USER_ID、KEY_USEなどの列が含まれます。

- 鍵ソース情報: 多くの場合、鍵は、インポート/エクスポート操作やData Guard関連の操作のためにデータベース間で移動する必要があります。鍵ソース属性によって、それぞれの鍵の起点を追跡できます。鍵がローカルで作成されたかインポートされたか、および鍵を作成したデータベースのデータベース名とインスタンス番号を追跡できます。マルチテナント環境では、キーが作成されたPDBを追跡できます。
V$ENCRYPTION_KEYSビューには、CREATOR_DBNAME、CREATOR_DBID、CREATOR_INSTANCE_NAME、CREATOR_INSTANCE_NUMBER、CREATOR_PDBNAMEなどの列が含まれます。

- 鍵の使用情報: 鍵の使用情報によって、鍵が使用されているデータベースまたはPDBが決まります。また、鍵がアクティブに使用されているかどうかを判断するために役立ちます。
V$ENCRYPTION_KEYSビューには、ACTIVATING_DBNAME、ACTIVATING_DBID、ACTIVATING_INSTANCE_NAME、ACTIVATING_PDBNAMEなどの列が含まれます。

- ユーザー定義情報およびその他の情報: 鍵を作成するとき、TAGオプションを使用して情報を関連付けることができます。各鍵には、バックアップされたかどうかなどの重要な情報が含まれます。
V$ENCRYPTION_KEYSビューには、KEY_ID、TAGなどの列と、BACKED_UPなどのその他の列が含まれます。

使用中のTDEマスター暗号化鍵の検出

使用中のTDEマスター暗号化鍵は、データベースで一番最近アクティブ化された鍵です。

マルチテナント環境で、PDBで使用されているマスター鍵は、そのPDB用に最も最近アクティブ化されたものになります。

- マスター鍵を検出するには、V$ENCRYPTION_KEYS動的ビューを問い合せます。

- CDB以外で使用中のマスター鍵を検出する場合:

SELECT KEY_ID
FROM V$ENCRYPTION_KEYS
WHERE ACTIVATION_TIME = (SELECT MAX(ACTIVATION_TIME)
FROM V$ENCRYPTION_KEYS
WHERE ACTIVATING_DBID = (SELECT DBID FROM V$DATABASE));

- CDBで使用中のマスター鍵を検出する場合:

SELECT KEY_ID
FROM V$ENCRYPTION_KEYS
WHERE ACTIVATION_TIME = (SELECT MAX(ACTIVATION_TIME)
FROM V$ENCRYPTION_KEYS
WHERE ACTIVATING_PDBID = SYS_CONTEXT('USERENV', 'CON_ID'));

レポート用のTDEマスター暗号化鍵のカスタム属性の作成

TDEマスター暗号化鍵のカスタム属性では、ニーズに適した属性を定義できます。

内容は次のとおりです。

- カスタム属性タグの作成について

- カスタム属性タグの作成

カスタム属性タグの作成について

属性タグにより、特定の端末IDへのアクセスなど、ユーザーが実行する特定のアクティビティを監視できます。

デフォルトでは、Oracle Databaseには、作成時間やTDEマスター暗号化鍵が使用されるデータベースなど、作成されるTDEマスター暗号化鍵の様々な特性を説明する属性セットが定義されます。これらの属性は、V$ENCRYPTION_KEY動的ビューによって取得されます。

V$ENCRYPTION_KEYS動的ビューのTAG列で取得可能なカスタム属性を作成できます。これにより、暗号化鍵を操作するユーザーなど、監視したい動作を定義できます。タグには、特定の端末のセッションIDなど、複数の属性を含めることができます。

カスタム属性タグの作成

カスタム属性タグを作成するには、ADMINISTER KEY MANAGEMENT文のSET TAG句を使用する必要があります。

1. ADMINISTER KEY MANAGEMENTまたはSYSKM権限が付与されたユーザーとして、データベース・インスタンスにログインします。
マルチテナント環境では、rootとしてログインします。例:

sqlplus c##sec_admin as syskm
Enter password: password
Connected.

2. 必要に応じて、V$ENCRYPTION_KEY動的ビューのTAG列を問い合せて、TDEマスター暗号化鍵の既存のタグのリストを確認します。
TDEマスター暗号化鍵の新しいタグを作成すると、そのTDEマスター暗号化鍵の既存のタグは上書きされます。

3. 次のようにタグを作成します。

ADMINISTER KEY MANAGEMENT SET TAG 'tag' FOR 'master_key_identifier'
IDENTIFIED BY keystore_password
[WITH BACKUP [USING 'backup_identifier']];

ここでは次のように指定します

- tagは、定義する関連の属性または情報です。この情報は、一重引用符(' ')で囲みます。

- master_key_identifierは、tagが設定されるTDEマスター暗号化鍵を識別します。TDEマスター暗号化鍵識別子のリストを確認するには、V$ENCRYPTION_KEYS動的ビューのKEY_ID列を問い合せます。

- keystore_passwordは、キーストアの作成に使用されたパスワードです。

- backup_identifierは、タグの値を定義します。この設定は一重引用符(' ')で囲み、それぞれの値をコロンで区切ります。

たとえば、2つの値(1番目は特定のセッションID、2番目は特定の端末IDを取得)を使用するタグを作成するには、次のようにします。

ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY USING TAG
'sessionid=3205062574:terminal=xcvt'
IDENTIFIED BY keystore_password WITH BACKUP;

keystore altered.

セッションID (3205062574)と端末ID (xcvt)はどちらも、SYS_CONTEXT関数でUSERENVネームスペースを使用するか、USERENV関数を使用することで、値を導出できます。SYS_CONTEXT関数のUSERENVネームスペースの事前定義パラメータの完全なリストについては、Oracle Database SQL言語リファレンスを参照してください。

TDEマスター暗号化鍵のタグを作成すると、その名前がそのTDEマスター暗号化鍵のV$ENCRYPTION_KEYSビューのTAG列に表示されます。シークレットのタグを作成すると、そのタグは、V$CLIENT_SECRETSビューのSECRET_TAG列に表示されます。タグでシークレットを作成した場合、そのタグはV$CLIENT_SECRETSビューのSECRET_TAG列に表示されます。

関連項目:

シークレット作成の詳細は、キーストアへのOracle GoldenGateのシークレットの格納を参照してください。

キーストアのTDEマスター暗号化鍵の設定および再設定

ソフトウェア・キーストアとハードウェア・キーストアの両方の、TDEマスター暗号化鍵を設定および再設定できます。

内容は次のとおりです。

- キーストアのTDEマスター暗号化鍵の設定およびローテーションについて

- TDEマスター暗号化鍵の作成とバックアップおよびタグの適用

- TDEマスター暗号化鍵のローテーションについて

- TDEマスター暗号化鍵のローテーション

キーストアのTDEマスター暗号化鍵の設定およびローテーションについて

パスワードベースのソフトウェア・キーストアとハードウェア・キーストアの両方で、TDEマスター暗号化鍵を設定およびローテーションできます。

TDEマスター暗号化鍵は、外部セキュリティ・モジュール(キーストア)に格納され、TDE表キーおよび表領域暗号化鍵の保護に使用されます。デフォルトでは、TDEマスター暗号化鍵は、透過的データ暗号化(TDE)によって作成されるシステム生成のランダム値です。

TDEマスター暗号化鍵を設定または再設定(REKEY)するには、ADMINISTER KEY MANAGEMENT文を使用します。マスター暗号化鍵を設定すると、TDEは有効とみなされ、無効にすることはできません。

データベースの列または表領域を暗号化または復号化するには、TDEマスター暗号化鍵を事前に生成しておく必要があります。Oracle Databaseでは、TDE列暗号化とTDE表領域暗号化の両方で同じTDEマスター暗号化鍵が使用されます。次の各項では、基本的なTDEマスター暗号化鍵の作成方法について説明します。

- ソフトウェア・キーストアのマスター暗号化鍵: 手順4: ソフトウェアTDEマスター暗号化鍵の設定

- ハードウェア・キーストアのマスター暗号化鍵: 手順4: ハードウェア・キーストアのTDEマスター暗号化鍵の設定

TDEマスター暗号化鍵の作成とバックアップおよびタグの適用

ADMINISTER KEY MANAGEMENT文を使用して、TDEマスター暗号化鍵を作成してバックアップし、その鍵にタグを適用できます。

1. ADMINISTER KEY MANAGEMENTまたはSYSKM権限が付与されたユーザーとして、データベース・インスタンスにログインします。
マルチテナント環境で、rootまたはPDBにログインします。例:

sqlplus sec_admin@hrpdb as syskm
Enter password: password
Connected.

利用可能なPDBを検索するには、DBA_PDBSデータ・ディクショナリ・ビューを問い合せます。現在のPDBを確認するには、show con_nameコマンドを実行します。

2. 次のSQL文を実行します。

ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY [USING TAG 'tag']
IDENTIFIED BY keystore_password WITH BACKUP
[USING 'backup_identifier'] [CONTAINER = ALL | CURRENT];

ここでは次のように指定します。

- tagは、作成するタグです。このタグは、一重引用符(' ')で囲みます。(タグの詳細は、レポート用のTDEマスター暗号化鍵のカスタム属性の作成を参照してください。)

- keystore_passwordは、software_keystore_passwordまたはuser_id:passwordのいずれかです。user_id:password設定は、手順2: ハードウェア・セキュリティ・モジュールの構成の手順3で作成したハードウェア・キーストアのユーザーIDとパスワードです。ソフトウェア・パスワードと同様に、大/小文字が区別されます。パスワード文字列は、二重引用符(" ")で囲む必要があります。user_idとpasswordをコロン(:)で区切ります。

- WITH BACKUPは、鍵と同じ場所(V$ENCRYPTION_WALLETビューのWRL_PARAMETER列で識別されます)にTDEマスター暗号化鍵をバックアップします。すべてのデータベース・インスタンスのWRL_PARAMETER値を見つけるには、GV$ENCRYPTION_WALLETビューを問い合せます。
パスワードベースのソフトウェア・キーストアをバックアップする必要があります。自動ログイン・ソフトウェア・キーストアやローカル自動ログイン・ソフトウェア・キーストアの場合、使用する必要はありません。オプションで、USING backup_identifier句を含めることで、バックアップの説明を追加できます。この識別子は、一重引用符(' ')で囲みます。

- CONTAINERは、マルチテナント環境で使用するために用意されています。このCDBのすべてのPDBで暗号化鍵を設定する場合はALL、現在のPDBの場合はCURRENTを入力します。

例:

ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY USING TAG 'backups"
IDENTIFIED BY password WITH BACKUP USING 'hr.emp_key_backup';

keystore altered.

Oracle Databaseでは、sqlnet.oraファイルのENCRYPTION_WALLET_LOCATIONパラメータによって指定されているキーストア・ロケーションにあるキーストアを使用して、TDEマスター暗号化鍵を格納します。sqlnet.oraファイルのENCRYPTION_WALLET_LOCATIONパラメータの動作の詳細は、「sqlnet.oraファイルにおけるキーストア・ロケーションについて」を参照してください。

TDEマスター暗号化鍵のローテーションについて

Oracle Databaseでは、TDE列暗号化とTDE表領域暗号化の両方で統合されたマスター暗号化鍵が使用されます。

TDE列暗号化用にTDEマスター暗号化鍵をローテーション(キー更新とも呼ぶ)すると、TDE表領域暗号化用のマスター暗号化鍵もローテーションされます。マスター暗号化鍵のローテーションは、マスター暗号化鍵の安全性が損なわれた場合、または組織のセキュリティ・ポリシーに従う場合にのみ実行します。このプロセスによって、前のTDEマスター暗号化鍵は非アクティブ化されます。

TDEマスター暗号化鍵を変更したり、自動ログイン・キーストアのTDEマスター暗号化鍵をローテーションすることはできません。自動ログイン・キーストアにはパスワードがないため、管理者または権限のあるユーザーは、セキュリティ担当者に知らせずに鍵を変更できます。ただし、自動ログイン・キーストアとパスワードベースのキーストアの両方が(sqlnet.oraファイルで設定する)構成されたロケーションに存在する場合、TDEマスター暗号化鍵をローテーションすると、自動ログイン・キーストアとパスワードベースのキーストアの両方にTDEマスター暗号化鍵が追加されます。自動ログイン・キーストアが、パスワードベースのキーストアとは異なるロケーションで使用中の場合、自動ログイン・キーストアを再作成する必要があります。

注意:

自動ログイン・キーストアに新しい情報を個別に追加することはできません。

TDEマスター暗号化鍵のローテーション

ADMINISTER KEY MANAGEMENT文を使用して、TDEマスター暗号化鍵をローテーション(キー更新とも呼ぶ)できます。

1. ADMINISTER KEY MANAGEMENTまたはSYSKM権限が付与されたユーザーとして、データベース・インスタンスにログインします。
マルチテナント環境で、rootまたはPDBにログインします。たとえば、hrpdbというPDBにログインするには、次のようにします。

sqlplus sec_admin@hrpdb as syskm
Enter password: password
Connected.

利用可能なPDBを検索するには、DBA_PDBSデータ・ディクショナリ・ビューを問い合せます。現在のPDBを確認するには、show con_nameコマンドを実行します。

2. キーストアが開いていることを確認します。
V$ENCRYPTION_WALLETビューのSTATUS列を問い合せて、キーストアが開いているかどうかを確認します。キーストアが閉じている場合、開く方法の詳細は、次の項を参照してください。

- 手順3: ソフトウェア・キーストアを開く

- 手順3: ハードウェア・キーストアを開く

3. 自動ログインを有効化したキーストアのTDEマスター暗号化鍵をローテーションする場合、.ssoファイルによって識別される自動ログイン・キーストアと.p12ファイルによって識別される暗号化キーストアの両方が存在することを確認する必要があります。
これらのファイルのロケーションは、V$ENCRYPTION_WALLETビューのWRL_PARAMETER列を問い合せることで確認できます。すべてのデータベース・インスタンスのWRL_PARAMETER値を見つけるには、GV$ENCRYPTION_WALLETビューを問い合せます。

4. 次の文を使用して、TDEマスター暗号化鍵をローテーションします。

ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY [USING TAG 'tag'] IDENTIFIED BY keystore_password WITH BACKUP [USING 'backup_identifier'] [CONTAINER = ALL | CURRENT];

ここでは次のように指定します。

- tagは、定義する関連の属性および情報です。この設定は一重引用符(' ')で囲みます。

- keystore_passwordは、手順2: ソフトウェア・キーストアを作成するでキーストア作成時に作成した必須のキーストア・パスワードです。

- WITH BACKUPを使用すると、キーストアのバックアップが作成されます。パスワードベースのキーストアおよびハードウェア・キーストアの場合、このオプションを使用する必要があります。オプションでUSING句を使用し、バックアップの簡単な説明を追加できます。この説明は一重引用符(' ')で囲みます。この識別子は名前付きキーストア・ファイルに付加されます(ewallet_time-stamp_emp_key_backup.p12など)。オペレーティング・システムで使用されているファイル命名規則に従ってください。

- CONTAINERは、マルチテナント環境で使用するために用意されています。このCDBのすべてのPDBでキーストアを開くには、ALLを入力するか、現在のPDBでキーストアを開くには、CURRENTを入力します。

例:

ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY password WITH BACKUP USING 'emp_key_backup';

keystore altered.

セキュリティを強化し、コンプライアンス規制を満たすために、定期的にTDEマスター暗号化鍵をローテーションすることをお薦めします。このプロセスでは、前のTDEマスター暗号化鍵を非アクティブ化し、新しいTDEマスター暗号化鍵を作成してアクティブ化します。最近作成された鍵を確認するには、V$ENCRYPTION_KEYSビューのCREATION_TIME列を問い合せます。最近アクティブ化された鍵を確認するには、V$ENCRYPTION_KEYSビューのACTIVATION_TIME列を問い合せます。

TDEマスター暗号化鍵のエクスポートおよびインポート

TDEマスター暗号化鍵は、その他のOracle機能(マルチテナント環境やOracle Data Guardなど)のニーズを満たすために、様々な方法でエクスポートおよびインポートできます。

内容は次のとおりです。

- TDEマスター暗号化鍵のエクスポートおよびインポートについて

- TDEマスター暗号化鍵のエクスポートについて

- TDEマスター暗号化鍵のエクスポート

- 例: 副問合せを使用したTDEマスター暗号化鍵識別子のエクスポート

- 例: ファイルへのTDEマスター暗号化鍵識別子のリストのエクスポート

- 例: データベースのすべてのTDEマスター暗号化鍵のエクスポート

- TDEマスター暗号化鍵のインポートについて

- TDEマスター暗号化鍵のインポート

- 例: TDEマスター暗号化鍵のインポート

- キーストアのマージとTDEマスター暗号化鍵のエクスポートまたはインポートの相違点

関連項目:

Oracle Data Pumpを使用してダンプ・セット全体を暗号化

TDEマスター暗号化鍵のエクスポートおよびインポートについて

Oracle Databaseには、トランスポータブル表領域などの機能があり、Oracle Data Pumpでは、データベース間で暗号化される可能性のあるデータが移動されます。

さらに、CDBにはプラグインまたはアンプラグ可能なPDBが含まれます。これらは、TDEマスター暗号化鍵のエクスポートとインポートによってソース・キーストアとターゲット・キーストア間でそれらを移動することを選択できる一般的なシナリオです。Data Guard (ロジカル・スタンバイ)では、プライマリ・データベースのキーストアをスタンバイ・データベースにコピーする必要があります。プライマリ・データベースのキーストアをスタンバイ・データベースとマージするかわりに、使用中のTDEマスター暗号化鍵をエクスポートした後でスタンバイ・データベースにインポートできます。暗号化されているトランスポータブル表領域をデータベース間で移動するには、ソース・データベースのTDEマスター暗号化鍵をエクスポートしてから、ターゲット・データベースにインポートする必要があります。

TDEマスター暗号化鍵のエクスポートについて

ADMINISTER KEY MANAGEMENT EXPORTを使用して、キーストアからTDEマスター暗号化鍵をエクスポートし、その後、別のキーストアにインポートできます。

TDEマスター暗号化鍵は、鍵識別子および鍵属性とともにエクスポートされます。エクスポートされる鍵は、エクスポート・ファイルのパスワード(シークレット)で保護されます。

エクスポートするTDEマスター暗号化鍵を指定するには、ADMINSITER KEY MANAGENT EXPORT文のWITH IDENTIFIER句を使用します。TDEマスター暗号化鍵をエクスポートするには、それらの鍵識別子をカンマ区切りリストとして指定するか、鍵識別子を列挙する問合せを指定します。Oracle Databaseでは、定義者の権限ではなく現在のユーザーの権限内で鍵識別子を特定する問合せが実行されることに注意してください。

WITH IDENTIFER句を省略すると、データベースのすべてのTDEマスター暗号化鍵がエクスポートされます。

統合データベースでは、PDBのアンプラグのためにPDB内から鍵をエクスポートできます。このシナリオでは、PDBではなくrootでのみWITH IDENTIFIER句を使用できます。PDBで鍵をエクスポートする方法の詳細は、PDB向けのTDEマスター暗号化鍵のエクスポートおよびインポートを参照してください。

TDEマスター暗号化鍵のセットをエクスポートするには:

関連項目:

マルチテナント環境でこの文を使用する例の詳細は、PDB向けのTDEマスター暗号化鍵のエクスポートおよびインポートを参照してください

TDEマスター暗号化鍵のエクスポート

EXPORT [ENCRYPTION] KEYS WITH SECRET句を含むADMINISTER KEY MANAGEMENT文によって、TDEマスター暗号化鍵をエクスポートします。

1. ADMINISTER KEY MANAGEMENTまたはSYSKM権限が付与されたユーザーとして、データベース・インスタンスにログインします。
マルチテナント環境では、rootとしてログインします。例:

sqlplus c##sec_admin as syskm
Enter password: password
Connected.

2. 必要に応じて、キーストアを開きます。
キーストアを開く方法の詳細は、手順3: ソフトウェア・キーストアを開くを参照してください。

3. 次のSQL文を実行して、TDEマスター暗号化鍵のセットをエクスポートします。

ADMINISTER KEY MANAGEMENT EXPORT [ENCRYPTION] KEYS
WITH SECRET "export_secret"
TO 'file_path' IDENTIFIED BY software_keystore_password
[WITH IDENTIFIER IN 'key_id1', 'key_id2', 'key_idn' | (SQL_query)];

ここでは次のように指定します。

- export_secretは、エクスポートする鍵が含まれるエクスポート・ファイルを暗号化するために指定できるパスワードです。このシークレットは、二重引用符(" ")で囲むか、シークレットにスペースが使われていない場合は引用符を省略できます。

- file_pathは、鍵のエクスポート先ファイルの完全パスと名前です。このパスは、一重引用符(' ')で囲みます。

- software_keystore_passwordは、鍵が含まれるキーストアのパスワードです。

- key_id1、key_id2、key_idnは、エクスポートするTDEマスター暗号化鍵の1つ以上のTDEマスター暗号化鍵識別子の文字列です。各鍵識別子はカンマで区切り、それぞれの鍵識別子を一重引用符(' ')で囲みます。TDEマスター暗号化鍵識別子のリストを確認するには、V$ENCRYPTION_KEYS動的ビューのKEY_ID列を問い合せます。

- SQL_queryは、TDEマスター暗号化鍵識別子のリストをフェッチする問合せです。これによって、通常はTDEマスター暗号化鍵識別子が含まれる1つの列のみが返されます。この問合せは、現在のユーザー権限で実行されます。

例: 副問合せを使用したTDEマスター暗号化鍵識別子のエクスポート

ADMINISTER KEY MANAGEMENT EXPORT ENCRYPTION KEYS文によって、副問合せを使用してTDEマスター暗号化鍵をエクスポートできます。

例4-8に、識別子が問合せによってフェッチされるTDEマスター暗号化鍵をexport.expというファイルにエクスポートする方法を示します。ファイル内のTDEマスター暗号化鍵は、シークレットmy_secretを使用して暗号化されます。SELECT文で、エクスポートするTDEマスター暗号化鍵の識別子を検出します。

マルチテナント環境では、PDB内で鍵をインポートまたはエクスポートしようとする場合、WITH IDENTIFIER句はサポートされません。これはrootでのみ許可されます。PDBで鍵をエクスポートする方法の詳細は、PDB向けのTDEマスター暗号化鍵のエクスポートおよびインポートを参照してください。

例4-7 ファイルへのTDEマスター暗号化鍵識別子のリストのエクスポート

ADMINISTER KEY MANAGEMENT EXPORT ENCRYPTION KEYS WITH SECRET "my_secret"
TO '/TDE/export.exp' IDENTIFIED BY password
WITH IDENTIFIER IN 'AdoxnJ0uH08cv7xkz83ovwsAAAAAAAAAAAAAAAAAAAAAAAAAAAAA',
'AW5z3CoyKE/yv3cNT5CWCXUAAAAAAAAAAAAAAAAAAAAAAAAAAAAA';

keystore altered.

例: ファイルへのTDEマスター暗号化鍵識別子のリストのエクスポート

ADMINISTER KEY MANAGEMENT EXPORT ENCRYPTION KEYS WITH SECRET文によって、TDEマスター暗号化鍵識別子のリストをファイルにエクスポートできます。

例4-7に、リストとして識別子を指定することでTDEマスター暗号化鍵をexport.expというファイルにエクスポートする方法を示します。ファイル内のマスター暗号化鍵は、シークレットmy_secretを使用して暗号化されます。エクスポートされるTDEマスター暗号化キーの識別子は、カンマ区切りのリストとして提供されます。

例4-8 副問合せを使用したTDEマスター暗号化鍵識別子のエクスポート

ADMINISTER KEY MANAGEMENT EXPORT ENCRYPTION KEYS WITH SECRET "my_secret"
TO '/etc/TDE/export.exp' IDENTIFIED BY password
WITH IDENTIFIER IN (SELECT KEY_ID FROM V$ENCRYPTION_KEYS WHERE ROWNUM <3);

keystore altered.

例: データベースのすべてのTDEマスター暗号化鍵のエクスポート

ADMINISTER KEY MANAGEMENT EXPORT ENCRYPTION KEYS SQL文によって、データベースのすべてのTDEマスター暗号化鍵をエクスポートできます。

例4-9に、データベースのすべてのTDEマスター暗号化鍵をexport.expというファイルにエクスポートする方法を示します。ファイル内のTDEマスター暗号化鍵は、シークレットmy_secretを使用して暗号化されます。

例4-9 データベースのすべてのTDEマスター暗号化鍵のエクスポート

ADMINISTER KEY MANAGEMENT EXPORT ENCRYPTION KEYS WITH SECRET "my_secret" TO
'/etc/TDE/export.exp' IDENTIFIED BY password;

keystore altered.

TDEマスター暗号化鍵のインポートについて

ADMINISTER KEY MANAGEMENT IMPORT文によって、エクスポートしたTDEマスター暗号化鍵を鍵エクスポート・ファイルからターゲット・キーストアにインポートできます。

すでにインポートされているTDEマスター暗号化鍵を再インポートすることはできません。

統合データベースでは、PDBのプラグのためにPDB内から鍵をインポートできます。PDBで鍵をエクスポートする方法の詳細は、PDB向けのTDEマスター暗号化鍵のエクスポートおよびインポートを参照してください。

TDEマスター暗号化鍵のインポート

IMPORT [ENCRYPTION] KEYS WITH SECRET句を含むADMINISTER KEY MANAGEMENT文によって、TDEマスター暗号化鍵をインポートできます。

1. ADMINISTER KEY MANAGEMENTまたはSYSKM権限が付与されたユーザーとして、データベース・インスタンスにログインします。
マルチテナント環境では、rootとしてログインします。次のコマンドにより、ユーザーc##sec_adminをrootに記録します。

sqlplus c##sec_admin as syskm
Enter password: password
Connected.

2. 必要に応じて、キーストアを開きます。
キーストアを開く方法の詳細は、手順3: ソフトウェア・キーストアを開くを参照してください。

3. 次のSQL文を実行します。

ADMINISTER KEY MANAGEMENT IMPORT [ENCRYPTION] KEYS
WITH SECRET "import_secret"  FROM 'file_name' | FROM 'file_name'
IDENTIFIED BY [EXTERNAL STORE | keystore_password]
[WITH BACKUP [USING 'backup_identifier']];

ここでは次のように指定します。

- import_secretは、エクスポート操作時に鍵の暗号化に使用されたものと同じパスワードです。このシークレットは、二重引用符(" ")で囲むか、シークレットにスペースが使われていない場合は引用符を省略できます。

- file_nameは、鍵のインポート元ファイルの完全パスと名前です。この設定は、一重引用符(' ')で囲みます。

- IDENTIFIED BYは次のいずれかの設定にできます。

- EXTERNAL STOREは、外部ストアに格納されたキーストア・パスワードを使用して、キーストア操作を実行します。

- software_keystore_passwordは、鍵がインポートされているソフトウェア・キーストアのパスワードです。

- WITH BACKUPは、インポート操作の前にターゲット・キーストアがバックアップされていない場合は使用する必要があります。backup_identifierは、キーストアのバックアップを識別するために指定できるオプション文字列です。この設定は、一重引用符(' ')で囲みます。

例: TDEマスター暗号化鍵のインポート

ADMINISTER KEY MANAGEMENT IMPORT KEYS SQL文を使用して、TDEマスター暗号化鍵をインポートできます。

例4-10に、ファイルexport.expに格納され、シークレットmy_secretで暗号化されているTDEマスター暗号化鍵識別子をインポートする方法を示します。

例4-10 エクスポート・ファイルからのTDEマスター暗号化鍵識別子のインポート

ADMINISTER KEY MANAGEMENT IMPORT KEYS WITH SECRET "my_secret"
FROM '/etc/TDE/export.exp' IDENTIFIED BY password WITH BACKUP;

keystore altered.

キーストアのマージとTDEマスター暗号化鍵のエクスポートまたはインポートの相違点

キーストア・マージ操作は、TDEマスター暗号化鍵のエクスポートおよびインポート操作とは異なります。

ADMINISTER KEY MANAGEMENT MERGE文と、ADMINISTER KEY MANAGEMENT EXPORT文およびIMPORT文は、両方とも最終的にTDEマスター暗号化鍵があるキーストアから次のキーストアに移動されますが、これら2つの文の動作には違いがあります。

- MERGE文では2つのキーストアがマージされますが、EXPORTおよびIMPORT文ではファイルに鍵がエクスポートされるか、ファイルから鍵がインポートされます。キーストアはエクスポート・ファイルとは別のものであり、これら2つを交換して使用することはできません。エクスポート・ファイルはキーストアではなく、データベースでキーストアとして使用するように構成することはできません。同様に、IMPORT文でキーストアからTDEマスター暗号化鍵を抽出することはできません。

- MERGE文では指定したキーストアのすべてのTDEマスター暗号化鍵がマージされますが、EXPORTおよびIMPORT文では選択可能です。

- EXPORTおよびIMPORT文では、エクスポート・ファイルの場所(filepath)とファイル名の両方を指定する必要がありますが、MERGE文ではキーストアの場所のみを指定します。

- キーストアのファイル名は固定で、MERGE操作によって決定され、ewallet.p12またはcwallet.ssoになります。EXPORTおよびIMPORT文で使用するエクスポート・ファイルのファイル名は、ユーザーが指定します。

- 自動ストレージ管理(ASM)ディスク・グループまたは通常のファイル・システムのキーストアは、MERGE文でマージできます。EXPORTおよびIMPORT文で使用するエクスポート・ファイルは、通常のオペレーティング・システム・ファイルである必要があり、ASMディスク・グループには配置できません。

- MERGE文を使用してマージするキーストアは、構成されたり、データベースで使用されている必要はありません。EXPORT文は、構成されてデータベースで使用され、エクスポートの終了時に開かれるキーストアからのみ鍵をエクスポートできます。IMPORT文は、開かれて構成され、データベースで使用されているキーストアにのみ鍵をインポートできます。

- MERGE文では、TDEマスター暗号化鍵に関連付けられたメタデータは絶対に変更されません。EXPORTおよびIMPORT操作では、PDBのプラグ操作時など、必要に応じてTDEマスター暗号化鍵のメタデータが変更されることがあります。

Oracle Key Vaultを使用したTDEマスター暗号化鍵の管理

Oracle Key Vaultを使用して、企業全体でTDEマスター暗号化鍵を管理および共有できます。

Oracle Key Vaultでは、資格証明ファイルやJavaキーストアなどのセキュリティ・オブジェクトとともに、鍵を中央リポジトリに安全に格納し、これらのオブジェクトを他のTDE対応データベースと共有できます。

関連項目:

- Oracle Key Vaultの使用のその他の利点は、キーストアとOracle Key Vault間の移行

- Oracle Key Vault管理者ガイド

Oracle Databaseで使用するシークレットの格納

シークレットとは、Oracle Databaseの内部機能をサポートするデータであり、Oracle GoldenGateなどの外部クライアントをデータベースに統合することを可能にします。

内容は次のとおりです。

- キーストアへのOracle Databaseのシークレットの格納について

- ソフトウェア・キーストアへのOracle Databaseのシークレットの格納

- 例: ソフトウェア・キーストアへのHSMパスワードの追加

- 例: ソフトウェア・キーストアにシークレットとして格納されているHSMパスワードの変更

- 例: ソフトウェア・キーストアにシークレットとして格納されているHSMパスワードの削除

- ハードウェア・キーストアへのOracle Databaseのシークレットの格納

- 例: ハードウェア・キーストアへのOracle Databaseのシークレットの追加

- 例: ハードウェア・キーストアでのOracle Databaseのシークレットの変更

- 例: ハードウェア・キーストアでのOracle Databaseのシークレットの削除

- 自動ログイン・ハードウェア・セキュリティ・モジュールの構成

キーストアへのOracle Databaseのシークレットの格納について

キーストアでは、Oracle Databaseの内部機能をサポートするシークレットを格納したり、Oracle GoldenGateなどの外部クライアントを統合できます。

秘密鍵はOracleの識別子規則に従った文字列である必要があります。既存のキーストアでクライアントのシークレットを追加、更新または削除できます。Oracle GoldenGateのExtractプロセスでは、データ・ファイル内およびREDOまたはUNDOログ内のデータを復号化するためにデータ暗号化鍵が必要です。鍵は、Oracle DatabaseとOracle GoldenGateクライアントの間で鍵を共有するときに、共有シークレットによって暗号化されます。ソフトウェア・キーストアには、共有シークレットが格納されます。

サイトの要件によっては、ハードウェア・セキュリティ・モジュールが構成されている場合でも、自動的にキーストアを開く操作が必要となる場合があります。そのため、ハードウェア・セキュリティ・モジュールのパスワードを自動ログイン・ソフトウェア・キーストアに格納し、ハードウェア・セキュリティ・モジュールで自動ログイン機能を有効にすることができます。また、Oracle Database側では、データベース用の資格証明を格納して、ソフトウェア・キーストアで外部ストレージ・サーバーにログインできます。

Oracle Databaseのシークレットをソフトウェア・キーストアとハードウェア・キーストアの両方に格納できます。

- ソフトウェア・キーストア: シークレットをパスワードベースのソフトウェア・キーストア、自動ログイン・ソフトウェア・キーストア、およびローカル自動ログイン・ソフトウェア・キーストアに格納できます。シークレットを自動ログイン(または自動ログイン・ローカル)・キーストアに格納する場合は、次の点に注意してください。

- 自動ログイン・ソフトウェア・キーストアがその対応するパスワードベースのソフトウェア・キーストアと同じロケーションにある場合、シークレットは自動的に追加されます。

- 自動ログイン・ソフトウェア・キーストアがその対応するパスワードベースのソフトウェア・キーストアと異なるロケーションにある場合、パスワードベースのキーストアから自動ログイン・キーストアを再度作成して、2つのキーストアの同期を維持する必要があります。

- ハードウェア・キーストア: シークレットを標準ハードウェア・セキュリティ・モジュールに格納できます。

関連項目:

- ハードウェア・キーストアへのOracle Databaseのシークレットの格納

- 自動ログイン・ハードウェア・セキュリティ・モジュールの構成

ソフトウェア・キーストアへのOracle Databaseのシークレットの格納

ADMINISTER KEY MANAGEMENT ADD SECRET|UPDATE SECRET|DELETE CLIENT文によって、シークレットの追加、シークレットの更新、およびキーストアからのシークレットの削除を行うことができます。

すべてのADMINISTER KEY MANAGEMENT文と同様に、ADMINISTER KEY MANAGEMENTまたはSYSKM管理権限が必要です。マルチテナント環境では、この文をrootで実行します。

- シークレットの追加: 次の構文を使用します。

ADMINISTER KEY MANAGEMENT
ADD SECRET 'secret' FOR CLIENT 'client_identifier' [USING TAG 'tag']
IDENTIFIED BY keystore_password [WITH BACKUP [USING 'backup_identifier'];

- シークレットの更新: 次の構文を使用します。

ADMINISTER KEY MANAGEMENT
UPDATE SECRET 'secret' FOR CLIENT 'client_identifier' [USING TAG 'tag']
IDENTIFIED BY keystore_password [WITH BACKUP [USING 'backup_identifier'];

- シークレットの削除: 次の構文を使用します。

ADMINISTER KEY MANAGEMENT
DELETE SECRET FOR CLIENT 'client_identifier'
IDENTIFIED BY keystore_password [WITH BACKUP [USING 'backup_identifier'];

これらの文すべてで、次のように指定します。

- secretは、格納、更新、または削除するクライアントの秘密鍵です。この設定は、一重引用符(' ')で囲むか、シークレットにスペースが使われていない場合は引用符を省略します。

- client_identifierは、秘密鍵の識別に使用される英数字文字列です。client_identifierにはデフォルト値はありません。この設定は、一重引用符(' ')で囲みます。

- tagは、格納する秘密鍵についてのオプションのユーザー定義の説明です。tagは、ADDおよびUPDATE操作と一緒に使用できます。この設定は、一重引用符(' ')で囲みます。このタグは、V$CLIENT_SECRETSビューのSECRET_TAG列に表示されます。タグの詳細は、レポート用のTDEマスター暗号化鍵のカスタム属性の作成を参照してください。

- keystore_passwordは、キーストアのパスワードです。

- WITH BACKUPは、ADD、UPDATEまたはDELETE操作の前にキーストアがバックアップされていない場合は必須です。backup_identifierは、バックアップについてのオプションのユーザー定義の説明です。backup_identifierは、一重引用符(' ')で囲みます。

例: ソフトウェア・キーストアへのHSMパスワードの追加

ADMINISTER KEY MANAGEMENT ADD SECRET文によって、ソフトウェア・キーストアにHSMパスワードを追加できます。

例4-11に、ソフトウェア・キーストアにハードウェア・セキュリティ・モジュール(HSM)のパスワードをシークレットとして追加する方法を示します。

例4-11 ソフトウェア・キーストアへのOracle Databaseのシークレットの追加

ADMINISTER KEY MANAGEMENT
ADD SECRET 'psmith:password' FOR CLIENT 'HSM_PASSWORD'
USING TAG 'HSM credentials' IDENTIFIED BY password WITH BACKUP;

例: ソフトウェア・キーストアにシークレットとして格納されているHSMパスワードの変更

ADMINISTER KEY MANAGEMENT UPDATE SECRET文によって、ソフトウェア・キーストアにシークレットとして格納されているHSMパスワードを変更できます。

例4-12に、シークレットとしてソフトウェア・キーストアに格納されているHSMパスワードを変更する方法を示します。

例4-12 ソフトウェア・キーストアでのOracle Databaseのシークレットの変更

ADMINISTER KEY MANAGEMENT
UPDATE SECRET admin_password FOR CLIENT 'HSM_PASSWORD'
USING TAG 'new_host_credentials' IDENTIFIED BY software_keytore_password;

例: ソフトウェア・キーストアにシークレットとして格納されているHSMパスワードの削除

ADMINISTER KEY MANAGEMENT DELETE SECRET文によって、ソフトウェア・キーストアにシークレットとして格納されているHSMパスワードを削除できます。

例4-13に、シークレットとしてソフトウェア・キーストアに格納されているHSMパスワードを削除する方法を示します。

例4-13 ソフトウェア・キーストアでのOracle Databaseのシークレットの削除

ADMINISTER KEY MANAGEMENT
DELETE SECRET FOR CLIENT 'HSM_PASSWORD'
IDENTIFIED BY password WITH BACKUP;

ハードウェア・キーストアへのOracle Databaseのシークレットの格納

ADMINISTER KEY MANAGEMENT ADD SECRET|UPDATE SECRET|DELETE CLIENT文によって、シークレットの追加、更新および削除を行うことができます。

すべてのADMINISTER KEY MANAGEMENT文と同様に、ADMINISTER KEY MANAGEMENTまたはSYSKM管理権限が必要です。マルチテナント環境では、この文をrootで実行します。

注意:

シークレットをハードウェア・セキュリティ・モジュールに追加しようとする前に、PDCS#11データ・オブジェクトがサポートされていることを確認してください。

- シークレットの追加: 次の構文を使用します。

ADMINISTER KEY MANAGEMENT ADD SECRET 'secret'
FOR CLIENT 'client_identifier' [USING TAG 'tag']
IDENTIFIED BY "user_id:password";

- シークレットの更新: 次の構文を使用します。

ADMINISTER KEY MANAGEMENT UPDATE SECRET 'secret'
FOR CLIENT 'client_identifier' [USING TAG 'tag']
IDENTIFIED BY "user_id:password";

- シークレットの削除: 次の構文を使用します。

ADMINISTER KEY MANAGEMENT DELETE SECRET FOR CLIENT 'client_identifier'
IDENTIFIED BY "user_id:password";

これらの文すべてで、次のように指定します。

- secretは、格納、更新、または削除するクライアントの秘密鍵です。この設定は、二重引用符(' ')で囲むか、シークレットにスペースが使われていない場合は引用符を省略します。

- client_identifierは、秘密鍵の識別に使用される英数字文字列です。client_identifierにはデフォルト値はありません。この設定は、一重引用符(' ')で囲みます。

- tagは、格納する秘密鍵についてのオプションのユーザー定義の説明です。tagは、ADDおよびUPDATE操作と一緒に使用できます。この設定は一重引用符(' ')で囲みます。このタグは、V$CLIENT_SECRETSビューのSECRET_TAG列に表示されます。タグの詳細は、レポート用のTDEマスター暗号化鍵のカスタム属性の作成を参照してください。

- user_id:passwordは、ハードウェア・キーストアのパスワードです。user_idとpasswordをコロンで区切り、この設定を二重引用符(" ")で囲みます。

例: ハードウェア・キーストアへのOracle Databaseのシークレットの追加

ADMINISTER KEY MANAGEMENT ADD SECRET文によって、ハードウェア・キーストアにOracle Databaseのシークレットを追加できます。

例4-14に、ユーザーのパスワードをハードウェア・キーストアに追加する方法を示します。

例4-14 ハードウェア・キーストアへのOracle Databaseのシークレットの追加

ADMINISTER KEY MANAGEMENT ADD SECRET 'password'
FOR CLIENT 'admin@myhost' USING TAG 'myhost admin credentials'
IDENTIFIED BY "psmith:password";

例: ハードウェア・キーストアでのOracle Databaseのシークレットの変更

ADMINISTER KEY MANAGEMENT MANAGEMENT UPDATE SECRET文によって、ハードウェア・キーストアにあるOracle Databaseのシークレットを変更できます。

例4-15に、シークレットとしてハードウェア・キーストアに格納されているパスワードを変更する方法を示します。

例4-15 ハードウェア・キーストアでのOracle Databaseのシークレットの変更

ADMINISTER KEY MANAGEMENT MANAGEMENT UPDATE SECRET 'password2'
FOR CLIENT 'admin@myhost' USING TAG 'New host credentials'
IDENTIFIED BY "psmith:password";

例: ハードウェア・キーストアでのOracle Databaseのシークレットの削除

ADMINISTER KEY MANAGEMENT DELETE SECRET FOR CLIENT文によって、ハードウェア・キーストアにあるOracle Databaseのシークレットを削除できます。

例4-16に、シークレットとしてハードウェア・キーストアに格納されているハードウェア・セキュリティ・モジュール・パスワードを削除する方法を示します。

例4-16 ハードウェア・キーストアでのOracle Databaseのシークレットの削除

ADMINISTER KEY MANAGEMENT DELETE SECRET FOR CLIENT 'admin@myhost'
IDENTIFIED BY "psmith:password";

自動ログイン・ハードウェア・セキュリティ・モジュールの構成

自動ログイン機能を使用するには、ハードウェア・セキュリティ・モジュールを構成します。

内容は次のとおりです。

- 自動ログイン・ハードウェア・セキュリティ・モジュールの構成について

- 自動ログイン・ハードウェア・セキュリティ・モジュールの構成

自動ログイン・ハードウェア・セキュリティ・モジュールの構成について

自動ログイン・ハードウェア・セキュリティ・モジュールは、自動ログイン・キーストア内にハードウェア・セキュリティ・モジュールの資格証明を格納します。

この構成により、システム全体のセキュリティが低下します。ただし、この構成は無人または自動化された操作をサポートし、ハードウェア・セキュリティ・モジュールの自動的な再ログインが必要なデプロイメントで役に立ちます。

問合せSELECT * FROM V$ENCRYPTION_WALLETを実行すると、自動ログイン・ハードウェア・セキュリティ・モジュールが自動的に開くため、注意してください。たとえば、自動ログイン・ハードウェア・セキュリティ・モジュールを構成しているとします。キーストアを閉じて、V$ENCRYPTION_WALLETビューを問い合せると、出力にキーストアが開かれていることが示されます。これはV$ENCRYPTION_WALLETが自動ログイン・ハードウェアを開いて、自動ログイン・キーストアのステータスを表示したためです。

ハードウェア・セキュリティ・モジュールの自動ログイン機能を有効にするには、ハードウェア・キーストアにハードウェア・セキュリティ・モジュールの資格証明を格納する必要があります。

自動ログイン・ハードウェア・セキュリティ・モジュールの構成

ADMINISTER KEY MANAGEMENT文によって、自動ログイン・ハードウェア・セキュリティ・モジュールを構成します。

1. 「ハードウェア・キーストアの構成」を使用してTDEハードウェア・キーストアが構成済であることを確認します。

2. ハードウェア・セキュリティ・モジュールが開いている場合は閉じます。(キーストアが開いているか、閉じているかのステータスは、V$ENCRYPTION_WALLETビューのSTATUS列を問い合せて、確認できます。)
例:

ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY "psmith:password";

詳細は、「ハードウェア・キーストアを閉じる」を参照してください。

3. まだソフトウェア・キーストアから移行していない場合、ハードウェア・キーストア・パスワードを使用して適切な場所にソフトウェア・キーストアを作成します(/etc/ORACLE/WALLETS/orclなど)。

例:

ADMINISTER KEY MANAGEMENT CREATE KEYSTORE '/etc/ORACLE/WALLETS/orcl'
IDENTIFIED BY "psmith:password";

4. 自動ログイン・ソフトウェア・キーストアを移行済で特定の場所(/etc/ORACLE/WALLETS/HSMなど)で使用中の場合、ハードウェア・キーストア・パスワードを使用してその自動ログイン・キーストアからソフトウェア・パスワード・キーストアを作成します。

例:

ADMINISTER KEY MANAGEMENT CREATE KEYSTORE '/etc/ORACLE/WALLETS/orcl' IDENTIFIED BY "psmith:password";

ADMINISTER KEY MANAGEMENT
MERGE KEYSTORE '/etc/ORACLE/WALLETS/HSM' -- Example keystore path
INTO EXISTING KEYSTORE '/etc/ORACLE/WALLETS/HSM' -- Example keystore location
IDENTIFIED BY "psmith:password" WITH BACKUP;

ADMINISTER KEY MANAGEMENTマージ文のキーストアの場所は、使用中のキーストアの場所である必要はありません。

5. sqlnet.oraファイルを再構成し、ENCRYPTION_WALLET_LOCATION設定のDIRECTORY設定に手順3または手順4で作成したソフトウェア・キーストアのキーストア・ロケーションを追加します。
例:

ENCRYPTION_WALLET_LOCATION=
(SOURCE=(METHOD=FILE)(METHOD_DATA=
(DIRECTORY=/etc/ORACLE/WALLETS/orcl)))

Oracle Databaseがキーストアの場所を探す方法の詳細は、「sqlnet.oraファイルでのキーストアの場所について」を参照してください。

6. データベースに再接続するか、ログアウトして再ログインすると、前の手順の変更内容が有効になります。
例:

CONNECT psmith/AS SYSKM
Enter password: password

7. ソフトウェア・キーストアを開きます。
例:

ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY software_keystore_password;

8. ソフトウェア・キーストアでシークレットを追加または更新します。
シークレットはハードウェア・セキュリティ・モジュール・パスワード、クライアントはHSM_PASSWORDです。HSM_PASSWORDは、HSMパスワードをソフトウェア・キーストアのシークレットとして表現するために使用されるOracle定義のクライアント名です。

例:

ADMINISTER KEY MANAGEMENT ADD SECRET "user_id:password"
FOR CLIENT "HSM_PASSWORD" IDENTIFIED BY software_keystore_password
WITH BACKUP;

9. ソフトウェア・キーストアを閉じます。
例:

ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY software_keystore_password;

10. 自動ログイン・キーストアを作成(または再作成)します。

ADMINISTER KEY MANAGEMENT CREATE AUTO_LOGIN KEYSTORE
FROM KEYSTORE '/etc/ORACLE/WALLETS/orcl/hsm' -- Keystore location
IDENTIFIED BY software_keystore_password;

11. ハードウェア・セキュリティ・モジュールのロケーションを使用するようにsqlnet.oraファイルを更新します。
例:

ENCRYPTION_WALLET_LOCATION=
(SOURCE=(METHOD=HSM)(METHOD_DATA=
(DIRECTORY=/etc/ORACLE/WALLETS/orcl)))

この段階で、TDE操作が次に実行されるときに、ハードウェア・セキュリティ・モジュールの自動ログイン・キーストアが自動的に開くようになります。

キーストアへのOracle GoldenGateのシークレットの格納

Oracle GoldenGateシークレットを透過的データ暗号化キーストアに格納できます。

内容は次のとおりです。

- キーストアへのOracle GoldenGateのシークレットの格納について

- Oracle GoldenGate Extractのクラシック・キャプチャ・モードのTDE要件

- Oracle GoldenGate用のTDEキーストア・サポートの構成

関連項目:

Oracle Key Vault環境でTDEとOracle GoldenGateを使用する方法は、『Oracle Key Vault管理者ガイド』

キーストアへのOracle GoldenGateのシークレットの格納について

キーストアを使用して、ツールおよびOracle GoldenGateなどの外部クライアントの秘密鍵を格納できます。

秘密鍵はOracleの識別子規則に従った文字列である必要があります。既存のキーストアでクライアントのシークレットを追加、更新または削除できます。この項では、Oracle GoldenGateのExtract(抽出)プロセスでクラシック・キャプチャ・モードを使用して、透過的データ暗号化によって暗号化されたデータを取得する方法について説明します。

Extractがクラシック・キャプチャ・モードの場合、TDEをサポートするには次の鍵の交換が必要です。

- Extractプロセスのクラシック・キャプチャ・モードでのTDEによるOracle GoldenGateのサポートでは、Oracle DatabaseとExtractプロセスでシークレットを共有して、交換される機密情報を暗号化する必要があります。共有シークレットは、Oracle DatabaseおよびOracle GoldenGateドメインに安全に格納されます。共有シークレットは、ソフトウェア・キーストアまたはHSMにデータベース・シークレットとして格納されます。

- 復号化鍵は、Oracle DatabaseおよびOracle GoldenGateドメインに安全に格納されている、共有シークレットとして知られているパスワードです。共有シークレットを所有している当事者のみが、表キーおよびREDOログ・キーを復号化できます。

共有シークレットの構成後、共有シークレットを使用してOracle GoldenGate Extractによってデータが復号化されます。Oracle GoldenGate Extractでは、TDEマスター暗号化鍵自体は扱われず、キーストア・パスワードも認識しません。TDEマスター暗号化鍵およびパスワードは、Oracle Database構成内に保持されます。

Oracle GoldenGate Extractでは、遷移時にOracle GoldenGateによって保持されるOracle GoldenGate証跡ファイルに、復号化されたデータが書き込まれるのみです。サイトのオペレーティング・システムの標準セキュリティ・プロトコルと、Oracle GoldenGate AES暗号化オプションを使用して、このファイルを保護できます。Oracle GoldenGateでは、暗号化データは破棄ファイル(DISCARDFILEパラメータで指定)には書き込まれません。ENCRYPTEDという語は、使用中のすべての破棄ファイルに書き込まれます。

Oracle GoldenGateでは、暗号化データの処理時にキーストアが開いている必要はありません。TDE操作に対するOracle GoldenGate機能のパフォーマンス上の影響はありません。

Oracle GoldenGate Extractのクラシック・キャプチャ・モードのTDE要件

Oracle GoldenGate Extractで透過的データ暗号化の取得をサポートするための要件を満たしていることを確認します。

要件は次のとおりです。

- 高いセキュリティ基準を維持するには、Oracle GoldenGateのExtractプロセスがOracleユーザー(Oracle Databaseを実行するユーザー)の一部として実行されるようにします。これにより、鍵はOracleユーザーと同じ権限によってメモリー内で保護されます。

- Oracle GoldenGateのExtractプロセスを、Oracle Databaseインストールと同じコンピュータで実行します。

Oracle GoldenGate用のTDEキーストア・サポートの構成

Oracle GoldenGateのために透過的データ暗号化キーストアのサポートを構成するには、キーストアの共有シークレットを決定し、Oracleデータベースを構成し、共有シークレットをキーストアに格納し、Extractプロセスに共有シークレットを設定します。

内容は次のとおりです。

- 手順1: キーストアの共有シークレットを決定する

- 手順2: TDEによるOracle GoldenGateのサポートのためにOracle Databaseを構成する

- 手順3: TDE GoldenGate共有シークレットをキーストアに格納する

- 手順4: TDE Oracle GoldenGate共有シークレットをExtractプロセスに設定する

手順1: キーストアの共有シークレットを決定する

キーストアの共有シークレットはパスワードです。

- Oracle Databaseのパスワード基準を満たす(または超える)共有シークレットを決定します。

このパスワードは、Oracle GoldenGate Extractと連携するように透過的データ暗号化を構成する作業を担当する、信頼できる管理者以外のユーザーと共有しないでください。

関連項目:

安全なパスワードの作成に関するガイドラインの詳細は、Oracle Databaseセキュリティ・ガイドを参照してください。

手順2: TDEによるOracle GoldenGateのサポートのためにOracle Databaseを構成する

DBMS_INTERNAL_CLKM PL/SQLパッケージを使用して、Oracle GoldenGateのためにTDEのサポートを構成できます。

1. SYSDBA管理権限を持つユーザーSYSとしてデータベース・インスタンスにログインします。
次に例を示します

sqlplus sys as sysdba
Enter password: password
Connected.

2. マルチテナント環境で、適切なPDBに接続します。
例:

CONNECT SYS@hrpdb AS SYSDBA
Enter password: password

利用可能なPDBを検索するには、DBA_PDBSデータ・ディクショナリ・ビューを問い合せます。現在のPDBを確認するには、show con_nameコマンドを実行します。

3. Oracle Databaseに付属のDBMS_INTERNAL_CLKM PL/SQLパッケージをロードします。
例:

@?/app/oracle/product/12.1/rdbms/admin/prvtclkm.plb

prvtclkm.plbファイルでも、Oracle GoldenGateによってOracle Databaseから暗号化データを抽出できます。

4. DBMS_INTERNAL_CLKM PL/SQLパッケージに対するEXECUTE権限をOracle GoldenGate Extractデータベース・ユーザーに付与します。
例:

GRANT EXECUTE ON DBMS_INTERNAL_CLKM TO psmith;

この手順によって、Oracle DatabaseとOracle GoldenGate Extractで情報を交換できます。

5. SQL*Plusを終了します。

手順3: TDE GoldenGate共有シークレットをキーストアに格納する

ADMINISTER KEY MANAGEMENT文によって、TDE GoldenGate共有シークレットをキーストアに格納できます。

1. 次のトピックに基づいて、TDEソフトウェア・キーストアまたはハードウェア・キーストアが構成済であることを確認します。

- ソフトウェア・キーストアの構成

- ハードウェア・キーストアの構成

2. Oracle GoldenGate-透過的データ暗号化鍵をキーストアに設定します。
構文は次のとおりです。

ADMINISTER KEY MANAGEMENT ADD|UPDATE|DELETE SECRET 'secret'
FOR CLIENT 'secret_identifier' [USING TAG 'tag']
IDENTIFIED BY keystore_password [WITH BACKUP [USING 'backup_identifier']];

ここでは次のように指定します。

- secretは、格納、更新、または削除するクライアントの秘密鍵です。この設定は、一重引用符('  ')で囲みます。

- secret_identifierは、秘密鍵の識別に使用される英数字の文字列です。secret_identifierにはデフォルト値はありません。この設定は、一重引用符(' ')で囲みます。

- tagは、格納する秘密鍵についてのオプションのユーザー定義の説明です。tagは、ADDおよびUPDATE操作と一緒に使用できます。この設定は一重引用符(' ')で囲みます。このタグは、V$CLIENT_SECRETSビューのSECRET_TAG列に表示されます。タグの詳細は、「レポート用のTDEマスター暗号化鍵のカスタム属性の作成」を参照してください。

- keystore_passwordは、構成されているキーストアのパスワードです。

- WITH BACKUPは、ADD、UPDATEまたはDELETE操作の前にキーストアがバックアップされていない場合は必須です。backup_identifierは、バックアップについてのオプションのユーザー定義の説明です。backup_identifierは、一重引用符(' ')で囲みます。

次の例は、秘密鍵をキーストアに追加して、キーストアと同じディレクトリにバックアップを作成します。

ADMINISTER KEY MANAGEMENT ADD SECRET 'some_secret'
FOR CLIENT 'ORACLE_GG' USING TAG 'GoldenGate Secret'
IDENTIFIED BY password WITH BACKUP USING 'GG backup';

3. 作成したエントリを確認します。
例:

SELECT CLIENT, SECRET_TAG FROM V$CLIENT_SECRETS WHERE CLIENT = 'ORACLEGG';

CLIENT   SECRET_TAG
-------- ------------------------------------------
ORACLEGG some_secret

4. ログ・ファイルを切り換えます。

CONNECT / AS SYSDBA

ALTER SYSTEM SWITCH LOGFILE;

ログ・ファイルの切替えの詳細は、『Oracle Database管理者ガイド』を参照してください。

関連項目:

Oracle Real Application Clusters (RAC)環境でこの手順の使用に問題が発生した場合は、透過的データ暗号化とOracle Real Application Clustersとの連携を参照してください。

手順4: TDE Oracle GoldenGate共有シークレットをExtractプロセスに設定する

GoldenGateソフトウェア・コマンド・インタフェース(GGSCI)ユーティリティによって、TDE Oracle GoldenGate共有シークレットをExtractプロセスに設定します。

1. GGSCIユーティリティを起動します。
例:

ggsci

2. GGSCIユーティリティでENCRYPT PASSWORDコマンドを実行し、共有シークレットを暗号化してOracle GoldenGate Extractパラメータ・ファイル内で不明瞭化します。

ENCRYPT PASSWORD shared_secret algorithm ENCRYPTKEY keyname

ここでは次のように指定します。

- shared_secretは、手順1: キーストアの共有シークレットを決定するで作成したクリアテキストの共有シークレットです。この設定では大文字と小文字が区別されます。

- algorithmは、AES暗号化を指定する次のいずれかの値です。

- AES128

- AES192

- AES256

- keynameは、ENCKEYS参照ファイルの暗号化鍵の論理名です。Oracle GoldenGateでは、この名前を使用して、ENCKEYSファイル内で実際の鍵が参照されます。

例:

ENCRYPT PASSWORD password AES256 ENCRYPTKEY mykey1

3. Oracle GoldenGate Extractパラメータ・ファイルで、DECRYPTPASSWORDオプションを指定してDBOPTIONSパラメータを設定します。
入力として、暗号化共有シークレットと、Oracle GoldenGateによって生成されたか、またはユーザーが定義した復号化鍵を指定します。

DBOPTIONS DECRYPTPASSWORD shared_secret algorithm ENCRYPTKEY keyname

ここでは次のように指定します。

- shared_secretは、手順1: キーストアの共有シークレットを決定するで作成したクリアテキストの共有シークレットです。この設定では大文字と小文字が区別されます。

- algorithmは、AES暗号化を指定する次のいずれかの値です。

- AES128

- AES192

- AES256

- keynameは、ENCKEYS参照ファイルの暗号化鍵の論理名です。
例:

DBOPTIONS DECRYPTPASSWORD AACAAAAAAAAAAAIALCKDZIRHOJBHOJUH AES256 ENCRYPTKEY mykey1

5 透過的データ暗号化を使用する場合の一般的な考慮事項

透過的データ暗号化を使用するときは、セキュリティ、パフォーマンス、記憶域のオーバーヘッドなどの要因を考慮する必要があります。

内容は次のとおりです。

- 暗号化データの圧縮とデータ重複除外

- 透過的データ暗号化のセキュリティに関する考慮事項

- 透過的データ暗号化のパフォーマンスと記憶域のオーバーヘッド

- 透過的データ暗号化と組み合せて使用するためのアプリケーションの変更

- ALTER SYSTEMおよびorapkiとADMINISTER KEY MANAGEMENTとの対応

- PKI暗号化での透過的データ暗号化の使用

暗号化データの圧縮とデータ重複除外

表領域の暗号化を使用して、Oracle Databaseでは表領域の暗号化前に表と索引を圧縮します。

これにより、保存の暗号化のセキュリティを確保しながら、圧縮による、容量とパフォーマンス上のメリットを最大限に得ることができます。CREATE TABLESPACE SQL文には、COMPRESSとENCRYPT句の両方が含まれます。

列暗号化を使用すると、Oracle Databaseでは列を暗号化した後でデータを圧縮します。これは、圧縮には、暗号化された列で最小限の有効性があることを意味します。注目すべき例外が1つあります。列がSecureFiles LOBであり、暗号化がSecureFiles LOB暗号化を使用して実装され、圧縮(重複除外の場合もあり)がSecureFiles LOB圧縮および重複除外を使用して実装されている場合、圧縮は暗号化の前に実行されます。表領域の暗号化のCREATE TABLESPACE文と同様に、COMPRESSとENCRYPT句の両方が含まれます。

関連項目:

- 拡張圧縮オプションの詳細は、Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイドを参照してください。

- SecureFiles LOB記憶域の詳細は、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』を参照

- SecureFiles圧縮の詳細は、Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイドを参照してください。

透過的データ暗号化のセキュリティに関する考慮事項

TDEポリシーを作成する場合には、Oracle Databaseのすべての機能のときと同様に、セキュリティを考慮する必要があります。

内容は次のとおりです。

- 透過的データ暗号化のセキュリティに関する一般的なアドバイス

- 透過的データ暗号化の列暗号化固有のアドバイス

- 平文の断片のセキュリティの管理

透過的データ暗号化のセキュリティに関する一般的なアドバイス

透過的データ暗号化(TDE)を使用する場合のセキュリティに関する考慮事項は、全システム・セキュリティの広範囲に適用されます。

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

- データベースのデータの機密度、必要な保護、および対処するリスクのレベルを識別します。たとえば、厳密な保護を必要とする機密度の高いデータは、AES256アルゴリズムで暗号化できます。それほど機密度の高くないデータベースは、パフォーマンス上の利点を得るために、no saltまたはnomacオプションを使用して保護できます。

- データおよびキーストアの保護にとって許容できるコストと利点を評価します。鍵の保護によって、使用するキーストアのタイプ(自動ログイン・ソフトウェア・キーストア、パスワードベースのソフトウェア・キーストアまたはハードウェア・キーストア)が決定されます。

- TDEとデータベースに個別のセキュリティ管理者を割り当てることを検討します。

- TDEに個別の排他的キーストアを割り当てることを検討します。

- 暗号化データのための保護されたバックアップ手順を実施します。

透過的データ暗号化の列暗号化固有のアドバイス

セキュリティに関するその他の考慮事項は、TDEを使用している場合の通常のデータベース操作およびネットワーク操作に適用されます。

暗号化列のデータは、データ・ファイル、UNDOログ、REDOログおよびシステム・グローバル領域(SGA)のバッファ・キャッシュ内では暗号化されたままになります。一方、データは式の評価時に復号化されるため、ディスク上のスワップ・ファイルには復号化後のデータを表示できます。権限のあるオペレーティング・システム・ユーザーは、このデータを表示できる可能性があります。

TDEを使用して暗号化された列値は、暗号化された形式でデータ・ファイルに格納されます。ただし、これらのデータ・ファイルには、表に対する過去のデータ操作で残されたゴースト・コピーと呼ばれるプレーン・テキストの断片が含まれている場合があります。これは、オペレーティング・システムによってファイルが削除された後に、ディスク上にデータが残存している場合に類似しています。

平文の断片のセキュリティの管理

一定期間存在する可能性のある古い平文の断片は削除する必要があります。

古いプレーン・テキストの断片は、それらの値を含んでいるブロックがデータベースによって上書きされるまで、しばらく存在し続ける可能性があります。権限のあるオペレーティング・システム・ユーザーがデータベースのアクセス制御をバイパスした場合、表領域を保持するデータ・ファイル内のこれらの値に直接アクセスされる可能性があります。

このリスクを最小限に抑えるには:

1. 新しいデータ・ファイルに新しい表領域を作成します。
CREATE TABLESPACE文を使用して、この表領域を作成できます。

2. 暗号化列を含む表を新しい表領域に移動します。ALTER TABLE.....MOVE文を使用できます。
元の表領域のすべてのオブジェクトについて、この手順を繰り返します。

3. 元の表領域を削除します。
DROP TABLESPACE tablespace INCLUDING CONTENTS KEEP DATAFILES文を使用できます。データ・ファイルは、プラットフォーム固有のユーティリティを使用して安全に削除することをお薦めします。

4. 古いデータ・ファイルを安全に削除するには、プラットフォームおよびファイル・システムに固有のユーティリティを使用してください。このようなユーティリティの例には、shred (Linuxの場合)やsdelete (Windowsの場合)などがあります。

透過的データ暗号化のパフォーマンスと記憶域のオーバーヘッド

透過的データ暗号化のパフォーマンスは変わる場合があります。記憶域にはオーバーヘッドはありませんが、TDE列暗号化に関係する記憶域のオーバーヘッドは多少あります。

内容は次のとおりです。

- 透過的データ暗号化のパフォーマンスのオーバーヘッド

- 透過的データ暗号化の記憶域のオーバーヘッド

関連項目:

透過的データ暗号化に関するパフォーマンスの質問

透過的データ暗号化のパフォーマンスのオーバーヘッド

透過的データ暗号化の表領域暗号化には、パフォーマンスのオーバーヘッドが多少伴います。

アプリケーションに対する実際のパフォーマンスの影響は異なることがあります。TDE列暗号化がパフォーマンスに影響を与えるのは、暗号化列に対してデータの取得または挿入が行われた場合のみです。暗号化されていない列に関係する操作の場合は、これらの列が暗号化列を含む表内にあっても、パフォーマンスが低下することはありません。暗号化列のデータへのアクセスでは多少のパフォーマンス・オーバーヘッドが伴いますが、発生する正確なオーバーヘッドは異なる場合があります。

全体的なパフォーマンスのオーバーヘッドは、暗号化列の数とそのアクセス頻度によって異なります。暗号化するのが最も妥当な列は、最高機密のデータを含む列です。

既存の表で暗号化を有効化すると、表の特性を変更する他のALTER TABLE操作と同様に、完全な表更新が行われます。大規模な既存の表で暗号化を有効化する前に、データベース・サーバーに与えるパフォーマンスおよびREDOログの潜在的な影響を考慮する必要があります。

表に対する書込み操作は、暗号化の有効化中、TDE表キーのキー更新中または暗号化アルゴリズムの変更中は一時的に実行できなくなる場合があります。このような処理が実行されている場合は、表のオンライン再定義を使用して、表への書込み操作が可能かどうかを確認できます。

大規模な表に対してTDE列暗号化を有効化している場合は、操作に対応できるよう、REDOログのサイズを大きくする必要があることがあります。

索引付けされた列の暗号化には、索引のない列の暗号化よりも多くの時間を要します。索引が作成された列を暗号化する必要がある場合は、索引を削除してから列をNO SALTで暗号化し、その後で索引を再度作成できます。

暗号化列に索引を付ける場合、索引は暗号化された値に対して作成されます。暗号化列の値を問い合せると、SQL問合せで使用される値がOracle Databaseで透過的に暗号化されます。その後、暗号化された値を使用して、索引の参照が実行されます。

注意:

索引付けされた暗号化列のレンジ・スキャンを実行する必要がある場合は、TDE列暗号化のかわりにTDE表領域暗号化を使用します。

関連項目:

- 外部表への暗号化列の作成

- オンラインでの表の再定義の詳細は、Oracle Database管理者ガイドを参照してください。

透過的データ暗号化の記憶域のオーバーヘッド

TDE表領域暗号化には記憶域のオーバーヘッドはありませんが、TDE列暗号化には多少の記憶域のオーバーヘッドが伴います。

暗号化列のデータには、プレーン・テキスト・データより多くの記憶域が必要です。さらに、TDEでは、暗号化された値が16バイトの倍数に拡張されます。これは、クレジット・カード番号の格納に9バイトが必要な場合、クレジット・カード番号を暗号化して格納するには、さらに7バイトが必要になることを意味します。

暗号化された各値は、20バイトの整合性チェックにも関連付けられます。これは、NOMACパラメータを使用して列を暗号化した場合には当てはまりません。saltを使用してデータを暗号化した場合は、暗号化された各値を格納するために、さらに16バイトの記憶域が必要になります。

暗号化された各値の記憶域の最大オーバーヘッドは1から52バイトです。

関連項目:

外部表への暗号化列の作成

透過的データ暗号化と組み合せて使用するためのアプリケーションの変更

アプリケーションで透過的データ暗号化を使用するよう、変更することができます。

1. TDE用のソフトウェアまたはハードウェア・キーストアを構成し、マスター暗号化鍵を設定します。
詳細は、次の各項を参照してください。

- ソフトウェア・キーストアの構成

- ハードウェア・キーストアの構成

2. V$ENCRYPTION_KEYSビューのKEY_ID列を問い合せることで、マスター暗号化鍵が作成されていることを確認します。

3. 透過的データ暗号化による保護が必要な機密列(クレジット・カード・データが含まれるものなど)を特定します。

4. TDE列暗号化またはTDE表領域暗号化のどちらを使用するか決定します。
詳細は、次の各項を参照してください。

- 透過的データ暗号化列暗号化の動作

- 透過的データ暗号化表領域暗号化の動作

5. キーストアを開きます。
詳細は、次の各項を参照してください。

- 手順3: ソフトウェア・キーストアを開く

- 手順3: ハードウェア・キーストアを開く

6. 列または表領域を暗号化します。
詳細は、次の各項を参照してください。

- 表の列の暗号化

- 表領域の暗号化

ALTER SYSTEMおよびorapkiとADMINISTER KEY MANAGEMENTとの対応

ALTER SYSTEM文の多くの句は、ADMINISTER KEY MANAGEMENT文に対応しています。

表5-1では、透過的データ暗号化でのALTER SYSTEM文およびorapkiユーティリティの使用と、以前のリリースのADMINISTER KEY MANAGEMENT文を比較しています。

表5-1 ALTER SYSTEMおよびorapkiとADMINISTER KEY MANAGEMENTとの対応

動作

ALTER SYSTEMまたはorapki

ADMINISTER KEY MANAGEMENT

キーストアの作成

ソフトウェア・キーストアの場合(以前のリリースではウォレットと呼ばれていました) :

ALTER SYSTEM SET ENCRYPTION KEY
["certificate_ID"] IDENTIFIED
BY keystore_password;

ハードウェア・キーストアの場合、ハードウェア・セキュリティ・モジュールを構成した後で、キーストアを利用できるようになります。

ソフトウェア・キーストアの場合:

ADMINISTER KEY MANAGEMENT CREATE KEYSTORE
'keystore_location'
IDENTIFIED BY software_keystore_password

ハードウェア・キーストアの場合、ハードウェア・セキュリティ・モジュールを構成した後で、キーストアを利用できるようになります。

自動ログイン・キーストアの作成

orapki wallet create -wallet
wallet_location
-auto_login [-pwd password]

ソフトウェア・キーストアの場合:

ADMINISTER KEY MANAGEMENT CREATE [LOCAL]
AUTO_LOGIN KEYSTORE FROM KEYSTORE
'keystore_location'
IDENTIFIED BY software_keystore_password;

このタイプのキーストアは、ソフトウェア・キーストアのみに適用されます。

キーストアを開く

ALTER SYSTEM SET ENCRYPTION
WALLET OPEN IDENTIFIED BY
password;

ADMINISTER KEY MANAGEMENT SET KEYSTORE
OPEN IDENTIFIED BY keystore_password
[CONTAINER = ALL | CURRENT];

キーストアを閉じる

ALTER SYSTEM SET ENCRYPTION
WALLET CLOSE IDENTIFIED BY
password;

ソフトウェア・キーストアとハードウェア・キーストアの場合:

ADMINISTER KEY MANAGEMENT SET KEYSTORE
CLOSE IDENTIFIED BY keystore_password
[CONTAINER = ALL | CURRENT];

ハードウェア・キーストアからソフトウェア・キーストアへの移行

使用不可

ADMINISTER KEY MANAGEMENT SET ENCRYPTION
KEY IDENTIFIED BY
software_keystore_password
REVERSE MIGRATE USING "user_id:password"
[WITH BACKUP [USING 'backup_identifier']];

ソフトウェア・キーストアからハードウェア・キーストアへの移行

ALTER SYSTEM SET ENCRYPTION KEY
IDENTIFIED BY
"user_id:password" MIGRATE
USING wallet_password;

ADMINISTER KEY MANAGEMENT SET ENCRYPTION
KEY IDENTIFIED BY "user_id:password"
MIGRATE USING software_keystore_password;

キーストア・パスワードの変更

orapki wallet change_pwd
-wallet wallet_location
[-oldpwd password ]
[-newpwd password]

パスワードベースのソフトウェア・キーストアの場合:

ADMINISTER KEY MANAGEMENT ALTER KEYSTORE
PASSWORD IDENTIFIED BY
software_keystore_old_password
SET software_keystore_new_password
[WITH BACKUP [USING 'backup_identifier']];

ハードウェア・キーストアの場合、キーストアを閉じてハードウェア・セキュリティ・モジュール・インタフェースで変更してから、再びキーストアを開きます。

パスワードベースのソフトウェア・キーストアのバックアップ

使用不可

ADMINISTER KEY MANAGEMENT BACKUP KEYSTORE
[USING 'backup_identifier'] IDENTIFIED BY
software_keystore_password
[TO 'keystore_location'];

2つのソフトウェア・キーストアから3つ目の新しいキーストアへのマージ

使用不可

ADMINISTER KEY MANAGEMENT MERGE KEYSTORE
'keystore1_location' [IDENTIFIED BY
software_keystore1_password]
AND KEYSTORE 'keystore2_location'
[IDENTIFIED BY software_keystore2_password]
INTO NEW KEYSTORE 'keystore3_location'
IDENTIFIED BY software_keystore3_password;

1つのソフトウェア・キーストアから別の既存のキーストアへのマージ

使用不可

ADMINISTER KEY MANAGEMENT MERGE KEYSTORE
'keystore1_location' [IDENTIFIED BY
software_keystore1_password]
INTO EXISTNG KEYSTORE 'keystore2_location'
IDENTIFIED BY software_keystore2_password
[WITH BACKUP [USING 'backup_identifier']];

マスター暗号化鍵の設定またはローテーション

ソフトウェア・ウォレットの場合:

ALTER SYSTEM SET ENCRYPTION KEY
["certificate_ID"] IDENTIFIED
BY keystore_password;

ハードウェア・セキュリティ・モジュールの場合:

ALTER SYSTEM SET ENCRYPTION KEY
IDENTIFIED BY "user_id:password"

注意: ALTER SYSTEM SET ENCRYPTION KEY文は、暗号化鍵をローテーションした後、V$ENCRYPTION_KEYS動的ビューを更新しません。

ADMINISTER KEY MANAGEMENT
SET ENCRYPTION KEY [USING TAG 'tag']
IDENTIFIED BY keystore_password
WITH BACKUP [USING 'backup_identifier']
[CONTAINER = ALL | CURRENT];

暗号化鍵をローテーションした後、V$ENCRYPTION_KEYS動的ビューが更新されます。

後で使用するマスター暗号化鍵の作成

使用不可

ADMINISTER KEY MANAGEMENT CREATE KEY
[USING TAG 'tag']
IDENTIFIED BY keystore_password
[WITH BACKUP [USING 'backup_identifier']]
[CONTAINER = (ALL|CURRENT)];

マスター暗号化鍵のアクティブ化

使用不可

ADMINISTER KEY MANAGEMENT USE KEY
'key_identifier' [USING TAG 'tag']
IDENTIFIED BY keystore_password
[WITH BACKUP [USING 'backup_identifier']];

マスター暗号化鍵のカスタム・タグの作成

使用不可

ADMINISTER KEY MANAGEMENT SET TAG 'tag'
FOR 'master_key_identifier'
IDENTIFIED BY keystore_password
[WITH BACKUP [USING 'backup_identifier']];

マスター暗号化鍵のエクスポート

使用不可

ADMINISTER KEY MANAGEMENT
EXPORT [ENCRYPTION] KEYS
WITH SECRET "export_secret"
TO 'file_path'
IDENTIFIED BY software_keystore_password
[WITH IDENTIFIER IN
'key_id1', 'key_id2', 'key_idn' |
(SQL_query)]

マスター暗号化鍵のインポート

使用不可

ADMINISTER KEY MANAGEMENT
IMPORT [ENCRYPTION] KEYS
WITH SECRET "import_secret" |
FROM 'file_name'
IDENTIFIED BY software_keystore_password
[WITH BACKUP [USING 'backup_identifier']];

キーストアへのOracle Databaseのシークレットの格納

使用不可

ソフトウェア・キーストアの場合:

ADMINISTER KEY MANAGEMENT
ADD SECRET|UPDATE SECRET|DELETE SECRET
"secret" FOR CLIENT 'client_identifier'
[USING TAG'tag']
IDENTIFIED BY keystore_password
[WITH BACKUP [USING 'backup_identifier'];

ハードウェア・キーストアの場合:

ADMINISTER KEY MANAGEMENT
ADD SECRET|UPDATE SECRET|DELETE SECRET
"secret" FOR CLIENT 'client_identifier'
[USING TAG 'tag']
IDENTIFIED BY "user_id:password"
[WITH BACKUP [USING 'backup_identifier'];

PKI暗号化での透過的データ暗号化の使用

PKIによる暗号化は非推奨となっていますが、これをまだ使用している場合は、考慮する必要のある問題がいくつかあります。

内容は次のとおりです。

- ソフトウェア・マスター暗号化鍵とPKI鍵ペアとの併用

- PKI暗号化とTDEの表領域およびハードウェア・キーストア

- PKI鍵ペアのバックアップおよびリカバリ

注意:

PKI暗号化と透過的データ暗号化を組み合せた使用は非推奨です。透過的データ暗号化を構成するには、ADMINISTER KEY MANAGEMENT SQL文を使用します。

ソフトウェア・マスター暗号化鍵とPKI鍵ペアとの併用

マスター暗号化鍵は、暗号化用に指定されたPKI証明書の既存の鍵ペアにすることができます。

次の点に注意してください。

- 組織内にすでにPKIをデプロイしている場合は、鍵供託およびリカバリなどのPKIサービスを活用できます。ただし、現在のPKIアルゴリズムを使用する暗号化では、対称鍵暗号化よりもはるかに多くのシステム・リソースが必要になります。マスター暗号化鍵としてPKI鍵ペアを使用すると、データベース内の暗号化列にアクセスする場合にパフォーマンスが大幅に低下する可能性があります。

- PKIベースの鍵の場合、証明書の失効を強制すると、暗号化されたデータベース内の情報すべてにアクセスできなくなる可能性があるため、証明書失効リストは強制されません。ただし、同じ証明書を使用してマスター暗号化鍵を再び作成することはできません。

PKI暗号化とTDEの表領域およびハードウェア・キーストア

PKI暗号化は、2つの鍵(公開鍵と秘密鍵)を使用してデータを暗号化する暗号システムです。

PKIベースの暗号化をTDE表領域暗号化やハードウェア・キーストアと一緒に使用することはできません。

PKI鍵ペアのバックアップおよびリカバリ

ソフトウェア・キーストアの場合、透過的データ暗号化では、列暗号化のためにマスター暗号化鍵としてPKI非対称鍵ペアを使用できます。

これにより、データベースでは、主要な認証局ベンダーの既存の鍵のバックアップ、供託およびリカバリ機能を使用できます。

現在の鍵供託またはリカバリ・システムでは、秘密鍵のバージョンまたは秘密鍵のリカバリに役立つ情報は、通常、鍵のリカバリ機能を提供する認証局に保管されます。秘密鍵が失われた場合、認証局に連絡し、鍵のリカバリ・プロセスを開始することで、元の鍵および証明書をリカバリできます。

通常、鍵のリカバリ・プロセスは自動化されており、ユーザーは認証局に対して特定の認証資格証明を提示する必要があります。リカバリ対象となる鍵およびその関連証明書が、キーストアにインポート可能なPKCS#12ファイルである必要があることを除き、TDEでは、鍵のリカバリ・プロセスに制限を設けていません。この要件は、主要な認証局の鍵のリカバリ・メカニズムと同じです。

元の証明書および秘密鍵を含むPKCS#12ファイルの取得後は、以前のキーストアと同じ場所に空のキーストアを作成する必要があります。その後、同じユーティリティを使用してPKCS#12ファイルを新しいキーストアにインポートできます。キーストアを保護するために強力なパスワードを選択する必要があります。

ADMINISTER KEY MANAGEMENT文を使用してキーストアを作成して正しい暗号化鍵をインポートした後、データベースにログオンして、SQLプロンプトで次のALTER SYSTEM文を実行し、リカバリ・プロセスを完了します。

ALTER SYSTEM SET ENCRYPTION KEY "cert_id" IDENTIFIED BY keystore_password;

ここでは次のように指定します。

- cert_idは、マスター暗号化鍵として使用する証明書の証明書IDです。

- keystore_passwordは、作成するパスワードです。

注意:

ALTER SYSTEM文を使用して、PKI鍵ペア専用の暗号化鍵を再生成する必要があります。この制約はPKI以外の暗号化鍵には適用されません。

6  他の Oracle機能で透過的データ暗号化を使用

Oracle Data Encryptionは、Oracle Data GuardやOracle Real Application ClustersなどのOracle機能とともに使用できます。

内容は次のとおりです。

- 透過的データ暗号化とエクスポートおよびインポート操作の連携

- 透過的データ暗号化とOracle Data Guardとの連携

- 透過的データ暗号化とOracle Real Application Clustersとの連携

- 透過的データ暗号化とSecureFilesとの連携

- 透過的データ暗号化のマルチテナント環境での使用

- 透過的データ暗号化とOracle Call Interfaceとの連携

- 透過的データ暗号化とエディションとの連携

- マルチデータベース環境で機能するように透過的データ暗号化を構成

透過的データ暗号化とエクスポートおよびインポート操作との連携

Oracle Data Pumpを使用して、暗号化された列を含む表をエクスポートおよびインポートしたり、ダンプ・セット全体を暗号化できます。

内容は次のとおりです。

- 暗号化データされたデータのエクスポートおよびインポートについて

- 暗号化された列のある表のエクスポートおよびインポート

- Oracle Data Pumpを使用してダンプ・セット全体を暗号化

暗号化データされたデータのエクスポートおよびインポートについて

暗号化列を持つ表のエクスポートとインポートには、Oracle Data Pumpを使用できます。

ソフトウェアおよびハードウェアの両方のキーストアに関して、暗号化された列を含む表をエクスポートする必要がある際に次の点が重要です。

- 転送中も機密データが解読されないように保つ必要があります。

- 権限のあるユーザーは、宛先にインポートされたデータを復号化できる必要があります。

Oracle Data Pumpを使用して暗号化列を含む表をエクスポートおよびインポートする場合、ENCRYPTIONパラメータを使用してダンプ・ファイル・セットのデータを暗号化できるようにします。ENCRYPTIONパラメータには、次の値を指定できます。

- ENCRYPTED_COLUMNS_ONLY: 暗号化列が暗号化された形式でダンプ・ファイル・セットに書き込まれます。

- DATA_ONLY: すべてのデータが暗号化された形式でダンプ・ファイル・セットに書き込まれます。

- METADATA_ONLY: すべてのメタデータがダンプ・ファイル・セットに暗号化された形式で書き込まれます。

- ALL: すべてのデータとメタデータが暗号化された形式でダンプ・ファイル・セットに書き込まれます。

- NONE: ダンプ・ファイル・セットに対して暗号化は使用されません。

暗号化された列のある表のエクスポートおよびインポート

ENCRYPTION=ENCRYPTED_COLUMNS_ONLY設定を使用して、暗号化された列のある表をエクスポートおよびインポートできます。

1. 暗号化列を含む表のエクスポートを試行する前に、キーストアが開いていることを確認します。
マルチテナント環境では、プラガブル・データベース(PDB)内のデータをエクスポートする場合、ウォレットがPDB内でオープン状態であることを確認します。rootにエクスポートする場合、ウォレットがroot内でオープン状態であることを確認します。

キーストアが開いているかどうかを確認するには、V$ENCRYPTION_WALLETビューのSTATUS列を問い合せます。キーストアを開く必要がある場合は、次のSQL文を実行します。

ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY software_keystore_password [CONTAINER = ALL | CURRENT];

software_keystore_password設定は、キーストアのパスワードです。キーストアが開いている必要があるのは、暗号化列の復号化にはTDE表キーを使用する必要があり、そのためにはTDEマスター暗号化鍵へのアクセスが必要なためです。列は、エクスポートされる前にパスワードを使用して再暗号化されます。

2. エクスポート・ダンプ・ファイル・セットの列データを暗号化する際に使用するパスワードを、ENCRYPTION_PASSWORDパラメータを使用して指定し、EXPDPコマンドを実行します。
次に、employee_data表をエクスポートする例を示します。ENCRYPTION_PWD_PROMPT = YES設定によって、対話式でパスワードを求めるプロンプトの表示が可能となり、これは推奨されるセキュリティ上の措置となっています。

expdp hr TABLES=employee_data DIRECTORY=dpump_dir
DUMPFILE=dpcd2be1.dmp ENCRYPTION=ENCRYPTED_COLUMNS_ONLY
ENCRYPTION_PWD_PROMPT = YES

Password: password_for_hr

3. エクスポートされたデータをターゲット・データベースにインポートするには、ENCRYPTION_PASSWORDパラメータによって設定されエクスポート操作に使用したものと同じパスワードを確実に指定してください。
このパスワードは、データの復号化に使用されます。データは、ターゲット・データベースに生成された新しいTDE表キーを使用して再暗号化されます。ターゲット・データベースがTDEマスター暗号化鍵にアクセスするためには、キーストアが開いている必要があります。次に、employee_data表をインポートする例を示します。

impdp hr TABLES=employee_data DIRECTORY=dpump_dir
DUMPFILE=dpcd2be1.dmp
ENCRYPTION_PWD_PROMPT = YES

Password: password_for_hr

Oracle Data Pumpを使用してダンプ・セット全体を暗号化

Oracle Data Pumpによって、透過的データ暗号化列のみではなく、ダンプ・セット全体を暗号化できます。

インポートでは、パスワードまたはキーストアTDEマスター暗号化鍵のいずれかを使用してデータを復号化できます。パスワードを指定しなかった場合、データの復号化にはキーストアのTDEマスター暗号化鍵が使用されます。ターゲット・データベースにおいて、キーストアが存在して開いている必要があります。この開いているキーストアは、ターゲット・データベースで列暗号化データを再暗号化する際にも必要です。

ENCRYPTION_MODE=TRANSPARENT設定を使用すると、キーストアに格納されているTDEマスター暗号化鍵を使用してダンプ・ファイル・セットを透過的に暗号化できます。この場合、パスワードは不要です。キーストアはターゲット・データベースに存在して開いている必要があり、インポート操作時に列暗号化メタデータを復号化できるようにソース・データベースのTDEマスター暗号化鍵が含まれている必要があります。

この開いているキーストアは、ターゲット・データベースで列暗号化メタデータを再暗号化する際にも必要です。キーストアがすでにターゲット・データベースに存在している場合は、ソース・データベースのキーストアから現在のTDEマスター暗号化鍵をエクスポートして、ターゲット・データベースのキーストアに対してこれをインポートできます。

- ENCRYPTION_MODEパラメータを使用して、暗号化モードを指定します。ENCRYPTION_MODE=DUALによって、キーストアに格納されているTDEマスター暗号化鍵と指定したパスワードを使用してダンプ・セットが暗号化されます。

たとえば、二重暗号化モードを使用して、暗号化されたデータをエクスポートする場合、次のようにします。

expdp hr DIRECTORY=dpump_dir1 DUMPFILE=hr_enc.dmp
ENCRYPTION=all ENCRYPTION_PASSWORD=encryption_password
ENCRYPTION_ALGORITHM=AES256 ENCRYPTION_MODE=dual

Password: password_for_hr

関連項目:

- TDEマスター暗号化鍵のエクスポートおよびインポート

- Oracle Data Pumpおよびこれに関連する暗号化パラメータの使用に関する詳細は、『Oracle Databaseユーティリティ』を参照してください。

- 外部表への暗号化列の作成

透過的データ暗号化とOracle Data Guardとの連携

ソフトウェアおよびハードウェアの両方のキーストアに関して、Oracle Data Guardは透過的データ暗号化(TDE)をサポートしています。

プライマリ・データベースでTDEを使用する場合、Data Guard構成の各スタンバイ・データベースには、プライマリ・データベースからの暗号化キーストアのコピーが必要です。プライマリ・データベースでTDEを使用する場合、Data Guard構成の各スタンバイ・データベースには、これにマージされたプライマリ・データベースからのキーストアがある暗号化キーストアが必要です。プライマリ・データベースでTDEマスター暗号化鍵を再設定した場合は、そのTDEマスター暗号化鍵が格納されているプライマリ・データベースのキーストアを各スタンバイ・データベースにマージする必要があります。

次の点に注意してください。

- データをスタンバイ・データベースに転送する場合、ログ・ファイル内の暗号化データは暗号化されたままです。暗号化データは転送中も暗号化されたままです。

- TDEは、SQL*Loaderのダイレクト・パス・ロードと連携します。暗号化列にロードされるデータは、ダイレクト・パス・ロードの過程で透過的に暗号化されます。

- マテリアライズド・ビューは、TDE表領域暗号化と連携します。暗号化表領域にはマテリアライズド・ビューとマテリアライズド・ビュー・ログの両方を作成できます。マテリアライズド・ビューは、TDE列暗号化とも連携します。

関連項目:

- ソフトウェア・キーストアのマージ

- TDEとロジカル・スタンバイ・データベースの併用の詳細は、Oracle Data Guard概要および管理を参照してください。

- マテリアライズド・ビューの詳細は、Oracle Databaseアドバンスト・レプリケーションを参照してください

- Oracle Key Vault環境でTDEとOracle Data Guardを使用する方法は、『Oracle Key Vault管理者ガイド』

透過的データ暗号化とOracle Real Application Clustersとの連携

Oracle Real Application Clusters (Oracle RAC)のノードでは、ソフトウェア・キーストアを共有できます。ハードウェアのセキュリティ・モジュール・キーストアは、ネットワーク接続を使用して共有する必要があります。ソフトウェア・キーストアは、Oracle RACの共有されていないファイル・システムに格納できます。

内容は次のとおりです。

- Oracle Real Application Clustersでの透過的データ暗号化の使用について

- 非共有ファイル・システムを使用したOracle RACへのソフトウェア・キーストアの格納

関連項目:

Oracle Key Vault環境でTDEとOracle RACを使用する方法は、『Oracle Key Vault管理者ガイド』

Oracle Real Application Clustersでの透過的データ暗号化の使用について

Oracle Databaseでは、Oracle Real Application Clustersノードがソフトウェア・キーストアを共有できます。ハードウェアのセキュリティ・モジュールは、各データベース・インスタンスに対してネットワーク接続を使用します。

これによって、すべてのノードにソフトウェア・キーストアを手動でコピーし同期化する必要がなくなります。オラクル社は、共有ファイル・システム上にソフトウェア・キーストアを作成することをお薦めします。これによってすべてのインスタンスが、同じ共有ソフトウェア・キーストアにアクセスできます。自動ストレージ管理(ASM)を使用するようにOracle RACを構成する場合、キーストアをASMディスク・グループに格納します。

ハードウェアのセキュリティ・モジュールの場合には、各データベース・インスタンスに対してネットワーク接続を使用します。したがって、すべてのデータベース・インスタンスがこのハードウェアのセキュリティ・モジュールにアクセス可能です。

すべてのインスタンスで実行または同期される必要があるキーストア操作(キーストアの開閉またはキー更新)は、任意の1つのOracle RACインスタンスで実行可能です。この同期操作は、クラスタ内のその他のOracle RACインスタンスに適用されます。つまり、ユーザーが1つのインスタンスに対して開閉したキーストアは、すべてのOracle RACインスタンスに対して開閉されます。同様に、1つのデータベース・インスタンスで実行したTDEマスター暗号化鍵のキー更新操作は、すべてのデータベース・インスタンスに適用されます。TDEマスター暗号化鍵のエクスポート、キーストアのパスワードのローテーション、キーストアのマージ、キーストアのバックアップを含む他のキーストア操作なども、1つのインスタンスのみから実行できます。

共有ファイル・システムを使用する場合は、すべてのOracle RACインスタンスのsqlnet.oraファイルにおけるENCRYPTION_WALLET_LOCATIONまたはWALLET_LOCATIONパラメータ設定が、必ず同じ共有ソフトウェア・キーストアの場所を指すようにします。また、適切なディレクトリ権限を割り当てることによって、共有ソフトウェア・キーストアのセキュリティを確保する必要もあります。

非共有システムを使用したOracle RACへのソフトウェア・キーストアの格納

ソフトウェア・キーストアを格納するために共有ファイル・システムを使用しない場合は、キーストアを関連するノードにコピーする必要があります。

1. ADMINISTER KEY MANAGEMENTまたはSYSKM権限が付与されたユーザーとして、データベース・インスタンスにログインします。
マルチテナント環境で、rootまたは適切なPDBにログインします。例:

sqlplus sec_admin@hrpdb as syskm
Enter password: password
Connected.

2. 最初のOracle Real Application Clusters (Oracle RAC)ノードのTDEマスター暗号化鍵を再設定します。
詳細は、キーストアのTDEマスター暗号化鍵の設定および再設定を参照してください。

3. 新しいTDEマスター暗号化鍵が格納されたキーストア・ファイルを、最初のノードから他のすべてのノードにコピーします。
キーストア・ファイルの場所を確認するには、V$ENCRYPTION_WALLETビューのWRL_PARAMETER列を問い合せます。すべてのデータベース・インスタンスのWRL_PARAMETER設定を確認するには、GV$ENCRYPTION_WALLETビューを問い合せます。

4. 任意の1つのノードのキーストアを閉じてから再度開きます。(マルチテナント・コンテナ・データベース(CDB)を使用している場合は、rootでこれらの文を実行します。)

ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY software_keystore_password;

ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY software_keystore_password [CONTAINER = ALL | CURRENT];

注意:

ある1つのOracle RACインスタンスで実行されるキーストアを開く、閉じるなどのキーストア操作は、他のすべてのOracle RACインスタンスに適用されます。これは、共有ファイル・システムを使用していない場合にも当てはまります。

すべてのOracle RACノードで新しいTDEマスター暗号化鍵が使用されるようになりました。

関連項目:

- 手順3: ソフトウェア・キーストアを開く

- ソフトウェア・キーストアを閉じる

透過的データ暗号化とSecureFilesとの連携

LOBを保存するには、SecureFilesを使用します。また、SecureFilesの記憶域には、圧縮、重複除外および暗号化の3つの機能があります。

内容は次のとおりです。

- 例: 特定の暗号化アルゴリズムを使用したSecureFiles LOBの作成

- 例: 列パスワードを指定したSecureFiles LOBの作成

関連項目:

SecureFiles暗号化の詳細は、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』を参照してください。

透過的データ暗号化およびSecureFilesについて

SecureFilesの暗号化では、LOBの暗号化機能を提供するためにTDEを使用します。

表を作成または変更する際に、SecureFiles記憶域を使用する必要があるSecureFiles暗号化やLOB列を指定できます。現在の透過的データ暗号化(TDE)構文を使用するか、またはLOB列に関するLOBパラメータの一部としてENCRYPT句を使用することによって、LOB列の暗号化を有効化できます。現在の構文またはLOBパラメータにおけるDECRYPTオプションによって、暗号化を無効化できます。

例: 特定の暗号化アルゴリズムを使用したSecureFiles LOBの作成

CREATE TABLE文によって、暗号化を指定してSecureFiles LOBを作成できます。

例6-1では、CREATE TABLE文でSecureFiles LOBを作成する方法を示しています。

例6-1 特定の暗号化アルゴリズムを使用したSecureFiles LOBの作成

CREATE TABLE table1 ( a BLOB ENCRYPT USING 'AES256')
LOB(a) STORE AS SECUREFILE (
CACHE
);

例: 列パスワードを指定したSecureFiles LOBの作成

CREATE TABLE文によって、列パスワードを指定してSecureFiles LOBを作成できます。

例6-2では、暗号化された列に対してパスワード保護を使用するSecureFiles LOBの作成例を示しています。

LOB列のすべてのLOBが、同じ暗号化の指定で暗号化されます。

例6-2 列パスワードを指定したSecureFiles LOBの作成

CREATE TABLE table1 (a VARCHAR2(20), b BLOB)
LOB(b) STORE AS SECUREFILE (
CACHE
ENCRYPT USING 'AES192' IDENTIFIED BY password
);

透過的データ暗号化のマルチテナント環境での使用

マルチテナント環境では、実行できるTDE操作はrootにいるかPDBにいるかによって変わります。

内容は次のとおりです。

- マルチテナント環境における透過的データ暗号化の使用について

- rootで実行される必要がある操作

- rootまたはPDBで実行可能な操作

- PDB向けのTDEマスター暗号化鍵のエクスポートおよびインポート

- 暗号化データのあるPDBをCDBでプラグおよびアンプラグ

- マルチテナント環境でのキーストアの開閉操作の機能

- マルチテナント環境のすべてのPDBのキーストアのステータスの確認

マルチテナント環境における透過的データ暗号化の使用について

マルチテナント環境で、列および表領域の両方に透過的データ暗号化を使用できます。

次の点に注意してください。

- 作成するキーストアは、特定のPDB内ではなくホストのマルチテナント環境に存在します。複数のPDBはこのホスト上で動作中に、単一のキーストアにアクセス可能です。暗号化を使用する各PDBには、このキーストアに格納されている透過的データ暗号化のTDEマスター暗号化鍵があります。

- 各PDBには個別のTDEマスター暗号化鍵があります。PDB固有のキー管理のADMINISTER KEY MANAGEMENT文を使用して、PDB内でのみ各PDB用のTDEマスター暗号化鍵を管理する必要があります。rootまたはPDBから、CDBにおけるPDBのTDEマスター暗号化鍵についての情報を確認するために適切なビューを問合せできます。たとえば、V$ENCYRYPTION_KEYSビューのPDBID列は、TDEマスター暗号化鍵が属するPDBを示しています。

- 各PDBのキーストア内で、透過的データ暗号化のTDEマスター暗号化鍵を個別に管理できます。各PDB向けのTDEマスター暗号化鍵を、個別にローテーションできます。詳細は、「TDEマスター暗号化鍵のエクスポートおよびインポート」を参照してください。

- rootからキーストア操作の大部分を実行します。キーストア・パスワードのローテーションやキーストアのマージなどのキーストア操作は、rootで実行する必要があります。鍵を開く、閉じる、リセットする、作成するなど、PDB内で実行できるキー管理の操作がいくつかあります。rootからすべてのPDBに操作を実行することもできます。適用可能な場合には、ADMINISTER KEY MANAGEMENT文にCONTAINER句があります。CONTAINER=ALLと設定すると、すべてのPDBにアクションが実行されます。
詳細は、次の各項を参照してください。

- 「rootで実行される必要がある操作」

- 「rootまたはPDBで実行可能な操作」

- 透過的データ暗号化を使用するPDBを、新しいホスト・コンピュータに移動する予定の場合、TDEマスター暗号化鍵も移動する必要があります。TDEマスター暗号化鍵をあるホスト・コンピュータから別のコンピュータに移動するには、「TDEマスター暗号化鍵のエクスポートおよびインポート」に記載されている手順を使用します。

rootで実行される必要がある操作

特定のADMINISTER KEY MANAGEMENTキーストア操作は、rootでのみ実行される必要があります。

操作は次のとおりです。

- ADMINISTER KEY MANAGEMENT CREATE KEYSTORE文を使用したパスワードベースのソフトウェア・キーストアの作成

- ADMINISTER KEY MANAGEMENT CREATE [LOCAL] AUTO_LOGIN KEYSTORE FROM KEYSTORE文を使用した自動ログインのソフトウェア・キーストアの作成

- ADMINISTER KEY MANAGEMENT ALTER KEYSTORE PASSWORD文を使用したソフトウェア・キーストアのパスワードの変更

- ADMINISTER KEY MANAGEMENT MERGE KEYSTORE文を使用したソフトウェア・キーストアのマージ

- ADMINISTER KEY MANAGEMENT BACKUP KEYSTOREキーストアを使用したソフトウェア・キーストアのバックアップ

- ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY... MIGRATE USING文を使用したソフトウェア・キーストアからハードウェア・キーストアへの移行

- ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY... REVERSE MIGRATE文を使用したハードウェア・セキュリティ・モジュールからソフトウェア・キーストアへの逆移行

- ADMINISTER KEY MANAGEMENT ADD|UPDATE|DELETE SECRET文を使用したシークレットの追加、更新および削除

- 問合せまたは識別子リストに基づいた、キーの選択的なエクスポートおよびインポート

鍵およびキーストア操作に関するCONTAINER=ALL設定の動作状況

この項に記載されている鍵およびキーストア操作に関して、CONTAINER=ALL設定を指定できます。CONTAINER=ALL設定を指定することによって、CDB内のすべてのPDBで同じ操作が実行されます。rootでのみCONTAINER=ALL設定を使用できることに留意してください。CONTAINER句はオプションです。CONTAINER句を省略すると、デフォルトはCONTAINER = CURRENTになります。

許可されているCONTAINER=ALL操作は次のとおりです。

- キーストアを開く。CONTAINER=ALL設定を使用してキーストアを開くと、関連するすべてのPDBのキーストアが開きます。

- キーストアを閉じる。CONTAINER=ALL設定を使用してキーストアを閉じると、関連するすべてのPDBのキーストアが閉じます。

- TDEマスター暗号化鍵を作成する。CONTAINER=ALL設定を使用してTDEマスター暗号化鍵を作成すると、開いているすべてのPDBに鍵が作成されます。最近作成された鍵を確認するには、V$ENCRYPTION_KEYSビューのCREATION_TIME列を問い合せます。CONTAINER=ALL操作でタグの指定もできますが、この操作によってすべてのPDBの鍵が同じタグで作成されることに注意してください。各TDEマスター暗号化鍵に個別のタグを作成する必要があり、これは、エラー発生時に鍵作成操作が成功したPDBがこのタグによって識別可能であるためです。ADMINISTER KEY MANAGEMENT SET TAG文を使用して、後でタグを変更できます。

- キー更新操作を実行する。CONTAINER=ALL設定でキー更新操作を実行することによって、開いているすべてのPDBで鍵が作成され、有効化されます。最近作成された鍵を確認するには、V$ENCRYPTION_KEYSビューのCREATION_TIME列を問い合せます。最近アクティブ化された鍵を確認するには、V$ENCRYPTION_KEYSビューのACTIVATION_TIME列を問い合せます。CONTAINER=ALL操作でタグの指定もできますが、この操作によってすべてのPDBの鍵が同じタグで作成されることに注意してください。このタグは、エラー時に鍵作成操作が成功したPDBの識別にも役立ちます。ADMINISTER KEY MANAGEMENT SET TAG文を使用して、後でタグを変更できます。

rootまたはPDBで実行可能な操作

rootまたはPDBのいずれかで、次の一部のキーストア操作を実行できます。

操作は次のとおりです。

- ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN文を使用して、キーストアを開く

- ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE文を使用して、キーストアを閉じる

rootまたはPDBのいずれかで、次のキー管理操作を実行できます。

- ADMINISTER KEY MANAGEMENT SET TAG文を使用した、TDEマスター暗号化鍵のタグの作成

- ADMINISTER KEY MANAGEMENT CREATE KEY文を使用した、TDEマスター暗号化鍵の作成

- ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY文を使用した、TDEマスター暗号化鍵の再設定またはローテーション

- ADMINISTER KEY MANAGEMENT USE KEY文を使用した、TDEマスター暗号化鍵のアクティブ化

- ADMINISTER KEY MANAGEMENT EXPORT ENCRYPTION KEYS文を使用した、TDEマスター暗号化鍵のエクスポート

- ADMINISTER KEY MANAGEMENT IMPORT ENCRYPTION KEYS文を使用した、TDEマスター暗号化鍵のインポート

PDB向けのTDEマスター暗号化鍵のエクスポートおよびインポート

PDB向けにTDEマスター暗号化鍵をエクスポートまたはインポートするには、ADMINISTER KEY MANAGEMENT EXPORTおよびADMINISTER KEY MANAGEMENT IMPORT文を使用します。

内容は次のとおりです。

- PDB向けのTDEマスター暗号化鍵のエクスポートおよびインポートについて

- PDB向けのTDEマスター暗号化鍵のエクスポートまたはインポート

- 例: PDBからTDEマスター暗号化鍵をエクスポート

- 例: PDBにTDEマスター暗号化鍵をインポート

PDB向けのTDEマスター暗号化鍵のエクスポートおよびインポートについて

CDB以外のデータベースのTDEマスター暗号化鍵をエクスポートおよびインポートする場合と同じ方法で、rootから任意のTDEマスター暗号化鍵をエクスポートおよびインポートできます。

PDB内からTDEマスター暗号化鍵をエクスポートおよびインポートすることで、PDBに属するすべてのTDEマスター暗号化鍵をエクスポートおよびインポートできます。PDBのTDEマスター暗号化鍵のエクスポートおよびインポートでは、PDBのアンプラグとプラグ操作がサポートされます。PDBのアンプラグとプラグでは、PDBに属するすべてのTDEマスター暗号化鍵、およびメタデータが対象になります。したがって、PDB内から鍵をエクスポートする場合、ADMINISTER KEY MANAGEMENT EXPORT文のWITH IDENTIFIER句は許可されません。WITH IDENTIFIER句は、rootでのみ許可されます。

ルートに自動ログイン・キーストアがある場合、またはキーストアが閉じている場合は、FORCE KEYSTORE句を含める必要があります。キーストアがパスワードに外部ストアを使用するように構成されている場合、IDENTIFIED BY EXTERNAL STORE句を使用します。たとえば、このシナリオにおいてエクスポート操作を実行するには、次のようにします。

ADMINISTER KEY MANAGEMENT EXPORT KEYS WITH SECRET "my_secret"
TO '/etc/TDE/export.exp'
FORCE KEYSTORE IDENTIFIED BY EXTERNAL STORE;

このADMINISTER KEY MANAGEMENT EXPORT操作では、鍵がエクスポートされるだけでなく、PDB環境(およびクローニング操作)に必要なメタデータも作成されます。

PDBの内部では、TDEマスター暗号化鍵のエクスポート操作によって、鍵がエクスポートされるPDBと同じGUIDを持つPDBにより作成またはアクティブ化された鍵がエクスポートされます。基本的に、エクスポートが実行されるPDBに属しているすべての鍵がエクスポートされます。

PDB内のエクスポート・ファイルからTDEマスター暗号化鍵がインポートされるのは、そのTDEマスター暗号化鍵が同じGUIDを持つ別のPDBからエクスポートされている場合のみです。CDBへのPDBのプラグインをサポートするため、インポートでは、WITH IDENTIFIER句なしでエクスポートされたCDB以外のTDEマスター暗号化鍵を含むエクスポート・ファイルからもTDEマスター暗号化鍵がインポートされます。PDB名やデータベースIDなどのPDB固有の詳細は、CDBごとに変化する可能性があるため、PDB固有の情報は、更新されたPDB情報を反映するようにインポート時に変更されます。

注意:

PDB内では、PDB全体のキーのみエクスポートできます。問合せまたは識別子に基づいた選択的なエクスポート機能はrootに制限されています。

PDB向けのTDEマスター暗号化鍵のエクスポートまたはインポート

PDB向けのTDEマスター暗号化鍵をエクスポートまたはインポートするには、キーストアを開いてから、EXPORT ENCRYPTION KEYS WITH SECRETまたはIMPORT ENCRYPTION KEYS WITH SECRET句を含むADMINISTER KEY MANAGEMENT文を使用する必要があります。

1. ADMINISTER KEY MANAGEMENTまたはSYSKM権限を付与されたユーザーとしてPDBにログインします。
例:

sqlplus sec_admin@hr_pdb as syskm
Enter password: password
Connected.

利用可能なPDBを検索するには、DBA_PDBSデータ・ディクショナリ・ビューを問い合せます。現在のPDBを確認するには、show con_nameコマンドを実行します。

2. キーストアが開いていることを確認します。
V$ENCRYPTION_WALLETビューのSTATUS列を問い合せると、キーストアが開いているかどうかを確認できます。

キーストアを開く必要があることがわかった場合は、「手順3: ソフトウェア・キーストアを開」を参照してください。

3. 「例: PDBからTDEマスター暗号化鍵をエクスポート」の例に従って、エクスポートまたはインポート操作を実行します。

例: PDBからTDEマスター暗号化鍵をエクスポート

ADMINISTER KEY MANAGEMENT EXPORT ENCRYPTION KEYS SQL文を使用し、PDBからTDEマスター暗号化鍵をエクスポートできます。

例6-3では、PDB hr_pdb1からTDEマスター暗号化鍵をエクスポートする方法を示しています。

例6-3 PDBからTDEマスター暗号化鍵をエクスポート

sqlplus sec_admin@hr_pdb1 as syskm
Enter password: password
Connected.

ADMINISTER KEY MANAGEMENT EXPORT ENCRYPTION KEYS WITH SECRET "my_secret" TO '/export.p12' IDENTIFIED BY password_cdb1;

例: PDBにTDEマスター暗号化鍵をインポート

ADMINISTER KEY MANAGEMENT IMPORT ENCRYPTION KEYS SQL文を使用して、PDBにTDEマスター暗号化鍵をインポートできます。

例6-4では、PDB hr_pdb2へTDEマスター暗号化鍵をインポートする方法を示しています。

例6-4 PDBにTDEマスター暗号化鍵をインポート

sqlplus sec_admin@hr_pdb2 as syskm
Enter password: password
Connected.

ADMINISTER KEY MANAGEMENT IMPORT ENCRYPTION KEYS WITH SECRET "my_secret" FROM '/tmp/export.p12' IDENTIFIED BY password_cdb2 WITH BACKUP;

暗号化データのあるPDBをCDBでプラグおよびアンプラグ

暗号化されたデータのあるPDBを、CDBに追加またはCDBから削除できます。

暗号化データを含むPDBのアンプラグ

1つのCDBからPDBをアンプラグして、別のCDBにプラグインできます。

アンプラグされたデータベースには、データ・ファイルおよび他の関連ファイルが含まれます。エクスポート・ファイルは、アンプラグされたPDBのファイルの一部を構成する別のファイルであり、アンプラグされたPDBとともに転送する必要があります。

1. アンプラグするPDBのTDEマスター暗号化鍵をエクスポートします。
PDB向けのTDEマスター暗号化鍵のエクスポートおよびインポートを参照してください。

2. 『Oracle Database管理者ガイド』に説明されている方法で、PDBをアンプラグします。

注意:

TDSマスター暗号化鍵を最初にエクスポートしないで間違ってPDBをアンプラグしても、暗号化鍵は失われません。この情報はまだデータベース内にあります。PDBをCDBにプラグインしなおし、TDEマスター暗号化鍵をエクスポートしてから、PDBをアンプラグします。

暗号化データを含むPDBのCDBへのプラグイン

暗号化データを含むPDBをCDBにプラグインするには、TDEマスター暗号化鍵をPDBにインポートしてから、そこで構成する必要があります。

1. 『Oracle Database管理者ガイド』に説明されている方法で、アンプラグされたPDBをCDBにプラグインすることによって、PDBを作成します。
プラグ操作後のPDBのオープン操作中に、Oracle DatabaseによってPDBに暗号化データが含まれるかどうかが判別されます。その場合、PDBはRESTRICTEDモードでオープンされます。

PDBのオープン・モードの詳細は、『Oracle Database管理者ガイド』を参照してください。

2. TDEマスター暗号化鍵をPDBにインポートします。
「PDB向けのTDEマスター暗号化鍵のエクスポートおよびインポート」を参照してください。

3. 『Oracle Database管理者ガイド』の説明に従って、PDBをクローズしてからPDBを再オープンします。

4. キーストアを開きます。
次の項を参照してください。

- 「手順3: ソフトウェア・キーストアを開く」

- 「手順3: ハードウェア・キーストアを開く」

5. PDBにTDEマスター暗号化鍵を設定します。
次の項を参照してください。

- 「手順4: ソフトウェアTDEマスター暗号化鍵の設定」

- 「手順4: ハードウェア・キーストアのTDEマスター暗号化鍵の設定」

- 「後で使用するためのTDEマスター暗号化鍵の作成」

HSMに格納されたマスター鍵を含むPDBのアンプラグ

ハードウェア・セキュリティ・モジュール(HSM)で構成された1つのCDBからPDBをアンプラグし、それをHSMで構成された別のCDBにプラグインできます。

1. PDBをアンプラグします。

PDBのアンプラグの詳細は、Oracle Database管理者ガイドを参照してください。

2. ソースCDBで使用されていたHSMのアンプラグされたPDBのマスター鍵を、宛先のCDBで使用されているHSMに移動します。

マスター鍵のHSM間での移動の詳細は、HSMのドキュメントを参照してください。

HSMに格納されたマスター鍵を含むPDBのプラグ

ADMINISTER KEY MANAGEMENT文を使用して、別のCDBに移動したPDBにHSMマスター鍵をインポートできます。

1. アンプラグされたPDBをHSMで構成された宛先CDBにプラグインします。
プラグイン操作の後、プラグインされたPDBは制限モードになります。PDBのプラグの詳細は、Oracle Database管理者ガイドを参照してください。

2. ソースCDBで構成されたHSMからのマスター鍵が、宛先CDBのHSMで使用可能であることを確認します。

3. プラグされたPDBに、ADMINISTER KEY MANAGEMENTまたはSYSKM権限を付与されたユーザーとしてログインします。

例:

sqlplus sec_admin@hr_pdb as syskm
Enter password: password
Connected.

利用可能なPDBを検索するには、DBA_PDBSデータ・ディクショナリ・ビューを問い合せます。現在のPDBを確認するには、show con_nameコマンドを実行します。

4. プラグされたPDBのマスター暗号化鍵を開きます。

たとえば、PDB1というPDBの場合は、次のようになります。

ALTER SESSION SET CONTAINER = PDB1;
ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "keystore_passsword";

5. HSMマスター鍵をPDBにインポートします。

ADMINISTER KEY MANAGEMENT IMPORT ENCRYPTION KEYS WITH SECRET "HSM" FROM 'HSM' IDENTIFIED BY "keystore_password";

6. PDBを再起動します。

ALTER PLUGGABLE DATABASE PDB1 CLOSE;
ALTER PLUGGABLE DATABASE PDB1 OPEN;

マルチテナント環境でのキーストアの開閉操作の機能

マルチテナント環境でキーストアの開閉操作がどのように機能するかを知っておく必要があります。

マルチテナント環境における各PDBに関して、透過的データ暗号化の操作が続行できるように、PDBにおいてパスワードベースのソフトウェア・キーストアまたはハードウェア・キーストアを明示的に開く必要があります。(自動ログイン・ソフトウェア・キーストアおよびローカル自動ログイン・ソフトウェア・キーストアは自動的に開きます。)PDBのキーストアを閉じることによって、PDBのすべての透過的データ暗号化操作がブロックされます。

CDBにおいて、PDBにおけるキーストア操作の開閉操作は、rootにおけるキーストアの開閉状態に依存します。

次の点に注意してください。

- 個別のPDBにおいてソフトウェアのパスワードベースのキーストアまたはハードウェア・キーストアを手動で開くには、rootでキーストアを開く必要があります。

- 個々のPDBでTDEマスター暗号化鍵を設定する前に、rootで鍵を設定する必要があります。

- (自動ログイン・ソフトウェア・キーストアおよびローカル自動ログイン・ソフトウェア・キーストアは自動的に開きます。)これらを最初にrootからまたはPDBから、手動で開く必要はありません。

- rootでキーストアを閉じると、これに依存するPDBのキーストアも閉じられます。rootにおいてキーストアを閉じる操作は、CONTAINER句がALLに設定されていてキーストアを閉じる操作を実行することと同等です。

- rootでキーストアを開いてCONTAINERをALLに設定すると、これに依存するPDBのキーストアも開きます。

マルチテナント環境のすべてのPDBのキーストアのステータスの確認

V$ENCRYPTION_WALLETビューでは、PDBのキーストアのステータス(オープン、クローズ、ソフトウェアまたはハードウェア・キーストアを使用しているかどうかなど)が表示されています。このビューを使用する便利なファンクションを作成して、CDB環境におけるすべてのPDBのキーストアのステータスを確認できます。

- V$ENCRYPTION_WALLETビューを使用してキーストアのステータスを検出するファンクションを作成するには、CREATE PROCEDURE PL/SQL文を使用します。

例6-5では、このファンクションを作成する方法を示しています。

例6-5 CDBにおけるすべてのPDBに関するキーストアのステータスを確認するファンクション

CREATE OR REPLACE PROCEDURE all_pdb_v$encryption_wallet
IS
err_occ            BOOLEAN;
curr_pdb           VARCHAR2(30);
pdb_name           VARCHAR2(30);
wrl_type           VARCHAR2(20);
status             VARCHAR2(30);
wallet_type        VARCHAR2(20);
wallet_order       VARCHAR2(12);
fully_backed_up    VARCHAR2(15);
wrl_parameter      VARCHAR2(4000);
cursor sel_pdbs IS SELECT NAME FROM V$CONTAINERS
WHERE NAME <> 'PDB$SEED' order by con_id desc;
BEGIN

-- Store the original PDB name
SELECT sys_context('userenv', 'con_name') INTO curr_pdb FROM DUAL;
IF curr_pdb <> 'CDB$ROOT' THEN
dbms_output.put_line('Operation valid in ROOT only');
END IF;

err_occ := FALSE;
dbms_output.put_line('---');
dbms_output.put_line('PDB_NAME                       WRL_TYPE STATUS                        ');
dbms_output.put_line('------------------------------ -------- ------------------------------');
dbms_output.put_line('WALLET_TYPE          WALLET_ORDER FULLY_BACKED_UP');
dbms_output.put_line('-------------------- ------------ ---------------');
dbms_output.put_line('WRL_PARAMETER');
dbms_output.put_line('--------------------------------------------------------------------------');
FOR pdbinfo IN sel_pdbs LOOP

pdb_name := DBMS_ASSERT.ENQUOTE_NAME(pdbinfo.name, FALSE);
EXECUTE IMMEDIATE 'ALTER SESSION SET CONTAINER = ' || pdb_name;

BEGIN
pdb_name := rpad(substr(pdb_name,1,30), 30, ' ');
EXECUTE IMMEDIATE 'SELECT wrl_type from V$ENCRYPTION_WALLET' into wrl_type;
wrl_type := rpad(substr(wrl_type,1,8), 8, ' ');
EXECUTE IMMEDIATE 'SELECT status from V$ENCRYPTION_WALLET' into status;
status := rpad(substr(status,1,30), 30, ' ');
EXECUTE IMMEDIATE 'SELECT wallet_type from V$ENCRYPTION_WALLET' into wallet_type;
wallet_type := rpad(substr(wallet_type,1,20), 20, ' ');
EXECUTE IMMEDIATE 'SELECT wallet_order from V$ENCRYPTION_WALLET' into wallet_order;
wallet_order := rpad(substr(wallet_order,1,9), 12, ' ');
EXECUTE IMMEDIATE 'SELECT fully_backed_up from V$ENCRYPTION_WALLET' into fully_backed_up;
fully_backed_up := rpad(substr(fully_backed_up,1,9), 15, ' ');
EXECUTE IMMEDIATE 'SELECT wrl_parameter from V$ENCRYPTION_WALLET' into wrl_parameter;
wrl_parameter := rpad(substr(wrl_parameter,1,79), 79, ' ');
dbms_output.put_line(pdb_name || ' ' || wrl_type || ' ' || status);
dbms_output.put_line(wallet_type || ' ' || wallet_order || ' ' || fully_backed_up);
dbms_output.put_line(wrl_parameter);

EXCEPTION
WHEN OTHERS THEN
err_occ := TRUE;
END;
END LOOP;

IF err_occ = TRUE THEN
dbms_output.put_line('One or more PDB resulted in an error');
END IF;
END;
.
/
set serveroutput on
exec all_pdb_v$encryption_wallet;

透過的データ暗号化とOracle Call Interfaceとの連携

透過的データ暗号化は、Oracle Call Interface (OCI)の動作に影響しません。

多くの実用的な目的のために、TDEは行の受渡し機能を除き、OCIに対して透過的です。行を使用可能にする鍵は受信ポイントでは使用できないため、OCIの行の受渡し機能をTDEで使用できません。

透過的データ暗号化とエディションとの連携

透過的データ暗号化は、Oracle Databaseのエディション機能に影響しません。

多くの実用的な目的のために、TDEはエディションに対して透過的です。表は常に非エディション化オブジェクトです。TDEの列暗号化によって、表の列が暗号化されます。エディションは、TDEの表領域の暗号化によって影響されません。

マルチデータベース環境で機能するように透過的データ暗号化を構成

同じサーバー上の各Oracle Database (同じOracleバイナリを共有しているが異なるデータ・ファイルを使用しているデータベースなど)は、それぞれ独自のTDEキーストアにアクセスする必要があります。

キーストアは、データベース間で共有されるようには設計されていません。設計によって、データベースごとに1つのキーストアが必要となっています。複数のデータベースには同じキーストアを使用できません。

- 複数データベース環境に対してsqlnet.oraファイルを構成するには、次のオプションを使用します。

- オプション1: データベースが同じOracleホームを共有する場合、sqlnet.oraファイルをデフォルトの場所(ORACLE_HOME/network/adminディレクトリ)に保持します。
この場合、デフォルトの場所を使用することをお薦めします。sqlnet.oraファイルに、WALLET_LOCATIONまたはENCRYPTION_WALLET_LOCATIONエントリがないことを確認します。これらの2つのエントリがsqlnet.oraファイルにない場合、透過的データ暗号化は、デフォルトのsqlnet.oraの場所からキーストアにアクセスします。

- オプション2: オプション1がご使用のサイトで実行可能な場合、ORACLE_SIDのような環境変数設定に基づき、キーストアの場所を指定できます。
例:

ENCRYPTION_WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = /home/oracle/wallet/$ORACLE_SID)

- オプション3: オプション1および2が実行可能でない場合、個別のsqlnet.oraファイルを各データベースにつき1つ使用します。TNS_ADMIN環境変数が、正しいデータベース構成を指すように正確に設定されていることを確認します。TNS_ADMIN変数の詳細および設定例は、SQL*Plusユーザーズ・ガイドおよびリファレンスを参照してください。

注意:

他のデータベースからキーストアを使用することによって、データの一部または全部が失われる可能性があります。

7 透過的データ暗号化に関するよくある質問

透過的データ暗号化の透過およびパフォーマンスに関して、ユーザーからよく質問が寄せられます。

内容は次のとおりです。

- 透過的データ暗号化に関する透過の質問

- 透過的データ暗号化に関するパフォーマンスの質問

透過的データ暗号化に関する透過の質問

透過的データ暗号化は、データの透過性を様々な方法で扱います。

セキュリティ監査により、Oracle Advanced Security Transparent Data Encryption (TDE)で使用する暗号化について詳細な質問を受ける場合があります。TDEの鍵、長さおよびキーストアに関する情報を求められ、PCI-DSSなどの基準要件に直接比較されます。この項では、TDE暗号化および鍵管理の重要な詳細について説明します。この情報は、Oracle Database 12c (12.1.0.2)を基準にしています。これは、TDE顧客が監査の質問に迅速および正確に回答するのに役立ちます。

1. 透過的データ暗号化は、使用しているアプリケーション・ソフトウェアに対応していますか。
透過的データ暗号化は、インバウンドのSQL文またはアウトバウンドのSQL問合せの結果を変更しないので、デフォルトでアプリケーションに対応しています。オラクル社では、オラクル社およびサード・パーティの特定のアプリケーション・ソフトウェアを内部でテストおよび検証し、役立つデプロイ時のヒントやスクリプトを得たり、パフォーマンス・プロファイルを評価しています。様々なアプリケーションで使用可能なデプロイメント・スクリプトの詳細は、次のOracle Technology Networkのページを参照してください。

http://www.oracle.com/technetwork/database/options/advanced-security/index-099011.html

透過的データ暗号化とDBMS_CRYPTO PL/SQLパッケージには違いがあることに注意してください。このパッケージは、お客様の別のユースケース向けです。これはAPIおよびツールキットのソリューションであるため、透過ではありません。

2. 透過的データ暗号化は、使用中のその他のOracle Databaseツールおよびテクノロジと対応していますか。
透過的データ暗号化の主な利点の1つは、高可用性クラスタ、記憶域の圧縮、バックアップの圧縮、データ移動、データのバックアップおよびリストア、データベースのレプリケーションなどでよく使用されるOracle Databaseツールおよびテクノロジと統合できることです。透過的データ暗号化に直接統合されているOracleテクノロジは、具体的には特にOracle Real Application Clusters (Oracle RAC)、Oracle Recovery Manager (RMAN)、Oracle Data Guard、Advanced Compression、Oracle Data PumpおよびOracle GoldenGateです。透過的データ暗号化には、オラクル社がエンジニアリングした独自のシステム機能を最大限に活用するOracle Exadataとの統合という特別な利点があります。

透過的データ暗号化は、Oracle Databaseのセキュリティ機能ともうまく動作します。透過的データ暗号化では、付与された権限、ロール、Oracle Database Vaultレルム、仮想プライベート・データベースのポリシー、Oracle Label Securityのラベルがそのまま適用されます。これらおよびその他のセキュリティ機能は、透過的データ暗号化の暗号化と並行して使用できます。

3. 透過的データ暗号化に既知の制限や非互換性はありますか。

- TDE列暗号化: TDE列暗号化では、データがSQLレイヤーを通過するとき、データを透過的に暗号化および復号化します。Oracleの一部の機能は、SQLレイヤーをバイパスするため、TDE列暗号化のメリットを受けません。次にTDE列暗号化でサポートされないデータベース機能および該当するそのソフトウェア・バージョン番号を示します。

- マテリアライズド・ビュー・ログ(Oracle Database 11gリリース2より前がサポート対象外)

- Streams (Oracle Database 11gリリース1より前がサポート対象外)

- データ・ウェアハウスの同期および非同期チェンジ・データ・キャプチャ(CDC)

- トランスポータブル表領域

- LOB

セキュア・ファイルは、Oracle Database 11gリリース1で導入されたため、それより前のリリースのTDE列暗号化ではサポートされていません。

- TDE表領域暗号化: TDE表領域暗号化は、表領域に保存されているすべてのコンテンツを記憶域のブロック・レベルで暗号化し、通常は他のデータベース機能と競合しません。TDE表領域暗号化には、TDE列暗号化にある制限はありません。ただし、次を注意する必要があります。

- TDEで暗号化されたソースからTDEで暗号化された宛先に移動する際に、Oracle Data Pumpの圧縮および暗号化で完全トランスポータブル表領域(TTS)を使用できます。元のOracleウォレット・ファイルを上書きする必要なく、宛先データベース・ホストへの正しいTDEマスター鍵を取得するために鍵エクスポートまたはキーストア(ウォレット)マージ機能を使用できるように、Oracle Databaseリリース12cデータベース・インスタンスを使用可能にする必要があります。このプロセスは標準TTS制限の影響を受けるため、互換性のあるエンディアンであるかどうかを忘れずにチェックする必要があります。

- TDE表領域暗号化を使用して、SYSTEM、SYSAUX、UNDOまたはTEMP表領域などの内部オブジェクトを暗号化しないようにする必要があります。TDE表領域暗号化では、このようなOracle Databaseのコア・コンポーネントではなく、アプリケーション・データを保持する表領域を対象とする必要があります。

4. TDEではどのようなタイプの鍵およびアルゴリズムが使用されますか。
TDEは、2つの異なる暗号化鍵セットに依拠しています。1つめの暗号化鍵セットはデータ暗号化鍵(DEK)で、格納されているデータを透過的に暗号化および復号化するために使用します。DEKは、データベースにより自動的に生成され、暗号化された形でデータベースに内部的に格納され、多くの場合、シーンの裏側で管理されます。エンド・ユーザーとDEKが相互作用して、TDEで使用する暗号化アルゴリズムと鍵の長さが選択されます(3DES168、AES128、AES192またはAES256)。この選択は暗号化列を含む各表および各暗号化表領域に対して個別に行われます。また、DEKを表鍵として参照(列暗号化)するか、または表領域鍵として参照(表領域暗号化)するか、通知されます。表鍵は暗号ブロック連鎖(CBC)操作モードで使用し、表領域鍵は暗号フィードバック(CFB)操作モードで使用します。

2つめの暗号化鍵セットは、現行および過去の暗号化鍵(KEK)からなり、TDEマスター鍵とも呼ばれます。TDEマスター鍵は、データベースにより自動的に生成され、必要に応じDEKの暗号化および複号化のために自動的に使用され、保護されたキーストアに外部的に格納されます。ユーザーは、現行TDEマスター鍵と相互作用して、周期的なローテーション、特定の鍵属性の変更などを行います。通常、TDEマスター鍵のキーストアは、Oracleウォレット(そのまま使用できるソリューション)またはOracle Key Vault (特別な鍵管理製品)のいずれかです。データベースが一度に使用するTDEマスター鍵は1つのみですが、ローテーションされたすべてのTDEマスター鍵は、暗号化データ・バックアップを長期間リカバリするためにキーストアに残ります。TDEマスター鍵は、常にAES256です。これらは、CBC操作モードを使用して、DEKを暗号化および復号化します。DEKおよびTDEマスター鍵のいずれも、基本となる鍵データは直接表面に現れません。エンド・ユーザーは、TDEの管理に必要な鍵の属性のみを見ることができます。

5. TDEマスター鍵を含むOracleウォレットはどのように保護されていますか。
OracleウォレットをTDEマスター鍵のキーストアとして使用する場合、パスワードベースのウォレット、自動ログイン・ウォレットおよびローカル自動ログイン・ウォレットの異なる3タイプのウォレットについて考慮します。これらのウォレットはすべて、TDEマスター鍵を外部化するため、TDE暗号化データから独立しています。厳密なファイル許可およびその他のセキュリティの手段で保護されたローカルまたはネットワーク・ディレクトリに、ウォレットを配置することをお薦めします。

パスワードベースのウォレットは、暗号化鍵ストレージ・ファイル(ewallet.p12)で、PKCS #12標準に準拠します。これは、PKCS #5標準に従い、パスワードにより導出される鍵によって暗号化されます。ユーザーは、ウォレットを開き、そのコンテンツを復号化し、鍵へのアクセスを取得するためのデータベースに対するパスワードを含むコマンドを入力する必要があります。パスワードベースのウォレットは、TDEマスター鍵のデフォルト鍵です。以前は、これは3DES168暗号化アルゴリズムおよびCBC操作モードを使用して暗号化されていました。Oracle Database 12c (12.1.0.2)以降、新しいorapkiコマンド、convert walletを使用して、パスワードベースのウォレットをAES256およびCBC操作モードに変換できます。(orapkiを使用してウォレットを変換する方法の詳細は、Oracle Databaseセキュリティ・ガイドを参照してください。)

自動ログイン・ウォレット(cwallet.sso)は、ユーザーの相互作用なしにウォレット・パスワードを入力してデータベースを起動する必要がある特殊な場合に、オプションで標準パスワードベースのウォレットから導出されます。自動ログイン・ウォレットを使用する場合、これはTDEマスター鍵のローテーションを必要とするため、マスター・パスワードベース・ウォレットを保持する必要があります。加えて、厳密なファイル許可により保護されるローカルまたはネットワーク・ディレクトリに自動ログイン・ウォレットを格納するためのベスト・プラクティスとして、ファイル・コンテンツはセキュリティを追加する独占メソッドを使用してデータベースによりスクランブルされます。自動ログイン・ウォレットの変化形であるローカル自動ログイン・ウォレットは、動作が類似しています。ローカル自動ログイン・ウォレットとの大きな違いは、ファイルが作成されたホスト・マシンから取得した追加ファクタを使用してコンテンツをスクランブルすることです。これにより、ローカル自動ログイン・ウォレットが別のホスト・マシン上で使用できなくなります。ホスト・ファクタおよびスクランブル・テクニックの詳細は、独占的です。

6. Oracle Key Vaultとは何ですか、またTDEマスター鍵をどのように管理するのですか。
Oracle Key Vaultは、TDEマスター鍵、Oracleウォレット、Javaキーストアなどを中心的に管理します。これは、鍵の増加および鍵ストレージ・ファイルを制御するのに役立ちます。これには、TDEおよび他のOracleスタックのコンポーネント専用の最適化が含まれます。TDEでOracle Key Vaultを使用する方法の詳細は、www.oracle.comおよびOracle Technology Networkの製品ページ、および『Oracle Key Vault管理者ガイド』を参照してください。

透過的データ暗号化に関するパフォーマンスの質問

透過的データ暗号化を使用する際には、検討すべきパフォーマンスの問題がいくつかあります。

1. 透過的データ暗号化によって生じる典型的なパフォーマンス・オーバーヘッドはどのようなものですか。
透過的データ暗号化の正確なパフォーマンス・テストの作成には、様々な変動要素が関係します。テスト環境、テスト・ケースまたはワークロード、計測メトリックまたは方法などにより、結果は変わります。オラクル社は、考えられるすべてのシナリオに当てはまる、パフォーマンス・オーバーヘッドの具体的なパーセンテージを保証することはできません。実際に、透過的データ暗号化の多くのお客様のパフォーマンス・テストでは1桁台前半のパーセンテージが示されますが、必ずそうなるわけではありません。オーバーヘッドがそれぞれ1パーセントおよび2パーセントである顧客事例が、Oracle Technology Networkの次のURLで公開されています。

http://streaming.oracle.com/ebn/podcasts/media/12740910_ColumbiaU_120312.mp3

可能な場合、Oracle Real Application Testing (Oracle RAT)を使用して実際の本番ワークロードを取得し、透過的データ暗号化に対してリプレイして、ご自身の環境で想定されるパフォーマンスのオーバーヘッドの実際の目安を得てください。

関連項目:

- 透過的データ暗号化のパフォーマンスと記憶域のオーバーヘッド

- Oracle Real Application Testingのオプションの詳細は、Oracle Database Testingガイドを参照してください。

2. 透過的データ暗号化のパフォーマンス調整はどのように最適化するのでしょうか。

- TDE列暗号化:

- 暗号化の処理を、必ず保護する必要のある列のサブセットに限定します。また、オプションの整合性チェックの機能をオフにします。

- 列を暗号化したら、列の索引を再構築します。

- TDE表領域暗号化: TDE表領域暗号化では、SGAバッファ・キャッシュ内のメモリーに、暗号化されていないデータをキャッシュしてパフォーマンスを向上させます。この機能により、ディスクではなくSGAから取得することで、SELECT問合せをユーザーが実行した際に必ず行われる多数の暗号化操作が減少します。(ディスクからの取得は、データベースによる復号化操作の実行を強制します。)このパフォーマンスの最適化を最大限に利用できるよう、SGAのバッファ・キャッシュが十分に大きいことを確認します。
Intel AES-NIおよびOracle SPARC T4/T5に搭載されているCPUベースの暗号アクセラレーションをサポートするハードウェアおよびソフトウェアを使用することでも、パフォーマンスを大きく向上させることができます。この機能を利用するには、最新バージョンのデータベースが実行され、最新バージョンのオペレーティング・システムがインストールされ、CPU/コアに暗号アクセラレーション回路を搭載したハードウェアが使用されている必要があります。

データベースの圧縮も、透過的データ暗号化のパフォーマンスをさらに向上させます。すでに圧縮されているデータで暗号化処理が発生して、暗号化および復号化するデータの総量が減少するためです。

- 一般的な処理は次のとおりです。

- 次のMy Oracle Supportからダウンロードできる最新のパッチを適用します。
https://support.oracle.com

- 暗号化アルゴリズムを指定する際には、AESは3DESよりもわずかに高速であることを覚えておいてください。可能な場合は、AES128を使用します。パフォーマンス上のメリットは少ないことに注意してください。

- パフォーマンス上の追加のメリットがあるExadataを使用します。Oracle Exadataの詳細は、Oracle Database Testingガイドを参照してください。

3. TDEのパフォーマンスを低下させる可能性のある問題は具体的には何で、それはどのように回避できますか。
ハードウェアやデータベースのバージョンやオペレーティング・システムが古いなどの要因により、データベースのホスト・マシンでCPUベースのハードウェア・アクセラレーションを使用できない場合、TDEの表領域のパフォーマンスは遅くなります。

特定のデータベースのワークロードに関し、次に注意してください。

- (Oracleデータ・ウェアハウスへのデータのバルク・ロードの実行など)データ・セット全体の一度での暗号化: 新しいデータをデータベースまたはデータ・ウェアハウスにバルク・ロードする際、暗号化のパフォーマンスの低下がみられました。新しいデータはSGAにキャッシュできないので、TDE表領域暗号化のパフォーマンスの最適化がバイパスされます。したがって、透過的データ暗号化はこの種の操作には何もパフォーマンス上のメリットはありません。
次のガイドラインに従います。

- CPUベースの暗号化アクセラレーションを搭載したサーバーでデータベースを実行していることを確認します。これにより、復号化操作のみでなく、(新しいデータをロードする)暗号化操作も同様に高速化されます。データ・セットを事前に暗号化し、トランスポータブル表領域(TTS)を使用してデータベースにロードすることで、暗号化処理を帯域外で実行します。可能な場合には、この処理をパラレル化します。これには、データベース・インスタンスで必要なTDE鍵を宛先データベースのキーストアにコピーする必要があります。暗号化およびロードに時間枠が決まっている場合、この手順は実行不可能で、これらは逐次実行する必要があります。

- TDE列暗号化の使用を検討してください。表領域全体を暗号化するのではなく、機密で規制対象になる少数の列のみを暗号化します。

- (SGAからは読み込まず、ディスクから直接読み込んで表を完全にスキャンするなど)データ・セット全体の一度での復号化:
データが記憶域から直接読み込まれる表を完全にスキャンする問合せを実行する場合、暗号化のパフォーマンスの低下がみられます。TDE表領域暗号化の特定のパフォーマンスの最適化が省略されます(キャッシングなし)。したがって、透過的データ暗号化はこの種の操作には何もパフォーマンス上のメリットはありません。

次のガイドラインに従います。

- CPUベースの暗号化アクセラレーションを搭載したサーバーでデータベースを実行していることを確認します。

- データがキャッシュから読み込まれる場合、より大容量のSGAサイズで表全体に対するスキャン問合せを再テストします。Oracleイベント番号10949によってダイレクト・パス読取りが無効化されるようにします。

- 表のフル・スキャン操作で少量のデータのみがスキャンされるよう、データベースをパーティション化します。本番データベースでは、このようなシナリオ(つまり、スキャンするデータの総量を制限するシナリオ)でよくパーティション化が使用されます。

- TDE列暗号化の使用を検討してください。表領域全体を暗号化するのではなく、機密で規制対象になる少数の列のみを暗号化します。

第II部 Oracle Data Redactionの使用

第II部では、Oracle Data Redactionの使用方法について説明します。

内容は次のとおりです。

- Oracle Data Redactionの概要

- Oracle Data Redactionの特徴と機能

- Oracle Data Redactionポリシーの構成

- Oracle Enterprise ManagerでのOracle Data Redactionの使用

- Oracle Data RedactionとOracle Database機能の併用

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

8 Oracle Data Redactionの概要

Oracle Data Redactionとは、機密データを、リアルタイムでリダクションする機能です。

内容は次のとおりです。

- Oracle Data Redactionとは

- Oracle Data Redactionを使用する状況

- Oracle Data Redactionを使用する利点

- Oracle Data Redactionのターゲットのユースケース

関連項目:

- Oracle Data Redactionポリシーの作成に関するチュートリアルは、『Oracle Database 2日でセキュリティ・ガイド』を参照してください。

- Oracle Data Redactionでの透過的機密データ保護ポリシーの使用に関する情報は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

Oracle Data Redactionとは

Oracle Data Redactionを使用すると、アプリケーションが発行する問合せから返されるデータをマスク(リダクション)できます。

次の方法のいずれかを使用して、列データをリダクションできます。

- 完全リダクション。列データの内容をすべてリダクションします。問合せを行ったアプリケーション・ユーザーに返される、リダクションされた値は、列のデータ型によって異なります。たとえば、NUMBERデータ型の列はゼロ(0)でリダクションされ、文字データ型は空白1つでリダクションされます。

- 部分リダクション。列データの一部をリダクションします。たとえば、社会保障番号の最後の4桁以外をアスタリスク(*)でリダクションできます。

- 正規表現。正規表現を使用してリダクションするデータのパターンを検索できます。たとえば、正規表現を使用して、文字の長さが変化する可能性のある電子メール・アドレスをリダクションできます。これは、文字データのみで使用するように設計されています。

- ランダム・リダクション。問合せを行ったアプリケーション・ユーザーに表示されるリダクションされたデータは、列のデータ型に応じて、表示されるたびにランダムに生成された値として表示されます。

- リダクションなし。リダクション・タイプNoneを指定するオプションでは、リダクション・ポリシーが定義された表に対する問合せの結果に影響を与えずに、ポリシーの内部動作をテストできます。このオプションを使用して、リダクション・ポリシー定義を本番環境に適用する前にテストできます。

Oracle Databaseは、起動時、およびユーザーがデータにアクセスするとき(つまり問合せ実行時)にリダクションを適用します。このソリューションは、本番システムでも十分の機能します。データがリダクションされている間、処理中のすべてのデータは通常どおりに実行され、バックエンドの参照整合性制約は保持されます。

データ・リダクションは、クレジットカード業界のセキュリティ基準(PCI DSS)やサーベンス・オクスリー法などの業界の規則の順守に役立ちます。

Oracle Data Redactionを使用する状況

アプリケーションおよびアプリケーション・ユーザーがアクセスする必要のある機密データを偽装しなければならない場合には、Oracle Data Redactionを使用します。

データ・リダクションを使用すると、いくつかの異なるリダクション・スタイルを使用して簡単にデータを偽装できます。

Oracle Data Redactionは、特定のアプリケーション・ユーザーに戻される、個人を識別できる情報(PII)の問合せの結果セットから、特定の文字をリダクションする必要がある場合に最適です。たとえば、末尾が4320の米国社会保障番号番号を、***-**-4320のように提示できます。

Oracle Data Redactionは特に、コール・センター・アプリケーションや読取り専用のアプリケーションに適しています。更新を実行してデータベースに書き戻すアプリケーションにOracle Data Redactionを使用する場合は注意してください。リダクションされたデータがこのデータベースに書き戻されることもあるからです。

Oracle Data Redactionを使用する利点

Oracle Data Redactionをデータの保護に使用するといくつかの利点があります。

これらの利点は次のとおりです。

- 異なるスタイルのリダクションから選択できます。

- データは起動時にリダクションされるため、データ・リダクションは、データが常時変更されている環境に非常に適しています。

- 中央となる1か所にリダクション・ポリシーを作成して、そこから簡単に管理できます。

- データ・リダクション・ポリシーを使用して、データ・リダクション・ポリシーがアプリケーション・ユーザーの問合せの結果に適用されるタイミングを決定するために、実行時に使用できるSYS_CONTEXT値に基づいて、様々な種類の関数の条件を作成できます。

Oracle Data Redactionのターゲットのユースケース

Oracle Data Redactionは、一般的なユースケース・シナリオに対応します。

内容は次のとおりです。

- データベース・アプリケーションにおけるOracle Data Redactionの使用

- 非定型データベース問合せにおけるOracle Data Redactionの考慮事項

データベース・アプリケーションにおけるOracle Data Redactionの使用

Oracle Data Redactionは、データベース・アプリケーションに表示される機密データを保護します。

データ・リダクションは、元のデータ型と(オプションで)形式を維持するためアプリケーション・ユーザーに対して透過的です。データは同じバッファ、キャッシュ、記憶域に保持され、呼出し元にSQL問合せの結果が戻される直前に初めて変更されるので、データベースに対して非常に透過的です。リダクションは、基礎となる同じデータベースを使用するすべてのアプリケーションに一貫して適用されます。リダクションされたデータのみが表示されるアプリケーション・ユーザーを指定するには、SYS_CONTEXT関数でデータベースに渡されるアプリケーション・ユーザー情報をチェックします。データは、現在のデータベースまたはアプリケーション・ユーザーの属性に基づいてリダクションでき、特定のリダクション・ポリシーに複数の論理条件を実装できます。また、データ・リダクションは、パフォーマンス・オーバーヘッドを最小化する方法で実装されます。このような特徴から、Oracle Data Redactionは、共通の本番データベースを共有する様々なアプリケーション、分析ツール、レポート・ツールおよび監視ツールを使用する場合に非常に適しています。この主要なターゲットは、アプリケーションの本番データのリダクションですが、Oracle Data Redactionは、テストおよび開発環境の機密データを保護するために、Oracle Enterprise Manager Data Masking and Subsetting Packと組み合せて使用することもできます。

関連項目:

- データ・マスキングおよびサブセッティングの詳細は、Oracle Data Masking and Subsettingガイドを参照してください。

- Oracle Data RedactionとData Masking and Subsetting Pack

非定型データベース問合せにおけるOracle Data Redactionの考慮事項

データベース・ユーザーによって実行される非定型の問合せの機密データをリダクションすると便利な場合に遭遇する可能性があります。

たとえば、本番アプリケーションのサポート中に、ユーザーは、非定型のデータベース問合せを実行して、アプリケーションの緊急な問題のトラブルシューティングを行って修正する必要がある場合があります。これは、データベース・アプリケーションにおけるOracle Data Redactionの使用で説明されているアプリケーション・ベースのシナリオ(通常、SQL問合せのバインドされたセットを生成し、定義されたデータベース・アカウントを使用し、権限が固定されている)とは異なります。

Oracle Data Redactionは、データベースに対して非定型問合せを実行するデータベース・ユーザーにデータが公開されることを防ぐために設計されているわけではありませんが、誤ってデータが公開される危険性を少なくする追加のセキュリティ層として利用できます。そのようなユーザーは、データを変更したり、データベース・スキーマを変更したり、SQL問合せインタフェースを完全に回避する権限があるため、悪質なユーザーは、特定の状況ではデータ・リダクション・ポリシーをバイパスすることができます。

Oracle Databaseのセキュリティ・ツールは、全体的なセキュリティを向上させるために同時に使用するように設計されています。Oracle Data Redactionを補完するものとして1つ以上のこれらのツールをデプロイすることで、全体的なセキュリティ体制を改善することができます。

関連項目:

他の一般的な使用上のガイドラインは、Oracle Data Redactionの一般的な使用上のガイドラインを参照してください。

9 Oracle Data Redactionの特徴と機能

Oracle Data Redactionには、データをリダクションする様々な方法があります。

内容は次のとおりです。

- 全データをリダクションする完全データ・リダクション

- データのセクションをリダクションする部分データ・リダクション

- データのパターンをリダクションする正規表現

- ランダム値を生成するランダム・データ・リダクション

- データ型に基づいた完全、部分およびランダム・リダクションの比較

- テストを目的にリダクションしない場合

全データをリダクションする完全データ・リダクション

完全データ・リダクションでは、表またはビューの指定した列の内容全体がリダクションされます。

デフォルトでは、出力は次のように表示されます。

- 文字データ型: 出力テキストは、空白1つです。

- 数値データ型: 出力テキストはゼロです(0)です。

- 日時データ型: 出力テキストは、2001年1月1日に設定されており、01-JAN-01と表示されます。

完全リダクションがデフォルトで、これは、データ・リダクション・ポリシーで列を指定されているが、function_typeパラメータ設定が指定されていないときに使用されます。完全リダクションにfunction_typeパラメータ設定を設定するには、DBMS_REDACT.ADD_POLICYプロシージャを実行するときに、次の設定を入力します。

function_type    => DBMS_REDACT.FULL

DBMS_REDACT.UPDATE_FULL_REDACTION_VALUESプロシージャを使用すると、完全リダクションの出力を別の値に変更できます。

関連項目:

- 完全リダクション・ポリシーを作成する構文

- デフォルトの完全データ・リダクション値の変更

データのセクションをリダクションする部分データ・リダクション

部分データ・リダクションでは、表示される出力の一部をリダクションします。

実際のデータ内に、リダクションを開始する位置、その位置からリダクションする文字数および使用するリダクション文字を設定できます。このタイプのリダクションは、なんらかの方法でデータがリダクションされたことを、データを表示しているユーザーに明らかにしたい場合に便利です。通常、このタイプのリダクションは、クレジット・カードやID番号に使用します。

部分データ・リダクションでは、データの幅が固定されている必要があることに注意してください。可変長の文字列値を含む列をリダクションする場合、データのパターンをリダクションする正規表現の説明に従って正規表現を使用する必要があります。

部分リダクションを指定するには、DBMS_REDACT.ADD_POLICYプロシージャのfunction_typeパラメータをDBMS_REDACT.PARTIALに設定し、function_parametersパラメータを使用して部分リダクション動作を定義する必要があります。

部分データ・リダクションで表示される出力は、次のとおりです。

- 文字データ型: 部分的にリダクションする場合、987-65-4320という値の社会保障番号(文字データ型内で文字列がハイフンで連結されている)をリダクションすると、次の例のように表示されます。右側のコードは文字データのリダクション方法を指定します。このコードで、実際のデータの期待される入力形式、リダクションされる出力の表示に使用する形式、リダクションの開始位置、リダクションに使用する文字、リダクションする文字数が指定されます。最初の例では、文字データ型の社会保障番号に事前定義された形式(以前のリリースでは「ショートカット」)を使用し、2番目の例では、番号間のハイフン(-)を保持しながら最初の5つの番号をアスタリスク(*)で置換します。

XXX-XX-4320    function_parameters => DBMS_REDACT.REDACT_US_SSN_F5,

***-**-4320    function_parameters => 'VVVFVVFVVVV,VVV-VV-VVVV,*,1,5',

- 数値データ型: 部分的にリダクションされたNUMBERデータ型の社会保障番号987654328は、次のように表示されます。どちらも最初の5桁をリダクションします。最初の例では、NUMBERデータ型の社会保障番号のために設計されている事前定義された形式を使用し、2番目の例では、最初の5桁の番号が9で置換されます。

XXXXX4328    function_parameters => DBMS_REDACT.REDACT_NUM_US_SSN_F5,

999994328    function_parameters => '9,1,5',

- 日時データ型: 部分的にリダクションされた日時の値を単純に別の日付に表示できます。たとえば、日付29-AUG-11 10.20.50.000000 AMは、次のように表示されます。最初の例では、月の日付が02 (d02という設定を使用)にリダクションされ、2番目の例では、月がDEC (m12を使用)にリダクションされます。大文字の値は、実際の月(M)、年(Y)、時間(H)、分(M)および秒(S)を示します。

02-AUG-11 10.20.50.000000 AM   function_parameters  =>  'Md02YHMS',

29-DEC-11 10.20.50.000000 AM   function_parameters  =>  'm12DYHMS',

関連項目:

- 正規表現ベースのリダクション・ポリシーを作成する構文

- 部分リダクション・ポリシーを作成する構文

データのパターンをリダクションする正規表現

正規表現を使用して、パターン検索に基づいて列データの値内にある特定のデータをリダクションできます。

たとえば、ドメインのみが表示されるように電子メール・アドレスのユーザー名をリダクションできます(電子メール・アドレスhpreston@example.comのhprestonを[redacted]に置き換えて、[redacted]@example.comと表示するなど)。リダクションを実行するには、DBMS_REDACT.ADD_POLICYプロシージャのfunction_typeパラメータをDBMS_REDACT.REGEXPに設定し、さらに次のパラメータを使用して、正規表現を作成する必要があります。

- 文字列検索パターン(つまり、検索対象の値)で、例は次のとおりです。

regexp_pattern         => '(.+)@(.+\.[A-Za-z]{2,4})'

この設定では、次の形式のパターンが検索されます。

one_or_more_characters@one_or_more_characters.2-4_characters_in_range_A-Z_or_a-z

- regexp_pattern設定で一致した値を置換する置換文字列です。置換文字列は、主要な正規表現パターンの副次式に後方参照を含めることができます。次の例では、(regexp_pattern設定の) @記号の前にあるデータをテキスト[redacted]に置き換えます。\2設定は、2番目の一致グループであるregexp_pattern設定の(.+\.[A-Za-z]{2,4})を示します。

regexp_replace_string  => '[redacted]@\2'

- データの最初の文字などの文字列検索の文字の開始位置で、例は次のとおりです。

regexp_position        => DBMS_REDACT.RE_BEGINNING

- 実行する検索および置換操作の種類(最初の出現、5回おきの出現、すべて出現)で、例は次のとおりです。

regexp_occurrence      => DBMS_REDACT.RE_ALL

- 検索および置換操作のデフォルトの一致動作で、検索で大/小文字を区別するかどうかの例は次のとおりです(iはこれを大/小文字の区別なしに設定します)。

regexp_match_parameter => 'i

デフォルトのパラメータに加え、電話番号、電子メール・アドレスおよびクレジット・カード番号に、よく使用される正規表現を使用できるように事前定義された形式のセットを使用できます。

関連項目:

正規表現ベースのリダクション・ポリシーを作成する構文

ランダム値を生成するランダム・データ・リダクション

ランダム・データ・リダクションでは、値全体がランダムな値に置換されてリダクションされます。

問合せの結果セットに表示されるリダクションされた値は、アプリケーション・ユーザーが問合せを実行するたびに、ランダムに変更されます。

このタイプのリダクションは、データがリダクションされていることを明らかにしたくない場合に便利です。ランダム・データか実際のデータか区別するのが難しい数値および日時データ型の場合に、特に最適です。

ランダム値として表示される出力は、次のように、リダクションされた列のデータ型によって異なります。

- 文字データ型: ランダムな出力は、文字が混合されています(たとえば、HTU[G{\pjkEWcK)。CHARとVARCHAR2のデータ型では、次に示すように動作が異なります。

- CHARデータ型: リダクションされた出力のキャラクタ・セットは、常に列のキャラクタ・セットと同一になります。リダクションされた出力のバイト長は、常に列定義の長さ(つまり、表の作成時に指定した列の長さ)と同一になります。たとえば、列がCHAR(20)である場合、ユーザー問合せのリダクションされた出力には、ランダムな20文字が提供されます。

- VARCHAR2データ型: VARCHARデータ型のランダム・リダクションでは、リダクションされた出力のキャラクタ・セットは、常に列のキャラクタ・セットと同一になります。リダクションされた出力の長さは、列の実際のデータの長さに基づいて制限されます。実際のデータの長さを超える文字は表示されません。たとえば、列がVARCHAR2(20)で、リダクションされる行に長さ12の実際のデータが含まれている場合、その行に対するユーザー問合せのリダクションされた出力には、ランダムな12文字(20文字ではない)が提供されます。

- 数値データ型: 実際の各数値が、実際のデータの絶対値のモジュロである、ランダムな非負値に置換されてリダクションされます。このリダクション結果は、実際のデータの精度を超えないランダムな数値になります。たとえば、数値987654321は、数値12345678、13579、0または987654320のいずれかに置換されてリダクションされます。数値987654321、99987654321または-1に置換されることはありません。数値-123は、数値122、0または83に置換されてリダクションされますが、数値123、1123または-2のいずれかに置換されることはありません。
前述の例の唯一の例外は、実際の値が-1から9の間の整数である場合です。この場合、実際のデータは、ランダムな非負整数であるmodulo 10に置換されてリダクションされます。

- 日時データ型: 日付データ型の値がランダム・データ・リダクションを使用してリダクションされる場合、Oracle Databaseには、実際のデータの日付と異なるランダムな日付が常に表示されます。

ランダム・リダクションを使用する設定は、次のとおりです。

function_type    => DBMS_REDACT.RANDOM

関連項目:

ランダム・リダクション・ポリシーを作成する構文

データ型に基づいた完全、部分およびランダム・リダクションの比較

完全、部分およびランダムのどのデータ・リダクション方式を使用するかによって、Oracle組込み、ANSI、ユーザー定義、およびオラクル社提供のデータ型に対する影響は異なります。

内容は次のとおりです。

- Oracle組込みデータ型のリダクション機能

- ANSIデータ型のリダクション機能

- ユーザー定義データ型またはオラクル社提供の型のリダクション機能

Oracle組込みデータ型のリダクション機能

Oracle Data Redactionでは、使用されるデータ・リダクション・ポリシーのタイプに応じてOracle組込みデータ型を処理します。

表9-1では、Oracle組込みデータ型に対する、完全、部分およびランダム・リダクションの機能の違いを比較します。

表9-1 Oracle組込みデータ型のリダクション機能

データ型

完全リダクション

部分リダクション

ランダム・リダクション

文字: CHAR、VARCHAR2(たとえばVARCHAR2(20000)などの長いVARCHAR2)、NCHAR、NVARCHAR2

デフォルトのリダクションされた値は、空白1つです。

サポートされているデータ型

サポートされているデータ型

数値: NUMBER、FLOAT、BINARY_FLOAT、BINARY_DOUBLE

デフォルトのリダクションされた値はゼロ(0)です。

サポートされているデータ型

サポートされているデータ型

Raw: LONG、RAW、RAW

サポート外のデータ型

サポート外のデータ型

サポート外のデータ型

日時: DATE、TIMESTAMP、TIMESTAMP WITH TIME ZONE、TIMESTAMP WITH LOCAL TIME ZONE

デフォルトのリダクションされた値は、01-01-01、または01-01-01 01:00:00。

サポートされているデータ型

サポートされているデータ型

インターバル: INTERVAL YEAR TO MONTH、INTERVAL DAY TO SECOND

サポート外のデータ型

サポート外のデータ型

サポート外のデータ型

ラージ・オブジェクト: BFILE

サポート外のデータ型

サポート外のデータ型

サポート外のデータ型

ラージ・オブジェクト: BLOB

Oracleの[redacted]のRAW表現

脚注1

サポート外のデータ型

サポート外のデータ型

ラージ・オブジェクト: CLOB、NCLOB

デフォルトのリダクションされた値は、[redacted]です。

サポート外のデータ型

サポート外のデータ型

Rowid: ROWID、UROWID

サポート外のデータ型

サポート外のデータ型

サポート外のデータ型

脚注1

文字セットを変更した場合、DBMS_REDACT.UPDATE_FULL_REDACTION_VALUESプロシージャを呼び出して、次のように新しい文字セットで値をRAW表現に設定する必要があります。

DECLARE
new_red_blob BLOB;
BEGIN
DBMS_LOB.CREATETEMPORARY(new_red_blob, TRUE);
DBMS_LOB.WRITE(new_red_blob, 10, 1, UTL_RAW.CAST_TO_RAW('[redacted]'));
dbms_redact.update_full_redaction_values(
blob_val      => new_red_blob);
DBMS_LOB.FREETEMPORARY(new_red_blob);
END;
/

このプロシージャの実行後、データベースを再起動します。

DBMS_REDACT.UPDATE_FULL_REDACTION_VALUESプロシージャの使用の詳細は、「デフォルトの完全データ・リダクション値の変更」も参照してください。

ANSIデータ型のリダクション機能

Oracle Data Redactionでは、データ・リダクション・ポリシーのリダクション・タイプに応じて固有の方法でANSIデータ型を変換します。

表9-2では、ANSIデータ型に対する、完全、部分およびランダム・リダクションの機能の違いを比較します。

表9-2 ANSIデータ型のリダクション機能

データ型

変換方法

完全リダクション

部分リダクション

ランダム・リダクション

CHARACTER(n)、

CHAR(n)

CHAR(n)に変換

はい

はい

はい

CHARACTER VARYING(n)、

CHAR VARYING(n)

VARCHAR2(n)に変換

はい

はい

はい

NATIONAL CHARACTER(n)、

NATIONAL CHAR(n),

NCHAR(n)

NCHAR(n)に変換

はい

はい

はい

NATIONAL CHARACTER VARYING(n)、

NATIONAL CHAR VARYING(n)、

NCHAR VARYING(n)

NVARCHAR2(n)に変換

はい

はい

はい

NUMERIC[(p,s)]

DECIMAL[(p,s)]

NUMBER(p,s)に変換

はい

はい

はい

INTEGER

INT

SMALLINT

NUMBER(38)に変換

はい

はい

はい

FLOAT

DOUBLE PRECISION

FLOAT(126)に変換

はい

はい

はい

REAL

FLOAT(63)に変換

はい

はい

はい

GRAPHIC

LONG VARGRAPHIC

VARGRAPHIC

TIME

変換なし

なし

なし

なし

ユーザー定義データ型またはオラクル社提供の型のリダクション機能

Oracle Data Redactionでは、いくつかのデータ型はサポートされていません。

表9-3では、ユーザー定義およびオラクル社提供データ型に対する、完全、部分およびランダム・リダクションの機能の違いを比較します。

表9-3 ユーザー定義データ型またはOracle指定データ型のリダクション機能

データ型またはタイプ

完全リダクション

部分リダクション

ランダム・リダクション

ユーザー定義データ型

サポート外のデータ型

サポート外のデータ型

サポート外のデータ型

Oracle提供の型: 任意の型、XML型、Oracle Spatial型、Oracle Media型

サポート外のデータ型

サポート外のデータ型

サポート外のデータ型

テストを目的にリダクションしない場合

リダクションを実行しないデータ・リダクション・ポリシーを作成できます。

これは、リダクションされたベース表があるが、特定のアプリケーション・ユーザーのビューには実際のデータを常に表示する必要があるケースで便利です。リダクションされた表の新しいビューを作成して、このビューにデータ・リダクション・ポリシーを定義できます。ポリシーは引き続きベース表に存在しますが、DBMS_REDACT.NONE function_type設定を使用してビューにポリシーを作成した場合、アプリケーションがビューを使用して問い合せてもリダクションは実行されません。

第10章 Oracle Data Redactionポリシーの構成

Oracle Data Redactionポリシーでは、表の列タイプおよび使用するリダクションのタイプに応じて、列でデータをどのようにリダクションするかを定義します。

内容は次のとおりです。

- Oracle Data Redactionポリシーについて

- Oracle Data Redactionポリシーを作成できるユーザーは?

- データ・リダクション・ポリシーの計画

- DBMS_REDACT.ADD_POLICYプロシージャの一般的な構文

- データ・リダクション・ポリシーの条件を定義する式の使用

- 完全データ・ポリシーの作成と完全リダクション値の変更

- 部分リダクション・ポリシーの作成

- 正規表現ベースのリダクション・ポリシーの作成

- ランダム・リダクション・ポリシーの作成

- リダクションを使用しないポリシーの作成

- Oracle Data Redactionポリシーからのユーザーの除外

- Oracle Data Redactionポリシーの変更

- 複数列のリダクション

- デフォルトの完全データ・リダクション値の変更

- Oracle Data Redactionポリシーの有効化と無効化

- Oracle Data Redactionポリシーの削除

- チュートリアル: SQL式を使用したリダクションされた値を含むレポートの作成

- Oracle Data Redactionポリシーのデータ・ディクショナリ・ビュー

Oracle Data Redactionポリシーについて

Oracle Data Redactionポリシーでは、表またはビューでリダクションが発生する条件を定義します。

データ・リダクション・ポリシーには、次のような特徴があります。

- データ・リダクション・ポリシーは、実行するリダクションの種類、リダクションの出現方法およびリダクションを実行するタイミングを定義します。Oracle Databaseは、実行時に、データがアプリケーションに戻される直前にリダクションを実行します。

- データ・リダクション・ポリシーでは、値の完全なリダクション、部分的なリダクション、ランダムなリダクションが可能です。さらに、テスト環境でポリシーをテストする場合には、データをまったくリダクションしないようにデータ・リダクション・ポリシーを定義することもできます。

- データ・リダクション・ポリシーは、ポリシー式がTRUEまたはFALSEのどちらを返すかに基づいて、異なるアプリケーション・ユーザーにリダクションされたデータまたは実際のデータのいずれかの表示を許可するポリシー式で定義できます。ポリシー式の評価のブール結果がTRUEであると、リダクションが実行されます。セキュリティ上の理由から、ポリシー式で使用できる関数および演算子は、SYS_CONTEXTなどの少数に限定されています。ユーザー作成関数は使用できません。ポリシー式では、SYS_SESSION_ROLES名前空間とSYS_CONTEXT関数を組み合せて使用し、有効なロールを確認できます。

表10-1に、DBMS_REDACTパッケージのプロシージャを示します。

表10-1 DBMS_REDACTプロシージャ

プロシージャ

説明

DBMS_REDACT.ADD_POLICY

データ・リダクション・ポリシーを表またはビューに追加します

DBMS_REDACT.ALTER_POLICY

データ・リダクション・ポリシーを変更します

DBMS_REDACT.UPDATE_FULL_REDACTION_VALUES

指定されたデータ型の完全にリダクションされた値をグローバルに更新します。データベース・インスタンスを再起動すると、更新された値を使用できます。

DBMS_REDACT.ENABLE_POLICY

データ・リダクション・ポリシーを有効化します

DBMS_REDACT.DISABLE_POLICY

データ・リダクション・ポリシーを無効化します

DBMS_REDACT.DROP_POLICY

データ・リダクション・ポリシーを削除します

関連項目:

- DBMS_REDACT PL/SQLパッケージの詳細は、Oracle Database PL/SQLパッケージおよびタイプ・リファレンスを参照してください。

- Oracle Enterprise Manager Cloud Controlを使用してOracle Data Redactionのポリシーと形式を作成して管理する方法の詳細は、「Oracle Enterprise ManagerでのOracle Data Redactionの使用」を参照してください。

Oracle Data Redactionポリシーを作成できるユーザーは?

データ・リダクションには高機密データの保護が伴うため、信頼できるユーザーのみがOracle Data Redactionポリシーを作成する必要があります。

リダクション・ポリシーを作成するには、DBMS_REDACT PL/SQLパッケージに対するEXECUTE権限が必要です。ユーザーに付与された権限を確認するには、DBA_SYS_PRIVSデータ・ディクショナリ・ビューに問い合せます。

ポリシーで保護される基礎となる表やビューにアクセスする場合、権限は一切必要ありません。

データ・リダクション・ポリシーの計画

Oracle Data Redactionポリシーを作成する前に、サイトのニーズに最も適したデータ・リダクション・ポリシーを計画する必要があります。

1. DBMS_REDACT PL/SQLパッケージに対するEXECUTE権限が付与されていることを確認してください。

2. リダクションする表またはビューの列のデータ型を決定します。

3. この列がOracle Virtual Private Database (VPD) 行フィルタ処理条件で使用されていないことを確認してください。つまり、VPDポリシー関数によって生成されるVPD述語の一部であってはなりません。

4. 実行するリダクションのタイプ(完全、ランダム、部分、正規表現またはなし)を決定します。

5. データ・リダクション・ポリシーを適用するユーザーを決定します。

6. この情報に基づいて、DBMS_REDACT.ADD_POLICYプロシージャを使用てデータ・リダクション・ポリシーを作成します。

7. 複数列のリダクションの説明に従って、追加の列をリダクションするようにポリシーを構成します。

データ・リダクション・ポリシーは、作成後、自動的に有効化され、データをリダクションできるようになります。

DBMS_REDACT.ADD_POLICYプロシージャの一般的な構文

データ・リダクション・ポリシーを作成するには、DBMS_REDACT.ADD_POLICYプロシージャを使用する必要があります。

DBMS_REDACT.ADD_POLICYプロシージャの完全な構文は次のとおりです。

DBMS_REDACT.ADD_POLICY (
object_schema               IN VARCHAR2 := NULL,
object_name                 IN VARCHAR2 := NULL,
policy_name                 IN VARCHAR2,
policy_description          IN VARCHAR2 := NULL,
column_name                 IN VARCHAR2 := NULL,
column_description          IN VARCHAR2 := NULL,
function_type               IN BINARY_INTEGER := DBMS_REDACT.FULL,
function_parameters         IN VARCHAR2 := NULL,
expression                  IN VARCHAR2,
enable                      IN BOOLEAN := TRUE,
regexp_pattern              IN VARCHAR2 := NULL,
regexp_replace_string       IN VARCHAR2 := NULL,
regexp_position             IN BINARY_INTEGER :=1,
regexp_occurrence           IN BINARY_INTEGER :=0,
regexp_match_parameter      IN VARCHAR2 := NULL);

ここでは次のように指定します。

- object_schema: データ・リダクション・ポリシーを適用するオブジェクトのスキーマを指定します。この設定を省略(またはNULLを入力)する場合、Oracle Databaseは現在のユーザー名を使用します。ここでの「現在のユーザー」の意味は、DBMS_REDACT.ADD_POLICYプロシージャを呼び出す場所によって変わる場合があることに注意してください。
たとえば、ユーザーmpikeは、ユーザーfbrownに、mpikeのスキーマ内のmpike.protect_dataという名前の定義者権限のPL/SQLパッケージに対するEXECUTE権限を付与すると仮定します。このパッケージ内から、mpikeは、protect_cust_dataと呼ばれるプロシージャをコード化し、これにより、DBMS_REDACT.ADD_POLICYが呼び出されます。ユーザーmpikeは、object_schemaパラメータをNULLに設定しました。

fbrownがmpike.protect_dataパッケージのprotect_cust_dataプロシージャを呼び出すと、Oracle Databaseは、fbrownのスキーマのcust_dataオブジェクトではなく、mpikeスキーマのオブジェクトcust_dataの周りにデータ・リダクション・ポリシーを定義しようとします。

- object_name: データ・リダクション・ポリシーが適用する表またはビューの名前を指定します。

- policy_name: 作成するポリシーの名前を指定します。この名前は、データベース・インスタンス内で必ず一意である必要があります。REDACTION_POLICIESデータ・ディクショナリ・ビューのPOLICY_NAME列を問い合せることで、既存のデータ・リダクション・ポリシーのリストを検索できます。

- policy_description: ポリシーの目的についての簡単な説明を指定します。

- column_name: データをリダクションする必要がある列を指定します。次の点に注意してください。

- データ・リダクション・ポリシーを複数の列に適用できます。データ・リダクション・ポリシーを複数の列に適用する場合、DBMS_REDACT.ADD_POLICYを使用してポリシーを作成した後、DBMS_REDACT.ALTER_POLICYプロシージャを必要な回数実行して、必要な残りの列それぞれをポリシーに追加します。Oracle Data Redactionポリシーの変更を参照してください。

- 表またはビューに定義できるポリシーは1つだけです。ただし、表に新しいビューを作成できるため、2つ目のリダクション・ポリシーをこの新しいビューに定義することで、この新しいビューに対して問合せを発行するときに、異なる方法で列をリダクションできます。指定された列のリダクション方法を決める際、Oracle Databaseは、ビュー・チェーンの最初のビューのポリシーを使用します。

- 列を指定しない場合(たとえば、NULLを入力)、いずれの列もポリシーによるリダクションは行われません。これにより、ユーザー自身のポリシーを作成して配置できるようになるため、後で準備ができたときに列の仕様を追加することができます。

- Oracle Virtual Private Database (VPD)の行フィルタ処理条件で現在使用されている列は使用しないでください。つまり、列は、VPDポリシー関数によって生成されるVPD述語の一部にすることはできません。(VPDでデータ・リダクションを使用する方法の詳細は、Oracle Data RedactionとOracle Virtual Private Databaseを参照してください。)

- 仮想列にデータ・リダクション・ポリシーを定義することはできません。また、任意の仮想列のSQL式に関連する列にデータ・リダクション・ポリシーを定義することもできません。

- column_description: リダクションする列の簡単な説明を指定します。

- function_type: リダクションのタイプを設定するファンクションを指定します。詳細は、次の各項を参照してください。

- 完全リダクション・ポリシーを作成する構文

- 部分リダクション・ポリシーを作成する構文

- 正規表現ベースのリダクション・ポリシーを作成する構文

- ランダム・リダクション・ポリシーを作成する構文

- リダクションを使用しないポリシーの作成の構文

function_typeパラメータを省略する場合、デフォルトのリダクションfunction_type設定は、DBMS_REDACT.FULLです。

- function_parameters: 部分リダクションのために列のリダクションをどのように表示するかを指定します。部分リダクション・ポリシーを作成する構文を参照してください。

- expression: ポリシーの適用方法を決定するブール型SQL式を指定します。リダクションは、ポリシー式がTRUEと評価された場合にのみ実行されます。データ・リダクション・ポリシーの条件を定義する式の使用を参照してください。

- enable: TRUEに設定すると、作成時にポリシーが有効になります。FALSEに設定すると、無効化されたポリシーとしてポリシーを作成します。デフォルトはTRUEです。ポリシーを作成した後、そのポリシーを無効化または有効化できます。次の項を参照してください。

- Oracle Data Redactionポリシーの無効化

- Oracle Data Redactionポリシーの有効化

- regexp_pattern、regexp_replace_string、regexp_position、regexp_position、regexp_occurrence、regexp_match_parameter: 正規表現を使用してデータを完全に、または部分的にリダクションできます。実際のデータにregexp_patternに一致するものがない場合は完全リダクションが実行されるので、regexp_patternを指定するときは注意してください。列のすべての値が、使用している正規表現のセマンティクスに一致しているか確認します。詳細は、正規表現ベースのリダクション・ポリシーを作成する構文を参照してください。

データ・リダクション・ポリシーの条件を定義する式の使用

DBMS_REDACT.ADD_POLICYプロシージャのexpressionパラメータには、ポリシーが適用される条件を指定します。

内容は次のとおりです。

- データ・リダクション・ポリシーでの式の使用について

- ユーザー環境に基づくリダクション・ポリシーの適用

- データベース・ロールに基づくリダクション・ポリシーの適用

- Oracle Label Securityラベル優位に基づくリダクション・ポリシーの適用

- Application Expressセッション・ステートに基づくリダクション・ポリシーの適用

- すべてのユーザーへのリダクション・ポリシーの適用

データ・リダクション・ポリシーでの式の使用について

DBMS_REDACT.ADD_POLICYおよびDBMS_REDACT.ALTER_POLICYのexpressionパラメータには、リダクションを有効化するためにTRUEに評価される必要があるブール式を定義します。

この式は次のいずれかのファンクションに基づいている必要があります。

- 指定された名前領域を使用するSYS_CONTEXT。SYS_CONTEXTのデフォルトの名前空間は、SESSION_USERおよびCLIENT_IDENTIFIERなどの値を含むUSERENVです。(この関数の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。)使用できるもう一つの名前空間は、各ロールの属性を含むSYS_SESSION_ROLES名前空間です。

- 次のOracle Application Expressファンクション:

- APEX_UTIL.GET_SESSION_STATEファンクションのラッパーであるV

- NV、APEX_UTIL.GET_NUMERIC_SESSION_STATE関数のラッパーです。

これらのAPEX_UTILパッケージ・ファンクションの詳細は、『Oracle Application Express APIリファレンス』を参照してください。

- 『Oracle Label Security管理者ガイド』で説明されている、OLS_LABEL_DOMINATESファンクションは、LBACSYS.OLS_LABEL_DOMINATESファンクションのラッパーです。

式を記述する場合は次のガイドラインに従ってください。

- 使用できる演算子は、=、!=、>、<、>=、<=のみです。

- リダクションの際に式はTRUEに評価される必要があるので、NULLと比較する場合には注意が必要です。SQLでは、値NULLは定義されていないため、NULLと比較すると、FALSEを返す傾向があります。

- expressionパラメータでユーザー作成ファンクションを使用することはできません。

ユーザーSYSおよびEXEMPT REDACTION POLICY権限を持つユーザーでは、すべてのデータ・リダクション・ポリシーがバイパスされるため、問合せの結果はリダクションされないことに注意してください。データ・リダクション・ポリシーから除外されるユーザーの詳細は、次の項を参照してください。

- Oracle Data Redactionポリシーからのユーザーの除外

- Oracle Data RedactionのためのOracle Data Pumpセキュリティ・モデル

ユーザー環境に基づくリダクション・ポリシーの適用

セッション・ユーザー名またはクライアント識別子などユーザーの環境に基づいて、データ・リダクション・ポリシーを適用できます。

- DBMS_REDACT.ADD_POLICY expressionパラメータでSYS_CONTEXTファンクションのUSERENV名前空間を使用して、ユーザー環境に基づいてポリシーを適用します。

たとえば、セッション・ユーザー名psmithにのみポリシーを適用するには、次のようにします。

expression  => 'SYS_CONTEXT(''USERENV'',''SESSION_USER'') = ''PSMITH'''

関連項目:

SYS_CONTEXTファンクションで使用できるネームスペースの詳細は、Oracle Database SQL言語リファレンスを参照してください。

データベース・ロールに基づくリダクション・ポリシーの適用

DBAロールなどのデータベース・ロールに基づいて、データ・リダクション・ポリシーを適用できます。

- SYS_CONTEXTファンクションのSYS_SESSION_ROLES名前空間を使用して、ユーザー・ロールに基づいてポリシーを適用します。
この名前空間には、各ロールの属性が含まれます。指定されたロールが、問合せを行ったアプリケーション・ユーザーに対して有効化されている場合、属性の値はTRUEで、ロールが有効化されていない場合、属性の値はFALSEです。

たとえば、スーパーバイザのみに実際のデータの表示を許可するとします。次の例では、DBMS_REDACT.ADD_POLICY expressionパラメータを使用してポリシーを設定し、supervisorロールが有効化されているアプリケーション・ユーザーには実際のデータを表示し、他のすべてのアプリケーション・ユーザーにはデータをリダクションする方法を示します。

expression  => 'SYS_CONTEXT(''SYS_SESSION_ROLES'',''SUPERVISOR'') = ''FALSE'''

Oracle Label Securityラベル優位に基づくリダクション・ポリシーの適用

Oracle Label Securityラベルの優位性に基づきデータ・リダクション・ポリシーを適用する条件を設定できます。

注意:

この機能は、Oracle Database 12cリリース1 (12.1.0.2)以降で使用可能です。

- パブリック・スタンドアロン・ファンクションOLS_LABEL_DOMINATESを使用して、セッション・ラベルの優位性を確認します。このファンクションは、指定したpolicy_name値のセッション・ラベルがlabelパラメータで指定したラベルよりも優位または同位の場合、1 (TRUE)を戻します。それ以外の場合は0 (FALSE)を戻します。

たとえば、ポリシーhr_ols_polのセッション・ラベルがラベルhsよりも優位でも同位でもない場合のみデータ・リダクション・ポリシーを適用するには、次のように指定します。

expression  => 'OLS_LABEL_DOMINATES (''hr_ols_pol'',''hs'') = 0'

Application Expressセッション・ステートに基づくリダクション・ポリシーの適用

Oracle Application Express (APEX)セッション・ステートに基づいて、データ・リダクション・ポリシーを適用できます。

- DBMS_REDACT.ADD_POLICY expressionパラメータで、次に示すパブリックApplication Express APIのいずれかを使用して、Oracle Application Expressのセッション・ステートに基づいてポリシーを適用します。

- V、APEX_UTIL.GET_SESSION_STATEファンクションのシノニムです。

- NV、 APEX_UTIL.GET_NUMERIC_SESSION_STATEファンクションのシノニムです。

たとえば、G_JOBというアプリケーション項目の値がCLERKとなったときにリダクションを発生させるようにDBMS_REDACT.ADD_POLICYのexpressionパラメータを設定するには次のようにします。

expression => 'V(''APP_USER'') != ''mavis@example.com'' or V(''APP_USER'') is null'

たとえば、これらのようなファンクションを使用することにより、APEXアプリケーションのセッション・ステートに格納されているジョブまたは権限ロールに基づいてデータをリダクションできます。

問合せユーザーがAPEXアプリケーションのコンテキストにないとき(問合せがAPEXフレームワーク外、たとえばSQL*Plusから直接発行されたとき)にリダクションを発生させる場合は、次のようにIS NULL句を使用します。このポリシー式を使用すると、mavisというユーザーの問合せがAPEXアプリケーション内部から発行された場合にのみ、このユーザーに実際のデータが表示されます。それ以外の場合、問合せ結果はリダクションされます。

関連項目:

Oracle Application Express APIリファレンス

すべてのユーザーへのリダクション・ポリシーの適用

フィルタリングを使用しなければ、コンテキストに関係なくポリシーを任意のユーザーに適用できます。

ただし、ユーザーSYSおよびEXEMPT REDACTION POLICY権限を持つユーザーは常にOracle Data Redactionポリシーから除外されることに注意してください。

- SYS以外のユーザーまたはEXEMPT REDACTION POLICY権限が付与されていないユーザーにポリシーを適用するには、TRUEに評価されるDBMS_REDACT.ADD_POLICY expressionパラメータを記述します。

例:

expression  => '1=1'

関連項目:

Oracle Data Redactionポリシーからのユーザーの除外

完全データ・ポリシーの作成と完全リダクション値の変更

完全リダクション・ポリシーを作成して、データ列のすべての内容をリダクションできます。また、必要に応じて、デフォルトの完全リダクション値を変更できます。

内容は次のとおりです。

- 完全リダクション・ポリシーの作成

- デフォルトの完全データ・リダクション値の変更

完全リダクション・ポリシーの作成

完全データ・リダクション・ポリシーでは、データ列のすべての内容がリダクションされます。

内容は次のとおりです。

- 完全データ・リダクション・ポリシーの作成について

- 完全リダクション・ポリシーを作成する構文

- 例: 完全リダクション・ポリシー

- 例: 完全にリダクションされた文字値

完全データ・リダクション・ポリシーの作成について

列のすべてのデータをリダクションするリダクション・ポリシーを設定するには、function_typeパラメータをDBMS_REDACT.FULLに設定する必要があります。

デフォルトでは、NUMBERデータ型の列はゼロ(0)に置き換えられ、文字データ型の列は空白1つに置き換えられます( )。DBMS_REDACT.UPDATE_FULL_REDACTION_VALUESプロシージャを使用することにより、このデフォルトを変更できます。

関連項目:

デフォルトの完全リダクション値を変更する場合には、デフォルトの完全データ・リダクション値の変更を参照してください。

完全リダクション・ポリシーを作成する構文

DBMS_REDACT.ADD_POLICYプロシージャでは、完全リダクション・ポリシーを作成できます。

完全データ・リダクション・ポリシーを作成する場合のDBMS_REDACT.ADD_POLICYフィールドは次のとおりです。

DBMS_REDACT.ADD_POLICY (
object_schema           IN VARCHAR2 := NULL,
object_name             IN VARCHAR2,
column_name             IN VARCHAR2 := NULL,
policy_name             IN VARCHAR2,
function_type           IN BINARY_INTEGER := NULL,
expression              IN VARCHAR2,
enable                  IN BOOLEAN := TRUE);

ここでは次のように指定します。

- object_schema、object_name、column_name、policy_name、expression、enable: 「DBMS_REDACT.ADD_POLICYプロシージャの一般的な構文」の項を参照してください。

- function_type: リダクションのタイプの設定に使用するファンクションを指定します。DBMS_REDACT.FULLと入力します。
function_typeパラメータを省略する場合、デフォルトのリダクションfunction_type設定は、DBMS_REDACT.FULLです。

列のデータ型は、使用が許可されているfunction_type設定を決定することに注意してください。データ型に基づいた完全、部分およびランダム・リダクションの比較を参照してください。

例: 完全リダクション・ポリシー

DBMS_REDACT.ADD_POLICY PL/SQLプロシージャを使用して、完全リダクション・ポリシーを作成できます。

例10-1に、HR.EMPLOYEES表のCOMMISSION_PCT列にすべての値の完全なリダクションを使用する方法を示します。式パラメータは、EXEMPT REDACTION POLICYシステム権限が付与されているユーザーは除き、表の問合せを行った任意のユーザーにポリシーを適用します。(EXEMPT REDACTION POLICYシステム権限の詳細は、Oracle Data Redactionポリシーからのユーザーの除外を参照してください。)

例10-1 完全データ・リダクション・ポリシー

BEGIN
DBMS_REDACT.ADD_POLICY(
object_schema    => 'hr',
object_name      => 'employees',
column_name      => 'commission_pct',
policy_name      => 'redact_com_pct',
function_type    => DBMS_REDACT.FULL,
expression       => '1=1');
END;
/

問合せおよびリダクションされた結果:

SELECT COMMISSION_PCT FROM HR.EMPLOYEES;

COMMISSION_PCT
--------------
0
0
0

例: 完全にリダクションされた文字値

DBMS_REDACT.ADD_POLICY PL/SQLプロシージャを使用して、文字値を完全にリダクションするポリシーを作成できます。

例10-2では、mavis.cust_info表のuser_id列のユーザーIDを完全にリダクションする方法を示しています。user_id列は、VARCHAR2データ型です。出力は空白の文字列です。expression設定により、MGRロールのあるユーザーは、ユーザーIDを表示できます。

例10-2 完全にリダクションされた文字値

BEGIN
DBMS_REDACT.ADD_POLICY(
object_schema   => 'mavis',
object_name     => 'cust_info',
column_name     => 'user_id',
policy_name     => 'redact_cust_user_ids',
function_type   => DBMS_REDACT.FULL,
expression      => 'SYS_CONTEXT(''SYS_SESSION_ROLES'',''MGR'') = ''FALSE''');
END;
/

問合せおよびリダクションされた結果:

SELECT user_id FROM mavis.cust_info;

USER_ID
------------
0
0
0

デフォルトの完全データ・リダクション値の変更

DBMS_REDACT.UPDATE_FULL_REDACTION_VALUESプロシージャを使用すると、デフォルトの完全データ・リダクション値を変更できます。

内容は次のとおりです。

- デフォルトの完全データ・リダクション値の変更について

- DBMS_REDACT.UPDATE_FULL_REDACTION_VALUESプロシージャの構文

- デフォルトの完全データ・リダクション値の変更

デフォルトの完全データ・リダクション値の変更について

完全データ・リダクション・ポリシーで表示されるデフォルトの値を変更できます。

Oracle DatabaseがNUMBERデータ型の列に完全リダクション(DBMS_REDACT.FULL)を実行する場合、デフォルトでは0がリダクションされた値です。これを他の値(たとえば、7)に変更する場合、DBMS_REDACT.UPDATE_FULL_REDACTION_VALUESプロシージャを実行すると、この値を変更できます。この変更は、現在のデータベース・インスタンスのすべてのデータ・リダクション・ポリシーに適用されます。値を有効にするには、変更した後に、データベースを再起動する必要があります。現在の値を検索するには、REDACTION_VALUES_FOR_TYPE_FULLデータ・ディクショナリ・ビューを問い合せます。

この変更は、完全なデータ・リダクションを使用するデータベースのすべてのデータ・リダクション・ポリシーに影響することに注意してください。デフォルトの完全データ・リダクション値を変更する前に、既存の完全データ・リダクション・ポリシーにこの変更が及ぼす影響を確認してください。

DBMS_REDACT.UPDATE_FULL_REDACTION_VALUESプロシージャの構文

DBMS_REDACT.UPDATE_FULL_REDACTION_VALUESプロシージャでは、サポートされている標準のOracle Databaseデータ型を使用できます。

構文は次のとおりです。

DBMS_REDACT.UPDATE_FULL_REDACTION_VALUES (
number_val       IN NUMBER                    NULL,
binfloat_val     IN BINARY_FLOAT              NULL,
bindouble_val    IN BINARY_DOUBLE             NULL,
char_val         IN CHAR                      NULL,
varchar_val      IN VARCHAR2                  NULL,
nchar_val        IN NCHAR                     NULL,
nvarchar_val     IN NVARCHAR2                 NULL,
date_val         IN DATE                      NULL,
ts_val           IN TIMESTAMP                 NULL,
tswtz_val        IN TIMESTAMP WITH TIME ZONE  NULL,
blob_val         IN BLOB                      NULL,
clob_val         IN CLOB                      NULL,
nclob_val        IN NCLOB                     NULL);

ここでは次のように指定します。

- number_valは、NUMBERデータ型の列のデフォルトの値を変更します。

- binfloat_valは、BINARY_FLOATデータ型の列のデフォルトの値を変更します。

- bindouble_valは、BINARY_DOUBLEデータ型の列のデフォルトの値を変更します。

- char_valは、CHARデータ型の列のデフォルトの値を変更します。

- varchar_valは、VARCHAR2データ型の列のデフォルトの値を変更します。

- nchar_valは、NCHARデータ型の列のデフォルトの値を変更します。

- nvarchar_valは、NVARCHAR2データ型の列のデフォルトの値を変更します。

- date_valは、DATEデータ型の列のデフォルトの値を変更します。

- ts_valは、TIMESTAMPデータ型の列のデフォルトの値を変更します。

- tswtz_valは、TIMESTAMP WITH TIME ZONEデータ型の列のデフォルトの値を変更します。

- blob_valは、BLOBデータ型の列のデフォルトの値を変更します。

- clob_valは、CLOBデータ型の列のデフォルトの値を変更します。

- nclobは、NCLOBデータ型の列のデフォルトの値を変更します。

デフォルトの完全データ・リダクション値の変更

デフォルトの完全データ・リダクション値を変更するには、DBMS_REDACT.UPDATE_FULL_REDACTION_VALUESプロシージャを使用します。

1. SYSDBA管理権限を持つユーザーSYSとしてデータベース・インスタンスにログインします。

2. 変更する値を確認します。
たとえば、NUMBERデータ型を使用する列の現在の値を確認します。

SELECT NUMBER_VALUE FROM REDACTION_VALUES_FOR_TYPE_FULL;

NUMBER_VALUE
------------
0

3. DBMS_REDACT.UPDATE_FULL_REDACTION_VALUESプロシージャを実行して値を変更します。
例:

EXEC DBMS_REDACT.UPDATE_FULL_REDACTION_VALUES (number_val => 7);

4. データベース・インスタンスを再起動します。
例:

SHUTDOWN IMMEDIATE

STARTUP

部分リダクション・ポリシーの作成

部分データ・リダクションでは、様々な種類のデータ型についてデータの一部をリダクションできます。

内容は次のとおりです。

- 部分リダクション・ポリシーの作成について

- 部分リダクション・ポリシーを作成する構文

- 固定文字形式を使用した部分リダクション・ポリシーの作成

- 文字データ型を使用した部分リダクション・ポリシーの作成

- 数値データ型を使用した部分リダクション・ポリシーの作成

- 日時データ型を使用した部分リダクション・ポリシーの作成

部分リダクション・ポリシーの作成について

データの部分リダクションでは、ID番号の最初の5桁など、データの一部のみがリダクションされます。

たとえば、クレジット・カードの番号の大半(最後の4桁以外)をアスタリスク(*)でリダクションできます。文字、数値または日時のデータ型を使用する列に対してポリシーを作成できます。文字データ型のリダクションを行うポリシーには、固定文字リダクション形式を使用できます。Enterprise Manager for Oracle Database 12.1.0.7プラグインがシステムにデプロイされている場合は、カスタム・リダクション形式を作成して保存することもできます。

注意:

以前のリリースでは、「形式」のかわりに「ショートカット」という用語が使用されていました。

部分リダクション・ポリシーを作成する構文

DBMS_REDACT.ADD_POLICY文では、アプリケーションに戻されるデータの特定の部分をリダクションするポリシーを作成できます。

部分リダクション・ポリシーを作成する場合の DBMS_REDACT.ADD_POLICYフィールドは次のとおりです。

DBMS_REDACT.ADD_POLICY (
object_schema           IN VARCHAR2 := NULL,
object_name             IN VARCHAR2,
column_name             IN VARCHAR2 := NULL,
policy_name             IN VARCHAR2,
function_type           IN BINARY_INTEGER := NULL,
function_parameters     IN VARCHAR2 := NULL,
expression              IN VARCHAR2,
enable                  IN BOOLEAN := TRUE);

ここでは次のように指定します。

- object_schema、object_name、column_name、policy_name、expression、enable: 「DBMS_REDACT.ADD_POLICYプロシージャの一般的な構文」の項を参照してください

- function_type: リダクションのタイプの設定に使用するファンクションを指定します。DBMS_REDACT.PARTIALと入力します。

- function_parameters: ここで設定するパラメータは、column_nameパラメータに指定された列のデータ型によって異なります。詳細は次の項を参照してください。

- 固定文字形式を使用した部分リダクション・ポリシーの作成

- 文字データ型を使用した部分リダクション・ポリシーの作成

- 数値データ型を使用した部分リダクション・ポリシーの作成

- 日時データ型を使用した部分リダクション・ポリシーの作成

固定文字形式を使用した部分リダクション・ポリシーの作成

DBMS_REDACT.ADD_POLICY function_parametersパラメータを使用することにより、固定文字形式を使用できるようになります。

内容は次のとおりです。

- 固定文字形式の設定

- 例: 固定文字形式を使用した部分リダクション・ポリシー

固定文字形式の設定

Oracle Data Redactionには、固定文字を使用するポリシーを構成するための、特別な事前定義形式が用意されています。

表10-2では、 DBMS_REDACT.ADD_POLICY function_parametersパラメータ形式について説明します。これは、通常リダクションされることが多い社会保障番号、郵便番号およびクレジット・カード(列でVARCHAR2またはNUMBERデータ型のいずれかが使用される)に対して使用できます。

表10-2 部分固定文字リダクションの形式

形式

説明

DBMS_REDACT.REDACT_US_SSN_F5

列がVARCHAR2データ型の場合、社会保障番号の最初の5つの数字をリダクションします。たとえば、番号987-65-4320はXXX-XX-4320になります。

DBMS_REDACT.REDACT_US_SSN_L4

列がVARCHAR2データ型の場合、社会保障番号の最後の4つの数字をリダクションします。たとえば、番号987-65-4320は987-65-XXXXになります。

DBMS_REDACT.REDACT_US_SSN_ENTIRE

列がVARCHAR2データ型の場合、社会保障番号全体をリダクションします。たとえば、番号987-65-4320はXXX-XX-XXXXになります。

DBMS_REDACT.REDACT_NUM_US_SSN_F5

列がNUMBERデータ型の場合、社会保障番号の最初の5つの数字をリダクションします。たとえば、番号987654320はXXXXX4320になります。

DBMS_REDACT.REDACT_NUM_US_SSN_L4

列がNUMBERデータ型の場合、社会保障番号の最後の4つの数字をリダクションします。たとえば、番号987654320は98765XXXXになります。

DBMS_REDACT.REDACT_NUM_US_SSN_ENTIRE

列がNUMBERデータ型の場合、社会保障番号全体をリダクションします。たとえば、番号987654320はXXXXXXXXXになります。

DBMS_REDACT.REDACT_ZIP_CODE

列がVARCHAR2データ型の場合、5桁の郵便番号をリダクションします。たとえば、95476はXXXXXになります。

DBMS_REDACT.REDACT_NUM_ZIP_CODE

列がNUMBERデータ型の場合、5桁の郵便番号をリダクションします。たとえば、95476はXXXXXになります。

DBMS_REDACT.REDACT_DATE_MILLENNIUM

DD-MON-YY形式の日付を01-JAN-00 (2000年1月1日)にリダクションします。

DBMS_REDACT.REDACT_DATE_EPOCH

すべての日付を01-JAN-70にリダクションします。

DBMS_REDACT.REDACT_CCN16_F12

最後の4桁は表示したまま、16桁のクレジット・カード番号をリダクションします。たとえば、5105 1051 0510 5100は****-****-****-5100になります。

関連項目:

その他のDBMS_REDACT.ADD_POLICYパラメータの詳細は、「DBMS_REDACT.ADD_POLICYプロシージャの一般的な構文」を参照してください。

例: 固定文字形式を使用した部分リダクション・ポリシー

DBMS_REDACT.ADD_POLICY PL/SQLプロシージャを使用して、固定文字形式を使用する部分リダクション・ポリシーを作成できます。

例10-3 では、VARCHAR2データ型の列にある社会保障番号をREDACT_US_SSN_F5 形式によってリダクションする方法について説明します。

例10-3 部分的にリダクションされた文字値

BEGIN
DBMS_REDACT.ADD_POLICY(
object_schema       => 'mavis',
object_name         => 'cust_info',
column_name         => 'ssn',
policy_name         => 'redact_cust_ssns3',
function_type       => DBMS_REDACT.PARTIAL,
function_parameters => DBMS_REDACT.REDACT_US_SSN_F5,
expression          => '1=1',
policy_description  => 'Partially redacts 1st 5 digits in SS numbers',
column_description  => 'ssn contains Social Security numbers');
END;
/

問合せおよびリダクションされた結果:

SELECT ssn FROM mavis.cust_info;

SSN
-------
XXX-XX-4320
XXX-XX-4323
XXX-XX-4325
XXX-XX-4329

文字データ型を使用した部分リダクション・ポリシーの作成

DBMS_REDACT.ADD_POLICY function_parametersパラメータを使用することにより、文字データ型をリダクションできるようになります。

内容は次のとおりです。

- 文字データ型の設定

- 例: 文字データ型を使用した部分リダクション・ポリシー

文字データ型の設定

Oracle Data Redactionには、文字データ型を使用するポリシーを構成するための、特別な設定が用意されています。

DBMS_REDACT.ADD_POLICYのfunction_parametersパラメータを設定して文字データ型の部分リダクションを定義するときは、次の順序で次の設定の値を入力します。各値はカンマで区切ります。

注意:

部分リダクションには、固定幅の文字セットを使用する必要があることに注意してください。つまり、リダクションされる各文字は、バイト長が等しい別の文字に置換される必要があります。可変長の文字セット(たとえば、UTF-8)を使用する場合、正規表現ベースのリダクションを使用する必要があります。詳細は、正規表現ベースのリダクション・ポリシーを作成する構文を参照してください。

設定は次のとおりです。

1. 入力形式: データが現在どのようにフォーマットされているかを指定します。クレジット・カード番号の全桁など、リダクションされる可能性のある各文字にVを入力します。クレジット・カード番号のハイフンまたは空白のような書式化文字を使用して書式化する場合、Fを入力します。各文字に、対応するVまたはF値があるか確認します。(入力形式の値は大/小文字を区別しません。)

2. 出力形式: 表示されるデータを書式化する方法を定義します。リダクションされる可能性のある各文字にVを入力します。入力形式の各文字Fをハイフンなど表示される文字に使用する文字に置換します。(出力形式の値は大/小文字を区別しません。)

3. マスク文字: リダクションに使用する文字を指定します。アスタリスク(*)など、リダクションに使用する単一の文字を入力します。

4. 開始する数字位置: リダクションで開始するVの数字位置を指定します。

5. 終了する数字位置: リダクションで終了するVの数字位置を指定します。終了する位置の値を決めるときは、Fの位置を含めないでください。

たとえば、次の設定は、クレジット・カード番号5105 1051 0510 5100の最初の12桁のVをリダクションし、Fの位置(空白)をハイフンに置換することでクレジット・カード番号で通常使用されるスタイルに書式化し、その結果****-****-****-4320と表示されます。

function_parameters  => 'VVVVFVVVVFVVVVFVVVV,VVVV-VVVV-VVVV-VVVV,*,1,12',

関連項目:

その他のDBMS_REDACT.ADD_POLICYパラメータの詳細は、DBMS_REDACT.ADD_POLICYプロシージャの一般的な構文を参照してください。

例: 文字データ型を使用した部分リダクション・ポリシー

DBMS_REDACT.ADD_POLICY PL/SQLプロシージャにより、文字データ型を使用する部分リダクション・ポリシーを作成できます。

例10-4には、VARCHAR2データ型の列にある社会保障番号をリダクションする方法と、社会保障番号に含まれているハイフンを保持する方法を示します。

例10-4 部分的にリダクションされた文字値

BEGIN
DBMS_REDACT.ADD_POLICY(
object_schema       => 'mavis',
object_name         => 'cust_info',
column_name         => 'ssn',
policy_name         => 'redact_cust_ssns2',
function_type       => DBMS_REDACT.PARTIAL,
function_parameters => 'VVVFVVFVVVV,VVV-VV-VVVV,*,1,5',
expression          => '1=1',
policy_description  => 'Partially redacts Social Security numbers',
column_description  => 'ssn contains character Social Security numbers');
END;
/

問合せおよびリダクションされた結果:

SELECT ssn FROM mavis.cust_info;

SSN
-----------
***-**-4320
***-**-4323
***-**-4325
***-**-4329

数値データ型を使用した部分リダクション・ポリシーの作成

DBMS_REDACT.ADD_POLICY function_parametersパラメータを使用することにより、数値データ型をリダクションできるようになります。

内容は次のとおりです。

- 数値データ型の設定

- 例: 数値データ型を使用した部分リダクション・ポリシー

数値データ型の設定

数値データ型の値を設定する場合、マスク文字、開始する数字位置および終了する数字位置を指定する必要があります。

数値データ型の部分リダクションの場合、DBMS_REDACT.ADD_POLICY function_parametersパラメータについて、次の設定項目の値を記載されている順番に入力できます。

1. マスク文字: 表示する文字を指定します。0から9までの数値を入力します。

2. 開始する数字位置: 最初の数字に1を指定するなど、リダクションで開始するの数字位置を指定します。

3. 終了する数字位置: リダクションで終了する数字位置を指定します。

たとえば、次の設定は、社会保障番号987654321の最初の5桁をリダクションし、その結果、999994321と表示されます。

function_parameters  => '9,1,5',

関連項目:

その他のDBMS_REDACT.ADD_POLICYパラメータの詳細は、DBMS_REDACT.ADD_POLICYプロシージャの一般的な構文を参照してください。

例: 数値データ型を使用した部分リダクション・ポリシー

DBMS_REDACT.ADD_POLICYプロシージャにより、数値データ型を使用する部分リダクション・ポリシーを作成できます。

例10-5では、mavis.cust_info表の一連の社会保障番号を、ログインした任意のアプリケーション・ユーザーに対して部分リダクションする方法を示しています。(そのため、expressionパラメータはTRUEと評価されます。)

このタイプのリダクションが役立つのは、文字列ではなく書式設定された数値をアプリケーションが想定している場合です。このシナリオでは、社会保障番号はデータ型NUMBERの列にあります。つまり、ssn列に含まれるのは数字のみで、ハイフンまたは空白など他の文字は含まれせん。

例10-5 部分的にリダクションされたデータ・リダクションの数値

BEGIN
DBMS_REDACT.ADD_POLICY(
object_schema       => 'mavis',
object_name         => 'cust_info',
column_name         => 'ssn',
policy_name         => 'redact_cust_ssns1',
function_type       => DBMS_REDACT.PARTIAL,
function_parameters => '7,1,5',
expression          => '1=1',
policy_description  => 'Partially redacts Social Security numbers',
column_description  => 'ssn contains numeric Social Security numbers');
END;
/

問合せおよびリダクションされた結果:

SELECT ssn FROM mavis.cust_info;

SSN
---------
777774320
777774323
777774325
777774329

日時データ型を使用した部分リダクション・ポリシーの作成

DBMS_REDACT.ADD_POLICY function_parametersパラメータを使用することにより、日時データ型をリダクションできるようになります。

内容は次のとおりです。

- 日時データ型の設定

- 例: 日時データ型を使用した部分リダクション・ポリシー

日時データ型の設定

Oracle Data Redactionには、日時データ型を構成するための特別な設定が用意されています。

日時データ型の部分リダクションの場合、次のDBMS_REDACT.ADD_POLICY function_parametersパラメータ設定項目の値を入力します。

値は次に示す順序で入力します。

1. m: 月をリダクションします。月の名前でリダクションするには、1から12を小文字のmに追加します。たとえば、m5は、MAYと表示されます。リダクションを省略するには、大文字のMを入力します。

2. d: 月の日をリダクションします。月の日でリダクションするには、1から31を小文字のdに追加します。たとえば、d7は、07と表示されます。月の日よりも大きい数値(たとえば、2月に31を入力)を入力すると、その月の最終日(たとえば、28)が表示されます。リダクションを省略するには、大文字のDを入力します。

3. y: 年をリダクションします。年でリダクションするには、1から9999を小文字のyに追加します。たとえば、y1984は、84と表示されます。リダクションを省略するには、大文字のYを入力します。

4. h: 時間をリダクションします。時間でリダクションするには、0から23を小文字のhに追加します。たとえば、h20は、20と表示されます。リダクションを省略するには、大文字のHを入力します。

5. m: 分をリダクションします。分でリダクションするには、0から59を小文字のmに追加します。たとえば、m30は、30と表示されます。リダクションを省略するには、大文字のMを入力します。

6. s: 秒をリダクションします。秒でリダクションするには、0から59を小文字のsに追加します。たとえば、s45は、45と表示されます。リダクションを省略するには、大文字のSを入力します。

関連項目:

その他のDBMS_REDACT.ADD_POLICYパラメータの詳細は、DBMS_REDACT.ADD_POLICYプロシージャの一般的な構文を参照してください。

例: 日時データ型を使用した部分リダクション・ポリシー

DBMS_REDACT.ADD_POLICYプロシージャにより、日時データ型を使用する部分リダクション・ポリシーを作成できます。

例10-6では、日付を部分的にリダクションする方法を示しています。この例では顧客の誕生年をリダクションし、それを13に置き換え、残りの値はそのまま保持します。

例10-6 日時値を使用した部分リダクションによるデータ・リダクション

BEGIN
DBMS_REDACT.ADD_POLICY(
object_schema       => 'mavis',
object_name         => 'cust_info',
column_name         => 'birth_date',
policy_name         => 'redact_cust_bdate',
function_type       => DBMS_REDACT.PARTIAL,
function_parameters => 'mdy2013HMS',
expression          => '1=1',
policy_description  => 'Replaces birth year with 2013',
column_description  => 'birth_date contains customer's birthdate');
END;
/

問合せおよびリダクションされた結果:

SELECT birth_date FROM mavis.cust_info;

BIRTH_DATE
07-DEC-13 09.45.40.000000 AM
12-OCT-13 04.23.29.000000 AM

正規表現ベースのリダクション・ポリシーの作成

正規表現ベースのリダクション・ポリシーでは、検索置換モデルに基づいてデータをリダクションできます。

内容は次のとおりです。

- 正規表現ベースのリダクション・ポリシーの作成について

- 正規表現ベースのリダクション・ポリシーを作成する構文

- 形式を使用した正規表現ベースのリダクション・ポリシー

- カスタム正規表現リダクション・ポリシー

正規表現ベースのリダクション・ポリシーの作成について

正規表現ベースのリダクションでは、リダクションするデータのパターンを検索できます。

たとえば、正規表現を使用して、文字の長さが変化する可能性のある電子メール・アドレスをリダクションできます。これは、文字データのみで使用するように設計されています。検索および置換操作に形式を使用することも、カスタム・パターン形式を作成することもできます。

列内の値のサブセットのリダクションに正規表現は使用できません。REGEXP_REPLACE_STRINGの設定を有効にするには、REGEXP_PATTERN (正規表現パターン)がすべての値に一致する必要があり、REGEXP_REPLACE_STRINGが値を変更する必要があります。

REGEXP_PATTERNが一致しない行では、データ・リダクションはDBMS_REDACT.FULLリダクションを実行します。これにより、一致しない行の実際のデータの表示から、正規表現が列内の値のすべてに一致しない原因となるREGEXP_PATTERNでの誤りのリスクが軽減されます。

さらに、正規表現の置換操作中に、REGEXP_REPLACE_STRING設定の結果として発生する値への変更がない場合、データ・リダクションはDBMS_REDACT.FULLリダクションを実行します。

正規表現ベースのリダクション・ポリシーを作成する構文

DBMS_REDACT.ADD_POLICYプロシージャのregexp_*パラメータによって、正規表現ベースのリダクション・ポリシーを作成できます。

正規表現ベース完全データ・リダクション・ポリシーを作成する場合のDBMS_REDACT.ADD_POLICYフィールドは次のとおりです。

DBMS_REDACT.ADD_POLICY (
object_schema           IN VARCHAR2 := NULL,
object_name             IN VARCHAR2,
column_name             IN VARCHAR2 := NULL,
policy_name             IN VARCHAR2,
function_type           IN BINARY_INTEGER := NULL,
expression              IN VARCHAR2,
enable                  IN BOOLEAN := TRUE,
regexp_pattern          IN VARCHAR2 := NULL,
regexp_replace_string   IN VARCHAR2 := NULL,
regexp_position         IN BINARY_INTEGER := 1,
regexp_occurrence       IN BINARY_INTEGER := 0,
regexp_match_parameter  IN VARCHAR2 := NULL);

ここでは次のように指定します。

- object_schema、object_name、column_name、policy_name、expression、enable: 「DBMS_REDACT.ADD_POLICYプロシージャの一般的な構文」の項を参照してください。

- function_type: リダクションのタイプの設定に使用するファンクションを指定します。DBMS_REDACT.REGEXPと入力します。
次の点に注意してください。

- function_typeパラメータをDBMS_REDACT.REGEXPに設定すると、function_parametersパラメータを省略します。

- 正規表現(regexp_pattern、regexp_replace、regexp_position、regexp_occurrenceおよびregexp_match_parameter)を、pattern、replace、position、occurrenceおよびmatch_parameter引数をREGEXP_REPLACE SQLファンクションに指定するときとほぼ同じ方法で指定します。REGEXP_REPLACE SQLファンクションの詳細は、Oracle Database SQL言語リファレンスを参照してください。

- regexp_pattern: 一致する必要のあるデータの検索パターンを説明します。一致が見つかった場合、Oracle Databaseは、regexp_replace_string設定で指定されたとおりにデータを置換します。詳細は、次の各項を参照してください。

- 形式を使用した正規表現ベースのリダクション・ポリシー

- カスタム正規表現リダクション・ポリシー

- regexp_replace_string: データのリダクション方法を指定します。詳細は、次の各項を参照してください。

- 形式を使用した正規表現ベースのリダクション・ポリシー

- カスタム正規表現リダクション・ポリシー

- regexp_position: 文字列検索の開始位置を指定します。入力する値は、Oracle Databaseが検索を開始するcolumn_nameデータの文字を示す正の整数です。デフォルトは、1またはRE_BEGINNING形式で、Oracle Databaseがcolumn_nameデータの最初の文字で検索を開始することを意味します。

- regexp_occurrence: 検索および置換操作の実行方法を指定します。入力する値は、置換操作の回数を示す正の整数です。

- 0またはRE_ALL形式を指定する場合、Oracle Databaseは、一致したすべてのものを置換します。

- RE_FIRST形式を指定する場合、Oracle Databaseは、最初に一致したものを置換します。

- 正の整数nを指定すると、Oracle Databaseは、n番目の一致を置換します。

出現が1より大きい場合、1番目のパターンが検出された後に続く1文字目から、2番目(以降)の出現を検索します。

- regexp_match_parameter: ファンクションが持つデフォルトの照合動作を変更できるテキスト・リテラルを指定します。このパラメータの動作は、REGEXP_REPLACE SQLファンクションのこのファンクションの動作と同じです。詳細は、Oracle Database SQL言語リファレンスを参照してください。
大文字と小文字を区別せずに検索をフィルタするには、RE_MATCH_CASE_INSENSITIVE形式を指定します。

形式を使用した正規表現ベースのリダクション・ポリシー

DBMS_REDACT.ADD_POLICYプロシージャ内のregexp_patternパラメータとregexp_replace_stringパラメータの両方に対して形式を使用できます。

内容は次のとおりです。

- 正規表現の形式

- 例: 形式を使用した正規表現リダクション・ポリシー

正規表現の形式

正規表現の形式によって、クレジット・カード番号の数を置換する場合などによく使用される表現を表します。

表10-3では、DBMS_REDACT.ADD_POLICYプロシージャ内のregexp_patternパラメータで使用できる形式について説明します。

表10-3 regexp_patternパラメータの形式

形式

説明

DBMS_REDACT.RE_PATTERN_ANY_DIGIT

任意の桁を検索します。識別されたパターンを、regexp_replace_stringパラメータで指定された文字に置き換えます。DBMS_REDACT.RE_PATTERN_ANY_DIGITは、regexp_replace_stringパラメータの次の値でよく使用されます。

regexp_replace_string => DBMS_REDACT.RE_REDACT_WITH_SINGLE_X,

この設定によって、一致した任意の桁がXの文字に置換されます。

次の設定では、一致した任意の桁が1の文字に置換されます。

regexp_replace_string => DBMS_REDACT.RE_REDACT_WITH_SINGLE_1,

DBMS_REDACT.RE_PATTERN_CC_L6_T4

先頭6桁および末尾4桁を持つ任意のクレジット・カードの中央の桁を検索します。識別されたパターンを、regexp_replace_stringパラメータで指定された文字に置き換えます。

この形式で使用する適切なregexp_replace_string設定はDBMS_REDACT.RE_REDACT_CC_MIDDLE_DIGITSです。これによって、先頭6桁と末尾4桁を実際のデータとして残すすべてのクレジット・カードが検索されます。その後、中央の桁がリダクションされます。

DBMS_REDACT.RE_PATTERN_US_PHONE

任意の米国の電話番号を検索します。識別されたパターンを、regexp_replace_stringパラメータで指定された文字に置き換えます。

この形式で使用する必要のある適切なregexp_replace_string設定はDBMS_REDACT.RE_REDACT_US_PHONE_L7であり、これによって米国の電話番号が検索され、その後、最後の7桁がリダクションされます。

DBMS_REDACT.RE_PATTERN_EMAIL_ADDRESS

任意の電子メール・アドレスを検索します。識別されたパターンを、regexp_replace_stringパラメータで指定された文字に置き換えます。

この形式で使用できる適切なregexp_replace_string設定は次のとおりです。

RE_REDACT_EMAIL_NAME: 任意の電子メール・アドレスを検索して電子メール・ユーザー名をリダクションします。

RE_REDACT_EMAIL_DOMAIN: 任意の電子メール・アドレスを検索して電子メール・ドメインをリダクションします。

RE_REDACT_EMAIL_ENTIRE: 任意の電子メール・アドレスを検索して電子メール・アドレス全体をリダクションします。

DBMS_REDACT.RE_PATTERN_IP_ADDRESS

任意のIPアドレスを検索します。識別されたパターンを、regexp_replace_stringパラメータで指定された文字に置き換えます。

この形式で使用する必要のある適切なregexp_replace_string設定はDBMS_REDACT.RE_REDACT_IP_L3であり、これによってIPアドレスにおけるドット付きの10進文字列表現の最後のセクションが、リダクションされたことを示す文字の999に置換されます。

表10-4では、DBMS_REDACT.ADD_POLICYプロシージャ内のregexp_replace_stringパラメータで使用できる形式について説明します。

表10-4 regexp_replace_stringパラメータの形式

形式

説明

DBMS_REDACT.RE_REDACT_WITH_SINGLE_X

実際のデータの各文字を単一の文字Xで置換します。たとえば、クレジット・カード番号5105 1051 0510 5100をXXXX XXXX XXXX XXXXに置換できます。

DBMS_REDACT.RE_REDACT_WITH_SINGLE_1

実際のデータの各桁を1桁の数字1で置換します。たとえば、クレジット・カード番号5105 1051 0510 5100を1111 1111 1111 1111に置換できます。

DBMS_REDACT.RE_REDACT_CC_MIDDLE_DIGITS

クレジット・カード番号の中央の桁を、RE_PATTERN_CC_L6_T4形式を使用したregexp_patternパラメータの設定で指定したとおりにリダクションします。このリダクションにより、リダクションされる各文字はXに置換されます。たとえば、クレジット・カード番号5105 1051 0510 5100を5105 10XX XXXX 5100に置換できます。

DBMS_REDACT.RE_REDACT_PHONE_L7

米国の電話番号の最後の7桁を、RE_PATTERN_US_PHONE形式を使用したregexp_patternパラメータの設定で指定したとおりにリダクションします。このリダクションにより、リダクションされる各文字はXに置換されます。この設定はハイフンで連結された電話番号にのみ適用され、空白を含む電話番号には適用されません。たとえば、電話番号415-555-0100は、415-XXX-XXXXに置換できます。

DBMS_REDACT.RE_REDACT_EMAIL_NAME

電子メール・アドレスを、RE_PATTERN_EMAIL_ADDRESS形式を使用したregexp_patternパラメータの設定で指定したとおりにリダクションします。このリダクションにより、電子メール・ユーザー名は4つの文字xに置換されます。たとえば、電子メール・アドレスpsmith@example.comは、xxxx@example.comに置換されます。

DBMS_REDACT.RE_REDACT_EMAIL_DOMAIN

電子メール・ドメイン名を、RE_PATTERN_EMAIL_ADDRESS形式を使用したregexp_patternパラメータの設定で指定したとおりにリダクションします。このリダクションにより、ドメインは5つの文字xに置換されます。たとえば、電子メール・アドレスpsmith@example.comは、psmith@xxxxx.comに置換できます。

DBMS_REDACT.RE_REDACT_IP_L3

IPアドレスの最後の3桁を、RE_PATTERN_IP_ADDRESS形式を使用したregexp_patternパラメータの設定で指定したとおりにリダクションします。たとえば、IPアドレス192.0.2.254は、無効なIPアドレスである192.0.2.999に置換されます。

関連項目:

その他のDBMS_REDACT.ADD_POLICYパラメータの詳細は、DBMS_REDACT.ADD_POLICYプロシージャの一般的な構文を参照してください。

例: 形式を使用した正規表現リダクション・ポリシー

DBMS_REDACT.ADD_POLICY PL/SQLプロシージャを使用して、形式を使用した正規表現リダクション・ポリシーを作成できます。

例10-7では、正規表現形式を使用してクレジット・カード番号をリダクションする方法を示しています。

例10-7 正規表現データ・リダクション文字値

BEGIN
DBMS_REDACT.ADD_POLICY(
object_schema          => 'mavis',
object_name            => 'cust_info',
column_name            => 'cc_num',
policy_name            => 'redact_cust_cc_nums',
function_type          => DBMS_REDACT.REGEXP,
function_parameters    => NULL,
expression             => '1=1',
regexp_pattern         => DBMS_REDACT.RE_PATTERN_CC_L6_T4,
regexp_replace_string  => DBMS_REDACT.RE_REDACT_CC_MIDDLE_DIGITS,
regexp_position        => DBMS_REDACT.RE_BEGINNING,
regexp_occurrence      => DBMS_REDACT.RE_FIRST,
regexp_match_parameter => DBMS_REDACT.RE_MATCH_CASE_INSENSITIVE,
policy_description     => 'Regular expressions to redact credit card numbers',
column_description     => 'cc_num contains customer credit card numbers');
END;
/

問合せおよびリダクションされた結果:

SELECT cc_num FROM mavis.cust_info;

CC_NUM
-------
401288XXXXXX1881
411111XXXXXX1111
555555XXXXXX1111
511111XXXXXX1118

カスタム正規表現リダクション・ポリシー

データ・リダクション・ポリシーで正規表現をカスタマイズできます。

内容は次のとおりです。

- カスタム正規表現の設定

- 例: カスタム正規表現リダクション・ポリシー

カスタム正規表現の設定

Oracle Data Redactionには、正規表現を使用するポリシーを構成するための、特別な設定が用意されています。

カスタム正規表現リダクション・ポリシーを作成するには、DBMS_REDACT.ADD_POLICYプロシージャで次のパラメータを使用します。

- regexp_pattern: このパターンは通常テキスト・リテラルであり、データ型はCHAR、VARCHAR2、NCHARまたはNVARCHAR2のいずれかになります。パターンには、 512バイトまで入力できます。regexp_patternパラメータの正規表現を記述する方法の詳細は、『Oracle Database SQL言語リファレンス』にあるREGEXP_REPLACE SQL関数のpattern引数の説明を参照してください(データ・リダクションがサポートする正規表現の一致は、REGEXP_REPLACE SQL関数のものとよく似ているため)。

- regexp_replace_string: データ型はCHAR、VARCHAR2、NCHARまたはNVARCHAR2のいずれかになります。regexp_replace_stringには、最大500個の部分正規表現への後方参照を\nという書式で指定でき、nは、1から9の数値です。regexp_replace_string設定にバックスラッシュ(\)を含める場合、その前にエスケープ文字(これもバックスラッシュ)を付ける必要があります。たとえば、一致したパターンを文字どおり\2に置換するには(それを一致したパターンで2番目に一致した部分正規表現に置換するのではない場合)、regexp_replace_string設定に\\2を入力します。詳細は、Oracle Database SQL言語リファレンスを参照してください。

関連項目:

その他のDBMS_REDACT.ADD_POLICYパラメータの詳細は、DBMS_REDACT.ADD_POLICYプロシージャの一般的な構文を参照してください。

例: カスタム正規表現リダクション・ポリシー

DBMS_REDACT.ADD_POLICYプロシージャのregexp*パラメータによって、カスタム正規表現リダクション・ポリシーを作成できます。

例10-8では、emp_id列データをリダクションする正規表現の使用方法を示しています。次の例では、regexp_patternパラメータとregexp_replace_stringパラメータが組み合されて、最初に9桁のパターンが検索されます。参照用に、それらは最初の3桁、次の2桁、最後の4桁を含む3つのグループに分割されます。その後、9桁すべてが、元のパターンで検索された3番目のグループ(最後の4桁)と連結されたXXXXXに置換されます。

問合せおよびリダクションされた結果:

SELECT emp_id FROM mavis.cust_info;

EMP_ID
------------
XXXXX1234
XXXXX5678

例10-8 正規表現を使用した部分的にリダクションされたデータ・リダクション

BEGIN
DBMS_REDACT.ADD_POLICY(
object_schema          => 'mavis',
object_name            => 'cust_info',
column_name            => 'emp_id',
policy_name            => 'redact_cust_ids',
function_type          => DBMS_REDACT.REGEXP,
expression             => '1=1',
regexp_pattern         => '(\d\d\d)(\d\d)(\d\d\d\d)',
regexp_replace_string  => 'XXXXX\3',
regexp_position        => 1,
regexp_occurrence      => 0,
regexp_match_parameter => 'i',
policy_description     => 'Redacts customer IDs using regular expression',
column_description     => 'emp_id contains employee ID numbers');
END;
/

ランダム・リダクション・ポリシーの作成

ランダム・リダクション・ポリシーは、リダクションされたデータをランダムに生成した値(Ukjsl32[[]]]sなど)で表します。

内容は次のとおりです。

- ランダム・リダクション・ポリシーを作成する構文

- 例: ランダム・リダクション・ポリシー

ランダム・リダクション・ポリシーを作成する構文

ランダム・リダクション・ポリシーでは、問合せを行ったアプリケーション・ユーザーに対し、列のデータ型に基づいてランダムに生成された値によるリダクション済のデータが表示されます。

LOB列がサポートされていないことに注意してください。

ランダム・リダクション・ポリシーを作成する場合の DBMS_REDACT.ADD_POLICYフィールドは次のとおりです。

DBMS_REDACT.ADD_POLICY (
object_schema           IN VARCHAR2 := NULL,
object_name             IN VARCHAR2,
column_name             IN VARCHAR2 := NULL,
policy_name             IN VARCHAR2,
function_type           IN BINARY_INTEGER := NULL,
expression              IN VARCHAR2,
enable                  IN BOOLEAN := TRUE);

ここでは次のように指定します。

- object_schema、object_name、column_name、policy_name、expression、enable: 「DBMS_REDACT.ADD_POLICYプロシージャの一般的な構文」の項を参照してください。

- function_type: リダクションのタイプの設定に使用するファンクションを指定します。DBMS_REDACT.RANDOMと入力します。
function_typeパラメータを省略する場合、デフォルトのリダクションfunction_type設定は、DBMS_REDACT.FULLです。

列のデータ型は、使用が許可されているfunction_type設定を決定することに注意してください。データ型に基づいた完全、部分およびランダム・リダクションの比較を参照してください。

例: ランダム・リダクション・ポリシー

DBMS_REDACT.ADD_POLICY PL/SQLプロシージャを使用して、ランダム・リダクション・ポリシーを作成できます。

例10-9では、ランダム値の生成方法を示しています。SELECT文を実行するたびに、出力は異なります。

例10-9 ランダムにリダクションされたデータ・リダクションの値

BEGIN
DBMS_REDACT.ADD_POLICY(
object_schema   => 'mavis',
object_name     => 'cust_info',
column_name     => 'login_username',
policy_name     => 'redact_cust_rand_username',
function_type   => DBMS_REDACT.RANDOM,
expression      => 'SYS_CONTEXT(''USERENV'',''SESSION_USER'') = ''APP_USER''');
END;
/

問合せおよびリダクションされた結果:

SELECT login_username FROM mavis.cust_info;

LOGIN_USERNAME
--------------
N[CG{\pTVcK

リダクションを使用しないポリシーの作成

開発環境でポリシーをテストする場合には、まったくリダクションを使用しないポリシーを作成できます。

内容は次のとおりです。

- リダクションを使用しないポリシーの作成の構文

- 例: リダクションを実行しない

リダクションを使用しないポリシーの作成の構文

リダクション・タイプNoneを指定するオプションを使用して、リダクション・ポリシーの内部動作をテストできます。

リダクション・タイプNoneは、ポリシーが定義された表に対する問合せの結果に影響を与えません。このオプションを使用して、リダクション・ポリシー定義を本番環境に適用する前にテストできます。LOB列がサポートされていないことに注意してください。

リダクションを使用しないポリシーを作成する場合の DBMS_REDACT.ADD_POLICYフィールドは次のとおりです。

DBMS_REDACT.ADD_POLICY (
object_schema           IN VARCHAR2 := NULL,
object_name             IN VARCHAR2,
column_name             IN VARCHAR2 := NULL,
policy_name             IN VARCHAR2,
function_type           IN BINARY_INTEGER := NULL,
expression              IN VARCHAR2,
enable                  IN BOOLEAN := TRUE);

ここでは次のように指定します。

- object_schema、object_name、column_name、policy_name、expression、enable: 「DBMS_REDACT.ADD_POLICYプロシージャの一般的な構文」の項を参照してください。

- function_type: データ・リダクションのタイプの設定に使用するファンクションを指定します。DBMS_REDACT.NONEと入力します。
function_typeパラメータを省略する場合、デフォルトのリダクションfunction_type設定は、DBMS_REDACT.FULLです。

例: リダクションを実行しない

DBMS_REDACT.ADD_POLICYプロシージャによって、リダクションを実行しないポリシーを作成できます。

例10-10では、表示されている値のいずれもリダクションしないデータ・リダクション・ポリシーの生成方法を示しています。

例10-10 リダクションされないデータ・リダクション値

BEGIN
DBMS_REDACT.ADD_POLICY(
object_schema    => 'mavis',
object_name      => 'cust_info',
column_name      => 'user_name',
policy_name      => 'redact_cust_no_vals',
function_type    => DBMS_REDACT.NONE,
expression       => '1=1');
END;
/

問合せおよびリダクションされた結果:

SELECT user_name FROM mavis.cust_info;

USER_NAME
----------
IDA NEAU

Oracle Data Redactionポリシーからのユーザーの除外

アクセスしたデータにOracle Data Redactionポリシーを適用しないように、ユーザーを除外することができます。

そのためには、そのユーザーにEXEMPT REDACTION POLICYシステム権限を付与する必要があります。この権限は信頼できるユーザーにのみ付与してください。

また、この権限を付与されているユーザーに加え、ユーザーSYSも、すべてのデータ・リダクション・ポリシーから除外されます。データ・リダクション・ポリシーを作成するユーザーは、そのユーザーがユーザーSYSであるか、またはEXEMPT REDACTION POLICYシステム権限が付与されている場合を除き、デフォルトでは、データ・リダクション・ポリシーから除外されません。

次の点に注意してください。

- 表に対するINSERT権限があるユーザーは、データ・リダクション・ポリシーがテーブルに存在するかどうかにかかわらず、リダクションされた列に値を挿入できます。データ・リダクションは、ユーザーが発行したSQL SELECT文(つまり、問合せ)のみに影響し、ユーザーが発行するその他のSQL(INSERT、UPDATEまたはDELETE文など)には影響しません。(この例の例外は、次の箇条書きを参照してください。)

- 選択されている列(ソース列)のいずれかがデータ・リダクション・ポリシーで保護されている場合、ユーザーは、EXEMPT REDACTION POLICYシステム権限が付与されていないかぎり、CREATE TABLE AS SELECTを実行できません(同様に、ソースがリダクションされた列である場合、DML操作も実行できません)。

- EXEMPT REDACTION POLICYシステム権限は、DBAロールに含まれますが、この権限は、DBAロールが付与された場合のWITH ADMIN OPTIONには含まれないので、明示的にユーザーに付与される必要があります。DBAロールには、EXEMPT REDACTION POLICYシステム権限が付与されるEXP_FULL_DATABASEロールが含まれるため、DBAロールが付与されたユーザーはリダクション・ポリシーから除外されます。

関連項目:

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

- Oracle Data Pumpの権限によるEXEMPT REDACTION POLICYシステム権限への影響の詳細は、Oracle Data RedactionのためのOracle Data Pumpセキュリティ・モデルを参照してください。

Oracle Data Redactionポリシーの変更

DBMS_REDACT.ALTER_POLICYプロシージャでは、Oracle Data Redactionポリシーを変更できます。

内容は次のとおりです。

- Oracle Data Redactionポリシーの変更について

- DBMS_REDACT.ALTER_POLICYプロシージャの構文

- DBMS_REDACT.ALTER_POLICY操作に必要なパラメータ

- チュートリアル: Oracle Data Redactionポリシーの変更

Oracle Data Redactionポリシーの変更について

DBMS_REDACT.ALTER_POLICYプロシージャは、データ・リダクション・ポリシーを変更します。

ポリシーがすでに有効化されている場合は、最初に無効化する必要はなく、またポリシーを変更した後でもポリシーは有効化された状態が維持されます。

REDACTION_POLICIESデータ・ディクショナリ・ビューのPOLICY_NAME列を問い合せて、既存のデータ・リダクション・ポリシーの名前を検索したり、REDACTION_COLUMNSビューを問い合せて、ポリシー内に指定された列、関数およびパラメータに関する情報を検索できます。完全データ・リダクションを使用するポリシーを現在の値から検索するには、REDACTION_VALUES_FOR_TYPE_FULLデータ・ディクショナリ・ビューを問い合せます。

actionパラメータは、実行する変更の型を指定します。このプロシージャを実行するときは、少なくともobject_nameおよびpolicy_nameパラメータを含める必要があります。

DBMS_REDACT.ALTER_POLICYプロシージャの構文

DBMS_REDACT.ALTER_POLICYプロシージャの構文を使用して、すべてのタイプのデータ・リダクション・ポリシーを変更できます。

DBMS_REDACT.ALTER_POLICYプロシージャの構文は次のとおりです。

DBMS_REDACT.ALTER_POLICY (
object_schema          IN VARCHAR2 := NULL,
object_name            IN VARCHAR2 := NULL,
policy_name            IN VARCHAR2,
action                 IN BINARY_INTEGER := DBMS_REDACT.ADD_COLUMN,
column_name            IN VARCHAR2 := NULL,
function_type          IN BINARY_INTEGER := DBMS_REDACT.FULL,
function_parameters    IN VARCHAR2 := NULL,
expression             IN VARCHAR2 := NULL,
regexp_pattern         IN VARCHAR2 := NULL,
regexp_replace_string  IN VARCHAR2 := NULL,
regexp_position        IN BINARY_INTEGER := NULL,
regexp_occurrence      IN BINARY_INTEGER := NULL,
regexp_match_parameter IN VARCHAR2 := NULL,
policy_description     IN VARCHAR2 := NULL,
column_description     IN VARCHAR2 := NULL);

ここでは次のように指定します。

- action: 次のいずれかの値を1つ選択し、使用するアクションの種類を定義します。

- DBMS_REDACT.MODIFY_COLUMN (column_nameの値を変更する場合)

- DBMS_REDACT.ADD_COLUMN ((ポリシーですでに保護されている列に加えて)リダクションのために新しい列を追加する場合)この設定はactionパラメータのデフォルトです。

- DBMS_REDACT.DROP_COLUMN (列からリダクションを削除する場合)。

- DBMS_REDACT.MODIFY_EXPRESSION (expressionの値を変更する場合)各ポリシーに指定できるポリシー式は1つのみです。つまり、ポリシー式を変更する際は、既存のポリシー式を新しいポリシー式で置換します。

- DBMS_REDACT.SET_POLICY_DESCRIPTION (ポリシーの説明を変更する場合)

- DBMS_REDACT.SET_COLUMN_DESCRIPTION (列の説明を変更する場合)

関連項目:

- DBMS_REDACT.ALTER_POLICY操作に必要なパラメータ

- 残りのパラメータの詳細は、DBMS_REDACT.ADD_POLICYプロシージャの一般的な構文を参照してください。

DBMS_REDACT.ALTER_POLICY操作に必要なパラメータ

DBMS_REDACT.ALTER_POLICYプロシージャには、列の追加や変更などの様々な操作を実行できるパラメータが用意されています。

表10-5は、これらのパラメータの組合せを示しています。

表10-5 様々なDBMS_REDACT.ALTER_POLICYの操作に必要なパラメータ

変更内容

設定パラメータ

列の追加または変更

- action (DBMS_REDACT.MODIFY_COLUMN)

- column_name

- function_type

- function_parameters (必要な場合)

- regexp* (必要な場合)

ポリシー式の変更

- action (DBMS_REDACT.MODIFY_EXPRESSION)

- expression

ポリシーの説明の変更

- action (DBMS_REDACT.SET_POLICY_DESCRIPTION)

- policy_description

列の説明の変更

- action (DBMS_REDACT.SET_COLUMN_DESCRIPTION)

- column_description

列の削除

- action (DBMS_REDACT.DROP_COLUMN)

- column_name

チュートリアル: Oracle Data Redactionポリシーの変更

列ごとに独自のリダクション設定を使用して、表またはビューの複数の列をリダクションできます。

この項の演習は、データ・リダクション・ポリシーを変更して、複数の列をリダクションする方法を示しています。また、ポリシーのexpression設定を変更する方法も示しています。これを実行するには、各段階でDBMS_REDACT.ALTER_POLICYプロシージャを実行する必要があります。

1. ユーザーの作成およびそれらのユーザーへの権限の付与を行う権限を持つユーザーとして接続します。
例:

CONNECT sec_admin
Enter password: password

2. 次のユーザーを作成します。

GRANT CREATE SESSION TO dr_admin IDENTIFIED BY password;
GRANT CREATE SESSION TO sales_rep IDENTIFIED BY password;
GRANT CREATE SESSION TO support_rep IDENTIFIED BY password;

3. ユーザーdr_adminに、DBMS_REDACT PL/SQLパッケージに対するEXECUTEを付与します。

GRANT EXECUTE ON DBMS_REDACT TO dr_admin;

4. ユーザーOEとして接続します。

CONNECT OE
Enter password: password

5. 顧客のクレジット・カード情報を含む表を作成し移入します。

CREATE TABLE cust_order_info(
first_name varchar2(20),
last_name varchar2(20),
address varchar2(30),
city varchar2(30),
state varchar2(3),
zip varchar2(5),
cc_num varchar(19),
cc_exp varchar2(7));

INSERT INTO cust_order_info VALUES ('Jane','Dough','39 Mockingbird Lane', 'San Francisco', 'CA', 94114, '5105 1051 0510 5100', '10/2018');
INSERT INTO cust_order_info VALUES ('Mary','Hightower','2319 Maple Street', 'Sonoma', 'CA', 95476, '5111 1111 1111 1118', '03/2019');
INSERT INTO cust_order_info VALUES ('Herbert','Donahue','292 Winsome Way', 'San Francisco', 'CA', 94117, '5454 5454 5454 5454', '08/2018');

6. ユーザーsales_repおよびsupport_repに、表cust_order_infoに対するSELECT権限を付与します。

GRANT SELECT ON cust_order_info TO sales_rep, support_rep;

7. ユーザーdr_adminとして接続します。

CONNECT dr_admin
Enter password: password

8. クレジット・カード番号をリダクションするポリシーを作成し、有効にします。

BEGIN DBMS_REDACT.ADD_POLICY(
object_schema              => 'oe',
object_name                => 'cust_order_info',
column_name                => 'cc_num',
policy_name                => 'redact_cust_cc_info',
function_type              => DBMS_REDACT.REGEXP,
function_parameters        => NULL,
expression                 => '1=1',
regexp_pattern             => DBMS_REDACT.RE_PATTERN_CCN,
regexp_replace_string      => DBMS_REDACT.RE_REDACT_CCN,
regexp_position            => NULL,
regexp_occurrence          => NULL,
regexp_match_parameter     => NULL,
policy_description         => 'Partially redacts credit card info',
column_description         => 'cc_num_number lists credit card numbers');
END;
/

9. ポリシーを有効期限のリダクションを含めるよう変更します。

BEGIN DBMS_REDACT.ALTER_POLICY(
object_schema     => 'oe',
object_name       => 'cust_order_info',
policy_name       => 'redact_cust_cc_info',
action            => DBMS_REDACT.ADD_COLUMN,
column_name       => 'cc_exp',
function_type     => DBMS_REDACT.RANDOM,
expression        => '1-1');
END;
/

10. ユーザーsales_repがリダクション済の値を表示し、ユーザーsupport_repが実際のデータを表示する条件を使用するよう、再度ポリシーを変更します。

BEGIN
DBMS_REDACT.ALTER_POLICY(
object_schema     => 'oe',
object_name       => 'cust_order_info',
policy_name       => 'redact_cust_cc_info',
action            => DBMS_REDACT.MODIFY_EXPRESSION,
expression        => 'SYS_CONTEXT(''USERENV'',''SESSION_USER'') = ''SALES_REP''');
END;
/

11. ポリシーをテストするために、2人のユーザーに表cust_order_infoを問い合せさせます。

CONNECT suport_rep
Enter password: password

SELECT cc_num, cc_exp FROM OE.cust_order_info;

CC_NUM               CC_EXP
-------------------  -------
5105 1051 0510 5100  10/2018
5111 1111 1111 1118  03/2019
5454 5454 5454 5454  08/2018

ユーザーsupport_repは実際のデータを表示できます。

CONNECT sales_rep
Enter password: password

SELECT cc_num, cc_exp FROM OE.cust_order_info;

CC_NUM             CC_EXP
----------------   -------
************5100   lST=033
************1119   OZA.w4C
************5454   B(9+;O1

実際のデータは、ユーザーsales_repを使用してリダクションされます。

12. support_repのみがリダクション済データを表示でき、sales_repは表示できないようにする条件を含めるよう、cust_order_infoを変更します。

CONNECT dr_admin
Enter password: password

BEGIN
DBMS_REDACT.ALTER_POLICY(
object_schema      => 'oe',
object_name        => 'cust_order_info',
policy_name        => 'redact_cust_cc_info',
action             => DBMS_REDACT.MODIFY_EXPRESSION,
expression         => 'SYS_CONTEXT(''USERENV'',''SESSION_USER'') = ''SUPPORT_REP''');
END;
/

13. ユーザーに再度ポリシーをテストさせます。

CONNECT support_rep
Enter password: password

SELECT cc_num, cc_exp FROM OE.cust_order_info;

CC_NUM             CC_EXP
----------------   -------
************5100   1^XMF~`
************1119   qz+9=#S
************5454   *KCaUkm

これで実際のデータがリダクションされるため、ユーザーsupport_repはこのデータを表示できなくなります。

CONNECT sales_rep
Enter password: password

SELECT cc_num, cc_exp FROM OE.cust_order_info;

CC_NUM               CC_EXP
-------------------  -------
5105 1051 0510 5100  10/2018
5111 1111 1111 1118  03/2019
5454 5454 5454 5454  08/2018

これでユーザーsales_repは実際のデータを表示できます。

14. このチュートリアルのコンポーネントが不要になった場合、次のようにしてそれらを削除できます。

CONNECT dr_admin
Enter password: password

BEGIN
DBMS_REDACT.DROP_POLICY (
object_schema  => 'oe',
object_name    => 'cust_order_info',
policy_name    => 'redact_cust_cc_info');
END;
/

CONNECT sec_admin
Enter password: password

DROP USER dr_admin;
DROP USER sales_rep;
DROP USER support_rep;

CONNECT OE
Enter password: password

DROP TABLE cust_order_info;

複数列のリダクション

データ・リダクション・ポリシーで2つ以上の列をリダクションできます。

内容は次のとおりです。

- 1つの表またはビューのデータ・リダクション・ポリシーへの列の追加

- 例: 複数列のリダクション

1つの表またはビューのデータ・リダクション・ポリシーへの列の追加

1つの表またはビューで、様々なリダクション・タイプを使用して様々なデータ型の列をリダクションできます。

1. リダクションする最初の列に対するポリシーを作成します。

2. DBMS_REDACT.ALTER_POLICYプロシージャを使用して、ポリシーに次の列を追加します。
必要に応じて、action、column_name、function_typeおよびfunction_parametersパラメータ(またはregexp_で始まるパラメータ)を設定して、新しい列に対するリダクションを定義しますが、object_schema、object_name、policy_nameまたはexpressionパラメータは変更しないでください。リダクションされた各列には、それを作成するために使用したのと同じリダクション・パラメータが引き続き使用されます。

例: 複数列のリダクション

DBMS_REDACT.ALTER_POLICYプロシージャによって、複数の列をリダクションできます。

例10-11では、既存のデータ・リダクション・ポリシーに列を追加する方法を示しています。この例のactionパラメータは、DBMS_REDACT.ADD_COLUMNを使用して新しい列を追加する必要があることを定義しています。新しい列の名前であるcard_numは、column_nameパラメータによって設定されます。

例10-11 データ・リダクション・ポリシーへの列の追加

BEGIN
DBMS_REDACT.ALTER_POLICY(
object_schema       => 'mavis',
object_name         => 'cust_info',
policy_name         => 'redact_cust_user_ids',
action              => DBMS_REDACT.ADD_COLUMN,
column_name         => 'card_num',
function_type       => DBMS_REDACT.FULL,
function_parameters => '',
expression          => 'SYS_CONTEXT(''SYS_SESSION_ROLES'',''ADM'') = ''TRUE''');
END;
/

Oracle Data Redactionポリシーの有効化と無効化

作成したOracle Data Redactionポリシーは、必要に応じて無効化することも再度有効化することもできます。

内容は次のとおりです。

- Oracle Data Redactionポリシーの無効化

- Oracle Data Redactionポリシーの有効化

Oracle Data Redactionポリシーの無効化

DBMS_REDACT.DISABLE_POLICYプロシージャは、Oracle Data Redactionポリシーを無効化します。

REDACTION_POLICIESビューのPOLICY_NAMEおよびENABLE列を問い合せると、既存のデータ・リダクション・ポリシーの名前およびそれらが有効化されているかがわかります。ただし、ポリシーが存在している場合は、元のポリシーが無効化されていても表またはビューに他のポリシーを作成することはできません。つまり、同じ表の列に別のポリシーを作成する場合、最初のポリシーを削除してから新しいポリシーを作成して使用する必要があります。

- データ・リダクション・ポリシーを無効化するには、次の構文を使用してDBMS_REDACT.DISABLE_POLICYプロシージャを実行します。

DBMS_REDACT.DISABLE_POLICY (
object_schema       IN VARCHAR2 DEFAULT NULL,
object_name         IN VARCHAR2,
policy_name         IN VARCHAR2);

ここでは次のように指定します。

- object_schema: データ・リダクション・ポリシーを適用するオブジェクトのスキーマを指定します。この設定を省略(またはNULLを入力)する場合、Oracle Databaseは現在のスキーマ名を使用します。

- object_name: データ・リダクション・ポリシーに使用する表またはビューの名前を指定します。

- policy_name: 無効化するポリシーの名前を指定します。

例10-12では、データ・リダクション・ポリシーを無効化する方法を示しています。

例10-12 データ・リダクション・ポリシーの無効化

BEGIN
DBMS_REDACT.DISABLE_POLICY (
object_schema  => 'mavis',
object_name    => 'cust_info',
policy_name    => 'redact_cust_user_ids');
END;
/

データ・リダクション・ポリシーの有効化

DBMS_REDACT.ENABLE_POLICYプロシージャは、Oracle Data Redactionポリシーを有効化します。

新しいポリシーを作成した直後に有効化する必要はありません。作成プロセスによって処理されます。既存のデータ・リダクション・ポリシーの名前およびそれらが有効化されているかを確認するには、REDACTION_POLICIESビューのPOLICY_NAMEおよびENABLE列を問い合せます。ポリシーを有効にするプロシージャを実行すると、ポリシーはすぐに有効になります。

- データ・リダクション・ポリシーを有効化するには、次の構文を使用してDBMS_REDACT.ENABLE_POLICYプロシージャを実行します。

DBMS_REDACT.ENABLE_POLICY (
object_schema       IN VARCHAR2 DEFAULT NULL,
object_name         IN VARCHAR2,
policy_name         IN VARCHAR2);

ここでは次のように指定します。

- object_schema: データ・リダクション・ポリシーを適用するオブジェクトのスキーマを指定します。この設定を省略(またはNULLを入力)する場合、Oracle Databaseは現在のスキーマ名を使用します。

- object_name: データ・リダクション・ポリシーに使用する表またはビューの名前を指定します。

- policy_name: 有効化するポリシーの名前を指定します。

例10-13では、データ・リダクション・ポリシーを有効化する方法を示しています。

例10-13 データ・リダクション・ポリシーの有効化

BEGIN
DBMS_REDACT.ENABLE_POLICY (
object_schema  => 'mavis',
object_name    => 'cust_info',
policy_name    => 'redact_cust_user_ids');
END;
/

Oracle Data Redactionポリシーの削除

DBMS_REDACT.DROP_POLICYプロシージャは、Oracle Data Redactionポリシーを削除します。

Oracle Data Redactionポリシーは、有効であっても無効であっても削除できます。REDACTION_POLICIESビューのPOLICY_NAME列を問い合せて、既存のデータ・リダクション・ポリシーの名前を確認できます。Oracle Data Redactionポリシーに関連付けられた表またはビューを削除すると、ポリシーは自動的に削除されます。ベスト・プラクティスは、まずポリシーを削除し、その後、表またはビューを削除することです。詳細は、ごみ箱が有効になっている場合のOracle Data Redactionポリシーの削除を参照してください。

- データ・リダクション・ポリシーを削除するには、DBMS_REDACT.DROP_POLICYプロシージャを実行します。
次の構文を使用します。

DBMS_REDACT.DROP_POLICY (
object_schema       IN VARCHAR2 DEFAULT NULL,
object_name         IN VARCHAR2,
policy_name         IN VARCHAR2);

ここでは次のように指定します。

- object_schema: データ・リダクション・ポリシーが適用されるオブジェクトのスキーマを指定します。この設定を省略(またはNULLを入力)する場合、Oracle Databaseは現在のスキーマ名を使用します。

- object_name: データ・リダクション・ポリシーに使用する表またはビューの名前を指定します。

- policy_name: 削除するポリシーの名前を指定します。

DBMS_REDACT.DROP_POLICYプロシージャを実行した後、削除はすぐに有効になります。

例10-14では、データ・リダクション・ポリシーを削除する方法を示しています。

例10-14 データ・リダクション・ポリシーの削除

BEGIN
DBMS_REDACT.DROP_POLICY (
object_schema  => 'mavis',
object_name    => 'cust_info',
policy_name    => 'redact_cust_user_ids');
END;
/

チュートリアル: SQL式を使用したリダクションされた値を含むレポートの作成

SQL式を使用して、Oracle Data Redactionポリシーが定義された列に基づくレポートを作成できます。

SQL式に使用される値はリダクションされます。このリダクションはSQL式が評価される前に実行され、レポートに表示される結果の値は、リダクションされたSQL式の結果全体ではなく、リダクションされた値に対して評価されたSQL式の最終結果になります。

1. HR.EMPLOYEES表に対して次のようなデータ・リダクション・ポリシーを作成します。
このポリシーにより9という数値を持つSALARY列の最初の4桁の値およびCOMMISSION_PCT列の最初の1桁の値が9に置換されます。

BEGIN
DBMS_REDACT.ADD_POLICY(
object_schema          => 'HR',
object_name            => 'EMPLOYEES',
column_name            => 'SALARY',
column_description     => 'emp_sal_comm shows employee salary and commission',
policy_name            => 'redact_emp_sal_comm',
policy_description     => 'Partially redacts the emp_sal_comm column',
function_type          => DBMS_REDACT.PARTIAL,
function_parameters    => '9,1,4',
expression             => '1=1');
END;
/
BEGIN
DBMS_REDACT.ALTER_POLICY(
object_schema          => 'HR',
object_name            => 'EMPLOYEES',
policy_name            => 'redact_emp_sal_comm',
action                 => DBMS_REDACT.ADD_COLUMN,
column_name            => 'COMMISSION_PCT',
function_type          => DBMS_REDACT.PARTIAL,
function_parameters    => '9,1,1',
expression             => '1=1');
END;
/

2. HRスキーマにログインして、次のレポートを実行します。
このレポートでは、SQL式(SALARY + COMMISSION_PCT)を使用して、従業員の給料と歩合を組み合せます。

SELECT (SALARY + COMMISSION_PCT) total_emp_compensation
FROM HR.EMPLOYEES
WHERE DEPARTMENT_ID = 80;

TOTAL_EMP_COMPENSATION
----------------------
9999.9
9999.95
99990.95
...

3. レポートには、連結などのSQL式を使用します。
例:

SELECT 'Employee ID '          || EMPLOYEE_ID ||
' has a salary of '     || SALARY ||
' and a commission of ' || COMMISSION_PCT || '.' detailed_emp_compensation
FROM HR.EMPLOYEES
WHERE DEPARTMENT_ID = 80
ORDER BY EMPLOYEE_ID;

DETAILED_EMP_COMPENSATION
-------------------------------------------------------------
Employee ID 150 has a salary of 99990 and a commission of .9.
Employee ID 151 has a salary of 9999 and a commission of .95.
Employee ID 152 has a salary of 9999 and a commission of .95.
...

4. redact_emp_sal_commデータ・リダクション・ポリシーを作成したユーザーを接続し、次の文を実行してポリシーを削除します。

BEGIN
DBMS_REDACT.DROP_POLICY (
object_schema => 'HR',
object_name   => 'EMPLOYEES',
policy_name   => 'redact_emp_sal_comm');
END;
/

Oracle Data Redactionポリシーのデータ・ディクショナリ・ビュー

Oracle Databaseには、データ・リダクション・ポリシーに関する情報をリストするデータ・ディクショナリ・ビューが用意されています。

これらのビューを問い合せる前に、SELECT_CATALOG_ROLEロールを付与する必要があります。

表10-6に、データ・リダクションのデータ・ディクショナリ・ビューを示します。

表10-6 データ・リダクション・ビュー

ビュー

説明

REDACTION_COLUMNS

データベースのリダクションされたすべての列を示し、列が存在する表またはビューの所有者、オブジェクト名、列名、リダクション機能のタイプ、リダクション機能に対するパラメータ(該当する場合)およびリダクション・ポリシーの説明の情報を提供します。ポリシー式が作成されている場合、デフォルトのオブジェクト全体にわたるポリシー式のSQL式を表示します。

REDACTION_EXPRESSIONS

既存のポリシー式の名前およびそれらのSQL式を表示します

REDACTION_POLICIES

データベースのすべてのデータ・リダクション・ポリシーを示します。これには、オブジェクトの所有者、オブジェクト名、ポリシー名、ポリシー式およびポリシーが有効かどうかに関する情報と、データ・リダクション・ポリシーの説明が含まれます。

REDACTION_VALUES_FOR_TYPE_FULL

完全リダクションを使用するデータ・リダクション・ポリシーの現在のリダクション値を表示します。

11 Oracle Enterprise ManagerでのOracle Data Redactionの使用

Oracle Enterprise Manager Cloud Control (Cloud Control)を使用して、Oracle Data Redactionのポリシーと形式を管理できます。

内容は次のとおりです。

- Oracle Enterprise ManagerでのOracle Data Redactionの使用について

- Oracle Data Redactionのワークフロー

- Enterprise Managerでの機密列タイプの管理

- Enterprise Managerを使用したOracle Data Redaction形式の管理

- Enterprise Managerを使用したOracle Data Redactionポリシーの管理

Oracle Enterprise ManagerでのOracle Data Redactionの使用について

Oracle Enterprise Manager Cloud Controlでは、Oracle Data Redactionポリシーの作成と管理のために統一されたユーザー・インタフェースが提供されます。

Oracle Enterprise Manager 12cデータベース・プラグイン12.1.0.7以上で、次の操作を実行できます。

- カスタムOracle Data Redaction形式(以前のデータ・リダクション・ショートカット)の作成と管理。(この機能はコマンドラインからは使用できません。)

- Oracle Data Redactionページでの機密列タイプの作成および管理。データ・リダクション・ポリシーを作成するとき、Cloud Controlは機密列タイプを使用して、リダクションする列に関連するOracle Data Redaction形式を取得します。

注意:

Oracle Database Enterprise Edition 11.2.0.4以上では、Oracle Enterprise Manager (Oracle Enterprise Manager 12c以上)を使用してデータをリダクションできます。ただし、カスタム・リダクション形式と機密列タイプを作成する前に、Enterprise Manager for Oracle Databaseプラグイン12.1.0.7以上をデプロイする必要があります。

プラグインのデプロイ方法の詳細は、Enterprise Manager Cloud Control管理者ガイドを参照してください。

Oracle Data Redactionのワークフロー

最初に必要に応じて機密列タイプおよび形式を作成してから、次にOracle Data Redactionポリシーを作成します。

次の図では、このプロセスを示します。

1. (オプション)データベース列(リダクションするデータを含む)を新しい機密列タイプにマッピングする場合は、「Enterprise Managerでの機密列タイプの管理」の説明に従って、必要な機密列タイプを作成します。

2. (オプション) カスタム・リダクション形式を使用してデータ(特定のデータベース列に存在する)をリダクションする場合は、「カスタムOracle Data Redaction形式の作成」の説明に従って、必要なリダクション形式を作成します。

3. 「Enterprise Managerを使用したOracle Data Redactionポリシーの作成」の説明に従って、必要なデータベースに対してOracle Data Redactionポリシーを作成します。

注意:

Oracle Data Redactionポリシーは、作成した時点でデフォルトで有効になっています。有効化されたリダクション・ポリシーを無効化する方法の詳細は、Enterprise ManagerでのOracle Data Redactionポリシーの有効化または無効化を参照してください。

Enterprise Managerでの機密列タイプの管理

機密列タイプによって、表の列の機密情報がクレジット・カード番号などの機密情報タイプに分類されます。

機密列タイプは、列の名前と内容および正規表現を使用して定義されたデータ・パターンの組合せを使用して、列を特定の機密情報タイプに関連付けます。

Oracle Data Redactionポリシーを作成すると、選択した機密列タイプに基づいてリダクション形式がフィルタ処理されるため、時間を節約して手間を省くことができます。たとえば、リダクションしようとするデータベース表の列に米国社会保障番号が含まれており、その列に対してSOCIAL_SECURITY_NUMBER機密列タイプを選択した場合に、その列をOracle Data Redactionポリシーに追加すると、その列データのリダクションに使用できるデフォルトのリダクション形式はフィルタ処理され、関連するリダクション形式のみが表示されます。

図11-1に、機密列タイプに基づくOracle Data Redaction形式のフィルタ処理を示します。

図11-1 機密列タイプに基づいてフィルタ処理されるOracle Data Redaction形式

注意:

この機能が使用できるのは、Enterprise Manager for Oracle Databaseプラグイン12.1.0.7以上がシステムにデプロイされている場合です。

環境にデプロイされているプラグインを確認する方法の詳細は、Enterprise Manager Cloud Control管理者ガイドを参照してください。

アプリケーション・データ・モデル機能の中で、データベースの列をマッピングできるデフォルト機密列タイプが多数提供されています。

図11-2に、デフォルトの機密列タイプの一部を示します。

図11-2 デフォルトの機密列タイプ

デフォルトの機密列タイプの中に、リダクションしようとするデータを含むデータベース列に適したものがない場合は、Oracle Database Testingガイドの説明に従って、新しい機密列タイプを作成できます。または、既存の機密列タイプに基づいて機密列タイプを作成できます。

Enterprise Managerを使用したOracle Data Redaction形式の管理

Oracle Data Redactionには、データをリダクションするためにリダクション・ポリシー内で直接使用できるリダクション形式が用意されています。

内容は次のとおりです。

- Enterprise Managerを使用したOracle Data Redaction形式の管理について

- カスタムOracle Data Redaction形式の作成

- カスタムOracle Data Redaction形式の編集

- Oracle Data Redaction形式の表示

- カスタムOracle Data Redaction形式の削除

Enterprise Managerを使用したOracle Data Redaction形式の管理について

Oracle Data Redaction形式は、ID番号、クレジットカード、電話番号などの通常リダクションされることが多いデータに対して使用されます。

Oracle Databaseでは、いくつかのデフォルトOracle Data Redaction形式が提供されます。

図11-3にデフォルトのOracle Data Redaction形式を示します。

図11-3 デフォルトのOracle Data Redaction形式

デフォルトの各Oracle Data Redaction形式は、特定のリダクション機能で構成され、リダクション形式がOracle Data Redactionポリシーで使用される際のリダクション出力を決定します。たとえば、「クレジット・カード番号 - NUMBER」デフォルト・リダクション形式は、Oracle Data Redactionポリシーで使用されると、列データの先頭12桁を数字0で置換します。つまり、列データが5555555555554444の場合、リダクションされた出力は0000000000004444になります。

Enterprise Manager for Oracle Databaseプラグイン12.1.0.7以上をシステムにデプロイしている場合は、カスタム・リダクション形式を作成して保存し、リダクション・ポリシーで使用できます。

カスタムOracle Data Redaction形式の作成

Enterprise Manager Cloud Controlを使用してカスタムOracle Data Redaction形式を作成および保存できます。

1. ユーザーSYSTEMまたはSYSMANとしてOracle Enterprise Manager Cloud Controlにログインします。
URLは次のとおりです。

https://host:port/em

2. 「ターゲット」メニューから「データベース」を選択します。

3. 「検索リスト」を選択し、データベース・ターゲット名をクリックします。

4. データベース・ターゲットのホームページで、「セキュリティ」メニューから「データ・リダクション」を選択します。

5. 求められた場合にはデータベースにログインします。
DBMS_REDACT PL/SQLパッケージに対するEXECUTE権限を持つユーザーとしてデータベースにログインしてください。

6. 「形式」タブを選択し、「作成」をクリックします。
既存のリダクション形式に基づいてカスタム・リダクション形式を作成する(つまり類似した形式を作成する)場合は、「類似作成」をクリックします。

「作成」を選択した場合、次のダイアログ・ボックスが表示されます。

7. 作成するリダクション形式の名前と説明を指定します。
リダクション形式を特定の機密列タイプにマッピングする場合(作成されるリダクション形式を使用して、機密列タイプに関連付けられている列のデータをリダクションできるようにする場合)、「機密列タイプ」の値を選択します。

列データをリダクションするために形式で使用する必要がある機能を選択します。「リダクション機能」では、「完全」(列データ全体をリダクションする形式)、「部分」(列データの一部をリダクションする形式)、正規表現(正規表現に基づいてデータをリダクションする形式)、「ランダム」(ランダム生成された値を使用してランダムな方法でデータをリダクションする形式)または「なし」(リダクション・ポリシーの定義をテストするためのみに形式を使用し、列データをリダクションしない場合)を選択します。「部分」を選択した場合は、機能属性とリダクション形式で使用するデータ型を必ず指定してください。正規表現を選択した場合は、機能属性を必ず指定してください。

使用できるリダクション機能や各リダクション機能で指定できるパターンの詳細は、「Oracle Data Redactionの特徴と機能」を参照してください。

8. 「OK」をクリックすると、カスタム・リダクション形式が作成されて保存されます。
これで、この形式を使用してリダクション・ポリシーを作成できます。リダクション・ポリシーの作成方法の詳細は、「Enterprise Managerを使用したOracle Data Redactionポリシーの作成」を参照してください。

カスタムOracle Data Redaction形式の編集

カスタムOracle Data Redaction形式は、Enterprise Manager Cloud Controlを使用して編集できます(SQL*Plusでは編集できません)。

1. ユーザーSYSTEMまたはSYSMANとしてOracle Enterprise Manager Cloud Controlにログインします。
URLは次のとおりです。

https://host:port/em

2. 「ターゲット」メニューから「データベース」を選択します。

3. 「検索リスト」を選択し、データベース・ターゲット名をクリックします。

4. データベース・ターゲットのホームページで、「セキュリティ」メニューから「データ・リダクション」を選択します。

5. 求められた場合にはデータベースにログインします。
DBMS_REDACT PL/SQLパッケージに対するEXECUTE権限を持つユーザーとしてデータベースにログインしてください。

6. 「形式」タブを選択します。

7. 編集するカスタム・リダクション形式を選択し、「編集」をクリックします。
次のようなダイアログ・ボックスが表示されます。

8. (オプション)形式の説明、機密列タイプ、リダクション機能およびリダクション機能属性の編集を選択します。

9. 「OK」をクリックすると、編集した形式が保存されます。

Oracle Data Redaction形式の表示

Enterprise Manager Cloud Controlには、Oracle提供およびカスタムのOracle Data Redaction形式の詳細が表示されます。

1. ユーザーSYSTEMまたはSYSMANとしてOracle Enterprise Manager Cloud Controlにログインします。
URLは次のとおりです。

https://host:port/em

2. 「ターゲット」メニューから「データベース」を選択します。

3. 「検索リスト」を選択し、データベース・ターゲット名をクリックします。

4. データベース・ターゲットのホームページで、「セキュリティ」メニューから「データ・リダクション」を選択します。

5. 求められた場合にはデータベースにログインします。
DBMS_REDACT PL/SQLパッケージに対するEXECUTE権限を持つユーザーとしてデータベースにログインしてください。

6. 「形式」タブを選択します。

7. 必要なリダクション形式を選択し、「表示」をクリックします。
次のページに類似したデータ・リダクション形式ページが表示されます:

カスタムOracle Data Redaction形式の削除

Enterprise Manager Cloud Control (Cloud Control)を使用して、カスタムOracle Data Redaction形式を削除できます。

削除できるのはカスタムOracle Data Redaction形式のみです。Oracle提供のリダクション形式は削除できません。

1. ユーザーSYSTEMまたはSYSMANとしてOracle Enterprise Manager Cloud Controlにログインします。
URLは次のとおりです。

https://host:port/em

2. 「ターゲット」メニューから「データベース」を選択します。

3. 「検索リスト」を選択し、データベース・ターゲット名をクリックします。

4. データベース・ターゲットのホームページで、「セキュリティ」メニューから「データ・リダクション」を選択します。

5. 求められた場合にはデータベースにログインします。
DBMS_REDACT PL/SQLパッケージに対するEXECUTE権限を持つユーザーとしてデータベースにログインしてください。

6. 「形式」タブを選択します。

7. 削除するカスタム・リダクション形式を選択し、「削除」をクリックします。

8. 「確認」ダイアログ・ボックスで「はい」または「いいえ」をクリックします。

Enterprise Managerを使用したOracle Data Redactionポリシーの管理

Enterprise Manager Cloud Control (Cloud Control)でOracle Data Redactionポリシーの作成、編集、表示および削除を行うことができます。

内容は次のとおりです。

- Enterprise Managerを使用したOracle Data Redactionポリシーの作成

- Enterprise Managerを使用したOracle Data Redactionポリシーの編集

- Enterprise Managerを使用したOracle Data Redactionポリシーの詳細の表示

- Enterprise ManagerでのOracle Data Redactionポリシーの有効化または無効化

- Enterprise Managerを使用したOracle Data Redactionポリシーの削除

Enterprise Managerを使用したOracle Data Redactionポリシーの管理について

Cloud Controlの「データ・リダクション」ページを使用して、Oracle Data Redactionポリシーを管理できます。

特定のデータベース表またはビューの列に存在するデータをリダクションするには、Oracle Data Redactionポリシーを作成する必要があります。データは、Oracle Data Redactionポリシーによって指定されるリダクション形式を使用してリダクションされます。データをリダクションするには、Oracle提供のリダクション形式のいずれかを使用するか、カスタム・リダクション形式を作成して使用します。リダクションしようとするデータを含む表またはビューの列が機密列タイプにマッピングされている場合、そのマッピングを使用してデータの適切なリダクション形式が推奨されます。このように、Oracle Data Redactionポリシーが、データベース・スキーマ、データベースの表とビューの列、機密列タイプおよびOracle Data Redaction形式をカプセル化します。

図11-4にデータ・リダクション・ページを示します。このページを使用して、Cloud ControlでOracle Data Redactionポリシーを作成および管理できます。

図11-4 Oracle Data Redactionのポリシー・ページ

Enterprise Managerを使用したOracle Data Redactionポリシーの作成

Enterprise Manager Cloud Controlを使用してOracle Data Redactionポリシーを作成できます。

1. ユーザーSYSTEMまたはSYSMANとしてOracle Enterprise Manager Cloud Controlにログインします。
URLは次のとおりです。

https://host:port/em

2. 「ターゲット」メニューから「データベース」を選択します。

3. 「検索リスト」を選択し、Oracle Data Redactionポリシーを作成するデータベース・ターゲットの名前をクリックします。

4. データベース・ターゲットのホームページで、「セキュリティ」メニューから「データ・リダクション」を選択します。

5. 求められた場合にはデータベースにログインします。
DBMS_REDACT PL/SQLパッケージに対するEXECUTE権限を持つユーザーとしてデータベースにログインしてください。

6. 「ポリシー」タブの「ポリシー」セクションで「作成」を選択します。

7. データ・リダクション・ポリシーの作成ページで次の情報を入力します。

- スキーマ: リダクションするデータを含むスキーマの名前を入力(または検索)します。

- 表/ビュー: リダクションする列を含む表またはフィールドを入力(または検索)します。

- ポリシー名: ポリシーの名前(emp_wages_polなど)を入力します。

- ポリシー式: ポリシー式を入力します。デフォルトは1=1で、ポリシーが常に適用されます。ポリシー式の構成要素に詳しくない場合は、「ポリシー式」フィールドの横にある鉛筆のアイコンをクリックしてポリシー式ビルダーを使用します。「ポリシーの適用時」を選択し、必要な条件を選択してから「追加」をクリックします。ポリシー式を手動で編集する場合は「編集」をクリックします。必要なポリシー式を構築してから、「OK」をクリックします。次のようなポリシー式ビルダーが表示されます。

8. 「オブジェクト列」セクションで「追加」をクリックすると、表またはビューの列がリダクション・ポリシーに追加されます。
次のダイアログ・ボックスが表示されます:

リダクション・ポリシーは、そのポリシーが追加されている表またはビューの列のみに適用されます。

9. 「列」メニューで、リダクション・ポリシーを適用する表またはビューの列を選択します。
「列」メニューの右側のアイコンをクリックすると、選択した列の内容を確認できます。

例:

列に機密データが含まれ、機密列タイプにマッピングされている場合は、マッピングされている機密列タイプを「機密列タイプ」メニューで選択します。「機密列タイプ」メニューの検索パターンが一致すると、その機密列タイプがデフォルトで選択されます。たとえば、クレジット・カード番号を含む列に一致するものがあると、メニューには「未定義」とCREDIT_CARD_TYPEが表示されます。機密列タイプが作成されていない場合、デフォルトの「機密列タイプ」メニューには「未定義」のみが表示されます。

10. 「リダクション形式」メニューで、使用するリダクション形式を選択します。
ドロップダウン・リストには、Oracle Database提供のリダクション形式とユーザーが作成して保存したカスタム・リダクション形式が含まれます。リダクション形式を作成および保存する方法の詳細は、「カスタムOracle Data Redaction形式の作成」を参照してください。
事前定義済のリダクション形式(つまりOracle Database提供のリダクション形式または以前に作成したカスタム・リダクション形式)を使用せず、リダクション・ポリシーを作成するときにリダクションの詳細を指定する場合は、「リダクション形式」で「カスタム」を選択します。

選択するリダクションの形式とタイプに合せて、「追加」ダイアログ・ボックスの表示が変わります。たとえば、「カスタム」リダクション形式とREGEXリダクション機能を選択すると、ダイアログ・ボックスに「機能属性」リージョンが表示されます。

11. 「リダクション機能」メニューで、列データのリダクションに使用する機能を選択します。
「完全」(列データ全体をリダクションする場合)、「部分」(列データの一部をリダクションする場合)、正規表現(正規表現に基づいてデータをリダクションする場合)、「ランダム」(ランダム生成された値を使用してランダムな方法でデータをリダクションする場合)または「なし」(リダクション・ポリシーの定義のテストのみを行い、列データをリダクションしない場合)を選択します。特定のリダクション形式にはすべてのリダクション機能を適用できるわけではないことに注意してください。ドロップダウン・リストには、選択したリダクション形式に適用できるリダクション機能のみが表示されます。

前の手順で「リダクション形式」に「カスタム」、「リダクション機能」に「部分」または正規表現を選択した場合は、機能属性を必ず指定してください。

使用可能なリダクション形式の詳細と例は、「Oracle Data Redactionの特徴と機能」を参照してください。

12. 「OK」をクリックします。

13. リダクション・ポリシーに追加するすべての列について、手順8以降の手順を繰り返します。

14. データ・リダクション・ポリシーの作成ページで、「OK」をクリックすると、データ・リダクション・ポリシーが作成されます。
次の図に類似した新しいポリシーが表示されます:

注意:

Oracle Data Redactionポリシーは、作成した時点でデフォルトで有効になっています。有効化されたリダクション・ポリシーを無効化する方法の詳細は、Enterprise ManagerでのOracle Data Redactionポリシーの有効化または無効化を参照してください。

Enterprise Managerを使用したOracle Data Redactionポリシーの編集

Enterprise Manager Cloud Controlを使用してOracle Data Redactionポリシーを編集できます。

1. ユーザーSYSTEMまたはSYSMANとしてOracle Enterprise Manager Cloud Controlにログインします。
URLは次のとおりです。

https://host:port/em

2. 「ターゲット」メニューから「データベース」を選択します。

3. 「検索リスト」を選択し、編集するOracle Data Redactionポリシーが作成されているデータベース・ターゲットの名前を検索してクリックします。

4. データベース・ターゲットのホームページで、「セキュリティ」メニューから「データ・リダクション」を選択します。

5. 求められた場合にはデータベースにログインします。
DBMS_REDACT PL/SQLパッケージに対するEXECUTE権限を持つユーザーとしてデータベースにログインしてください。

6. 「ポリシー」タブの「ポリシー」セクションで、編集するリダクション・ポリシーを選択し、「編集」をクリックします。

7. データ・リダクション・ポリシーの編集ページで、ポリシー式の編集、リダクション・ポリシーへの新しい列の追加、ポリシーに含まれる列のリダクション詳細の変更、またはリダクション・ポリシーからの列の削除を選択します。

次の操作を実行できます。

- リダクション・ポリシーに新しい列を追加するには、「オブジェクト列」セクションで「追加」をクリックし、追加する表またはビューの列を選択してからリダクションの詳細を指定します。

- ポリシーに含まれる列のリダクションの詳細を変更するには、「変更」をクリックして、リダクションの詳細を編集します。

- リダクション・ポリシーから列を削除するには、列を選択して、「削除」をクリックします。

ポリシー式を指定または編集する方法の詳細は、「Enterprise Managerを使用したOracle Data Redactionポリシーの作成」の手順6を参照してください。列のリダクション詳細を指定または編集する方法の詳細は、手順7を参照してください。

8. データ・リダクション・ポリシーの編集ページで、必要なフィールドを編集してから「OK」をクリックすると、編集されたリダクション・ポリシーが保存され有効になります。

Enterprise Managerを使用したOracle Data Redactionポリシーの詳細の表示

Enterprise Manager Cloud Controlを使用して、Oracle Data Redactionポリシーの詳細(ポリシーが有効かどうかなど)を確認できます。

Enterprise Manager Cloud Control (Cloud Control)を使用して、有効化されたリダクション・ポリシーの無効化、または無効化されたリダクション・ポリシーの有効化を行うことができます。

1. ユーザーSYSTEMまたはSYSMANとしてOracle Enterprise Manager Cloud Controlにログインします。
URLは次のとおりです。

https://host:port/em

2. 「ターゲット」メニューから「データベース」を選択します。

3. 「検索リスト」を選択し、表示するOracle Data Redactionポリシーが作成されているデータベース・ターゲットの名前を検索してクリックします。

4. データベース・ターゲットのホームページで、「セキュリティ」メニューから「データ・リダクション」を選択します。

5. 求められた場合にはデータベースにログインします。

6. 「ポリシー」タブの「ポリシー」セクションで、次のいずれかを実行します:

- 表でポリシーの名前を選択します。

- 必要なリダクション・ポリシーを選択し、「表示」をクリックします。

Enterprise ManagerでのOracle Data Redactionポリシーの有効化または無効化

実行時にOracle Data Redactionポリシーが適用されるのは有効化されている場合のみです。Oracle Data Redactionポリシーは、作成した時点でデフォルトで有効になっています。

Enterprise Manager Cloud Control (Cloud Control)を使用して、有効化されたリダクション・ポリシーの無効化、または無効化されたリダクション・ポリシーの有効化を行うことができます。

1. ユーザーSYSTEMまたはSYSMANとしてOracle Enterprise Manager Cloud Controlにログインします。
URLは次のとおりです。

https://host:port/em

2. 「ターゲット」メニューから「データベース」を選択します。

3. 「検索リスト」を選択し、有効化または無効化するOracle Data Redactionポリシーが作成されているデータベース・ターゲットの名前を検索してクリックします。

4. データベース・ターゲットのホームページで、「セキュリティ」メニューから「データ・リダクション」を選択します。

5. 求められた場合にはデータベースにログインします。
DBMS_REDACT PL/SQLパッケージに対するEXECUTE権限を持つユーザーとしてデータベースにログインしてください。

6. 「ポリシー」タブの「ポリシー」セクションで、有効化または無効化するリダクション・ポリシーを選択し、「有効化」または「無効化」をクリックします。

7. 「確認」ダイアログ・ボックスで「はい」または「いいえ」をクリックします。

Enterprise Managerを使用したOracle Data Redactionポリシーの削除

Enterprise Manager Cloud Controlを使用してOracle Data Redactionポリシーを削除できます。

1. ユーザーSYSTEMまたはSYSMANとしてOracle Enterprise Manager Cloud Controlにログインします。
URLは次のとおりです。

https://host:port/em

2. 「ターゲット」メニューから「データベース」を選択します。

3. 「検索リスト」を選択し、削除するOracle Data Redactionポリシーが作成されているデータベース・ターゲットの名前を検索してクリックします。

4. データベース・ターゲットのホームページで、「セキュリティ」メニューから「データ・リダクション」を選択します。

5. 求められた場合にはデータベースにログインします。
DBMS_REDACT PL/SQLパッケージに対するEXECUTE権限を持つユーザーとしてデータベースにログインしてください。

6. 「ポリシー」タブの「ポリシー」セクションで、削除するリダクション・ポリシーを選択し、「削除」をクリックします。

7. 「確認」ダイアログ・ボックスで「はい」または「いいえ」をクリックします。

12 Oracle Data RedactionとOracle Database機能の併用

Oracle Data Redactionは、他のOracle機能とともに使用できます。一部のOracle機能には、Oracle Data Redactionに関する制限がある場合があります。

内容は次のとおりです。

- Oracle Data Redactionと、DMLおよびDDL操作

- ネストした関数、インライン・ビューおよびWHERE句でのOracle Data Redaction

- Oracle Data Redactionとデータベース・リンク

- Oracle Data Redactionおよび集計関数

- Oracle Data Redactionおよびオブジェクト型

- Oracle Data RedactionおよびXML生成

- Oracle Data Redactionおよびエディション

- マルチテナント環境におけるOracle Data Redaction

- Oracle Data RedactionとOracle Virtual Private Database

- Oracle Data RedactionとOracle Database Real Application Security

- Oracle Data RedactionとOracle Database Vault

- Oracle Data RedactionとOracle Data Pump

- Oracle Data RedactionとData Masking and Subsetting Pack

Oracle Data Redactionと、DMLおよびDDL操作

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システム権限の付与が必要になる可能性があります。

ネストした関数、インライン・ビューおよびWHERE句でのOracle Data Redaction

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とデータベース・リンク

データベース・リンクを参照するデータベース・ビューでOracle Data Redactionポリシーを作成しないでください。

DBA_DB_LINKSデータ・ディクショナリ・ビューを問い合せることによって、既存のデータベース・リンクについての情報を検索できます。

関連項目:

データベース・リンクの詳細は、Oracle Database管理者ガイドを参照してください。

Oracle Data Redactionおよび集計関数

集計関数は、Oracle Data Redactionポリシーのパフォーマンス・オーバーヘッドに影響を与えることがあります。

Oracle Data Redactionは列の各行の値を動的に変更するため、集計関数を使用する特定のSQL問合せでは、行の値が静的であると仮定しているデータベース最適化を最大限に利用できません。

集計関数をコールするSQL問合せでは、リダクションが原因でパフォーマンス・オーバーヘッドが発生する可能性があります。

Oracle Data Redactionおよびオブジェクト型

オブジェクト型を使用して、顧客アカウントなどの実世界のエンティティをモデル化できます。

オブジェクト型はユーザー定義の型です。オブジェクト型をリダクションすることはできません。これは、データベース・リダクションでは、オブジェクト型を構成できる可能性のある一部の方法を処理できないためです(ユーザー定義であるため)。オブジェクトで使用する型は、ALL_OBJECTSデータ・ディクショナリ・ビューのOBJECT_NAMEおよびOBJECT_TYPE列を問い合せることで検索できます。

Oracle Data RedactionおよびXML生成

Oracle Data Redactionポリシーが定義されている列で、XML生成関数を使用することはできません。

Oracle XML DB開発者ガイドで、この制限が適用されるSQL関数の種類について説明しています。この制限は、Oracle Data Redactionポリシーが有効化されているか無効化されているか、または問合せを行っているユーザーに対してアクティブかどうかに関係なく適用されます。

Oracle Data Redactionおよびエディション

エディション化ビューはリダクションできません。

エディション化ビューはリダクションできないほかに、いずれのエディション化ビューの定義でも、リダクションされた列を使用することはできません。DBA_EDITIONSデータ・ディクショナリ・ビューを問い合せると、エディションに関する情報を検索できます。

マルチテナント環境におけるOracle Data Redaction

マルチテナント環境では、Oracle Data Redactionポリシーは、現在のプラガブル・データベース(PDB)内のオブジェクトのみに適用されます。

データ・リダクション・ポリシーは、マルチテナント・コンテナ・データベース(CDB)には作成できません。これは、一般的にデータ・リダクション・ポリシーを作成するオブジェクトがPDBにあるためです。DBA_PDBSデータ・ディクショナリ・ビューを問い合せると、CDB内のすべてのPDBを検索できます。

Oracle Data RedactionとOracle Virtual Private Database

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とは異なります。

Oracle Data Redactionは、アプリケーション・セキュリティに包括的な認可フレームワークを提供している点で、Oracle Database Real Application Securityとは異なります。

Real Application Security内の列セキュリティは、Real Application Securityフレームワークを使用してアプリケーションで定義されるアプリケーション権限に基づきます。

関連項目:

カスタム・アプリケーション権限で表の列を保護する方法の詳細は、Oracle Database Real Application Security管理者および開発者ガイドを参照してください。

Oracle Data RedactionとOracle Database Vault

Oracle Database Vault環境で、Oracle Data Redactionを使用できます。

たとえば、オブジェクトがOracle Database Vaultレルムに含まれている場合、レルムの所有者または参加者の認証済リストに属していないユーザーは、ユーザーにEXEMPT REDACTION POLICY権限が付与されているかどうかにかかわらず、オブジェクト・データを表示できません。ユーザーがデータに対してDMLまたはDDL文を試みると、エラー・メッセージが表示されます。

Oracle Data RedactionとOracle Data Pump

Oracle Data PumpとともにOracle Data Redactionを使用した場合、DATAPUMP_EXP_FULL_DATABASEロールが与える影響、データ・リダクション・ポリシーを含むオブジェクトをエクスポートする際の影響、EXPDP access_methodパラメータを使用してデータをエクスポートする影響を考慮する必要があります。

内容は次のとおりです。

- Oracle Data RedactionのためのOracle Data Pumpセキュリティ・モデル

- Oracle Data Redactionポリシーが定義されているオブジェクトのエクスポート

- EXPDPユーティリティのaccess_methodパラメータを使用したデータのエクスポート

- Oracle Data Redactionで保護されているオブジェクトへのデータのインポート

Oracle Data RedactionのためのOracle Data Pumpセキュリティ・モデル

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 Redactionポリシーがすでに定義されているオブジェクトをエクスポートできます。

内容は次のとおりです。

- Oracle Data Pumpで使用されるタイプ名の検索

- データ・リダクション・ポリシーに関連するデータ・ディクショナリ・メタデータのみのエクスポート

- IMPDPのINCLUDEパラメータを使用したオブジェクトのインポート

Oracle Data Pumpで使用されるタイプ名の検索

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ユーティリティを参照してください。

IMPDPのINCLUDEパラメータを使用したオブジェクトのインポート

Oracle Database Pumpを使用してオブジェクトをインポートできます。

- オブジェクトをインポートするには、DATABASE_EXPORT_OBJECTSビューでOBJECT_PATH列を問い合せた出力に基づいて、これらの名前をIMPDPユーティリティ・コマンドのINCLUDEパラメータに含めます。

EXPDPユーティリティのaccess_methodパラメータを使用したデータのエクスポート

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 Redactionで保護されているオブジェクトへのデータのインポート

インポート操作中に、インポートされるデータを保護するデータ・リダクション・ポリシーを誤って削除しないように注意してください。

Oracle Data Pumpエクスポート(EXPDP)ユーティリティを使用してエクスポートされたソース表にOracle Data Redactionポリシーが存在しないシナリオを考えてみます。ただし、Oracle Data Pumpインポート(IMPDP)を使用してデータをインポートする宛先表には、Oracle Data Redactionポリシーが存在します。

Data Pumpインポート操作中、インポートされるオブジェクトでのデータ・リダクション・ポリシーのステータスは、IMPDPコマンドのCONTENTオプションによって異なります。

- IMPDPコマンドでCONTENT=ALL またはCONTENT=METADATA_ONLYオプションを使用する場合、宛先表のデータ・リダクション・ポリシーは削除されます。データ・リダクション・ポリシーを再作成する必要があります。

- IMPDPコマンドでCONTENT=DATA_ONLYを使用する場合、宛先表のデータ・リダクション・ポリシーは削除されません。

関連項目:

データ・ポンプ・エクスポートの使用の詳細は、Oracle Databaseユーティリティを参照してください

Oracle Data RedactionとData Masking and Subsetting Pack

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ガイドを参照してください。

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

Oracleには、Oracle Data Redactionを使用する場合の一連のガイドラインがあります。

内容は次のとおりです。

- Oracle Data Redactionの一般的な使用上のガイドライン

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

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

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

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

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

Oracle Data Redactionの一般的な使用上のガイドライン

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

- Oracle Data Redactionは、データベースに対して直接非定型な問合せを実行する権限を持つ通常のデータベース・ユーザーによって行われる攻撃に対する保護目的では使用できません。

- Oracle Data Redactionは、推論によって実際の値を判断しようと試みる非定型なSQL問合せを実行するユーザーに対する保護目的では使用できません。

- 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操作、レプリケーションなど)には影響しません。

- SQL文のGROUP BY句で使用されるSQL式にリダクションされた列を含めることはできません。Oracleでは、このような動作をサポートせず、 「ORA-00979: GROUP BYの式ではありません。」エラーが発生します。これはSELECTリスト内の式がデータ・リダクションにより内部で変更される必要があるために発生しますが、GROUP BY句(その時点ではデータ・リダクションにより更新されていない)を処理するときに見つからなくなっている原因となり、この予期せぬエラー・メッセージが発生します。

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

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

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

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

関連項目:

- Oracle Data Redactionポリシーからのユーザーの除外

- Oracle Data RedactionとOracle Database Vault

- Oracle Database Vaultの詳細は、『Oracle Database Vault管理者ガイド』を参照してください。

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

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

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

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

次のガイドラインに従います。

- デフォルトのOracle Databaseスキーマには、データ・リダクション・ポリシーを作成しないでください。SYSおよびSYSTEMスキーマも同様です。

- 追加ロールにEXEMPT DATA REDACTIONシステム権限を付与すると、ユーザーにOracle Data Redactionのバイパスを許す場合があることに注意してください。権限受領者ロールが追加のロールに付与されている可能性があるからです。

- デフォルトで付与されているロールからは、EXEMPT DATA REDACTIONシステム権限を取り消さないでください。

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ポリシー

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

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

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

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

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

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

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

関連項目:

ごみ箱からのオブジェクトの消去の詳細は、Oracle Database管理者ガイドを参照してください。

用語集

実際のデータ

Oracle Data Redactionで、保護表または保護ビューにあるデータ。実際のデータには数字123456789などがあり、この数字のリダクションされたデータは、999996789になります。

自動ログイン・ソフトウェア・キーストア

システム生成のパスワードによって保護され、セキュリティ管理者によって明示的に開かれる必要のないソフトウェア・キーストア。自動ログイン・ソフトウェア・キーストアは、アクセス時に自動的に開かれます。また、Oracleデータベースを実行しているすべてのコンピュータで使用できます。たとえば、4つのノードそれぞれが別のコンピュータに存在するOracle RAC環境があるとします。この環境で自動ログイン・キーストアが使用されます。REKEY操作がノード1で実行されると、自動ログイン・キーストアとパスワードベースのキーストアを、ノード2、3および4をホストするコンピュータにコピーする必要があります。この構成では、自動ログイン・キーストアは必要な場合に4つのノードすべてで開きます。

「ローカル自動ログイン・ソフトウェア・キーストア」も参照してください。

暗号スイート

Secure Sockets Layer (SSL)を使用して、ネットワーク・ノード間でメッセージを交換するために使用される認証、暗号化およびデータ整合性のアルゴリズムのセット。たとえば、SSLハンドシェイク時に、2つのノードでネゴシエーションを行い、メッセージを交換するときにどの暗号スイートを使用するかを確認します。

暗号文

暗号化されたメッセージ・テキスト。

「暗号化テキスト」も参照してください。

データ・リダクション

様々な値でデータをリアルタイム(ユーザーがデータにアクセスしようとする瞬間)にマスクする機能。すべてのデータまたは一部のデータをマスクしたり、データのかわりにランダム値を表示できます。データベースの実際のデータは変更されません。

復号化

暗号化されたメッセージ(暗号文)を元のメッセージ(平文)に変換する処理。

暗号化テキスト

暗号化アルゴリズムおよび暗号化鍵を使用して暗号化されたテキスト。暗号化プロセスの出力ストリーム。テキストは、最初に復号化しないと読取りまたは解読できません。暗号文とも呼ばれます。

暗号化

元のメッセージ(平文)を暗号化されたメッセージ(暗号文)に変換する処理。

ハードウェア・キーストア

ハードウェア・セキュリティ・モジュール用の透過的データ暗号化鍵を格納するコンテナです。

ハードウェア・セキュリティ・モジュール

暗号化鍵を安全に格納する物理デバイスです。

推論

問合せを繰り返し試行してデータを検出するように設計された問合せ。たとえば、最高額の給与を得ているユーザーを検出する場合、侵入者は次の問合せを使用できます。

SELECT FIRST_NAME, LAST_NAME, SALARY FROM HR.EMPLOYEES WHERE SALARY > 16000 ORDER BY SALARY DESC;

FIRST_NAME           LAST_NAME                     SALARY
-------------------- ------------------------- ----------
Steven               King                           24000
Neena                Kochhar                        17000
Lex                  De Haan                        17000

鍵のペア

公開鍵とそれに対応する秘密鍵。「公開鍵と秘密鍵のペア」を参照。

キーストア

透過的データ暗号化鍵などの暗号化鍵およびその他の暗号化されたデータを格納するコンテナに対する一般的な用語です。以前のリリースでは、このコンテナはウォレットと呼ばれ、Oracle固有のものでした。Oracle Database 12cリリース12.1からは、この用語はハードウェア・セキュリティ・モジュールなどのOracle Database以外の暗号化鍵コンテナを含めるように変わりました。

「自動ログイン・ソフトウェア・キーストア」、「ハードウェア・キーストア」および「ローカル自動ログイン・ソフトウェア・キーストア」も参照してください。

ローカル自動ログイン・ソフトウェア・キーストア

作成されたコンピュータ上に制限されるローカルのソフトウェア・キーストア。

「自動ログイン・ソフトウェア・キーストア」も参照してください。

マスク

ユーザーまたはアプリケーションからデータをリダクションする機能。

パスワードベースのソフトウェア・キーストア

アクセスする前にパスワードで開く必要のあるソフトウェア・キーストア。

キーストアも参照してください。

平文

暗号化されていないメッセージ・テキスト。

秘密鍵

公開鍵暗号化では、この鍵が、その所有者のみが知る秘密鍵になります。主に、デジタル署名で使用されるメッセージ・ダイジェストの暗号化に使用されます。

「公開鍵と秘密鍵のペア」を参照。

公開鍵

公開鍵暗号で使用される2つの鍵の1つ。もう一方は秘密鍵です。公開鍵暗号の一般的な使用方法では、公開鍵はデータを暗号化するとき、またはデジタル署名を検証するときに使用されます。秘密鍵は、データを復号化するとき、またはデジタル署名を生成するときに使用されます。公開鍵は誰でも使用できますが、秘密鍵は秘密のまま管理されます。

「公開鍵と秘密鍵のペア」を参照。

公開鍵暗号化

メッセージの送信側が受信側の暗号化鍵を暗号化する処理。配信されたメッセージは、受信側の秘密鍵で復号化されます。

公開鍵と秘密鍵のペア

暗号化および復号化に使用される関連する2つの数字のセットで、1つは秘密鍵、もう1つは公開鍵と呼ばれます。公開鍵は通常広く使用可能であるのに対して、秘密鍵はそれぞれの所有者によって保持されます。鍵のペアの公開鍵または秘密鍵で暗号化されたデータは、鍵のペアのうち関連付けられている鍵で復号化できます。

公開鍵インフラストラクチャ

公開鍵暗号化の原理を利用した情報セキュリティ・テクノロジ。公開鍵暗号化には、共有の公開鍵と秘密鍵のペアを使用した情報の暗号化および復号化が含まれます。パブリック・ネットワーク内にセキュアでプライベートな通信を提供します。

リダクションされたデータ

問合せユーザーに表示される、マスクされたデータ。たとえば、実際のデータが3714-4963-5398-4321の場合、データ・リダクション・ポリシーに従って、リダクションされたデータはXXXX-XXXX-XXXX-4321として表示されます。

salt

暗号化技術において、暗号化されたデータのセキュリティを強化する方法。データが暗号化される前に追加されるランダムな文字列で、攻撃者が暗号文のパターンを既知の暗号文サンプルに一致させてデータを盗むことを困難にします。saltは通常、辞書攻撃(攻撃者が秘密のパスワードを特定するために使用する方法)を防ぐために、ハッシュ化される前のパスワードにも追加されます。saltを前もって知ることはできないため、ハッシュ化の前にsaltをパスワードに追加することで、侵入者は、ハッシュ値(ベリファイアとも呼ばれる)を一般的なパスワード・ハッシュ値の辞書リストと照合することがより困難になります。

ソフトウェア・キーストア

自動ログイン・ソフトウェア・キーストア、ローカル自動ログイン・ソフトウェア・キーストアまたはパスワードベースのソフトウェア・キーストアとして使用するために透過的データ暗号化のTDEマスター暗号化鍵を格納したコンテナ。

表領域暗号化鍵

表領域の暗号化の暗号化鍵。TDE表領域暗号化鍵は表領域暗号化鍵を暗号化し、表領域暗号化鍵は表領域のデータの暗号化および復号化を行います。

TDEマスター暗号化鍵

ソフトウェア・キーストアまたはハードウェア・キーストア内に格納された鍵。表の暗号化では、この鍵によってTDE表キーが暗号化され、表領域の暗号化では、この鍵によって表領域暗号化鍵が暗号化されます。

キーストアも参照してください。

TDE表キー

列が暗号化用にマークされている表に関連付けられた暗号化鍵。TDEマスター暗号化鍵は、この表暗号化鍵を暗号化します。

ウォレット

個々のエンティティのセキュリティ資格証明を格納したり、管理するために使用されるデータ構造。ウォレットはOracle Databaseのみの固有のものです。ウォレット・リソース・ロケータ(WRL)は、ウォレットを探すために必要なすべての情報を提供します。Oracle Databaseリリース12c以降の透過的データ暗号化の場合、ウォレットがキーストアになります。

ウォレット不明瞭化

アクセスの前に、ユーザーにパスワードを問い合せずにOracleウォレットを格納およびアクセスする機能です(シングル・サインオン(SSO)をサポートしています)。

ウォレット・リソース・ロケータ(WRL)

ウォレットを探すために必要なすべての情報を提供するツールです。ウォレットの保存場所であるオペレーティング・システムのディレクトリへのパスです。

索引

A  C  D  E  G  H  I  K  M  N  O  P  R  S  T  U  V  X

A

- 管理について 1

- 非定型ツール

- Oracle Data Redaction 1

- ポリシーへの管理アクセス, 制限 1

- 集計関数

- データ・リダクション・ポリシー最適化に対する影響 1

- ALTER SYSTEM文

- ADMINISTER KEY MANAGEMENT文との比較 1

- APEX_UTIL.GET_NUMERIC_SESSION_STATEファンクション

- Oracle Data Redactionポリシー(NVパブリック・ファンクション) 1

- APEX_UTIL.GET_SESSION_STATEファンクション

- Oracle Data Redactionポリシー(Vパブリック・ファンクション) 1

- アプリケーション

- データベース・アプリケーションおよびOracle Data Redaction 1

- 透過的データ暗号化を使用するための変更 1

- 自動ログイン・キーストア

- および透過的データ暗号化(TDE) 1

- 自動ストレージ管理(ASM)

- ソフトウェア・キーストアの移動 1

C

- CDB

- データ・リダクションのマスキング・ポリシー 1

- 暗号化されたデータがあるPDB 1

- rootでのTDE操作 1

- ルートおよびPDBでのTDE操作 1

- チェンジ・データ・キャプチャ, 同期 1

- ハードウェア・キーストアを閉じる 1

- ソフトウェア・キーストアを閉じる 1

- 列の暗号化

- 概要 1

- アルゴリズムの変更 1

- 暗号化鍵の変更 1

- 暗号化された表の列をデフォルトのアルゴリズムで作成 1

- 暗号化された表の列をデフォルト以外のアルゴリズムで作成 1

- 索引または暗号化列の作成 1

- 暗号化するデータ型 1

- 既存の表

- 概要 1

- 暗号化列の追加 1

- 暗号化の無効化 1

- 暗号化されていない列の暗号化 1

- 外部表 1

- 非互換性 1

- 制限事項 1

- パフォーマンス, 最適化 1

- 制限事項 1

- salt 1

- セキュリティに関する考慮事項 1

- 整合性チェックのスキップ 1

- 法令順守

- 透過的データ暗号化 1

- 透過的データ暗号化のデータの圧縮 1

- ソフトウェア・キーストアの構成

- ローカル自動ログイン・キーストアの作成 1

D

- 保存データ 1

- データベース・リンク

- Oracle Data Redactionポリシー 1

- データベースのロール

- データ・リダクション・ポリシー 1

- 透過的データ暗号化のデータのデータ重複除外 1

- データ・リダクション

- 「Oracle Data Redaction」を参照

- データ記憶域

- 透過的データ暗号化 1

- DDL文

- Oracle Data Redactionポリシー 1

- DML文

- Oracle Data Redactionポリシー 1

E

- カスタム形式の編集 1

- ポリシーの編集 1

- エディション

- 透過的データ暗号化 1

- 暗号化 1

- 「透過的データ暗号化(TDE)」も参照

- EXEMPT REDACTION POLICY権限

- Database Vaultでの使用 1

- 外部キーストア 1

- パスワード用の外部ストア 1

G

- ガイドライン

- 非定型な問合せの攻撃とデータ・リダクション 1

- データ・リダクション・ポリシーで扱われるアプリケーションのコンテキスト値 1

- 日常の操作とデータ・リダクション 1

- DDL文とデータ・リダクション・ポリシー 1

- 総当たりSQL問合せおよび推論とデータ・リダクション 1

- マテリアライズド・ビューとデータ・リダクション 1

- ごみ箱とデータ・リダクション 1

- SYS_CONTEXT値とデータ・リダクション 1

H

- ハードウェア・キーストア

- バックアップ 1

- 閉じる 1

- ハードウェア・セキュリティ・モジュール

- キーストアのバックアップ 1

- PDBのプラグ 1

- PDBのアンプラグ 1

I

- インポート/エクスポート・ユーティリティ, オリジナル 1

- インデックス

- 暗号化列に作成 1

- 索引レンジ・スキャン 1

- インライン・ビュー

- データ・リダクション・ポリシーのリダクションの順序 1

- Data Redactionのリダクション 1

- 侵入者

- 非定型な問合せの攻撃 1

K

- キーストア

- 概要 1

- アーキテクチャ 1

- ASMベース 1

- 自動ログイン 1

- パスワードベースのソフトウェア・キーストアのバックアップ

- 概要 1

- バックアップ識別子のルール 1

- プロシージャ 1

- ハードウェア・キーストアのパスワードを変更 1

- パスワードベースのソフトウェア・キーストアのパスワードを変更 1

- ハードウェア・キーストアを閉じる 1

- ソフトウェア・キーストアを閉じる 1

- 削除 1

- 外部 1

- ハードウェア・キーストア

- 構成プロセス 1

- インポートまたはエクスポートとは異なるマスター暗号化鍵のマージ 1

- マージ

- 概要 1

- パスワードベースへの自動ログイン 1

- あるものを既存の別のキーストアへ 1

- マージ操作を戻す 1

- 2つを3つ目の新しいキーストアへ 1

- 移行

- ハードウェア・キーストアベースの暗号化に関するマスター暗号化鍵を作成 1

- ハードウェア・キーストアからソフトウェア・キーストア 1

- 移行後のキーストアの順序 1

- ハードウェア・キーストアへのパスワード鍵 1

- Oracle Key Vaultを使用した移行 1

- ASMからの移動 1

- 新しい場所へソフトウェア・キーストアを移動 1

- ハードウェア・キーストアを開く 1

- ソフトウェア・キーストアを開く 1

- Oracle Databaseのシークレット

- 概要 1

- ハードウェア・キーストアに格納 1

- ソフトウェア・キーストアに格納 1

- 自動ログイン・ハードウェア・キーストアの使用 1

- キーストア, ソフトウェア

- 作成について 1

- 構成プロセス 1

- パスワード用の外部ストア 1

M

- マスキング

- 「Oracle Data Redaction」を参照

- マスター暗号化鍵

- 「TDEマスター暗号化鍵」を参照

- マテリアライズド・ビュー

- データ・リダクションのガイドライン 1

- 透過的データ暗号化表領域暗号化 1

- マルチテナント・コンテナ・データベース

- 「CDB」を参照

N

- ネストした関数

- データ・リダクション・ポリシーのリダクションの順序 1

- NVパブリック・ファンクション(APEX_UTIL.GET_NUMERIC_SESSION_STATEファンクション), データ・リダクション・ポリシー 1

O

- OLS_LABEL_DOMINATESパブリック・ファンクション

- データ・リダクション・ポリシー 1

- ハードウェア・キーストアを開く 1

- ソフトウェア・キーストアを開く 1

- ORA-00979

- 「GROUP BYの式ではありません。」エラー 1

- ORA-28081

- 「権限が不十分です - コマンドはリダクション済のオブジェクトを参照しています。」エラー 1

- Oracle Application Express

- データ・リダクション・ポリシーのセッション状態によるフィルタ使用方法 1

- Oracle Call Interface

- 透過的データ暗号化 1

- Oracle Database Real Application Security

- データ・リダクション 1

- Oracle Database Vault

- データ・リダクションでの使用 1

- Oracle Data Guard

- 透過的データ暗号化 1

- Oracle Data Pump

- 暗号化された列 1

- 暗号化データ 1

- ダンプ・セットで暗号化されたデータ 1

- データ・リダクション・ポリシーからエクスポートされたデータ 1

- Oracle Data Redactionオブジェクトのエクスポート 1

- データ・リダクション・ポリシーからインポートされたデータ 1

- Oracle Data Redactionセキュリティ・ポリシー 1

- Oracle Data Redaction

- 概要 1 , 2

- 非定型ツール 1

- 集計関数 1

- 利点 1

- CDB 1

- XML生成データを含む列 1

- カスタム形式の作成 1

- データベース・アプリケーション 1

- DBMS_REDACT.ADD_POLICYプロシージャ

- 使用 1

- DBMS_REDACT.ALTER_POLICYプロシージャ

- 概要 1

- 例 1

- 様々な操作に必要なパラメータ 1

- 構文 1

- DBMS_REDACT.DISABLE_POLICY

- 概要 1

- 例 1

- 構文 1

- DBMS_REDACT.DROP_POLICY

- 概要 1

- 例 1

- 構文 1

- DBMS_REDACT.ENABLE_POLICY

- 概要 1

- 例 1

- 構文 1

- DBMS_REDACT.UPDATE_FULL_REDACTION_VALUESプロシージャ

- 概要 1

- 構文 1

- 使用 1

- ポリシーの削除 1

- カスタム形式の編集 1

- エディション 1

- Enterprise Manager Cloud Control 1 , 2 , 3 , 4 , 5

- Enterprise Manager Cloud Controlのワークフロー 1

- データ・ポンプ・エクスポートを使用してデータをエクスポート 1

- データ・ポンプを使用してオブジェクトをエクスポート 1

- 完全なデータ・リダクション

- 概要 1

- ポリシーの作成 1

- 例 1

- デフォルト値の変更 1

- 構文 1

- Oracle Database Real Application Securityマスキングとの相違点 1

- Oracle Virtual Private Databaseマスキングとの相違点 1

- データ・ポンプ・エクスポートを使用してデータをインポート 1

- インライン・ビューのリダクションの順序 1

- ポリシーの管理 1

- ネストした関数のリダクションの順序 1

- データ・リダクションなし

- 概要 1 , 2

- ポリシーの作成 1

- 例 1

- 構文 1

- Oracle Data Pumpセキュリティ・ポリシー 1

- Oracle Enterprise Manager Data Masking and Subsetting Pack 1

- 部分的なデータ・リダクション

- 概要 1

- キャラクタ・タイプ, ポリシー 1

- 日時データ型 1

- 文字データ型の使用例 1

- 日時データ型の使用例 1

- 固定文字形式を使用する例 1

- 数値データ型の使用例 1

- 形式, 固定文字 1

- 数値データ型 1

- 構文 1

- ポリシー作成の権限 1

- ランダム・データ・リダクション

- 概要 1

- ポリシーの作成 1

- 例 1

- ランダム化されたデータ・リダクション

- 概要 1

- 正規表現によるデータ・リダクション

- ポリシーの作成 1

- カスタム, ポリシーの作成 1

- 例 1

- カスタムの例 1

- 形式 1

- 形式, ポリシーの作成 1

- 設定 1

- 構文 1

- 正規表現によるリダクション

- 概要 1

- SYSスキーマ・オブジェクト 1

- SYSTEMスキーマ・オブジェクト 1

- 使用例 1

- カスタム形式の表示 1

- 使用する状況 1

- WHERE句のリダクション 1

- Oracle Data Redaction, データベース・リンク 1

- Oracle Data Redaction:Enterprise Manager Cloud Control 1

- Oracle Data RedactionEnterprise Manager Cloud Control

- カスタム形式の削除 1

- Oracle Data Redaction形式

- Cloud Controlでの管理について 1

- Cloud Controlでの表示 1

- Cloud Controlでの作成 1

- Cloud Controlでの削除 1

- Cloud Controlでの編集 1

- 機密列タイプ 1

- Oracle Data Redactionの部分リダクション

- ポリシーの作成 1 , 2

- Oracle Data Redactionポリシー

- 概要 1

- 変更 1

- レポートの作成 1

- 作成

- 例 1

- 一般的な構文 1

- プロシージャ 1

- Cloud Controlでの作成 1

- Cloud Controlでの削除 1

- 無効化 1

- Cloud Controlでの無効化 1

- 削除 1

- Cloud Controlでの編集 1

- 有効化 1

- ユーザーの除外 1

- 式

- Application Expressセッション状態 1

- データベース・ロール 1

- OLSラベル優位による 1

- ユーザー環境 1

- ユーザーのフィルタリング

- 概要 1

- フィルタリングなし 1

- 情報の検索 1

- Oracle Enterprise Manager Cloud Control 1

- 1つのポリシーにおける複数列のリダクション 1

- Cloud Controlでの表示 1

- Oracle Enterprise Manager Cloud Control

- カスタム形式の作成 1

- ポリシーの作成 1

- ポリシーの無効化 1

- Oracle Data Redaction 1 , 2 , 3 , 4 , 5 , 6

- ポリシーの詳細の表示 1

- 形式の表示 1

- Oracle Enterprise Manager Data Masking and Subsetting Pack

- Oracle Data Redactionの影響 1

- Oracle GoldenGate

- Oracleキーストアへのシークレットの格納 1

- Oracle Key Vault

- キーストアの移行 1

- Oracle Real Application Clusters

- TDEキーストアを格納するための非共有ファイル・システム 1

- 透過的データ暗号化 1

- Oracle Recovery Manager

- 透過的データ暗号化 1

- Oracle Securefiles

- 透過的データ暗号化 1 , 2

- Oracle Virtual Private Database(VPD)

- データ・リダクション 1

- orapkiユーティリティ

- ADMINISTER KEY MANAGEMENT文との比較 1

- オリジナルのインポート/エクスポート・ユーティリティ 1

P

- PDB

- データ・リダクション・ポリシー 1

- すべてのPDBに関するTDEキーストア・ステータスの検索 1

- マスター暗号化鍵

- エクスポート 1

- インポート 1

- 透過的データ暗号化 1

- パフォーマンス

- 透過的データ暗号化 1

- PKI暗号化

- バックアップおよびリカバリ操作 1

- ハードウェア・キーストア 1

- マスター暗号化鍵 1

- 表領域の暗号化 1

- プラガブル・データベース

- 「PDB」を参照

R

- ごみ箱

- データ・リダクション・ポリシー 1

- レポート

- 基礎となるデータ・リダクション・ポリシー 1

- ローテーション

- マスター暗号化鍵 1

S

- salt

- 削除 1

- salt (TDE)

- 追加 1

- シークレット

- キーストアへのOracle Databaseのシークレットの格納

- 概要 1

- ハードウェア・キーストアに格納 1

- ソフトウェア・キーストアに格納 1

- SecureFiles

- 透過的データ暗号化 1 , 2

- 機密列タイプ 1

- 同期チェンジ・データ・キャプチャ 1

- SYS_CONTEXT関数

- データ・リダクション・ポリシー 1

- データ・リダクションで使用されているSYS_SESSION_ROLESネームスペース 1

- SYS_SESSION_ROLES SYS_CONTEXTネームスペース

- データ・リダクション 1

- SYSTEMユーザー

- データ・リダクション・ポリシー 1

- SYSユーザー

- データ・リダクション・ポリシー 1

T

- 表領域の暗号化

- 概要 1

- アーキテクチャ 1

- 暗号化された表領域の作成 1

- 例 1

- 非互換性 1

- キーストアを開く 1

- パフォーマンス, 最適化 1

- パフォーマンスのオーバーヘッド 1

- プロシージャ 1

- 制限事項 1

- 平文のフラグメントに関するセキュリティ上の考慮事項 1

- 表領域の鍵の設定 1

- 記憶域のオーバーヘッド 1

- 表領域マスター暗号化鍵

- 設定 1

- TDE

- 「透過的データ暗号化(TDE)」を参照

- TDEマスター暗号化鍵

- アクティブ化

- 概要 1

- 例 1

- プロシージャ 1

- アーキテクチャ 1

- 属性 1

- 今後の使用のために作成

- 概要 1

- 例 1

- プロシージャ 1

- カスタム属性タグ

- 概要 1

- 作成 1

- 許可されない無効化 1

- エクスポート 1

- PDBでのエクスポート 1

- 現在使用されている鍵の検出 1

- インポート 1

- PDBでのインポート 1

- インポートまたはエクスポートとは異なるキーストアのマージ 1

- キーストアにおけるリセット 1

- ローテーション 1

- キーストアにおける設定 1

- 透過的データ暗号化(TDE)

- 概要 1

- 利点 1

- CDB

- ルートまたはPDBでの操作 1

- 列の暗号化

- 概要 1 , 2

- 既存の表への暗号化列の追加 1

- アルゴリズムの変更 1

- 暗号化鍵の変更 1

- 外部表への暗号化列の作成 1

- 索引または暗号化列の作成 1

- デフォルトの暗号化アルゴリズムで表を作成 1

- 非デフォルト暗号化アルゴリズムで表を作成 1

- サポートされているデータ型 1

- 既存の列における暗号化の無効化 1

- 既存の表にある列の暗号化 1

- 既存の列の暗号化 1

- 暗号化および整合性アルゴリズム 1

- 制限事項 1

- 暗号化された列のsalt 1

- アプリケーション・ソフトウェアとの互換性 1

- Oracle Databaseツールとの互換性 1

- 暗号化データの圧縮 1

- ハードウェア・キーストアの構成

- 概要 1

- 構成手順 1

- 開く 1

- PKCS#11ライブラリ, 1

- ソフトウェア・キーストアの再構成 1

- マスター暗号化鍵の設定 1

- sqlnet.ora構成, 1

- ソフトウェア・キーストアの構成

- 概要 1

- 自動ログインのキーストアの作成 1

- パスワードベースのキーストアの作成 1

- キーストアを開く 1

- ソフトウェアのマスター暗号化鍵の設定 1

- sqlnet.oraファイル構成 1

- 暗号化データのデータ重複除外 1

- エディション 1

- 暗号化および整合性アルゴリズム 1

- 情報の検索 1

- よくある質問 1

- 非互換性 1

- キーストア管理

- ASMベースのキーストア 1

- パスワードベースのソフトウェア・キーストアのバックアップ 1

- ハードウェア・キーストアのパスワードを変更 1

- パスワードベースのソフトウェア・キーストアのパスワードを変更 1

- ハードウェア・キーストアを閉じる 1

- ソフトウェア・キーストアを閉じる 1

- マスター暗号化鍵の属性 1

- キーストアのマージ, 概要 1

- キーストアのマージ, パスワードベースへの自動ログイン 1

- キーストアのマージ, 既存のキーストアへ 1

- キーストアのマージ, マージ操作を戻す 1

- キーストアのマージ, 2つを3つ目の新しいキーストアへ 1

- パスワード鍵およびハードウェア・キーストアの移行, マスター暗号化鍵の作成 1

- パスワード鍵およびハードウェア・キーストアの移行, 移行を戻す 1

- パスワード鍵およびハードウェア・キーストアの移行, sqlnet.ora構成 1

- キーストア

- 概要 1

- 利点 1

- タイプ 1

- マスター暗号化鍵

- ローテーション 1

- マスター暗号化鍵の属性

- 概要 1

- カスタム・タグの作成 1

- マスター暗号化鍵

- エクスポートとインポート 1

- キーストアにおけるリセット 1

- キーストアにおける設定, 概要 1

- キーストアにおける設定, 手順 1

- 組み合せて使用するためのアプリケーションの変更 1

- マルチデータベース環境 1

- Oracle Call Interface 1

- Oracle Data Guard 1

- Oracle Data Pump

- ダンプ・セットに関するエクスポートおよびインポート操作 1

- 暗号化された列に関するエクスポートおよびインポート操作 1

- Oracle Data Pumpのエクスポートおよびインポート操作

- 概要 1

- Oracle Real Application Clusters

- 概要 1

- キーストアを格納するための非共有ファイル・システム 1

- Oracle Recovery Manager

- キーストア 1

- PDB

- 概要 1

- すべてのPDBに関するキーストア・ステータスの検索 1

- rootでの操作 1

- パフォーマンス

- データベース・ワークロード 1

- データ・セット全体の復号化 1

- 最適化 1

- 最悪なケースのシナリオ 1

- パフォーマンスのオーバーヘッド

- 概要 1

- 標準 1

- PKI暗号化 1

- 必要な権限 1

- SecureFiles 1 , 2

- セキュリティ上の考慮点

- 列の暗号化 1

- 一般的なアドバイス 1

- 平文のフラグメント 1

- 記憶域のオーバーヘッド 1

- Oracle GoldenGateのシークレットの格納 1

- 表領域の暗号化

- 概要 1 , 2

- 作成 1

- 暗号化および整合性アルゴリズム 1

- 例 1

- キーストアを開く 1

- 制限事項 1

- マスター暗号化鍵の設定 1

- 表領域の暗号化, COMPATIBLEパラメータでの設定 1

- ビュー 1

- 透過的データ暗号化(TDE)整合性

- 列の暗号化

- 整合性チェックなしで表を作成(NOMAC) 1

- パフォーマンスの向上 1

- NOMACパラメータ(TDE) 1

- 透過的データ暗号化(TDE)キーストア

- 削除 1

- 新しい場所へソフトウェア・キーストアを移動 1

- トランスポータブル表領域 1

U

- ユーティリティ, インポート/エクスポート 1

V

- V$ENCRYPTION_WALLETビュー

- 移行後のキーストアの順序 1

- ビュー

- データ・リダクション 1

- Vパブリック・ファンクション(APEX_UTIL.GET_SESSION_STATEファンクション), データ・リダクション・ポリシー 1

X

- XMLの生成 1

Oracleの法律上の注意点

コピーライト

Copyright © 1994-2017, Oracle and/or its affiliates. All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクルまでご連絡ください。

制限付権利について

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

Pre-General Availability (一般提供前)版のドキュメントについて

このドキュメントがPre-General Availability (一般提供前)版の場合:

このドキュメントはPre-General Availability (一般提供前)版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のPre-General Availability (一般提供前)版のドキュメントについて

このドキュメントが非公開のPre-General Availability (一般提供前)版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のPre-General Availability Trial Agreement (Pre-GAトライアル契約)のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle Partner Network Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

ドキュメントのアクセシビリティ

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info)か、聴覚に障害のあるお客様は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。