TOP>企業情報>コラム>技術情報>移行前に知っておきたい、Oracle Database 12c新機能のオモテとウラ Vol.5

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

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

Vol.5 現場も納得の“手軽な”セキュリティ機能で情報を守る


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

豊富なセキュリティ機能からどれを選択するか


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

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

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

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

Oracle Databaseの代表的なセキュリティ製品(機能)
カテゴリ 製品または機能名 概要
暗号化、マスキング Oracle Advanced Security Oracle Database Enterprise Edition(以下、EE)のオプション。透過的データ暗号化(TDE)とOracle Data Redactionで構成される。Oracle Database 11g(以下、11g)まではネットワーク暗号化も含まれていたが、12cから標準機能となった。
Oracle Data Redaction 12cで追加されたOracle Advanced Securityの新機能。格納データに手を加えず、リアルタイムにデータをマスキングできる。
Oracle Data Masking Pack EEのオプション。本番データを不可逆な形式でテスト用にマスキングできる。
アクセス制御、職務分掌 Oracle Database Vault EEのオプション。管理者ユーザを含むアクセス制御により、職務分掌を実現できる。
監査 必須監査、DBA監査
標準監査、ファイングレイン監査
Oracle Databaseの標準機能。4種類あり、それぞれ監査対象や監査ログの出力場所が異なる。12cからは従来型監査と呼ばれている。ファイングレイン監査のみEEの標準機能。
統合監査(Unified Auditing) 12cで追加された標準機能。ポリシーベースのアーキテクチャを採用し、監査ログを一元化。Data PumpやRecovery Manager(以下、RMAN)の操作も対象にできる。
Oracle Audit Vault and
Database Firewall
SQLのモニタリングとブロッキングを行うソフトウェア・アプライアンス。SQLインジェクションによる情報漏えいを防げる。MySQL、Sybase SQL Anywhere、Microsoft SQL Server、IBM DB2にも対応。

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

Oracle Data Redactionの基本動作と実装上の注意点


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

Oracle Data Redactionの動作イメージ

Oracle Data Redactionの動作イメージ

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

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

Oracle Data Redactionのマスキング・パターン
パターン 動作
FULL
(フル・リダクション)
データ型に応じて任意の値を返す。
デフォルトでは以下の値を返す。
・文字列型 → シングル・スペース
・数値型 → ゼロ(0)
・日付型 → 01-JAN-01
・LOB型 → [redacted]
RANDOM
(ランダム・リダクション)
データ型に応じてランダム値を返す。
・文字列型 → ランダム文字
・数値型 → ランダム数値
・日付型 → ランダム日付
・LOB型 → 使用不可
PARTIAL
(部分リダクション)
データ型に応じて部分的に任意の値を返す
・文字列型 → 部分的に任意の文字列
・数値型 → 部分的に任意の数値
・日付型 → 部分的に任意の日付
・LOB型 → 使用不可
REGEX
(正規表現リダクション)
正規表現を使用して任意の値を返す。

かなり手軽に実装できる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の性能検証


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

Oracle Data Redactionの性能検証方法

Oracle Data Redactionの性能検証方法

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

マスキング・パターン別の応答時間

マスキング・パターン別の応答時間

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

マスキング・パターン別のCPU Time

マスキング・パターン別のCPU Time

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

仕組みを一新した12cの統合監査


Oracle Databaseは標準機能として「必須監査」、「DBA監査」、「標準監査」、「ファイングレイン監査」の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のオプティマイザについて解説します。


執筆者紹介

関 俊洋(Toshihiro Seki)

株式会社アシスト データベース技術本部

2006年、株式会社アシスト入社。データベース・システムの構築や運用トラブルの解決といったフィールド・サポート業務を経験し、その後は新製品の検証やハードウェアとデータベースを組み合わせたソリューション(DODAI)の立ち上げに従事。現在はデータベースの価値や魅力を伝えるための執筆・講演活動を行っている。『SQL逆引き大全363の極意』共著。

関の紹介記事はこちら

「移行前に知っておきたい、Oracle Database 12c新機能のオモテとウラ」
連載記事一覧

オンライン・セミナー続々公開中!

アシストでは、全国どこからでも好きな時間に参加できるOracle Databaseのオンライン・セミナーを開催しています。アーキテクチャの基礎からEnterprise Managerやバックアップなどの運用テクニック、12cやアプライアンスといった最新情報まで20種類以上のコンテンツを用意しています。便利なオンライン・セミナーに是非ご参加ください。

関連製品


Facebookで情報をお届けしています

Facebookでは、アシストの「今」を週3回のペースでお届けしています。「めげない、逃げない、あまり儲けない」を合言葉に日々頑張っておりますので、応援よろしくお願いします。



ページの先頭へ戻る