JP2022151190A - 業務監査支援システム及び業務監査支援方法 - Google Patents

業務監査支援システム及び業務監査支援方法 Download PDF

Info

Publication number
JP2022151190A
JP2022151190A JP2021054141A JP2021054141A JP2022151190A JP 2022151190 A JP2022151190 A JP 2022151190A JP 2021054141 A JP2021054141 A JP 2021054141A JP 2021054141 A JP2021054141 A JP 2021054141A JP 2022151190 A JP2022151190 A JP 2022151190A
Authority
JP
Japan
Prior art keywords
organization
node
certificate
distributed ledger
held
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2021054141A
Other languages
English (en)
Inventor
崇之 永井
Takayuki Nagai
洋司 小澤
Yoji Ozawa
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2021054141A priority Critical patent/JP2022151190A/ja
Priority to PCT/JP2021/030905 priority patent/WO2022201581A1/ja
Publication of JP2022151190A publication Critical patent/JP2022151190A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09C—CIPHERING OR DECIPHERING APPARATUS FOR CRYPTOGRAPHIC OR OTHER PURPOSES INVOLVING THE NEED FOR SECRECY
    • G09C1/00—Apparatus or methods whereby a given sequence of signs, e.g. an intelligible text, is transformed into an unintelligible sequence of signs by transposing the signs or groups of signs or by replacing them by others according to a predetermined system
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Figure 2022151190000001
【課題】ＢＣサービスベンダによる不正な証明書発行を検知可能とする。
【解決手段】複数の組織配下の複数の分散台帳ノードによってビジネスネットワークが構成される分散台帳システムを格納したブロックチェーンプラットフォームにおいて、前記複数の組織のうち、第一の組織が、第二の組織配下の分散台帳ノードおよび認証局ノードの管理を代行する運用下で、所定の監査ノード１５０００が、前記第二の組織が保持し、前記第一の組織が管理を代行する認証局ノード内の秘密鍵へのアクセス履歴と、前記第二の組織が保持する認証局ノードへのアクセス履歴と比較することで、前記第一の組織による前記秘密鍵への不正アクセスを検知する構成とする。
【選択図】図１

Description

本発明は、業務監査支援システム及び業務監査支援方法に関するものである。
従来、金融機関や政府などの信頼できる中央集権機関を経由して実施されてきた取引を、利用者間のＰ２Ｐ（Ｐｅｅｒ ｔｏ Ｐｅｅｒ）による直接的な取引で代替する技術として、ブロックチェーン（以下、ＢＣとも称する）を用いた分散台帳技術が登場している。
分散台帳技術に関しては様々な派生技術が提案され、進化を続けている。現状の主な特徴としては、（１）分散台帳への参加者間の取引において、中央集権機関ではなく（任意ないしは特定の）参加者による合意形成や承認によって取引を確定させること、（２）複数のトランザクションをブロックとしてまとめ、数珠つなぎにブロックチェーンと呼ばれる分散台帳に記録し、連続するブロックにハッシュ計算を施すことにより、改ざんを実質不可能にすること、（３）参加者全員が同一の台帳データを共有することにより、参加者全員での取引の確認を可能とすることが挙げられる。
このようなＢＣを用いた分散台帳技術は、以上のような特徴から、信頼できるデータの管理/共有や、契約に基づく取引の執行/管理を行う仕組みとして、金融や製造業等、幅広い分野での応用が検討されている。
分散台帳を提供する基盤（以下、分散台帳基盤）を用いることで、中央集権機関による管理がなくとも複数の主体間で情報共有や取引を行うことができる（例えば、特定 業界のコンソーシアムやサプライチェーンに関係する複数企業等）。
なお、特定の組織により許可されたコンピュータのみが取引の参加者となるブロックチェーンまたは分散台帳を「コンソーシアム型」と呼ぶ。コンソーシアム型では参加者を認証する管理主体が存在するため、その分取引承認のスピードを早くすることができるメリットがある。そのため分散台帳技術を、特定業界のコンソーシアム内で利用する場合、一般的にコンソーシアム型の分散台帳基盤が用いられる。
また、一部の分散台帳基盤においては、複雑な取引条件や多様なアプリケーションにも適用可能とするために、分散台帳の中で取引データだけでなく取引条件を記載したロジックも管理できるようになってきている。このロジックはスマートコントラクト（以下、ＳＣとも称する）と呼ばれる。
非特許文献１には、ＳＣの実行機能を有する分散台帳基盤に関する技術について開示されている。これらの分散台帳基盤では、分散台帳基盤を構成するノード間で所定の合意水準で合意形成しながらトランザクション（以下、ＴＸとも称する）を受け入れる。そして、各ノードでＴＸを実行し、当該ＴＸの実行結果を保持することにより、複数ノード上で情報（台帳）を共有する。また、ＴＸに対して予め決めたロジックを実行するＳＣ実行機能を備える。
また、コンソーシアム型ＢＣを組織間横断業務に用いることで、ビジネスプロセスの効率化を図る試みもなされている。この場合、ＢＣに参加する全組織の取引履歴を格納した台帳を組織間で共有することとなる。そうした状況は、各事業者の機密保持の観点上必ずしも好ましくない。そのため、所定の取引関係がある組織同士のみで台帳を共有する運用
形態も想定される。
そこで非特許文献１では、そうした形態に対応すべく、分散台帳を論理分割する「Ｃｈａｎｎｅｌ」と称する概念が開示されている。この場合の分散台帳基盤は、全組織が参加するひとつの分散台帳基盤でありながらも、内部的には複数の分散台帳基盤に論理分割された構成となっている。
以下、この論理分割された分散台帳基盤に属するノードの集合を「サブグループ」と呼ぶ。上述のサブグループに属するノードは、当該サブグループ内のノードのみで分散台帳を共有する。また各ノードは、ＴＸ実行に際し、サブシステム毎にインストールされたＳＣを実行し、各サブグループに紐付けられた分散台帳のデータを更新する。
上述の通り、コンソーシアム型ＢＣでは、特定の組織により許可されたコンピュータのみが取引参加可能とする必要がある。非特許文献１に示される分散台帳基盤技術において、取引に参加するノードは所属組織および権限を明らかにするため、それぞれ固有の電子証明書を保持する。
この電子証明書は、各組織が持つ認証局ノードによって発行される。また、電子証明書は、認証局による電子署名がなされている。
一方、認証局ノード自身の公開鍵は事前に全組織に配布されている。そこで、その公開鍵を用いて、参加ノードの証明書上に書き込まれた認証局ノードの署名を検証することにより、参加ノードの証明書の正当性を確認できる。
また非特許文献１では、認証局ノードが持つ各組織固有の秘密鍵を、各組織が管理するＨＳＭ（Ｈａｒｄｗａｒｅ Ｓｅｃｕｒｉｔｙ Ｍｏｄｕｌｅ)上で保存することで、認
証局ノードのセキュリティを向上させること技術が開示されている。
この場合、認証局ノードは、例えばＰＫＣＳ＃１１のような公開鍵暗号化標準を用いて、ＨＳＭ上での秘密鍵の作成および操作を実行する。一般的なＨＳＭでは、秘密鍵へのアクセス履歴を監査ログとして改ざんされない形で保持することが可能である。
一方、コンソーシアム型ＢＣをＰａａＳ(Ｐｌａｔｆｏｒｍ ａｓ ａ Ｓｅｒｖｉｃ
ｅ)の形態で提供するクラウドベンダが複数出現しつつある。このようなサービスは、マ
ネージド型ブロックチェーンサービス(ＢＣサービス)と呼称される。ＢＣサービスでは顧客の構築作業負荷を軽減するため、分散台帳ノードや認証局ノードの構築や運用を代行する一方、分散台帳にアクセスするアプリを具備するクライアントノード、およびＨＳＭの構築は顧客側にて実施することが一般的である。
"Hyperledger Fabric", [online]、［２０２０年１２月１日検索］、インターネット＜URL：http://hyperledger-fabric.readthedocs.io/en/latest/＞
非特許文献１の開示技術に基づく既存のＢＣサービスでは、認証局ノードや分散台帳ノードの構築はＢＣサービスベンダが代行する。そのため、ＢＣサービスを利用する顧客は、自組織の秘密鍵を管理するＨＳＭへのアクセス方法(アドレス、クレデンシャル情報)を、ＢＣサービスベンダに周知しておく必要がある。
このため、ＢＣサービスベンダによる、ＨＳＭ上の秘密鍵の不正利用のリスクが生じうる。例えば、ＢＣサービスベンダが特定のＢＣ参加組織と結託し、他組織の秘密鍵を悪用してクライアント証明書を発行すれば、なりすましによるデータ改ざんが行われうる。
そこで本発明の目的は、ＢＣサービスベンダによる不正な証明書発行を検知可能とする技術を提供することにある。
上記課題を解決する本発明の業務監査支援システムは、複数の組織配下の複数の分散台帳ノードによってビジネスネットワークが構成される分散台帳システムを格納したブロックチェーンプラットフォームにおいて、前記複数の組織のうち、第一の組織が、第二の組織配下の分散台帳ノードおよび認証局ノードの管理を代行する運用下で、所定の監査ノードが、前記第二の組織が保持し、前記第一の組織が管理を代行する認証局ノード内の秘密鍵へのアクセス履歴と、前記第二の組織が保持する認証局ノードへのアクセス履歴と比較することで、前記第一の組織による前記秘密鍵への不正アクセスを検知するものである、ことを特徴とする。
また、本発明の業務監査支援方法は、複数の組織配下の複数の分散台帳ノードによってビジネスネットワークが構成される分散台帳システムを格納したブロックチェーンプラットフォームにおいて、前記複数の組織のうち、第一の組織が、第二の組織配下の分散台帳ノードおよび認証局ノードの管理を代行する運用下で、所定の監査ノードが、前記第二の組織が保持し、前記第一の組織が管理を代行する認証局ノード内の秘密鍵へのアクセス履歴と、前記第二の組織が保持する認証局ノードへのアクセス履歴と比較することで、前記第一の組織による前記秘密鍵への不正アクセスを検知する、ことを特徴とする。
本発明によれば、ＢＣサービスベンダによる不正な証明書発行を検知可能となる。
本実施形態における業務監査支援システムの構成例を示す図である。 本実施形態における計算機の構成例を示す図である。 本実施形態におけるアクセスログの構成例を示す図である。 本実施形態における情報収集対象管理表の構成例を示す図である。 本実施形態におけるブロックチェーンの構成例を示す図である。 本実施形態におけるステート情報の構成例を示す図である。 本実施形態における証明書失効リストの構成例を示す図である。 本実施形態における自組織ノードリストの構成例を示す図である。 本実施形態における証明書発行ログの構成例を示す図である。 本実施形態におけるＨＳＭアクセス情報の構成例を示す図である。 本実施形態におけるログインＩＤ管理表の構成例を示す図である。 本実施形態における秘密鍵管理表の構成例を示す図である。 本実施形態における署名実行ログの構成例を示す図である。 本実施形態における業務監査支援方法のフロー例を示す図である。 本実施形態における業務監査支援方法のフロー例を示す図である。 本実施形態における業務監査支援方法のフロー例を示す図である。 本実施形態における業務監査支援方法のフロー例を示す図である。 本実施形態における出力例を示す図である。 本実施形態における出力例を示す図である。 本実施形態における出力例を示す図である。
＜システム構成＞
以下に本発明の実施形態について図面を用いて詳細に説明する。図１は、本実施形態の業務監査支援システム１０を含むネットワーク構成図である。ここでは、業務監査支援システム１０を計算機システムと称し、その構成および計算機システムに接続されるノードの構成を示している。
なお、図１で例示する全体構成は、マネージド型ブロックチェーンサービス（ＢＣサービス）の構成を模式的に示したものとなる。
ＢＣサービスは２つのクラウド基盤４５０００により構成され、それぞれＢＣサービスベンダ向けおよび顧客向けに分かれている。クラウド基盤４５０００同士はインターネット回線４１０００により相互に接続されている。
このうち顧客向けのクラウド基盤４５０００は、１台以上のクライアントノード１００００、１台以上のＨＳＭ３５０００、１台以上の監査ノード１５０００によって構成される。これらの機器は、物理的もしくは論理的な通信回線を通して内部ネットワーク４００００に接続される。
一方、ＢＣサービスベンダ向けのクラウド基盤４５０００は、１台以上の分散台帳ノード２００００、１台以上の認証局ノード３００００によって構成される。これらの機器は、物理的もしくは論理的な通信回線を通して内部ネットワーク４００００に接続される。
本実施形態においては、分散台帳ノード２００００が複数台存在し、コンソーシアムを構成する複数の組織(例えば、複数の事業者/複数の組織/複数のベンダ)によって分散台帳ノードがそれぞれ管理されることを想定する。
同様に、クライアントノード１００００も複数台存在し、複数の組織がそれぞれ別のクライアントノードを利用することを想定する。また、認証局ノード３００００およびＨＳＭ３５０００も各組織向けに複数台存在してよく、複数の認証局ノードおよびＨＳＭが同じ情報を共有しつつ並存することで、障害発生時における冗長性を担保してもよい。
なお、クライアントノード１００００、分散台帳ノード２００００、監査ノード１５０００および認証局ノード３００００の物理的な実体は、プロセッサ１０４、メモリ１０３、データバス１０８からなる一般的な計算機である（図２参照。以下同様）。
また、全てのクラウド基盤上にはＤＮＳサーバが別途存在し、各ノードの名称（「ｐｅｅｒ１．ｏｒｇ１．ｅｘａｍｐｌｅ．ｃｏｍ」など）と対応するＩＰアドレスを対応付けるＤＮＳ名前解決が行えるものとする。
クライアントノード１００００は、トランザクション発行部１１０００、業務アプリ１２０００、証明書発行要求部１３０００、アクセスログ１４０００、参加メンバー管理情報１４１００によって構成される。
このうち業務アプリ１２０００は、ユーザより業務に関する情報の入力を受ける。その後、業務アプリ１２０００はトランザクション発行部１１０００を介してＴＸを発行して、ユーザの入力内容を分散台帳ノード２００００に対して送信する。なお、ＴＸには発行者の署名と証明書を付与するが、この際は認証局ノード３００００より発行され、参加メンバー管理情報１４１００に格納された秘密鍵および証明書を利用する。
監査ノード１５０００は、監査処理部１６０００、監査情報収集部１７０００、情報収集対象管理表１８０００によって構成される。
分散台帳ノード２００００は、トランザクション配信部２１０００、スマートコントラクト実行/管理部２２０００（以下、ＳＣ実行/管理部とも称する）、トランザクション管理部２３０００、サブグループ管理部２４０００、分散台帳２５０００、参加メンバー管理情報２９０００、証明書失効リスト２９１００、自組織ノードリスト２９２００によって構成される。分散台帳２５０００はサブグループ毎に定義され、サブグループに属するノード間で同じ台帳が共有される。
分散台帳ノード２００００は、トランザクション管理部２３０００の機能によりＴＸを受け付け、他組織との合意形成がなされていればＳＣ実行/管理部２２０００の機能を介
して、ＳＣのデプロイ、デプロイ済みのＳＣに対する実行を行い、ＴＸの履歴とその実行結果を分散台帳２５０００に記録する。
また、分散台帳ノード２００００のトランザクション管理部２３０００は、クライアントノード１００００等の各ノードからの要求に対して、ＴＸを受け付けたり、ＴＸの履歴情報を取得・閲覧したりする機能/インタフェースを提供する。
トランザクション配信部２１０００は、トランザクション管理部２３０００が受け付けたトランザクションを組織内の全分散台帳ノードにブロードキャストする機能を提供する。
本実施形態の分散台帳システムでは、コンソーシアムに参加するメンバー、すなわち組織や分散台帳ノード２００００の管理を各組織の分散台帳２５０００にて行う。また、分散台帳システムのサブグループ管理部２４０００が、組織やサブグループの新規登録や追加機能を提供する。
また、本実施形態の分散台帳システムでは、秘密鍵や証明書を用いて、参加組織の認証やＴＸへの署名、ＳＣ実行権限の制御等を行うことを想定する。各分散台帳ノード固有の証明書および秘密鍵の情報は、分散台帳ノード２００００の参加メンバー管理情報２９０００に格納・管理される。一方、各組織のルート証明書の情報は全ての分散台帳ノード間で共有される。
分散台帳ノード２００００のトランザクション管理部２３０００は、ＴＸを受け付けた際に随時、ＴＸの発行者が権限を持った正しい参加者かどうかを確認する。また、証明書失効リスト２９１００には、認証局ノード３００００によって失効扱いとされた証明書のシリアル番号が登録されている。
トランザクション管理部２３０００はＴＸを受け付けた際に随時、ＴＸへの署名が失効した証明書により行われていないか確認し、もし該当すればそのＴＸは受け付けない。
なお、証明書と秘密鍵の組を生成する手法や署名検証をする手法については、公知または周知の技術を適用すれば良いので、本実施形態では詳述しない。
分散台帳２５０００は、業務に関するスマートコントラクト２６０００と、ＳＣによるＴＸ結果を格納・管理する。ＴＸ結果のデータ構造として本実施例では、ＴＸの履歴をブロックチェーン２７０００として、ＴＸの実行結果に基づくステート情報２８０００をテーブル形式で保持することを想定する。
認証局ノード３００００は、証明書発行部３１０００、証明書発行ログ３２０００、ＨＳＭアクセス情報３３０００によって構成される。
ＨＳＭ３５０００は、署名実行部３６０００、ＩＤ管理表３７０００、秘密鍵管理表３７２００、署名実行ログ３７３００によって構成される。
本実施形態におけるＨＳＭ３５０００では、秘密鍵を事前に作成して秘密鍵管理表３７２００に格納するとともに、その秘密鍵にアクセス可能なユーザのＩＤおよびパスワードをＩＤ管理表３７０００に格納する。
署名実行部３６０００は、秘密鍵にアクセスしようとするユーザのＩＤおよびパスワード、使用する秘密鍵のＩＤ、署名対象のファイルを外部から受け付ける。次に署名実行部３６０００は、ＩＤ管理表３７０００および秘密鍵管理表３８０００を参照し、ユーザが指定した秘密鍵に対するアクセス権限を持つかを特定し、アクセス権限があれば、その鍵を用いて署名対象のファイルへの署名を行う。
＜ハードウェア構成＞
また、本実施形態の業務監査支援システム１０を構成する、各計算機１００のハードウェア構成は、図２に以下の如くとなる。
すなわち計算機１００は、記憶装置１０１、メモリ１０３、プロセッサ１０４、入力装置１０５、出力装置１０６、および通信装置１０７を備える。
このうち記憶装置１０１は、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）やハードディスクドライブなど適宜な不揮発性記憶素子で構成される。
また、メモリ１０３は、ＲＡＭなど揮発性記憶素子で構成される。
また、プロセッサ１０４は、記憶装置１０１に保持されるプログラム１０２をメモリ１０３に読み出すなどして実行し装置自体の統括制御を行なうとともに各種判定、演算及び制御処理を行なうＣＰＵである。
また、通信装置１０７は、インターネット４１０００と接続して、外部装置との通信処理を担うネットワークインターフェイスカード等を想定する。
なお、計算機１００がスタンドアロンマシンである場合、ユーザからのキー入力や音声入力を受け付ける入力装置１０５、処理データの表示を行うディスプレイ等の出力装置１０６、を更に備えるとすれば好適である。
また、記憶装置１０１内には、本実施形態の計算機として必要な機能を実装する為のプログラム１０２に加えて、それらプログラム１０２の実行に際して必要となるデータ類１１２５が記憶されている。
＜データ構造例＞
続いて、本実施形態の業務監査支援システム１０を構成する各計算機が用いる各種情報について説明する。９９９
図３は、クライアントノード１００００の具備するアクセスログ１４０００の構成例を示す図である。アクセスログ１４０００は、クライアントノード１００００から認証局ノ
ード３００００に対し証明書発行リクエストが行われた際に追記される。
アクセスログ１４０００は、当該アクセスが発生した日時を登録するフィールド１４０１０と、当該アクセス先となる認証局ノード３００００の名称を登録するフィールド１４０２０と、当該アクセスにより認証局ノード３００００より取得した証明書の識別子を登録するフィールド１４０３０と、当該証明書のシリアル番号を登録するフィールド１４０４０と、を構成項目として含んでいる。
図４は、監査ノード１５０００の具備する情報収集対象管理表１８０００の構成例を示す図である。
情報収集対象管理表１８０００は、監査対象となる組織のドメイン名を登録するフィールド１８０１０と、監査対象ノードの種別を登録するフィールド１８０２０と、監査対象ノードの名称を登録するフィールド１８０３０と、を構成項目として含んでいる。
図５および図６は、分散台帳ノード２００００の具備する分散台帳２５０００に格納するデータ構造の一例である。
図５は、分散台帳２５０００上で管理するデータ構造の一つであるブロックチェーン２７０００の例である。ＢＣを用いた分散台帳管理では、複数のＴＸをブロックとしてまとめて、各ブロックが前のブロックのハッシュ値を持つことでデータを数珠つなぎにして管理する。
前段のブロックの値が１ビットでも変わると後続の全ブロックのハッシュ値が変わるため、改ざんを困難にすることができる。なお、本実施形態では説明をシンプルにするために、１つのＴＸにつき、１ブロックとするが、本発明は、複数ＴＸをまとめて１ブロックに格納した場合にも適用可能である。
図５で示すＢＣは、ブロック２７０１０～２７０３０からなる一連のブロックで構成される。各ブロックは、それぞれＳＣのデプロイ、実行、いずれかのＴＸ情報を含む。また各ブロックは前ブロックのハッシュ値２７１００を含み、後述のステート情報から生成したハッシュ値２７２００を含む。
上記のようなデータ構造により、サブグループの作成、およびＳＣのデプロイ、実行の履歴情報がＢＣの中でデータの連鎖として管理される。
このうちブロック２７０１０は、サブグループの初期情報を格納したブロックの一例である。本実施形態の初期ブロック２７３００には、分散台帳と紐付けられたサブグループのＩＤが定義されている。さらに、当該サブグループに属する組織のドメイン名およびルート証明書の一覧と、各組織の代表となる分散台帳ノードの名称が定義されている。加えて、参加組織間でトランザクションの承認を得るために必要な条件を含む。
また、ブロック２７０２０は、ＳＣのデプロイＴＸを格納したブロックの一例である。本実施形態のデプロイＴＸ２７４００は、コントラクトを一意に識別するコントラクトＩＤと、コントラクトのロジック(例えば実行可能なバイナリ)を含む。
また、コントラクトが持つ関数名やその引数を利用者が把握するためのコントラクト入力仕様を含む。
この例では、「送金業務」というＩＤを持つＳＣの関数名として「送金」が定義されて
おり、併せて関数のロジックが定義されている。さらに、このデプロイＴＸの発行元のＩＤと、データに改ざんが無いことを検証するために用いる電子署名を含む。また、ＴＸの固有の識別子であるＩＤを含む。
また、ブロック２７０３０はＳＣの実行ＴＸを格納したブロックの一例である。本実施形態の実行ＴＸ２７５００は、呼び出し対象となるコントラクトのコントラクトＩＤ、呼び出し対象となるコントラクトの関数名と入力する引数の情報を含む。
この例では、「送金業務」というＩＤを持つＳＣの関数「送金」を呼び出しており、その引数は送金組織ＩＤ、受取組織ＩＤ、金額の３つであり、その値はそれぞれ“Ｏｒｇ１”、“Ｏｒｇ３”、“１００”である。
さらに、このＴＸの発行元のＩＤと、データに改ざんが無いことを検証するために用いる電子署名を含む。なお、発行元だけでなく、合意形成に関わったノードの情報も管理/
保持してもよい。また、分散台帳内でのＴＸの固有の識別子であるＩＤを含む。
図６は、分散台帳上で管理するステート情報２８０００である。ＢＣを用いた分散台帳管理では通常、最新のステート(例えば、仮想通貨の場合にはアカウントの残高)を取得するためには、ＢＣを辿らなければならない。これでは処理効率が悪いため、ＢＣとは別に、最新のステート情報をキャッシュしておく方法が存在する（非特許文献１等）。
本実施形態でも最新のステート情報を保持することを想定する。本実施形態では、スマートコントラクトが持つ関数毎にステートのデータ領域が用意されることとする。
ステート情報２８０００はスマートコントラクトの識別子であるＩＤ２８０１０と、そのスマートコントラクトの実体２８０２０と、スマートコントラクトに紐付けられたサブグループの識別子２８３００を保持する。
これにより、ＳＣ実行/管理部は、コントラクトＩＤと関数名をキーにして、スマート
コントラクトの実体を取得して実行することができる。また、ステート情報はＳＣの実行結果を保持するための内部テーブル２８０４０を備える。
ＴＸが実行される度にこの内部テーブルの内容を更新する。ステート情報２８０００の内部テーブル２８０４０は「所有金額データ」というテーブルで構成されており、ＴＸの引数で指定された情報を随時上書きする。
図７は、分散台帳ノード２００００の具備する証明書失効リスト２９１００の構成例を示す図である。証明書失効リスト２９１００は、クライアントノード１００００など外部から認証局ノード３００００に対し証明書失効リクエストが行われた際に作成され、ＢＣサービスベンダが随時分散台帳ノード２００００に配置することで有効となる。
なお、認証局ノード３００００が証明書失効リクエストを受ける度に、自動的に全ての分散台帳ノード２００００に配信する仕組みがあってもよい。
証明書失効リスト２９１００は、認証局ノード３００００が失効させた証明書の識別子を登録するフィールド２９１１０と、当該証明書のシリアル番号を登録するフィールド２９１２０と、を構成項目として含んでいる。
図８は、分散台帳ノード２００００の具備する自組織ノードリスト２９２００の構成例を示す図である。自組織ノードリスト２９２００は、分散台帳ノード２００００内のトラ
ンザクション配信部２１０００が相互に通信しあうことで自動的に生成される。
自組織ノードリスト２９２００は、当該分散台帳ノードと同じ組織に所属するノードの名称を登録するフィールド２９２１０と、を構成項目として含んでいる。
図９は、認証局ノード３００００の具備する証明書発行ログ３２０００の構成例を示す図である。証明書発行ログ３２０００は、クライアントノード１００００など外部から認証局ノード３００００に対し証明書発行リクエストが行われた際に追記される。
証明書発行ログ３２０００は、当該アクセスが発生した日時を登録するフィールド３２０１０と、当該アクセスにより発行された証明書の用途を登録するフィールド３２０２０と、当該アクセスにより認証局ノードが発行した証明書の識別子を登録するフィールド３２０３０と、当該証明書のシリアル番号を登録するフィールド３２０４０と、を構成項目として含んでいる。
図１０は、認証局ノード３００００の具備するＨＳＭアクセス情報３３０００の構成例を示す図である。
ＨＳＭアクセス情報３３０００は、認証局ノード３００００がアクセスするＨＳＭ３５０００の名称を登録するフィールド３３０１０と、ＨＳＭ３５０００にログインするために用いるＩＤを登録するフィールド３３０２０と、ＨＳＭ３５０００にログインするために用いるパスワードを登録するフィールド３３０３０と、を構成項目として含んでいる。
図１１は、ＨＳＭ３５０００の具備するログインＩＤ管理表３７０００の構成例を示す図である。
ログインＩＤ管理表３７０００は、外部からＨＳＭ３５０００にログインするために用いるＩＤを登録するフィールド３７０１０と、ＨＳＭ３５０００にログインするために用いるパスワードを登録するフィールド３７０２０と、当該アカウントを用いてＨＳＭ３５０００にログインした際に使用可能な秘密鍵の識別子を登録するフィールド３７０３０と、を構成項目として含んでいる。
図１２は、ＨＳＭ３５０００の具備する秘密鍵管理表３７１００の構成例を示す図である。秘密鍵管理表３７１００は、ＨＳＭ３５０００により発行された秘密鍵の識別子を登録するフィールド３７１１０と、当該秘密鍵のバイナリを登録するフィールド３７１２０と、を構成項目として含んでいる。
図１３は、ＨＳＭ３５０００の具備する署名実行ログ３７２００の構成例を示す図である。署名実行ログ３７２００は、認証局ノード３００００など外部からＨＳＭ３５０００に対し署名実行リクエストが行われた際に追記される。
署名実行ログ３７２００は、当該アクセスが発生した日時を登録するフィールド３７２１０と、当該アクセスを実施したノードの名称を登録するフィールド３７２２０と、当該アクセス時に使用した秘密鍵の識別子を登録するフィールド３７２３０と、を構成項目として含んでいる。
＜フロー例１＞
以下、本実施形態における業務監査支援方法の実際手順について図に基づき説明する。以下で説明する業務監査支援方法に対応する各種動作は、計算機１００がメモリ等に読み出して実行するプログラムによって実現される。そして、このプログラムは、以下に説明
される各種の動作を行うためのコードから構成されている。
図１４は、分散台帳ノード２００００が備えるサブグループ管理部２１４００のサブグループ新規作成処理の例を示すフローチャートである。具体的な内部処理を以下に示す。
ブロックチェーン上の複数の組織が、サブグループを新たに作成しようとする場合、ＢＣサービスの管理者は、事前に参加組織と合意のうえ、サブグループＩＤ、参加組織のドメイン名、参加組織のルート証明書、参加組織の代表ノードの名称、トランザクション承認条件を決定してサブグループ管理部２１４００に入力する。
サブグループ管理部２１４００は、これらの情報に基づき初期ブロックを作成する（ステップ５１０１０）。
次に、サブグループ管理部２１４００は、作成した初期ブロックを、他分散台帳ノードのサブグループ管理部に配布する（ステップ５１０２０）。
また、各組織のサブグループ管理部２１４００は、初期ブロックを起点としたブロックチェーンを含む分散台帳を作成する（ステップ５１０３０）。
＜フロー例２＞
図１５は、分散台帳ノード２００００のＴＸ実行処理、すなわち、ＳＣのデプロイおよび実行の例を示すフローチャートである。
クライアントノード１００００は、トランザクションを実行するために必要な承認を得るため、各参加組織の分散台帳ノード２００００のトランザクション管理部２１３００に対してトランザクションを発行する（ステップ５２０１０）。
ＴＸの内容は実行するＳＣ名と関数名および引数である。クライアントノード１００００はＴＸ発行の際、自身が持つ秘密鍵を用いてＴＸに署名を行うとともに、証明書を合わせて送付する。証明書と秘密鍵は、図１６に示す証明書発行処理により認証局ノード３００００から事前に発行を受けたものである。
分散台帳ノード２００００のトランザクション管理部２１３００はクライアントノード１００００からＴＸを受け取ると、トランザクションに付与されたクライアントノード１０００の署名および同時に送付された証明書が、初期ブロック内のルート証明書と比較して正当かどうかを検証する（ステップ５２０２０）。
トランザクションが正当であれば、分散台帳ノード２００００は自身の秘密鍵を用いてＴＸに署名を行う（ステップ５２０３０）。次に分散台帳ノード２００００は、クライアントノード１００００に対し署名済みのＴＸを返す（ステップ５２０４０）。
クライアントノード１００００は、各分散台帳ノードから署名済みＴＸ受け取った場合、合意形成が完了したものとみなし、自組織の分散台帳ノード２００００のトランザクション管理部２１３００に対しＴＸの配信を依頼する（ステップ５２０５０）。
分散台帳ノード２００００のトランザクション管理部２１３００は、ＴＸをトランザクション配信部２１０００に送信する。トランザクション配信部２１０００は、ＴＸにＩＤを付与するとともに、初期ブロックに記録された他組織の代表分散台帳ノードに対しＴＸの配信を依頼する（ステップ５２０６０）。
各組織の代表分散台帳ノードは、参加メンバー管理情報２９０００を参照し、自組織内の他の分散台帳ノードに対しトランザクションを配信する（ステップ５２０７０）。ＴＸを受け取った各分散台帳ノード２００００のＳＣ実行/管理部２２０００は、受け取った
ＴＸを分散台帳２５０００に登録する。
その際、ＴＸの内容がＳＣのデプロイに関する場合、コントラクトＩＤやコントラクト実体を分散台帳上のステート情報２８０００として登録し、ブロックチェーン２７０００の末尾にこのＴＸを含むブロックを追加する。
ＴＸの内容がＳＣに定義された関数の実行に関する場合、ＴＸ内で指定されたコントラクトＩＤを持つＳＣに対して、ＴＸ内で指定された呼び出し関数と入力引数を与えて実行する。
そして、その結果に基づき、分散台帳２５０００の内容を更新する。すなわち、実行結果に基づいて、本コントラクトに関するステート情報２８０００を更新し、ブロックチェーン２７０００の末尾のブロックとして実行ＴＸを追加する（ステップ５２０８０）。
なお、本実施例ではステップ５２０６０および５２０７０におけるブロードキャストの処理を分散台帳ノード２００００が実施しているが、これを別のトランザクション配信専用ノードによって行っても構わない。
＜フロー例３＞
図１６は、認証局ノード３００００が備える証明書発行部３１０００の証明書発行処理の例を示すフローチャートである。具体的な内部処理を以下に示す。
クライアントノード１００００の証明書および秘密鍵を取得しようとするクライアント管理者は、クライアントノード１００００の証明書発行要求部１３０００を通じて認証局ノード３００００の証明書発行部３１０００にアクセスし、証明書発行を要求する。
一方、分散台帳ノード構築のため、分散台帳ノード向けの証明書および秘密鍵を取得しようとするＢＣサービス管理者は、直接、認証局ノード３００００の証明書発行部３１０００にアクセスし、証明書発行の操作を行う。この場合、認証局ノード３００００の証明書発行部３１０００は、証明書発行を要求する（ステップ５３０１０）。
なお、証明書発行要求時にはその用途（分散台帳ノード向けもしくはクライアントノード向け）を指定する必要がある。用途は証明書の内部に記録され、異なる用途に転用することはできない。
次に、証明書発行部３１０００は秘密鍵と公開鍵のペアを作成する（ステップ５３０２０）。次に、証明書発行部３１０００はＨＳＭアクセス情報を用いてＨＳＭ内の秘密鍵にアクセスし、公開鍵に署名を実施して証明書を作成する（ステップ５３０３０）。
最後に証明書発行部は作成した証明書と秘密鍵を要求元に返信する（ステップ５３０４０）。
＜フロー例４＞
図１７は、監査ノード１５０００が備える監査処理部１６０００の監査処理の例を示すフローチャートである。具体的な内部処理を以下に示す。
ＢＣサービスを利用する組織の管理者は、監査ノード１５０００が備える監査処理部１
６０００にアクセスし、組織のドメイン名を指定して監査の実行を指示する。
監査処理部１６０００は、上述の指示を受けると、監査情報収集部１７０００に必要な情報の収集を指示する。監査情報収集部１７０００は情報収集対象管理表１８０００を参照して、当該組織が持つクライアントノード１００００を特定し、アクセスログを収集する（ステップ５４０１０）。
次に、監査情報収集部１７０００は、情報収集対象管理表１８０００を参照して、当該組織が持つ認証局ノード３００００を特定し、認証局ノード３００００から証明書発行ログを収集する（ステップ５４０２０）。
次に監査処理部１６０００は、監査情報収集部１７０００が収集した情報を元に（Ａ）クライアントノード１００００における証明書生成要求数と、（Ｂ）認証局ノード３００００におけるクライアントノード証明書発行数を算出し、比較する（ステップ５４０３０）。
上述の比較の結果、（Ａ）の方が（Ｂ）に比べて少ない場合、監査処理部１６０００は「クラウドベンダ等によるクライアント証明書不正作成の可能性あり」との応答（図１８参照）を管理者に返す（ステップ５４０４０）。一方、上述の比較の結果、（Ａ）と（Ｂ）が同数であれば、次のステップに進む。
以下、図面に示したデータの例を用いて説明する。まず組織ｏｒｇ１．ｅｘａｍｐｌｅ．ｃｏｍの管理者は、監査ノードに対し監査の実行を指示する。監査情報収集部は図４に示す情報収集対象管理表を参照して、組織ｏｒｇ１．ｅｘａｍｐｌｅ．ｃｏｍが持つクライアントノード（ｃｌｉｅｎｔ１．ｏｒｇ１．ｅｘａｍｐｌｅ．ｃｏｍ）を特定し、アクセスログ（図３）を収集する。
次に監査情報収集部１７０００は、情報収集対象管理表１８０００を参照して、当該組織が持つ認証局ノード（ｃａ．ｏｒｇ１．ｅｘａｍｐｌｅ．ｃｏｍ）を特定し、証明書発行ログ（図９）を収集する。
その結果、監査処理部１６０００は（Ａ）クライアントノード１００００における証明書生成要求数、（Ｂ）認証局ノードにおけるクライアントノード証明書発行数は共に２で同数と判断し、次のステップ５４０５０に進む。一方（Ｂ）が多い場合、ＢＣサービスベンダが不正にクライアント証明書を作成した可能性があると分かる。
次に監査情報収集部１７０００は情報収集対象管理表１８０００を参照して、当該組織が持つ分散台帳ノードを特定し、分散台帳ノードから自組織ノードリストと失効証明書リストを収集する（ステップ５４０５０）。
次に、監査情報収集部１７０００は、情報収集対象管理表１８０００を参照して、当該組織が持つＨＳＭ３５０００を特定し、ＨＳＭ３５０００から署名実行ログを収集を収集する（ステップ５４０６０）。
次に監査処理部１６０００は、監査情報収集部１７０００が収集した情報を元に（Ｃ）組織内の分散台帳ノード数、（Ｄ）自組織内の分散台帳ノード向け証明書のうち失効したものの数、（Ｅ）ＨＳＭ内の秘密鍵を用いた署名回数、を算出し、比較する（ステップ５４０７０）。
上述の比較の結果、（Ａ）（Ｃ）（Ｄ）の合計値が（Ｅ）に比べて少ない場合、監査処
理部１６０００は「クラウドベンダ等によるＨＳＭ内秘密鍵の不正使用の可能性あり」との応答（図１９参照）を管理者に返す（ステップ５４０８０）。
一方、上述の比較の結果、（Ａ）（Ｃ）（Ｄ）の合計値が（Ｅ）と同数であれば、監査処理部は「クラウドベンダ等による不正の可能性なし」との応答（図２０参照）を管理者に返す（ステップ５４０９０）。
以下、図面に示したデータの例を用いて説明する。監査情報収集部１７０００は図４に示す情報収集対象管理表１８０００を参照して、組織ｏｒｇ１．ｅｘａｍｐｌｅ．ｃｏｍが持つ分散台帳ノード（ｐｅｅｒ１．ｏｒｇ１．ｅｘａｍｐｌｅ．ｃｏｍ）を特定し、自組織ノードリスト（図８）と失効証明書リスト（図７）を収集する。
次に監査情報収集部１７０００は、情報収集対象管理表１８０００を参照して、当該組織が持つＨＳＭ（ｈｓｍ．ｏｒｇ１．ｅｘａｍｐｌｅ．ｃｏｍ）を特定し、署名実行ログ（図９）を収集する。
その結果、監査処理部１６０００は、（Ｃ）組織内の分散台帳ノード数＝２、（Ｄ）自組織内の分散台帳ノード向け証明書のうち失効したものの数＝１、（Ｅ）ＨＳＭ内の秘密鍵を用いた署名回数＝５と算出する。
この結果に基づき、（Ａ）（Ｃ）（Ｄ）の合計値と（Ｅ）は共に５で同数と判断し、「クラウドベンダ等による不正の可能性なし」との応答（図２０参照）を管理者に返す。
一方（Ｅ）が多い場合、ＢＣサービスベンダが不正にＨＳＭ内の秘密鍵にアクセスし、証明書の発行などを行った可能性があると分かる。
なお、上記のステップは必ずしも全て行う必要はなく、（Ａ）～（Ｅ）のうちいずれかの情報の取得を省略してもよい。
また、本実施形態では認証局ノード３００００がＨＳＭ３５０００を利用せず、秘密鍵を直接保持する構成も考えられる。その場合、上述した「（Ｅ）ＨＳＭ内の秘密鍵を用いた署名回数」は、認証局ノード３００００における証明書発行ログ３２０００に含まれる証明書発行数から判断してもよい。
その場合、当該ログをＢＣサービスベンダ側が事後に改ざんすることの無いよう、改ざん不能な第三者のログ保管サービス等を用いて保管する必要がある。
以上で示したとおり、本発明を用いることで、ＢＣサービスを利用する各組織は、ＢＣサービスベンダが直接操作できないログや構成情報のみを用いて、ＢＣサービスベンダによるＨＳＭ上の秘密鍵の不正利用の有無を検知することができる。
一方で、ＢＣサービスベンダは本発明による監査機能を提供を顧客に提供することで、ＢＣサービスのセキュリティ面における信頼性を担保し、サービスの価値向上を図ることができる。
以上、本発明を実施するための最良の形態などについて具体的に説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。
こうした本実施形態によれば、各組織が自身で管理可能なログや構成情報、具体的にはクライアントノードから認証局ノードへのアクセスログ、分散台帳ノードの構成情報、Ｈ
ＳＭ上の秘密鍵を用いた署名の履歴ログを照合して、ＢＣサービスベンダによる不正な証明書発行を検知することができる。各組織のシステム管理者は、そうした機能を有した監査ツールを定期的に実行することで、ＢＣサービスベンダによる不正行為を検知できる。
一方で、ＢＣサービスベンダは、上記手段による監査機能を顧客に提供することで、ＢＣサービスのセキュリティ面における信頼性を担保し、サービスの価値向上を図ることができる。
すなわち、ＢＣサービスベンダによる不正な証明書発行を検知可能となる。
本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、本実施形態の業務監査支援システムにおいて、前記監査ノードは、前記前記第二の組織が保持し、前記第一の組織が管理を代行する認証局ノードによる証明書作成履歴と、前記第二の組織が保持する認証局ノードへのアクセス履歴と比較し、前記第一の組織による前記認証局を用いた不正な証明書発行を検知するものである、としてもよい。
これによれば、証明書作成履歴と認証局ノードへのアクセス履歴の比較により、より効率的に、ＢＣサービスベンダによる不正な証明書発行を検知可能となる。
また、本実施形態の業務監査支援システムにおいて、前記第二の組織が保持する専用のハードウェアにおいて、前記第二の組織が保持する認証局ノード内の秘密鍵を管理するものである、としてもよい。
これによれば、いわゆるＨＳＭでの情報管理によって、よりセキュアかつ精度良くに、ＢＣサービスベンダによる不正な証明書発行を検知可能となる。
また、本実施形態の業務監査支援システムにおいて、前記監査ノードは、前記第二の組織が保持する認証局ノードへのアクセス履歴に加え、前記第二の組織が保持する分散台帳ノードの構成情報を取得し、前記第一の組織による前記秘密鍵への不正アクセス検知に利用するものである、としてもよい。
これによれば、分散台帳ノードの構成情報にも基づいて不正アクセス検知を行うことで、より効率的、精度良好に、ＢＣサービスベンダによる不正な証明書発行を検知可能となる。
また、本実施形態の業務監査支援システムにおいて、前記監査ノードは、前記第二の組織が保持する認証局ノードへのアクセス履歴に加え、前記第二の組織が保持する認証局ノードが発行した証明書のうち、失効済みの証明書を示す証明書失効リストを取得し、前記第一の組織による前記秘密鍵への不正アクセス検知に利用するものである、としてもよい。
これによれば、証明書失効リストに基づく、より効率的な、ＢＣサービスベンダによる不正な証明書発行を検知可能となる。
また、本実施形態の業務監査支援方法において、前記監査ノードが、前記前記第二の組織が保持し、前記第一の組織が管理を代行する認証局ノードによる証明書作成履歴と、前記第二の組織が保持する認証局ノードへのアクセス履歴と比較し、前記第一の組織による前記認証局を用いた不正な証明書発行を検知する、としてもよい。
また、本実施形態の業務監査支援方法において、前記第二の組織が保持する専用のハー
ドウェアにおいて、前記第二の組織が保持する認証局ノード内の秘密鍵を管理する、としてもよい。
また、本実施形態の業務監査支援方法において、前記監査ノードが、前記第二の組織が保持する認証局ノードへのアクセス履歴に加え、前記第二の組織が保持する分散台帳ノードの構成情報を取得し、前記第一の組織による前記秘密鍵への不正アクセス検知に利用する、としてもよい。
また、本実施形態の業務監査支援方法において、前記監査ノードが、前記第二の組織が保持する認証局ノードへのアクセス履歴に加え、前記第二の組織が保持する認証局ノードが発行した証明書のうち、失効済みの証明書を示す証明書失効リストを取得し、前記第一の組織による前記秘密鍵への不正アクセス検知に利用する、としてもよい。
１０ 業務監査支援システム
１００ 計算機
１０１ 記憶装置
１０２ プログラム
１０３ メモリ
１０４ 演算装置
１０５ 入力装置
１０６ 出力装置
１０７ 通信装置
１２５ データ類
１００００ クライアントノード
１１０００ トランザクション発行部
１２０００ 業務アプリ
１３０００ 証明書発行要求部
１４０００ アクセスログ
１５０００ 監査ノード
１６０００ 監査処理部
１７０００ 監査情報収集部
１８０００ 情報収集対象管理表
２００００ 分散台帳ノード
２１０００ トランザクション配信部
２２０００ スマートコントラクト実行／管理部
２３０００ トランザクション管理部
２４０００ サブグループ管理部
２５０００ 分散台帳
２６０００ スマートコントラクト
２７０００ ブロックチェーン
２８０００ ステート情報
２９０００ 参加メンバー管理情報
２９１００ 証明書失効リスト
２９２００ 自組織ノードリスト
３００００ 認証局ノード
３１０００ 証明書発行部
３２０００ 証明書発行ログ
３３０００ ＨＳＭアクセス情報
３５０００ ＨＳＭ
３６０００ 署名実行部
３７０００ ログインＩＤ管理表
３７１００ 秘密鍵管理表
３７２００ 署名実行ログ
４００００ 内部ネットワーク
４１０００ インターネット
４５０００ クラウド基盤

Claims (10)

  1. 複数の組織配下の複数の分散台帳ノードによってビジネスネットワークが構成される分散台帳システムを格納したブロックチェーンプラットフォームにおいて、
    前記複数の組織のうち、第一の組織が、第二の組織配下の分散台帳ノードおよび認証局ノードの管理を代行する運用下で、所定の監査ノードが、前記第二の組織が保持し、前記第一の組織が管理を代行する認証局ノード内の秘密鍵へのアクセス履歴と、前記第二の組織が保持する認証局ノードへのアクセス履歴と比較することで、前記第一の組織による前記秘密鍵への不正アクセスを検知するものである、
    ことを特徴とした業務監査支援システム。
  2. 前記監査ノードは、
    前記前記第二の組織が保持し、前記第一の組織が管理を代行する認証局ノードによる証明書作成履歴と、前記第二の組織が保持する認証局ノードへのアクセス履歴と比較し、前記第一の組織による前記認証局を用いた不正な証明書発行を検知するものである、
    ことを特徴とした請求項１に記載の業務監査支援システム。
  3. 前記第二の組織が保持する専用のハードウェアにおいて、
    前記第二の組織が保持する認証局ノード内の秘密鍵を管理するものである、
    ことを特徴とした請求項１に記載の業務監査支援システム。
  4. 前記監査ノードは、
    前記第二の組織が保持する認証局ノードへのアクセス履歴に加え、前記第二の組織が保持する分散台帳ノードの構成情報を取得し、前記第一の組織による前記秘密鍵への不正アクセス検知に利用するものである、
    ことを特徴とした請求項１に記載の業務監査支援システム。
  5. 前記監査ノードは、
    前記第二の組織が保持する認証局ノードへのアクセス履歴に加え、前記第二の組織が保持する認証局ノードが発行した証明書のうち、失効済みの証明書を示す証明書失効リストを取得し、前記第一の組織による前記秘密鍵への不正アクセス検知に利用するものである、
    ことを特徴とした請求項１に記載の業務監査支援システム。
  6. 複数の組織配下の複数の分散台帳ノードによってビジネスネットワークが構成される分散台帳システムを格納したブロックチェーンプラットフォームにおいて、
    前記複数の組織のうち、第一の組織が、第二の組織配下の分散台帳ノードおよび認証局ノードの管理を代行する運用下で、所定の監査ノードが、前記第二の組織が保持し、前記第一の組織が管理を代行する認証局ノード内の秘密鍵へのアクセス履歴と、前記第二の組織が保持する認証局ノードへのアクセス履歴と比較することで、前記第一の組織による前記秘密鍵への不正アクセスを検知する、
    ことを特徴とした業務監査支援方法。
  7. 前記監査ノードが、
    前記前記第二の組織が保持し、前記第一の組織が管理を代行する認証局ノードによる証明書作成履歴と、前記第二の組織が保持する認証局ノードへのアクセス履歴と比較し、前記第一の組織による前記認証局を用いた不正な証明書発行を検知する、
    ことを特徴とした請求項６に記載の業務監査支援方法。
  8. 前記第二の組織が保持する専用のハードウェアにおいて、
    前記第二の組織が保持する認証局ノード内の秘密鍵を管理する、
    ことを特徴とした請求項６に記載の業務監査支援方法。
  9. 前記監査ノードが、
    前記第二の組織が保持する認証局ノードへのアクセス履歴に加え、前記第二の組織が保持する分散台帳ノードの構成情報を取得し、前記第一の組織による前記秘密鍵への不正アクセス検知に利用する、
    ことを特徴とした請求項６に記載の業務監査支援方法。
  10. 前記監査ノードが、
    前記第二の組織が保持する認証局ノードへのアクセス履歴に加え、前記第二の組織が保持する認証局ノードが発行した証明書のうち、失効済みの証明書を示す証明書失効リストを取得し、前記第一の組織による前記秘密鍵への不正アクセス検知に利用する、
    ことを特徴とした請求項６に記載の業務監査支援方法。
JP2021054141A 2021-03-26 2021-03-26 業務監査支援システム及び業務監査支援方法 Pending JP2022151190A (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2021054141A JP2022151190A (ja) 2021-03-26 2021-03-26 業務監査支援システム及び業務監査支援方法
PCT/JP2021/030905 WO2022201581A1 (ja) 2021-03-26 2021-08-24 業務監査支援システム及び業務監査支援方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2021054141A JP2022151190A (ja) 2021-03-26 2021-03-26 業務監査支援システム及び業務監査支援方法

Publications (1)

Publication Number Publication Date
JP2022151190A true JP2022151190A (ja) 2022-10-07

Family

ID=83396670

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2021054141A Pending JP2022151190A (ja) 2021-03-26 2021-03-26 業務監査支援システム及び業務監査支援方法

Country Status (2)

Country Link
JP (1) JP2022151190A (ja)
WO (1) WO2022201581A1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116361753B (zh) * 2023-03-17 2024-03-22 深圳市东信时代信息技术有限公司 权限认证方法、装置、设备及介质

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5509796B2 (ja) * 2009-11-02 2014-06-04 コニカミノルタ株式会社 通信システム、通信装置、通信制御方法および通信制御プログラム
US11169985B2 (en) * 2018-07-27 2021-11-09 Oracle International Corporation System and method for supporting SQL-based rich queries in hyperledger fabric blockchains
WO2020049656A1 (ja) * 2018-09-05 2020-03-12 学校法人法政大学 医療情報管理システム及びそれに用いるメンバー装置
CN109816335B (zh) * 2018-12-29 2021-03-16 广州市中智软件开发有限公司 电子证照的签发对账方法、系统、存储介质以及设备
SG11202010851WA (en) * 2019-11-19 2020-11-27 Alipay Hangzhou Inf Tech Co Ltd System and method for consensus management

Also Published As

Publication number Publication date
WO2022201581A1 (ja) 2022-09-29

Similar Documents

Publication Publication Date Title
US11533164B2 (en) System and method for blockchain-based cross-entity authentication
AU2021206913B2 (en) Systems and methods for distributed data sharing with asynchronous third-party attestation
US11025435B2 (en) System and method for blockchain-based cross-entity authentication
US11477032B2 (en) System and method for decentralized-identifier creation
KR102415210B1 (ko) 디지털 명목 화페
EP3424177B1 (en) Systems and methods for distributed identity verification
WO2021000420A1 (en) System and method for blockchain-based cross-entity authentication
US10965472B2 (en) Secure bootstrap for a blockchain network
US20200145373A1 (en) System for blockchain based domain name and ip number register
US20190295069A1 (en) Systems and methods for integrating cryptocurrency wallet identifiers with digital certificates
US11121876B2 (en) Distributed access control
Garba et al. LightLedger: a novel blockchain-based domain certificate authentication and validation scheme
WO2022201581A1 (ja) 業務監査支援システム及び業務監査支援方法
CN113271207A (zh) 基于移动电子签名的托管密钥使用方法、系统、计算机设备及存储介质
CN111769956B (zh) 业务处理方法、装置、设备及介质
US11509484B1 (en) Security settlement using group signatures
CN117061089B (zh) 一种投票管理方法、装置、设备及存储介质
Gergely et al. BlockCACert–A Blockchain-Based Novel Concept for Automatic Deployment of X. 509 Digital Certificates

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20230606

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20240507