人工知能インフラストラクチャへの攻撃は増加していますが、ほとんどの人々が予想するような方法ではありません。AIセキュリティのニュースはプロンプト操作に焦点を当てていますが、攻撃者はこれらのシステムの背後にあるインフラストラクチャを狙っています。この記事は、AIセキュリティをより広い観点から取り上げ、このシフトを説明し、対応するための実用的な戦略の概要を示します。
リスクを理解するために、セキュリティエンジニアの立場に立ってみてください。
ある日の金曜日の午後、小売業者のセキュリティチームは警告を受け取ります。顧客の住所と銀行情報が地下フォーラムに出回っているということです。このニュースは予期しないものでした。本番システムは厳密に監視され、データは分離され、流出は検出されていません。
調査は不快な方向に進みます。ソースは、強化されたeコマースプラットフォームではなく、実際の顧客データで推奨モデルをトレーニングしている新しく作成されたAI研究環境からでした。本番環境ではありません。公開されることを想定していません。それでもクラウドで実行されています。
このシナリオは仮説的です。リスクパターンはそうではありません。
結局のところ、クラウドインフラストラクチャについてです
AIワークロードはまだ初期段階にあり、実験のオーラを持っていますが、その背後にあるインフラストラクチャは現実的であり、それらが管理するデータはしばしば大規模で機密です。そのため、リスク面積は通常、チームが最初に想定するより大きいです。
AIは魔法のように見えるため、人々はそれを中心に警戒心を低下させます。これを明確にするために、直感的ではないことを明確にすることから始めましょう。
抽象化を取り除くと、AIはまだどこかで実行されているワークロードです。
実際の質問は、AIがコンピューティングサービスに依存しているかどうかではなく、組織が何を制御し、何が第三者に依存しているかということです。
次に、現代の企業でAIが実際にどのような姿をしているかを見てみましょう。
今日のエンタープライズAIの形
AIが何を意味するかを特定することは、思ったより難しいです。10人のIT専門家に聞くと、10の異なる答えが得られます。チャットボット、基盤モデル、MLパイプライン、アルゴリズム、インフラストラクチャを意味することができます。聞き手によります。それらはすべて正しいです。
学問分野としてのAIは1960年代から存在しています。本質的には、知的行動の側面をシミュレートするコンピューティングです。今日、AIが成熟し、クラウドとDevOpsと交差するにつれて、科学分野から産業領域へと進化しています。
AI運用モデル
セキュリティチームは、AIが実際に組織にどのように表れるかを理解する必要があります。次のセクションは、これらのシステムがどのように見えるか、どのように構築されるか、そしてなぜ異なる方法で採用されるかを説明しています。
AI価値スタック
これについて考える有用な方法は、メーカー、シェーパー、およびテーカーフレームワークです。これは、生成AIについて議論する際に、マッキンゼーなどの企業によってよく使用されます。
メーカーは、大規模なGPU容量と膨大なデータを使用して基盤モデルをトレーニングする、比較的小さいグループのフロンティアモデルベンダー、クラウドプロバイダー、スタートアップ、および研究機関です。
テーカーには、ChatGPT、Gemini、またはCopilotなどのプラットフォームを通じてAI機能を直接消費する組織および個人が含まれます。
それらの間に、シェーパーの幅広いエコシステムがあります。これは、AIシステムの上に製品を構築し、ファインチューニング、取得層、または独自のデータ統合を通じてモデルを適応させている企業です。
より運用的な観点から、アマゾンウェブサービスのAIセキュリティスコーピングマトリックスは、AIシステムを5つの異なる責任領域に分けています。これはセキュリティの責任について考えるときに参照するのに有用です。
アーキテクチャパズル
前述のように、AIは広い学問です。以下では、いくつかの基本的な違いとそれらのリスク プロフィールを確認します。これは高レベルの概要に過ぎません。詳細な議論については、関連するブログシリーズを参照してください。
生成 vs. 予測
生成AIは最近大きな注目を集めていますが、AIはそれを大きく超えています。
生成システムがオープンエンドの出力を生成し、通常は対話的である一方、予測システムはより制約があり、決定指向です。生成システムは、テキスト、コード、画像、または応答を生成するコパイロット、エージェント、およびアシスタントを強力にし、多くの場合、複数のデータソースを組み合わせることで機能します。予測システムはビジネスロジックとトランザクショナルフローの中で動作し、詐欺検出、需要予測、推奨エンジン、またはリスクスコアリングなどのユースケースをサポートします。
この区別はアーキテクチャ、公開、および制御戦略を形作ります。
セキュリティの観点から、生成システムはデータを集約し、ユーザーをワークフロー全体にガイドする傾向があり、セキュリティをより容易にします。対照的に、予測システムはプロファイラーとして機能し、パターンを識別し、疑わしい活動にフラグを立てます。
リアクティブ vs. エージェント
エージェントシステムは複数のステップで動作し、より長く存続するセッションを維持し、ツールを呼び出し、目的を達成するためにシステムにアクセスします。一方、リアクティブシステムはリクエストを実行して結果を返します。
これらの違いはセキュリティ公開と制御を形作ります。
トレーニングと推論
トレーニングパイプラインは、前に定義されたメーカーカテゴリに近い場所にあります。それらはデータ、モデルアーティファクト、多くの場合、GPUなどの専門的なコンピューティング リソースを、高い特権を持つコントロールプレーン内に集中させます。それらはインターネットに面しているとは限りませんが、多くの場合、重要な知的財産の管理者です。
推論サービスは、シェーパーが動作する場所です。これらのサービスはモデルをライブトラフィック、API、および内部システムに接続します。それらは認証情報、取得層、およびリアルタイム実行を処理します。主なリスクは、集中したモデル資産から、ランタイム公開とシステム統合にシフトします。
セキュリティレンズを通して見ると、トレーニングは資産を保護することです。推論はエクスポーズとランタイムプロセスを制御することです。
IaaS、PaaS、SaaS
同じ問題は、非常に異なるアーキテクチャを使用して解決できます。
1つのセットアップは、高スループットネットワークを活用しながら、GPUクラスターでバックアップされたKubernetesベースの環境でモデルをトレーニングまたはファインチューニングし、プライマリ データセットをデータ重力のためのオブジェクトストレージに保持します。結果のモデルは、同じまたは異なるクラウドで推論のためにデプロイされ、APIを通じて公開され、ビジネスアプリケーションに統合されます。このパターンの詳細な例は、Oracle Kubernetes Engine におけるGPU加速AIワークロードのセキュリティに記載されています。
別の方法は、AWS Bedrock、GCPVertexなどのマネージドサービスを使用して基盤モデルを採用し、プラットフォームAPIを通じてRAGデータベースに接続します。
同様のユースケースであっても、アーキテクチャと責任の境界は大きく異なる可能性があります。理由はさまざまで、主権要件からパフォーマンスと精度の制約までです。
企業の現在の運用方法
生成AIはもはや実験的ではありません。
チューリングの2025年AI採用状況レポートによると、80%の企業が生成AIおよびLLMベースのツールをコアワークフローに導入または統合しています。マッキンゼーは、組織の65%の定期的な生成AI使用を配置し、年間約2倍になっています。
しかし、勢いは成熟を意味しません。Information Services Groupは、企業ユースケースの31%のみが完全本番環境であることを発見しており、多くの取り組みが移行中であることを示唆しています。
生成的と予測的なシステムを区別するいくつかの信号があります。フィラデルフィア連邦準備銀行は、調査対象企業の50%が生成ツールを使用していると報告していますが、23%は従来のAI展開を報告しています。生成ワークロードは急速に増加していますが、予測システムは運用プラットフォーム全体に組み込まれたままです。
採用パターンはまた、組織がこのテクノロジーをどのように消費するかを示しています。メンロベンチャーズは、ソリューションの76%が内部で構築されるのではなく購入されていると報告しています。インフラストラクチャも同じパターンに従います。BentoMLの調査では、組織の77%が推論ワークロードをパブリッククラウドで実行していますが、30%はオンプレミスデプロイを報告しており、多くはハイブリッドセットアップです。
エージェントシステムは採用の初期段階にとどまります。マッキンゼーによると、組織の23%は少なくとも1つの機能でそれらをスケーリングしていますが、39%は実験しています。
動く対象のセキュリティ確保
前のセクションは、AIが多様でフラグメント化されており、その急速に進化するスタックも同様であることを示しています。
セキュリティ専門家にとって、優先事項は可視性です。見えないものは保護できません。組織が採用するAIシステムを理解し、必要なスケールとスピードでそれらを保護する必要があります。
最近の攻撃と脆弱性が明かすこと
AIシステムの実際のリスクと制御の有効性を理解するために、最近数年間にAIインフラストラクチャを標的にした攻撃を調べるべきです。
次のメトリックスは直接比較できません。ほとんどの数値はダウンロード量を反映しています。しかし、それらを一緒に見ると、明確なトレンドを指しています。AIの採用が加速し、インフラストラクチャがより相互接続されるにつれて、攻撃はスケールで増加しています。
増加した技術的深さは、より有能な敵を指しており、多くの場合、AI駆動ツールを活用しています。より広い影響は、採用の速度と公開されているインフラストラクチャの拡大を反映しています。
|
時期 |
攻撃名 |
推定リーチ |
情報 |
層 |
|
Q1–26 |
Hackerbot-claw |
150,000+ |
サプライチェーンRCE: ビルドランナーにコードを注入する自律ボット |
AIパイプライン (CICD) |
|
Q1–26 |
Copilot YOLOモード |
5,000,000+ |
セーフガードなしでアクションを実行する自律AI |
エージェントワークフロー |
|
Q1–26 |
OpenClaw/MCP |
50,000+ |
エージェントAIがツールを誤用して有害なアクションを引き起こす |
エージェントプロトコル |
|
Q4–25 |
Kerasの任意アクセス & SSRF |
4,000,000+ |
被害者が悪意のあるモデルをダウンロードして読み込みます。攻撃者はSSHキーを取得します |
AIソフトウェアライブラリ |
|
Q4–25 |
BodySnatcher |
500,000+ |
コンテキストハイジャックがエージェント悪用を有効にする |
AIエージェント ID |
|
Q4–25 |
LangGrinch |
3,000,000+ |
パッチされていないウィンドウ中にPyPIのlangchain-coreの月次ダウンロードスパイク（約98M月次）から派生 |
AIオーケストレーター |
|
Q4–25 |
ShadowRay 2.0 |
100,000+ |
最大15,000のクラスターが影響を受けました。ボットネットは100,000+の要素に影響を与えた可能性があります |
AIインフラストラクチャとソフトウェアライブラリ |
|
Q1–25 |
Hugging Face Hub |
1,200,000+ |
悪意のあるアーティファクトを通じたモデルサプライチェーンの危険にさらす |
モデルレジストリ |
|
Q4–24 |
Ultralytics 毒殺 |
260,000+ |
サプライチェーン毒殺により、モデル動作が危険にさらされます |
MLパイプライン |
|
Q3–24 |
NVIDIA エスケープ |
1,000,000+ |
GPUメモリ分離障害がデータ漏洩につながる |
クラウドコンテナ |
|
Q1–24 |
ShadowRay 1.0 |
230,000+ |
公開されたRayクラスターがリモートコード実行を可能にする |
AIインフラストラクチャとソフトウェアライブラリ |
|
Q1–23 |
PyTorch RCE |
2,300+ |
安全でないモデル逆シリアル化により、任意のコード実行が可能になります |
ソフトウェアライブラリ |
注目すべきことに、このポストの編集プロセス中に、AIが生成した命令に関連するMetaインシデントなど、複数のエージェント関連のセキュリティ問題が開示されており、内部データ公開につながり、エージェント機能の急速な拡大と外部システムとの深い統合を反映しています。
問題は理解されていましたが、制御ポイントはそうではありませんでした
これらのすべての事件において、違反ベクトルはプロンプト操作または破損したトレーニングデータに関連していません。それはインフラストラクチャでした。アクセス制御、ネットワーク公開、ストレージ構成、変更されたコンポーネント、またはランタイム操作です。
今日のAIセキュリティ会話の多くは、テキスト入力を通じたプロンプト分析と赤チーム作成に焦点を当てています。これらの実践は重要ですが、問題の一方の側だけに対処しています。インフラストラクチャレイヤーはそれほど注意を受けませんが、プロンプトレベルのリスクの一部は実際には設計の失敗です。
ゼロデイ脆弱性は依然として回避不可能なリスクであり、警告なしに出現する可能性があります。設定ミスが本番環境にスリップします。シャドウAIシステムが正式なガバナンスの外側に表示され、監視されません。よく意図されたアーキテクチャでも、時間とともにドリフトします。
そのため、AIインフラストラクチャの保護は、セキュリティ会話で独自のカテゴリに値します。
神経科医の視点を採用する
心理学者が行動を研究し、神経科医がその行動を生産するシステムを研究するのと同じように、サイバーセキュリティツールは異なるレイヤーで動作します。
クラウドワークロード保護プラットフォーム (CWPP) は、ワークロード自体の内部組成、アクセス、およびリアルタイム信号を分析します。
対照的に、Webアプリケーションファイアウォール (WAF)、および最近ではLLM保護プラットフォームなどのツールは、主に入力と出力を分析します。
我々の類似例では:
- 心理学者 → 入力と出力を分析する
- 神経科医 → 内部組成と信号を分析する
会話を保護しながら、それを生成するインフラストラクチャを無視する場合、症状を治療していますが、原因を見逃しています。
観点から実践へ
これがシフトです。意味のあるAIリスクは、必ずしもプロンプトから発生するのではなく、インフラストラクチャ、サプライチェーン、実行環境から発生しています。
そのリスクに対処するには、表面レベルの制御を超え、AIシステムが実際にどのように構築・運用されるかに焦点を当てる必要があります。それがどこで実行されるか、どのように構成されるか、本番環境でどのように動作するかを理解することを意味します。
これがアプローチが具体的になるところです。
完全な保護アプローチ
先ほど説明した神経科医のワークフローは、4つの実用的な制御領域に変換されます。
検出はSaaS、PaaS、IaaSレイヤー全体にわたるAI固有の資産を考慮する必要があります。
姿勢管理は、設定ミス、公開エンドポイント、過剰な特権、および脆弱な依存関係を継続的に評価する必要があります。攻撃パスは分離された発見より重要です。
左シフト制御は重要です。脆弱性とリスクのある構成は、デプロイ前にイメージ、パイプライン、インフラストラクチャ定義で特定する必要があります。
最後に、ランタイム保護は非交渉です。悪用はコンテナとクラウドサービス内で発生します。実行動作、特権使用、異常なアクティビティを監視することが、設定ミスが違反になるのを防ぎます。
AI-SPMとAIBOMでは不十分です。AIインフラストラクチャには、高価値のクラウドワークロードに適用するのと同じ深さの制御、または引数によってそれ以上の制御が必要です。これは、関与するデータ、コンピュート、特権の集中、およびAI関連の違反の上昇コストが与えられています。これらの制御はまた、AIスタック全体の特定の技術と高い断片化に対処するために特化する必要があります。
AIインフラストラクチャセキュリティの運用化
Sysdigでは、このアプローチをインフラストラクチャセキュリティに適用し、AIサービスおよびソフトウェア（MLおよびLLMシステムを含む）へのクラウドネイティブ制御を拡張します。
- AIBOMは、関連するサービス、ワークロード、および信頼できる境界を表示します。これはシャドウAIのブラインドスポットを排除するために重要です。
- リスク管理は、実際の攻撃パス、使用中の脆弱性、および危険な設定ミスを優先します。
- 左シフトセキュリティは、脆弱なイメージとリスクのある構成が本番環境に到達するのを防ぎます。
- ランタイムペリメーター保護は、コンテナおよびクラウドサービス内の実行動作と特権使用を監視します。
ますます、AIはAIのセキュリティを支援できます。Sysdig Sage™などのAIアナリストを使用するか、セキュリティインサイトを直接エンタープライズLLMワークフローに統合すると、チームはより速く調査し、運用上の摩擦を軽減できます。
LLMアプリケーションにSysdigを使用する
大規模言語モデル アプリケーション用OWASP Top 10は、これらの考えを実際のセキュリティシナリオに接続する有用な方法を提供します。このリストはトレーニングと推論リスクにまたがり、LLMシステムをセキュリティで保護するときに実務家が直面する課題を反映しています。次の図は、これらのリスクをSysdig CNA PPランサ機能に関連付けています。
結論
エンタープライズAIはクラウドインフラストラクチャで実行されます。それはデータ、コンピューティング、特権を、公開性と影響の両方を増加させる方法で集中させます。
入力と出力のセキュリティ確保は十分ではありません。システムをセキュリティで保護する必要があります。Sysdig AIワークロード保護機能の詳細を確認し、Sysdig脅威研究の出版物を参照して、AI攻撃の詳細情報をご確認ください。
翻訳元: https://www.sysdig.com/blog/ai-infrastructure-security-why-it-deserves-its-own-category
