17

asp.netとsqlサーバーを使用してWebアプリケーションを開発しています。アプリケーションの監査証跡を作成する必要があります。私がこれを理解しているように、監査証跡は基本的にデータベース上のすべての挿入、更新、および削除に対するものですよね？これにアプローチする方法は、挿入、更新、または削除が実行されるたびにデータが入力される監査証跡テーブルをDBに作成することです（DAL内でスクリプトを手動で記述します）。ただし、SQL Management Studioから直接発生したDBの変更は記録されません（明らかな理由：P）。

それに応えるために、私はトリガーを作成することができ、それがすべてを処理します。また、グーグルを実行したところ、SQLサーバーに監査証跡を実行する機能があることがわかりました。ただし、トリガーを使用する場合の問題は、Webサイトにログインしたユーザー情報を取得できないことです。私はSQLユーザーを取得しますが、それについて2つのヒントを与えることはしません。私は、Webサイトユーザーについて心配しています。

私が理解した解決策は、a）Webアプリケーションからの監査証跡を持ち、トリガーを設定することでした。監査レポートには、Webアプリケーションからの監査ログとSQLサーバーからの監査ログを表示するだけです。このアプローチの明らかな問題：頭上。DBが変更されるたびに2つの異なるテーブルセットに書き込みます。

b）すべてのDBテーブルにUserIdという列があります。次に、すべてのDB変更をキャプチャするトリガーを作成します。変更するすべてのテーブル（挿入、更新、削除）にこのuserIdを渡し、トリガーからこのIDを取得します。明らかな挫折：すべてのテーブルに不要なuserid列

長い投稿をお詫び申し上げます。基本的に、すべてのデータベースの変更（データベースへの直接ハックを含む）をログに記録する監査ログが必要ですが、同時に、Webアプリケーションから行われたデータベースの変更のユーザーログイン情報を提供します。

この点に関するご意見をいただければ幸いです。

どうもありがとう

xeshu

4

4 に答える 4

12

SQL Management Studioまたはその他の方法でデータベースに対してSQLクエリを直接実行することにより、DBに正当な変更が加えられる可能性はどのくらいありますか。データ内のすべてのデータがアプリケーションを介して入力され、BLレイヤーで監査が行われていると想定することをお勧めします。次に、データベースへのアクセスを信頼できるユーザーに制限するだけです。最終的には、データベーススキーマを変更する権限を持つユーザーが1人以上いる必要があります。これらのユーザーが監査をバイパスしたい場合は、トリガーを無効にするか、監査証跡を偽造することができます。DBに対して直接SQLクエリを実行する正当な理由がある場合、たとえば、他のシステムからのデータインポートの頻度が低い場合は、このアクティビティを信頼できるユーザーに制限し、インポートスクリプトが監査テーブルに正しく入力されるようにすることができます。

于 2010-07-13T09:37:05.333 に答える
4

返信ありがとうございます。いくつかグーグルした後、これは私が適切だと思うアプローチです：一般的な監査テーブル

Audit_Table（Id、TableName、RecordId、（問題のレコードへのリンク）ModifiedBy、ModifiedOn、Type（I、U、またはD））

Audit_Details_Table（Id、AuditId、FieldName、OldValue、NewValue）

私はこれがそれをするべきだと思います。何かご意見は？

于 2010-07-14T10:24:10.667 に答える
3

あなたは正しい方向に進んでいるようですね。ただし、通常は単一の監査証跡テーブルではなく、すべてのテーブルの監査テーブルがあります。したがって、TableAの行を変更するたびに、TableAの新しい状態に加えて、ユーザーの日付と名前を含む新しい行がTableA_Auditに追加されます。

通常、これにはトリガーが使用されますが、Webアプリのユーザー名を格納している場合、このデータをトリガーに渡す方法がわかりません（他の誰かが助けてくれますか？）この場合、ストアドを使用したくなるかもしれません手順。テーブルごとに、行を挿入、更新、および削除するためのストアドプロシージャがあります。これらのストアドプロシージャはそれぞれ、監査テーブルに行を挿入する別のストアドプロシージャを呼び出します。このようにして、Webアプリのユーザー名をストアドプロシージャに簡単に渡して、監査テーブルに行を挿入します。明らかに欠点は、テーブルごとに多数のストアドプロシージャを維持する必要があることです。これは、スキーマの変更が必然的に必要になるため、すべてのストアドプロシージャがテーブル（およびアプリケーションのデータアクセス層）と一致していることを確認する必要があるため、少し面倒な場合があります。 。

すべてのテーブルにユーザー名列が必要なわけではなく、すべての監査テーブルにのみ必要であることに注意してください。

その一部がお役に立てば幸いです。

乾杯

デビッド

于 2010-07-13T09:20:34.107 に答える
3

私は他の両方のポスターに同意します。つまり、Webアプリユーザーのユーザー名（つまり、カスタム認証）を保存する場合、トリガーは何が起こっているのかを監査するのに役立ちません。-統合認証を使用できない場合の警告

これは、たとえばユーザーごとのアクティビティの量を監視するために監査証跡も使用する場合に非常に重要です。これに対する解決策は、ストアドプロシージャを介してすべてのDDLを実行し、それらのストアドプロシージャ内に監査ロジックを追加することです（すべてのログをT-SQLで記述したい場合）。または、アプリケーションから実行し、 NLogなどのASP.Netで使用可能な多くのログライブラリの1つを確認します。

于 2010-07-13T12:55:08.930 に答える