Database Support Blog

  • Oracle Database
2021.04.27

OracleDBにブロックチェーン?21c新機能Blockchain Tableとは

Oracle Database 21cのオンプレミスリリースが目前となり、その全容が明らかになってきました。
あわせてOracle Databaseは「コンバージド・データベース」として、様々なデータをOracle Databaseでサポートするという展望が発表されています。
このコンバージド・データベースの一角として、Oracle Database 21cではOracleへブロックチェーン(分散型台帳技術)の思想を取り入れたBlockchain Tableという新たなオブジェクトが誕生しました。

今回はOracle Database 19c Release Update 19.10(以降、RU 19.10)でバックポート※された、このBlockchain Tableを検証していこうと思います。

※バックポート...新たなバージョンにて実装された機能を、旧バージョンへ移植すること。


Blockchain Tableの概要

Oracle Databaseにおけるセキュリティ対策

Oracle Databaseには豊富なセキュリティ対策の機能が提供されています。

データ暗号化オプション「Oracle Advanced Security」、DBAの職務分掌やアクセス制御を実現する「Oracle Database Vault」、監査情報の統合ソリューションである「Oracle Audit Vault and Database Firewall」、データモデリングやマスキングを実現する「Oracle Data Masking and Subsetting」など多種多様です。

今回取り上げるBlockchain Tableは、Oracle Database 21cより標準実装(エディション問わず使用可能)された新たな機能であり、セキュリティの位置づけとしては格納されたデータの改ざんを阻止するためのソリューションとなっています。


Blockchain Tableとは

Blockchain Tableとは、ブロックチェーン技術の思想を取り入れた新たなテーブルオブジェクトのタイプです。
従来のテーブルと使用方法に大きな差はありませんが、耐改ざん性と証跡性を備えた特殊なテーブルオブジェクトです。

INSERTのみが許可されることに大きな特徴があり、挿入後のデータ変更はオブジェクトのオーナーもSYSDBAのような特権ユーザにも認められないことから、改ざんが事実上不可という特性を備えています。
また、ブロックチェーン技術の特色が大きく出ていると感じる点として、Blockchain Tableに格納される最初の行を除き、以降の全ての行は一つ前の行と暗号化ハッシュを使用して連鎖されています。
このハッシュの連鎖で前後の行をリンクし、データが改ざんされていない整合性を検証および証明することができます。


Oracle Databaseのリリースモデル

本編に入る前に、今後のOracle Databaseのリリースモデルについて簡単におさらいをします。
Oracle Database 18c以降のリリースには、Long Term ReleaseとInnovation Releaseの2つのタイプがあります。

2021年4月20日時点の情報です。掲載情報は変更になる可能性があります。
参考:Release Schedule of Current Database Releases (ドキュメントID 742060.1)


Innovation ReleaseのPremier Supportは2年であり、その後のExtended Supportの提供はありません。
対してLong Term RleaseのPremier Supportは5年、その後のExtended Supportは3年であり、その名の通り長期的なサポートが提供されます。
そのため、Innovation Releaseでは将来のLong Term Rleaseに備えた新規機能のアプリケーション検証などの用途が向いており、Long Term Rleaseは本番システムでの導入事例が多くなることが予想されます。

直近のInnovation ReleaseよりもRU 19.10以上での本番利用が現実的ではと想定し、当記事ではバックポートが提供された19cでの検証に臨みました。


Oracle Database 19cでBlockchain Tableを使用するためには

19cでBlockchain Tableを使用するには、いくつかの事前準備が伴います。
本来21cからの新機能であるBlockchain Tableは、19cではバックポートという形で提供されています。

RU 19.10とPatch 32431413の適用

前提としてデータベースソフトウェアのバージョンがRU 19.10以上である必要があります。
加えて、19cで不足しているファイルをPatch 32431413で補うことでBlockchain Tableが作成可能となります。

COMPATIBLEパラメータの変更

パッチ(RU 19.10とPatch 32431413)を適用した直後はBlockchain Tableを作成しようとすると、下記のようにORA-05728とORA-00722が発生して失敗してしまいます。

 
 SQL> create blockchain table BC_TAB(col1 number)
   2  no drop until 16 days idle
   3  no delete locked
   4  hashing using "SHA2_512" version "v1";
 create blockchain table BC_TAB(col1 number)
 *
 行1でエラーが発生しました。:
 ORA-05728: COMPATIBLE needs to be 19.10.0.0.0 or higher to use blockchain table
 ORA-00722: 機能"Blockchain table"
 

ORA-05728のエラーメッセージの通り、バックポートを有効にするためには初期化パラメータCOMPATIBLEに「19.10.0.0.0」と設定しなくてはなりません。

 
 --初期化パラメータCOMPATIBLEにRUのバージョンを設定する
 SQL> alter system set compatible='19.10.0.0.0' scope=spfile;
  
 システムが変更されました。
 
 --パラメータを反映させるためにインスタンスを再起動する
 SQL> shutdown immediate
 データベースがクローズされました。
 データベースがディスマウントされました。
 ORACLEインスタンスがシャットダウンされました。
 SQL> startup
 ORACLEインスタンスが起動しました。
  
 Total System Global Area 5049940832 bytes
 Fixed Size              9145184 bytes
 Variable Size        1040187392 bytes
 Database Buffers     3992977408 bytes
 Redo Buffers            7630848 bytes
 データベースがマウントされました。
 データベースがオープンされました。
 
 --PDBへ接続してBlockchain Tableが作成できることを確認
 SQL> conn knakagaki/pass@gacky:1521/orcl_pdb.ashisuto.co.jp
 接続されました。
 SQL> create blockchain table BC_TAB(col1 number)
   2  no drop until 16 days idle
   3  no delete locked
   4  hashing using "SHA2_512" version "v1";
  
 表が作成されました。
 

その他

通常はCOMPATIBLEパラメータにRUのバージョンを格納はしません。

Oracle Databaseのリリース デフォルト値 最小値 最大値
Oracle Database 19c 19.0.0 11.2.0 CDBまたは非CDBインスタンスの場合、RUまたはRURのCOMPATIBLEパラメータを変更しないでください。

Oracle® Database データベース・アップグレード・ガイド 19c
Oracle DatabaseのCOMPATIBLE初期化パラメータの値 より引用


RU 19.10以上で提供されているBlockchain Tableのバックポートを利用するために、例外的にRUのバージョンを格納することは認められております。

既知の問題として、COMPATIBLEパラメータにRUのバージョンを格納するとData Pumpユーティリティが使用できなくなってしまう事象が発生します(My Oracle Support Notes 2656508.1 )。
この問題はPatch 30828205を別途適用することで回避可能です。


Blockchain Tableを検証

それではBlockchain Tableを実際に作成し、検証を行っていきましょう。

Blockchain Tableの作成

Blockchain Tableは「CREATE BLOCKCHAIN TABLE」コマンドを使用して作成します。
実際の作成時にはオブジェクトごとに 赤い太字の箇所 を書き換える必要がある点にご注意ください。


CREATE BLOCKCHAIN TABLE オブジェクト名 ( 列定義 )
NO DROP [ UNTIL n DAYS IDLE ]
NO DELETE [ UNTIL n DAYS AFTER INSERT ] [ LOCKED ]
HASHING USING “SHA2_512” VERSION “v1”;

Blockchain TableはINSERTのみ可能なイミュータブル※なオブジェクトであるという設計思想があります。
そのため、CREATE文ではBlockchain Tableの保存期間と、格納される行データの保存期間を設定します。

※イミュータブル...作成後に変更されない性質のこと。


Blockchain Table の保存期間
NO DROP Blockchain Tableが削除されない定義です。
NO DROP UNTIL n DAYS IDLE Blockchain Tableに格納された最新の行データの経過日数がn日未満の場合、削除されない定義です。nの最小値は0です。
なお、作成後に保存期間を短くすることはできません。

格納される行データの保存期間
NO DELETE [ LOCKED ] 行データが削除されない定義です。
LOCKEDキーワードを付与すると、保存設定は変更不可となります。
NO DELETE UNTIL n DAYS AFTER INSERT [ LOCKED ] 行データがn日経過するまで削除されない定義です。nの最小値は16です。
LOCKEDキーワードを付与すると、保存設定は変更不可となります。
なお、作成後に保存期間を短くすることはできません。


以下では検証用のオブジェクトとして、格納された最新の行データの経過日数を問わずDROP可能で、行データが16日経過するまで削除されないBlockchain Tableを作成しました。

 
 SQL> create blockchain table BC_TAB(col1 number)
   2  no drop until 0 days idle
   3  no delete until 16 days after insert locked
   4  hashing using "SHA2_512" version "v1";
  
 表が作成されました。
 
 SQL> select TABLE_NAME,ROW_RETENTION,ROW_RETENTION_LOCKED,TABLE_INACTIVITY_RETENTION
   2  from USER_BLOCKCHAIN_TABLES;
  
 TABLE_NAME ROW_RETENTION ROW_RETENTION_LOCKED TABLE_INACTIVITY_RETENTION
 ---------- ------------- -------------------- --------------------------
 BC_TAB                16 YES                                           0
 

Blockchain Tableへのデータ登録

データの登録は通常のテーブルオブジェクトと変わりなく可能です。
試しに1行INSERTしてみます。

  
 SQL> insert into BC_TAB values (12345);
  
 1行が作成されました。
  
 SQL> commit;
  
 コミットが完了しました。
  
 SQL> select COL1 from BC_TAB;
  
       COL1
 ----------
      12345
 

通常のテーブルと同様にINSERT文でデータが登録でき、SELECT文で問い合わせができました。

Blockchain Tableへのデータ移行

通常のテーブルからBlockchain Tableへ利用を切り替える場合、前述のように通常のテーブルと同様にSELECT文での問い合わせが可能なことから、データを移行するのみでアプリケーションからは透過的に利用が可能と考えられます。

例えば、以下のような部屋の入退室記録があり、セキュリティ重要度が高いことからBlockchain Tableへ利用を移行するケースを想定します。

 
 SQL> select ACCESS_DATE,ID,ACTION from ROOM_ACCESS order by 1;
 
 ACCESS_DATE                      ID ACTION
 ------------------------ ---------- ------------------------------
 21-01-01 04:17:30.174396       9265 EXIT
 21-01-01 05:05:04.986174       8390 EXIT
 21-01-01 10:18:30.140534       9302 EXIT
 21-01-01 13:10:04.190704       6774 ENTER
 21-01-01 14:36:30.097022       5595 EXIT
 21-01-01 19:05:00.114364       7970 EXIT
 21-01-01 19:18:10.217762       6217 ENTER
 ・・・省略・・・
 21-04-10 00:55:50.038410       1163 EXIT
 21-04-10 04:12:28.132694       8398 ENTER
 21-04-10 05:14:30.077214       9246 EXIT
 21-04-10 06:25:50.000568       2172 EXIT
 21-04-10 08:30:30.174714       5653 EXIT
 21-04-10 09:38:10.075122       6698 EXIT
 21-04-10 12:21:40.033440       4134 EXIT
 21-04-10 12:25:40.104282       3615 EXIT
 21-04-10 13:41:30.018330       9997 EXIT
 21-04-10 18:11:56.981372        885 EXIT
 21-04-10 18:18:10.019506       4609 EXIT
 

アプリケーションから透過的に利用を切り替えることを考慮すると、オブジェクト名は同名であることが望ましいかと思います。
しかし、ディクショナリ上では通常のテーブルもBlockchain TableもOBJECT_TYPE=TABLEとして扱われるため、同名のオブジェクトは作成ができません。

 
 --同名のオブジェクトが存在する旨のエラーを受ける
 SQL> create blockchain table ROOM_ACCESS
   2   (ACCESS_DATE TIMESTAMP(6),
   3    ID          NUMBER(4,0),
   4    ACTION      VARCHAR2(10)
   5   )
   6  no drop until 0 days idle
   7  no delete until 16 days after insert
   8  hashing using "SHA2_512" version "v1";
 create blockchain table ROOM_ACCESS
                        *
 行1でエラーが発生しました。:
 ORA-00955: すでに使用されているオブジェクト名です。
 
 --USER_OBJECTSビューを参照するとBlockchain TableもOBJECT_TYPE=TABLE
 SQL> select OBJECT_NAME,OBJECT_TYPE from USER_OBJECTS
   2  where OBJECT_NAME='BC_TAB';
  
 OBJECT_NAME          OBJECT_TYPE
 -------------------- --------------------
 BC_TAB               TABLE
 

そのため、同名のオブジェクトが必要な場合にはオリジナルのテーブルを一度別のテーブルへ退避した後に、Blockchain Tableを作成する必要があります。

  
 --ROOM_ACCESS表のデータを退避用のテーブルへ格納する
 SQL> create table ROOM_ACCESS_TEMP as select * from ROOM_ACCESS;
  
 表が作成されました。
  
 SQL> drop table ROOM_ACCESS purge;
  
 表が削除されました。
  
 --ROOM_ACCESSという名前のBlockchain Tableを作成
 SQL> create blockchain table ROOM_ACCESS
   2   (ACCESS_DATE TIMESTAMP(6),
   3    ID          NUMBER(4,0),
   4    ACTION      VARCHAR2(10)
   5   )
   6  no drop until 0 days idle
   7  no delete until 16 days after insert
   8  hashing using "SHA2_512" version "v1";
  
 表が作成されました。
 

その後、退避したオリジナルのデータをBlockchain Tableへ移行していきます。

「データの移行」と聞くとData Pumpユーティリティを思い浮かべる方が多いかと思います。残念ながらBlockchain TableではData Pumpユーティリティの制限が多く(Data Pump使用に関する制限はデータベース管理者ガイド を参照)、table_exists_actionパラメータのAPPEND、TRUNCATE、REPLACEが使用できないため、既存のBlockchain Tableへのデータインポートはできません。

そのため、データを移行するには、INSERT … SELECTで移行するという方法のみが可能であると考えられます。

 
 --退避用のテーブルからBlockchain Tableへデータを登録し直す
 SQL> insert into ROOM_ACCESS select * from ROOM_ACCESS_TEMP;
  
 1000行が作成されました。
  
 SQL> commit;
  
 コミットが完了しました。
 
 SQL> select * from ROOM_ACCESS order by 1;
  
 ACCESS_DATE                      ID ACTION
 ------------------------ ---------- ------------------------------
 21-01-01 04:17:30.174396       9265 EXIT
 ・・・省略・・・
 21-04-10 18:18:10.019506       4609 EXIT
 

Blockchain Tableの耐改ざん性

Blockchain Tableがどのようにして高い耐改ざん性を実現しているのか確認していきましょう。

前後行の関係性

Blockchain Tableはユーザが定義する列と、Oracleが作成する非表示の列から構成されます。
この非表示列にはテーブル内で一意のシーケンスなどが含まれ、前後の行の関係性を暗黙的に記録しています。
内部的にシーケンスが割り当てられるため、最初の1行目を除き全ての行データには一意の前の行が存在することになります。

この前後の行の関係性をBlockchain TableではSHA2-512アルゴリズムによるハッシュ値を算出し、行を連鎖することで高い耐改ざん性を実現しています。

  
 SQL> select COL1,
   2         ORABCTAB_CHAIN_ID$,
   3         ORABCTAB_SEQ_NUM$,
   4         to_timestamp_tz(ORABCTAB_CREATION_TIME$) at time zone 'Asia/Tokyo' "ORABCTAB_CREATION_TIME$",
   5         ORABCTAB_HASH$
   6  from BC_TAB order by 4;
  
       COL1 ORABCTAB_CHAIN_ID$ ORABCTAB_SEQ_NUM$ ORABCTAB_CREATION_TIME$
 ---------- ------------------ ----------------- ----------------------------------------
 ORABCTAB_HASH$
 ---------------------------------------------------------------------------------------------------------------------------------------
      12345                 17                 1 21-03-14 20:11:25.616573 ASIA/TOKYO
 6897669AE1EA23A1327AC1CCB9AC0BE74E27D1CBD3BBDFBD9B55C4DECE7CC7DF51B42F81EEDB6F12C939659411C6E0542C9E1C8479297FF18F7DCDB89BA3DACD
  
      67890                 17                 2 21-03-14 20:11:25.619577 ASIA/TOKYO
 1AA48865D4BCE8F56B478042110A709058959877DC300ADB79E026D7BDAA010F2033BF1CC7B059CB5BF6712DBFDE813EE5080E97072B7EC9115AD75FBE289D24
 

非表示列についてはデータベース管理者ガイド をご参照ください。


行データの整合性検証

前述の通り、Blockchain TableはINSERTのみ可能なイミュータブルなオブジェクトです。
つまり、挿入後のデータ変更は認められません。

このBlockchain TableへINSERTされた行データが挿入後に変更されていないことを証明するために、DBMS_BLOCKCHAIN_TABLE.VERIFY_ROWSプロシージャ でデータの整合性を検証することができます。

DBMS_BLOCKCHAIN_TABLE.VERIFY_ROWSプロシージャでは、Blockchain Table内のハッシュ値を再計算して、その値が対応する内部列に保存されている値と一致することを検証し、不正がある場合には該当する例外が表示されます。

 
 SQL> set serveroutput on
 SQL> DECLARE
   2      	verify_rows NUMBER;
   3  BEGIN
   4      	DBMS_BLOCKCHAIN_TABLE.VERIFY_ROWS('KNAKAGAKI','BC_TAB', NULL, NULL, 1, NULL, verify_rows);
   5      	DBMS_OUTPUT.PUT_LINE('Number of rows verified in instance Id '|| 1 || ' = '|| verify_rows);
   6  END;
   7  /
 Number of rows verified in instance Id 1 = 2
  
 PL/SQLプロシージャが正常に完了しました。
 

Blockchain Tableの制限

高い耐改ざん性を実現する一方で、Blockchain Tableには通常のテーブルと比べて多くの使用上の制限事項があります。

代表的な例としては、挿入後のデータ変更は認められないためINSERTを除くDML操作は受け入れられず、作成後のテーブル定義の変更も行うことはできません。

 
 --UPDATEが実行できない
 SQL> update BC_TAB set col1=99999 where col1=12345;
 update BC_TAB set col1=99999 where col1=12345
    	*
 行1でエラーが発生しました。:
 ORA-05715: operation not allowed on the blockchain table
 
 --列定義の変更が行えない
 SQL> alter table BC_TAB modify (col1 number(10));
 alter table BC_TAB modify (col1 number(10))
 *
 行1でエラーが発生しました。:
 ORA-05715: operation not allowed on the blockchain table
 

その他にも制限される操作が多々あるため、データベース管理者ガイド を併せてご確認ください。

保存期間を超えた行データの削除

Blockchain Tableの作成時に行データの保存期間を定めます。
「NO DELETE UNTIL n DAYS AFTER INSERT」で定義した場合、設定したn日を超えた行データを削除することができます。

ただし、通常のテーブルのようにDELETEコマンドでは削除できない点がBlockchain Tableの特徴です。

 
 --各行のINSERTされた時間を確認する
 SQL> select COL1,to_timestamp_tz(ORABCTAB_CREATION_TIME$) at time zone 'Asia/Tokyo' "ORABCTAB_CREATION_TIME$"
   2  from BC_TAB order by 2;
  
       COL1 ORABCTAB_CREATION_TIME$
 ---------- ----------------------------------------
      12345 21-03-14 20:11:25.616573 ASIA/TOKYO
      67890 21-03-14 20:11:25.619577 ASIA/TOKYO
      99999 21-03-15 19:46:44.101890 ASIA/TOKYO
  
 SQL> select SYSDATE from DUAL;
  
 SYSDATE
 -----------------
 21-04-11 16:41:51
  
 --現在格納されている行データは何れも保存期間を超過しているが、DELETEコマンドでは削除できない
 SQL> delete BC_TAB where COL1=12345;
 delete BC_TAB where COL1=12345
        *
 行1でエラーが発生しました。:
 ORA-05715: operation not allowed on the blockchain table
 

保存期間を超えた行データは、DBMS_BLOCKCHAIN_TABLE.DELETE_EXPIRED_ROWSプロシージャ を使用して削除します。
下記の例ではbefore_timestampパラメータ(第3引数)より前に挿入されたデータを削除しています。

 
 SQL> set serveroutput on
 SQL> DECLARE
   2          num_rows NUMBER;
   3  BEGIN
   4          DBMS_BLOCKCHAIN_TABLE.DELETE_EXPIRED_ROWS('KNAKAGAKI',
   5                                                    'BC_TAB',
   6                                                    '21-03-14 20:12:00.00 +09:00',
   7                                                    num_rows
   8                                                   );
   9          DBMS_OUTPUT.PUT_LINE('Number_of_rows_deleted=' || num_rows);
  10  END;
  11  /
 Number_of_rows_deleted=2
  
 PL/SQLプロシージャが正常に完了しました。
 
 --before_timestampパラメータより前に挿入されたCOL1=12345と67890の行が削除された
 
 SQL> select COL1,to_timestamp_tz(ORABCTAB_CREATION_TIME$) at time zone 'Asia/Tokyo' "ORABCTAB_CREATION_TIME$"
   2  from BC_TAB order by 2;
  
       COL1 ORABCTAB_CREATION_TIME$
 ---------- ----------------------------------------
      99999 21-03-15 19:46:44.101890 ASIA/TOKYO
 

保存期間の変更

Blockchain Tableの表定義の変更は基本的に不可ですが、行データの保存期間やBlockchain Tableの保存期間の変更は可能です。

 
 --最新の行データの経過日数が5日未満の場合に表がDROPできず、
   行データは16日経過するまで削除されないBlockchain Tableを作成
 SQL> create blockchain table BC_TAB(col1 number)
   2  no drop until 5 days idle
   3  no delete until 16 days after insert
   4  hashing using "SHA2_512" version "v1";
  
 表が作成されました。
  
 SQL> select * from USER_BLOCKCHAIN_TABLES;
  
 TABLE_NAME ROW_RETENTION ROW_RETENTION_LOCKED TABLE_INACTIVITY_RETENTION HASH_ALGORITHM
 ---------- ------------- -------------------- -------------------------- ------------------------
 BC_TAB                16 NO                                            5 SHA2_512
  
 --表のDROPが可能となる最新の行データの経過日数を10日未満へ延長する
 SQL> alter table BC_TAB no drop until 10 days idle;
  
 表が変更されました。
  
 SQL> select * from USER_BLOCKCHAIN_TABLES;
  
 TABLE_NAME ROW_RETENTION ROW_RETENTION_LOCKED TABLE_INACTIVITY_RETENTION HASH_ALGORITHM
 ---------- ------------- -------------------- -------------------------- ------------------------
 BC_TAB                16 NO                                           10 SHA2_512
  
 --行データが削除可能となる経過日数を20日に延長する
 SQL> alter table BC_TAB no delete until 20 days after insert;
  
 表が変更されました。
  
 SQL> select * from USER_BLOCKCHAIN_TABLES;
  
 TABLE_NAME ROW_RETENTION ROW_RETENTION_LOCKED TABLE_INACTIVITY_RETENTION HASH_ALGORITHM
 ---------- ------------- -------------------- -------------------------- ------------------------
 BC_TAB                20 NO                                           10 SHA2_512
 

ただし、保存期間を大きくすることはできますが、短縮することはできないため、Blockchain Tableの作成時や定義の変更時には十分に要件を考慮のうえ作業を実施ください。

ある程度の保持期間で運用検証を行った後に、Blockchain TableをDROPできないように変更するというケースもあるかもしれません。
しかし、現状この操作を行うとORA-00600エラーで処理が失敗してしまう不具合があります(My Oracle Support Notes 2762547.1 )。開発部門での調査中のため、DROP不可なBlockchain Tableを作成したい場合にはCREATE時に指定するようにしてください。

 
 SQL> alter table BC_TAB no drop;
 alter table BC_TAB no drop
 *
 行1でエラーが発生しました。:
 ORA-00600: 内部エラー・コード, 引数: [atbbctable_1], [0], [], [], [], [], [], [], [], [], [], []
 

まとめ

今回はOracle Database 21cから登場したBlockchain Tableを検証、ご紹介しました。
INSERTのみが許可される、SYSDBAもオブジェクトオーナーでもデータ変更が不可能というデータの堅牢性が担保された、格納されたデータの信頼性が非常に高いオブジェクトです。

オラクル社のセミナーではこのイミュータブルな特性から、
 「アプリケーションのアクセスログや監査ログ、
  高セキュリティエリアへの入退室記録などセキュリティ上重要な記録」
 「企業の会計、財務のデータなど法律上確実な保存が要求される情報」
 「勘定系システム、決済系システムなど内外からの攻撃に対して保護すべきデータ」
といったユースケースが紹介されていました。

しかしこの堅牢さから、誤ったデータの混入が万が一起こった場合には対応が難しいオブジェクトである側面もあると考えます。
例えば、「FLASHBACK TABLE」コマンドはオブジェクトの制限上使用できず、バックアップファイルからメディアリカバリを行う必要があるなど、扱ううえでの考慮点は多々あります。
格納されるタイミングのデータの信頼性も確実なものにするためには、もうワンクッション対策が必要である点はシステム構築上の1つの課題となるでしょう。

アシストでは多くの製品を組み合わせてお客様の課題を解決するお手伝いをしています。
データベースのセキュリティ対策もご支援しておりますので、ぜひお気軽にお問い合わせください。

 


<参考>
オラクルエンジニア通信
オラクルのデータベース・セキュリティ全体像:DB基本機能~情報漏洩・不正アクセス防止etc
Blockchain TableによるOracle Databaseのコンバージドデータベースの拡張


執筆者情報

なかがき けいすけ プロフィール画像

アシスト北海道

2016年アシスト北海道へ入社後、Oracle Databaseのサポート業務に従事。入社2年目より夜間休日帯など営業時間外の緊急対応を主に担当。現在は通常時間帯のサポート業務を担当しており、第一線で日々奮闘中。...show more


■本記事の内容について
 本記事に示した定義及び条件は変更される場合があります。あらかじめご了承ください。

■商標に関して
 ・Oracle®、Java、MySQL及びNetSuiteは、Oracle、その子会社及び関連会社の米国及びその他の国における登録商標です。
 ・Amazon Web Services、AWS、Powered by AWS ロゴ、[およびかかる資料で使用されるその他の AWS 商標] は、Amazon.com, Inc. またはその関連会社の商標です。
  文中の社名、商品名等は各社の商標または登録商標である場合があります。

関連している記事

  • Oracle Database
2024.04.08

【Oracle Database】FAQで安定運用に貢献!サポートセンターのナレッジ公開の取り組み

アシストオラクルサポートセンターが公開しているFAQは、仕様に関するQAやエラー発生時の対処方法などはもちろん、不具合情報や障害発生時の情報取得方法といった安定運用に役立つ内容も扱っています。そのFAQをどのように作成しているのか、サポートセンターの取り組みをご紹介します。

  • Oracle Cloud
  • Oracle Database
2024.02.02

OCIにおけるOracle Database 11g R2、12g R1、12g R2の新規プロビジョニング終了とその影響

Oracle Databaseのバージョン11g R2、12g.R1、12g.R2は既にすべてのメーカーサポートが終了しています。OCIのBase Database Serviceでも2024年1月中旬ころから11g R2、12g R1、12g R2での新規プロビジョニングができなくなりました。

  • Oracle Database
  • その他
2023.12.21

【Oracle Database】サポートセンターでの生成AI(Glean)活用

アシストでは全社員にAIアシスタントGleanを導入しました。サポートセンターで2ヶ月間使ってみて感じた効果やメリットをお伝えします。

ページの先頭へ戻る