2021年に改正・2022年1月に施行され、2024年1月には完全義務化された改正電子帳簿保存法への対応や電子署名・電子契約の普及、サイバー攻撃の被害拡大・手口の高度化により、企業はこれまで以上に厳密な鍵管理と真正性担保が求められるようになりました。

そこで、注目されているのが暗号処理を物理的に保護する「ハードウエアセキュリティモジュール（HSM）」です。本記事では「HSMとは何か」を皮切りに、今注目を集める理由やその種類を整理し、暗号鍵管理の説明可能性が問われる時代に情シスが備えておくべき知識をご紹介します。

【関連記事】

「暗号化」とは？ いまさら聞けない仕組みや注意点

HSMとは何か。なぜ今「HSM」なのか──暗号鍵管理を“説明できる状態”にするための装置

「ハードウエアセキュリティモジュール（HSM）」とは、暗号鍵を生成・保管・利用するプロセスを、専用のハードウエア内で完結させるための装置です。

その最大の特徴は、HSM内で暗号鍵が生成され、OSやアプリケーション、管理者は生成された暗号鍵を利用することはできても、鍵そのものを直接扱うことはできない点にあります。ソフトウエアベースの鍵管理では、設定ファイル、クラウドの管理画面といった入口からマルウエア感染や内部不正により暗号鍵が露出する余地が残ります。一方HSMでは、鍵は装置の内部に封じ込められ、外部からは「署名」「復号」などの指示しか出せません。

この仕組みが、どのような場面で価値を持つのか。代表的なユースケースを見てみましょう。

ユースケース1：電子契約・電子帳簿の「署名鍵」を誰も触れない状態で管理したい

電子契約や電子帳簿保存では、署名鍵やタイムスタンプに用いられる鍵が、その文書の真正性を裏付ける根拠になります。そのため関連する法規制や監査基準では、単に署名が行われていることだけでなく、その署名鍵がどのように管理されているか、そして不正利用される可能性がないかまで説明できることが重要視されています。

HSMを用いる構成では、署名処理そのものがHSM内部で完結し、鍵は生成から利用まで一切外部に露出しません。誰が、どの権限で、どの署名処理を実行したかはログとして追跡可能である一方、暗号鍵をコピーしたり持ち出したりすることは構造的に不可能です。

これにより、電子契約や帳簿データの信頼性を、技術的根拠をもって説明できる状態が生まれます。

ユースケース2：暗号鍵の管理を‟属人化“させたくない

API連携やSaaS利用が前提となった現在、多くの業務システムでは、APIキーや証明書といった認証用の暗号鍵が不可欠です。これらの鍵は、設定ファイルや環境変数、クラウド管理画面など、人やOSが直接扱える場所に保存されることが多く、担当者の端末・アカウント侵害、設定変更時の誤操作、鍵の使い回しや放置といったリスクにさらされることとなります。

そこでHSMを用いて‟鍵の保管と利用”を切り離すことで、特定の担当者が暗号鍵そのものを管理する必要のない構成を実現し、「パスワードを管理していた担当者が退職して何もわからない」「退職者にシステム権限が残ってしまう」といった属人的なリスクからも脱却し、組織として統制された鍵管理を実現できます。

ユースケース3：クラウド環境でも「鍵は自社で統制している」と説明したい

クラウドサービスの利用が進む一方で、発生するのが「暗号鍵までクラウド事業者に預けてよいのか」という問題です。特に、個人情報や重要業務データを扱う場合、鍵の管理責任という観点から、企業には慎重な対応が求められます。

特にクラウドHSMを用いた構成では、クラウド基盤を利用しながらも、暗号鍵の生成・保管・使用に関する統制を自社側に残すことができます。クラウド事業者はHSMのインフラを提供するにとどまり、通常の運用においては鍵の実体や利用内容にアクセスできません。

その結果、「クラウドを使っているが、鍵管理は自社責任で行っており、クラウド管理者やベンダーでも鍵を取得できない、かつ鍵の利用履歴を自社で監査できる」といった説明可能性が担保されるのです。

「説明責任を果たす」ことが求められる時代にHSMが注目を集めている

ここまで見てきたように、HSMは暗号鍵のセキュリティ強化につながり、その結果としての説明責任の担保につながります。

• 不正が起きていないことをどう説明するか
• 内部不正の可能性をどう排除したか
• 人や運用ルールに依存していないといえるか

こうした問いに対し、運用の工夫ではなく、構造として答えを用意できるのが、HSMが現在注目を集める最大の理由です。

クラウド／オンプレミス、汎用／用途特化……HSMの種類と役割を整理する

HSMがなぜ今あらためて注目されているのか、その背景と代表的なユースケースを整理しました。

ここからは一歩踏み込み、具体的にHSMにはどのような種類があり、それぞれがどのような役割を担うのかを整理します。

HSMの種類1：設置場所による違い──どこで鍵を守るのか

企業がHSMを導入する際の最大の判断軸は、「暗号鍵をどこで、誰の責任として守るのか」です。

HSMはオンプレミスHSM、クラウドHSMに分けられ、それぞれが異なるメリット・デメリットを持ちます。

オンプレミスHSM：鍵管理を“自社設備として”保有する

オンプレミスHSMは、自社のデータセンターやサーバールームに物理装置を設置し、暗号鍵を自社内で完結して管理する形態です。鍵はHSM内部で生成・保管・利用され、OSやアプリケーション、管理者であっても直接取り出すことはできません。

最大のメリットは、物理的な耐タンパ性（第三者による不正介入=タンパ（tamper）に対する耐性）や厳格な運用統制を含め、「鍵が社外に一切存在しない」と説明できる点にあります。そのため、金融機関、認証局、官公庁など、法規制や説明責任が極めて重い組織で長年採用されてきました。

一方で、装置購入や鍵管理、多人数承認、監査対応といった運用負荷は高く、HSMを扱える体制が必要になります。そのため、オンプレミスHSMは、セキュリティを“自社資産として保有する”ことを重視する企業向けの選択肢といえます。

クラウドHSM：鍵管理の責任だけを切り出して外部化する

クラウドHSMは、クラウド事業者が管理する物理HSMを、サービスとして利用する形態です。

ハードウエア自体はクラウド側に存在しますが、暗号鍵の論理的な管理権限は利用者にあり、クラウド事業者が鍵を取り出したり、恣意的に利用したりすることはできません。

オンプレミスHSMと同等のHSM機能を利用しつつ、装置調達や保守、可用性設計をクラウド側に委ねられる点が大きなメリットです。API連携を前提とした設計のため、電子署名、電子契約、証明書管理などの用途では、運用負荷とセキュリティのバランスが取りやすい現実的な選択肢となっています。

「クラウド＝鍵を預ける」と誤解されがちですが、実際には“鍵管理という責任領域だけを分離して外部化する”設計と捉えるのが適切です。一方、物理装置を自社で直接管理したい企業や、クラウド利用そのものに制約がある場合には適さないでしょう。

HSMの種類2：提供形態による違い──何をさせるためのHSMか

設置場所とは別に、HSMを分類するもう一つの重要な観点が「どの範囲の暗号処理を担わせるのか」という提供形態の違いです。HSMは大きく、汎用HSMと用途特化型HSMに分けられ、それぞれ設計思想と想定する運用負荷が異なります。

汎用HSM：暗号処理の“基盤”として使う

汎用HSMは、PKCS#11をはじめとする標準APIを通じて、鍵の生成・保管・署名・復号といった幅広い暗号処理機能を提供するHSMです。業務システムやアプリケーションから柔軟に呼び出すことができ、電子署名、証明書管理、データ暗号化など、用途を限定せずに利用できる点が最大の特徴です。

一方で、「どの処理をHSMに任せ、どこまでをアプリケーション側で担うのか」「鍵のライフサイクルをどう設計するのか」といった判断は、すべて利用者側に委ねられます。汎用であるがゆえに、設計の巧拙がそのままセキュリティレベルや説明責任の重さに直結する点には注意が必要です。

そのため汎用HSMは、暗号処理を業務システム全体の基盤として位置付け、自社で設計・統制できる企業に向いた選択肢といえます。

用途特化型HSM：特定業務の“安全装置”として使う

用途特化型HSMは、決済処理、TLSオフロード、コードサイニングなど、特定の用途に最適化されたHSMです。あらかじめ想定された用途に沿って機能や設定項目が限定されており、規制要件や監査基準を満たしやすい設計になっています。

そのため、「何のために使うのか」が明確な業務では、導入時の設計負荷や運用ミスを抑えやすい点が大きなメリットです。特に、決められた手順で確実に鍵を扱うことが求められる業務では、用途特化型HSMの方が説明しやすく、運用も安定しやすい点があげられます。

HSMの種類3：管理モデルによる違い──誰が鍵を“支配”するのか

HSMを選定する上で、設置場所や用途と並んで重要になるのが、「暗号鍵の管理モデル」です。

その観点では、HSMは大きくシングルテナント型とマルチテナント型に分けられます。

シングルテナント型：HSMを組織専有で利用する

シングルテナント型は、1台のHSM（またはHSMクラスター）を単一の組織が専有して利用する管理モデルです。

物理的・論理的な分離性が高く、鍵操作の権限管理や監査ログの取得、運用ルールを自社の方針に沿って厳密に設計できる点が特徴です。

そのため、「鍵は自社専有の環境で管理している」と明確に説明でき、規制対応や外部監査への説明責任を果たしやすい構成となります。一方で、専有利用であるがゆえにコストは高くなりやすく、可用性確保や運用体制の整備も求められます。

マルチテナント型：論理分離によってHSMを共有する

マルチテナント型は、1台のHSMを複数の利用者が論理的に分離して共有する管理モデルです。

物理装置は共有されますが、鍵領域や操作権限、監査ログはテナントごとに分離され、ほかの利用者が鍵にアクセスすることはできません。

このモデルの最大の利点は、コスト効率と運用負荷の低さにあります。特にクラウドHSMでは、マルチテナント型が一般的であり、スケーラビリティや可用性を確保しつつ、HSMのセキュリティ特性を活用できます。

HSMの種類4：信頼性・認証レベルによる違い──どこまで説明できるか

HSMの信頼性を示す指標として広く用いられているのが、FIPS 140-2 / 140-3といった暗号モジュール認証です。これは暗号実装や物理的耐タンパ性を第三者が評価・認証する枠組みです。

レベルは1から4まであり、企業利用ではレベル2〜3が一般的で、特に厳格な用途ではレベル3が一つの目安とされます。重要なのは、認証の有無が単なる安心材料ではなく、監査や対外説明における技術的根拠となる点です。

情シス視点で整理するHSMの役割と設計ポイント― HSMが適する場合・適さない場合

さて、企業が実際の導入を判断するには「自社にとってHSMが本当に必要なのか」「導入するとしてどこまでの範囲で使うべきか」といった問いに答えを出す必要があります。

そこで、HSMが適するケース・必ずしも適さないケースと、その判断にあたって持っておくべき観点を整理します。

HSMが適する場合・適さない場合の違いとは？

HSMの導入を検討すべきなのは、「暗号鍵の管理に対して高い説明責任が求められ、かつ人やプロセスに依存しない統制が必要な場合」です。具体的には以下のような状況が該当します。

• 法規制・監査要件で鍵管理の説明が求められる場合
• 内部不正リスクを構造的に排除したい場合
• クラウド利用と鍵管理の責任分界を明確にしたい（「BYOK：Bring Your Own Key」を実現したい）場合

一方で、すべての暗号鍵管理にHSMが必要なわけではありません。以下のような場合、HSMは過剰な投資となる可能性があります。

• 社内の開発環境など鍵の管理に対する説明責任が求められない場合
• API開発におけるテスト用トークンや、短期間で破棄される一時的な暗号鍵など、鍵のライフサイクルが短く、頻繁に更新される場合
• HSMを運用できる体制が整っていない場合

HSMが適するかどうかは「その鍵について、将来“説明を求められる場面”が来るかどうか」「その説明を、人ではなく構造で支える必要があるかどうか」の2要素で判断されます。

まずは、監査法人、取引先、経営層、顧客など鍵管理について誰に説明する必要が生じるのか、その可能性を洗い出し、ケースごとに対応を整理しましょう。そうすることで初めて、HSMが適しているのか、それとも人の運用で守り続けられるのかの判断フェーズに進めます。ぜひ以下のポイントで、現状の鍵管理を見直してみてください。

• 担当者の異動・退職があっても問題ないか
• 権限管理が属人化していないか
• 非公式に鍵を扱える個人は存在しないか

そうしてHSMを導入することになったらそこで終わり──ではありません。

HSMは、鍵の生成・利用・更新・廃棄というライフサイクル全体を、どのように統制するかを決めるための装置です。そのため、これまでの鍵管理体制の見直しは不可欠となります。少なくとも、以下のポイントについては明確に定め、文書化しておきましょう。

• どの鍵をHSMで管理し、どの鍵は対象外とするのか
• 鍵の生成・有効化・失効を誰が、どの承認プロセスで行うのか
• 障害時にどのように鍵を復旧し、誰が最終判断を行うのか
• 操作ログや監査ログを、どこに保管し、誰がレビューするのか

これらが曖昧なままHSMを導入すると、「安全なはずの鍵に、誰も触れず復旧できない」「説明責任を果たすための仕組みのはずが、逆に説明しにくくなる」といった本末転倒な状態に陥りかねません。

• 「この鍵は誰が管理しているのか」
• 「なぜ漏えいしていないといえるのか」
• 「人が不正できない構造になっているのか」

こうした問いに対し、構造として答えを用意できるからこそ、HSMは意味を持つのです。

HSMは「説明できる統制」を実現するための選択肢

サイバー攻撃の巧妙化や社会のデジタル化を背景に、企業には暗号鍵管理の説明責任がかつてなく強く求められるようになりました。HSMの本質は、暗号鍵を「誰も直接触れない構造」で守ることで、運用ではなく技術で信頼性を証明できる点にあります。

そして、情シスに求められるのは、「どこまでを構造で守り、どこからを運用で回すのか」を見極める設計判断です。HSMは単なるセキュリティ製品ではなく、組織の信頼性を対外的に証明するための基盤として利用していきましょう。