プロンプトとコンテキスト
CDNのエッジノードは数が多く外部に露出しているため、長期有効な証明書鍵を配布すると侵害時の影響が拡大します。RFC 9345を使用してDelegated Credentials（DC）を設計します。証明書保持者が短期間有効なクレデンシャルを発行し、エッジはそれをTLS認証に使用し、そのクレデンシャルからさらに別のDCを発行することはできません。ハンドシェイクの検証、有効期限、ローテーション、失効の制限、およびフォールバックを網羅してください。
面接官がテストしているポイント
評価されるシグナルは、DCとX.509エンドエンティティ証明書とのバインディング、短期間有効な鍵の権限境界、TLS拡張のネゴシエーション、時間枠、および侵害時の影響に対する理解です。優れた回答では、露出時間の削減と即時失効の違いを明確に区別し、DCをサポートしていないクライアントに対する安全なフォールバックを説明します。
最初に確認すべき明確化のための質問
トラフィックと終端ポイント
TLSがCDN、リージョナルゲートウェイ、オリジンのどこで終端するか、エッジが複数の管理ドメインにまたがっているか、DTLSやQUICが関係しているかを確認します。終端ポイントによって発行および配布の経路が決まります。
クライアント互換性マトリクス
ブラウザ、モバイル、IoT、および内部クライアントのバージョンを特定し、それらのTLSスタックがアップグレード可能かどうかを確認します。DCには拡張のネゴシエーションと新しい検証ロジックが必要となるため、サポートを前提とすることはできません。
侵害対策の目標
目標が長期有効な鍵の露出制限なのか、エッジ鍵の有効期間の短縮なのか、あるいはその両方なのかを明確にします。コンプライアンス上、個別の失効リストや強制的な取り下げが必要かどうかも確認します。
30秒の回答フレームワーク
「証明書保持者が短期間有効なDCを発行し、その署名、用途、有効期間はエンドエンティティ証明書の鍵で検証されます。エッジはDC秘密鍵のみを受け取り、別のDCを作成することはできません。クライアントはTLS拡張フロー中にそのバインディングを検証します。長期有効な鍵を保護しつつ、短い有効期間、重複を持たせたローテーション、鍵の分離を採用します。非対応クライアントには通常の証明書パスを明示的に使用し、検証失敗時に暗黙的にダウングレードすることは決してありません。侵害対応は即座のDC失効を前提とするのではなく、短い有効期限、発行の停止、そして必要に応じた親証明書の失効に依存します。」
深掘り回答ステップ
ステップ1: 発行関係を定義する
エンドエンティティ証明書に対応する長期有効な秘密鍵を保持するイシュアが、DC公開鍵、有効期間、署名アルゴリズム、およびTLS/DTLSの用途情報を作成します。エンドエンティティの公開鍵で署名を検証します。エッジはDC秘密鍵とパブリッククレデンシャルを受け取りますが、親の秘密鍵を受け取ることは決してありません。
ステップ2: 権限と用途を限定する
DC秘密鍵は合意されたTLS認証の役割に限定され、別のDCを発行することはできません。TLS専用のクレデンシャルが汎用的な署名鍵として扱われないよう、DelegationUsage、アルゴリズムの互換性、およびプロトコルコンテキストを検証します。
ステップ3: ハンドシェイク中に検証する
クライアントは従来のX.509チェーンを検証し、続いてDC署名、有効期間、親証明書とのバインディング、およびハンドシェイクコンテキストを検証します。拡張ネゴシエーションが失敗した場合は、明示的な通常証明書パスを使用します。未知または矛盾するセキュリティフィールドは、無視するのではなく検証失敗としなければなりません。
ステップ4: ローテーション期間を設計する
エッジのクロックスキュー、伝播遅延、および最大ハンドシェイク時間を考慮して重複期間を設定します。古いクレデンシャルが有効な間に新しいDCをロードしてから切り替え、配布が確認された後にのみ古いクレデンシャルの使用を停止します。時間同期とモニタリングによって境界期間をカバーします。
ステップ5: 侵害と失効に対処する
DC秘密鍵を取得した攻撃者は、そのDCが期限切れになるまで新規接続で当事者になりすますことができますが、別のDCを発行することはできません。対応策には、発行の停止、有効期間の短縮、エッジクレデンシャルの取り下げ、そして必要に応じた親証明書の失効や通常証明書への切り替えが含まれます。DCは即時失効のためのメカニズムではありません。
ステップ6: 互換性とフォールバックを計画する
クライアントマトリクスと段階的なトラフィック移行を用いて拡張機能のサポートを検証します。非対応クライアントは、親鍵が分離された状態を保ちつつ、長期有効な証明書による終端パスに従います。「ピアが非対応」と「検証失敗」を区別し、検証失敗を平文通信や任意の証明書へとダウングレードしてはなりません。
ステップ7: 監視と訓練を実施する
秘密鍵をログ出力することなく、発行、配布、ロード、ハンドシェイク失敗、クロックスキュー、およびフォールバック率を記録します。エッジの侵害、イシュアの停止、親証明書の失効、完全なフォールバックを訓練し、短い有効期間内に復旧できることを検証します。
高品質な回答例
長期有効な証明書鍵はイシュア内に保持し、短期間有効なDCへの署名に使用します。エッジは各DCの秘密鍵のみを受け取ります。ハンドシェイク中には、X.509チェーンを検証した後、DCのバインディング、用途、アルゴリズム、有効期間、ハンドシェイクコンテキストを検証します。重複を持たせてローテーションし、クロックを監視し、段階的に互換性を確保して、古いクライアント向けの明示的なフォールバックを提供します。DCが漏洩した場合は、発行を停止し、エッジのクレデンシャルを取り下げ、有効期限切れを待ち、必要に応じて親証明書を失効させます。検証失敗とフォールバック率を監視します。DCは即時失効を提供するものではありません。
よくある間違い
- 間違い: 漏洩したDCがOAuthトークンのように即座に失効できると思い込む。 → 理由: RFCは短い有効期間と親証明書へのバインディングに主眼を置いています。 → 改善策: 有効期間を短縮し、親証明書の失効および取り下げを準備します。
- 間違い: DC秘密鍵を持つエッジがさらにDCを発行できるようにしてしまう。 → 理由: 委譲チェーンと権限が無秩序に拡大するためです。 → 改善策: 親鍵は厳格に管理されたイシュア内に保持します。
- 間違い: 拡張機能のサポートがない場合にフィールドを無視する。 → 理由: ネゴシエーション互換性と検証成功は同一ではありません。 → 改善策: 非対応、検証失敗、通常のフォールバックを明確に分離します。
- 間違い: 発行タイムスタンプのみに基づいてローテーションする。 → 理由: 伝播遅延やクロックスキューにより、エッジがクレデンシャルを早すぎる時期や遅すぎる時期に使用する可能性があります。 → 改善策: 重複期間を設け、時刻同期を監視します。
フォローアップの質問と回答
フォローアップ1: DCと通常の短期間有効なX.509証明書の違いは何ですか？
DCは既存のエンドエンティティ証明書にバインドされてTLSハンドシェイクで使用されるため、エッジが親の秘密鍵を保持する必要がありません。通常の短期間有効な証明書では、通常CAや証明書システムが完全なチェーンを発行する必要があります。デプロイと検証の境界が異なります。
フォローアップ2: 攻撃者がDC秘密鍵を入手した場合、何ができますか？
DCの有効期限が切れるまで、新規TLS接続で当事者になりすますことができますが、別のDCを発行するためにその鍵を使用することはできません。攻撃可能な時間枠は、有効期間、親証明書の状態、ならびに検知および対応の速度に依存します。
フォローアップ3: なぜDelegationUsageが必要なのですか？
どの証明書が明示的にDCへの参加を許可しているかを制限し、委譲セマンティクスを持たない証明書がDC検証に流用されることによるクロスプロトコルリスクを軽減するためです。
フォローアップ4: QUICやDTLSには個別のトラストアンカーが必要ですか？
新しいトラストアンカーは不要ですが、用途、ハンドシェイクフィールド、およびアルゴリズムを検証するためにRFC 9345のプロトコルコンテキストと拡張ルールに従う必要があります。十分な検証なしにTLSのパース処理を別のプロトコルにそのまま再利用することはできません。