ベクトルDB（Pinecone / Weaviate）の脆弱性と侵入経路

ベクターDB（Pinecone / Weaviate）の脆弱性と侵入経路

生成AIの普及で、企業が独自ナレッジを格納するベクターデータベースの導入が急速に進んだ。Pinecone、Weaviate、Qdrant、Milvus、Chroma といった製品群は、社内文書・顧客対応履歴・契約書・ソースコードを埋め込みベクトルとして大量に保持している。しかしその多くは新興ミドルウェアゆえに運用の歴史が浅く、デフォルトで認証無効、Public 公開、暗号化未設定といった素朴な事故が後を絶たない^[1][2]。本稿は CISO・情シス向けに、ベクターDB の侵入経路と防御策を整理する。

1. ベクターDBがいま狙われる背景

ベクターDB は、テキスト・画像・音声を高次元ベクトル（embedding）に変換して類似検索するためのストアであり、RAG アーキテクチャの中核を担う^[3]。社内チャットボット、カスタマーサポート、コードアシスタント、医療・法務文書検索など用途は急速に広がっている^[4]。問題は、格納される「ベクトル」が単なる数値列ではなく原文の意味情報を強く保持する点だ。さらにベクターDB は新興 OSS が多く API ファースト設計ゆえ、Elasticsearch や MongoDB が辿った「初期設定で認証無し → Shodan で発見 → 全件ダンプ」のシナリオを再演しやすい^[6][7]。Wiz Research など複数のクラウドセキュリティベンダーも AI スタックの新たなアタックサーフェスとして警告している^[8]。

2. 主要製品のセキュリティ機能比較

SaaS 型（Pinecone・Zilliz・Weaviate Cloud）は最初から認証必須・暗号化済みである一方、OSS 版（Weaviate / Qdrant / Milvus / Chroma）は 「明示的に塞がない限り素通し」の設計思想を持つ^{[10][11][12][13]}。これは旧 Elasticsearch / MongoDB / Redis と同じ思想で、過去 10 年で繰り返し公開漏洩を生んだパターンそのものだ^[6][7]。

3. 公開インスタンス問題 — Shodan で見える VectorDB

Shodan・Censys 観測では、認証無しで到達可能な OSS ベクターDB が多数報告されている^[14]。代表的なポート（Qdrant 6333、Milvus 19530、Weaviate 8080、Chroma 8000）に対するクエリで、数百〜数千台規模の露出インスタンスが継続的に確認されている^[14][15]。多くはクラウド VM に開発者がそのまま立て、セキュリティグループを 0.0.0.0/0 で開けたまま放置したケースで、過去の Elasticsearch・MongoDB 漏洩と同じ構図だ^[6][7]。第三者が到達すれば、コレクション一覧 API・ベクトル取得 API は概ね認証無しで叩けるため、社内ナレッジ・顧客 FAQ・チャット履歴を 全件ダンプされる。Wiz Research は AI 関連スタックの Public 露出を継続的に警告している^[8]。

4. 既知脆弱性事例

ベクターDB 自身の CVE 報告も増えている。NVD には Milvus・Qdrant・Chroma・Weaviate について、認証バイパス、SSRF、パストラバーサル、依存ライブラリ起因の DoS／RCE が登録されている^[16]。多いのは (a) gRPC/HTTP ハンドラの入力検証不備、(b) Python SDK のデシリアライズ問題、(c) 周辺コンポーネント（etcd・MinIO 等）由来の CVE 連鎖の 3 系統^[16][17]。Hugging Face / LangChain など AI エコシステム側でも Pickle デシリアライズや SSRF が相次ぎ報告されており^[18]、パイプライン全体をアタックサーフェスとして見る必要がある^[16][19]。

5. Embedding Inversion による情報漏洩

「ベクトルは数値の羅列だから流出しても原文は分からない」という前提は崩れている。Cornell の Morris らによる vec2text（2023）は、対象モデルへのブラックボックスクエリのみで埋め込みから原文を高精度に復元できることを示し、32 トークン程度では正確一致率が 92% を超える条件も報告された^[20]。後続研究でも、医療記録・メール・契約書のように定型的で機微なテキストは商用埋め込みモデルの出力からも実用レベルで復元しうる^[21][22]。ベクターDB の漏洩は「原文の漏洩」と等価に扱うべきだ^[5][20]。

マルチテナント運用でも深刻だ。複数顧客のベクトルを同一インデックスに混載し Namespace 論理分離だけで運用する場合、フィルタ漏れや SDK バグで他テナントのベクトルが返り、攻撃者は invert モデルで原文を復元しうる^[5][22]。機密度の高いテナントは物理分離（別インスタンス・別キー）を原則とすべきだ^[9][23]。

6. 防御策の全体像

ベクターDB のセキュリティは 6 層で考える^[8][24]。

• 認証：OSS は 必ず API キー／OIDC を有効化。Weaviate は ANONYMOUS_ACCESS_ENABLED=false、Qdrant は service.api_key、Chroma は CHROMA_SERVER_AUTHN_PROVIDER の設定が出発点^[10][11][13]。
• 暗号化：通信は TLS 必須、保存時は KMS 連携の AES-256^[9][25]。
• ネットワーク分離：VPC／PrivateLink で Public IP を持たせない。SaaS でも IP 許可リスト・Private Endpoint を活用^[9][25]。
• RBAC とテナント分離：Read/Write/Admin を分け、アプリには最小権限の Read-only キー。機微テナントは物理分離^[9][12][23]。
• 監査と検知：Audit log を SIEM 転送し、大量取得・新規 Namespace 作成・キー発行を検知^[24]。
• データ最小化：PII はベクトル化前にマスキング、メタデータに原文を丸ごと残さない^[5][22]。

CISO・情シス向け 5 項目チェックリスト

1. 本番ベクターDB は Public IP を持たず、VPC / PrivateLink / IP 許可リストで限定されているか。
2. OSS 版を使う場合、デフォルトの匿名アクセス・認証無効が 明示的に 塞がれているか（設定ファイルで監査済みか）。
3. API キーは Vault / Secrets Manager 管理で、Read-only と Admin が分離されているか。
4. マルチテナント運用で、機微度の高いテナントは Namespace 分離ではなく インスタンス／キー分離になっているか。
5. 埋め込み元の原文・PII を不必要にメタデータへ保持していないか、invert 攻撃を脅威モデルに含めているか。

7. 経営層が打つべき手

第一に、社内ベクターDB の 棚卸しを 30 日以内に実施する。シャドー RAG（事業部が独自に立てた Chroma / Qdrant）を CASB・EDR・クラウド請求書から横断的に洗い出す^[8]。第二に、「ベクトルは原文と同等の機密情報」を社内ポリシーに明文化し、データ分類規程・委託先選定基準・DLP ルールへ反映する^[5][20]。第三に、SaaS 採用時は SOC 2 / ISO 27001 / ISMAP 等の第三者評価、暗号化・ネットワーク分離・監査ログの実装レベルを RFP 段階で必ず確認する^[9][25]。

ベクターDB の漏洩は「数値の漏洩」ではなく「原文の漏洩」である。Embedding Inversion 研究の進展により、ベクトル流出は実質的に文書流出と同義となった。情シス・CISO は、ベクターDB を「新しいミドルウェア」ではなく 「機密文書を保管するファイルサーバー」として扱うべきである。

結論（3 点）

1. OSS ベクターDB のデフォルト設定は「素通し」が前提。Elasticsearch / MongoDB が辿った Public 露出事故を、ベクターDB はいま再演している^[6][7][14]。
2. Embedding Inversion により、ベクトル漏洩は原文漏洩と等価。マルチテナントの論理分離だけでは機密データを守りきれない^[20][21][22]。
3. 防御は「認証・暗号化・ネットワーク分離・RBAC・監査・データ最小化」の 6 層を一気通貫で設計する。SaaS 選定時は第三者認証と Private Endpoint を必須要件とする^[8][9][25]。

経営者視点のサマリ

RAG を本番投入した瞬間、自社で最も機微なナレッジ（顧客リスト、契約書、社内手順、ソースコード、医療・法務記録）が 1 つの新しいデータストアに集約される。従来のファイルサーバーや DWH と同等以上のガバナンス（アクセス制御・暗号化・監査・委託先審査）をベクターDB にも適用する必要がある。特に「PoC で立てた Chroma / Qdrant をそのまま本番投入」「SaaS Free プランでテナント分離を Namespace に頼る」「原文をメタデータに丸ごと残す」の 3 点は、経営判断として明示的に禁止すべきアンチパターンだ^[5][8][13]。AI 投資の ROI を語る前に、生成 AI の心臓部であるベクターDB が自社のクラウド資産棚卸しに載っているかを確認することが、CISO・情シスの最初の一手である。

参考文献

1. OWASP, “Top 10 for Large Language Model Applications” (LLM06: Sensitive Information Disclosure, LLM08: Excessive Agency 等), 2023–2024.
2. NIST, “AI Risk Management Framework (AI RMF 1.0)”, 2023.
3. Lewis, P. et al., “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks”, NeurIPS 2020.
4. Gartner, “Emerging Tech Impact Radar: Generative AI”, 2024.
5. CSA, “Securing LLM Backed Systems”, 2024.
6. Diachenko, B., “Unsecured Elasticsearch / MongoDB exposure reports” (Security Discovery).
7. Shodan Blog, “The Hunt for Unsecured Databases”, 2019.
8. Wiz Research, “AI Security Posture Management” 関連レポート（Replicate / Hugging Face 等）, 2024.
9. Pinecone, “Security and Compliance” / “Enterprise SSO & RBAC” Documentation.
10. Weaviate Documentation, “Authentication” / “Anonymous access”.
11. Qdrant Documentation, “Security” / “API key configuration”.
12. Milvus Documentation, “Authenticate User Access” / “Enable RBAC”.
13. Chroma Documentation, “Authentication” / “Deployment & security”.
14. Shodan / Censys, 既定ポート（6333, 19530, 8080, 8000）に対する観測クエリ.
15. The Register / Bleeping Computer, “Exposed AI vector databases” 報道, 2024.
16. NVD, Milvus / Qdrant / Chroma / Weaviate 関連 CVE 一覧.
17. GitHub Security Advisories（GHSA）, 各ベクターDB リポジトリ.
18. Protect AI, “huntr” 報告群（LangChain・Hugging Face 等）, 2024.
19. 各製品公式 Security Advisories（Pinecone Trust Center 他）.
20. Morris, J. X. et al., “Text Embeddings Reveal (Almost) As Much As Text”, EMNLP 2023.
21. Li, H. et al., “Sentence Embedding Leaks More Information than You Expect”, ACL Findings 2023.
22. Pan, X. et al., “Privacy Risks of General-Purpose Language Models”, IEEE S&P 2020.
23. Microsoft, “Multi-tenant SaaS isolation patterns” Architecture Center.
24. MITRE ATLAS, “Exfiltration via ML Inference API” ほか.
25. IPA「AI 利活用におけるセキュリティ対策ガイドブック」/ 経産省「AI事業者ガイドライン」, 2024.