問題タブ [audit]

データベース内のいくつかのテーブルに対して単一の監査テーブルのアイデアをいじっています。このページでコードを見つけました: 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）には選択肢があることは知っていますが、最初に基盤に興味があります。

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

私はEntityFrameworkでいくつかの監査フックを見てきました。それらの多くは、新旧の値の比較を示しています。これは監査証跡には最適ですが、オブジェクトのスナップショットを探しています。

たとえば...製品を管理するアプリケーションがあるとします。製品には、複数の属性と関連する他のオブジェクトがあります。オブジェクトを10回変更するとします。また、これらのオブジェクトの変更の画面を表示できることも重要だとしましょう（監査証跡ではなく、読み取り専用形式で画面が実際にどのように表示されたか）。私が興味を持っているのは、これらの10個の変更すべて（表示したいものに応じて）の元のEF製品オブジェクト（関連するすべてのデータを含む）を取得し、それを使用して画面にバインドできることです。

SQL Serverを使用している場合、最近のシリアル化されたオブジェクトにはどのタイプ（XML、blobなど）を使用する必要がありますか？これを行うのは理にかなっていますか？

この質問で提案されたものと同様の監査証跡を実装することを計画していた新しいプロジェクトに SQLAlchemy を使用し始めています。

• C# でオブジェクトの監査証跡を実装しますか?
• 監査証跡と SOX/HIPAA/etc の実装、機密データのベスト プラクティス
• 監査証跡を取得するためのデータベース設計に関するアイデア
• DB 監査証跡の最適な実装は何ですか?
• これは、監査証跡を作成する最善の方法ですか?
• DB アプリケーションの監査証跡/変更履歴を残すための適切な戦略は?
• NHibernate および SqlServer でのデータ監査。
• 監査証跡を取得するためのデータベース設計に関するアイデア

私はすでに「興味深い」オブジェクトの完全な履歴を持っているので、ユーザーが特定のバージョンにロールバックできるようにすることを考えていましたundo。

これは、SQLAlchemy を使用してクリーンな方法で行うことは可能でしょうか?

内部 API (ビジネス ロジックと ORM) でこの機能を公開する正しい方法は何でしょうか?

私はのようなものでしuser.rollback(ver=42)た。

最近、テーブルを監査する方法のトピックが私たちの議論で浮上しました...これにアプローチする最良の方法についてのあなたの意見が好きです. 以前の各 DBA が正しいと信じていたことを実行したため、データベースには両方のアプローチが混在しています (これは良くありません)。したがって、いずれかのモデルに従うように変更する必要があります。

アプローチ 1:監査テーブルに、メイン テーブルから置き換え/削除されたレコードのみを格納します (システム テーブル DELETED を使用)。したがって、メイン テーブルの各 UPDATE および DELETE について、置き換えられるレコードは、'U' ( UPDATE の場合) または 'D' (DELETE の場合) として 'Audit_Type' 列を使用して監査テーブルに挿入されます。

INSERT は監査されません。レコードの現在のバージョンについては、常にメイン テーブルをクエリします。履歴については、監査テーブルにクエリを実行します。

長所: 以前のバージョンのレコードを保存するのは直感的です 短所: 特定のレコードの履歴を知る必要がある場合は、監査テーブルをメイン テーブルと結合する必要があります。

アプローチ 2:メイン テーブルに入るすべてのレコードを監査テーブルに格納します (システム テーブル INSERTED を使用)。

メインテーブルに INSERTED/UPDATED/DELETED された各レコードは、監査テーブルにも格納されます。したがって、新しいレコードを挿入すると、監査テーブルにも挿入されます。更新されると、(INSERTED からの) 新しいバージョンのテーブルが Audit テーブルに格納されます。削除すると、古いバージョン (DELETED から) のテーブルが監査テーブルに格納されます。

長所: 特定のレコードの履歴を知る必要がある場合、すべてが 1 か所にあります。

すべてをここに挙げたわけではありませんが、それぞれのアプローチには長所と短所があります。

大規模なネットワークの機器を可能な限り迅速に監査したいと考えています。またはを使用する必要がありますNmap::ParserかNmap::Scanner？

関連する OS のフットプリントと ID だけでなく、ping を返す IP アドレスのリストを作成したいと考えています。

例：

次に、ping が成功したら、OS の推測とともに IP アドレスをハッシュに保存します。

SimpleRepositoryモードでSubSonic3.0.0.3を使用しています。Subsonic 3で、バージョン2.xで標準であったcreatedon、createdbyなどの監査フィールドを自動的に作成して入力する方法を考えていました。

これは、T4テンプレートで構成する必要があるものですか？