問題タブ [audit]

データベースの設計から始めて、HIPPA の監査証跡を実装するためのベスト プラクティスはありますか。

私の記憶は私に失敗しています。トリガーに基づく単純な監査ログ テーブル

ID            int (identity, PK)
CustomerID    int               
Name          varchar(255)      
Address       varchar(255)      
AuditDateTime datetime          
AuditCode     char(1)           


があります。次のようなデータが

ID CustomerID Name      Address             AuditDateTime          AuditCode  1  123        Bob       123 Internet Way    2009-07-17 13:18:06.353I          2  123        Bob       123 Internet Way    2009-07-17 13:19:02.117D          3  123        Jerry     123 Internet Way    2009-07-17 13:36:03.517I          4  123        Bob       123 My Edited Way   2009-07-17 13:36:08.050U          5  100        Arnold    100 SkyNet Way      2009-07-17 13:36:18.607I          6  100        Nicky     100 Star Way        2009-07-17 13:36:25.920U          7  110        Blondie   110 Another Way     2009-07-17 13:36:42.313I          8  113        Sally     113 Yet another Way 2009-07-17 13:36:57.627I         


あります。 参考までに、I は挿入、D は削除、U は更新です。

監査テーブルに欠けているものはありますか? 次のステップは、変更のみを記録する監査テーブルを作成することですが、特定の時間枠の最新のレコードを抽出できます。私の人生では、どの検索エンジンでも簡単に見つけることができません。リンクも機能します。助けてくれてありがとう。

このテーブル定義が与えられた場合

変更は最小限で、通常は単一のフィールドのみで、非常にまばらになると思います。

だから私はこのテーブルを作成しました：

トリガーで、変更された値の列名を取得して保存するにはどうすればよいですか? 削除されたテーブルを結合して値を取得する方法を知っています。

データベース内のいくつかのテーブルに対して単一の監査テーブルのアイデアをいじっています。このページでコードを見つけました: http://www.simple-talk.com/sql/database-administration/pop-rivetts-sql-server-faq-no.5-pop-on-the-audit-trail/

このアイデアは気に入っていますが、少し困惑しているのは、情報を照会して有用な方法で表示できるようにする方法だけです。

変更を加えると、監査テーブルは次のようになります。

ほとんどの場合、履歴を作成するには、テーブルのコピーを作成し、最後に日付変更列を追加してから、行全体を履歴テーブルにコピーしますが、これにより、コピーされたデータと履歴テーブルが大量に作成されます。監査するものがたくさんある場合。

現在、データベース内のいくつかのテーブルの履歴テーブルを作成するというアイデアをいじっています。基本的に、メイン テーブルとそのテーブルのコピーがあり、変更日とアクション列があり、実行されたアクション (更新、削除、挿入など) を格納します。

これまでのところ、履歴テーブルの作業を行うことができる 3 つの異なる場所を考えることができます。

• 更新、挿入、および削除のためのメイン テーブルでのトリガー。(データベース)
• ストアド プロシージャ。(データベース)
• アプリケーション層。（応用）

私の主な質問は次のとおりです。これらの各レイヤーで作業を行うことの長所、短所、落とし穴は何ですか?

トリガーを使用する利点の 1 つは、データベース上に何が実装されていても、整合性が常に維持されることです。

SQL Server 2005 のトリガーに関するかなり一般的な質問です。

どのような状況でテーブル トリガーが起動され、どのような状況で起動されないか?

デモンストレーションするコード例はどれも素晴らしいでしょう。

私は監査ベースのデータベースを作成していますが、テーブルの更新、削除、および挿入用に設定したトリガーが起動しない可能性がある状況に注意したいだけです。

私が言いたいことの例、

次のステートメントは、更新トリガーを 1 回だけ起動します。

企業のセキュリティ ポリシーでは、低レベルのイベント ログが必要になり始めています。たとえば、ファイル アクセス許可の変更。解決策の 1 つは SELinux を使用することですが、これに関する私たちの知識はせいぜいまばらです。もう 1 つは、コマンドを監査を実行するプロキシに置き換えることです (これは残念ですが)。

何か案は？

現在のエンタープライズソリューションは、EntityFrameworkによって駆動されるASP.NETMVCアプリケーションです。監査のために変更イベントにフックする方法については、いくつかのリンクがあります。私はこれにはあまり興味がありません。

エンタープライズレベルの監査アーキテクチャに興味があります。エンタープライズレベルの戦いの傷を負っている人たち、あなたの監査ソリューションは何でしたか？フレームワーク内のデータベース内のオブジェクトをシリアル化しますか？テーブルを監査するためのデータベーストリガーを設定していますか？監査の拡大がアプリデータベースに影響を与えないように、個別のデータベースをすべて一緒に使用していますか？私はここで実証済みの真の解決策に興味があります。私たちのテクノロジーの選択（EF）には選択肢があることは知っていますが、最初に基盤に興味があります。

リンクをいただければ幸いです。