そのDB監査システム、維持できますか?

すでにコントロールの一つとしてデータベース監査を取り入れている、あるいはこれから取り入れようとしているところが多くなってきました。データベース監査の実装方法としては、手作業による管理、あるいはツールやソリューションの中から、各社の要件や状況にあわせて選択することになります。

 その中で最適な方法を手にするにはどうしたらよいか、いくつか確認しておきたいことがあります。まず、質問します。

今考えている、そのデータベース監査システムは、維持できますか?

 もし、選定ポイントを見た目に洗練された画面やアウトプット、他にはない独自で先進的と標榜する機能、簡単には理解できない位の機能バリエーションの豊富さ、使ったこともない製品との連携可否...に求めてしまうと、失敗あるいは後悔することになるかもしれません。

・操作は簡単ですか?

 これからもずっと続けていく内部統制の運用において、重要なのは、将来の利用者は必ずしもシステムに詳しい人とは限らないということです。また、人もシステムも変わっていく、という事実です。簡単かどうかは、システム部門の人が判断すべきではありません。できるだけシステム的な発想によらず、直感的に操作できるもの、つまりできるだけシンプルにものが望ましいのです。

・環境の変更を視野に入れていますか?

 インストール時はもちろん、対象の追加や変更、サーバリプレイスやDBバージョンアップなど環境の変化に対して自社メンバーで対応できますか?自動学習という機能についてそのロジックを監査人に答えられますか?

・運用コストを考慮していますか?

 導入後の、長期的な視点にたった経費を確認されることをお奨めします。
まず、人手による対応が、自動化されたものと比べてコントロールの質が落ちるということは周知の事実です。ノウハウの継承も難しい問題です。またデータベース監査ログに対する要求は変化します。期間指定で監査提出用のログ出力を要求されたり、インシデント発生時の絞込み調査など、予期しないことも想定しなければなりません。データベース監査ログをモニタリングするために、複数の仕組みを組み合わせることは、実は非常に対応に時間をとることになります。手間がかかることは、結果的にコストに反映することになります。

 これらの質問に対して、皆様は回答できたでしょうか。さて、最後にもうひとつ、ご認識いただきたいことがあります。それは、「汎用のレポートはない!」ということです。どこにでも汎用に通用するアウトプットという幻想は捨ててください。自社のリスクに応じたコントロール、すなわち、レポートなどのモニタリング方式は、個々で確立する必要があり、他社で通用したレポートが自社でもOKになるとは必ずしも言えないのです。リスクを評価した上で、必要十分なログを取得し、コントロールが効いていることを証明する、最適なアプローチを実現する、柔軟なレポート機能こそが必要となります。
内部統制の有効性証明は、一度達成して終わりではありません。
継続して運用できること。忘れてはならない、データベース監査システムの要件です。