Oracle 11g　暗号化 + 監査

＜Oracle 11g　暗号化 + 監査＞
ペンネーム：ぽっちゃりメタボン　他2名

読者の皆様こんにちは。
いつもご愛読ありがとうございます。
おかげさまで、今回の配信は2007年内最終となりました。
いやー、2007年最後を飾れるなんて・・・感激です。

来年は、少し新しいチャレンジをする予定です。
今年同様、ma-e-no-me-ri spiritsで邁進する所存ですので
今後ともメタボンを・・・
いやインサイトテクノロジーをよろしくお願いします。

また読者の皆様だけに、先行してお知らせします。
なんと！インサイトテクノロジーの製品やサービスに特化したムック本
「Insight Press」が翔泳社より発売されます。

http://www.amazon.co.jp/Insight-Press-%E5%86%85%E9%83%A8%E7%B5%B1%E5%
88%B6%E6%99%82%E4%BB%A3%E3%81%AE%E3%83%87%E3%83%BC%E3%82%BF%E3%83%99%
E3%83%BC%E3%82%B9%E5%BC%B7%E5%8C%96%E3%82%BD%E3%83%AA%E3%83%A5%E3%83%
BC%E3%82%B7%E3%83%A7%E3%83%B3PISO-Performance-Insight%E5%BE%B9%E5%BA%
95%E6%B4%BB%E7%94%A8/dp/4798115991/ref=sr_1_2?ie=UTF8&s=books&qid=1197360543&sr=8-2

弊社社内すべての英知を結集して社員全員で作成した本です。
皆様のデスクに一冊、ご自宅の書斎に一冊、鞄に一冊！
ぜひご覧ください。

それでは、今週もはりきって検証しちゃいます。

▼ はじめに

先週のメールマガジン「表領域暗号化」を皆さん読んでいただけましたでしょ
うか？表領域をすべて暗号化するという(実際は表領域配下のデータファイル)
機能の、データベースセキュリティにおける、その位置づけと適用範囲がイ
メージできたと思います。社内にてその後、引き続き検証を実施していったこ
とろ、暗号化された表領域ではデータファイルのサイズが結構大きくなる傾向
がありました。ま、当然と言えばそうなんですが・・・。データベースに格納
するデータの暗号化も要件に含まれるような構築案件や、既存データを暗号化
された表領域へ移行するなどのケースでは多少考慮が必要ですね。

先週、へぇーと余裕かましてメルマガを見ていると、ふと思いました。
「おいらが検証した”LogMiner”って、データが暗号化されていて、リカバリや
監査ができるのだろうか？」と。

そんな事を考えつつ、11gの新機能をぱらぱら調べていると、

なんと！

TDEの新機能として “LogMiner対応” の文字が！！

はて、これは一体どういうことでしょう？
10gまでは、対応していなかったということ？

これは、検証せずにはいられません！
ということで・・・

今回のテーマは、「暗号化 + 監査」のセキュリティ機能マッシュアップで
むりやり執拗にデータベースをセキュアしてみようと考えついちゃいました。

前回も紹介しましたが、データベースセキュリティの基本といえば・・・

１．ユーザー認証とユーザー一元管理
２．アクセスコントロール
３．暗号化（格納データおよび通信データ）
４．監査

今回は、前回検証時に使用したTDEを活用してカラムを暗号化し、さらにメタ
ボン唯一の得意分野であるLogMinerを使用して「監査」してみます。
はたして、データは見えるのか？
暗号化したのに、データは見えて良いのか？悪いのか？

※注意
今回の検証は、表領域暗号化ではなくカラム単位で暗号化可能なTDEを使用。

*TDEについては「Oracleで暗号化に関する検証」を参照してください。
https://old.insight-tec.com/mailmagazine/ora3/vol271.html

********今回の検証内容********
１．10gR2 環境においてTDEで暗号化したカラムを更新(UPDATE)する
→ 更新前後の値がみられるか？
２．11g 環境においてTDEで暗号化したカラムを更新(UPDATE)する
→ 更新前後の値がみられるか？
３．REDOダンプの中身はどうなっているか？
******************************

まずは、検証環境の準備から。

・検証用ユーザ作成
　　　　　　　　SQL> create user &username identified by &username;

・テーブルを作成して、データを入れる
　　　　　　　　通常のテーブル
　　　　　　　　SQL> create table metabon_normal
　　　　　　　　　　　　　　　　　　　　　　(id number
　　　　　　　　　　　　　　　　　　　　　　　,name varchar2(40)
　　　　　　　　　　　　　　　　　　　　　　　,sal number);
　　　　　　　　　SQL> insert into metabon_normal values (1,'metabon1',500);
　　　　　　　　　SQL> insert into metabon_normal values (2,'metabon2',1000);
　　　　　　　　　SQL> insert into metabon_normal values (3,'metabon3',1500);
　　　　　　　　　SQL> commit;

　　　　　　　　　暗号化されたテーブル(sal列を暗号化)
　　　　　　　　　SQL> create table metabon_encrypt(id number , name varchar2(40)
　　　　　　　　　　　　　　　　　　　,sal number encrypt);
　　　　　　　　　SQL> insert into metabon_encrypt values (1,'metabon1',500);
　　　　　　　　　SQL> insert into metabon_encrypt values (2,'metabon2',1000);
　　　　　　　　　SQL> insert into metabon_encrypt values (3,'metabon3',1500);
　　　　　　　　　SQL> commit;

・最小サプリメンタルロギングを有効にする
　　　　　　　　SQL> alter database add supplemental log data;

・sal列をupdateする
　　　　　　　　SQL> update metabon_normal set sal=sal*2;
　　　　　　　　SQL> update metabon_encrypt set sal=sal*2;
　　　　　　　　SQL> commit;

準備完了！
早速、LogMinerで、それぞれのテーブルの更新情報を見てみます。
まずは、10gを見てみるのだ。

１．10gR2 環境においてTDEで暗号化したカラムのREDO情報を確認する

OS: RedHat ES4 update4
Oracle: 10gR2(10.2.0.3)

SQL_REDO
----------------------------------------------------------------------
update "METABON"."METABON_NORMAL" set "SAL" = '1000'
　　　　　　　　　　　　where "SAL" = '500';

update "METABON"."METABON_NORMAL" set "SAL" = '2000'
　　　　　　　　　　　　where "SAL" = '1000';

update "METABON"."METABON_NORMAL" set "SAL" = '3000'
　　　　　　　　　　　　where "SAL" = '1500';

update "METABON"."METABON_ENCRYPT" set "SAL" = Unsupported Type
　　　　　　　　　　　　where "SAL" = Unsupported Type;

update "METABON"."METABON_ENCRYPT" set "SAL" = Unsupported Type
　　　　　　　　　　　　where "SAL" = Unsupported Type;

update "METABON"."METABON_ENCRYPT" set "SAL" = Unsupported Type
　　　　　　　　　　　　where "SAL" = Unsupported Type;

おーーーっと。

やはり、”METABON_ENCRYPT”の方は、SAL列の値が”Unsupported Type”
となっていますね。
10gR2まではTDEを使用して、データを暗号化すると、LogMinerではデータの参
照ができませんね。
これじゃ、監査もリカバリもできないな・・・。

気持ちを入れ替えて、11gでやってみるのだ。

２．11g 環境においてTDEで暗号化したカラムのREDO情報を確認する

OS: RedHat ES4 update4
Oracle: 11gR1 (11.1.0.6)

SQL_REDO
----------------------------------------------------------------------
update "METABON"."METABON_NORMAL" set "SAL" = '1000'
　　　　　　　　　　　　where "SAL" = '500';

update "METABON"."METABON_NORMAL" set "SAL" = '2000'
　　　　　　　　　　　　where "SAL" = '1000';

update "METABON"."METABON_NORMAL" set "SAL" = '3000'
　　　　　　　　　　　　where "SAL" = '1500';

update "METABON"."METABON_ENCRYPT" set "SAL" = '1000'
　　　　　　　　　　　　where "SAL" = '500';

update "METABON"."METABON_ENCRYPT" set "SAL" = '2000'
　　　　　　　　　　　　where "SAL" = '1000';

update "METABON"."METABON_ENCRYPT" set "SAL" = '3000'
　　　　　　　　　　　　where "SAL" = '1500';

本当に見えるのかと、若干疑いながらやってみたものの、METABON_ENCRYPTも
データがしっかりと見えます。
TDEの11g新機能、「LogMiner対応」は確実にされてますね。

本当にREDOログが暗号化されているのか、念のためダンプも見てみましょう。

３．REDOダンプの中身はどうなっているか？

まずは、10g。

METABON_NORMALの更新処理が含まれるREDOダンプは、こんな感じ。

[UNDO]
col  2: [ 2]  c2 06  ← "sal = 500"

[REDO]
col  2: [ 2]  c2 0b  ← "sal = 1000"

METABON_ENCRYPTの更新処理が含まれるREDOダンプは、こんな感じ。

[UNDO]
col  2: [52]
 ad 6b 85 99 6c 64 28 b0 42 15 6d 19 89 2d 3c 7f ea bc 91 96 78 43 3a 7b 3f
 05 59 f5 bb 32 d9 18 90 89 a2 a1 a1 08 37 8d a8 5e 38 dc c7 fd ff 80 05 01
 a1 25 ← "sal = ????"

[REDO]
col  2: [52]
 98 32 e0 9f 63 6f ab 01 c1 54 95 9a c0 3b 2b f7 73 72 14 61 ef af 4e b4 42
 d0 5d 4f 5b 9f 1a 35 2b 5e f2 b2 ba 61 d8 61 89 4d 62 26 bc c4 0e 11 d0 55
 08 0f ← "sal = ????"

やっぱり暗号化されてます。

お次は、11g。

METABON_NORMALの更新処理が含まれるREDOダンプは、こんな感じ。

[UNDO]
col  2: [ 2]  c2 06  ← "sal = 500"

[REDO]
col  2: [ 2]  c2 0b  ← "sal = 1000"

METABON_ENCRYPTの更新処理が含まれるREDOダンプは、こんな感じ。

[UNDO]
col  2: [52]
 9c 61 f8 44 4b 7b da ac 0c 99 2c 3f a0 05 ee 41 f0 1a d7 29 e2 27 18 45 84
 06 ec fd c9 73 84 41 45 d6 02 c6 67 94 84 c7 d5 68 b5 de 1f be 3e e4 1d ed
 ea 44 ← "sal = ????"

[REDO]
col  2: [52]
 40 6c 84 64 96 b4 22 d9 84 f4 23 d6 e7 a7 17 ee c7 08 a6 83 ae b4 26 a2 e5
 bd ab 3a e9 52 92 7e b4 f1 a9 74 2c 3b 96 62 1c fc 39 c8 8d 40 be 9a 89 ca
 00 24 ← "sal = ????"

ふむ。
REDOログは、10gであっても11gであっても、暗号化されていました。

********検証結果のまとめ********

１．10gR2 環境においてTDEで暗号化したカラムを更新(UPDATE)して
更新前後の値が参照可能か？
→ ”参照できない”
２．11g 環境においてTDEで暗号化したカラムを更新(UPDATE)する
更新前後の値がみられるか？
→ ”参照できる”
３．REDOダンプの中身はどうなっているか？
→ 10gR2、11gともにencrypt指定カラムの値は暗号化されていた

やはり、TDEを使用してデータを暗号化すると、10gまではLogMinerではデータ
が参照できなかったが11gでは参照できるようになってます。
ふむふむ・・・マニュアル通りである。

今回は、データが暗号化されている場合であってもLogMinerを使用してどこま
で「LogMiner監査」ができるのか？を確認しました。11gで対応されたという
事実から推測すると、データが暗号化されているからといってもLogMinerを使
用するのであればデータはその変更内容は確認できるようになったほうがよい
ということですねー、ふ～～～～ん。
ただ、裏を返すとデータベースのバージョンでできる事とできないことがある
ということで、正直少し気を使いマスますね・・・。

現実として、「暗号化 + LogMiner 監査」って、Too Much、なかなかここまで
凝った対策を施す企業様はいないでしょう。

やはり、データベースセキュリティはリスク・オリエンティッドで検討したほ
うが良いということでしょうか。

2007年は、さまざまな法令に合わせたデータベースセキュリティ製品が人気を
博しました。その中でも僭越ではありますが弊社PISOは大健闘！
パチ！パチ！！パチ！！！
茅ケ崎にある開発部隊に感謝し、パートナー様へ感謝し、お客様へ感謝して
今年を締めくくりたいと思います。

ありがとうございましたっ！！。

あっという間に一年が過ぎた茅ヶ崎より

Oracle 11g 暗号化 + 監査