ネイティブ・ブロックチェーンテーブルがOracle Databaseのマルチモデル・コンバージド・アーキテクチャを拡張 (2020/12/24)
ネイティブ・ブロックチェーンテーブルがOracle Databaseのマルチモデル・コンバージド・アーキテクチャを拡張 (2020/12/24)
https://blogs.oracle.com/blockchain/native-blockchain-tables-extend-oracle-database%e2%80%99s-multi-model-converged-architecture1
投稿者：Mark Rakhmilevich | Senior Director, Blockchain Product Management
彼らはここにいます!
当初はOOW 2019で発表され、私のOOWブログ記事でも説明しましたが、
Oracle Cloud Database Service Virtual Machine（RACとシングルインスタンス用）とBare Metal Service（シングルインスタンス用）で
最新リリースの可用性を発表したIntroducing Oracle Database 21cの記事でも触れたように、ブロックチェーンテーブルが一般的に利用可能になりました。
また、Ashburn（IAD）、Phoenix（PHX）、Frankfurt（FRA）、London（LHR）リージョンのAutonomous Database Free Tier Serviceでも利用できます。
オンプレム・プラットフォーム（Exadata、Linux、Windowsを含む）向けのOracle Database 21cの一般的な利用可能性は2021年に続き、
2021年初頭に19.10 Release Update（RU）が利用可能になると、19cデータベースでもブロックチェーンテーブルが利用できるようになります。
では、ブロックチェーンテーブルとは一体何なのか、なぜ気にする必要があるのでしょうか？
ブロックチェーンテーブルは、Oracle Databaseに高度な耐タンパー性のある永続化オプションを提供する新しい特殊なテーブルタイプです。
これは、更新やその他の変更を許可せず、挿入のみの操作を許可し、削除を制限します。
さらに耐タンパー性を高めるために、前の行のハッシュを現在の行に格納することで行をチェーン化し、ユーザーが変更を確認できるようにしています。
また、ユーザーはX.509認証を利用したPKIベースの署名で行の内容を署名することができ、署名とデータの整合性を検証することができるため、否認されないことが保証されます。
ブロックチェーンテーブルを使用することで、ユーザーは他のユーザーによる不正行為からアプリケーションを透過的に保護することができます。
また、データに署名して検証することで、プロバイダーの不正行為を検知することができます（信頼はするが検証はする）。
新興の非中央集権型アプリケーションはOracle Blockchain Platformの非中央集権型信頼モデルの恩恵を受けていますが、
今日のほとんどのアプリケーションには中央機関（銀行、エスクロー会社、取引所、政府機関など）が存在しています。
これがOracle Databaseネイティブのブロックチェーンテーブルの理由です。
例としては、金融取引ログ、監査証跡、規制遵守データ、SOX-404統制の対象となる金融記録、法的保有データ、中央集権的な保管チェーン、または証明情報などがあります。
ブロックチェーンテーブルを適用することで、これらのアプリケーションの安全性を高め、データの改ざんを防止することができます。
上記で引用した例では、ブロックチェーンテーブルを使用することは、ブロックチェーン・ネットワークや脱中央集権型アプリケーションを実装するよりもはるかに簡単です。
新しいインフラストラクチャは必要ありません - この機能はOracle Databaseの一部として提供されます。
テーブルの使用は既存のアプリケーションに対して透過的に行うことができ、開発者はSQL、PL/SQL、JDBC、その他の方法で
テーブルにアクセスする方法を使用して、現在のアーキテクチャやプログラミングモデルを維持することができます。
また、ブロックチェーンテーブルは、他のテーブルとのトランザクションやクエリに参加することができます。
一般的なデザインパターン
1つ目のパターンは、IoTデバイスからの読み取りデータやコンプライアンスデータなど、チェンジレスなデータを保存する必要があるアプリケーション向けです。
ブロックチェーンテーブルを作成して使用し、このデータを直接保存します。
2つ目のケースは、既存のアプリケーションが通常のデータベースのテーブルに加えられた変更の改ざん防止の監査証跡を必要とする場合です。
追加のブロックチェーンテーブルを追加し、現在のテーブルへの更新ごとにレコードを挿入するようにアプリケーションを更新するか、
現在のテーブルにトリガー付きのストアドプロシージャを作成して、ブロックチェーンテーブルに維持されている監査証跡に更新をキャプチャしてログに記録することができます。
もう一つのシナリオは、分散型ブロックチェーンネットワークを使用した非中央集権型アプリケーションに関するものです。
いくつかのケースでは、これらのアプリケーションは、電子健康記録（EHR）、画像、法的契約書や契約書など、大量のデータを保存する必要があります。
分散ネットワーク内のノードによって交換されるメッセージの数が多いため、MBサイズの文書やGBサイズの画像は、多くの接続をまたいで高いネットワーク負荷を発生させます。
好ましい設計パターンは、これらのレコードを分散台帳上に「アンカー」（メタデータレコードでハッシュ化してオンチェーンで維持する）するが、
実際のソースデータは、例えば耐タンパー性のあるブロックチェーンテーブルを使用してオフチェーンで保存することです。
テーブルの耐タンパー性と、ブロックチェーンネットワーク上でレコードをアンカリングするという追加のセキュリティの組み合わせにより、あらゆるデータの改ざんがさらに困難になります。
さて、「なぜ」を説明したところで、「どのように」という話をしましょう。
ブロックチェーンテーブルの作成と使用
Oracle Database 21cでは、ブロックチェーンテーブル用のDDLを新しく修正したものと、便利な機能を備えた3つのPL/SQLパッケージが提供されています。
このハンズオンをフォローしたい場合は、Oracle Cloud (Database Cloud Service Virtual MachineまたはAlways Free Tierで取得できるAutonomous Database) にアクセスして
インスタンスをスピンアップし、お気に入りのデータベースクライアントでデータベースに接続してください。
新しいDDL
CREATE BLOCKCHAIN TABLEは、ブロックチェーンテーブルを定義し、いくつかのパラメータを設定するための新しいDDLです。 これの例は次のようになります。
CREATE BLOCKCHAIN TABLE bank_ledger (bank varchar2(128), EOD_deposit NUMBER, ...)
\
NO DROP UNTIL 31 DAYS IDLE
\
NO DELETE LOCKED
\
HASHING USING "sha2_512" VERSION "v1“;
このリリースでサポートされているデータ型は、NUMBER、VARCHAR2、RAW、JSON、BLOB、CLOB、DATE形式、およびその他のスカラー型であることに注意してください。
LONG、ADTs、TYPE、varray、OBJECTS、ROWID、BFILE、REF、Collectionsなどの他の型はサポートされていません。
上記の例では、3つの追加の句があることに注意してください。
- NO DROP [UNTIL n DAYS IDLE]は必須の句で、テーブルがドロップされるのを防ぐか、テーブルをドロップする前に非アクティブ保持期間を課します。
nの最小値は0ですが、本番環境では少なくとも16を使用することを推奨します。
これは、テーブルが自然にアイドル状態になる可能性があるほとんどの一般的な休日にまたがる十分に長い期間です。
保持期間を16日よりも長い値に変更するにはALTER TABLE句を使用してください。 - NO DELETE [LOCKED]またはNO DELETE UNTIL n DAYS AFTER INSERT [LOCKED]は削除ポリシーを制御する句です。
行の削除は、真の恒久的な元帳では禁止されるか、またはn日の保持期間の後に許可されます。
NO DELETE (LOCKED付きまたはLOCKEDなし) または NO DELETE UNTIL ... LOCKED が使用されている場合、これらの設定は変更できません。
NO DELETE UNTIL ... が LOCKED なしで指定されている場合、ALTER TABLE を使用して n の現在の値を増加させることができますが、減少させることはできません。 - HASHING USING "SHA2_512" VERSION "v1 "は、行チェーニングのためのハッシュ計算に512ビットの出力長を持つSHA2アルゴリズムを使用することを指定する必須の句でもあります。
この節は、このテーブルのDDLが新しいリリースでレプリケートされたときに、
異なるハッシュアルゴリズムや新しいリリースで使用されるデータフォーマットのバージョンにデフォルトで変更されないことを保証するために、OGGや論理レプリケーションのために将来的に必要になるでしょう。
ALTER TABLE句に関しては、上記のものと制約を追加する際に使用される句を除いて、ほとんどのブロックチェーンテーブルでは使用できません。
ブロックチェーンテーブル制限
ブロックチェーンにおけるデータの不変性の核心原理は、ブロックチェーンテーブルのデータベース実装で使用されています。
ブロックチェーンテーブルを使用する場合、ユーザーはDML、ダイレクトパス挿入（INSERT AS SELECT、SQL Loader）、
Goldengate論理レプリケーションを介して行を更新することはできません。また、ユーザーは以下のことができません。
- 設定された保持期間内またはこれまでに行を削除（テーブルに設定されたパラメータに応じて）列の追加/削除/名前の変更
- パーティションのドロップ
- 行の更新トリガーの前に定義
- ブロックチェーンテーブルを非ブロックチェーンテーブルに変換
これにより、偽造や書き換え履歴など、データベース利用者による基本的な操作や不正行為からブロックチェーンテーブル内のデータを保護することができます。
行の連結と署名
行が挿入される際には、Oracleが管理する隠しカラムを使って特別なチェーン処理が行われ、改ざん防止が保証されます。
これは、ブロックチェーン由来の耐タンパー性とは、前のブロックの暗号ハッシュを現在のデータと一緒に保存する方法のことを指します。
前のデータが改ざんされると、そのハッシュが変更され、現在のデータで保存されているハッシュと一致しなくなります。
Oracleブロックチェーンテーブルでは、新しい行のハッシュは、
1)現在の行のユーザーと隠しカラム（ユーザー署名カラムを除く）の "行の内容 "と
2)前の行の隠しハッシュカラムの組み合わせの上にSHA2-512計算として生成されます。
並列性と各テーブルへの行挿入のパフォーマンスを向上させるために、我々は32チェーン、RAC構成ではRACインスタンスごとに32チェーンを維持しています。
したがって、技術的には「前の」行とは、特定のチェーン上の現在の行よりもシーケンス番号が1小さい行を指します。
SHA2-512 ハッシュ計算は、各列位置のメタデータ・ヘッダとカラム・バイト値を含む連結配列上で行われ、最後の配列エントリとして、
「前の」行の隠しハッシュ列のメタデータとカラム・バイト値が追加されます。
これは、誰かがデータベースの保護機能を迂回して行の内容を変更した場合に、より深いレベルでの改ざんからデータを保護するのに役立ちます。
ハッシュチェーンの整合性は、後述するPL/SQLパッケージの関数を使用して検証することができます。
以下のようにして、管理者レベルの改ざんからブロックチェーンテーブルをさらに保護することができます。
- 暗号化とデータボールトの使用
- 暗号ハッシュをDBAがアクセスできない外部リポジトリに定期的にコピーする。
暗号化ハッシュを介した組み込みの行チェーニングに加えて、以下に説明するPL/SQLパッケージでは、
行が挿入された後に、ユーザがPKI（X.509）証明書を登録し、行の内容にユーザ署名を適用することができます。
署名は、行が挿入され、データベースによってハッシュが追加された後に行われます。
しかし、その前に、署名者の証明書をデータベースに登録する必要があります。 以下に、一連の手順の完全な例を示します。
| -- Add user certificate to database, get as output the Certificate ID dbms_user_certs.add_certificate(buffer, cert_id); -- Insert row in to the blockchain table insert into bank_ledger values ('Chase', 1000); -- Commit the row. This causes the crypto hash to be computed on row & linked to previous row commit; -- Get the bytes to be signed. Returns the output in crypto_hash dbms_blockchain_table.get_bytes_for_row_signature('EXAMPLE', 'BANK_LEDGER', 'instance_id', 'chain_id', 'sequence_id', 1, row_hash); -- Application signs the bytes using some trusted library like openssl openssl dgst -sha256 –sign … -- Sign the row (and specify the id of the registered public key certificate) dbms_blockchain_table.sign_row(… 'BANK_LEDGER’…, sequence_no, row_hash, signature, cert_id, dbms_blockchain_table.SIGN_ALGO_RSA_SHA2_256); |
これにより、ユーザや管理者が他人になりすましたり、他人になりすましられたと主張したりすることを防ぐために、否認防止機能が有効になります。
もちろん、openssl コマンドで使用される秘密鍵のセキュリティを維持することは、
秘密鍵が漏洩した場合に証明書を失効させたり再発行したりする機能と同様に、これを機能させるためには非常に重要です。
ブロックチェーンテーブル PL/SQL パッケージ
PL/SQLでブロックチェーンテーブルを操作するために、我々は一連の関数を持つ3つのデータベースパッケージを提供しています。
DBMS_BLOCKCHAIN_TABLE (詳細はリファレンスドキュメントを参照)
- delete__expired_rows() - 保持ウィンドウの外の行を削除する (将来のリリースでは delete_expired_rows() に名前を変更する)
- verify_rows() - チェーンの整合性を検証する
- sign_row() - 以前に挿入した行のユーザ署名を保存する
- get_bytes_for_row_hash() - SHA2-512 ハッシュを計算する行の内容データ形式を返す
- get_bytes_for_row_signature() - ユーザがデータベースの外部で自分の秘密鍵を使って署名できる行のハッシュを返す
- get_signed_blockchain_digest() - スキーマ所有者の秘密鍵で署名されたダイジェスト (各チェーンの最後の行に関するメタデータ) を返す
- verify_table_blockchain() - 追加された行の定期的な整合性検証を可能にするために、2 つのブロックチェーンダイジェストの期間の間に作成された行を検証する
DBMS_TABLE_DATA (詳細はリファレンスドキュメントを参照)
- get_bytes_for_column() - 指定したカラムの {column-byte-value} を返す
- get_bytes_for_columns() - 指定したカラムに対する {column-byte-value}* 配列を返す
- get_bytes_for_row() - 行の全列に対する {column-byte-value}* 配列を返す
DBMS_USER_CERTS (詳細はリファレンスドキュメントを参照)
- add_certificate() - 証明書を "sys.user_certs$" ディクショナリテーブルに挿入し、一意の GUID を返す
- drop_certificate() - 指定した証明書が存在する場合、"sys.user_certs$" テーブルから削除する
ビューを使ったブロックチェーンテーブルの管理
ブロックチェーンテーブルとユーザー証明書に関するメタデータ情報のクエリと管理を支援するために、2つのビューセットが事前に定義されています。
- ALL_BLOCKCHAIN_TABLES
- DBA_BLOCKCHAIN_TABLES
- USER_BLOCKCHAIN_TABLES
- CDB_BLOCKCHAIN_TABLES
これらのビューには以下の列が含まれています(名前は簡略化されています。ドキュメントの完全な名前を参照してください)。
SCHEMA_NAME
(USERを除くすべてのビュー)、TABLE_NAME、ROW_RETENTION、ROW_RETENTION_LOCKED、TABLE_INACTIVITY_RETENTION、HASH_ALGORITHM、CON_ID
(CDBビューのみ)
ユーザー証明書については、以下のビューが定義されています。
- DBA_CERTIFICATES
- USER_CERTIFICATES
- CDB_CERTIFICATES
これらのビューには、以下の列が含まれています。
CERTIFICATE_GUID、USER_NAME、DISTINGUISHED_NAME、CERTIFICATE (BLOB)、CON_ID (CDBビューのみ)。
行とテーブルの整合性の検証
ブロックチェーンテーブルは、データの不変性を検証する方法と改ざんを検出する方法の2つを提供しています。
まず、DBMS_BLOCKCHAIN_TABLE.VERIFY_ROWSプロシージャを使用して、2つのタイムスタンプ間の行のセットについて、
ハッシュと、引数に指定されている場合はオプションで署名を検証します。
| DECLARE verify_rows NUMBER; instance_id NUMBER; BEGIN FOR instance_id IN 1 .. 4 LOOP DBMS_BLOCKCHAIN_TABLE.VERIFY_ROWS('EXAMPLES','BANK_LEDGER', NULL, NULL, instance_id, NULL, verify_rows); DBMS_OUTPUT.PUT_LINE('Number of rows verified in instance Id '|| instance_id || ' = '|| verify_rows); END LOOP; END; / Number of rows verified in instance Id 1 = 3 Number of rows verified in instance Id 2 = 12 Number of rows verified in instance Id 3 = 8 Number of rows verified in instance Id 4 = 10 PL/SQL procedure successfully completed. |
2番目のプロセスでは、ブロックチェーンテーブルのデータが危殆化していないことを継続的に検証することで、ブロックチェーンテーブルの整合性を維持することができます。
これは、DBMS_BLOCKCHAIN_TABLE.GET_SIGNED_BLOCKCHAIN_DIGESTプロシージャを使用して生成されたブロックチェーンテーブルの符号付きダイジェストを使用します。
これは、データベースのウォレットに保持されているデータベーススキーマ所有者の秘密鍵によって署名された各チェーンの最上位行のみのシステム生成カラムコンテンツを含むBLOBを返します。
署名されたダイジェストは定期的に生成することができ、データベースの外部に公開または保存する必要があります。
その後、DBMS_BLOCKCHAIN_TABLE.VERIFY_TABLE_BLOCKCHAINプロシージャを使用して、
2つのダイジェストに対応する時間（前のダイジェストの最も古い時間から後のダイジェストの最も新しい時間まで）の間のすべての行の整合性を検証します。
ダイジェストを生成する例を以下に示します。
この例では、署名付きダイジェストを計算し、ブロックチェーンexamples.bank_ledgerの署名を生成します。
符号付きダイジェストはバイナリ形式で、各チェーンの最後の行のメタデータとデータで構成されています。
signed_bytesに格納されています。符号付きダイジェストの PL/SQL 配列バージョンは、出力パラメータ signed_row_array に格納されます。
署名の生成に使用された証明書の GUID は、certificate_guid に格納されます。
DBMS_USER_CERTS.ADD_CERTIFICATE プロシージャを使用して、最初に証明書をデータベースに格納する必要があることに注意してください。
| DECLARE signed_bytes BLOB:=EMPTY_BLOB(); signed_row_array SYS.ORABCTAB_ROW_ARRAY_T; certificate_guid RAW(2000); signature RAW(2000); BEGIN signature := DBMS_BLOCKCHAIN_TABLE.GET_SIGNED_BLOCKCHAIN_DIGEST('EXAMPLES', 'BANK_LEDGER', signed_bytes, signed_row_array, certificate_guid, dbms_blockchain_table.SIGN_ALGO_RSA_SHA2_512); DBMS_OUTPUT.PUT_LINE('Certificate GUID = ' || certificate_guid); DBMS_OUTPUT.PUT_LINE('Signature length = ' || UTL_RAW.LENGTH(signature)); DBMS_OUTPUT.PUT_LINE('Number of chains = ' || signed_row_array.count); DBMS_OUTPUT.PUT_LINE('Signature content buffer length = ' || DBMS_LOB.GETLENGTH(signed_bytes)); END; / Certificate GUID = AF27H7FE3EEA473GE0783FE56A0AFCEB Signature length = 256 Number of chains = 10 Signature content buffer length = 1248 PL/SQL procedure successfully completed. |
signed_bytes_T1 と signed_bytes_T2BLOB を使用すると、以下の例のように DBMS_BLOCKCHAIN_TABLE.VERIFY_TABLE_BLOCKCHAIN プロシージャを使用することができます。
| DECLARE signed_bytes_T1 BLOB; signed_bytes_T2 BLOB; rows_verified NUMBER; BEGIN DBMS_BLOCKCHAIN_TABLE.VERIFY_TABLE_BLOCKCHAIN(signed_bytes_T2,signed_bytes_T1, rows_verified); dbms_output.put_line('Rows verified = ' || rows_verified); END; / Rows verified = 10 PL/SQL procedure successfully completed. |
ベストプラクティス
- 各インスタンスの各チェーンについて、定期的に現在のハッシュと対応するシーケンス番号を台帳データベースの外部に保存し、チェーンの整合性を検証できるようにします。
- Data Guardを使用する場合は、Max Protectionモードを使用して元帳レコードの損失を回避します
（同期的なREDOトランスポートとプライマリでトランザクションがコミットされる前にスタンバイDBでコミット）。 - ユーザーは、データベースによって生成されたハッシュ値に挿入された行の署名を計算しなければなりません
(DBMS_BLOCKCHAIN_TABLE.get_bytes_for_row_signature()から)。 - ハッシュと署名は、データベースがまだ信頼できることを確認するために、将来の検証のためにデータベースの外部に保存されるべきです。
ブロックチェーンテーブルとブロックチェーンプラットフォームを使用する場合
Oracle Database Blockchain Tables | Oracle Blockchain Platform |
|---|---|
|
|
使用事例には以下のようなものがあります。
| 使用事例には以下のようなものがあります。
|
試用する準備はできていますか？
新しいネイティブ・ブロックチェーンテーブル機能を試すには、Oracle Cloudアカウントを持っていることを確認し、
cloud.oracle.comにアクセスして、Autonomous DatabaseをAlways Free層でプロビジョニングするか、またはコンピュート・インスタンス上のデータベースVMを30日間無料で試用してください。
次に、お気に入りのデータベース・クライアントに接続して、CREATE BLOCKCHAIN TABLEを作成します（必須条項を忘れずに！）。
何か問題や質問がある場合は、通常のカスタマーサポートチャンネルやパブリックフォーラムでサポートを提供しています。
コメント
コメントを投稿