明日の暗号技術は、貴社の暗号インベントリから始まります。

はい。6件のサービスは、明確に区切られた作業パッケージとして計画できます。現状、前提条件、最初に必要な成果を貴社とともに明らかにします。各サブページでは、それぞれの範囲と技術的な判断事項を確認できます。

実装前に、目標、対象システム、貴社の関与、成果物、検収基準を取り決めます。未解決の技術的な課題は、まず現状の棚卸しやパイロットで明らかにできます。追加の作業は、工数と納期への影響を踏まえて評価します。

ドキュメント、操作説明、責任分担は契約に含まれます。OTOKO®が継続的な業務を担う場合は、サービス時間とエスカレーション経路を含む運用範囲を取り決めます。貴社のチームが自ら、あるいは既存のパートナーとともに成果を引き継ぐことも可能です。

耐量子暗号（PQC）とは、高性能な量子コンピュータによる攻撃に対しても耐性を持つことを目指したアルゴリズムを指します。企業にとってまず重要なのは、脆弱なアルゴリズムがどこで使われているか、そしてデータや署名をどれだけの期間保護し続ける必要があるかという点です。OTOKO®は、インベントリ作成、リスク評価、技術的な実装を組み合わせて対応します。アルゴリズムの変更だけでは不十分です。ライブラリ、プロトコル、機器、接続先システムが、すべて連携して機能する必要があります。

貴社のどのアプリケーションが、どの暗号化方式を使っているのか。そして、誰がそれを変更できるのか。暗号技術に関する依存関係を把握し、貴社のシステムと責任者に対応付けます。このインベントリが、今後の計画に向けた検証可能な基盤となります。

調査範囲と許可された収集方法を定める プロトコル、証明書、ライブラリ、鍵の利用状況を把握する スキャン、コード分析、システムエクスポートの結果を統合する 依存関係と未調査領域を明示する インベントリの継続更新と機械可読形式でのエクスポートを準備する

出典と網羅範囲を明示した暗号インベントリ アプリケーションごとの依存関係一覧 CBOMの更新手順

ネットワークスキャンで把握できるのは到達可能なサービスまでであり、組織内の暗号技術全体を捉えることはできません。エンドポイント、証明書の一覧、ライブラリ、設定、システム責任者へのヒアリングなど、許可された複数の収集方法を組み合わせます。オフライン署名、モバイル機器、組み込みコンポーネントも対象となり得ます。結果では、実際に観測された利用状況と、単にインストールされているだけの機能とを区別します。後の判断が不明確な前提に基づかないよう、それぞれの所見には出典と時点を記録します。

Cryptography Bill of Materials、略してCBOMは、暗号関連のコンポーネントとその関係を機械可読な形式で記述します。重要なのは、用途との対応付けです。証明書は通信を保護することもあれば、長期にわたり検証可能な署名を支えることもあります。所有者、変更可能性、メーカーへの依存関係を把握します。到達できない、または調査対象外のシステムは、欠落箇所として可視化したままにします。こうした分類を伴わない大量のデータエクスポートは、信頼できる判断の根拠にはなりません。

ライブラリ、証明書、設定への変更は、継続的な更新に反映されるようにします。そのために、責任者と更新のきっかけとなる事象をあらかじめ定めます。検収では、実際のシステムに対してサンプル検証を行い、達成した調査範囲を文書化します。本番環境でのスキャンは、承認された範囲内で、かつ影響を受けやすいコンポーネントに配慮したうえでのみ実施します。

すべてのシステムを同時に移行する必要はありません。保護期間、攻撃対象領域、技術的な依存関係、移行にかかる工数を評価します。そこから、根拠のある施策、責任分担、判断ポイントを伴う実施順序が導き出されます。

データと署名の保護要件をあわせて評価する 暗号関連の依存関係と移行工数を整理する メーカーへの依存関係と調達サイクルを把握する パイロット案件と移行ウェーブを計画する 残存リスクと未決定事項を文書化する

根拠のある優先順位付け 依存関係を明示した移行計画 業務部門とIT向けの意思決定資料

特定の情報は、何年にもわたって機密性を保つ必要があります。そのため、記録された暗号化通信は、すでに現時点から長期的なリスク評価において意味を持つことがあります。同時に、調達、ソフトウェアの改修、接続先システム側の変更には時間がかかります。これらの要因を貴社の保護要件と結び付けますが、高性能な量子コンピュータの登場時期についての推測を、確実な計画の前提として扱うことはありません。署名については別途検討します。長期にわたる検証可能性には、通信の機密性とは異なる対策が必要になる場合があるためです。

中核となるライブラリや証明書プラットフォームは、多くのアプリケーションに影響を及ぼす可能性があります。逆に、1台の古い機器が、ある通信経路全体の移行を制約することもあります。こうした依存関係を整理し、メーカーの情報を確認したうえで、短期的に実施可能な施策と事前準備とを切り分けます。パイロットには明確な検証課題を設定します。例えば、ゲートウェイチェーンの互換性や、特定の鍵の種類への対応状況などです。ロードマップには判断ポイントを設け、測定結果や新しい情報によって、その後の計画を見直せるようにします。