Vault 関連資格の全体像 ─ Associate と Operations Professional の実務目線

Vault は認証（Auth Method）、ポリシー、シークレットエンジン、ストレージ、監査の各レイヤが明確に分かれており、資格もそれに沿って出題されます。まずは概念の地図を頭に入れた上で、手を動かして確認していくのが近道です。

この記事では、Vault Associate を基礎力の到達点として定義し、Operations Professional を本番運用・自動化を担うエンジニアの検定として位置付け、両者の差分と学習戦略を具体的に示します。内容は公式ドキュメントに基づく安定挙動を前提にしています。

資格マップと前提知識

Vault Associate は「なぜ Vault が安全か」を構成要素レベルで説明し、基本的な操作でシークレットを安全に扱えることを確認する試験です。Operations Professional は、インストールから設定、TLS・監査・バックアップ、Raft 統合ストレージの管理、ヘルスチェックや自動化まで、継続運用に必要な判断と手順が問われます。

公式の試験ガイドに沿って、設問は製品の標準動作に基づきます。特定バージョンに依存しやすい細部には立ち入らず、原理と標準的な CLI/API の使い方を押さえるのが安全です。

• 想定前提: Linux 基礎、ネットワークとTLSの基礎、シェル操作、HCL 読解力
• Associate で必要: Auth Method・ポリシー・KV v2・Transit の基本操作、トークンと権限モデルの理解
• Ops Pro で必要: サーバ設定、TLS/証明書、Raft 統合ストレージ、監査、バックアップ、ヘルスチェックと自動化
• あると良い: Systemd やコンテナ運用経験、クラウドKMSでのオートアンシール概念

Vault 資格マップ（進み方の目安）

初期セットアップ時の確認コマンド

export VAULT_ADDR=https://vault.example.com:8200
vault version
vault status
# 未ログイン時は 1xx/2xx のステータスに注意。必要なら login 実行
vault login # 対話 or VAULT_TOKEN で実行

Associate で押さえるコア概念

Associate は、Vault のセキュリティモデル（Auth Method → トークン → ポリシー → シークレットエンジン）を言語化でき、基本操作を誤りなく行えるかを確認します。特に KV v2 のデータ/メタデータのパス、Transit の暗号化と鍵ライフサイクル、ポリシーの最小権限が定番です。

Auth Method は人/アプリを Vault に認証させる入口、ポリシーはトークンの行動範囲、シークレットエンジンは実際の機能（保存・動的発行・暗号化）を担います。

• Auth Method: token, approle, kubernetes などを場面で使い分ける
• ポリシー: 路径ベースの能力付与（read, create, update, delete, list, patch, sudo）
• KV v2: データは secret/data/、一覧は secret/metadata/ を使う
• Transit: データを保存せず暗号化/復号・署名・検証を提供

トークン発行と評価フロー（簡略）

KV v2 の有効化と最小権限ポリシー

# KV v2 を有効化（デフォルトの secret/ を v2 に）
vault secrets enable -path=secret -version=2 kv

# データ投入（v2 は kv put でOK。APIは /v1/secret/data/...）
vault kv put secret/app/config username=appuser password=s3cr3t

# 一覧に必要な list と、読み取りに必要な read を明示
cat > read-secrets.hcl <<'EOF'
path "secret/metadata/app" {
  capabilities = ["list"]
}
path "secret/data/app/*" {
  capabilities = ["read"]
}
EOF

vault policy write read-secrets read-secrets.hcl
vault token create -policy=read-secrets

Ops Pro で問われる運用領域

Ops Pro は、サーバ構成・TLS・監査・バックアップ復旧・Raft 統合ストレージやヘルスチェックなど、日々の運用と障害対応を安全に回す判断力が中心です。インストールは各OS/コンテナで流儀が違いますが、server.hcl の構造、リスナー、ストレージ、クラスタアドレスや UI 設定などは共通です。

バックアップはスナップショット（Raft）で取得し、監査は少なくとも1つの監査デバイスを有効化。TLS は相互認証や中間CAの連鎖を理解し、API のヘルスエンドポイントで監視連携します。

• Raft 統合ストレージ: リーダ選出、スナップショット、ピア管理
• TLS: listener での cert/key、CA 連鎖、クライアント検証の有無
• Audit: file/syslog/socket などの監査デバイス有効化
• ヘルスチェック: /sys/health のコードとオプション理解
• オートアンシール: クラウドKMS連携の概念と鍵分割との違い

Raft クラスタ（概念図）

代表的な server.hcl（簡略例）

storage "raft" {
  path    = "/opt/vault/data"
}
listener "tcp" {
  address       = "0.0.0.0:8200"
  tls_disable   = 0
  tls_cert_file = "/etc/vault/tls/server.crt"
  tls_key_file  = "/etc/vault/tls/server.key"
}
api_addr     = "https://vault.example.com:8200"
cluster_addr = "https://10.0.0.10:8201"
ui = true
# 必要なら seal ブロックで auto-unseal（KMS等）を設定

出題ドメインと深さの差分を掴む

Associate は「概念の正確さ」と「安全な基本操作」を幅広く、Ops Pro は「運用判断」と「安全な手順化」を深く問います。どちらも CLI と API の相互理解が鍵です。

Enterprise 機能（例: DR/Performance Replication）は、Ops Pro では概念として触れられる可能性がありますが、実環境の詳細なライセンス依存手順までは前提になりにくいです。

• Associate: Auth/Policy と KV/Transit の基本、トークンとTTL、HAの概念理解
• Ops Pro: server.hcl、TLSと監査、Raft運用、スナップショット、ヘルス/自動化、オートアンシール

ドメイン別の深さ（目安）

運用コマンドの詰め合わせ（確認用）

# 初期化・シール/アンシール
vault operator init
vault operator unseal

# Raft ピアとスナップショット
vault operator raft list-peers
vault operator raft snapshot save /tmp/vault.snap

# 監査
vault audit enable file file_path=/var/log/vault_audit.log
vault audit list

# ヘルスチェック（例）
curl -s -o /dev/null -w "%{http_code}\n" \
  "$VAULT_ADDR/v1/sys/health?standbyok=true&perfstandbyok=true"

学習ロードマップと演習セット

短期集中（2〜4週間）なら、概念→最小ラボ→運用演習→模擬設問の順で反復します。Associate は単一ノードの dev モードで十分に練習できます。Ops Pro は TLS を伴う3ノード Raft と監査・バックアップ・ヘルスの自動化まで一通り触るのが近道です。

各演習は「結果の確認コマンド」を必ずセットにします。出力と戻り値を見て因果関係を言語化できると本番でも強いです。

• Day 1–3: 概念図と主要コマンドを暗記でなく因果で理解
• Day 4–7: KV v2/Transit/Policy を dev サーバで往復練習
• Day 8–12: 3ノード Raft・TLS・監査・スナップショット・ヘルスを構築
• Day 13–14: 失敗注入（証明書期限切れ/誤ポリシー/ノード停止）と復旧演習

最小ラボのトポロジ（例）

最小ラボ起動スクリプト（Associate と Ops の入口）

# Associate: 単一ノード dev（永続化なし。本番不可）
export VAULT_DEV_ROOT_TOKEN_ID=root
vault server -dev -dev-root-token-id=$VAULT_DEV_ROOT_TOKEN_ID &
export VAULT_ADDR=http://127.0.0.1:8200
vault login $VAULT_DEV_ROOT_TOKEN_ID

# Ops: systemd などで本番相当に起動する前の雰囲気確認
# 注意: 実運用は TLS 必須。以下は雰囲気のみ。
cat >/etc/vault.d/server.hcl <<'EOF'
storage "raft" { path = "/opt/vault/data" }
listener "tcp" { address = "0.0.0.0:8200" tls_disable = 1 }
ui = true
EOF
vault server -config=/etc/vault.d/server.hcl &

よくある落とし穴と試験対策チェック

多くのミスはパスの取り違え、権限の不足、TLS/監査の未設定に集約されます。設問でもこうした“うっかり”を見抜けるかが問われがちです。以下のチェックを最後に通すと精度が上がります。

API を 1 回でも叩いておくと、CLI が内部で何をしているかが繋がり、出題の言い換えにも対応しやすくなります。

• KV v2 は read=secret/data、list=secret/metadata の使い分けを暗唱ではなく説明できるか
• トークンの TTL、最大TTL、オーファンの意味を言語化できるか
• Transit は平文を保存しない。保存したいなら KV で管理する設計にできるか
• AppRole は role_id と secret_id の両方が必要（デフォルト）。自動ローテーションの流れを描けるか

リクエスト評価の通過ポイント

※ Auth Method から Secret Engine までの処理は Audit Log に記録される

API 呼び出し（KV v2 読み取りの実体）

curl -s \
  -H "X-Vault-Token: $VAULT_TOKEN" \
  "$VAULT_ADDR/v1/secret/data/app/config" | jq '.data.data'
# ポリシーが read を許可していない場合は permission denied

問題で確認

よくある質問