FacebookやTwitterと同様のセキュリティを自社メディアに施すには、セキュリティ最新トレンド／日本ベリサイン

クリックするとセミナーの内容を動画でご覧いただけます（動画を別ウィンドウで開く）

クリックで動画を表示
（ボックスが広がって
再生が始まります）

powered by 株式会社ヒューマンセントリックス

オウンドメディアを展開するためには、訪問者が安心できるセキュリティを施しておく必要がある。日本ベリサインの安達徹也氏は、無線LANなどでのアクセス時のCookieの危険性を唱え、常時SSLによって保護する必要性を解説。FacebookやTwitterの常時SSLへの対応や次世代暗号アルゴリズム「ECC」について話し、サイト運営に欠かせないセキュリティの重要性を説いた。

潜在的なリスクのある無線LANでのCookie窃取を防ぐ常時SSL

日本ベリサイン株式会社
SSL製品本部
上席部長
安達 徹也氏

今回は、前半は常時SSLについて紹介し、後半は常時SSLによるパフォーマンスの課題を解決するECC（楕円曲線暗号）について説明したい。細かな解説は行わないが、会社に戻って技術者と話し合いができるための知識を覚えていってほしい。

安達氏はまず、セキュリティをテーマにした本講演について、2つの技術に分けて解説を行うと話し、それぞれについて説明を始めた。

まず常時SSLは、httpサイトでの中間者攻撃（マンインザミドル）によるCookieの窃取を防衛するために、Webサイト上のすべてのページをhttps化することを意味する。Webサーバがクライアント（Webブラウザ）を識別するために用いられるCookieは、入力したIDやパスワードを保持したり、アクセス解析や行動ターゲティングの識別に用いられたりしているものだが、「最近は、スマートフォンなどの普及により、公衆無線LANなどがよく利用されているが、これらの無線LANには潜在的な脅威が潜んでいる」と安達氏は説明する。

有線LANやLTEなどの回線に比べ、無線LANはまだまだ脆弱性が多く、暗号化していないCookie内のセッションIDが窃取され、アカウントのなりすましの危険性があるのだ。もちろん、無線LANの暗号化方式はさまざまだが、すべての基地局が適切な暗号化を行っているとは限らないと安達氏は警告する。そのため、訪問者が安心してアクセスするためには、Webサイト側が常時SSLに対応して、第三者による盗聴・漏えいを防ぐ必要があるのだ。

大手サイトは常時SSL化へ続々と移行

安達氏がセキュリティ対策の1つとして提示する常時SSLは、その名の通りすべてのWebページをSSL（https）化させることだ。通常、Webサイトではフォームや問い合わせページ、ログインページなどでSSL暗号化を行い、他のページはhttpのままにしてある場合が多い。

しかし、訪問者のさまざまなデータを取得してマーケティングに役立てるためには、httpのページでもCookieを使ってアクセスさせることが一般的だ。そのため、httpのページへのアクセス中にCookieが窃取され、SSL暗号化されているhttpsページに不正にアクセスされる可能性があり、常時SSL化が推奨されるという。

たとえば、Hotmail、PayPal、Google、Twitter、Facebook、Yahoo! Mailなどの大手サイトではすでに常時SSL化が行われており、顧客情報の保護を強化している。特にGoogle検索では、ログイン後は検索が常時SSL化されており、Google Chromeのバージョン25からは、非ログイン状態でも常時SSL化されている。

常時SSLの有効性

また、常時SSL化によってパフォーマンスが低下するという課題も指摘されているが、Gmailを常時SSL化したときの影響はCPU負荷の1％以下、セッションあたり10KB以下のメモリ、ネットワーク負荷の2％以下だったというデータも示されており、安達氏は、「これらの常時SSLの詳しい解説や大手企業の取り組みは、OTA（Online Trust Alliance）のWebサイトに日本語のホワイトペーパーが掲載されているので参考にしてほしい」と説明する。

常時SSL化を行うための4つの手法

では、実際に常時SSL化を行うにはどのような手法があるのだろうか。安達氏は「常時SSL化する場合には、httpsのみにするか、ハイブリッドにするかという問題がある」と話を続け、次の4つの方法があることを示した。

• HTTPS（SSL）のみ
  

  安全性が高い反面、HTTPによるアクセスを取りこぼしてしまう可能性

• HTTPのアクセスをHTTPSに転送する（実質SSLのみ）
  

  同じURLのHTTPSページに301転送（完全に移動）を設定する
  HTTP/HTTPSのいずれでアクセスしても必ずSSL暗号化される

• ハイブリッド（HTTP/HTTPSの両方を運用）して、HTTPSのリンクを設置
  

  HTTPSへの切り替えボタンを用意

• ハイブリッドだけ

  HTTPSを知っている場合やリンクで誘導されたユーザだけSSL化される

安達氏によれば、上記のうち2番目に示した「httpのアクセスをhttpsに転送する」方法が最もお勧めできるという。SEOを考えれば、ハイブリッド方式では被リンクの効果が分散されてしまうため、httpまたはhttpsのいずれかの順位が落ちてしまうことが考えられるが、「.htaccess」ファイルを利用してhttpsに「301転送（永久移転）」した場合は、被リンクやSEO効果を引き継ぐことができる。

安達氏は、Googleがhttpsページの検索順位へ与える影響について回答した動画を紹介し、PayPalでは常時SSL化によって順位が下がっていないことを示した。ただし、2011年5月のこの動画の時点ではまだ例が少ないため、いったんアクセスの少ないサイトや一部のサブディレクトリで試してみることが推奨されている。

日本ベリサインの子会社である日本ジオトラストのWebサイトでは、2012年9月に常時SSL化を行ったが、トラフィックにネガティブな影響はなかったと安達氏は話す。また、httpとhttpsでログファイルが別になっている解析ツールも多いが、常時SSL化でログファイルをまとめられることや、httpのままでは取得できなかったhttpsからのリファラ情報を取得できるようになることも常時SSL化のメリットの1つだと言える。

続いて、安達氏はサーバがクライアントにCookieを送るときのレスポンスヘッダでSECURE属性を指定することで、Cookie情報を保護できることを説明する。

• Set-Cookieヘッダのフォーマット 例

  Set-Cookie: NAME=VALUE; expires=DATE; secure

• Set-Cookieヘッダ 例

  Set-Cookie: num=0001; expires=Sun, 1-Jan-2012 12:00:00 GMT; secure

また、補足情報としてhttpとhttpsのハイブリッドなサイトでライアントがhttp（非セキュアな状態）のアクセスをしてきた場合でも、強制的にhttps（セキュアな状態）に変更するために、サーバ側のhttpsレスポンスに「Strict-Transport-Security: max-age=2592000; includeSubDomains」のように指定することも説明した（2592000は有効期限を秒数で指定、includeSubDomainsはサブドメインを対象に指定）。ただし、このhttpsレスポンスは、IE 9では未対応となっている。

常時SSL化によって、レスポンスの低下を気にする人も多い。安達氏は「最近はhttpsによるレスポンスの低下は比較的改善されてきたが、2010年にRSAの鍵の長さを1024ビットから2048ビットにして暗号化を強めることが決められてから、再度パフォーマンスの問題が論議されるようになった」と説明する。しかし、レスポンス低下の原因となるCPU負荷はマルチコアなどの処理能力の向上で問題とはならず、SSLネゴシエーションの発生回数を減らすために「Connection: keep-alive」のようにKeep Aliveを有効な設定にすれば、レスポンス低下を防ぐことができる。

安達氏は、ここまでの説明の最後に常時SSL化のメリットとデメリットを次のようにまとめた。

さらに常時SSLの実装事例としてPayPalを紹介する安達氏は、EV SSL証明書と組み合わせることで検索結果にhttpsのページが表示され、Webページではブラウザのアドレスバーが緑になり、アクセスしたときにPayPalのサイトであることがわかるようになっていると説明する。

EV SSL証明書を採用したサイトでは、アドレスバーが緑色になりサイトの所有者がわかりやすく表示される（画面はIE 9の例）。

処理負荷を軽減させて強固なセキュリティを提供するECC

続いて解説は、新しい暗号アルゴリズムであるECC（楕円曲線暗号）の話題に移る。以前から広く普及している素因数分解で暗号化するRSAとは異なり、ECCでは「楕円曲線上での離散対数問題」を活用した暗号アルゴリズムで、素因数分解よりも解読に時間を要することが特徴となっている。また、NIST（National Institute of Standards and Technology：米国国立標準技術研究所）なども評価しており、標準の暗号アルゴリズムの次世代候補と考えてもよいという。RSAの2048ビットは112ビットのセキュリティであるのに対し、ECCは256ビットで128ビットのセキュリティとなることも大きな特徴の1つだ。

2010年にRSAが暗号に使う鍵の長さを長くするように決められたように、今後も暗号化の強度を上げる必要が出てくることも予想されるが、鍵が長くなるほど必要なCPU処理負荷がかかるため、短い鍵でも暗号化の強度を上げられるECCは非常に注目されている。安達氏によれば、Webサーバへの同時セッション数が増えてRSAのレスポンスタイムが悪化した場合、ECCとのパフォーマンスの差が非常に大きくなるため、ECCはトラフィック集中に強い暗号アルゴリズムだといえ、サーバやリソースなどへの設備投資を抑える効果も出るという。

ECCは新しい暗号アルゴリズムであるため、サーバ側が未対応である場合は利用することができないと考える技術者も多い。この打開策として安達氏は、Apache+mod_sslによるハイブリッド構成でRSAとECCの両方をサーバにインストールする方法を示し、「Apacheを利用している場合は、このような手法も使えることを理解し、技術者にも伝えてほしい」と話す。

Apache + mod_ssl によるハイブリッド構成

ECCは、ベリサインだけでなく、さまざまなリーディングカンパニーとパートナーシップを組みながら普及に努めていることをアピールした安達氏は、「現状はApacheだけだが、今後ECCを使えるサーバは増えていくことが予想される。ぜひ、今後も注目し、ECC導入の検討を開始することをお勧めする」と最後に話し、講演を終えた。