問題タブ [audit]

新しいデータベースを設計する必要があるたびに、変更の監査ログを保持するためにデータベーススキーマを設定する方法を考えるのにかなりの時間を費やします。

これについてはすでにいくつかの質問がありますが、すべてのシナリオに最適なアプローチが1つあることに同意しません。

• 改訂のためのデータベース設計
• 変更ログ監査データベーステーブルの最適な設計
• 監査証跡をキャプチャするためのデータベース設計に関するアイデア

また、各アプローチの長所と短所をリストしようとする、データベース変更のログの保守に関するこの興味深い記事に出くわしました。それは非常によく書かれていて、興味深い情報を持っていますが、それは私の決定をさらに難しくしました。

私の質問は次のとおりです。私が使用できる参照、おそらく本や、次のようないくつかの入力変数に基づいてどちらの方向に進むべきかを決定するために参照できる決定木のようなものはありますか。

• データベーススキーマの成熟度
• ログの照会方法
• レコードを再作成する必要がある確率
• さらに重要なこと：書き込みまたは読み取りのパフォーマンス
• ログに記録される値の性質（文字列、数値、blob）
• 利用可能なストレージスペース

私が知っているアプローチは次のとおりです。

1.作成および変更された日付とユーザーの列を追加します

表の例：

• id
• value_1
• value_2
• value_3
• 作成日
• Modified_date
• によって作成された
• 変更された

主な短所：変更の履歴が失われます。コミット後にロールバックできません。

2.テーブルのみを挿入します

表の例：

• id
• value_1
• value_2
• value_3
• から
• に
• 削除済み（ブール値）
• ユーザー

主な短所：外部キーを最新の状態に保つ方法は？巨大なスペースが必要

3.テーブルごとに個別の履歴テーブルを作成します

履歴テーブルの例：

• id
• value_1
• value_2
• value_3
• value_4
• ユーザー
• 削除済み（ブール値）
• タイムスタンプ

主な短所：すべての監査済みテーブルを複製する必要があります。スキーマが変更された場合は、すべてのログも移行する必要があります。

4.すべてのテーブルの統合履歴テーブルを作成します

履歴テーブルの例：

• table_name
• 分野
• ユーザー
• new_value
• 削除済み（ブール値）
• タイムスタンプ

主な短所：必要に応じてレコードを簡単に再作成（ロールバック）できますか？new_value列は、すべての異なる列タイプをサポートできるように、巨大な文字列である必要があります。

私の ERP システムには、M2MDeleteLog というテーブルに次の情報を挿入する中途半端な削除追跡システムがあります。簡単にするために、RecordId などの不要な列は省略しています。

残念ながら、関連情報のほとんどは 1 つのテキスト フィールドに含まれています。最初のステップは、ユーザー (D.STEIN)、画面 (SOMAST)、および画面 (frmso) を LogInfo フィールドから取得することです。その部分は比較的簡単です。

私がやりたいことは、疑わしいアクティビティを探すために、15 分ごとに実行されるスケジュールされたジョブを作成することです。疑わしいアクティビティとは、ユーザーごとに 15 分間隔で 3 回削除されることです。

ちょっと待って！ゼアズ・モア！

私が提供したデータでは、削除イベントは 3 つしかなく、それぞれの間隔は 1 分未満です。新しい削除イベントは、最後のイベントから少なくとも 20 秒後に定義します。

LogDate を評価し、15 分さかのぼり、ユーザーごとの削除イベントをカウントして、特定のユーザーに対して 3 つ以上が記録されたときに管理者に通知するにはどうすればよいですか?

皆さん、

興味深い技術的課題があります。ソフトウェアの使用状況を追跡する安全な監査ファイルを作成して、ライセンス料を使用状況に基づいて設定し、使用頻度の低い人にとって手頃な価格にする方法。

具体的には、TickZoom はヘッジファンド向けのアルファ世代の取引プラットフォームを販売しており、現在、サポートを含めて月額 2,000 ドルのライセンス費用がかかります (まもなく 2 倍以上に値上がりします)。これは機関にとっては問題ありませんが、個人にとっては高すぎます。個人は、固定料金を支払う余裕ができるまで、ソフトウェアを使用して得た利益の一部と引き換えに、より低い価格を要求することがよくあります.

私たちはその提案が好きです。しかし、プラットフォーム上で実際に生み出された利益を監査する信頼できる方法と、ユーザーが監査ファイルを削除または上書きして実際よりも低い利益を報告することで「ゲーム」を行うのを防ぐ方法が必要です。

このアプリケーションは C# で記述されており、システムのこの部分は難読化されており、少なくともコードの解読が困難になっています。

もう 1 つの要件は、取引が発生するたびにファイルに書き込むことです。これにより、ユーザーが合計料金に何らかの不一致があると感じた場合に、より詳細な監査が可能になります。そうすれば、個々のトレード利益をブローカーのステートメントと比較できます。

もちろん、ファイルが暗号化されることが想定されています。

しかし、それを「改ざん防止」にする方法についてのアイデアはありますか? 特に単純な削除の試みに対して？

私の最初の推測は、ソフトウェアが常に既存の監査ファイルを必要とするようにすることです。そうしないと、実行を拒否します。

次に、ソフトウェアを配布すると、「空の」監査ファイルがパッケージ化されますが、実際には、何らかの改ざん防止検証が行われています。

ユーザーがファイルを「改ざん」しようとする次の明らかな手法は、誰かがその元の「空の」ファイルを単にバックアップし、後でそれを使用して後で監査ファイルを上書きし、システムをだましてそれが新たなスタートであると思わせることです。

おそらく、ある種の「最終更新タイムスタンプ」と有効期限を含めることで解決できます。

また、まったく異なるソリューションのアイデアも歓迎します。この場合、取引が中央サーバーに記録されるように、「家に電話」機能を追加する必要があるかもしれません。しかし、これは不利なように思われ、ミッション クリティカルなアプリケーションに別の障害点を追加する可能性があります。一般的に、彼らは明らかに正当な理由で「家に電話」機能を非常に嫌います。

敬具、ウェイネック

私は、すべてのデータベーストランザクションを監査する必要があるビジネスアプリに取り組んでいます（主に法的な目的で）。

私はWebを見回して、DoddleAudit（http://www.codeplex.com/DoddleAudit）に出くわしました。これは、基本的に、変更を追跡するためのLinqtoSQLの機能を追加します。人々がHibernateでインターセプターを使用するのと同じように。

これに関して私が懸念しているのは、信頼性の問題です。ORMレイヤーの監査ログは、コードを介して発生するすべてのことを記録する場合がありますが、誰かがデータベースやハッカーなどに対して手動でSQLステートメントを発行した場合、変更はログに記録されません。基本的に、私が扱っている情報はやや敏感。それが、トリガーがおそらく最も信頼できる方法であると私に信じさせる理由です。（？）

ログに記録する他の方法は、コードを使用するか、少しハッキーで信頼性が低いと思われるストアドプロシージャを使用する方法です。だから私は基本的にトリガーかDoddleAuditのようなものを使うことになります。

どちらかを選ぶ前に、私はいくつかの意見を得たいと思っていました。

私のASP.NETイントラネットWebアプリケーションはWindows認証を使用していますが、次の詳細を記録したいと思います。

1）Windows ID
2）セッション開始時間
3）セッション停止時間
4）参照されているURL（オプション）

Global.ASAXの「Session_Start」メソッドにいくつかの基本的なコード設定があり、セッションの開始時刻をログに記録します（以下を参照）が、これまでのところこれで終わりです。これは原始的なアプローチであり、これを行うための「より良い」方法があると私は感じています。だから私は本当に2つの質問があります：

1）これはこれを行うための正しい方法ですか？そうでない場合、他のいくつかのオプションは何ですか？

2）これが正しい方法である場合、「Session_End」メソッドにコードをドロップして、終了時間を記録する必要がありますか？それは完全な解決策ですか？このメソッドは、サイトを開いているブラウザータブを閉じるときに常に呼び出されますか、それともブラウザー全体を閉じる必要がありますか（ログアウト機能はありません）？ユーザーがこのセッション終了メソッドをスキップする（またはその場合は開始する）方法はありますか？

まず、現在、望ましい動作をしていますが、データベースへの変更が必要になったときに維持するのは簡単ではありません。私は、よりシンプルで、より効率的で、保守しやすいものを探しています (これら 3 つのいずれかを行うものは大歓迎です)。更新を実行すると、現在の行のコピーである履歴行が作成され、現在の行の値が更新されます。その結果、更新前の行の履歴が記録されます。

理由: 私たちは多くの連邦規則に準拠する必要があり、すべての完全な監査履歴を保持するためにこの方法を採用しました。また、いつでもデータベースを見て、物事がどのように見えるかを確認できます (将来の要件) . 同様の理由で、履歴の記録方法を変更することはできません...どのソリューションも、現在のトリガーが作成するデータと同じ結果になる必要があります。

Contactテーブルの現在のトリガーは次のようになります:
(簡潔にするために不要なフィールドを取り除いています。フィールドの数は重要ではありません)

更新前 (各行):

更新前 (すべての行に対して 1 回):

更新後 (すべての行に対して 1 回):

次のように定義されたパッケージ (トリミングされたフル バージョンは、表ごとにこれをコピーしたものにすぎません):

現在の結果

結果の履歴サンプルは次のとおりです。

各履歴レコードには、現在の行の ID である Entity_ID があり、新しいレコードの Date_Start は、最後の履歴行の Date_Modified と一致します。これにより、次のようなクエリを実行できますWhere Entity_ID = :id Or ID = :id And :myDate < Date_Modified And :myDate >= Date_Start。履歴は で取得できますEntity_ID = :current_id。

これを行うためのより良いアプローチはありますか? 概念は単純です。行を更新するときに、古い値を挿入して同じテーブルにコピーし、現在の行を更新します...しかし、実際にそれを行うには、もっと簡単な方法をまだ見つけていません。オラクルのより巧妙で賢明な人が、これに対するより良いアプローチを持っていることを願っています。速度はそれほど重要ではありません。ほとんどの Web アプリケーションと同様に、99% 読み取り 1% 書き込みであり、すべての一括操作は挿入であり、履歴を作成しない更新ではありません。

誰かがこれのメンテナンスを簡素化するためのアイデアを持っているなら、私は非常に感謝しています、ありがとう!

特定のユーザーが SQL Server に最後にログインしたのはいつかを判断する方法はありますか? データベース サーバーの監査を実行しようとしていますが、冗長なユーザーを削除したいと考えています。

ちなみに、私が興味を持っているのは、個々のデータベースのユーザーではなく、サーバー レベル (つまり、ログイン) のユーザーです。

前もって感謝します。

私のクライアントは、アプリケーションで完全な監査証跡 (すべてのテーブルの履歴データの完全なビュー) を実行する方法を探しています。

テーブルのコピーを作成したり、フィールド名、フィールド値、変更者、変更者などを保存したりする昔ながらの方法を使用する以外に、Sql Server 2008 変更追跡の使用を検討していました。msdnでハウツー記事を
見つけました。

Sql Server 2008 の Change Tracking 機能を使用した (または POC を行った) 人はいますか? また、可能であれば、そこから何を望んでいたのか、何を見つけた/結論付けたのかを明記してください. 同じことに関するヒントは大歓迎です。

[編集]
1 週間経ってもまだ回答がありません。

SQL Server の監査、具体的には不正調査に推奨されるアプリケーションは何ですか?

エンド ユーザーがデータ値を関連付けて不正パターンを見つけられるようにするツールが必要です。このツールは、誤検知を減らすために必要に応じて調整できる必要があります。

また、かなり直感的であることも重要です。理想的には、SQL に慣れていないエンド ユーザーが SQL を直接操作し、GUI インターフェイスを使用してカスタマイズできるようにすることです。

提案？

私はこれらの 2 つの単語に出くわすことが多くなりましたが、これらに大きな違いは見られませんでしたか? つまり、それらは同じ意味で使用されているのか、それともこれら2つにいくつかの違いがあるのか​​ を知りたいということですか? ありがとう。