私はすでに承認の成功、失敗、ログアウトを監査しています。
すべてのメソッド呼び出しを監査（ログ記録）し、変更されたすべての行と列のバージョンを保持することを検討しましたが、これらのオプションはどちらも監査の複雑さを大幅に増大させます。ランダムなサブセットを監査すると、ランダムすぎるように見えます。
法的仕様（FISMA、C＆A）は、何かを監査する必要があると言っているだけです。
私が忘れている他の非ドメイン固有の監査戦略はありますか？
2 に答える
3
監査は説明責任に関するものであることが多いことを考えると、誰か/何かが説明責任を負う必要があるイベントに寄与する可能性のあるアクションをログに記録することをお勧めします。
- クライアントレコードの変更
- 構成の変更
- データの削除
重要なデータへの変更をロールバックできるように、これらの一部をバージョン管理しておくことをお勧めします。そもそも「変更者」を追加するのは非常に簡単です。
誰かがデータベースに直接アクセスできない限り、多くの場合、データベースに影響を与えるイベントのアプリケーションログ（多くのテーブルを変更するトランザクションなど）で十分な場合があります。監査可能な論理アクションを説明責任の論理ユニットにリンクできる限り、影響を受けるサブシステムに関係なく、説明責任を追跡できるはずです。
メソッドの呼び出しとデータベースの変更を直接ログに記録するのではなく、それらの呼び出しと変更につながったビジネスロジック、およびそのロジックを使用したユーザーをログに記録する必要があります。呼び出し/テーブルの変更と監査メッセージの間の因果関係をリンクする少量のバックエンドコードも有益です（リソースがある場合）。
アプリケーションの監査要素をイベントのツリーと考えてください。ルートはログに記録するものです。たとえば、「Daveは顧客レコード2938を削除しました」。ルートの子はすべてログに記録でき、監査イベントの一部としてログに記録することが重要な場合は、ルートに関連付けることができます。たとえば、ある監査イベント「Davedeleted ...」が、制約などの一部として歩き回る請求情報に関連付けられていると断言できます。
しかし、私は専門家ではありません。
于 2009-05-27T11:28:17.403 に答える
2
私はエイデンが言ったことの多くに同意しますが、監査はデータベースレベルで行われるべきだと強く信じています。動的SQLでアクセスされるデータベースが多すぎるため、アクセス許可はテーブルレベルにあります（少なくともSQL Serverでは）。したがって、詐欺を犯した人は、すべてのルールをバイパスして、データベースにデータの削除または変更を入力できます。適切に設計されたシステムでは、prodの監査トリガーを変更する権限を持っているのは数人（dbaとバックアップ）のみであるため、変更が許可されていないデータを変更している場合、ほとんどの人が捕まる可能性があります。アプリを介して監査することは、これらの人々を捕まえることは決してありません。もちろん、dbasが不正を行うことを選択した場合、それを防ぐ方法はほとんどありませんが、誰かがデータベースに対する管理者権限を持っている必要があるため、そのような人を選ぶ際には特に注意する必要があります。
データベース内のほとんどのテーブルで、データへのすべての変更、すべての挿入、およびすべての削除を監査します。これにより、変更を簡単に取り消すことができ、監査証跡を提供できます。データベースに保存されている内容によっては、それを行う必要がない場合があります。しかし、私はすべての金融取引、すべての人事取引、および注文、倉庫保管、または犯罪行為の対象となる可能性のあるその他のものに関係するすべての取引を監査します。
何を絶対に監査する必要があるのかを本当に知りたい場合は、監査を行う人に相談して、何を見たいか尋ねてください。
于 2009-05-27T20:22:18.370 に答える