PQC（耐量子暗号）移行の最初の作業は、自社がどこでどの暗号を使っているかを洗い出すクリプト・インベントリ（暗号の棚卸し）です。私たちは金融機関の案件で、この作業に商用のスキャンツールを使いました。前回の記事では、工数がスキャンそのものより段取りに消えたことを書きました。
今回は、ツールが出した結果そのものの話です。何が分かり、何が分からず、何がそのままでは使えなかったのか。そして、人手の調査をどう組み合わせて台帳を完成させたのかを書きます。
ツールで把握できたこと
使ったのは、IPアドレスなどの範囲を指定してネットワーク越しに調べる方式のツールです。指定した範囲にあるサーバーや機器に接続し、通信の中で見える暗号の情報を集めます。
把握できたのは、ネットワーク上から確認できる情報です。具体的には、サーバー証明書、TLSの設定（バージョンや暗号スイート）、公開鍵のアルゴリズムなどです。これらを、対象の範囲について効率よく収集できました。
人手で同じことをしようとすると、サーバーごとに接続して設定を確認し、結果を表に転記することになります。ツールは、この部分を短時間で、同じ基準で、漏れなく実行します。棚卸しの入口としては十分に役に立ちました。
ツールでは分からなかったこと
一方で、ネットワークから見える範囲の外にある暗号は、ツールでは分かりませんでした。
- アプリケーションの内部で行われる暗号処理。プログラムの中でライブラリを呼び出して行う暗号化や署名は、通信として外に出てこないため、外から観測できません
- データベースやファイルの暗号化。保存しているデータをどの方式で暗号化しているかは、通信の中には現れません
- 独自のプロトコル。TLSのような標準の手順を使わない通信は、ツールが解釈できる形になっていません
- 暗号の利用目的。その暗号が何を守るために使われているのか、どの業務のどの情報に関わるのかは、設定を見ても分かりません
これらは、設計書を確認し、システムの担当者やベンダーに聞いて埋めるしかありませんでした。とくに「利用目的」は、PQC移行の優先順位を決めるときに必要になります。HNDLの記事で書いたとおり、優先順位は「その情報を何年秘密にしておく必要があるか」で決まるからです。暗号の方式が分かっても、何を守っているかが分からなければ、順番は決められません。
そのままでは使えなかった検出結果
ツールが出した結果にも、人手での整理が必要なものがありました。大きく3種類です。
- 重複した検出。同じ暗号の情報が複数の行として出てくるもの。そのまま数えると、実態より多く見えます
- どのシステムのものか分からない検出。IPアドレスは分かっても、それがどの業務システムに属するのかは、ツールの結果だけでは判断できません
- OSやアプリケーションの情報が取れない検出。何の上で動いている暗号なのかが分からず、対処の担当も決められません
台帳として使うには、重複をまとめ、システムと結びつけ、足りない情報を補う作業が要りました。ツールの出力は材料であって、台帳そのものではありませんでした。
人手でどう補ったか
補い方は、順番に言えば次のとおりです。
まず、設計書や既存の資料を確認し、スキャンの結果と突き合わせました。IPアドレスとシステムの対応、暗号を使っている箇所、使っている方式が資料に書いてあれば、そこで埋まります。
資料で分からない点は、システムの担当者やベンダーに確認しました。利用目的と暗号方式を中心に聞き、ツールの結果に書き足していきました。
この作業の工数は、ツールを回す工数よりはるかに大きいものです。前回の記事で書いた「段取り」に、この突き合わせとヒアリングの時間を最初から見込んでおく必要があります。
「結局手作業が要るなら、効果は小さいのでは」への答え
ここまで読むと、こう思う方がいるはずです。ツールを使っても人手の調査が必要なら、導入する意味はそれほど大きくないのではないか。
私たちの答えは、ツールには人手では代えにくい利点が3つある、というものです。
- 網羅性。人手の調査では、対象の見落としや、転記のときの書き間違いが起こります。ツールは指定した範囲を機械的に調べるため、この種の漏れと間違いを防げます
- 効率性。広い範囲を一度に調べられます。サーバーが数十台、数百台と増えるほど、人手との差は開きます
- 継続管理。システムを更改したあとも、再度スキャンすれば台帳を自動で更新できます。更改のたびに台帳を手で直す運用では、いずれ更新漏れが起きます。暗号アジリティの記事で書いた「恒久的な台帳」を維持するには、この継続性が要ります
まとめると、スキャンツールは暗号資産を見つけるための有効な入口です。ただし、ツールだけでクリプト・インベントリが完成するわけではなく、人手の調査と組み合わせることが前提になります。この二つを分けて考えると、ツールへの期待も、人手の工数の見積もりも、現実に近づきます。
この記事の限界
書いておくべき限界が4つあります。
- *対象は金融機関の案件の検証環境と開発環境です。**本番環境や、別の業種のシステムでは、見える範囲や検出結果の傾向が違う可能性があります。
- *ツールの方式によって、分かる範囲は変わります。**今回使ったのは、IPアドレスを指定して外側から調べる方式です。ソースコードを解析する方式や、サーバーの内側で動かす方式では、アプリケーション内部の暗号が見える代わりに、別の限界があります。この記事の「分からなかったこと」は、外側から調べる方式についてのものです。
- *人手で補う量は、資料の整備状況で大きく変わります。**設計書が最新の状態で保たれている組織では、突き合わせで多くが埋まります。資料が古い、または存在しない組織では、ヒアリングの比重が上がり、工数も増えます。
- *見つからなかったものは数えられません。**ツールと人手を組み合わせても、台帳に漏れがないことを証明する方法はありません。できるのは、調べた範囲と方法を記録しておき、漏れが見つかったときに追加できる状態を保つことです。
これから使う方へ
スキャンツールの導入を検討している方に、私たちの経験から3つお伝えします。
- ツールに期待する範囲を先に決める。ネットワークから見える暗号を見つけることが、ツールの仕事です。アプリケーション内部や保存データの暗号、利用目的は別の方法で調べると、最初から計画に書いておく
- 人手の調査を計画に入れる。設計書との突き合わせと、担当者・ベンダーへの確認の時間を、スキャンの工数とは別に見積もる。ここを見込まないと、ツールを回したあとで計画が止まります
- 継続管理の道具として位置づける。一度きりの調査で終わらせず、更改のたびに再スキャンして台帳を更新する運用まで決めておく。「いつやるの？」に答えてきた現場の記事で書いたとおり、台帳はPQC対応が終わっても捨てないものです
ツールは入口で、台帳を完成させるのは人の作業です。この順番で考えておくと、導入後に期待と現実の差で止まることが減ります。
