製品セキュリティの最前線【第5回】

暗号鍵管理、実際にやるなら、なにを決めてどう管理するか
―暗号鍵管理における考え方・設計・運用を整理する

※こちらのページに記載されている内容は、2026年5月時点の情報です。

暗号鍵管理を検討する際、ベストプラクティス的な仕様・ガイドラインとして、以下のものが参照されることが多いかと思います。

それぞれの規格で内容は若干異なりますが、基本的には、暗号鍵を安全に取り扱う上で、何をどのような考え方で管理すべきかということに対する指標が示されています。そして、重要なポイントとして、いずれも特定の製品やツール、具体的な実装方法を指定するものではないということが言えます。「この実装を行っていればよい」「このツールを使えばよい」という話ではなく、製品や組織の状況を考慮し、暗号鍵管理の設計を適切に行っているか説明できることが重要であるというのが、これらの仕様や規格から読み取れます。

暗号鍵管理を考える第一歩は、「何を管理対象としてとらえるのか」を明確にすることです。
前章で述べたガイドラインでは、主に次のものが対象になっています。

暗号を使用するにあたって、どのアルゴリズムを使い、その暗号鍵がどこでどの用途で使われているか、有効であるかどうか。電子証明書を使用する場合は、どの暗号鍵とひもづいているか、適切な発行手順や有効期限となっているか。暗号に関する上記の情報を、関係性も含める形で管理対象としてとらえることが、設計や運用を説明するための第一歩と言えるでしょう。管理対象を定義すること自体が、暗号鍵管理のゴールではありませんが、まずはこれらが設計・運用・監査について議論するための前提条件であることは間違いありません。

暗号鍵管理の検討にあたって、意外に見落とされがちなのが「暗号期間（Cryptoperiod）」です。
暗号期間とは、特定の暗号アルゴリズムや暗号鍵が、安全であるとみなして利用できる期間を指します。

NIST SP800-57では、鍵種別ごとに想定される暗号期間や有効期間の考え方が整理されており、暗号アルゴリズムの強度低下や解読するために使用するコンピューターの計算能力向上を前提に、いずれは更新や移行が必要になることが明示されています。つまり、多くの仕様ははじめから「暗号は永続的に使えるものではない」ことを前提に作られているわけです。この暗号期間の考え方をふまえると、暗号鍵管理は単に現時点で安全な方式を選ぶだけでなく、将来の更新や移行を見据えて、どの暗号鍵が、どの用途で、いつまで使われているのかを把握できていることが重要になります。こうした視点が、第4回で解説したクリプトインベントリやクリプトアジリティの必要性につながっています。

また、マスター鍵、保管鍵、配送鍵といった「暗号鍵を管理するための鍵」も、重要な管理対象として扱うことを忘れてはいけません。製品メーカーにおいては、つい製品自体に使用する暗号鍵そのものに目が行ってしまうのは自然なことではありますが、それらを守るための暗号鍵も、製品と同じような暗号アルゴリズムや鍵長が使われていることがほとんどです。これらは、暗号鍵管理そのものの信頼性を担保する基盤となるため、危殆(きたい)化した場合の影響は極めて大きくなります。

暗号鍵管理を設計する際は、どの暗号鍵が最上位にあり、どこに信頼の基点を置いているのかを明示することが重要です。

管理対象が明確になった後は、それぞれの暗号鍵に対して設計していく必要があります。

鍵管理のライフサイクルは、一般に「生成」「利用」「更新」「廃棄」といった段階で整理されますが、重要なのは各段階の詳細な手順ではなく、暗号鍵の状態が時間の経過とともにどのように変化しうるのかを一貫した形で把握できているかどうかです。多くのガイドラインでは、暗号鍵は永続的な利用を前提としておらず、安全に利用できる期間（暗号期間）を過ぎると、更新や利用停止、廃棄が必要になることが示されています。そのため、鍵が「いつ生成され、いつから利用され、いつまで有効とされているのか」を説明できることが、鍵管理の基本的な要件となります。

また、暗号鍵のライフサイクル管理においては、暗号鍵が単に存在するか否かではなく、現在利用中なのか、更新待ちなのか、すでに失効・廃棄されたものなのかといった状態の違いを区別して管理することが求められます。
こうした状態管理が曖昧なままでは、将来の更新判断や、問題発生時の影響範囲の説明が困難になります。

このように、暗号鍵のライフサイクル管理は個々の作業手順の話ではなく、暗号鍵を「時間軸を持つ管理対象」としてとらえ、現在の状態と将来の変化を把握できるようにするための整理である、ということが本質と言えます。

暗号鍵管理の方法について、仕様やガイドラインに「必ずシステムを用いて管理すること」と明示的に書かれているわけではありません。実際には、対象となる暗号鍵の本数が極端に少なく、運用が限定的であれば、手動による管理が選択されるケースもあります。一方で、多くのガイドラインが共通して重視しているのは、

といった点です。
これらを満たそうとすると、対象となる暗号鍵や証明書の数が増えるにつれて、人の作業に依存した管理には限界が生じやすくなります。結果として、管理情報を記録し、状態を把握し続ける手段として、システムによる管理の方が整理しやすいという場面が増えていきます。

また、近年のセキュリティインシデントの事例を見ると、仕様を熟知する従業員による内部犯行や産業スパイなどのケースもあり、もはや性善説は通用しないという観点からも、権限を持つ人しか操作できず、かつ作業証跡が必ず残り改ざんできないという、高いセキュリティ性を持つシステムを用いて暗号鍵管理を行った方が安全かつ運用負荷が低いと言えます。

システム化はあくまで選択肢のひとつですが、フォレンジックや監査、説明責任を意識するほど、その有効性が高まるという点は押さえておく必要があります。

ここまで説明してきた内容について、すべてを一度に完璧に整える必要はありません。
ただし、曖昧にしておくと後で困ってしまうような内容については、設計段階で一定の方針を決めておくことが重要です。例えば、以下のようなことが挙げられます。

これらは、手動運用・システム運用のいずれであっても避けて通れない論点です。具体的な実装方法や手段の話に入る前に、後戻りできない内容を整理して押さえておき、設計としての考え方を整理しておくことが肝要です。

法規や認証制度が最終的に見ているのは、「最先端の暗号技術を使っているかどうか」ではありません。
それよりも、暗号鍵や証明書がどのような方針で管理され、どのような状態にあり、問題が起きた場合にどう対応できるのか、を説明できる状態にあるかどうかが重視されます。クリプトインベントリや、暗号鍵管理に関する手順書等の各種ドキュメントは、そのための証拠や説明材料として位置づけられるものです。ただし、これらを個別に整備するだけでは、状態の変化や規模の拡大が起こった場合に「説明できる状態」を維持することは容易ではないはずです。

実務の現場では、暗号鍵や証明書の数や利用範囲が増え、将来的な更新や移行も見据えた管理が求められる中で、方針・ドキュメント・実運用を一貫して支える仕組みが必要になる場面が多く見られます。

暗号鍵管理のシステム化は、こうした課題に対する、有効な手段のひとつであり、単なる効率化ではなく、「管理できている状態を、継続して説明し続ける」ための基盤として位置づけて検討されるべきものと言えるでしょう。

【60秒チェック】今、どのような状態ですか？

→ ひとつでも当てはまれば、まずは「暗号鍵管理の設計（責任分担・運用・範囲決め）」から始めるのが近道です。

【暗号鍵管理がこれからの方へ】

暗号や法規の話を読んで、「まだここまでは整理できていない」「暗号鍵管理が重要なのはわかるが、何から始めればよいかわからない」と感じた方も多いかもしれません。
実際、そのように何も決まっていない状態から検討を始める企業も少なくありません。
その場合は、「何に対して暗号鍵管理を行うのか」「誰が責任を持って推進するのか」その大枠を決めるところから始めるのが近道です。
DNPでは、暗号鍵管理の検討初期におけるご相談や、現状整理のご支援も行っています。

【将来の暗号変更やPQC※¹対応を見据えたい方へ】

という方もいらっしゃるかと思います。
そうした場合には、本コラムで紹介した「クリプトインベントリ」や「クリプトアジリティ」の考え方を前提に、暗号の利用状況を整理し、将来の変更に耐えうる形での設計が重要になります。
DNPでは、暗号鍵管理の設計から将来の暗号化方式（or 暗号アルゴリズム）の変更を見据えた検討まで、段階に応じて支援します。

本コラムでは、暗号鍵管理について、管理やシステムの視点から整理してきました。
次回のコラムでは、もうひとつ見落とされがちな暗号鍵管理を含む「製造現場のセキュリティ対策と運用」についてご紹介します。