ブロックチェーンは、分散型台帳システムであり、中央集中管理機関を持たずに参加者間でデータの共有及び記録をする仕組みです。本稿では、品質面でシステム要件の高い金融機関のITシステムへのブロックチェーン適用性を見極めることを目的に、企業間連携の業務を一例に実施したPoCを紹介します。結果として、本PoCで採用したブロックチェーン基盤であるHyperledger Fabric 1.0は、運用/保守性やセキュリティの面で多くのシステム要件を充足することが判明した一方、現時点では改ざん耐性や暗号化機能など、未達成の項目も存在することが分かりました。

1. はじめに

ブロックチェーンは、サトシ・ナカモト氏により提唱されたBitcoinの基幹となる分散型台帳システムであり、中央集中管理機関を持たずに参加者間でデータの共有及び記録をする仕組みです^1）。2018年時点では、金融業界に限らず、金融業界以外のさまざまな企業により研究開発や実証実験（Proof of Concept： PoC）が進められています^2）3）。

本稿では、ITシステムの信頼性やセキュリティなどの品質面でシステム要件の高い金融業界において、ブロックチェーンを用いたシステム実装で品質基準を充足できるかなどを見極めるべく、NEC、三井住友フィナンシャルグループ、日本総合研究所の三社合同で実施したPoCについて紹介します。

2. PoCの目的及び進め方

金融機関を含む企業間連携システムをユースケースとし、ブロックチェーンを活用したシステムの構築及び運用の実現性・有効性を見極めることをPoCの目的と設定しました。企業間連携に着目した理由は、以下に述べるブロックチェーンの性質との親和性が高いことにあります。

2.1 評価軸の選定

次に、金融業界のITシステムを実現する上で不可欠な以下2点を踏まえ、検証項目を定義しました^4）5）6）。

（1） 運用/保守性

企業間連携ブロックチェーンシステムに必要な運用機能（ノード起動・停止、障害通知など）を洗い出すため、検証環境を構築し、実機での検証を実施しました。

（2） セキュリティ

企業間連携ブロックチェーンシステムで具備すべきセキュリティ機能（データ秘匿やアクセス制限、不正の追跡など）への整合性を見定めるため、検証環境で準拠性の検証を実施しました。

2.2 検証環境

以下に検証環境の概要、図1に全体概観を示します。

ブロックチェーン基盤は、OSS（Open Source Software）のHyperledger Fabric 1.0（以下、Fabric 1.0）を用いました^8）9）。Fabric 1.0は処理部とデータ部に大別でき、「スマートコントラクト」「業務データ」「履歴データ」の3つの要素で構成されます。Fabric 1.0では「スマートコントラクト」 をchaincodeで記述し、「業務データ」をKVS（Key-Value Store）として保持します。図2に構成例を示します。

また、検証環境では、ユーザー操作画面の他に、以下の2つを開発しました。

呼出側アプリケーション

JavaScript言語で実装。ユーザー操作画面からのリクエストを処理し、chaincodeを呼び出す

chaincode

Go言語で実装。業務ロジックを実行する

3. PoCの結果

表1に結果概要を示します。Fabric 1.0は、運用/保守性やセキュリティの面で多くのシステム要件を充足することが判明した一方、現時点では未達成の項目も存在することが分かりました。それらについて、第3章各節で掘り下げて言及します。

3.1 運用/保守性

表2に結果詳細を示します。特筆すべき点として、保有するデータを改ざんされたノードは、改ざんされたことを自身で検知できないことが挙げられます。原因は、ノードがブロックを追加する時に、ハッシュチェーンを検証する処理が不十分なためです。ただし、改ざんされたデータが他のノードに伝播することはありません。また、実機検証にてFabric 1.0の仕様上の問題が2点判明しました。

3.2 セキュリティ

表3に結果詳細を示します。第3章1節でも改ざん耐性についての問題を指摘しましたが、 Fabric 1.0は、データ秘匿やアクセス制限、不正の追跡などの機能が十分でないと言えます。なお、今後のHyperledger Fabricのバーションアップによって、機能が追加される可能性があります。

4. PoCの結果に対する考察

PoCの結果から、金融サービスの基盤としてFabric 1.0を採用するには、現時点で不足している機能を補完するシステムを外部で実装するなどの検討・検証が必要と考えられます。図3に結果を鑑みたシステム構成例を示します。

4.1 運用/保守性

（1） 改ざん耐性

Fabric 1.0では、ブロックチェーンの改ざん耐性の肝となるハッシュチェーンの検証処理が不足しているため、金融機関のITシステムへ適用するには、機能追加が必須となります。

（2） データアーカイブ

Fabric 1.0においては、履歴データ、業務データのいずれにおいても、データは増加する一方であるため、ブロックチェーンを活用するシステムごとにデータの増加量、及び、増加に対する応答性能の劣化を測定し、アーカイブの必要性を検討する必要があります。

4.2 セキュリティ

（1） システム構成

Fabric 1.0におけるシステム構成においては、業務データを保存しているデータベースに対する攻撃耐性を向上させるため、KVSサーバを内部ネットワークに配置する必要があります（図4）。

（2） 監査ログ

Fabric 1.0には監査ログを取る機能がありません。ただし、金融業界のITシステムにおいてはデータへのアクセスの証跡を取ることが要件となる場合が多いため、別途、監査ログを取る仕組みを導入する必要があります。

（3） 鍵管理

Fabric1.0には秘密鍵の管理機能がありません。一般にブロックチェーン基盤では秘密鍵が盗まれないことを前提にしたセキュリティ保証であるため、金融サービスの基盤として採用する場合は、別途、秘密鍵の管理方式を検討する必要があります。例えば、PKCS（Public Key Cryptography Standards）を鍵管理に利用することで対応可能です。

5. おわりに

本稿では、企業間連携システムをユースケースとして、Fabric 1.0が金融業界で求められる品質基準を充足する部分と充足しない部分を明らかにし、ブロックチェーンを取り入れた金融機関のITシステム構築時の留意事項を示しました。ブロックチェーンの適用範囲は、仮想通貨の送金にとどまらず、価値ある情報の共有や、スマートコントラクト機能を活用したシェアリングエコノミーの社会実装など、その広がりが国内外のさまざまな業種で期待されています。しかし、本稿で紹介したPoCで明らかになった項目を含め、実業務への適用にはまだクリアすべき事項が存在しています。ブロックチェーン自体、いまだ仮想通貨以外のユースケースが少ないため、外部セキュリティ監査により、他に具備すべき機能の実装漏れがないかを改めて点検し、詳細にリスクを洗い出すことが必要であるとも考えられます。NECは、実業務へのブロックチェーン適用に向けて、PoCで明らかになった課題を補完するシステム構成での追加PoC、取り巻く社会環境の変化を鑑みた適用分野の拡大、Hyperledger Fabricへのノウハウ還元による普及促進を通じ、ビジネスの発展や豊かで明るい社会や未来を支える社会の実現に貢献していきます^10）。また、三井住友フィナンシャルグループ及び日本総合研究所は一体となって新しいIT技術の積極的な活用に取り組むことで、時代の変化に対応しながら、企業競争力の高い先進的な金融グループを目指すとともに、お客様へのサービス向上に努めていきます。

参考文献

執筆者プロフィール

関連URL