ワークロードID移行クイズ

このクイズでは、SPIFFE/SPIREの構成、アテステーションの原則、IAM Authとの共通点と決定的な違いについて理解度を確認します。

多肢選択問題

1. SPIFFE IDにIPアドレスやホスト名などのネットワーク情報が含まれないのはなぜですか？
   • A) URI形式ではIPアドレスを表現できないため
   • B) ワークロードの配置先やIPアドレスが変わっても、IDは同じである必要があるため
   • C) ネットワーク情報はSVIDに別途含まれるため
   • D) IPアドレスを公開するとセキュリティ上のリスクになるため

回答を表示

回答: B) ワークロードの配置先やIPアドレスが変わっても、IDは同じである必要があるため

解説: SPIFFE IDはspiffe://<trust-domain>/<workload-path>という形式で、パスには通常、NamespaceとServiceAccountが反映されます。ネットワーク情報を含めないのは意図的です。Podが再スケジュールされて新しいIPアドレスを取得しても、IDは維持されなければなりません。これは、IPベースの制御からIDベースの制御へ移行するための出発点です。Latticeのリンクローカル範囲では宛先IPベースの制御が意味をなさなくなるのも、同じ考え方です。

2. SPIREのWorkload Attestationでは、ブートストラップ問題はどの時点で決定的に解決されますか？
   • A) ワークロードが事前に埋め込まれたトークンを提示したとき
   • B) 信頼できるカーネルとアテスターを前提に、Agentがカーネル提供のピア情報を使い、ワークロードセレクターと照合したとき
   • C) ServerがSVIDに署名したとき
   • D) EnvoyがSDS経由で証明書を受信したとき

回答を表示

回答: B) 信頼できるカーネルとアテスターを前提に、Agentがカーネル提供のピア情報を使い、ワークロードセレクターと照合したとき

解説: この方式では、ワークロードが事前共有されたアプリケーションシークレットを使ってブートストラップする必要がありません。ただし、ホストの侵害、不適切なセレクター、誤ったアテスター設定に対する無条件の保証ではありません。

3. SVIDの有効期間が短く設計されているのはなぜですか？
   • A) ストレージ容量を節約するため
   • B) 短い有効期間で認証情報が使える時間を限定しつつ、侵害対応や認可制御の代わりにはならないため
   • C) CAの署名処理の負荷を分散するため
   • D) 実行時のあらゆるシークレットと侵害対応の要件をなくすため

回答を表示

回答: B) 短い有効期間で認証情報が使える時間を限定しつつ、侵害対応や認可制御の代わりにはならないため

解説: 更新処理、実行時の保管場所、リプレイへの露出、緊急拒否や失効の動作を確認してください。有効期限が切れるまで有効な認証情報にもシークレットが含まれており、期限切れまで自動的に安全になるわけではありません。

4. SPIFFE/SPIREとLattice IAM Authの構造上の共通点は何ですか？
   • A) どちらもX.509証明書を使い、mTLSを実行する
   • B) どちらも長期間有効なシークレットの埋め込みを避けられる一方、実行時の秘密鍵や一時的なシークレット認証情報は保護する必要がある
   • C) どちらも顧客がCAを運用し、接続ごとに認証する
   • D) どちらもAWS外のワークロードに対応し、リクエストごとに認証する

回答を表示

回答: B) どちらも長期間有効なシークレットの埋め込みを避けられる一方、実行時の秘密鍵や一時的なシークレット認証情報は保護する必要がある

解説: X.509 SVIDの配布には鍵のマテリアルが含まれ、IAM認証情報にはシークレットアクセスキーとセッショントークンが含まれます。プラットフォームのアテステーションによってプロビジョニング方法は変わりますが、ソケットやエンドポイント、メモリ、キャッシュを保護する必要は変わりません。

5. 決定的な違い(a)である認証の方向性の変化は、実務上どのような意味を持ちますか？
   • A) クライアントの証明が弱くなるため、アプリケーション側で補う必要がある
   • B) サーバーIDの証明がTLSサーバー証明書の確認までに限定されるため、防御の軸がワークロード間の相互認証からLatticeリソース作成に対するIAM制御へ移る
   • C) 双方向認証が維持されるため、レビューへの影響はない
   • D) 認証そのものが不要になる

回答を表示

回答: B) サーバーIDの証明がTLSサーバー証明書の確認までに限定されるため、防御の軸がワークロード間の相互認証からLatticeリソース作成に対するIAM制御へ移る

解説: 実際には、クライアント側の証明はリクエストごとのSigV4検証によって、より細かくなります。問題はサーバー側の証明です。クライアントが確認できるのはTLS証明書が有効でドメインが一致することまでで、ワークロードIDシステム内で「本当にそのチームのサービスなのか」を確認する手順はありません。対策として、誰がLattice Serviceを作成できるかをIAMで厳格に制限し、サービスネットワークへの関連付けを制御し、CloudTrailで監視します。レビュー資料に「相互認証」と記載していた場合は、書き換える必要があります。

6. 決定的な違い(b)である信頼の起点の所有者の移転が、金融業界のレビューで重要になるのはなぜですか？
   • A) AWS IAMはSPIREより安全性が低いため
   • B) 多くの組織のセキュリティ基準では、認証システムの信頼の起点を自組織の管理下に置くことが求められる、またはそのように解釈されるため。独自CAの運用はそれを満たす最も直接的な方法だった
   • C) CloudTrailでは監査証跡を取得できないため
   • D) IAMポリシーを決める権限がAWSに移るため

回答を表示

回答: B) 多くの組織のセキュリティ基準では、認証システムの信頼の起点を自組織の管理下に置くことが求められる、またはそのように解釈されるため。独自CAの運用はそれを満たす最も直接的な方法だった

解説: SPIREの採用は、そのレビューを通過した結果である可能性が高いでしょう。Lattice IAM Authへ移行する場合は、共有責任モデル、顧客がIAMを通じて誰が何を呼び出せるかを引き続き定義すること、CloudTrailとアクセスログによる監査証跡、顧客がCAの秘密鍵を保有しないことで鍵漏えいのリスクを排除できることなどを根拠に、説明を組み立て直す必要があります。ただし、これは「管理の方法が異なる」という主張であり、「同等である」という主張ではありません。受け入れられるかどうかは組織の基準によります。Dは誤りです。ポリシーを決める権限は顧客に残ります。

7. Latticeへ移行した後もSPIREの運用を続ける必要があるのは、どのような場合ですか？
   • A) IAM Authを使うすべての場合
   • B) エンドポイントのmTLSや、サポート対象のAWS外ワークロードなど、選択したアーキテクチャでSPIFFEエンドポイントIDが引き続き必要な場合
   • C) Gateway API Controllerを使う場合
   • D) マルチクラスター構成を使う場合

回答を表示

回答: B) エンドポイントのmTLSや、サポート対象のAWS外ワークロードなど、選択したアーキテクチャでSPIFFEエンドポイントIDが引き続き必要な場合

解説: SPIREを継続するかどうかはアーキテクチャ上の選択肢であり、AWS外のワークロードすべてに共通する要件ではありません。他の認証情報プロバイダーや、サポートされているプライベートネットワーク経路も評価できます。