ASMでTLSが見えるなら、PQC対応も判定できるのか
はじめに
ASM、すなわちAttack Surface Managementは、外部公開されている自社資産を攻撃者視点で発見し、リスクを可視化するための仕組みです。外部公開Webサイト、サブドメイン、証明書、DNS、メール設定、公開ポート、クラウド上の公開IPなどを継続的に監視するASM系ツールは増えています。UpGuardのように、攻撃面管理とサードパーティリスク管理を同じプラットフォームで扱う製品もあります。1
ここで気になるのが、PQC、すなわちポスト量子暗号への対応状況です。ASMツールがTLS設定を見られるのであれば、そのまま「PQC対応の暗号設定ができているか」を判定できるのでしょうか。
結論から言えば、部分的には可能ですが、完全な判定はできません。
ASMで見えるのは、あくまで外部公開された通信面です。PQC対応全体を見るには、外部TLSだけでなく、内部通信、アプリケーション内暗号、署名、証明書、HSM、KMS、PKI、ライブラリ、製品組込み暗号まで含めた暗号インベントリが必要になります。NIST NCCoEも、PQC移行では組織内の暗号利用を把握する暗号インベントリを重視しています。23
全体像
ASMは、PQC対応の「完了判定装置」ではありません。外部公開面を発見し、外部TLS終端で観測できる暗号設定を棚卸しし、暗号インベントリへつなぐための入口として使うのが現実的です。
TLSが見えるということ
ASMツールがTLSを検査できる場合、一般的には次のような情報を外部から確認できます。
| 外部TLSスキャンで見える主な情報 |
|---|
| TLSバージョン |
| 証明書の発行者、有効期限、SAN、鍵種別、鍵長 |
| RSA/ECDSAなどの公開鍵アルゴリズム |
| 対応している暗号スイート |
| 弱いTLS設定の有無 |
| HSTSなどのHTTPセキュリティヘッダー |
| 一部のメール/DNS関連設定 |
これらは、外部公開サービスの基本的なセキュリティ衛生状態を見るうえで有用です。
ただし、ここで見えているのは「外部クライアントから観測できるTLS終端の状態」です。CDN、WAF、ロードバランサ、リバースプロキシでTLSを終端している場合、外から見えているのはその終端装置の設定であり、必ずしもオリジンサーバや内部APIの暗号設定ではありません。
PQC対応TLSで見るべきもの
PQC対応という言葉は広く、TLSの文脈では特に鍵交換・鍵確立の部分が重要になります。
NISTは2024年8月、最初のPQC標準としてFIPS 203、FIPS 204、FIPS 205を公表しました。それぞれML-KEM、ML-DSA、SLH-DSAを扱います。このうちTLSの鍵交換・鍵確立の文脈で中心になるのは、主にML-KEMです。4
TLS 1.3では、従来のECDHEなどの鍵交換とML-KEMのようなPQC方式を組み合わせるハイブリッド鍵交換が標準化されています。IETFのRFC 9954はTLS 1.3におけるハイブリッド鍵交換の構成を定義し、個別のML-KEM系NamedGroupについては、ML-KEM単独の鍵確立ドラフトや、X25519MLKEM768、SecP256r1MLKEM768、SecP384r1MLKEM1024を定義するECDHE-MLKEMドラフトが進んでいます。2026年6月5日時点で、ECDHE-MLKEMドラフトはProposed Standardを意図したInternet-Draftで、IESG Last Call中です。567
したがって、外部TLSスキャンでPQC対応を見る場合、単純に「PQC暗号スイートがあるか」を見るのではありません。TLS 1.3の暗号スイートは鍵交換方式を含まないため、鍵交換はNamedGroupとkey_shareの交渉として見ます。確認観点は次のようになります。
| PQC対応TLSとして確認したい観点 |
|---|
| TLS 1.3に対応しているか |
| スキャナがPQC/ハイブリッド対応のClientHelloとkey_shareを送れるか |
| 複数のプローブで、サーバが交渉できるNamedGroupを推定できるか |
| ML-KEM系、またはX25519MLKEM768などのハイブリッドNamedGroupを交渉できるか |
| SNI、ALPN、ポート、IPv4/IPv6、CDN/WAF/LB終端の違いを切り分けられるか |
| 外部TLSの鍵交換と、証明書・署名・PKIのPQC対応を分けて評価できるか |
ここで注意したいのは、サーバが「自分のsupported_groups一覧」をそのまま返すわけではない点です。スキャナができるのは、さまざまなClientHelloとkey_shareを送って、どのNamedGroupが交渉できるかを推定することです。
ASM製品が「TLSを見られる」と言っていても、それが直ちに「PQC/ハイブリッド鍵交換の交渉可否まで評価できる」という意味にはなりません。多くのTLS診断は、従来型のTLS健全性チェック、つまり古いTLSバージョン、弱い暗号スイート、証明書期限、鍵長、HSTS、DNS/メール設定などを中心にしている可能性があります。
PQC対応確認を目的にASMを使うなら、PoCで次を確認すべきです。
| PoCで確認すべきこと |
|---|
| PQC/ハイブリッド対応のClientHelloを送れるか |
| TLS 1.3のNamedGroup交渉結果をプローブで推定できるか |
| ML-KEM系のNamedGroup、またはECDHE-MLKEM系のハイブリッドNamedGroupを検出できるか |
| 未対応の場合に「観測した外部TLS終端では確認できない」と表現できるか |
| CDN/WAF/LB終端とオリジン終端を識別できるか |
| 443以外のTLSサービスも対象にできるか |
| SNI、ALPN、IPv4/IPv6などの条件差を記録できるか |
ASMで「PQC未対応」と言える範囲
外部ASMで、あるFQDNに対してTLSスキャンを行い、PQC/ハイブリッド鍵交換が交渉できなかったとします。
この場合に言えるのは、次の範囲に限られます。
| 外部ASMで言えること |
|---|
| 観測した外部公開TLS終端では、PQC/ハイブリッド鍵交換を交渉できなかった |
| 少なくとも、その公開エンドポイントの外部TLS面ではPQC対応を確認できなかった |
| その結論は、スキャナが送ったClientHello、key_share、SNI、ALPN、プロトコル、ポートの範囲に依存する |
一方で、次のような断定はできません。
| 外部ASMだけでは言えないこと |
|---|
| そのシステム全体がPQC未対応である |
| その会社全体がPQC未対応である |
| 内部通信もPQC未対応である |
| アプリケーション内暗号もPQC未対応である |
| 証明書・署名・PKI・HSM・KMSまで未対応である |
逆も同じです。CDNがPQC/ハイブリッド鍵交換に対応している場合、外から見ればPQC対応に見えます。しかし、それは「外部公開TLS終端が対応している」という意味であって、オリジン、内部API、データベース、署名基盤、業務アプリ内の暗号まで対応していることを意味しません。
ASMのスキャン範囲は何で決まるのか
ASM全般で難しいのは、「自社の外部公開サービスを全量スキャンできていると言えるのか」という問題です。
外部公開サービスは、公式ドメイン配下のWebサイトだけではありません。キャンペーンサイト、旧ブランド、買収会社、委託先運用のサブドメイン、SaaS連携、クラウド上の一時公開IP、検証環境、メール系サービス、管理画面、API、CDN、WAF、ロードバランサなども存在します。
このため、単一のキーで全量を網羅することはできません。ASMの資産発見は、複数のキーを組み合わせて確度を上げるものと考えるべきです。
| ASMで使う主な探索キー |
|---|
| ルートドメイン |
| サブドメイン |
| DNSレコード |
| 証明書透明性ログ |
| WHOIS / RDAP |
| IPレンジ / ASN |
| クラウド資産 |
| CDN / WAF / ロードバランサ |
| MX / SPF / DKIM / DMARC |
| ブランド名、旧社名、買収会社名 |
| 証明書のSubject / SAN |
| HTTPタイトル、ヘッダー、リダイレクト |
| GitHub等の公開情報 |
| Shodan、Censys、検索エンジン等のOSINT |
| 委託先管理台帳 |
| SaaS台帳 |
| CMDB、システム台帳、ドメイン台帳 |
重要なのは、ASM単体で全量性を保証しようとしないことです。現実的には、次のような突合が必要になります。
| 全量性を高めるための突合 |
|---|
| 公式台帳 x ASM発見資産 |
| DNS台帳 x 外部DNS観測結果 |
| CTログ x 証明書台帳 |
| クラウド台帳 x 公開IP / LB / CDN |
| CMDB x FQDN / IP / システム名 |
| 委託先台帳 x 外部公開サービス |
| SaaS台帳 x 利用中SaaSドメイン |
| ブランド台帳 x 類似ドメイン / 旧ブランド |
この突合によって、次の2種類の差分が見えてきます。
| 差分の種類 |
|---|
| 台帳にあるがASMで見つからない資産 |
| ASMで見つかったが台帳にない資産 |
後者は特に重要です。台帳にない公開資産は、所管不明、管理漏れ、廃止漏れ、委託先運用の見落とし、クラウド上の残骸、シャドーITの可能性があります。
PQC対応で必要なのは暗号インベントリ
PQC移行で重要なのは、外部TLSだけではありません。
CISA、NIST、NSAは、PQC移行に向けて、量子レディネスのロードマップ作成、ベンダーとの対話、暗号システム・暗号資産のインベントリ作成、重要資産を優先した移行計画を推奨しています。8
NIST NCCoEのPQC移行プロジェクトも、量子脆弱な公開鍵暗号がハードウェア、ソフトウェア、サービスのどこで使われているかを理解し、ロードマップを作る必要があるとしています。また、暗号利用を把握するためのCryptographic Discoveryワークストリームを設け、暗号インベントリがリスク管理と優先順位付けを支えると説明しています。2
このことからも、PQC対応は単なるTLS設定確認ではなく、暗号利用全体の棚卸しとして捉える必要があります。実務上は、CBOM、すなわちCryptography Bill of Materials的な暗号インベントリを整備する発想が重要です。NIST NCCoEのFAQも、CBOMガイドや、TLS/SSHをスキャンするツール、暗号インベントリの構成要素を紹介しています。9103
| 暗号インベントリで持ちたい情報 |
|---|
| システム名 |
| 所管部署 |
| 所管ベンダー |
| FQDN / IP / ポート |
| 通信プロトコル |
| TLS終端位置 |
| 利用アルゴリズム |
| 鍵長 |
| 証明書種別 |
| 暗号ライブラリ |
| KMS / HSM / PKI利用有無 |
| データの機密性 |
| 長期秘匿性の要否 |
| Harvest Now, Decrypt Laterの影響 |
| ベンダーのPQCロードマップ |
| 更改時期 |
| 移行優先度 |
ASMはこのうち、外部公開面の発見と外部TLS設定の棚卸しに強みがあります。しかし、内部通信、アプリケーション内暗号、ファイル暗号、署名、鍵管理、認証基盤、製品組込み暗号、SaaS内部の暗号利用までは、ASMだけでは見えません。
実務上の整理
ASMとPQC対応の関係は、次のように整理できます。
| 仕組み | 主な役割 |
|---|---|
| ASM | 外部公開資産を発見する / 外部TLS設定を棚卸しする / 公開面のPQCまたはハイブリッド鍵交換の対応有無を観測する / 未管理資産、古いTLS設定、証明書問題を検出する |
| CMDB / システム台帳 | 正式な管理対象、所管、重要度、業務、委託先を示す |
| クラウド棚卸し | 実際に存在する公開IP、LB、CDN、API Gatewayを示す |
| DNS / CTログ | 名前と証明書発行の痕跡を示す |
| TPRM / ベンダー管理 | 委託先やSaaSの対応状況を確認する |
| 暗号インベントリ / CBOM的管理 | 組織全体の暗号利用とPQC移行対象を管理する |
したがって、ASMはPQC対応の「判定装置」ではありません。ASMは、PQC移行に向けた「外部公開面の発見装置」であり、「外部TLSの暗号インベントリ作成装置」であり、「優先順位付けの材料を作る装置」です。
まとめ
TLSが見えるASMを使えば、外部公開TLS終端の暗号設定は一定程度見えます。そのため、PQC/ハイブリッド鍵交換に対応しているかを、外部から観測できる範囲で確認することは可能です。
しかし、それはあくまで外部公開TLS終端の話であり、組織全体のPQC対応状況を示すものではありません。PQC対応を本気で進めるなら、次の順番で考えるべきです。
| PQC対応に向けた現実的な進め方 |
|---|
| 1. ASMで外部公開資産を発見する |
| 2. 外部TLS設定を棚卸しする |
| 3. PQC/ハイブリッド鍵交換の交渉可否を確認する |
| 4. CMDB、DNS、クラウド、CTログと突合する |
| 5. 台帳にない公開資産を潰す |
| 6. 内部通信、アプリ暗号、署名、PKI、KMS、HSMを棚卸しする |
| 7. 長期秘匿性が必要なデータを優先する |
| 8. ベンダーのPQCロードマップを確認する |
| 9. 暗号インベントリを継続更新する |
ASMは、PQC対応の入口として非常に有用です。ただし、ASMだけでPQC対応を完了判定するのは危険です。外部から見えるもの、内部でしか分からないもの、ベンダーに確認しなければ分からないものを分けて、暗号インベントリとして管理していくことが重要です。