耐量子暗号の移行は製品交換から始めない、先に暗号を棚卸し

耐量子暗号への移行は、対応製品の購入ではなく、現在の暗号利用を棚卸しするところから始める。TLS、VPN、PKI、コード署名、バックアップ、組み込みシステムについて、どこで何を守り、誰が管理し、どの接続先に依存しているかを一つの台帳にまとめる。

次に、保護期間、停止時の業務影響、変更に要する時間、外部依存性から着手順を決める。候補構成は非本番環境で新旧システムの相互運用性と撤回手順まで試し、合格した範囲だけを段階的に展開する。この順序は無停止を保証するものではないが、全システムの一斉交換を前提にせず、影響を限定して移行を管理できる。

棚卸しは製品名ではなく暗号の用途から始める

台帳の対象は「暗号製品」に限らない。NIST NCCoEの移行プロジェクト は、量子計算機に脆弱な公開鍵暗号がハードウェア、ソフトウェア、サービスのどこで使われているかを把握し、移行の優先順位を定めるロードマップを作る必要があるとしている。同プロジェクトは、暗号の発見と相互運用試験を二つの作業系統に分けている。

初回調査では、資産管理表や構成管理データベースだけで完結させない。設定ファイル、証明書ストア、ロードバランサー、APIゲートウェイ、クラウドの鍵管理サービス、HSM、暗号ライブラリ、CI/CDパイプラインを確認し、可能なら設定取得や通信観測の結果と突き合わせる。文書だけでは、部門が個別に導入した証明書、委託先が管理する鍵、更新機能のない機器を見落としやすい。

探索票は、少なくとも次の領域に分ける。方式名を記録するだけでなく、その暗号が使えなくなったときに影響を受ける業務まで結び付ける。

• TLS：公開・社内エンドポイント、終端装置、証明書発行元、利用クライアント、更新方法
• VPN：ゲートウェイ、端末、拠点機器、鍵交換・認証方式、遠隔保守経路
• PKI：ルート・中間認証局、証明書プロファイル、登録局、失効確認、HSM、更新周期
• コード署名：ビルド基盤、署名鍵、検証環境、配布経路、成果物を検証する期間
• バックアップ：暗号化箇所、鍵の保管先、保持期間、復元先、災害復旧手順
• 組み込みシステム：機器型番、ファームウェア、セキュアブート、更新可否、保守期限、ベンダー

一行ごとに責任者と変更境界を持たせる

台帳の一行は、サーバー単位ではなく、変更判断ができる暗号利用単位にする。同じ装置でも、外向けTLS、管理用SSH、バックアップ暗号化、署名検証では、保護対象、接続相手、変更手順が異なるため、原則として行を分ける。同じ証明書、設定、更新手順を共有する均質なサーバー群は、対象数を付けてまとめてもよい。

各行には、資産ID、業務サービス、管理部門、技術担当、暗号の用途、プロトコル、アルゴリズムとパラメーター、鍵・証明書の保管先、保護期間、接続先、利用製品またはライブラリ、設定変更の可否、保守期限、ベンダー対応状況、検証環境の有無を持たせる。発見方法、確認者、確認日、情報の確度も分けて記録すれば、推測値を確定情報として扱う事故を避けられる。

「ベンダー対応待ち」は状態であって計画ではない。問い合わせ先、回答日、対応予定版、追加ライセンスの要否、既存機器を更新できるか、接続相手にも変更が必要かを記録する。SaaS、通信事業者、決済網、行政機関など自組織だけで切り替えられない経路には、依存先の責任者と共同試験の窓口を割り当てる。

保護期間と移行時間を先に比べる

着手順を「重要システムかどうか」だけで決めると、長期間守るべきデータや、交換に時間のかかる基盤を後回しにしかねない。守秘用途ではデータをいつまで秘密にする必要があるか、署名用途ではコードや文書をいつまで真正なものとして検証する必要があるかを台帳に加える。

CRYPTRECの2024年度版ガイドライン は、情報を保護する期間と暗号実装の置き換えに要する期間の合計を、量子計算機による攻撃が可能になるまでの期間と比較する考え方を説明している。攻撃可能時期は不確実であり、保護期間と移行期間もシステムごとに異なるため、まず両者を把握する必要がある。

組織内で着手順をそろえるため、次の五項目を低・中・高など共通の尺度で評価する。この評価表は実務用のテンプレートであり、法令、契約、既存のリスク基準がある場合は、それらを優先する。

• 保護期間：データの機密性または署名の検証可能性を維持すべき期間
• 業務影響：障害時の代替手段、停止範囲、復旧目標への影響
• 外部露出：閉域、限定接続、インターネット公開などの接続条件
• 交換難度：設定変更、ソフトウェア更新、機器交換、再認証に必要な作業
• 外部依存性：接続先、クラウド、ベンダーとの調整範囲と共同試験の可否

評価が高い対象は、直ちに本番変更するのではなく、詳細調査、予算確保、ベンダー調整、検証枠の確保を先に始める。同程度なら、保護期間が長いもの、移行のリードタイムが長いものを先行させる。逆に、短期間しか保持しない低影響データを扱い、通常更改で置き換えられる対象は、更改計画に組み込む判断ができる。

試験はアルゴリズム単体ではなく接続全体で行う

検証の目的は、新しい方式が単体で動くことの確認ではない。クライアント、サーバー、証明書チェーン、ネットワーク中継装置、監視、ログ、鍵管理、バックアップ、復旧手順まで含む接続全体が成立し、新旧構成を併存させられるかを確かめる。

検証環境には、本番で利用するOSとライブラリの主要版に加え、残存している旧版クライアント、ロードバランサー、VPN装置、HSM、プロキシ、通信検査装置を含める。合否を接続成功だけで決めず、応答時間、CPU・メモリー使用量、通信サイズ、タイムアウト、証明書更新、監視イベント、監査ログも既存構成の基準値と比較する。

1. 現行構成の接続成功率、応答時間、資源使用量、ログ出力を基準値として保存する。
2. 一度に変更する要素を限定し、対応するクライアントとサーバーの正常系を確認する。
3. 未対応クライアント、通信断、証明書検証失敗、鍵更新失敗を再現し、影響範囲を記録する。
4. PKIでは発行・更新・失効、コード署名では新旧署名の作成・検証、バックアップではテストデータの復元まで試す。
5. 旧構成への撤回を実行し、鍵、証明書、設定、監視が所定の状態へ戻ることを確認する。

合格条件は事前に数値または観測可能な状態で定める。必要な接続先が成功すること、組織が定めた性能幅に収まること、監視と監査の記録が残ること、復元と撤回が許容時間内に終わることを判定項目にする。重要経路に未対応機器が残る場合、その経路は対応策が決まるまで展開対象から外す。

段階展開には撤回条件を組み込む

段階展開では、影響の小さい対象をパイロットにして運用経験を得る一方、重要システムの設計、調達、接続先との調整を並行して進める。金融分野を対象とする G7 Cyber Expert Groupの2026年1月ロードマップ は、暗号資産、通信プロトコル、第三者依存関係の包括的な棚卸しを置いた後、リスク評価、優先機能からの段階展開、移行試験、継続的な検証へ進む枠組みを示している。これは規制上の義務を定める文書ではなく、組織ごとの事情に合わせる非規範的な考慮事項である。

展開範囲は、開発環境、社内限定利用、限定拠点または少数利用者、一部の本番通信、全体の順に広げる。各段階で観測期間を設け、接続失敗、遅延、資源使用量、証明書の発行・更新失敗、監視イベント、問い合わせの増加を基準値と比べる。次段階への承認には、実装担当だけでなく、対象業務とセキュリティの責任者を含める。

撤回条件には、重要な接続先の不通、性能基準の超過、監査ログの欠落、鍵管理の異常、復旧試験の失敗を入れる。撤回後は旧方式を無期限に残さず、原因、残存リスク、対応責任者、再試験日を台帳へ戻す。最初にそろえる成果物は購入品一覧ではなく、責任者の付いた暗号台帳、優先順位表、試験計画、段階展開と撤回の条件である。