NISTのPQC標準化の記事で、企業の第一歩は「暗号資産の棚卸し（暗号インベントリ）」だと書きました。自社がどこで、どの暗号を、どのように使っているかの一覧を作る作業です。では、それは実際にやるとどんな作業なのか。
私たち（R&R Partners）は、金融機関のPQC対応案件で、商用の証明書ライフサイクル管理ツール（クラウド型）を使った暗号スキャンの事前検証と、開発環境への導入を担当しました。この記事では、その現場で分かったことを書きます。結論を先に言うと、工数の大半はスキャンそのものではなく、スキャンを始めるまでの段取りに費やされます。これから棚卸しを計画する方は、ここを見積もりに入れておいてください。
「想定外は出なかった」——その意味
基礎解説の記事では「棚卸しをすると、誰も把握していないサーバーや期限切れの証明書が出てくる」と書いてきました。では今回の現場ではどうだったか。事前検証と開発環境のスキャンでは、想定外の発見は特にありませんでした。
これを「スキャンは簡単だった」と読むのは誤りです。想定外が出なかったのには理由が2つあります。第一に、検証環境と開発環境は本番に比べて規模が小さく、構成が把握されている場所だったこと。第二に、スキャンを始める前に対象範囲・構成・許可を一つずつ潰す準備をしていたこと。つまり「想定外ゼロ」は、環境の性質と準備の結果です。
裏を返せば、構成が完全には把握されていない本番環境——数が多く、歴史が長く、担当者が代替わりしている場所——でこそ、棚卸しの本当の発見は起きます。そこはこれからの工程であり、続報として書く予定です。今回の記事の主題はその手前、「スキャンを始められる状態にする」までに何が起きるかです。
時間はどこに消えたか
検証から開発環境導入までで、実際に時間を要した工程を並べます。
- ツール自体の無害確認に5〜6時間——スキャンツールを顧客環境に持ち込む前に、こちらの検証環境（Rocky Linux）でマルウェア対策ソフトによるフルスキャンを実施しました。ツールを疑うのかと思われるかもしれませんが、金融機関の環境に外部製ソフトを入れる以上、「持ち込むもの自体の無害性を確認した」という事実と記録が必要です。時間はほぼ待ち時間ですが、スケジュールには丸々効いてきます
- 環境構築のやり直しに2時間——検証用サーバーの構築中、コマンドの誤入力によるエラーが解決できず、最終的にサーバー構築からやり直しました。地味な話ですが、検証作業の実態はこういう時間の積み重ねです
- ライセンス取得の往復に1日——ツールのアカウント登録が、こちらではなくクライアント側の手続きとして必要な設計になっており、進め方と初期設定の連絡の往復が発生しました。作業時間ではなく、関係者間の調整時間です
- プロキシ許可の切り分けに数十分——開発環境で、ブラウザからツールのクラウドにはアクセスできるのに、スキャンサーバーからは届かない、という状況が起きました。原因は、ブラウザの外部アクセス許可と、サーバーからの外部アクセス許可が別物として管理されていたこと。分かってしまえば単純ですが、「どちらの許可の話をしているのか」を切り分けて先方に伝えるまでに時間を要しました
並べると見えてくるのは、時間を消費したのがスキャンの実行ではなく、確認・調整・許可だということです。ツールのボタンを押す時間は、全体から見ればごくわずかでした。
ツールを回す前のチェックリスト
今回の経験を、これから棚卸しを始める人向けのチェックリストに整理します。ツールが変わっても、確認すべき構造はほぼ共通のはずです。
- 対象範囲の合意——どこをスキャンするかを、IPアドレスまたはFQDN（サーバーの名前）とポートの単位で、事前に文書で合意する
- センサー用サーバーの用意——スキャンの実行役となるサーバーには専用ホストの要件があり、OSの種類や管理者権限（sudo）の準備が要る
- ツールのクラウドへの疎通確認——スキャン結果の送信先となるクラウドサービスへ、外向きの通信（443番ポート）が通ることを、対象ホストごとに確認する
- ファイアウォールの許可申請——今回はFQDN単位で許可するという環境固有の条件があり、事前確認が必須だった。許可のルールは環境ごとに違うため、最初に聞く
- 名前解決の設定——FQDN単位の許可に対応するため、サーバー側の名前解決（hosts設定）が必要になった
- 管理単位（Business unit）の指定——ツールの有効化ファイルを取得する際に組織の管理単位を指定する必要があり、ここを誤ると管理権限の割り当てがずれる
- 証明書構成の事前把握——負荷分散装置が何個のFQDNと証明書を持っているか（SNI＝1台の装置が複数のサイト名を名乗る構成）を先に確認しておく。スキャン結果を読むときの答え合わせに必要になる
- 持ち込みツールの無害確認——前述のマルウェアスキャンに加えてオンラインの検査サービスも使ったが、一部の設定ファイルは検査対象外だった。「何をどこまで確認したか」を記録に残す
8項目のうち、こちらの手だけで完結するものはほとんどありません。大半がクライアント側の情報・判断・作業を必要とする——これが「段取りに時間が消える」の構造です。
先に聞いておけば楽だったこと
振り返って、キックオフの時点で決めておくべきだったことが2つあります。
- ツールのアカウント登録は、最初にクライアントに依頼しておく——登録がクライアント側の手続きだと分かった時点で往復が始まりました。契約や環境の話と並行して、初回の打ち合わせで「アカウント登録をお願いします」まで伝えておけば、この1日は消えていません
- スキャンの単位を、最初から本番に合わせて擦り合わせる——今回、開発環境ではIPアドレス単位でスキャンしましたが、本番はFQDN単位という条件です。開発でIP単位の手順に習熟しても、本番ではファイアウォール許可も名前解決も別の準備が要る。開発環境は「本番の予行」として設計してこそ価値があるので、単位の違いは最初に潰しておくべきでした
どちらも技術の問題ではなく、段取りの問題です。そして段取りの失敗は、技術の失敗より発見が遅れます。
読者への持ち帰り——見積もりの主役を入れ替える
PQC移行や暗号インベントリを計画するとき、多くの見積もりは「ツールのライセンス費用」と「スキャンにかかる時間」を軸に組まれます。今回の経験から言えるのは、その2つは工数の主役ではないということです。
主役は、対象範囲の合意、権限と許可の申請、アカウントと管理単位の設計、ネットワーク経路の確認、持ち込み物の無害確認——つまり組織を横断する調整です。これらは1つずつは小さくても、それぞれに「依頼して、待って、確認する」サイクルが付きます。社内の担当部署が多いほど、このサイクルは伸びます。
自社で棚卸しを計画するなら、証明書の台帳整備やIT資産の一覧化と同じ発想で、まず「誰に何の許可を求めることになるか」のリストから作ることをおすすめします。スキャンは、段取りが終われば動きます。動かないのはいつも、その手前です。
