Vault Enterprise: Sentinel Policiesで実現する高度なポリシー制御

Vaultのアクセス制御を「誰が・どこに・いつ・どんな条件で」まで踏み込んで制御するなら、EnterpriseのSentinel Policiesが要です。

本稿はOps視点で、EGP/RGP、評価順序、実用ポリシー例、テスト/ロールアウト戦略を整理。試験対策にも役立つ要点をまとめます。

全体像と用語整理（ACLとSentinelの関係）

Vault EnterpriseのSentinel Policiesは、標準ACLの上に「実行時評価」を重ねる仕組みです。まずACLで基本能力（read/write/listなど）を判定し、通過したリクエストに対してSentinelが追加条件（時間帯、トークンメタデータ、Identityグループ、パラメータ内容など）で最終判断を下します。

適用単位として広く使われるのが、エンドポイント単位にかけるEGP（Endpoint Governing Policy）と、ロール操作に焦点を当てるRGP（Role Governing Policy）です。いずれも enforcement level（advisory / soft-mandatory / hard-mandatory）を持ち、特にhard-mandatoryは失敗時に必ず拒否されます。

• 評価順序: ACL → Sentinel（通過すれば実行、NGなら拒否）
• Enforcement level: advisory（通知のみ）、soft-mandatory（原則強制、特権により上書き可能な構成が一般的）、hard-mandatory（絶対強制）
• EGP: パス/操作種別ベースで広範な要求に適用
• RGP: 役割（例: PKI/AWS/Database等のロール）に紐づく操作やパラメータを精緻に制限

Vault リクエスト評価の流れ

EGP/RGPの作成・更新（例）

## EGPの例: sys/* 直下操作を厳格化
evn VAULT_ADDR=https://vault.example.com
vault login $TOKEN
vault write sys/policies/egp/egp-sys-guard \
  [email protected] \
  enforcement_level=hard-mandatory \
  paths="sys/*"

## RGPの例: PKI発行ロールのTTL制限
evn VAULT_ADDR=https://vault.example.com
vault write sys/policies/rgp/pki-ttl-guard \
  [email protected] \
  enforcement_level=soft-mandatory \
  paths="pki/issue/*"

評価トリガーと利用できるコンテキスト

Sentinelは、対応するエンドポイント/ロールに一致したリクエストがACLを通過した時点で評価されます。評価では、要求パスや操作種別、ボディデータだけでなく、トークンに付与されたメタデータ、紐づくIdentityエンティティ/グループなどが参照可能です。これにより「特定グループのみ特定パラメータ値での発行を許す」「業務時間外は変更系を抑止」など、運用の実態に即したルールを実装できます。

実務では、以下の情報がよく使われます。名前や厳密な属性はバージョンにより増減しますが、リクエスト（path/operation/data）、トークン（policies/meta）、Identity（entity/groups）といった大枠は安定しています。

• request: path, operation（read/create/update/delete/list/sudo など）, data（書き込み系の入力）
• token: policies（付与ポリシー）, meta（任意のKV; 例: team, change_window）
• identity: entity（ID/aliases）, groups（名称/ID）
• time/strings等の標準ライブラリ: 時間帯や文字列前方一致などの条件表現に利用

EGPに適用するパスのスコープ指定（例）

# 変更系（create/update/delete）でのみ評価したい場合は、
# ポリシー本体でoperationを条件化するのが確実。
# パスは広めに、操作はSentinel内で絞る構成が保守しやすい。

vault write sys/policies/egp/kv-change-guard \
  [email protected] \
  enforcement_level=hard-mandatory \
  paths="kv/*"

実用ポリシー例：業務時間外の変更抑止とメタデータゲート

以下は、prod配下のKV（例: kv/data/prod/...）に対する変更系操作を、営業時間内かつトークンメタデータにchange_window=daytimeが付与されている場合にのみ許可する例です。読み取りは常に許可します。

運用では、CAB（変更承認）通過時に一時的にこのメタデータを付与したトークンを払い出すなどのプロセスと組み合わせます。

• 時間帯制御は標準のtimeライブラリで実装可能
• readは常時OK、write/update/deleteのみガード
• メタデータは発行フロー側で付与し、追跡可能にする

Sentinel（EGP）サンプル: prod KVの変更を時間帯＋メタデータで制約

import "strings"
import "time"

# 営業時間帯（9:00-18:00）
allowed_write_window = rule {
  time.hour(time.now()) >= 9 and time.hour(time.now()) < 18
}

# prod配下KVへの変更系操作か
is_prod_kv_write = rule {
  strings.has_prefix(request.path, "kv/data/prod/") and
  (request.operation == "create" or request.operation == "update" or request.operation == "delete")
}

main = rule {
  if is_prod_kv_write {
    allowed_write_window and token.meta["change_window"] == "daytime"
  } else {
    true
  }
}

運用での組み合わせ戦略：ACL・Control Groups・Sentinel

最小権限のACLで土台を作り、Control Groupsで重要操作に多者承認をかけ、Sentinelで条件付きのガードを重ねるのが安全かつ現実的です。特にハイリスク操作（rootトークン発行、PKIの長寿命証明書、transitの鍵操作など）はhard-mandatoryでガードします。

ロールアウトは、まずadvisoryで影響を観測し、soft-mandatoryを経てhard-mandatoryへ段階的に引き上げるのが定石です。Namespaceを使う場合、下位環境で十分に検証してから上位へ昇格させます。

• 段階導入: advisory → soft-mandatory → hard-mandatory
• 高リスク操作はControl Groupsと併用（多者承認＋条件ガード）
• Namespace単位での段階適用で影響範囲を局所化
• 明示的な除外条件（緊急用break-glassユーザーなど）は監査強化とセットで最小化

Enforcement levelの段階引き上げ（例）

# まずはadvisoryで導入
vault write sys/policies/egp/kv-change-guard \
  [email protected] \
  enforcement_level=advisory \
  paths="kv/*"

# 振る舞いに問題がなければsoft→hardへ
vault write sys/policies/egp/kv-change-guard \
  [email protected] \
  enforcement_level=soft-mandatory \
  paths="kv/*"

vault write sys/policies/egp/kv-change-guard \
  [email protected] \
  enforcement_level=hard-mandatory \
  paths="kv/*"

テストとデバッグ：安全に検証する

SentinelはスタンドアロンのCLIでユニットテスト可能です。Vault特有のコンテキスト（request/token/identity）を模したモック入力を用意し、sentinel apply/testで期待どおりに評価されるか確認します。Vault側ではadvisoryで先行適用し、監査ログでヒット状況を追うのが安全です。

評価失敗のトレースは、Sentinelの-traceオプションで分岐やルールの真偽を逐次確認できます。

• ローカルでSentinel CLIテスト → 下位Namespaceでadvisory適用 → 段階昇格
• 監査ログと関連ID（path/operation/entity）を突合し、誤検知を洗い出す
• 境界時刻（9:00/18:00）やサマートタイムの扱いは必ずテスト

モック入力でのローカル検証例

# policy.sentinel（前述の例）をローカルに保存
# mock.json: Vaultの評価コンテキストを簡易に模す
{
  "request": {
    "path": "kv/data/prod/app1",
    "operation": "update",
    "data": {"key":"value"}
  },
  "token": {
    "meta": {"change_window":"daytime"}
  },
  "identity": {
    "entity": {"name":"alice"},
    "groups": ["devops"]
  }
}

# テスト実行（パスは適宜修正）
sentinel apply -trace policy.sentinel -json mock.json

試験対策の要点（Ops向け）

試験では、ACLとSentinelの役割分担、EGP/RGPの適用対象、enforcement levelの違いと運用上の使い分けが頻出ポイントです。特に「ACLを通ってもSentinelで拒否され得る」「hard-mandatoryは原則上書き不能」という基本を押さえます。

また、実運用フロー（advisoryで影響観測→段階昇格）、トークンメタデータやIdentity条件の活用、監査ログでの検証といった現場目線の設問にも備えましょう。

• ACLは能力付与、Sentinelは実行時条件の最終ゲート
• EGPはエンドポイント全般、RGPはロール操作に特化
• advisory/soft/hardの違いと代表ユースケース
• 段階導入と監査ログ活用のベストプラクティス

ポリシーの確認・削除（試験で問われやすい操作）

# 作成済みポリシーの確認
vault read sys/policies/egp/kv-change-guard
vault read sys/policies/rgp/pki-ttl-guard

# 削除
vault delete sys/policies/egp/kv-change-guard
vault delete sys/policies/rgp/pki-ttl-guard

問題で確認

よくある質問