レベル: 初級 WebSphereテクニカル・セールス, , IBM
2004年 9月 20日 第2回「さらに知りたいセキュリティー（SSL）の仕組み」
前回はWebアプリケーション（eコマース）における危険性をとりあげて、その対処法をご紹介しました。もう一度、簡単に前回の内容を纏めておきたいと思います。
Webアプリケーション（eコマース）において必ず考慮すべきリスクが3つありました。それは「盗聴」、「改ざん」、「なりすまし」のリスクです。そして、それぞれのリスク対処方法として「盗聴には暗号化」、「改ざんにはメッセージ・ダイジェスト」、「なりすましには電子署名と電子証明書」を使用するということでしたね。
今回はこれらの仕組みを使って実現しているSSL通信について解説していきますが、その前に、電子証明書の中身についてさらに探っていきたいと思います。
認証局が保証する電子証明書
SSL通信を実現するためには、必ず電子証明書が必要になります。先に触れましたように、電子証明書とは認証局が発行する暗号文書で、Webサーバーの公開鍵は認証局の秘密鍵で暗号化されています。認証局が証明書を発行するということは、発行先である利用者（Webサーバー）の身元を認証局が確認したということです。ただし、気を付けていただきたいこととして、電子証明書は発行先の利用者（Webサーバー）の存在を認証局が証明しているだけで、信用できるWebサーバーであるかどうかを証明しているのではありません。
図：電子証明書のしくみ
拡大図
（348KB）
それでは、実際に電子証明書がどのように使われているのかを説明していきます。
まず、認証局で発行された電子証明書をWebサーバーに配置し、WebクライアントからSSL通信での要求があった場合に、この電子証明書を提示します。通常、Webクライアントは受け取った電子証明書が有効であるかを検証するために、電子証明書に記載されている発行者（認証局）の名前からその認証局にアクセスして、認証局の公開鍵を取得します。そして、取得したこの公開鍵を使用して、電子証明書の中に埋め込まれているWebサーバーの公開鍵を復号化して取得します。
しかし、通常のWebクライアントのブラウザには、一般的によく利用されている認証局の公開鍵があらかじめインストールされています。Internet Explorerの場合、メニューの「ツール」から「インターネットオプション」を選択して、「コンテンツ」タブを選択し、「証明書」ボタンをクリックします。証明書ウィンドウが開きますので、「信頼されたルート証明機関」タブをクリックすると、インストールされている認証局の公開鍵一覧が表示されます（実際には公開鍵が埋め込まれている電子証明書です）。
図：Internet Explorerにインストールされた認証局の公開鍵一覧
そのため、一般的な証明機関で電子証明書を作成していれば、Webクライアントは公開鍵を取得するためにわざわざ認証局にアクセスすることはありません。
認証構造
また、証明書ウィンドウの中に「中間証明機関」というタブがあることにお気づきでしょうか。
図：Internet Explorerにインストールされた中間証明機関
中間証明機関を説明するには、認証局や電子証明書がどのような仕組みで認証されているのかを示す認証構造について解説する必要があります。
まず、認証構造には大きく分けて「階層型」と「メッシュ型」がありますが、当記事は最も一般的に利用されている「階層型」構造のみを取り上げたいと思います。
図：階層型の認証構造
拡大図
（192KB）
階層構造を持つ認証局の公開鍵自身も、実は証明書によって配布されています。認証局の公開鍵についての証明書と公開鍵自身は、その認証局の上位にあたる証明機関によって作成され証明されています。そして、その認証局の証明書と公開鍵も、さらに上位の証明機関によって作成されているといった階層構造になっています。このような階層構造の一番頂点に立つ認証局が、先に触れました「ルート証明機関」に当たり、その配下の証明機関「中間証明機関」が配置され、最下位に「証明書保持者」が位置します。
左記のような階層型の認証構造は、Webサーバー側で保持している証明書自身には問題（有効期限切れ等）が無くても、その上位の証明書に問題があれば、ルート証明機関の公開鍵を取得することが不可能な為、認証構造が崩れ、証明書の機能を果たしません。
したがって、ルート証明機関まで一貫して有効な電子証明書が必要になります。
図：3階層型の認証構造を持つ証明書
SSL（Secure Sokets Layer）とは？
図：SSL通信の仕組み
拡大図
（500KB）
ようやく、当記事の最終目的であるSSL通信について説明したいと思います。
SSLとは、米国Netscape Communications社が開発したHTTP用のセキュア・プロトコルで、WebクライアントとWebサーバー間の通信における認証と暗号化を実現します。その仕組みは公開鍵暗号化方式を基にしており、電子証明書を使った安全なデータの送受信を行います。
さらにSSL通信の仕組みを詳しく解説していきますが、第1回「セキュリティー対策を考える」で説明しました公開鍵暗号化方式と電子署名、それに電子証明書の仕組みをご理解頂けているのであれば、これらの単純な組み合わせで実現しているアーキテクチャーであるため、すぐにご理解いただけるかと思います。
例えばSSL通信を使用して、Webクライアント（購買者）がWebサーバー（eコマース・サイト）から商品を購入すると考えた場合のアクセス手順は次のようになります。
- Webクライアント（購買者）がSSLでのアクセスをサーバーに要求します。
- Webサーバー（eコマース・サイト）は、電子証明書をWebクライアント（購買者）に送信します。電子証明書は、認証局の秘密鍵で暗号化されており、Webサーバー（eコマース・サイト）の公開鍵を含みます。
- Webクライアント（購買者）は、受け取った電子証明書から、その中に登録されている認証局にアクセスして認証局の公開鍵を入手します。Webブラウザに認証局の公開鍵がインストールされているのであれば、認証局にアクセスすることはありません。
- Webクライアント（購買者）は、入手した認証局の公開鍵を使用して、電子証明書を復号化し、Webサーバー（eコマース・サイト）の公開鍵を入手します。
- Webクライアント（購買者）は一時的な共通鍵を生成して、それを取得したWebサーバー（eコマース・サイト）の公開鍵で暗号化して、Webサーバー（eコマース・サイト）に送信します。
- Webサーバー（eコマース・サイト）は、Webクライアント（購買者）から暗号化された共通鍵を受け取り、Webサーバー（eコマース・サイト）が持っている自分の秘密鍵で復号化して共通鍵を入手します。共通鍵暗号化方式は公開鍵暗号化方式よりも処理速度が速いというメリットを持つため、データ通信は共通鍵を使用して暗号化されています。
- ここから同じ共通鍵を使用して、Webクライアント（購買者）とWebサーバー（eコマース・サイト）との暗号化通信が開始されます。Webサーバー（eコマース・サイト）は復号化したデータとダイジェストを確認することで、間違いなくWebクライアント（購買者）からの送信データであるということと、改ざんの有無が判定でき、確実に注文データを受け取ることが出来ます。
上記アクセス手順の中で、少し補足をしておきます。
SSL通信を使ってアクセスするURLは「https://〜」となっていることはご存知だと思います。電子証明書を発行した認証局がWebブラウザーにインポートされていれば、自動的にサーバーとクライアント間でSSL通信が開始されます。SSL通信が開始されていればアドレスがhttpsから始まり、Internet Explorerの場合、右下に鍵のマークが表示され、鍵マークをダブルクリックすると証明書情報が確認できます。
図：SSL通信が開始されているInternet Explorerの画面
Webブラウザーにインポートされていない電子証明書を受け取った場合は、下図のようなセキュリティー警告が表示されます。「今からSSL通信を開始しますが、この証明機関を信用しますか？」といった警告を出しています。ここで、「はい」を選択すると自動的にSSL通信が開始されてしまいますが、この連載を読まれた方は「はい」を選択する前に、可能な限り「証明書の表示」を選択して証明書情報を確認して下さい。もしかしたら、Webサーバーのなりすましが潜んでいるかもしれないからですね（証明書はWebサーバーの信頼度までは証明しません）。
図：セキュリティー警告の画面
最後に
今回は電子証明書とSSLに関する話をしましたが、ご理解頂けたでしょうか。
この連載の目的である、信頼されるWebアプリケーション構築のために、実装すべきセキュリティーの1つとしてSSLの仕組みについてご説明しました。
一般的によく利用されるSSL通信は、Webサーバー側に証明書を持っていて、Webクライアント側には持っていない片側認証型が採られています。さらに高度な認証方式として、Webクライアント側にも証明書を持たせ、Webサーバー側でもクライアントの認証をクライアント証明書で行うことが出来る相互認証型もあります。こうすることで、WebクライアントとWebサーバーはお互いを認証することが出来るようになり、認証の精度が高まります。少し複雑な構成になりますが、証明書とSSLの仕組みを理解していれば、容易に構築できるはずです。
SSL通信が可能な領域は、WebブラウザーとWebサーバー間の暗号化通信の他に、WebSphere Application Server（WAS）ではWebサーバー（厳密にはWebサーバー・プラグイン）とWebアプリケーション・サーバー（WAS）間の通信にもSSLを使用することが出来ます。
SSLの設定手順については、この記事の掲載元であるWebSphere Developer DomainのWebSphereテクニカル・フラッシュやテクニカル情報に記載されているため、当記事では触れませんでした。あくまでも、セキュリティーの仕組みをご理解頂けるように努めてまいりました。
私事で大変申し訳ございませんが、仕事上この連載記事から離れることとなってしまい、この記事で終了とさせていただきます。連載講座と題しながら2回の執筆で終了してしまうことを深くお詫びいたします。
また、ここまで読んで頂いた皆様、本当に有難うございました。
参考文献
著者について  | | | WebSphereテクニカル・セールス,IBM |
記事の評価
| 
