AWS障害は本当にサイバーテロではない?サイバー攻撃を「トラブル」とごまかす大企業たち

ここだけの話、大企業になればなるほどサイバーテロのリスクが大きくなります。多くなって管理しきれなくなった社員、把握しきれなくなった取引先、購入するさまざまな端末の脆弱性はあるのにも関わらず、技術レベルは一般と変わらないため地道な運用をしていないと足元をすくわれます。外見は高級そうで、安心できそうに見せていても現場は人間が地に足つけて汗水垂らして保守・運用している事を忘れてはいけません。

 

大手はサイバーテロを隠すことがある

サイバーテロを世間に知らせるリスク

大手の企業で、数億人規模の顧客がいる場合、サイバー攻撃を受けたことを世間に知らせるとそれだけでリスクがあります。評判が落ちるなどリスクにならず、サイバー攻撃に成功したということを、サイバーテロ集団に知らせてしまうことの方が危険です。大々的にサイバーテロがあったと公表すればユーザーはパニックになり、必要以上に大騒ぎし、収拾がつかなくなります。

 

また、サイバーテロ集団がその道で有名になれば、そのサイバーテロ集団に仕事を依頼する大企業、国、組織も出てきます。スパイ行為、サイバー攻撃を受けたという事実は、戦術的に表に出してはいけないという難しい立場に置かれてしまう事例が多くあります。

 

もし、iPhoneにゼロデイ脆弱性があり、それに対して攻撃が行われているという事実を公表すれば、修正が入るよりも前に、サイバーテロ集団はそのゼロデイを突きに行きます。確実に稼げる脆弱性がそこにあることが分かって、しかも、サービス公式が発表したとなれば狙ってくださいと言っているようなものです。

 

この脆弱性が合ったという報告は一般的には表に出さず、裏側で秘密裏に処理し合います。大手のGAFAでもお互いに脆弱性を探り合い、それぞれの弱点を潰されないよう、常時バグハンター同士で探り合って、見つけ次第ホワイトハッカーが共有して対策を講じます。

 

急を要するものは追加のバージョンアップやアップデートを行って対策し、そうでないものは定期アップデートの合わせて更新を行います。この更新前に脆弱性情報を公表すれば対応できていない端末が多数存在することになるため、公表のタイミングはシビアです。

 

大企業はサイバーテロにあった事実があっても、そのほとんどを公表しません。メンテナンス、エラーへの対応、バグ対応と言い訳をして何事もなかったかのように振る舞わないと余計に狙われてしまいます。

 

名誉と評判を守るために隠す

信頼やイメージを重視するサービスでは、名誉、評判を守るために隠蔽する所もあります。日本の官公庁では特にその様子が顕著で、人間の脆弱性を突かれていて問題が起きてもそれを責任逃れのために隠します。

 

もちろん、システム上のエラーやバグに関しては、官公庁は気づきもしないので、さんざん盗み見られて盗られた後になってからも気づかず、オンライン上、闇市場などで販売されているのに気づいてから、やっと漏洩してたと気づくレベルです。

 

官公庁に限らず、保険会社、銀行、郵便関係、セキュリティ企業、チケット取り扱いサービスなどは個人情報の漏洩やサイバーテロにあったという事例があるだけで、その評判を大きく落とします。こういう場合もサイバー攻撃を受けたことを隠します。内部の人間の脆弱性のせいで何かが漏洩していても、基本、公にはならずに秘密裏に処理されて終わりです。

 

理由をつけるのは簡単です。冷却装置のエラー、赤外線センサーのバグ、認証装置の故障など理由はいくらでも付けられます。世間的には、バグ、エラー、メンテナンスといえば、会社や組織はちゃんとサービスを運用していると認識するので評判悪化にはつながりにくいです。

 

メンテナンスやバグといえばなんとかなると思ってる人もいる

コンピュータ、パソコンに疎い人は、そういうトラブルも含めて全部メンテナンス、バグ処理と考えている人もいます。工場機械のわずかな設定のズレ、監視カメラの動作エラー、時計の電池の老朽化、装置のボタンの故障レベルでサイバーテロを捉えていて、問題視する感覚がない人も多いです。問題が起きれば対処すればいいという感覚の人間がいれば、それそのものが脆弱性です。

 

そのサービスを利用する顧客、取引先、クレジットカード情報、社員の個人情報など全てを盗み取られてからであっても、後手後手で対処すればいいという認識でいるのであれば、そうすればよいでしょう。その代わり、数十億円という賠償額、数年~数十年積み上げてきた信頼の崩壊といった大きな問題を引き起こして回復不可能な状態にもなります。

 

冷却装置のゼロデイ攻撃の可能性はゼロではない

連鎖的なエラーはそんなに都合よく起きるか?

AWS障害は簡単に言えば冷却装置のトラブル、ロードバランサーの不具合など本来保証されていたはずの機能まで軒並み問題を起こしています。現場がどうだったかは、現場の人しか分かりませんが、本来トラブルに対処できるように導入していたマルチAZもうまく動かせず、ロードバランサーもうまく動かせず、という状況は見た感じ職務怠慢の招いた結果とも取れる状態です。

 

もちろん、どうしようもないトラブルだった可能性はありますが、事前にトラブルが起きたと仮定して復旧訓練をするのは現場の人間の常識なので、複数の異常が起きていたのは事実です。

 

AWSの発表では装置のせいにしていますが、人為的な訓練不足による失態、ミス、訓練不足に関してあまり公にされていません。エンジニアが十分な給与をもらっておらず、そこまで余裕がなかったか、給与をもらっていながらも怠慢が招いた結果なのか、起きてしまったことに関してはどちらにしてもトラブルで、大勢に迷惑をかけたのは事実です。

 

今回のAWS障害で一番問題なのは、どのサービスがAWSを使っているか明確になったことです。この時点でよりサービスへの攻撃がしやすくなり、サーバー攻撃も何を目指してアプローチすればよいか計画しやすくなってしまったというリスクもあります。また、サービスが停止したものについては、停止している間に本当に何の問題も起きなかったのか、きちんと確認ができていません。

 

とりあえず、AWSが動いていればサービスも動いてくれるという危機意識の低さでは、何かサービスのシステム内に埋め込まれている可能性を無視しているので、時間差で、時限爆弾的に起こるサイバーテロへの対処ができません。

 

IoT端末や冷却装置にもゼロデイ脆弱性がある

シンプルなIoT端末でも、パソコンの冷却装置でも、制御できるものであれば脆弱性を持つ可能性があります。モニタリング上はきちんと動いていると表示しながらも、十分な冷却機能を提供しないように書き換えてしまえば、CPUやメモリやサーバーは加熱により動作がおかしくなり、物理的に破壊が完了します。

 

コンピュータ、パソコンはしっかり冷却しないと自身の熱で自己破壊してしまうので、大企業のサーバーのように、稼働率を制限しにくい状況があるところほど警戒が必要です。

 

ゼロデイ脆弱性とは、その端末、装置を作った最初の頃に残されている脆弱性のことです。機械のブラックボックス部分で、書き換えや更新ができないレベルの問題のことをゼロデイと呼ぶこともあります。

 

例えば、時計の中の歯車の歯が最初から2つ多いけれど、しばらくは何も問題なく動き、一定期間経つと完全に狂ってしまいますが、さらに一定期間経つと時間のズレが戻っていき、再びずれ始めるというような場合、確実にずれが生じるのは分かっている部分になるので、意味的にはゼロデイ脆弱性に当たります。この例の場合、完全にずれた時が時限式のサイバー攻撃の時となります。

 

どんな装置でも弱点はありますが、それが最小限で、かつ、大きな問題につながらないものであるように厳正な調査と選別をして装置を組んでいくのが一般的です。AWS障害の冷却装置でも十分選別した結果、その方法、その装置しかなかったならば仕方がないですが、これだけの問題を起こしていればシステムを再構成するくらいの監査と見直しが必要です。

 

AWS神話を崩すためのサイバーテロキャンペーンでは?

サイバーテロにはたいてい何かしらの理由と目的があります。過去、AWSを使っていたけれど、料金やサポートのトラブルがあって恨んでいる人や、ライバルのクラウド企業がTorの闇市場経由で攻撃を依頼しているような場合もあります。

 

近年、GAFAを蹴落とそうとする動きもあるため、その一端としてのサイバーテロキャンペーンが行われていた可能性もあります。どんなサービスでも大規模になるとよく分からない恨みをぶつけられることもあるため、単なるエラーだったと早期に断言したのはなにか理由があったかもしれません。

 

本来は障害が起きてからどこにエラーが有るのかモニタリングを行い、エラー箇所だけ独立させて復旧作業をしていきます。大規模なサーバー、データセンターでもエラーが起きている部分の特定が保守の仕事ですが、近年はエラーの予兆を事前に把握できるくらいのモニタリングや管理ができているので、事前に対処すれば予防できた可能性もあります。

 

こうした予測を踏まえて、AWS障害から私たちが学ぶべきことは、古い端末はたとえシンプルな機能しかないものでも使わないこと、そして、新しいものを使い始める前にゼロデイ脆弱性が致命的でないか実験してから本番環境で使うことです。

 

さらに、サービスを落としてはいけないような場面では、常に本番と同じサブの環境で復元訓練を行うことです。大きい会社で意識の高いところは定期的にエラー対応、復元対応の練習を行いますが、やっていなかった場合は今からでも良いので復元作業に慣れましょう。

 

有名で大きいサービスになるほど、蹴落とそうとする動きが出てくるのは間違いないので、データセンターの場所や使用している端末の情報は何が合っても漏らさないようにしましょう。

 

如何なる情報でも脆弱性を突くのに利用できてしまうので、常に、いつ狙われても復元できるようにし、日頃から情報を探られていないかアクセスログやエラーログ、脆弱性スキャンとロギングをし、データ管理して確認し、些細な異常も存在していないかチェックしましょう。少しでも早く異常や脅威に気づければ最悪の事態は防げます。

 

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA