23 1月 2026, 金

公開状態のLLMエンドポイントを狙う攻撃の急増:日本企業が直視すべき「AIの管理不全」リスク

大規模言語モデル(LLM)の活用が進む一方で、インターネット上に不用意に公開されたLLMサービスを標的としたサイバー攻撃キャンペーンが確認されています。本記事では、最新の脅威レポートをもとに、開発現場やPoC(概念実証)環境に潜むリスクと、日本企業がとるべき現実的なセキュリティ対策について解説します。

9万件超のアクセスが示唆する「無防備なAI」の現状

セキュリティメディアDark Readingが報じた最新の観測データによると、組織が利用するLLM(大規模言語モデル)の「公開エンドポイント」を標的とした、合計91,403回にも及ぶ不審なアクセスセッションが確認されました。これは単なる散発的な攻撃ではなく、組織的なキャンペーンとして、AIの利用に伴う情報漏洩の穴や、攻撃可能な領域(アタックサーフェス)の拡大をマッピングしようとする試みです。

ここで言う「公開エンドポイント」とは、インターネット経由でアクセス可能なAPIや、認証が不十分なまま立ち上げられたLLM推論サーバー(OllamaやvLLMなどのツールを用いたインスタンス)などを指します。多くの開発者やエンジニアが、検証の手軽さを優先してクラウド上のインスタンスを「フルオープン」な状態で稼働させてしまうケースが後を絶たず、攻撃者は自動化されたスクリプトを用いてこれらを探索しています。

なぜLLMエンドポイントが狙われるのか

攻撃者がLLMのエンドポイントを狙う動機は複合的です。第一に、企業の機密情報や個人情報が含まれるプロンプト履歴や、ファインチューニング(追加学習)されたモデルデータそのものの窃取です。これらはダークウェブ上で高値で取引される可能性があります。

第二に、計算リソースの不正利用です。LLMを稼働させるためのGPUインスタンスは高価であり、攻撃者はセキュリティの甘いサーバーに侵入し、クリプトジャッキング(仮想通貨のマイニング)や、他の攻撃のための踏み台として悪用することを狙っています。

第三に、これが「組織内部への入り口」になるリスクです。開発環境は本番環境に比べて監視が緩い傾向にありますが、そこから社内ネットワークへの横展開(ラテラルムーブメント)を許す可能性があります。

日本企業における「シャドーAI」とガバナンスの課題

日本企業においては、全社的なAI導入プロジェクトとは別に、現場部門やエンジニア個人が業務効率化のために独自にAIツールを導入する「シャドーAI」や、PoC(概念実証)段階の一時的な環境構築がリスクの温床になりがちです。

日本の組織文化として、本番環境への導入には厳格な稟議やセキュリティチェックが入る一方で、開発・検証環境やクラウド上のサンドボックス環境については、「テストだから」という理由で管理が個人の裁量に任されるケースが散見されます。今回の攻撃キャンペーンは、まさにそのような「管理の死角」にある、認証のかかっていないAIサーバーを狙い撃ちにしています。

日本企業のAI活用への示唆

今回の事例は、AI技術そのものの欠陥というよりも、運用と管理(MLOps/LLMOps)における不備を突いたものです。日本企業が安全にAI活用を進めるためには、以下の3点を徹底する必要があります。

1. 全社的なAI資産の棚卸しと可視化
社内で稼働しているLLMサービスやクラウドインスタンスを網羅的に把握することが第一歩です。「誰が、どこで、どのモデルを動かしているか」を管理部門が把握できない状態(シャドーAI)を解消し、不要なエンドポイントは即座に閉鎖または保護する必要があります。

2. 開発・検証環境への「ゼロトラスト」適用
「PoC環境だからセキュリティは後回し」という考え方は改めるべきです。開発段階であっても、インターネットに公開するエンドポイントには必ず強固な認証(APIキー認証やOAuthなど)を設け、IPアドレス制限やVPN経由でのアクセスを必須とするなどのネットワーク制御を行うべきです。

3. AIガバナンスと現場のスピード感のバランス
リスクを恐れてAI利用を一律に禁止すれば、企業の競争力を削ぐことになります。重要なのは、現場が安全に実験できる「ガードレール付きのサンドボックス環境」をIT部門が主導して提供することです。監視と制御が効いた環境を提供することで、現場のイノベーションを阻害することなく、セキュリティリスクを最小化することが可能です。

コメントを残す

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