署名保証ガイドライン：3 -電子署名リスク管理：ESRM-

概要

SAG-1:2026がお手本にしているNIST SP 800-63-4には3章にデジタル・アイデンティティ・リスク管理（DIRM：Digital Identity Risk Management）がnormative（遵守項目）として記載されています。これはSP 800-63-4が米国政府のシステム構築向けのガイドラインであるために、遵守項目として記載されているためです。

一方で「署名保証ガイドライン第1.00版（JNSA SAG-1:2026）」は民間も含む一般的な用途のガイドラインですのでリスク管理を必須とするわけには行きません。このためにSAG-1:2026では3.章にて参考情報（Informative）として、電子署名リスク管理（ESRM：Electronic Signature Risk Management）を整理しました。ただしDIRMと違い実施要項ではありませんので、信頼される電子署名サービスを構築する際のリスクに対する考え方についての参考情報としています。またDIRMは正直難解なので、新規にISO 31000ベースで再検討したものです。ですのでDIRMとESRMは全く別物となっています。SP 800-63のxALをベースとしたSAG-1:2026のSxALとの関係とは違いますので注意してください。

閑話休題。以下の図がESRM全体の手順図です。まあこれが全てと言っても良いですが、オレンジの部分が必須アウトプットでブルーの部分がオプションアウトプットになっています。

図3-2　電子署名のリスク管理（ESRM）の手順

手順としては以下となります。ISO 31000と比較するとStep0が増えていますが、これはESRMが署名保証レベルを使うことで、初期目標として署名保証レベルを設定するからです。

ステップ	内容	補足
Step0	定義と初期保証レベルの仮置き	初回のみ
Step1	リスクアセスメント実施
Step2	基本策と最終保証レベルの決定
Step3	文書化（SSAS/SSPS作成）
Step4	署名サービス運用と再評価	Step1へ戻る

なお最初に書いておきますが、DIRMやESRMのようなリスク管理のステップを使ったプロジェクト開発は正直を言って予算やスケジュールの関係で難しいことは理解しています。でもリスク管理の考え方は大事で身につけておくべきと考えています。ですのでESRMを説明した後で「リスク管理と言う考え方」を追加していますのでお読みいただければ幸いです。

電子署名リスク管理：ESRM

ESRMのステップを説明する前にSAG-1:2026の3章から抜粋します。「リスク管理と言えばセキュリティ・プライバシーに関するリスクのイメージがあるが、別カテゴリーとして、利便性・UI/UXやコスト・財務的等のリスクカテゴリーも合わせて評価する必要がある。一般にはセキュリティリスクに対して高い要求をすると、利便性やコストが悪化する面があり、セキュリティリスク以外のカテゴリーもリスク管理する必要がある。」と書いています。日本ではリスク管理と言えば全てセキュリティ的に安全な方を選択しがちですが、使われないシステムは意味がありません。ちょうどよい適当なリスク管理をおこないましょう。

Step0: 定義と初期保証レベルの仮置き

SAG-1:2026は保証レベルを定義しているガイドラインです。ですのでリスク管理をおこなう前にまずはリスク管理の対象となる署名サービスが目指す保証レベルを定義しましょう。これは目指すべき保証レベルとなりますので、リスクアセスメントした結果としては保証レベルが下がったり上がったりする可能性があります。SIAL/SPAL/SDAL/SOALの4つの保証レベルがありますので、時間をかけずに最初に考えている保証レベルを決めましょう。各保証レベルについては前章を参考にしてください。

SxAL	保証レベル	対象	フェーズ
SIAL	署名者身元保証レベル	アイデンティティの保証	登録
SPAL	署名プロセス保証レベル	プロセスの保証	署名
SDAL	署名データ保証レベル	データの保証	検証
SOAL	サービス運用保証レベル	ガバナンスの保証	全体

3.2. Step1: リスクアセスメント実施

リスクアセスメントも日本ではリスク評価と訳す場合がありますが、SAG-1:2026ではリスクアセスメント（Risk Assessment）とリスク評価（Risk Evaluation）と訳して使い分けます。リスクアセスメントは全体の評価で、リスク評価は個別リスクの評価としています。ISO 310000においてリスクアセスメントは、リスク特定・リスク分析・リスク評価の3ステップにさらに分けられます。

ステップ	目的と成果（アウトプット）
リスク特定	目的：想定されるリスクの列挙 成果：電子署名のリスクと想定対策のリスト
リスク分析	目的：リスクのレベルの把握 成果：リスクリストの各リスクのレベル
リスク評価	目的：リスク毎の個別対応要否の判定 成果：対応が必要となるリスクリスト

細かな話はSAG-1:2026を参照していただくとして、ここでは簡単に各項目を解説します。

リスク特定

まずは想定されるリスクをリストアップしていきます。「リスクの特定には多方面からの視点が必要であり、可能な限りステークホルダーと共に検討するかリスクを指摘して貰うことが望ましい。」としており、できるだけ色々な視点で、例えばコストであったりUI/UXであったりも含めてリストアップしましょう。各保証レベル・フェーズである、登録時・署名時・検証時・運用時のそれぞれについてのリスク例も記載していますので参考にしてください。

リスク分析

次にリストアップされたリスクリストを分析して、各リスクの影響度と発生頻度によるリスクマトリクスを使い、リスクのレベルを最高・高・中・低・最低の５段階で判定するとしています。低・最低のリスクであれば残置リスクとして許容することも必要です。一方で中以上のリスクは更なる評価が必要です。

リスク評価

最後にリスク毎のリスクレベルが署名保証レベル（SxAL）として許容可能かどうかを評価します。中以上のリスクに関しては被害額も考慮して評価することが必要です。

3.3. Step2: 基本策と最終保証レベルの決定

Step1のリスクアセスメントの結果、残ったリスク項目に対しての対応を決定します。リスク対応には、回避・軽減・移転・受容の4つの方法があります。

リスク対応	説明
回避 Avoid	リスクの原因となる操作や機能の提供自体をやめることで、リスク自体を回避する。
軽減 Mitigate	影響度や発生頻度を下げる新たな対策を取り入れることで、リスクを軽減して受容可能なリスクにする。
移転 Transfer	リスク自体を第三者に契約や保険等で移転することで、リスクを回避する。
受容 Accept	影響度や発生頻度が許容できる場合には、残留リスクとして受け入れる。

次に、プライバシー（Privacy）・顧客体験（Customer Experience）・脅威（Threat）の3つの観点から初期署名保証レベルを見直して調整します。

その上で標準で利用者に提供する基本策の策定と、リスクが顕在化した時に備えた代替策と追加策を検討します。基本策の策定は必須であり、代替策と追加策はオプションです。

策定された基本策により初期保証レベルに対して見直しをおこなった結果が最終的な署名保証レベルとなります。残留リスクがあった場合にはきちんと記録を残します。

3.4. Step3: 文書化（SSAS/SSPS作成）

ここまでで基本策と最終保証レベルが決定されました。最後にここまでの検討経緯や内容を文書化します。文書化する対象は、内部向けの署名サービス承認規定（SSAS）と、外部公開向けの署名サービス運用規定（SSPS）に分かれます。SSPSはPKIの認証局で言うところのCPSと同じとなります。SSASは必須ですが、SSPSはSOALのレベルによってはオプションとなります。

3.5. Step4: 署名サービス運用と再評価

最終保証レベルが決定したら署名サービスを開発実装して、運用規定に従って署名サービスの運用を開始します。SOAL2/SOAL3の場合にはSSPSを公開します。

署名サービスに対する脅威・利用者のニーズ・法的な要件等は常に変化しています。定期的にStep1に戻り、署名サービスのリスク管理のプロセスを実行します。これは署名サービスが終了するまで続きます。

リスク管理と言う考え方

正直を言えばここに書かれているようなリスク管理をおこなって開発されている署名サービスはあまりないでしょう。それは予算的時間的な問題だと思います。しかしながら署名サービスの開発時または運用時にリスクが顕在化する場合があります。この時にはそのリスクを評価して対応策を検討しましょう。リスク評価をおこなわない場合によく出るのは「最も安全な策を採用しましょう。」と言う言葉です。ですがちょっと待ってください。その対応策を実行した場合に、利用者の利便性やコスト面での評価をしましたか？その署名サービスが目指す目的によってはリスクを許容または低減する策で良い場合があります。会議室の申請と億単位の契約において同じレベルのリスク管理はできませんよね。もしリスクが顕在化した場合にどれだけの被害が想定されるのかをリスク評価した上で対応策を考えるべきです。

リスクに対してすべて安全側に倒した対策をすると、利便性が低下して使われないという別の根本的なリスクが出てきます。ある意味PKIベースの電子署名はそのために普及が遅れたようにも思えます。きちんとリスク管理をおこなうことが理想ですが、顕在化したリスク単体に対してもリスク管理の考え方を適用して、適切な対応策と保証レベルを選択するようにしましょう。

おわりに

SAG-1:2026では、署名の定義・署名の基本モデル・署名方式の整理・署名保証レベルの定義・署名サービスのリスク管理を解説するガイドラインです。と言うことで今回までで本文についてはすべて解説したことになります。次回は付属書の部分、つまりは付録の説明をします。付録についても解説しますが、ここから後はご興味があれば読んでいただけると嬉しいです。

署名保証ガイドライン解説シリーズ

章	タイトル	概要
--	リリースしました！	署名保証ガイドライン第1.00版の概要
1	電子署名（と電子認証）の要件	電子署名（電子認証）とは？
2.1	署名サービスの基本モデル	電子署名の基本モデルの定義
2.2	各種署名方式の整理	ローカル署名と認証技術を使った様々な署名
2.3	電子署名の保証レベル：SxAL	SIAL/SPAL/SDAL/SOALの解説
3	電子署名リスク管理：ESRM	リスク管理と保証レベルの選択
A	適合宣言と情報公開（仮）	信頼と情報公開
B	承認目的署名と発行元保証署名（仮）	eシール的署名とは
C	電子委任（仮）	委任状モデルと問合せモデル
D	トラスト設計（仮）	署名と認証による設計