最適なSSL/TLS化の設定ガイドライン

  Googleがhttps化(SSL/TLS化)されていないWebページについて「Not secure」メッセージをChrome上で表示させる取り組みがいよいよ7月にスタートします。今後httpの場合にはアラートメッセージがもれなく表示されることになります。   そこで、これからはログインなどの入力フォームを利用していない単純なホームページであっても、基本的にhttpsに対応しておく必要があるでしょう。   SSL/TLS化する際にネックとなる複雑な問題については、以前のブログで解説をしていますので、是非そちらをご覧ください。(https://www.cdnetworks.co.jp/blog/6144/)   SSL/TLS化については、特にSSLサーバ証明書(certificate)の準備からプロトコルおよびcipher(暗号)の設定が複雑です。そこで本ブログでは、SSL/TLS化の設定時に最適なSSL/TLSプロトコルおよびcipherの設定構成について解説します。     無料でApache WebサーバにSSL/TLSサーバ証明書を構築する   SSL/TLSの利用には、まずSSLサーバ証明書の設定から始めなければなりません。ただし、同時にCDNを利用する(している)場合には、比較的簡単にこれを構築することができます。   Webサーバ(オリジン)に直接httpsを構築するには、comodoやdigicertのようなSSLサービス(暗号化通信)の利用が一般的ですが、最近はほぼすべての最新ブラウザとの互換性を維持しつつ無料でサービスを提供するLet’s Encrypt(https://letsencrypt.org/)を利用するケースが急増しています。   <画像1>   ここではApache Webサーバを運用する前提で、Let’s Encryptを設定する方法について解説します。 Let’s Encrypt を利用してSSLサーバ証明書を設定する方法はとても簡単です。まず、gitで関連ファイルをインストールしてスクリプトを実行するだけで完了です。    git clone https://github.com/letsencrypt/letsencrypt  cd letsencrypt/  /etc/init.d/httpd stop  ./letsencrypt-auto certonly –standalone  vi /etc/httpd/conf.d/ssl.conf  /etc/init.d/httpd start <表1>   次に<表2>は、viでssl.confを設定する際に、追加する必要がある内容の例です。 <表1>のスクリプトで生成したSSLサーバ証明書関連ファイルの場所を「SSLCertificate*」の指定子で指定します。    <VirtualHost www.example.com:443>  ErrorLog logs/ssl_error_log  TransferLog logs/ssl_access_log  LogLevel warn  SSLEngine on  SSLProtocol TLSv1.2 -SSLv2…

ワンタイムパスワード(OTP)、 今すぐ使い方をマスターしよう

  私たちはインターネットで銀行振込サービスを利用する時や株の取引をする時など、重要な作業をする時にワンタイムパスワード(OTP)を使用します。たまに不便を感じたりもするOTPは、絶対に使わなければならないものなでしょうか?   答えは「Yes」です。しかも「今すぐ」にです。   本ブログでは、なぜOTPを使わなければならないのか、そしてCDN利用時におけるカスタマーポータルサイトへアクセスする際のOTPの使い方についても解説します。     完璧なセキュリティ対策はない   もし、今この記事をお読みになっている皆様のパソコンやスマートフォンの画面を、自分だけでなく他人が遠隔で一緒に見ていたとしたらどうでしょうか?また、ログインをするために自分が入力したID/PWの情報がリアルタイムでハッカーの画面にも転送され表示されていたとしたら?   もしや、最新バージョンへのセキュリティパッチを済ませているから、シマンテックのようなアンチウィルスソフトがインストールされているから、「私は絶対に大丈夫」と思っていませんか?もちろんある意味それは正しいですが、必ずしもそれで完璧だとは言えません。   なぜなら、パッチが公開済のセキュリティ脆弱性のみならず、まだ知られていないセキュリティ脆弱性(これを「ゼロデイ」と言います)も世の中にはたくさん存在するからです。もし「我が社のセキュリティ対策は完璧で安全だ」としても(絶対そんなことはありえませんが)、巧妙に偽装された偽サイトにアクセスし誤ってあなたのID/PWを入力してしまったり、さまざまな社会工学的(Social Engineering)技法を通じてあなたのID/PW情報を攻撃者が奪い取る可能性もあるためです。この場合、どんなに難しいパスワードの設定をしても意味がなく、結局のところ完璧なセキュリティ対策は存在せず、追加対策が必要と言えるでしょう。     正解は2要素認証(2Factor Authentication)を使用する方法   既存のID/PWは1要素認証(1Factor Authentication)と言い、これにOTPなど追加認証を結合したものを「2要素認証」、または「2ステップ 認証」と言います。最近では「トリプル認証(Triple)」、または「多要素認証(Multiple Factor)」や「マルチステップ認証」という言葉も使用されています。   概念としては次の画像のように、すでに知っているもの (ID/PWなど)以外にもIDを所有している本人であることを追加で認証できるツールで認証することを意味します。例えば指紋や虹彩(目)のような生体認証や所有するスマートフォンを通じた使い捨てパスワードの発行(OTP)などです。     画像 : 多要素認証の概念     OTPのメリットとは   ではOTPはどんな「メリット」があるのでしょうか。   1、パスワードは一定時間(30秒程度)のみ有効で再使用ができないため、万が一情報が漏れても安全 2、一般的なデジタル認証に比べて安価 3、時間同期化方式(TOTP:Time Based OTP)※1、およびイベント基盤(HOTP:HMAC Based OTP)※2の両方に対応、ほとんどがTOTPを使用 4、スマートフォンアプリなど別のデバイスを利用したH/W OTP※3の場合には無料で使用できるので便利かつ安全   ===== ※1 一定時間(30秒程度)が経過するたびに新しいOTPが生成されるアルゴリズムで、一定時間が過ぎると使えなくなり、改めて生成したOTPを使用しなければならない方式 ※2 イベント基盤のアルゴリズムでログインするたびに新しいユニークなパスワードを生成する、クリックして生成されたOTPをパスワード入力枠に入力して認証を受ける方式 ※3 APP利用ではなくデバイスを利用する、デバイスの購入が必要で値段が高い上に紛失の恐れがあり不便と言われている方式 =====     CDNetworksは、PCI DSSのセキュリティポリシーに基づき、すでに数年前からなどにアクセスする場合に、既存のID/PW/IP/Keyなどいくかつの要素に対する認証を行っており、その他にも追加でOTPを使用して厳格にアクセスコントロール・ポリシーを守っています。  …

近づくEUのGDPR施行、日本への影響と準備すべきWeb対策ガイドラインとは

  “GDPR”という言葉を聞いたことがありますか?   EU(ヨーロッパ連合)ではヨーロッパ市民の個人情報保護およびデータ セキュリティのために2018年5月25日よりGDPR(General Data Protection Regulation、一般個人情報保護規則)の適用が予定されており、もしこれに違反した場合、企業は最大で全売上の4%または€20 million(20億円)の罰金を支払うことになり、特にインターネットサービスおよびビジネスを展開している企業にとっては大きな課題となっています。   その内容は下記のようなものです。  - 個人情報の範囲は会員情報だけでなくWebサーバのログなども対象となる  - 会員から要請があった場合、即時に個人情報すべてを提出したり削除しなければならない  - 会員情報の漏洩などセキュリティ事故が発生した場合、72時間以内に被害対象および関係機関に報告しなければならない  - これに違反した場合、定められた罰金を支払わなければならない   今回はもうすぐ施行されるGDPRに関して、日本への影響とその対応策について、CDNetworksで今準備していることと今後の計画について解説することで、皆様がこれに備えるために何が必要で今後どう向き合えばよいのかについて、考えるヒントとなれば幸いです。       1.CDNetworksセキュリティファースト   GDPRは、EUでビジネスをしていないからといって対象外にはなりません。社内でEU圏出身の社員がいたり、フランスやドイツなどEU加盟国の会員情報を保有していたりサービスを提供している場合は、GDPRの対象になるため、実際はほとんどのB2C企業はGDPRの影響を受けると言えるでしょう。   CDNetworksは、ヨーロッパに自社法人を置いており、現在も多くのヨーロッパ のお客さまに安定的かつパフォーマンスに優れたCDNサービスを提供しているため、今回のGDPRの対象企業となります。   CDNetwokrsでは、2017年の早い段階から新たな個人情報保護規定に関する検討や準備を進めており、最近では著名なセキュリティコンサルティング会社であるBSIグループと共同でGDPR施行に向けた準備のためのセキュリティ・コンサルティング・プロジェクト(以下、プロジェクト)に取り組んでいます。   またCDNetworksでは、CDNサービスを利用するお客さまのセキュリティ対策が最も重要という原則の下で、GDPRの施行に対してただ新しい規定に遵守するためだけでなく、これを大切な個人情報をより安全に保護するためのよい機会と捉え、全社員が積極的に準備に参加しています。それは例えば次のようなものです。   画像 : https://www.gdpreu.org/ では適用日まで残り少ないことを表しています     2.GDPRに対する認知向上と備え   まず、プロジェクトの始めに主要社員に向けてGDPRについてレクチャーすることで認知向上を図る活動をしています。さらに、社員の個人的な人事情報、CDNサービスを利用するお客さま情報、そして一般サイト訪問者(ユーザ)に関する各種個人情報をまとめたリストを作成し、それぞれの情報について流れ(フロー)を把握してまとめています。   このような情報に対してリスト化が先行することにより、何を準備して何を改善すべきかが明確になります。このリストの準備が完了したら、次に組織に見合う技術的な保護措置が必要です。   画像:: 特定サービスのデータフローの例   CDNetworksでは、CDNサービス提供においてすでにPCI DSS レベル1 およびISOと同レベルのK-ISMS認証を毎年取得ならびに維持して常時保護しているため、現在の技術レベルでも十分な状態にあると判断できます。一方でデータの保存・管理・転送をより安全に行う方法はないのか、アクセス統制およびセキュリティポリシーに改善が必要な部分はないのかなど、さまざまな角度からの分析・検証も行っています。また、もしものセキュリティ侵害が発生した時のために、対応プロセスおよび管理対策についても改めて検討しています。   CDNetworksでは、次の原則に従って内部規定およびプロセスを検討しています。   – 個人情報の最小化 (data minimization) 必要により個人情報を収集する際には必ず必要な情報だけを収集します。…

SNI、なぜこれ以上適用を遅らせられないのか

  httpsを検討しているユーザはSNIという用語はよく耳にすると思います。   本ブログでは、https有効化のためのSSL/TLS証明書を適用する際に必ず知っておくべきのSNIの定義と、なぜ適用しなければならないのかについてお話したいと思います。     1.SNIとは?   SNIは Server Name Indication の意味でHTTPSで使用するName基盤のバーチャルホスト 機能と考えてください。(https://en.wikipedia.org/wiki/Server_Name_Indication)   HTTPでは、HTTP/1.1が導入されて以降、下記のように1つのIP(172.20.30.40)に複数のドメインのバーチャルホスティングが可能となり、多くのWebホスティング会社ではこの機能を利用して以前からWebホスティングサービスを提供しています。   NameVirtualHost 172.20.30.40   <VirtualHost 172.20.30.40> DocumentRoot /www/example1 ServerName www.example1.com </VirtualHost>   <VirtualHost 172.20.30.40> DocumentRoot /www/example2 ServerName www.example2.com </VirtualHost>   HTTPSでも、SNIというTLSの拡張機能を利用して似たような方式でサービス適用が可能ですが、各ドメインごとにSSL/TLS証明書を設置する必要があるため、やや複雑な過程を経る必要があります。   つまり、HTTPは3 way ハンドシェイク後にホスト・ヘッダーを通じてクライアントがアクセスしようとするドメインをすぐに認識できますが、HTTPSの場合は3 way ハンドシェイク後にTLSハンドシェイクを行い、その後アクセスしようとするドメインに対してホスト・ヘッダーが伝達されるため、暗号化されたプロセスによりクライアントがアクセスしようとするドメインをすぐに認識できない問題があります。結局1つのIPで1つのSSL/TLS証明書のみサービスができる構造のままのため、多くのIPを消耗してしまう問題が発生します。   このような問題を解消するために、2003年rfc3546を通じて初めてSNI機能が提案され、現在はrfc6066にアップデートされています。これを通じてクライアントはTLS交渉のクライアント Hello 過程でアクセスしようとするドメイン情報をプレーンテキストで伝達することによって認識可能になり、SSL/TLSサービスにおいてもバーチャルホスティングが可能になりました。   次の画像はPCで https://www.cdnetworks.co.jp/ にアクセスする時のパケットのキャプチャですが、SNI関連情報をプレーンテキストで見られることを確認できます。   画像 : SNIパケットのキャプチャ   LinuxやMacOSがあればopensslコマンドでも簡単に確認することができます。 (バージョンによってオプションは異なる可能性があります)   ex) SNIに対応する場合 ::…

近づくSSL/TLS リスク、どう対応するのか

    最近、IT関連メディアでよく目にするニュースがあります。   それは、Chromeブラウザを提供しているGoogleが、2018年7月からはHTTPSでないすべてのHTTPサイトに対し、Chromeブラウザで「Not secure」メッセージを表示させることを明らかにしたことです。今まではHTTPでもログインなどの入力フォームがある場合のみ表示させてきましたが、これからはHTTPであればすべてアラートメッセージを表示させるということになります。   参照元 : Google 告知: https://security.googleblog.com/2018/02/a-secure-web-is-here-to-stay.html   Google Chromeに続いて他のブラウザもこのポリシーに従うと予想されますが、ただ、日本国内においてはGoogle Chromeブラウザのシェアが40%を占めているため、このポリシー変更の影響は少なくないと思われます。「個人情報や重要なデータを扱っていないからHTTPで問題ない」と考えているWebサイト担当者がいれば、これからは真剣にHTTPSへのサービス転換を準備する時期に来ていることを認識すべきです。   ところで、HTTPSへ切り替えるためには考慮すべき点が多く複雑ですが、この解決にはCDN(コンテンツ・デリバリ・ネットワーク)の導入をお勧めします。   そこで本ブログでは、なぜCDNの導入が確実で簡単な解決策になれるかをお伝えします。     1. HTTPSはHTTPに比べパフォーマンスに大きな影響を与える   HTTPSはクライアントとサーバの間の通信でcipherや証明書の交換などはるかに多いプロセスを処理するためHTTPに比べて遅くなりがちで、Webサーバに何倍もの負荷を発生させます。   例えば下記のイメージはwww.cdnetworks.co.jpから小さいイメージファイル1つをダウンロードするプロセスですが、既存のHTTPより多くの過程が必要ということが分かります。また、各々の通信では転送データの圧縮や暗号化・復号化を繰り返し行うため多くのリソースが必要とされます。     従って既存のHTTPのみでサービスを運用している場合、今後はこれまでの何倍ものWebサーバやロードバランサなどのIT設備を準備する必要に迫られます。   しかしCDNを利用すればこれらすべてをCDNプラットフォームで処理するため安心です。   実際にCDNetworksのお客様の中では、イベントがあるたびに予約が集中しサーバが耐え切れず、Webサイトが遅くなったりエラーが頻繁に発生したりなどユーザからの不満が多く発生していましたが、CDNサービスを導入してからはいつでも安定、かつ快適にサービスを提供できるようになり顧客利用満足度が上がった事例が多くあります。   また、CDNを導入すればend to endまですべてのプロセスを HTTPSでサービスすることが可能で、クライアント <—-> CDNプラットフォーム間はHTTPSでサービスしつつ、CDNプラットフォーム<—> お客様のWebサーバの間はHTTPでサービスすることも可能なため、お客様のニーズに合わせて柔軟にさまざまな設定ができます。     2. 複雑なSSL/TLSの証明書やcipherを常にチューニングしなければならない   SSL/TLSを適用しただけでWebサイトの安全性が確保されたということではありません。   SSL/TLSでもSweet32、DROWN、FREAKなど用語も難しく理解しづらい新しいセキュリティ脆弱性が次々と公開されています。   また、セキュリティ・コンプライアンスのためにSSL/TLS プロトコル・バージョンもマッチさせる必要があり、RC4のような脆弱性のあるcipherを無効にしないとウェブサイトの評判が悪くなる課題もあります。   さらに、セキュリティを強化するために強力なcipherだけを有効にすると、まだアップグレードしていない古いバージョンのデバイスやブラウザのユーザはWebサイトにアクセスすらできないなど、きちんと管理しなければむしろ多くの問題を発生させることになります。   https://www.ssllabs.com/ssltest/ を見ると、直接自分のHTTPSサイトに対し評価したり、さまざまなサイトの成功・失敗事例を比較することもできます。   2018年月現在ssllabsの画面    さらにSSL/TLS証明書の場合は、毎年契約満了日前に契約更新しなければなりません。…

PCI DSS レベル1 、7年連続認定の意義

  CDNetworksは7年連続でPCI DSS(※1)の最高レベルであるレベル 1 認定を受けました。 >>2017年10月13日 プレスリリース >>PCI DSSレベル1認定証   特に今回は、v.3.1と比較してより厳しい取得条件が課されているv3.2(※2)を適用しています。 この連続取得の背景には、CDNetworksが社会的に最上級のセキュリティ要素の1つであるクレジットカード決済において、標準化されたプロセスと高度な技術水準のセキュリティ対策で、高い信頼性の下に利用できる環境を維持・提供していることが挙げられます。   そこで本ブログでは、PCI DSS認定を維持するためのCDNetworksの日々の取り組みについて簡単にご紹介します。   毎週/セキュリティ会合の開催   毎週開催されるセキュリティ会合を通じて、情報セキュリティチーム以外にもIT室長、研究所長、サービス本部長などが最新のセキュリティ動向を共有しつつ、解決すべき問題点について論議および決定をしています。会議では中心メンバーが参加することで、早い決定と実施が遂行されています。このセキュリティ会合は、数年間に渡って着実に運営され続けているものです。   毎月/セキュリティチェックキャンペーンを実施   セキュリティはソリューションではなく装備でもありません。結論、”人”です。 いくら高価な装備やソリューションを導入しても、社員一人ひとりのセキュリティ対策の心構えが整っていなければ、“自分は問題ない”と考えるものが現れ、その小さなほころびは事故 (インシデント)へと繋がります。   毎月1回、CEOを含めたグローバル全社員を対象とした、最新のセキュリティパッチの適用やアンチウィルスソフトウェアのアップデートなど、各々が利用しているPCのセキュリティレベルのチェック&確認を全社員が実施しています。このセキュリテチェックの結果情報に基づき、各オフィス、並びに個人ごとの達成度や迅速に対応したかなどを調査・分析し、毎月統計結果を公開しています。もちろん、すべてのプロセスを自動化し、社員にセキュリテチェックをさせないことも可能ですが、この方法は”セキュリティチームがやってくれるから私は関係ない”という思考に陥りがちで、むしろ危険です。   毎月/クリーンデスクキャンペーンを実施   毎月1回、社員が退社後の時間帯にセキュリティチームメンバーが社員の席を見回り、物理的なセキュリティポリシーを社員が守っているかどうかを目視で確認しています。 例えば、デスクにラップトップやお客様情報などの重要な機器や書類を放置したまま帰宅していないかどうか、引き出しには鍵がかけられているかどうかなど、全10項目のチェックリストを確認し、守られていない社員には“警告状”をデスク上に置いて指導を行っています。   画像:クリーンデスクキャンペーンのイメージ   継続的/厳格なネットワーク分離運用   いくら最新のセキュリティパッチやセキュリティ装備でモニタリングしても、まだ公開されていないゼロデイ(未知)の脆弱性は存在しており、ネットサーフィンやメールを通して知らないうちにマルウェアに感染したりするものです。   CDNetworksの技術チームは、このような問題を解消するために、物理的なネットワーク分離を実施してサービスを運用しています。これは、CDNプラットフォームにアクセスするためには、インターネットに接続されていない専用のデバイスを利用してアクセスする仕組みです。つまり、物理的にネットワークが分離されているため、もしインターネットに接続している既存のPCがウィルスに感染したとしても、CDNのサービス運用に影響が及ぶことはありません。もちろんアクセスできるユーザは厳格な認証プロセスに添って特定社員のみに限定されており、単純なID/PWだけでなくPKI Key、OTP Keyなど複数の認証を経てアクセスすることができます。   継続的/内部アクセス時にMulti Factor Authentication(MFA)を適用   前述したCDNプラットフォームはもちろん、その他の管理や運用ページなど、内部の主要コンテンツにアクセスする際にはOTP(※3)として代表的なMFA(※4)を導入しています。これを通じて、もしID/PWが外部に漏れる事故があったとしても本人でない場合には、認証を迂回して内部システムにアクセスしようとする行為自体を遮断することができます。これには、OTP発行・解除・再発行などの管理に対して厳しいプロセスに従ったモニタリングおよび運用の実施が必要であり、CDNetworksでは定期的に権限をレビューして変更事項を即時反映しています。   画像:OTP認証作動方式のイメージ   随時/セキュリティ点検 (Security Scan)     前述した定期的なセキュリティチェック以外にも、セキュリティチームではさまざまなソリューションを活用して内部コンテンツおよびサービスインフラに対して脆弱性点検を定期/不定期で実施しています。 例えば、外部に知られたポートはないか、パッチされていないバージョンの低いデーモン(※5)を利用していないか、問題になりそうな点はないかなど、攻撃者の観点から脆弱性を見つけ出し、該当の部署に知らせて即時解決するよう働きかけを実施しています。   また、システム 運営者がデータセンターに装備を設置する際にも、サービス開始前に必ずセキュリティチームからスキャン完了…

CDNによる災害復旧、BCP対策

CDNサービスを使えば、ウェブサイトの災害復旧対策にかかるコストや工数を削減できる可能性があります。   大災害によるウェブサイトへの影響 2011年8月、アメリカ東海岸を巨大なハリケーン「アイリーン」が襲いました。6つの州で停電が起こり、多くの人が数日間電力を使えない状況となりました。 事前にニューヨークへの上陸が予測されていたため、事前に災害対策をとっていた企業のIT担当者はそのまま本来の業務に集中し続けることができましたが、そうでない担当者には多大な負担を強いるものでした。   同じ年の3月に、日本でも大きな地震とそれに伴う津波が発生しています。こうした自然災害によって起こるウェブサイトやウェブインフラへの影響は、停電だけではありません。災害が起こると、政府や復旧支援活動を行なう組織のウェブサイトには通常では考えられないほど多くのアクセスが集まります。そこにはユーザが知るべき重要な情報があるからで、これらのウェブサイトでは情報の発信を止めるわけにはいきません。   災害対策とクラウドサービス 災害対策のためにクラウドサービスを選択する企業も増えています。クラウドサービスの中には、グローバルなCDNサービスと同様、世界中にインフラを分散配置しているものもありますが、そうでないものもあります。 アメリカのウェブメディアで以下のような指摘がなされたことがあります。 「クラウドサービスプロバイダを選ぶ際には、どこにプラットフォームの配置拠点があるかを確認するべきだ。もしすべての拠点が同一の電力源を利用しているようなら、そのサービスを使ってはいけない。」 これに対し、DRI、ディザスタ・リカバリ・インスティテュート・インターナショナルの役員が賛同して次のように述べました。 「遠く離れたデータセンタに複製を置いておけば十分と思うかもしれないが、元のデータと同じ電力源を使っている可能性もある。」   CDNによる災害対策 CDNサービスは、世界中に分散配置されたプラットフォームを使い、常に冗長化されています。各データセンタは多くの国、複数の大陸にまたがっているため、全てのプラットフォームが同じ電力源を利用しているということはありません。 ウェブサイトの災害復旧対策をお考えの方は、是非一度CDNサービスをご検討ください。   >> 自治体・官公庁向けCDNソリューション

モバイルフレンドリーなECサイトを作り上げるために必要な5つのこと

注 本記事は、米国CDNetworksより、EC向けニュースや情報発信をするウェブサイトである「Internet Retailer」に対して提供された記事を日本語に翻訳したものです。   モバイルユーザにとって使いやすいサイトは、シンプルで整然としています。そして、読み込みに時間がかかりません。ここではこれらをどのように成し遂げるか、その秘訣を紹介します。 ここ10年ほどの間にスマートフォンは爆発的に普及し、私たちの生活や仕事、そしてほとんどの業種において、事業に変革をもたらしました。ユーザが長く滞在し購入をしてくれるような競争力のあるECサイトでありたいと考えるならば、ページの読み込み時間が速いことは特に重要です。   2014年10月時点で、米国居住者の64パーセントがスマートフォンを保有しています。そのため、スマートフォン上で消費者との接点を開発していくことはとても重要になってきており、実現するための手段はモバイルアプリ、テキストメッセージ、メールマーケティングと多岐に渡っています。 しかし、最先端のマーケティング施策を取り入れる前にまず取り組まなければならないのは、ウェブサイトをモバイルフレンドリーにしておくことです。これは、カスタマーエクスペリエンスの観点から重要であると同時に、Googleの検索結果において上位に表示されるようになるためにも重要なことです。 2015年4月、Googleのアルゴリズムにおいて、モバイルフレンドリーであるかどうかが評価ポイントの一つとして採用されました。レスポンシブデザイン、動的な配信、またモバイル用にサブドメインを用意して別のサイトを構築するなどいくつかの方法はありますが、何らかの方法でECサイトをモバイルフレンドリーにする必要があります。 加えて、スマートフォンを利用するECユーザは、自分に合っていて、速くて、使い方のわかりやすいウェブサイトを求めています。その要求に応えたEC事業者だけが、彼らからの報酬(売上)を得ることができるのです。――NetElixirの調査によると、スマートフォン対応しているECサイトとそうでないECサイトを比べると、スマートフォン対応しているECサイトのコンバージョン率は1.6倍も高いそうです。(注 引用元: Mobile Shoppers convert 160% more often on sites optimized for smartphones ) これらの統計からもわかるように、本当にモバイルフレンドリーなウェブサイトには、多くのアクセスが集まり、収益力も高まります。もし既にモバイルフレンドリーなウェブサイトをお持ちだとしたら、それは素晴らしいことです。もしそうでないなら、すぐに取り組みを始めましょう!   チャネルを通じた一貫性 モバイルフレンドリーなウェブサイトは、企業のブランドと事業を体現するものです。モバイルを利用したサイトの訪問者にも、他のチャネルと同じクオリティのユーザエクスペリエンスを提供する必要があります。ユーザエクスペリエンスのコンサルタントであるThe Nielsen Norman Groupの分析・発表によると、一貫性は、クロスチャネル・エクスペリエンスを成功に導く4つの重要な要素のひとつだということです。この調査では、モバイルでもウェブでも変わらないユーザエクスペリエンスを提供する企業は、顧客からの信頼と良好な関係を得ることができるであろう、と報告を結んでいます。リサーチャーは、「ひとつひとつの接点はユーザが企業との間に築き上げるユーザエクスペリエンスの一部です。ユーザエクスペリエンスがチャネル別に分断されていたら、ユーザはその企業の信頼性に疑問を持つでしょう。」と述べています。 ルック・アンド・フィールや機能がPC向けウェブサイトと変わらないモバイルプラットフォームを持つことはとても大切なことです。また、ユーザにとってさらに重要なことは、必要な機能をPCでもモバイルでも同じように使えることです。顧客が買う準備ができた時には、それがスマートフォンであろうと、お店であろうと、デスクトップコンピュータであろうと、企業は完全なユーザエクスペリエンスを提供する必要があるのです。   ユーザのためのデザイン モバイルフレンドリーなウェブサイトは、明確な特徴を持っています。デザインが整理されていて、シンプルで、機能的なのです。Googleは、検索アルゴリズムがモバイルフレンドリーなサイトに対して何を求めているか、次の画像を使って説明しています。 Googleは、モバイルフレンドリーアップデートのゴールを次のように設定しています。「このアップデートは、ハイクオリティで適切な検索結果を作り上げることを目的にしています。つまり、テキストはタップやズームをせずとも読みやすく、リンクボタンが適切に配置され、表示できないコンテンツがなく、水平方向のスクロールを行う必要もないウェブサイトをユーザに提供することです」。こういったユーザエクスペリエンスを提供することは、お客様に対する優れたサービスのひとつであり、Googleモバイル検索結果における順位を上げるだけでなく、モバイルサイトのコンバージョンを増やすことにも繋がるでしょう。 ヒント: ・ ウェブサイトの読み込み時間を短くするために、大きく容量の重い画像や写真を削除しましょう ・ CTAボタンやリンクを、指でタップしやすいよう大きくしましょう ・ 本当に必要なカテゴリだけをグローバルナビゲーションにしましょう ・ テキストは要点を絞りましょう さらに、顧客や見込み顧客が貴社のモバイルサイトを使う最も一般的な場面を想定しましょう。価格を確認しているのでしょうか?実店舗を探しているのでしょうか?カスタマーサービスの電話番号を探しているのでしょうか?こういった想定のもと、必要な機能をモバイルサイトに実装していきましょう。   購入プロセスを簡単に ECサイトにとって究極のゴールは、商品を買ってもらうこと――つまり訪問者を売上に転換、コンバージョンさせることです。購入、はその重要な最後のステップですが、結果論になりがちです。 参考: 最近の調査では、平均してショッピングカートの68%は完了されていません。簡単でセキュアな購入完了プロセスを作ることで、この数字を少しずつ減らしていきましょう。 購入プロセスは可能な限りスムーズに、流れるように進まなければなりません。なぜなら、モバイルユーザは絶え間なく動いているからです。今ミーティングの合間かもしれませんし、病院の待合室、もしかしたら通勤の合間かもしれません。彼らはものごとを速く、直ちに完了させたいため、購入プロセスがシンプルであり、なるべく障壁が少ないことを望んでいます。 ワンクリック購入オプションや、複数ページにまたがらず1ページをスクロールすればよいだけの購入フォームは理想的です。また、ショッピングカートがどのチャネルでも連動して使えたら、企業のウェブサイトをマルチチャネルで使っているユーザにとって、それは大きなアピールになりますよね。   速いこと。高いパフォーマンス ウェブパフォーマンスの重要性は、いくつかの統計値を見ることで簡単に理解することができます。Kissmterics.comが発表している以下の数字をご覧ください。 ・ 47%の消費者は、ウェブページは2秒以内に表示されることを期待している ・ 40%のユーザは、3秒以内にウェブサイトが表示されなければ離脱してしまう ・…