ゼロトラスト時代のRAGインフラ設計：保護対象領域とマイクロセグメントを定義する5ステップ

ゼロトラスト RAG ネットワーク設計は、2025年以降のエンタープライズAI基盤において避けられないテーマになっている。 RAG（Retrieval-Augmented Generation）はVector Store・LLM API・Orchestratorといった複数コンポーネントが連携するため、 単一の境界で守る従来のアプローチでは内部横断侵害（ラテラルムーブメント）を防げない。

本記事では、ゼロトラストの5ステップ方法論をRAG構成に直接当てはめ、 「どのコンポーネントに対して何をするか」を具体的に解説する。 KubernetesのNetworkPolicy YAMLとService Mesh mTLS設定例も含むため、 すぐに自分の環境へ適用できる。

この記事で分かること

  • RAGの各コンポーネント（Vector Store・LLM API・Orchestrator等）をDAAS分類して保護対象領域を定義する方法
  • ゼロトラストアーキテクチャ RAGに対応したKubernetes NetworkPolicy YAMLとService Mesh mTLSの実装例
  • 既存環境からゼロトラスト化するフェーズ1〜3のロードマップ

ゼロトラストの核心とRAGへの適用意義

ゼロトラストの出発点は「保護対象領域（Protected Surface）」の定義だ。 NIST SP 800-207が定義するゼロトラストアーキテクチャでは、守るべき対象を先に特定し、 そこへの通信経路のみを明示的に許可する。RAGにおける保護対象領域は以下の3つに集約される。

  • Vector Store：ドキュメントの埋め込みベクトルと原文チャンクが格納された知識DB
  • LLM API：推論リクエストと生成応答が流れる外部・内部エンドポイント
  • 管理UI / Orchestrator：クエリルーティング・プロンプト構成・システムプロンプトを操作できる制御面

従来のRAG設計では「クラスタ内は信頼できる」という暗黙の前提が残りやすい。 しかし、Vector StoreへのInjection攻撃（ベクトルポイズニング）や Orchestratorへの間接Prompt Injection攻撃が実証されている現在、 内部通信も「検証済みでなければ拒否」するマイクロセグメンテーション LLM設計が必須となる。

ゼロトラストアーキテクチャ RAGが解決するのは、VPNや境界ファイアウォールの廃止ではなく、 RAGコンポーネント間の最小権限通信の強制だ。 「誰が・どのコンポーネントに・何のプロトコルで・いつ」アクセスするかを ポリシーエンジンが継続的に評価する構造に切り替える。

ここまでのまとめ
RAGにゼロトラストを適用する起点は「保護対象領域の特定」。Vector Store・LLM API・Orchestratorの3箇所を先に定義し、そこへの通信経路だけを許可する設計に転換する。

RAGシステムのコンポーネント棚卸し

ゼロトラスト ポリシー設計の前に、全コンポーネントをDAAS（データ・資産・アプリ・サービス）に分類する。 これにより保護優先度と通信許可スコープが定まる。

コンポーネント DAAS分類 主要な通信先 機密度
Vector Store（例：Weaviate, pgvector） データ（D） Retriever, Indexer 🔴 最高（原文チャンク含む）
LLM API（OpenAI, Vertex AI, vLLM） サービス（S） Orchestrator 🔴 最高（プロンプト・レスポンス）
Orchestrator / LangChain / LlamaIndex アプリ（A） Vector Store, LLM API, API Gateway 🟠 高（制御フロー全体）
Embedder（embedding model server） サービス（S） Indexer, Retriever 🟡 中（入力テキスト処理）
API Gateway / Ingress サービス（S） 外部クライアント, Orchestrator 🟠 高（認証・レート制御点）
管理UI / Admin Console アプリ（A） Orchestrator, Vector Store 🔴 最高（システムプロンプト編集可）
Document Indexer / Crawler アプリ（A） Object Storage, Embedder, Vector Store 🟡 中（書き込み権限保持）
Object Storage（S3/GCS） データ（D） Indexer 🟠 高（生ドキュメント）
Secrets Manager（Vault, AWS SM） 資産（A） 全コンポーネント 🔴 最高（API Key, 証明書）
ここまでのまとめ
DAAS分類によってVector Store・LLM API・管理UIが最高機密度であることが明確化される。この3点を中心にマイクロセグメントを設計する。

ゼロトラスト適用5ステップ

Forresterが定義したゼロトラスト5ステップ方法論を、RAG構成に1:1で対応させる。 各ステップは「どのコンポーネントに対して何をやるか」で完結する。

Step 1：保護対象領域の定義

保護対象領域 DAASに基づき、3つの保護ゾーンを設ける。 機密度「最高」のコンポーネントを個別ゾーンに配置し、それ以外は接触禁止をデフォルトとする。 

保護ゾーン構成（論理分割）

┌──────────────────────────────────────────────────────┐
│  Zone A: Data Plane（最高機密）                       │
│   ├─ Vector Store (pgvector / Weaviate)              │
│   ├─ Object Storage (S3/GCS)                         │
│   └─ Secrets Manager (Vault)                         │
├──────────────────────────────────────────────────────┤
│  Zone B: LLM Service Plane（最高機密）                │
│   └─ LLM API Endpoint (vLLM / OpenAI Proxy)          │
├──────────────────────────────────────────────────────┤
│  Zone C: Application Plane（高）                      │
│   ├─ Orchestrator (LangChain / LlamaIndex)           │
│   ├─ Embedder                                        │
│   └─ Document Indexer                                │
├──────────────────────────────────────────────────────┤
│  Zone D: Control Plane（最高機密）                    │
│   └─ 管理UI / Admin Console                          │
├──────────────────────────────────────────────────────┤
│  Zone E: Ingress Plane（高）                          │
│   └─ API Gateway / Load Balancer                     │
└──────────────────────────────────────────────────────┘

Zone AへはZone Cのみアクセス可（読み取り専用）。 Zone BへはZone Cのみアクセス可（HTTPS, mTLS強制）。 Zone DはSREのIDプロバイダーが発行するJWTを保持するセッションのみ許可。

ここまでのまとめ
保護ゾーンはZone A〜Eの5区画に分割。機密度「最高」の3ゾーン（A・B・D）へはそれぞれ一方向の明示的許可通信のみを認める。

Step 2：トランザクションフローのマッピング

ユーザーリクエストからレスポンス返却までの全通信経路を可視化し、 各ホップで「誰が・何のプロトコルで・どのポートで」通信するかを確定させる。 

RAGトランザクションフロー（クエリパス）

[User Browser]
    │ HTTPS (TLS 1.3)
    ▼
[API Gateway: Zone E]  ← JWT認証, レート制限, WAF
    │ HTTPS + mTLS
    ▼
[Orchestrator: Zone C]
    ├──── gRPC/HTTPS ──────▶ [Embedder: Zone C]
    │                              │ embed query
    │                              ▼
    │         mTLS (port 5432) ──▶ [Vector Store: Zone A]
    │                              │ top-K chunks
    │                              ▼
    │         context returned ───▶ [Orchestrator: Zone C]
    │ HTTPS + mTLS
    ▼
[LLM API: Zone B]  ← prompt + context
    │ HTTPS response
    ▼
[Orchestrator: Zone C]
    │ HTTPS
    ▼
[API Gateway: Zone E] → [User Browser]

[管理UI: Zone D]
    │ mTLS + MFA required
    ▼
[Orchestrator / Vector Store admin API]  ← 別経路・別認証
ここまでのまとめ
フローマッピングにより「Orchestrator → Vector Store」「Orchestrator → LLM API」の2経路が最も高リスクなホップであることが特定できる。この2経路に最初にmTLSを適用する。

Step 3：ゼロトラストアーキテクチャ設計（マイクロセグメント分割）

KubernetesではNamespaceをセグメント境界として使い、 NetworkPolicy + Service Meshの2層でマイクロセグメンテーション LLMを実現する。 

Kubernetes Namespace マイクロセグメント構成

┌─────────────────────────────────────────────────────────┐
│ ns: rag-ingress                                         │
│  [api-gateway Pod]                                      │
│       │ allow: → rag-app/orchestrator (8080/TCP)        │
└───────┼─────────────────────────────────────────────────┘
        │ NetworkPolicy: allow ingress→app
┌───────▼─────────────────────────────────────────────────┐
│ ns: rag-app                                             │
│  [orchestrator] [embedder] [indexer]                    │
│       │ allow: → rag-data/vectorstore (5432/TCP)        │
│       │ allow: → rag-llm/llm-proxy  (443/TCP)           │
└───────┼────────────────────┼────────────────────────────┘
        │                    │ NetworkPolicy: app→data, app→llm
┌───────▼──────────┐  ┌──────▼──────────────────────────┐
│ ns: rag-data     │  │ ns: rag-llm                     │
│  [vectorstore]   │  │  [llm-api-proxy]                │
│  [object-store]  │  │                                 │
│  [vault]         │  │ deny-all default                │
│  deny-all default│  └─────────────────────────────────┘
└──────────────────┘
┌─────────────────────────────────────────────────────────┐
│ ns: rag-control  (完全分離)                              │
│  [admin-ui]  ← MFA + OIDC のみ到達可                    │
│  deny-all default, ingress: IdP経由セッションのみ        │
└─────────────────────────────────────────────────────────┘
ここまでのまとめ
4 Namespaceへの分割（rag-ingress / rag-app / rag-data / rag-llm / rag-control）がゼロトラストアーキテクチャRAGのKubernetes実装における最小構成。

Step 4：セキュリティポリシーの実装

NetworkPolicyはデフォルト拒否を基盤とし、必要な通信を個別Podセレクターで許可する。 Service Mesh（Istio / Linkerd）でmTLSを強制し、NetworkPolicyでカバーできないL7制御を補完する。

以下はOrchestratorからVector Storeへの通信を許可するNetworkPolicy YAML例（Step 3の設計に対応）：

# NetworkPolicy: rag-app Orchestrator → rag-data VectorStore (port 5432)
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-orchestrator-to-vectorstore
  namespace: rag-data
spec:
  podSelector:
    matchLabels:
      app: vectorstore
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: rag-app
          podSelector:
            matchLabels:
              app: orchestrator
      ports:
        - protocol: TCP
          port: 5432
---
# Default-deny: rag-data Namespace 全Pod への ingress/egress 禁止
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: rag-data
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Istioを使ったmTLS強制とPeerAuthentication（rag-appとrag-data間）：

# PeerAuthentication: rag-data Namespace 全通信をmTLS STRICT に設定
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: mtls-strict-rag-data
  namespace: rag-data
spec:
  mtls:
    mode: STRICT
---
# AuthorizationPolicy: rag-data/vectorstore への接続をrag-app ServiceAccountのみ許可
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-orchestrator-sa
  namespace: rag-data
spec:
  selector:
    matchLabels:
      app: vectorstore
  rules:
    - from:
        - source:
            principals:
              - "cluster.local/ns/rag-app/sa/orchestrator"
      to:
        - operation:
            ports:
              - "5432"
ここまでのまとめ
NetworkPolicy（L3/L4）とIstio AuthorizationPolicy（L7）の2層構成で、Orchestratorのみがvectorstoreへ到達できる最小権限を実装できる。

Step 5：監視・検証・継続改善

ゼロトラスト ポリシー設計は「設定して終わり」ではなく、 継続的な検証サイクルが不可欠だ。RAG特有の監視対象を明示する。

  • NetworkPolicy Audit Log：Calicoの felix_denied_packets_total メトリクスをPrometheusで収集、Vector Storeへの未許可到達試行をアラート化
  • mTLS Certificate Expiry：Istio Pilot metrics の citadel_server_csr_sign_error_count で証明書失効・署名エラーを検知
  • LLM API Request Tracing：OrchestratorからLLM APIへの全リクエストをOpenTelemetryで分散トレーシング。プロンプトサイズ異常（Injection兆候）を検知
  • Vector Store Access Pattern：大量chunkの一括取得（data exfiltration兆候）をPGAuditログで監視
  • 定期的なPolicy Review：OWASP LLM Top 10（LLM06: Sensitive Information Disclosure等）を参照し、四半期ごとにAuthorizationPolicyを棚卸し
ここまでのまとめ
監視の重点はNetworkPolicy拒否ログ・mTLS証明書状態・LLM APIトレーシングの3点。OWASP LLM Top 10を参照軸にPolicy Reviewを定期化する。

Kubernetesでの実装例

Namespace設計とNetworkPolicyサンプル

Step 3の設計をフルに実装する場合のNamespace構成と、 LLM API Proxy（rag-llm Namespace）へのアクセス制御YAMLを示す。 

# Namespace作成（labelはNetworkPolicyのnamespaceSelectorで使用）
apiVersion: v1
kind: Namespace
metadata:
  name: rag-ingress
  labels:
    zone: ingress
---
apiVersion: v1
kind: Namespace
metadata:
  name: rag-app
  labels:
    zone: app
---
apiVersion: v1
kind: Namespace
metadata:
  name: rag-data
  labels:
    zone: data
---
apiVersion: v1
kind: Namespace
metadata:
  name: rag-llm
  labels:
    zone: llm
---
apiVersion: v1
kind: Namespace
metadata:
  name: rag-control
  labels:
    zone: control

# rag-llm: default-deny + Orchestratorのみ443/TCPでアクセス許可
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: rag-llm
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-orchestrator-to-llm
  namespace: rag-llm
spec:
  podSelector:
    matchLabels:
      app: llm-api-proxy
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: rag-app
          podSelector:
            matchLabels:
              app: orchestrator
      ports:
        - protocol: TCP
          port: 443
---
# rag-llm Egress: 外部LLM API (例: api.openai.com) のみ許可
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-egress-llm-external
  namespace: rag-llm
spec:
  podSelector:
    matchLabels:
      app: llm-api-proxy
  policyTypes:
    - Egress
  egress:
    - to:
        - ipBlock:
            cidr: 0.0.0.0/0          # CIDRをOpenAI/Vertex AI IP rangeに絞ること
            except:
              - 10.0.0.0/8
              - 172.16.0.0/12
              - 192.168.0.0/16
      ports:
        - protocol: TCP
          port: 443

Service MeshによるmTLSとポリシー適用

NetworkPolicyはIPレイヤーでの制御に留まるため、Service Meshを追加してL7制御と証明書ベースの相互認証を重ねる。 

Service Mesh mTLS レイヤー（Istio）

[orchestrator Pod]
    ↓ Envoy Sidecar
    │  発信側証明書: cluster.local/ns/rag-app/sa/orchestrator
    │  mTLS (SPIFFE/SPIRE)
    ▼
[llm-api-proxy Pod]
    ↑ Envoy Sidecar
    │  受信側証明書を検証
    │  AuthorizationPolicy: principals チェック
    └── NG → 即時 RST（TCP接続リセット）
        OK → 443/TCP 通過

証明書ローテーション: Istio Citadel が24h毎に自動発行
監査ログ:  Envoy Access Log → Fluentd → SIEM
ここまでのまとめ
NetworkPolicy（L4）+ Istio PeerAuthentication/AuthorizationPolicy（L7）の2層で、コンポーネント間通信を証明書ベースで相互検証する構成を完成できる。

クラウド（AWS / GCP / Azure）対応設計パターン

マネージドRAGインフラをクラウドで構築する場合、各プロバイダーのゼロトラスト対応コンポーネントは異なる。 以下にKubernetesのNetworkPolicy相当機能と、LLM API保護に使えるサービスを比較する。

設計要素 AWS GCP Azure
Namespace分離（K8s） EKS + VPC CNI
Network Policy		 GKE + Dataplane V2
（Cilium内包）		 AKS + Azure CNI
Network Policy
Service Mesh mTLS AWS App Mesh
or Istio on EKS		 Anthos Service Mesh
（Istio互換）		 Open Service Mesh
or Istio on AKS
Vector Store保護 OpenSearch VPC Endpoint
+ Security Group		 Vertex AI Vector Search
Private Service Connect		 Azure Cognitive Search
Private Endpoint
LLM APIゲートウェイ保護 API GW + WAFv2
+ PrivateLink		 Apigee + VPC SC
（VPC Service Controls）		 Azure API Management
+ Private Link
Secrets管理 AWS Secrets Manager
+ KMS		 Secret Manager
+ Cloud KMS		 Azure Key Vault
+ Managed HSM
Identity（SPIFFE相当） IAM Roles for SA（IRSA） Workload Identity Workload Identity
for AKS
ゼロトラスト統合製品 AWS Verified Access BeyondCorp Enterprise Azure AD Conditional Access

GCPはDataplane V2でCiliumがGKEに組み込まれているため、 NetworkPolicy + L7 Policy（CiliumNetworkPolicy）を追加CNI不要で利用できる点が設計上のアドバンテージになる。 AWSはPrivateLinkとIRSAの組み合わせがゼロトラスト的に最も成熟している。

ここまでのまとめ
各クラウドともKubernetesのNetworkPolicy＋Service Meshの組み合わせはサポートされる。GCPのDataplane V2はL7制御まで含めた統合度が高く、GKE環境では追加CNI導入なしでCiliumPolicy を活用できる。

既存環境からのゼロトラスト化ロードマップ

稼働中のRAG環境をダウンタイムなくゼロトラスト化するには、フェーズを分けた段階的適用が現実的だ。

フェーズ1：可視化と棚卸し（〜4週間）

  • 全コンポーネントのDAAS分類を実施（本記事Section 2のテーブルを実環境に当てはめる）
  • 既存クラスタにCiliumまたはCalico ObservabilityモードをDryRunで導入し、実際の通信フローを可視化
  • NetworkPolicyをAudit（監視のみ）モードで適用し、拒否対象となる通信を洗い出す
  • Istioをサイドカーインジェクション無効で導入し、mTLSなし状態のトラフィックを記録

フェーズ2：rag-dataとrag-llmのハードニング（〜8週間）

  • 機密度「最高」のNamespace（rag-data, rag-llm）にdefault-deny NetworkPolicyを適用
  • Orchestrator → Vector Store, Orchestrator → LLM APIの2経路にmTLS STRICTを有効化
  • Secrets ManagerをVaultまたはクラウドネイティブに移行し、環境変数でのSecret保持を廃止
  • Vector StoreへのSQL/gRPCアクセスをServiceAccount単位でIRSA/Workload Identityに統一

フェーズ3：全Namespaceのゼロトラスト化と継続監視（〜12週間）

  • rag-app, rag-ingress, rag-controlにもdefault-denyを順次適用
  • 管理UIへのアクセスをOIDC + MFAのみに制限し、直接Podへのkubectl execを禁止
  • OpenTelemetryによる全ホップのトレーシングをSIEMに接続し、OWASP LLM Top 10の監視ルールを実装
  • 四半期ごとのPolicy Review（AuthorizationPolicy棚卸し）と年1回のペネトレーションテストを定常プロセス化
ここまでのまとめ
フェーズ1で可視化→フェーズ2で最高機密ゾーンのハードニング→フェーズ3で全体適用と監視定常化、という3段階が現実的なゼロトラスト化のロードマップ。

📚 シリーズの関連記事