Vault 試験の問題例: 主要ドメインの問題形式（Associate / Ops）

本稿は、HashiCorp Vault の認定試験（Associate / Operations）で頻出のドメインを、実務に直結する観点でまとめた問題例集です。

バージョン依存の細部は避け、公式ドキュメントに準拠した安定した振る舞いに基づきます。Enterprise 固有機能（名前空間・複製など）は明記します。

試験ドメイン全体像と関係整理

Associate はコア概念（初期化/Unseal、トークン/ポリシー、認証方式、主要な Secrets Engine、TTL/リース/ラップ、監査）を広く浅く。Ops はこれに加え、HA/ストレージ、バックアップ/復旧、運用オペレーション、（Enterprise 前提の）複製の基礎が問われます。

多くの設問は「どのコンポーネントがどの責務を持つか」を正しく結びつけられるかで決まります。クライアントの認証、ポリシー適用、Secrets Engine の発行・失効、監査の記録、これらの流れを頭に描けるようにします。

• 認証方式は「誰か」を証明、ポリシーは「何ができるか」を制御、Secrets Engine は「何を渡すか（静的/動的）」を決める。
• TTL/リースは寿命管理、ラップは安全な引き渡し、監査は操作の証跡。
• Ops 観点では、HA/ストレージ設計、初期化とUnseal、バックアップ/復旧の手順整合性が問われる。

クライアント要求からシークレット発行までの流れ（概略）

Client --> [Auth Method] --(login)--> [Token]
   |                                   |
   |---- request w/ token ------------> |  (policy check)
                                       v
                                   [Secrets Engine]
                                       |
                                       v
                                   [Lease/TTL]
                                       |
                                       v
                                    [Audit]

概念把握向けの最小コマンド例（KV v2 読み取り）

vault login <TOKEN>
# ポリシーで許可されたパスのみ成功
vault kv get -mount=secret app/config

トークンとポリシーの設計ポイント（Associate/Ops 共通）

Vault の権限制御はポリシーが中心です。path ブロックに対する capabilities（read, create, update, delete, list, deny, sudo など）を最小権限で付与します。deny は常に最優先で、明示 deny があれば許可は打ち消されます。default ポリシーは最小限の自己情報取得のみで、root トークンの常用は不可です。

トークンは大別して service トークンと batch トークン。service は永続化・更新可能で子トークン発行可。batch は非永続・非更新・子トークン不可で高スループット用途に向きます。orphan トークンは親に連鎖失効しません。periodic トークンは指定期間で更新必須（max_ttl に縛られない設計）です。

• 試験では「どのトークンで何ができるか」よりも「なぜそれを選ぶか」が問われることが多い。
• TTL は要求 TTL ≤ 役割の max_ttl ≤ システムの上限。renewable=false の場合、更新は不可。
• ポリシーは累積評価だが deny は最優先。ワイルドカードの広すぎる許可は誤答の誘い。

ポリシーとトークン作成の例

# ポリシー（HCL）
path "secret/data/app/*" {
  capabilities = ["read", "list"]
}

# ポリシー適用
vault policy write app-read app-read.hcl

# service トークン（1h、更新可）
vault token create -policy=app-read -ttl=1h

# batch トークン（非永続・非更新）
vault token create -type=batch -policy=app-read -ttl=15m

# orphan トークン
yes | vault token create -policy=app-read -orphan

認証方式と Secrets Engine の選択

ワークロードの配置とアイデンティティ供給元で認証方式を選びます。例: Pod なら Kubernetes Auth、サーバアプリなら AppRole、SaaS/人なら OIDC/JWT、クラウドランタイムは各クラウド Auth を優先。人手運用の一時利用は GitHub/LDAP/ユーザパスなどを最小権限で。

Secrets Engine は用途中心に選定します。KV v2 はバージョン管理つきの静的シークレット、Database は動的資格情報の発行と失効、Transit はデータを保存せず暗号化/署名、PKI は短命証明書の発行。試験では「データは保存せず暗号だけしたい→Transit」のような適材適所がよく問われます。

• Kubernetes: ServiceAccount と JWT を検証し、Role/RoleBinding でポリシー付与。
• AppRole: ロール ID + シークレット ID。Pull 型デプロイに相性良し。
• KV v2: data/ と metadata/ の二層 API、削除と破壊の違いが問われやすい。

代表的な有効化例

# 認証方式の有効化（例: AppRole）
vault auth enable approle
vault write auth/approle/role/app ttl=1h policies=app-read
vault read -field=role_id auth/approle/role/app/role-id
vault write -f -field=secret_id auth/approle/role/app/secret-id

# Secrets Engine の有効化（例: KV v2）
vault secrets enable -path=secret -version=2 kv
vault kv put secret/app/config username=svc password=s3cr3t

TTL、リース、失効、レスポンスラップ

動的シークレット（例: Database Engine）が返す資格情報にはリースが付きます。リースは期限切れで自動失効、もしくはクライアントが更新（renew）して延命できます。prefix で失効（revoke -prefix）すれば同一マウント配下の全動的資格情報を回収します。静的シークレット（KV）は通常リース対象ではありません。

レスポンスラップは X-Vault-Wrap-TTL を指定して応答を一回限りのラップトークンで包み、安全に引き渡します。unwrap は受領者のみが実行でき、内容は Cubbyhole に一時保管されます。試験では「資格情報の中継経路を安全にしたい」要求に対する正解として頻出です。

• periodic トークンは max_ttl を超えても更新を続けられるが、更新を怠ると失効。
• token と lease は別物。token は認可、lease は発行物（例: DB ユーザ）の寿命。
• revoke は即時回収、revoke-prefix は範囲回収、revoke-force は最終手段。

更新と失効の典型操作

# トークン更新（可能な場合）
vault token renew -increment=30m

# リース ID を指定して更新/失効
vault lease renew database/creds/app/abc123
vault lease revoke database/creds/app/abc123

# プレフィックス配下を一括失効
yes | vault lease revoke -prefix database/creds/app

# レスポンスラップで安全に受け渡し
VAULT_ADDR=https://vault:8200 \
curl -H "X-Vault-Token: $TOKEN" -H "X-Vault-Wrap-TTL: 5m" \
  $VAULT_ADDR/v1/secret/data/app/config
# 受領側: vault unwrap

運用: 初期化、Unseal、HA とストレージ

初期化では Shamir 方式で分割されたキー（閾値で復元）と初期 root トークンが生成されます。手動 Unseal の代わりにクラウド KMS/HSM による Auto Unseal を構成すると、起動時に自動解錠できます。この場合、復旧時に用いるリカバリ用のキーが別途用意される構成があります。

HA では Active/Standby の構成を取り、書き込みは Active のみ。統合ストレージ（Raft）は Vault 自身がストレージの合意形成を行い、複数ノードで可用性を確保します。スナップショットで一貫性のあるバックアップを取得し、計画停止や障害時の復旧に用います。

• 統合ストレージはクラスタ内で投票多数決（クォーラム）を要する。停止順序と再起動順序に注意。
• アップグレードは事前スナップショット、互換性の確認、段階的ロールアウトが基本線。
• スタンバイは要求を転送するが、書き込みは行わない。Active の切替時は短時間のリース更新失敗に備える。

初期化/Unseal と Raft の代表手順

# 初期化（例: 5分割・3閾値）
vault operator init -key-shares=5 -key-threshold=3
# Unseal（閾値分のキーを入力）
vault operator unseal

# Raft クラスタ参加
vault operator raft join http://vault-1:8200

# Auto Unseal の例（設定ファイル抜粋）
seal "awskms" {
  region     = "ap-northeast-1"
  kms_key_id = "arn:aws:kms:..."
}

運用: 監査、バックアップ、Enterprise の複製機能

監査デバイスは全 API リクエスト/レスポンスのメタデータを記録します。機微なフィールドは HMAC 化され、漏えいリスクを下げます。実運用では出力先のローテーションや保全、時刻同期が重要です。

バックアップは統合ストレージのスナップショットを取得します。整合性のある状態を保存し、同一メジャー互換範囲での復元を行います。Enterprise では DR/Performance 複製が利用可能で、DR は待機系へのフェイルオーバー、Performance は読み取りスケールアウトに用います（試験では用語と用途の区別が問われます）。

• 監査は最初に有効化する運用コントロールのひとつ。HMAC 無効化は検証環境に限定。
• スナップショットは復元先のクラスター状態と整合させる。復元後はアクセスポリシーを検証。
• DR は可用性、Performance はスループット。片方で両方の要件を満たすと考えるのは誤り。

監査/スナップショット/複製（Enterprise 機能を含む）

# 監査デバイスの有効化（ファイル出力）
vault audit enable file file_path=/var/log/vault_audit.log

# 統合ストレージのスナップショット
vault operator raft snapshot save backup.snap
# 復元（メンテ状態で実施）
vault operator raft snapshot restore backup.snap

# Enterprise（用語の把握が主題）
# DR/Performance 複製の有効化はライセンス前提。CLI は概念理解に留める。

問題で確認

よくある質問