課題とスコープ
ある企業が耐量子暗号（PQC）への移行を準備していますが、どのシステムがRSA、楕円曲線暗号、または共有鍵を使用しているかを把握できていません。収集、重複排除、リスクスコアリング、アクセス制御、変更検知、および移行ハンドオフを網羅する暗号資産インベントリサービスを設計してください。
これは資産ガバナンスの設計問題であり、量子コンピュータがいつ登場するかを予測するものではありません。RFC 9958は、インベントリ、鍵共有と署名の用途、暗号アジリティ、および移行エビデンスを関連付けており、NISTはML-KEM、ML-DSA、SLH-DSAの各標準を策定完了しています。
面接官が評価するポイント
- アルゴリズム、鍵、証明書、プロトコルスイート、データの有効期間の明確な区別。
- コードスキャン、ランタイムテレメトリ、証明書データ、HSM APIを追跡可能なファクト（事実）として連携させる能力。
- 重複した検出結果、陳腐化したレコード、未知のアルゴリズム、内部構造が不透明なベンダーの処理。
- テナント分離、最小権限、バージョニングされたエビデンス、および監査クエリの設計。
- 単にダッシュボードを作成するだけでなく、リスクスコアを移行バッチ、停止ライン（ストップライン）、ロールバックへ連携させる仕組み。
明確化のための質問
- スコープに含まれる環境はどれか：ソースコード、コンテナ、モバイルクライアント、ファームウェア、クラウドKMS、HSM、SaaSベンダー？
- アイデンティティは鍵、証明書、呼び出し箇所、サービス、データフローのどれか？システム間での鍵の再利用は許可されているか？
- 履歴はどのくらいの期間保持する必要があるか、また誰がアルゴリズム名や機密性の高いビジネスラベルを閲覧できるか？
- スコアリングの目的はコンプライアンスのエビデンス、エンジニアリング計画、それとも自動デプロイブロックか？
- 収集が失敗した場合、システムは推定を行うことが許されるか、それとも「未知」としてマークし、完了ステータスの主張を防止すべきか？
エンドツーエンドの設計
コレクターは、静的スキャン結果、証明書パース結果、KMS/HSMの監査イベント、サービス構成、ランタイムのハンドシェイク要約を不変のイベントストリームに書き込みます。正規化レイヤーは、アルゴリズム、用途、鍵識別子、呼び出し元、機密性保持期間、ソース、時刻、信頼度をバージョニングされたスキーマにマッピングします。エンティティ解決ではtenant_id + asset_namespace + provider_id + local_idを候補鍵として使用し、証明書フィンガープリント、鍵ARN、デプロイID、時間枠を用いて重複排除を行います。同一であると証明できないレコードは、マージせずにリンクされた状態を維持します。
クエリAPIはメタデータとエビデンスへのリンクを返し、秘密鍵や完全な暗号文を返すことは決してありません。ポリシーレイヤーは、データの有効期間、アルゴリズムのステータス、露出度、アップデート不可能なクライアントの割合、エビデンスの鮮度に基づいて資産をスコアリングします。スコアには入力スナップショット、ルールバージョン、オーバーライド理由が保存されます。移行オーケストレーターは高リスク資産を読み取ってバッチ、担当者、互換性マトリクス、受け入れメトリクスを生成しますが、本番環境の鍵を直接置き換えてはなりません。
整合性と変更検知
ストリームは少なくとも1回（at-least-once）配信されるため、各検出結果にはsource_event_idとコレクターバージョンが付与され、コンシューマーは冪等な書き込みを行います。資産の状態はイベントからフォールド（集約）され、削除は時限付きの失効イベントとして処理されるため、スキャン漏れが資産の消失に見えることはありません。スケジュールされたスキャンとランタイムのハートビートがlast_seenを更新し、鮮度ウィンドウ外となったレコードは未知として扱われます。
コード、証明書、構成に対して個別のコンテンツダイジェストを計算します。ダイジェストの変更は履歴の上書きではなく新しいバージョンを作成します。ルールのアップグレード時は過去のスコアを保持しつつ再計算を行うため、当時その資産が承認された理由を監査できます。競合が発生した場合はフィールド、ソースの優先順位、確認タスクを表示し、システムがソースを勝手に選択してはなりません。
アクセス、プライバシー、および信頼性
テナント、ドメイン、資産ラベルに基づいて行レベルのアクセス制御を適用します。セキュリティ担当者はアルゴリズムと露出度を閲覧でき、アプリケーションチームは自身の移行タスクのみを閲覧できます。鍵情報、トークン、未加工トラフィックがインベントリに入ることは決してなく、ランタイム収集ではハンドシェイクのメタデータとマスキングされた識別子のみを保持します。すべての読み取りと手動編集は監査されます。
オフラインコレクターはローカルにバッファリングしてリプレイします。クォータとバックプレッシャーによりイベントストリームを保護します。クエリは「基準時刻（as-of time）」とエビデンスの鮮度を公開し、陳腐化したインベントリが最新の実態として提示されないようにします。マルチリージョンデプロイではパーティション化された書き込みとグローバル読み取りインデックスを使用し、レプリケーション障害時は完全な状態を主張するのではなくカバレッジの欠落を報告します。
トレードオフと境界
静的スキャンは広範囲をカバーしますが動的ネゴシエーションを見落とす可能性があり、ランタイムテレメトリは実際の使用状況に近いもののトラフィックやプライバシーによる制約を受けます。両方を異なる信頼度とともに保存します。中央集権的なグラフは依存関係のクエリを簡素化しますが爆発半径（影響範囲）を拡大させます。ドメインパーティションはアクセス制御を簡素化し、ドメイン間は読み取り専用リンクで接続します。
新しいアルゴリズムを自動的にブロックすることで新たな負債を減らせますが、未知のベンダーとの連携が破綻する可能性があります。まずは高リスクルールの承認ゲートから開始し、偽陽性率、未知資産の割合、ロールバック成功率に基づいて強制適用の是非を判断します。インベントリはファクトと優先順位付けを担い、ライブラリのアップグレード、証明書の発行、ビジネスの移行は独立したパイプラインとして維持します。
障害訓練とスコアリング基準
HSMが鍵の用途を公開していない場合は、「用途不明（purpose unknown）」と記録してエビデンス収集タスクを作成し、サービス名から推測してはなりません。証明書が複数のテナントにまたがって存在する場合は、共有関係を保持したまま分離レビューをトリガーします。コレクターのアップグレードによって資産が急増した場合は、新しいベースラインを受け入れる前に生イベントとルールのバージョンを比較します。
優れた回答には、複数のソースタイプ、不変のエビデンス、冪等性と失効セマンティクス、最小権限、説明可能なスコアリング、移行ハンドオフが含まれます。明示的な未知状態の定義、保持期間、競合処理、ロールバック境界、インベントリ網羅率メトリクスに言及すると高評価となります。データベースとダッシュボードだけでは不十分です。
フォローアップの質問と模範回答
なぜサービス名からアルゴリズムを推測してはならないのか？
サービスは複数のライブラリ、プロトコル、またはベンダーを呼び出す可能性があり、その名前は鍵の用途やネゴシエートされた動作を証明しないためです。ソースエビデンスを保持し、推測によるものは信頼度「低」としてマークします。
インベントリの網羅性（Completeness）をどのように定義するか？
環境カバレッジ、ソースの鮮度、未知資産の割合、重複率、イベントレイテンシ、サンプリングによる人手での検証精度を使用します。資産数だけでは網羅性の証明になりません。
移行処理はどのようにインベントリを利用するか？
オーケストレーターがリスクとアップデート可能性に基づいて資産をバッチ化し、互換性とパフォーマンスのバジェットを読み取って、カナリアデプロイ、監視、ロールバックを実行します。インベントリはファクトとエビデンスを提供する役割を担い、本番環境の暗号設定を直接変更することはありません。