ローカルLLM セキュリティ対策｜Ollama・vLLMの守り方とチェックリスト

関連記事AIセキュリティ対策の仕組みとは？攻撃を防ぐ10の方法とAI自体の守り方【2026年】 ／ ollama ragをローカルで構築する実装ガイド｜設計から運用まで ／ Ollama API完全リファレンス｜エンドポイント・実装・運用設定【2026年版】

結論：ローカルLLMは「社内に置けば安全」ではない――守る5つの層

ローカルLLMの最大の誤解は「クラウドを使わなければ情報は外に出ない」という前提だ。実際には推論サーバーの認証欠如・モデルファイルの汚染・RAGの権限設計ミス・プロンプトインジェクションなど、クラウドとは別の攻撃面が存在する。2026年の実際の事故はその前提を覆した。

守るべき層は次の5つに整理できる。

• ①推論サーバー：Ollama・vLLM・llama.cppの認証欠如・CVEへの対処
• ②モデルファイル：サプライチェーン汚染・形式の選択・版の固定
• ③RAG：検索段階での権限フィルタ設計
• ④入出力：プロンプトインジェクション対策（OWASP LLM Top 10 2026）
• ⑤運用：更新管理・露出点検・ログ

---

2026年に実際に起きたこと――Ollama 17.5万台露出・Bleeding Llama・vLLM RCE

2026年1月、SentinelLABSとCensysの調査で130か国・17.5万台以上の公開Ollamaサーバーがインターネット上に露出していることが確認された（The Hacker News, 2026年1月）。その多くはOLLAMA_HOSTを0.0.0.0に変更したままファイアウォールを設定していないケースで、ツール呼び出し（function calling）を有効にしたサーバーも多く含まれていた。計算資源を不正利用する「LLMjacking」（Operation Bizarre Bazaar）の悪用も報告されている。

続いて2026年に発覚したCVE-2026-7482（通称：Bleeding Llama、CVSS 9.1）はより深刻だ。Cyeraが発見したこの脆弱性は、認証なしのAPI呼び出し3回でサーバーのメモリ全体――APIキー・システムプロンプト・会話履歴・コードを含む――を抜き取れるというものだ（Indusface、CSA Research Note）。細工したGGUFファイルのモデル作成処理が悪用経路で、修正はOllama 0.17.1。公開状態だった期間があれば、APIキー・認証情報の全ローテーションが必要になる。

vLLMでもCVE-2026-22778（CVSS 9.8）として細工した動画URLによる認証なしのリモートコード実行が確認されており、0.14.1以降への更新が推奨されている（Orca Security）。llama.cppでもCVE-2026-43631（--sleep-idle-seconds を有効時の認証なしRCE、ビルドb7492〜b9060）が公開された（NVD）。

これらはすべて「社内配置のローカルLLM」で発生し得る問題だ。クラウドを使わないことと、安全であることはイコールではない。

---

①推論サーバーの守り方――Ollama・vLLM・llama.cppの脆弱性と対策

推論サーバー3製品の主な脆弱性と対策を下表に整理する。

※修正版の番号は情報源によって食い違いがある。各ソフトのGitHubセキュリティ勧告とCVE記録を必ず直接確認する。

基本構成のポイントは次のとおりだ。

• 待ち受けは127.0.0.1に固定し、推論ポート（Ollamaなら11434番等）をファイアウォールで遮断する
• 他の端末と共有する場合は許可済み社内IPのみに制限する
• 前段にNginx等のリバースプロキシを置き、認証とTLSを全パスに対して終端する（vLLMの認証バイパスCVEはプロキシでエンドポイント全体を保護することで影響を抑えられる）
• 専用ユーザーで実行し、systemdのProtectSystem・PrivateTmp等でプロセスを隔離する
• auditdで操作ログを記録し、/api/createへの不審なアクセスを確認できるようにする
• CORSで*（ワイルドカード）を使わない
• 動画入力・モデル作成・送信など使わない機能は起動オプションで止める

参考：Ollama Linuxセキュリティ強化ガイド（Linux Master, 2026年8月）、Mondoo: Three Ollama CVEs

OllamaのAPIの仕組みと使い方はOllama APIの解説にまとめている。

---

②モデルファイルの守り方――safetensors・trust_remote_code・版の固定

モデルの重みファイル自体が攻撃経路になる点は、推論サーバーのCVEと同様に見落とされやすい。

形式の選択

• pickle形式：読み込み時に任意コードを実行できる。使用しない
• safetensors：データのみの形式で読み込み時にコードを実行しない。重みの配布形式として推奨（DataCamp: safetensors format）
• GGUF：読み込み時のコード実行はないが、チャットテンプレート（Jinja2）に命令を仕込むリスクが指摘されている（1件）。llama.cppのCVE（上記）も念頭に置く

trust_remote_code=True を使わない

Hugging Faceからモデルを取得する際にtrust_remote_code=Trueを指定すると、リポジトリに同梱されたPythonコードをそのまま実行する。重みがsafetensors形式でも、同梱コードに仕込まれた悪意あるコードが実行される。2026年の研究では、ローカルでのファインチューニング中にモデル同梱コードの裏口からAPIキーを盗む手口が示されている（arxiv: 2604.27426）。

スキャナーへの過信は禁物

PickleScan等のスキャナーは既知の手口にマッチするものを検出するにすぎず、陰性であっても安全の証明にはならない。2025年2月には7z圧縮でPickleScanを回避した「NullifAI」事例が報告されている（stingrai.io）。

版（コミット）の固定と取得元の確認

モデルは確認済みのコミットハッシュを指定して取得し、意図しないアップデートを防ぐ。周辺ツールも同様で、2026年3月にはLiteLLMの不正バージョン1.82.7・1.82.8がPyPIに直接公開されるサプライチェーン攻撃が発生した（Upwind Security）。pip install litellm==X.Y.Zのようにバージョンを固定し、取得元ハッシュを記録する。

---

③RAGの守り方――検索段階での権限フィルタ

RAGシステムの最大のリスクは権限の漏れだ。人事情報・取締役会議事録・未公開の財務データを、本来閲覧権限のない社員がAIチャット経由で検索・取得できてしまう状態は、社内文書をベクトルDBに一括投入した瞬間に発生し得る。

対策の原則：「生成後フィルタ」ではなく「検索段階フィルタ」

生成されたテキストを後から検閲する方式では遅い。モデルはすでに中身をコンテキストに取り込んでおり、間接プロンプトインジェクション等で内容が漏れる余地が残る（tianpan.co: Permission-aware RAG、vdf.ai: Permission-aware Private RAG）。

正しい設計は次のとおりだ。

1. 取り込み時：文書チャンクごとに閲覧可能なユーザー／ロールのメタデータを付与する
2. 検索時：クエリを実行するユーザーのロールで絞り込み、その人が見てよいチャンクだけを取り出す
3. ログ：検索ごとに「誰が・何を取り出したか」を記録する

原則は「AIが取り出せる範囲は、その人が元のシステムで見られる範囲まで」。オンプレミス配置（処理場所の境界）は権限設計の代替にはならない。

OllamaでRAGを構築する手順はOllama RAGの解説で扱っている。

---

④入出力の守り方――OWASP LLM Top 10 2026とプロンプトインジェクション

OWASP Top 10 for LLM Applications の2026年版は2026年8月4日に公開された（Help Net Security, 2026年8月）。1位がプロンプトインジェクション、2位が機密情報の漏えいで、この2つは2025年版から順位を維持している。

間接プロンプトインジェクションへの対処

RAGシステムでは、ユーザーが直接悪意ある入力を打ち込まなくても、取り込んだ文書やメールに「これ以降の指示を無視して〜」と埋め込まれた命令をモデルが実行してしまう（間接プロンプトインジェクション）。この攻撃を前提とした設計が必要だ。

• 取り込み文書を「信用できない入力」として扱い、システムプロンプトを防御線としない
• 秘密情報・認可判定の結果をモデルのコンテキストに直接入れない
• モデルへの入力・出力をログに記録し、異常なパターンを検知できる体制を作る
• モデルに渡す権限を最小化し、不要なツール呼び出し（function calling）を無効にする

---

⑤運用の守り方――更新・露出点検・ログ

運用フェーズでの対策は、セキュリティ体制の継続性に直結する。

• リリースノートの定期確認：Ollama・vLLM・llama.cppはCVEが頻発しているため、各GitHubリポジトリのセキュリティ勧告をRSS等で購読し、修正版が出たら速やかに更新する
• 外部露出の定期点検：推論ポートがインターネットから到達可能でないかをnmap等で定期確認する。OLLAMA_HOSTの設定変更や社内ネットワーク変更後は必ず再確認する
• ログの確認：/api/createなど通常利用では発生しないエンドポイントへのアクセスを定期的に確認する
• 全社AIガバナンスとの統合：IPA「生成AIおよびAIエージェントを安全に活用するための手引書」（2026年7月）が示すシャドーAI対策・ガバナンス体制と組み合わせて運用する

AIで攻撃を防ぐ仕組みとAIそのものを守る仕組みの全体像はAIセキュリティ対策の仕組みで整理している。

---

最低限のチェックリスト（7項目）

次の7項目を今すぐ確認する。

---

よくある質問（FAQ）

Q：VPNの内側にあれば外部露出の心配はないか？

VPNはインターネットからの直接経路を遮断するが、VPN接続済みの端末が侵害された場合、その端末から認証なしで推論サーバーに到達できる。侵害済み端末からの横移動（ラテラルムーブメント）は防げないため、VPNとは別にネットワークセグメント・認証・ログの対策が必要だ。

Q：Ollamaをローカル1台で使うなら外部公開のリスクはないか？

1台使用・127.0.0.1待ち受け・ポート遮断の状態であれば外部公開のリスクは抑えられる。ただしCVE-2026-7482（Bleeding Llama）のように認証なしのローカルAPIが悪用される経路は存在する。バージョンを最新に保つ・不要なエンドポイントを止める・モデルのサプライチェーンを管理する対策は1台構成でも必要だ。

Q：safetensors形式ならピックル攻撃から完全に安全か？

safetensorsは読み込み時のコード実行を防ぐが、trust_remote_code=Trueを使えばリポジトリの同梱コードが実行される。形式と取得オプションは別の問題として管理する必要がある。

Q：RAGをオンプレミスに置けば情報漏えいのリスクはないか？

処理場所の境界と権限設計は別の対策だ。オンプレ配置でも権限フィルタなしでベクトルDBに文書を一括投入すれば、社内の誰でもAI経由で全文書を取り出せる状態になり得る。

---

参考文献

• The Hacker News (2026年1月)「Researchers Find 175,000 Publicly Exposed Ollama Servers」https://thehackernews.com/2026/01/researchers-find-175000-publicly.html
• Indusface「CVE-2026-7482: Bleeding Llama Vulnerability」https://www.indusface.com/blog/cve-2026-7482-bleeding-llama-vulnerability/
• Cloud Security Alliance Research Note「Ollama Bleeding Llama CVE-2026-7482」https://labs.cloudsecurityalliance.org/wp-content/uploads/2026/05/CSA_research_note_ollama-bleeding-llama-cve-2026-7482-ai-inference-exposure_20260511-csa-styled.pdf
• Mondoo「Three Ollama CVEs: Bleeding Llama and Windows Updater Flaws」https://mondoo.com/blog/three-ollama-cves-bleeding-llama-and-windows-updater-flaws
• Red Hat「CVE-2026-48746」https://access.redhat.com/security/cve/cve-2026-48746
• Orca Security「CVE-2026-22778: vLLM RCE Vulnerability」https://orca.security/resources/blog/cve-2026-22778-vllm-rce-vulnerability/
• NVD「CVE-2026-43631」https://nvd.nist.gov/vuln/detail/CVE-2026-43631
• Linux Master「Ollama Linuxセキュリティ強化ガイド」（2026年8月）https://www.linuxmaster.jp/linux_skill/2026/08/ollama-linux-security-hardening.html
• arxiv「Fine-tuning and backdoor risks in local LLMs」https://arxiv.org/html/2604.27426v1
• Upwind Security「LiteLLM PyPI Supply Chain Attack」https://www.upwind.io/feed/litellm-pypi-supply-chain-attack-malicious-release
• stingrai.io「Clean Model Scan Is Not Safe: PickleScan and safetensors」https://www.stingrai.io/blog/clean-model-scan-not-safe-picklescan-safetensors
• DataCamp「safetensors format」https://www.datacamp.com/blog/safetensors-format
• tianpan.co「Permission-aware Retrieval: Enterprise RAG Access Control」（2026年5月）https://tianpan.co/blog/2026-05-04-permission-aware-retrieval-enterprise-rag-access-control
• vdf.ai「Permission-aware Private RAG On-Premises」https://vdf.ai/blog/permission-aware-private-rag-on-premises/
• Help Net Security「OWASP 2026 LLM Top 10 Released」（2026年8月）https://www.helpnetsecurity.com/2026/08/06/owasp-2026-llm-top-10-released/