| Oracle® Fusion Middleware Oracle Unified Directoryの管理 11g リリース2 (11.1.2.3) E61945-07 |
|
 前 |
 次 |
この章では、Oracle Unified Directoryにおけるデータ暗号化の概要(暗号化の基本概念、サポートされている機能および基本構成タスクなど)について説明します。
この章には次のセクションが含まれます:
暗号化は、無許可の機密データへのアクセスを防止するために、平文のデータを暗号文という判読できない形式に変換するメカニズムです。復号化は、暗号文を変換して平文に戻すプロセスです。
Oracle Unified Directoryは、ストレージ、同期およびプロキシ機能を統合して、ビジネス・アプリケーションが動作するための重要な識別情報の管理を支援する、次世代の統合ディレクトリ・ソリューションです。このデータには、機密情報が含まれている可能性があり、参照できるのは意図された受信者のみにする必要があります。Oracle Unified Directoryでは、データへのアクセスをセキュリティで保護する、アクセス制御ルール、パスワード認証、SSLなどのメカニズムが提供されています。データには、クレジット・カード番号やSSN番号などの非常に機密性の高い情報が含まれている可能性もあります。このタイプのデータの場合、情報がデータベース内に判読可能な平文で保存されているため、無許可のアクセスを防止するために標準的な対策のみでは不十分です。侵入者がサーバーのストレージ・ファイルにアクセスし、この情報を私的な利益のために使用する場合、その損害は大きなセキュリティ・リスクとなります。
Oracle Unified Directoryでは、特定のセンシティブ属性を暗号文として保存できる属性の暗号化機能を提供しています。これにより、基礎となるデータベース・ファイル、バックアップ・ファイルおよびエクスポートされたLDIFファイルに保存されている間はデータを読み取れなくなります。属性を暗号化すると、重要なデータをディスクに書き込む前に暗号化でき、ディスクから読み取るときに復号化できます。
|
注意: 属性の暗号化機能では、LDAPプロトコルで取得されるデータは暗号化されません。ディスク上に保存されたデータのみが暗号化されます。LDAPクライアントが暗号化された属性を持つ、ディスク上のエントリを読み取る(検索する)場合、そのクライアントは復号化されたエントリを受け取るため、暗号化された元の属性の値を復号化しなくてもすぐに読み取ることができます。 |
デフォルトでは、属性は暗号化されません。属性の暗号化は、接尾辞レベルで構成されます。つまり、接尾辞内でその属性が現れるエントリごとに属性が暗号化されます。したがって、属性が暗号化された後、その属性のすべてのインスタンスがデータベース・ファイルに保存される前に暗号化されます。これは、ディスク上にあるその特定の属性のすべてのデータが暗号化されることを意味します。
暗号化は常に可逆です。検索リクエストの結果として返されるときには、暗号化された属性が復号化されます。ディレクトリ全体で属性を暗号化する場合は、それぞれの接尾辞でその属性の暗号化を有効にするか、接頭辞のリストを空のままにしておく必要があります。
|
注意: 属性の暗号化は、接尾辞に関連付けられたすべてのデータおよび索引ファイルに影響を与えます。これらの属性は、属性の暗号化がアクティブ化された後で変更(暗号化)されます。既存の属性は、そのまま変更されません。すべてのデータに暗号化を適用するには、まず構成を変更してから、内容をエクスポートし、その内容をインポートしなおす必要があります。 |
属性の暗号化を使用すると、データを暗号化された形式で別のデータベースにエクスポートすることもできます。属性の暗号化の目的は、機密データが格納またはエクスポートされる場合にのみ、それらのデータを保護することです。
Oracle Unified Directoryでは次の暗号化が可能です。
必須属性タイプ・リストに定義された特定の属性タイプ
|
注意: 一部の操作属性や内部属性(entryuuidやcreateTimestamp、仮想属性、パスワード属性など)は暗号化できません。暗号化でサポートされていない属性の詳細は、第14.6項「属性の暗号化の使用に関する考慮事項」を参照してください。 |
DBローカル・バックエンド(ユーザー・バックエンド)のみ
すべての使用可能なDBローカル・バックエンドのすべての接尾辞の属性、またリストに指定されている場合は次のような一部の特定の接尾辞。例:
接尾辞が指定される場合、サブ接尾辞ではなくDBローカル・バックエンドのルート接尾辞である必要があります。たとえば、DBローカル・バックエンドにルート接頭辞のdc=example,dc=comがある場合、ou=people,dc=example,dc=comにある一部の属性のみを暗号化することはできません。
Oracle Unified Directoryでは、暗号化アルゴリズムを使用して、ディスクに格納されているエントリの属性への無許可のアクセスを防止できます。
暗号化アルゴリズムは、データの暗号化および復号化に使用される数学的な一連の規則または関数です。これらのアルゴリズムは、データを暗号化または復号化するキーと連携して動作します。
属性の暗号化機能では、標準的な暗号化アルゴリズムが幅広くサポートされています。
サーバーでは、いくつかの暗号化スキームを使用して属性を暗号化できます。サポートされている暗号化スキームは次のとおりです。
AES128
AES256
|
注意: AES256アルゴリズムの場合、Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Filesをインストールする必要があります。Javaのバージョンに応じて正しいJCE Unlimited Strength Jurisdiction Policy Filesをダウンロードしてインストールしてください。Java 7の場合、次のOTNの「Java SE Downloads」ページからJava Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 7をダウンロードします。 |
Blowfish (128ビット・キー)
トリプルDES (168ビット・キー)
RC4 (128ビット・キー)
攻撃者は、索引ファイルを通じて直接機密データにアクセスすることもできます。したがって、暗号化する属性に対応する索引キーを暗号化することで、属性を完全に保護することが不可欠です。
データベースの暗号化は索引付けに部分的に対応しています。多くの場合、属性値から抽出される索引ファイルの内容も、攻撃者が索引の分析によって暗号化データの一部または全部を復元しないように暗号化されます。
サーバーは、暗号化された属性の索引を参照する前に、すべての索引キーを事前に暗号化します。この処理は、暗号化された索引を利用する検索のサーバー・パフォーマンスに多少影響します。ただし、パフォーマンスの影響は限られているため、索引の使用を妨げることはありません。
Oracle Unified Directoryでは、次の索引タイプを関連する暗号化属性に使用できます。
等価
部分文字列
近似
プレゼンス
|
注意: 暗号化の技法では、索引の順序が維持されないことに注意する必要があります。したがって、属性の暗号化の際に索引の順序指定はサポートされません。 |
暗号化は、DBローカル・バックエンドの索引のみでサポートされています。索引のキーは暗号化された属性用に暗号化されます。
レプリケーション・トポロジの暗号化では、レプリケーション・サーバーのデータベースに格納された暗号化データを参照します。
この項では、レプリケーション・トポロジで暗号化がどのようにサポートされているかについて説明します。内容は次のとおりです。
changelog)での暗号化の理解Oracle Unified Directoryでは、レプリケーション・サーバーのデータベース(changelog)、およびcn=changelog (external changelogまたはretro-changelog)で暗号化をサポートしています。
Oracle Unified Directoryはサーバー・データベースに対する方法と同じ方法でレプリケーション・サーバーのデータベースのデータを暗号化します。追加の構成は必要ありません。暗号化の有効化と無効化、暗号化の属性の定義および暗号化の接尾辞の定義は、どちらのデータベースに対しても同じです。
レプリケートされたトポロジの一部であるサーバーで操作を実行する場合、およびその変更が暗号化された属性に関連付けられている場合、Oracle Unified Directoryでは、サーバーでの暗号化に使用されるアルゴリズムと同じアルゴリズムを使用してレプリケーション・サーバーのデータベース(cn=changelogから読取り可能なchangelog)のデータを暗号化します。
Oracle Unified Directoryがレトロ変更ログ(cn=changelog)にアクセスする場合(cn=changelogはchangelogにアクセスします)、レトロ変更ログは常にクリア値を返します。暗号化は保存時、つまり、安定したストレージ(ハード・ディスク)でのみ行われます。
暗号化に使用されるキーは、作成および格納され、cn=admin dataから取得されます。この接尾辞は、トポロジ内の他のすべてのサーバーにレプリケートされます。したがって、トポロジ内のすべてのサーバーで、暗号化された属性を復号化し、LDAPクライアントに送信できます。つまり、暗号化または復号化アルゴリズムに使用されるキーは、cn=admin dataがレプリケートされるため、トポロジ全体でレプリケートされます。
バージョン11.1.2.2.0のレプリケートされたサーバーのトポロジをバージョン11.1.2.3.0に更新する場合、すべてのサーバーの更新が完了するまで、すべてのレプリケーション・サーバーのデータベースで暗号化は行われません。また、変更ログから暗号化されていない値が確実になくなるようにパージ遅延の期間が過ぎるまで待機する必要があります。
Oracle Directory Server Enterprise Editionでは、一部の属性をバックエンドで暗号化できますが、変更ログではできません。
Oracle Unified Directoryのバージョン11.1.2.3.0以降では、Oracle Directory Server Enterprise Editionからゲートウェイを使用している場合、Oracle Unified Directoryトポロジの他のサーバーのようにそのゲートウェイを構成できます。
レプリケーション・ゲートウェイを介してOracle Directory Server Enterprise Editionサーバーから送信される変更が暗号化された属性に関連付けられている場合(通常のOracle Unified Directoryサーバーの場合と同様に構成によって定義される)、Oracle Unified Directoryはそのデータを暗号化し、レプリケーション・サーバーのデータベースに格納できます。
属性の暗号化機能を実装する場合、次の点を考慮する必要があります。
属性を暗号化することでデータのセキュリティが向上しますが、システムのパフォーマンスにも影響を及ぼします。暗号化は、センシティブ属性にのみ使用することを検討してください。
属性の暗号化構成を変更する場合、データをエクスポートして構成を変更したうえで、新たに構成したデータをインポートする必要があります。これにより、情報が失われることなく、すべての構成の変更が考慮されます。これを行わない場合、バックエンドに前からある、データ暗号化の構成変更後変更のなかったデータが、初期のアルゴリズムによる構成に従って、クリアまたは暗号化形式で維持されます。
アルゴリズムの変更がサポートされています。索引付けされた属性で暗号化を変更するには、暗号化された属性に関連付けられた索引を再構築する必要があります。これも、パフォーマンスに影響します。索引の再構築の詳細は、第A.3.13項「rebuild-index」を参照してください。
索引が付けられた暗号化済属性の場合、索引とデータ暗号化の構成間で整合性を維持する必要があります。暗号化された属性の構成を変更または更新する場合、暗号化された属性に関連付けられた索引を再構築する必要があります。これを行わない場合、構成が変更されたために索引を再構築することを求めるエラー・メッセージがエラー・ログ・ファイルに記録されます。索引の再構築の詳細は、第A.3.13項「rebuild-index」を参照してください。
暗号化するRDNの属性を構成する場合、DNに表示される値は暗号化されません。エントリに格納される値のみが暗号化されます。
たとえば、次のエントリについて考えてみます。
dn: uid=foo,dc=example,dc=com objectclass: inetorgperson objectclass: organizationalperson objectclass: person objectclass: top uid=foo cn=bar sn=joe
ここで、uidは次の属性です。
エントリのDNの一部で、そのエントリのRDN。
エントリの属性の一部。RDNは常にエントリ内に属性として存在するため、この状況が常に存在することを覚えておく必要があります。
ただし、uidは複数値の属性であるため、次のようにエントリ内のuidに値を追加できます。
dn: uid=foo,dc=example,dc=com objectclass: inetorgperson objectclass: organizationalperson objectclass: person objectclass: top uid=foo uid=secondValue cn=bar sn=joe
これで、uidを暗号化すると、追加した新しい値は暗号化され、初期値のfooは暗号化されません。RDN内の値は暗号化されません。
次の属性は、サーバーで内部的に使用されるため暗号化を構成できません。
操作属性
オブジェクト・クラス
entryUUID
creatorsName
createTimestamp
modifiersName
modifyTimestamp
仮想属性
仮想属性は暗号化用に構成できません。
パスワード属性
パスワードはすでにハッシュまたは暗号化されているため、属性の暗号化機能を使用して、パスワード・ポリシーに定義されているパスワード属性の既存の動作を変更したり、暗号化を構成することはできません。たとえば、デフォルト・パスワード・ポリシーに定義されているuserPassword属性はサポートされません。
パスワードの暗号化とハッシュは、別々に処理されます。パスワード・ポリシーとパスワード記憶スキームの詳細は、第30章「パスワード・ポリシーの管理」を参照してください。
この項では、属性の暗号化を構成する方法について説明します。内容は次のとおりです。
表14-1は、属性の暗号化を有効にする構成パラメータを説明しています。
表14-1 属性の暗号化の構成パラメータ
| 名前 | 説明 | 単一/ 複数値 |
形式 | プレゼンスのルール |
|---|---|---|---|---|
|
|
暗号化を有効化または無効化できます。 |
|
ブール値、trueまたはfalseを表す文字列 |
|
|
|
ここに定義されたすべての属性が暗号化されます。すべての接尾辞のすべてエントリの属性が暗号化されます。 |
|
1つの属性名またはOIDを表す文字列 |
|
|
|
接尾辞に暗号化を適用する方法を制御します。
警告: この接尾辞はバックエンドに定義されているルートの接尾辞にする必要があり、子の接尾辞は使用できません。たとえば、バックエンドにサポートされている接尾辞として |
|
1つの接尾辞を表す文字列 |
|
|
|
暗号化に使用するアルゴリズムを定義します。 |
|
暗号化アルゴリズムを表す文字列。 有効な値は次のとおりです。
|
|
dsconfigコマンドを使用した属性の暗号化の構成この項では、dsconfigコマンドを使用した属性値暗号化の構成方法を説明します。
ユーザーDBローカル・バックエンド・ルート接尾辞のdc=customers,dc=comおよびdc=partners,dc=comのエントリで、AES-128アルゴリズムを使用し、postalAddressおよびmail属性のすべてに暗号化を実行するシナリオについて考えます。
dsconfigコマンドを使用して属性の暗号化を構成する手順は次のとおりです。
次のコマンドを順番に実行します。
dc=customers,dc=com接尾辞でのpostalAddress属性に対するAES-128アルゴリズムを使用した属性の暗号化を構成するには、次のコマンドを実行します:
dsconfig -n -X -h localhost -p 1444 -D "cn=Directory Manager" \ -j /local/password set-data-encryption-prop --set enabled:true \ --set attribute-encryption-include:postalAddress \ --set encryption-algorithm:aes-128 \ --set encrypted-suffix:dc=customers,dc=com
mail属性に属性の暗号化を追加し、dc=partners,dc=com接尾辞に暗号化を追加するには、次のコマンドを実行します:
dsconfig -n -X -h localhost -p 1444 -D "cn=Directory Manager" \ -j /local/password \ set-data-encryption-prop --add attribute-encryption-include:mail \ --add encrypted-suffix:dc=partners,dc=com \
次のいずれかを実行します。
バックエンドに存在する既存のデータを暗号化用に構成する場合は、LDIFスクリプトを使用してデータをエクスポートします。
export-ldif -n userRoot -l /data/export.ldif
LDIFへのエクスポートの詳細は、第A.3.5項「export-ldif」を参照してください。
新規の暗号化構成を考慮し、今後の変更のみが必要な場合は、ステップ4に進んでください。
次のステップを実行して、データを再度インポートし、停止します。
サーバーを停止します。
stop-ds
データをインポートします。
import-ldif -n userRoot -l /data/export.ldif
コマンド行からのインポートの詳細は、第A.3.6項「import-ldif」を参照してください。
|
注意: インポートされたLDIFファイルでデータが暗号化されているかどうかに関係なく、import-ldifコマンドは、現在のサーバー構成の指定に従ってバックエンドにデータを保存します。このため、必要に応じてインポート・プロセスでデータを暗号化または復号化できます。たとえば、暗号化が構成されていないサーバーで、暗号化されたデータをインポートする場合に、暗号化されていないデータを保存できます。さらに、暗号化が構成されたサーバーにクリアLDIFファイルをインポートする場合に、暗号化されたデータを保存できます。
現在の構成のアルゴリズムが常に使用されます。AES128暗号化データ・セットをRC4暗号化が構成されているサーバーにインポートする場合、データはRC4の構成で再度暗号化され保存されます。 |
サーバーを起動します。
start-ds
データをインポートすると、索引も作成されます。したがって、ステップ4を行う必要はありません。
索引を再度作成します。
暗号化を構成する接尾辞に、対象となる属性の索引がある場合、それらの索引を再作成します。次のコマンドを実行します:
たとえば、postalAddress属性に関連付けられた索引がいくつかある場合、次のコマンドを使用してインデックスを再構築します。
rebuild-index -b dc=customers,dc=com -i postalAddress
同様に、mail属性に関連付けられた索引がいくつかある場合、次のコマンドを使用してインデックスを再構築します。
rebuild-index -b dc=customers,dc=com -i mail
索引の再構築の詳細は、第A.3.13項「rebuild-index」を参照してください。
dsconfig対話モードを使用した属性の暗号化の構成dsconfigコマンド行の対話モードを使用して、属性の暗号化を構成できます。
メインの「セキュリティ」メニューにある「データ暗号化」サブセクションの概要説明によって、表14-1に説明されているすべての構成属性の変更が可能になります。
例14-1は、対話モードでdsconfigコマンドを使用したサンプル出力を示しています。
例14-1 対話モードでdsconfigを使用した属性の暗号化構成
Oracle Unified Directory Configuration Console Main Menu
What do you want to configure?
1) Security 6) Schema
2) Local Storage 7) Distribution
3) Miscellaneous Workflow Elements 8) Replication
4) Virtualization 9) Remote Storage
5) General Configuration 10) Load Balancing
q) quit
Enter choice: 1
Security Management Menu
What would you like to do?
1) Access Control Group 5) Key Manager Provider
2) Access Control Handler 6) Root DN
3) Crypto Manager 7) SASL Mechanism Handler
4) Data Encryption 8) Trust Manager Provider
b) back
q) quit
Enter choice [b]: 4
Configure the Properties of Data Encryption
Property Value(s)
------------------------------------------------------------------
1) attribute-encryption-include description, givenname, mobile
2) enabled true
3) encrypted-suffix "dc=example,dc=com"
4) encryption-algorithm aes-128
?) help
f) finish - apply any changes to the Data Encryption
c) cancel
q) quit
Enter choice [f]: ?
Component name: Data Encryption
Data Encryption allows to configure attribute encryption.
Option Types:
r -- Property value(s) are readable
w -- Property value(s) are writable
m -- The property is mandatory
s -- The property is single-valued
a -- Administrative action is required for changes to take effect
Property Options Syntax
--------------------------------------------------
attribute-encryption-include rw--- OID
enabled rw-s- BOOLEAN
encrypted-suffix rw--- DN
encryption-algorithm rw-s- ALGORITHM
---------------------------------------------------
ODSMの「構成」タブで「一般構成」要素を選択して、データの暗号化を有効化、無効化および構成できます。詳細は、第17.3.8項「一般的なサーバー構成の変更」を参照してください。
この項のでは、属性の暗号化を構成するシナリオについて説明します。内容は、次のとおりです。
この項では、ユーザーDBローカル・バックエンドのルート接尾辞dc=customers,dc=comおよびdc=partners,dc=comのエントリで、3DES-168アルゴリズムを使用し、postalAddressおよびmail属性のすべてに暗号化を実行するシナリオについて説明します。
次のコマンドを使用してpostalAddresに対する属性の暗号化を構成する手順は次のとおりです。
dsconfig -n -X -h localhost -p 1444 -D "cn=Directory Manager" \ -j /local/password \ set-data-encryption-prop --set enabled:true \ --set encryptedsuffix:dc=customers,dc=com \ --set attribute-encryption-include:postalAddress \ --set encryption-algorithm:triple-des-168 \
次のコマンドを使用してmailに対する属性の暗号化を構成する手順は次のとおりです。
dsconfig -n -X -h localhost -p 1444 -D "cn=Directory Manager" \ -j /local/password \ set-data-encryption-prop --add attribute-encryption-include:mail \ --add encrypted-suffix:dc=partners,dc=com \
dsconfigコマンドのset-data-encryption-propオプションを使用して、属性を構成できます。暗号化パラメータの詳細は、第2.4項「dsconfig」を参照してください。
この例では、前述の2つのdsconfigコマンドを順番に使用して暗号化を構成します。詳細は、第14.7.2項「dsconfigコマンドを使用した属性の暗号化の構成」を参照してください。
次のdsconfigコマンドを使用して暗号化を無効にします。
dsconfig -n -X -h localhost -p 1444 -D "cn=Directory Manager" \ -j /local/password \ set-data-encryption-prop --set enabled:false \
次のコマンドを使用して、mobile属性をAES-128アルゴリズムによって暗号化します。
dsconfig -n -X -h localhost -p 1444 -D "cn=Directory Manager" \ -j /local/password set-data-encryption-prop --set enabled:true \ --set attribute-encryption-include:mobile \ --set encryption-algorithm:aes-128 \
属性は、次のようにdsconfigコマンドとset-data-encryption-propサブコマンドを使用して変更できます。
dsconfig -n -X -h localhost -p 1444 -D "cn=Directory Manager" / -j /local/password set-data-encryption-prop --set "enabled:true"
|
注意: set-data-encryption-propオプションの内容表示を行うには、dsconfig set-data-encryption-prop --helpを実行します。詳細は、第A.2.4項「dsconfig」を参照してください。 |
属性は、次のようにdsconfigコマンドとget-data-encryption-propサブコマンドを使用して読み取ることができます。
dsconfig -n -X -h localhost -p 1444 -D "cn=Directory Manager" / -j /local/password get-data-encryption-prop Property : Value(s) -----------------------------:------------------------------- attribute-encryption-include : description, givenname, mobile enabled : true encrypted-suffix : "dc=example,dc=com" encryption-algorithm : aes-128
属性の暗号化を指定してOUDトポロジを初期化できます。暗号化に使用されるキーは、キーストアではなくcn=adminデータ接尾辞に保存されます。この接尾辞は、トポロジのすべてのサーバーにレプリケートされます。そのため、暗号化された属性をクライアント・アプリケーションに送り返す前に任意のOUDインスタンスで復号化できます。
レプリケートされたトポロジで実行されているOUDインスタンスの場合を考えてみます。属性値をディスクに保存するときには、属性値を保護するために、属性の暗号化を定義する必要があります。新規作成された属性データは、レプリケートされたトポロジで暗号化されますが、既存エントリの属性データは安全に保存されません。
すべてのエントリまたは属性データに暗号化を適用するには、次に説明するように、コンテンツをエクスポートして、再インポートする必要があります。
すべてのインスタンスのレプリケーションを有効にします。第32.2.1項「2つのサーバー間のレプリケーションの有効化」を参照してください。
dsconfigを使用して、すべてのインスタンスの属性の暗号化を構成します。第14.7.2項「dsconfigコマンドを使用した属性の暗号化の構成」および第14.7.3項「dsconfig対話モードを使用した属性の暗号化の構成」を参照してください。
インスタンスのいずれかに対してpre-external-initializationを実行します。付録A「サーバー・サブコマンド」を参照してください。
すべてのインスタンスまたは1つのインスタンスのどちらかに対してオフライン・インポートを実行して、他のインスタンスへのバイナリ・コピー、またはdsreplication initializeを実行します。付録A「import-ldif」を参照してください。
インスタンスのいずれかに対してpost-external-initializationを実行します。付録A「サーバー・サブコマンド」を参照してください。
