はじめまして、永岡と申します！
テックブログを通してみなさまにIDCFクラウドの良さをどんどんお伝えしていきたいと思います！
今回は、セキュリティ面やSEOの観点から様々な企業でも対応が進んでいる常時SSL化がなぜ求められてきているのか、またIDCFサービスを使用した対応方法をご紹介したいと思います！
常時SSL化ってなに？
常時SSL化とはすべてのWebページを暗号化(SSL/TLS化）するセキュリティ手法のことでAOSSL(Always On SSL)とも呼ばれています。
通常ログインページなどの特定ページのみを暗号化しますが、すべてのページを暗号化することでCookieなどの情報も暗号化され、盗聴されにくくなります。
また、常時SSL化を行うことで次の3点を守ることができます。
1.機密性
すべてのページで通信が暗号化されます。
通信内容を盗聴されにくくなり、情報の機密性を守ることができます。
2.完全性
通信を暗号化することにより、データの改ざんがされにくくなりデータの完全性を守ることができます。
3.サイトの実在性
常時SSL化する際に、証明書が必要になります。証明書によって通信相手が正しく存在していることを証明できます。サイトの実在性が取れることにより、フィッシング対策にもなります。
このように、常時SSL化を行うことでサイトのセキュリティを強化することができます。
また、サイトの実在性が取れることでユーザーが安心して通信を行え、結果としてサイトの信頼性向上にも繋がります。
なぜ対応が求められているのか？
常時SSL化に対応することでユーザーが安全に通信を行えたり、個人情報の盗難を防ぐことができることはお分かりいただけたと思います。
ではみなさん、「個人情報」と聞いてどのようなキーワードが思い浮かぶでしょうか？
多くの方は「名前」、「電話番号」、「住所」などを思い浮かべると思います。
しかし、これらの情報だけが個人情報ではなく、
ユーザーとWebサイトがやり取りしているCookieや履歴などの情報も立派な個人情報として認識する必要があります。
近年、カフェや空港などでも公共の無線LANが普及してきており、とても便利になってきました。
しかし、中にはパスワードが不要な無線LANなどがあります。
暗号化されていない公共の無線LANから、悪意のある第三者により次のような被害にあう危険性があります。
・盗聴、なりすましによる個人情報流出や、盗聴した情報を使ってページの改ざん
・偽のWebページを用意し個人情報などを入力させ詐取する「フィッシング詐欺」などネット上での犯罪
このようなユーザーの個人情報やWebページの運営側の信頼性低下を回避するため、サーバー側での対策として常時SSL化が求められてきています。
また、SEOの観点からも常時SSL化対応を促す動きが起きています。
2014年8月にGoogleから「HTTPS（暗号化通信)をランキングシグナルにします」という発言がありました。
これは「HTTPS(暗号化通信)しているかどうかを検索ランキング順位決めの判断基準としますよ」という意味です。
また、入力フォームがあるページではHTTPS化していないと「このページは保護されていません」という警告文が表示されるようになりました。
常時SSL化を行っていないと検索ランキングの低下や警告文の表示による信頼性の低下などのデメリットが生じるようになり、これを機に多くの企業で対応されるようになってきています。
これらの背景によって、常時SSL化はユーザーを守るだけではなく、Webページの運営側も守るために必要であり、求められてきています。
常時SSL化時の課題点とIDCFでの対策
セキュリティ強化や信頼性の向上などと多くのメリットがある常時SSL化ですが、導入時に証明書のコストや手間がかかったり、通信時に暗号化(SSL/TLS化)するためサーバーへの負荷が増えレスポンスが遅くなる...というデメリットも存在します。
このようなデメリットを感じ「まだ対応しなくても大丈夫だろう...」とあと一歩常時SSL化へ踏み出せない方もいらっしゃるのではないでしょうか。
そんなみなさま！IDCFサービスを使えばこのようなデメリットを改善し、常時SSL化に対応させることが可能です！今回はILBとコンテンツキャッシュの2通りの方法をご紹介します。
「ILB」を使って証明書の導入、更新時の手間を効率化
ILBを使用し、証明書の管理方法を工夫することで導入、更新時の手間を効率化できます。
基本的に証明書の管理方法として
・各サーバーごとで管理する方法
・証明書用管理サーバーを立て管理する方法
・ロードバランサ―に集約させ管理する方法
があると思います。
「証明書用管理サーバーを立て管理する方法」、「ロードバランサ―に集約させ管理する方法」は一箇所で管理するだけで済むため各サーバーで管理するよりも作業効率がいいです。
しかし、大量のトラフィックが流れてきたときに処理が追いつかずボトルネックとなってしまうケースがあります。
そこで、IDCFサービスのILB(Infinite Load Balancer)に証明書を集約させることで、導入や更新時の手間を格段に効率化することができます。
ILBはIDCFクラウドで動作するロードバランサーで、証明書を集約できるほか、トラフィック流量に応じてオートスケールアウト/インを行います。
また、IDCFクラウドの標準提供ロードバランサ―に比べ処理が約10倍の性能*1なので手間なく証明書集約によるボトルネックを防ぐことができ安定した運用が可能になります。
ILBでは証明書を終端させる機能のみを使用しバランシング機能は使わないという使用方法もできますので、
現在使っているサーバー構成を変えずに常時SSL化したりなど要望に沿った使い方が可能です。
＜「ILB」の関連記事＞
■ILBを使ってWebサーバーをバランシング！構成事例もご紹介 - IDCF テックブログ
■超簡単〜ILBをMackerelで監視してみよう - IDCF テックブログ
*1 計測ツール：Apach Bench 2.3 / リクエスト回数:100,000回 / 同時コネクション数：2,000 / ファイルサイズ:32KB
「コンテンツキャッシュ」を使って負荷を軽減
また、コンテンツキャッシュを使用し暗号化通信によるサーバーへの負荷を軽減することで、レスポンスタイムの低下を防ぐことができます。
常時SSL化はすべてのページを暗号化するため、HTTPで通信するよりサーバーやロードバランサ―に負荷がかかりレスポンスタイムが遅くなってしまうことがあります。 レスポンスタイムが遅くなってしまうとユーザーが快適にWebページを閲覧することができなくなり結果的にページから離脱してしまうかもしれません。
そこでIDCFのコンテンツキャッシュというコンテンツ配信サービス使うことでサーバーやロードバランサーのSSL処理の負荷を軽減させることができます。 さらに、HTTPと同等費用でHTTPS化を簡単に行うことができます。
＜「コンテンツキャッシュ」の関連記事＞
■IDCフロンティアのコンテンツキャッシュサービスを使ってコンテンツを高速配信！ - IDCF テックブログ
■コンテンツキャッシュの2つの新機能について - IDCF テックブログ
このように、IDCFのサービスを使用することでそれぞれの構成や要望に合わせたサービスを選び常時SSL化することができます！
まとめ
ユーザーに安心してサイトを利用してもらえるように、運営側がWebページのセキュリティを高める手段として常時SSL化は求められています。
今後もどんどん常時SSL化の動きは加速していくと予想され、HTTPSページが当たり前になる日もそう遠くないのかもしれません。
ただ、流されるままに対応するのではなく本当に対応する必要があるのか、
対応するならどの証明書がベストなのかなどサイトに合った対応方法をしっかりと考えることが重要だと思います。
今回は常時SSL化についてイベントで登壇した際の資料をベースとしています。 本記事の内容に加え、事例などを用いた対応方法も紹介していますので是非みなさまのご参考になればと思います。
www.slideshare.net
