導入事例

活用事例と検証からみる AUDIT MASTERによるデータベース監査の実践

データベース監査に対応されたお客様事例から、データベース監査実務において何が要求され、AUDIT MASTER でどのように対応してきたかを紹介します。

データベース操作ログの統合管理により全社レベルでのガバナンス強化に貢献

国内大手の損害保険会社様事例から

金融庁監査指針に耐えられるよう、100台を超えるデータベースサーバのセキュリティ、監査ログの統合管理、モニタリングを実現

金融庁ガイドラインであるFISC (金融機関等コンピュータシステムの安全対策基準・解説書) にのっとり、データベース操作の管理、モニタリングは必須とされています。そのため、OracleデータベースのAudit機能を使って操作ログを取得するよう標準化されていました。 しかし、多数のデータベースがあり、複数のベンダーに管理を委託され、データベース操作ログの取得、ログ管理をベンダーに依存していたことで、統制が取れているとは言えない状態にありました。また、出力された操作ログの管理をそれぞれのデータベースでバッチプログラムを作り込んで実施しており、非効率でした。
課題は「操作ログのモニタリング・監査を自社にて一元的に行う」こと。
Oracle標準の機能を使うことで漏れなく操作ログを取得することを前提に、多数のデータベースの一元管理、ログ管理を自動的に行うことのできるツールを導入する、という方針の下、いくつかの製品を比較検討され、選定いただいたのがAUDIT MASTERでした。

なぜOracle Audit 機能を使うのか

データベースの操作ログを取得する手段として、ネットワークを流れるパケットをキャプチャリングする方法、メモリ上のSQL文を参照取得する方法といった、製品独自の方法ではなく、データベースが標準で提供しているAudit (監査) 機能を使うことが必須とされていました。
数多くのデータベースにエージェントやネットワーク製品を導入し個別に設定するといったことは困難ですし管理上も望ましくありません。なにより、どのような利用パターンでも操作ログを漏れなく取得できるのはAudit機能だけです。 Oracle標準のAudit機能を利用する以外に選択肢はありませんでした。

AUDIT MASTER選択の経緯

課題である「操作ログのモニタリング・監査を自社にて一元的に行う」ことを実現するために、最適な製品を導入することを目指しました。
選定のポイントは、一元管理を行うための、複数のデータベースの操作ログ出力設定やログ収集、レポート出力などを、データベース毎ではなく製品側で容易に実施できることです。
加えて、国内のミッションクリティカル環境での実績と、継続してデータベース監査を支援できるサポート力が求められました。
比較検討されたのは、国内でも実績が多くあった海外製品とAUDIT MASTERでした。
AUDIT MASTERの操作画面は直観的に利用でき、対象とする操作を選択するだけでログ出力設定 (ポリシー設定) ができます。テンプレート化した設定をインポートすれば、標準的なルールを多くのデータベースに対して容易に適用できます。
強力なレポーティング機能が製品標準機能として提供されているので、ポリシー設定と同様、定型パターンを各データベースに容易に適用することができます。
多数のデータベースに対して短期間、低コストで導入することが可能であり、お客様自身で問題なく運用できるようシンプルに作り込まれた操作性の良さが大きな理由となり、採用に至りました。
コンサルティングまで提供できるサービスラインナップの豊富さ、国内で長年データベースに特化して蓄積したミッションクリティカル環境への知見、サポート力にも、長く支援を任せられる会社として魅力を感じていただきました。

AUDIT MASTER導入の実際と効果

AUDIT MASTERの導入は、

  1. 製品のインストール
  2. 対象データベース初期化パラメータの設定・データベース再起動
  3. 対象データベースを製品に登録 (接続設定)
  4. 操作ログ出力設定 (ポリシー設定)・適用、ログ確認
  5. レポート設定

という流れで行います。
今回は、既にAudit機能をご利用だったこともあり、2.の対象データベース初期化パラメータ設定・データベース再起動は必要ありませんでしたが、代わりに、実際にデータベースへの接続の情報や、どのように設定されているか、といった調査が必要で、各ベンターに調査票を送り記載してもらいました。ただ、実際に対象データベースを製品側に登録する際に、提供された情報が違っていることも多く、確認に多くの時間が必要となりました。
データベース監査の目的とは別に、お客様にとっては、今までベンダー任せでブラックボックスとなっていたデータベースの実態 (利用状況も含めて) を改めて確認、把握できるよい機会になったようです。
前述のように正確でなかった情報の確認を行いながらでしたが、3以降の作業を進め、週1~2日のペースで3ヶ月、正味1人月ほどで約100台のデータベースすべての設定対応が終了しました。
AUDIT MASTER導入によって、データベース監査システムの構成はこう変わりました。

お客様は、課題であった「操作ログのモニタリング・監査を自社にて一元的に行う」ことを実現し、ベンダーに依存しないデータベース管理を行われています。

性能にシビアな環境で実証、 データベース監査の負荷インパクトは0.4%

通信会社様導入前検証から

データベース監査機能の負荷への懸念から、本番環境のトランザクションを再現した環境で性能試験を実施した結果、そのインパクトはわずか0.4%、問題なしと判断

個人情報保護の観点からデータベースでの操作ログを取得する必要に迫られた通信会社様。2,000TPSのデータベースシステムで非常に性能要件がシビアな環境のため、操作ログ取得手法としてOracle標準のAudit機能を導入することには非常に懐疑的でした。
データベースのAudit機能は負荷が高いということがよく言われていますが、それは適切な設定をしていない条件下の”風評”であり、負荷は最適化できることをご説明し、本番相当のアクセスを再現した環境での負荷検証をご提案しました。お客様からのご要望でAudit機能に加え、メモリ参照手法の場合の負荷を、システム運用を担当する運用管理会社と一緒に検証することになりました。

採用すべき適正なAudit設定とは

Oracle標準のAudit機能は負荷が高い---その理由のほとんどは、操作ログ出力を行うAudit設定が不適切であるためです。
不適切な設定は、操作ログを取得すること=すべての操作のログを取得することという誤解から生じた設定をとられてしまうため引き起こされます。あるいは特にOracleデータベースではAudit設定がきめ細かく行えるため、マイナーなスキルであるAudit機能に精通していないエンジニアによって単純な設定がされてしまうということでも引き起こされます。例えばselect (レコード参照) 操作のログを出力する、という設定をすると、Oracleが内部処理で実行しているリカーシブルSQLのような意味のない操作ログを大量に出力させ、結果負荷が高くなってしまうのです。
そもそも、操作ログに必要のないものが大量に含まれてしまうことは、負荷の心配以前に可監査性の観点から問題です。せっかくログを取得したとしても、モニタリングできない量のものであれば、ログの価値が低下します。広大な砂漠から一粒の異なる色の砂を見つけるのではなく、その砂漠からすくったコップの中から見つけるようにすること。必要なものは逃さずに、いかにコップ容量を少なくできるか、それも重要なログの要件でしょう。
では適正なAudit設定とは何か。それは必要なログ”のみ”を取得する設定です。必要なログのみを取得するには、個人情報や、監査対象の財務会計情報など、まずは守るべき情報を特定し、それらに対する参照や更新操作を条件にして設定することが肝要です。また、不正なアクセスの試行(失敗操作)、ユーザーや権限に関わる操作、管理者の操作は対象いかんに関わらずすべて取得すべきです。
きめ細かなAudit設定が可能なOracleの場合、Enterprise Editionであれば、対象のテーブルやDBユーザー、プログラム、アクセス元のユーザーIPアドレス等を組み合わせた細かいログ条件を設定することができます。また操作ログをOSファイル出力にすることによって出力負荷は更に低減されます。
今回の検証では、対象がEnterprise Editionであったこともあり、細かな出力条件を設定する手法をとりました。セキュアにデータベースアクセスされることが確認されているアプリケーションからの操作はログ取得の必要がないということで、対象テーブルとプログラムを組み合わせた条件で、OSファイルに出力をすることになりました。取得が必要な操作ログを絞り込んでいった結果、監査対象となるテーブルに対する操作は全体の5%未満、その上でアプリケーションまで絞り込むと実際にログ出力される操作はさらに少なくなりました。

負荷検証の結果得られたもの

アクアシステムズの性能検証サービスを使った負荷検証では、本番で流れているSQLをキャプチャリングして、SQLのバリエーション、頻度を検証環境で再現した疑似本番環境を作り検証を行います。何も設定しない状態と比較して、Audit設定でログ取得をした場合、メモリ参照手法によるログ取得をした場合で負荷検証をしました。

検証方法

本番環境でキャプチャしたSQLを、検証機に対して同等の頻度で実行します。監査設定をなにもしない場合、Oracle標準の監査機能 (FGA/Audit) によるログ出力、メモリ参照形式によるログ取得の3パターンについて、データベース性能・負荷並びにログサイズ、取得件数(全件取得できているか)を検証しました。

検証仕様

実施方法
  • 本番機で実行されるSQLのうち、Program 名が所定のものは、3台のノートPCに設定したSQL負荷ツールから、計45セッションで同時実行。
  • ログ取得対象となるSQLは、SQL*Plus(Program 名SQL*Plus)から、計2セッションで同時実行。
テストパターン
  1. ウォームアップ
    テストトランザクションを30分以上流し続けてOSメモリ、Oracleキャッシュ状態を安定させます。スループットが本番機同等で安定していることを確認。テストトランザクションは、これ以降の試験期間中、同じ頻度で流し続けることとします。
  2. 通常性能試験
    監査ログ取得設定なしでの性能を測定する。監査設定後の性能と比較する基準とします。
  3. 標準監査性能試験
    Oracle標準の監査機能 (FGA/Audit) によるログ出力設定を行って性能を測定。
  4. メモリ参照監査性能試験
    メモリ参照形式によるログ取得設定を行って性能を測定。
検証結果
  • CPU使用率
    (A) 監査ログ出力/取得設定なし (B) Oracle標準の監査機能 (FGA/Audit) によるログ出力 (C) メモリ参照形式によるログ取得 各ケースにおいて、vmstat によりCPU 使用率を10秒間隔で取得。結果、(A) と比較して、(B) (C) いずれの場合も、CPU 使用率に大きな変化は見られませんでした。
    Oracle標準の監査機能 (FGA/Audit)では、CPU上昇はなんと、わずか0.4% にしかなりませんでした。

  • SQL単位での性能比較
    更に詳しくSQL単位での実行時間を確認した結果が次の表になります。 (A) 監査ログ出力/取得設定なし (B) Oracle標準の監査機能 (FGA/Audit) によるログ出力 (C) メモリ参照形式によるログ取得 各ケースにおいて、V$SQL で取得したSQL性能情報を比較しました。 いずれの場合も、性能指標に大きな変化はなく、ほぼ誤差の範囲内という結果になりました。

SQL全体

  (A) 設定なし (B) FGA/Audit (C) メモリ参照
10,000SQL 平均 10,000SQL 平均 10,000SQL 平均
ELAPSED 23,909 2.39 24,658 2.47 24,920 2.49
CPU_TIME 22,423 2.24 23,132 2.31 23,268 2.33

監査対象でないテーブルを参照するケース(ログ出力なし)
--SQL (TOP 5)での性能比較

  (A) 設定なし (B) FGA/Audit (C) メモリ参照
10,000SQL 平均 10,000SQL 平均 10,000SQL 平均
ELAPSED 45,417 4.54 42,945 4.29 44,106 4.41
CPU_TIME 41,403 4.14 39,119 3.91 39,857 3.99

監査対象となるテーブルを参照するケース(ログ出力あり)
--SQL (TOP 5)での性能比較

  (A) 設定なし (B) FGA/Audit (C) メモリ参照
10,000SQL 平均 10,000SQL 平均 10,000SQL 平均
ELAPSED 4,898 0.49 6,816 0.68 5,054 0.51
CPU_TIME 4,133 0.41 6,111 0.61 3,867 0.39
  • 取得されたログについて
    取得されるべきログに対して、Audit機能では当然100%取得できたことを改めて確認しました。一方、メモリ参照形式においては、約60%にとどまる結果になりました。

結論

Oracle標準の監査機能 (FGA/Audit)においても、Oracleデータベースサーバへの負荷は非常に軽微で、スループット、SQL時間、サーバ/インスタンスへの影響もほとんどみられませんでした。

検証結果はお客様に報告され、これを元に方針を大きく転換、データベース操作ログを取得する手法としてAudit機能を採用することに至りました。 これまでもAudit設定での負荷は懸念するほどではないことをご説明してきましたが、実際にお客様環境でも証明され、その結果も十分な説得力を持ってお客様にご理解いただきました。

エンタープライズクラウド時代に応えるデータベースセキュリティ

本格化するクラウドデータベース。 操作ログをシームレスに管理するには

クラウド利用者が担保すべきデータベースセキュリティ、その一翼を担うのは、リモート型ソリューション

クラウドが大きな潮流になり、日本においてもクラウドファースト、そしてエンタープライズクラウドの本格化はすぐそこまできています。一方、クラウドにおけるセキュリティは未だ最大の懸念事項でもあります。
しかし、クラウド事業者が提供するクラウド基盤は、実はオンプレミスで自社管理するよりはるかにセキュアなものです。クラウドのセキュリティを考える場合、理解すべきことは、クラウドを利用するからといって利用者がセキュリティ対策を何もしなくてよいわけではない、ということにほかなりません。つまり、クラウドにおけるセキュリティの懸念は実はクラウド事業者に対してのものではなく、利用者側にあるという事実です。
利用するシステムやアプリケーション、及び管理されるデータまでも含めて丸ごとクラウドに預ける、という使い方であればSLA (サービス品質保証契約) にのっとって、クラウド事業者に委ねればいいでしょう。しかしIaaS, PaaSをエンタープライズクラウド環境として利用する場合、クラウドに構築されるOS、データベース、アプリケーションは、原則、利用者自身がセキュリティを担保しなければなりません。
クラウドを利用する企業は、従来行っていたこれらのセキュリティ対策、監査対応は引き続き自らで実施する必要があります。

AUDIT MASTER はリモート型製品で、対象データベースに何もインストールする必要がなく、ネットワーク構成、データベースの場所に依存せず、対象とするデータベースに接続できさえすれば、操作ログの取得・モニタリングや監査要求への対応を可能にします。
パブリッククラウドにシステム基盤を移しこれから本格的にコンプライアンスや監査対応を迫られてくる企業、クラウドにシステム基盤を構築したスタートアップ企業、海外基盤も含めて統合管理していきたい企業など、既に多くのリクエストをいただいています。

エンタープライズクラウドが本格化する中で、AUDIT MASTER はクラウド環境でのセキュリティや監査要件を満たす唯一のソリューションとして、お客様のセキュアなクラウド活用をより一層支援していきます。