Vault Token Accessorの実務と試験対策: 監査とトークン無効化を最短で行う

Token Accessorは、トークン本体を晒さずに参照・更新(更新可能な場合)・失効を行うための識別子で、監査とインシデント対応の要です。

本稿では、監査ログとの紐付け、revocation手順、必要なポリシー権限、運用上の落とし穴を実例ベースでまとめます。

Token Accessorの基礎: 何ができて何ができないか

Vaultは各トークンに対してアクセサ(Accessor)という短い識別子を生成します。アクセサは認証には使えませんが、管理API経由で対象トークンの照会、(更新可能なら)延長、失効に用いることができます。これにより、トークン値を直接扱わずに運用が可能になります。

監査の観点では、リクエスト/レスポンスの監査エントリにアクセサが含まれるため、SOCが疑わしいリクエストを特定したら、そのアクセサをキーに即時の失効が可能です。アクセサはトークンのライフサイクルに紐付き、一意で、トークンが失効すると無効になります。

• できること: lookup-accessor、renew-accessor(更新可のみ)、revoke-accessor。
• できないこと: アクセサでの認証、シークレット参照、トークン値の復元。
• 監査ログに現れるため、調査と無効化のハブとして機能する。

監査ログでのアクセサ活用: 収集から無効化までの流れ

Vaultの監査デバイスは、認証後のリクエストに関する情報をJSONで記録します。ここにアクセサが含まれるため、トークン文字列を扱わずに事後追跡が可能です。監査デバイスは機密フィールドをHMAC化しますが、環境設定によりアクセサもHMAC表記になる場合があります(例: hmac-sha256:...)。

運用では、SIEMで疑わしいリクエストを検知→アクセサ抽出→管理トークンでlookup→必要ならrevoke-accessorで無効化、という流れを標準化すると対応が速くなります。

• 監査エントリ(type=request/response)のauth.accessorで特定。
• client_tokenはHMAC化されるが、accessorで同定と失効が可能。
• 複数の監査デバイスを同時に有効化してもアクセサは一貫して同一トークンを指す。

監査から失効までのシグナルフロー

監査ログからアクセサ抽出の例(JSON Lines)

tail -f /var/log/vault_audit.log | jq -r 'select(.type=="request") | .auth.accessor' | grep -v null

トークンの無効化・参照・延長をアクセサで行う

アクセサはインシデント対応の中核です。まずlookup-accessorで対象を確定し、不要または不審であればrevoke-accessorで即時無効化します。更新可能なトークンであればrenew-accessorでTTLを延長できます。

いずれのエンドポイントもHTTPメソッドはPOST(書き込み)で、適切なポリシー権限(update、場合によりsudo)が必要です。見つからないアクセサに対しては404相当のエラーが返ります。

• Lookup: /v1/auth/token/lookup-accessor
• Renew: /v1/auth/token/renew-accessor
• Revoke: /v1/auth/token/revoke-accessor

cURLによるアクセサ運用の最小セット

# 管理トークンを使う
export VAULT_ADDR=https://vault.example.com
export VAULT_TOKEN=s.xxxxx

# 1) Lookup: アクセサからメタデータを確認
curl -s \
  --header "X-Vault-Token: $VAULT_TOKEN" \
  --request POST \
  --data '{"accessor":"h1234567-..."}' \
  $VAULT_ADDR/v1/auth/token/lookup-accessor | jq

# 2) Renew: 更新可能な場合にTTL延長(3600秒)
curl -s \
  --header "X-Vault-Token: $VAULT_TOKEN" \
  --request POST \
  --data '{"accessor":"h1234567-...", "increment": "3600"}' \
  $VAULT_ADDR/v1/auth/token/renew-accessor | jq

# 3) Revoke: 即時無効化(子トークンも失効)
curl -s \
  --header "X-Vault-Token: $VAULT_TOKEN" \
  --request POST \
  --data '{"accessor":"h1234567-..."}' \
  $VAULT_ADDR/v1/auth/token/revoke-accessor

必要な権限とポリシー設計の勘所

アクセサ系エンドポイントはいずれも書き込み(update)権限が必要で、トークン管理に相当するため、一般ユーザーではなく運用(デューティ)トークンや自動化ロールに限定します。特にrevoke-accessorは影響範囲が広いため、意図しない無効化を防ぐために細かいガードレールが必須です。

EnterpriseのNamespacesを使う場合、アクセサはそのNamespaceのコンテキスト内で有効です。誤Namespaceでの操作は失敗するため、運用スクリプトでは必ずNamespaceヘッダ/環境変数を明示します。

• 最小権限: lookup/renewは特定範囲のトークンに限定、revokeは運用チームのみに付与。
• ポリシーはauth/token/* の対象パスにupdate(必要に応じてsudo)を付与。
• 自動化では実行前にlookupで二重確認→条件一致のみrevoke。

ポリシー例(HCL): アクセサ操作専用ロール

path "auth/token/lookup-accessor" {
  capabilities = ["update", "sudo"]
}
path "auth/token/renew-accessor" {
  capabilities = ["update", "sudo"]
}
path "auth/token/revoke-accessor" {
  capabilities = ["update", "sudo"]
}
# 追加の安全策: 対象を運用で許可するprefix等に制限する場合は、
# Sentinel/OPA等のポリシー統制と組み合わせる。

運用パターンと落とし穴: 失敗しないための注意点

アクセサは便利ですが万能ではありません。更新不能なトークンではrenew-accessorは失敗します。また、既に失効済みのアクセサはlookupもrevokeも対象が存在せずエラーとなります。監査ログのタイムラグや並行失効で“見えない”ことは珍しくありません。

親子関係に注意。親トークンのrevokeは子トークンも連鎖的に失効します。影響範囲の確認のため、事前のlookupでpolicies、display_name、creation_path、ttlなどを確認し、必要に応じて段階的な失効戦略(対象のスコープ絞り込み)を取りましょう。

• renew-accessorは更新可能トークンのみ。非更新・期限固定はエラー。
• アクセサが不明(404等)でも、監査時系列の整合性は保つ。SIEM側で再集計。
• revoke-accessorは子トークンも失効。影響範囲の確認を徹底。
• 自動化は冪等に: lookupで存在確認→条件合致→revokeの順。
• 監査デバイスのHMAC設定によりアクセサ表示がハッシュ化される場合がある。

Associate試験向けチェックポイントと比較表

試験では、アクセサの用途(照会・更新・失効)と“認証には使えない”点、監査ログでの役割、revoke-accessorの効果(子トークン含む)が頻出です。エンドポイント名と必要権限(update/場合によりsudo)を正確に記憶しておきましょう。

混同しやすい概念との差分を下表にまとめます。現場では“監査はアクセサ、認証はトークン値”という原則で整理すると誤操作を防げます。

• Accessorは運用・監査のキー、Token値は認証のキー。
• lookup/renew/revokeはいずれもPOSTでupdate権限。
• revoke-accessorは即時かつ子トークンも巻き取る。

問題で確認

よくある質問