Vault Control Groupsで実現する承認フロー付きアクセス（Ops向け実務と資格対策）

Control Groups（Control Group Authorization）は、Vault Enterpriseの機能で、指定パスへのアクセスに対し、事前に定義した承認者グループからの承認をしきい値（N名など）で満たした場合にのみレスポンス（シークレット）を開示します。承認者はシークレットそのものを閲覧できず、承認行為のみを行う点が重要です。

本稿では、公式ドキュメントに基づく安定した概念を中心に、フロー、ACLポリシーでの定義、CLI/APIによる運用、設計パターン、トラブルシュート、Ops系資格対策の要点をまとめます。細かなAPIフィールド名やUIの表記はバージョンで差異があり得るため、実装前に現行の公式ドキュメントで確認してください。

Control Groupsの概要と前提

Control Groupsは、Vaultがアクセスを即時に許可せず、所定の承認手続きを満たすまでブロックする"承認ゲート"です。承認はVaultのIdentityグループと連携し、パス単位のACLポリシーで構成します。複数の"ファクター"を定義し、各ファクターに対して必要承認数を設定できます（例: セキュリティ1名 + チームリード2名）。

承認リクエストは単回性のラッパートークン（包み）として表現され、承認者はこのトークンに対して承認操作を実行します。必要承認数に達すると、依頼者は元のレスポンスをアンラップ（unwrap）して初めてシークレットを取得できます。承認やアンラップのイベントは監査ログに記録されます。

• Enterprise限定機能（OSSには未実装）
• 承認者はシークレット本文を見ない（承認のみ）
• IdentityグループとACLポリシーで制御（パス単位）
• ファクターごとに承認数を設定可能。全ファクターの条件を満たす必要あり
• 承認要求は有効期限付き（期限切れで無効化）

リクエストのライフサイクル（依頼→承認→アンラップ）

依頼者がControl Groupsの対象パスを読み出すと、Vaultは即時にシークレットを返さず、承認が必要である旨と承認対象となるラッパートークン（単回性でTTL付き）を返します。依頼者はこのトークンを承認者に安全な経路で共有します。

承認者は自分のVaultトークン（所属グループに基づく権限）を用いて、ラッパートークンに対する承認操作を実行します。所定のファクターしきい値をすべて満たすと、依頼者はラッパートークンをアンラップでき、元のレスポンス（シークレット）を受け取れます。期限切れ・取り消しの場合はアンラップに失敗し、やり直しになります。

• ラッパートークンは単回利用。期限切れ前に承認がそろわないと無効化
• 承認は"誰が・どのトークンに対して"行ったかが監査に残る
• 承認数はユーザ単位でカウント（同一ユーザの多重承認は無効）
• 再試行は新しいリクエストとして扱われる（トークンは都度発行）

Control Groupsの承認フロー（概念図）

依頼者(Client)                 承認者(Approver)                Vault
      |                               |                         |
1)    |--- 読み取りリクエスト ------->|                         |
      |                               |----> 評価 -------------->|
      |<-- 承認必要 + ラップトークン --|                         |
      |         [token=T, TTL=t]      |                         |
2)    |--(安全な経路でTを共有)------->|                         |
3)    |                               |--- 承認(id=T) ---------->|
      |                               |<-- 承認受理(1/N) --------|
      |                               |--- 承認(id=T) ---------->|
      |                               |<-- 承認受理(N/N) --------|
4)    |--- アンラップ(T) --------------------------------------->|
      |<-- シークレット本文 -------------------------------------|
      |                               |                         |
(期限切れ/取消時はアンラップ失敗。リクエストを再発行する)

ACLポリシーでの定義（control_groupブロック）

Control GroupsはACLポリシー内でパスごとに"control_group"ブロックとして定義します。複数の"factor"を宣言でき、それぞれに"identity"条件（グループ名やID）と必要承認数"approvals"を設定します。全ファクターの条件が満たされたときにのみレスポンスが開示されます。

承認者側のポリシーは、対象パスへの読み取り権限は不要で、承認APIを叩ける権限と、Identityグループ所属が正しく解決できることが重要です。グループマッピング（OIDC/LDAP）やエンティティ結合の不備は、典型的な承認不能の原因になります。

• 全ファクター必須（OR条件にしたい場合は設計を分ける）
• 承認者はシークレット本文を見ない（承認APIのみ）
• 承認カウントは同一エンティティの重複を数えない
• パスは正確に一致させる（バージョン化KVは/data/などに注意）

ACLポリシー例（2ファクター: チームリード2名 + セキュリティ1名）

# policy.hcl
path "secret/data/payroll" {
  capabilities = ["read"]
  control_group = {
    factor "team-leads" {
      identity {
        group_names = ["team-leads"]
        approvals   = 2
      }
    }
    factor "secops" {
      identity {
        group_names = ["secops"]
        approvals   = 1
      }
    }
  }
}

# ポリシーの登録（Enterprise）
vault write sys/policies/acl payroll-cg [email protected]

# 依頼者・承認者それぞれに必要なポリシー/グループを割り当てる
# （Identityグループの事前作成と外部IdPマッピングを確認）

運用手順（依頼・承認・アンラップの実務）

依頼者: 対象パスを通常どおり読み出します。Control Groupsに該当すると、Vaultは即時本文を返さず、承認が必要な旨と"承認対象トークン"（ラップトークン）を示します。依頼者はこのトークンを承認者に安全な経路（社内承認ツール、セキュアチャット等）で共有します。

承認者: 自身のVaultトークンで承認APIを実行します。必要承認数に達すると、依頼者は同じラップトークンをアンラップでき、初めて本文が得られます。承認やアンラップは監査ログで追跡できます。APIのリクエストボディやレスポンスの詳細はバージョン差異があるため、現行の公式ドキュメントに従ってください。

• 承認の可否は各承認時点で評価（しきい値に達した時点でアンラップ可能）
• ラップトークンは単回利用・有効期限あり。期限切れなら再リクエスト
• 承認者ポリシーに"authorize"系エンドポイント利用権が必要
• UI/CLI/APIいずれでも運用可能（組織の承認業務フローに合わせる）

CLI/APIの最小例（概念）

# 1) 依頼者: 読み出し（CGに該当すると承認が必要な旨が返る）
vault read secret/data/payroll
# 出力の案内に従い、承認対象となるラップトークン（例: s.wrap_xxx）を控える

# 2) 承認者: ラップトークンに対して承認（自身のVaultトークンで実行）
# エンドポイント例（実環境のバージョンによりボディキー名は要確認）
vault write sys/control-group/authorize id=<ラップトークン>

# 3) 依頼者: 必要承認数の充足後、ラップトークンをアンラップ
vault unwrap <ラップトークン>
# → 元のレスポンス（シークレット本文）が表示される

設計パターンと運用上の注意点

承認ファクター設計: ビジネスリスクに応じた最小承認数を定義します。セグメントを越える承認（例: 開発部門＋セキュリティ）を分けてファクター化し、相互牽制を担保します。高頻度アクセスには過剰承認を避け、対象パスを細分化して高リスク領域のみControl Groupsを適用します。

TTLと失効戦略: 承認TTLは短すぎると実務に乗りにくく、長すぎるとリスクが高まります。業務の承認SLAに基づき適切に設定し、期限切れ時の再申請手順を明文化します。ブレークグラス手順（緊急時の一時的バイパス）も別途定義し、監査と事後レビューを必須にします。

監査・可観測性: 監査デバイスを有効化し、承認API・アンラップのイベントをSIEMに連携します。誰が・どのトークンに・いつ承認したか、失効や失敗の理由が追跡可能であることを確認します。

• 高リスク領域だけに適用し、承認ボリュームを制御
• ブレークグラスは限定トークン＋短TTL＋強監査で運用
• グループ名ベースの指定は命名変更に弱い。安定ID採用も検討
• 失効・再申請の運用手順をRunbook化し、当番者に周知

Ops資格対策：押さえるべき要点と落とし穴

頻出ポイント: Control GroupsはEnterprise機能、承認者は本文を見ない、ACLのcontrol_groupで定義、全ファクター必須、承認は単回ラップトークンに対して行われる、アンラップ後に初めて本文が開示、イベントは監査に残る。

混同しやすい概念: Response Wrappingは"運搬の安全化"であり"承認"ではない。Sentinel等のガバナンスポリシーはガードレールであってワークフロー承認そのものではない。MFA/二段階認証とも別概念。

落とし穴: パス表記の誤り（例: KV v2での/data/や/metadata/）、Identityグループ未解決、承認TTLが短すぎて失効、承認者にauthorize権限が付いていない、レプリカ経由で承認が届かない。

• Enterprise限定であることを明示できるか
• "承認者は本文を見ない"を説明できるか
• ACLのcontrol_groupブロックの役割を理解しているか
• Response Wrappingとの違いを言語化できるか

問題で確認

よくある質問