Vault Operations Professional: 上位資格としての範囲を実務目線で押さえる

Vaultを本番で安全かつ止めずに運用する能力を問うのがVault Operations Professional（以下Ops Pro）。Associateの知識を土台に、HA設計、ストレージ選定、シール/アンシール、バックアップと復旧、監視、Enterprise複製を含む実践的な運用手順が出題されます。

本記事は、上位資格としての位置づけと出題範囲を、実務での意思決定（どのバックエンドを選ぶか、どの手順を標準化するか）に結びつけて整理します。バージョン依存が強い機能は避け、公式ドキュメントで安定している概念と手順を中心に解説します。

上位資格としての位置づけと出題範囲

Ops Proは、Vaultを可用かつ回復可能に動かす責任を負う運用者向けの上位資格です。設計判断（ストレージ方式、アンシール戦略、可用化、バックアップ/DR）と、日々の運用SOP（初期化、ローテーション、監査、メンテナンスウィンドウのさばき方）を問われます。

試験は選択式で、設計の意図やコマンドの効果（例: operator系、raft、audit、sys/healthの返却コードなど）まで理解しているかを確認されます。Enterprise機能（DR/Performance Replication、Namespaces等）に関する理解も前提になることがあります。

• 想定ロール: SRE/プラットフォーム運用、セキュリティ運用、インフラ自動化担当
• 主な論点: ストレージとHA、Auto Unseal、初期化と鍵管理、バックアップ/復旧、監査、アップグレード戦略、Enterprise複製
• 出題スタイル: シナリオベースでのベストプラクティス選択、CLI/設定の効果理解、障害時の対応優先度

出題アプローチの例（シナリオの読み解き方）

例: 「クラウドKMSが利用可能で、外部依存を減らしたい」→ Auto Unseal + Integrated Storage(Raft) を第一候補に。
例: 「異リージョンDRを最小RTOで」→ EnterpriseのDR Replication + 定期スナップショット。
例: 「運用チームはrootキー共有を最小化」→ Auto UnsealとRecovery Keys運用、M of N管理を標準化。

試験ドメインと頻出タスク

頻出領域は、初期化/シール管理、HA構成、ストレージ選定、監査と可観測性、バックアップ/復旧、アップグレード運用です。CLIの効果と返却コード、設定ファイルのキープロパティ、SOPの正当性が問われます。

Enterprise機能の出題は、概念と運用上の責務を理解しているか（例: DRとPerformanceの複製の目的差、切替手順、権限境界）に焦点が当たります。

• 初期化と鍵管理: Shamir分割、key-sharesとkey-threshold、rekey/rotate
• Auto Unseal: クラウドKMSやHSMを用いた自動アンシールの設計とリスク
• ストレージ: Integrated Storage(Raft)とConsulの比較、移行時の手順
• HA/負荷分散: active/standby、リーダーフォワーディング、ヘルスチェック
• 監査: audit deviceの有効化、フォーマット、ローテーション戦略
• バックアップ/復旧: raftスナップショット、整合性、停止時間の最小化

頻出CLIの素振り

vault operator init -key-shares=5 -key-threshold=3
vault operator unseal <unseal_key_1>
vault operator rekey -init -key-shares=5 -key-threshold=3
vault operator rotate
vault audit enable file file_path=/var/log/vault_audit.log
vault status
curl -sSf http://127.0.0.1:8200/v1/sys/health

HAアーキテクチャとストレージ選定

本番の第一選択肢は、一般にIntegrated Storage（Raft）です。外部依存が減り、Vault自身が一貫性と選出を担います。既存に強固なConsul基盤がある場合はConsulバックエンドも選択肢になりますが、依存先のSLAを含めた全体SLAで設計します。

Auto Unsealは、クラウドKMSやHSMを用いてシール解除を自動化し、人的オペレーションを減らします。Shamirの復旧鍵は引き続き重要で、災害時の最終手段として安全に保管します。

• Raftは多数決で可用性を確保するため、奇数台での構成が基本（例: 3, 5ノード）。
• 負荷分散では、active判定と429（standby）を考慮したヘルスチェックを設計。
• Auto Unseal利用時も、recovery keysの保管・定期ドリルは必須。

Raft + Auto Unseal を用いた代表的HA構成

最小構成のserver.hcl例（要本番相当のハードニング）

storage "raft" {
  path    = "/opt/vault/data"
  node_id = "vault-1"
}

listener "tcp" {
  address     = "0.0.0.0:8200"
  tls_disable = 0
  tls_cert_file = "/etc/vault.d/tls/cert.pem"
  tls_key_file  = "/etc/vault.d/tls/key.pem"
}

seal "awskms" {
  region     = "ap-northeast-1"
  kms_key_id = "arn:aws:kms:...:key/..."
}

api_addr     = "https://vault-1.example.com:8200"
cluster_addr = "https://vault-1.example.com:8201"
ui = true

初期化・シール運用・バックアップのSOP

初期化ではShamirのkey-shares/key-thresholdを組織の分掌に合わせ設計します。Auto Unsealを使う場合、運用上のアンシールは自動化されますが、recovery keysは依然として災害復旧に必須です。

バックアップはRaftスナップショットを用い、整合性のある時点を確保します。復旧はバージョン互換性とクラスタの状態（単独ノードでの復旧→合流）を踏むのが安全です。

• init直後のrootトークンは即時に封印・保管、日常運用はプロセス化された手段（OIDC等）で実施。
• スナップショットは秘匿チャネルで保管し、復旧手順の定期演習を行う。
• アップグレード前に事前スナップショット取得、ロールバック基準を定義。

代表的な運用コマンド

# 初期化とアンシール（Auto Unseal併用でもrecovery keysは配布/保管）
vault operator init -key-shares=5 -key-threshold=3 > init.out
vault operator unseal <unseal_key_1>

# Raftスナップショットの取得と復旧
vault operator raft snapshot save /backup/vault.snap
vault operator raft snapshot restore /backup/vault.snap

# リーダー交代（メンテ前に計画的に）
vault operator step-down

# 鍵の再分割/ローテーション
vault operator rekey -init -key-shares=5 -key-threshold=3
vault operator rotate

セキュリティ運用とEnterprise機能の要点

監査は有効化されて初めてログが出ます。フォーマット、保管、ローテーション、アクセス制御を含めて設計します。ポリシーは最小権限の原則に沿ってHCLで定義し、変更はレビュー/適用のプロセス化が前提です。

EnterpriseのDR複製は災害対策、Performance複製は読み取り規模拡張が主目的です。切替や昇格の権限と手順、複製トポロジの境界（書き込み責務）を正しく理解します。Namespacesはテナント境界の分離に用います。

• 監査デバイスは少なくとも1つは必ず有効化、書き込み不可時の挙動を理解（Fail Open/Closeの選択）。
• DRとPerformanceの複製は目的が異なるため、同一設計で代替しない。
• ポリシーと認証方式（OIDC、AppRole等）は運用の自動化パイプラインに組み込む。

監査・ポリシー・認証方式の基本オペレーション

# 監査ログの有効化（例）
vault audit enable file file_path=/var/log/vault_audit.log mode=0640

# ポリシー適用（最小権限の例）
cat <<'POL' > team-read.hcl
path "kv/data/team/*" {
  capabilities = ["read", "list"]
}
POL
vault policy write team-read team-read.hcl

# 認証方式（例: OIDC）の有効化と設定の雛形
vault auth enable oidc
vault write auth/oidc/config oidc_discovery_url="https://accounts.example.com" default_role="team"

監視・SLA設計・トラブルシューティング

ヘルスチェックAPIの返却コードを正しく解釈し、LBのルーティングとSLA指標に反映します。メトリクスはストレージやレプリケーションの健全性を示す一次情報です。障害時はリーダー性とストレージ整合性の切り分けから入ります。

運用SOPは、計画メンテ（step-down、ローリング再起動）と緊急時（seal、node隔離、復旧）の両輪で整備します。

• sys/healthの主なコード: 200=active、429=standby、501=未初期化、503=sealed。
• Raft健全性: raft peersのメンバー確認、遅延ノードの解消、スナップショット整合性の確認。
• LBヘルスチェックはactive優先、standbyは429を許容しつつフォワード挙動を理解。

監視と切り分けに使う実用コマンド

# ヘルスチェックとステータス
curl -s -o /dev/null -w "%{http_code}\n" http://vault.service:8200/v1/sys/health
vault status

# Raftピアの確認
vault operator raft list-peers

# ログと監査の確認（出力先は環境に合わせる）
journalctl -u vault --since "-5m"
tail -n +1 /var/log/vault_audit.log

# メンテ前に計画的にリーダー降格
timeout 10s vault operator step-down || true

問題で確認

よくある質問