Vault 資格の勉強法：公式 Learn とハンズオンで押さえるAssociate / Ops要点

試験対策だけに閉じず、現場でそのまま使える知識に落とし込むのが最短です。本ガイドは公式ドキュメントとLearnの安定項目に寄せて、ハンズオン重視で整理します。

Associateは概念・主要機能の正確な把握、Opsは初期化・アンシール、ストレージ、監査、ポリシー運用といった“動かす責務”が焦点です。

試験の全体像と要点（Associate / Ops 共通）

Vaultは「認証→認可→シークレット配布→リース管理→監査」という一連の流れを正確に理解できているかが評価されます。Associateでは概念と代表的ユースケース、主要シークレットエンジン（KV、DB、Transit、PKI）と認証方式（Token、AppRole、Kubernetes、OIDCなど）が核です。Opsでは初期化・アンシール、ストレージ（Integrated Storage/Raft）、バックアップ、監査、トークン運用（TTL/Lease/Renew/Revoke）が問われます。

Enterprise固有機能（名前空間、パフォーマンスレプリケーション等）は深掘りしすぎず、出題されても概念と目的レベルで説明できる程度に留めるのが安全です。詳細は公式ドキュメントの安定項目に沿って確認します。

• 認証: userpass、AppRole、Kubernetes、OIDC、Tokenの特性と使い分け
• 認可: ポリシー（pathルール、capabilities）、default/denyの評価順序
• シークレットエンジン: KV v1/v2の違い、DB動的クレデンシャル、Transit（暗号化/署名/復号）、PKI（中間CA/ロール/有効期限）
• トークン: サービス/バッチ、orphan、periodic、TTLとmax_ttl、更新と再発行
• リース: 動的シークレットの付与・更新・取り消し、再利用時の注意
• 運用: init/unseal/rekey/rotate、Raftストレージ、スナップショット、監査（file/socket、redaction）

Vaultにおける認証→認可→シークレット配布の流れ

公式 Learn ロードマップ：最短でカバーする順序

公式Learnのチュートリアルは、CLIとAPIの両面で手が動く構成になっています。以下の順に通すとAssociateのブループリントを自然に網羅し、Opsで必要な運用コマンドも身に付きます。

各モジュールでは、CLIの簡略パス（vault kv get secret/foo）と実際のAPIパス（/v1/secret/data/foo）の差を必ず意識しましょう。試験ではこの差異がよく問われます。

• 1) KV v2 基本（書き込み/読み出し/バージョン/メタデータ/削除と破棄）
• 2) 認証（Token基礎→AppRole→Kubernetes→OIDCの順）
• 3) 動的シークレット（データベース）：リースとTTLの挙動まで確認
• 4) Transit（暗号/復号/署名/検証）：平文を保存しない点を強調
• 5) PKI（ルート/中間/ロール/CRL）：失効と有効期限の関係
• 6) 監査（file/socket、redact設定）

ハンズオン環境の作り方（安全に最短で）

最短で動作を掴むには-devモードが有効です。単一ノード、メモリ内ストレージ、自動アンシールで、学習には十分。ただし本番利用不可である点は試験でも強調されます。Dockerでも同様に再現可能です。

Opsを視野に入れる場合、Integrated Storage（Raft）での起動とスナップショット取得を一度体験しておきましょう。バックアップ/復旧の理解は得点源です。

• devモードは便利だが本番不可（単一ノード、永続化なし、簡易セキュリティ）
• CLIは環境変数VAULT_ADDR/VAULT_TOKENを前提に動作
• KV v2はAPIパスがsecret/data/foo等になる（CLI簡略化と混同しない）
• Raftはスナップショットで論理バックアップを取得できる（Ops向け必須）

15分で通す最小ハンズオン（dev + KV v2 + AppRole + Transit）

# 1) devサーバ起動（学習用。実運用不可）
vault server -dev -dev-root-token-id=root &
export VAULT_ADDR='http://127.0.0.1:8200'
export VAULT_TOKEN='root'

# 2) KV v2 を有効化し、データを書き/読む
vault secrets enable -path=secret -version=2 kv
vault kv put secret/app/config db_user=app db_pass=s3cr3t
vault kv get secret/app/config

# 3) ポリシーを作成（読み取りのみ許可）
cat <<'EOF' > read-app.hcl
path "secret/data/app/*" {
  capabilities = ["read"]
}
EOF
vault policy write read-app read-app.hcl

# 4) AppRole を作成し、ロールとポリシーを紐付け
vault auth enable approle
vault write auth/approle/role/app role_name=app policies=read-app secret_id_ttl=1h token_ttl=15m token_max_ttl=1h
ROLE_ID=$(vault read -field=role_id auth/approle/role/app/role-id)
SECRET_ID=$(vault write -field=secret_id auth/approle/role/app/secret-id)

# 5) AppRoleでログインしてシークレットを読む
APP_TOKEN=$(vault write -field=token auth/approle/login role_id="$ROLE_ID" secret_id="$SECRET_ID")
VAULT_TOKEN=$APP_TOKEN vault kv get secret/app/config

# 6) Transitを有効化して暗号/復号（平文は保存されない）
vault secrets enable transit
vault write -f transit/keys/appkey
CIPHERTEXT=$(vault write -field=ciphertext transit/encrypt/appkey plaintext=$(echo -n 'hello' | base64))
vault write -field=plaintext transit/decrypt/appkey ciphertext=$CIPHERTEXT | base64 -d

# 7) 監査を有効化（学習用にfile出力。実行権限/パスに注意）
sudo touch /var/log/vault_audit.log && sudo chmod 666 /var/log/vault_audit.log
vault audit enable file file_path=/var/log/vault_audit.log

運用（Ops）で外せない論点

初期化（init）でマスターキーが分割（Shamir）され、アンシールで閾値分のキー入力が必要になります。自動アンシール（クラウドKMS連携）はOps領域で頻出。rekeyは分割鍵の再生成、rotateは内部暗号鍵のローテーションで別物です。

Integrated Storage（Raft）はシンプルで本番利用に適し、スナップショットでバックアップを取得できます。監査はfile/socketなどデバイスを有効化し、機微情報はredactできます。トークンはサービス/バッチの違い、periodic、orphan、TTLとmax_ttlの関係を整理しておきましょう。

• vault operator init / unseal / rekey / rotate の違いと言い回し
• Auto-unsealの利点（ブート時の自動復旧、鍵管理の分離）
• Raftスナップショット: vault operator raft snapshot save/restore
• 監査ログ: enable/disable、file_path、redact設定の意味
• トークン: batchはストレージに保存されず非更新、serviceは更新・再発行可

出題パターンと落とし穴（頻出ミスを回避）

CLIの簡略パスとAPIパスの混同、KV v1/v2の取り違え、トークン種別とTTLの挙動は典型的なひっかけです。ポリシーの評価順（deny優先）やパスのワイルドカードも要注意。Transitは“暗号サービス”であり、平文を保存しない点を強調しましょう。

レスポンスラッピング（wrapping）はシークレットそのものではなく一時トークンを配布する仕組みです。unwrapで取り出すと一度きりで失効します。安全な受け渡しフローを説明できると強いです。

• KV v2: CLIは vault kv get secret/foo だがAPIは /v1/secret/data/foo
• ポリシー: 明示denyが優先、capabilitiesは最小権限で設計
• Token: batchは非永続・非更新、serviceは更新/再発行・リーシング対象
• TTL: 明示ttl <= max_ttl。periodicは固定更新サイクルで永続可
• DB動的シークレット: revokeは該当クレデンシャルのみ無効化、影響範囲を把握
• Transit: 平文を保存しない。キーのローテーションはバージョンで管理

直前チェックリストと学習計画（7日想定）

学習の最後は手を動かして確認→要点の暗記→模擬の順で締めます。7日間でAssociate/Opsを両立させる最短プランを置きます。実務での“あるある”と紐付けると忘れません。

時間がない場合でも、KV v2・AppRole・DB動的クレデンシャル・Transit・init/unseal/audit/raft snapshotの体験は死守しましょう。

• Day1: 概念整理（Auth/Policy/Secrets/Lease）とdev起動
• Day2: KV v2とポリシー、ラッピングの流れ
• Day3: AppRole/Kubernetes認証（どちらかは実機で）
• Day4: DB動的クレデンシャル（発行→更新→取り消し）
• Day5: Transit/PKIの基本操作
• Day6: Ops: init/unseal/rekey/rotate、監査、Raftスナップショット

問題で確認

よくある質問