SaaS/IaaS/PaaS利用の落とし穴

前回までの内容で、NIST SP800-53 の主要なファミリーごとの役割や、留意事項について紹介してきた。今回は、SaaS/IaaS/PaaS利用の落とし穴と題して、いわゆるクラウドサービス利用におけるセキュリティ上の留意点やインシデント事例について紹介する。クラウドサービスを軸として組織のITシステムを編成するようになって久しいが、同時にクラウドサービスに起因するサイバーインシデントも多発している。一言で言えば、「クラウドならでは」という考え方を捨てる必要があるといえる。
要するに、オンプレミスシステムへの防御策とクラウド環境のそれを、全く別の代物であると誤解したセキュリティ対策が跋扈しており、これを信じた企業は次々とインシデントに見舞われているということだ。今回は、クラウドセキュリティをASM(Attack Surface Management)の観点から考察する。
※本記事はサイバーセキュリティに関する啓発や考察を目的としています。特定の企業・団体を批判する意図は一切ありません。
前回の記事はこちら↓

クラウドに関するインシデントの数々
DX推進と、テック系ベンチャー企業の増加、SaaSサービスの加速に伴って、クラウド環境をベースとしたIT構成は爆発的に広まった。そんな中、クラウドへのサイバー攻撃を考えるにあたっては大きく、ガバナンス上の問題とセキュリティ上の問題の2つの側面からこれを捉える必要がある。
これは以前の記事「セキュリティとガバナンスの関係性」でも論じたとおりである。例えばクラウドにアップロードした重要情報の漏えいを考えてみれば、従業員が設定を誤って公開設定にしてしまうなどの誤設定は、ガバナンスの欠如の産物と言えるし、アカウントの乗っ取りやクラウド環境の脆弱性を突くなどする手法による被害は、セキュリティの欠如といえるだろう。
InfoStealer攻撃の増大
今回はセキュリティに比重をおいて解説を行う。大企業は当然そうであるが、クラウドを中心としたIT構成を取る中小企業の皆様にもぜひ読んでいただきたい。近年爆発的に増加している攻撃手法として、InfoStealer型攻撃というものがある。InfoStealerとは、知らず知らずの間にPCに侵入し、PCから入力された情報を主にブラウザなどから窃取するマルウェアを指す。例えば、ブラウザからショッピングサイトにログインすればそのIDとパスワード、住所などを入力すればそれらの情報は根こそぎInfoStealerによって攻撃者のサーバーに転送される事となる。SaaSサービスの認証情報も勿論例外ではない。

現在InfoStealerを提供する闇業者の最大手である Lumma Stealer の壊滅作戦を手動した米司法省によれば、全世界に感染端末は Lumma Stealer だけでも1,000万台以上存在し、アジア圏では日本での感染数は飛び抜けて多い。他のInfoStealerに感染している端末も含めればとんでもない数の端末から情報が抜かれているということである。こうして幅広く収集された認証情報は、ディープウェブ/ダークウェブで販売され、別のサイバー攻撃者が購入することで、ID/パスワードなどの認証情報を持ったうえでの攻撃が可能となるのである。

LummaStealer をはじめとするInfoStealerについては、過去セミナーでも取り上げているので参照されたい。

InfoStealer認知のきっかけ—証券会社オンライン口座乗っ取り事件
このようなInfoStealerを起点とする攻撃を私はInfoStealer型と呼称しており、今後のサイバー攻撃のテンプレートとなるだろうと睨んでいる。最も一般的にInfoStealer型の攻撃が認知されたのは2025年上旬に発生した証券会社オンライン口座乗っ取り事件だろう。2025年1~6月までで、17社以上の証券会社で7,139件もの顧客のアカウント乗っ取りが発生し、累計5,710億円分の株式が不正に売買された事件である。攻撃者は事前にInfoStealerを用いて証券会社の認証情報を被害者のPCから窃取して、その認証情報を用いて口座を操作したのである。多要素認証をAiTM(Adversary in the Middle)と呼ばれる中継攻撃により突破したことも話題となった。
Jaguar Land Rover Automotive PLC の生産停止事件
さて、証券会社をクラウドサービスに置き換えて考えてみよう。背筋が凍るはずである。例えば、ファイル共有サービスだったらどんなことが起こるだろうか。そこに保存しているあらゆる情報にアクセスされる可能性がある。
では少し視座を上げて、コード管理サービスではどうか。自社で開発している製品のソースコードが漏えいするばかりか、不正なバックドアを注入される可能性すらあるのである。そしてこれは実際に起きたのである。2025年12月時点で未だ解決の糸口が見えない、Jaguar Land Rover Automotive PLC の生産停止事件である。
実は Jaguar Land Rover Automotive PLC は2021年に取引先企業のPCがInfoStealerに感染したことでソースコード管理ソフト「Jira」の認証情報が窃取され、大規模な情報漏えいを起こしているのであるが、4年後に当たる2025年3月に当時窃取された認証情報を用いて「Rey」というハッキンググループが同社クラウド環境を含むITインフラにランサムウェアを仕掛けることに成功したのである。その後2025年8月に、別のハッキンググループが攻撃を仕掛けたことで生産停止に至り、数千億円単位の追加融資保証を英国政府が発表するに至った。
Jaguar Land Rover Automotive PLC の被害事例については、「自社開発の落とし穴」でも詳しく紹介しているので参照されたい。

必要な対策
ここでのポイントは、クラウドサービスの多くがブラウザを介してアクセスする存在であり、認証が持つ責任は多大であるということだ。そして、その認証に必要な情報はInfoStealerという新種のマルウェアによっていとも簡単に窃取されるし、それは海の向こうの話ではなくて、日本でも感染が確認され、大きな被害を出しているということを認識すべきなのである。
何が言いたいかといえば、クラウドを守るには、クラウド以外を守る必要が出てきたということだ。だからこそ、「クラウドならでは」の守りに終止して、それを持って安心と定義することは愚かなのである。具体的にいえば、当然と言えば当然なのであるが、エンドポイント対策として、単なるウイルス対策製品ではなく、EDRなどのより次世代的な対策製品の導入を推奨するということだ。というのも、InfoStealerがこれだけ感染を拡大できるのには理由がある。入力情報を外部サーバーに送る程度の動きは、他の正規ソフトもやっているのである。つまり、InfoStealerを幅広くウイルスとして認定してしまえば、正規のソフトも動かなくなる可能性が高いのである。だからこそ、InfoStealerも捉えることができる専門的な技術を持ったEDRの導入が必要なのである。また、当然多要素認証などは必須と言える。SaaS利用に留まる場合にはここまでの内容(アカウント管理とInfoStealer対策)が重要で、IaaSやPaaSのような利用方法を採っている読者の皆様は以降の対策が更に重要となる。
ASM(Attack Surface Management)の必要性
では、攻撃者の標的は完全にPCに移行したのかと問われればそんなことはない。勿論クラウド環境の設定の不備や、パッチが未適応なサービスの脆弱性を用いた侵入なども活発に行われている。このように攻撃者にとってパッと見て攻撃対象としたくなるような要素をAttack Surfaceと呼ぶ。ASMとはその名の通り、攻撃者の視点に立った時に、自社を攻撃するにあたってどの資産を攻撃したいと思うかというのを管理する概念なのである。

勿論この概念はクラウドのみならず、オンプレミスシステムにも適応できる。ただし、クラウド環境のAttack Surfaceには多くの誤解があると私は考えている。代表例は、閉域神話だろう。多くのIT管理者が「うちのプライベートクラウドは閉域なので、そもそもAttack Surfaceなど存在しない」というのである。しかしそれは大きな間違いである。
前述した通り、InfoStealerによって認証情報が窃取されるように、PCがマルウェアに感染したとすればその端末を経由して、閉域網内に不正なパケットを流すことは容易であるし、管理端末に対するフィッシングなどを行えば、外部からネットワーク構成設定を改ざんすることなど容易なことである。また、「クラウド環境の管理はコードベースで行われているので、管理は行き届いている」というものもある。その構成コード自体が管理できていない会社がどれほどに多いことか。
そして何よりも、記述したコードをもとにクラウドシステムがどのようなインスタンスを立ち上げ、その上で動くアプリケーションにはどのようなモジュールが含まれるかなども含めて、管理できていると言えるのだろうか。
要するに、クラウド環境とは特別な環境でもなんでもなくて、巨大なオンプレミス環境をネットワーク上に展開しただけのものであると、セキュリティ的には捉えるべきだということである。そうだとすると、クラウド環境のAttack Surfaceというのは、認証が突破された後、脆弱性を突かれた後というのをしっかりと考える必要が出てくるのである。クラウド環境に一般的なASM製品を導入すると、その構成要素の多さから、大量のアラートの滝に苦しむことになるだろう。それはその製品が、Exploitability Metricsと呼ばれる悪用可能性指標についてフォローしきれていないことが原因だと考えられる。悪用可能性指標とは、その脆弱性が本当に外部から悪用可能かを確かめるための指標であり、当該攻撃の発生可能性を図るものだ。深ぼれば途方もなく書くこととなるため、以下の図をもって解説とする。

付け加えるならば、単独の脆弱性のインパクトレベルを示すCVSS(Common Vulnerability Scoring System)は、あくまでも当該の脆弱性を悪用するために必要な条件の難易度を示したものであるため、CVSSのスコアでの判断は本質的に言えば、アラートの滝を解決する糸口にはならない。必要なのはネットワーク構成やシステム上のどこにどのような情報が格納されているかなどを把握したうえで、システム全体における悪用可能性指標をASMに組み込むことなのである。クラウド環境で仕事をしていて、SaaSのみならずIaaS/PaaSを利用しているのであれば、前述したようなことまでできるASM製品の目利きが必要なのである。
執筆者
