問題タブ [audit]

MySQL では、自分のデータベースにあるすべてのテーブルに、列dt_createdと(それぞれ作成と最終変更のタイム スタンプ)を追加することにうんざりしています。dt_modified

INSERT私またはUPDATEデータベースのたびに、NOW()キーワードを使用する必要があります。これは私の粘り強さ全体に行き渡っています。

MySQL が少なくとも挿入された行のデータタイムを自動的に保存し、それを取得できる効率的な代替手段はありますか?

SQL Server 2005 データベースの 2 つのテーブルに変更追跡を実装する必要があります。追加、削除、更新を監査する必要があります (更新内容の詳細を含む)。これを行うために を使用することを計画していましたtriggerが、これは簡単に間違って行うことができるようです。

これをうまくかつエレガントな方法で達成する更新トリガーの例を投稿できる人はいますか? 次の構造の監査テーブルになることを望んでいます。

• ID
• ログ日付
• テーブル名
• TransactionType (更新/挿入/削除)
• レコード ID
• フィールド名
• 古い値
• 新しい値

... 考え？

最近、データベースに監査を追加しました。同僚がトリガーを使用して実装し、Webサイトへのログイン時にストアドプロシージャを呼び出すように依頼しました。ストアドプロシージャは、現在のユーザー名と現在のOracleセッションIDをテーブルに挿入して、トリガーがセッションIDをユーザー名にマップできるようにします。問題は、ユーザーのインターネットセッションがデータベースセッションにマップされていると彼が想定していたことです（またはそうでした）。そうではなく、接続プールを使用するため、OracleセッションIDは、必ずしもそのセッションにログインしたユーザーではなく、多くのユーザーにマップできます。そこで、データアクセス層にユーティリティメソッドを作成しました。このメソッドは、挿入、更新、削除のたびにプロシージャを呼び出します（同じトランザクション内にあることを確認してください）。

これは機能し、監査は現在必要に応じて機能しています。ただし、HttpContextの呼び出しは好きではありません。

これはタスクを実装する最も速い方法でしたが、データアクセス層にあるべきではないと思います。将来、フォームアプリケーションを使用してデータベースにアクセスしたい場合はどうなりますか？HttpContextにアクセスするとエラーが発生しますか？懸念を適切に分離するユーザー名を取得するためのより良い方法はありますか？すべての挿入、更新、削除にパラメーターとしてユーザー名を渡すことはオプションですが、それは時間のかかる作業であり、よりエレガントな方法があるかどうか疑問に思いました。

特定の Exchange 2007 メールボックスへのフル アクセス権を持つユーザーのリストを作成するように依頼されることがあります。現時点ではこれを手動で行っていますが、理想的には Powershell で行いたいと考えています。

とにかく、フル アクセス許可のリストを作成する方法はありますか (代理送信権も役立ちます)。

ありがとう、ジョニー

これは、多くの開発者が以前に直面した要件であると確信しています。ビジネスには、システムでアクションを実行している人を知るための監査証跡が必要です。

監査情報の保存方法に関係なく、この問題の核心は現在のユーザーを特定する方法です。

小さなドメインモデルクラスからサービスコンポーネントまで、次のホストアプリケーションのいずれかから安全に呼び出すことができるコンポーネントを作成したいと思います。

• Windowsデスクトップアプリケーション。
• IISでホストされているASP.NETWebサイト。
• IISでホストされているWCFサービス。
• WindowsサービスでホストされているWCFサービス。

さまざまなテクノロジ、さまざまな認証モデル、および「匿名」ユーザーの概念を考慮する必要があることを考えると、コンポーネントを一元的に呼び出した人のIDを取得するために使用する戦略が明確ではありません。

賢い人の誰かがこれに取り組むためのアプローチを提案できますか？

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

これについてはすでにいくつかの質問がありますが、すべてのシナリオに最適なアプローチが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」メソッドにコードをドロップして、終了時間を記録する必要がありますか？それは完全な解決策ですか？このメソッドは、サイトを開いているブラウザータブを閉じるときに常に呼び出されますか、それともブラウザー全体を閉じる必要がありますか（ログアウト機能はありません）？ユーザーがこのセッション終了メソッドをスキップする（またはその場合は開始する）方法はありますか？