本文へ移動

電子署名法認定基準のモダナイズ検討会（第2回）

最終更新日:

概要

  • 日時：令和6年（2024年）11月1日（金）13時00分から15時00分まで
  • 場所：デジタル庁会議室及びオンライン開催
    検討会の様子をライブ配信します（Microsoft Teamsを使用）
    ※ライブ配信は終了しました。
  • 議事次第：
    1. 開会
    2. 議事
      1. 第1回検討会の振り返り
      2. モダナイズの方向性③から⑥に関する議論
      3. 次回開催について
    3. 閉会

資料

参考資料

  • 参考資料1：「利用者真偽の確認に係る自動化対応について」※構成員限り

議事録

事務局（山之上）： それでは、定刻となりましたので、これより「電子署名法認定基準のモダナイズ検討会第2回」を開会いたします。ご多忙の中、ご出席いただきまして、誠にありがとうございます。本日、事務局を務めさせていただきます、デジタル庁の山之上でございます。どうぞよろしくお願いいたします。

まず、議事に先立ち、本日ご用意いたしました資料についてご確認させていただきます。資料は3点ございます。1点目が議事次第、2点目が「モダナイズの方向性に関する追加議論」、そして3点目が委員の皆様限りで配布させていただいている電子署名法に基づく認定認証事業者my FinTech株式会社様よりご提供いただきました「利用者真偽の確認にかかる自動対応について」の資料でございます。これら3点の資料がお手元に揃っておりますでしょうか。ご確認ありがとうございます。また、本日の資料につきましては、デジタル庁のウェブサイトにも掲載しておりますので、ご確認いただければと存じます。

それでは、以降の議事進行を松本座長にお願い申し上げます。松本座長、どうぞよろしくお願いいたします。

松本座長： それでは議事に入りますが、前回に引き続き活発な意見をよろしくお願いいたします。では、最初に議題1について、事務局からご説明をお願いします。

事務局（山之上）： 事務局でございます。資料1に沿ってご説明いたします。9月20日に第1回検討会を開催し、委員の皆様からいただいた意見を取りまとめた結果、本検討会の全体の方針として事務局が提示したモダナイズの方向性①から⑥を優先して議論することに合意いただきました。

方向性①については、リスクマネジメントを電子署名法に盛り込むための基準改正の範囲及び改正する際に盛り込むべき内容について議論いただいたところ、法改正は不要であるものの、施行規則でリスク管理の義務を明示することが必要、また、リスクマネジメントは単なるセキュリティ対策ではなく、組織全体のガバナンスとしてETSIだけでなく、NIST指令やISMAPといったガバナンスに関する基準が規定されたものを参照し、盛り込むべきだとの意見がございました。

方向性②については、認証局の秘密鍵を管理する暗号装置の技術基準を更新することの必要性及び適合すべきFIPS 140のバージョンについて議論いただいたところ、暗号装置の技術基準をFIPS 140-3に更新すること自体は必要であるものの、FIPS 140-3準拠の製品が市場に少ないため、現時点ではFIPS 140-2相当とし、FIPS 140-3への移行時期は国内の関連製品の動向を踏まえることも必要であるとの意見がございました。事務局からは以上となります。

松本座長： ありがとうございました。ただ今事務局から前回の振り返りがありましたが、本日は議論が多いため、質疑応答は省略し、次の議題に移ります。

漆嶌委員： 一言だけよろしいでしょうか。方向性②に関して、「FIPS 140-3が非常に少ないため」と書いてありますが、少なくともあるので、「FIPS 140-2」とあるところを「FIPS 140-2または140-3」とすべきかと思いますがいかがでしょうか。既にある製品で新しいものが使えないというのが、困ったことになるのではないかと。

事務局（北井上）： 事務局でございます。ご指摘いただきありがとうございます。FIPS 140-3を排除することは念頭になく、「FIPS 140-2以上」になろうかと思います。FIPS 140-3に限定すべきかどうかという観点で記載していたため、分かりづらい表現となり、失礼しました。

松本座長： ありがとうございます。引き続きよろしくお願いします。
それでは次に、議事⑵に入ります。今回は四つの論点がございますので、一つずつ進めていきたいと思います。事務局の方から③についてご説明をお願いいたします。

事務局（當波）： 事務局でございます。論点③と④につきましては、一部考え方が共通する部分もございますが、まず、③においてHSMの周りの特に認証局において重要な設備となる箇所について議論いただいた後、④においてそれ以外の設備も含めた一般的なクラウド利用及び遠隔操作に関する議論に移らせていただきたいと考えております。

まず、③の論点につきましては、先ほど申し上げましたとおり、HSM及び認証業務用設備と呼んでいる、認証局においても特にキーとなる設備について、ネットワークを介しクラウドHSMの利用を許容するか否か、というところの論点でございます。こちらの具体的な論点といたしましては、まずは、クラウドHSMの利用のニーズ及びメリットについて今後の議論に役立てるため、事務局として把握したく、ご意見をいただけると幸いでございます。二つ目は遠隔操作の要件として、具体的にクラウドHSMを利用する際の要件、これは、この後のページで更に細分化して書かせていただいておりますので、この後ご説明いたします。最後に、調査・審査の方法になります。クラウドHSMの提供事業者は認定認証事業者ではない、別の法人であるため、電子署名法において課されている法的な規範がかからないところがあるということでその課題に関する議論をいただければと思います。

今ご説明いたしましたとおり、論点③-2および③-3につきましては、具体的に電子署名法においてHSMや暗号装置及び認証業務用設備に関連する基準として、主に3種類に分類されるものと考えております。まず一つ目は、HSM自体の安全性に関する基準。これは前回の検討会でご議論いただきましたFIPS 140-2及び140-3に代表される暗号装置に関する基準です。次に、HSMを設置する部屋を「認証設備室」と呼んでおりますが、その認証設備室が設置されている建物自体に関する基準。これは、入退室管理のための指紋認証装置や火災対策などを含みます。最後に、HSMの運用に関する基準です。こちらにつきましては、入退室管理が守られているか、指揮系統に関する管理基準、操作履歴の記録など、正しく認証局が運営されていることが記録として残されているというところになります。こちらのクラウドHSMに対して特別に求めるべき要件や、遠隔操作に関する基準として必要となる要素はどこかという観点について、ご議論をいただきたいと考えています。

③-3の調査・審査に関する論点としては、特に主務省庁及び指定調査機関が実際にクラウドHSMの運営事業者に立ち入って実際の建物を見て、認定基準に沿っているかという調査を行うことが困難になる箇所もありますので、そういった観点からご議論いただきたい、不十分である点の洗い出しをお願いしたいと思います。事務局からの説明は以上となります。よろしくお願いいたします。

松本座長： ありがとうございます。そもそもHSMとは何かについての深い理解が要りそうです。2000年頃はHSMを使っているのは認証事業者くらいしかなかったですが、今はクラウド事業者が山のように購入して色々なところに使われていますが、2000年当時はHSMを開発した事業者がいたので、そもそもHSMはどのように運用しなきゃいけないかであるとかも理解されていましたが、そういったところが日本の中ではある意味空洞化しているところがあって、クラウドを使っていれば安全だという単純なものではないっていうのが理解できるかっていうのが鍵のような気もします。

それでは、先ほどの説明をもとに、質疑応答に移りたいと思います。オンライン参加やオブザーバーの方で発言希望がある場合は、チャット欄にご記入ください。それでは質疑を始めます。よろしくお願いいたします。

漆嶌委員： まず整理させていただきたいのは、ネットワーク型HSM・クラウドHSMは別のものです。ネットワーク型HSMを認めるか認めないかの話っていうのは、現状どうなっているのかということのお話を聞かせていただいてもよろしいでしょうか。

事務局（當波）： 事務局側の理解の確認になりますが、ネットワーク型HSMとは、単にネットワークを介して別の拠点に設置されているHSMを指す、という理解でよろしいでしょうか。

漆嶌委員： 例えば、データセンター内で、ネットワークを介してCAサーバからHSMアプライアンス機器に接続するようなタイプですね。

松本座長： 多分、ネットワークHSMとクラウドHSMの違いを本当は正確に理解する必要があると思います。そして、多くのCA事業者、あるいはIA事業者に近いところでは、ホスティングを利用しており、ネットワークHSMがほぼデフォルトに近いと思います。ですので、本来はその運用がどのように行われているか、そしてそれが単一の組織としての運用なのか、という点についても確認が必要だと思います。実質的にはそうやっていると思います。ネットワークHSMとクラウドHSMの違いについてですが、そのあたりいかがでしょうか。

満塩委員： 逆に言うと、ネットワークHSMはサーバからインターフェースが伸びる形ですね。私も確認したかったのは、クラウドHSMというのが、いわゆるパブリッククラウドベンダーが持っているHSMですか。そうすると、他の議論で取り上げられているクラウドHSMには、BYOK（Bring Your Own Key）の話もありますが、ここで言っているクラウドHSMはBYOKではなく、第三者のクラウドサービスベンダーが運用するHSMということでよろしいでしょうか。この点を明確にしておかないといけないと思いますが、いかがでしょうか。

事務局（當波）： まず、最後の点についてお答えいたします。満塩委員からご指摘いただいた通り、第三者のクラウドベンダが提供するHSMを指しております。そもそもこの議論の出発点は、一昨年に認定認証事業者の方々に行ったアンケート結果に基づくものです。アンケートにおいて、事業者からの要望として挙がったのが、このクラウドHSMに関する点になります。その際には、ネットワーク型HSMという話までは踏み込まれていなかったように思いますので、まず今回クラウド事業者が運用するHSMというところの議論になっているものと理解しております。

漆嶌委員： 現状、9ページにあるABCの定義を見ますという定義になっていますが、それでは多分足りなくて、ネットワーク型HSMとクラウドHSMの両方において、CAサーバとHSMの通信がどのようになっているのか、またその通信の保護がどのように確保されているのかを調査し、しっかり確認しないと、適切に「使用して良い」「使用してはいけない」といった判断ができないのではないでしょうか。

松本座長： 私もネットワークHSMが出てきたのは多分2000年代後半ぐらいだと思うのですけど、それは必ずしもクラウドHSMを想定していないですよね。で、ちょっとここでの議論が難しいなと思うのは、一般的に証明書を発行している時点の話と、そもそもキーセレモニーをやっている話とは違うということです。ネットワークHSMはそのあたりでどう考慮されているのか、ということなのですけど、どうなのでしょうか。

満塩委員： そういう意味では、もう一点確認させていただきたいのですが、7ページの左側に書いてある、この「HSMの利用目的」のところなのですけど、発行者署名符号を持つサーバ的なものとして、CAの役割を果たすものだと理解しています。ただ、ネットワークHSMはオフラインではないですよね。オフラインではなくて、大量の証明書を発行するようなものだという理解だったので、その部分がターゲットという認識で良かったのでしょうか。

JIPDEC 大澤様： 基本的には、私達が調査した経験上ですと、CAサーバなりに直接つながっています。

松本座長： JIPDECさんが一番ご存知かと思いますが、ネットワークHSMについては監査、あるいは審査をしているのですよね。

JIPDEC 大澤様： そこはお答えしていいのでしょうか。

松本座長： これは、HSMの話だけでなく、「高セキュア領域」が何のためにあるのかを理解しないとわからない話であって、さらに言えば、PKIのアーキテクチャの理解も本当は必要で、「高セキュアルーム」は可用性があまり必要なく、可用性を犠牲にして秘匿性を高めているアーキテクチャである、という理解がないとわからない。皆さんで共通の理解を持つことが必要で、昔からやっている人には共通の理解があるが、そこがわかるかどうかですよね。

JIPDEC 大澤様： 認定認証事業者の実情だけを申し上げますと、法令に規定されましたとおり、認証設備室というかなりハイクオリティな要件を満たした室の中に認証業務用設備が設置されていて、それも認証業務用設備にダイレクトにつながっているシステムである場合もあれば、CAサーバと言われるものに内包されている場合もございます。いずれにしても、その認証業務用設備というものは電子署名法でかなり厳しい制御を課された部屋の中でしか扱えないという条件があり、ましてやクラウド上ということは全く想定されていないわけです。国の認定を受けた認証局が構築した認証設備室という部屋から出ていいのかどうかは、有識者にご議論いただく必要があるのかなというのが、指定調査機関として感じておるところであります。

松本座長： この点について、今日の限られた時間の中で十分に議論できるかは少し疑問がありますが、繰り返しになりますが、認証業務用設備には可用性があまり求められていない、というか入れないですよね。金融機関のコールドウォレットに近く、動かせないがために金庫にしまっているようなもので、機密性を保つための仕組みです。そのため、可用性を追求していないのは、そもそもPKIアーキテクチャが24時間か12時間ごとにCRL（証明書失効リスト）を発行しないといけない、要は「それまでに復旧できればよい」という可用性要件でアーキテクチャが成り立っているというのが一番大きく、CAの鍵を守っている人が非常に強い。一方で、クラウドHSMは可用性を求められているため、そこまでできるか疑問があります。とはいえ、電子署名法が実際にそこまでの要件を求めているかは別の話です。しかし、最高のセキュリティ (鍵の機密性) と可用性のトレードオフで作られているので、この理解がないと議論が噛み合わない気がします。

満塩委員： おっしゃるとおり、発行者署名符号を入れているわけですから、この配下のすべて、証明書なりCRLなりを証明していくことになります。ですから、逆にここが崩れると、漏洩して何か別のことを送り始めると、すべてが信用できないという話になって全崩壊するところなので、そういう意味では、厳密にしたいという意見が昔からありました。ここからさらにヒエラルキーにするべきかどうか、という議論もいろいろあるかと思います。ここから下は、少なくとも私はヒエラルキーでしか作れないと思うので、そういう意味ではここは大事だと思います。一方で、クラウドHSMについてですが、私もいろいろな場でISMAPやCRYPTRECの話を議論していますが、あれはやはりストレージを暗号化するか、もしくはストレージのデータの暗号化と暗号化消去するためのものです。この2つが主な目的であり、PKI自体を守るためのものとしてはどうしても見えません。

松本座長： 多分、クラウドHSMを使ってPKIをやっている事例は山のようにあると思います。それが電子署名法のアシュアランスレベルを満たしているかどうかは別で、クラウドHSMが進化したのは間違いないですが、過去との整合が取れるかどうかは難しいです。

満塩委員： 私も今の技術の代替を使えばいいという認識ではあります。

漆嶌委員： もう一度確認させていただきたいのですが、鍵が日本国内にある必要があるかどうかについてです。例えば、総務省が認定するタイムスタンプサービスでは、鍵が国内にあることが要件となっています。電子署名法の認定認証においても、鍵が国内にあるという要件があるのかどうかも、クラウド利用の可否を判断する際のポイントになるかと思いますが、いかがでしょうか。

事務局（當波）： 今の漆嶌委員からのご意見につきましては、これまで実際に認定を受けた事業者はいないのですけれども、電子署名法において「外国における特定認証業務の認定に関する基準」が設けられております。そのため、最初から海外事業者が関与し、鍵が海外に置かれるケースも想定されていたものと理解しています。

漆嶌委員： 事業者が海外であるというのと、鍵が国内にあるというのは違う話かと思います。海外の事業者が日本国内の鍵で運用するケースもあっていいと思いますが、その際に「鍵が国内にあること」が求められるのかどうか、という観点でお伺いした次第です。

満塩委員： おっしゃるとおり、海外事業者も想定内であったと理解しています。逆に言えば、鍵をどこに置くかについては何も言っていません。

漆嶌委員： その時に安保的な観点で、本当に国外に鍵があっていいのかというのも議論の必要があると思いました。

満塩委員： 最近の議論の論点としてはあり得ると私も思います。ただ、これまでの電子署名法の認定におけるモダナイゼーションのストーリーの中で、そこを一緒にするのはどうかという気もしています。この点については、さまざまな議論が考えられるため、部分的な議論に終わらせず、まとめて議論しないと、部分的な議論になってしまうのではないかと思います。

漆嶌委員： 9ページでネットワークを確認しなければならないという話をさせていただきましたが、やはりネットワーク型やクラウド型を利用する場合、ネットワークを介してCAサーバにアクセスすることになります。攻撃者からすると、攻撃の界面が一つ増えたことになるわけです。ですから、そこについての調査や確認はしっかり行うべきですし、ローカルで低価格で運用している事業者との間で保証レベルに差があってはいけないと思います。その観点からも、慎重に判断する必要があるのではないかと考えます。

満塩委員： ですので、9ページについては、ネットワーク型HSMだけでなく、クラウド内にあるHSMだとしたらとか、おっしゃったとおり、ネットワークだけでなく、クラウドサービスのGUIも含めて、それがどのようにHSMと連携しているかを確認しないと、最終的な答えは出ないと言われると思うので難しいですね。

漆嶌委員： そうですね。全体的な保護施策をネットワークも含めて見てあげないと、クラウドを使っていいかどうかの判断はできないかもしれません。

宮内委員： 現在存在しているクラウドHSMが「良い」となるとは限らず、すべてがダメかもしれないという大前提で議論しているという意味で「このルールは作るけど、このルールに当てはまることはない。結果としてそういうことが起こってもそれは良い」という前提で話していかないと、多分議論が進まないと思いますので、そこだけ確認させてください。

事務局（當波）： 様々な論点をいただいておりますが、今の宮内委員からのご意見に関しては、例えば欧州におけるQSCDの認定基準のように、鍵の生成装置に関する基準があると理解しています。そういったものとどこまでスコープが重なるのかについて、精査が必要ですが、実際に当てはまるとできるかもしれない事業者が一部いるかと考えてはおるところです。これまで議論いただいたところで、全体的に厳しいのではないかというご意見であると理解していますが、その厳しいクラウドHSMの利用に関する実際の需要がどの程度あるのか、ニーズについて改めて議論いただきたいと考えています。

小田嶋委員： 今回、事業者として各社に確認したところ、すべての事業者がクラウドHSMを望んでいるわけではなく、大多数のニーズではありません。しかし、望んでいる事業者については、高い熱意があり、緊急性があるという言い方をしています。

先ほどのセキュリティ観点以外にも、HSM自体の価格の辛さも結構聞こえています。2000年代と全然状況が違っていて、価格も相当高価になってしまっています。②の時にもありましたけれども、実際に変えるとなった時は相当な決断をして採用するということになります。そうすると、今後どういう価格の推移になるか予想はしづらいところもありますけれども、クラウドHSMのメリットとして考えている事業者もあるということだけ申し上げておきます。

事業者は、もともと先ほど皆さんから言われた通り、認証業務用設備室と設備を作りますが、堅牢な施設できちんと運用をするということは大前提なので、クラウドHSMに関しては議論はまだというところです。ですので、急にクラウドHSMが、例えば先ほどのネットワークのところの安全な管理ができているのかというのも含めて、現行の保証レベルと同等とみなされるぐらいのものになるのであれば、あえて道を閉ざす必要はないと思っています。

松本座長： 多分将来的にはありだと思いますが、現時点では厳しいと思いますね。HSMはほぼ一般的になりつつありますが、日本で作っていないですよね。

小田嶋委員： それも少し引っかかっていて、施行当時は国内にベンダーがいて、当該ベンダーから購入することもできましたが、今はないので、国内事業者としては辛いところもあります。

松本座長： そもそもHSMベンダーにとってクラウド事業は最大の顧客であり、クラウド利用者の要件に沿って製品を作っている、という現状がありますよね。ただ、だからといってクラウドに依存して良いのかという別の問題も出てきます。さて、どうしましょう。

宮内委員： 議論の仕方がちょっと難しいですね。

松本座長： 繰り返しになりますが、過去からの定義やPKIのアーキテクチャ、HSMの進化などについては、ほとんど一人ではわからない部分が多そうですね。

満塩委員： 小田嶋委員の話に賛成で、今後技術を理解したうえで整理をし、基準としてちゃんと確認ができるようになれば、やることはやぶさかではないし、その道は閉ざすべきではないですよね。ただ、今は我々が理解するところ、クラウドHSMはまだ色々なところのつながりがよくわからない人は多そうなので、そこが説明できるようになったらOKということですかね。

松本座長： HSMは使いこなすことが非常に重要になりつつあり、電子署名法だけでなく鍵管理の観点も含めて、さまざまな基準がきちんと整理されることが、今後のあるべき社会で、そこが信頼の基点になっているという世界は作られるべき。べき論は言えますが、現実はそこまでわからない。

満塩委員： クラウドHSMを使いましょう、とは言っていますが、繰り返しになりますが、まずは暗号化処理のためにストーリーが重要です。しかし現状を見ると、実際に使っている事例はまだ少なく、例えば米国のSaaSベンダーがクラウドHSMを使ったオプションを提供している一方で、当該SaaSベンダーの日本法人には「それは何ですか。」と聞かれ、「いや、ここに書いてあるじゃないですか」と指摘した経験もあるくらいSaaSベンダーの日本法人レベルでは、クラウドHSMの知識がない状況です。

このように、クラウドサービスベンダー側でもまだ対応が十分に進んでいない状況があるため、正直なところ、ストレージなどの暗号化すらまだうまく機能していない段階です。そうした現状を無視して、いきなりPKIベースのHSMを導入するのは非常にリスクが高いと感じています。おそらく、ステップを踏んで進めることが求められるのではないでしょうか。途中でさまざまな事故や問題が発生する可能性があり、その過程でスタディしながら、次のステップに進んでいけるのではないかと感じています。

事務局（當波） ありがとうございます。最後に事務局から一点確認させていただきたいのですが、先ほどのニーズにも繋がるのですが、今回の検討会ではリモート署名の認定基準はスコープ外としていますが、将来的にこのテーマを議論する際に、再度こうしたクラウドHSMに関する議論が出てくるか、また、その際にクラウドHSMの利用に対するニーズが新たに生じるか、について確認させていただきたいと思います。クラウドHSMといっても少々用途が異なり、利用者の鍵を保管するというところにもなると思いますが、コメントをいただけると幸いです。

小田嶋委員： もともと事業者から要望があった際、リモート署名に関する用途は特に考えられておらず、主にCA用途のHSMに使うことが想定にあったので、8ページ目のニーズの1つ目についても、その時点では利用者が行う署名を目的としたものではなかったと認識しています。ただ、来年以降でリモート署名について検討が進む場合、クラウドHSMが絡む可能性もあるかと思います。しかし、現状ではリモート署名に必ずしもクラウドHSMが使用されているわけでもなさそうですので、この点については、リモート署名の事業者など他の関係者にも確認した方が良いかもしれません。

漆嶌委員： リモート署名の話は、基本エンドエンティティ向けの鍵管理なのですね。共通する部分はあるが、きれいに整理しておかないと、一緒に議論するのはあまり良くないですね。

松本座長： リモート署名の難しい点は、欧州でQSCDの基準をリモート署名に適用しようとしていることにあり、それはエンドエンティティの鍵管理の話で、CAの管理基準とは異なるものです。リモート署名には可用性が要求される一方で、CAについては可用性を犠牲にしてでも守る価値がある、という解釈で成り立っているのが違いですね。

満塩委員： 私が最初に目的を確認したのはそこで、リモート署名はこれまでの議論とは全く別の話で、これまでの内容はどちらかといえばCAの署名についてのものなので、リモート署名は別で議論すべきだと思います。

松本座長： 確かに、クラウドHSMを使ったPKI構築は多分普通に行われており、PKI以外の用途でも広く利用されています。これが認められることで、認証事業者がその競争力を失うとあまりよろしいことじゃないというもう一つの側面があるため、継続的に調査し、認定まで持っていけるかどうかを検討するのが正しい方向性ではないでしょうか。

宮内委員： 運用面は結構難しく、たとえば認証設備室には複数人で入らなければならないなど、厳格なルールが定められています。CAの鍵管理においても同等に考えられているはずですよね。その中で、その部屋に入ることや、一つの部屋に複数のHSMを配置することや、複数の事業者が同じHSMを共有することは、もっと危ないでしょう。こうした状況を踏まえたときに、CAの基準と同等の安全基準を設けることができるのか、難しい課題があると感じています。可能性を否定するわけではありませんが、相当難しいのではないかと考えています。

松本座長： 相当難しいですね。HSMの開発に携わっていないとわからないかもしれません。もともとセキュリティドメインやその中でのセキュリティコントロールが高度なセキュリティ基準が求められてきた分野ですが、日本においてはこの分野がある意味で空洞化しています。

宮内委員： もしかすると、従来のCAの管理基準についても見直して、ここまででいいのかもしれないとか、そういうことを考える必要があるのかもしれません。今回の要件には含まれていませんが、こうした点も含めて今後検討していく必要があるような気がします。

松本座長： 皆さんありがとうございます。次に行きますか。

事務局（北井上）： 今の論点については、おそらく将来的な可能性の話はまた別の議論として、「今年度中にできることをやっていこう」という今年度の検討会の趣旨からすると、相当難しいのではないか、息の長い議論になるのではないかというのが総意ではないかと認識しています。したがって、今年度の本論点の扱いに関しては、今御議論いただいた、見るべき点と考えるべき点と整理すべき点をまとめて報告書に記載し、今後の議論につなげていきたいと考えています。ご議論いただきありがとうございます。

松本座長： ありがとうございます。次いきたいと思います。では、次に④について事務局の方からご説明お願いします。

事務局（當波） 論点④について、事務局より説明させていただきます。論点④は全体的に「遠隔操作」と「クラウドの利用」に関する議論になってございます。その中身といたしましては、まず認証局の保守やサーバの死活監視といった用途で、認証業務用設備を含む認証局の様々な機器に対して遠隔操作が可能かどうか、さらにその概念を拡張して、パブリッククラウドサービスの利用により認証局の一部業務を行えるようにするべきかが論点です。

具体的な観点として、まずは認証局の設備としても様々な種類がある中で、それぞれの設備や機器のカテゴリごとにクラウド化のニーズがどの程度あるか、また認証局の運用においてパブリッククラウドを利用する際の許容範囲や、許容に際しての具体的な措置について議論いただきたいと考えています。また、電子署名法に基づく認定認証事業者に対して課されている規範が、クラウドサービス事業者には適用されない現状において、調査・審査の方法や課題も検討する必要があると考えています。

認証局の設備について、大まかな分類はありますが、現在の書き方が少々複雑で漢字が多いため、皆様にとってイメージしづらい部分もあるかと思います。そこで、もう少しジャンルを整理し直した資料もご用意しております。

また、先ほどの③の議論で取り上げたネットワークのセキュリティについても、パブリッククラウドと接続する際にどのような形でセキュアなネットワーク接続を実現するか、さらにネットワーク自体のセキュリティに加え、UIやログ収集といった点も含めて、どのように安全性を確保するかが論点に挙げられるかと思っております。具体的な論点については、14ページに簡単にまとめてあります。

次のページでは、認証局の業務で用いる設備をAからDに分類して記載しています。この中で特にクラウド利用や遠隔操作のニーズが高いカテゴリがどれか、また事業者だけでなく利用者にとってもメリットがあるカテゴリがあるかどうかについてもご議論いただきたいと考えています。遠隔操作の範囲とその要件についても併せて検討いただければと思います。

AからDに分類した設備例のうち、リモート操作を許容できる範囲については、現在の電子署名法にてオンプレミスで求められる要件を担保できるもの、また、他の基準として、CA/BrowserフォーラムやWebTrust、eIDAS等の基準から大きく逸れないもの、また、クラウド利用にあたって安全なクラウドサービスであることを保証するために必要な基準などについてご議論いただきたいと考えています。

最後に、調査・審査の方法として、クラウドサービス事業者が提供するユーザーガイドや監査報告書を確認するほか、クラウドサービス事業者が提供するログも確認することになると考えています。こうした際に出てくる懸念点についてもご指摘いただければと思います。

こちらが、認証局における設備を4つに分類したものでございます。まず、Aは「認証局のリポジトリにおける利用」であり、認証局の公開鍵やCRL、CP/CPSのPDFドキュメントの公開を含み、これらは利用者以外にも一般に公開されているところです。次に、Bは「利用者の申込みや本人確認のための設備における利用」にあたります。そしてCは「認証局の保守・運用における活用」を指し、ログや死活監視のためのサーバ、また遠隔保守におけるサーバ利用などが含まれます。Cにおいては、サーバの設置と遠隔操作の両面が関わる点もございます。最後にDは、これまでのA、B、Cとはやや異なり、電子署名法の認定基準に基づき保管義務のある帳簿書類の管理に関するものです。ここには、利用者の本人確認書類や申込書、認証局の入退室履歴などの管理簿が含まれ、これらをクラウドで保管してよいか、という分類をさせていただいております。

また、遠隔操作を行える範囲及びその調査・審査の方法については、技術的な基準と調査の方法という二つの基準に基づいて整理しております。技術的な基準につきましては、先ほども申し上げたとおり、通信の安全性の確保、その他の情報設計の担保が含まれます。また、クラウドサービスの利用により可用性の高い構成が求められる点も重要です。例えば、従来バックアップサーバの設置が求められていた用途については、クラウド化する際に二つのリージョンを利用するなど、可用性の高い構成が実現できる可能性があります。これらについてもご議論をお願いしたいと考えております。クラウド利用及び遠隔操作の調査方法に関しては、クラウドの具体的な構成図と実際の運用状況との比較、権限の確認、ログの確認などが主な観点となります。また、利用するクラウドサービスが一定のセキュリティ基準を満たしていること、基準としては、例えばISMAPやISMSのクラウドセキュリティ認証などの外部監査基準を採用し、これらを満たすクラウドサービスであれば、認証局の設備の一部をクラウドに移行させることを許容することも考えられます。

ただし、これらの監査基準や制度においては、それぞれ担保される範囲が異なる点もあるため、特定認証業務においてクラウドサービスに求めるべき範囲やカバーされる制度について、具体的にご議論いただきたいと考えております。また、先ほどのAからDに分類した設備ごとに必要とされるレベルが異なる可能性もありますので、縦横マトリックス的に議論しなければならないところが多くなってしまいますが、活発なご議論をいただければと思います。よろしくお願いいたします。

松本座長： ありがとうございます。なかなか難しい論点が多く、いくつかに分けて議論しないと整理が難しいですね。それでは、まずは次の議題に進めたいと思いますが、まずニーズの方から見ていきましょうか。

小田嶋委員： まずニーズのところを、事業者に確認しました。3「組織管理に関する情報処理」と、4「設備安全対策措置に関する情報処理」は、どちらもニーズが高く、各社1～2番という優先順位でした。一方、1「利用申し込みに関する帳簿書類」と、2「失効に関する帳簿書類」は、現行紙ベースの申し込みが多いこともあり、クラウド利用の優先順位は高くなかったです。とはいえ、一部オンラインでしたり、書類をオンプレで保管することもありますので、もちろんセキュリティの担保が大前提だと思いますが、そういったところも少しニーズはあります。続けてABCのお話もした方が良いでしょうか。

松本座長： はい、行きましょうか。リモート遠隔操作の話は次にしましょう。

小田嶋委員： Aのリポジトリについては、ニーズが高いものになります。可用性が一番求められており、クラウドの利点を活かせるところでもあります。今、事業者は多くの場合、オンプレミスで冗長構成を取っていると思われますが、クラウドに移行した場合、その冗長性をどこまで担保するかについては、クラウドの構成次第といえます。

Bについては、各事業者はオンプレで運用していますが、これもセキュリティが担保されるのであればクラウド移行はニーズとしてあります。5年に1回発生している全データ移行がクラウドの場合はなくなるため、事業者としても負荷が減り、その分が利用者に還元される可能性はあります。

松本座長： ありがとうございます。事業者としてもニーズはあるということですね。世の中ではクラウドファーストと言っている中で、事業者は法律によってクラウド利用が阻まれている状況にあるかと思います。それに対して、実際に監査可能なのか、電子署名法の枠組みに収まるのかといった点については、相当見ないとわからないかなと思いました。

漆嶌委員： ニーズの観点ですが、15ページのAについて、リポジトリの公開部分、特にCDNについては、クラウド対応が望まれるところです。利用者にとって、例えば失効情報が常に利用可能であることが重要です。また、認証局の発行するCRLについても、署名データであるため悪さをしようがなく、どこに置いていても問題がありません。さらに、CPSの公開に関しても、署名されたPDFであれば、これも同様にどこに置いていても問題がありません。したがって、これらのクラウド利用は早急に認めてほしいと感じます。

松本座長： 当然の動きで、署名されていることが非常に重要であり、そのために鍵をしっかりと持っており、もともとがそういうアーキテクチャですよね。

事務局（當波）： CRLやリポジトリに関するご意見をいただきましたが、事務局から一点お伺いしたいと思います。OCSP（オンライン証明書ステータスプロトコル）の場合は、どのような考え方になるかについてご意見いただけますでしょうか。

漆嶌委員： 例えば、弊社の場合ですと、最近OCSPトラフィックが増えている企業では、OCSPレスポンスを事前に生成し、CDNに置いておく方法を取っています。このようにすれば、OCSPレスポンダ自体がパブリックに公開される必要はなく、レスポンスのみをCDNに置くことで検証が可能になります。この方法も一つの考え方かと思います。

松本座長： PKIのアーキテクチャからどうあるべきかを組み立てるのが一番良いと思います。ただ、それに対して今の色々な規定と整合できるのか、できるとこはやるべきだが本当にすべてできるか、まだ論点がいっぱいあると思います。

小田嶋委員： Aだけであれば規定を変える必要はないと考えていますが、いかがでしょうか。

JIPDEC 大澤様： 3C56がありますけれども、そういったところについてどのように守られていくかというところが、今回まさに議論されているクラウドというのが合致している。合致しているとすると、何を根拠にそれを是としていいか。何でもかんでもクラウドとしていいわけではないですよね。そういった時に指定調査機関として何を基準に何を是とするかというところをしっかり議論いただかないと、「OKになりました、では指定調査機関お願いします」と言われても困るので、先ほどからISMAPという話もございますし、ISMAPまで求めないとするなら、どういったところを判断基準にするかの議論が必要と考えます。

宮内委員： 調べると提供などはおそらく指針や方針に書かれておらず、審査基準にしか書かれていないのが今の実態です。そういう種類のものだということを、認識しておいていただいて、今の審査基準を除いた部分では、これを直接に保たれる情報は多分なさそうです。

小田嶋委員： 私もその理解です。

JIPDEC 大澤様： 調査表に書かれていることは方針には書かれているのですけどね。

宮内委員： 方針にかかれていましたっけ。あまり書いていなかったと思います。

松本座長： 前回の議論とも繋がりますが、もともと電子署名法は2001年の施行当時、その基準内ですべてを完結しようとしていました。当時は他に大きな基準がなかったためですが、並行してISMSの議論もありました。現在は多くの基準が存在しており、そうした基準を活用して担保する方向に向かうと思います。ただ、その基準と電子署名法が整合可能かについては、私もよくわからなくて、JIPDECさんもしかしたら一番汗をかかないといけないかなと思うのですけど、どうなのでしょう。JIPDECの基準ではないですよね。

JIPDEC 大澤様： 必ず調査表の適合例を修正する際には、主務省庁に確認し、内容についてご承認いただいています。

宮内委員： こうやって調査していますよって指定されているのですね。

満塩委員： ご参考までに、ISMAPを政府機関のシステムに適用する際には、公開情報である機密性レベル1については適用が不要で、可用性だけを確保する形になっています。そのため、どのように判断するかが問われるわけですが、機密性レベル2を適用する場合ISMAPの管理基準150個程度を満たすことが必要とされています。感覚的に言えば、Aは公開情報なので、特段の規定がなくても問題ないかもしれません。一方で、BとDについては、おっしゃる通りセキュアな環境を保つために、最低限レベル2の基準が必要になります。ISMAPであるかどうかは別の話とし、何らか規定があって、それを守るべきというのは、提供の仕方が分類できると考えます。

松本座長： 先ほどのHSMを守る話と比べると、一般的な情報という話にほぼ近いので、今の世の中の枠組みを利用するのが、おそらく正しいのではないかと思います。

JIPDEC 大澤様： 認証局のハッシュ値の公開についてはどうしますか。
認定認証業務のハッシュ値について、認定認証事業者のリポジトリでCRLやCP/CPS等と共に公開されており、それは改ざん防止と特定認証業務を特定できる措置が取られています。

松本座長： その話は本当は論点の一つにすべきことですね。

JIPDEC 大澤様： 事業者としては、CRLやCP/CPSとは異なるところに認証局のハッシュ値を公開するとなると、コストが別にかかってしまうので、それを無視して議論していいかということを気にしています。

満塩委員： 今書かれているものは大丈夫だと思いますが、ハッシュ値が官報に書かれたものの話をしていますか。

JIPDEC 大澤様： 認証局のハッシュ値は認定時や鍵更新の変更認定を受けた際に官報で公開されますが、官報は一定期間しか確認ができないので、CRLやCP/CPSの横にある形（リポジトリ）で公開されているというのが一般的ということです。

満塩委員： 横で良いのかという議論の方が大事ですよね。だめではないが、絶対に横になければいけないかというと違います。あの時も、本当は「国ルート」を作った方がいいという意見がありましたが、やっぱり難しいという話になり、結局その議論はそこで終了した経緯があります。

宮内委員： ここに表示されているのは官報が正本で、それは写しですよね。写しだからふわっとなってもいいという形です。

満塩委員： あるべき姿は今おっしゃったように官報は原本です。オンラインであるべきなのは、どちらかというと所管省庁の方で、多分「これが自分のものです」と言われても、感じじゃないですか。

宮内委員： タイムスタンプのものは、一応手元が総務省のHPにあります。そういうのをイメージされているということですね。

満塩委員： そうですね。今も認定認証業務のサービス名までは書いてあるじゃないですか。あれの横にあるのが本当の意味でのトラストだと思いますが、利用者のとこに置いとくのは、単なる便利のためですよね。

JIPDEC 大澤様： ただ、現状としてはどうなっているかというと、利用者さんは、自分が発行を受けた電子証明書のルートをたどる際に、認定認証事業者さんのリポジトリを見ている、というのが運用自体としてはある意味現実です。長い年月をかけて出来上がってしまった仕組みです。

満塩委員： 法律上いけないとは言っておらず、今までそこにあったことが必須でもなかったと理解しています。そこを引き続きやってもいいけど、それが要件にはならないです。それがどこにあるべきかは別の話ですよね。

宮内委員： 法令には、特にどうしようと書いておらず、色々な方法で出してあげなさいと書いてあるのですよね。

松本座長： 電子署名法とGPKIの話がごっちゃになっているかと思います。GPKIは相互認証するので検証する手段はありますけど、それ以外とかGPKI枠組みを超えた範囲でだんだん国際相互認証も含めて考えないといけなくなっているので、そもそも日本としてのトラストリストをどうするかというのは、今日の論点よりも重たい論点です。

時間がないので遠隔操作の話に参りましょう。遠隔操作についても、これも対象が何かによって話が変わると思っています。遠隔操作はある意味で危険な話でもあって、昔のデジサートのインシデントのように、それ自体が攻撃対象になることもあります。そもそも遠隔操作で何をやるのかという点が明確でないと、ニーズがいろいろあるのはわかりますが、議論が収束しないのではないかと思いますが、いかがでしょうか。

小田嶋委員： 大前提としては、保守に使います。クラウドに置くということと分けたほうがいいと思っています。昨年度の調査報告書では、保守で行うこと、となっていますが、基本的にはオンプレでやることになってはいますけれども、クラウドには保守に使われているものも用意されていますし、認証局の人的負担とシステムに関する負担が軽減される可能性があります。どの設備を保守するかによって、また話が違ってくるところだと思います。基本的には、先ほどの点に関してクラウドで保守するというわけにはいかないだろうと考えています。一方で、Aに関してはそういうものでもいいじゃないかと思います。

松本座長： 保守は監視も含まれます。ログ収集とかをアウトソーシングしたい話でもあります。クラウド化するって話と、それをリモートから監視するという話がありますよね。

満塩委員： おっしゃる通り、保守や死活監視の範囲を定めた方が良いですよね。範囲はBとかDの保守ということであって、秘密鍵の話ではないです。ということは、私はありだと思っています。例えばBとかDを今クラウドでやるという話になるわけですから、Cについては同等の要件が付与されるかもしれませんが、接続方法については後ほど検討するとして、やっていいと思います。逆にログなどについては、違うクラウドを使わなくてもいいのでしょうか。これは同じクラウド内での運用を想定していて、死活監視サーバも同じベンダーのクラウド内に設置するということですか。その場合、リモートも何もない気がしますが。あと遠隔の保守はこの先に部屋があって人がいますか。

小田嶋委員： 死活監視サーバの場合は、業務と保守が別のクラウドの可能性もあります。

事務局（當波）： 今御意見でおっしゃっている別のクラウドというのは別のCSPというわけではなく別のリージョンのようなところを含むという理解でよいでしょうか。その前提で、現時点で他のクラウドを利用することは想定されておらず、今の認証局の業務については引き続きオンプレで実施する予定で、ただし、オンプレで死活監視サーバを置かず、監視サーバのみを別の設備に配置し、どちらも同時に停止しないようにする案も考えられます。現状ではその部分まで踏み込んだ議論は行われていなかったかと思いますが、死活監視サーバと設置されている設備が同時に停止する事態は避けたいというご懸念は理解していますので、実際の構成としてそのような対策が採用される可能性は高いと考えていますが、これを基準とするか否かについては、もう少しご議論をいただきたいと考えております。

漆嶌委員： 最近では、死活監視をSaaSとして提供する企業も増えてきており、そのようなサービスを利用することで保守の負担を軽減することは、当然考慮されるべきだと思います。また、そのようなSaaSの利用を妨げない制度であることも必要があると思います。

松本座長： アウトソーシングサービスをうまく使ってコスト削減ができるような仕組みです。365日24時間サービスをしないといけないところに対してのコストの問題はありますよね。

満塩委員： 一瞬考えたのは、死活監視サーバと監視対象サーバの可用性を高めるのであれば、通常は分離するのが普通、ということでしたが、認定認証の要件としては、どちらでもあり得るかなと感じました。独立性という概念にも色々な考え方があり、例えば異なるCSP間での独立性や、同一リージョン内であってもアベイラビリティゾーンの違いによる独立性が挙げられます。そういった意味で、複数のレイヤーが存在するため、どのアプローチを取っても認定認証業務には特段問題がないと考えています。

事務局（當波）： 現状、オンプレで運営されている認証局において、ログの監視や死活監視を行っているサーバは同じ場所にある場合が多いと認識しています。そもそも、現行の基準ではその分離を求めていなかったため、クラウドの場合は新たにその要件を求めることになるのか、という議論になっていると考えています。

漆嶌委員： やはり、一つ一つについて「これは良い」「これはダメ」と判断する必要があるのだろうと思っています。先ほどの議論では、保守についてはクラウドを使っても良さそうだという雰囲気になりつつあるように思いますが、そこには危険な側面もあります。例えば、リモートで運用保守を行う際には、通常「ランディングサーバ」を経由して、例えばHSMの設定を行うといった手順が一般的です。このランディングサーバが脆弱だと問題があるため、どういうケースであればクラウド利用が良いけれど、ここではダメという点について、リストアップして整理する必要があると感じています。

松本座長： 確かに乱暴な議論になってしまいます。保守はバックドアになりやすい話でもありますからね。

漆嶌委員： 外から入るのはあまり良くないが、例えば監視のためのエージェントが内部に設置され、外部に対して状態を送信する形であれば問題ないので、こうした観点も整理して、「これは良い」「これはだめ」といった基準を決めていかないと、なかなか難しいと感じています。

宮内委員： 先ほどのお話で、オンプレと同じかというと、オンプレの場合は自分のところなので状況が割とすぐわかるわけですよね。でも、クラウド上のどこかで止まってしまった場合、それがすぐにわかるかというと話は別で、やっぱり全く同じとは言えないなという感じがします。

松本座長： 多分④に関しては、一般論としてクラウド利用を認め、遠隔操作といって良いのか分かりませんが、それもセットで進めていく方向性になるのではないかと思います。ただし、すべてをそれで良しとするのは少し乱暴で、精査が必要な部分もあるのではないかと感じています。

満塩委員： VPN接続については、正直あまりイメージが湧かなかったのですが、例えばアベイラビリティゾーンの問題であれば、それはアベイラビリティゾーン間の同期設定の話になりますし、CSPが違う場合でも、最近ではインターネットを介さずに閉域網接続を使うのが一般的ですね。それとVPNについてですが、通常は専用の装置が基本だと思うので、クラウド間でVPNというのはあまり聞かないと感じています。そういう意味では、インターネット経由での接続は、できれば避けたいと思っています。それから、下の認証の援用についてですが、例えばISMSを取得したからといって、すべてがOKというわけにはいかないと思います。同じエビデンスやテストケースを援用する可能性の議論はありますが、それもまだ結論が出ていない段階ですね。SOC2やSOC3についても、全く同一とは言えませんが、中身のエビデンスを利用することはあり得ると思います。

事務局（當波）： 議論が非常に盛り上がっておりまして、今事務局の方でも論点⑤と⑥をメール審議にするかどうか、どう進めるかを議論していたところです。まだ④の議論については収拾しそうにないと認識しておりますので、もうしばらく議論いただいた後で、時間の許す限り⑤と⑥を進め、時間が足りなければ次回に回すか、メール審議にさせていただければと思います。

また、③と④の論点については、次回までに今回の議論を整理し、レベル分けを行う予定です。例えば、先ほどのAの部分については、可用性だけが求められる箇所であるため、すぐに対応できる箇所であること、認定基準を変更するというよりも適合例の整理であるといった方向性で整理できるかと思います。Cについても実現の方向性が見えつつありますが、今回出た論点を整理してお示しできればと思っています。

結論を出すにあたって、早急に採用できる箇所については理由を補完する意見をいただき、さらに議論が必要な箇所はその意見を深めていただき、また次回までに整理が必要な箇所についてはコメントをいただければと思います。まだBとDについて伺っていないようですがいかがでしょうか。

漆嶌委員： BとDの部分についてですが、少し気になる点として、これらには個人情報が含まれている箇所があります。クラウドに移行した場合、その個人情報が適切に管理されているかどうかを確認する必要があるのかどうかについて、委員の皆様や事務局の方からもコメントをいただきたいと考えています。

松本座長： 個人情報については、クラウドで提供されているサービスにおいても当然求められるものであり、電子署名法の認定事業者が他と異なるとは思えないですよね。

満塩委員： そういう意味では、個人情報や企業秘密に関しても、機密性を保つものであると考えています。そうすると、おっしゃる通り、BやDに対しても何らかのセキュリティが必要であるという認識です。確かに、今までの認定認証業務上では特に否定されていなかった点ではありますが、オンプレの場合は設備で担保されていたので、その意味ではクラウドと少し性質が異なるように感じます。

最終的には、ISO/IEC 27000シリーズを参考に整理することが必要かと思います。例えば、ISO/IEC 27002がオンプレを前提としたものであるとすれば、クラウドの安全性を担保するISO/IEC 27017を何かしら参照すべきだと考えています。そうなると、ISMAPやISMSのセキュリティ基準とほぼ同等のものになるため、どのようにチューニングして最終的にどれを要件とするかですよね。

松本座長： BはRAに関する内容でして、RAは電子署名法においても一定の水準保証レベルを担保しなければならない部分でもあるので、そこの意識が高いのかなという気がしています。

小田嶋委員： 今は、基本的には紙の申請が多く、住民票の写しや印鑑登録証明書などを扱っています。そのため、いわゆる帳簿書類の保管に近い動きがあるのかなと思います。Bについては最初の申し込み部分に該当し、基本的にはWebで入力して、それを印刷して扱うケースが多いです。こうして取得したデータをどのように管理するかがポイントとなりますが、個人情報保護法令に従って、適切に管理するということで良いと思っています。

満塩委員： 一つだけ追加したいのは、スライド12でも触れていますが、登録用端末設備があることは要件に含まれていますが、それに加えて人間がそこで活動することも想定されている点です。逆に言うと、ISMAPやISO/IEC 27017はコンピュータに関する要件を対象としているため、人の活動に関する要件は含まれていません。しかし、そこに人が関与するのであれば、従来の要件を使った方が良いかもしれません。結局、クラウドの管理端末をどこで操作するかという問題に関わるのかもしれませんが、これまでは人が関与して審査する場合に要件がかかっていたため、同等の要件が必要になるかもしれません。一方で、もしそれが自動化されているのであれば、その要件は不要かもしれない、ということです。

事務局（當波）： 今、自動化に関する論点にも繋がるというご意見をいただきましたが、一部の事業者ではマイナンバーカードなど、人があまり介在しない方法で本人確認・身元確認を行っている事業者もありますので、そういった場合には、このBの部分をクラウド化する需要が高まるのであろうという。

松本座長： Bは自動化と非常に関係がありますね。

事務局（當波）： 本日のところは、一旦ここまででよろしいでしょうか。もし次回までに整理が必要な点があれば、今のうちにご意見をいただければと思います。特にご意見がなければ、このまま⑤の方に移らせていただきたいと思いますが、いかがでしょうか。

松本座長： 次行きましょうか。はい、では④はここで終了し、⑤に移りますね。次は少し観点が異なりますが、⑤に関して事務局の方からご説明をお願いいたします。

事務局（山之上）： 資料1の17ページからご説明させていただきます。課題⑤につきましては、昨年度の検討内容としまして、認定認証業務に関して、電子署名利用者の真偽確認及びこれを踏まえた利用申し込みの許諾決定について、従前は自然人による必要があるものとして運用されておりましたが、技術動向や利便性向上等の観点から18ページにも記載している通り、昨年の帳簿記入を含めた自動化を認める旨、指定調査機関であるJIPDEC様より通知文を発出させていただきました。現在、この通知文によりまして、認定認証事業者の皆様にはご対応いただいておりますが、明確化の観点の方から所管官庁名の文書の方に記載する必要があるという旨で、今、議論の方がございました。これを受けまして、本検討会での議論の方針としましては、所管官庁名の文書へ記載するために適切な規定を設ける必要がございまして、自動化の具体的な適合例について情報収集を行う必要があるというところから、課題5につきましては、ニーズの把握について議論いただきたいと考えております。

議論いただきたい内容としましては、マイナンバーカードを使用時等の身元確認の結果を受けた諾否の自動化の適合例として、どのようなものがあるかという点でございます。具体的に申し上げますと19ページの方になりまして、現在、認定認証事業者であるmy FinTech株式会社様の方が、サービスにおいてはLRAによる利用者の真偽確認が必要な業務について、新規発行など業務の自動化が実装されているというところでございます。20ページ目に記載しておりまして、従前におきましては申し込みの諾否の決定や証明書の発行指示について自然人が行っておりましたが、現在は申し込みの諾否をシステムで自動決定するなど変更されておりまして、自動化による事務削減の方が出ているところでございます。21ページの方に記載しています通り、こちらの論点詳細の部分によりまして、委員の皆様の方にご議論いただければと考えているところでございます。事務局から説明は以上となります。よろしくお願いいたします。

松本座長： 以前は、そもそもマイナンバーカードが発行されていなかったので、認定事業者としてはあまり興味がなかったかもしれないですが、マイナンバーカードがある意味で強制的に普及された状況の変化がある中で、一番効率的なeKYCを実現できる手段としてマイナンバーが浮上してきたわけですが、そこがグレーだったということでしょうかね。

満塩委員： 先にコメントしておくと、従来のルールでは、人間が必ず関与するというプロセスが前提になっていました。だから、自動的な判断がやっと出てきたなという印象です。私は特に違和感はなく、進めた方がいいと思います。事務局もほぼ同じ理解かと思いますので、別途検討している本人確認ガイドラインとの整合性を取ることが必要、というところだけコメントさせていただきます。

事務局（當波）： ありがとうございます。もともと、この電子署名法の利用者の真偽確認のところについては、例えば本人限定受取郵便の基本型ですとか、署名用電子証明書、または既に利用者に発行されていて有効期限が切れていない認定認証業務の電子署名がされているものなどを受け入れる形にしておりますので、基本的に自動化を実施する際は、この署名用電子証明書か、有効期限内の特定認証業務の電子証明書による電子署名、この二つに限られるものという認識です。それ以外の方法はおそらくないかと思います。本人確認ガイドラインの議論もこちらに反映させるところがあるかもしれませんが、すでに方法がこの自動化の論点に関してはかなり絞られておりますので、本人確認ガイドラインの議論を反映させる場合には、自動化ができるオンラインにおける本人確認に限らず、電子署名法における利用者の本人確認全体の議論にも関わる話になるかと思います。

満塩委員： 想定しているやり方が本人確認ガイドラインと矛盾していませんよね、という確認をするだけのレベルで、逆に言うと、今検討しているものではなく、従来の中で多分言えると思っています。だから、それはそれでいいと思いますので、それだけですね、というのが私の認識です。

松本座長： 電子認証局会議で議論されているのでしょうか。

小田嶋委員： すでに議論はされており、特にはないと思っています。

松本座長： 議論としては、今後他のやり方もあるかもしれません。自動化に向かって、もしかしたら急速に色々なものが進んでくるかもしれないので。

小田嶋委員： システムで自動化できれば、事業者負担が減りますし、利用者への還元ができます。

漆嶌委員： 方向性としては、マイナンバーカード使うってすごくいいことだと思います。ただ、どういう方法で本人確認したかというのは記録としてちゃんと残るんですよね。例えば、マイナンバーカードで失効申請しました、とかは全部残る認識です。

松本座長： ちょっと私が気になる点があるとすると、利用者の申請が、申請の文書といいますか、その同意の文書がちゃんとしていて、それに対して同意をしたのかというところですよね。証明されたものについて、利用者が認識のないまま行っているのではないか、ということです。

漆嶌委員： 例えば、ボタン操作で何かを行ったとしても、それが本当に正しい申請であるかどうかですよね。

松本座長： 事業者側には証明したというエビデンスはあると思うのですが、その申請者自身が本当にその内容を認識しているのか、という点が少し気になるところです。何も決めないと、そういう問題が起きます。自動化はやるべきですが、人が確認すると必ずヒューマンエラーが出る。しかし、自動化すると、それが攻撃の対象になりやすいという問題もあります。そこに何も規定がないのは若干問題があるかなと。今、例えばWebPKI等もそうですが、人手が関わって時間がかかれば、その分攻撃対象にはなりにくいですからね。

宮内委員： 確認すべき情報についてはもちろん規定があって、問題になっているのは、「人でやれ」と書いてあるわけじゃないのですよ。帳簿に書くときに「誰がやっているか」を書けと書いてあるのです。こういったことが規定上の問題点とされています。ですから、今は「ちゃんとやっているかどうか」というところではなく、やるべきことはきちんと行われていて、その上で帳簿にどう書くかが規定上の問題になっているという点をご理解いただきたいと思います。

漆嶌委員： これ、アプリで例えば申請とかができるって話が書いてありましたが、例えば公式アプリだけど、不正なコードが仕組まれていて、失効したつもりじゃないのに、他の申請がなされていた、みたいなことがないことをどう担保するかという観点ではどうですかね。

松本座長： ここでは現状問題ないかもしれないけど、これからの自動化で、そういうリスクは増えていく気がしますよね。多分、世の中はスマホですべて完結する方向に一気に進んでいる状況ですから。

宮内委員： アプリケーションの問題ではないのですよ。今おっしゃっているのは、スマホを使う際に、うっかりサインしてしまったら、それで重要な手続きが完了してしまうということですよね。カードをかざすとか、実印を押すとかといったようなことと同じようにやっていいですかということです。人は認識せずに大事なことをしてしまう恐れがありますから、これはアプリケーションだけの問題ではなく、とても大きな問題だと私も思います。

JIPDEC 大澤様： ⑤として取り上げられているのは、マイナンバーカードで署名を行うケースです。一方で、利用者の秘密鍵を認証局が生成する場合には、ICカードの発行後にICカードを受領したことについて利用者から受領書を受領したり、失効の申請が電子的に行われる場合があります。その際における、利用者の真偽の確認の手続きは機械化が進んでおり、いくつかの事例では自動化が実際に行われています。そのため、方針の中で第6の1．(1)と(2)に関して、システムによる自動的な受領および実施を許容していることを明示する文言に修正することが必要である、ということを昨年度の報告書で宮内先生にご提案いただきました。

松本座長： そうそう、今回の論点ではないですが、署名者の環境については何も規定していないから、そこが確かに問題なんですよね。もしかしたら危ないのではないかという話がどうしても出てくるわけです。これは今回の論点にはできないですが、どこかで解決しないといけない問題です。

満塩委員： しかも、この話は第3条との関係性も出てくるので、「第3条でこういう環境じゃなきゃ認めない」となってしまうかもしれません。それで本当にいいのかという議論にもなってしまいますからね。

宮内委員： 難しい問題ですよね。そもそも実印の管理をこうしろと定める法律がないのと同じように、秘密鍵の管理も、本来は責任の観点からいえば、ユーザー側で行うべきであって、国や認証局が管理するものではないはずだというのが大原則です。ただ、そうは言っても、放任すると何が起きるかわからないため、ある程度認めて対応していこうという考え方もあります。しかし、そうするならば、どこまで個人の行動に介入するかをしっかり考えなければならず、非常に難しい問題だと感じます。今日の会議や今年度の検討で解決できるかはわかりませんが、認定認証業務が親切に「こうしろ」と規定してあげること自体は構わないと思います。ただ、認定認証事業者が「こうしなければならない」となると大きな問題です。ですので、この問題は非常に大きなテーマだと思います。

松本座長： my FinTech 株式会社がやっているのは良いとしても、残る課題がある点が重要ですね。

宮内委員： 今言っている件についてですが、マイナンバーカードで署名されたことを機械がチェックしているわけですよ。それを人間が一回「OK」を出さなきゃいけない、ということになっているわけですよね。こういうのって馬鹿げているじゃないですか。それはなぜかというと、「誰がやったか書け」と規定に書いてあるから、そうしなきゃいけないんです。これ、馬鹿げていますよね、というのが今回の論点の発端です。だから、これはちょっと適当に条文を入れて、ちゃんと処理が行われているなら、その人の名前を書かなくていいことにしましょうかね、という話になっているわけです。

満塩委員： ようやく氏名に読みがつくようになりましたよね。これで、より正確に識別できるので、自動判断がさらにしやすくなるわけです。つまり、文字情報だけで判断する必要がなくなったため、自動化が進む理由としても大きな意味を持つと思います。

松本座長： さらにはエビデンスもより正確に残るって話ですよね。では次に⑥について事務局から説明をお願いします。

事務局（山之上） 資料1の22ページからご説明いたします。課題⑥についてですが、現行の電子署名法施行規則では、利用者が利用者署名符号を作成する場合、利用者の申し込みと同時に利用者署名検証符号を送信する方法が規定されておらず、利用者識別符号の交付または送付が必要です。利用者と事業者双方の負担軽減のため、公的個人認証法施行規則で認められている「同時送付」を可能にすべきであると考えています。また、電子署名法と公的個人認証法では、認定にかかる調査方法に差異があるため、方法の統一には電子署名法の認定手続きの方法の変更が必要となる可能性があります。

これを受け、本検討会での議論の方針として、公的個人認証法の施行規則の方法に統一する必要があるか、またその方法を追加する場合、電子署名法の特定認証業務をどのように変更するかについて検討が必要です。具体的には、公的個人認証サービスでは利用申し込みと同時に検証鍵が送付されますが、電子署名法の認定サービスでは利用申し込み後に利用者識別符号を郵送等で送付し、利用者から検証鍵を再度送付する方法が取られています。

24ページの背景には、施行規則第6条第3号の改正があり、当初は認証事業者が利用者署名符号を作成することを想定していましたが、その後、利用者が自ら作成した鍵ペアのうち、検証符号を認証事業者に送信し、電子証明書が自動的に作成されるケースも増えたため、平成15年にこのビジネスモデルに対応するよう認定基準が整理されました。その後、公的個人認証法が制定されましたが、電子署名法の技術基準が改正されず、現行の規定が維持されています。27ページの論点詳細をご参照いただき、課題⑥に関して委員の皆様には事務局の検討内容についてご議論いただきたいと考えております。事務局からの説明は以上です。よろしくお願いいたします。

松本座長： 電子認証局会議は認識されているのでしょうか。

小田嶋委員： はい、内容もわかっています。事業者が多くないので、現行の人たちに大きい影響を及ぼすわけでもないと思っていますが、個人的には違和感あります。

満塩委員： 右と左の絵があって、右側のICカードは誰が配っているのですか。左側のものは政府機関が配っているわけですが、右側のICカードのスペックはどうなっているのでしょうか。これがどういう通信をするのかによって、通信も含めてシステム全体がちゃんと管理されているか、つまりICカードやアプリのところがきちんと管理できているのか、というところが論点になりそうです。単純には同じにした方が良いとは思いますが、マイナンバーカードはスペックがコントロールされていますので、そことの差異も確認した方が良いかと思います。

宮内委員： 大前提として、この施行規則第26条というのは、公的個人認証法の第17条第1項第5号の認定をするための規則ですよね。要するに、特定認証業務がこういう条件を満たしていれば良いというもので、その条件の一つが、電子署名法の認定認証業務の規制と少しずれている、ということを言っているわけです。ただ、この絵がちょっとよくわからなかったのですが、実は条文の方は特におかしなことは言っていないかと思います。もともと有効な証明書というのは、JPKIか認定認証業務のもので、その証明書に基づいた署名をつけた申込書が提出されると、「証明書を発行してください」という依頼が来るわけです。その際、「私の公開鍵はこれです」と書いても良い、ということを条文では言っているわけです。つまり、5号認定と認定認証業務の差分になっている、ということですね。

JIPDEC 大澤様： この議論の元になっているのは、25ページのスライドに関する内容だと思います。「利用者識別符号を必ず送らないといけないのか。」という点に対しての議論がありました。その手続きとして、公的個人認証法施行規則における“イ”の方法が考えられるのではないか、という話だったと理解しています。つまり、すでに国から認定を受けた認証局から発行された秘密鍵を利用者が持っているにもかかわらず、利用者識別符号を送らなければならないという仕組みについて、疑問が生じるわけです。“イ”の考えを取り入れたいところですが、施行規則第6条第3号の2にはそのように書かれていないため、事業者としてはわざわざコストをかけて利用者識別符号を送る必要が出てきてしまっています。

松本座長： これもマイナンバーカードが普及したのでという話に近いですね。最初の信頼の起点がなかったのですね。

JIPDEC 大澤様： どこまで何を確認すればいいのかというのが課題ですね。電子化された仕組みが導入される前は、紙の手続きによって認証局の担当者が「確かに実在する利用者であることを確認しましたね」という事実が、紙面により直接確認できて、認定基準を満たしている要件の確認ができていました。確かに時間はかかりますが、確実に証跡の確認が行えたわけです。しかし、今は電子化されて、調査の中で指定調査機関と事業者が手探りで進めている状況です。利用者の発行や失効の意思表示や、失効されていない有効な電子証明書に紐づいた秘密鍵で電子署名されていることの確認が、アプリケーションのログやデータベースのテーブルに格納された情報等によって証明される（確認する）形になっています。また、先ほどの❺の要件にありました「責任を有する者の識別に関する情報」も記録されていて、こちらも確認する必要があります。そうした状況下で、事業者とすり合わせをしながら、なるべく多大なコストをかけずに必要な調査情報を確認する方法を模索している段階です。事業者ごとに異なる面もあるため、個別にすり合わせが必要になってくることもあります。ですので、こうした仕組みを採用するのであれば、少なくとも「こういったことは確認しないとダメだろう」といったところまで議論いただけると助かります。

宮内委員： 「本当に人が絡んでいなくて大丈夫なの。」って言われた時に、「はい、大丈夫です」と言い切れるかどうか、という問題ですよね。大丈夫そうだけど、誰が「大丈夫」と言い切れるのでしょうね。

松本座長： WebPKIのようなシステムでは自動発行が当たり前になっていますが、その確認手段としてはCTといった方法が使われています。これは自動的に確認を行う仕組みですね。

満塩委員： 統計とサンプリングですね。全体像をつかむためには、まず件数だとか「何個あるのか」、全体像に矛盾がないか、「どんな人が含まれているのか」に矛盾がないかを確認しつつ、サンプル的にいくつかを見てみる、といったことですね。

JIPDEC 大澤様： 紙の場合でも電子の場合でもですよね。

宮内委員： JPKIでサインされた申込書が来た時にそれを人が見て、「それはちゃんと画面に正しい情報が出ているか」等、そういうことに関して、どこかでちゃんとチェックしなきゃいけないが、「人が見れば大丈夫」というわけじゃないし、「機械が正しいから大丈夫」とも言い切れないわけです。これはおっしゃる通りだと思います。

JIPDEC 大澤様： 失効確認はJ-LISさんも絡んできます。認証事業者さんと利用者さんの間だけで閉じていないのですよね。OCSPレスポンスのところも含めて確認させていただいて、確かに調査対象として確認すべきたサンプリング・データについて、事業者さんとJ-LIS間の通信結果についても、正しくデータベースなりログから検証できるという状況を、確認させていただく必要があります。

事務局（當波）： よろしいでしょうか。ここの⑥のところは様々なご意見をいただいているところで、これをさらに掘り進めるほどの時間が本日ございませんので、本日議論した③から⑥までの論点、また前回も議論いたしました①②のうち、さらに掘り進めるところがあれば、整理をした上で、第3回、次回の検討会にまたお示しをさせていただければと思います。

松本座長： 最後の議事3について、事務局からご説明お願いします。

事務局（山之上）： 事務局でございます。資料の28ページの方でご説明させていただきます。本日は11月1日ということで、第2回検討会を開催させていただきましたが、第1回検討会および本日の検討会を踏まえまして、事務局としましては第3回検討会を開催させていただきたいと考えております。日程の方は11月26日を予定しております。

第3回検討会で議論いただきたい内容につきましては、事務局の方で一度整理させていただき、委員の皆様に再度ご連絡させていただければと考えております。第3回検討会を踏まえ、第4回検討会を開催し追加でご議論いただくか、または報告書をもとにこれまでの検討内容の振り返りとさせていただくかについて、改めて判断させていただければと考えております。本日はありがとうございました。

松本座長： 今日は皆さん、活発な議論どうもありがとうございました。次回もよろしくお願いいたします。
 
（参考）メールでの追加コメント
小田嶋委員： 令和5年調査研究からパブリッククラウドというキーワードが使われて、パブリッククラウドだけが対象との誤認を受けます。必要なのはクラウドサービス事業者の情報公開の姿勢であったり協力体制であって、パブリックであることは要件とは直接は無関係でありプライベートクラウドを否定するものではございません。むしろ、プライベートクラウドであれば、データが国境を超えることの懸念がなくなるのではないか。令和5年度最終報告書にも「プライベートクラウドを否定しない」と、報告されております。

CAシステムに対する遠隔操作の件でクラウドに遠隔操作でサーバの監視を行うランディングサーバが置かれているケースがあり、それにVPN接続し使用する使うことを想定するかのような議論がございました。しかし現実には、インターネットとは物理的に独立した監視ネットワークが設置され、当該ネットワークを利用して (ある意味裏側から当該) 監視ネットワーク上のランディングサーバに外部からVPN接続してCA死活監視を実施したり、ログを採取したりすることが行われます。実体がクラウドに合っても、クラウド外の監視ネットワーク側から論理的なクラウドに対して行う場合もあり、監視ネットワークがクラウド内インターネット側に存在しているのとは議論が異なります。令和5年度の最終報告書の遠隔操作の部分は、このような監視ネットワークがあることを意識した内容になっております。

クラウドHSMのサービサーにはパブリッククラウド(AWS,Azure,Google）が提供するほか、HSMベンダー提供クラウドHSM（Luna Cloud HSM Services）が存在し、当該サービスは多機能を有している。HSMベンダー自身によるサービスで、同サービスが公開された時点でFIPS140-3やCCの認定が保証されていると想定される。実サービスとして以下が挙げられます。
①タレスのクラウドHSMを使ったデータプロテクションサービス
また、HSMの議論をするにあたって、HSMベンダーであるTHALES社のHSM製品の例として以下に示します。
②ネットワーク接続型HSM
③USB接続型HSM
④PCIe内蔵型HSM

漆嶌委員： 利用者真偽確認(本人確認)をマイナンバーカード(公的個人認証証明書)で行い自動化するという方向性は会議の場でも合意され、私も同意ですがいくつか懸念点があります。

懸念1：紙や対面による申請と違って、設定や仕組みや操作の流れが複雑であるため、例えば高齢者やスマホの操作に慣れない者、身体障害者などが自分では意味や操作が理解できず、代理の者(親族やまわりの詳しい人)が行ってしまうケースがあると思われ、それをどこまで許容するのかは慎重に精査する必要があると思います。例えば、老人のマイナンバーカードを使って代理の人のスマホに発行された証明書と鍵が格納され、以降本人の同意なく署名できてしまうといったことが無いような対策などが必要と思われ、さらなる議論が必要です。

懸念2：本人確認をどのような方法で行ったのか、鍵を格納した端末の情報などは記録に残すなど、何をエビデンスとして残し、監査対象とする必要があるかはさらなる議論が必要です。

以上のことから、マイナンバーカードによる本人確認は概ね賛成ですが、今後もさらなる検討、審査内容の詳細化などを進める必要があると考えます。

以上