PQC（Post-Quantum Cryptography／ポスト量子暗号）への移行で最初に行うべきことは、新しいアルゴリズムの選定ではありません。現在どこで、何のために、どの暗号技術が使われているかを把握し、PQC暗号資産台帳として整理することです。
ただし、ソースコードや証明書を自動スキャンするだけでは、台帳は完成しません。CNG、SymCrypt、OpenSSLなどの基盤ライブラリ、外部コンポーネント、クラウドサービス、HSMやTPM、独自実装に暗号処理が分散しているうえ、間接依存や設計上の暗号利用はツールで発見できないことがあるためです。Microsoftは、こうした不足を脅威モデリングで補い、アルゴリズム、鍵長、プロトコル、鍵ライフサイクル、信頼境界、データ保存期間などを確認する方法を案内しています。(TECHCOMMUNITY.MICROSOFT.COM)
この記事では、脅威モデリングからPQC暗号資産台帳を作る手順、レビュー時に使える質問リスト、台帳項目のテンプレート、移行優先度の決め方まで具体的に解説します。
PQC移行はアルゴリズム選定ではなく暗号資産台帳から始める
ここでいう「暗号資産」は、仮想通貨を意味するものではありません。システム内で利用されている暗号アルゴリズム、鍵、証明書、プロトコル、暗号ライブラリ、鍵管理基盤、署名処理などを指します。
PQC暗号資産台帳は、英語では「Cryptographic Inventory」や「Cryptographic Asset Inventory」と呼ばれます。CBOM（Cryptographic Bill of Materials）という表現が使われることもあります。
Microsoft自身の量子安全プログラムも、暗号資産のリスクを評価して優先順位を付けるための全社的なインベントリ作成から始めています。また、MicrosoftはPQC移行を一度の切り替えではなく、即時の計画と組織的な実行が必要な複数年の取り組みと位置付けています。(Microsoft)
NISTは、次の主要なPQC標準を2024年に公開しました。
| 標準 | アルゴリズム | 主な用途 |
|---|---|---|
| FIPS 203 | ML-KEM | 鍵カプセル化、共有鍵の確立 |
| FIPS 204 | ML-DSA | デジタル署名 |
| FIPS 205 | SLH-DSA | ハッシュベースのデジタル署名 |
NISTは、量子計算に対して脆弱なアルゴリズムがどこで使われているかを組織が特定し、更新計画を作成する必要があるとしています。現在の移行方針では、量子脆弱なアルゴリズムを2035年までに標準から段階的に外し、高リスクなシステムはさらに早く移行する考えが示されています。(NIST Computer Security Resource Center)
ただし、既存アルゴリズムの名前を単純に置き換えれば移行できるわけではありません。Microsoftの.NETチームも、ML-KEMはRSAの鍵配送やECDHの鍵共有に相当する用途を担うものの、実際の利用方法は単純な差し替えにはならないと説明しています。署名についても、RSAやECDSAからML-DSA、SLH-DSAへ移行するには、鍵形式、証明書、署名サイズ、検証側の互換性まで確認する必要があります。(Microsoft Developer Blogs)
暗号資産台帳は「製品単位」ではなく「利用箇所単位」で作る
台帳作成で重要なのは、アプリケーションやサーバーをそのまま1行にしないことです。
1つのWebアプリケーションでも、次の暗号利用は別々に管理する必要があります。
- 利用者からロードバランサーまでのTLS
- ロードバランサーからAPIサーバーまでの内部TLS
- OAuthやOpenID Connectで使うトークン署名
- データベースの保存時暗号化
- データ暗号化鍵を保護する鍵ラッピング
- バックアップファイルの暗号化
- アプリケーションのコード署名
- シークレットを保管するクラウドKMSやHSM
台帳の1行は、原則として次の条件が同じ暗号利用を表します。
- 保護するデータや処理
- 暗号を使う目的
- アルゴリズムとパラメータ
- 実装ライブラリやサービス
- 鍵の保管場所とライフサイクル
- 信頼境界
- 管理責任者
- 移行方法と制約
たとえば、同じTLSでも、インターネット向け通信と社内通信では、管理者、終端装置、証明書、保存期間、移行可能時期が異なります。これらを1行にまとめると、移行時にどの機器やサービスを更新すべきか分からなくなります。
PQC暗号資産台帳に含める対象
暗号利用は、アプリケーションコードだけに存在するとは限りません。少なくとも次の範囲を対象にします。
| 分類 | 確認する対象 |
|---|---|
| OS・プラットフォーム | CNG、SymCrypt、証明書ストア、OSのTLSスタック、暗号プロバイダー |
| ランタイム・ライブラリ | OpenSSL、.NET暗号API、Java暗号プロバイダー、ネイティブライブラリ |
| 外部ライブラリ | NuGet、npm、Maven、Pythonパッケージ、ベンダーSDK |
| クラウドサービス | TLS終端、KMS、Key Vault、マネージドHSM、署名サービス、マネージドデータベース |
| ハードウェア | HSM、TPM、スマートカード、セキュアエレメント、ネットワーク機器 |
| プロトコル | TLS、SSH、IPsec、S/MIME、Kerberos、X.509、JWT、コード署名 |
| データ保護 | 保存時暗号化、バックアップ暗号化、鍵ラッピング、アーカイブ |
| ID・証明書 | ルートCA、中間CA、サーバー証明書、クライアント証明書、トークン署名鍵 |
| 運用処理 | 手動署名、鍵の持ち出し、証明書更新、緊急時の鍵ローテーション |
| 独自実装 | 自作暗号、独自データ形式、独自の鍵派生・署名・暗号化処理 |
特に注意したいのが、暗号処理を外部サービスに任せているケースです。「クラウド側で暗号化している」「OS標準のTLSを使っている」という回答だけでは、台帳として不十分です。
実際のアルゴリズム、設定可能な範囲、鍵の所有者、更新条件、クライアント互換性、ベンダーのPQC対応計画まで確認する必要があります。
自動スキャンだけではPQC暗号資産台帳が完成しない理由
自動化は台帳作成の出発点として有効です。しかし、それぞれの検出方法には得意分野と死角があります。
| 発見方法 | 発見しやすいもの | 見落としやすいもの |
|---|---|---|
| ソースコード検索 | 暗号API呼び出し、アルゴリズム名、ハードコードされた設定 | フレームワーク内部、OS委任、動的に選ばれるアルゴリズム |
| SCA・依存関係スキャン | OpenSSLなどの直接・間接ライブラリ | ライブラリが実際に暗号用途で使われているか |
| バイナリスキャン | リンクされた暗号ライブラリ、暗号関数 | クラウド側や外部機器で行われる処理 |
| TLS・証明書スキャン | 公開エンドポイントの証明書、TLS設定 | 内部通信、バックアップ、署名処理、鍵ラッピング |
| クラウド資産スキャン | KMS、証明書、ロードバランサー、暗号化設定 | アプリケーション上の利用目的やデータ保存期間 |
| HSM・KMS台帳 | 登録されている鍵、鍵種別、期限 | その鍵を使用するすべてのアプリケーションやデータフロー |
| 実行時監視 | 実際に使われたAPIやプロトコル | 利用頻度が低い処理、災害復旧時だけ使う処理 |
| 脅威モデリング | データフロー、信頼境界、保護目的、設計上の依存 | 実装バージョンなど、技術的な実測が必要な情報 |
Microsoftが指摘している重要な点は、自動検出ではアーキテクチャ上の前提、プラットフォームから提供される機能、間接依存、設計レベルのセキュリティ制御を完全には発見できないことです。そこで、自動スキャンの結果を脅威モデルに重ね、設計者や運用担当者への確認によって不足を埋めます。(TECHCOMMUNITY.MICROSOFT.COM)
脅威モデリングからPQC暗号資産台帳を作る手順
対象システムの範囲を決める
最初から全社システムを一度に棚卸ししようとすると、対象が広すぎて台帳が更新されないまま終わりやすくなります。
最初の対象には、次のようなシステムが適しています。
- 機密データを長期間保存するシステム
- インターネットや取引先との通信が多いシステム
- PKIや認証の基盤となるシステム
- コード署名やファームウェア署名を行うシステム
- HSMや専用機器を利用しているシステム
- 更新頻度が低く、置き換えに長い準備が必要なシステム
システム単位だけでなく、共通認証基盤、証明書基盤、APIゲートウェイ、署名サービスなど、複数システムが依存する基盤も対象にします。
データフロー図を作成する
対象システムについて、次の要素をデータフロー図に記載します。
- プロセス
- データストア
- 外部エンティティ
- データフロー
- 信頼境界
Microsoft Learnでも、データフロー図はシステムの構成要素、相互作用、背景情報を表し、信頼境界は信頼ゾーンが変わる場所として扱われています。(Microsoft Learn)
PQC台帳を作る場合は、一般的なデータフロー図に次の情報を追記するとレビューしやすくなります。
- 暗号化される区間
- TLSやVPNの終端点
- 署名と検証を行う場所
- 鍵を生成・保管する場所
- 証明書の発行元
- バックアップやアーカイブへの分岐
- クラウド事業者や取引先との責任分界点
自動検出の結果をデータフロー図に重ねる
次の情報を集め、該当するプロセスやデータフローに関連付けます。
- ソースコードと設定ファイルの検索結果
- SBOMや依存関係一覧
- TLSスキャン結果
- 証明書ストアの一覧
- KMSやHSMの鍵一覧
- クラウド構成情報
- ネットワークキャプチャ
- 実行時ログ
- ベンダーの製品仕様書
- 運用手順書
自動検出で見つかったライブラリ名だけを台帳に転記するのではなく、「そのライブラリを、どのデータフローが、何の目的で使っているか」まで関連付けることが重要です。
設計者・運用者への質問で不足を補う
自動検出結果を確認した後、開発者、アーキテクト、インフラ担当者、ネットワーク担当者、PKI担当者、サービス管理者に質問します。
回答が「クラウドの標準機能」「OSに任せている」「製品内部なので不明」で終わった項目は、未確認として残します。推測で安全と判定してはいけません。
証跡と責任者を登録する
すべての台帳行には、確認根拠と責任者を設定します。
証跡には、次のようなものを使用できます。
- 実行時に取得した暗号ネゴシエーション結果
- 証明書や公開鍵の実データ
- HSMやKMSの鍵属性
- ソースコードの該当箇所
- 設定ファイル
- パッケージマニフェスト
- クラウド管理画面の設定
- ベンダー公式文書
- 設計レビューの記録
責任者が決まっていない暗号利用は、移行計画を実行できません。「システム管理者」ではなく、設定変更やベンダー調整を実際に進められる担当組織まで登録します。
PQC移行の暗号資産台帳を脅威モデリングで補完する質問リスト
保護対象と保存期間を確認する質問
| 質問 | 台帳へ記録する内容 |
|---|---|
| 何を保護するために暗号を使っているか | 個人情報、認証情報、機密文書、ソフトウェア、通信など |
| 必要なセキュリティ特性は何か | 機密性、完全性、真正性、否認防止 |
| データはいつまで機密である必要があるか | 機密保持期限 |
| システム上ではいつまで保存されるか | 保存期間、バックアップ期間、アーカイブ期間 |
| 署名はいつまで検証できる必要があるか | 文書、証明書、コード、ファームウェアの信頼寿命 |
| 暗号化データの複製は存在するか | バックアップ、ログ、レプリカ、エクスポート |
| 通信内容を第三者が記録できる区間か | インターネット、取引先回線、共有ネットワーク |
| 削除後も別システムにデータが残るか | データレイク、監査基盤、災害復旧環境 |
PQCの優先順位では、単なる保存期間だけでなく「機密性が必要な期間」を確認します。保存期間が10年でも、公開後に機密性が不要になるデータと、数十年間機密である必要があるデータでは、リスクが異なるためです。
署名についても同様です。証明書の有効期間が短くても、署名済みソフトウェアや文書を長期間検証する必要がある場合、信頼の寿命は証明書の有効期間だけでは判断できません。
アルゴリズムとパラメータを確認する質問
| 質問 | 台帳へ記録する内容 |
|---|---|
| 実行時に使われるアルゴリズムは何か | RSA、ECDH、ECDSA、AES、ML-KEM、ML-DSAなど |
| 鍵長、曲線、パラメーターセットは何か | RSA-2048、P-256、ML-KEM-768など |
| 使用するハッシュやパディングは何か | SHA-256、RSA-PSS、RSA-OAEPなど |
| アルゴリズムは固定か、ネゴシエーションされるか | 優先順位、許可リスト、フォールバック |
| 古いアルゴリズムへ戻る可能性があるか | 互換モード、旧クライアント、障害時設定 |
| 暗号化と鍵保護で異なるアルゴリズムを使っているか | データ暗号化鍵と鍵ラッピング鍵 |
| 署名鍵と証明書チェーンで異なるアルゴリズムを使っているか | ルートCA、中間CA、利用者証明書 |
| 複合方式やハイブリッド方式を使用しているか | 従来暗号とPQCの組み合わせ |
「鍵長」だけを記録するのは不十分です。RSA、ECC、PQCでは、数値の意味や比較方法が異なります。Microsoftの.NET実装でも、PQCでは従来の共通的なKeySize表現が適さず、アルゴリズム固有のパラメーターセットを扱う設計になっています。(Microsoft Developer Blogs)
したがって、台帳には「鍵長」だけでなく、アルゴリズム名、曲線名、パラメーターセット、用途を組み合わせて記録します。
プロトコルと信頼境界を確認する質問
| 質問 | 台帳へ記録する内容 |
|---|---|
| どのプロトコルで暗号が使われるか | TLS、SSH、IPsec、JWT、S/MIME、X.509など |
| プロトコルのバージョンは何か | TLS 1.2、TLS 1.3など |
| 暗号化はどこで開始し、どこで終了するか | クライアント、プロキシ、ロードバランサー、API |
| TLS終端後の内部通信は再暗号化されるか | 内部経路の暗号方式と証明書 |
| どの信頼境界を越えるか | インターネット、クラウド境界、部署間、取引先 |
| 中継装置で復号・検査・再暗号化されるか | WAF、プロキシ、DLP、APIゲートウェイ |
| 通信相手も自組織で更新できるか | 外部顧客、取引先、古い端末、組み込み機器 |
| オフライン転送やキューイングはあるか | ファイル連携、メッセージキュー、バッチ処理 |
典型的な見落としは、「外部TLSは確認したが、終端後の内部通信を確認していない」というケースです。外部と内部で別の証明書、別のライブラリ、別のプロトコルが使われている場合、それぞれを別の暗号利用として登録します。
鍵ライフサイクルを確認する質問
| 質問 | 台帳へ記録する内容 |
|---|---|
| 鍵はどこで生成されるか | アプリケーション、OS、KMS、HSM、TPM |
| 誰が鍵を生成・承認できるか | 管理者、サービスアカウント、承認者 |
| 鍵はどこに保存されるか | ファイル、証明書ストア、CNG KSP、HSMなど |
| 秘密鍵をエクスポートできるか | エクスポート可否、バックアップ方法 |
| 鍵はどの程度の頻度で更新されるか | ローテーション周期 |
| 失効や侵害時にどのように交換するか | 緊急ローテーション、CRL、OCSP |
| 古い鍵はいつまで保持されるか | 復号用、検証用、監査用の保管期間 |
| 鍵を最終的にどう破棄するか | 論理削除、暗号消去、HSM内破棄 |
| ルート鍵や信頼アンカーの寿命はどれくらいか | CA、コード署名、ファームウェア署名 |
| 災害復旧環境にも同じ鍵が存在するか | レプリケーション、バックアップ、鍵エスクロー |
PQC移行では、アルゴリズムだけでなく、鍵を生成・保存するプロバイダーの対応状況が重要です。たとえばMicrosoftのAD CSにおけるPQC対応ではCNGキー記憶域プロバイダーが必要とされ、従来のCSPは対象外です。また、サーバーとクライアントの対応状況も要件に含まれます。(Microsoft Learn)
OSがPQC APIに対応していても、接続されたHSM、TPM、スマートカード、証明書利用アプリケーションまで同時に対応するとは限りません。台帳にはプロバイダー名、ハードウェア型番、ファームウェア、ドライバー、クライアント要件を記録します。
実装と依存関係を確認する質問
| 質問 | 台帳へ記録する内容 |
|---|---|
| どのAPIやライブラリが暗号を提供しているか | CNG、SymCrypt、OpenSSL、外部SDKなど |
| ライブラリやOSのバージョンは何か | パッケージ、ビルド、OS、コンテナイメージ |
| アプリケーションから直接呼び出しているか | 直接依存、フレームワーク経由、間接依存 |
| 暗号処理はクラウド側で行われるか | KMS、ロードバランサー、マネージドサービス |
| 独自実装や改変版を使っているか | 自作コード、フォーク、独自プロバイダー |
| アルゴリズム名がコードに固定されているか | ハードコード、設定変更可否 |
| 鍵や署名の形式が独自仕様か | 独自バイナリ、DB列、トークン形式 |
| ベンダー製品の暗号仕様を確認できるか | 公式仕様、サポート回答、ロードマップ |
| 暗号を交換できる抽象化層があるか | 暗号アジリティ、プロバイダー切り替え |
| 実行環境ごとに実装が異なるか | Windows、Linux、コンテナ、オンプレミス |
同じ.NETアプリケーションでも、WindowsではCNG、LinuxではOpenSSLなど、実行プラットフォームによって実装経路が異なることがあります。そのため、「アプリケーション名とアルゴリズム名」だけでなく、環境ごとのプロバイダーまで追跡します。
移行可能性と制約を確認する質問
| 質問 | 台帳へ記録する内容 |
|---|---|
| 現在の実装でPQCを利用できるか | 対応済み、予定あり、未定、非対応 |
| 純粋PQCとハイブリッド方式のどちらが可能か | 対応方式 |
| 通信相手や検証側も対応できるか | 相互運用性 |
| 鍵、署名、証明書のサイズ増加に耐えられるか | バッファ、DB列、トークン、MTU、帯域 |
| 処理時間やメモリ増加を許容できるか | 性能要件、同時処理数 |
| HSMやTPMを更新できるか | ファームウェア、機器交換、調達期間 |
| 組み込み機器を遠隔更新できるか | 更新機構、物理交換の必要性 |
| 証明書チェーン全体を更新できるか | CA、OCSP、登録サービス、利用者側 |
| 既存形式との後方互換性が必要か | 旧クライアント、長期保存データ |
| 問題発生時に戻せるか | ロールバック、二重運用、鍵の保持 |
| ベンダーの対応予定は確認済みか | 対応時期、サポート期限、契約条件 |
| 移行の責任者と意思決定者は誰か | 担当組織、サービスオーナー |
PQCでは、公開鍵、署名、証明書などが従来方式より大きくなる場合があります。MicrosoftのAD CS文書でも、従来方式とPQCを組み合わせた複合証明書は、純粋なPQC証明書や従来証明書より大きく、検証側も複合形式と両アルゴリズムを理解する必要があると説明されています。(Microsoft Learn)
したがって、アルゴリズムの対応有無だけでなく、データ形式、通信サイズ、HSM容量、証明書登録、検証アプリケーションまで検証対象にします。
PQC暗号資産台帳のテンプレート
実務では、次の項目を基本テンプレートとして使用できます。
| 項目 | 記録内容 |
|---|---|
| 台帳ID | 一意の識別子 |
| システム・サービス名 | 対象となる業務システムや共通基盤 |
| 環境 | 本番、検証、開発、災害復旧 |
| 暗号利用箇所 | コンポーネント、データフロー、データストア |
| 保護対象 | データ、通信、ID、ソフトウェア、鍵 |
| 保護目的 | 機密性、完全性、真正性、否認防止 |
| アルゴリズム | RSA、ECDSA、AES、ML-KEMなど |
| パラメータ | 鍵長、曲線、パラメーターセット、ハッシュ |
| プロトコル | TLS、SSH、JWT、X.509など |
| 実装・プロバイダー | CNG、SymCrypt、OpenSSL、クラウドKMSなど |
| ライブラリ・製品バージョン | OS、パッケージ、ファームウェア |
| 鍵保管場所 | HSM、TPM、証明書ストア、KMS、ファイル |
| 鍵ライフサイクル | 生成、配布、更新、失効、破棄 |
| 信頼境界 | インターネット、クラウド、取引先、管理境界 |
| データ保存期間 | システム上の保持期間 |
| 機密保持・信頼期間 | 機密性や署名検証が必要な期間 |
| 依存関係 | 外部ライブラリ、サービス、機器、取引先 |
| ハードウェア制約 | HSM、TPM、スマートカード、組み込み機器 |
| PQC対応状況 | 対応済み、対応予定、未確認、非対応 |
| 移行候補 | ML-KEM、ML-DSA、ハイブリッド方式など |
| 移行制約 | 互換性、性能、サイズ、調達、停止時間 |
| 責任者 | システム、暗号設定、ベンダー調整の担当者 |
| 証跡 | 設定、ログ、コード、文書、ヒアリング記録 |
| 確認日 | 最終確認日 |
| 確信度 | 実測済み、設定確認済み、文書のみ、未確認 |
| 優先度 | P1、P2、P3、監視 |
| 対応状況 | 未着手、調査中、検証中、移行中、完了 |
台帳の記入例
| 用途・データフロー | 現行方式 | 実装・保管場所 | 見落としやすい点 | 移行時の確認 |
|---|---|---|---|---|
| インターネット利用者からAPIゲートウェイ | TLS、ECDH、RSAまたはECDSA証明書 | クラウドのロードバランサー、管理HSM | TLS終端後の内部経路が別方式 | クラウド側のPQC対応、クライアント互換性、内部TLS |
| ソフトウェアのコード署名 | RSA署名 | オンプレミスHSM | 証明書期限より署名済み製品の寿命が長い | 検証環境、信頼チェーン、HSM対応、長期検証 |
| データベースの保存時暗号化 | AES-256 | DB機能とKMS | AES鍵をRSA鍵でラップしている可能性 | ラッピング鍵の移行、既存データ鍵の再ラップ |
| JWTアクセストークン | RS256 | ID基盤、証明書ストア | 発行側だけでなく全APIが検証側になる | 全検証者の対応、トークンサイズ、段階移行 |
| 機器のファームウェア署名 | ECDSA | TPMまたは専用署名装置 | 現地機器が新方式を検証できない | 遠隔更新機能、ブートローダー、機器交換計画 |
特に重要なのが、暗号の入れ子構造です。
データ本体がAES-256で暗号化されていても、そのAES鍵をRSA公開鍵で保護している場合、PQC移行の対象となる非対称暗号が残っています。「保存時暗号化はAESなので問題なし」と判断せず、データ暗号化鍵をどの方式で保護しているかまで追跡します。
証跡の確信度を台帳に付ける
同じ台帳項目でも、確認方法によって信頼性が異なります。確認状態を明確にするため、確信度を付けておくと再調査しやすくなります。
| 確信度 | 根拠 | 扱い |
|---|---|---|
| A | 実行時ログ、実証明書、実鍵属性、通信キャプチャ | 確認済み |
| B | 本番設定、ソースコード、依存関係、クラウド構成 | 原則確認済み |
| C | ベンダー文書、設計書、担当者へのヒアリング | 追加検証が望ましい |
| U | 根拠なし、不明、推測 | 未確認として調査対象にする |
ベンダー資料に「強力な暗号化」と書かれているだけでは、アルゴリズム、鍵長、プロトコル、鍵管理方式を特定できません。この場合は確認済みにせず、確信度UまたはCとして管理します。
空欄も避けるべきです。空欄では「該当なし」と「未調査」を区別できないため、次のように明示します。
- 該当なし
- 未確認
- ベンダー回答待ち
- 実測予定
- 設計書のみ確認
- 本番設定確認済み
PQC移行の優先順位を決める判断基準
すべての暗号利用を同時に移行する必要はありません。次の5つの観点で優先順位を付けます。
| 判断軸 | 優先度が高くなる条件 |
|---|---|
| 量子脆弱性 | RSA、ECDH、ECDSAなどの公開鍵暗号に依存している |
| 時間的な重なり | データの機密保持期間や署名の信頼期間が長い |
| 外部露出 | インターネットや第三者管理ネットワークを通る |
| 影響度 | 認証、署名、機密情報、全社共通基盤に関係する |
| 移行リードタイム | HSM交換、機器更新、取引先調整などに時間がかかる |
P1：最優先で調査・検証する
次の条件に該当する暗号利用です。
- 長期間機密であるデータを外部ネットワーク経由で送信する
- ルートCA、コード署名、ファームウェア署名など信頼寿命が長い
- 多数のシステムが依存する認証・PKI基盤
- 更新できない機器や専用HSMに依存する
- ベンダーのPQC対応時期が不明
- 移行に複数組織や取引先との調整が必要
P2：計画的に移行する
量子脆弱な公開鍵暗号を利用しているものの、データ寿命が短い、閉じたネットワーク内にある、比較的容易に更新できるなど、緊急性を下げられるものです。
ただし、内部ネットワークだから安全と決めつけず、バックアップ、ログ、レプリカ、管理経路まで確認します。
P3：依存関係を監視する
直接の量子脆弱性が低くても、次のような間接依存があるものです。
- AES鍵をRSAでラップしている
- SHA-256を使う署名処理の署名鍵がRSAである
- クラウドサービスの内部実装が不明
- 対応ライブラリはあるがHSMが未対応
- 本番環境の実際のアルゴリズムが確認できていない
「不明」は低優先度ではありません。少なくとも調査優先度を設定し、確認期限と担当者を付けます。
監視対象
十分な強度を持つ共通鍵暗号やハッシュを使用し、量子脆弱な鍵ラッピングや署名への依存がなく、設定と実行状態を確認できているものです。
ただし、ライブラリ、プロトコル、鍵管理方式、ベンダー仕様は変化します。台帳から削除するのではなく、監視対象として残します。
暗号資産台帳作成で失敗しやすいポイント
製品名だけを記録する
「Azure」「OpenSSL」「Windows標準」とだけ記録しても、移行判断には使えません。
最低でも、用途、アルゴリズム、プロトコル、実装バージョン、鍵保管場所、責任者を記録します。
インストール済みライブラリを利用中と判定する
OpenSSLが含まれているからといって、対象機能がそのOpenSSLを使っているとは限りません。反対に、ソースコードにOpenSSLの呼び出しがなくても、フレームワークやプロキシが内部で使用していることがあります。
依存関係の存在と、実際の暗号利用を分けて管理します。
公開TLSだけを調査する
TLSスキャンで確認できるのは、主に公開エンドポイントです。内部TLS、VPN、SSH、データベース接続、メッセージキュー、バックアップ、署名処理は別途調査します。
共通鍵暗号だけを見て安全と判断する
AESで暗号化されたデータでも、その鍵をRSAで保護している場合があります。データ暗号化と鍵保護を別の台帳行として管理し、関連IDで結び付けます。
証明書の有効期限だけで信頼期間を判断する
コード署名、電子文書、ファームウェア、ルートCAでは、署名や信頼が必要な期間が証明書の有効期限を超えることがあります。
証明書期限と、成果物の検証が必要な期間を分けて記録します。
クラウドサービスは事業者任せと考える
クラウド事業者が基盤を更新しても、利用者側でプロトコルの有効化、証明書の再発行、クライアント更新、互換性試験が必要になる場合があります。
責任共有モデルに沿って、事業者側と利用者側の対応を分けて記録します。
台帳を一度作って終わりにする
暗号利用は、OS更新、ライブラリ更新、証明書更新、クラウド構成変更、ベンダー製品の更新によって変化します。
一度作成したExcelを保管するだけでは、数か月後に実態と一致しなくなります。
PQC暗号資産台帳を継続的に更新する仕組み
台帳を維持するには、セキュリティ部門だけで管理するのではなく、既存の開発・運用プロセスに組み込みます。
更新の契機には、次の変更を含めます。
- 新しいシステムやサービスの導入
- 暗号ライブラリの追加・更新
- OSやコンテナイメージの更新
- TLSやVPN設定の変更
- 証明書テンプレートやCA構成の変更
- KMS、HSM、TPMの変更
- クラウドのロードバランサーやゲートウェイ変更
- データ保存期間の変更
- ベンダー製品のメジャーアップデート
- コード署名やファームウェア署名方式の変更
- 取引先との接続方式の変更
脅威モデリングやアーキテクチャレビューのテンプレートにも、次の確認欄を追加します。
- 新しい暗号利用を追加したか
- 既存のアルゴリズムや鍵長を変更したか
- 新しい信頼境界を越えるか
- データ保存期間や信頼期間が変わったか
- 新しい外部ライブラリやクラウドサービスに依存するか
- PQC移行を困難にする固定仕様を追加していないか
- 暗号方式を設定で変更できるか
台帳IDを設計書、チケット、プルリクエスト、証明書申請、HSM鍵申請などに記載すると、変更履歴を追跡しやすくなります。
まず重要システム1つから台帳を作り始める
PQC移行で必要なのは、最初から完全な全社台帳を作ることではありません。重要システムを1つ選び、次の順番で暗号利用を可視化することが現実的です。
- 対象システムのデータフロー図を作る
- 信頼境界と暗号化区間を記入する
- ソース、依存関係、証明書、KMS、HSMを自動調査する
- 質問リストを使って設計・運用上の不足を補う
- 暗号利用ごとに台帳行を分ける
- 証跡、確信度、責任者を登録する
- データ寿命、露出度、影響度、移行難易度から優先順位を付ける
- 未確認事項を調査タスクとして管理する
PQC暗号資産台帳の価値は、暗号アルゴリズムの一覧を作ることではありません。どのデータフローが、どの信頼境界で、どの実装と鍵に依存し、いつまで保護され、誰が移行できるのかを明確にすることにあります。
自動スキャンを出発点とし、脅威モデリングで設計上の暗号利用と間接依存を補完してください。その結果を継続的な台帳として管理することで、PQC移行を「将来の暗号更新」ではなく、具体的なシステム改修計画へ変えられます。
コメント