監査ログ戦略

Question

アプリケーション内の監査ログの最適な方法を決定しようとしています。ログの主な理由は、一連のイベント（変更）を報告することです。

オブジェクトの階層があり、後日、その階層の一部で何かが変更されたときにレポートを作成する必要があります。

3つのオプションがあると思います：

1. 各テーブルのログを作成し、オブジェクトの階層を一致させてから、レポートのビューを作成します。
2. 階層をフラット化してテーブルを非正規化し、レポート作成を簡単にします-単純な選択ステートメント。
3. ログテーブルを1つ用意し、変更ごとにレコードを用意することで、レポート作成をより困難にしますが、変更に対する柔軟性を高めます。

現在、オプション1に傾いています。

Answer 1

監査ログは、基本的に、発生したイベント、これらのイベントを実行したユーザー、およびイベントが何であるかを時系列に並べたリストです。

フラットビューは、簡単に注文および照会できるため、より良いと思います。だから私はあなたのオプション＃2 /＃3にもっと傾いています。

トランザクションタイプ、時間、ユーザーID、変更内容の説明、製品に関連するその他の関連情報などを含めます。

時間をかけて製品にアイテムを追加することもでき、監査ログモジュールを継続的に変更する必要はありません。

Answer 2

このテーマは古くても話をしなければなりません。

すべてがそのテーブルにヒットすると、データベースにロックの問題が発生するため、通常、監査テーブルを1つだけにすることは適切ではありません。各テーブルに個別の監査テーブルを使用します。

また、アプリケーションに監査を行わせるのは良くありません。監査はデータベースレベルで行う必要があります。そうしないと、一部の情報が失われる危険があります。データはほとんどのデータベースのアプリケーションからのみ変更されるわけではありません。すべての製品の価格を10,000,000個すべてに10％引き上げる必要があるときに、ユーザーインターフェイスから一度に1つずつすべての製品の価格を変更することはできません。監査では、一部の変更だけでなく、すべての変更をキャプチャする必要があります。これは、ほとんどのデータベースのトリガーで実行する必要があります（SQL Server 2008には監査機能が組み込まれています）。最悪の潜在的な可能性のある変更（詐欺を犯したり、悪意を持ってデータを破壊したい従業員）の一部は、特にユーザーにテーブルレベルのアクセスを許可する場合、アプリケーション以外の場所からも頻繁に発生します（金融データベースまたは個人情報）。アプリケーションからの監査はこれをキャッチしません。開発者は、データを保護する上で、外部のソースだけが脅威ではないことをしばしば忘れます。

Answer 3

監査目的の場合、同じデータベース内のテーブル/テーブルではなく、真の追加専用メディアを使用します。

変更履歴を目的とすることをお勧めします。この場合、アプリケーション/データベースを再構築して、現在の状態だけでなく実際のイベントを最初の場所に記録します。

Answer 4

（2）および（3）を使用します。すべての監査エントリに対して単一のテーブルを作成します。

余分な作業の平坦化がパフォーマンスに影響を与えない限り、平面図は良好です。

Answer 5

これを支援するために、AOPフレームワークを調べることができます。これにより、任意/すべてのメソッドの最初または最後にロギング機能を注入できます。この道を進むと、ログデータを保存するのに意味のあるものを定義するのに役立つ場合があります。