Vault の MFA: Step-up 認証の設計指針

本稿は Vault で「通常操作はそのまま、特定の高リスク操作では追加要素を要求する」Step-up 認証を設計・運用するための実務ガイドです。

公式ドキュメントの安定機能（Identity MFA、Enforcement、トークン管理、監査）に基づき、Ops 観点の落とし穴と試験で狙われやすい論点を整理します。

背景と用語整理：Vault の MFA と Step-up 認証

Vault の MFA は、Identity 機能に統合された多要素認証フレームワークを用いて、ログイン時や特定パスのリクエスト時に追加要素（TOTP、プッシュ認証など）を要求する仕組みです。運用では「通常は 1 要素で十分だが、高感度操作のみ 2 要素へ引き上げる」Step-up 認証がよく求められます。

Step-up 認証の中核は Enforcement（強制）の粒度設計です。Auth method 単位（ログイン時）だけでなく、パス単位（リクエスト時）に設定することで、特定のシークレット読取りや暗号操作だけに MFA を課すことができます。これにより、利便性とリスク低減の両立が可能になります。

• MFA method（TOTP/Duo/Okta など）を定義
• Enforcement（どこで MFA を要求するか）を定義：ログイン単位またはパス単位
• トークンとポリシーで通常操作と Step-up 操作の境界を明確化

方法選定：TOTP / Duo / Okta の比較と運用勘所

Step-up 認証の実装は MFA 手段の選択に強く依存します。TOTP はネットワーク要件が少なくシンプル、Duo/Okta はプッシュ型でユーザ体験が良い反面、外部連携の可用性を考慮する必要があります。

Ops 観点では、時刻同期（TOTP）、外部サービスの到達性（Duo/Okta）、非常時バイパスの手当（Break-glass トークンや DR 手順）を合わせて評価するのが定石です。

• TOTP はオフライン耐性が高く、メンテはシークレット配布・時刻同期が主眼
• プッシュ型（Duo/Okta）はユーザ体験が良いが、外部到達性とフェイルセーフ設計が鍵
• Step-up 適性は「要求タイミングを制御できるか」で判断（パス単位 enforcement との相性）

Identity MFA の基本構成（最小パス）

実装の流れは概ね次の通りです。1) MFA method の作成（例：TOTP で issuer、桁数、期間を定義）、2) Enforcement の定義（どの auth method・どのパスで MFA を要求するか）、3) テストと監査確認（想定外のブロックやバイパスがないか）。

Auth method の accessor を正しく特定すること、時刻同期（NTP）の徹底、メソッド別の運用系障害（外部 API 到達不可など）に対するフェイルクローズ/フェイルオープン方針の明文化が重要です。

• auth list -detailed で accessor を把握して Enforcement に結び付ける
• TOTP はクロックドリフトの監視とサポート手順（再同期）を用意
• プッシュ型は到達性監視と代替手段（予備コード）の準備

運用で使う基本コマンド／定義例

## Auth method の accessor を確認
vault auth list -detailed

## （例）Enforcement の定義イメージ（JSON、実体は API へ送信）
{
  "name": "ops-login",
  "mfa_method_ids": ["<METHOD_ID_TOTP>"],
  "auth_method_accessors": ["<ACCESSOR_USERPASS>"]
}

## （例）パス単位 Enforcement の定義イメージ（高リスクのみ）
{
  "name": "prod-kv-read",
  "mfa_method_ids": ["<METHOD_ID_TOTP>"],
  "paths": ["kv/data/prod/*"]
}

パス単位 Enforcement による Step-up 認証

Step-up の本命はパス単位の Enforcement です。通常操作はそのまま通し、例えば kv/data/prod/* や transit/sign/prod-* といった高リスクのリード/書き込み時だけ MFA を要求します。

クライアントは該当パスへアクセスする際、通常の X-Vault-Token に加え、MFA コードを X-Vault-MFA ヘッダで提示します。TOTP の場合は method_id:code 形式が典型です。

• 高リスク・低頻度のパスを明確化して glob で指定
• ヘッダ付与の失念を監査で検知（失敗イベントの増加を監視）
• CLI/SDK でのヘッダ注入方法を標準化（ラッパースクリプト等）

Step-up 認証（パス単位 Enforcement）の概念フロー

Client                Vault
  |    read kv/data/prod/db-pass (no MFA)   X
  |---------------------------------------->|
  |            403 w/ MFA required          |
  |<----------------------------------------|
  |  resend with X-Vault-MFA: <id>:<code>   |
  |---------------------------------------->|
  |                  200 OK                 |
  |<----------------------------------------|

MFA ヘッダ付きリクエスト例（TOTP）

## X-Vault-Token は通常どおり、MFA は method_id:code で送付
curl -sS \
  -H "X-Vault-Token: $VAULT_TOKEN" \
  -H "X-Vault-MFA: 3dd1b360-....:123456" \
  -H "X-Vault-Namespace: $VAULT_NAMESPACE" \
  "$VAULT_ADDR/v1/kv/data/prod/db-pass" | jq

短命トークン併用の設計：権限昇格を一時化する

もう一つの有効なパターンが「短命トークンによる一時的権限付与」です。Step-up 対象のパスに対して MFA を強制した上で、成功時のみ短 TTL のトークンを払い出す専用 API（例：auth/token/create もしくはラッパー）を用意します。

通常トークンでは prod-* への権限を与えず、短命トークンのみに付与します。これにより権限昇格の時間窓を最小化し、監査上も判別しやすくなります。

• 短命トークンにのみ高リスクパスの権限を付与（policy 分離）
• 払い出し API 自体を MFA 強制し、成功時のみ発行
• TTL は実運用の操作時間に合わせ 1〜10 分程度を目安に調整

短命トークンの作成と利用（例）

## 高権限ポリシー prod-stepup を短命トークンにのみ付与
vault token create -policy=prod-stepup -ttl=5m -orphan -format=json | jq -r '.auth.client_token' > /tmp/stepup.token

## 以後の高リスク操作にのみ短命トークンを使用
STEPUP_TOKEN=$(cat /tmp/stepup.token)
curl -H "X-Vault-Token: $STEPUP_TOKEN" \
  "$VAULT_ADDR/v1/transit/sign/prod-app" -d '{"input":"..."}'

運用・監査・障害時対応：落とし穴チェックリスト

MFA は利便性と安全性のバランス設計が肝です。導入後 1〜2 週間は失敗率・遅延・再送率を監視し、ヘッダ付与の抜けや外部連携の断続的障害を早期に洗い出します。

監査では、MFA が要求されたパスへのアクセスが適切に成功/失敗として記録されているか、短命トークン発行と使用が同一主体であるか、を重点確認します。DR/セカンダリ環境でも Enforcement と method が整合していることを定期的に検証します。

• 時刻同期（NTP）は TOTP 運用の前提。閾値超過時は早期アラート
• 外部連携（Duo/Okta）の到達性監視とフェイルクローズ方針を明示
• 監査ログで高リスクパスの 403→200 遷移を確認（Step-up 成功の痕跡）
• Break-glass トークンは格納・使用・失効を厳格に手順化
• レプリケーションや Namespace 配下でも Enforcement の範囲と整合を点検

監査観点のチェック例（擬似）

# 監査ログから対象パスと 403/200 を抽出（例：jq）
cat /var/log/vault_audit.log | jq 'select(.request.path | test("^kv/data/prod/")) | {path: .request.path, status: .response.status}'

問題で確認

よくある質問