運用
個人情報保護法時代のIISセキュリティ対策(前編)

2.SSL基礎の基礎

小田原 貴樹(ハンドル・ネーム:うりゅう)
2005/09/02

 普段からWebサイトを閲覧しているユーザーであれば、無意識のうちにSSLを利用しているケースは多い。SSLは利用者からは敷居の低い技術であるが、あらためてSSLとはどういったものなのか基礎の基礎を簡単に解説してみよう。ただ、こうした暗号化技術はアルゴリズムのような深い部分まで踏み込むと、理解するには高度な数学的知識を必要とするため本稿では割愛し、概論だけをさらってみたい。まずは、用語としてのSSLの意味を整理しておこう。

 SSL(エス・エス・エル)とはSecure Sockets Layerの略である。インターネット上でのWebサービスにおいて、サーバとクライアントとの間でクレジット・カード情報などの機密性の高い情報を安全にやりとりできるようにするために、米Netscape Communications社(現在はAOL社に吸収合併)が開発したセキュリティ機能付きの伝送プロトコルだ。SSLを利用したHTTPであるHTTPSとして利用されるのが一般的で、IETFによりTCPのポート443番がHTTPS用として定義されている。SSLを利用したSMTP(メール)やNNTP(ニュース・グループ)などにもTCPポート番号が予約されている。

SSLとネットワーク階層の関係
SSLをネットワークの階層モデルで表すと、セッション層/プレゼンテーション層に相当する。TCP/IPでいえば、TCPとアプリケーションの間に位置するプロトコルである。アプリケーションが送信するデータを暗号化して下位層に送る。受信した側では、暗号化されたデータを復号化してから上位のアプリケーションへと渡す。

 上図のように、SSLプロトコルをOSIのネットワーク階層モデルで表すと、TCP層とアプリケーション層の間に位置し、上位のアプリケーション層から、暗号化などのセキュリティ対策を施した通信が行えるようになっている。SSLは、サーバとクライアントの間でのセッション認証にはRSA方式などの公開鍵暗号技術を用いたデジタル証明書を使用し、データの暗号化にはDESやRC4などの共有鍵(秘密鍵)暗号技術を使用する。

 Netscape Communications社は、いわずと知れたWebブラウザ「Netscape Navigator」の開発元である。現在では、Internet Explorerなど他社のWebブラウザでも、業界標準としてSSLの機能は必ず搭載されていると思うが、もともとはNetscape Navigatorの一機能として開発され、後に標準化されたものだ。SSL 3.0仕様に拡張を施し、RFC 2246でTLS 1.0として標準化されている。

 SSLとはまさしくWebサイトにおいてクレジット・カード情報などを安全にやりとりするために開発されたものと理解できるだろう。そのうえでSSLでは、公開鍵暗号/デジタル証明書/共有鍵暗号といった技術を利用してセキュリティを高めているわけだ。ただ、上記の解説では、どういうプロセスで情報の暗号化が行われているのかが分かりにくいので、「SSLがどうやって安全性の高い通信を実現しているのか」について、次の図を見ていただきたい。

SSLはどうやって暗号化しているのか?
SSLでは、通信の内容を暗号化するために「共有鍵暗号システム」を利用している。これは、送信側と受信側が同じ鍵を使ってデータを暗号化/復号化するというシステムだ。だがこの共有鍵の内容が漏れてしまっては安全に通信することができない。そこで、最初に共有鍵を安全にやり取りするために「公開鍵暗号システム」を利用している。クライアント(Webブラウザ)が共有鍵を生成すると、それを「Webサーバの公開鍵」を使って暗号化し、サーバに送信する。サーバでは「Webサーバの秘密鍵」でそれを復号化し、元の共有鍵を得る。具体的な手順については本文を参照のこと。

 SSLでは、共有鍵暗号システムと公開鍵暗号システムを組み合わせて安全な通信を実現している。以下、図中の数字に沿って、通信の手順を解説しよう。

(1) 暗号化された情報のやりとり開始を、クライアントがサーバに対して「接続要求」として送信する。

(2) サーバは自分の署名/サーバの公開鍵が含まれた「サーバ証明書(デジタル証明書)」を、クライアントに送信する。

(3) クライアントは、受け取った証明書が信用できる認証局(CA)から発行されたものかどうかを確認し、通信を行っているサーバが信頼できる相手であるかどうかを確認する。信頼できる相手であることが、確認できたら、それ以後の暗号化通信に利用する「共有鍵」を、証明書に含まれる「サーバの公開鍵」で暗号化する。

(4) クライアントは、サーバの公開鍵で暗号化した共有鍵をサーバに送信する。この共有鍵はサーバだけが持っている「秘密鍵」でしか復号できないため、他者に悪用される心配はない。

(5) サーバはクライアントから受け取った共有鍵を、サーバの公開鍵とペアになっている秘密鍵で複号化する。

(6) ここまでのフェイズで生成された共有鍵を、クライアントとサーバの双方で他者に漏れることなく交換できた。これ以後の通信では共有鍵を用いて暗号化通信を行う。

 なんとなくご理解いただけただろうか? 要するに、SSLでは暗号化通信に必要な「共有鍵」の交換を「公開鍵暗号」システムを利用して行うところに特徴がある。なぜこのように複雑な手順を踏むのかというと、「共有鍵暗号」・「公開鍵暗号」にはそれぞれ以下のような利点と欠点があるからだ。

利点 欠点
共有鍵暗号 暗号化と復号化に同じ鍵を用いる 鍵交換の際に鍵を盗まれると、それ以後の通信内容がセキュアでなくなるため、鍵を安全にやりとりする手法が必須になる
公開鍵暗号 秘密鍵と公開鍵と呼ばれる対になる2つの鍵を使ってデータの暗号化/復号化を行う。秘密鍵で暗号化されたデータは対応する公開鍵でのみ復号できる。逆に、公開鍵で暗号化されたデータは対応する秘密鍵でのみ復号できる 暗号化/復号化演算量が多いという技術上の根本的問題で、処理にとても時間がかかる
共有鍵暗号と公開鍵暗号の利点/欠点

 この2つの暗号方式の欠点をそれぞれ補うために、共有鍵の交換に公開鍵暗号方式を利用しているのである。「素晴らしく現実的なアプローチを取っている技術だなぁ」と感じてもらえたらなら幸いである。「なんのことかやっぱりよく分からない……」という方でも気にせず先を読んでいただきたい。上記のようなことを理解していなくても、SSLを利用・導入する面では何の問題もないので安心してほしい。

 実際に一般ユーザーの目から見た場合、SSLというものを意識できるのは以下のわずかな部分だけである。

  • SSLで暗号化されたWebサイトのアドレスは「https://」で始まる。

  • 下図のようにWebブラウザのステータス・バーに鍵のマークが表示されている(ちなみにこの鍵をダブル・クリックすると、デジタル証明書を確認できる)。

 鍵のマークで安心感を提示しながらも、ユーザー側ではほとんどSSLという技術を意識する必要はない。スムーズに利用できているのは、Internet ExplorerやFirefoxなどの一般的なWebブラウザには、あらかじめルート証明書(rootCA)と呼ばれる「信頼できる認証局」の証明書が登録されており、対応する公開鍵が内蔵されているからである。そのため、ルート証明書として登録されている認証局が発行したデジタル証明書については、自動的に認証が行われ、SSLによる暗号化通信が開始できるのだ。

 SSLではこの「信頼できる認証局」という存在が非常に重要になる。情報の暗号化のためだけにSSLを利用する場合、フィッシング詐欺に代表される「なりすまし攻撃」を防ぐことは出来ない。なぜなら、IISなどのWebサーバでは、独自に構築した認証局で生成したデジタル証明書を利用できるからだ。独自の証明書を勝手に作れるということは、「どこかの有名な会社とよく似通って見える」ものを作成することも技術的には可能であるため、デジタル証明書があることだけでは「実在性の証明」を保証できないことになる。

 そうした問題に対応するために、Webブラウザにはルート証明書が実装されている。ルート証明書に登録されていない、すなわちWebブラウザから見て「信頼できるかどうか保証できない」認証局で発行されたデジタル証明書が受け渡され、SSL通信を開始しようとした場合、Internet Explorerであれば次のような画面が表示される。

信頼できないルート証明書に対する警告表示
信頼できるルート証明書が見つからない場合には、このようなダイアログが表示される。Webブラウザにはあらかじめ信頼できるルート証明書が内蔵/登録されているが、それに該当しないルート証明書が使われていると、このようなダイアログが表示され、信頼できるかどうか保証できないということが分かるようになっている。このようなWebサイトではユーザーは安心して利用することはできないであろう。

 実験的なWebサイトであればともかく、ショッピング・サイトのような商用サイトでユーザーからの情報を受け取ろうとするたびに、このような画面が表示されたのでは大問題となる。いくら運営者側が「証明書は独自ですが、暗号化されてますので大丈夫です!」と訴えたところでユーザーは不安でしょうがないだろう。そのため、SSLを導入する場合には「信頼できる第三者認証局から自分のサイト・会社の実在を証明してもらう」ためにデジタル証明書(サーバ証明書)を発行してもらう必要がある。SSLを導入するということは、とりもなおさず暗号化とサーバの実在証明のためにサーバ証明書を購入するということなのである。

「SSL」導入計画

 さて、前置きがかなり長くなってしまったが、SSLの仕組みがなんとなく分かったら(分かってなくても)ここからは実際に「SSLを導入する」ために必要となる計画を立てていこう。SSLを導入する=認証局からデジタル証明書を取得するためには、つぎのようなプロセスが必要になる。

1. どこのSSLサービスを選択するかを決める
 公的SSLをサービスとして提供している企業は数社ある。これは認証局の違いに始まり、料金・契約の手順・最終的に受けることのできるサービスの幅などにかかわってくる。この部分については次回詳しく説明する。

2. Webサーバを操作してCSRを生成する
 「CSR(Certificate Signing Request)」とはデジタル証明書生成の基となるサーバ情報のことである。IISなどのWebサーバにはCSRを簡単に生成するためのウィザードが搭載されているので、これを利用する。

3. 選択したSSLサービス提供会社のWebサイトなどから申し込みを行う
 この部分はどこのSSLサービス提供会社を利用するかによって大きく異なる。単純にフォームに企業情報などを入力すればよいだけのものから、申し込みには「部長以上の決裁者の承認」を証明しなければならないものまで存在する。

4. 認証局に対して自社情報の証明を行う
 この部分も提供会社によって大きく異なる。管理者用のメール・アドレスが確認できればよいものから、登記簿謄本の提出が必要なものまでさまざまである。また、特に厳しい提供会社の場合、Webサイトのドメイン登録者と利用者が違う場合、ドメイン登録者の証明も必要であったりして大変である。

5. 料金を支払う
 大半の公的SSLサービスでは、「年間利用料金」を支払い、年ごとに契約を更新する形式を取っている。金額については、最も安いサービスで「年間2万円弱」、最も高いサービスで「年間10万円強」というところである。値段の差がそのまま信頼性と一致しているわけではないが、高名な認証局の方が、価格が高い傾向にあるようだ。

6.デジタル証明書が発行される
 生成されたデジタル証明書は電子メールなどで届くことが多いようだ。デジタル証明書が届いたら、Webサーバにセットアップし、SSLが利用できるようにしよう。また、Webサイトを一部変更し、SSLでの通信が可能な状態にする必要もある。

 上記で説明したとおり、どこのサービスを受けるかによって、3番と4番のプロセスが大きく変わってくる。その結果として、申し込みを行ってからデジタル証明書が発行されるまでの期間が変動してくることになる。最も早いサービスの場合で手続きを開始した翌日、最も遅いサービスの場合は1カ月程度の期間が必要になることもある。

■ 次回予告

 今回は「IISにSSLを導入する」ための前段として、主に「SSLとはどういったものなのか」について解説を行ってみた。こうした概念的知識というのは、実際の導入や利用にどうしても必要なものというわけではない。ただ、ベースとして知っていれば、より適切に導入/利用しやすくなることは確かである。

 個人情報保護法の施行に前後して、Webサイトで個人情報を収集する場合には、SSLを導入していることが必須になってきている。それはユーザー自身の意識が高まっているために、SSLを導入していないようなWebサイトには不安感を覚えるという声が増えてきているからである。また、インターネット上のメルマガ広告やバナー広告などの媒体元でも「広告を出稿するならば、WebサイトにはSSLは導入してください」と要求してくるケースも飛躍的に増えてきている。もはやSSLの導入と実装は「した方がよい」ではなく「しなければならない」というフェイズに差し掛かっているのだ。

 さて次回は、具体的かつ実践的な内容をお送りする。代表的な提供会社サービスの違い、具体的な手続き、IISへの証明書インストール、という流れでSSLを導入するために必要となる作業一式を分かりやすく解説していく予定なので、次回もお付き合いいただければ幸いである。End of Article

筆者略歴
8年間のベンチャーIT企業勤務を経て、フリーのプログラマとして独立。専門はWebアプリケーションの設計・開発。「生涯一プログラマ」を目標に、常に中小事業者を対象とした現場に立ち続けている。
 

 INDEX
  [運用]
  個人情報保護法時代のIISセキュリティ対策(前編)
    1.暗号化通信の需要
  2.SSL基礎の基礎
  個人情報保護法時代のIISセキュリティ対策(後編)
    1.サーバ証明書サービスの選択
    2.CSRの生成と証明書の申請
    3.SSLのセットアップ
 
 運用

@IT Special

- PR -

TechTargetジャパン

Windows Server Insider フォーラム 新着記事
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)
- PR -

イベントカレンダー

PickUpイベント

- PR -

アクセスランキング

もっと見る

ホワイトペーパーTechTargetジャパン

注目のテーマ

Windows Server Insider 記事ランキング

本日 月間
ソリューションFLASH