GMOコネクトでCTOしている暗号おじさんこと菅野（かんの）です。
先日、第1回を公開したのですが、3連休は仕事三昧だったので気晴らしに記事を書いています。
前回の記事はこちら↓
はじめに
第1回では、量子計算機がクラウド環境に与える脅威の全体像を解説しました。「15年以内に現実的な脅威となる」という事実は理解できても、「では明日から何をすべきか」という具体的なアクションに落とし込むのは容易ではありません。
第2回では、論文が提唱するNIST Special Publication 800-30 Revision 1に準拠したリスク評価フレームワークを実務者向けに解説します。特に重要なCryptographic Inventory（暗号資産の棚卸し） の実施について、論文の意図を踏まえながら実務的な手順を例示します。
NIST SP 800-30準拠のリスク評価プロセス
論文では、NISTが定めた「NIST Special Publication 800-30 Revision 1: Guide for Conducting Risk Assessments」（以降、NIST SP 800-30と表記）に準拠した体系的なリスク評価手法をCRQCが発現した際の脅威に適用しています。以下の4つのフェーズで構成されます：
┌─────────────────────────────────────────────┐
│ Phase 1: 準備（Preparation） │
├─────────────────────────────────────────────┤
│ ・評価の目的とスコープの定義 │
│ ・脅威モデルの構築 │
│ ・評価基準の設定（15年タイムライン） │
└─────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────┐
│ Phase 2: 実施（Conduct Assessment） │
├─────────────────────────────────────────────┤
│ Task 1: 脅威源とイベントの特定 │
│ Task 2: 脆弱性と前提条件の特定 │
│ Task 3: 発生可能性（Likelihood）の決定 │
│ Task 4: 影響度（Impact）の決定 │
│ Task 5: リスクの評価 │
└─────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────┐
│ Phase 3: コミュニケーション │
├─────────────────────────────────────────────┤
│ ・評価結果の共有 │
│ ・ステークホルダーへの報告 │
└─────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────┐
│ Phase 4: 維持（Maintenance） │
├─────────────────────────────────────────────┤
│ ・継続的なモニタリング │
│ ・定期的な再評価 │
└─────────────────────────────────────────────┘
STRIDEモデルにおける量子時代の脅威への適用
STRIDEとは
STRIDEは、Microsoftが開発した脅威分類モデルです。6つのカテゴリで脅威を体系的に整理します：
| STRIDE | 脅威の種類 | 説明 |
|---|---|---|
| Spoofing | なりすまし | 偽の認証情報で正規ユーザーになりすます |
| Tampering | 改ざん | データやコードを不正に変更する |
| Repudiation | 否認 | 実行した操作を否定する |
| Information Disclosure | 情報漏洩 | 機密情報が権限のない者に開示される |
| Denial of Service | サービス拒否 | システムやサービスを使用不能にする |
| Elevation of Privilege | 権限昇格 | より高い権限を不正に取得する |
参考文献：
Kohnfelder, L. & Garg, P. (1999). The STRIDE Threat Model. Microsoft Internal Memo.
Microsoft Learn: Threat modeling fundamentals
Likelihood（発生可能性）の評価
ここで扱う「量子能力が到達すれば悪用容易」とは、**CRQC（Cryptographically Relevant Quantum Computer：暗号に影響を与える規模の量子計算機）**が登場した場合を想定しています。
すなわち、「いまは安全でも、CRQCが出現した瞬間に破られるリスクが高い」状態を指します。
論文では、3段階のLikelihoodを定義しています（Table IV参照）。
High（高）
条件：
- RSA/ECCなど量子耐性のない暗号を使用している
- PQC対策が未導入
- インターネットなど外部から直接アクセス可能なシステム
- 大規模量子計算機が登場すれば短期間で解読可能
具体例：
- RSA-1024やECC-256を使用している公開APIエンドポイント
- 10年以上のライフサイクルを持つRoot CA証明書（RSA-2048）
- ハイブリッドPQCが未導入の重要インフラ
Medium（中）
条件：
- 既知の脆弱性やレガシー構成が一部残存
- 一部でハイブリッドPQCが導入され、限定的防御が成立
- 内部ネットワークやアクセス制御により部分的に隔離
Low（低）
条件：
- 全面PQC移行済み（ML-KEM, ML-DSAなど）
- AES-256, SHA3-512を採用
- エアギャップやゼロトラスト運用が確立
Impact（影響度）の評価
論文では、3段階のImpactを定義しています（Table V参照）。
High（高）
条件：
- PKI破壊や暗号鍵漏洩などによる重大な機密性・完全性の喪失
- サービス停止、評判・財務損失、法的影響を伴う
Medium（中）
条件：
- 部分的な侵害や一時停止
- 復旧可能なデータ流出、限定的な規制対応
Low（低）
条件：
- 限定的な影響、短期間で復旧可能
- 内部テスト環境など限定範囲内
Cryptographic Inventory（暗号資産の棚卸し）
論文における位置づけ
論文では、Cryptographic Inventory（暗号資産の棚卸し）の必要性と、CBOM（Cryptographic Bill of Materials）およびKBOM（Key Bill of Materials）を用いた準備度評価の枠組みを提唱しています：
“Beyond cryptographic inventory, operators need threat models coupling harvest-now–decrypt-later exposure with migration lead times...”
“We advocate measurable readiness programs that combine CBOM/KBOM coverage…”
— Baseri, Hafid & Lashkari (2025)
ただし、困ったことに論文中ではCryptographic Inventoryをどのように実施するか（手順やツール、項目など）は具体的に示されていないので、実務においては、組織ごとの環境やシステム構成に応じて具体的な手順を検討・設計する必要がありますわ。
実務における例示的手順
以下は、論文の提唱内容をベースに、NIST SP 800-30のリスク評価プロセスと統合した実務的な実施例で、これは論文の直接的記述ではなく、ワイによる例示的な実務手順として叩き台としての例示となります。
Step 1: スコープの定義
スコープ定義チェックリスト：
□ 対象システム・サービスの範囲
├─ 本番環境のみ？開発・ステージング環境も含む？
├─ オンプレミス、クラウド、ハイブリッド？
└─ サードパーティSaaSサービスは含む？
□ 対象となる暗号資産の種類
├─ 暗号化アルゴリズム（対称鍵、公開鍵）
├─ デジタル署名
├─ ハッシュ関数
├─ 鍵管理システム（KMS, HSM）
├─ 証明書（TLS/SSL, コードサイニング）
└─ 暗号プロトコル（TLS, SSH, VPNなど）
□ データの機密性レベル
├─ Public（公開データ）
├─ Internal（社内データ）
├─ Confidential（機密データ）
└─ Highly Confidential（高機密データ）
□ データの保持期間
├─ 短期（1年未満）
├─ 中期（1-5年）
├─ 長期（5-10年）
└─ 超長期（10年以上）← HNDL攻撃の最優先対象
Step 2: 自動検出ツールの活用
手動での棚卸しは現実的ではありません。以下のツールカテゴリを活用します：
A. ネットワークスキャナー
nmap --script ssl-enum-ciphers -p 443 example.com
B. コード静的解析ツール
# Pythonコード内の暗号ライブラリ検出例
import ast
import os
C. 証明書管理ツール
openssl s_client -connect example.com:443 -showcerts | \
openssl x509 -noout -text | grep -E "Signature Algorithm|Not After"
D. クラウド事業者の提供ツール
| CSP | ツール | 機能 |
|---|---|---|
| AWS | AWS Config, Security Hub | 暗号設定の監査・検出 |
| Azure | Azure Security Center | 暗号化状態の可視化 |
| GCP | Security Command Center | 暗号資産の一覧化 |
了解しました。
こちらが後半部分（Step 3〜次回予告・参考文献まで）です。
前半とつなげるとそのままQiita等で掲載できる完全修正版になります。
Step 3: 暗号資産台帳の作成（CBOM/KBOM）
暗号資産の可視化ができたら、それを構造化して管理する必要があります。
このとき有効なのが、論文でも触れられている CBOM (Cryptographic Bill of Materials) と KBOM (Key Bill of Materials) の考え方です。
| 項目 | 内容 |
|---|---|
| システム名 | 対象アプリケーション、APIなど |
| アルゴリズム | RSA-2048, ECDSA-P256, AES-128 など |
| 用途 | 通信暗号化、署名、ハッシュ |
| 鍵長 | 2048bit, 256bit など |
| 実装ライブラリ | OpenSSL, BoringSSL, crypto++ など |
| 証明書有効期限 | 例：2032/12/31 |
| PQC対応有無 | ○ / × |
| リスクレベル | High / Medium / Low |
| 移行候補 | ML-KEM, ML-DSA, SLH-DSA, etc. |
これをスプレッドシートや構成管理DB（CMDB）で一元管理し、鍵（KBOM） と アルゴリズム構成（CBOM） を明示的に紐付けることで「どのシステムがどの鍵を使っているか」が追跡可能になりますね！
Step 4: リスクスコアリング
次に、検出した各暗号資産についてリスクを数値化します。台帳を作っても優先度が決められないと対応することができないので何かしらスコアリングしてあげることで整理するといいことがあると思います。
ここでは、論文のモデルに従い、Risk = Likelihood × Impact で算出します。
| 評価項目 | 説明 | 重み例 |
|---|---|---|
| アルゴリズム脆弱性 | Shor攻撃に対する脆弱性 | 0.4 |
| 可視性・露出 | インターネット公開/内部利用 | 0.2 |
| 鍵管理レベル | HSM・KMS使用有無 | 0.2 |
| データ保持期間 | 5年以上の保持対象は高リスク | 0.2 |
例：
RSA-2048 + 公開API + 内部KMS + 保持10年
= (1.0 × 0.4) + (1.0 × 0.2) + (0.5 × 0.2) + (1.0 × 0.2)
= 0.9 → High
このように、システム単位・鍵単位でリスクスコアを算出し、
優先的に移行すべき資産が特定できます。
Step 5: 移行計画の策定
リスク評価の結果を踏まえ、段階的に移行計画を立案します。
代表的な構成は次の3フェーズです。
| フェーズ | 対応内容 | 期間目安 |
|---|---|---|
| Phase 1: 診断・棚卸し | CBOM/KBOM整備・スコアリング | 〜6か月 |
| Phase 2: ハイブリッド導入 | PQC＋従来暗号の併用導入 | 6〜18か月 |
| Phase 3: 完全移行 | PQC単独への切替、認証基盤更新 | 18〜36か月 |
また、以下のような優先度マトリクスを用いると効果的です。
| 影響度＼発生可能性 | Low | Medium | High |
|---|---|---|---|
| Low | 監視 | 年次見直し | 対応検討 |
| Medium | 計画策定 | 早期対応 | 緊急対応 |
| High | 移行完了済み | 維持・更新 | 優先移行対象 |
Cryptographic Inventoryの継続的管理
重要なのは、一度作成したCBOM/KBOMは「棚卸しで終わり」ではなく、継続的に更新してこそ価値があります。
特にクラウド環境では、鍵や証明書の自動更新・ローテーションが頻繁に発生するため、定期監査と自動検出の併用が重要です。
継続的モニタリング例
- 四半期ごとの棚卸しレビュー
- 証明書期限監視（例：Let's Encrypt自動更新）
- 構成変更イベントをCloudTrail / Azure Monitorで検出
Python + AWS boto3の簡易スクリプト例
import boto3
client = boto3.client('acm')
certs = client.list_certificates()
for c in certs['CertificateSummaryList']:
detail = client.describe_certificate(CertificateArn=c['CertificateArn'])
print(detail['Certificate']['DomainName'], detail['Certificate']['NotAfter'])
量子計算機時代でのリスクスコアを算出
簡易的なセルフアセスメントとして、次の質問にYes/Noで答えてみることでも現状把握することができるかもしれまえん。
| 質問 | Yes | No |
|---|---|---|
| RSA-2048やECC-256をまだ使用している | □ | □ |
| PQC（例：ML-KEM/ML-DSA）の導入を検討していない | □ | □ |
| 鍵管理（KMS/HSM）が未整備 | □ | □ |
| 証明書の有効期限が2030年以降 | □ | □ |
| データ保持期間が5年以上のシステムが存在 | □ | □ |
3つ以上Yesなら「量子脅威対応の初期フェーズ」に該当し、早期にCryptographic Inventoryの実施が推奨されます。
実践例：架空企業のリスク評価
次の例は、この評価フレームワークを実際のシステムに適用した場合の流れを示すものです。
架空のクラウド事業者「株式会社ぽちょむきん」が、社内システムを自己評価したケースを考えてみます。
| 項目 | 内容 |
|---|---|
| 暗号方式 | RSA-2048（TLS通信）, ECDSA（署名） |
| 対象 | 外部APIゲートウェイ、および社内S3互換ストレージ |
| 保持データ | 顧客取引ログ、売上分析データ（保持期間：10年） |
| 評価根拠 | - RSA/ECCを使用（量子非耐性） - 外部アクセスが可能（露出度：高） - 保持期間が長期（HNDL攻撃対象） |
| 評価結果 | Likelihood = High（1.0） Impact = High（9.0） → Risk Score = 1.0 × 9.0 = 9.0（最大リスク） |
| 推奨対応 | Phase 1〜3に従い、12か月以内にハイブリッド化（ML-KEM + ECDHE）を完了 |
このように、リスクスコアを算出することで、どの資産を優先的に移行すべきかが定量的に説明可能になります。
たとえば別システムが「Likelihood: Medium × Impact: Medium = 4.0」なら、移行優先度はこのAPIゲートウェイより低くなる、という判断が可能です。
例として、ぽちょむきん社では外部APIにRSA-2048を使用しており、外部からの通信経路がCRQCの脅威にさらされる状態であり、評価の結果、LikelihoodとImpactともにHigh（=9.0）と判定され、最優先でハイブリッドTLS（ML-KEM + ECDHE）への移行を進めることとなります！
まとめ
第2回では、実務者向けの量子計算機時代のクラウドセキュリティに対するリスク評価フレームワークを解説しました。重要なポイントを列挙しておきますね！！
重要なポイント：
- 論文はCryptographic Inventoryの必要性を提唱しているが、手順は明示していない
- 実務者はNIST SP 800-30などのフレームワークを参考に、具体的手順を設計する必要がある
- STRIDEモデルで脅威を体系化し、Likelihood × Impactでリスクを定量評価をする
- Cryptographic Inventoryを通じて優先度を決定し、段階的移行を実現する
- CRQC出現を前提とした15年タイムラインが評価基準である
次回予告
第3回では、移行戦略 - ハイブリッドアプローチの実装を解説する予定です！ 皆さんのいいね！が元気をくれます。（いいねがなくても頑張って記事は公開しますｗ）
- PQ/T ハイブリッド構成（KEM/署名の組み合わせ方）
- 証明書レベルの現況（Dual Certificate vs Composite Certificate）
- プロトコルレベルの移行（TLS, SSH, VPNの実装例）
- 段階的移行のロードマップ
- 主要クラウド事業者での実装状況比較
参考文献
-
Baseri, Y., Hafid, A., & Lashkari, A. H. (2025).
Future-Proofing Cloud Security Against Quantum Attacks: Risk, Transition, and Mitigation Strategies.
arXiv: https://arxiv.org/abs/2509.15653v2 -
NIST (2012).
Special Publication 800-30 Revision 1: Guide for Conducting Risk Assessments.
DOI: https://doi.org/10.6028/NIST.SP.800-30r1 -
Microsoft (2024).
STRIDE Threat Modeling Fundamentals.
URL: https://learn.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats -
NIST (2024).
Cybersecurity Framework 2.0.
URL: https://www.nist.gov/cyberframework
最後に、GMOコネクトでは研究開発や国際標準化に関する支援や技術検証をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。