OpenAIとAnthropic用のアドオンでAI監視の盲点を解消

Security Greg Ziemiecki

主なポイント

  1. Splunkの新しいアドオンを使用すると、誰がAIツールを使用したか、何が変更されたか、APIキーの作成や不正利用がなかったかを、ChatGPTやClaudeなどさまざまなプロバイダーを横断して追跡できます。
  2. Ollamaといったようなツール上(モデルの実行基盤上)で動作するローカルのAIモデルや自己ホスト型のAIモデルも、クラウドベースのAIプラットフォームと併せてセキュリティリスクを監視できるようになりました。
  3. AIのアクティビティをSplunkに取り込むことで、アイデンティティ、ネットワーク、セキュリティの既存データと関連付けることができ、調査や監査を迅速化できます。

AIの導入は、新たな領域において従来と同様の課題を生み出しています。つまり、アクティビティの動きが速く、その状況を把握しきれないという課題です。

従業員はエンタープライズ向けAIアシスタントを利用します。開発者はモデルのAPIにアプリケーションを接続します。Ollamaのようなツールを使ってローカルモデルを実行するチームもあります。AIゲートウェイ、RAGアプリケーション、エージェント、MCPサーバーなどを試験運用中のチームもあるでしょう。こうした利用形態のそれぞれにおいて、誰がシステムを使用したか、何が変更されたか、どのサービスが呼び出されたか、そしてリスクのある挙動がどこで発生した可能性があるかを示す有用なシグナルが生成されます。

厄介なのはそうしたシグナルが、セキュリティ、コンプライアンス、運用管理のためにこれまで利用してきたシステムの外側にあることが多いことです。それが盲点となっています。監査や調査の際は、何が起きたのかを把握するために、プロバイダーのコンソール、ローカルサーバー、アプリケーションログ、単発のスクリプトを行き来しなければならない状況は避けるべきです。

Splunkの真価はこのような場面で発揮されます。AIリスクの管理を始めるにあたり、完璧なLLMオブザーバビリティアーキテクチャが登場するのを待つ必要はありません。まずは、運用イベントやセキュリティイベントのサーチ、保持、相関分析、調査のために既に利用しているデータプラットフォームにAIのアクティビティを取り込むところから始めましょう。

利用可能なAIアクティビティを管理下に置く。これこそが、LLMモニタリングにおける最初の効果的なステップとなります。

監査関連の質問を出発点とする

セキュリティ、コンプライアンス、運用の各チームが真っ先に知りたいのは、以下のようなシンプルな質問への答えです。

これらは、AIに関する抽象的な議論ではなく、調査に向けた具体的な問いです。

これらの問いは、Splunkの機能にスムーズに落とし込むことができます。行うべき作業は、関連するアクティビティを収集し、十分なコンテキストを保持し、それをサーチ可能にして、企業内の他のデータ資産と紐付けることです。その基盤が構築できれば、他の重要なビジネスシステムを調査しているのと同じ場所を起点に、ダッシュボード、検出、タイムライン、監査のワークフローを構築できます。

SaaS型AIプラットフォームのガバナンスと監査対応

最初に手を付けるべきなのはSaaS型AIのガバナンスです。

Splunkには現在、企業向けAIガバナンスのための相互補完的な3つのオープンソースアドオンがあります。OpenAI Compliance Add-on for Splunkは、ChatGPT Enterpriseの幅広いコンプライアンスデータをSplunkに取り込みます。Anthropic Claude Enterprise Add-on for Splunkは、Claudeのセキュリティ、ガバナンス、導入状況、利用状況、支出を詳細に可視化します。Enterprise AI Governance Add-on for Splunkは、複数のプロバイダーおよびセルフホスト型モデルを横断する正規化されたビューを提供します。

ベンダーに特化したアドオンは、各プロバイダーが提供する情報を詳細に保持することで「深さ」を提供します。一方、Enterprise AI Governance Add-onは、Claude、OpenAI、Gemini、Microsoft 365 Copilot、およびセルフホスト型モデルが生成するアクティビティ情報を幅広く収集して共有のスキーマに正規化することで「幅」を提供します。これにより、ダッシュボード、アラート、調査のいずれにおいても、プロバイダーをまたいだ一貫した運用が可能になると同時に、必要な場面ではプロバイダー固有の詳細情報もそのまま保持されます。

より広く当てはまる明確な原則があります。それはすなわち、AIのアクティビティも、セキュリティ、コンプライアンス、運用のイベントを調査するのと同じ場所で管理されるべき、という原則です。

具体的には、次のような実用的なメリットがあります。

これはすぐに取り組め、具体性がある上に既存の関心領域にも近いため、最初のユースケースとすることを強くおすすめします。

ローカルLLMおよびセルフホスト型LLMのセキュリティ監視

すべてのAIワークロードがSaaSプラットフォーム上で動作しているわけではありません。プライバシー保護、コスト管理、試験的運用、デプロイの柔軟性といった観点から、ローカルLLMや自己ホスト型のLLMを使用している場合もあるでしょう。これらの環境において生じる監視上の問題はSaaS環境とは異なりますが、データ管理のニーズはあまり変わりません。

Enterprise AI Governance Add-on for Splunkは、vLLM、Ollama、LiteLLMサーバー上で実行されているモデルのインベントリを作成し、利用可能なPrometheusのメトリクスを収集し、エンドポイントの健全性を監視することができます。これにより、自己ホスト型モデルのディスカバリー、パフォーマンスシグナル、可用性が、エンタープライズSaaSプラットフォームと同じガバナンスビューに統合されます。

ローカルLLMのデプロイ環境では、以下から有用なシグナルを生成できます。

これらのシグナルは、セキュリティ監視、検出ルールの開発、および調査を支援できます。Splunkでは、ローカルLLM/MCPの検出ルール開発に取り組んでおり、OllamaおよびMCP環境のアクティビティをSplunkに取り込み、MITRE ATLASスタイルの検出ルールを構築する方法を解説しています。

ローカルのLLM環境は、それぞれ少しずつ異なるでしょう。まずは、現行の環境ですでに生成されているシグナルを収集し、Splunkを使用してそれらをサーチ、相関付け、運用化することが現実的なアプローチとなります。

Splunkがもたらす価値

市場にはすでにさまざまなAIプラットフォーム、モデルゲートウェイ、オブザーバビリティツール、セキュリティツールが存在します。Splunkがもたらす価値はそれらとは異なり、ビジネス全体を対象とした調査で使用している既存のレイヤーにAIのアクティビティを取り込めることにあります。

これが重要であるのは、以下の理由によります。

まず1つ目として、AIのアクティビティは単独ではほとんど意味を持ちません。不審なAPIキーのイベントは、アイデンティティイベント、ソースIPアドレス、エンドポイントアクティビティ、クラウドアクティビティ、既存のセキュリティ検出結果と相関付けできるようにすることで有用性が高まります。

2つ目。監査および調査のワークフローは、データ保持と再現性に依存しています。プロバイダーコンソールは確かに便利ですが、サーチ、保持、アクセス制御、レポートに関する独自の運用ルールに基づいて自社環境でデータを管理しなければならない場合もあるでしょう。

3つ目。LLM監視の取り組みは、多角的なデータソースを基盤として発展していきます。SaaSコンプライアンスAPI、ローカルLLMアクティビティ、ゲートウェイイベント、OpenTelemetry、インフラメトリクス、評価イベント、アプリケーションテレメトリは、それぞれ別種の質問への答えを提供します。Splunkは、そのようなシグナルを徐々に統合していける場所を提供します。

最初の一歩

最初に着手すべきは、迅速な可視化のためのステップです。

以下から始めましょう。

これによって、ガバナンス、監査、セキュリティに関する業務のための実践的な基盤が構築されます。そこを起点に、LLM監視プログラムの成熟度に合わせながら、アプリケーション、コスト、品質、およびパフォーマンスをより詳細に監視できる体制を整えていくことができます。

広範なLLMオブザーバビリティにおける本アプローチの位置付け

AIアクティビティのシグナルは、オブザーバビリティを構成するレイヤーの一つに過ぎません。

アプリケーションチームは、レイテンシーやリクエストフローのトレースを追加することもできます。その際、LLMアプリケーションに関してはOpenTelemetryの生成AIセマンティックコンベンションが重要な役割を果たします。この規約を用いることで、モデルリクエスト、トークン使用量、操作名、関連ワークフローのメタデータを記述できます。インフラチームは、GPU、Kubernetes、サービングフレームワーク、クラウドサービスに関するメトリクスを追加することもできます。AIチームは、品質を把握するために、評価イベントやユーザーのフィードバックを追加することもできます。

こうしたレイヤーは「シグナル優先」という考え方を補強するものです。このアプローチによって、進むべき道筋が明確になります。

  1. まずは、現在利用可能で、ガバナンス、セキュリティ、監査のユースケースに直接対応するAIアクティビティから始める。
  2. ダッシュボード、検出ルール、調査プロセスなど、さまざまな場面でデータを再利用できるよう、十分なコンテキストを保持する。
  3. AIアクティビティを、Splunkの既存のセキュリティデータおよび運用データと相関付ける。
  4. 監視プログラムの成熟度に合わせて、トレース、メトリクス、コスト、品質に関するシグナルを追加していく。

市場に向けたメッセージはシンプルです。つまり、LLMの監視は、現状で利用可能なAIアクティビティを収集し、重要なシステムの調査のためにすでに使用しているプラットフォームに取り込むことから始められるということです。

必要な対象範囲に合ったアドオンを適宜選択してください。OpenAI Compliance Add-on for SplunkはChatGPT Enterpriseの幅広いコンプライアンスに対応し、Anthropic Claude Enterprise Add-on for SplunkはClaudeのセキュリティ、ガバナンス、利用状況、支出を詳細に可視化し、Enterprise AI Governance Add-on for Splunkは複数プロバイダーやセルフホスト型モデルを横断する正規化された可視性を提供します。

詳細については、LanternでエンタープライズAIプラットフォームの監視と管理の概説、エンタープライズAIガバナンスアドオンのセットアップガイド、企業のAIセキュリティ、コンプライアンス、支出の監視ガイドを参照してください。

このブログはこちらの英語ブログの翻訳、井上 綾乃によるレビューです。

関連記事

知っておくべき6つの脆弱性タイプ
セキュリティ
7 分程度

知っておくべき6つの脆弱性タイプ

脆弱性がどこにどのように存在する可能性があるのかを知っておくことで、先回りして脆弱性に対処できるようになります。重要性の高い脆弱性のタイプを6つご紹介します。
内部不正とは?後回しになりがちな要因から対策のポイントまで
セキュリティ
6 分程度

内部不正とは?後回しになりがちな要因から対策のポイントまで

企業にとって大きなリスクとされる内部不正は対策の難しさから後回しとなりがちなのも現状です。本記事では、なぜ内部不正の対策は難しいのか、具体的に、どのようなリスクがあるのか、を解説するとともに、実際の事例や効果的な対策のポイントなどについて詳しく解説します。
<第2回>Splunkでセキュリティダッシュボードを作成しよう!データの取り込み(その1)
セキュリティ
3 分程度

<第2回>Splunkでセキュリティダッシュボードを作成しよう!データの取り込み(その1)

全10回のブログを通して、Splunkを使ったセキュリティダッシュボード作成手順を説明します。シリーズの第2回目として、ダッシュボードのソースであるログの取り込みなど、データの取り込み手法の検討について紹介します。