test

Sun N1 Service Provisioning System 5.1 インストールガイド

N1 Service Provisioning System 5.1 での SSL サポートの概要

SSL は、IP ネットワーク上の通信を保護するためのプロトコルです。SSL は、TCP/IP ソケット技術を使用してクライアントとサーバー間のメッセージ交換を行い、RSA が開発した公開 / 非公開鍵ペア暗号化システムを使用してそのメッセージを保護します。SSL は、ほとんどの Web サーバー製品でサポートされるほか、Netscape Navigator ブラウザと Microsoft Web ブラウザでもサポートされます。

メッセージの傍受や改ざんを防止するため、ネットワーク通信に SSL を使用するように N1 Service Provisioning System 5.1 アプリケーションを構成できます。また、通信前に SSL を使用して認証を行うようにアプリケーションを構成すれば、ネットワークセキュリティーがさらに高まります。

暗号群: 暗号化と認証の概要

サーバーとクライアント間の相互認証、証明書の送信、セッション鍵の確立などのために、SSL プロトコルでは各種の暗号アルゴリズム (暗号方式) がサポートされます。認証が行われるかどうかは、SSL が接続に使用する暗号群によって決まります。

暗号群は慎重に選択する必要があります。各アプリケーションの設定では、ノードが要求する最小限のセキュリティーを提供する暗号群だけを有効にしてください。SSL は、クライアントとサーバーの双方がサポートする暗号群の中からもっともセキュリティーレベルの高い暗号群を使用します。低セキュリティーの暗号群を有効にすると、Sun 以外のクライアントは暗号群のネゴシエーションの際にセキュリティーレベルがもっとも低い暗号群しかサポートしなくなり、サーバーはセキュリティーレベルが比較的低い暗号群の使用を余儀なくされる可能性があります。

SSL は、次のモードで動作します。

インストール時にアプリケーション間の通信を保護する手段として SSL を選択すると、使用する暗号群の選択を求めるメッセージが表示されます。暗号群の値は、net.ssl.cipher.suites の値として config.properties ファイルに格納されます。暗号群の値は、選択に応じて次のように設定できます。

AIX サーバー上のローカルディストリビュータで SSL を使用する場合、SSL 暗号群は認証による暗号化に設定されます。認証を伴わない暗号化は、AIX サーバーで稼働しているローカルディストリビュータでは利用できません。

サーバー認証を必要とする SSL 暗号群とサーバー認証を必要としない SSL 暗号群の一覧は、「SSL 暗号群」を参照してください。クライアント認証は、サーバー認証を必要とする暗号群だけを対象に構成することもできます。

注 –

N1 Service Provisioning System 5.1 アプリケーションの SSL 構成は、認証を伴わない暗号化と認証を伴う暗号化のどちらも行えます。認証を伴う暗号化では、クライアントとサーバーの認証が行われます。前述のような構成が可能ですが、認証を伴う暗号化がもっとも安全です。

認証キーストア

N1 Service Provisioning System 5.1 は、自己署名付き証明書と認証局によって署名される証明書をサポートします。次の 2 種類のキーストアがあります。

「クライアントとサーバーの相互認証」で SSL を有効にした場合は、有効にした各アプリケーションに、SSL が使用する 2 つのキーストアを構成する必要があります。その 1 つは、SSL がほかのアプリケーションに対しそれ自体を認証するためのキーストアで、もう 1 つはほかのアプリケーションを認証するためのキーストアです。

「サーバーのみの認証」で SSL を有効にした場合は、SSL サーバーとして機能するアプリケーションにはプライベートキーストア、SSL クライアントとして機能するアプリケーションには公開 (トラステッド) キーストアが必要になります。公開キーストアは、Java Secure Sockets Extension (JSSE) v1.0.3 によって提供されている独自の JKS フォーマットになります。

これらのキーストアは、どちらもパスワードを指定する必要があります。このパスワードは、両キーストアで同一のものでなければなりません。

例として、アプリケーション A (SSL クライアント) とアプリケーション B (SSL サーバー) を SSL を使用して相互接続する場合を考えてみましょう。両方とも、サーバー認証を要求する暗号群を使用するように構成されています。アプリケーション B は、そのプライベートキーストアに公開 / 非公開鍵ペアが格納されていなければなりません。一方アプリケーション A は、そのトラストキーストアにアプリケーション B の公開鍵が格納されていなければなりません。アプリケーション A がアプリケーション B への接続を試みると、アプリケーション B はアプリケーション A に公開鍵を送信します。アプリケーション A は、トラストキーストア内にこの公開鍵が入っているかを確認することによってこの鍵を検証できます。

クライアント認証を要求するようにアプリケーション B が構成されている場合、アプリケーション A のプライベートキーストアには公開 / 非公開鍵ペアが格納されていなければなりません。同時に、アプリケーション B のトラストキーストアにはアプリケーション A の公開鍵が格納されている必要があります。アプリケーション A がアプリケーション B の認証を行なったあと、アプリケーション B はそのトラストキーストアに鍵が入っているかを確認することによってアプリケーション A の公開鍵を検証できます。

crkeys コマンドを使用してキーストアを生成する場合は、-mode upstream|downstream オプションを使用して、認証を実行しているマシンとの関係上での認証されているマシンの場所を指定します。SSL 接続の試行時には、接続の妥当性検査を行うサーバーが、証明書を送信したサーバーの相対的な位置に一致するモードが受信した証明書に含まれていることを確認します。たとえば、ローカルディストリビュータがマスターサーバーから SSL 接続要求を受信するとします。ローカルディストリビュータは、マスターサーバー証明書に downstream 注釈が含まれていないことを確認します。

注 –

サーバーは、証明書に upstream 注釈が含まれているかは確認しません。サーバーが確認するのは、証明書に downstream 注釈が含まれていないことだけです。この結果、元々 upstream 注釈なしの SSL を使用するように構成されていたサーバーはいずれも、引き続き SSL を接続に使用します。

CLI クライアントからアップストリームになれるサーバーはないため、CLI クライアントは、upstream 注釈のある証明書を転送するサーバーとの接続の妥当性を証明できません。リモートエージェントからダウンストリームになれるサーバーはないため、リモートエージェントは、downstream 注釈のある証明書を転送するサーバーとの接続の妥当性を証明できません。

SSL でのパスワードの使用

トラストキーストアの処理にパスワードを指定した場合、このパスワードはキーストアの整合性の検査にだけ使用されます。このパスワードはトラストキーストアのコンテンツに対するアクセスは防止しませんが、トラストキーストアの更新は防止します。ユーザーは、パスワードを指定しなければキーストアの内容を変更することはできません。

プライベートキーストアの処理にパスワードを指定した場合、このパスワードは、キーストアの整合性の検査、キーストアの内容の更新の禁止、非公開鍵のアクセスの暗号化と保護に使用されます。

crkeys コマンドは、両方のキーストアに同一のパスワードが指定されているかどうかの確認に使用されます。証明書をインポートして初めてトラストストアを作成するときに、プライベートストア内にパスワードが存在すると、これと同じパスワードが crkeys スクリプトによってトラストストアに設定されます。 同様に、初めてプライベートストアを作成するときに、トラストストア内にパスワードが存在すると、これと同じパスワードが crkeys スクリプトによってプライベートストアに設定されます。

crkeys コマンドを使用すると、符号化されたキーストアパスワードを作成できます。符号化されたパスワードは、キーストアパスワードを保存するどのプロパティファイルでも使用できます。安全性は、プロパティファイルに符号化されたパスワードを保存するほうが、プロパティファイルにプレーンテキストのパスワードを保存するより優れています。

N1 Service Provisioning System 5.1 における SSL の制限

N1 Service Provisioning System 5.1 の SSL 実装には、次のような制限があります。