Vault Enterprise Filtered Pathsで複製対象を最小化する: 運用設計と試験対策

Vaultのレプリケーションは便利ですが、すべてを複製すべきとは限りません。コンプライアンスやデータ局所性の観点から、複製対象を意図的に絞り込む設計が求められます。

本稿では、Vault EnterpriseのFiltered Paths（パスベースのフィルタ）を中心に、パフォーマンスレプリケーションでの複製対象の制限手法、DRレプリケーションとの違い、ローカルマウントや名前空間と組み合わせた現実的なパターンを解説します。

Filtered Pathsの概要と前提

Filtered Pathsは、Vault Enterpriseのパフォーマンスレプリケーションにおいて、複製対象をパス単位で絞り込むための仕組みです。インクルード（許可）/エクスクルード（拒否）ルールを定義し、セカンダリに送るデータの最小化を図れます。

重要なポイントは、Filtered Pathsはレプリケーション層の制御であり、クライアントへのアクセス制御（ポリシー）とは異なるという点です。ポリシーは読み書き可否を制御しますが、Filtered Pathsはセカンダリに『届くデータそのもの』を限定します。

また、ローカルマウント（local=true）を使うと、該当マウント配下のデータはパフォーマンス/DRの両方で複製対象外になります。より粗い粒度ですが、確実に除外できます。

• 対象: Vault Enterpriseのパフォーマンスレプリケーション
• 目的: セカンダリに送るデータ量・範囲の最小化（コスト/リスク低減）
• 補完関係: ポリシーはアクセス制御、Filtered Pathsは複製対象の制御
• 代替/補助: ローカルマウント、名前空間スコープのセカンダリ

パフォーマンス/DRレプリケーションの比較と制限のかけ方

Vaultのレプリケーションには主にパフォーマンスレプリケーションとDRレプリケーションがあります。Filtered Pathsはパフォーマンスレプリケーションで利用する考え方です。DRレプリケーションはフェイルオーバー目的であり、選別複製よりも完全性重視です。

複製対象を制限する手法は複数あり、要件に応じて使い分けます。細かく制御したい場合はFiltered Paths、マウント全体を除外したいならローカルマウント、テナントや組織単位で分けるなら名前空間スコープのセカンダリが適します。

• パフォーマンスレプリケーション: 読み取り分散・低レイテンシ向け。Filtered Pathsが設計の中心
• DRレプリケーション: 障害時の切替重視。原則として選別は行わず、必要最小限の除外はローカルマウントで
• 名称空間スコープ: マルチテナンシで特定サブツリーのみをセカンダリにする設計に有効

フィルタ設計の基本: インクルード中心と命名規則

パスベースのフィルタは誤設定があるとデータ漏えいまたは想定外の欠落を招きます。実務では『インクルード中心（許可リスト）＋最小権限』を基本に、対象を段階的に広げるのが安全です。

パス命名はプレフィックスでグルーピングし、チーム/システム/データ機密度を階層に反映します。これにより職責境界がそのままフィルタルールに落とし込みやすくなります。KV、PKI、Transitなどエンジン種別に関わらず、論理パスの前方一致で設計可能です。

Filtered Pathsのルールは、専用の設定でインクルード/エクスクルードを定義して適用します。評価順序や詳細仕様は利用中のVault Enterpriseバージョンのドキュメントに従い、ステージング環境で必ず検証してください。

• 許可リスト（allow-list）を起点に必要最小限から開始
• パスの粒度はチームや境界に揃える（team-a/* など）
• 命名規則を文書化し、CIで逸脱検知
• 変更は段階適用＋監査ログで確認

Filtered Pathsの評価イメージ

実装パターン: Filtered Paths/名前空間/ローカルの使い分け

細粒度に複製を制限したい場合はFiltered Pathsを中心に設計します。チーム単位やアプリケーション単位で論理パスを整理し、許可リストを定義します。監査やメトリクスで影響範囲を観測しながら段階的に拡張します。

テナント分離が前提の環境では、名前空間スコープのセカンダリを採用し、組織境界で複製を分けると運用が単純になります。各セカンダリ側に必要最小のパスのみが存在する状態をポリシーと合わせて維持します。

コンプライアンス上セカンダリに出せないデータ（例: 特定地域限定データ、実験用マウントなど）は、マウントをlocal=trueで作成/調整し、レプリケーション層から完全に除外します。

• Filtered Paths: 細粒度な最適化。変更時は段階適用＋ロールバック計画
• 名前空間スコープ: マルチテナント運用での基本形。境界設計が要
• ローカルマウント: 強制除外。マウント全体の不複製化に最適

運用: 検証、監査、変更管理

フィルタ設計は必ずステージングのセカンダリで検証します。代表的なパスにテストデータを投入し、到達可否とポリシー整合を確認します。監査ログ（audit）やメトリクスで想定外の到達/欠落がないかを継続監視します。

変更は申請・レビュー・実装・検証のワークフローを整備し、ロールバック手順を事前に用意します。Filtered Pathsのルール変更は将来の複製に影響します。既にセカンダリに存在するデータの扱い（自動削除の有無や手動クリーンアップ方針）は事前に合意しておきます。

DRレプリケーション環境では、原則として選別を行わず、どうしても除外が必要なものはローカルマウントを用いる方針に統一すると運用が安定します。

• ステージングでの到達確認と監査ログ突合
• 変更は小さく、影響範囲を明示した上で適用
• DRは完全性優先。除外はローカルマウントで一貫
• メトリクス/ステータスAPIでバックログを常時監視

CLI最小構成例: ローカル除外とパフォーマンスレプリケーションの有効化

以下は、ローカルマウントで一部マウントを複製対象外にしつつ、パフォーマンスレプリケーションを有効化する最小例です。Filtered Pathsのルール設定自体はEnterprise機能の詳細に依存するため、利用中のバージョンの公式手順に従ってください。

ポイントは、team-b マウントを local で作成しておくと、パフォーマンス/DRの双方で複製対象外になること、そしてteam-aは複製されることを確認できる構成になっている点です。

• ローカルマウント: マウント全体を確実に除外
• パフォーマンスレプリケーション: 読み取り分散向け。Filtered Pathsの設計は別途

例: ローカル除外 + パフォーマンスレプリケーション

# Primary でログイン
vault login <root>

# マウント作成（team-a は複製対象、team-b はローカル＝除外）
vault secrets enable -path=team-a kv-v2
vault secrets enable -local -path=team-b kv-v2

# サンプルデータ投入
vault kv put team-a/app foo=bar
vault kv put team-b/app baz=qux

# パフォーマンスレプリケーションを有効化（Primary 側）
vault write -f sys/replication/performance/primary/enable

# セカンダリ有効化用のトークンを作成（出力値を控える）
# 実際の出力・パラメータは利用バージョンのドキュメントに従ってください
vault write -f sys/replication/performance/primary/secondary-token

# Secondary 側で有効化（<token>は上記で取得）
vault write sys/replication/performance/secondary/enable token=<token>

# 検証: Secondary で team-a は取得可能、team-b は存在しない想定
vault kv get team-a/app     # => 存在するはず
vault kv get team-b/app     # => 見つからない（local で除外）

試験対策: Ops視点で落としやすいポイント

Filtered Pathsはパフォーマンスレプリケーションの話題であり、DRでの選別は基本想定外である点を混同しないでください。マウントのlocalフラグは両方のレプリケーションに効く排他的な除外です。

ポリシーdenyではレプリケーション自体は止まりません。『セカンダリにデータを運ばない』要件には、Filtered Pathsやローカルマウントを使います。

名前空間スコープは粗い粒度での分離に有効ですが、パス単位の最適化はFiltered Pathsで補います。

• DRでのパス選別は不可。局所性は設計で回避
• local=true は強力な除外。慎重に適用
• アクセス制御（ポリシー）と複製制御（Filtered Paths）は別物

問題で確認

よくある質問