20210317 Blockchain GIG Exhibition Blockchain Tableセッション資料

Blockchain GIG Exhibition #1
改ざん不能型データベース：
Oracle Blockchain Table
宮崎雄右
日本オラクル株式会社
2021/03/17

私について
Copyright © 2021 Oracle and/or its affiliates
2
宮崎雄右 - Yusuke Miyazaki
Twitter @miyacle0R
ブログ miyacle.com
• 入社：2020年春日本オラクル新卒入社
• 現職：ソリューションエンジニア@日本オラクル
• 担当：Oracle ハードウェア、 Oracle Exadata
• 好きな食べ物：ロースかつ膳

• Oracle Blockchain Tableとは
• ケース別Oracle Blockchain Tableの機能
• Oracle Blockchain Table デモ
目次
3

4
Oracle Blockchain Tableとは

• ブロックチェーン／DLTのPaaS
• いわゆるBlockchain as a Service（BaaS）
• Hyperledger Fabricベース
• 複数組織から成るコンソーシアム型
ネットワーク形態での利用を主に想定
• 分権／分散がメリットとなるような
ユースケースでの活用がターゲット
• Oracle Databaseの新機能として追加された
特殊なテーブル
• 21c、19cバージョンで利用可能（パッチ要
• 標準機能に含まれ、追加ライセンス不要
• 中央集権型：単一組織で運用、管理
• 耐改ざん性、監査性などのニーズに対応
Oracleのブロックチェーン関連ソリューション
5
BLOCKCHAIN
Oracle Blockchain Platform Oracle Blockchain Table

Oracle Blockchain TableはOracle Databaseの1機能として提供されるテーブル
特徴として
• リレーショナルデータベースのテーブル
• データの削除/変更が不可能
• 行をハッシュチェーンでリンク…改ざんの検知が可能
• 通常のテーブルと同様の操作が可能（JOIN、View、Index、 etc.)
書き換え・削除ができない中央集権データベース
Oracle Blockchain Tableとは
6

ブロックチェーン／DLT基盤や専用データベースと比較して……
利用のハードルが低い
• 一般的なOracle Databaseのスキルで十分使いこなせるため、学習コストが低い
• 通常のテーブルとの使い勝手の差異が小さく、アプリケーション透過的な利用が可能
• 通常テーブルからの乗り換えに必要な改修はゼロ～最小限
アプリケーション側の負担が小さい
• ふつうアプリケーションはイミュータブル（変更／削除しない）データのみを扱うわけではない
• イミュータブルデータ専用のデータベースを使う場合、
アプリケーションは少なくともふたつのデータベースを扱わなくてはならない
• 同一DB上で通常のテーブルとBlockchain Tableを扱えるためトランザクション、整合性担保が容易
データ分析、データ統合が容易
• Blockchain Table上でそのまま集計、分析が可能
• 他テーブル上のデータとのJOINやVIEW、多様なデータ統合ツールやBIツールも利用可能
処理性能
• Oracle Databaseの様々な処理性能向上手段を適用可能（例：Exadataを利用）
Oracle Databaseの1テーブルとして使えることのメリット
7

アプリケーションの負担を減らし、分析のための余分な手間も削減
単一用途データベース vs Oracle Database
8
App
BI
DIツール
イミュータブル
データ専用DB
（又はブロックチェーン/DLT）
通常データ用
DB
トランザクション
複製
複製
分析
分析用
DB
整合性担保は
アプリの責任
単一用途データベースの場合 Oracle Databaseの場合
App
BI
分析のための
データ統合に
余分な手間
Oracle
Database
分析
DB機能で
整合性担保
同一DB上で
容易に分析

データの完全性の担保、証明が求められるところ
• セキュリティ上重要な記録の保存：
• アプリケーションのアクセスログや監査ログ
• 高セキュリティエリアへの入退室記録
• 法律上確実な保存が要求される情報：
• 従業員の出退勤記録
• 企業の会計、財務のデータ
• 見積、契約、請求や支払のやり取りに係るドキュメント
• 内外からの攻撃に対してデータを保護：
• 勘定系システム、決済系システムなどのトランザクションログ
• 証券や各種アセットの所有権を管理する原簿
• 種々の認定、証明のエビデンス保存：
• 原産地証明、検査証、品質認証、etc.
Oracle Blockchain Tableのユースケースの一例
9

CREATE BLOCKCHAIN TABLE + 3つの必須句
Oracle Blockchain Tableの作成
10
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を増やすことも不能。
利用するハッシュアルゴリズムとデータフォーマットを記述する句。現状、値は固定。

シンプルなCREATE BLOCKCHAIN TABLEの例
11
CREATE BLOCKCHAIN TABLE logs (log_id NUMBER(30), user_id number(10)
operation_id number(10), error number(10), ip_address varchar2(20),
log_stamp TIMESTAMP)
NO DROP
NO DELETE UNTIL 365 DAYS AFTER INSERT
HASHING USING "SHA2_512" VERSION "v1";
• NO DROP
…表はDROPできない
• NO DELETE UNTIL 365 DAYS AFTER INSERT
…行はINSERT後365日経っていないとDELETEできない

追記オンリーのテーブルで、不変なデータを保持
• テーブルのDROPの制約（前述の通りn日～無制限の保護期間を設定可能）
• テーブルDROPは行のINSERT前なら常に可能（誤ってテーブル作成した場合すぐなら消せる）
• 行のDELETEの制約（前述の通りn日～無制限の保持期間を設定可能）
• データ量を削減したい場合、適切な保持期間を設定しておいたうえで、
保持期間を過ぎた行を整合性を検証した上で（必要に応じて外部にアーカイブしつつ）削除する
• 保持期間を過ぎた行の一括削除用PL/SQLパッケージファンクション
DBMS_BLOCKCHAIN_TABLE.delete_expired_rows()
• 行のUPDATEとMERGEが不可
• テーブルのTRUNCATEが不可
• パーティションのDROPが不可
• カラムの追加、削除および名前変更が不可
• データ型の変更や一部の長さ、精度の変更、NULL制約変更も不可
• Blockchain Tableの通常のテーブルへの変換、およびその逆の変換は不可
データの削除、変更を制約
12
BLOCKCHAIN

13
ケース別Oracle Blockchain Tableの機能

Oracle Blockchain Tableは様々なケースにおける不正や改ざんに対する機能/特徴をもつ
ケース別Oracle Blockchain Tableの機能
ハッシュチェーンの付与
検証可能
外部から攻撃/改ざん大規模なデータ改ざん
デジタル署名付き
ダイジェストの生成
14
内部不正/書き換え
削除・変更不可

対策：削除・変更不可
データの変更/削除ができないテーブル
• データベースの管理者/スキーマの所有者もデータの書き換え、
削除ができない
e.g. ）検品データを都合の良いように変更することを防ぐ
• 不正にデータベースにアクセスされてもデータの書き換え、削除が
できない
e.g. ）不正アクセスされたログの削除、改ざんを防ぐ
ケース１：内部不正/書き換え
15
追記onlyで削除、変更が不可能であるため、改ざんができない
特権を持つユーザーも書き換えが不可能

対策：ハッシュチェーンの付与/検証可能
ハッシュチェーンによる高い監査性
• データベースにクラッキングされ、データの書き換え、改ざんが起きても
ハッシュチェーンの検証が可能
e.g. ）改ざんされたデータをハッシュチェーンの整合性を検証すること
で検知可能
ケース２：外部から攻撃/改ざん
16
検証可能
外部から攻撃/改ざん
ハッシュチェーンの不整合でデータの改ざんが発覚する
検証可能性を担保
ハッシュ検証用PL/SQLパッケージファンクション
DBMS_BLOCKCHAIN_TABLE.verify_rows()

対策：ダイジェストの生成と外部保管/真正性担保
ケース３：大規模なデータ改ざん
17
大規模なデータ改ざん
暗号ダイジェストを生成し外部に保管し、真正性を担保
• 大規模なデータ変更によりハッシュチェーンの整合性を保ったまま
データの改ざん→検知可能
e.g. ）データベース丸ごと作り変え/取り換えを検知
e.g. ）大規模な変更後チェーン丸ごとの書き直しを検知
定期的にダイジェストとテーブルチェーンを検証が可能
ダイジェストを複数に配布、また、Blockchainに書き込み
より真正性を高めることが可能
署名付きダイジェスト生成用ファンクション
DBMS_BLOCKCHAIN_TABLE.GET_SIGNED_BLOCKCHAIN_DIGEST()

18
Oracle Blockchain Table デモ

通常のテーブルと異なる点及び通常のテーブルと同様な点
Oracle Blockchain Tableの基本機能（変更/削
除不可、隠しカラム、ハッシュ値の生成、通常の
SQL操作）を確認
• ユーザー情報、操作情報（マスター情報）を通常の
テーブルで作成
• 書き換え、削除のできないログテーブルをBlockchain
Tableを使って作成
• UPDATE, DELETE, TRUNCATE, DROP不可確認
• 通常のテーブルとBlockchain Tableの同一トランザク
ション（COMMIT, ROLLBACK）の確認
• ログテーブル、ユーザーテーブル、操作テーブルを結合
し、監査ログViewを作成
スキーマ図
デモの内容
19
LOGS (Blockchain Table)
USERS (Table)
OPERATIONS (Table)
AUDIT_LOGS (View)
システムの操作ログを記録
Blockchain Tableで作成
操作内容が記録される
操作マスターテーブル
ユーザー情報が記録される
ユーザーマスターテーブル
LOGS、OPERATIONS、
USERS ３表をJOINした
監査ログVIEW

20
Oracle Blockchain Table まとめ

耐改ざん性を追加、監査性を強化した特別なデータベース・テーブル
データベース上のレコードに耐改ざん性と監査性を付与
• 追記オンリーの不変なデータ…テーブル所有者も特権ユーザも改ざん不能
• ハッシュチェーンで行をリンク…整合性の検証、改ざんされていないことを容易に監査可能
Oracle Databaseの一部として高度で多彩な機能とともに容易に利用可能
• 他のテーブルと組み合わせたトランザクション
• 容易にデータ統合、多様なBIツールを用いての分析
• データベーストリガー、PL/SQLプログラムを利用
• レプリケーション、バックアップなどの耐障害性／高可用性機能、
アクセスコントロールなどのセキュリティ保護機能も併用可能
※19cではRU19.10アップデートおよび個別パッチ32431413を適用することで利用可能に。
データベースの基本機能として含まれており追加ライセンスは不要（SE2でも利用可能）。
Oracle Blockchain Table：Oracle Database 21c&19cで利用可能（※）
21
BLOCKCHAIN

簡単に利用可能
Oracle Blockchain TableはOracle Databaseの機能
22
Oracle Databaseで利用可能
これらの機能が…
大規模なデータ改ざん
外部から攻撃/改ざん

• 【公式ブログ】Blockchain TableによるOracle Databaseのコンバージドデータベースの拡張
…Blockchain Tableの技術的な特長およびユースケースの紹介記事
https://blogs.oracle.com/oracle4engineer/blockchain-table
• 【公式ドキュメント】 Oracle Database 21cドキュメントのBlockchain Tableについての箇所
https://docs.oracle.com/en/database/oracle/oracle-database/21/admin/managing-tables.html#GUID-
43470B0C-DE4A-4640-9278-B066901C3926
• 【ブログ】Oracle CloudでOracle Database 20c(プレビュー)のBlockchain Tableを使ってみた話
…Blockchain Tableを作成し、基本的な操作をテスト
https://miyacle.com/2020/07/oracle-cloud%E3%81%A7oracle-database-
20c%E3%83%97%E3%83%AC%E3%83%93%E3%83%A5%E3%83%BC%E3%81%AEblockchain-
table%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E3%81%BF%E3%81%9F%E8%A9%B1/
• 【ブログ】Oracle CloudのAlways FreeのATPのAPEXを使って作った我が家の体重管理アプリを、Blockchain Tablesで改
ざんできないようにした…Blockchain Tableを作成し、APEXで操作
https://qiita.com/maato/items/4a43841132074aa35d81
• 【ブログ】21cのブロックチェーン表を使ってみる
…Blockchain TableにネイティブJSON型（21cで追加）でデータを保存し、APEXから表示
https://apexugj.blogspot.com/2020/12/blockchain-table-with-json.html
Oracle Blockchain Tableについての参考Webサイト
23

24
Appendix

1.Always Free枠を使う場合
Autonomous Databaseで21cのインスタンスを構築してください
ただし、ホームリージョンはAshburnリージョンでユーザーを登録する必要があります
2.Free Trialクレジット枠（300あるいは500ドル枠）を使う場合
Database Cloud で21c環境を構築してください
リージョン指定はありません
Oracle Cloud Free TierでのおすすめのBlockchain Tableの作成方法
25

26
-- 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', 'tarou@demo.mail');
INSERT INTO users VALUES (2, 'hanako02', 'yamada', 'hanako', 'hanako@demo.mail');
INSERT INTO users VALUES (3, 'hiroshi03', 'suzuki', 'hiroshi', 'hiroshi@demo.mail');
-- 通常テーブルへのINSERTを確定
COMMIT;
-- 通常テーブルのINSERT確認
SELECT * FROM operations;
SELECT * FROM users;
-- LOGSテーブルにログ情報をINSERT
INSERT INTO logs VALUES (1, 1, 1, 0, '192.168.1.1', 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してみる→ハッシュ値などの隠しカラムが自動的に埋められている
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', 'kenta@demo.mail');
INSERT INTO users VALUES (5, 'haruka05', 'yamamoto', 'haruka', 'haruka@demo.mail');
FROM logs;
-- 通常テーブルとBlockchain TableへのINSERTを取り消し
ROLLBACK;
-- 通常テーブルのROLLBACK確認
-- Blockchain TableのROLLBACK確認
FROM logs;
-- 再度USERSテーブルとLOGSテーブルに対して行を追加INSERT
INSERT INTO users VALUES (4, 'kenta04', 'maeda', 'kenta', 'kenta@demo.mail');
INSERT INTO users VALUES (5, 'haruka05', 'yamamoto', 'haruka', 'haruka@demo.mail');
FROM logs;
-- 通常テーブルとBlockchain TableへのINSERTを確定
COMMIT;
-- （隠しカラム含め）LOGSテーブルをSELECTしてみる→ハッシュ値などの隠しカラムが自動的に埋められている
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 Script ～コピペしてご利用ください～

20210317 Blockchain GIG Exhibition Blockchain Tableセッション資料

20210317 Blockchain GIG Exhibition Blockchain Tableセッション資料

More Related Content

More from オラクルエンジニア通信

Recently uploaded

20210317 Blockchain GIG Exhibition Blockchain Tableセッション資料