クラウド侵害の 83% は ID 攻撃から始まる:事態を悪化させる NHI と AI の遭遇

83% of Cloud Breaches Start with Identity, AI Agents Are About to Make it Worse

2026/03/12 SecurityBoulevard — Google の “H1 2026 Cloud Threat Horizons Report” は、Google Threat Intelligence Group/Mandiant Incident Response/Office of the CISO が共同で作成したものであり、長年にわたりセキュリティ・リーダーたちが懸念してきた現実を明確に示している。脅威の環境は単に進化しているだけではなく、過去 20 年間に構築されたツールや組織的な対応能力を超えるスピードで加速している。このレポートの 3 つの主題を総合すると、それぞれの企業が見直すべきは、アイデンティティ管理/AI 管理/防御アーキテクチャの根本的な設計にあることが見えてくる。

解決されなかったアイデンティティ問題 — そして増幅

長年にわたり Verizon Data Breach Investigations Report は、アイデンティティが主要な攻撃対象領域であることを示してきた。しかし、盗まれた認証情報/フィッシング/ソーシャル・エンジニアリングは、依然として初期侵入手法の上位を占め続けている。

この事実は広く認識され議論されてきたが、数多くの組織において、今も過剰なアクセス権限が付与され続けている。経験豊富なセキュリティ・リーダーたちは、その理由を理解している。たとえば、営業担当者が契約書へアクセスできなかったことで、数百万ドル規模の契約を失ったという CEO からの電話を、管理者たちは受けたくないはずである。

そのため組織では、必要以上のアクセス権限を付与し、後で監査するという運用が定着している。そして、多くのケースにおいて、そのような監査は実施されない。その結果、企業のアイデンティティ基盤には、常に過剰な権限が残存する状態が広がり、それらを脅威アクターたちが収集/悪用/武器化している。

Google のレポートは、この問題を具体的な数値で示している。2025 年後半に観測されたクラウド侵害の 83% は、アイデンティティ侵害が原因であった。しかし、それよりも重要な発見は、アイデンティティの問題が発生している場所である。レポートに記載された 2 件のインシデントは、この構造的な変化を明確に示している。

北朝鮮の国家に支援される攻撃者 UNC4899 は、開発者の侵害されたノート PC から Kubernetes 環境へ侵入した。この攻撃者は、認証セッションを悪用することで、CI/CD サービスアカウント・トークンを収集した。それらは、クラウド全体に権限を持つ非人間アイデンティティ (NHI:Non-Human Identities) であり、大半の制限が設定されない状況にあった。

また、 UNC6426 による攻撃は、侵害された npm パッケージが開発者の GitHub Personal Access Token を盗み出すところから始まっている。それらのトークンを介して、攻撃者は OIDC (OpenID Connect) 信頼関係を悪用し、72 時間以内に AWS 管理者権限へ昇格した。

参考:AWS Admin アクセスを npm パッケージを介して 72 時間で奪取:UNC6426 の手口とは?

初期侵入後の主役は、サービス・アカウント/OIDC ロール/長期間有効なトークンなどの非人間アイデンティティ (NHI) であり、人間ユーザーのアイデンティティはほとんど用いられない。つまり、人間アイデンティティで解決できなかった過剰権限の問題が、機械アイデンティティ層にも、そのままコピーされていたことになる。

それに加えて、今の企業環境では、AI エージェントが急速に増加している。これらは認証を行い、API を呼び出し、データストアへアクセスし、自律的に操作を実行する。過剰権限を持つ AI エージェントは、機械速度で環境を横断できる自律アクターとなるため、単なるガバナンスの問題では済まされない。さらに言えば、数多くの組織は、その認証フットプリントを監視する能力すら持っていない。

開発者のノート PC 上で既に AI は攻撃に利用されている

このレポートの 2 つ目の主題は、技術者以外にとっても重要なものである。

Nx NPM パッケージに仕込まれた QUIETVAULT 認証情報スティーラーは、トークンを盗み外部へ送信するだけではなかった。開発者の端末に存在する LLM を悪用し、”.env”/”.conf”/”.log” などの機密コンフィグ・ファイルを列挙し、その中から認証情報を収集していた。

つまり、攻撃者は AI を持ち込むことなく、開発者自身の AI 開発環境を悪用して攻撃を実行していた。エンジニアの生産性を高めるツールが、攻撃者に悪用されることで自動偵察エンジンとして機能するという、AI セキュリティ問題の具体例である。

LLM は OS に信頼され、開発者のワークフローに統合されている。そして多くのエンドポイント検知システムは、悪意のバイナリや異常プロセスだけを検知し、LLM の動作を監視していない。Google からの提言は、管理者による CLI ツールと同じレベルで、LLM プロセスの実行を監視すべきというものだ。

この提言は、技術的に正当なものであるが、それを実現するための可視性を、多くの企業は持っていない。ほとんどの組織は、AI ツールによるプロセス・レベル動作を監視できず、異常な LLM 活動を検知するポリシーも整備していない。

脆弱性悪用までのタイムラグは既に消えている

3 つ目の主題は、アイデンティティと AI の問題を統合するものだ。

ソフトウェアの脆弱性を悪用した初期侵入は、半年間で 2.9% から 44.5% へ急増し、脆弱性情報の公開から攻撃までの時間は、数週間から数日に短縮された。手動によるパッチ管理/アクセスレビュー/インシデント対応は、従来の脅威の速度を前提とするものだ。

2025 年後半に Google が観測したインシデントとして、CVE の公開から 48 時間以内に暗号通貨マイナーが展開されたという事例がある。

Google の内部フォレンジック・パイプラインは別のアプローチを示し、クラウド侵害調査を数日から 60 分未満へと短縮している。この成果は、人間による作業の高速化によるものではなく、一定の時間内に人間では完了できない作業を、自動化したことによる。

AI ネイティブ・セキュリティ・アーキテクチャの必要性
  • クラウド脅威環境は機械速度で動作している。
  • 人間中心の組織構造で設計されたアイデンティティ基盤が悪用されている。
  • 現時点で防御側が管理できていない AI ツールが武器化されている。

ここまでに解説してきた、3 つの主題から導かれる結論は明確である。

既存のセキュリティ・ツールへ AI 機能を追加するだけでは、この環境の変化に対応できない。多くのセキュリティ・プラットフォームは、ケース管理/手動トリアージ/アナリスト中心の調査ワークフローを前提として設計されている。

例え話を用いるなら、複葉機にジェット・エンジンを取り付けるようなものである。その負荷に、これまでの構造は耐えられない。

必要なのは AI ネイティブ・セキュリティである。

  • 攻撃者が機械速度で動くことを前提に設計されたプラットフォーム。
  • NHI や AI エージェントの行動モデルと権限を管理できる ID ガバナンス。
  • LLM 活動を検知シグナルとして組み込む脅威分析。
  • 数分単位で動作する自動対応パイプライン。

人間は重要な判断を行うが、対応速度におけるボトルネックにはならない。

すでに攻撃者たちは機械速度で活動し、機械ネイティブ・ツールを用いることで、いまの企業が管理できていないアイデンティティ基盤を攻撃している。

AI ネイティブ・セキュリティを将来の課題として扱う組織は、いまも現在進行形のリスク判断を用いている。問題は、その判断を自覚していないことである。

それを明確に示すのが、”H1 2026 Cloud Threat Horizons Report” のデータである。