B OKM を Advanced Security の Transparent Data Encryption (TDE) とともに使用する

この付録では、機密性のあるデータベース情報の暗号化または復号化を管理するために、Transparent Data Encryption (TDE) とともに OKM を使用することについて説明します。このソリューションでは、Oracle StorageTek テープドライブで使用されているのと同じ暗号化テクノロジーを使用して、Oracle データベースの暗号化鍵を管理できます。

Oracle Database 11gR2 の機能である Transparent Data Encryption は、次に対してデータベースの暗号化および復号化のサービスを提供します。

Oracle Database 製品
Oracle Real Application Clusters (Oracle RAC)
Oracle Data Guard
Oracle Exadata Database Machine
Oracle Recovery Manager (RMAN)
Oracle Data Pump

この付録では、TDE に精通していることを想定しています。次の URL から入手できる Oracle Advanced Security Transparent Data Encryption のベストプラクティスに関するドキュメントを参照してください。

http://www.oracle.com/us/products/database/twp-transparent-data-encryption-bes-130696.pdf

Transparent Data Encryption (TDE) の概要

図 B-1 に、Oracle データベースと Transparent Data Encryption (TDE) を利用した OKM クラスタを示しています。OKM クラスタの基本コンポーネントの詳細については、章 1, "概要"を参照してください。

図 B-1 TDE を使用した OKM クラスタ

TDE は、TDE 列の暗号化およびテーブル領域の暗号化に、2 層鍵アプローチを使用した暗号化サービスを提供します。マスター暗号化鍵は、第 1 層で使用され、データベース内に格納されている第 2 層のテーブルまたはテーブル領域のデータ暗号化鍵を暗号化します。

TDE は、マスター暗号化鍵を外部のセキュリティーモジュール (Oracle Wallet または HSM) に格納します。これは、セキュリティーの実践として推奨されており、さまざまな脅威に対してもっとも高いレベルのセキュリティーを維持するために重要です。TDE のマスター暗号化鍵のセキュアなストレージのために OKM を使用することは推奨されるアプローチです。

TDE で OKM を使用するように構成すると、OKM は AES256 マスター暗号化鍵を作成し、安全に保護します。OKM は、レプリケーション (クラスタ内の複数のコピー) および OKM 自体のバックアップにより鍵を保護します。

障害回復計画については、OKM の障害回復に関するガイドを参照してください。

OKM の PKCS#11 プロバイダ

PKCS#11 プロバイダは、Oracle Solaris および Oracle Linux で利用可能であり、TDE が OKM と連動することが認証されています。このプロバイダは、「pkcs11_kms」と呼ばれます。TDE は、組み込みでサポートされている Hardware Security Module (HSM) を使用して pkcs11_kms プロバイダを利用するように構成できます。

pkcs11_kms プロバイダは、鍵の作成操作および鍵の取得操作のために OKM と対話します。TDE などの PKCS#11 コンシューマアプリケーションは、暗号化および復号化機能のために使用する鍵を取得するために pkcs11_kms プロバイダを使用できます。これらのアプリケーションは鍵オブジェクトを識別する際、それらが定義するラベルを使用します。TDE は、マスター鍵が作成されたときにこのラベルを生成します。pkcs11_kms プロバイダは、このラベルを OKM に渡し、そこでデータユニットのメタデータとして維持管理されます。OKM では、鍵はデータユニットと関連付けられ、pkcs11_kms プロバイダの場合、この関係は常に 1 対 1 です。新しいマスター鍵が作成されるたびに、対応する鍵オブジェクトとともに鍵ラベルを持つデータユニットが作成されます。

詳細については、"OKM 内の TDE マスター鍵の検出"を参照してください。

OKM での TDE の認証

管理ユーザーのログイン、鍵素材を取得するテープドライブ、または Oracle TDE などの PKCS#11 コンシューマのいずれであっても、OKM と対話するすべてのエンティティーは認証する必要があります。

TDE は、pkcs11_kms プロバイダを利用するために構成された特定のトークンを使用して OKM で認証します。このトークンは、セッションの各パーティー (具体的には、Oracle データベースインスタンスおよび OKM クラスタノード) の相互認証のためにパスワードベースの認証および X.509 証明書を使用します。これらの資格を PKCS#11 に適切に渡すように TDE を構成する必要があります。

構成の手順については、この付録の最初に参照した Oracle Advanced Security Transparent Data Encryption のベストプラクティスに関するドキュメントを参照してください。

認証資格の管理

OKM では、pkcs11_kms プロバイダを使用してエージェントの認証資格を管理できます。ポリシーの規定に応じて、エージェントのパスフレーズのリセット、およびエージェントの有効化、無効化、または削除を行うことができます。

セキュリティー違反が検出された場合、鍵の取得が拒否されるように特定のエージェントを無効化し、同時に、ほかのアプリケーションまたはデバイスにサービスを提供するほかのエージェントのアクセスは維持できます。

エージェントのパスフレーズをリセットする場合、pkcs11_kms プロバイダがスロット構成を格納するディレクトリ内のプロファイルディレクトリを削除します (たとえば、KMSTOKEN_DIR ディレクトリによって識別される場所)。

負荷分散とフェイルオーバー

pkcs11_kms プロバイダは、OKM クラスタサービス、ロードバランサ、およびクラスタのフェイルオーバーロジックを使用して OKM クラスタを認識します。pkcs11_kms プロバイダは、クラスタ発見操作を定期的に発行することにより、OKM クラスタに対するクライアント側の認識を透過的に維持します。ネットワークの変更および OKM クラスタまたは KMA の可用性の変更は、pkcs11_kms プロバイダおよび TDE に代わって、エージェントが処理します。PKCS#11 の鍵生成および鍵取得の操作は、OKM クラスタの KMA 間で負荷分散されます。

鍵取得のパフォーマンスをさらに最適化するために、OKM サイトを使用してエージェントが KMA に関連付けられるように構成できます。この機能を使用すると、ネットワークトポロジに応じてサイトを定義できます。通常、サイト内の KMA およびエージェントは、WAN を経由するメンバー KMA およびエージェントと比べて、ネットワークの待機時間が短くなります。

ネットワークセグメントまたは KMA が利用できない場合は、エージェント内のフェイルオーバーロジックによって、別の KMA が選択されて操作が完了します。TDE ではフェイルオーバーが認識されないため、鍵管理操作は非常に信頼性が高くなります。フェイルオーバーでは、同じサイト内の KMA がエージェントとして優先されます。

kmscfg(1M) ユーティリティーを使用すると、発見の頻度およびエージェントのフェイルオーバープロパティーを調整できます。詳細は、kmscfg のマニュアルページを参照してください。

計画に関する考慮事項

以降ではさまざまな計画トピックについて説明します。

Oracle Database に関する考慮事項
OKM のパフォーマンスおよび可用性に関する考慮事項
障害回復の計画
ネットワークの計画
鍵管理の計画。

Oracle Database に関する考慮事項

OKM は次のすべての Oracle Database 構成と互換性があります。

単一インスタンス、Oracle RAC One Node
Oracle Database 高可用性アーキテクチャー
- Oracle RAC
  
  Oracle Database と Oracle Real Application Clusters (Oracle RAC) の組み合わせは OKM を使用できることが認証されています。Oracle RAC システムの各ノードには、TDE が使用する構成済みの pkcs11_kms プロバイダがある必要があります。すべてのノードは、認証用に同じ OKM エージェント ID を共有する必要があります。Oracle RAC では、ネットワークトポロジとして、パブリックおよびプライベートネットワークを利用します。Oracle RAC のノード間トラフィックに使用されるプライベートネットワークは、鍵取得トラフィックをより良く分離するために OKM のサービスネットワークと共有できます。このプライベートネットワークの構成方法によっては、これにより、プライベートネットワークの外部の KMA (リモートサイトの KMA など) へのエージェントのフェイルオーバーが妨げられる可能性があります。
  
  Oracle RAC の共有ストレージ要件および pkcs11_kms プロバイダの構成ファイルについては、"OKM と TDE の統合"を参照してください。
- Oracle RAC 拡張クラスタ
  
  この構成では、取得時間を最小化するために、OKM クラスタ内の KMA を Oracle RAC ノードと同じネットワークに配置する必要があります。
- Oracle Exadata Database Machine
  
  前述の"Oracle RAC"を参照してください。
Oracle Data Guard

すべてのセカンダリデータベースは、プライマリデータベースによって使用されるのと同じ OKM クラスタにアクセスします。
複数のデータベースインスタンス

1 つのホスト上で複数の独立したデータベースインスタンスを実行する場合は、各インスタンスに PKCS#11 トークンを構成する必要があります。そのため、各データベースインスタンスに対して OKM エージェントを作成し、OKM へのエージェントの認証をトークンを使用して行います。このタスクを実行するには、kmscfg ツールを使用します。

複数のデータベースインスタンスを同じ O/S ユーザーで実行しているが、異なる OKM エージェントを使用している場合、kmscfg ユーティリティーを起動するたびに、別の場所への KMSTOKEN_DIR 環境変数を設定する必要があります。kmscfg ユーティリティーの詳細については、"TDE 用の OKM の構成"を参照してください。

同じホスト上での複数のデータベースの実行については、この付録の最初に参照した Oracle Advanced Security Transparent Data Encryption のベストプラクティスに関するドキュメントを参照してください。
Oracle RMAN
Oracle Data Pump

OKM のパフォーマンスおよび可用性に関する考慮事項

pkcs11_kms トークンを使用した TDE の鍵取得は、通常、1 回の KMA アクセスで 100 - 200 ミリ秒かかります。フェイルオーバーが発生すると、応答時間はフェイルオーバーの試行回数を乗算した時間になります。

OKM のバックアップ操作および鍵転送操作は、リソースに負荷がかかるアクティビティーであり、OKM データベースのパフォーマンスに影響する場合があります。OKM のバックアップを行うタイミングと対象を十分に計画して決定してください。

OKM のバックアップは、クラスタ全体で行われるため、Oracle Database インスタンスで使用されていない KMA で実行できます。同様に、鍵転送操作もクラスタ全体の操作であり、任意の KMA で実行できます。このため、使用中の Oracle Database インスタンスで利用されていない KMA を選択することを推奨します。

障害回復の計画

OKM の障害回復計画の詳細については、OKM の障害回復に関するガイドおよび Oracle データベースの発行物を参照してください。

障害回復計画での決定事項は、ネットワーク計画の立案に影響します。pkcs11 プロバイダの構成ディレクトリは、障害回復計画の新しい考慮事項です。pkcs11_kms トークンを再構成する必要がないように (特に Oracle RAC のノード間で共有される場合)、このストレージ領域の回復シナリオを検討します。

ネットワークの計画

OKM のクラスタ構成は、Oracle Database サーバーおよび企業の障害回復方針に従って計画する必要があります。OKM のネットワークオプションは、非常に柔軟であり、OKM の管理およびサービスネットワークで使用されるマルチホームのインタフェースが含まれています。詳細は、『Oracle Key Manager システムアシュアランスガイド』を参照してください。

鍵管理の計画

鍵管理の計画では、企業の鍵のライフサイクルおよびセキュリティーポリシーを検討する必要があります。これらの考慮事項によって、必然的にデータ保持について検討することになります。

NIST SP-800 の鍵管理フェーズおよび対応する OKM の鍵の状態については、"状態遷移"を参照してください。
鍵ポリシーが十分な長さの期間に設定されていない場合に発生する可能性がある問題については、"OKM ポリシーベースの鍵の期限切れによる鍵の再作成"を参照してください。

鍵ポリシーに関する考慮事項

すべての TDE マスター鍵は、AES 256 ビットであり、OKM によって生成されます。KMA には、FIPS 140-2 レベル 3 の認定を受けた HSM である Sun Crypto Accelerator 6000 PCIe カードを含めることができます。KMA にこの Hardware Security Module がある場合、鍵は HSM によって作成されます。それ以外の場合、暗号化操作では、Solaris 暗号化フレームワークのソフトウェアトークンプロバイダが利用されます。詳細については、"鍵ポリシー"を参照してください。

鍵のライフサイクル

鍵ポリシーの計画で決定する事項に関しては、鍵のライフサイクルが主な構成項目です。鍵のライフサイクルの運用フェーズの期間は、データ保持の必要性および TDE マスター鍵が再度鍵に作成される頻度に基づいて選択するようにしてください。詳細については、"鍵のライフサイクル"を参照してください。

注:

TDE の DDL は、OKM 内のスキーマ暗号化ダイアログと同様に、さまざまな鍵サイズのマスター鍵の仕様をサポートします。OKM で使用できるのは、AES 256 ビット鍵のみです。

鍵ポリシー暗号化期間

鍵ポリシー暗号化期間は、ライフサイクルが保護および処理 (暗号化および復号化) 状態のときに鍵を使用する期間を定義します。この期間は、マスター鍵が再度鍵に作成されるまでの、マスター鍵を使用する期間に対応するようにしてください (たとえば、PCI の場合、最大 1 年間)。

鍵ポリシー暗号化有効期間

鍵ポリシーの暗号化有効期間は、鍵のライフサイクルが処理のみ (復号化のみ) 状態のときに、マスター鍵を使用したデータの復号化のために割り当てられている残りの時間です。この期間の長さは、TDE マスター鍵によって保護されるデータのデータ保持要件と一致するようにしてください。通常、この値は、企業のデータ保持ポリシーに対応する年数となります (たとえば、米国の税務記録の場合、保持期間は 7 年間です)。

鍵の再作成操作はまれにしか行わないため、新しい鍵を生成する頻度は、TDE とは関係がないはずです。これが問題となる場合は、鍵ポリシーの暗号化期間を長くするか、鍵の再作成の頻度を低くすることを検討します。また、OKM の鍵プールサイズ構成パラメータを増加させて、利用可能な鍵のより大きいプールを維持管理するように KMA に指示することもできます。

必要に応じて、さまざまなタイプのデータベースで使用するために、複数の鍵ポリシーを定義できます。

鍵グループを使用した鍵アクセス制御

複数のデータベースインスタンスまたは複数のエージェントがさまざまな目的で OKM のクラスタにアクセスする場合、OKM によって管理される鍵へのアクセスを制御する必要がある場合があります。

すべての OKM エージェントには、少なくとも 1 つの鍵グループが割り当てられており (デフォルトの鍵グループへの割り当ては必須です)、このグループにより、グループ内の鍵へのアクセスが認証されます。エージェントのデフォルトの鍵グループは、pkcs11_kms プロバイダのエージェントがその中で鍵を作成する唯一の鍵グループです。

マスター鍵をデータベースインスタンスまたはホスト間で共有する必要がない場合は、複数の鍵グループの使用を検討してください。例としては、ある鍵グループを本番データベースインスタンスで使用し、別の鍵グループを開発/テストのデータベースで使用して、分離が保証されるようにします。テストデータベースの鍵グループのエージェントは、本番データベースのマスター鍵を使用しようとすると、OKM によってブロックされます。また、そのような試行は OKM の監査ログにフラグが付けられ、本番データベースに支障を与える可能性がある構成エラーが存在することを示す場合があります。

TDE は、鍵ラベルの命名規則を使用したマスター鍵の分離も提供します。PKCS#11 の仕様では、鍵のラベルは一意である必要はありません。ただし、OKM は鍵グループに関係なく、ラベルが一意になるように強制し、OKM のクラスタでラベルの名前空間の有効範囲がグローバルになるようにします。別個のデータベースインスタンスの別個のマスター鍵の間でラベルの衝突が発生した場合は、最初に作成されたラベルが常に返されます。同一のラベルを共有する、別の鍵グループに属する鍵にエージェントがアクセスしようとすると、OKM によって拒否されます。これは、鍵の再作成操作の際に捕捉されますが、回避方法は衝突しない別のラベルが生成されるまで鍵を再作成することです。

鍵およびデータ破棄に関する考慮事項

データ保持要件に一致させるためのデータの破棄は、TDE のマスター鍵の破棄から開始できます。これらの鍵を破棄する方法とタイミングは、重要な計画項目です。OKM では、これを行うことができ、これらの鍵が含まれている OKM のバックアップを追跡することもできます。OKM のバックアップの管理は、障害回復計画および鍵の破棄計画の両方の項目です。

OKM と TDE の統合

このセクションでは、pkcs11_kms および OKM クラスタを TDE と一緒に使用するようにインストールおよび構成する方法について説明します。

システム要件

OKM を TDE とともに使用する場合、次の最小バージョンがサポートされます。

Oracle Key Manager

Replication Schema version 13 とともに動作する Oracle Key Manager 2.4.1

GUI および CLI 用にサポートされる OKM 管理プラットフォームについては OKM 製品リリースノートに記載されており、これには Oracle Solaris および Microsoft Windows プラットフォームに固有の考慮事項も含まれています。

pkcs11_kms

SRU 12 を適用した Oracle Solaris 11 Express
Oracle Solaris 11 pkcs11_kms、x86 または SPARC、32 ビットまたは 64 ビット
Oracle Solaris 10 Update 10 pkcs11_kms x86 用パッチ 147441-03 または SPARC 用パッチ 147159-02、32 ビットまたは 64 ビット
Oracle Enterprise Linux (OEL) リリース 5.5。
サポートされる pkcs11_kms プラットフォームおよび必須のパッチ 12626642 を使用した Oracle Database 11.2.0.2。

OKM のインストール

OKM クラスタのインストール手順は OKM のインストールガイドに記載されています。一般的に、OKM のインストールには、計画、インストール、および構成サービスの選択を支援する Oracle プロフェッショナルサービスとの契約が伴います。また、セキュリティーチームが計画プロセスに関与することをお勧めします。

作業用の OKM クラスタを設定したあと、この付録の構成のセクションで説明されている OKM 管理手順に従います。

pkcs11_kms のインストール

OKM の PKCS#11 プロバイダである pkcs11_kms を Oracle データベースサーバーにインストールおよび構成する必要があります。pkcs11_kms のディストリビューションは、次の各プラットフォームで利用できます。

Oracle Solaris 11 または Solaris 11 Express
Oracle Solaris 10 Update 10
Oracle Enterprise Linux

Oracle Solaris 11 または Solaris 11 Express の場合の pkcs11_kms のインストール

次の手順を実行して、pkcs11_kms をインストールします。

pkcs_kms パッケージのバージョンを表示します。
```
#> pkg info -r pkcs11_kms
```
このコマンドの出力を確認します。
Solaris 11 の場合、次のコマンドを入力します。
```
#> pkg install system/library/security/pkcs11_kms
```
Solaris 11 Express の場合、次のコマンドを入力します。
```
#> pkg install system/library/security/crypto/pkcs11_kms 
```
プロバイダを Solaris 暗号化フレームワークにインストールします。
```
# cryptoadm install provider='/usr/lib/security/$ISA/pkcs11_kms.so.1'
```
注:
単一引用符は重要です。cryptoadm(1M) を参照してください。
次の一連のコマンドを入力してインストールを確認します。
```
# cryptoadm list -m -v \
provider='/usr/lib/security/$ISA/pkcs11_kms.so.1'
```
注:
これにより、kmscfg が実行されるまでは「no slots presented」というメッセージが表示されます。

Oracle Solaris 10 Update 10 の場合の pkcs11_kms のインストール

pkcs のディストリビューションは Solaris 10 Update 10 インストールでは「SUNWpkcs11kms」としてインストールされます。

SPARC システムでは Solaris パッチ 147159-03 以降が必要です。
x86 システムでは Solaris パッチ 147441-03 以降が必要です。

Solaris パッチをダウンロードするには、次の URL に移動します。

https://patchstatus.us.oracle.com/patchstatus/

次の手順を実行して、pkcs11_kms をインストールします。

次のコマンドを入力して、ハードウェアプラットフォーム用の pkcs11_kms パッケージをインストールします。
```
# pkgadd [-d path to parent dir of package] SUNWpkcs11kms
```
プロバイダを Solaris 暗号化フレームワークにインストールします。
```
# cryptoadm install provider='/usr/lib/security/$ISA/pkcs11_kms.so.1'
```
注:
単一引用符は重要です。cryptoadm(1M) を参照してください。

Oracle Enterprise Linux の場合の pkcs11_kms のインストール

pkcs11_kms は「パッチ」13245560 として次の URL の My Oracle Support サイトから配布されています。

http://www.myoraclesupport.com

ログインして「パッチと更新版」タブをクリックします。次に、この特定のパッチ ID を直接検索するか、Oracle Key Manager 製品と Oracle Key Manager 2.5 リリースを検索します。

pkcs11_kms は RPM パッケージとして配布されています。RPM パッケージマネージャーコマンドを使用して、このソフトウェアをインストールします。

例:

# rpm -i pkcs11kms-1.0.0-1.x86_64.rpm

pkcs11_kms のアンインストール

次のコマンドで pkcs11_kms をアンインストールします。

Oracle Solaris 11 の場合の pkcs11_kms のアンインストール

pkcs11_kms をアンインストールするには、次のコマンドを入力します。

# cryptoadm uninstall \
provider='/usr/lib/security/$ISA/pkcs11_kms.so.1'
# pkg uninstall system/library/security/pkcs11_kms

Oracle Solaris 10 Update 10 の場合の pkcs11_kms のアンインストール

pkcs11_kms をアンインストールするには、次のコマンドを入力します。

# pkgrm SUNWpkcs11kms

Oracle Enterprise Linux の場合の pkcs11_kms のアンインストール

Oracle Database にパッケージされている場合、pkcs11_kms プロバイダは Oracle Database 製品のアンインストールに使用される手順を通じてアンインストールされます。別の方法でインストールされた場合、rpm を使用してインストールの逆の手順を使用します。

例:

# rpm -e pkcs11kms-1.0.0-1.x86_64.rpm

TDE 用の OKM の構成

次のセクションでは TDE の構成について説明します。

Oracle Database の TDE の構成

各 Oracle データベースサーバーは、サポートされる pkcs11_kms プラットフォームで 11.2.0.2 以降を実行している必要があります。必須のパッチ 12626642 をインストールする必要があります。このパッチは、次の URL から入手できます。

https://updates.oracle.com/download/12626642.html

インストールが完了したら、TDE アクセスのために共有ライブラリファイル (pkcs_kms.so) を構成する必要があります。ライブラリのパスは OS に固有です。

/usr/lib/security/pkcs11_kms.so.1 (Solaris のみ、32 ビット)
/usr/lib/security/amd64/pkcs11_kms.so.1 (Solaris のみ、64 ビット)
/usr/lib64/pkcs11_kms.so.1 (Linux のみ、64 ビット)

TDE 用の OKM クラスタの構成

次のリストは、TDE 用に OKM クラスタを構成するために必要なタスクを要約しています。

これらのタスクでは、適切な管理ユーザーおよび役割によって構成された動作している OKM クラスタがあることを想定しています。
OKM クラスタ内のすべての KMA では、最低 OKM 2.4.1 および Replication Version 13 が実行されている必要があります。

鍵ポリシーを定義します。

参照:
- "鍵ポリシー"
- "鍵ポリシーに関する考慮事項"。
グループ定義を定義します。

鍵グループに鍵ポリシーを割り当て、グループにわかりやすい名前を付けます。

参照:
- "鍵グループ"
- "鍵グループを使用した鍵アクセス制御"
エージェントを構成します。

参照:
- "OKM の PKCS#11 プロバイダ"。
- "「Agent List」メニュー"
各エージェントをデフォルトの鍵グループと関連付けます。

"「Key Group Assignment to Agents」メニュー"を参照してください。

エージェント ID

エージェント ID は、その構成において意味を持つものにできますが、そのエージェントに関連付けられるデータベースインスタンスの Oracle ユーザーに対応するようにしてください。

パスフレーズ

このパスフレーズは、ウォレット (たとえば、pkcs11_kms トークン) を開く DDL 文を使用して OKM で認証するために、Oracle のホストにも構成されるため、強いパスフレーズを選択します。パスフレーズの要件については、"エージェントの作成"を参照してください。

共通のエージェント ID を共有する複数の Oracle RAC ノードからの場合に加えて、TDE の「ウォレット」を開く必要がある場合に、常にパスワードベースの認証を利用できるようにするために、OneTimePassphrase フラグを「false」に設定するようにしてください。セキュリティーを最大にする場合は、デフォルト値の「true」に設定できますが、単一ノードの Oracle Database 構成でのみ動作し、Oracle RAC では動作しません。OneTimePassphrase が true の場合、エージェントが認証に最初に成功したときにのみ、エージェントの X.509 証明書が返されます。pkcs11_kms プロバイダは、パスフレーズで保護された PKCS#12 ファイルに X.509 証明書の非公開鍵をセキュアに格納します。その後、X.509 証明書および対応する非公開鍵は、エージェントの OKM とのトランザクションに使用されます。pkcs11_kms プロバイダが格納するその他の情報については、kmscfg(1M) を参照してください。

鍵グループ

TDE 用に定義された鍵グループにエージェントを割り当てます。pkcs11_kms プロバイダは、鍵の作成操作 (鍵の再作成操作を含む) に対してデフォルトの鍵グループのみをサポートします。エージェントに関連付けられているデフォルト以外の追加の鍵グループは、それらのグループの鍵からの鍵取得のみが許可されます。この機能は、読み取り専用/復号化専用のデータベースシナリオで活用できます (マスター鍵を生成することはないが、マスター鍵にアクセスする機能のみが必要なセカンダリデータベースをサポートする場合など)。

TDE 用の pkcs11_kms の構成

TDE のマスター鍵を必要とする Oracle Database ノードに pkcs11_kms プロバイダを構成する必要があります。次の手順を実行して、pkcs11_kms プロバイダを構成します。

O/S ユーザーに関する考慮事項:

Oracle Database のユーザーアカウントを使用して、エージェントと pkcs11_kms プロバイダを構成します。これは、O/S ユーザーの特殊な権限を必要としません。ホストで「複数の Oracle ホーム」がサポートされる場合は、各 Oracle Database ソフトウェア所有者のユーザーアカウントに応じて pkcs11_kms トークンを構成する必要があります。詳細は、『Oracle Database インストレーションガイド 11g リリース 2』を参照してください。
kmscfg ユーティリティーは、1 ユーザーごとに 1 つのスロットの構成を一度に作成します。個別のユーザーに対して追加のスロット構成を定義することはできますが、1 プロセスでアクティブにできるのは 1 つのみです。

注意:
KMS PKCS#11 プロバイダのデフォルトのスロット構成ディレクトリの場所は Solaris 11 Express 上の /var/kms/$USER および Solaris 11 SRU5 上の /var/user/$USER/kms です。 Solaris 11 Express システムを Solaris 11 SRU5 にアップグレードする計画がある場合は、まず任意の場所にスロット構成を保存しておいてください。
例:

# cd /var/kms/$USER

# tar cvf ~/save_my_okm_config.tar .

アップグレード後に、スロット構成を新しい場所に復元します。例:

# mkdir -p /var/user/$USER/kms

# cd /var/user/$USER/kms

# tar xvf ~/save_my_okm_config.tar

アップグレード前に pcks11_kms データをバックアップしないと、データが失われ、暗号化データ用の Oracle データベースが使用するマスター鍵が使用できなくなります。

kmscfg ユーティリティーは、次のいずれかのパスにある KMS 構成ディレクトリに構成および実行時データを格納します。
- /var/user/$USER/kms (Solaris 11)
- /var/kms/$USER (Solaris 10u10 および Solaris 11 Express)
- /var/opt/kms/$USER (Oracle Enterprise Linux)
このディレクトリは、$KMSTOKEN_DIR 環境変数によって顧客が選択した場所に指定変更されます。

.kmscfg が実行すると、「プロファイル」名が指定されます。この名前は、上記の構成ディレクトリ内に作成されるエージェント固有の実行時サブディレクトリに使用されます。
スロット構成のデフォルトの場所については、kmscfg のマニュアルページを参照してください。スロット構成は、KMSTOKEN_DIR 環境変数を使用して制御し、代替のスロット構成およびファイルシステムの場所を定義できます。

エージェントプロファイルを Oracle RAC ノード間で共有する必要がある Oracle RAC の場合は、KMSTOKEN_DIR 環境変数を使用し、適切な共有ファイルシステムパスを使用してプロファイルを作成するように kmscfg に指示します。KMSTOKEN_DIR 環境変数が設定される場合、シェルで永続的になるようにシェル構成ファイル (.bashrc など) 内に設定して、データベースが PKCS#11 操作を実行する前に常に設定されているようにしてください。
スロットの構成および実行時の情報のために、ファイルシステムのストレージスペースを割り当てます。Oracle RAC の使用を計画している場合は、Oracle RAC ノードの各ユーザーが読み取り可能および書き込み可能なアクセス権を持つ共有ファイルシステムの場所に、プロファイルを定義します。
各エージェントログが拡張可能になるように領域要件を割り当てます。このログファイルは自動的に作成され、トラブルシューティングのツールとして役に立ちます。KMSAgentLog.log ファイルによって消費される領域は、Solaris の logadm(1M) や Oracle Enterprise Linux の logrotate(8) などのツールを使用して管理できます。ほとんどの構成では、各エージェントのプロファイルディレクトリに 10M バイトを割り当てれば十分です。
kmscfg ユーティリティーを使用して、pkcs11_kms プロバイダを初期化します。このステップでは、あとで pkcs11_kms トークンに関連付ける OKM エージェントにプロファイルを定義します。
```
 # kmscfg 
 Profile Name: oracle
 Agent ID: oracle
 KMA IP Address: kma1
```
この時点で、PKCS11 スロットを定義し、OKM での認証を検証できます。
1. Solaris システムでは、cryptoadm(1M) コマンドを使用して認証を検証します。次の例では、フラグフィールドに CKF_LOGIN_REQUIRED が表示され、スロットがまだ認証済みのトークンで構成されていないことを示しています。
```
solaris> cryptoadm list -v \ 
provider='/usr/lib/security/$ISA/pkcs11_kms.so.1' 
Provider: /usr/lib/security/$ISA/pkcs11_kms.so.1 
Number of slots: 1  
Slot #1 
Description: Oracle Key Management System 
Manufacturer: Oracle Corporation 
PKCS#11 Version: 2.20 
Hardware Version: 0.0 
Firmware Version: 0.0 
Token Present: True 
Slot Flags: CKF_TOKEN_PRESENT 
Token Label: KMS 
Manufacturer ID: Oracle Corporation 
Model: 
Serial Number:
Hardware Version: 0.0
Firmware Version: 0.0
UTC Time:
PIN Min Length: 1
PIN Max Length: 256
Flags: CKF_LOGIN_REQUIRED
```
2. pkcs11_kms トークンが OKM クラスタで認証できることを確認します。
  
  この例では、Linux プラットフォームで使用できないユーティリティー Oracle Solaris pktool(1) を使用しています。
```
solaris> pktool inittoken currlabel=KMS
Enter SO PIN:
Token KMS initialized.
```
  SO (セキュリティー責任者用の PKCS#11 の略称) プロンプトは、エージェントを作成した OKM 管理者によって前に手順で作成されたエージェントの秘密パスフレーズ用です。
3. Solaris システムでは、Solaris Crypto Framework cryptoadm(1M) コマンドまたは pktool(1) ユーティリティーを使用してトークンが初期化されていることを確認します。cryptoadm の出力に示されているトークンのフラグが CKF_TOKEN_INITIALIZED になっていることに注意してください。
```
solaris> cryptoadm list -v \
provider='/usr/lib/security/$ISA/pkcs11_kms.so.1'
 Provider: /usr/lib/security/$ISA/pkcs11_kms.so.1
 Number of slots: 1
 Slot #1
 Description: Oracle Key Management System
 Manufacturer: Oracle Corporation
 PKCS#11 Version: 2.20
 Hardware Version: 0.0
 Firmware Version: 0.0
 Token Present: True
 Slot Flags: CKF_TOKEN_PRESENT
 Token Label: KMS
 Manufacturer ID: Oracle Corporation
 Model:
 Serial Number:
 Hardware Version: 0.0
 Firmware Version: 0.0
 UTC Time:
 PIN Min Length: 1
 PIN Max Length: 256
 Flags: CKF_LOGIN_REQUIRED CKF_TOKEN_INITIALIZED
```
4. Solaris システムでは、pktool(1) ユーティリティーを使用して、PKCS#11 表示トークンのステータスを確認します。
```
glengoyne> pktool tokens
Flags: L=Login required  I=Initialized  X=User PIN expired  S=SO PIN expired
Slot ID  Slot Name     Token Name                  Flags
-------  ---------     ----------                  -----
1        Sun Crypto    Softtoken      Sun Software PKCS#11 softtoken
2        Oracle Key Management System              KMS  L
glengoyne>
```
  これは、トークンへのログインがまだ必要であることを示します。pktool 出力のフラグの意味は次のように表示できます。
```
glengoyne> pktool tokens -h
Usage:
   pktool -?    (help and usage)
   pktool -f option_file
   pktool subcommand [options...]
```
  サブコマンドが次のような場合:
```
   tokens
   * flags shown as: L=Login required  I=Initialized  
     E=User PIN expired  S=SO PIN expired
glengoyne>
```
5. Solaris システムでは、pktool(1) ユーティリティーを使用して、トークンにログインし、kmscfg(1) 手順で指定した OKM クラスタの KMA とエージェント用に OKM 管理者によって作成されたパスフレーズで認証します。このパスフレーズは SO PIN プロンプトによって提供されます。
```
glengoyne> pktool inittoken currlabel=KMS
Enter SO PIN:
Token KMS initialized.
```
6. Solaris システムでは、pktool(1) ユーティリティーを使用して、トークンのステータスと、それが現在初期化されていないことを確認します。
```
glengoyne> pktool tokens
Flags: L=Login required  I=Initialized  X=User PIN expired  S=SO PIN expired
Slot ID  Slot Name   Token Name                    Flags
-------  ---------   ----------                    -----
1        Sun Crypto  Softtoken         Sun Software PKCS#11 softtoken
2        Oracle Key Management System              KMS   LI
```
7. Solaris システムでは、cryptoadm(1M) コマンドを使用して、pkcs11_kms トークンのサポートするメカニズムを表示する要求によって、pkcs11_kms が初期化されていることを確認します。
```
glengoyne> cryptoadm list -m -p  provider=/usr/lib/security/'$ISA'/pkcs11_kms.so.1
Mechanisms:
CKM_AES_KEY_GEN
CKM_AES_CBC
CKM_AES_CBC_PAD
glengoyne>
```
  Solaris システムでは、pktool(1) ユーティリティーを使用して、次のように pkcs11_kms プロバイダによって鍵を作成して、一覧表示します。
```
 # pktool genkey token=KMS keytype=aes keylen=256
   label=MyKey-test1
 # pktool list token=KMS objtype=key
 # pktool list token=KMS objtype=key label=MyKey-test1
```
  OKM Manager GUI または OKM CLI によって、OKM システム内の鍵を表示できます。
注:
Solaris の場合、kmscfg(1) はデフォルトで一度にユーザーあたり 1 つのスロット構成だけを作成します。
追加のスロット構成を定義することはできますが、1 プロセスでアクティブにできるのは 1 つのみです。これは、KMSTOKEN_DIR 変数を使用して、代替のスロット構成およびファイルシステムの場所を定義することによって実行できます。

Solaris 11 のデフォルトは /var/user/$USERNAME/kms ですが、独自の命名スキームを作成できます。ベストプラクティスは

/var/user/$USERNAME/$AGENTID-$CLUSTER/

この命名規則により、Solaris では多様な使用シナリオに基づいて、スロットとエージェントとクラスタの複数の組み合わせを使用できます。

一部の PKCS#11 構成では、各ノードで pkcs11_kms プロバイダのメタデータを共有するように、Oracle RAC を使用した TDE (前述の TDE 構成のセクションを参照) など、代替の場所が推奨されます。
TDE が自動オープンウォレットを使用するように構成する場合は、この付録の最初に参照した Oracle Advanced Security Transparent Data Encryption のベストプラクティスに関するドキュメントに説明されている手順に従ってください。

継続的な運用

次のセクションでは、繰り返し行う OKM および TDE の運用タスクについて説明します。

Oracle Wallet からのマスター鍵の移行

以前のウォレットは保持する必要があり、OKM によって新しいマスター鍵が生成されて、鍵管理システムによって安全に保護されます。

この付録の最初に参照した Oracle Advanced Security Transparent Data Encryption のベストプラクティスに関するドキュメントを参照してください。

TDE は、各マスター鍵を識別する一意の鍵ラベルを生成します。実際の鍵の値は、pkcs11_kms トークンから TDE に渡されるまで、標準テキストとして公開されません。「作成された」鍵は、アクティブ状態の (安全に複数の KMA にレプリケートされた) AES 256 ビット鍵のプールから取得されます。その後、この鍵は、PKCS#11 トークンによって使用される特定のエージェントに応じて、OKM 鍵ポリシーと関連付けられます。OKM は、ポリシーによって規定された鍵のライフサイクルに応じて鍵を管理します。

鍵の再作成操作

Oracle Database 管理者は、鍵のライフサイクルによって要求される前に、鍵の再作成操作を実行する必要があります。そうしない場合、データベースは起動しません。

この操作を実行するために使用される DDL については、Oracle Database および TDE の各種ドキュメントを参照してください。鍵の再作成は、Oracle Enterprise Manager を使用して実行することもできます。

OKM ポリシーベースの鍵の期限切れによる鍵の再作成

鍵が運用後状態に達した場合、TDE によって各鍵取得が行われると、運用後鍵を取得したことを示す警告が OKM 監査ログに出力されます。これらの監査メッセージが存在する場合は、そのデータベースインスタンスのマスター暗号化鍵を再作成する時期であることを示しています。OKM の監査メッセージは、Oracle Database インスタンスおよび運用後状態に達したマスター暗号化鍵の識別を容易にするために、特定のエージェントと取得されている鍵を識別します。この処理の自動化をサポートするために、SNMP v3 の inform または SNMP v2 の trap を使用した通知を OKM に構成できます。

pkcs11_kms プロバイダは、鍵が運用後状態に達したことを PKCS#11 コンシューマに通知しようとします。これは、マスター鍵に対して PKCS#11 の「CKA_ENCRYPT」属性を false に設定することにより行われます。

現在、Oracle Database 11gR2 は、暗号化期間が期限切れになったあとも、鍵を使用したデータの暗号化を継続します。次のエラーが警告ログに出力されたときにこの動作を確認できます。

HSM heartbeat died. Likely the connection has been lost. PKCS11 function C_EncryptInit returned
PKCS11 error code: 104
HSM connection lost, closing wallet

このエラーが発生した場合、データベース管理者は次のアクションを実行する必要があります。

pkcs11_kms トークンに関連付けられているユーザーに、次の環境変数を設定します (通常は、Oracle ユーザーのプロファイル)。
```
# export PKCS11_KMS_ALLOW_ENCRYPT_WITH_DEACTIVATED_KEYS=1
```
データベースを再起動します。
データベースインスタンス用のマスター鍵を再作成します。

上記のエラーを回避するために、Oracle Database エージェントに関連付けられている OKM 鍵ポリシーに非常に長い暗号化期間を使用することをお勧めします。あるいは、pkcs11_kms プロバイダの動作を変更して、鍵の状態の確認を無効にすることもできます。これを実行するには、上記の手順 1 に記載されている環境変数を設定します。この変数を設定すると、HSM を開くことができます。

これにもかかわらず、TDE はその鍵の使用を継続し、自動的な鍵の再作成操作を行いません。運用後鍵の取得に関する監査警告を確認した OKM 管理者は、データベースインスタンスのマスター鍵を再作成する時期であることをデータベース管理者に通知する必要があります。

別の HSM ソリューションからの変換

別のベンダーの HSM ソリューションから OKM に変換するために必要な具体的な手順については、Oracle テクニカルサポートにお問い合わせください。

鍵の破棄

運用後フェーズに達した鍵を破棄する前に、OKM 管理者はその鍵が使用されなくなったことを検証する必要があります。

OKM 管理者は、運用後フェーズに入った鍵を定期的に破棄する責任があります。pkcs11_kms プロバイダを使用した鍵の削除は、OKM でサポートされておらず、オペレータの役割を割り当てられている OKM ユーザーに予約されている制限された操作です。鍵が破棄されたあとに、それを取得しようとすると失敗します (PKCS#11 の C_FindObjects 要求も含みます)。

Oracle RMAN または Oracle Data Pump、あるいはその両方をサポートするための鍵転送

Oracle RMAN または Oracle Data Pump、あるいはその両方を使用する場合、マスター鍵を別の OKM クラスタに提供する機能が必要となることがあります (たとえば、障害回復サイトにおいて、またはパートナーに対して)。OKM の鍵転送操作は、セキュアな鍵エクスポートサービスおよび鍵インポートサービスを使用して、これを容易にサポートします。詳細については、"鍵転送"を参照してください。

次の手順を実行します。

転送元および転送先の OKM クラスタ間で鍵転送パートナーを確立します。
Oracle RMAN バックアップ、または Oracle Data Pump を使用してエクスポートされる暗号化データをサポートするためにエクスポートする TDE マスター鍵を識別します。
転送元 OKM クラスタから鍵をエクスポートします。これにより、セキュアな鍵エクスポートファイルが作成されます。
エクスポートされた鍵ファイルを転送パートナーに転送します。
転送先の転送パートナーは、鍵を自身の OKM クラスタにインポートします。

Oracle RMAN の復元または Oracle Data Pump のインポートを実行して、鍵を必要とするデータベースインスタンスを再作成します。これには、インポートする場所で TDE を OKM で使用するために必要な構成ステップが必要です。その後、復元またはインポートの操作は OKM にアクセスして、データベースインスタンスによって使用される列またはテーブル領域の鍵を復号化するために必要な汎用マスター鍵を取得します。

管理

システムがアクティブになったら、次のガイドラインを使用して、このソリューションを効果的に管理およびモニターします。

確認、監査、およびモニタリング

推奨事項は次のとおりです。

TDE エージェントの OKM 動作履歴を確認およびモニターして、問題の検出に役立てます。
監査者は、OKM 監査イベントを使用して、TDE が OKM クラスタからマスター鍵にアクセスしていることを確認できます。
OKM 用に SNMP マネージャーを構成します。
OKM の CLI を使用して、企業に固有のレポートを生成することを検討します。

OKM 内の TDE マスター鍵の検出

GUI 管理ツールまたは CLI を使用して、OKM 内の TDE マスター鍵を検出できます。TDE はマスター鍵のラベルを生成し、OKM はデータユニットの External Tag 属性を使用してこの値を格納します。TDE のマスター鍵生成 (鍵の再作成操作を含む) では、OKM クラスタ内に新しいデータユニットオブジェクトおよび鍵オブジェクトが常に作成されます。

TDE マスター鍵を検出するには、次を行います。

OKM データユニットに対してクエリーを実行し、ExternalTag フィルタ (「ExternalTag」が「ORACLE.TDE」で始まる) を使用してリストをフィルタします:。すべての TDE 鍵ラベルはこの文字列で始まるため、これにより、TDE によって作成された OKM データユニットのリストが生成されます。各 OKM データユニットには、単一の TDE マスター鍵が関連付けられます。これらの鍵は、OKM GUI を使用して表示し、ライフサイクルの状態およびその他のプロパティー (鍵グループ、エクスポート/インポートのステータス、破棄された鍵が含まれている OKM バックアップなど) を確認できます。これらの鍵は OKM CLI を使用して表示することもできます。例:
```
>okm listdu --kma=acme1 --user=joe \
--filter="ExternalTag=ORACLE.TDE"
```
複数の Oracle Database インスタンスが 1 つの OKM クラスタを共有している場合、OKM 管理者は、データベースインスタンスに対応するエージェントの監査イベントに対してクエリーを使用することで、特定のデータベースに対応する鍵を識別できます。これらの監査イベントは Oracle GUI を使用して表示できます。フィルタ「Operation が CreateDataUnit に等しい」を使用して、エージェントの監査履歴をフィルタします。これにより、TDE マスター鍵の作成に対応する監査イベントのリストが生成されます。この監査イベントの詳細には、マスター鍵の特定のデータユニットを識別するために必要な情報が示されます。これらの監査イベントは OKM CLI を使用して表示することもできます。例:
```
>okm listauditevents --kma=acme1 --user=joe \
--filter="Operation=CreateDataUnit"
```

トラブルシューティング

このセクションでは、OKM を TDE とともに使用するときに発生することがあるエラー状態について説明します。

マスター鍵を取得できない

マスター鍵を取得できない場合、Oracle Database は次のいずれかのエラーを報告します。

ORA-28362
ORA-06512

これらのエラーが発生した場合は、次の診断手順を行なって問題を特定します。

$ORACLE_BASE/diag/rdbms/$SID/$SID/trace/alert_$SID.log ファイルを確認します。このファイルには、暗号化ウォレットにアクセスするために使用された「alter」DDL 文に関連する成功/失敗のメッセージが記録されます。
pkcs11_kms 構成ディレクトリ内の KMSAgentLog.log ファイルを確認します ($KMSTOKEN_DIR/KMSAgentLog.log)。
OKM の全般的なステータスを確認します。次を確認してください。
- KMA はアクティブか?
- KMA はロックされているか?
- 鍵プールは枯渇しているか?
- KMA の ILOM/ELOM の障害
- KMA コンソールのメッセージ
pkcs11_kms トークンのステータスが以前のステータスと同じであるかどうかを確認します。
エージェントの OKM 監査イベントを調査することでエージェントのステータスを確認し、そのエージェントが登録され、有効になっていることを確認します。
Oracle Database のホストから OKM ノードへのネットワーク接続を確認します。
Oracle 技術サポートに連絡してください。1 つまたは複数の KMA システムダンプの提供を要請されることがあります。

pkcs11_kms 構成ディレクトリの消失

次の手順を使用して、消失または破壊された pkcs11_kms トークンプロファイルを復元します。

"TDE 用の OKM の構成"で説明されている構成手順を行います。
Solaris のみ - OKM でデータユニットのフィルタ (「ExternalTag」が「ORACLE.TDE」で始まる) を使用して、トークンのメタデータを取り込み直します。
Solaris のみ - このリストの結果をファイル (たとえば、「du.lst」) に保存してから、次のシェルスクリプトを実行します。
```
for label in `awk '{print $2}' < du.lst `
do
pktool list token=KMS objtype=key label="${label}"
done
```

No Slots Available エラー

PKCS#11 操作を発行すると、クライアントで「No Slots Available」エラーを受け取ります。

kmscfg ユーティリティーが正常に実行していることを確認します。
pkcs11_kms プロバイダが適切にインストールおよび構成されていることを確認します。

CKA_GENERAL_ERROR エラー

鍵を取得しようとしたときに、クライアントで CKA_GENERAL_ERROR エラーを受け取ります。

OKM クラスタ内でエージェントにデフォルトの鍵グループがあることを確認します。
詳細は、$KMSTOKEN_DIR/KMSAgentLog.log ファイルを確認します。

Could Not Open PKCS#12 File エラー

$KMSTOKEN_DIR/KMSAgentLog.log ファイルに「Could not open PKCS#12 file」エラーが表示されます。

OKM クラスタ内の監査イベントを選択して、エージェントのパスフレーズが最近変更されたかどうかを判別します。
$KMSTOKEN_DIR の下の <profile-name> ディレクトリを削除します。