Falco Feedsは、オープンソースに焦点を当てた企業に、新しい脅威が発見されると継続的に更新される専門家が作成したルールにアクセスできるようにすることで、Falcoの力を拡大します。
本文の内容は、2026年2月2日に Manuel Boira が投稿したブログ(https://www.sysdig.com/blog/securing-gpu-accelerated-ai-workloads-in-oracle-kubernetes-engine)を元に日本語に翻訳・再構成した内容となっております。
人工知能（AI）および機械学習（ML）のワークロードは、確立されたソフトウェアエンジニアリングおよびインフラストラクチャーの原則に基づいています。AI や ML のライフサイクルは新たな運用上の制約をもたらしますが、それらは依然としてコンピュート、ストレージ、ネットワーク基盤上でワークロードとして実行され、IaaS、PaaS、SaaS といった馴染みのある提供モデルに自然に適合します（AI も結局はどこかで動作するワークロードです）。
組織は、自社インフラ上に AI システムをデプロイするか、またはマネージドサービスとしてモデルを利用します。本記事では、Kubernetes およびクラウドインフラ上にデプロイされた AI アプリケーションに焦点を当て、特に Oracle Cloud Infrastructure（OCI）と Oracle Kubernetes Engine（OKE）に注目します。
OCI は、セキュリティ、コンプライアンス、データ主権の観点から、採用が進んでいます。コスト効率の高さと、エンタープライズおよび規制要件との強い整合性により、OCI は AI や高性能コンピューティング（HPC）アプリケーションのための堅牢な基盤を提供します。RDMA 対応ネットワーキング（高帯域幅・超低レイテンシ）といった機能は、特に高度な並列計算を必要とするワークロード（金融、自動車、航空宇宙、バイオメディカル、生成 AI、ビッグデータ）において重要です。
新たな攻撃対象領域
AI の脅威対象領域は、物理的な CPU や GPU から仮想化レイヤー、さらにモデル、データ、推論、エージェント、アプリケーション、API に至るまで、階層化されたスタック全体に及びます。Kubeflow や MLflow といった MLOps プラットフォームは、共有データストアと密接に結び付いた形で、モデルアーティファクトや学習パイプラインを管理します。
ランタイムでは、vLLM や TensorRT-LLM などの推論エンジンが、高い権限と持続的な GPU アクセスを伴って実行されます。Kubernetes 環境では、llm-d のようなスタックがモデルワーカー向けの分散サービング機能を提供し、NVIDIA Triton Inference Server のようなプラットフォームは、複数のモデルバックエンドに対応したプロダクション向け推論サーバーを提供します。
その上位では、LlamaIndex や LangChain などのフレームワークで構築されたエージェントレイヤーが、モデル、ツール、データを動的に接続し、アプリケーション層や API 層を通じて機能を公開します。これらのレイヤーは密接に相互接続されており、どこか一箇所の弱点が上位へ波及することで、モデルの盗難、データ漏えい、あるいは大規模な GPU の不正利用につながる可能性があります。
OCI 責任共有モデル
OCI と OKE は堅牢で適切に管理されたプラットフォームを提供しますが、攻撃者が狙うのはその上にデプロイされたものです。OCI の責任共有モデルでは、Oracle がコントロールプレーンを管理し、顧客はアプリケーションのセキュリティおよびデータプレーンの大部分の運用に責任を負います。以下は、このモデルがどのように機能するかの例です。
中核的な責任
- Oracle は、可用性や CNCF 準拠の挙動を含め、Kubernetes のコントロールプレーン（API サーバー、etcd、コアコントローラー）をマネージドサービスとして全面的に管理・運用します。
共有運用
- コントロールプレーンのアップグレードは共有されます。Oracle がサポート対象バージョンをリリースしアップグレードを実施しますが、Console／API／CLI を通じてアップグレードを開始するのは利用者側です。
- データプレーンの責任も共有されます。Oracle はイメージおよびコアとなるデータプレーンコンポーネント（kubelet、kube-proxy、flannel）を提供し、利用者はそれらのイメージを用いてワーカーノードとワークロードを管理します。
セキュリティとパッチ適用
- コントロールプレーンの脆弱性については Oracle が影響を受けるクラスターにパッチを適用します。データプレーンの脆弱性については、Oracle が修正済みイメージを提供し、利用者がそれをノードに展開する必要があります。
サポート範囲
- Oracle Support は、OKE が提供するコンポーネントおよび統合（API サーバー接続、クラスター運用、CCM 統合、CoreDNS や kube-proxy などのネットワークコンポーネント）を対象とします。
- 一方で、Kubernetes の利用方法に関する支援、サードパーティ製ソフトウェア（例：Istio、Helm）、サポート対象外の Kubernetes バージョン、アップストリームのバグ、アルファ機能はサポート対象外です。
アプリケーションおよびネットワークの責任
- クラスターのネットワーク設定、アプリケーションネットワーキング（ロードバランサー、Ingress、ネットワークポリシー）、可観測性（ログ／メトリクス）、アプリケーションの健全性およびパフォーマンス、セキュリティ、そしてクラスター上で稼働するすべてのワークロードについては、利用者が単独で責任を負います。
AI 脅威の拡散
攻撃は、その件数、巧妙さ、影響の大きさのいずれにおいても増加しています。ここ数か月の間に発生した多くの注目すべきインシデントは、脅威がいかに急速に進化しているかを浮き彫りにしています。
2025年7月 -LangFlow Server RCE の脆弱性 → 認証されていない AI パイプラインの乗っ取り。
2025年7月 -Nvidia コンテナエスケープ → コンテナからホスト GPUへのエスケープ。
2025年11月 -ShadowRay 2.0 → AI 推論サーバーの悪用とクラウドマルウェア。
2025年11月 -Keras サプライチェーンの脆弱性 → 機械学習（ML）依存関係のサプライチェーン悪用。
2026年1月 -IBM Bob が騙されてマルウェアを実行 → 信頼された AI エージェントのセキュリティ侵害。
より詳細な分析や追加の事例については、Sysdig 脅威リサーチチーム のコンテンツをご覧ください。
学んだ教訓
これらの攻撃の多くは、稼働中のワークロード内部で実行されます。多くの場合、サプライチェーンの弱点やゼロデイエクスプロイトを侵入口とし、過剰な権限を持つ GPU ランタイム、公開された推論サービス、あるいは誤設定されたデータストアやベクトルストアを介して権限昇格が行われます。
その結果、私たちは以下の点に特別な注意を払う必要があります。
リアルタイムの挙動
強固なセキュリティポスチャーが整っていても、ゼロデイ攻撃やサプライチェーン攻撃は予防的な制御を回避する可能性があるため、ランタイム保護は AI および GPU ワークロードにおける異常な振る舞いを検知・阻止するうえで不可欠です。たとえば LLM ベースのシステムでは、プロンプトベースの攻撃によってリソースの乗っ取りや意図しない計算資源の悪用が引き起こされる可能性があります。
単一のメトリクスでは不十分です。ShadowRay 2.0 の事例で見たように、攻撃者はアラートを回避するために GPU 使用率を低く抑えていました。効果的なセキュリティアプローチには、複数ドメインの情報をリアルタイムで相関させることが求められます。
セキュリティポスチャーとガードレール
CI/CD セキュリティや Kubernetes セキュリティポスチャー管理（KSPM）プラットフォームは、汚染された依存関係、公開された AI サービス、安全でない GPU や Kubernetes の設定を検知することで、攻撃を早期に防止できます。また、最小権限の IAM、信頼されたイメージ、強化された GPU ノードプールを強制することも可能です。
Sysdig による AI ワークロード保護のアプローチ
Sysdig は、CNAPP プラットフォームを 3 つの基盤となる柱に沿って構築することで、AI ワークロードを保護します。
ランタイムインサイトは、マルチドメインの相関分析を通じて、AI および GPU ワークロードに対する深くリアルタイムな可視性を提供します。
エージェンティック AIは、推論サーバーのエクスプロイトからコンテナエスケープに至るまで、脅威が実行されている最中にそれを検知・対応し、停止させるための正確なアクションを実行します。
オープンイノベーションはこのプラットフォームの基盤を成し、オープンソース、透明性の高いポリシー、顧客が制御可能なルールを活用することで信頼を構築し、チームが主導権を保てるようにします。これらの柱が一体となることで、AI ライフサイクル全体をカバーし、パフォーマンスや開発スピードを犠牲にすることなく、本番環境レベルのアプリケーションの安全性を確保します。
GPU ノードにおける OKE クラスターの保護
ハイレベルアーキテクチャー
ホワイトペーパー「OKE GPU アクセラレーテッド AI アプリケーションの運用セキュリティ」をダウンロードして詳細をご覧ください
AI ワークロード保護、正しい方法
AI の攻撃対象領域を脅威から防御するには、主要なセキュリティのベストプラクティスと機能を活用することが不可欠です。
できるだけ早くポスチャーを固める
CI/CD における脆弱性およびリスク管理は、デプロイ前に汚染された依存関係、公開されたサービス、安全でない GPU／Kubernetes 設定を遮断することで、AI 攻撃を防止します。Sysdig のランタイムインサイトはノイズを低減し、明確で適切な優先順位付けを支援します。
- ドリフト検知を伴う IaC スキャン
- サプライチェーン、コンテナイメージ、SBOM
- 継続的なポスチャーおよびコンプライアンス（クラウド、コンテナ、OS、Kubernetes クラスター）
- リスク管理およびインベントリ（高度な露出分析、機密データアクセス）
- ランタイムインサイトによる優先順位付け
ランタイム境界を保護してください。常時オン。
ゼロデイ脆弱性やサプライチェーンの欠陥は依然として発生するため、AI および GPU ワークロードにおける異常な振る舞いを阻止するには、ランタイム検知が極めて重要です。
- ほぼリアルタイムの検知と対応
- AI を活用した脅威インテリジェンス
- マルチドメイン相関
- フォレンジック分析
- ネットワークトポロジー
クラウドのスピードで対応できるように準備しておく
クラウド侵害のコストが 445 万ドルに達する中、セキュリティチームには攻撃者に迅速に対応することが求められています。Sysdig は「Sysdig 555」によって、検知と対応のベンチマークを再定義しました。その方法は次のとおりです。
- エージェント AI セキュリティ (Sysdig Sage)
- 高度なレスポンスアクション
- ビルトイン・オートメーション・フレームワーク
さらに詳しく知りたいですか？Sysdig Secure の Web サイトをご覧ください。
ブループリントとランディングゾーン
GPU アクセラレーテッド Kubernetes クラスターのセキュリティは、後付けで考えるべきものではありません。セキュリティは設計の最初期段階から考慮される必要があり、そのため、クラスターがデフォルトで安全になるよう、明確に定義されたランディングゾーンやブループリントから始めることが重要です。
Oracle はこのニーズに応えるため、AI アプリケーション向けの OCI Kubernetes ブループリントを拡充しており、大規模言語モデル向けのリファレンスアーキテクチャーも含まれています。これらのブループリントは、検証済みのインフラ設計、推奨される GPU およびノードプロファイル、必要なソフトウェアコンポーネント、ベースラインとなる監視設定を提供します。これにより、新しいアーキテクチャーを採用する際に、その場しのぎで安全性の低いデプロイを避けつつ、チームは迅速に導入を進めることができます。
Sysdig と Oracle Kubernetes Engine は、セキュリティに特化したクイックスタート用ブループリントを共同で開発しました。このブループリントは、Terraform を用いて、Sysdig Secure がデフォルトで統合された OKE クラスターをワンクリックでデプロイできるようにし、OCI クイックスタートの標準に準拠しています。その目的は、ランタイムセキュリティ、可視性、脅威検知を、ワークロードがすでに稼働した後に追加するものではなく、クラスター設計の初期段階から組み込むことにあります。
セキュリティ運用
現代のセキュリティチームは、ツールは日常業務の中で適切に統合され、活用されて初めて価値を発揮することを理解しています。これは通常、新しいツールを既存のセキュリティスタックに組み込むことを意味します。特に SOC チームにおいては、ワークフロー、データの所有権、対応の自動化に関して、すでに確立された考え方があるため、この点は顕著です。
運用モデルは組織ごとに大きく異なるため、チームは統合方法、責任の所在、対応パターンについて意図的に選択を行う必要があります。Sysdig をセキュリティスタック内でどのようにデプロイすべきかを判断するために、次の質問を検討してください。
自社に必要なサービスレベルはどの程度ですか？
Sysdig は、クラウド環境全体にわたる準リアルタイムの検知およびエンリッチメントレイヤーとして機能し、高品質なセキュリティシグナルを生成するとともに、迅速な対応アクションを支援します。
長期的な保持や相関分析は必要ですか？
Sysdig は、セキュリティイベントを選択的にエンリッチして転送できるため、ノイズを低減し、SIEM に保持する必要のあるデータ量を抑えられます。これにより、運用負荷やデータ取り込みコストの削減につながります。
組織は規制要件の対象ですか？
Sysdig は、リスク管理、資産管理、コンプライアンス管理プラットフォームと統合し、規制環境および継続的なコンプライアンスプロセスを支援します。
セキュリティチームはコードからクラウドまでのパイプラインをどの程度制御していますか？
Sysdig は、SCA、SAST、ASPM ツールと統合し、ビルド、デプロイ、ランタイムの各段階にわたってセキュリティコンテキストを提供します。
自動化はどこまで行いますか？
API や SOAR プラットフォームとの統合を通じて、Sysdig は自動化されたカスタマイズ可能なセキュリティワークフローをサポートします。
マネージドセキュリティサービスプロバイダーと連携していますか？
SIEM、SOAR、ケース管理システムと統合することで、可視性と制御を維持しながら、外部プロバイダーとの協業を支援します。
まとめ
OCI 上の OKE は、GPU アクセラレーテッド AI ワークロードに対して、耐障害性とコンプライアンスを備えた基盤を提供しますが、その上で稼働するアプリケーションのセキュリティを確保する最終的な責任は、利用者にあります。
セキュリティ業界の多くは、出力の分析やプロンプト層でのガードレール追加に注目していますが、インフラ、サプライチェーン、ランタイムセキュリティはいずれも依然として最優先で取り組むべき重要な課題です。進化する AI の脅威環境と新しいテクノロジースタックは、専用のセキュリティアプローチを必要としています。
Sysdig は、この課題に対応するため、準リアルタイムの検知、ノイズ低減とコスト削減を実現するセキュリティシグナルのエンリッチメント、そしてコンプライアンスおよびセキュリティ運用プラットフォームとの強力な統合を含む、AI ワークロード保護機能を提供します。
SysdigとOracleクラウドの詳細はこちら:
OCI ブログ投稿 https://blogs.oracle.com/developers/sysdig-monitoring-security-for-oci-oke-and-oracle-linux
Sysdig とOracle https://www.sysdig.com/ecosystem/oracle
ホワイトペーパーの全文をダウンロード ここにあります。