PQCへの移行は難しそうに見えますが、課題を絞り込めば、そうではありません。

Joel Moses戦略エンジニアリング担当バイスプレジデント | F5

耐量子計算機暗号（PQC）への移行範囲をじっくり検討すると、ある結論に至るのも無理はありません。これは困難な取り組みになるでしょう。

暗号技術は、数十年にわたり企業のさまざまなテクノロジーに組み込まれてきました。Webトランザクション、ネットワーク接続、VPNトンネル、証明書、アプリケーション、インフラストラクチャ、データを保護しています。一部のシステムでは、いずれソフトウェアのアップグレードだけでは対応できなくなり、システム自体の置き換えが必要になる可能性もあります。そのため、大企業全体でのPQC移行は、複数年にわたる大規模な取り組みとなります。

しかし、エンジニアとして次に問いたいのは、問題が難しいかどうかではありません。その問題を正しく定義できているかどうかです。

すべてを一度に行う必要はありません

PQCへの対応を準備する際、組織が陥りがちな最大の過ちの1つは、保有するテクノロジー資産全体を見渡し、すべてを一度に変える必要があると判断することです。その必要はありません。

量子コンピューターによる脅威の影響は、暗号の種類によって異なります。この違いは重要です。組織はPQCへの対応を無差別な全面置き換えと捉えるのではなく、当面対処すべきリスクの範囲を絞り込めるためです。

しかし、問題の範囲を絞っても、既存の技術的負債がなくなるわけではありません。実際、PQCによって、その負債がいかに大きな影響を及ぼすようになっているかが明らかになる可能性があります。この点については、オンデマンド配信のF5 Post Mythos Security Summitでの私のセッション「PQCへの備えは今から始まる」で、より詳しく解説しています。

TLS 1.3を例に考えてみましょう。F5 Labsの2026年の調査では、上位のWebサイトの10%が依然としてTLS 1.3に対応していないことが明らかになりました。これは単なるモダナイゼーションの問題ではありません。PQC暗号はTLS 1.2ではネゴシエーションできないため、TLS 1.3はPQCへの備えに不可欠な基本要件です。そのため、依然として従来のTLSに依存している組織には、次の暗号技術への移行に着手する前に取り組むべき課題があります。

今日のモダナイゼーションの積み残しが、将来のセキュリティ上の制約になる可能性があります。

移行にかかる時間もリスクの一部

Q-Dayがいつ到来するか、より確かな見通しが立つのを待つのではなく、今、問題を絞り込むべき理由がもう1つあります。考慮すべき時間的な要素は、Q-Dayの到来時期だけではありません。

Moscaの定理は、対策のタイミングを考えるうえで役立ちます。情報の安全性を維持する必要がある期間と、量子耐性暗号への移行にかかる期間の合計を、十分に強力な量子コンピューターが現在の公開鍵暗号を脅かし得るようになるまでの残り時間と比較します。前者の合計が後者を上回る場合、その組織は問題を抱えていることになります。

このことは、PQCへの対応準備に関する考え方を変えます。移行に要する時間は、単にプロジェクト計画で考慮すべき事項ではなく、リスクの一部です。

そして、エンタープライズアーキテクチャは、その移行時間に極めて大きな影響を及ぼす可能性があります。

暗号技術と個々のアプリケーションやシステムとの結び付きが強いほど、組織が最終的に変更、テスト、検証、保守を行う必要のある箇所が増える可能性があります。さらに、レガシーインフラストラクチャやサードパーティへの依存関係が加わると、暗号技術のアップグレードに見える取り組みが、たちまち企業全体に及ぶ大規模な変革になりかねません。

そのため、組織はQ-Dayの時期が確実になるのを待たずに、アーキテクチャの見直しに取り組むべきです。量子コンピューティングがいつその境界を超えるのかを正確に把握していなくても、対応に必要な時間を短縮することの価値は明らかです。

暗号技術の変化に対応する設計

最終的な目標は、現在承認されているPQCアルゴリズムを導入するだけでなく、進化し続ける暗号要件に適応できる能力を構築することです。

私にとって、暗号アジリティとは、稼働中のシステムの動作を中断することなく、暗号アルゴリズムを置き換え、変化に適応させる能力を意味します。

テクノロジー部門のリーダーが検討すべき、有用な問いがあります。もし明日、暗号アルゴリズムの変更が必要になったら、いくつのアプリケーションに手を加える必要があるでしょうか。

その答えが数百、数千であるなら、PQCは単なる暗号技術の問題ではありません。アーキテクチャの問題です。

その問題を解決するために、アプリケーションを1つずつ手作業で書き換えていくのは、望ましい方法ではありません。大企業全体でこの方法を採用すると、時間とコストがかかり、運用に支障をきたし、インフラへの負荷が大きくなる可能性があります。

幸い、それが唯一の解決策ではありません。

今後の課題は大きいものの、実際にどこでリスクにさらされているかを特定し、どの依存関係を自ら管理できるかを把握し、暗号技術の変更が各アプリケーションチームの課題にならずに済むようにインフラを設計することで、組織はこの課題に対処しやすくなります。

サミットセッション：今から始めるPQCへの備え

オンデマンド配信のF5 Post-Mythos Security Summitでは、私のセッション「PQCへの備えは今から」で、まさにこの課題を掘り下げます。このセッションでは、現在直面しているリスクへの露出範囲を把握し、移行を統制し、現在の運用への不要な影響を避けながらインフラを保護するための、実践的な3段階のアプローチをご紹介します。ぜひご視聴ください。

著者について

Joel Moses戦略エンジニアリング担当バイスプレジデント | F5

Joel Mosesのその他のブログ記事