なぜ常時SSL化なのか？
まずは、常時SSLのメリットについて、簡単におさらいしておきたい （表1）。 そもそもSSLの目的には、通信の暗号化によるセキュリティ強化 と、認証局が発行したSSLサーバー証明書によるWebサイト運営 書の信頼性の証明という、大きく2つがある。従来から、個人情報 を入力するフォームやログインページなどをSSL化するWebサイト は多かったが、巧妙化するサイバー攻撃への対策や、モバイル化の 進展に伴い急増している公衆 Wi-Fiなどからの通信の安全性の確 保、さらにはWebサイトの信頼性に対するインターネットユーザー の意識の高まりなどを背景に、Webサイト全体の常時 SSL化の必 要性が高まっている。 常時 SSL化は、Webサイトを運用する側にもメリットが大きい。 HTTPとHTTPSが混在するサイトでは、ユーザーの動線をCookie で追いかけようとしても、うまく運用できず、また、それを技術的に 解決するのは難易度が高い。そこで、常時 SSLか非 SSLかのどちら かということになるが、当然、常時SSLを選ばないという考えはない はずだ。 コストが気になるかもしれないが、実はSSLサーバー証明書の発 行にかかる費用は、同じWebサイト上であれば1ページのみをSSL 化しても、全ページをSSL化しても基本的に変わらないのだ。つま り、常時SSL化に必要なのは、現場担当者のちょっとした工夫だけな のである。Web制作者が押さえるべき
常時SSL化のポイント
では、常時SSLのためにWeb制作者が押さえるべきポイントを 説明する。まず基本的な姿勢として身につけておきたいのが、常 時SSLを前提としてWebサイトのコンテンツを設計することだ。■HTTP/HTTPS混在の回避
従来、サイト内へのリンクを張る際には、どのページが SSL化さ れているかはあまり気にはしていなかったかもしれない。そのよう な意識で常時SSL化されたWebサイトを設計／運用してしまった際 に問題となるのが、絶対パスで“http://……”と記述してリンクを 張っていたり、CSSやJavaScriptファイル、画像をHTTPで埋め込 んでいたりしていた場合である。こうしたページをそのままSSL化し てしまうと、主なWebブラウザでは「http混在」の警告が表示され てしまう（図1）。 日頃はこのような表示を何気なく見過ごしているかもしれない が、実際のところHTTPコンテンツとHTTPSコンテンツが混在する と深刻な危険が生じる。通常、画像データはCookieなどとともに Webサイトの全ページを HTTPS化する「常時 SSL」が、大きなトレンドとなっている。しかし、Web担当者やサーバー担当者の中に は、その意義は十分に理解しつつも、常時SSL化のために特別なスキルや手間が必要になると考えて導入に二の足を踏んでいる方も いるのではないだろうか。はっきり言おう、そのような心配は無用だ。最小限のポイントさえ押さえれば、常時 SSL化は実現できるの だ。本書では、常時 SSL化へと踏み出すために Webサイト設計・運用の現場を担うWeb制作者とサーバー担当者が知っておきたい 事項について解説する。 表1：常時SSL化のメリットとデメリット 常時SSL化 一部ページのSSL化 メリット ●すべてのアクセスを暗号化 ●SEOで優遇される ●コンテンツ／リンクの管理がシンプル ●リファラ情報が取得しやすくなる ●全ページで信頼性を伝えやすい（EV SSL証明書の場合） ●ユーザーに接続タイプの選択権がある ●証明書の管理負担が少ない、または変わらない デメリット ●SSL接続を禁止しているネットワークに対応できない●HTTP接続のときと比べ、SSLネゴシエーションによる負荷が発生する ●ログ解析が複雑になる●Cookieの安全なセッション管理が煩雑に ●httpsのページ内にhttpの画像、js、cssファイルなどが 混じっているとブラウザが警告を出す ●Cookieの値が暗号化されず、なりすましされる恐れがある ●httpの画像ファイル等を読み込む際に暗号化していない cookieの値がやり取りされる危険性がある サーバへのリクエスト例 GET /logo.gif HTTP/1.1 Accept: */* Referer: http://www.example.com Accept-Language: jaUser-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Accept-Encoding: gzip, deflate Host: www.example.com
Connection: Keep-Alive
Cookie: sessionID=0233683208C683A3053473E67BE2AE63
図1：「http混在」の警告
やり取りが行われるが、例えばよくあるコーポレートロゴの画像ファ イルが HTTPで指定されていた場合、Webサイトを訪れたユー ザーの Webブラウザがダウンロードした時に、Cookieの情報が 暗号化されずに流れてしまう（Cookieにsecure属性を設定してい ない場合）。その他のコンテンツが HTTPSだったとしても、たった 1つの非暗号化画像のためにCookieの値が漏えいしてしまうのだ。 このような事態を避けるためにも、HTTPとHTTPSが混在したコ ンテンツはゼロにすべきだ。普段から、リンクを張る際に相対パス で指定するか、もしくは“https://……”というように絶対パスで記 述するよう心がけることが大切だ。当然、既存の混在コンテンツ内 のリンクはすべてこのいずれかに書き換える必要がある。
■HTTPS対応Webビーコンの採用
サードパーティで提供しているWebビーコンの中には、HTTPS に未対応のものも稀に存在する。このようなWebビーコンを埋め 込んだページもまた、HTTP/HTTPS混在としてWebブラウザの警 告が表示されてしまう。もしSSL非対応の Webビーコンが必須で あれば、常時 SSL化は諦めざるをえない。そして常時 SSL化を実施 しつつ、Webビーコンも使い続けるのであれば、HTTPSに対応し たWebビーコンに切り替えるか、ビーコンの提供者にSSL化を要 望するアクションをとってほしい。■301リダイレクト設定
Web制作者が覚えておくと便利なのが、HTTPで指定されたア クセスをすべてHTTPSのコンテンツへと転送するようにWebサー バーソフトウェアの .htaccessファイルなどを書き換えておく方法 である。このように、サーバー側でいわゆる301リダイレクトの設 定を行っておけば、すべてのリンクを“https”に書き換えることな く、Webサイト全体にHTTPSでアクセスさせることが容易に行え る。ただし、企業によっては、Web制作者の権限では Webサー バー側の設定を変更できないケースもある。そうした際には、サー バー運用の担当者などに問い合わせるようにしたい。Web制作者とサーバー担当者の
両者が押さえておきたいポイント
続いて、企業によってWeb制作者とサーバー担当者のどちらか に担当がわかれるが、双方ともに押さえておきたい事項を解説して いこう。■認証局の信頼度
第一のポイントは、常時 SSLに限らないが、信頼できる認証局が 発行するサーバー証明書を選ぶことが重要である。 サーバー証明書の内容は、どの認証局のものでもほとんど同 じだが、大きく異なるのが認証局側のバックエンドに構築されて いる、サーバー証明書の発行や失効情報配信などにかかわるイ ンフラの運用体制である。過去には、認証局のインフラが何者か に乗っ取られ、不正証明書を発行してしまうといった事件も発生 している（図2）。 例えば、その認証局が発行したルート証明書が各Webブラウザ にきちんとインストールされるように日頃からWebブラウザベン ダーとのコミュニケーションを綿密に行っていたり、OCSPによる失 効情報配信などインフラへの投資を怠らず、継続的にパフォーマン スを改善したりといったように、しっかりとした運用体制が整ってい る認証局を選ぶべきである。 認証局を選ぶ際には、有名ブランドのものを選ぶことを推奨した い。大手の認証局セキュリティベンダーであり、SSL認証局としても シェアNo.1を誇るシマンテックであれば、仮に問題が生じても、万全 なサポート体制のもとで手厚い対応が期待できるなど、大きな安心 感がある。加えて、同社のサーバー認証を受けていることを証明する シールをWebサイト内に貼ることができるため、例えばサイト内共 通のフッターにこのシールを貼っておけば、サイト訪問者はどのペー ●2011年7月にオランダの認証局Diginotarの発行システムがハッキングされた ●8月に不正証明書によるマンインザミドル攻撃が確認された ●インフラや情報開示が不十分で認証局の信頼性を著しく損ねたため、ブラウザのセキュリティアップデートによってルート証明書が無効化された 認証局A発行 SSLサーバ証明書 すみれ商店 Diginotar発行 SSLサーバ証明書 つばき商店 認証局A用ルート証明書 Diginotar用ルート証明書Diginotar社
・CPA（運用規定） ・第三者監査 ・インフラDiginotar事件
（531件の不正証明書発行） 図2：認証局の信頼性が問われた「Diginotar事件」ジにアクセスしても安心してコンテンツを閲覧できるはずだ（図3）。
■ワイルドカード証明書
従来のSSLサーバー証明書とは視点を変えて考えるべきなのが、 証明書の種類についてだ。一般的な証明書ではコモンネーム型の モデルが採用されており、サブドメインを含めたドメイン名（ホスト 名）ごとに1枚ずつ証明書を購入しなければならない。 常時SSL化を行わないのであれば、個人情報の入力や決済を行う ページを証明書の対象となるドメイン下に置けば問題はない。しか し、企業のWebサイトの場合、目的や性質ごとにさまざまなサブド メイン名を使用しているケースが多い。そうなると、常時 SSL化の ための証明書には、1枚の証明書を購入するだけでサブドメインも 含めて使えるものが適していると言える。 このように、複数のドメインに対応したサーバー証明書はワイル ドカード証明書と呼ばれている。ワイルドカード証明書であれば、 “*.◯◯◯.co.jp”のように文字通りワイルドカードを使った証明書の 発行が可能となる。もちろん、ワイルドカードの部分は、Webの標 準規格で定義された表記ルール内であれば自由な名称をいくつで も使用することができる。 実はワイルドカード証明書はフィーチャーフォンに未対応なことか ら、これまではどちらかと言うと敬遠されがちであった。しかし現在 は、スマートフォンやタブレット端末からが当たり前となったため、こ こに来て一気に普及が広がり始めたのだ。■マルチドメイン対応証明書
もう1つ、1つのサーバー上で複数のドメインを運用しているよう な場合に効果が大きいのが、マルチドメイン対応証明書だ。前述の ように従来のコモンネーム型の証明書は、1枚で1つのドメイン名し か対応していない。しかし、バーチャルドメインをはじめとして、同じ サーバー上であっても複数のドメイン名を使いわけて使用している ケースは多々ある。そこで1つの証明書の中に複数のドメイン名を 登録することができるのが、マルチドメイン対応証明書なのだ。同 一 IPアドレス上でドメイン名ごとに別々の証明書を使い分けられる SSLの拡張仕様としてSNI（Server Name Indication）があるが、 マルチドメイン対応証明書は、特にSNI非対応のバーチャルドメイ ンWebサイトなどで必須の証明書と言っていいだろう。3つの認証レベルについて
サーバー証明書は、認証レベルに応じて次の 3つに分類される（表 2）。 1. ドメイン認証型（Domain Validation＝DV） 2. 企業実在性認証型（Organization Validation＝OV） 3. EV SSL（Extended Validation） 正当な ドメイン保持者 （警告無しの暗号化） 実在する企業 （企業の公式サイト） 国際的認定基準による 組織の法的実在性 （緑色のアドレスバー） 自己 署名型 ドメイン認証型 企業 実在性 署名型 EV SSL このうちドメイン認証については、正当なドメインの利用権限だけ を確認して発行されるという簡易的なものなので、証明書に組織情 報は記載されない。低コストが魅力ではあるが、不特定多数のユー ザーがアクセスするオープンなWebサイトで採用するよりも、特定 利用者のみがアクセスするイントラネットへのセキュアなアクセスに 向いている証明書だと言える。 2つ目の企業実在性認証型は、SSL暗号化に加えて、Webサイト を運営する企業の実在性確認までを経たうえで発行される証明書で ある。第三者機関のデータを活用し、人手によって企業の実在性を 認証してから発行されるため、ユーザーに対して相当な信頼感を与 えることが期待できる。そのため．不特定多数がアクセスする企業 の公式サイトやECサイトで非常に広く普及している。 そして3つ目の EV SSL証明書は、事業所の住所や事業所の責任 者など、企業実在認証型の証明書よりもさらに厳格にWebサイト運 営団体の実在性を審査したうえで、国際的な認定基準に基づいて発 行される証明書だ。この証明書のあるWebサイトにアクセスする と、Webブラウザのアドレスバーが緑色に変化するとともにサイト 運用者名が表示されるようになる。ちなみにインストールの方法は 従来の証明書と変わらない。常時SSL化には現状で最適な証明書と 言えるEV SSLは、既に銀行その他の大手企業を中心として導入が 進んでいる。サーバー担当者が押さえるべき
常時SSL化のポイント
最後に、サーバー担当者が常時SSL化のために押さえておきたい 項目を整理しよう。■適切な暗号アルゴリズムの選択
一部 SSL化を行っている場合、自社の SSLではどのような暗号ア ルゴリズムを利用しているのかあらかじめ確認しておきたいという 図3：シマンテックの「ノートンTMセキュアドシール」 表2：サーバー証明書の種類担当者も多いことだろう。そこで、現在のサーバーの SSLにまつわ る設定がどうなっているのか確認できるチェックサイトを活用するこ とをおすすめしたい（図4）。 こうしたチェックサイトでテストを行い、業界標準として推奨され ている設定とのギャップを認識したうえで、地道にギャップを埋めて いくのがサーバー担当者に求められる使命だと言える。これは Webサイトの SSL化を行う場合には一部か常時かにかかわらず必 須となるが、常時SSL化を良い機会と捉えて改めて確認してみてほ しい。 そして避けなければならないのが、脆弱性が指摘されている暗号 アルゴリズム／プロトコルバージョンの利用である。代表的なの が、SSL3.0（IE6）の禁止（TLS1.1以上推奨）や RC4の禁止（AES-GCMの推奨）などだ。 では、どのアルゴリズム／プロトコルに脆弱性があり、どれを使 えばいいのか知るためには、各セキュリティベンダーなどが提供し ている推奨情報や、IPAのような政府機関が発表している情報を参 考にしていただきたい（表3）。
