ポスト量子暗号への対応で最初にやるべきことは、いきなり新しい暗号アルゴリズムを選ぶことではありません。まず必要なのは、自社のどこで、どの暗号技術が、何を守っているのかを把握する cryptographic inventory、つまり暗号資産インベントリの整備です。
2026年4月17日時点の更新として注目したいのが、Microsoft Security Blog が2026年4月16日に公開した「Building your cryptographic inventory」です。Microsoft は、Cryptographic posture management をポスト量子時代への準備だけでなく、暗号運用全体を継続的に健全化するための取り組みとして位置付けています。(Microsoft)
結論から言うと、Security architects や risk leaders が今すぐ始めるべきことは、暗号の「棚卸し」「リスク評価」「優先順位付け」を一体で進めることです。暗号資産が見えていなければ、量子耐性のある方式へ移行する計画も、脆弱な証明書や古いライブラリの是正も、現実的なロードマップに落とし込めません。
Microsoft Securityが示したCryptographic posture managementの最新動向
Microsoft が今回示したポイントは明確です。Post-quantum cryptography、いわゆるポスト量子暗号への移行で難しいのは、単に新しいアルゴリズムを選ぶことではありません。企業内のアプリケーション、インフラ、デバイス、クラウドサービスのどこで暗号が使われているかを見つけることが、最初の大きな壁になります。(Microsoft)
Microsoft は、Cryptographic posture management、略して CPM を「単一製品」ではなく、継続的なライフサイクルとして説明しています。流れは大きく次の6段階です。(Microsoft)
| 段階 | 実務でやること |
|---|---|
| Discover | コード、ネットワーク、実行環境、ストレージから暗号利用のシグナルを集める |
| Normalize | 証明書、鍵、アルゴリズム、期限、所有者などを共通スキーマで整理する |
| Assess risk | 弱いアルゴリズム、期限切れ証明書、非準拠設定、脆弱な暗号ライブラリを評価する |
| Prioritize | 外部公開、重要システム、規制対象、データ機密度を基準に優先順位を付ける |
| Remediate | 鍵のローテーション、証明書更新、ライブラリ更新、プロトコル設定変更を行う |
| Continuous monitoring | 新しいデプロイ、証明書更新、設定ドリフト、脆弱性情報を継続的に追跡する |
ここで重要なのは、cryptographic inventory は一度作って終わる台帳ではないという点です。新しいアプリがリリースされ、証明書が更新され、ライブラリが差し替わり、クラウド構成も変わります。したがって、暗号資産インベントリは「静的なExcel表」ではなく、継続的に更新される運用基盤として設計する必要があります。
なぜポスト量子時代の計画前にcryptographic inventoryが必要なのか
ポスト量子暗号への関心が高まると、「RSAをやめるべきか」「ECCはいつ置き換えるのか」「PQC対応製品を導入すべきか」といった議論に進みがちです。しかし、cryptographic inventory がない状態で移行計画を立てると、対象範囲も影響範囲も分からないまま予算だけが膨らみます。
NIST は2024年8月、ポスト量子暗号に関する最初の3つのFIPS標準を承認しました。主な対象は、鍵確立のための ML-KEM、デジタル署名のための ML-DSA と SLH-DSA です。(NIST) ただし、標準が存在することと、企業が安全に移行できることは別問題です。移行対象となる暗号利用箇所を把握していなければ、どのシステムから手を付けるべきか判断できません。
特に問題になるのが、長期間価値を持つデータです。Microsoft の量子安全に関する説明でも、将来の量子コンピューターを前提に、今盗まれた暗号化データが将来も意味を持つかを考える必要があるとされています。(Microsoft Quantum) たとえば、知的財産、医療情報、政府・防衛関連データ、長期契約情報、顧客認証基盤に関わる情報は、短期的なWebセッションよりも優先度が高くなります。
暗号資産が見えていないと起きる実務上の問題
暗号資産インベントリがない企業では、次のような問題が起きやすくなります。
| よくある状況 | 実際に起きる問題 |
|---|---|
| 証明書の一覧はあるが、利用アプリや所有者が不明 | 期限切れや弱い設定を見つけても、誰が直すべきか分からない |
| TLS設定だけ確認している | ソースコード内の暗号ライブラリ、秘密鍵、APIキー、HSM利用が抜け落ちる |
| クラウド環境だけ見ている | オンプレミス、OT、IoT、レガシーアプリの暗号利用が残る |
| 脆弱性管理ツールの検出結果だけを見ている | データの重要度や外部公開状況を踏まえた優先順位が付かない |
| PQC移行を技術部門だけで進める | リスク許容度、予算、規制対応、ベンダー契約の判断が遅れる |
つまり、cryptographic inventory は単なる技術台帳ではありません。セキュリティアーキテクチャ、リスク管理、コンプライアンス、調達、アプリケーション開発をつなぐ判断材料です。
cryptographic inventoryに含めるべき項目
Microsoft は cryptographic inventory を、組織内で使われている暗号資産と暗号メカニズムの「生きたカタログ」と説明しています。対象には、証明書、鍵、プロトコル、暗号ライブラリ、コード内の暗号プリミティブ、暗号化セッション、シークレット、HSMやTPMなどが含まれます。(Microsoft)
実務では、単に「証明書一覧」を作るだけでは不十分です。少なくとも次の観点を持つと、リスク判断に使えるインベントリになります。
| 分類 | 収集したい情報 | 判断に使うポイント |
|---|---|---|
| 証明書・鍵 | 証明書名、発行元、有効期限、鍵長、アルゴリズム、秘密鍵の保管場所 | 期限切れ、弱い鍵長、所有者不明、外部公開の有無 |
| プロトコル・暗号スイート | TLS/SSL、SSH、IPsec、利用バージョン、暗号スイート | 古いプロトコル、弱い暗号スイート、外部公開エンドポイント |
| 暗号ライブラリ | OpenSSLなどのライブラリ名、バージョン、利用アプリ | 既知脆弱性、更新困難な組み込みライブラリ |
| コード内の暗号利用 | RSA、ECC、AES、ハッシュ関数、独自実装の有無 | 非推奨アルゴリズム、ハードコード、独自暗号の混入 |
| シークレット | APIキー、接続文字列、サービスプリンシパル資格情報 | リポジトリや設定ファイルへの露出、ローテーション状況 |
| HSM・TPM・Key Vault | 鍵の保管先、アクセス権、操作ログ、バックアップ | 高信頼領域の依存関係、運用者権限、監査可能性 |
| 所有者・用途 | システム名、業務オーナー、技術オーナー、保護対象データ | 是正責任、優先順位、例外承認の判断 |
ここで見落としやすいのが「所有者」と「用途」です。暗号設定そのものが分かっても、どの業務を支えているのか、停止できるのか、ベンダー管理なのかが分からなければ、移行計画は進みません。台帳には技術情報だけでなく、業務影響を判断できる情報も入れるべきです。
Microsoft Securityで始める暗号資産インベントリの作り方
Microsoft は、既存の Microsoft Security や Azure の機能を使い、コード、エンドポイント、クラウドワークロード、ネットワークから暗号関連のシグナルを集めるアプローチを示しています。具体例として、GitHub Advanced Security、Microsoft Defender Vulnerability Management、Microsoft Defender for Endpoint、Microsoft Defender for Cloud、Azure Key Vault、Azure Network Watcher などが挙げられています。(Microsoft)
実務では、次のように領域ごとに収集ポイントを分けると始めやすくなります。
| 領域 | 使える主なMicrosoft関連機能 | 初回に確認すること |
|---|---|---|
| Code | GitHub Advanced Security、CodeQL | 暗号アルゴリズムの利用箇所、暗号ライブラリ、ハードコードされた秘密情報 |
| Runtime / Storage | Microsoft Defender for Endpoint、Microsoft Defender Vulnerability Management | 端末・サーバー上の証明書、暗号ライブラリ、脆弱なコンポーネント |
| Network | Microsoft Defender for Endpoint のネットワーク検出、Azure Network Watcher、Azure Firewall | TLS/SSHなどの暗号化通信、外部公開エンドポイント、通信メタデータ |
| Cloud storage / Secrets | Azure Key Vault、Microsoft Defender for Cloud | 鍵、証明書、シークレット、クラウドリソース上に露出した秘密情報 |
| Central view | Microsoft Sentinel、既存SIEM、データ基盤 | 検出結果の正規化、検索可能な台帳、リスクスコアの集約 |
注意したいのは、どれか1つのツールだけで完全な cryptographic inventory が完成するわけではない点です。Microsoft も、CPM は単一製品ではなく、ツール、統合、プロセスを組み合わせて顧客が構築・維持するライフサイクルだと説明しています。(Microsoft)
たとえば、GitHub Advanced Security でコード上の暗号利用を検出できても、本番環境で実際にどの証明書が使われているかは別途確認が必要です。Azure Key Vault に格納された鍵を把握できても、オンプレミスのHSMやレガシーアプリ内の秘密鍵までは自動的に見えません。最初から完全性を求めるのではなく、重要領域から段階的にカバレッジを広げる設計が現実的です。
優先順位付けは「暗号の種類」だけで決めない
暗号資産インベントリを作る目的は、一覧を増やすことではありません。限られた人員と予算で、どこから直すべきかを決めることです。
優先順位付けでは、少なくとも次の5軸を使うと判断がぶれにくくなります。
| 評価軸 | 優先度が高くなる例 |
|---|---|
| 外部露出 | インターネット公開API、VPN、顧客向けWeb、パートナー接続 |
| データの寿命 | 10年以上価値を持つ機密情報、研究開発データ、医療・金融・政府関連情報 |
| システム重要度 | 認証基盤、PKI、決済、基幹業務、OT・IoT制御系 |
| 暗号上の弱さ | 古いプロトコル、弱い鍵長、期限切れ証明書、脆弱なライブラリ |
| 変更難易度 | ベンダー依存、組み込み機器、停止調整が難しいシステム、独自実装 |
ポスト量子対応の文脈では、公開鍵暗号に依存する鍵交換やデジタル署名の扱いが重要になります。一方で、AESなどの対称鍵暗号は同じ意味で単純に置き換える対象ではありません。Microsoft も、対称鍵暗号は量子安全性の観点で公開鍵暗号とは異なる扱いになると説明しています。(Microsoft Quantum)
そのため、「RSAやECCが見つかったら全部すぐ置き換える」という単純な対応は現実的ではありません。まずは、どの用途で使われているのかを確認します。たとえば、短命な内部テスト用証明書よりも、外部公開された認証基盤や長期保存データを保護する鍵交換の方が、計画上の優先度は高くなります。
最初の90日で進める実践ロードマップ
Cryptographic posture management は大規模な取り組みですが、最初から全社完全対応を目指すと止まりやすくなります。Security architects と risk leaders は、まず90日単位で成果が見える進め方に分解するとよいでしょう。
| 期間 | 目的 | 実施内容 |
|---|---|---|
| 最初の2週間 | 責任範囲を決める | セキュリティ、インフラ、アプリ、GRC、調達の責任者を決め、対象範囲を重要システムに絞る |
| 30日目まで | 初期インベントリを作る | GitHub、Defender、Key Vault、証明書管理、SIEMなどから暗号関連データを集める |
| 60日目まで | リスク評価を始める | 外部公開、データ機密度、期限切れ、弱い設定、所有者不明を基準にスコアリングする |
| 90日目まで | 是正計画に落とす | 上位リスクの修正計画、例外承認、ベンダー確認、継続監視の運用ルールを作る |
最初の対象は、全システムではなく「重要システム」「外部公開システム」「長期保護が必要なデータを扱うシステム」に絞るのが現実的です。ここで運用モデルを固めてから、オンプレミス、SaaS、OT、IoT、海外拠点、子会社へ広げていきます。
失敗しやすいポイントと回避策
暗号資産インベントリの取り組みでは、技術的な検出よりも、運用設計で失敗するケースが少なくありません。
| 失敗しやすいポイント | 回避策 |
|---|---|
| 証明書管理だけで十分だと思ってしまう | コード、ライブラリ、ネットワーク、シークレット、HSMまで対象範囲を定義する |
| 検出結果を大量に集めて終わる | 所有者、重要度、外部露出、是正期限を必ず付与する |
| すべての暗号リスクを同じ重みで扱う | データ寿命と業務重要度を加味して優先順位を付ける |
| 開発チームを後から巻き込む | コード解析やライブラリ更新が必要なため、初期段階から開発責任者を入れる |
| ベンダー製品の暗号利用を放置する | 調達・契約更新時に、PQC対応方針、暗号設定、証明書管理、ログ提供可否を確認する |
| 一度の棚卸しで完了扱いにする | CI/CD、証明書更新、クラウド変更、脆弱性情報と連動した継続監視にする |
特に避けたいのは、「PQC対応」という大きなテーマを掲げながら、実際には期限切れ証明書や古いTLS設定といった基本的な暗号衛生が放置される状態です。ポスト量子暗号への準備は重要ですが、日常的な暗号運用の改善と切り離して考えるべきではありません。
Security architectsとrisk leadersが分担すべき役割
cryptographic inventory は、セキュリティ部門だけで完結しません。アーキテクチャ、リスク、開発、インフラ、法務・コンプライアンス、調達が同じ台帳を見て意思決定する必要があります。
| 役割 | 主な責任 |
|---|---|
| Security architects | インベントリ項目、共通スキーマ、暗号ポリシー、技術的な例外基準を設計する |
| Risk leaders | リスク許容度、優先順位、予算、経営報告、規制対応の判断を行う |
| App owners | コード内の暗号利用、ライブラリ更新、アプリ改修の影響を評価する |
| Infrastructure / Network teams | TLS、SSH、VPN、証明書、HSM、ネットワーク機器の設定を管理する |
| GRC / Legal | 規制、監査、契約、データ保護要件との整合を確認する |
| Procurement / Vendor management | ベンダー製品の暗号仕様、PQC対応ロードマップ、サポート範囲を確認する |
グローバル企業では、地域ごとに規制や業界標準の要求が異なります。Microsoft は、複数国・EU・DORA・OMB M-23-02・PCI DSS 4.0などの文脈で cryptographic inventory の重要性が高まっていると説明しています。(Microsoft) そのため、単なる技術プロジェクトではなく、リスク管理プログラムとして経営層に説明できる形にしておくことが重要です。
パートナー製品を検討すべきケース
Microsoft は、CPM領域のパートナーとして Keyfactor、Forescout、Entrust、Isara などを挙げています。これらは、証明書・鍵ライフサイクル管理、ネットワーク可視化、ソフトウェアサプライチェーン、コード解析など、それぞれ異なる強みを持つとされています。(Microsoft)
パートナー製品を検討すべきなのは、次のようなケースです。
- オンプレミス、マルチクラウド、SaaS、OT、IoTが混在している
- 証明書や鍵の数が多く、手動管理では期限切れや所有者不明が頻発している
- HSM、PKI、ベンダー管理アプリが多く、標準ツールだけでは可視化が難しい
- 規制業界で、監査証跡やリスク評価レポートを継続的に出す必要がある
- ポスト量子暗号への移行ロードマップを、経営・監査・顧客に説明する必要がある
ただし、ツール導入が目的化すると失敗します。先に「何をインベントリ化するか」「どのリスクを優先するか」「誰が直すか」を決め、その上で不足する可視化や自動化を補うために製品を選ぶべきです。
まず着手すべき3つのアクション
ポスト量子時代に向けた計画を現実的に進めるなら、最初の一歩はシンプルです。
まず、重要システムに限定して cryptographic inventory の最小スキーマを決めます。証明書名やアルゴリズムだけでなく、所有者、用途、外部公開、保護対象データ、有効期限、是正期限を含めることが重要です。
次に、Microsoft Security や Azure、GitHub、既存SIEMから取得できる暗号関連データを集めます。完全性よりも、継続的に更新できる形を優先します。
最後に、リスクベースで上位20件程度の是正対象を決めます。外部公開、長期保護データ、認証基盤、期限切れ、脆弱なライブラリ、所有者不明を優先すれば、経営層にも説明しやすい計画になります。
Cryptographic posture management は、将来の量子コンピューターに備えるためだけの取り組みではありません。今日の証明書管理、鍵管理、暗号ライブラリ管理、シークレット管理を強くするための基盤でもあります。PQC移行を本気で計画するなら、最初に作るべきものは新しい暗号方式の一覧ではなく、自社の暗号利用を正確に把握する cryptographic inventory です。
コメント