SSLによる安全なWebサイト作り：ApacheによるWebサーバ構築（12）（1/2 ページ）

アクセス制限をもってしても、盗聴や改ざんには対応できない。通信経路をセキュアにしなければならない。今回は、SSLを用いてより信頼性の高いWebサイトを構築する方法を紹介する。

[一志達也，TIS株式会社]

　IP認証、ユーザー認証、データベース認証と、Webコンテンツの閲覧を制限する方法を順に紹介してきた。しかし、盗聴や改ざんには対応できない。従って、悪意を持った第三者が、個人情報や機密情報を盗聴するかもしれない。ちょっと探せば、ネットワークの通信を盗聴するためのツールが無料で公開されているのが現実だからだ。

　盗聴や改ざんから身を守るには、通信信号を暗号化するのが最も簡単かつ確実な方法である。Web、すなわちHTTPの通信の暗号化には、SSL（Secure Socket Layer）を用いるのが一般的だ。なお、ApacheへのSSLの組み込み方法については連載第4回の「ApacheのSSL対応化と環境設定」を参照していただきたい。

SSLの仕組み

　SSLの仕組みは、本サイトでいくつか紹介されている。詳しくはそれらを参照していただくとして、ここでは簡単な説明にとどめる。

公開鍵、秘密鍵、共通鍵

　SSLによる暗号化には、公開鍵（Public Key）と秘密鍵（Private Key）、それに共通鍵が欠かせない。共通鍵は、いわゆる「扉の鍵」をイメージすればよい。つまり、暗号化と復号に共通の鍵を使うのである。

　ところが、公開鍵と秘密鍵には、このイメージが通用しない。なぜなら、暗号化用の鍵と復号用の鍵が異なるのである。公開鍵で暗号化されたものは秘密鍵でしか復号できず、秘密鍵で暗号化されたものは公開鍵でしか復号できない。これが公開鍵と秘密鍵のポイントである。

　公開鍵と秘密鍵はセットで作成されていて、その組み合わせでないと暗号化／復号できない。また、公開鍵がその名のとおりだれでも入手できるのに対し、秘密鍵は自分だけが持っておく秘密の鍵となる。

　以上をまとめると、

• 公開鍵はだれでも入手できる
• 公開鍵は秘密鍵で暗号化されたものしか復号できない
• 秘密鍵は自分だけが持っている
• 秘密鍵は公開鍵で暗号化されたものしか復号できない

となる。最初は戸惑うかもしれないが、これを押さえることが現代の暗号化技術を理解する第一歩となる。

秘密鍵／公開鍵の弱点

　秘密鍵と公開鍵の仕組みを使えば、暗号化は完ぺきであるように思える。しかし、ぱっと思い付くだけでも、この方式には2つの弱点がある。

　1つは、個人用の秘密鍵を一般ユーザーに作成させることの難しさだ。例えば、個人情報を送受信する商用サイトの場合、サーバから送信する情報には問題ない。サーバ側は、唯一の秘密鍵で暗号化し、信頼できる相手であることを証明する手段があるからだ。

　しかし、サーバに情報を送信する個人の側はそうもいかない。公開鍵で暗号化することはできるが、それはだれにでもできることである。通信の途中で、悪意のある第三者が割り込んで公開鍵で暗号化した情報をサーバに送信する可能性もある。こうなると、サーバは自分の通信相手を特定できないことになる。公開鍵と秘密鍵を使った暗号化は、通信する双方が秘密鍵を持っている必要性がある。個人にも秘密鍵を作成してもらえばいいのだが、それはだれにでもできることではない。

　もう1つは、暗号化と復号に要する負荷の問題である。公開鍵と秘密鍵を使った暗号化は、思いのほかコンピュータに負荷が掛かる。大多数のアクセスを受けるサイトともなれば相当な負担となる。こうした負荷を軽減するために、「SSLアクセラレータ」と呼ばれる専用のハードウェアが発売されているくらいである。

　こうした理由から、暗号化には共通鍵方式を用いるのが望ましいのだが、ここに1つの問題が発生する。それは、どうやってサーバ側とクライアント（Webブラウザ）側で共通の鍵を用意するのかである。インターネットの世界では、特定の個人（Webブラウザ）だけがサーバにアクセスするとは限らない。従って、両者があらかじめ共通の鍵を保持することなど、現実的に不可能なのだ。そこで、SSLでは公開鍵と秘密鍵を使って共通鍵を相手に渡す、ハイブリッド方式を用いている。

共通鍵で通信できるまでの仕組み

　SSLが、公開鍵と秘密鍵を使った通信から共通鍵を使った通信に切り替えるまでの流れは、おおよそ次のとおりである。より詳細な仕組みについては、「身近なPKI〜SSLを理解する」が役立つだろう。

1. WebブラウザからSSLによる通信をサーバに要求
2. 署名付きの証明書とサーバの公開鍵を送付
3. 共通鍵をランダムに生成
4. 生成した共通鍵をサーバの公開鍵で暗号化して送付
5. 共通鍵での通信を開始

　この手順からも分かるように、公開鍵と秘密鍵はWebブラウザとサーバ間で共通鍵を共有するまでの間だけ使われる。無事に共通鍵を使った通信ができる状態になると、肝心の通信内容を送受信し始める。

本当に信頼できる相手なのか？

　ところで、疑い始めればキリがないのが現代の世の中である。通信している相手は、本当にデータを送信していい相手なのだろうか？ 受信しているデータは本物だろうか？

　通信相手が信頼できるかどうかを証明してくれるのが「証明書」である。そして、この証明書を発行してくれるのが「認証機関」（CA）である。認証機関は、サーバ所有者からの申請を受けて、認証機関の秘密鍵で暗号化された証明書を発行する。認証機関の秘密鍵で暗号化することで、証明書の改ざんや偽証明書の作成を防ぐのである。

　サーバは、先ほどの手順2でこの証明書とサーバの公開鍵をWebブラウザに送付する。Webブラウザは、あらかじめ組み込まれている認証機関の公開鍵を使って証明書を復号し、このサーバが信頼できる相手かどうかを判断する。もし、組み込まれていない認証機関であったり、証明書を確認できなかったりした場合には、Webブラウザが警告を発する仕組みである。

　この辺りの話は、「PKIの基礎を理解しよう！」を一通り見ていただくのがいいだろう。証明書と認証機関の仕組みや概念は非常に重要なものだが、ここではサーバに証明書を組み込む必要があることを理解しておけばよい。また、証明書は認証機関によって発行されることも知っておいていただきたい。