オンプレミスのプライベートクラウドリソースとパブリッククラウドリソースを組み合わせたクラウド環境、いわゆるハイブリッドクラウドは、多くの企業ですでに活用されています。しかし、ことサイバーセキュリティに関しては、物理環境や仮想環境の保護は重視するものの、パブリッククラウド上にある自社インフラ部分にはあまり注意を払わない傾向が見られます。保護の責任はクラウドプロバイダーにあると考える企業もあれば、パブリッククラウドはセキュリティに配慮して設計されているのでそれ以上の保護は必要ないとする企業もあります。しかし、どちらの仮説も誤っています。パブリッククラウドも、他のインフラと同様に、ソフトウェアの脆弱性の悪用、レジストリの感染、ネットワーク攻撃、アカウント情報の不正利用を受けがちです。その理由をお話ししましょう。
RDPとSSHの脆弱性
Amazonのインスタンスでは、リモートデスクトッププロトコル(RDP)がデフォルトで有効になっています。また、2要素認証をサポートしていません。RDPは、さまざまな総当たり攻撃用ツールによって標的とされてきました。よくある既定のユーザー名(「Administrator」など)のいくつかに的を絞り込んでパスワードの推測を何千回も試行するツールもあれば、一般的な姓とよく使われるパスワードを使って管理者のログイン名を推測するものもあります。総当たり攻撃のアルゴリズムは、自動検知を回避するために、試行回数を制限してランダム化し、試行と試行の間に中断を挟むことが可能です。また、AWSのインスタンスにプログラミングされていることの多いssm-userログイン用のパスワードに総当たり攻撃をかけるという方法もあります。
似たようなものに、常にセキュアシェル(SSH)を使用したサービスを標的にする総当たり攻撃があります。確かにSSHはRDPよりも強力な保護(2要素認証など)を提供しますが、慎重に構成しないと、執拗な攻撃によってアクセス権をたやすく握られてしまいます。 2019年前半に検知されたKasperskyのIoTハニーポットに対する全攻撃のうち、12%をSSHとRDPへの総当たり攻撃が占めていました(英語記事)。
サードパーティソフトウェアの脆弱性
パブリッククラウドは利用者に脆弱性をもたらす可能性があり、現にそうなっています。サードパーティのソフトウェアに存在する脆弱性がインスタンスそのものでコードを実行する機会を攻撃者に与えてしまった例を、いくつか見てみましょう。
2019年6月3日、パブリッククラウドでよく使われているメールサーバー、Eximに脆弱性が発見されました(英語記事)。この脆弱性は、リモートコードの実行を可能にするものでした。Eximがrootとして実行されるのはよくあることですが、その場合、サーバーに入り込んだ悪意あるコードもroot権限で実行されます。また、Eximでは、2019年7月にも、root権限でのリモートコード実行が可能になる脆弱性が発見されています。
2016年には、Linux Mintの公式Webサイトがハッキングされました。その結果、このディストリビューションは一定期間、DDOS機能を持つIRCバックドアが組み込まれた状態で提供されていました。このマルウェアは、感染したマシンに悪意あるペイロードをドロップするのにも利用可能でした。このほか、悪意あるnode.jsモジュールに関連する事例や、Docker Hubでのコンテナ感染(英語記事)の事例などが報告されています。
リスクを軽減するには
サイバー犯罪者は、インフラへの侵入口を見つけることにかけては、大変な創造力を発揮する場合があります。特に、非常によく似ている上に同様の問題を抱え、好都合なことに設計の段階からセキュリティがしっかりしていると信じられているインフラが多数存在する状況であれば、なおさらです。リスクを軽減し、より効率的に管理するには、クラウド上と仮想マシン上のOSを保護する必要があります。基本的なアンチウイルス製品やアンチマルウェア保護では、十分ではありません。産業のベストプラクティスとして、インフラ内のあらゆるOSに包括的で多層型の防御が求められていますが、パブリッククラウドプロバイダーも同様の提言をしています。
ここで必要となるのは、Kaspersky Hybrid Cloud Securityのようなセキュリティソリューションです。 システムの強化、脆弱性攻撃ブロック、ファイル整合性の監視、ネットワーク攻撃防御、静的なアンチマルウェアやふるまいをベースにしたアンチマルウェアなど、複数の層にわたるセキュリティ技術を使用して、異なるプラットフォームの上で稼働するさまざまな種類のワークロードを保護します。詳しくはこちらをご覧ください。