Vault サンプル問題

正解：B

A　RoleIDとSecretIDを使う機械向けの認証で、人間の既存ディレクトリ資産を活用できない

B（正解）　正解。既存のLDAP/ADディレクトリに問い合わせて認証し、ディレクトリ側のグループをVaultポリシーにマッピングできる

C　Vault内に独自のユーザー名とパスワードを作る方式なので、ADとの二重管理が発生してしまう

D　クライアント証明書の発行と配布という別の運用が増え、既存アカウントの再利用にはならない

正解：C

A　人間向けにVault内へユーザーを作る方式で、機械への安全な資格情報配布の仕組みを持たない

B　実在する認証メソッドだが、個人のGitHubトークンを使う人間向けの方式であり、RoleIDとSecretIDの組み合わせではない

C（正解）　正解。RoleID(公開してよい役割の識別子)とSecretID(機密値)を分離して配布でき、アプリやCIジョブの認証を想定した設計になっている

D架空　このような名前の認証メソッドはVaultに存在しない

正解：A

A（正解）　正解。インスタンスメタデータの署名やIAMの署名済みリクエストをVaultが検証するため、事前に秘密値を配置する必要がない

B　機械向けではあるが、SecretIDという秘密値をどうやってインスタンスに届けるかという問題が残る

C　クライアント証明書と秘密鍵をインスタンスに配置する必要があり、「秘密値を配置しない」という要件に反する

D　既に発行済みのトークンを使うだけの仕組みで、そのトークン自体を安全に配布する問題は解決しない

正解：B

A　アンシールキーは初期化時に一度だけ配布される運用者向けの鍵素材で、ログインとは無関係

B（正解）　正解。認証はトークンの発行に集約され、以後のすべての操作はそのトークンと付随するポリシーで認可される

C　ポリシーはサーバ側に保存され、クライアントへファイルとして返されることはない

D　ルートキーはVault内部で管理される鍵で、クライアントに渡されることはない

正解：B

A　2つを分離する設計の意味が失われ、設定ファイルが漏れただけで認証できてしまう

B（正解）　正解。受け取り側が一度だけunwrapでき、途中で開封されていれば検知できるため、配送経路の信頼性を下げられる

C　プロセス一覧や管理APIから読める可能性があり、開封の検知もできない

D　ポリシーは認可ルールの定義であり、秘密値を格納する場所ではない

正解：D

A　Kubernetesでも使えるが、SecretIDの配布が別途必要でServiceAccountトークンを直接検証はしない

B　クライアント証明書を検証する方式で、ServiceAccountトークンの検証は行わない

C　Vault内のユーザー名とパスワードによる人間向けの認証で、Podのアイデンティティとは無関係

D（正解）　正解。PodのServiceAccountトークンをKubernetes APIで検証し、名前空間とServiceAccountに対応するロールのポリシーを付与する

正解：A

A（正解）　正解。認証メソッドの有効化はauth enableで行い、-pathで任意のマウントパスを指定できる

B　secrets enableはシークレットエンジン用のコマンドで、認証メソッドの有効化には使えない

C　writeは既に有効化済みのメソッドを設定するためのもので、有効化そのものは行えない

D　有効化済みメソッドへログインするコマンドであり、マウントを作る操作ではない

正解：B

A　サーバ設定ファイルはリスナーやストレージなどの構成用で、利用者の権限定義は置かない

B（正解）　正解。認証(誰か)と認可(何ができるか)はトークンを介して結び付き、ポリシーは認証メソッドの設定側で割り当てる

C　自己申告で権限を選べれば権限昇格が自由にできてしまう。Vaultはサーバ側の定義に従う

D　既定で付くのはdefaultポリシーのみで、rootが自動付与されることはない

正解：A

A（正解）　正解。pathブロックにcapabilitiesの配列を書くのがVaultポリシーの基本構文

B架空　permissionsという属性はVaultのポリシー構文に存在しない。正しい属性名はcapabilities

C　ブロック名はpathであり、policyではない

D　KV v2の実際のAPIパスはsecret/data/配下になるため、このパスでは読み取りが許可されない

正解：C

A　Vaultは許可優先ではない。denyが混在した時点で拒否される

B　ポリシーに適用順という概念はなく、付与順で結果は変わらない

C（正解）　正解。denyは他のどの許可よりも強く働くため、誤って広い権限を与えたときの安全弁として使える

D　競合は明確なルールで解決されるだけで、トークンが失効することはない

正解：B

A　空ではなく、自分自身のトークンを扱うための最低限の権限が定義されている

B（正解）　正解。これがあるおかげで、どのトークンも自分の情報確認や更新、自主的な失効ができる

C　それはrootポリシーの説明で、defaultとは別物

D　特別扱いどころか、既定ですべてのトークンに付く汎用のポリシー

正解：D

A　除外パスはなく、sys/配下も含めてすべてが許可される

B　rootポリシーは変更できない。権限を絞りたい場合は別のポリシーを作って使う

C　削除もできない。運用上はrootトークンを失効させ、必要なときだけ再生成する運用が推奨される

D（正解）　正解。特権が強すぎるため、日常運用ではrootトークンを常用せず必要時のみ生成する

正解：B

A　root保護された特権パスに必要なもので、通常のキー一覧とは関係がない

B（正解）　正解。キーの一覧取得はreadとは別のcapabilityとして扱われるため、listを明示的に許可する必要がある

C　新規作成のための権限で、一覧の可否には影響しない

D　既存データの更新のための権限で、読み取り系の一覧操作には使われない

正解：C

A　rootはポリシー名であってcapabilityではない。ポリシー内に書けるものではない

B架空　Vaultのポリシーにexecuteというcapabilityは存在しない

C（正解）　正解。root保護パスに対してはreadやupdateといった通常のcapabilityに加えてsudoを併記する必要がある

D　アクセスを明示的に拒否するためのもので、特権を与える方向には働かない

正解：B

A　CLIで見える表記に近いが、KV v2の実際のAPIパスではないためこのポリシーは効かない

B（正解）　正解。KV v2ではシークレット本体がdata/の下に置かれるため、ポリシーもこのパスで書く

C　バージョン情報などのメタデータ用のパスで、ここを許可してもデータ本体は読めない

D　マウント配下すべてに広がってしまい、最小権限の要件を満たさない

正解：A

A（正解）　正解。既定拒否(deny by default)なので、必要な権限だけを足していく設計になる

B　読み取りであっても明示的な許可がなければ拒否される

C　defaultポリシーが許可するのは自トークンの管理など限られた操作だけで、任意のパスには及ばない

D　警告付きで通すという挙動はなく、単純に拒否される

正解：B

A　既定の種別で機能は豊富だが、1つ1つがストレージに永続化されるため大量発行時の負荷が問題になる

B（正解）　正解。暗号化された値としてクライアントに返され、ストレージに書かれない。その代わり更新も子トークン作成もできない軽量な種別

C　長期稼働プロセス向けに更新し続けられる性質を指すもので、ストレージ負荷を減らす仕組みではない

D　親を持たないという性質を指すだけで、永続化されるかどうかとは別の軸の話

正解：C

A　そもそも更新ができないため、TTLが切れた時点で使えなくなる

B　指定回数使うと失効する種別で、長期稼働にはむしろ不向き

C（正解）　正解。通常の最大TTLの制約を受けず、period(周期)ごとに更新し続ける限り有効期限が延び続ける

D　親の失効の影響を受けないというだけで、最大TTLの制約は通常どおり適用される

正解：A

A（正解）　正解。親を持たないため親トークンの失効に巻き込まれず、独立したライフサイクルを持つ

B架空　transientという名前のトークン種別はVaultに存在しない

C　TTLの長さと親子関係は別問題で、親を失効させれば残TTLに関係なく子も失効する

D　ストレージに永続化されない軽量な種別で、親子関係の解消を目的とした選択ではない

正解：D

A　子は親のライフサイクルに従うため、TTLが残っていても一緒に失効する

B　トークンに紐付くリースも同時に失効し、動的シークレットの実体も削除される

C　子の存在は失効を妨げない。むしろ連鎖的に処理される

D（正解）　正解。トークンは木構造を持ち、失効は下方向へ伝播するので、根を切れば配下がまとめて無効になる

正解：B

A　最大TTLは発行時点から測られる上限で、更新によって延びることはない

B（正解）　正解。最大TTLは無期限に生き続けるトークンやリースが生まれないようにする安全装置として働く

C　警告値ではなく強制的な上限で、到達すれば失効する

D　動的シークレットのリースにも同様に最大TTLが適用される

正解：A

A（正解）　正解。指定した回数だけ使えるトークンとなり、使い切った時点でTTLが残っていても自動的に失効する

B　periodは更新周期を表す時間の設定で、使用回数の制限ではない

C　親子関係の設定であり、使用回数とは無関係

D　時間の制限にはなるが、その時間内であれば何回でも使えてしまう

正解：C

A　リースは再取得のためのキーではなく、要求のたびに新しい資格情報とリースが作られる

B　追跡にも使えるが、本質はライフサイクル管理であり監査専用の値ではない

C（正解）　正解。動的シークレットは発行しっぱなしにならず、リースを通じて確実に後始末される

D　鍵バージョンはTransitなどの概念で、リースIDとは別物

正解：A

A（正解）　正解。リースIDを指定して更新することで、最大TTLの範囲内で有効期間を延長できる

B　トークン自体のTTLを更新するコマンドで、シークレットのリースは延長されない

C　リースを失効させる操作で、延長したいという意図とは逆の結果になる

D　新しい資格情報と新しいリースが作られるだけで、使用中の資格情報の期限は延びない

正解：C

A　KVはv1もv2も静的なシークレットの保管用で、動的シークレットは発行しない

B　どちらもバリアで暗号化されて保存される。暗号化の有無は違いではない

C（正解）　正解。値を上書きしても過去バージョンが残り、削除してもundeleteで戻せる点がv1との大きな違い

D　バージョンに関係なくポリシーによる認可は必要で、むしろv2ではdata/とmetadata/を意識した記述が要る

正解：B

A　これはKV v1のパス構造。v2ではdata/が挟まる

B（正解）　正解。kvサブコマンドがv2のパス構造を補ってくれるため、CLIの見た目とAPIパスがずれる。ポリシー記述時はこの実パスを使う

C　バージョン一覧や削除状況などメタデータを取得するパスで、値そのものは返らない

D　マウントパスはsecretのままであり、kvというセグメントが前に付くことはない

正解：A

A（正解）　正解。誤操作からの回復を考えた設計になっており、完全に消すには別途destroyが必要

B　即時消去されるのはdestroyを使った場合の挙動

C　メタデータごと消すにはmetadata deleteを使う。deleteの対象は特定バージョンにとどまる

D　削除マークが付いたバージョンは読み取れなくなる。読み書きの片方だけを止める機能ではない

正解：D

A　確認から書き込みまでの間に他プロセスが更新する余地が残るため、競合は防ぎきれない

B　運用としては単純化できるが、複数プロセスが更新するという前提そのものを崩してしまう

C　参照側がどのパスを見ればよいか分からなくなり、根本的な解決にならない

D（正解）　正解。現在のバージョンが期待値と一致するときだけ書き込みが成功するため、見落とした更新を上書きせずに済む

正解：A

A（正解）　正解。要求時に生成され期限が来れば消える短命な資格情報になるため、共有アカウントの問題を避けられる

B　それは静的なシークレット保管の動作で、動的シークレットエンジンの振る舞いではない

C　Vaultは資格情報を発行するだけで、DB通信の経路には入らない

D　ルート資格情報のローテーションなど別機能の話で、creds/の読み取りでは新規ユーザーが作られる

正解：C

A　Vaultはデータベースのユーザー管理機能を使って資格情報を作るため、DB側の認証は引き続き必要

B　むしろ有効期限があるためキャッシュと更新の考慮は増える。利点の本質ではない

C（正解）　正解。共有アカウントでは不可能だった追跡性と、影響範囲を限定した失効が実現できる

D　強度は主にVaultとDB側の設定に従うもので、移行の主目的でもない

正解：B

A　外部ストレージの中身を読むための機能ではない

B（正解）　正解。要求時に生成され、リース満了で自動的に無効化されるため、長期のアクセスキーを配布せずに済む

C　それはストレージバックエンドの設定であり、シークレットエンジンの役割ではない

D　それはAuto Unsealのためのsealスタンザの設定で、シークレットエンジンとは別の機能

正解：D

A　シークレットの保管が役目で、任意データを暗号化して返すAPIは提供しない

B架空　このような名前のシークレットエンジンはVaultに存在しない

C　証明書の発行と失効を担うもので、アプリのデータを暗号化するサービスではない

D（正解）　正解。暗号化/復号/署名/HMACをAPIとして提供するEaaSで、鍵はVaultが管理する一方、暗号化されたデータ自体はVaultに保存されない

正解：C

A　表形式の出力から抜き出す形になり、キー名や整形の変化に弱く値の切り出しも余計な処理が要る

B　-keyというフラグは用意されていない。フィールド指定は -fieldを使う

C（正解）　正解。指定したフィールドの値だけが余計な装飾なしで出力されるため、そのまま変数に代入できる

D　-field自体は正しいが、KV v2ではパスにdata/が必要になるためこのままでは目的のシークレットを読めない

正解：A

A（正解）　正解。ほとんどのコマンドで使えるグローバルオプションで、リースIDやメタデータも含めた構造化された出力が得られる

B　そのようなオプション名ではない。書式指定は -format

C　単独のフラグとしては用意されておらず、-formatに値を渡す形が正しい

D　既定の人間向け表形式で、機械処理には向かない

正解：D

A　トークンをAuthorization: Bearerで渡すこと自体はVaultも受け付けるが、APIパスに /v1/プレフィックスが無く、KV v2のdata/も含まれていないため取得できない

B　ヘッダは正しいが、KV v2のデータ本体はdata/を含むパスにあるため、このパスでは取得できない

C　トークンをURLに含めるとログ等に残る。Vaultはヘッダでトークンを受け取る設計になっている

D（正解）　正解。すべてのAPIは /v1/配下にあり、トークンはX-Vault-Tokenヘッダで渡す。KV v2ではパスにdata/が入る

正解：B

A　認証トークンを渡すための変数で、接続先の指定には使われない

B（正解）　正解。CLIとAPIクライアントが接続するVaultサーバのURLを指定する変数で、未設定だと既定のローカルアドレスが使われる

C　名前空間を指定する変数で、接続先ホストとは無関係

D　出力形式の既定値を決める変数で、接続には影響しない

正解：A

A（正解）　正解。シール状態の確認は認証前でも必要になるため、トークンなしで参照できるようになっている

B　特権は不要で、トークンなしでも状態を確認できる

C　それはvault secrets listの役割

D　それはvault token lookupの役割で、statusはサーバ側の状態を示す

正解：B

A　vault listはAPIのパスをそのまま指定するコマンドで、KV v2ではmetadata/を含むパスを書かないと一覧できない

B（正解）　正解。kvサブコマンドがKV v2のパス構造(metadata/)を補ってくれるため、マウントからの見た目どおりのパスで一覧できる

C　指定したパスのシークレットの値を読み取るコマンドで、配下のキーを列挙する操作ではない

D　metadataサブコマンドに用意されているのはgetやput、deleteなどで、listは存在しない

正解：B

A　シール中はデータの復号に必要な鍵が使えないため、読み取りもできない

B（正解）　正解。シールとはストレージを復号する鍵がメモリ上に無い状態を指し、ほぼすべての機能が停止する

C　トークンの権限とは無関係で、アンシールしない限り誰も操作できない

D　認証もストレージの読み書きを伴うため実行できない

正解：A

A（正解）　正解。1人の手元にある鍵だけではVaultを開けられないため、単独犯行や1枚の紛失に耐えられる

B　1つで足りるならシェアに分ける意味がない。しきい値の数だけ必要になる

C　全数ではなくしきい値(例えば5つのうち3つ)で足りる。1枚紛失しただけで復旧不能になるのを避けるため

D　Vaultが自分で保存していれば封印の意味がない。シェアは運用者が分散して保管する

正解：C

A　手間は減るが1つの鍵でVaultを開けられてしまい、分散管理の安全性が失われる

B　鍵と暗号文が同じ場所に置かれ、封印の意味がなくなる最悪の運用

C（正解）　正解。起動時にVaultが外部の鍵管理サービスへ問い合わせて自動的にアンシールする。人手で扱う鍵はリカバリーキーに置き換わる

D　そのような設定は存在しない。シールはVaultのセキュリティモデルの中核

正解：D

A　Vaultが自ら暗号化してから書き込むため、平文で保存されることはない

B　バリアを通過するデータはまとめて暗号化されるため、値だけという区別はない

C　ストレージを直接読む話とトークンによるAPI認可は別で、直接読んでも暗号文しか得られない

D（正解）　正解。この前提があるため、信頼できないストレージにもVaultのデータを置ける設計になっている

正解：B

A　実在するHA対応のバックエンドだが、別のクラスタを構築・運用する必要があり「外部の運用を増やさない」という要件に合わない

B（正解）　正解。Vaultノード自身がRaftでデータを複製するため、外部依存なしにデータ保存とHAを同時に満たせる

C架空　このような名前のストレージバックエンドは存在しない

D　単一ノードの開発・検証向けでHAに対応しておらず、本番の可用性要件を満たせない

正解：C

A　監査を欠いたまま処理を続けることはVaultの設計上許容されない

B　シールはされない。リクエストが通らなくなるだけで、書き込み先を復旧すれば処理は再開する

C（正解）　正解。監査ログを残せない操作は実行しないという方針のため、監査デバイスは冗長に構成しておくのが定石

D　ログのローテーションや削除はVaultではなく外部の仕組みで管理する

正解：A

A（正解）　正解。誰が何を要求したかを追跡しつつ、ログの流出がシークレットの流出にならないよう配慮されている

B　平文で残るとログ自体が攻撃対象になる。実際にはハッシュ化される

C　成功したリクエストも記録される。むしろ成功した操作の追跡こそが監査の目的

D　シークレットへのアクセスも記録対象で、記録範囲は認証に限られない

正解：D

A　書き込みの一貫性を保つため、同時に処理するアクティブノードは1つに限られる

B　標準構成のスタンバイは読み取りも自分では処理せず、アクティブノードに任せる

C　スタンバイの1つが自動的にアクティブへ昇格するため、手動再構成は不要

D（正解）　正解。アクティブ/スタンバイ方式で、アクティブが落ちればスタンバイが昇格して処理を引き継ぐ

正解：B

A　公開鍵暗号による封筒化ではない。実体は一時的な保管領域と引き換えトークンの組み合わせ

B（正解）　正解。受け渡し経路にはラップトークンしか流れず、途中で開封されていれば受信者側のunwrap失敗として検知できる

C　転送効率のための機能ではなく、秘密の受け渡しを安全にするための仕組み

D　unwrapは一度きり。2回目が成功しないからこそ、開封済みかどうかを判断できる

正解：A

A（正解）　正解。アプリからVaultの認証やトークン更新のロジックを取り除けることがAgentを使う大きな理由になる

B　アンシールはAuto Unsealの担当で、Agentの機能ではない

C　認証メソッドの有効化は運用者がサーバ側で行う作業

D　ポリシーは人が設計して登録するもので、自動生成する機能はない

正解：C

A　暗号化しても、アプリが自力で復号できなければ設定ファイルを読み込めない

B　受け渡しの安全性は高まるが、unwrapする処理をアプリ側に実装する必要があり無改修にはならない

C（正解）　正解。Agentがシークレットを取得してファイルに書き出し、更新時には再描画するため、アプリは通常のファイルを読むだけで済む

D　シークレットの履歴管理の機能で、アプリへの受け渡し方法の問題は解決しない

正解：B

A　説明が逆になっている。rekeyが扱うのはアンシールキーの側

B（正解）　正解。担当者の異動でシェアを配り直すのがrekey、以後の書き込みを新しい鍵で暗号化するのがrotate

C　対象が異なる別の操作で、必要になる場面も違う

D　rotate後も既存データは以前の鍵バージョンのまま復号でき、全件の再暗号化は行われない