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 ファイルに格納されます。暗号群の値は、選択に応じて次のように設定できます。
「暗号化のみ (認証なし)」を選択した場合、暗号群は SSL_DH_anon_WITH_3DES_EDE_CBC_SHA に設定されます。
「暗号化 (認証あり)」を選択した場合、暗号群は SSL_RSA_WITH_3DES_EDE_CBC_SHA に設定されます。
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 注釈のある証明書を転送するサーバーとの接続の妥当性を証明できません。
トラストキーストアの処理にパスワードを指定した場合、このパスワードはキーストアの整合性の検査にだけ使用されます。このパスワードはトラストキーストアのコンテンツに対するアクセスは防止しませんが、トラストキーストアの更新は防止します。ユーザーは、パスワードを指定しなければキーストアの内容を変更することはできません。
プライベートキーストアの処理にパスワードを指定した場合、このパスワードは、キーストアの整合性の検査、キーストアの内容の更新の禁止、非公開鍵のアクセスの暗号化と保護に使用されます。
crkeys コマンドは、両方のキーストアに同一のパスワードが指定されているかどうかの確認に使用されます。証明書をインポートして初めてトラストストアを作成するときに、プライベートストア内にパスワードが存在すると、これと同じパスワードが crkeys スクリプトによってトラストストアに設定されます。 同様に、初めてプライベートストアを作成するときに、トラストストア内にパスワードが存在すると、これと同じパスワードが crkeys スクリプトによってプライベートストアに設定されます。
crkeys コマンドを使用すると、符号化されたキーストアパスワードを作成できます。符号化されたパスワードは、キーストアパスワードを保存するどのプロパティファイルでも使用できます。安全性は、プロパティファイルに符号化されたパスワードを保存するほうが、プロパティファイルにプレーンテキストのパスワードを保存するより優れています。
N1 Service Provisioning System 5.1 の SSL 実装には、次のような制限があります。
トラストキーストアとプライベートキーストアには同じパスワードを設定する必要があります。また、プライベートキーストア内において、ストア内の各キーのパスワードはストアパスワードと同じでなければなりません。この制限は、キーの作成に使用された crkeys スクリプトによって適用されます。
CLI Client アプリケーションのクライアント認証を有効に設定することはできますが、セキュリティーの制限上この設定はサポートされません。CLI Client アプリケーションは、キーストアパスワードの入力を求めるプロンプトを表示しません。キーストアが作成されている場合は、符号化パスワードを CLI Client プロパティファイルに指定する必要があります。
N1 Service Provisioning System 5.1 は、接続する側と接続される側で同一のトラストキーストアを使用します。このため、たとえばマスターサーバーがリモートエージェントに接続し、その公開鍵を信頼するとします。リモートエージェントが危険にさらされた場合、CLI Client がクライアント認証を使用するように設定されていれば、リモートエージェントの鍵を使用して、マスターサーバーに対して CLI Client の認証を行えます。同様に、ローカルディストリビュータがリモートエージェントに接続し、リモートエージェントが危険にさらされた場合、ローカルディストリビュータを使用してマスターサーバーにコマンドを発行できます。
このような問題からマスターサーバーとローカルディストリビュータを保護するには、それらに接続を認められているサーバーからの接続だけを受け入れるようにアプリケーションを設定します。ローカルディストリビュータは、その親ノードからの接続だけを受け入れるようにし、マスターサーバーは指定されている CLI ホストからの接続だけを受け入れるようにします。手順については、第 9 章「Java 仮想マシンのセキュリティーポリシーの構成」を参照してください。
SSH 接続の場合、リモートアプリケーション (ローカルディストリビュータまたはリモートエージェント) は自動的に起動します。これらのアプリケーションを起動するキーストアパスワードの入力プロンプトは表示されません。ただし、アプリケーションがキーストアを使用して初期化されている場合は、キーストアの符号化されたパスワードをプロパティファイルに指定する必要があります。
SSH を使ってマスターサーバーに接続するように CLI Client を構成した場合、CLI Client は、ソケット経由でマスターサーバーに接続する SshProxy アプリケーションを利用してマスターサーバーに接続します。SshProxy は SSL 経由でマスターサーバーに接続できますが、この構成はサポートされていません。
Windows アプリケーションの場合、符号化されたキーストアパスワードをプロパティファイルで指定する必要があります。