Oracle11g 表領域暗号化
＜Oracle11g 表領域暗号化＞
ペンネーム： びー・うぃりー
今回から、2007年10月23日にリリースされましたOracle11gの気になる機能
を中心に連載する。
現在、弊社においてデータベースセキュリティに関する問い合わせが増加し
ている。この背景には、情報漏洩事故や企業会計不正といった社会的にイン
パクトのある問題がある。また物理的セキュリティ対策やクライアント側の
セキュリティ対策を実施し、さらにはサーバー側のセキュリティ対策までを
検討している企業が増えていると、考えられる。さらに情報セキュリティ強
化、内部統制確立、J-SOX 対応などにおいても、データベースのセキュリテ
ィ機能はますます注目度が上がると思う。
データベースのセキュリティといえば・・・
１．ユーザー認証とユーザー一元管理
２．アクセスコントロール
３．暗号化（格納データおよび通信データ）
４．監査
が、基本中の基本としてあげられる。
その中でも今回は暗号化をテーマに、
Oracle11gで実装された新機能の「表領域の暗号化」を検証する。
▼検証OS/Oracle環境
Linux server 2.6.9-42.EL
Oracle Database 11g Enterprise Edition
Release 11.1.0.6.0 – Production
▼表領域暗号化機能検証の手順と確認方法
１．Wallet保管場所の決定と作成
２．Walletと暗号鍵の生成
３．Walletオープン
４．暗号化された表領域の作成
５．オブジェクト作成
６．暗号化の確認
基本的な流れは上記の通り。Wallet及びTDEに関する検証は、
メルマガバックナンバーの「Oracleで暗号化に関する検証」
https://old.insight-tec.com/mailmagazine/ora3/vol271.htmlを参照。
１．Wallet保管場所の決定と作成
Oracle11gからは、sqlnet.oraに定義が追加されている
※検証環境の定義（例）
-格納場所
/home/ora11g/oracle/product/11.1.0/db/network/admin # sqlnet.ora Network Configuration File: /home/ora11g/oracle/product/11.1.0/db/network/admin/sqlnet.ora # Generated by Oracle configuration tools. NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT) encryption_wallet_location = (source = (method = file) (method_data = (directory =/home/ora11g/oracle/product/11.1.0/db)))
２．Walletと暗号鍵の生成
SQL> alter system set encryption key identified by “insight”;
-鍵の確認
sqlnet.oraで定義された格納場所にWalletと暗号鍵が”ewallet.p12”の
名前で作成される。
３．Walletオープン
SQL> alter system set wallet open identified by “insight”;
※ちなみにWalletクローズしたい場合は・・・、
alter system set wallet close;を実行。
SQL> select * from v$encyption_wallet; WRL_TYPE WRL_PARAMETER STATUS ------------ -------------------------------------- ---- file /home/ora11g/oracle/product/11.1.0/db OPEN
４．暗号化された表領域の作成
SQL> create tablespace secure_tbs datafile '/home/ora11g/oradata/ora11g/secure01.dbf' size 10M encryption using 'AES256' default storage (encrypt) ; ※コマンド後半の指定が表領域暗号化のための”おまじない” ※またこの後の確認のためノーマル表領域用テーブルスペースも作成 SQL> create tablespace normal_tbs datafile '/home/ora11g/oradata/ora11g/normal01.dbf' size 1M; SQL> select tablespace_name ,encrypted from dba_tablespaces; TABLESPACE_NAME ENC ------------------------------ --- SYSTEM NO SYSAUX NO UNDOTBS1 NO TEMP NO USERS NO EXAMPLE NO SECURE_TBS YES NORMAL_TBS NO SQL> select a.ts#,a.name,b.encryptionalg,b.eccryptedts from v$tablespace a,V$encrypted_tablespaces b where a.ts#=b.ts#; TS# NAME ENCRYPT ENC ---- ------------------------------ ------- --- 12 SECURE_TBS AES256 YES
５．オブジェクト作成
-テスト専用スキーマ作成 create user insight identified by insight default tablespace normal_tbs temporary tablespace temp quota unlimited on normal_tbs quota unlimited on secure_tbs; -テストデータ作成 ノーマル表領域にテーブル作成＆データ挿入 create table test_nml (col1 number(5), col2 varchar2(30), col3 date) tablespace normal_tbs; declare cnt number; begin cnt := 1; loop insert into test_nml values(cnt,'INSIGHT'||cnt,sysdate); commit; cnt := cnt + 1; if cnt >= 11 then exit; end if; end loop; end; / --暗号化表領域にテーブル作成＆データ挿入 create table test_enc (col1 number(5), col2 varchar2(30), col3 date) tablespace secure_tbs; declare cnt number; begin cnt := 1; loop insert into test_enc values(cnt,'INSIGHT'||cnt,sysdate); commit; cnt := cnt + 1; if cnt >= 11 then exit; end if; end loop; end; / -- テストデータ更新 & 表領域ONLINE/OFFLINE -- ※念のために表領域のONLINE/OFFLINEを実施 update test_nml set col2 = 'Insight Technology'; update test_enc set col2 = 'Insight Technology'; commit; alter tablespace normal_tbs offline; alter tablespace normal_tbs online; alter tablespace secure_tbs offline; alter tablespace secure_tbs online;
６．暗号化の確認
それぞれのデーファイルを直接確認する（※stringsコマンドで確認）
$ strings /home/ora11g/oradata/ora11g/normal01.dbf | grep Insight Insight Technology Insight Technology Insight Technology Insight Technology Insight Technology Insight Technology Insight Technology Insight Technology Insight Technology Insight Technology
10行選択されました。
$ strings /home/ora11g/oradata/ora11g/secure01.dbf | grep Insight
何も選択されません。暗号化されている模様・・・。
さらにデータファイルのダンプを取得して確認する
。
※下記はノーマル表領域のデータファイルのダンプ抜粋
～ ダンプファイルの一部抜粋 はじめ ～～ B7FB23D0 6E49120B 68676973 65542074 6F6E6863 [..Insight Techno] B7FB23E0 79676F6C 0C6B7807 2F291203 0203012C [logy.xk...)/,...] B7FB23F0 49120AC1 6769736E 54207468 6E686365 [...Insight Techn] B7FB2400 676F6C6F 6B780779 2912030C 03012C2F [ology.xk...)/,..] B7FB2410 1209C102 69736E49 20746867 68636554 [....Insight Tech] B7FB2420 6F6C6F6E 78077967 12030C6B 012C2F29 [nology.xk...)/,.] B7FB2430 08C10203 736E4912 74686769 63655420 [.....Insight Tec] B7FB2440 6C6F6E68 0779676F 030C6B78 2C2F2912 [hnology.xk...)/,] B7FB2450 C1020301 6E491207 68676973 65542074 [......Insight Te] B7FB2460 6F6E6863 79676F6C 0C6B7807 2F291203 [chnology.xk...)/] ～ ダンプファイルの一部抜粋 おわり ～～
※下記は暗号化表領域のデータファイルのダンプ抜粋
～～ ダンプファイルの一部抜粋 はじめ ～～ st: XCURRENT md: NULL tch: 2 flags: encrypted_on_disk only_sequential_access LRBA: [0x0.0.0] LSCN: [0x0.0] HSCN: [0xffff.ffffffff] HSUB: [65535] cr pin refcnt: 0 sh pin refcnt: 0 ★Encrypted buffer contents not dumped★ buffer tsn: 12 rdba: 0x0180000c (6/12) scn: 0x0000.00c34de7 seq: 0x0b flg: 0x06 tail: 0x4de7060b frmt: 0x02 chkval: 0x2314 type: 0x06=trans data Block dump from disk: Encrypted block <12, 25165836> content will not be dumped. Dumping header only. ～～ ダンプファイルの一部抜粋 おわり ～～
では、従来TDE問題視されていた暗号化列に対するレンジ検索は可能であるか
どうか？
(表領域暗号化機能では暗号化列を特定するわけではないので確認まで)
SQL> explain plan for select * from test_enc where col1 between 1 and 3; SQL> @?/rdbms/admin/utlxpls.sql 実行計画（一部抜粋） ----------------------------------------------------------------- | Id | Operation | Name | Time | ----------------------------------------------------------------- | 0 | SELECT STATEMENT | | 00:00:01 | | 1 | TABLE ACCESS BY INDEX ROWID| TEST_ENC | 00:00:01 | |* 2 | INDEX RANGE SCAN | SYS_C0013180 | 00:00:01 | -----------------------------------------------------------------
普通にRANGE SCANができている。
その他、Walletをクローズしても、TEST_ENC表は参照できた。しかし表領域
オフライン・オンラインを実施すると「Walletがオープンされてません」と
エラーになる。メモリ上にデータがある場合は引き続き参照できる場合もあ
るようだ。このあたりは、暗号化・復号化される個所がディスクのみである
ことからも納得。おそらくDBWRnが実施していると思われる。
▼まとめ
TDEとの違いとして、「暗号化の単位」「暗号化・復号化のタイミング」
「暗号化する範囲」がマニュアルにも明記されている。
ブロック単位で暗号化できる、ディスクI/O時に暗号化・復号化される、
ディスクのみ暗号化される（メモリ上はしない）、となる。
この特徴は、暗号化を細かい範囲でかつ暗号化・復号化による負荷が
かかる頻度を下げることになり、Oracle暗号化機能がだいぶリーズナブル
なものなったのでは、考える。
もともと暗号化ソリューションは、万一、データが摂取された場合であっ
ても暗号化されているからだいじょーぶ！ということ。だからデータ摂取
される可能性が非常に低いケースにおいて、暗号化するためにわざわざア
プリケーションを変更しなければならないとか、パフォーマンスが極度に
落ちるとかは、許容できない。
（パフォーマンスの検証はまたの機会に・・・。）
この表領域の暗号化機能は非常に使いやすく、Oracleデータベース間で移
動、保管のために外部設備に移動するためにバックアップしたい、またそ
こにリスクが大きいと判断される企業様においては暗号化を検討する余地
があるのでは！、と考える。
ただ、データベース内からのアクセスは制御できない、Oracleの対応して
いるバージョンが限定的など、数々の制限事項があるのも事実。この機
能も含む暗号化機能全般においていえることだが、すべてのセキュリティ
問題に対処できるわけではないことには変わりない。
だとすれば、やはり「あくまでも補完的」、「あくまでもリスクのあると
ころのみ」のソリューションであると考える。
さぁー！師走！情熱に突き動かされ仕事しまくった今年2007年。
2008年のキーワードは「Beyond!!」だーー。
恵比寿にて