Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Oracle DatabaseのBlockchain Tableのご紹介

Oracle DatabaseのBlockchain Tableのご紹介

Oracle Databaseの機能である、「Blockchain table」のご紹介です。機能とユースケース、実際のサンプルスクリプトをご紹介しています。
- 20230501 Database 23cの機能強化についてのスライドを追加

oracle4engineer

October 04, 2021
Tweet

More Decks by oracle4engineer

Other Decks in Technology

Transcript

  1. 仮想通貨の基盤として始まり、適用領域を拡大 Copyright © 2022, Oracle and/or its affiliates • 2008年にサトシ・ナカモトを名乗る人物が特定の管理者がいないネットワーク上に分

    散した台帳上で管理されるビットコインという新たな通貨(を実現するシステム)に係 る論文をネット上に発表 • 仮想通貨を実現する基盤の特長に徐々に注目が集まり、 より一般的な用途への応用が進み、 「ブロックチェーン/DLT(分散台帳技術)」の適用領域が拡大 • エンタープライズ領域では「データ活用のための信頼できる企業間データ共有基盤」、 「ビジネスプロセス効率化のための企業間ワークフロー基盤」としてユースケースが 続々 4 4
  2. エンタープライズ領域におけるブロックチェーン/DLTとは 複数の企業、組織が協力して課題を解く際に利用できる新たなパラダイム 5 Copyright © 2023, Oracle and/or its affiliates

    従来の企業間データ共有 XXX YYY AAA ZZZ 特定組織にデータと責任、特権が集中 XXX YYY ZZZ AAA ① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨ ⑩ ⑪ ⑫ 従来の企業間ワークフロー 複雑で遅い、手間のかかるプロセス
  3. エンタープライズ領域におけるブロックチェーン/DLTとは 複数の企業、組織が協力して課題を解く際に利用できる新たなパラダイム 6 Copyright © 2023, Oracle and/or its affiliates

    従来の企業間データ共有 XXX YYY AAA ZZZ 特定組織にデータと責任、特権が集中 XXX YYY ZZZ AAA ① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨ ⑩ ⑪ ⑫ 従来の企業間ワークフロー 複雑で遅い、手間のかかるプロセス リアルタイムで水平に共有する 確実で信頼できるデータにもとづいて 業務を自動化、効率化、高度化 ブロックチェーン/DLTによる データとロジックの共有
  4. ブロックチェーンの利用形態(ネットワーク)の分類 Copyright © 2022, Oracle and/or its affiliates パブリック 公開制のネットワークを

    不特定多数で運用 コンソーシアム 許可制のネットワークを 複数組織で運用 プライベート 許可制のネットワークを 単一組織で運用 パーミッションレス← →パーミッションド 7 7 エンタープライズ領域ではこちらが主
  5. 9 Copyright © 2021 Oracle and/or its affiliates 「分散/分権」を実現するためのダウンサイドが伴う ブロックチェーン/DLTがDBと比較して一般に不得意としていること

    複雑な構造 高度な検索 • ブロックチェーンは、複雑な構造を持ったデータをリレーショナルデータベース(RDB)の ようにうまく扱えるわけではない • 高度な検索や集計、分析などの処理も苦手としており、これらのために台帳データを外 部のRDBに複製する必要が生じる場合が多い パフォーマンス • 「データベース」と比較した場合には「ブロックチェーン」の処理性能は数桁ほど違うレベル で遅い • 大量のトランザクション処理、高速なレスポンスが求められるユースケースでは性能限界 への留意と、設計の工夫が必要 サイズの大きなデー タ • 同一データを複数ノードで持つためストレージ効率が悪い • ネットワークでやり取りしてコンセンサスを取ってから書き込む仕組み上、サイズの大きな データを扱うと、大きな処理性能劣化が起こる
  6. プライベート型のブロックチェーン利用とは? Copyright © 2022, Oracle and/or its affiliates パブリック 公開制のネットワークを

    不特定多数で運用 コンソーシアム 許可制のネットワークを 複数組織で運用 プライベート 許可制のネットワークを 単一組織で運用 パーミッションレス← →パーミッションド 10 10 フォーカスは • データの持ち主でも改ざんできないこと • 改ざんされていないことを証明できること これらが実現できれば、使うのは「ブロックチェーン」/ 分散台帳技術でなくてもよい ⇨ブロックチェーンにインスパイアされた技術を備えた 中央集権型データベースの活用にシフト
  7. • データの不変性、耐改ざん性 • データベースの持ち主であっても、 一旦書き込まれたデータを更新、削除できないようにする仕組みを備えている • 検証可能性と監査性、証跡性 • 更新、削除されていないことを検証できる仕組みを備えている •

    検証可能であることにより改ざんされていないことの監査も容易に • 中央集権型(NOT分散/分権) • 複数組織で所有や管理を分散できるようにはなっていない • (「分散データベース」は複数組織で分散できるわけではない) 改ざん不能型データベースとは? 11 11 Copyright © 2022, Oracle and/or its affiliates
  8. Oracle Database Blockchain Table Oracle Blockchain Platform Cloud Service 「信頼できるデータ」でビジネスの課題を解決するふたつの”ブロックチェーン”テクノロジー

    フルマネージドサービスとして提供されるブロックチェーン基盤Oracle Blockchain Platform Cloud Serviceと Oracle Databaseの機能の一部として使えるBlockchain Tableでブロックチェーン技術の活用を強力に推進 Oracleが提供するブロックチェーンソリューション • 実績多数のOSS:Hyperledger Fabricベース • コンソーシアム型ブロックチェーン・ネットワークを形成し、複数企 業間で確実かつリアルタイムにデータとロジックの共有が可能 • 業界全体の抱える課題の解決や、集積したデータの活用による 新たなビジネスを創出をサポート • ユースケースの例: • サプライチェーンのトレーサビリティ向上と全体効率化 • 発注/請求/支払業務の自動化 • データの追記のみを許し、削除/修正不可の特殊なテーブル • 外部からの攻撃はもちろん、管理者を含めた内部による改ざんも 防止し、データの検証可能性により監査も容易 • 既存のデータベース資産とスキルを活かしてすぐに、容易に、ピン ポイントでの利用開始が可能 • ユースケースの例: • 契約情報や会計/財務データ、CO2排出量などの法律上 確実な保管が要求される情報の保持 • セキュリティログや監査証跡の保存 分散/分権 集中管理 Copyright © 2021 Oracle and/or its affiliates 12 Copyright © 2022, Oracle and/or its affiliates 12
  9. ブロックチェーン/DLTと改ざん不能型データベース:それぞれの用途 対応する 主要なニーズ 例となる ユースケース ▪ 複数の企業間で水平に確実かつリアルタイムに データを持ち寄り共有したい ▪ 企業をまたいだワークフローを信頼できるかたち

    で実行したい ▪ 原材料~製造~輸送~小売までの一貫した データ持ち寄りによるサプライチェーンの全体最適 化 ▪ スマートコントラクトによる取引約定~決済までの 企業間ワークフローの自動化、効率化、迅速化 ▪ 台帳上での価値交換 分権/分散, ブロックチェーン/DLT Oracle Blockchain Platform ▪ 法律上確実な保存が要求される契約情報や会 計、財務データの保持 ▪ 重要なアクセス情報や操作履歴などの システムログを監査証跡として保存 ▪ データを外部犯行、内部犯行両面から保護し、 セキュリティ確保 ▪ 保存して以降、誰にも変更・削除できないよう データを保持したい ▪ 監督機関、監査法人などに対し、改ざんされて いないことを証明したい 中央集権, 改ざん不能型データベース Oracle Database Blockchain Table 13 Copyright © 2022, Oracle and/or its affiliates 13
  10. • エンタープライズ領域ではブロックチェーン/DLTという分散/分権のパラダイムは 複数組織での協力が必要な課題に取り組む際の選択肢 • データとロジックの水平で確実な共有によって解ける課題を解く • 改ざん不能型データベースは中央集権型で、 • エンタープライズ領域でのブロックチェーンユースケースにおける耐改ざん性と証跡性へのニーズに対応し て言わば「後出し」で登場

    • 証跡性、監査性、セキュリティの課題を解く • 両者は一部の技術要素に共通する部分があるが、フォーカスが異なる • 解くべき課題の内容はもちろん、時には組織間の関係性など多角的な要素を考慮して選定する必要が ある まとめ:ブロックチェーン/DLTと改ざん不能型データベース Copyright © 2021 Oracle and/or its affiliates 14
  11. 耐改ざん性を追加、監査性を強化した特別なデータベース・テーブル データベース上のレコードに耐改ざん性と監査性を付与 • 追記オンリーの不変なデータ…テーブル所有者も特権ユーザも改ざん不能 • ハッシュチェーンで行をリンク…整合性の検証、改ざんされていないことの証明が可能 Oracle Databaseの一部として高度で多彩な機能とともに容易に利用可能 • 他のテーブルと組み合わせたトランザクション

    • 容易にデータ統合、多様なBIツールを用いての分析 • データベーストリガー、PL/SQLプログラムを利用したロジック表現 • レプリケーション、バックアップなどの耐障害性/高可用性機能、 アクセスコントロールなどのセキュリティ保護機能も併用可能 ※19cではRU19.11アップデートを適用することで利用可能に。 データベースの基本機能として含まれており追加ライセンスは不要(SE2でも利用可能)。 Blockchain Table:Oracle Database 21c以降&19cで利用可能(※) 16 16 Copyright © 2023, Oracle and/or its affiliates
  12. 情報の真正性の担保=確実な保管と監査、証明を大幅にシンプル化 Blockchain Tableを用いることで… 情報の 確実な保管 監査と証明 認証設計、アクセス制御、監査ログ、etc... 様々な情報を収集し、突き合わせて整合性を確認 複雑で手間のかかる監査プロセス データベースに情報を保存しつつ、

    耐改ざん性のために紙原本や別媒体での記録 →記録、保管に余分なコスト Blockchain Tableに保存し、 データ活用の利便性と耐改ざん性を両立 Blockchain Tableで完結した検証可能性により 監査、証明が容易 17 17 Copyright © 2022, Oracle and/or its affiliates
  13. • すぐに、簡単に使える • 耐改ざん性と監査性の課題をシンプルに、最低限のコストだけで解決 • アプリケーションの改修はゼロ~最小限、学習コストも極小 • ピンポイントソリューション • 他の箇所に影響を与えることなく、データベースの一部分、アプリケーションの一部分のみにセキュリティ

    向上を適用可能 • 参照、分析、データ統合、BIツール等は通常テーブルと同様にそのまま使える • どこでも利用可能 • クラウドでもオンプレミスでも利用可能 • 追加ライセンス不要:データベースのすべてのエディションで利用可能 Blockchain Tableの特長 18 18 Copyright © 2022, Oracle and/or its affiliates
  14. Blockchain Table: 主なユースケース Copyright © 2021 Oracle and/or its affiliates

    19 内外からの攻撃に対してデータを保護 ・勘定系システム、決済系システムなどのトランザクションログ ・証券や各種アセットの所有権を管理する原簿 セキュリティ上重要な記録の保存 ・アプリケーションのアクセスログや監査ログ ・高セキュリティエリアへの入退室記録 種々の認定、証明のエビデンス、法律上確実な保存が要求される情報 ・従業員の出退勤記録、企業の会計、財務のデータ ・見積、契約、請求や支払のやり取りに係るドキュメント ・原産地証明、検査証、品質認証、RE100証明、CO2排出量証明など
  15. Blockchain Tableのご利用事例 GDPR関連データへのアクセスなど、 銀行の法的に重要な業務について のレポートおよび監査ログを Blockchain Tableに保存 管理ワークフロー(申請、確認、 データ暗号化)の法的な記録を高 い監査性で保持できるように

    コーポレート・ガバナンスに係るワークフ ローの作業をBlockchain Tableに記 録して追跡可能にすることで、信頼性、 不変性を担保し、また、証書を発行 ドキュメントへのデジタル印の生成を可 能に: • ドキュメントの初版 • ドキュメントのレビュー • 承認ワークフロー 等 匿名化された(ある距離内/持続時間 以上の)接触の記録をBlockchain Tableに保管 アプリユーザーがCOVID19陽性となった 場合には、X-RINGのボタンを押すことで、 濃厚接触した可能性があるすべてのユー ザーに警告通知を送ることができる スマートコンプライアンス 法律×テクノロジー 接触追跡ソリューション 20 20 Copyright © 2022, Oracle and/or its affiliates
  16. 【Blockchain Table検証事例】 PwC様:アンカリングによる証拠データの信頼性担保 クライアントのeディスカバリー業務(電子証拠開示)を支援されているPwC様において、Oracle Blockchain Tableとパブリック チェーンを組み合わせ、第三者視点で証拠データの信頼性を担保する検証を実施いただきました。 21 eディスカバリーの業務ステップ Webアプリを使用した検証

    業務上の要求事項/課題 アーキテクチャ概要 収集 レビュー/分析 提出/報告 証拠性を保持しつつ データを受領 データ分析で検知した 不正をレビュー レビュー結果を文書に 整理・報告 ✓Oracle Blockchain Tableとパブリックチェーンの組み合わせ ✓Forensic業務以外でも信頼性担保を要求する業務に適用可能 ・証拠データは収集から分析、報告、破棄に至るまで トレース出来る必要がある ・プロジェクトの実施内容について、データが改ざんされていないことを 証明する必要がある ・従来はExcel資料や紙媒体で管理していたが、手作業を 排除し アプリで一元管理することで業務品質を高めたい ✓Oracle Cloudを用いてPwCインドとWebアプリを構築 ✓証拠データとクライアント署名を紐づけブロックチェーン上で管理 ✓デバイスに張り付ける QRコードも自動生成 証拠データの ハッシュ値を に保存 テーブルの ダイジェスト値 を保存 Oracle Database Cloud Service Blockchain Table パブリック ブロックチェーン 証拠データ Copyright © 2022 Oracle and/or its affiliates
  17. 【Blockchain Table検証事例】 PwC様:アンカリングによる証拠データの信頼性担保 クライアントのeディスカバリー業務(電子証拠開示)を支援されているPwC様において、Oracle Blockchain Tableとパブリック チェーンを組み合わせ、第三者視点で証拠データの信頼性を担保する検証を実施いただきました。 Copyright © 2022

    Oracle and/or its affiliates アーキテクチャ Oracle Cloud Infrastructure Load Balancer Object Storage DDoS Protection WAF DNS 証拠データのハッシュ値を Blockchain Tableに保存 テーブルの ダイジェスト値を パブリック ブロックチェーン上に保存 (アンカリング) Webアプリ Oracle Database Cloud Service Blockchain Table パブリック ブロックチェーン 証拠データ 監査法人 ユーザー 22
  18. 【Blockchain Table検証事例】 Green x Digitalコンソーシアム実証実験におけるNRI-CTSでの活用 23 Copyright © 2023, Oracle

    and/or its affiliates 図: Green x Digital コンソーシアム 実証フェーズ1 成功報告より引用 https://www.gxdc.jp/pdf/press_release230215.pdf サプライチェーンCO2排出量データ見える化の実証 ✓ Green x Digitalコンソーシアム(*1) は、サプライチェーンCO2排 出量見える化に向けた企業間データ交換の実証実験を実施 ✓ ソリューション提供企業が参加し、製品の仮想サプライチェーン 上で複数ソリューション間のデータ 連携を行う実証フェーズ1は 成功裏に完了(2023年2月) ✓ ユーザー企業も参加する実証フェーズ2が進行中 (~2023年6月完了予定) 実証ソリューションにBlockchain Tableを活用 ✓ 野村総合研究所(NRI)のCO2排出量算定・データ連携ソ リューションであるNRI-CTS (*2) が実証に参加 ✓ 実証実験の中で、NRI-CTSではOracle Databaseの機能で あるBlockchain TableをOCI(*3) 上で活用 ✓ データのより高いトレーサビリティと信頼性を実現 *1: Green x Digital コンソーシアム https://www.gxdc.jp/ *2: 野村総合研究所 様 NRI-CTS https://www.nri.com/jp/news/info/cc/lst/2021/1215_1 *3: Oracle Cloud Infrastructure
  19. Green x Digitalコンソーシアム実証実験におけるNRI-CTSでの活用 NRI-CTS:サプライチェーンにおける温室効果ガス(GHG)排出量算定・データ連携ソリューション 24 Copyright © 2023, Oracle and/or

    its affiliates 図:野村総合研究所 NRI-CTSプロトタイプ紹介資料より引用 https://www.nri.com/jp/news/info/cc/lst/2021/1215_1 NRI-CTSで企業のSCOPE3対応を支援 ✓ 他者の排出量削減の取り組みにより得られた成果をよりタイム リーに自社のSCOPE3の排出量に取り込むためには、「サプライ チェーンにおける実測値による排出量把握」の実現が必要 ✓ 実測値による排出量情報の共有において多くの企業が抱える、 対応負荷と情報反映までの時間差の大きさ、正確性の担保など の課題をNRI-CTSが解消 ✓ 2023年のサービス開始を予定 NRI-CTSの特長 ✓ 実測値に基づくサプライチェーンのGHG排出状況把握の支援と 排出量のトレーシング ✓ 使いやすいインターフェースで、ロングテールの取引先まで容易に 情報展開が可能 ✓ エネルギー消費量やオフセット状況、正確性に関する情報も同時 に伝達 ✓ SCOPE1に関する他社の取り組みとの連携 ✓ カーボンフットプリント情報共有の国際的な技術仕様 「Pathfinder Network」の準拠ソリューションとしていち早く認定
  20. Green x Digitalコンソーシアムと サプライチェーンCO2排出量見える化実証について Green x Digitalコンソーシアムおよび見える化WGについて Green Digitalは、電子情報技術産業協会(JEITA)が事務局を務める、社会全体でのカーボンニュートラルの実現に向け、デジタル技術を活用した 新しい社会作り・市場創造を目指す企業間コンソーシアムです。

    配下の見える化WG(ワーキンググループ)では、サプライチェーンの企業間でCO2排出量データを連携しスコープ3を含む見える化のための仕組みを検 討、「CO2可視化フレームワーク」と「データ連携のための技術仕様」を策定してきました。さらに、それらに基づき、多様な業界の企業が共通的な方法で 算定した排出量データを、異なるソリューション間でデータ連携し、サプライチェーンCO2排出量を正確かつ効率的に把握することを目的とした実証実験 を2022年9月からスタートしています。 日本オラクルはGreen x Digitalコンソーシアム、また、見える化WGのメンバーであり、見える化実証フェーズ1、フェーズ2にもソリューション提供企業として 参加しています。 見える化実証 フェーズ1について 2022年9月~2023年1月にかけ、ソリューション提供企業15社が参加し実施されました。 グローバルでのデータ連携を見据え、先行する国際的な枠組みであるWBCSD Partnership for Carbon Transparency(PACT)のPathfinder Networkにて提示されているデータフォーマットとAPI(接続方式)を用いて、製品の仮想サプライチェーン上で複数ソリューション間のデータ連携が検証 されました。 詳細はJEITAの実証フェーズ1成功報告(https://www.jeita.or.jp/japanese/topics/2023/0215.pdf)を参照ください。 見える化実証 フェーズ2について ソリューション提供企業に加えユーザー企業も参加して、CO2算定実務も含めた検証を行う「フェーズ2」が2023年6月中の完了を目指して進行中です。 25 Copyright © 2023, Oracle and/or its affiliates
  21. 文書の確実な保存とその証明 • SaaSの”スキマ”にピンポイントで適用 • APEXを活用し短期間、低コストで開発 • ペーパーレス化による、脱はんこ、 リモートワーク対応力向上 電子帳簿保存法の改正対応 •

    2022年1月施行開始 • 改正による要件緩和で、 システム見直しとコスト削減のチャンス • ERPの補助システムや、 パートナー様のソリューションの一部として 品質検査や製造履歴の改ざん対策 • 製造業を中心とした、品質情報の改ざん 対策 • 品質情報や製造履歴に関わる、 内部不正を防止し、真正性を証明 • 複合的な対策の一部として活用 ESG関連情報の保存 • 関連する情報は、より厳しい水準の管理 が要求されていく • 改ざんを防ぎつつ、外部に証明しやすい 形式で確実に保存 • 紛争鉱物などの法規制対応、SCOPE3 対応の二酸化炭素排出量管理、 原材料や含有物質管理 Blockchain Table×旬な領域 Copyright © 2021, Oracle and/or its affiliates 26
  22. 文書の内容および履歴をBlockchain Tableで保持することで、真正性を担保し監査性も向上 Blockchain TableはOracle Databaseのテーブルなので: • ドキュメントファイルそのものを登録可能 (WORD、EXCEL、PDF、画像形式など) • 登録したドキュメントの中身の文章も検索可能

    (Oracle Textによる全文検索) 文書に付随する履歴も併せて保存可能: • 修正、更新に伴う複数のバージョンを保存 • 申請~承認のようなワークフローの操作履歴を保存 監査も容易に: • 保存されて以降不変な内容、登録日時、履歴をチェック • 整合性検証機能を利用することで改ざんされていないことを容易 に確認、証明可能 Blockchain Table応用例: 文書の確実な保存とその証明 Copyright © 2021, Oracle and/or its affiliates 27 A部門 B部門 C部門 作成 更新 承認 監査 履歴情報 文書内容
  23. 電子取引保存およびスキャナ保存の要件を満たしたシステムを短期間、低コストでシンプルに構築 電子取引保存 • 真実性の要件:Blockchain Tableの耐改ざん性を活かし、記録事項の訂 正・削除をできないようにする、あるいは訂正・削除の履歴を確実に保存し確 認可能に • 可視性の要件:検索機能も容易に実装可能 スキャナ保存

    • 「電磁的記録について訂正又は削除を行った場合に、これらの事実及び内容 を確認することができる」 「入力期間内にその電磁的記録の保存を行ったことを確認することができる」 の条件を満たすシステムを開発することで、原本保存を廃止(ペーパーレス) &タイムスタンプサービスを利用したタイムスタンプ付与が不要に 既存ERPの補助システムとして開発・利用 • 上記について必要となる範囲でピンポイントに実装し、監査を含めた追加・変 更オペレーションも最小限に • データベースに含まれるOracle APEX機能を活用することで、UIも簡易に開 発・運用が可能 Blockchain Table応用例: 改正電子帳簿保存法への対応に活用 Copyright © 2021, Oracle and/or its affiliates スキャナ保存 電子取引 ERP Blockchain Tableにも保存 APEX 28
  24. 品質情報に関わる内部の不正を防止し、真正性を証明 Blockchain Table応用例: 品質検査結果データへの耐改ざん性付与および外部証明 検査装置 2.データの分析、検索 1.検査結果ファイル、ファイルのハッシュ、検査値を、 耐改ざん性の高いBlockchain Tableに登録 5.

    外部に開示したドキュメントの真正性を 証明するためには、別途の仕組みの検討が必要 例)ハッシュ値をブロックチェーン上で共有 4.品質証明書を取引先に開示 取引先 3.品質証明書を作成、 Blockchain Tableに登録 Copyright © 2021, Oracle and/or its affiliates 29
  25. 求められる「データの正当性」、「詳細かつリアルタイムでの可視化」、「データドリブンなアクションと経営判断」 Blockchain Table応用例: 脱炭素社会への取り組みの信頼できるデータ基盤に利用 30 CO2排出量DB 可視化 予測 アクション Copyright

    © 2021, Oracle and/or its affiliates | CO2排出量DB CO2排出量、品質検査/品質認証、RE100証明、原産地証明 などへの展開 1.自社の稼働実績に基づいた CO2排出量を算出、集約 2.集約されたCO2排出量を可視化、 詳細な改善アクションへ 4.LCAでの排出量正当性のため、 他社企業とのデータ開示、 ユーザー使用の排出把握 3.CO2排出量の正当性証明のため 取引先、投資家、監査機関へ共有 自社 他社 取引先、投資家、 監査機関
  26. 文書ファイルの保存、参照、管理のBlockchain Table+APEXでの容易な実現を体験 Blockchain Tableのふたつの特性―耐改ざん性と監査性―を、文書ファイルの管理の シナリオを通じて体験いただくためのサンプルアプリケーションです。 • WORD、PDF、Excel、テキストなど任意の形式の文書ファイルをBlockchain Tableに保 存(アップロード)し、文書の検索や参照(ダウンロード)が可能です。 •

    Blockchain Tableの持つ耐改ざん性、監査性を体験するための機能も備えています。 データベース上で迅速、容易にアプリケーションを開発し、稼働させるためのツールである Oracle APEXを利用しています。 • アプリケーションサーバーの用意は不要で、Oracle Databaseのみでサンプルアプリケー ションの利用が可能です。 • インストール~セットアップは最速数分程度で完了し、すぐにトライ可能です。 詳細、ダウンロードはこちら:https://oracle- japan.github.io/ocidocs/solutions/blockchain/blockchain-table-document- sample/ サンプルアプリケーション:Blockchain Tableでの文書管理 Copyright © 2021, Oracle and/or its affiliates APEX 31
  27. 追記オンリーのテーブルで、イミュータブル/不変なデータを保持 • 行のDELETEの制約(n日~無制限の保持期間を設定可能) • 保持期間を設定しておいた場合、INSERT後に保持期間を過ぎた行は削除することが可能 • 通常のDELETE操作は不可で、保持期間を過ぎた行の一括削除用PL/SQLパッケージファンクションを使用 DBMS_BLOCKCHAIN_TABLE.delete_expired_rows() • 行のUPDATEとMERGEが不可

    • テーブルのDROPの制約(n日~無制限の保護期間を設定可能) • テーブルDROPは行のINSERT前なら常に可能(誤ってテーブル作成した場合すぐなら消せる) • テーブルのTRUNCATE、パーティションのDROPが不可 • カラムの追加/削除(※)および変更が不可 • 名前、データ型や一部の長さ、精度の変更、NULL制約変更が不可 • ※カラム追加と削除は23cでの機能追加により可能になった • Blockchain Tableの通常のテーブルへの変換、およびその逆の変換は不可 Blockchain Tableの特性①:データの削除、変更を制約 33 33 Copyright © 2023, Oracle and/or its affiliates
  28. ハッシュ値によるデータの検証可能性により、テーブルの中で完結した監査性を提供 Blockchain Tableの特性②:ハッシュチェーン • 行のINSERT時、自動的に {行データ+前の行のハッシュ値} に対して計算したハッシュ値を隠しカラムに保持 • ある行のハッシュ値はその前の行のハッシュ値に依存し、その前 の行のハッシュ値はその前の前の行のハッシュ値に依存し…

    →ハッシュチェーンのつながりで改ざんが検知可能に • ハッシュチェーンと行データを突合しながら辿っていくことで、整合 性(INSERT以降、行データが変更、削除されていないこ と)の検証が可能 • 検証用PL/SQLパッケージファンクション DBMS_BLOCKCHAIN_TABLE.verify_rows() ID User Value 1 Tom 500 2 Carol 176 3 Steve 500 4 John 176 5 Mike 332 6 Sarah 632 7 Eve 25 8 Prisha 850 Hash ADSJS %SHS SH@1 DHD3 *EGG AH11 LIO$ SHS4 Copyright © 2021, Oracle and/or its affiliates 34 Copyright © 2023, Oracle and/or its affiliates
  29. Q. データが削除不能なら容量がずっと積み上がり続け るのでは?不要になっても消せない? A. 古いデータを破棄できるようにする設定も可能です。 ・行レベル:登録後、指定の日数過ぎた行は削除が可 能になる ・テーブルレベル:指定の日数新たなデータが登録されな い場合、テーブルの削除が可能になる いずれのレベルの設定もテーブル作成時に定義します。

    作成以降は設定を緩められない点に注意ください。 Q. バックアップやリストアはできる? A. バックアップ、リストアも可能です。 ただし、Flashback Tableや19cでのDatapumpを利用 した論理バックアップ/リストアなど、耐改ざん性の担保の 仕様上、一部のツールには制約があります。 Q. インデックスやトリガー、通常のテーブルと組み合わせ たJOIN、VIEWやトランザクションは使用できる? A. 使用可能です。 Q. 利用できるデータ型は? A. 通常のテーブルで利用可能なほとんどのデータ型が 利用可能です。一部(LONG、TIMESTAMP WITH TIME ZONEやBFILE等)のデータ型のみ利用できませ ん。 Q. 削除、更新不可の他に制約はある? A. シャーディング、分散トランザクションなど一部のデー タベース機能の利用に制約があります。 21cの公式ドキュメント、19cの公式ドキュメントそれぞれ の制約の箇所を確認ください。 Blockchain TableのFAQ Copyright © 2023, Oracle and/or its affiliates
  30. 開発と分析に最高の生産性を 統合された マイクロサービス、イベント、REST, SaaS, 機械学習, CI/CD, ローコード あらゆるワークロードをサポート トランザクション, 分析,

    機械学習, IoT, ストリーミング, ブロックチェーン あらゆるデータをサポート Relational, JSON, グラフ, 地理空間, テキスト, OLAP, XML, マルチメディア 世界で唯一のコンバージドデータベース - インクラウドとオンプレミスの両方に対応 オラクルデータベースのビジョン Copyright © 2021 Oracle and/or its affiliates 36 Copyright © 2023, Oracle and/or its affiliates
  31. ブロックチェーン/DLT基盤や専用データベースと比較して…… 利用のハードルが低い • 一般的なOracle Databaseのスキルで十分使いこなせるため、学習コストが低い • 通常のテーブルとの使い勝手の差異が小さく、アプリケーション透過的な利用が可能 • 通常テーブルからの乗り換えに必要な改修はゼロ~最小限 アプリケーション側の負担が小さい

    • 通常の構造化データやJSON、BLOB(画像やドキュメントファイル)、CLOBなど多様な形式のデータを Blockchain Table上で扱えるため、複数のデータストアを使い分ける必要がない • 同一DB上で通常のテーブルとBlockchain Tableを扱えるためトランザクション、整合性担保が容易 データ分析、データ統合が容易 • Blockchain Table上でそのまま集計、分析が可能 • 他テーブル上のデータとのJOINやVIEW、多様なデータ統合ツールやBIツールも利用可能 処理性能 • Oracle Databaseの様々な処理性能向上手段を適用可能(例:Exadataを利用) Oracle Databaseの1テーブルとして使えることのメリット Copyright © 2021, Oracle and/or its affiliates 37 Copyright © 2023, Oracle and/or its affiliates
  32. アプリケーションの負担を減らし、分析のための余分な手間も削減 単一用途データベース vs Oracle Database App BI DIツール イミュータブル データ専用DB

    (又はブロックチェーン/DLT) 通常データ用 DB トランザクション トランザクション 複製 複製 分析 分析用 DB 整合性担保は アプリの責任 単一用途データベースの場合 Oracle Databaseの場合 App BI 分析のための データ統合に 余分な手間 トランザクション Oracle Database 分析 DB機能で 整合性担保 同一DB上で 容易に分析 Copyright © 2021, Oracle and/or its affiliates 38 単一用途データベースの場合 Oracle Databaseの場合 Copyright © 2023, Oracle and/or its affiliates
  33. CREATE BLOCKCHAIN TABLE + 3つの必須句 Blockchain Tableの作成 Copyright © 2023,

    Oracle and/or its affiliates CREATE BLOCKCHAIN TABLE table_name(columns,constraints) NO DROP [ UNTIL number DAYS IDLE ] NO DELETE [ LOCKED ] | NO DELETE UNTIL number DAYS AFTER INSERT [LOCKED] HASHING USING sha2_512 VERSION v1 テーブルのDROPに対しての制約を記述する句。 • UNTIL n DAYS IDLEを付けておいた場合、テーブル上の最新の行がINSERT後n日経っていないとDROPでき ない(→付けない場合は常にDROP不可)。nの最小は0(16以上の指定を推奨)。 • 後からALTER TABLEでUNTIL~~は付けられない&nを減らせない(制約を緩められない)。 行のDELETEに対しての制約を記述する句。 • UNTIL n DAYS AFTER INSERTを付けておいた場合、INSERT後n日経っていないとDELETEできない(→ 付けない場合は常にDELETE不可)。nの最小は16。 • 後からALTER TABLEでUNTIL~~は付けられない&nを減らせない(制約を緩められない)。 • LOCKEDを付けておくとnを増やすことも不能。 利用するハッシュアルゴリズムとデータフォーマットを記述する句。現状、値は固定。
  34. シンプルなCREATE BLOCKCHAIN TABLEの例 Copyright © 2023, Oracle and/or its affiliates

    CREATE BLOCKCHAIN TABLE bank_ledger (bank VARCHAR2(128), deposit_date DATE, deposit_amount NUMBER) NO DROP UNTIL 31 DAYS IDLE NO DELETE LOCKED HASHING USING "SHA2_512" VERSION “V2"; • NO DROP UNTIL 31 DAYS IDLE …テーブル上の最新の行がINSERT後31日経っていないとDROPできない • NO DELETE LOCKED …行は無期限にDELETEできない 40
  35. Copyright © 2023, Oracle and/or its affiliates 隠しカラム 説明 INST_ID$

    行が書き込まれたデータベースインスタンスを示すID CHAIN_ID$ 行が属するハッシュチェーンを示すID SEQ_NUM$ そのハッシュチェーンの中で何番目の行かを示すシーケンス番号 CREATION_TIME$ 自動的に記録される行の作成時刻 USER_NUMBER$ 行を書き込んだデータベース・ユーザーのユーザー番号 HASH$ (行内容および前行のハッシュ値から計算された)ハッシュ値 SIGNATURE$ ユーザーの秘密鍵を用いて行のハッシュ値から計算されたデジタル署名(オプショナル) SIGNATURE_ALG$ デジタル署名に使用した署名アルゴリズム SIGNATURE_CERT$ デジタル署名に紐付いた証明書のGUID SPARE$ 現状未使用の予備カラム Blockchain Tableの隠しカラム 作成時刻や行ハッシュ値などのデータを格納
  36. App Database • Blockchain Table上の行データに対し、エンドユーザーが自身の 秘密鍵を用いて生成したデジタル署名を付与可能 • 秘密鍵は(DBには引き渡さず)アプリケーション側で保持し、 署名の生成もDB外で実行 •

    エンドユーザーのデジタル証明書はDBに事前に登録 • 証明書に照らして署名が有効かチェックされる • 「誰が書き込んだか」を確実に区別、記録することでセキュリティを 向上し、否認防止にも利用可能 • さらに応用編として、書き込まれた行内容および署名に対して テーブルオーナー側の秘密鍵を用いた副署(Countersign) の要求が可能 • 副署を受領証としてアプリケーションに返却することで、書き込 み成功の確実性の担保および双方向の否認防止が可能 エンドユーザーによるデータへのデジタル署名(オプショナル) Copyright © 2023, Oracle and/or its affiliates CertID GRTE SOQP OPRT ID User Value 1 Tom 500 2 Carol 176 3 Wang 500 TRADE LEDGER Signature RT#E GI(! HV*P 行内容 ハッシュ 署名& 証明書ID 行内容 ハッシュ ①書き込み ②署名 ③副署 受領証 42
  37. テーブル作成時に”Immutable”キーワードを追加するだけでインサート オンリーの不変なテーブルを作成 • リレーショナルデータ、JSONやLOBドキュメントも格納可能 • 帳簿データだけでなく参照情報もテーブルに保管 通常のテーブルと同様に利用が可能だが、以下の操作には制約: • 行のUPDATEとDELETE •

    テーブル定義の変更 • Immutable Tableの通常のテーブルへの変換、およびその逆 • データベースディクショナリでテーブルメタデータの修正 アプリケーションに変更を加えることなくImmutable Tableを利用可能 Oracle Immutable Table CREATE IMMUTABLE TABLE trade_ledger (…); ID User Value 1 Tom 500 2 Carol 176 3 Wang 500 4 Eve 25 TRADE LEDGER データベース19.11, 21.3で利用可能 Copyright © 2021, Oracle and/or its affiliates 43 Copyright © 2023, Oracle and/or its affiliates
  38. Copyright © 2023, Oracle and/or its affiliates Oracle Database 23cでの

    Blockchain Table関連の機能強化 ※2023年4月現在、Oracle Database 23cは開発者向けの無償版であるDeveloper Editionのみがリリースさ れております。商用利用可能な正式リリース版までに記載した機能等に変更が入る可能性があることにはご留意く ださい。 44
  39. Oracle Database 23cで導入されたBlockchain Table関連の機能強化 機能強化 説明 詳細 行バージョンおよび最新バージョンビュー機能の追加 行バージョンの自動採番機能、および最新バージョン行を抽出する ビューの自動作成機能が追加された。

    ◦ User Chain機能の追加 ユーザー側で定義したグループに対してハッシュチェーンを付与、検証 できるようになった。 ◦ より柔軟なデータへの署名プロセス 代理ユーザーによる委任署名の追加など、プロセスが改善された。 ◦ 副署プロセスの改善 副署機能が追加され行メタデータとしても格納されるようになった。 ◦ カラムの追加/削除が可能に 作成済のBlockchain Tableのカラムの追加、削除が可能になった。 ◦ Flashback Data Archiveのログの格納に対応 通常テーブルのFlashback Data Archiveの格納先にBlockchain Table を選べるようになった。 長期テーブル保持期間の設定に用いられる新しいユーザー権限が追加 テーブル保持期間に関するしきい値の設定が追加され、これ以上の 期間を指定する場合には新たに権限(TABLE RETENTION)が 要求されるようになった。 ◦ Copyright © 2023, Oracle and/or its affiliates
  40. Blockchain Table v2(バージョン2)の導入 Copyright © 2023, Oracle and/or its affiliates

    CREATE BLOCKCHAIN TABLE bank_ledger (bank VARCHAR2(128), deposit_date DATE, deposit_amount NUMBER) NO DROP UNTIL 31 DAYS IDLE NO DELETE LOCKED HASHING USING "SHA2_512" VERSION “V2"; • 23cの機能強化のほとんどはv2のみが対象 • 23c以降のバージョンでBlockchain Tableを作成する場合、基本的にv2を推奨 • 既存のv1のBlockchain Tableをv2にアップグレードすることはできないので、 作り直しとデータ移行が必要 46
  41. Oracle Database 23cで導入されたBlockchain Table関連の機能強化 機能強化 説明 詳細 行バージョンおよび最新バージョンビュー機能の追加 行バージョンの自動採番機能、および最新バージョン行を抽出する ビューの自動作成機能が追加された。

    ◦ User Chain機能の追加 ユーザー側で定義したグループに対してハッシュチェーンを付与、検証 できるようになった。 ◦ より柔軟なデータへの署名プロセス 代理ユーザーによる委任署名の追加など、プロセスが改善された。 ◦ 副署プロセスの改善 副署機能が追加され行メタデータとしても格納されるようになった。 ◦ カラムの追加/削除が可能に 作成済のBlockchain Tableのカラムの追加、削除が可能になった。 ◦ Flashback Data Archiveのログの格納に対応 通常テーブルのFlashback Data Archiveの格納先にBlockchain Table を選べるようになった。 ◯ 長期テーブル保持期間の設定に用いられる新しいユーザー権限が追加 テーブル保持期間に関するしきい値の設定が追加され、これ以上の 期間を指定する場合には新たに権限(TABLE RETENTION)が 要求されるようになった。 Copyright © 2023, Oracle and/or its affiliates 47
  42. • Blockchain Table上で更新が入る情報を扱うには、 新バージョンとしてデータを追記していくことで表現する • 例:ある銀行口座について、残高が更新されるたびに行を追加 • 23cでは、このような複数行によるバージョン表現の使い勝手を強化 • テーブル作成時、最大3つのカラムを指定し、

    それらの値が同一な行を行グループとして管理 • 例:同一のBANKおよびACCOUNT_NOの値を持つ行を 行グループに指定 • INSERT時、自動で行グループ内のバージョン番号が採番され、 隠しカラム(ORABCTAB_ROW_VERSION$)に格納 • さらに、それぞれの行グループから最新のバージョンの行を抽出するビュー (例:BANK_LEDGER_LAST$)を自動的に生成 ※ROW VERSION対象のカラムの型はNUMBER、CHAR、VARCHAR2、RAWに限定 行バージョンおよび最新バージョンビュー機能の追加 Copyright © 2023, Oracle and/or its affiliates CREATE BLOCKCHAIN TABLE BANK_LEDGER ("BANK" VARCHAR2(128 BYTE), "ACCOUNT_NO" NUMBER, "DEPOSIT_AMOUNT" NUMBER ) … WITH ROW VERSION BANK_ACCOUNTS (BANK,ACCOUNT_NO) … BANK ACCOUNT _NO AMOUNT VERSION$ A BANK 123456 100 1 A BANK 123456 200 2 A BANK 123456 500 3 48
  43. • あるBlockchain Table上の行のハッシュチェーンの検証には、 そのテーブル上のすべての行へのアクセスが必要となっていた • 単一のテーブル上に複数種類の当事者の異なる情報が混在しているよう な場合に、プライバシー上の課題につながる • 23cでは、ユーザー側で定義した行グループそれぞれに独立したハッシュチェーン (User

    Chain)を付与することが可能に ※行バージョン機能の利用が前提 • User Chainを対象としたハッシュチェーン検証機能を追加 • メリット: • より高速な検証:User Chainごとに含まれる行のみ • プライバシー:検証の実行者に対しあるBlockchain Table上の行すべて ではなく、あるUser Chainに属する行(同一行グループに属する行) だけを開示すれば済む User Chain機能の追加 Copyright © 2023, Oracle and/or its affiliates CREATE BLOCKCHAIN TABLE BANK_LEDGER ("BANK" VARCHAR2(128 BYTE), "ACCOUNT_NO" NUMBER, "DEPOSIT_AMOUNT" NUMBER ) … WITH ROW VERSION AND USER CHAIN BANK_ACCOUNTS (BANK,ACCOUNT_NO) … 49
  44. App Database • Blockchain Table上の行データに対し、エンドユーザーが自身の 秘密鍵を用いて生成したデジタル署名を付与可能 • 秘密鍵は(DBには引き渡さず)アプリケーション側で保持し、 署名の生成もDB外で実行 •

    エンドユーザーのデジタル証明書はDBに事前に登録 • 証明書に照らして署名が有効かチェックされる • 「誰が書き込んだか」を確実に区別、記録することでセキュリティを 向上し、否認防止にも利用可能 • さらに応用編として、書き込まれた行内容および署名に対して テーブルオーナー側の秘密鍵を用いた副署(Countersign) の要求が可能 • 副署を受領証としてアプリケーションに返却することで、書き込 み成功の確実性の担保および双方向の否認防止が可能 (※23c以前から存在)エンドユーザーによるデータへのデジタル署名 Copyright © 2023, Oracle and/or its affiliates CertID GRTE SOQP OPRT ID User Value 1 Tom 500 2 Carol 176 3 Wang 500 TRADE LEDGER Signature RT#E GI(! HV*P 行内容 ハッシュ 署名& 証明書ID 行内容 ハッシュ ①書き込み ②署名 ③副署 受領証 50
  45. より柔軟で使いやすくなったBlockchain Table上のデータへのデジタル署名: • INSERT実行ユーザーではない代理ユーザーによる委任署名(Delegate Signature)が可能に • ユーザーカラム指定(例:主キーに指定したID系の列)での署名対象行の選択が可能に(以前は隠しカラムの instance_id, chain_id, sequence_idの値を指定)

    使いやすく改善された副署プロセス: • 署名および委任署名を含む行データに対し、テーブルオーナーの秘密鍵により副署を生成 • 副署がリクエスト元に返却されるとともに、メタデータとしてテーブルの隠しカラムに格納されるように 署名プロセスと副署プロセスの改善 Copyright © 2023, Oracle and/or its affiliates ID User Digest Signature Delegate Signature Counter- signature 1 Alice xxxx Ra1H 2kxS 2 Bob xxxx EKoU 03Ls 3 Charlie xxxx b3Mx Hs2H 93Ks 51
  46. 作成済のBlockchain Tableのカラムの追加と削除(ALTER TABLE ~ ADD | DROP COLUMN)が可能に • 業務要件の変更によりカラムの追加が必要になった、などのケースに対応

    • データにより柔軟性を求められるユースケースでもBlockchain Tableが選択肢に • 既存行のハッシュチェーンの検証のため、既存行のDROPされたカラムのデータは保持される • 既存行のADDされたカラムの値はNULLになる(DEFAULT値は設定できない) カラムの追加/削除に対応 Copyright © 2023, Oracle and/or its affiliates ID Col_1 Col_2 ID Col_1 Col_3 ALTER TABLE … DROP col_2 ADD col_3 … 52
  47. Flashback Data Archiveのログの格納に対応 • Flashback Data Archiveのログの格納先としてBlockchain Tableを指定できるようになった • 変更履歴(UNDO情報)であるFlashback

    Data ArchiveログをBlockchain Tableで行うことで、 通常のテーブル についても変更履歴をセキュアかつ検証可能なかたちで保持できる • テーブル作成時Flashback Data Archiveを有効化する際に、BLOCKCHAINキーワードを追加して指定することで 利用が可能 Copyright © 2023, Oracle and/or its affiliates CREATE TABLE part ( part_id NUMBER CONSTRAINT part_pk PRIMARY KEY, description VARCHAR2(50) ) BLOCKCHAIN FLASHBACK ARCHIVE fba_1; ID User Value 1 Tom 500 2 Carol 176 3 Wang 500 4 Eve 25 TRADE LEDGER Flashback Data Archive ログをBlockchain Tableに保存 過去時点のデータのクエリや テーブル単位のリストアが可能 53
  48. Blockchain Tableの隠しカラム;v2で追加された分 隠しカラム 説明 ORABCTAB_COUNTERSIGNATURE$ テーブルオーナーの秘密鍵を用いて計算される副署のデジタル署名 ORABCTAB_COUNTERSIGNATURE_ALG$ 副署に使用した署名アルゴリズム ORABCTAB_COUNTERSIGNATURE_CERT$ 副署に紐付いた証明書のGUID

    ORABCTAB_COUNTERSIGNATURE_ROW_FOR MAT_FLAG$ 内部的にのみ使用されるカラム ORABCTAB_COUNTERSIGNATURE_ROW_FOR MAT_VERSION$ 内部的にのみ使用されるカラム ORABCTAB_DELEGATE_SIGNATURE$ 代理ユーザーによる委任署名のデジタル署名 ORABCTAB_DELEGATE_SIGNATURE_ALG$ 委任署名に使用した署名アルゴリズム ORABCTAB_DELEGATE_SIGNATURE_CERT$ 委任署名に紐づいた証明書のGUID ORABCTAB_DELEGATE_USER_NUMBER$ 委任署名をした代理ユーザーのユーザーID ORABCTAB_LAST_ROW_VERSION_NUMBER$ NULLでなければ行グループの中で最新のバージョンであることを示す ORABCTAB_PDB_GUID$ 行がINSERTされたもとのPDBのGUID ORABCTAB_ROW_VERSION$ 行グループの中での行バージョン ORABCTAB_TS$ インターバルパーティショニングがテーブルに追加された場合に用いられる仮想列 ORABCTAB_USER_CHAIN_HASH$ User Chain機能が用いられる場合にUser Chainのハッシュ値 Copyright © 2023, Oracle and/or its affiliates 54
  49. C (機密性) A (可用性) I (完全性) 可用性 : 情報資産を必要時に中断することなく、アクセスできる状態を確保すること •

    可用性に対する攻撃 :データの破壊、システム停止、サービス妨害(DoS)攻撃 機密性 : 情報資産を正当な権利を持った人だけ、アクセスできる状態を確保すること • 機密性に対する攻撃:情報漏えい 完全性 : 情報資産が破壊、改ざんから守られ、正確さと完全さを確実にすること • 完全性に対する攻撃:データ改ざん、Webサイト改ざん 情報セキュリティの3要素とその脅威 56 Blockchain Tableにより セキュリティ向上できる範囲 Copyright © 2021, Oracle and/or its affiliates
  50. DB管理者職務分掌 /アクセスパス制限 (Database Vault) 内部犯行や悪意ある操作によるデータ抽出、破壊、改竄から保護 知財・機密情報、個人情報を守るデータベースセキュリティソリューション ユーザー データベース 管理者 イベント

    DF11233 U*1 $5Ha1qui %H1 HSKQ112 A14 FASqw34 £$1 DF@£!1ah HH! データの暗号化 (Transparent Data Encryption) 行列レベルのアクセス制御 (Virtual Private DB, Real Application Security) 不正検知・証跡管理 (Audit Vault and Database Firewall) 通信暗号化 (標準機能) レポート アラート ポリシー 開発 データの伏字化 (Data Masking and Subsetting) 多要素認証 (Identity CS) 改ざん対策 (Blockchain Table) セキュリティアセスメント、監査・ 検知の可視化・自動化 (Data Safe CS) Copyright © 2021, Oracle and/or its affiliates 57
  51. 様々なパターンの不正なデータの書き換えや攻撃への対策となる特徴 Blockchain Tableによるセキュリティ向上 ハッシュチェーンの検証 により 検知可能 脆弱性を利用した ハッカーの攻撃 大規模な データベース改ざん

    デジタル署名付き ダイジェストの生成 で抑止可能 Copyright © 2021, Oracle and/or its affiliates 58 内部/外部からの 不正な書き換え 削除・更新不可で 改ざんを防止
  52. 対策:書き込んで以降データの削除も更新もできないテーブル セキュリティの脅威 • 組織内部の悪意のあるユーザーや外部の攻撃者が、 データベース管理者などの特権ユーザー権限を利用し、 重要なデータを改ざん • 例: 会計データや品質情報データ、個人情報へのアクセスログを 都合よく書き換え、削除

    • 改ざんが発覚しないよう各種の痕跡も隠蔽 • 例:システムのアクセスログを削除 対策 • 特権ユーザー含め誰にもデータの書き換え、削除が不能 • 確実に追記オンリーな信頼できるかたちでデータを保持 パターン1:内部/外部からの不正な書き換え Copyright © 2021, Oracle and/or its affiliates 59 内部/外部からの 不正な書き換え 削除・更新不可で 改ざんを防止
  53. 対策:ハッシュチェーンによる容易かつ確実な検証可能性、監査性 セキュリティの脅威 • 攻撃者がOSやデータベースの脆弱性を利用してデータベースをクラッ キングし、削除/更新防止をすり抜けてデータを改ざん • データベースに攻撃者の侵入を許してしまい、結果、保持している データが改ざんされた可能性がありもはや信用できない 対策 •

    ハッシュチェーンの整合性を検証することで • データの改ざんを検知できる • 改ざんが起きていないことを確認できる パターン2:脆弱性を利用したハッカーの攻撃 Copyright © 2021, Oracle and/or its affiliates 60 脆弱性を利用した ハッカーの攻撃 ハッシュチェーンの検証 により検知可能
  54. 対策:データの署名付きダイジェストを生成し外部に保管することで真正性を担保 ケース3:大規模なデータベース改ざん Copyright © 2021, Oracle and/or its affiliates 61

    セキュリティの脅威 • 権威者の命令による組織ぐるみの内部不正、あるいは高度に洗練 された組織的外部攻撃による大掛かりなオペレーションで、ハッシュ チェーンの整合性を保ったままデータを改ざん • 例:データベースを丸ごと作り変え • 複数のデータベースを保持し、監査には都合の良いものを提出(二 重帳簿、データベースの真正性についての不正) 対策 • 定期的にテーブルのデータダイジェストを生成し、デジタル署名を 付与したうえで外部に配布(監査機関に送付、パブリックブロック チェーンに記録) • ダイジェストとテーブルを比較することで真正性を確認 大規模な データベース改ざん デジタル署名付き ダイジェストの生成 で抑止可能
  55. 通常のテーブルと異なる点及び通常のテーブルと同様な点を体験 Oracle Blockchain Tableの基本機能(変更/削 除不可、隠しカラム、ハッシュ値の生成、通常の SQL操作)を確認 • ユーザー情報、操作情報(マスター情報)を通常の テーブルで作成 •

    書き換え、削除のできないログテーブルをBlockchain Tableを使って作成 • UPDATE, DELETE, TRUNCATE, DROP不可確認 • 通常のテーブルとBlockchain Tableの同一トランザク ション(COMMIT, ROLLBACK)の確認 • ログテーブル、ユーザーテーブル、操作テーブルを結合 し、監査ログViewを作成 スキーマ図 サンプルSQLスクリプト: Blockchain Tableの基本 Copyright © 2021, Oracle and/or its affiliates 63 LOGS (Blockchain Table) USERS (Table) OPERATIONS (Table) AUDIT_LOGS (View) システムの操作ログを記録 Blockchain Tableで作 成 操作内容が記録される 操作マスターテーブル ユーザー情報が記録される ユーザーマスターテーブル LOGS、OPERATIONS、 USERS 3表をJOINした 監査ログVIEW
  56. Copyright © 2021, Oracle and/or its affiliates 64 -- exhibition

    スキーマ -- システムの操作内容が記録される通常のテーブルを作成(操作マスター) CREATE TABLE operations ( operation_id number(10) PRIMARY KEY, operation_name varchar2(50) NOT NULL UNIQUE ); -- ユーザーの情報が記録される通常のテーブルを作成(ユーザーマスター) CREATE TABLE users ( user_id number(10) PRIMARY KEY, user_name varchar2(30) NOT NULL UNIQUE, last_name varchar2(30) NOT NULL, first_name varchar2(30) NOT NULL, mail varchar2(60) NOT NULL ); -- システムのログを記録するBlockchain Tableを作成 CREATE BLOCKCHAIN TABLE logs ( log_id number(30) PRIMARY KEY, user_id number(10) NOT NULL, operation_id number(10) NOT NULL, error number(10), ip_address varchar2(20), log_stamp timestamp DEFAULT systimestamp NOT NULL, CONSTRAINT user_id_fk FOREIGN KEY(user_id) REFERENCES users(user_id), -- ユーザーIDに対して外部キーを指定 CONSTRAINT operation_id_fk FOREIGN KEY(operation_id) REFERENCES operations(operation_id) -- 操作IDに対して外部キーを指定 ) NO DROP NO DELETE UNTIL 365 DAYS AFTER INSERT HASHING USING "SHA2_512" VERSION "v1" ; -- 隠しカラムの表示をONにしてからLOGSテーブル定義を表示→Blockchain Table特有の隠しカラムが自動的に作成されている SET COLINVISIBLE ON; DESC logs; -- OPERATIONSテーブルに操作情報をINSERT INSERT INTO operations VALUES (1, 'login'); INSERT INTO operations VALUES (2, 'logout'); INSERT INTO operations VALUES (3, 'add_user'); INSERT INTO operations VALUES (4, 'delete_user'); INSERT INTO operations VALUES (5, 'insert_data'); -- USERSテーブルにユーザー情報をINSERT INSERT INTO users VALUES (1, 'tanaka01', 'tanaka', 'tarou', '[email protected]'); INSERT INTO users VALUES (2, 'hanako02', 'yamada', 'hanako', '[email protected]'); INSERT INTO users VALUES (3, 'hiroshi03', 'suzuki', 'hiroshi', '[email protected]'); -- 通常テーブルへのINSERTを確定 COMMIT; -- 通常テーブルのINSERT確認 SELECT * FROM operations; SELECT * FROM users; -- LOGSテーブルにログ情報をINSERT INSERT INTO logs VALUES (1, 1, 1, 0, '192.168.1.1', systimestamp); INSERT INTO logs VALUES (2, 2, 1, 0, '192.168.1.2', systimestamp); INSERT INTO logs VALUES (3, 2, 5, 0, '192.168.1.2', systimestamp); -- (隠しカラム含め)LOGSテーブルをSELECTしてみる→ハッシュ値などの隠しカラムはまだ入っていない SELECT log_id, user_id, operation_id, log_stamp, ORABCTAB_INST_ID$ "inst", ORABCTAB_CHAIN_ID$ "chain", ORABCTAB_SEQ_NUM$ "seq", ORABCTAB_CREATION_TIME$ "time", ORABCTAB_USER_NUMBER$ "user", ORABCTAB_HASH$ "hash" FROM logs; -- Blockchain Tableへのinsertを確定 COMMIT; -- (隠しカラム含め)LOGSテーブルをSELECTしてみる→ハッシュ値などの隠しカラムが自動的に埋められている SELECT log_id, user_id, operation_id, log_stamp, ORABCTAB_INST_ID$ "inst", ORABCTAB_CHAIN_ID$ "chain", ORABCTAB_SEQ_NUM$ "seq", ORABCTAB_CREATION_TIME$ "time", ORABCTAB_USER_NUMBER$ "user", ORABCTAB_HASH$ "hash" FROM logs; -- LOGSテーブルに対してUPDATEを試す UPDATE logs SET user_id = 2 WHERE log_id = 1; -- LOGSテーブルに対してDELETEを試す DELETE FROM logs WHERE user_id = 1; -- LOGSテーブルに対してTRUNCATE(テーブル上のデータ全削除)を試す TRUNCATE TABLE logs; -- LOGSテーブルに対してDROP(テーブルごと削除)を試す DROP TABLE logs CASCADE CONSTRAINTS; -- OUTPUTをON SET SERVEROUTPUT ON; -- LOGSテーブルの行の整合性を検証 DECLARE verify_rows NUMBER; BEGIN DBMS_BLOCKCHAIN_TABLE.VERIFY_ROWS('exhibition','logs', NULL, NULL, NULL, NULL, verify_rows); DBMS_OUTPUT.PUT_LINE('Number of rows verified = '|| verify_rows); END; / -- USERSテーブルとLOGSテーブルに対して行を追加INSERT INSERT INTO users VALUES (4, 'kenta04', 'maeda', 'kenta', '[email protected]'); INSERT INTO users VALUES (5, 'haruka05', 'yamamoto', 'haruka', '[email protected]'); INSERT INTO logs VALUES (4, 1, 3, 0, '192.168.1.1', systimestamp); INSERT INTO logs VALUES (5, 3, 3, 0, '192.168.1.10', systimestamp); INSERT INTO logs VALUES (6, 3, 5, 0, '192.168.1.10', systimestamp); -- 通常テーブルのINSERT確認 SELECT * FROM users; -- (隠しカラム含め)LOGSテーブルをSELECTしてみる→ハッシュ値などの隠しカラムはまだ入っていない SELECT log_id, user_id, operation_id, log_stamp, ORABCTAB_INST_ID$ "inst", ORABCTAB_CHAIN_ID$ "chain", ORABCTAB_SEQ_NUM$ "seq", ORABCTAB_CREATION_TIME$ "time", ORABCTAB_USER_NUMBER$ "user", ORABCTAB_HASH$ "hash" FROM logs; -- 通常テーブルとBlockchain TableへのINSERTを取り消し ROLLBACK; -- 通常テーブルのROLLBACK確認 SELECT * FROM users; -- Blockchain TableのROLLBACK確認 SELECT log_id, user_id, operation_id, log_stamp, ORABCTAB_INST_ID$ "inst", ORABCTAB_CHAIN_ID$ "chain", ORABCTAB_SEQ_NUM$ "seq", ORABCTAB_CREATION_TIME$ "time", ORABCTAB_USER_NUMBER$ "user", ORABCTAB_HASH$ "hash" FROM logs; -- 再度USERSテーブルとLOGSテーブルに対して行を追加INSERT INSERT INTO users VALUES (4, 'kenta04', 'maeda', 'kenta', '[email protected]'); INSERT INTO users VALUES (5, 'haruka05', 'yamamoto', 'haruka', '[email protected]'); INSERT INTO logs VALUES (4, 1, 3, 0, '192.168.1.1', systimestamp); INSERT INTO logs VALUES (5, 3, 3, 0, '192.168.1.10', systimestamp); INSERT INTO logs VALUES (6, 3, 5, 0, '192.168.1.10', systimestamp); -- 通常テーブルのINSERT確認 SELECT * FROM users; -- (隠しカラム含め)LOGSテーブルをSELECTしてみる→ハッシュ値などの隠しカラムはまだ入っていない SELECT log_id, user_id, operation_id, log_stamp, ORABCTAB_INST_ID$ "inst", ORABCTAB_CHAIN_ID$ "chain", ORABCTAB_SEQ_NUM$ "seq", ORABCTAB_CREATION_TIME$ "time", ORABCTAB_USER_NUMBER$ "user", ORABCTAB_HASH$ "hash" FROM logs; -- 通常テーブルとBlockchain TableへのINSERTを確定 COMMIT; -- (隠しカラム含め)LOGSテーブルをSELECTしてみる→ハッシュ値などの隠しカラムが自動的に埋められている SELECT log_id, user_id, operation_id, log_stamp, ORABCTAB_INST_ID$ "inst", ORABCTAB_CHAIN_ID$ "chain", ORABCTAB_SEQ_NUM$ "seq", ORABCTAB_CREATION_TIME$ "time", ORABCTAB_USER_NUMBER$ "user", ORABCTAB_HASH$ "hash" FROM logs; -- ログのユーザー情報と操作内容を表示する監査ログのVIEWを作成…通常のテーブルとBlockchain TableをJOINしたVIEWの利用が可能 CREATE VIEW audit_logs AS SELECT l.log_id "ID", o.operation_name "operation", l.ip_address "ip_address", l.log_stamp "time", u.first_name || '.' || u.last_name "name", l.ORABCTAB_HASH$ as hash FROM logs l, users u, operations o WHERE l.user_id = u.user_id and l.operation_id = o.operation_id ORDER BY log_stamp WITH READ ONLY ; -- 作成したVIEWで監査ログを確認 SELECT * FROM audit_logs; SQLスクリプト ~コピペしてご利用ください~
  57. Blockchain Tableと通常のテーブルでの基本的な操作の比較で耐改ざん性を体験 このシナリオでは… • 通常のテーブルとBlockchain Tableを作成し、品質情報に見立てたデータを格納する • 両者に対してデータのUPDATE/更新(→改ざん)、DELETE/削除(→隠蔽)の操作結果を比較する • Blockchain

    Table独特の隠しカラムに自動的に保存されるデータの有用性を理解する サンプルSQLスクリプト:Blockchain tableへの品質情報の保存 Copyright © 2021, Oracle and/or its affiliates 65 QUALITY 製品の品質検査の 結果データを保存する 通常のテーブル QUALITY_BCT 製品の品質検査の 結果データを保存する Blockchain Table ・UPDATE ・DELETE ・UPDATE ・DELETE
  58. Copyright © 2021, Oracle and/or its affiliates 66 -- ※※※まずは通常のテーブルを作成し操作を実験※※※

    -- QUALITYという名前の品質検査結果を記録する通常のテーブルを作成 -- 製品ID、検査結果スコア、検査実施日時 CREATE TABLE quality ( product_id VARCHAR2(256) NOT NULL, test_score NUMBER NOT NULL, inspection_date DATE NOT NULL ); -- QUALITYテーブルに品質検査結果データをINSERT INSERT INTO quality VALUES ('aaa111', 88, TO_DATE('2021/03/02 10:12:34', 'YYYY-MM-DD HH24:MI:SS')); INSERT INTO quality VALUES ('bbb222', 89, TO_DATE('2021/03/02 11:11:22', 'YYYY-MM-DD HH24:MI:SS')); INSERT INTO quality VALUES ('ccc333', 64, TO_DATE('2021/03/02 12:18:44', 'YYYY-MM-DD HH24:MI:SS')); INSERT INTO quality VALUES ('ddd444', 92, TO_DATE('2021/03/02 13:13:21', 'YYYY-MM-DD HH24:MI:SS')); INSERT INTO quality VALUES ('fff666', 89, TO_DATE('2021/03/02 14:22:04', 'YYYY-MM-DD HH24:MI:SS')); INSERT INTO quality VALUES ('ggg777', 93, TO_DATE('2021/03/02 15:23:12', 'YYYY-MM-DD HH24:MI:SS')); INSERT INTO quality VALUES ('hhh888', 94, TO_DATE('2021/03/02 16:12:58', 'YYYY-MM-DD HH24:MI:SS')); INSERT INTO quality VALUES ('iii999', 90, TO_DATE('2021/03/02 17:18:07', 'YYYY-MM-DD HH24:MI:SS')); -- QUALITYテーブルの品質検査結果データを全件表示 SELECT * FROM quality ORDER BY product_id; -- 検査結果スコアが89点(ギリギリ不合格)のものを90点(ギリギリ合格)に更新…品質情報の改ざん -- 成功する UPDATE quality SET test_score = 90 WHERE test_score = '89'; -- 検査結果スコアが一定以上低かった不良品のデータを削除…隠ぺい -- 成功する DELETE FROM quality WHERE test_score < 70; -- 検査漏れしていた製品の結果を過去日時で新規登録…ねつ造 -- 成功する INSERT INTO quality VALUES ('eee555', 90, TO_DATE('2021/03/02 14:00:45', 'YYYY-MM-DD HH24:MI:SS')); -- QUALITYテーブルの品質検査結果データを全件表示 SELECT * FROM quality ORDER BY product_id; -- ※※※次にBlockchain Tableを作成し操作を実験※※※ -- QUALITY_BCTという名前の品質検査結果を記録するBlockchain Tableを作成 CREATE BLOCKCHAIN TABLE quality_bct ( product_id VARCHAR2(256) NOT NULL, test_score NUMBER NOT NULL, inspection_date DATE NOT NULL ) NO DROP UNTIL 0 DAYS IDLE NO DELETE HASHING USING "SHA2_512" VERSION "v1" ; -- QUALITY_BCTテーブルに品質検査結果データをINSERT INSERT INTO quality_bct VALUES ('aaa111', 88, TO_DATE('2021/03/02 10:12:34', 'YYYY-MM-DD HH24:MI:SS')); INSERT INTO quality_bct VALUES ('bbb222', 89, TO_DATE('2021/03/02 11:11:22', 'YYYY-MM-DD HH24:MI:SS')); INSERT INTO quality_bct VALUES ('ccc333', 64, TO_DATE('2021/03/02 12:18:44', 'YYYY-MM-DD HH24:MI:SS')); INSERT INTO quality_bct VALUES ('ddd444', 92, TO_DATE('2021/03/02 13:13:21', 'YYYY-MM-DD HH24:MI:SS')); INSERT INTO quality_bct VALUES ('fff666', 89, TO_DATE('2021/03/02 14:22:04', 'YYYY-MM-DD HH24:MI:SS')); INSERT INTO quality_bct VALUES ('ggg777', 93, TO_DATE('2021/03/02 15:23:12', 'YYYY-MM-DD HH24:MI:SS')); INSERT INTO quality_bct VALUES ('hhh888', 94, TO_DATE('2021/03/02 16:12:58', 'YYYY-MM-DD HH24:MI:SS')); INSERT INTO quality_bct VALUES ('iii999', 90, TO_DATE('2021/03/02 17:18:07', 'YYYY-MM-DD HH24:MI:SS')); -- QUALITY_BCTテーブルの品質検査結果データを全件表示 SELECT * FROM quality_bct ORDER BY product_id; -- 検査結果スコアが89点(ギリギリ不合格)のものを90点(ギリギリ合格)に更新…品質情報の改ざん -- 失敗する(Blockchain Tableの制約) UPDATE quality_bct SET test_score = 90 WHERE test_score = '89'; -- 検査結果スコアが一定以上低かった不良品のデータを削除…隠ぺい -- 失敗する(Blockchain Tableの制約) DELETE FROM quality_bct WHERE test_score < 70; -- 検査漏れしていた製品の結果を過去日時で新規登録…ねつ造 -- 成功する…ただし隠しカラムに自動で記録されるタイムスタンプと齟齬が出るため識別可能 INSERT INTO quality_bct VALUES ('eee555', 90, TO_DATE('2021/03/02 14:00:45', 'YYYY-MM-DD HH24:MI:SS')); -- 一部の隠しカラム含めBlockchain Tableのデータを表示 -- Blockchain Tableでは、自動的にINSERT時のタイムスタンプが登録されている SELECT product_id, test_score, inspection_date, ORABCTAB_CREATION_TIME$ "bc_date", ORABCTAB_HASH$ "hash" FROM quality_bct ORDER BY product_id; -- ※※※Blockchain Tableのその他の操作※※※ -- 隠しカラムの表示をONにしてからテーブル定義を表示 SET COLINVISIBLE ON; DESC quality_bct; -- Blockchain Tableの行の整合性を検証 DECLARE verified_rows NUMBER; BEGIN DBMS_BLOCKCHAIN_TABLE.VERIFY_ROWS('admin','quality_bct', NULL, NULL, NULL, NULL, verified_rows); DBMS_OUTPUT.PUT_LINE('Number of rows verified = '|| verified_rows); END; -- Blockchain Tableに対してTRUNCATE(テーブル上のデータ全削除)を試す -- テーブル作成時にNO DELETEを指定している場合は常に失敗する TRUNCATE TABLE quality_bct; -- Blockchain Tableに対してDROP(テーブルごと削除)を試す -- テーブル作成時のNO DROP UNTIL n DAYS IDLEの指定およびテーブル上の最新データの経過日数次第で可不可が分かれる -- NO DROP UNTIL 0 DAYS IDLEで作成している場合は常に成功する DROP TABLE quality_bct; サンプルSQLスクリプト ~コピペしてご利用ください~