ECサイトに限った話ではなく、何かしらの制作を行う際には機能要件と共に非機能要件を定義する必要がある。

ECサイト制作における非機能要件とは大きく分けて

• 可用性
• 性能・拡張性
• 運用・保守性
• 移行性
• セキュリティ

に分類することができる。

本記事では急激なアクセス増加などに伴う高負荷時に要求される可用性、運用・保守性を満たすに留意すべき事項と、主だったセキュリティ対策を紹介する。

高負荷対策

前提として、可用性、運用・保守性とはなんたるかを簡潔に説明すると

可用性とは

システムが継続して稼働できる能力のこと。定量的に表現したもののとして稼働率があり、これは平均故障間隔と平均修復間隔から求めることができる。関係を式で表すと

$$稼働率=\frac{平均故障間隔}{平均故障間隔+平均修復間隔}$$

となる。要するに壊れにくく復旧が速いことを可用性が高いと表現する。

運用とは

サーバーのダウンなどによる機会損失を限りなく減らし、利益の最大化を試みること。

保守とは

保守性とは障害が発生した場合に迅速に復旧できること。保守を行うということは考えうるリスクに備え対策を練り、リスクの最小化を試みることとなる。

ページ表示速度と売上の相関

サーバーに高負荷がかかったとき、完全にダウンしアクセス不可になるとまでいかなくとも懸念されるのがページ表示速度の低下だ。

表示速度が低下するとどのようなデメリットが起こりえるのだろうか？有名な数字としてECの最大手であるAmazonの統計をご紹介すると

読み込み時間が0.1秒減ると、売上が1%増加する。

これは2006年に公開された情報だが、未だによく目にする数字だ。

その他、表示速度の低下によるデメリットをまとめたものを引用すると

ページ表示速度が1秒遅くなると

• コンバージョン数が7%減少
• PV数が11％減少
• ユーザー満足度が16％減少

ページが表示されるまでに3秒待たされると

• 57%のユーザーがそのサイトから離脱
• 離脱したユーザーの内80％のユーザーは、そのサイトを再訪しない
• サイトを再訪しないユーザーの内ほとんど半分のユーザーは、そのサイトへの不満を他人に漏らす

http://bristowe.com/blog/2013/3/5/visualizing-web-performanceより引用

こちらは2013年の記事。データとしては少々古く数字を鵜呑みにするのは危険だが「表示速度の遅延がユーザーエクスペリエンスにどのような影響をもたらすのか」という点では十分に参考になるデータかと思う。

より悲観的に推測すると、Web技術の進歩により現在のユーザーは上掲のデータ以上にせっかちでワガママになっていると考えた方がいい。驚くほどリッチなサイトが驚くほど速く表示可能になってきた。そういった経験により「このサイトなんか遅い。使い勝手悪い。」と感じる閾値が下がってきているはずだ。

それにより、現在ではますます表示速度がユーザーエクスペリエンスに及ぼす影響が大きくなっていると推察される。

理想は1.4秒以内、最低でも2秒以内が目安というのが現在の通説だ。

具体的な数値の信憑性はともかく「ECサイトのページ表示速度と売上には大きな相関がある」ことは意識してECサイトは制作するべきだと考える。

急激なトラフィック増加を覚悟するパターン

あるWebサイトにどの程度のトラフィックが見込まれるか正確に予想するのは難しいが、確実に急激なトラフィック増加を引き起こす要因として

• Yahooトピックスへの掲載
• 大量のフォロワーを抱えるLINEやTwitter公式アカウントによる告知
• テレビ放送

などが挙げられる。これらは大きな拡散力を持つのでサイト運営者からしたら嬉しいことなのだが、何の対策もしていなければ負荷に耐えきれずサーバーが落ちてしまい大きな損失を生む恐れがある。

ピークが継続するのはせいぜい15分程度と言われている。逆に言えばこの15分はWebビジネスにおいて大きなチャンスなので、絶対にサーバーを落とさない対策が必要だろう。

DDoS攻撃による負荷

DDoS攻撃とはDoS攻撃を強化させたものであり、DoS攻撃が単一の端末から大量の処理要求を送りつけるのに対し、複数の端末から一斉に大量の処理要求を送りつける攻撃手法だ。

サーバーに多大な負荷をかけることによりサーバーをダウンさせ、可用性を侵害させる。

2016年ほどから1Tbps規模のDDoS攻撃が観測されている。一度ターゲットにされると40%ほどの確率で再度攻撃されるとの統計もある。

仮にサーバーがダウンしなかったとしても、AWSのような従量課金制のサーバーである場合多額の請求が懸念される。WAFの導入などによる対策が必須だろう。

代表的なサーバー負荷対策方法

前述のような外的要因による急激なトラフィック増加への主だった対処法を紹介する。

スケールアップ

メモリやハードディスクを増設、CPUをより高性能なものにすることでサーバーそのもののパフォーマンスを強化する手法。

ハードウェアの増設や交換を行うため、一時的にサーバーを停止せざるを得ないので事が起こる前に実施しておく必要がある。

※クラウドサーバーによっては無停止スケールアップが可能なものもある。

ロードバランサーを用いたスケールアウト

複数のサーバーを用意しておき、トラフィックを分散させる手法。サーバー負荷監視機能とオートスケーリング機能を用いて、ある一定の負荷に達した場合自動的にサーバーの台数を増やすなどの対策が考えられる。

しかし、前述のような「急激なトラフィック増加」の場合突然負荷が上がることになるのでサーバーの増設が間に合わない可能性がある。

そもそも常に予想される最大の負荷に耐えうるように設計しておくことも考えられるが、これは通常時においてはオーバースペックな構成を用意することになるのでコストがかさむ。

リスク管理の一環としてここに投資する手もあるが、「利益の最大化」という観点で考えると最善の選択とは言えないだろう。

CDNの利用

CDNとはコンテンツデリバリーネットワークの略で、画像・動画・音楽などの大容量のコンテンツを専用のキャッシュサーバーから呼び出すことでWebサーバーそのものへの負荷を軽減させる手法である。

負荷を軽減すると共に、コンテンツをキャッシュするので速度の向上も期待できる。

また、ユーザーから最も近い経路に存在するキャッシュサーバーにアクセスすることも速度の向上に一役買っている。以前の記事で検証したが、地球の反対側に位置するWebサーバーへのアクセスは理論値でも0.1秒の遅延が見込まれる。

AWSのAmazon Linuxに5分でLAMP環境を構築する(PHP7)

0.1秒という数値は前述の統計によると売上に1%の影響を与えるので無視できる数値ではないだろう。

 

実際にはこれらの手法を複合的に利用することになるだろうが、「急激なトラフィック増加」に焦点を当てた場合最も有効なのはCDNの利用だと考えられる。

 

セキュリティ対策

攻撃者の目的

やはり金銭目的。主に個人情報を奪取し闇ルートで売買することにより利益を得ているようだ。

単価は高くはなくクレジットカード情報1件につきせいぜい数千円程度が相場。実際に悪用できる可能性の低さを考えればそんなものかという感じもする。

ただし、ある程度の規模を持つECサイトへの攻撃に成功し、仮にクレジットカード情報を1万件入手できれば数千万円になるわけだから、利益としては十分な数字であろう。

DDoS攻撃代行なども存在する模様。これは競合となるサービスの可用性を侵害することで、自社サービスへ流用させることが目的だと思われる。

ただし、2017年末頃にニコニコ動画や北朝鮮政府公式サイトなどのサーバーを次々と落としたツイッタラーが話題となったように、興味本位や売名目的で行う者も一定数存在する。

被害額

個人情報を流出させてしまった場合、顧客に対する賠償金という形で被害が発生する。

ここで注意されたいのは「個人情報」の中身により賠償額は大きく異なってくるということだ。

日本における過去の判例を紐解いてみると、基本4情報となる「氏名、性別、住所、生年月日」だけの流出であったケースの判決として、被害者への賠償としてクオカード500円を支払うのみに留まった例がある。

これは、基本4情報は秘匿性が低い＝知ろうと思えば容易に知ることができる情報であるから被害者への実害は小さい、という解釈による判決だ。

では、どのような「個人情報」に対して大きな賠償が発生するのだろうか。

日本での個人情報の流出による賠償額の過去最高額はエステティックサロンの顧客情報流出事件によるもので、1人あたり3万円の賠償金が支払われた。

これは「スリーサイズ」や「自身の体の悩み」など、極めて秘匿性の高い情報を流出させてしまったことで被害者に大きな心の傷を与えたいう解釈によるものだ。

他にも「年収」や「学歴」などの情報も秘匿性が高いと判断され高い賠償額を課せられる場合がある。

自サイトがどのような「個人情報」を扱っているのか、運営者は正しく把握しセキュリティマネジメントを行うべきだろう。

主な攻撃方法とその対策

ここからはより具体的な攻撃方法とその対策について説明していく。

• SQLインジェクション

データベースに対して悪意のあるSQL文を実行させ、データベース内の情報を抜き取ろうと試みること。

対策としてはバインド機構を利用してエスケープ処理させれば良い。というかこれは必須事項で、まともなエンジニアであれば当たり前に対策を行うはずだ。

• クロスサイトスクリプティング(XSS)

掲示板のような入力フォームから悪意のあるスクリプトを実行させようと試みること。

&，<，>，”，’のプログラムとして意味を持つ特殊な5文字をサニタイジングすることで大体防げる。というかこれも必須。併せてWAFを導入するとより良いだろう。

• クロスサイトリクエストフォージェリ(CSRF)

ユーザーに意図しないHTTPリクエストを送信させ、意図しない処理を実行させる攻撃方法。

少々理解が難しいので、ありえてはならない極端な例を示すと

http://example.com/delete/というURLをGETするとユーザー情報が削除されるサービスがあったとして、ここへ誘導するような手法だ。

対策としてはGETを用いず、POSTする際にワンタイムトークンを仕込むというのが一般的な実装だろう。

• ブルートフォースアタック

管理画面へのログインを機械的に総当りする。類似の攻撃手法に辞書攻撃があるが、これはあらゆる文字列の組み合わせを総当たりするのではなく、よく使われがちなユーザー名やパスワードを辞書としてまとめておきこれを用いて総当たりする。

対策としては

・ありがちなユーザー名やパスワードは避ける

・推測可能なパスワードを用いない(誕生日など)

・大文字小文字数字記号などを混在させある程度長いパスワードを用いる

などが挙げられる。

が、大文字小文字数字記号を混在させることは実は無意味だったと昨年話題になった。考えてみれば当たり前で、人間が手入力でパスワードを探るのであれば意味があるだろうが、機械的に総当たりする場合記号だろうが大文字だろうが関係ないのだ。

今、推奨されているのは適当な文章をパスワードにしてしまうことだ。忘れにくい上に強度も高い。

例えば「私は今ブログを書いています」という文をローマ字表記にすると

「watashihaimaburoguwokaiteimasu」

という30文字のパスワードが得られる。

このパスワードがどのくらい強力か概算すると、ローマ字小文字のみを用いた30文字の文字列の組み合わせは26^30で2813198901284750000000000000000000000000000通りある。命数法で表記すると281正3198澗9012溝8475穰という厨二病感溢れる大きさだ。

一方、大文字小文字数字記号を混在させたパターンだと使える文字は94種類ある。比較対象としてこちらの94種類を用いた16桁のパスワードを適当に生成すると

「)V8Mzzj&x~o(sHyc」

のようなものが得られる。このパスワードを簡単に覚えられる人はまずいないだろうし、一見すると非常に強力そうである。

しかし、組み合わせ数を計算すると94^16で37157429083410100000000000000000通り。前述のパスワードの10億分の1程度の強度しかないことになる。

前述のローマ字小文字のみの30文字のパスワードを上回る強度を持つ大文字小文字数字記号を混在させたパスワードを生成したければ最低でも22文字必要となる。

「Xm_en_zvavB8o4NRT_!u1d」

このようなものだ。余裕で覚えられるという宇宙人はこちらを採用すればいいでのはなかろうか。

理論上「適当な文章をパスワードにする」というのは正しいのだが、この考え方が浸透するにはまだまだ年月がかかるだろう。例えばクライアントになんらかのパスワードを提示する時に

「パスワードはこのメールのタイトルをローマ字入力したものです」

などと示す勇気は私にはない。「x&Cuk4u+」のような10垓分の1程度の強度しかないパスワードの方を無難に選択するだろう。

• ソーシャルエンジニアリング

そもそもコンピュータを用いて機械的な攻撃を試みるのではなく、物理的または心理的にパスワードなどの機密情報を入手するやり口のこと。

例えば社員になりすまし、「パスワード忘れちゃったんで教えてもらえませんか？」などと言いパスワードを入手するなどだ。ゴミ箱を漁って機密情報が書かれたメモを探し出すなんてこともありえる。

上述のような様々な施策を打ったところで、マスターのパスワードが漏れてしまえばなんの意味も持たない。ある意味最強の攻撃方法と言えるだろう。

対策としては、これはもう社内教育を徹底するしかないだろう。パスワードはどんなことがあっても人には教えない、機密情報が書かれたメモはシュレッダーにかける、背後には気をつける。などスパイめいてくるが機密情報を扱う者の責務として細心の注意を払おう。

より簡単にできる対策

使用しているCMSやミドルウェアはこまめにアップデートし最新のものを使うこと！

なんだそんなことかって感じがするが非常に大事なことだ。特に技術的知識がない人でも、使っているCMSなどに対してこれを行うだけで飛躍的なセキュリティの向上が望める。

手動でこまめにチェックするのが面倒なら脆弱性自動チェッカーなども存在するので、導入してみてもいいだろう。

 

終わりに

お洒落で、見やすく、使い勝手のいいECサイトを作り、広告も十分に打ちユーザーを集めることに成功したとしても、そのサイトが遅かったりすぐ落ちてしまったりするようではECサイトとしての成功は見込めないだろう。

大量のアクセスに強く、セキュアなECサイト作りはECサイト制作.comにお任せください。

無料お見積もりはこちらから！