まず大切なこととして、パブリッククラウドサービスを利用した攻撃の動きは以前からあった。実際に、過去10年の間に膨大な件数のクラウドマルウェアが報告され、多数のクラウドベンダーが影響を受けている。最も有名なのは2009年に発生したクラウドマルウェア攻撃で、この時はAmazon Web Services（AWS）のサービス「Amazon Elastic Compute Cloud」（EC2）が悪名高いマルウェア「Zeus」のインスタンスをホスティングしている事例が相当数見つかった。一部業界関係者の推計によると、2007～2009年にかけてEC2でZeusを含むマルウェアをホスティングしていた事例は最大で80件に上り、多くはEC2インスタンスでC＆Cサーバをホスティングしていた。

　2011年には、銀行情報を狙うトロイの木馬「SpyEye」をAWSのストレージサービス「Amazon Simple Storage Service」（Amazon S3）でホスティングしているのをKaspersky Labの研究者が発見した。

　セキュリティサービス企業Solutionaryは、2014年の初頭に発表した2013年10～12月期の攻撃に関する報告書の中で、GoogleやAWSなどクラウドサービスが相当数のマルウェアインスタンスを、米国を拠点とするクラウドサーバでホスティングしていると指摘した。2014年6月にTrend Microの研究者が発表した政府機関に対する標的型攻撃の事例では、マルウェア「PlugX」がDropboxから命令を受け取っていた。この直近の事例では、DropboxとGoogleのクラウドサーバが利用され、標的とする環境にインストール済みのクラウドマルウェア用のC＆Cサーバと命令セットの両方がホスティングされていた。

クラウドマルウェア攻撃について理解する

　なぜクラウドベンダーのサーバをマルウェアや不正な命令のために利用するのか。最も分かりやすい理由は信頼にある。悪質なコンテンツやサービスを名高いクラウドサービスベンダーの環境でホスティングすることで、攻撃用のサイトやトラフィックがドメインによって遮断されない確率が高まる。ほとんどの組織は、GoogleやAWSのトラフィックを全て遮断しない。攻撃者はさらに、ほとんどの企業と同じ理由、すなわちコスト効率が高くコンピュータ処理能力の拡張性が高いという理由でクラウドを活用する。

　では、攻撃者はどのようにしてクラウドに侵入するのか。例えば攻撃者は、盗んだ決済手段を使い、正規の手順で顧客アカウントを開設する。この場合、決済手段を頻繁に入れ替える必要はあるものの、リソースを持った攻撃者がクラウドを使い始める最も簡単な手段だ。また、別の手段として顧客が使っているアカウントやサイトを攻撃者が乗っ取り、顧客は意に反してクラウドマルウェアの配布や制御に加担してしまうこともある。使わなくなったアカウントをクラウドベンダーの環境の中で生きたままにしている組織も多く、攻撃者はその気になれば、アカウントを乗っ取り、活用する。

　ではクラウドベンダーはなぜマルウェアや不正行為を検出できないのか。その答えは、多くのクラウドサービスの契約内容にある。AWSやGoogleのようなIaaS（Infrastructure as a Service）ベンダーは、顧客のシステムの導入が無事に済めば、配備した資産を監視することはしない。全てのC＆Cトラフィックの痕跡を監視しようとしても、利用しているベンダーの大きさやクラウドの規模を考えれば不可能に近い。Dropboxのケースでも、マルウェアはDropboxのアカウントから命令を受け取ったり、悪質な「ドロッパー」呼ばれるマルウェアをダウンロードしたりしていたが、そのプロセスが不正なものとして検出されていた可能性は低い。

クラウドマルウェアへの対策

　残念ながら、クラウドベンダーが近い将来、この種の行為に対して警戒を強める可能性は高くない。自社のクラウド環境内の全挙動や他の環境からくるトラフィックを慎重に監視し、制御する責任は顧客側にある。

　例えば、クラウドベースの全資産についてログ管理とイベント監視を導入し、セットアップした全アカウントに常に気を配ってクラウド環境を管理する。クラウドサービスベンダーと社内資産の間のトラフィックも全て監視する必要があり、異常なパターンや通信が検出されれば詳しく調べる。さらに、可能であれば、あるはずのないトラフィックを全て遮断することにより、許可されたクラウドベンダーしか社内システムと通信できないようにする。

　以上の基本的な措置を講じることで、企業の全体的なクラウドセキュリティ対策を強化でき、自社のクラウドインスタンスがサイバー攻撃に利用される可能性も低くなる。