Vault EGP（Endpoint Governing Policy）で実現するエンドポイント単位の制御

EGPはVault EnterpriseのSentinel統合により、APIエンドポイント単位で事前・事後の評価を行い、柔軟な制御を追加できる仕組みです。

本稿ではACLとの違い、評価フロー、パス/操作のマッチング方法、ポリシー記述パターン、安全な導入手順、運用上の落とし穴をOps視点でまとめます。

EGPの基本とACL/RGPとの役割分担

EGP（Endpoint Governing Policy）は、VaultのAPIエンドポイント（例: secret/data/*, sys/mounts/* など）に対して、追加的なガバナンスを与える仕組みです。記述にはSentinel言語を用い、リクエスト内容や呼び出し主体（Identity連携が有効な場合）などのコンテキストに基づく条件分岐が可能です。

ACLは認可の基盤であり、能力（capabilities: read, create, update, delete, list, sudo）を付与・拒否します。EGPはACLを通過した後の要求に対し、さらなる条件（時間帯、パス命名規約、ラベル、発行者属性など）で制御を強化します。RGP（Role Governing Policy）は認証ロール単位でのガバナンスに適し、EGPはエンドポイント単位でのガバナンスに適します。EGP/RGPはいずれもVault Enterpriseの機能です。

• EGPはEnterprise/HCP Vaultの機能（OSS単体では不可）
• ACLは“何ができるか”、EGPは“どんな条件で許すか”
• RGPはロール中心、EGPはパス（エンドポイント）中心

評価フローと適用ポイント（事前・事後）

EGPは一般に、ACL評価の後に“事前（pre）評価”として実行され、バックエンド処理の後に“事後（post）評価”として実行されます。事後評価はレスポンス内容（利用可能な範囲のメタデータ）に基づく検証に使えます。これにより、たとえば“返却されるシークレットのキー数が上限を超えない”といった検査が可能です（対応可否は対象エンドポイントに依存します）。

Sentinelの強制レベル（advisory / soft-mandatory / hard-mandatory）をEGPでも利用できます。運用ではまずadvisoryで監視し、問題がなければhard-mandatoryに引き上げる段階適用が安全です。

• 評価順序の理解は試験で頻出（ACL → EGP(pre) → バックエンド → EGP(post) → レスポンス）
• 事後評価は全エンドポイントで常に同一ではないため、要件に合わせて適用可否を確認する

VaultにおけるEGPの評価フロー（概念図）

ターゲット指定：パス、操作（capabilities）、ネームスペース

EGPは、対象とするエンドポイントをパス（ワイルドカードを含むパターン）と操作（capabilities）で絞り込みます。よく使う操作はread, create, update, delete, list, sudoです。たとえば secret/data/prod/* に対する create と update のみを対象とする、といった設定が可能です。

Vault Enterpriseのネームスペース機能を併用すると、同じEGPポリシーを上位で定義して子ネームスペースに継承させたり、特定のネームスペースのみに適用する、といった配置が可能です。大規模環境では“グローバルで緩やかに、下位で厳格に”という二段構えが運用しやすいです。

• パスパターン例: secret/data/prod/*, sys/mounts/*, auth/oidc/*
• 操作の粒度を狭めるほど副作用が減る（create/updateに限定など）
• ネームスペース単位の適用範囲は設計初期に決めると後戻りが少ない

SentinelによるEGPポリシー記述パターン

EGPポリシーはSentinelで記述します。以下は“prodパスへの書き込みはprod-writersグループに属するエンティティのみ許可する”という概念例です。Identity統合が有効なことを前提にしています（テスト時はグループ属性が実際に付与されているかを必ず確認してください）。

書き味のポイントは、対象パスと操作を明確にし、該当しないケースは通す、該当するケースのみ厳しく判定するという流れにすることです。これにより不要な副作用を避けられます。

• mainルールは最終判定（trueで許可、falseで拒否）
• 前段のACLが許可していることが前提。EGPは“追加検証”役
• 強制レベルはまずadvisoryで適用範囲とログを確認してから段階的に強化

EGP向けSentinelポリシー（概念例）

import "strings"

# prod配下かどうか
prod_path = strings.has_prefix(request.path, "secret/data/prod/")

# 書き込み操作か（create/update）
is_write = rule { request.operation in ["create", "update"] }

# 呼び出し主体が必要グループに属するか（Identity連携が有効な場合）
allowed_writer = rule { identity.groups contains "prod-writers" }

# メイン判定：prod配下かつ書き込みの場合はグループ所属を要求
main = rule {
  !(prod_path and is_write) or allowed_writer
}

安全な導入とテスト手順（Ops実務）

導入は小さく始めて段階的に強化します。まずは限定的なパス（例: secret/data/prod/app1/*）に対してadvisoryで適用し、監査ログとメトリクスを観察します。誤検知がないことを確認したらsoft-mandatory、最終的にhard-mandatoryへと引き上げます。

変更は常にコード化し、ステージングでリプレイテスト（代表的なAPIシナリオの再生）を行います。特に事後評価を使う場合、対象エンドポイントが返却するレスポンス構造に依存するため、バージョン差異の影響を最小化するための回帰テストが有効です。

• 適用範囲をワイルドカードで広げ過ぎない（まずはピンポイント）
• 強制レベルはadvisoryから開始
• 監査ログとメトリクスのしきい値監視を併用（拒否急増を即検知）
• ロールバック手順（直前のポリシーに戻す）を実地で検証しておく

落とし穴と試験対策ポイント

ハードマンダトリのEGPはrootトークンであっても迂回できません。緊急時対応は“ポリシーの適用範囲から外す or 強制レベルを一時的に下げる”という運用で行います。これはOpsの現場で頻出する誤解ポイントです。

評価順序（ACL→EGP(pre)→バックエンド→EGP(post)）と、EGPが“追加検証”であることの理解は資格試験でも問われやすい観点です。設定時は常に“ACLで基本許可、EGPで条件強化”の役割分担を意識してください。

• 事後評価の前提となるレスポンスメタデータはエンドポイント依存。過度な前提にしない
• Identity属性に依存する場合、認証パスごとの属性付与差を確認
• 監査ログでadvisoryのヒット件数を追い、影響範囲を可視化してから強化

問題で確認

よくある質問