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

改ざん対策型データベース概要とOracle Database Blockchain Tableご紹介 / Anti-tamper databases 101 and Oracle Database Blockchain Table

gakumura
March 22, 2024

改ざん対策型データベース概要とOracle Database Blockchain Tableご紹介 / Anti-tamper databases 101 and Oracle Database Blockchain Table

2024/3/21 Blockchain GIG #17で話した内容
改ざん対策型データベースとはどのような特性が備わっているものなのか、どのような背景で登場してきたものなのか、どのようなユースケースで活用できるのか、活用によるメリットは、カテゴリに含まれる主要な製品ラインナップは、などの概要をご紹介
併せて、主要なラインナップのひとつであるOracle DatabaseのBlockchain Table機能について、構造上の特徴や利用方法などをご説明

gakumura

March 22, 2024
Tweet

More Decks by gakumura

Other Decks in Technology

Transcript

  1. 改ざん対策型データベース概要と Oracle Database Blockchain Tableご紹介 Blockchain GIG #17 中村 岳

    日本オラクル株式会社 クラウド事業統括/クラウド・エンジニアリング統括/CoE本部/ソリューションアーキテクト部 2024/3/21
  2. Copyright © 2023, Oracle and/or its affiliates 2 中村 岳

    Twitter @gakumura はてなブログ @gakumura …主にHyperledger Fabric関連 • 現職:ソリューションエンジニア@日本オラクル • 担当:Oracle Blockchain Platform、 Blockchain Table • 前職:金融決済系SIerでパッケージ開発 • SWIFT、CLS、日銀ネット関連の銀行間決済システム
  3. 仮想通貨の基盤として始まり、適用領域を拡大 Copyright © 2024 Oracle and/or its affiliates • 2008年にサトシ・ナカモトを名乗る人物が特定の管理者がいないネットワーク上に分

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

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

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

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

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

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

    検証可能であることにより改ざんされていないことの監査も容易に • 中央集権型(NOT分散/分権) • 複数組織で所有や管理を分散できるようにはなっていない • (「分散データベース」は複数組織で分散できるわけではない) 改ざん対策型データベースとは? 12 12 Copyright © 2024 Oracle and/or its affiliates
  10. 改ざん対策型データベースのラインナップ比較 Amazon QLDB (Quantum Ledger Database) SQL Server Ledger Oracle

    Database Blockchain Table 機能の形態 独立した専用DB 汎用的なDBに含まれる機能 テーブル単位で耐改ざん特性を 指定可 汎用的なDBに含まれる機能 テーブル単位で耐改ざん特性を 指定可 データベース形式 ドキュメントDB(JSON) リレーショナルDB リレーショナルDB 操作言語 独自クエリ言語(PartiQL) SQL(Transact-SQL) SQL(PL/SQL) イミュータブルな 箇所 ジャーナル部分 (トランザクションログ) Updatableの場合: 変更履歴(History Table) Append-onlyの場合: テーブル自体 テーブル自体 改ざん検証を 可能にする 仕組み ジャーナル部分が ブロックチェーン構造 トランザクションのメタデータの マークルルートハッシュ値を ブロックチェーン構造で保持 テーブル上の行が ハッシュチェーンを保持 利用方法 AWS上でのみ利用可能 Azureやサードパーティクラウド上、 およびオンプレミスのSQL Server (2022以上)で利用可 OCIやサードパーティクラウド上、 およびオンプレミスのOracle (19cR11、21c以降)で利用可 Copyright © 2024 Oracle and/or its affiliates 14
  11. データ構造としての「ブロックチェーン」とは 耐改ざん性を実現する仕組み Copyright © 2024 Oracle and/or its affiliates 15

    トランザクション A→B 100 前回のハッシュ値 BLOCK A トランザクション C→B 200 Timestamp ナンス トランザクション C→B 20 前回のハッシュ値 BLOCK B トランザクション C→X 100 Timestamp ナンス トランザクション D→B 80 前回のハッシュ値 BLOCK C トランザクション F→B 50 Timestamp ナンス 前のブロックから計算されたハッシュ値を 次のブロックの中に埋め込んでつなぐ ハッシュ:一定のデータを特定の値に変換 ・少しでもデータが異なると全く異なる値 ・ハッシュから元の値を推定できない ・ハッシュ値は一定の値(256桁など) ex) 0000XXCFY456CY64KLL… BLOCK A BLOCK B BLOCK C BLOCK B’ BLOCK D BLOCK Bを改ざん 一部のトランザクションやブロックを改ざんしたり削除したりすると、 ハッシュ値のリンク(ハッシュチェーン)が崩れる →ハッシュチェーンを検証することで改ざんがないことを確認可能
  12. Amazon QLDB(Quantum Ledger Database)の概要 Copyright © 2024 Oracle and/or its

    affiliates 17 https://aws.amazon.com/jp/qldb/ Amazon QLDB はフルマネージド型の台帳データベースで、信頼され た中央機関が所有する、透過的でイミュータブルであり、暗号的に検 証可能なトランザクションログを備えています。 Amazon QLDB を使用すると、アプリケーションデータの全変更を追 跡し、完全で検証可能な変更履歴を長期間維持することができます。
  13. QLDBのデータ構造 Copyright © 2024 Oracle and/or its affiliates 18 ジャーナルセントリックなDB

    • ドキュメントDBであるStateは値の最新の状態を保持しており 更新、削除可能 • 過去バージョンの値(History)もIndexから辿れるよう になっている • JournalはStateの変更ログ(トランザクションログ)で、 これがブロックチェーン構造を取っている • ブロックごとにハッシュリンクが貼ってありイミュータブル • Stateが更新されたこと、削除されたことがJournalに必ず 記録されており、APIから検証可能
  14. 耐改ざん性を追加、監査性を強化した特別なデータベース・テーブル データベース上のレコードに耐改ざん性と監査性を付与 • 追記オンリーの不変なデータ…テーブル所有者も特権ユーザも改ざん不能 • ハッシュチェーンで行をリンク…整合性の検証、改ざんされていないことの証明が可能 Oracle Databaseの一部として高度で多彩な機能とともに容易に利用可能 • 他のテーブルと組み合わせたトランザクション

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

    耐改ざん性のために紙原本や別媒体での記録 →記録、保管に余分なコスト Blockchain Tableに保存し、 データ活用の利便性と耐改ざん性を両立 Blockchain Tableで完結した検証可能性により 監査、証明が容易 21 21 Copyright © 2024 Oracle and/or its affiliates
  16. 追記オンリーのテーブルで、イミュータブル/不変なデータを保持 • 行の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の特性①:データの削除、変更を制約 22 22 Copyright © 2024 Oracle and/or its affiliates
  17. CREATE BLOCKCHAIN TABLE + 3つの必須句 Blockchain Tableの作成 Copyright © 2024

    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を増やすことも不能。 利用するハッシュアルゴリズムとデータフォーマットを記述する句。現状、値は固定。 23
  18. シンプルなCREATE BLOCKCHAIN TABLEの例 Copyright © 2024 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できない 24
  19. ハッシュ値によるデータの検証可能性により、テーブルの中で完結した監査性を提供 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 25 25 Copyright © 2024 Oracle and/or its affiliates
  20. Copyright © 2024 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の隠しカラム 作成時刻や行ハッシュ値などのデータを格納 26
  21. Copyright © 2024 Oracle and/or its affiliates -- Movie_adminによるCustsalesテーブルの行の検証 CONNECT

    movie_admin/*********** BEGIN dbms_blockchain_table.verify_rows('MOVIE_ADMIN', 'CUSTSALES', NULL, NULL, NULL, NULL, :rows_count); dbms_output.put_line('CUSTSALES: rows_verified = ' || :rows_count); END; / CUSTSALES: rows_verified = 10000 PL/SQL procedure successfully completed. Blockchain Table:行の検証
  22. SELECT actual_price FROM custsales WHERE order_id='00123’; ACTUAL_PRICE ------------ 5 --

    ハッカーが行データを改ざん(ここでは具体的なステップは伏せる) SELECT actual_price FROM custsales WHERE order_id='00123’; ACTUAL_PRICE ------------ 0.1 Blockchain Table:ハッカーがデータを改ざんした場合 Copyright © 2024 Oracle and/or its affiliates
  23. -- 再度Movie_adminによるCustsalesテーブルの行の検証 BEGIN dbms_blockchain_table.verify_rows('MOVIE_ADMIN', 'CUSTSALES', NULL, NULL, NULL, NULL, :rows_count);

    dbms_output.put_line('CUSTSALES: rows_verified = ' || :rows_count); END; / ERROR at line 1: ORA-05737: rows verification failed at instance ID '1', chain ID '29', sequence number '1’ Blockchain Table:改ざんされた行に対して検証を行う Copyright © 2024 Oracle and/or its affiliates 改ざんされた行が含まれていた場合、エラーが発生
  24. -- 再度Movie_adminによるCustsalesテーブルの行の検証 BEGIN dbms_blockchain_table.verify_rows('MOVIE_ADMIN', 'CUSTSALES', NULL, NULL, NULL, NULL, :rows_count);

    dbms_output.put_line('CUSTSALES: rows_verified = ' || :rows_count); END; / ERROR at line 1: ORA-05737: rows verification failed at instance ID '1', chain ID '29', sequence number '1’ SELECT order_id, actual_price FROM custsales WHERE ORABCTAB_INST_ID$=1 AND ORABCTAB_CHAIN_ID$=29 AND ORABCTAB_SEQ_NUM$=1; ORDER_ID ACTUAL_PRICE ------------ --------- 00123 0.1 Blockchain Table:改ざんされたデータの特定 Copyright © 2024 Oracle and/or its affiliates
  25. ハッシュチェーンはOracle Databaseに依存しないかたちで、 独立して検証可能 • Blockchain Tableは確立されたハッシュアルゴリズムと プラットフォームに依存しない行データの表現を利用しハッシュ値 を計算 • 行の元のデータ内容と計算されたハッシュ値に対し、オープンソー

    スのライブラリを用いるなどして、自身で記述したプログラムでも検 証が可能 データ検証の透明性 DBMS_BLOCKCHAIN_TABLE.VERIFY_ROWS() TITLE Aliens Top Gun Argo Fear ID DAY CUST_ID 1 500 2 176 3 500 4 31-Dec 25 CUSTSALES CRYPTODIGEST ADSJS %10S SH31 LRO$ 1-Feb 8-Mar 3-Jan Copyright © 2024 Oracle and/or its affiliates 32
  26. /* https://github.com/oracle-samples/blockchain-table-samples */ verifyRow() { /* Get Bytes to construct

    the Hash */ /* Format to construct the stream of bytes is given here */ getBytesForRowHash(); /* Calculate Hash over the bytes */ hashSHA512(); /* Get the expected Hash from the database */ getExpectedHash(); /* If Hash matches verification is successful else there is a failure */ // Publish Data according to the mode specified to a local file or OBP. if(expected_hash != calculated_hash){ /* Log to the console that the hash verification failed */ if(COPY_BYTESFILE_FOR_FAILED) { /* Copy the stream of bytes that failed verification to a local file for the user to inspect */ } } publishResults() { if(mode == CONTINUOUS_LOCAL){ /* Write to the results to the log file and update metadata in the JSON file */ publishLocal(); } else if(mode == CONTINOUS_OBP) { /* Make a REST call to the OBP Platform URL and invoke the chaincode to insert a new record, also update the metadata JSONArray. */ publishOBP(); } } } /* End of a verification cycle – console log stats about how many rows were verified in this round */ } 外部プログラムによるBlockchain Tableの検証の擬似的なコード例 Copyright © 2024 Oracle and/or its affiliates
  27. Oracle Database 23cで導入されたBlockchain Table関連の機能強化 機能強化 説明 詳細 行バージョンおよび最新バージョンビュー機能の追加 行バージョンの自動採番機能、および最新バージョン行を抽出する ビューの自動作成機能が追加された。

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

    それらの値が同一な行を行グループとして管理 • 例:同一のBANKおよびACCOUNT_NOの値を持つ行を 行グループに指定 • INSERT時、自動で行グループ内のバージョン番号が採番され、 隠しカラム(ORABCTAB_ROW_VERSION$)に格納 • さらに、それぞれの行グループから最新のバージョンの行を抽出するビュー (例:BANK_LEDGER_LAST$)を自動的に生成 ※ROW VERSION対象のカラムの型はNUMBER、CHAR、VARCHAR2、RAWに限定 行バージョンおよび最新バージョンビュー機能の追加 Copyright © 2024 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 38
  29. 作成済のBlockchain Tableのカラムの追加と削除(ALTER TABLE ~ ADD | DROP COLUMN)が可能に • 業務要件の変更によりカラムの追加が必要になった、などのケースに対応

    • データにより柔軟性を求められるユースケースでもBlockchain Tableが選択肢に • 既存行のハッシュチェーンの検証のため、既存行のDROPされたカラムのデータは保持される • 既存行のADDされたカラムの値はNULLになる(DEFAULT値は設定できない) カラムの追加/削除に対応 Copyright © 2024 Oracle and/or its affiliates ID Col_1 Col_2 ID Col_1 Col_3 ALTER TABLE … DROP col_2 ADD col_3 … 39
  30. 開発と分析に最高の生産性を 統合された マイクロサービス、イベント、REST, SaaS, 機械学習, CI/CD, ローコード あらゆるワークロードをサポート トランザクション, 分析,

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

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

    (又はブロックチェーン/DLT) 通常データ用 DB トランザクション トランザクション 複製 複製 分析 分析用 DB 整合性担保は アプリの責任 単一用途データベースの場合 Oracle Databaseの場合 App BI 分析のための データ統合に 余分な手間 トランザクション Oracle Database 分析 DB機能で 整合性担保 同一DB上で 容易に分析 43 単一用途データベースの場合 Oracle Databaseの場合 43 Copyright © 2024 Oracle and/or its affiliates
  33. • すぐに、簡単に使える • 耐改ざん性と監査性の課題をシンプルに、最低限のコストだけで解決 • アプリケーションの改修はゼロ~最小限、学習コストも極小 • ピンポイントソリューション • 他の箇所に影響を与えることなく、データベースの一部分、アプリケーションの一部分のみにセキュリティ

    向上を適用可能 • 参照、分析、データ統合、BIツール等は通常テーブルと同様にそのまま使える • どこでも利用可能 • クラウドでもオンプレミスでも利用可能 • 追加ライセンス不要:データベースのすべてのエディションで利用可能 Blockchain Tableの特長 44 44 Copyright © 2024 Oracle and/or its affiliates
  34. 通常のテーブルと異なる点及び通常のテーブルと同様な点を体験 Oracle Blockchain Tableの基本機能(変更/削 除不可、隠しカラム、ハッシュ値の生成、通常の SQL操作)を確認 • ユーザー情報、操作情報(マスター情報)を通常の テーブルで作成 •

    書き換え、削除のできないログテーブルをBlockchain Tableを使って作成 • UPDATE, DELETE, TRUNCATE, DROP不可確認 • 通常のテーブルとBlockchain Tableの同一トランザク ション(COMMIT, ROLLBACK)の確認 • ログテーブル、ユーザーテーブル、操作テーブルを結合 し、監査ログViewを作成 スキーマ図 サンプルSQLスクリプト: Blockchain Tableの基本 Copyright © 2024 Oracle and/or its affiliates 46 LOGS (Blockchain Table) USERS (Table) OPERATIONS (Table) AUDIT_LOGS (View) システムの操作ログを記録 Blockchain Tableで作 成 操作内容が記録される 操作マスターテーブル ユーザー情報が記録される ユーザーマスターテーブル LOGS、OPERATIONS、 USERS 3表をJOINした 監査ログVIEW
  35. Copyright © 2024 Oracle and/or its affiliates 47 -- 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スクリプト ~コピペしてご利用ください~
  36. Blockchain Tableと通常のテーブルでの基本的な操作の比較で耐改ざん性を体験 このシナリオでは… • 通常のテーブルとBlockchain Tableを作成し、品質情報に見立てたデータを格納する • 両者に対してデータのUPDATE/更新(→改ざん)、DELETE/削除(→隠蔽)の操作結果を比較する • Blockchain

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

    -- 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スクリプト ~コピペしてご利用ください~
  38. 文書ファイルの保存、参照、管理の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 © 2024 Oracle and/or its affiliates APEX 50 50
  39. DOCUMENT_BCT (Blockchain Table) 文書管理サンプルアプリケーションの主な機能 Copyright © 2024 Oracle and/or its

    affiliates 文書ファイルを不変・確実に保管 ADDITIONAL_INFO (通常Table) 文書①:document_id=aaa バージョン1:発行日=2021/7/1, ファイル=XXX バージョン2:発行日=2021/8/1, ファイル=XXX 文書②:document_id=bbb バージョン1:発行日=2021/5/16, ファイル=XXX バージョン2:発行日=2021/6/17, ファイル=XXX バージョン3:発行日=2021/8/2, ファイル=XXX 更新可能な付帯情報 文書①の付帯情報 (文書ステータス、 カテゴリー、 備考) 文書②の付帯情報 ひとつの文書について 複数バージョンを登録、 保持可能 文書管理に 関わる機能 耐改ざん性と 監査性に 関わる機能 • 文書と付帯情報の新規登録 • 文書の新バージョン登録 • 付帯情報の更新 • 文書と付帯情報の検索、閲覧 (文書ファイルのダウンロード) • ブロックチェーンテーブルの行の 整合性確認 • ハッシュ値などの確認 • 文書削除・更新不能確認 51
  40. 文書管理サンプルアプリケーションの利用するテーブルとビュー Copyright © 2024 Oracle and/or its affiliates document_id(ドキュメントID):varchar2 -

    PK revision(バージョン):number - PK document_title(ドキュメント名):varchar2 registerer_name(登録者名):varchar2 publish_date(発行日):date update_type(更新種別):varchar2 document(ドキュメント):BLOB document_filename(ファイル名):varchar2 document_mimetype(ファイル種別):varchar2 document_charset(ファイル文字セット):varchar2 document_register_date(ファイル登録日時):date document_bct(文書ブロックチェーンテーブル) document_id(ドキュメントID):varchar2 - PK category( 文書のカテゴリー):varchar2 status(文書のステータス):varchar2 remarks(備考):varchar2 additional_info(付帯情報) update_type(更新種別):varchar2 - PK description(説明):varchar2 update_type_master(更新種別マスタ) category(文書のカテゴリー):varchar2 - PK description(説明):varchar2 category_master(カテゴリーマスタ) status(文書のステータス):varchar2 - PK description(説明):varchar2 status_master(ステータスマスタ) ※文書ブロックチェーンテーブルから各ドキュメントIDについて最新 のバージョンのレコードを抽出し、 付帯情報テーブルとJOIN latest_document_with_additional_info (最新バージョン文書+付加情報のビュー) 52