| Oracle® Fusion Middleware Oracle Directory Server Enterprise Editionリファレンス 11g リリース1 (11.1.1.7.0) B72441-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Directory Server Enterprise Editionリファレンス 11g リリース1 (11.1.1.7.0) B72441-01 |
|
前 |
次 |
Directory Serverのセキュリティの詳細は、次の各項を参照してください。
Directory Serverは、次の方法を組み合せてセキュリティを提供します。
認証
認証は、1つのパーティが別のパーティのアイデンティティを検証するための手段です。たとえば、クライアントはLDAPのバインド操作中にDirectory Serverに対してパスワードを提供します。ポリシーは、パスワードが有効とみなされるために満たす必要がある基準(期間、長さ、構文など)を定義します。Directory Serverでは、匿名認証、パスワードベースの認証、証明書ベースの認証、SASLベースの認証およびプロキシ認証をサポートされています。認証が拒否された場合、Directory Serverは、アカウント非アクティブ化およびグローバル・ロックアウトというメカニズムを使用してデータを保護します。認証の詳細は、「Directory Serverの認証の提供方法」を参照してください。
暗号化
暗号化によって情報のプライバシが保護されます。データが暗号化されるとき、そのデータは正当な受信者のみがデコードできる方法でスクランブルされます。Directory Serverでは、SSL暗号化および属性の暗号化がサポートされています。暗号化の詳細は、「Directory Serverの暗号化の提供方法」を参照してください。
アクセス制御
アクセス制御では、様々なディレクトリ・ユーザーに付与されたアクセス権を調整し、必須資格証明またはバインド属性を指定するための手段を提供します。アクセス制御の詳細は、「Directory Serverのアクセス制御の提供方法」を参照してください。
監査
監査では、ディレクトリのセキュリティが脅威にさらされているかどうかを判断します。たとえば、ディレクトリによって保持されているログ・ファイルを監査できます。ログ・ファイルの詳細は、第10章「Directory Serverのロギング」を参照してください。
Directory Serverは、アクセス制御命令(ACI)を使用して、LDAPクライアントからのリクエストに対して付与または拒否する権限を定義します。Directory Serverがリクエストを受信すると、サーバー内に定義されたACI、およびユーザーによって提供された認証情報を使用して、ディレクトリ情報へのアクセスを許可または拒否します。サーバーは、読取り、書込み、検索、比較などの権限を許可または拒否できます。
Directory ServerでのACIの詳細は、次の各項を参照してください。
ACIは、aci操作属性に格納されます。aci属性は、エントリのオブジェクト・クラスに対してaci属性が定義されているかどうかにかかわらず、ディレクトリ内のすべてのエントリに使用できます。aci属性は複数値のため、複数のACIをディレクトリの同じ部分に対して定義できます。
ACIは、ディレクトリの次の部分に対するアクセス制御に使用できます。
ディレクトリ全体
ディレクトリのサブツリー
構成タスクを定義するエントリを含む、ディレクトリ内の特定のエントリ
エントリ属性の特定のセット
特定のエントリ属性の値
ACIは、次のユーザーに対するアクセスを定義するために使用できます。
特定のユーザー
特定のグループまたはロールに属しているすべてのユーザー
ディレクトリのすべてのユーザー
IPアドレスまたはDNS名で識別される特定のクライアント
ACIは、ルートDSEを含む、ディレクトリ・ツリー内のすべてのノードに作成できます。
ACIの有効範囲は、ターゲット・エントリ、ターゲット・エントリとその直下の子またはターゲット・エントリとそのすべての子にできます。有効範囲が指定されていない場合、ターゲット・エントリとそのすべての子にACIが適用されます。
サーバーがエントリに対するアクセス権を評価する場合、そのエントリに対するACIおよびエントリのルート・サフィックスのベースにバックアップされる親エントリのACIを検証します。
サーバー内のエントリへのアクセスは、ACIによって明示的に付与される必要があります。ACIはデフォルトで、匿名読取りアクセスを定義し、ユーザーによる自身のエントリ(セキュリティ上必要な属性を除く)の変更を許可します。エントリにACIが適用されない場合、ディレクトリ・マネージャを除くすべてのユーザーに対するアクセスが拒否されます。
ACIによって付与されたアクセスは、階層内の他のACIが拒否しないかぎり、許可されます。階層内で表示される場所にかかわらず、アクセスを拒否するACIは、同じリソースに対してアクセスを許可するACＩより優先されます。
ディレクトリ・マネージャは、アクセス制御が適用されない唯一の特権ユーザーです。クライアントがディレクトリ・マネージャとしてディレクトリにバインドされている場合、サーバーは操作を実行する前にACIを評価しません。
Directory Serverの以前のバージョンでは、ACIはルートDSEの下に直接追加または削除できませんでした。現在、この制限はDirectory Serverで削除されています。
ACIには、次の制限が適用されます。
アクセス制御ルールは、常にローカル・サーバーで評価されます。ACIキーワードに使用されているサーバーのホスト名またはポート番号は、LDAPのURLで指定できません。
ディレクトリ・マネージャとしてユーザーにプロキシに対する権限を付与することはできず、ディレクトリ・マネージャに対してプロキシ権限を付与することもできません。
使用可能な物理メモリーにサーバーが確実に適合するために使用するキャッシュ設定は、ACIキャッシュには適用されませんが、これは、過剰な数のACIが使用可能なメモリーを飽和させる可能性があることを意味します。
次のデフォルトACIがルートDSEで定義されています。
すべてのユーザーは、検索、比較および読取り操作用に、ディレクトリに対して匿名アクセスを持ちます(userpassword属性を除く)。
バインド済ユーザーは、自身のパスワードを変更できます。
グループcn=Administrators,cn=configのユーザーは、すべてのエントリに対して完全なアクセスを持ちます。これはディレクトリ・マネージャのアクセスと同等ですが、ディレクトリ・マネージャとは異なり、管理者グループのユーザーはACIの対象になります。
ACIはエントリの属性として格納されます。したがって、ACIを含むエントリがレプリケートされたサフィックスの一部の場合、ACIは他の属性と同様にレプリケートされます。
ACIは、受信LDAPリクエストを処理するディレクトリ・サーバー上で、常にローカルで評価されます。
コンシューマ・サーバーが更新リクエストを受信すると、コンシューマ・サーバーは、このリクエストをマスターで処理できるかどうかを評価するために、マスター・サーバーに対してリフェラルを返します。
実効権限機能は、次の情報を取得するために使用できます。
エントリ・レベルの権限、属性レベルの権限およびロギングを含む、権限情報。
書込み、自己書込みの追加および自己書込みの削除に対する権限。
アクセス制御の問題をデバッグするためのログ情報。
実効権限機能を使用するには、実効権限制御を使用するためのアクセス制御権限およびaclRights属性の読取りアクセス権が必要です。
プロキシ制御が実効権限制御ベースの検索操作に付随している場合は、実効権限操作はプロキシ・ユーザーとして認証されます。そのため、プロキシ・ユーザーは、実効権限制御を使用するための権利を持っている必要があります。プロキシ・ユーザーが検索および表示に対する権利を持つエントリが返されます。詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の第6章「Directory Serverのアクセス制御」を参照してください。
Directory Serverは、アクセス制御命令に対して、パフォーマンスおよびスケーラビリティの改善を提供します。改善には、メモリー管理の向上が含まれます。また、マクロACIに対するサポートも改善に含まれます。改善にもかかわらず、Directory Serverは複合ACIを評価するためにかなりのシステム・リソースを使用します。したがって、複合ACIを大量に使用すると、パフォーマンスに悪影響を与える場合があります。
マクロACIは、使用するACIの数を制限するのに役立ちます。ACIの数を制限することで、システム上の負荷を管理および削減するためのアクセス制御が容易になります。マクロは、ACIの中でDN、またはDNの一部を表現するプレースホルダです。マクロは、ACIターゲット内、ACIバインド・ルール内またはその両方で使用できます。Directory Serverがリクエストを受信すると、結果として生じる操作のターゲットとなるリソースに一致するACIマクロが確認されます。マクロが一致した場合、Directory Serverは、それを実際のDNの値で置き換えます。その後、Directory Serverは順当にACIを評価します。
テストでは、Directory Serverインスタンスは50,000を超えるACIをサポートできることが証明されました。とはいえ、ACIの数はできるだけ少なく維持します。ACIの数を少なく維持することで、パフォーマンスへの悪影響が制限されます。数を少なくすることで、アクセス制御の管理の複雑さも軽減されます。複合ACI環境が関係するデプロイでは、一部のアクセス制御機能を提供するために、Directory Proxy Serverの使用を検討してください。
認証は、アイデンティティを確認するプロセスです。ネットワーク相互作用では、認証は、別のパーティによる1つのパーティのアイデンティティの確実性に関係します。一般にネットワーク相互作用は、パーソナル・コンピュータ上で動作しているブラウザ・ソフトウェアなどのクライアントと、Webサイトをホストするために使用されるソフトウェアおよびハードウェアなどのサーバー間で行われます。クライアント認証では、サーバーによるクライアントの確証アイデンティティを参照し、サーバー認証では、クライアントがサーバーの確証アイデンティティを参照します。
認証の詳細は、次の各項を参照してください。
匿名アクセスでは、認証資格証明を提供することなく、ユーザーをディレクトリにバインドできます。アクセス制御を使用することで、匿名ユーザーに選択した任意の権限を付与できます。たいていの場合、匿名ユーザーは、ディレクトリからの名前、電話番号、電子メールアドレスなどの機密ではないデータの読取りが許可されます。
匿名アクセスの権限を制限したり、アドレス帳情報が含まれる属性のサブセットに匿名アクセスを制限することもできます。機密データに対して匿名アクセスを許可しないようにします。
匿名ユーザーが何かに対するアクセス権を持っている場合、匿名としてアクセスが付与されているにもかかわらず、ユーザーが適切なバインドに失敗するのを防ぐ必要がある場合があります。詳細は、serverのrequire-bind-pwd-enabledを参照してください。
単純なパスワード認証は、ユーザーの認証の簡単な方法を提供します。パスワード認証では、ユーザーは、各サーバーに対してパスワードを提供する必要があり、管理者は、各ユーザーの名前およびパスワードを(通常はサーバーごとに)追跡する必要があります。
図5-1に、名前およびパスワードを使用したクライアントの認証に関する手順を示します。この図では次の点を想定しています。
ユーザーは、認証せずに、またはSSLを介したサーバー認証の基づいて、システムをすでに信頼しています。
ユーザーは、サーバーによって制御されるリソースをリクエストしました。
サーバーは、リクエストされたリソースへのアクセスを許可する前に、クライアント認証が必要です。
図5-1では、パスワード認証は次の手順で実行されます。
ユーザーが名前とパスワードを入力します。
Directory ServerへのLDAPバインドでは、クライアント・アプリケーションは識別名を使用してバインドする必要があります。そのため、クライアント・アプリケーションは、ユーザーによって入力された名前を使用してDNを取得する場合があります。
クライアントは、DNおよびパスワードをネットワークを介して送信します。
サーバーは、クライアントが送信したパスワードが、エントリに対して格納されているパスワードと一致していることかどうかをクライアントが送信したDNを使用して確認します。
一致する場合、サーバーは、ユーザー・アイデンティティを認証した証拠として資格証明を受け入れます。
サーバーは、識別したユーザーによるリクエストされたリソースに対するアクセスが許可されているかどうかを確認します。
許可されている場合、サーバーはクライアントに対してリソースへのアクセスを許可します。
パスワード・ポリシーは、システムでのパスワードの管理方法を制御する一連のルールです。Directory Serverでは、複数のパスワード・ポリシーがサポートされています。パスワード・ポリシーは、デプロイメントのセキュリティ要件を満たすように構成できます。
Directory Serverのインスタンスは、デフォルトのパスワード・ポリシーを使用して作成されます。
Directory Serverには、次のパスワード・ポリシーが用意されています。
デフォルトのパスワード・ポリシーは、構成エントリcn=PasswordPolicy,cn=configに定義されています。デフォルトのパスワード・ポリシーはディレクトリ・マネージャを除くディレクトリ内のすべてのアカウントに適用されます。
デフォルトのポリシーのパラメータは、デフォルト設定をオーバーライドするために変更できます。ただし、デフォルトのパスワード・ポリシーはインスタンスの構成の一部であるため、デフォルトのパスワード・ポリシーに対する変更はレプリケートできません。
パスワード・ポリシーは、個々のユーザー、またはCoSおよびロール機能を使用することでユーザーのセットに対して構成できます。ただし、特殊パスワード・ポリシーは静的グループには適用できません。
特殊パスワード・ポリシーはディレクトリ・ツリーのサブエントリに定義されます。デフォルトのパスワード・ポリシーと同様に、特殊パスワード・ポリシーはpwdPolicyオブジェクト・クラスを使用します。たとえば、次のエントリは特殊パスワード・ポリシーを定義します。
dn: cn=TempPolicy,dc=example,dc=com objectClass: top objectClass: pwdPolicy objectClass: LDAPsubentry cn: TempPolicy pwdCheckQuality: 2 pwdLockout: on pwdLockoutDuration: 300 pwdMaxFailure: 3 pwdMustChange: on
特殊パスワード・ポリシーは、単一のユーザー・アカウントまたはロールを使用することでユーザーのセットに割り当てることができます。たとえば、次のエントリでは、cn=TempPolicy,dc=example,dc=comに定義されたパスワード・ポリシーは、ユーザー・エントリのpwdPolicySubentry属性に割り当てられています。
dn: uid=dmiller,ou=people,dc=example,dc=com objectClasaccess controls: person objectClass: top sn: miller cn: david userPassword: secret12 pwdPolicySubentry: cn=TempPolicy,dc=example,dc=com
ユーザー・エントリによって参照されると、特殊パスワード・ポリシーは、デフォルトのパスワード・ポリシーをオーバーライドします。
特殊パスワード・ポリシーはディレクトリ・データに定義されるため、レプリケートできます。
パスワード・ポリシーの構成方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の第7章「Directory Serverのパスワード・ポリシー」を参照してください。
パスワード・ポリシーの構成に使用される属性の詳細は、pwpolicyマニュアル・ページを参照してください。
プロキシ認可では、クライアントからのリクエストを、クライアントのアイデンティティではなくプロキシ・アイデンティティを使用して処理できます。自身のアイデンティティを使用してバインドされたクライアントには、プロキシ認可を介してプロキシ・ユーザーの権限が付与されます。クライアントのアクセス制御命令(ACI)ではなく、プロキシ・ユーザーのACIは、操作を許可または拒否するために評価されます。
プロキシ認可を使用して操作を実行する前に、プロキシ・ユーザーのアカウントが検証されます。プロキシ・ユーザーのアカウントがロック・アウト、非アクティブ化されている場合、パスワードがリセットされた場合または期限切れの場合は、クライアント操作は強制終了されます。
プロキシ認可を使用することで、LDAPアプリケーションは、単一のバインドを使用して、Directory Serverに対してリクエストを行う複数のユーザーに対処できます。各ユーザーに対してバインドおよび認証するのではなく、クライアント・アプリケーションはDirectory Serverにバインドしてプロキシ権限を使用します。
プロキシ認可を使用するには、次の条件を満たしている必要があります。
Directory Serverは、プロキシ・アイデンティティに対して適切なACIを使用して構成されている必要があります。
たとえば、次のACIは、ALLアクセス権限を管理者に与えます。
aci: (targetattr="*") (version 3.0; acl "allowAll-Admin"; allow (all) userdn="ldap:///uid=Administrator, ou=Administrators, dc=example,dc=com";)
Directory Serverは、他のユーザーに対してプロキシとして動作するために、プロキシ・アイデンティティに対する許可を使用して構成されている必要があります。
たとえば、次のACIは、ユーザーuser ClientApplicationに対してプロキシとして動作する権限を管理者に与えます。
aci: (targetattr="*") (version 3.0; acl "allowproxy- accountingsoftware"; allow (proxy) userdn= "ldap:///dn:uid=ClientApplication,ou=Applications, dc=example,dc=com";)
次の例に、Administratorプロキシ・アイデンティティを使用して検索操作を実行するユーザーClientApplicationを示します。
$ ldapsearch \
-D "uid=ClientApplication,ou=Applications,dc=example,dc=com" \
-w password \
-y "uid=Administrator,ou=Administrators,dc=example,dc=com" ...
クライアントは自身としてバインドしますが、プロキシ・エントリの権限が付与されます。クライアントには、プロキシ・エントリのパスワードは不要です。
プロキシ権限は、ディレクトリ・マネージャを除くすべてのユーザーに付与できます。
プロキシ認可の構成方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のプロキシ認可に関する説明を参照してください。
ユーザー・アカウントまたはアカウントのセットは、dsutil account-inactivateコマンドを使用して、一時的または無限に非アクティブ化できます。「dsutil」を参照してください。
アカウントが非アクティブの場合、ユーザーはDirectory Serverにバインドできません。この機能は、アカウントの非アクティブ化と呼ばれます。
ユーザー・アカウントおよびロールは非アクティブ化できます。ロールが非アクティブの場合、ロール自体ではなく、ロールのメンバーが非アクティブ化されます。
アカウントの非アクティブ化の構成方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のアカウントの手動ロックに関する説明を参照してください。
パスワード・ポリシーの設定に応じて、失敗したバインド試行の数が許可されているバインド試行の数を超えた場合に、クライアント・アカウントは、アカウントからロック・アウトされます。レプリケートされたトポロジでは、クライアントがバインドを試みたインスタンスのみでなく、Directory Serverのすべてのインスタンスからクライアントがロック・アウトされます。この機能は、グローバル・アカウント・ロックアウトと呼ばれます。
Directory Server 6より前のDirectory Serverのバージョンでは、アカウント・ロックアウトは整数カウンタに基づいていました。これらのカウンタは、デフォルトではレプリケートされませんでした。
製品のこのバージョンでは、バインド機能はタイムスタンプを使用して記録されます。タイムスタンプはデフォルトでレプリケートされ、失敗したバインド・リクエストが原因で発生したロック・アウト・データに対する更新をレプリケートするために優先順序付きレプリケーションが使用されます。
グローバル・アカウント・ロックアウトは、次のシナリオで使用できます。
レプリケーションがバインド失敗を伝播するために使用される場合
バインド・リクエストは読取り専用のコンシューマを対象にできません。クライアントが読取り専用コンシューマへのバインドに失敗した場合、ロックアウト・データはレプリケートされません。そのため、バインド・リクエストが読取り専用コンシューマで失敗した場合、ロックアウト・データはそのインスタンス上でのみ更新され、トポロジ全体にはレプリケートされません。
すべてのバインド試行がマスター・レプリカを対象としている場合でも、クライアントは、ロックアウト・データがレプリケートされるより早く複数のサーバー上でバインド試行を実行できる可能性があります。このようにして、クライアントは、パスワード・ポリシーでの失敗したバインド試行の制限を超えることができます。優先順序付きレプリケーションを使用してバインドの失敗がレプリケートされる場合にも、この危険性が存在することに注意してください。
Directory Proxy Serverがバインド操作のルーティングを管理する場合
Directory Proxy Serverでは、ロード・バランシング用にハッシュ・アルゴリズムを使用して指定されたアカウントに対するすべてのバインド・リクエストを同じDirectory Serverにルートすることで、グローバル・アカウント・ロックアウトを実現できます。グローバル・アカウント・ロックアウトのためのハッシュ・アルゴリズムの使用に関する詳細は、「グローバル・アカウント・ロックアウトの操作アフィニティ・アルゴリズム」を参照してください。
証明書を使用したクライアント認証の詳細は、次の各項を参照してください。
図5-2に、認証での証明書およびSSLプロトコルの併用方法を示します。サーバーに対してユーザーを認証するには、クライアントは、ランダムに生成されたデータの1つにデジタル署名し、証明書および署名済データの両方をネットワークを介して送信します。この説明では、データに関連付けられているデジタル署名は、クライアントからサーバーに対して提供された証拠と考えることができます。サーバーは、ユーザーのアイデンティティをこの証拠の強度で認証します。
図5-1に示されているパスワードベースの認証と同様に、図5-2は、ユーザーは、すでにサーバーを信用済で、リソースをリクエスト済であると想定します。サーバーは、リクエストされたリソースへのアクセスを付与するかどうかの評価の過程で、クライアント認証をリクエスト済です。
図5-1に示されているパスワードベースの認証とは異なり、図5-2ではSSLの使用が必要です。図5-2では、サーバーに対してクライアントを識別するために使用できる有効な証明書がクライアントにあることを想定しています。
証明書ベースの認証は、ユーザーが持っているもの(秘密鍵)およびユーザーが認識していること(秘密鍵を保護するパスワード)に基づいているため、一般に、パスワードベースの認証より望ましいと考えられています。ただし、これら2つの前提は、権限のない者がユーザーのマシンまたはパスワードにアクセスしない場合、クライアント・ソフトウェアの秘密鍵データベースにパスワードが設定されている場合およびソフトウェアが適度な頻度の間隔でパスワードを要求するように設定されている場合にのみ当てはまることに注意する必要があります。
|
注意: パスワードベースの認証および証明書ベースの認証のどちらも、個々のマシンまたはパスワードへの物理的アクセスに関するセキュリティの問題には対処しません。公開鍵暗号化のみが、証明書内の公開鍵に対応する一部のデータの署名に使用された秘密鍵を検証できます。マシンの物理的セキュリティを保護することおよび秘密鍵のパスワードを隠しておくことはユーザーの責任です。 |
証明書は、クライアントとサーバー間の相互作用の認証部分を置換します。終日にわたってユーザーにネットワークを介してパスワードの送信を要求するかわりに、シングル・サインオンでは、ネットワークを介して送信するのではなく、ユーザーは、秘密鍵データベースのパスワードを一度のみ入力する必要があります。残りのセッションでは、クライアントは、新しく接続する各サーバーに対してユーザーを認証するためにユーザーの証明書を提示します。認証済のユーザー・アイデンティティに基づいた既存の認証メカニズムには影響しません。
証明書は、電子ドキュメントで、個人、サーバー、会社またはその他のエンティティを識別します。証明書は、そのアイデンティティと秘密鍵を関連付けます。運転免許証、パスポートまたは一般に使用されるその他の個人のIDと同様に、証明書は、誰かまたは何かのアイデンティティの一般に認識されている証拠を提供します。
認証局(CA)は、アイデンティティを検証し、証明書を発行します。CAは、独自の証明書発行サーバー・ソフトウェアを実行する独立したサード・パーティまたは組織です。アイデンティティの検証に使用される方法は、指定されたCAのポリシーによって異なります。一般には、証明書の発行前に、CAは、証明書の発行をリクエストしているエンティティが、実際に要求している本人であることを確認するために、証明書のその種類用に公開されている検証手順を使用する必要があります。
CAによって発行された証明書は、特定の秘密鍵をその証明書が識別するエンティティの名前(従業員またはサーバーの名前など)にバインドします。証明書は、なりすまし用の偽の秘密鍵の使用を防ぐのに役立ちます。証明書によって認証された公開鍵のみが、その証明書によって識別されたエンティティが保有する対応する秘密鍵と機能します。
公開鍵に加え、常に、証明書には、それが識別するエンティティの名前、有効期限、その証明書を発行したCAの名前、シリアル番号およびその他の情報が含まれます。最も重要なことは、証明書には発行したCAのデジタル署名が常に含まれています。CAのデジタル署名によって、証明書は、証明書によって識別されたエンティティは知らないが、そのCAを認識して信頼するユーザーにとっての「紹介状」として機能できます。
証明書をサポートするすべてのクライアント・ソフトウェアまたはサーバー・ソフトウェアは、信頼できるCAの証明書の集合を維持します。これらのCA証明書は、ソフトウェアが検証できる他の証明書を特定、つまり、ソフトウェアが信頼できる証明書の発行者を特定します。最も簡単な場合、ソフトウェアは、証明書を保持しているCAの1つによって発行された証明書のみを検証できます。また、信頼されたCA証明書は、証明書の階層でそれより上位にあるCAによってそれぞれが発行されたCA証明書のチェーンの一部になることができます。
CAの詳細は、次の各項を参照してください。
大規模な組織では、証明書の発行に対する責任を異なる複数の認証局に委任することが適切な場合があります。たとえば、単一のCAでは維持できないほど必要な証明書の数が多い場合、それぞれの組織単位で異なるポリシー要件が必要な場合、証明書を発行する人々と同じ地理的な場所に物理的に位置することがCAによって重要な場合です。
証明書発行の責任を下位のCAに委任することができます。X.509規格には、CAの階層を設定するためのモデルが含まれています。
このモデルでは、ルートCAが階層の最上位にあります。ルートCAの証明書は、自己署名証明書です。つまり、証明書は、証明書が識別するのと同じエンティティ(ルートCA)によってデジタル署名されます。ルートCAの直下にあるCAには、ルートCAによって署名されたCA証明書があります。階層で、下位のCAの下にあるCAには、より上位レベルにある下位CAによって署名されたCA証明書があります。
組織は、独自のCA階層を設定する方法に関して、非常に高い柔軟性を持っています。図5-3には、1つの例のみを示しますが、多数の他の配置が可能です。
CA階層は証明書チェーンに反映されます。証明書チェーンは、連続するCAによって発行された一連の証明書です。図5-4に、(次の図に示すCA階層に基づいて) 2つの下位CA証明書を介していくつかのエンティティを識別する証明書からルートCAのCA証明書までの証明書チェーンを示します。
証明書チェーンは、階層内のブランチから階層のルートまでの証明書の経路をたどります。証明書チェーンでは、次のことが発生します。
各証明書の後にその発行者の証明書が続きます。
図5-4では、Engineering CA証明書にはその証明書を発行したCA (つまり、USA CA)のDNが含まれています。USA CAのDNは、チェーン内の次の証明書のサブジェクト名でもあります。
各証明書は、発行者の秘密鍵を使用して署名されます。署名は、発行者の証明書(チェーンの次の証明書)内の公開鍵を使用して検証できます。
図5-4では、USA CAの証明書内の公開鍵は、Engineering CAの証明書上のUSA CAのデジタル署名を検証するために使用できます。
証明書チェーンの検証は、指定された証明書チェーンが適格で、有効で、適切に署名され、信頼できることを確認する過程です。Directory Serverソフトウェアは、証明書チェーンの形成および検証を、認証のために提示された証明書から次の手順を使用して始めます。
証明書の有効期間は、検証装置のシステム時計で提供される現在の時間と照合されます。
発行者の証明書が特定されます。ソースは、検証者のローカル証明書データベース(クライアントまたはサーバー上)またはサブジェクトによって指定されている証明書チェーン(SSL接続経由など)のいずれかになります。
証明書の署名は、発行者の証明書の公開鍵を使用して検証されます。
発行者の証明書が、検証者の証明書データベース内の検証者によって信頼される場合は、検証は成功し、ここで終了します。それ以外の場合は、発行者の証明書にDirectory Server証明書タイプの拡張の適切な下位のCA表示が含まれていることを確認するために確認され、チェーンの検証は手順1に戻り、この新しい証明書を使用して再び開始されます。
図5-5に、検証者のローカル・データベースにルートCAのみが含まれている場合の動作を示します。図5-6に示す中間CAの1つの証明書(Engineering CAなど)が検証者のローカル・データベースに見つかった場合、図に示すとおり、検証はその証明書で停止します。
証明書チェーン内のどの時点でも、有効期限切れ、無効な署名または発行したCAの証明書がないことによって、認証は失敗します。たとえば、次の図に、検証者のローカル・データベースにルートCAの証明書または中間CAの証明書が含まれていない場合に、検証がどのように失敗するのかを示します。
デジタル署名が機能する方法の概要は、「デジタル署名」を参照してください。
Directory Serverは、次のタイプの証明書を使用します。
クライアントSSL証明書は、サーバーに対してSSL (クライアント認証)を介してクライアントを識別するために使用されます。一般に、クライアントのアイデンティティは、企業の従業員などの人間のアイデンティティと同様であると考えられています。クライアントSSL証明書は、フォームの署名に使用され、シングル・サインオン・ソリューションの一部として使用できます。
たとえば、銀行は顧客に対してクライアントSSL証明書を提供し、銀行のサーバーがその顧客を識別して、顧客のアカウントへのアクセスを許可することが可能です。会社は新しい従業員に対してクライアントSSL証明書を提供し、会社のサーバーがその従業員を識別して、会社のサーバーへのアクセスを許可することが可能な場合があります。
サーバーSSL証明書は、クライアントに対してSSL (サーバー認証)を介してサーバーを識別するために使用されます。サーバー認証は、クライアント認証を使用してまたは使用せずに、使用することができます。サーバー認証は、暗号化されたSSLセッションの要件です。
たとえば、電子商取引に携わるインターネット・サイトは通常、少なくとも証明書ベースのサーバー認証をサポートして、暗号化SSLセッションを確立し、顧客が特定の会社であることが確認されたWebサイトと取引することを保証します。暗号化SSLセッションでは、ネットワークを介して送信されるクレジット・カード番号などの個人情報が簡単に傍受されないことを保証します。
S/MIME証明書は、署名および暗号化された電子メールで使用されます。クライアントSSL証明書と同様に、クライアントのアイデンティティは、一般に、企業の従業員などの人間のアイデンティティと同様であると考えられています。単一の証明書がS/MIME証明書およびSSL証明書の両方で使用されることがあります。S/MIME証明書は、フォームの署名に使用され、シングル・サインオン・ソリューションの一部として使用できます。
たとえば、会社は、従業員のアイデンティティを認証する目的で、S/MIME証明書とSSL証明書を組み合せて配置し、これによって署名された電子メールおよびクライアントSSL認証は許可しますが、暗号化された電子メールは許可しません。別の会社は、機密に属する財務または法的事項を扱う署名および暗号化された電子メールの両方を目的として、S/MIME証明書を発行します。
オブジェクト署名証明書は、Javaコード、JavaScriptのスクリプトまたはその他の署名されたファイルの署名者を識別するために使用されます。
たとえばソフトウェア会社は、そのソフトウェアがその会社の正規の製品であるという保証をユーザーに与えるために、インターネットを介して配布されるソフトウェアに署名します。証明書およびデジタル署名をこの方法で使用することによって、ダウンロードしたソフトウェアがコンピュータに対して行うアクセスの種類を、ユーザーが識別および制御することも可能になります。
CA証明書は、CAの識別に使用されます。クライアント・ソフトウェアおよびサーバー・ソフトウェアは、CA証明書を使用して、信用できる他の証明書を識別します。
たとえば、クライアント・ソフトウェアに格納されたCA証明書は、クライアントが認証できる他の証明書を判別します。管理者は、各ユーザーのクライアントに格納されたCA証明書を制御することによって、会社のセキュリティ・ポリシーの一部を実装できます。
Directory Serverおよびその他多数のソフトウェア会社によってサポートされる証明書の内容は、国際的基準策定団体である国際電気通信連動(ITU)によって1988年から推奨されているX.509 v3の証明書仕様に従って編成されています。この項の例は、証明書のデータおよび署名セクションの例を示します。
すべてのX.509証明書は、次の各セクションで構成されています。
データ・セクションには、次の情報が含まれます。
証明書でサポートされるX.509規格のバージョン番号。
証明書のシリアル番号。CAによって発行されるすべての証明書には、そのCAで発行される証明書間で一意のシリアル番号があります。
使用されたアルゴリズムおよび鍵自身の表現を含む、ユーザーの公開鍵に関する情報。
その証明書を発行したCAのDN。
証明書が有効である期間(2003年11月15日の午後1時から2004年11月15日の午後1時までなど)。
証明書のサブジェクトのDN (たとえば、クライアントSSL証明書ではユーザーのDN)、サブジェクト名と呼ばれます。
オプションの証明書拡張要素、クライアントまたはサーバーで使用される追加データを提供する場合があります。たとえば、証明書タイプの拡張は、証明書のタイプ、つまり、それがクライアントSSL証明書か、サーバーSSL証明書か、署名付き電子メールに対する証明書かどうかなどを示します。証明拡張要素は、他の様々な目的で使用することもできます。
署名セクションには、次の情報が含まれます。
発行CAによって自身のデジタル書名を作成するために使用される暗号アルゴリズム(暗号)。
証明書内のすべてのデータを一緒にハッシュし、CAの秘密鍵を使用して暗号化することで取得されるCAのデジタル署名。
例5-1 証明書の人間が判読可能な形式でのデータ・セクションおよび署名セクション
Certificate:
Data:
Version: v3 (0x2)
Serial Number: 3 (0x3)
Signature Algorithm: PKCS #1 MD5 With RSA Encryption
Issuer: OU=Certificate Authority, O=Example Industry, C=US
Validity:
Not Before: Fri Oct 17 18:36:25 2003
Not After: Sun Oct 17 18:36:25 2004
Subject: CN=Jane Doe, OU=Finance, O=Example Industry, C=US
Subject Public Key Info:
Algorithm: PKCS #1 RSA Encryption
Public Key:
Modulus:
00:ca:fa:79:98:8f:19:f8:d7:de:e4:49:80:48:e6:2a:2a:86:
ed:27:40:4d:86:b3:05:c0:01:bb:50:15:c9:de:dc:85:19:22:
43:7d:45:6d:71:4e:17:3d:f0:36:4b:5b:7f:a8:51:a3:a1:00:
98:ce:7f:47:50:2c:93:36:7c:01:6e:cb:89:06:41:72:b5:e9:
73:49:38:76:ef:b6:8f:ac:49:bb:63:0f:9b:ff:16:2a:e3:0e:
9d:3b:af:ce:9a:3e:48:65:de:96:61:d5:0a:11:2a:a2:80:b0:
7d:d8:99:cb:0c:99:34:c9:ab:25:06:a8:31:ad:8c:4b:aa:54:
91:f4:15
Public Exponent: 65537 (0x10001)
Extensions:
Identifier: Certificate Type
Critical: no
Certified Usage:
SSL Client
Identifier: Authority Key Identifier
Critical: no
Key Identifier:
f2:f2:06:59:90:18:47:51:f5:89:33:5a:31:7a:e6:5c:fb:36:
26:c9
Signature:
Algorithm: PKCS #1 MD5 With RSA Encryption
Signature:
6d:23:af:f3:d3:b6:7a:df:90:df:cd:7e:18:6c:01:69:8e:54:65:fc:06:
30:43:34:d1:63:1f:06:7d:c3:40:a8:2a:82:c1:a4:83:2a:fb:2e:8f:fb:
f0:6d:ff:75:a3:78:f7:52:47:46:62:97:1d:d9:c6:11:0a:02:a2:e0:cc:
2a:75:6c:8b:b6:9b:87:00:7d:7c:84:76:79:ba:f8:b4:d2:62:58:c3:c5:
b6:c1:43:ac:63:44:42:fd:af:c8:0f:2f:38:85:6d:d6:59:e8:41:42:a5:
4a:e5:26:38:ff:32:78:a1:38:f1:ed:dc:0d:31:d1:b0:6d:67:e9:46:a8:
d:c4
例5-2 ソフトウェアによって解読される64バイトでエンコードされた形式での証明書
-----BEGIN CERTIFICATE----- MIICKzCCAZSgAwIBAgIBAzANBgkqhkiG9w0BAQQFADA3MQswCQYDVQQGEwJVUzER MA8GA1UEChMITmV0c2NhcGUxFTATBgNVBAsTDFN1cHJpeWEncyBDQTAeFw05NzEw MTgwMTM2MjVaFw05OTEwMTgwMTM2MjVaMEgxCzAJBgNVBAYTAlVTMREwDwYDVQQK EwhOZXRzY2FwZTENMAsGA1UECxMEUHViczEXMBUGA1UEAxMOU3Vwcml5YSBTaGV0 dHkwgZ8wDQYJKoZIhvcNAQEFBQADgY0AMIGJAoGBAMr6eZiPGfjX3uRJgEjmKiqG 7SdATYazBcABu1AVyd7chRkiQ31FbXFOGD3wNktbf6hRo6EAmM5/R1AskzZ8AW7L iQZBcrXpc0k4du+2Q6xJu2MPm/8WKuMOnTuvzpo+SGXelmHVChEqooCwfdiZywyZ NMmrJgaoMa2MS6pUkfQVAgMBAAGjNjA0MBEGCWCGSAGG+EIBAQQEAwIAgDAfBgNV HSMEGDAWgBTy8gZZkBhHUfWJM1oxeuZc+zYmyTANBgkqhkiG9w0BAQQFAAOBgQBt I6/z07Z635DfzX4XbAFpjlRl/AYwQzTSYx8GfcNAqCqCwaSDKvsuj/vwbf91o3j3 UkdGYpcd2cYRCgKi4MwqdWyLtpuHAH18hHZ5uvi00mJYw8W2wUOsY0RC/a/IDy84 hW3WWehBUqVK5SY4/zJ4oTjx7dwNMdGwbWfpRqjd1A== -----END CERTIFICATE-----
ネットワーク環境での公開鍵暗号化およびX.509 v3の証明書の使用を容易にする標準およびサービスのセットは、公開鍵インフラストラクチャ(PKI)と呼ばれます。Directory Serverで対処される証明書管理の問題の詳細は、次の各項を参照してください。
証明書の発行プロセスは、発行する認証局および使用目的によって異なります。非デジタル形式の識別情報の発行プロセスも同様に異なります。たとえば、カリフォルニアの車両管理局から一般的なIDカード(運転免許証ではなく)を取得する場合、住所が記載された公共料金の請求書や学生証などのアイデンティティを証明するものを提示する必要があるという具合に、要件は単純です。通常の運転免許証を取得する場合は、試験(初めて免許を取得する場合は運転の試験を、更新の場合は筆記試験)も受ける必要があります。18輪トラックの第2種運転免許を取得する場合は、要件はより厳しくなります。他の州や国に住んでいる場合、様々な種類の免許に対する要件は異なります。
同様に、それぞれのCAには、様々な種類の証明書の発行に異なる手順があります。郵便の宛先が唯一の要件である場合もあります。UNIXのログインおよびパスワードで十分な場合もあります。基準の反対側の端では、大規模な出費する権限を与えたり、慎重に扱うべき決定をする人を識別するための証明書では、公正証書、身元調査および個人面接が発行プロセスで必要になる場合があります。
組織のポリシーに応じて、証明書の発行プロセスは、ユーザーに対して完全に透過的なものからかなりのユーザー参加と複雑な手順が必要なものまで多岐にわたります。一般に、証明書の発行プロセスは、組織が変化するニーズにプロセスを適応させることができるように、高度に柔軟である必要があります。
証明書の発行は、個々の登録局によって処理可能な複数の管理タスクの1つです。
ディレクトリ・サービスにアクセスするためのLightweight Directory Access Protocol (LDAP)は、組織内の証明書の管理における高柔軟性をサポートします。システム管理者は、証明書の管理に必要な情報の多くをLDAP準拠のディレクトリに格納できます。たとえば、CAは、ディレクトリ内の情報を使用して、新しい従業員の氏名およびその他の情報を使用して証明書を事前移入できます。CAは、指定された組織のセキュリティ・ポリシーに応じた様々な識別技術を使用して、証明書を1つずつまたはまとめて発行するための他の方法でディレクトリ情報を使用できます。鍵の管理および証明書の更新や失効などのその他の日常的な管理タスクは、このディレクトリを活用して一部または完全に自動化できます。
ディレクトリに格納された情報は、様々なユーザーまたはグループごとに各種のネットワークリソースに対するアクセスを制御するために、証明書で使用することもできます。そのため、証明書の発行およびその他の証明書の管理タスクは、ユーザーおよびグループの管理の不可欠な部分になります。
証明書を発行する前に、証明書に含まれる公開鍵および対応する秘密鍵を生成する必要があります。1人に対して、署名操作には1つの証明書と鍵のペアを発行し、暗号化操作には別の証明書と鍵のペアを発行することが有効な場合もあります。署名と暗号化の証明書を分けることで、秘密の署名鍵をローカル・マシンのみに保持し(これにより最大の非拒否が提供され)、ユーザーが元の鍵を失くしたり会社を辞める場合に取得できるように、秘密の暗号化鍵を中央の場所のどこかにバックアップすることが可能になります。
鍵は、クライアント・ソフトウェアによって、またはCAによって集中的に生成でき、LDAPディレクトリを介してユーザーに配布できます。ローカルおよび集中型の鍵生成の選択の際には、トレードオフが関係します。たとえば、ローカル鍵生成では最大の非拒否が提供されますが、発行プロセスにはユーザーの参加がより多く伴う場合があります。柔軟なキー管理機能は、ほとんどの組織にとって不可欠です。
鍵のリカバリ、つまり注意深く定義された条件下での暗号化鍵のバックアップを取得する機能は、証明書管理の重要な要素となります(組織の証明書の使用方法に応じて)。鍵のリカバリ・スキームには通常、M of Nメカニズムを必要としますが、たとえば、特定の人の暗号化鍵をリカバリする前には、組織のM of N人のマネージャが同意する必要があり、それぞれが独自の特別なコードまたはキーを提供します。この種のメカニズムでは、暗号化鍵をリカバリする前に、複数の関係者の同意が必要になります。
運転免許証と同様に、証明書はそれが有効である期間を指定します。有効期間の前または後に、認証に証明書を使用しようとすると失敗します。そのため、証明書更新を管理するためのメカニズムは、すべての証明書管理計画で不可欠のものです。たとえば管理者は、証明書のサブジェクトで不都合が発生しないように、適切な更新プロセスが時間に余裕を持って完了するように、有効期限が近くなったら自動的に通知されるようにする場合もあります。更新プロセスでは、同じ公開鍵と秘密鍵のペアを再使用する場合や、新しい鍵を発行する場合があります。
運転免許証は、たとえば重大な運転違反の処罰として、期限切れでない場合でも一時停止できます。同様に、従業員が会社を辞める場合や会社内の他の仕事に移る場合などに、期限が切れる前に証明書を失効する必要がある場合があります。
証明書の失効は、複数の異なる方法で処理できます。提示された証明書がディレクトリに存在することの確認を認証プロセス含むようにサーバーを設定することで十分な組織もあります。管理者が証明書を失効させると、その証明書はディレクトリから自動的に削除され、その後のその証明書を使用した認証の試行は、その他すべての箇所で有効のままであっても失敗します。別の方法では、ディレクトリに対して定期的に証明書失効リスト(CRL) (失効した証明書のリスト)を発行し、認証プロセスの一部としてリストを確認することを含みます。ある組織では、認証のために証明書が提示されるたびに発行CAに直接問い合わせることが望ましい場合もあります。この方法は、リアルタイム・ステータス・チェックと呼ばれることもあります。
証明書によって識別されたエンティティ(エンド・エンティティとも呼ばれます)とCA間の相互作用は、証明書管理の不可欠な部分です。これらの相互作用には、証明書の登録、証明書の取得、証明書の更新、証明書の失効、鍵のバックアップおよびリカバリなどの操作が含まれます。通常CAは、リクエストに応答する前に、エンド・エンティティのアイデンティティを認証できる必要があります。さらに、提供される前に、認可された管理者またはマネージャによって承認される必要のあるリクエストもあります。
前述のとおり、証明書を発行する前にアイデンティティを検証するために使用される方法は、証明書が使用される組織および目的に応じて、CAごとに大きく異なります。運用上の最大の柔軟性を提供するために、エンド・エンティティとの相互作用をCAの他の機能と切り離し、登録局(RA)と呼ばれる別のサービスによって処理することが可能です。
RAは、エンド・エンティティのリクエストを受信し、それらを認証し、それらをCAに転送することで、CAのフロント・エンドとして機能します。CAから応答を受信した後、RAはエンド・エンティティに結果を通知します。RAは、PKIを別の部署、地理的なエリアまたは異なるポリシーおよび認証要件を使用する他の運営単位に拡大する際に役立ちます。
SSLまたはTLS接続時のクライアント認証では、Simple Authentication and Security Layer (SASL)も使用できます。Directory Serverでは、SASLメカニズムをサポートしています。
DIGEST-MD5メカニズムは、クライアントによって送信されたハッシュされた値をユーザーのパスワードのハッシュと比較することによって、クライアントを認証します。ただし、このメカニズムはユーザー・パスワードを読み取る必要があるため、DIGEST-MD5による認証を希望するすべてのユーザーは、ディレクトリ内にクリアテキストのパスワードを持つ必要があります。
GSSAPI は、Solarisオペレーティング・システムのみで使用できます。General Security Services API (GSSAPI)では、ユーザーを識別するためのDirectory ServerによるKerberos V5セキュリティ・システムとの対話が可能です。クライアント・アプリケーションは、Kerberosシステムに資格証明を提示する必要があり、これによって、Directory Serverに対してユーザーのアイデンティティが検証されます。
SASLベースの認証の構成方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の資格証明レベルおよび認証方法の構成に関する説明を参照してください。
Directory Serverがデータを暗号化する方法の詳細は、次の各項を参照してください。
SSLは、暗号化された通信およびオプションとしてDirectory Serverとクライアントの間の認証を提供します。SSLは、LDAPを介して、またはHTTP経由のDSMLで使用できます。SSLは、LDAP上ではデフォルトで有効であり、HTTP経由のDSMLを有効にできます。
サーバー間のセキュアな通信にSSLを使用するように、レプリケーションを構成できます。レプリケーションがSSLを使用するように構成されている場合、サーバーに対して送受信されるデータは、SSLを使用して暗号化されます。
デフォルトでは、Directory Serverでは、異なるポート番号を要求する保護と非保護の同時通信が可能です。保護されていないLDAP通信は、1つのポート(慣例的にポート番号389)上で処理されます。セキュアなLDAP通信は、別のポート(慣例的にポート番号636)上で処理されます。
また、セキュリティ上の理由から、すべての通信をセキュアなポートに限定することもできます。クライアント認証も構成できます。クライアント認証を必要とする、または許可するように設定できます。この設定によって、実行するセキュリティのレベルが決定されます。
SSLによって、通常のLDAP接続をセキュリティ保護するStart TLS拡張処理のサポートも有効になります。クライアントはSSL以外のポートにバインドでき、トランスポート層セキュリティ・プロトコルを使用してSSL接続を開始できます。Start TLS処理では、クライアントに一層の柔軟性が与えられ、ポートの割当ても簡素化できます。
SSLの詳細は、次の各項を参照してください。
TCP/IPは、インターネットを介したデータの転送およびルーティングを制御します。HTTP、LDAP、IMAPなどのその他のプロトコルは、TCP/IPを使用して、Webページの表示やメール・サーバーの運用などの標準のアプリケーション・タスクをサポートします。
SSLプロトコルは、TCP/IPの上、HTTPまたはIMAPといった上位レベルのプロトコルの下で実行されます。上位レベルのプロトコルのかわりにTCP/IPを使用し、プロセスでは、SSL対応のサーバーによるSSL対応のクライアントに対する自身の認証を可能にし、クライアントによるサーバーに対する自身の認証を可能にし、両方のマシンが暗号化接続を確立するのを可能にします。
SSLは、インターネットおよびその他のTCP/IPネットワークを介した通信に関する問題に対処します。
SSL対応のクライアント・ソフトウェアは、公開鍵暗号化の標準的な技術を使用して、サーバーの証明書および公開IDが有効で、クライアントの信頼できるCAのリストにリストされている認証局(CA)で発行されたことを確認できます。たとえば、ユーザーがネットワークを介してクレジット・カード番号を送信する際に受信するサーバーのアイデンティティを確認する場合に、この確認が重要になることがあります。
サーバー認証で使用する同じ技術を使用して、SSL対応のサーバー・ソフトウェアは、クライアントの証明書および公開IDが有効で、サーバーの信頼できるCAのリストにリストされている認証局(CA)で発行されたことを確認できます。たとえば、サーバーが親展の財務情報を顧客に送信する銀行で、受信者のアイデンティティを確認が必要な場合に、この確認が重要になることがあります。
機密保護は、両者にとってすべてのプライベート・トランザクションで重要です。さらに、暗号化SSL接続を使用して送信されるすべてのデータは、改ざんを検出する(送信中にデータが変更されたかどうかを自動的に判断する)ためのメカニズムを使用して保護されます。
SSLプロトコルには、SSLレコード・プロトコルおよびSSLハンドシェイク・プロトコルの2つのプロトコルが含まれます。
SSLレコード・プロトコルは、データの送信に使用される形式を定義します。SSLハンドシェイク・プロトコルでは、SSLレコード・プロトコルを使用して、SSL対応のサーバーとSSL対応のクライアント間で最初にSSL接続が確立されたときに、一連のメッセージを交換することが要求されます。このメッセージの交換は、次のアクションを容易にするために設計されています。
クライアントに対してサーバーを認証します。
クライアントおよびサーバーによる、両方がサポートする暗号化アルゴリズム(暗号)の選択を可能にします。
オプションで、サーバーに対してクライアントを認証します。
公開鍵暗号化技術を使用して共有秘密を生成します。
暗号化されたSSL接続を確立します。
ハンドシェイク・プロセスの詳細は、「SSLハンドシェイク」を参照してください。
暗号スイートは、SSL通信の次の側面を定義します。
キー交換アルゴリズム
暗号化暗号
暗号化暗号の鍵の長さ
メッセージ認証方式
SSLプロトコルでは多数の暗号がサポートされています。クライアントおよびサーバーは、サポートするSSLのバージョン、および許容される暗号化強度に関する会社のポリシーなどの要因によって、様々な暗号スイートをサポートできます。SSLハンドシェイク・プロトコルでは、相互に認証するため、証明書を転送するためおよびセッション・キーを確立するために使用する暗号スイートについて、サーバーとクライアント間での交渉方法を決定します。
SSL 2.0プロトコルおよびSSL 3.0プロトコルでは、暗号スイートの重複設定がサポートされています。管理者は、クライアントとサーバーの両方でサポートされている任意の暗号スイートを有効化または無効化できます。SSLハンドシェイク時にサーバーとクライントで情報を交換する際、共通して持っている有効化されていて最も強力な暗号スイートを特定し、SSLセッションで使用します。有効化する暗号スイートに関する決定は、関係するデータの機密性、暗号の速度およびエクスポート・ルールの適用性に依存します。
KEA、RSAなどのキー交換アルゴリズムは、サーバーおよびクライアントがSSLセッションで使用する対称鍵を決定する方法を制御します。最も一般的に使用されるSSL暗号スイートでは、RSAキー交換が使用されます。
Directory Serverで有効化できる暗号のリスト、およびDirectory Serverでサポートされる暗号のリストは、dsconfコマンドを使用して取得できます。dsconfコマンドを使用した使用可能な暗号のリストおよび暗号の管理の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の暗号化暗号の選択に関する説明を参照してください。
暗号に対するサポートは、ネットワーク・セキュリティ・サービス(NSS)のコンポーネントによって提供されます。NSSの詳細は、NSSのプロジェクト・サイト(http://www.mozilla.org/projects/security/pki/nss/)を参照してください。
SSLプロトコルは、公開鍵および対称鍵暗号化の組合せを使用します。対称鍵暗号化は公開鍵暗号化よりはるかに高速ですが、公開鍵暗号化はより優れた認証技術を提供します。SSLセッションは、常にSSLハンドシェイクと呼ばれるメッセージの交換から開始されます。ハンドシェイクでは、サーバーは、公開鍵技術を使用してクライアントに対して自身を認証でき、その後、クライアントおよびサーバーは、高速暗号化、復号化および改ざん検出に使用される対称鍵を協働して作成できます。ハンドシェイクでは、オプションで、サーバーに対するクライアント自身の認証も可能です。
SSLハンドシェイクの詳細は、次の各項を参照してください。
次の手順では、SSLハンドシェイクでのメッセージ交換の順序を説明します。これらの手順は、SSLハンドシェイクで交換されるメッセージのプログラム的な詳細を説明します。
クライアントは、サーバーに対して、クライアントのSSLバージョン番号、暗号設定、ランダムに生成されたデータおよびサーバーがSSLを使用してクライアントと通信するために必要なその他の情報を送信します。
サーバーは、クライアントに対して、サーバーのSSLバージョン番号、暗号設定、ランダムに生成されたデータおよびクライアントがSSLを使用してサーバーと通信するために必要なその他の情報を送信します。さらにサーバーは、自身の証明書を送信し、クライアント認証が必要なサーバー・リソースをクライアントがリクエストしている場合は、クライアントの証明書をリクエストします。
クライアントは、サーバーによって送信された情報の一部を使用して、サーバーを認証できます。詳細は、「SSLハンドシェイクでのサーバー認証」を参照してください。サーバーが認証できない場合、ユーザーは問題を警告され、暗号化された認証接続が確立できないことが通知されます。サーバーの認証に成功した場合、クライアントは手順4に進みます。
ハンドシェイクでここまでに生成されたすべてのデータを使用して、クライアントは、(サーバーの協力で)使用する暗号に応じて、セッションのプリマスタ・シークレットを作成し、(手順2で送信されたサーバーの証明書から取得した)サーバーの公開鍵を使用してそれを暗号化し、暗号化されたプリマスタ・シークレットをサーバーに送信します。
サーバーがクライアント認証をリクエストしている(ハンドシェイクのオプションの手順)場合、クライアントは、このハンドシェイクに一意で、クライアントとサーバーの両方で認識されている別のデータにも署名します。この場合、クライアントは署名済データおよびクライアント自身の証明書を、暗号化されたプリマスタ・シークレットとともにサーバーに送信します。
サーバーがクライアント認証をリクエストしている場合、サーバーはクライアントの認証を試みます。詳細は、「SSLハンドシェイクでのサーバー認証」を参照してください。クライアントが認証できない場合、セッションは終了します。クライアントの認証に成功すると、サーバーは自身の秘密鍵を使用してプリマスタ・シークレットを復号化し、一連の手順を実行(同じプリマスタ・シークレットから、クライアントも実行)してマスター・シークレットを生成します。
クライアントおよびサーバーの両方は、マスター・シークレットを使用してセッション・キーを生成しますが、これはSSLセッションで情報の暗号化および復号化およびその整合性の検証(SSL接続を介した送信時と受信時の間のデータの変更を検出する)に使用される対称鍵です。
クライントは、今後、クライアントからのメッセージはこのセッション・キーを使用して暗号化されることを通知するメッセージをサーバーに送信します。その後、ハンドシェイクのクライアント部分が終了したことを示す(暗号化された)別のメッセージを送信します。
サーバーは、今後、サーバーからのメッセージはこのセッション・キーを使用して暗号化されることを通知するメッセージをクライアントに送信します。その後、ハンドシェイクのサーバー部分が終了したことを示す(暗号化された)別のメッセージを送信します。
これでSSLハンドシェイクが完了し、SSLセッションが開始されます。クライアントおよびサーバーは、セッション・キーを使用して、相互に送信するデータを暗号化および復号化し、その整合性を検証します。
セッションを継続する前に、クライアントの証明書がLDAPディレクトリのユーザーのエントリに存在することを確認するようにDirectory Serverを構成できます。この確認オプションは、クライアントの証明書が失効していないことを確認するための1つの方法を提供します。
クライアントおよびサーバー認証のどちらも、秘密鍵と公開鍵のペアの片方の鍵を使用してデータの一部を暗号化し、もう片方の鍵を使用してそれを復号化する必要があります。
サーバー認証の場合、クライアントは、サーバーの公開鍵を使用してプリマスタ・シークレットを暗号化します。対応する秘密鍵でのみシークレットを正しく復号化できるため、クライアントは、公開鍵に関連付けられているアイデンティティが、クライアントが実際に接続しているサーバーであることの保証が得られます。それ以外の場合、サーバーはプリマスタ・シークレットを復号化できず、セッションに必要な対称鍵を生成できないため、セッションは終了します。
クライアント認証の場合、クライアントは、クライアントの秘密鍵を使用してランダム・データの一部を暗号化(つまり、デジタル署名を作成)します。クライアントの証明書の公開鍵は、対応する秘密鍵が使用された場合のみデジタル署名を正しく検証できます。それ以外の場合、サーバーはデジタル署名を検証できないため、セッションは終了します。
SSL対応のクライアント・ソフトウェアは、常にサーバー認証、またはサーバーのアイデンティティのクライアントによる暗号化の検証が必要です。サーバーは、自身を認証するために、クライアントに対して証明書を送信します。クライアントは、その証明書を使用して、証明書が表すことを主張するアイデンティティを認証します。
公開鍵と公開鍵を含む証明書によって識別されるサーバー間のバインディングを認証するには、SSL対応のクライアントで、次の図に示す4つの質問に対してはいの回答を受信する必要があります。
SSL対応のクライアントは、サーバーのアイデンティティを認証するために、次の手順を実行します。
今日の日付は有効期限内ですか。
クライアントは、サーバーの証明書の有効期限を確認します。現在の日時がその範囲外の場合は、認証プロセスはこれ以降進みません。現在の日時が証明書の有効期限内の場合は、クライアントは次の手順に進みます。
発行CAは信頼できるCAですか。
SSL対応の各クライアントは、図5-9の右側の網掛け部分で表される信頼できるCA証明書のリストを保持します。このリストで、クライアントが受け入れるサーバーの証明書を判断します。発行CAの識別名(DN)が、信頼できるCAのクライアントのリストにあるCAのDNと一致した場合、この質問に対する回答は「はい」となり、クライアントは次の手順に進みます。発行CAがリストにない場合、クライアントがリストにあるCAで終わる証明書チェーンを検証できないかぎり、サーバーは認証されません。
発行CAの公開鍵は、発行者のデジタル署名を検証しますか。
クライアントは、CAの証明書(手順2の信頼できるCAのリストにある)からの公開鍵を使用して、提示されたサーバー証明書のCAのデジタル署名を検証します。CAによって署名された後にサーバーの証明書の情報が変更された場合またはCA証明書の公開鍵がサーバーの証明書を署名するためにCAによって使用された秘密鍵と一致しない場合は、クライアントはサーバーのアイデンティティを認証しません。CAのデジタル署名が検証できた場合、サーバーは、ユーザーの証明書をそのCAからの有効な「紹介状」として処理し、次に進みます。この時点でクライアントは、サーバーの証明書が有効であると判断します。
サーバーの証明書のドメイン名は、サーバー自身のドメイン名と一致しますか。
この手順は、サーバーの証明書にあるドメイン名によって指定されているものと同じネットワーク・アドレスに、このサーバーが実際に存在していることを確認します。手順4は、厳密にはSSLプロトコルの一部ではありませんが、これは、中間者攻撃と呼ばれるセキュリティ攻撃の一種に対する唯一の保護を提供します。クライアントはこの手順を実行して、ドメイン名が一致しない場合は、サーバーの認証または接続の確立を拒否する必要があります。サーバーの実際のドメイン名がサーバーの証明書のドメイン名と一致した場合、クライアントは次の手順に進みます。
サーバーは認証されました。
クライアントはSSLハンドシェイクを開始します。なんらかの理由でクライアントが手順5に到達しない場合は、証明書で識別されるサーバーは認証されないため、ユーザーは問題を警告され、暗号化された認証接続を確立できないことが通知されます。サーバーでクライアント認証が必要な場合は、サーバーは、「SSLハンドシェイクでのクライアントの認証」に記載されている手順を実行します。
ここに記載されている手順の後、サーバーは、自身の秘密鍵を使用してクライアントから送信されたプリマスタ・シークレットの復号化に成功する必要があります。
中間者攻撃とはローグ・プログラムで、クライアントとサーバー間でクライアントがSSLを介して通信を試行するすべての通信を傍受するプログラムです。ローグ・プログラムは、SSLハンドシェイクで往復して受け渡される正当な鍵を傍受し、自らの鍵で置き換え、自分をクライアントに対してはサーバーであるかのように、サーバーに対してはクライアントであるかのように見せます。
SSLハンドシェイクの最初に交換される暗号化された情報は、クライアントまたはサーバーの本物の鍵ではなく、ローグ・プログラムの公開鍵または秘密鍵を使用して実際に暗号化されます。最終的に、ローグ・プログラムは、本物のサーバーと使用するためのセッション・キーの1つのセットを、クライアントと使用するためのセッション・キーの別のセットを作成します。これによって、ローグ・プログラムは、クライアントと本物のサーバーの間に流れるすべてのデータを読み取れるだけでなく、削除することなくデータを変更できます。したがって、「SSLハンドシェイクでのサーバーの認証」に記載されているその他の手順を実行することで証明書の有効性を確認することに加えて、クライアントが通信を試みるサーバーのドメイン名とサーバーの証明書のドメイン名が一致するかどうかを確認することは、クライアントにとって非常に重要です。
SSL対応のサーバーは、クライアント認証、またはクライアントのアイデンティティのサーバーによる暗号化の検証を必要とするように構成できます。サーバーがこのように構成されているとき、自身を認証するために、クライアント認証のデジタル署名された別のデータをリクエストします。サーバーは、デジタル署名されたデータを使用して証明書内の公開鍵を検証し、証明書が表すことを主張するアイデンティティを認証します。
SSLプロトコルでは、クライアントに対して、ハンドシェイク時にランダムに生成され、クライアントおよびサーバーのみが認識するデータから一方向ハッシュを作成することによってデジタル署名を作成することが要求されます。データのハッシュはその後、サーバーに提示された証明書の公開鍵と対応する秘密鍵を使用して暗号化されます。
公開鍵と公開鍵を含む証明書によって識別される人またはその他のエンティティ間のバインディングを認証するには、SSL対応のサーで、図5-10に示す最初の4つの質問に対してはいの回答を受信する必要があります。5番目の質問はSSLプロトコルの一部ではありませんが、認証プロセスの一部としてLDAPディレクトリのユーザー・エントリを活用するためにこの要件をサポートするように、Directory Serverを構成できます。
SSL対応のサーバーは、ユーザーのアイデンティティを認証するために、次の手順を実行します。
ユーザーの公開鍵は、ユーザーのデジタル署名を検証しますか。
サーバーは、ユーザーのデジタル署名が証明書の公開鍵を使用して検証できることを確認します。できる場合、サーバーは、John Doeに属すと主張される公開鍵が署名を作成するために使用されたこと、およびデータは署名後に改ざんされていないことが証明されます。
ただし、この時点では、公開鍵と証明書で指定されたDN間のバインディングはまだ証明されていません。証明書は、ユーザーになりすますことを試みる誰かによって作成された可能性があります。公開鍵とDN間のバインディングを検証するには、サーバーは、このリストの手順3および4を完了する必要があります。
今日の日付は有効期限内ですか。
サーバーは、クライアントの証明書の有効期限を確認します。現在の日時がその範囲外の場合は、認証プロセスはこれ以降進みません。現在の日時が証明書の有効期限内の場合は、サーバーは次の手順に進みます。
発行CAは信頼できるCAですか。
SSL対応の各サーバーは、図5-10の右側の網掛け部分で表される信頼できるCA証明書のリストを保持します。このリストで、サーバーが受け入れる証明書を判断します。発行CAのDNが、信頼できるCAのサーバーのリストにあるCAのDNと一致した場合、この質問に対する回答は「はい」となり、サーバーは次の手順に進みます。発行CAがリストにない場合、サーバーが、クライアントおよびサーバーで保持されるCA証明書のリストを制御する組織内で信頼できるまたは信頼されないCAで終わる証明書チェーンを検証できないかぎり、クライアントは認証されません。
発行CAの公開鍵は、発行者のデジタル署名を検証しますか。
サーバーは、CAの証明書(前述の手順の信頼できるCAのリストにある)からの公開鍵を使用して、提示された証明書のCAのデジタル署名を検証します。CAによって署名された後に証明書の情報が変更された場合またはCA証明書の公開鍵が証明書を署名するためにCAによって使用された秘密鍵と一致しない場合は、サーバーはユーザーのアイデンティティを認証しません。CAのデジタル署名が検証できた場合、サーバーは、ユーザーの証明書をそのCAからの有効な「紹介状」として処理し、次に進みます。この時点でSSLプロトコルでは、サーバーが、クライアントが認証されたとみなし、手順6の説明に従って接続に進むことを許可します。Directory Serverでは、手順6の前に手順5を実行するようにオプションで構成できます。
LDAPエントリにリストされているユーザーの証明書はそのユーザーのものですか。
このオプションの手順は、ユーザーの証明書が他のすべての手順のテストに合格したとしても、システム管理者がそれを失効させるための1つの方法を提供します。証明書管理システムは、失効した証明書をLDAPディレクトリのユーザーのエントリから自動的に削除できます。この手順を実行するように設定されているすべてのサーバーは、次にその証明書の認証または接続の確立を拒否します。ディレクトリ内のユーザーの証明書とSSLハンドシェイク時に提示されたユーザーの証明書が同じ場合は、サーバーは次の手順に進みます。
認証されたクライアントは、リクエストされたリソースに対するアクセスが許可されていますか。
サーバーは、サーバーのアクセス制御リスト(ACL)に基づいて、クライアントがアクセスを許可されているリソースを確認し、適切なアクセスで接続を確立します。なんらかの理由でサーバーが手順6に到達しない場合は、証明書で識別されるユーザーを認証できないため、そのユーザーは、認証が必要なすべてのサーバー・リソースへのアクセスが許可されません。
デジタル署名は、Directory Serverによって情報の整合性を保つために使用できます。送信される情報に暗号化およびメッセージ・ダイジェストが適用されている場合、受信者は、その情報が送信中に改ざんされていないと判断できます。
改ざん検出および関連する認証技術は、一方向ハッシュという数学関数に依存します。この関数は、メッセージ・ダイジェストとも呼ばれます。一方向ハッシュは、次の特性を持つ固定長の数字です。
ハッシュの値はそのハッシュ・データに対して一意です。1文字の削除または変更でもデータを変更すると、異なる値になります。
事実上、ハッシュ・データの内容はハッシュからは予測できないため、一方向と呼ばれます。
暗号化に秘密鍵を使用し、復号化に公開鍵を使用することは可能です。これは機密情報を暗号化する際には望ましくありませんが、あらゆるデータをデジタル署名する場合の重要な部分です。データ自体を暗号化するかわりに、署名ソフトウェアでは、データの一方向ハッシュを作成し、秘密鍵を使用してそのハッシュを暗号化します。ハッシュ・アルゴリズムなどのその他の情報とともに暗号化されたハッシュは、デジタル署名と呼ばれます。図5-11に、署名されたあるデータの受信者に転送される2つのアイテムを示します。
図5-11では、元のデータおよびデジタル署名は、基本的に署名者の秘密鍵を使用して暗号化された(元のデータの)一方向ハッシュです。そのデータの整合性を検証するには、受信ソフトウェアは、最初に署名者の公開鍵を使用してハッシュを復号化します。次に、元のハッシュを生成したものと同じハッシュ・アルゴリズムを使用して、同じデータの新しい一方向ハッシュを生成します。(この図には記されていませんが、使用されたハッシュ・アルゴリズムに関する情報は、デジタル署名とともに送信されています。)最後に、受信ソフトウェアは、新しいハッシュと元のハッシュを比較します。2つのハッシュが一致した場合、データは署名されてから変更されていません。それらが一致しない場合、データは署名後に改ざんされたか、署名者によって提示された公開鍵と一致しない秘密鍵を使用して署名が作成された可能性があります。
2つのハッシュが一致した場合、受信者は、デジタル署名の復号化に使用した公開鍵が、デジタル署名の作成に使用された秘密鍵と対応することを確信できます。ただし、署名者のアイデンティティを確認するには、その公開鍵が本当に特定の人または他のエンティティに属していることを確認するなんらかの方法が必要です。
デジタル署名の重要性は、手書きの署名の重要性に相当します。一度あるデータに署名したら、秘密鍵が危険にさらされることがなく、所有者が制御できている場合は、後でそのことを否定することは困難です。デジタル署名のこの性質によって高度の非拒否が提供されますが、つまり、デジタル署名は、署名者がデータに署名したことを否定するのを困難にします。場合によっては、デジタル署名は、手書きの署名と同程度の法的拘束力がある場合があります。
最近の暗号化では、暗号化された情報の秘密を保つ機能は、暗号化アルゴリズムに基づいているのではなく、これは広く知られていることですが、鍵に基づいています。鍵は、暗号化された結果を作成する、または暗号化済の情報を復号化するためにアルゴリズムとともに使用する必要のある数字です。鍵を使用した暗号化および復号化の詳細は、次の各項を参照してください。
対称鍵暗号化では、暗号化鍵は復号化鍵から計算でき、その逆も同様です。最も対称なアルゴリズムでは、暗号化と復号化の両方に同じ鍵が使用されます。次の図に、対称鍵暗号化を示します。
対称鍵暗号化の実装は非常に効率がよいため、ユーザーは、暗号化および複合化による大幅な遅延時間を経験しません。対称鍵暗号化では、1つの対称鍵で暗号化された情報は他の対称鍵では復号化できないため、認証度も提供されます。したがって、通信を暗号化するために対称鍵を使用した2つのパーティによって対称鍵の秘密が保持されるかぎり、復号化されたメッセージのつじつまが合っている間は、それぞれのパーティはもう一方と通信していることを確認できます。
対称鍵暗号化は、関係する2つのパーティによって対称鍵の秘密が保持される場合にかぎり、効果的です。他の誰かが鍵を見つけた場合は、機密保護と認証の両方に影響があります。認可されていない対称鍵を持った人は、その鍵を使用して送信されたメッセージを復号化できるだけでなく、新しいメッセージを暗号化し、本来その鍵を使用していた2つのパーティのうちのどちらかからのふりをしてメッセージを送信できます。
対称鍵暗号化は、認証、改ざん検出およびTCP/IPネットワークを経由した暗号化で広く使用されるSSLプロトコルで重要な役割を果たします。また、SSLは、次の項で説明する公開鍵暗号化の技術も使用します。
最も一般的に試用される公開鍵暗号化の実装は、RSA Data Security社が特許権を所有するアルゴリズムを基にしています。そのため、この項では公開鍵暗号化に対するRSAの方法について説明します。
公開鍵暗号化(非対称暗号化)には、電子的なアイデンティティの認証や、データの署名または暗号化が必要なエンティティに関連付けられている公開鍵および秘密鍵の鍵のペアを必要とします。各公開鍵は公開し、対応する秘密鍵は秘密にしておきます。次の図に、公開鍵が機能する仕組みを簡略化した図を示します。
公開鍵暗号化では、公開鍵を配布し、あなただけがこの鍵で暗号化されたデータを読み取ることができます。一般に、暗号化されたデータを誰かに送信するには、その人の公開鍵を使用してデータを暗号化し、その暗号化されたデータを受け取る人が対応する秘密鍵でそれを復号化します。
対称鍵暗号化と比較して、公開鍵暗号化にはより多くの計算が必要なため、必ずしも大量のデータに適しているとはいえません。ただし、対称鍵を送信するために公開鍵暗号化を使用することは可能であり、つまり、その他のデータの暗号化に使用できます。これがSSLプロトコルで使用される方法です。
さらに、あなたの秘密鍵を使用して暗号化されたデータはあなたの公開鍵でのみ復号化できるという、図5-13に示されているスキームの逆も機能します。ただし、公開が示すとおり、あなたの公開鍵を持つ誰でもがそのデータを復号化できることを意味するため、これは機密データを暗号化するには望ましい方法ではありません。そうだとしても、秘密鍵を使用して、電子商取引およびその他の暗号化の商用アプリケーションの重要な要件であるデジタル署名でデータに署名できることを意味するため、秘密鍵は役立ちます。クライアント・ソフトウェアは、あなたの公開鍵を使用して、メッセージが秘密鍵で署名され、署名後に改ざんされていないことを確認できます。デジタル署名およびその後の各項では、この確認プロセスの機能する方法について説明します。
暗号化の強度は、鍵の発見の難しさに関係し、これは、使用する暗号と鍵の強度に依存します。たとえば、公開鍵に最も一般的に使用されるRSA暗号の鍵の発見の難しさは、大きい数の因数分解(周知の数学の問題)の難しさに依存します。
暗号化の強度は、多くの場合、暗号化の実行に使用される鍵のサイズの観点から説明されますが、一般に、鍵が長いほど強い暗号化が提供されます。鍵の長さはビットで測定されます。たとえば、SSLでサポートされるRC4対称鍵暗号で使用される128ビットの鍵では、同じ暗号を使用する40ビットの鍵よりかなり優れた暗号保護が提供されます。おおまかにいうと、128ビットのRC4暗号には、40ビットのRC4暗号よりも3×1026倍の強度があります。
同じレベルの暗号化強度を得るためには、それぞれの暗号に異なる鍵の長さが必要になる場合があります。たとえば、公開鍵暗号化で使用されるRSA暗号は、それが基にしている数学の問題の性質により、指定された長さの鍵で可能なすべての値のサブセットのみが使用できます。対称鍵暗号化などに使用されるその他の暗号では、値のサブセットではなく、指定された長さの鍵で可能なすべての値を使用できます。このため、対称鍵暗号化暗号で使用される128ビットの鍵は、RSA公開鍵暗号化暗号で使用される128ビットの鍵よりも強度のある暗号が提供されます。この違いによって、RSA公開鍵暗号化暗号は、暗号の強度があると判断されるためには512ビット(またはそれ以上)の鍵を使用する必要があるのに対して、対称鍵暗号がほぼ同じレベルの強度を得るために64ビットの鍵を使用することの説明がつきます。このレベルの強度も、近い将来、攻撃に対して脆弱となる可能性があります。
属性の暗号化では、エントリの機密属性を暗号化形式で格納することが可能です。機密属性を暗号化することで、データベース・ファイル、バックアップ・ファイルまたはエクスポートされたLDIFファイルにデータが格納されている間や、データがエクスポートされている間に、属性が読み取られないようにできます。図5-14に、salary属性を暗号化するように属性の暗号化が構成されているデータベースに追加されるユーザー・エントリを示します。
属性の暗号化機能では、広範な暗号化アルゴリズムおよび様々なプラットフォームがサポートされます。属性の暗号化では、サーバーのSSL証明書の秘密鍵を使用して独自の鍵を生成します。この鍵はその後、暗号化および復号化操作を実行するために使用されます。
属性の暗号化は、サフィックス・レベルで構成されます。これは、サフィックスに表示されるすべてのエントリに対して属性が暗号化されることを意味します。ディレクトリ全体で属性を暗号化するには、すべてのサフィックスでその属性の暗号化を有効にする必要があります。
一部のエントリがネーミング属性として使用する属性を暗号化する場合、DNに表示される値は暗号化されませんが、そのエントリに格納される値は暗号化されます。
userPassword属性を暗号化すると、DIGEST-MD5 SASL認証のように、パスワードがクリア・テキストで格納される必要がある場合を除いて、セキュリティの利点は提供されません。パスワード・ポリシーに定義されている暗号化メカニズムがすでにパスワードにある場合は、それをさらに暗号化してもセキュリティの強化にはなりません。
暗号化された属性が格納されている場合、使用された暗号化アルゴリズムを示す暗号タグが最初に付けられます。DES暗号化アルゴリズムを使用して暗号化された属性は、次のように表示されます。
{CKM_DES_CBC}3hakc&jla+=snda%
属性の暗号化によってデータ・セキュリティが強化される一方で、この機能はパフォーマンスに影響を与えます。暗号化が必要な属性について注意深く検討し、特に機密にする必要がある属性のみを暗号化します。機密データは索引ファイルから直接アクセスできるため、暗号化された属性に対応する索引キーは、属性が完全に保護されるように暗号化する必要があります。
属性を暗号化する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の属性値の暗号化に関する説明を参照してください。
