後編

Oracleセキュリティと性能劣化のトレードオフは？

アシスト
伊藤 佳
2006/7/26

暗号化実装時のパフォーマンスへの影響

　では、これら暗号化の機能を実装することによって、Oracleではどの程度パフォーマンスに影響を与えるのか、各暗号化方式を比較しながら検証結果を見てみます（図2）。

図2　暗号化方式ごとの秒間スループット 　N           ：暗号化しない 　DES       ：DBMS_OBFUSCATION_TOOLKITのTriple-DES 3key 　TDE_DES：TDEのTriple-DES 　TDE_AES：TDEのAdvanced Encryption Standard 　100        ：同時接続セッション数：100 　200        ：同時接続セッション数：200

　図2の暗号化方式ごとの秒間スループットを比較すると、DBMS_OBFUSCATION_TOOLKITパッケージを利用した場合には、スループットが低下していることを確認できます。しかし、TDEを利用した場合にはスループットにあまり影響を与えていないことが分かりました。また同じTDEでも、暗号化アルゴリズムをDESからAESにした場合には、より効率よく暗号化／復号処理を実施できていることが分かります。同時ユーザー数が増加した場合には、パッケージを利用した実装とTDEによる実装で、その差がより顕著になりました（図3）。

図3　暗号化方式ごとのユーザーCPUリソースの使用率

　図3の暗号化方式ごとのCPUリソース使用率でも、TDEで暗号化アルゴリズムをAESにした場合に、最もCPUリソースに影響を与えないことを確認できました。また、複数ノードのCPUで処理を分散できるReal Application Clusters（RAC）構成の方がシングルインスタンスと比べ、暗号化による影響が現れにくいという結果となりました。

　パッケージを利用した実装の場合、暗号化／復号の処理において毎回パッケージを呼び出す動作が行われるため、CPUやスループットに大きな影響があることが分かります。一方のTDEを利用する場合は、パッケージによる実装時ほどのスループットやCPUへの影響は見られません。サーバプロセスが暗号化／復号の処理を行うため、データベースに対する負荷は低い動作であることが分かりました。TDEが登場したことによって暗号化の実装に対する敷居は低くなり、格納データの暗号化はより現実味を帯びてきたのではないかと思われます。

Oracleの監査機能

　次に、データベースの監査機能を確認してみましょう。アプリケーション経由でアクセスするアプリケーション・ユーザーはアプリケーション側でログを取得することで監視することはできますが、アプリケーション開発、データベース管理、システム管理などの権限を持ったユーザーはアプリケーションを介さないでデータベースにアクセスすることができます。データベースには価値の高いデータが格納されており、情報漏えいの多くが内部の悪意のあるユーザーによる犯行であることを考えると、データベースにアクセスする「誰が」「どの」データに対して、「いつ」「どのような」アクセスを、「どこ」の端末から行ったのかをアクセスログとして管理することが重要であると思われます。

　Oracleでは、以下のような監査機能が用意されています。

• 必須監査
  管理者権限によるインスタンスへの接続や起動・停止を監査

• DBA監査
  SYSユーザーでのセッションを監査

• 標準監査
  特定の監査に対して取得される監査

• ファイングレイン監査
  標準監査よりも細かな監査、イベントハンドラにより独自ルールでの監査を実装

• イベントトリガー
  DML実行時にプロシージャが起動し監査を実施

• LogMiner
  データベースに対する変更履歴をSQLに変換し、事後監査を行う

　Oracle 10gから標準監査でSQLを取得できるようになり、ユーザーの操作をより細かく監査ログとして保持できるようになりました。Oracle9iから提供されたファイングレイン監査（FGA）では、標準監査よりもより細かな行や列レベルでの監査条件を設定できます。さらにイベントハンドラの機能により、指定した条件の監査が行われたときに任意の処理を実行できるため、独自の監査証跡への監査情報の出力や、管理者への警告メールの送信機能を実装することができます。

　では、各監査の実装時のスループットやCPUへの影響度合いを検証結果から見ていきます（図4、図5）。

図4　監査方式ごとの秒間スループット NORMAL：監査なし AUDIT DB：標準監査 　 全表の全アクションに対する監査 AUDIT EXT：標準監査 　 AUDIT_TRAIL：DB_EXTENDED 　 全表の全アクションに対する監査 FGA ALL：ファイングレイン監査 　 全表の全アクションに対する監査 FGA SELECT：ファイングレイン監査 　 監査する表を限定しSELECTのみ監査 FGA EVENT：ファイングレイン監査 　 FGA SELECTに加え、イベントプロシージャで 　 独自表に監査ログを保存 FGA TRIGGER 　 FGA SELECTに加え、DMLトリガーでDML監査を実施

図5　監査方式ごとの平均CPU使用率

　図4および図5から各監査機能の影響度合いを見てみると、SQLの情報を取得する監査の方がSQLの情報を取得しない監査と比べ、秒間スループット、CPU使用率ともに影響を与えることが分かりました。また、監査証跡に監査情報を格納するための再帰SQLが増加したり、SQL文の収集で一時表領域が利用されるなど、SQLを取得しない場合と比べより多くのリソースを必要とします。

　不正アクセスや情報漏えいの監査に備え、SQL文のレベルまで特定できる監査を実施することを考えると、より多くの情報を取得できることが望ましいといえますが、より多くのリソースが必要となるため既存のシステムに設定することは困難な場合が多く、また、監査証跡の保管方法や分析方法、あるいは複数バージョン、エディションが混在する環境で効果的に監査を行う場合には、Oracleの監査機能だけで監査を実施することに限界も感じられます。そこで、サードベンダ製の監査ソフトを導入し、バージョンやエディションの違いを吸収することも検討します。

2/3

Index
特集：日本版SOX法時代のOracleセキュリティ（後編） 　Oracleセキュリティと性能劣化のトレードオフは？
	Page 1 ・Oracleとセキュリティの守備範囲 ・格納データの暗号化
	Page 2 ・暗号化実装時のパフォーマンスへの影響 ・Oracleの監査機能
	Page 3 ・可及的な監査を行うには？

日本版SOX法時代のOracleセキュリティ

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）