見出し画像

シャープの「マスク購入希望者殺到でIoT家電にも影響」はAWS Shieldか

塚本 牧生

先日、一般販売が開始されたシャープのマスクは、同社ECサイトのダウン、さらにアカウント管理を共有していた同社IoT家電の不調にもつながりました。当初は過負荷に耐えられなかったのだろうと思っていましたが、徐々に情報が出てくるにつれ、AWS Shield StandardによるDDoS誤検知だった可能性がないのか気になり始めました。シャープの件が該否どちらであったとしても、「AWS Shield StandardによるDDoS誤検知」という可能性とその対策はこの先考えていかないといけなそうに思われます。。

マスク製造開始からIoT家電不調まで

シャープがマスクを製造と報じられたのは3月24日。当初分は政府に納入、一般販売はその後とされ、3月31日には第一便の出荷が（経産省公式アカウントで）ツイートされました。4月1日にはマスク製造を事業化し健康関連分野進出の足掛かりにするとの発表もあります。

4月20日、翌日から一般販売開始とツイート。そして翌21日、公式アカウントがこうつぶやきます。

マスク販売ページがアクセス困難、アカウント作成の確認メールが届かないなどに加え、同社のIoT家電にも影響が出た、スマホアプリからIoT家電を操作できないと報じられました。

IoT家電への影響波及についてはより踏み込んだ後続記事も複数出ており、ECサイトとIoT家電アプリがともに認証機能として利用していた「COCORO MEMBERS」への接続障害のようです。この原因は想定外のアクセス量に対してファイアウォールが動作し接続できない状態にしたものということで、各記事おおむね一致しています。

疑問点1：誰のデータセンターでのできごとか

ここで私が気になっているのは、この「ファイアウォール」というのが、誰の管理しているものかという点です。まずシャープは、今回の原因を「データセンターのファイアウォール機能」と表現しているようです。また「DDoS/サイバー攻撃と誤認」したというニュアンスの表現も複数の記事にあります。

シャープでは、同社データセンターにおけるファイヤーウォール機能が原因の1つであるとの見方を明らかにした。（PC Watch）
予想を上回るアクセス数に対して、データセンターのファイヤーウォール機能が働き、サイトにつながらない状況になったという。（ASCII.jp）
ファイアーウォールは、｢その企業のサービスとして想定し得ない量のアクセス｣を、DDoS攻撃と認識して止める。今回は、その｢想定し得ない量のアクセス｣が会員制ECサイト｢COCORO MEMBERS｣に集中した。結果、ファイアーウォールは、殺到する購入希望者をサイバー攻撃と誤解し、サービスを止めてしまった…というのが真相だ。（Business Insider Japan)
システム障害の原因として、セキュリティーシステムがサイバーテロと認識して通信を遮断したのではともみられている。（日刊スポーツ）

このファイアウォール機能を提供しているデータセンターは、誰のものだったのでしょうか。この点、各記事は見解が分かれます。

シャープでは、大阪・堺のグリーンフロント堺に自社データセンターを持ち、同社サイトの運営や各種クラウドサービスの提供しているが、これらのサービスに同じプラットフォームを利用していたことが影響したものとみられる。（ASCII.jp）（※大河原克之氏執筆）
ジャーナリストの大河原克行氏の取材記事によれば、シャープのAIoTプラットフォームは大阪・堺データセンターのインフラを活用しており、AIoT家電以外にもオフィス向けのサービスや他社サービス・機器に対して、COCOROサービスプラットフォーム事業を提供することを考えているそうです。（マイナビニュース）
シャープでは、本社がある大阪・堺のグリーンフロント堺にデータセンターを自前で持ち、さまざまなサービスを同データセンターから提供している。ECサイトにつながらないという状況や、AIoT家電への影響は、同データセンターとも関連がありそうだ。（PC Watch）（※大河原克之氏執筆）
シャープのネットワーク家電サービスである｢COCORO＋｣は、コアがアマゾンのクラウドインフラサービスである｢AWS｣で動いており、混雑に合わせた対処には、本来比較的強い。（BUSINESS INISDER JAPAN）

上記の通りグリーンフロント堺のシャープ自社所有のデータセンターとする記事が3本と、AWSとする記事1本があります。ただし前者はいずれも大河原氏執筆または同氏の記事を参考にした記事なので、ソースは同一。後者はソース不明ですが、AWSが公開しているCASE STUDYを読むとCOCOLO+がAWSを利用しているのは間違いなさそうです。ただしその中で、COCOLO MEMBERSがどちらのデータセンターにあるのかは依然明確になりません。

疑問点2：誰のファイアウォールが働いたのか

AWSでは、データセンター側の機能としてネットワークレイヤー3と4でのDDoSからの保護が行われます。これはAWS Shield Standardと呼ばれるファイアウォール機能で、全利用者の環境で自動的に適用されます。

AWS Shield は、AWS で実行されるアプリケーションを Distributed Denial of Service (DDoS) 攻撃から保護するマネージド型のサービスです。AWS Shield Standard は、すべてのお客様に対し追加料金なしで自動的に有効化されます。（よくある質問 - AWS Shield | AWS）

レイヤー7でのDDoS保護には、AWS WAFを組合わせる、AWS Shield Advancedに切り替えるなど、利用者の任意で、利用者のコントロール下で防御策を講じます。

今回の件は「データセンターのファイアウォール機能がDDoSと誤認して止めた」とのことでした。仮にデータセンターがAWSの場合、利用者のコントロール下にある任意で構築したファイアウォールなのか、それともAWS側が管理し利用者には触れることのできないAWS Shield Standardなのかが気になります。そして仮に後者だと仮定すると、以下の部分は非常にわかりやすくなります。

アクセスしてきた人数がシャープの想定とは文字通り｢桁違い｣だったと想定されることだ。ではどのくらいだったのか？ シャープ広報は｢実は、把握できていない｣と答える。なぜなら、｢サイトが落ちる前に｣セキュリティが働いてしまったためだ。（Business Insider Japan）

ファイアウォールがアクセスを遮断しているなら、ファイアウォール自身には遮断の閾値なりアクセス数を示す記録がありそうな気がします。ただしアクセスを遮断したのがAWS Shield Standardなら、閾値や条件などは分からず、履歴も有償のAWS Shield Advancedプランにしていないと取得できないようです。

Q: AWS リソースへの DDoS 攻撃すべての履歴は取得できますか?
はい。AWS Shield Advanced では、13 か月間のすべての攻撃履歴を確認できます。（よくある質問 - AWS Shield | AWS）

またBusiness Insider Japanの記事では、以下の部分もファイアウォールがマルチテナント性を持っているように読めます。

DDoS攻撃は、大量のアクセスを短時間に行うことで、サーバーへの侵入やサービス停止を試みる。そのためファイアーウォールは、｢その企業のサービスとして想定し得ない量のアクセス｣を、DDoS攻撃と認識して止める。（Business Insider Japan）

AWS Shield Standardの誤検知は対策できるのか

今回、シャープのCOCOLO MEMBERSが使っていたのは自社データセンターかAWSか、仮にAWSだとして不調を引きを越したファイアウォールはAWS Shield Standardか否か、結局のところ公表されない限りは分かりません。ただ今回のことで「AWS Shield StandardがアクセススパイクをDDoSと誤認する可能性」に気づいてしまったのは、ちょっと私には気の重いことでした。

もしAWS Shield Standardによる誤認だった場合、どのような対策がとれるのでょう。このDDoS認識のロジックは、AWS全体で共通の同サービスの知見によるもので、利用者が手を出せる部分ではなさそうです。こうなった場合、DDoSとみなされる利用のされ方を避けること、つまりワークフローやロジックを変更することまで必要になりそうに思われます。例えば今回のマスク販売の件では、次のように申し込みまでのフローから見直すことなどです。

アクセス集中を避け、トラブルなく公平に必要なものを売るためには、｢事前登録による抽選｣｢公平なアクセス制限による販売｣などの施策が必要だと筆者は考える。（Business Insider Japan）

そして実際にシャープの対応は、前回の障害についての詳細などはないまま、まさにこの方向になりました。

アクセス集中を緩和するため、販売方法を抽選方式に変更させていただくことといたしました。（株式会社SHARP COCORO LIFE）

かなり上流からそれ以降最下流までの見直しになるので、これは多くの場合簡単なことではないと思います。本件については「データセンターのファイアウォール機能」が具体的にはなにだった、それがどちらであれ一般論としてクラウドでは事業者のセキュリティ責任範囲となるインフラレイヤでの誤検知があったら何が起こるのか、そしてどんな対応が可能なのかと言ったことは今後知りたいところです。

この記事が気に入ったらサポートをしてみませんか？