みんな、お元気ですか？
GMOコネクトでCTOな菅野 哲（かんの さとる）です。
最近はIETFのミーティングやら何やらで飛び回っていて、時差ボケがデフォルト設定になりつつある今日このごろですwww
さて、いきなりですが皆さん、「暗号の2030年問題」 への備え、進んでますか？
「まだ先の話でしょ？」「偉い人がなんとかしてくれる」
……なんて思ってたら大間違い！ 量子計算機の足音はすぐそこまで迫っています。
IETFで標準化活動をしているワイとしては、仕様書やRFCを眺めているだけだとどうしてもモヤモヤしちゃうんですよね。「実際、世界はどれくらい対応できてるんや！？」と。
というわけで、「モヤったらまず動く」が信条のワイ、作っちゃいました。
世界のトップ100万ドメインを片っ端からスキャンして、PQC（耐量子計算機暗号）への移行状況を丸裸にするシステムを！
今回は、なぜワイがこの「SSL/TLS Scan Dashboard」を作ろうと思ったのか、その熱い思いとシステムの全貌を語らせてください。
この記事でわかること
- なぜ今、PQC（耐量子計算機暗号）の可視化が必要なのか
- 100万ドメインを捌くスキャンシステムの全体像
- 「Sランク」判定基準に見る、最強のセキュリティ構成とは
なぜ「可視化」が必要なのか？ 〜暗号おじさんとしての焦り〜
ワイのような「暗号おじさん」が生息する耐量子計算機暗号（PQC）やTLSの世界では、今まさに歴史的な転換点を迎えています。
実用的な量子計算機が登場すると、現在インターネットの安全を守っているRSAや楕円曲線暗号は、Shorのアルゴリズムによってあっという間に解読されてしまうと言われています。これが「2030年問題」です。
※ 厳密には「暗号の2030年問題」は2つの側面があるので、気になった人がいたら、気軽に声かけてください。
これに対抗するため、NIST（米国国立標準技術研究所）やIETFでは、量子計算機でも解けない新しい暗号（PQC）の標準化を急ピッチで進めています。
でもね、ここでワイは思ったんです。
「標準が決まっても、使われなきゃ意味なくね？」
- 実際にWebサイトの設定を変更するのは現場のエンジニア。
- サーバーのミドルウェアが対応しないと始まらない。
- そもそも、今どれくらいのサイトが準備できているのか誰も知らない。
「全世界でPQC移行が行われているのか、あるいは着手しやすいTLSの暗号移行が行われているのか」。
これを定点観測（モニタリング）できる仕組みがないと、僕らは暗闇の中を手探りで進むことになってしまいます。
だから、ワイが作ることにしました。「推測するな、計測せよ」です！
目指したのは「SSL Pulse」のPQC特化版
皆さんは、Qualys社が公開している「SSL Pulse」をご存知でしょうか？ 世界のWebサイトのSSL実装状況を可視化する素晴らしいツールです。
今回のプロジェクトでは、これをリスペクトしつつ、「PQC時代」に対応した日本発の最強ダッシュボードを目指しました。
システムの要件はこんな感じ
- 圧倒的規模: 「Majestic Million」を使用し、トップ100万ドメインを対象にする
- 最新プロトコル対応: TLS 1.3はもちろん、PQ/T（Post-Quantum/Traditional）ハイブリッド暗号の対応状況を検出する
- セキュリティ格付け: 独自基準でS〜Fまでのランク付けを行い、「安全なサイト」を定義する
- 週次更新: 常に最新の状況をウォッチする
設計図（Design Doc）の一部をチラ見せすると、こんなアーキテクチャになっています。
CSV[100万ドメインリスト] --> Loader
Loader --> Queue
Queue --> Scanner[TLSスキャナー<br/>(Python/sslyze)]
Scanner --> Analyzer[分析・格付け]
Analyzer --> DB[(PostgreSQL)]
DB --> Generator[静的サイト生成]
Generator --> GitHub[GitHub Pages<br/>(ダッシュボード)]
Pythonの非同期処理でガガッとスキャンして、GitHub Actionsで週次で回して、GitHub Pagesで公開する。
「OSSフル活用」かつ「サーバーレス（に近い）」構成で、100万件を捌きます。
って、GitHub Actionsのパフォーマンスで100万件捌けるのか問題がありそうな気もしているがwww
ここがアツい！ ワイが定義した「Sランク」の基準
このダッシュボードの目玉機能の一つが、各ドメインの「セキュリティグレード（格付け）」です。
単に「HTTPSだから安全」という時代は終わりました。
ワイが定義した、これからの時代に求められる「Sランク（Safe & Future-proof）」の条件はこれです！
Grade S (Safe & Future-proof)
- TLS 1.3 が必須
- PQC Hybrid (耐量子計算機暗号とのハイブリッド鍵交換) に対応している
- No Weak Ciphers (脆弱な暗号スイートを含まない)
どうですか？ 結構シビアでしょ？
でも、これくらいやらないと「将来の脅威」には勝てないんです。
ちなみに、TLS 1.2で止まっていたり、脆弱な暗号設定が残っているサイトは容赦なく「B」や「F」判定になりますwww
スキャナーの実装では、X25519Kyber768Draft00 (0x6399) みたいなIANAのパラメータコードを直接チェックして、PQC対応を厳密に判定しています。この辺りのマニアックな実装も、職人魂の見せ所です！
まとめ：次回は「実装・アーキテクチャ編」！
今回は、SSL/TLS Scan Dashboard開発の「動機」と「構想」についてお話ししました。
暗号技術は「難しい」「とっつきにくい」と思われがちですが、こうやって可視化することで、「お、ウチのサイトもSランク目指そうぜ！」という機運が高まれば最高に嬉しいです。
次回は、「Python + GitHub Actionsで100万ドメインをどうやって制限時間内にスキャンするか？」 という、よりディープな技術解説編（Architecture & Implementation）をお届けする予定です。
並列処理のチューニングや、タイムアウトとの戦いなど、現場の泥臭い話も交えてお届けしますので、お楽しみに！
もし「こんな機能も欲しい！」「この判定基準はどうなの？」といったご意見があれば、ぜひコメントやXで教えてください。ワイと一緒に最強のスキャナーを作りましょう！
最後に、GMOコネクトでは研究開発や国際標準化に関する支援や技術検証をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。
お問合せ: https://gmo-connect.jp/contactus/