移行前に知っておきたい、Oracle Database 12c新機能のオモテとウラ Vol.5

前回はOracle Database 12c（以下、12c）のReal Application Clusters（RAC）とASM（自動ストレージ管理）について解説しました。今回はセキュリティ関連の新機能について検証結果を紹介します。

※セキュリティ関連の新機能概要は「連載：徹底解説！Oracle Database 12cのすべて」の中で解説していますので、併せてご参照ください。

セキュリティ関連の事件は2014年になってもいっこうに減る気配を見せず、不正ログインや個人情報の流出といったニュースが毎週のように取り上げられています。手口も巧妙かつ多様化しており、内部犯行や外部からの大規模なサイバー攻撃など、企業にとって数多くのリスクが潜む時代になりました。

さらに最近では、あまりにも事件が多すぎて1つひとつの事件があっという間に風化してしまい、どこに原因があったのか、どのような対策を講じたのかといった情報が広く伝わりにくくなっているような傾向も見受けられます。他社で発生した事件を教訓にセキュリティを見直すことも必要ですが、それに頼ることなく自らセキュリティを見直す努力も今後は必要になるでしょう。

とは言え、現場からするとセキュリティ対策にはどうしてもネガティブなイメージがあります。「運用が大変になる」、「セキュリティ製品を新しく買わないといけない」、「動作が重くなる」など、導入に関して慎重な意見が多く聞こえてきます。これらの意見が間違っているわけではありませんが、Oracle Databaseではバージョンを重ねるごとに多くのセキュリティ新機能が実装され、パフォーマンスも良くなっていますので、最新の情報をもとに検討することで「これなら実装できそうだ」という機能が見つけられると思います。

以下の表は、Oracle Databaseの代表的なセキュリティ製品（機能）です。12cではOracle Data Redactionと統合監査（Unified Auditing）が新しく追加されました。

このように、Oracle Databaseのセキュリティ対策には様々なアプローチがあります。最初からすべてを実装しようとすると検討範囲が広くなりすぎるので、まずは守るべき情報を明確にし、優先順位をつけた上で機能を取捨選択していくことが重要です。当然ながら、検討にあたっては基本動作や運用方法、性能への影響度といった情報が必要になりますので、今回は12cの新機能であるOracle　Data　Redactionと統合監査（Unified Auditing）が本当に使える機能なのかを詳しく解説していきます。

12cの新機能であるOracle Data Redactionは、格納されているデータやアプリケーションに一切変更を加えず、リアルタイムにデータをマスキング（リダクション）できる機能です。以下のように、SELECT結果の特定列だけがマスキングされた状態で表示されます。

これまでは、Oracle Data Redactionのようにデータベース側でマスキングを行う機能がなかったため、アプリケーション側での作り込みが必要でした。上記のようなシンプルな処理であれば簡単に実装できるように思えますが、アプリケーションを経由した場合しかマスキングされないため、開発ツールや運用管理ツールからはデータが閲覧できてしまうという課題がありました。Oracle Data Redactionでは、データベース側で設定したポリシーに基づいてマスキングを行うため、アプリケーション以外からのアクセスであっても漏れなくデータを保護することができます。

マスキングのパターンも豊富で、電話番号の場合は「000-0000-0000」のようにゼロで充填したり、カード番号やパスワードの場合は「****」のように置き換えることができます。マスキング前のデータ型と桁数にしたがって表示できるので、画面の表示幅などを気にする必要はありません。マスキングの設定はOracle Enterprise Managerまたはコマンド・ラインから簡単に行うことができます。

かなり手軽に実装できるOracle Data Redactionですが、以下のような注意点がありますので、影響を受ける処理がないか事前に洗い出しておくことが必要です。

①マスキング対象外となるユーザが存在する

SQLを発行したのがSYSユーザであったり、DBAロールやEXEMPT REDACTION POLICY権限を付与されたユーザの場合は、マスキングが行われません。マスキングだけに頼るのではなく、適切な権限管理を行うことがセキュリティにおいては重要です。SYSユーザのアクセスを制御したい場合は、Oracle Database Vaultを組み合わせて使用します。

②表から派生するビューもマスキング対象となる

マスキングの設定は表に対して行いますが、その表から派生したビューもマスキング対象になります。思わぬところでマスキングされてしまわないよう、設定後は動作確認が必要です。なお、マテリアライズド・ビューを作成／リフレッシュする場合はマスキングされません。

③マスキング対象外となる操作がある

Export/Importやデータベースのバックアップ、リストアなどの操作はマスキングされません。こうしたSQLではないデータベースの操作に関しては、OSレベルで適切な認証を行うことが必要です。Oracle Advanced Securityを組み合わせて使用すれば、これらの操作でも暗号化を行うことができます。

上記3つの注意点をクリアできれば、Oracle Data Redactionの効果を期待できる状態にあると言えます。繰り返しになりますが、マスキングは数あるセキュリティ対策の1つでしかないため 、あらゆるケースに対応できるわけではありません。守るべき情報を明確にし、マスキングで対応できる範囲を見極めた上で使用する必要があります。

Oracle Data Redactionによるリアルタイムなマスキングは、SQL 1つひとつが対象になりますので、マスキングされた場合とそうでない場合で性能（応答時間）にどの程度違いが出るのかが気になるところです。そこで今回は、単一表に対する全件検索において、マスキングのパターン別の応答時間を比較してみます。

以下のグラフが検証結果です。Oracle Data Redactionを使用しない場合と比べて、Fullの場合は応答時間がわずかに短く、Randomの場合はほとんど変わらないという結果になっています。体感ではほとんど分からないレベルなので、性能面で心配する必要はないと言えます。注意すべきはRegExpで、グラフに収まらないほど応答時間が長くなっています。現時点では、できるだけFullまたはRandomを使用するのが望ましいと言えます。

応答時間についてはマスキングなしとRandomの場合でほとんど差がありませんでしたが、以下のようにデータベースがCPUを使用した時間（CPU Time）で比較してみると、両者の違いがはっきりと分かります。マスキングなしと比べてRandomのほうがCPU Timeが長く、ランダムな値の生成に多少負荷がかかっています。CPUリソースに余裕がある場合は問題ありませんが、大量のセッションからSELECTを行う場合は多少注意が必要です。

検証の結果、Oracle Data Redactionは手軽に実装できるだけではなく、性能的にも優れていることが確認できました。性能要件が厳しいシステムにも十分対応でき、セキュリティを実装すると性能が落ちるというこれまでのイメージを変えてくれる機能です。12cだけではなく11gR2のターミナル・リリースである11.2.0.4.0にもバックポートされていますので、今すぐ12cにバージョンアップできないという場合でも使用できます。

Oracle Databaseは標準機能として「必須監査」、「ＤＢＡ監査」、「標準監査」、「ファイングレイン監査」の4つをサポートしていますが（12cでは「従来型監査」と呼ばれている）、監査ログがOS上にファイルとして出力されたり、データベース内の表に格納されたりと管理面で課題がありました。12cでは監査の仕組みを一新し、統合監査（Unified Auditing）という監査ログを一元化管理できる機能が実装されています。

統合監査を使えば、SQLだけではなくRMANやData Pumpといったユーティリティのログまで取得でき、さらにそれらをUNIFIED_AUDIT_TRAILビューで一元的に管理／参照できます。データベースがクローズしていた場合でも、ユーティリティのログがOS上に残されるようになっているため、データベースがオープンした後でログをインポートすることができます。

また、監査の設定も非常に分かりやすいものに変更されており、「IPアドレスが○○の場合」や「OSユーザが☓☓の場合」といった監査条件をOracle Enterprise Managerまたはコマンド・ラインから設定することができます。あらかじめ用意されているデフォルト・ポリシーも豊富なため、それほど難しい知識は必要とせずに使い始めることができます。

さらに特筆すべきは、非同期書込みが選択できるようになっていることです。従来型の監査では同期書込みしかサポートされていなかったため、監査ログが書かれるまでSQLが完了せず、十分な性能が出ないこともありましたが、非同期書込みではSGA内のキューに監査ログを保存してから後で書き出すため、素早くSQLの応答を返すことができるようになっています。続いては、この非同期書込みによってどれほど性能に影響が出るのかを検証してみます。

以下のグラフが検証結果です。左から順に見ていくと、監査設定なしの性能が当然ながら最も良く、従来型監査では同期書込みによる影響を受けて10%ほど数値が下がっています。統合監査の非同期書込みではこのオーバーヘッドが解消され、従来型監査よりも数値が上がるという結果になりました。監査設定なしと比べても、ほとんど性能差はありません。注意すべきは統合監査の同期書込みで、他のパターンと比べて数値に大きく差が出ています。非同期書込みがデフォルトなので明示的に指定しない限り使われることはありませんが、どうしても使用したい場合は性能検証が必要です。

統合監査で出力されるログのサイズは、10,000レコードで8MB程度です。すべてSYSAUX表領域内に出力されるため、表領域の自動拡張を有効にするなど、領域が枯渇しないように余裕を持たせておくのが良いでしょう。

今回検証したOracle Data Redactionと統合監査は、ともに性能面でのオーバーヘッドがほとんどなく設定も簡単であるため、数あるセキュリティ機能の中でも導入にあたっての敷居は低いと言えます。これからデータベースのセキュリティを検討したり見直しを行う場合は、こうした新機能の採用も視野に入れてはいかがでしょうか。

次回は12cのオプティマイザについて解説します。

・移行前に知っておきたい、Oracle Database 12c新機能のオモテとウラ Vol.1
・移行前に知っておきたい、Oracle Database 12c新機能のオモテとウラ Vol.2
・移行前に知っておきたい、Oracle Database 12c新機能のオモテとウラ Vol.3
・移行前に知っておきたい、Oracle Database 12c新機能のオモテとウラ Vol.4
・移行前に知っておきたい、Oracle Database 12c新機能のオモテとウラ Vol.6
・移行前に知っておきたい、Oracle Database 12c新機能のオモテとウラ Vol.7

最後までご覧いただきありがとうございました。
本記事でご紹介した製品・サービスに関するコンテンツをご用意しています。また、この記事の他にも、IT技術情報に関する執筆記事を多数公開しておりますのでぜひご覧ください。