【実務・中級編】サプライチェーン攻撃：悪意あるプラグインと拡張機能の特定 – ガバナンス・リスク管理 & 生成AIセキュリティ防御ガイド

LLMの「甘い果実」を狙う影：悪意あるプラグインと戦うための防衛ライン

現場でインシデント対応をしていると、開発者が「便利だから」という理由だけで深く考えずに導入したプラグインが、実は組織全体を揺るがす特大のバックドアになっているという光景に何度も出くわす。

今、LLM（大規模言語モデル）アプリケーションは、サードパーティ製のプラグインや拡張機能という「拡張性」という名の麻薬に溺れている。だが、少し想像してほしい。君が信頼して読み込ませたそのプラグインが、裏でユーザーの機密情報を外部のC2サーバーに送信していたら？あるいは、LLMのプロンプトを改ざんして、データベースの全権限を奪うようなクエリを投げさせていたら？

今日は、教科書的な「リスクアセスメント」という言葉の裏にある、泥臭い現実と、それを技術で封じ込めるための実装論を叩き込む。

—

1. サプライチェーン攻撃の盲点：なぜ「プラグイン」が危ないのか

攻撃者は、わざわざ君たちの堅牢なファイアウォールを突破しようとはしない。彼らは、君たちが「信頼できるサードパーティ」としてホワイトリストに入れているプラグインのメンテナを標的にする。

攻撃のPoC（概念実証）のイメージ

1. 信頼の悪用: オープンソースのプラグインに、難読化された悪意あるコードを混入させる。
2. 権限の昇格: LLMがプラグインを呼び出す際、アプリケーションの権限（例：AWS IAMのReadOnly権限など）を借りて実行する。
3. データ抽出: プラグインがLLMのコンテキスト（ユーザーの入力データ）を盗み取り、外部サーバーへPOSTリクエストを送る。

この攻撃を防ぐには、「どのプラグインなら安全か」を考えるのではなく、「どのプラグインも根本的に信用せず、権限を剥奪し続ける」というゼロトラストの姿勢が必要だ。

—

2. 権限の最小化と隔離の設計

プラグインに与える権限は「必要最小限」などという甘い言葉では足りない。「実行時に必要なものだけを、一時的に貸し出す」のが正解だ。

Pythonでの実装例：サンドボックス化と権限分離

プラグインの実行を独立したプロセスとして分離し、ネットワークアクセスを制限する実装例だ。

import subprocess
import os

def run_plugin_safely(plugin_path, input_data):
    """
    プラグインを隔離環境で実行し、ネットワークアクセスを遮断する
    """
    # 権限を剥奪した特定のユーザーでプロセスを実行
    # --net=none はDocker等のコンテナ環境でネットワークを遮断する設定の比喩
    cmd = [
        "sudo", "-u", "plugin_user",
        "python3", plugin_path,
        "--input", input_data
    ]
    
    try:
        # タイムアウトを設定し、無限ループ攻撃を防ぐ
        result = subprocess.run(cmd, capture_output=True, text=True, timeout=5)
        return result.stdout
    except subprocess.TimeoutExpired:
        return "Error: Plugin timed out."
    except Exception as e:
        return f"Error: {str(e)}"

—

3. プラグインの署名検証：偽物を排除する仕組み

野良プラグインを実行させないための絶対条件は、デジタル署名の検証だ。プラグインの配布元が発行した公開鍵で署名を検証し、改ざんされたコードは実行前に落とす。

PHPでの署名検証サンプル

プラグインのロード時に、あらかじめ保持している公開鍵で署名をチェックする。

<?php
/**
 * プラグインの整合性を検証する関数
 */
function verify_plugin($plugin_code, $signature, $public_key_path) {
    $public_key = openssl_pkey_get_public(file_get_contents($public_key_path));
    
    // プラグイン本体と署名を検証
    $result = openssl_verify($plugin_code, base64_decode($signature), $public_key, OPENSSL_ALGO_SHA256);
    
    if ($result === 1) {
        return true; // 検証成功
    } else {
        error_log("セキュリティ警告: 署名が不正なプラグインを検知しました。");
        return false;
    }
}
?>

—

4. インフラレベルでの防御：Egressフィルタリング

たとえプラグインがコードを奪取しても、外部への送信ができなければ攻撃は成立しない。Webサーバーやコンテナの出口（Egress）で通信先を厳格に制限しよう。

Nginx/クラウド環境での設定の考え方

各プラグインが通信を行うドメインをホワイトリスト化する。AWS環境であれば、Security Groupではなく、Network FirewallやVPC Endpointsを使用して、特定のAPI以外へのアウトバウンド通信を全てドロップさせる設定が必須だ。

# Nginxでプラグイン専用のエンドポイントへの通信をプロキシする場合
location /plugin-api/ {
    # 信頼できる宛先にのみ転送を許可する
    proxy_pass https://trusted-api.vendor.com/;
    
    # 不必要なヘッダーを削除し、機密情報の漏洩を防ぐ
    proxy_hide_header X-Powered-By;
    proxy_set_header X-Forwarded-For "";
}

—

最後に：エンジニアとしての矜持

「便利なライブラリを入れれば開発効率が上がる」。それは事実だ。しかし、セキュリティの現場で戦う我々にとって、その「便利さ」は常に「脆弱性のリスク」と表裏一体であることを忘れてはいけない。

1. プラグインを盲信しない: アップデート履歴やメンテナの署名を確認する。
2. サンドボックスで隔離する: 権限を剥奪して動かすのが鉄則。
3. 出口を塞ぐ: Egressフィルタリングで、データが外部へ漏れる経路を断つ。

今日紹介したコードは、あくまで「最低限の防御」だ。これをベースに、自分たちのプロダクトに合わせた「防御の多層化」を構築してほしい。君たちが書く一行のコードが、ユーザーの情報を守る最後の砦になる。頼んだぞ。