安全なAIモデルを使っても安心できない 攻撃者が狙う「AIの外側」：AIとサイバー攻防のダイナミクス（1/2 ページ）
最近「AIを守る」ことの必要性を感じる企業は多くなっているかもしれません。ただ、何をどう守れば安全なのかについてはまだ十分な答えを持っているところは少ないでしょう。水面下で高まるAIのサイバーリスクにどう備えるか。実被害の事案から分析します。
この連載について
本連載「AIとサイバー攻防のダイナミクス」では、AIとサイバーセキュリティの構造変化を読み解くためのフレームワークを提示し、攻撃事例や防御の実践を交えながら、「AIをどこに導入すると効果的か」「どこまでAIに任せるべきか」「逆に人間の判断が不可欠な領域はどこか」を明らかにしていきます。
前回は、CSIRTの業務をAIとの親和性に基づいて6つの「業務型」として分類し、どの業務をAIに任せ、どの判断に人間を残すかを業務単位で検討しました。
議論の軸は「任せ方」にありました。AIに任せた業務の結果は、AIによる自律的な判断・実行に依存します。そのため、それを不正に操作された場合、業務そのものに影響が生じます。
今回の問いは、「AIを守る」とは具体的に何を守ることかです。ただし、その前に確かめておくべきことがあります。AIそのものへの攻撃は、どの程度まで現実の問題になっているのでしょうか。
本稿は、第1回で示したAIとサイバーセキュリティの関係を整理する4象限フレームワークのうち「Cyber for AI」（AIのためのセキュリティ）の攻撃側面を扱います。
AIによるセキュリティリスクは“水面下で起きる” なぜ対策しないと危険か
従来の脆弱（ぜいじゃく）性は、実装上の欠陥でした。「想定していない入力で処理が破綻している」「権限の確認が漏れている」といった欠陥です。対処の枠組みも定まっており、修正プログラムの適用や設定の変更、通信の制限といった手段が適用されてきました。
しかしAIへの攻撃は、これとは性質が異なります。システムは仕様通りに動作したまま、出力だけが操作される可能性があるためです。システムそのものはエラーを返さず、正常な処理として動作するため、従来の障害監視や脆弱性管理だけでは異常を捉えにくい部分があります。
さらに、この種の失敗はすぐには表面化しません。何かが停止するわけではないため、出力を受け取った側が誤りに気付かない限り、記録にも残らないためです。
以上を踏まえると、AIを導入した時点で、守るべき資産の一覧にAIシステム自体を加える必要があり、ネットワークやサーバと並ぶ保護対象として扱うことが求められます。
AIエージェント活用で高まるリスク データで見る「AIへの攻撃」
OECD（経済協力開発機構）は、AIに関連して生じた事案（インシデント）や、生じ得る事案（ハザード）を収集して公開しています。「AI Incidents and Hazards Monitor」と呼ばれるデータベースで、公開報道などを収集元とし、事案ごとに参照先のURLが付されていて、誰でも見られます。対象範囲はサイバーセキュリティの事案に限らず、AIによる差別的な取り扱い、誤作動、権利侵害なども含む汎用（はんよう）的なデータベースです。
収集の対象は報道された事案であり、報道されなかった事案は含まれません。分類の一部には自動処理が使われています。つまり、これは網羅性を前提とした統計ではなく、傾向を見るための材料として取り扱いましょう。
2024年8月〜2026年8月までの約2年間に、このデータベースには約9900件が記録されています（本稿執筆時点）。このうち、AI自体が攻撃の対象となった事案に該当するものは約240件で、構成比でいうとおよそ2％です。
さらにそのうち、実際に悪用され被害が生じたことが確認できるものは、その一部にとどまります。ただし、このデータベースは「AIへの攻撃」という区分を持たないため、「およそ2％」という割合は記録された内容に基づいて筆者が分類したものです。
下図が示す通り、件数は期間を通じて増加しています。また、実際に悪用され被害が生じたことが確認できる事案は、この2年のうち後半に偏っておりAIエージェントの活用推進と連動していると考えられます。
AIを狙う攻撃の4パターンを紹介 実被害につながる最も危険な運用
AI Incidents and Hazards Monitorに記録された事案を見ると、攻撃はAIモデルの内部で起きているわけではないことが分かります。狙われているのは、AIが何を入力として受け取り、何を実行できるのかという、その外側の部分です。実際の事案は、以下の4パターンに分類できます。
- 入力への攻撃：AIに与える入力を通じて、出力や動作を操作するパターンです。利用者が直接入力する場合だけでなく、AIが参照した外部の情報に指示が埋め込まれていることもあります。記録されている事案では、Webページや投稿に埋め込まれた指示をAIエージェントが読み取り、利用者が意図しない操作や支払いに至っています。
- 知識・データへの攻撃：AIが学習に使うデータや「検索拡張生成」（RAG）が参照する情報源を汚染するパターンです。記録されている事案では、拡張機能の配布経路や、AI開発で使用される部品の依存関係が汚染され、認証情報の窃取や情報の持ち出しに至っています。
- 権限と接続への攻撃：AIエージェントに与えたツール連携やAPIの権限を悪用するパターンです。記録されている事案では、AIエージェントに与えた外部連携の権限や認証情報が複数の用途で共用されており、それが乗っ取りの起点になっています。1〜4のうち、実被害につながった事案が最も多いパターンです。
- 資産としてのAIへの攻撃：AIモデルや設定を窃取する、挙動を推測するといった攻撃に加えて、AIそのものを破壊する攻撃です。記録されている事案では、AI開発基盤の脆弱性を突いて侵入し、学習データやモデルを暗号化する形の攻撃が観測されています。
これらを通して見ると、ある共通点が浮かび上がります。それは、いずれも全く新しい高度な攻撃ではなく、既存の攻撃手法（権限の乱用や供給経路の汚染、身代金の要求）が、AIという新しい対象に向けられたものだということです。
これを踏まえると、AIエージェントを導入する際に確認すべきは、AIモデルの性能ではなく、そのAIが何に接続し、何を実行できるのかという権限の範囲です。そのため、既存の権限管理や供給経路の管理をAIにも適用できているかどうか点検する作業が出発点になります。
なお、ここで挙げた事案はいずれもセキュリティ運用のAIではありません。事業部門や開発部門が使うAIでこうした事案が起きている点にも注意すべきでしょう。
一つ間違えば大事故 「AIがうまく機能しなかった」被害事例
この他、AI Incidents and Hazards Monitorには、攻撃ではないものの依存したAIが機能しなかった事案も記録されています。ここでは以下3つの例を挙げます。
1つ目は、公共施設の遊泳場に設置された溺水検知AIが、監視範囲の死角のために期待通り作動しなかった事例です。検知に依存する運用では、AIが機能しない領域が存在することが、そのまま結果に直結します。
2つ目は、学校に設置された銃器検知AIが検知に失敗した事案です。説明されていた性能と実態が異なるとして、法的な責任が争われています。「導入した」ことと「機能する」ことは別であり、説明された能力と実際の限界の差が問われています。
3つ目は、オンラインプラットフォームで、AIによる有害コンテンツの検知が期待された機能を果たせず、監督当局の関与に至った事案です。検知AIへの依存は、技術的な問題だけでなく組織の説明責任の問題になります。
これらはいずれも攻撃ではなく偶発的な失敗ですが、サイバー領域でのユースケースでは、悪意を持った攻撃者がこうした検知しない条件・検知を免れる条件を意図的に悪用することが想定されます。そのため、AIの検知能力を評価する際に「何を検知できたか」だけでなく「どのような条件で検知できなかったか」を記録するのが重要です。この記録は、偶発的な失敗への対策としても、意図的な悪用への備えとしても有効です。
Copyright © ITmedia, Inc. All Rights Reserved.