Pick Upテクノロジー

データベース・セキュリティの実装　第2回　ログの取得と監査設計のポイント 連載の1回目では、アクセスコントロールと権限管理について取り上げた。今回は想定外のアクセスがなく適切な権限管理ができているかを確認し、また万が一の事故発生時には事故原因を究明するために利用するログと監査について取り上げる。

■監査の意義

一般的に監査は以下の目的で実施される。

  • 権限管理の実装に関する問題の検出
  • 不審なアクティビティの調査・検出
  • 不正行為をおこなっていない証明
  • 不正行為の未然予防(心理的障壁)
  • コンプライアンス要件への対応(監査レポート提出など)
　

監査というと不正をチェックするものとの認識が多いと思うが、その他にも管理者や社員の身の潔白を証明するためにも利用できる。とくに大きな権限を持つ管理者は、Database Vaultなどを利用した管理者自身の権限の制限(厳格な職務分掌)をおこない、かつ整合性が確保された監査証跡を残す必要がある。 Oracle

Databaseでは、監査機能、標準監査、ファイングレイン監査、DBA監査という3つの監査機能を提供している。まずはこの3つの監査の特徴とTIPSを紹介する。詳細な設定方法に関しては、それぞれのリンク先を確認してほしい。

■標準監査

標準監査は指定した操作が実行された際に証跡を出力する。表へのアクセスの他にも、データベースへのログイン、表などのオブジェクトの構成変更、権限管理の実施など様々なデータベース操作に対して監査を設定することが可能だ。監査可能な操作は「SQL言語リファレンス」マニュアルのAUDITコマンドにまとまっている。 標準監査の監査証跡の出力先はAUDIT_TRAIL初期化パラメータで設定し、OSファイルやデータベース表(SYS.AUD$表)を指定できる。出力先にOSファイルを指定した場合には、AUDIT_FILE_DEST初期化パラメータで指定したディレクトリに出力される。

監査証跡の出力先として、データベース表を指定したほうが管理は容易だが、OSファイルに監査証跡を格納したほうが監査処理のオーバーヘッドが少なく、またデータベースへの権限ではないOSファイルへのアクセス権限が必要になるためより安全と言える。

Oracle Database 11gR1以降では、DBCA(Database Configuration Assistant)でデータベースを作成すると、デフォルトでいくつかの標準監査が有効になるように変更された。詳細は「セキュリティ・ガイド」マニュアルのデフォルトの監査設定の概要にある。

権限付与やデータベースオブジェクトの構成変更など、実行回数が多くなく、問題発生時に後から問題発生原因を突き止めるのに非常に有効な監査設定が有効になる。だたし、ログイン監査など、システムによっては大量の監査証跡が生成される可能性がある監査もあるため、どのような監査が有効になっているかを確認し、パフォーマンスや利用領域に影響が大きいと判断した監査に関しては個別に無効化してほしい。

Oracle Database 11gR1までは監査証跡を格納するSYS.AUD$表をSYSTEM表領域から移動することはできないが、Oracle Database 11gR2では、DBMS_AUDIT_MGMTパッケージを利用して、SYS.AUD$表を他の表領域に移動できる。監査証跡表を自動セグメント領域管理の表領域に移動することで、バッファビジーやキャッシュフュージョンによる待機を軽減可能であるため、該当バージョン利用の場合にはぜひ利用してほしい。

■ファイングレイン監査

ファイングレイン監査は指定した条件のデータに実際にアクセスがあった際に証跡を出力する。ファイングレイン監査はSELECT・INSERT・UPDATE・DELETEに対してのみしか設定ができないが、監査対象として表名だけではなく、列や条件の指定ができる。そのため、従業員表(表)の特定の部門の従業員(条件)の給与列(列)にアクセスがあった場合のみ監査するといった柔軟な設定が可能となり、不要な監査証跡の削減に役立つ。

また、監査証跡出力時にオプションで任意のアクションをプログラムできる。たとえば、監査証跡表をデフォルトとは別に作成して監査レコードを出力したり、SNMPやメールで管理者にアラートを上げたりすることが可能だ。

img_pickup_110414_01.jpg

ファイングレイン監査による詳細な監査設定

　ファイングレイン監査の監査証跡の出力先もOSファイルとデータベース表(SYS.FGA_LOG$表)を選択できる。ファイングレイン監査の設定をおこなうDBMS_FGAパッケージでパラメータとして出力先を指定する。出力先にOSファイルを指定した場合には、AUDIT_FILE_DEST初期化パラメータで指定したディレクトリに出力される。

ファイングレイン監査の監査証跡表もOracle Database 11gR2では、DBMS_AUDIT_MGMTパッケージを利用することで他の表領域に移動できる。監査証跡表を自動セグメント領域管理の表領域に移動することで、バッファビジーやキャッシュフュージョンによる待機を軽減可能であるため、該当バージョン利用の場合にはぜひ利用してほしい。

■DBA監査

Oracle DatabaseではSYSDBAおよびSYSOPER権限で接続したユーザーの接続、データベースの起動・停止に関して、必ずAUDIT_FILE_DEST初期化パラメータで指定した位置にログが出力される。このログ出力を停止することはできない。 さらにAUDIT_SYS_OPERATIONS初期化パラメータをTRUEに設定することで、SYSDBAおよびSYSOPER権限で接続したユーザーのすべての操作を監査しOSファイルに出力できる。この監査はDBA監査と呼ばれる。 なお、SYSユーザーによる操作は標準監査やファイングレイン監査の監査証跡には残らない。そのため、SYSユーザーを監査するためにはこのDBA監査が必須となる。

■アプリケーション・コンテキストの利用

WEBアプリケーションサーバーなど現在多くのシステムで利用されている、3層構造のアプリケーションでは、コネクションプールや代表ユーザーを利用するため、アプリケーションを利用している実際に利用者情報がデータベースから把握できず、データベースで監査をとっても実際に誰がそのSQL文を発行したかわからないことがある。

Oracle Databaseでは、接続ごとにアプリケーションが任意の値を設定できるメモリ空間を定義できる。このメモリ空間はアプリケーション・コンテキストと呼ばれる。アプリケーション・コンテキストはアプリケーション開発者が独自に定義することもできるが、Oracleでは事前定義のアプリケーション・コンテキストを用意しており、その一つにCLIENT_IDENTIFIER属性がある。このCLIENT_IDENTIFIERに設定された値はすべての監査の監査証跡に含まれるため、アプリケーションはここに実際の利用者情報を格納しておくことで、データベースで実施した監査に実際の利用者情報を含めることができる。

img_pickup_110414_02.jpg

CLIENT_IDENTIFIER属性を利用したアプリケーションユーザーの監査

　たとえば、コネクションプールを利用しているJAVAのアプリケーションを利用している場合、アプリケーションがデータベース処理をおこなうためにコネクションプールからコネクションを獲得するメソッドの中にCLIENT_IDENTIFIERを設定する命令を1行追加するだけで監査証跡にアプリケーションユーザーを含めることができる。

アプリケーションサーバーを利用している場合、アプリケーションサーバーのコネクションプール設定画面からコネクション獲得時の追加処理としてアプリケーションユーザー名をCLIENT_IDENTIFIERにセットする処理を追加するだけでアプリケーション側には全く手を加えずに設定できる。 CLIENT_IDENTIFERは、PL/SQL、Oracle Call Interface(OCI)およびJDBCドライバを利用して設定できる。詳細は「セキュリティ・ガイド」マニュアルのデータベースに認識されないアプリケーションユーザーの識別でのクライアント識別子の使用を参照してほしい。

Oracle Databaseには、いままでに紹介した監査機能のほかにもデータの変更履歴を後から確認できる機能がある。変更履歴を確認することで、監査証跡だけからは分からない実際のデータの値の変化を確認することができる。今回は更新履歴を後から確認できる機能として、LogMinerとTotal Recallを紹介する。

■LogMiner

Oracle Databaseでは、REDOログ(オンラインREDOログ、アーカイブREDOログ)にデータベースに対するすべての変更履歴を格納している。LogMinerはこのREDOログを分析し、発行されたSQL文と同じ変更が適用されるSQL文(SQL_REDO)と、適用した変更をロールバックするためのSQL文(SQL_UNDO)を取得する機能だ。LogMinerは既存のREDOログの仕組みを利用しているため、変更データの保存に別の領域を確保する必要がない。通常、本番システムのデータベースはリカバリのためアーカイブログモードで運用されるので、バックアップ要件に従ってある程度過去までのアーカイブログファイルが保存されているが、アーカイブログが保存されている限り、過去の変更を確認できる非常に便利な機能だ。

img_pickup_110414_03.jpg

LogMinerを利用した変更履歴の確認

　ただし、デフォルトの状態ではLogMiner機能は利用できず、事前にサプリメンタルロギングを有効化する必要がある。サプリメンタルロギングを有効化すると生成されるREDOログ量が多少増えるが、性能や物理容量に大きな影響はないため、アーカイブログを長期間保存しているシステムでは、LogMinerを利用するためにサプリメンタルロギングをあらかじめ有効にしておくことを考慮いただきたい。 LogMinerの設定方法は「ユーティリティ」マニュアルのREDOログ・ファイル分析のためのLogMinerの使用を参照してほしい。

■Total Recall

Oracle Databaseでは、フラッシュバック問合せという過去のある時点のデータに対して検索する機能がある。これはUNDO表領域に格納された履歴データを利用して過去の表データを再現する機能で、簡単に過去のデータを確認することができる。また、特定のレコードの変更履歴を確認するフラッシュバック・バージョン問合せという機能もある。ただし、どちらもUNDO表領域にUNDOデータが残っていることが前提条件であり、UNDOデタの保持期間はUNDO_RETENTION初期化パラメータで調整できるものの、デフォルトでは900秒と長期間データを残しておくことは考慮されていない。 Total Recallでは、指定した表のみのUNDOデータを別領域に書き出すことで、このフラッシュバック問合せを数年間という単位で実現する機能だ。

img_pickup_110414_04.jpg

Total Recallを利用した過去データの検索

　たとえば情報流出事故が発生した場合、監査を取得していればいつどんなSQL文によって流出が起こったかは分かるが、実際に流出したデータは分からない。Total Recallのフラッシュバック問合せを利用すればSQLが発行された時点でのデータでのSQL実行を再現できるので、データの流出範囲を特定できる。 変更履歴はパーティション化され圧縮されてデータベース内に格納される。そのため管理の手間がなく、また内部的に自動管理されているため、変更履歴を改ざんできない。 フラッシュバック問合せとTotal Recallの利用方法は「アドバンスト・アプリケーション開発者ガイド」マニュアルのOracle Flashback Technologyの使用を参照してほしい。

■監査設計のポイント

監査を実施すると性能が出ない、という話をよく聞く。片やいかに処理を速くするかと必死にチューニングする一方で、処理性能に影響を与える監査は必要と思っていても実施できないこともあるだろう。だたし、これは監査の目的を考えず「とりあえず何かあった時のためにすべてのアクセスログを残しておこう」と漠然としか監査について考慮されていないだけであって、通常の業務処理と同様、監査についても適切に設計がなされていれば性能への影響は無視できるレベルにできる。 監査設計の肝は、「監査対象の設計」と「監査証跡の設計」だ。

■監査対象の設計

監査対象の設計では、とりあえずすべてのアクセスを監査したい、という過ちが多い。本当に必要な監査は何なのかを理解する必要がある。一般的にアプリケーションが発行するSQL文に関しては監査の必要性は低い。アプリケーションが発行するSQL文のうち監査の必要がある可能性があるのは、個人情報、会計情報などの個人情報保護法、J-SOX法などのコンプライアンス対応に必要な情報と機密情報に対するアクセスだ。すべてのSQL文に監査を設定することは、無駄な監査証跡が増え、後からの解析が煩雑になるという欠点もある。

逆に管理操作などの非定形SQL文は監査の必要性が高い。ユーザーやオブジェクト定義の変更、権限設定などデータベースやアプリケーション管理者の操作は構成変更管理の観点からも監査すべきだ。Oracle Database 11gR1以降のデフォルト監査設定は、この構成変更操作に対しての監査が有効化されているのが確認できる。

■監査証跡の設定

監査の性能は監査証跡の出力先でも変わる。具体的には監査証跡の出力先をOSファイル(OS、XMLとも)にしたほうが、データベース内の監査証跡表を利用するよりも性能への影響は少ない。また、管理の容易性を優先して出力先を監査証跡表にする場合には、11gR2以降ではDBMS_AUDIT_MGMTパッケージを利用して、監査証跡表(SYS.AUD$およびSYS.FGA_LOG$)表の出力先をSYSTEM以外の表領域に移動してほしい。データブロックの空き領域管理がフリーリスト管理であるSYSTEM表領域から、自動セグメント領域管理である他の領域に移動することで同時実行性が向上し、とくにRAC環境では監査証跡レコードの同じブロックに対する同時挿入によるキャッシュフュージョンが起こりにくくなる。 DBMS_AUDIT_MGMTパッケージにはほかにも古い監査証跡の自動削除やOS監査証跡ファイル分割サイズの指定などができるため、監査証跡の管理のために有効活用してほしい。

このほかにも監査に利用できる製品として、Oracle Net通信をモニタリング、さらにはブロッキングできるOracle Database Firewallがあるが、これは最終回に紹介する。その前に次回はデータの暗号化とハードウェアを利用したその高速化を取り上げるのでご期待いただきたい。

■関連資料