SplunkでローカルLLMのセキュリティを監視する方法(パートII)
Artificial Intelligence Rod Soto「SplunkでローカルLLMのセキュリティを監視する方法」のパートIIでは、ローカル大規模言語モデル(LLM)を保護するために注力すべき主な領域と、LLMの脅威対策と防御に関するガイダンスを提供する現在のフレームワークについて説明します。LLMの保護には、ログデータとSplunkを使用します。
SplunkでLLMを保護
LLMの監視と保護に活用できるログソースを見てみましょう。このブログでは、Ollamaをフレームワークとして利用し、リスクへの対処方法、TTP (攻撃者の戦術、手法、手順)、および緩和策の例をご紹介します。なお、これらのモデルが相互に連携する大規模かつ複雑なアーキテクチャには、このブログで取り上げないコンポーネントも含まれることにご注意ください。以下は、AIへの脅威に関する知識を広げるのに役立つリソースです。
OWASP AIセキュリティテスト
上記のガイダンスを活用することで、監視と保護の観点から脅威カテゴリ別にログソースを分類できます。
LLMのセキュリティを監視するためのログソース
上記の図に示すように、AIに対する脅威は以下の4つのカテゴリに基づいて対処、評価できます。
-
- 基準、コンプライアンス、セキュリティ態勢の欠如
-
- 悪質な入力、意図しない出力、回避
-
- データ、トレーニング、フィードバック、サプライチェーンのコンポーネント
-
- サービス拒否、モデルの窃盗、インジェクション攻撃
上記のカテゴリを踏まえ、次のステップでは、ログやアラートのソースをこれらのカテゴリに分類し、特にローカルでLLMを運用する場合における監視と防御の体系的なアプローチを構築します。具体的には、以下を中心に説明します。
モデル使用中の脅威
- ユーザープロンプトと応答
- セッションデータ(タイムスタンプ、セッション期間、ブラウザ、UA)
- エラーログと例外ログ(システム、アプリケーション)
- ファイアウォール、WAF、UEBA
- API呼び出し
- セキュリティアクセスログ
開発中の脅威(またはモデル開発に関連する脅威)
- セキュリティログ(アクセス、変更、認証)
- API呼び出し
- ネットワーク/アプリケーションのアクセスパターン
- 品質と完全性(モデルドリフト)
- フィードバックログ(該当する場合)
- システム監査ログ(エラー、障害、権限)
- データアクセスログ(トレーニングに使用されたデータセット)
実行時の脅威(モデルをホストするシステム)
- リソースの使用状況(CPU、GPU、メモリー、I/O)
- エラーログ(システム、アプリケーション)
- セキュリティログ(アクセス、変更、認証)
- API呼び出し
- ネットワーク/アプリケーションのアクセスパターン
- 出力ログ(IP、PIIの監視)
上記のカテゴリで示されるように、ログソースの多くはこの3つの脅威カテゴリで使用できます。これらの3つのカテゴリは、モデルの運用段階に基づき、使用の観点、システムの観点、および開発の観点から分類したものです。
-
アプリケーションログ:起動、終了、および実行時のエラーや警告など、アプリケーションの動作に関する詳細を記録します。
- Apache2、Nginx、PyTorch、TensorFlow、IIS、MySQL、PostgreSQL、MongoDB
- APIログ、セッションデータ
-
パフォーマンスログ:応答時間、システム負荷、処理時間などのメトリクスを記録します。
- Sysmon、Syslog、モデルトレーニングログ(タイムスタンプ、入力データ、出力データ、処理時間)
-
セキュリティログ:認証やアクセス制御に関する詳細を記録します。
- Windowsイベントログ、Linux Syslog、LDAP、Oauth、EDR、IDS、IPS
-
エラーログ: 開発中、実行中、および使用中のエラーと例外を追跡できます。
- Sysmon、Syslog
-
監査ログ:システムとアプリケーションに対する変更、アクセス、アクションの詳細を記録します。
- Sysmon、Syslog、ADログ、関連する設定変更ログ
- モデルトレーニングの精度に関連したログ(パラメーター、エポック、損失メトリクス、検証精度、警告またはエラー)
- データアクセス(トレーニングと推論に使用されたデータを記録)
-
ネットワークトラフィックログ:トラフィックの異常、禁止されたトラフィック、帯域幅の変動をサーチできます。
- Syslog、ADログ、Sysmon、ファイアウォール、WAF、CloudTrail
-
リソース使用状況ログ:CPU/GPU、メモリー、ディスク使用率など、コンピューティングリソースの消費量を記録します。
- Sysmon、Syslog、CloudWatch、Azure Monitor、GCP
SplunkでOllamaを活用
以下は、Ollamaを例に、上記の脅威カテゴリを適用してログを取得し、ローカルLLMを実行するフレームワークを監視して、セキュリティ上のリスクや潜在的な脅威に対処する方法を説明します。
具体的には、以下のログを監視します。
使用中と実行時の監視(この例では、開発中の監視は含まれません)
- API呼び出し
- Ollamaのプロンプト、日付
- Ollamaのエラーと警告
- CPUとメモリーの使用率に関する情報
- 応答時間とトークンの使用量、メモリー
以下は、~/.ollama/logs/server.logにあるOllamaログの例です。
Ollamaから最大限の情報を得るには、Ollamaでデバッグログを有効にする必要があります(DEBUG=1)。その結果、以下のスクリーンショットのように、プロンプト情報など多くの情報を取得できるようになります。
その後、tail -f ~/.ollama/server.logを実行すると、以下のスクリーンショットのように、実際のプロンプトを含むプロンプト情報が表示されます。
これらのログがSplunkでどのように表示されるか見てみましょう。このデモでは、Ollamaを操作するスクリプトをいくつか作成しました。目的は、システムメッセージ、プロンプト、API呼び出し、モデルパフォーマンスに関する有用な情報を含む解析可能なログを、csvファイルやjsonファイルとして出力し、Splunkに簡単にインポートできるようにすることです。Ollamaログの取り扱いは簡単ではなく、多少の工夫が必要になります。これらのログを管理するために作成したスクリプトは、GitHubでご覧いただけます。
Ollamaのシステムメッセージ
Ollamaのプロンプトメトリクス
Ollamaのプロンプト入力
Ollamaの出力メトリクス
Ollamaのパフォーマンスメトリクス(モデル別)
OllamaのAPI呼び出し
このブログに掲載しているスクリーンショットの一部では、Ollamaに加え、可視化のためにWebUIを使用しています。このような場合にDockerコンテナ経由でWebUIログを監視するには、ログを変換してSplunkに取り込むか、直接Splunkに送信してください。
これまでのスクリーンショットが示すように、Splunkを活用することで、ローカルLLMを可視化して監視および保護する取り組みを、自信を持って進めることができます。また、このテクノロジーが普及するにつれて、標準的なログ形式が確立され、ログの詳細度がさらに高まっていくでしょう。
これらのログを、他のホストシステムのセキュリティやアプリケーションセキュリティログ、それにCisco AI Defenseなどのエンタープライズセキュリティ製品と組み合わせることで、ローカルにホストされているLLMのセキュリティ監視と保護を補完、強化できます。特に、インターネット上でのやり取りを避けるためにLLMをローカルで運用したい企業にとって有効です。Splunk脅威調査チームは、この製品で利用できるコンテンツを開発しています。詳しくは、research.splunk.comをご覧ください。
関連記事

ログファイル分析でのLLMの活用方法:例、ワークフロー、ベストプラクティス

SplunkはAIを何に使っているのか
