自己ホスト型LLMのセキュリティ強化：チェックリスト

Ollamaやllama.cpp、vLLM、LM Studioを使ってローカルでモデルを実行するのは簡単な作業です。しかしチームメンバーやエージェント、別のマシンからそのエンドポイントにアクセスさせる際にセキュリティを確保することは難しく、多くの設定で失敗が生じます。このチェックリストでは、実際に問題となりやすい項目を順を追って解説し、Tokiosのようなアウトバウンド専用コネクターを導入すればどの項目がもはや懸念事項とならなくなるかも示しています。 これはあくまでチェックリストであり、絶対的な保証ではありません。これに従うことでリスクは低減しますが完全に排除されるわけではなく、Tokiosを含めどの設定も絶対に破られないという保証は一切ありません。

​

1. バインドアドレス：ループバックに限定する

この分野の各ランタイムがデフォルトで127.0.0.1（ループバックのみ）を採用しているのには理由があります。これが最も効果的な制御手段であり、実行中のマシン以外からAPIにアクセスできないようにするためです。

• Ollamaはデフォルトで127.0.0.1:11434でリスニングします。OLLAMA_HOST=0.0.0.0を設定するとすべてのネットワークインターフェースでリスニングするようになり、LAN内の他マシンや、ポートが外部に転送されていればインターネットからもアクセス可能になります。
• llama.cpp server、vLLM、LM Studioも同様で、デフォルトはループバック設定ですが、フラグや設定項目を使って0.0.0.0や特定のLANインターフェースにバインドすることも可能です。

チェック項目：ループバック以外のアドレスにバインドする明確な理由がない限り、そうしない方が良いでしょう。LANや遠隔アクセスが必要な場合は、このチェックリストの他の項目やアウトバウンド専用コネクターを利用してください。

​

2. 認証処理：ほとんどのランタイムでは認証機能が存在しないか、任意設定のみ

ループバック以外のアドレスにバインドしつつ認証処理がなければ、該当ポートに到達可能な誰でも資格情報なしにAPIを呼び出せるようになります。モデル一覧の取得や推論の実行、モデルのダウンロードも可能になってしまいます。 チェックリスト項目：複数の人物やサービスがエンドポイントを呼び出す場合、共通の静的キー（あるいはキーなし）では呼び出し元を識別できず、特定の相手だけの認証解除も不可能だ。詳細なトレードオフについては キーの不要なローカルモデルにAPIキーを追加する を参照のこと。

​

3. ファイアウォールと受信ポートの設定

ループバックより広範囲にバインドする場合、次に設定すべきはその前段にあるファイアウォールだ。

• 可能な限り、受信ポート（Ollamaでは 11434、llama.cppでは 8080、vLLMでは 8000、LM Studioでは 1234）を特定の送信元IPに限定し、あらゆるアドレスからのアクセスを許可しないようにする。
• ルーター上でポート転送を行うには安定したパブリックIPが必要だ。多くの家庭用回線やモバイル回線はCGNATの背後にあり、そもそも転送用のパブリックIPが存在しない。詳細は CGNAT下にあるモデルにアクセスする方法 をご覧ください。
• ShodanやCensysといったインターネット全体をスキャンするツールは、新たに開放されたサービスを数時間から数日以内にインデックス化する。認証なしで開放されたポートは長く見過ごされることはない。

チェックリスト項目：「ポートは一時的にしか転送していない」という状況でも発見される可能性がある。ポートが開放されている限り、発見されると見なすべきだ。

​

4. リバースプロキシ利用時の落とし穴

上記の認証問題を解決するため、キーの不要なランタイムの前段にnginxやCaddyを配置するのがDIY的な対策として最も一般的だが、それには注意すべき点が多数存在する。

• TLS終端処理。プロキシには有効な証明書が必要です。自己署名証明書ではほとんどのHTTPクライアントの信頼チェックが失敗してしまいます。
• ストリーミング応答。LLM APIはServer-Sent Events（SSE）を通じてトークンをストリーム配信します。応答内容を一旦バッファリングしてから送信するリバースプロキシやアップストリームCDNでは、本来はトークンごとにストリームされるはずのチャットが、応答全体が揃うまで応答が止まったりタイムアウトしたりする事態が起こり得ます。
• 認証ロジックはプロキシ設定側に存在し、モデルサーバー側にはない。プロキシの認証ルールを正しく維持し、同期させ、テストすることは利用者の責任となります。実行環境側にはユーザーごとのAPIキーに関する概念は存在しません。
• タイムアウト。生成処理に時間がかかると、プロキシやエッジネットワークの既定のリクエストタイムアウトを超えてしまい、ストリーム中に応答が切断される可能性があります。

チェックリスト項目：リバースプロキシを導入する際は、高速かつ短時間の応答だけでなく、遅いストリーム応答もエンドツーエンドで必ずテストしてから本番環境で利用するようにしてください。

​

5. ランタイムをパッチ適用状態のまま維持すること

ローカル推論サーバーも通常のソフトウェアと同様に脆弱性が存在し、公開されたCVE番号が悪用されるケースもあります。例えばOllamaにもこれまでにセキュリティアドバイザリーが公開されています。特定のCVE番号や修正済みバージョンを信頼する前に、プロジェクトのGitHub上のセキュリティアドバイザリーやNVDで最新情報を確認してください。 チェックリスト項目：実行環境のリリースノートやセキュリティアドバイザリーを定期的に確認し、動作しているからといって特定バージョンを無期限に使い続けないようにしてください。サーバーがループバック上にあるか外部に公開されているかに関わらず、ホストが侵害された場合はネットワーク全体に問題が生じます。

​

アウトバウンド専用モードではこのリストから特定の項目が完全に除外される。

上記の各項目は、外部からの接続を受け付けるためのリスナーが必要だから存在するのです。アウトバウンド専用コネクター（Tokiosコネクターがその一例）ではその仕組みが逆転します。コネクタープロセスはモデルと同じ場所で動作し https://api.tokios.com へ接続を開始するため、マシンやネットワーク上でモデル通信用のポートを待ち受けるプロセスは一切存在しません。 これにより一部のチェックリスト項目は完全に不要となり、他の項目はそのまま残る。

• 受信用ポートのバインドや転送が不要。モデルは 127.0.0.1 上で動作し続け、コネクターが外部へ接続するため、0.0.0.0 のバインド処理やポート転送ルール、CGNATによる接続問題などを解決する必要は一切ない。
• モデル用ポートに対するファイアウォールルールは存在しない。 ファイアウォールがモデルのために許可またはブロックすべき受信通信は何もないのだ。
• No reverse proxy needed for TLS or routing. The connection to https://api.tokios.com is already TLS; you aren’t running or maintaining nginx or Caddy to get there.
• 単一の共有静的APIキーの代わりに、スコープ付きの個別APIキーを利用。 各リクエストはTokiosの sk-tok-… キーで認証される。このキーは特定のモデルデプロイごとにスコープ設定が可能（gemma*, gpt-4*のようなカンマ区切りのグロブ指定も可）かつ個別に無効化もできる。つまりチームメンバーやサービスごとのアクセス権を取り消す際にも、他者が利用中のキーを一斉に更新する必要がないのだ。詳細は キーレスなローカルモデルにAPIキーを追加する方法 を参照されたい。
• 変更されない点：パッチ適用。 Tokiosは実行環境の前段に位置するだけで、その内容を修正することはない。Ollamaやllama.cpp、vLLM、LM Studio自体を最新状態に保つ責任は依然として利用者側にある。コネクターの有無に関わらずだ。

万が一リクエストがエラーとなった場合でも、直ちにセキュリティ問題と断定せずに トラブルシューティング で一般的な原因を確認されたい。ほとんどの接続障害は設定ミスが原因であり、不正アクセスによるものではない。

​

送信専用の設定へ移行する