| Oracle® Fusion Middleware Oracle Unified Directory管理者ガイド 11g リリース2 (11.1.2) B72794-04 |
|
 前 |
 次 |
暗号化は、無許可の機密データへのアクセスを防止するために、平文のデータを暗号文という判読できない形式に変換するメカニズムです。復号化は、暗号文を変換して平文に戻すプロセスです。
この章では、Oracle Unified Directoryで機密情報をどのように暗号化するかについて説明します。この章の内容は次のとおりです:
Oracle Unified Directoryは、ストレージ、同期およびプロキシ機能を統合して、ビジネス・アプリケーションが動作するための重要な識別情報の管理を支援する、次世代の統合ディレクトリ・ソリューションです。そのデータには、機密情報が含まれている可能性があり、参照できるのは意図された受信者のみにする必要があります。Oracle Unified Directoryでは、機密データへのアクセスをセキュリティで保護する、アクセス制御ルール、パスワード認証、SSLなどのいくつかのメカニズムが提供されています。ただし、属性、クレジット・カード番号、SSN番号などの一部の情報は非常に機密性が高い可能性があります。この状況では、情報がデータベース内に判読可能な平文で保存されているため、無許可のアクセスを防止するために標準的な対策のみでは不十分です。つまり、侵入者がサーバーのストレージ・ファイルにアクセスし、その情報を私的な利益のために使用する可能性があります。このような情報の損害は、大きなセキュリティ・リスクとなります。
属性の暗号化機能は、基礎となるデータベース・ファイルに機密情報が保存されている間にその情報を暗号化することで、このような情報の損害を防止します。属性の暗号化により、エントリの特定の機密性の高い属性を暗号化された形式で保存できます。そうすることで、データベース・ファイル、バックアップ・ファイル、およびエクスポートされたLDIFファイルに格納されている間は、データが読めなくなります。
属性の暗号化機能では、LDAPプロトコルで取得されたデータは暗号化されない点に注意してください。ディスク上に保存されたデータのみが暗号化されます。
デフォルトでは、属性は暗号化されません。属性の暗号化は、接尾辞レベルで構成されます。つまり、接尾辞内でその属性が現れるエントリごとに属性が暗号化されます。したがって、属性が暗号化された後、その属性のすべてのインスタンスがデータベース・ファイルに保存される前に暗号化されます。これは、ディスク上にあるその特定の属性のすべてのデータが暗号化されることを意味します。暗号化は常に可逆です。検索リクエストの結果として返されるときには、暗号化された属性が復号化されます。ディレクトリ全体で属性を暗号化する場合は、それぞれの接尾辞でその属性の暗号化を有効にするか、接頭辞のリストを空のままにしておく必要があります。
|
注意: 属性の暗号化は、接尾辞に関連付けられたすべてのデータおよび索引ファイルに影響を与えます。属性の暗号化が有効になった後で変更された属性のみが暗号化されます。既存の属性は、そのまま変更されません。 すべてのデータに暗号化を適用するには、まず構成を変更してから、内容をエクスポートし、その内容をインポートしなおす必要があります。 |
属性の暗号化を使用すると、データを暗号化された形式で別のデータベースにエクスポートすることもできます。属性の暗号化の目的は、機密データが格納またはエクスポートされる場合にのみ、それらのデータを保護することです。
Oracle Unified Directoryでは次の暗号化が可能です。
必須属性タイプ・リストに定義された特定の属性タイプ
一部の操作属性や内部属性(entryuuidやcreateTimestamp、仮想属性、パスワード属性など)は暗号化できません。暗号化でサポートされていない属性の詳細は、第15.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 6の場合:
Java 7の場合:
|
Blowfish (128ビット鍵)
トリプルDES (168ビット鍵)
RC4 (128ビット鍵)
攻撃者は、索引ファイルを通じて直接機密データにアクセスすることもできます。したがって、暗号化する属性に対応する索引キーを暗号化することで、属性を完全に保護することが不可欠です。
データベースの暗号化は索引付けに部分的に対応しています。多くの場合、属性値から抽出される索引ファイルの内容も、攻撃者が索引の分析によって暗号化データの一部または全部を復元しないように暗号化されます。
サーバーは、暗号化された属性の索引を参照する前に、すべての索引鍵を事前に暗号化します。これは、暗号化された索引を利用する検索のサーバー・パフォーマンスに多少影響します。ただし、パフォーマンスの影響は限られているため、索引の使用を妨げることはありません。
Oracle Unified Directoryでは、次の索引タイプを関連する暗号化属性に使用できます。
等価
部分文字列
近似
プレゼンス
|
注意: 暗号化の技法では、索引の順序が維持されないことに注意する必要があります。したがって、属性の暗号化の際に索引の順序指定はサポートされません。 |
暗号化は、DBローカル・バックエンドの索引のみでサポートされています。索引の鍵は暗号化された属性用に暗号化されます。
レプリケーション・トポロジの暗号化では、レプリケーション・サーバーのデータベースに格納された暗号化データを参照します。
レプリケーション・サブシステムは、暗号化の対象ではありません。変更ログと呼ばれるレプリケーション・データベース、および外部変更ログと呼ばれるcn=changelogの両方に対して暗号化はサポートされません。継承される制限によって、バックエンドで暗号化が確実に実行されますが、最後の一連の変更はパージ遅延の間に維持され暗号化されません。
レプリケート・トポロジに含まれるサーバーで操作を実行するとき、その変更が暗号化属性に関係する場合、バックエンドのデータが暗号化されます。ただし、変更ログのデータは暗号化されません。変更ログで変更されたデータがパージされると、この変更について暗号化されていないデータは存在しなくなります。これで、トポロジ内でデータが完全にセキュリティで保護されます。レプリケートされたトポロジでは、トポロジ内のすべてのサーバーでデータ暗号化の構成を有効にする必要があります。これは、トポロジ全体で属性の暗号化を実現するために必要です。サーバーごとのデータ暗号化の構成はレプリケートされません。
暗号化に使用される鍵は、作成および格納され、cn=admin dataから取得されます。この接尾辞は、トポロジ内の他のすべてのサーバーにレプリケートされます。したがって、トポロジ内のすべてのサーバーで、暗号化された属性を復号化し、LDAPクライアントに送信できます。つまり、暗号化または復号化アルゴリズムに使用される鍵は、cn=admin dataがレプリケートされるため、トポロジ全体でレプリケートされます。
属性の暗号化機能を実装する場合、次の点を考慮する必要があります。
属性の暗号化によって、より高いデータのセキュリティを実現できます。ただし、これはシステムのパフォーマンスに影響します。このため、暗号化は最も機密性の高い属性のみで検討する必要があります。
属性の暗号化構成を変更する場合、データをエクスポートして、構成に変更を加えた上で、新たに構成したデータをインポートします。これにより情報の損失なく、すべての構成の変更が考慮されます。これを行わない場合、バックエンドに前からあるデータ暗号化の構成変更で変更されなかったデータが、初期のアルゴリズムによる構成に従って、クリアまたは暗号化形式で維持されます。
アルゴリズムの変更がサポートされています。索引付けされた属性で暗号化を変更するには、暗号化された属性に関連付けられた索引を再構築する必要があります。これも、パフォーマンスに影響します。索引の再構築の詳細は、第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内の値は暗号化されません。
次の属性は、サーバーで内部的に使用されるためサポートされません。
操作属性
objectclass
entryUUID
creatorsName
createTimestamp
modifiersName
modifyTimestamp
仮想属性
仮想属性は暗号化用に構成できません。
パスワード属性
パスワード・ポリシーに定義されたパスワード属性は、データ暗号化に対してサポートされません。たとえば、デフォルト・パスワード・ポリシーに定義されたuserPasswordは、サポートされません。パスワードの暗号化とハッシュは、別々に処理されます。パスワード・ポリシーとパスワード記憶スキームの詳細は、第27章「パスワード・ポリシーの管理」を参照してください。
この項のでは、属性の暗号化を構成する方法について説明します。内容は、次のとおりです。
表15-1は、属性の暗号化を有効にする構成パラメータを説明しています。
表15-1 属性暗号化の構成パラメータ
| 名前 | 説明 | 単一値/複数値 | 形式 | プレゼンスのルール |
|---|---|---|---|---|
|
|
暗号化を有効化または無効化できます。 |
|
ブール値、trueまたはfalseを表す文字列 |
|
|
|
ここに定義されたすべての属性が暗号化されます。すべての接尾辞のすべてエントリの属性が暗号化されます。 |
|
1つの属性名またはOIDを表す文字列 |
|
|
|
存在しない場合、DBローカル・バックエンドに格納されている接尾辞について暗号化が実行されます。存在する場合は、暗号化が実行されるユーザーDBローカル・バックエンド接尾辞のリストを定義します。他の接尾辞は暗号化されません。警告: この接尾辞はバックエンドに定義されているルートの接尾辞にする必要があり、子の接尾辞は使用できません。たとえば、バックエンドにサポートされている接尾辞として |
|
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ファイルでデータが暗号化されているかどうかに関係なく、 現在の構成のアルゴリズムが常に使用されます。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コマンド行の対話モードを使用して、属性の暗号化を構成できます。
メインの「Security」メニューにある「Data Encryption」サブセクションの概要説明によって、表15-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.2.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コマンドを順番に使用して暗号化を構成します。詳細は、第15.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"
|
注意:
|
属性は、次のように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
