0

トリガー内からトリガーをトリガーしたSQLにアクセスする方法はありますか? master..monProcessSQLText MDA テーブルに参加することでなんとか取得できましたが、これは mon_role を持つユーザーに対してのみ機能し、すべての人にそれを提供したくありません。見逃したグローバル変数はありますか?

テーブルに対して実行されたすべての更新をログに記録しようとしているので、IP アドレスとユーザー名までさかのぼって追跡できます。

これは ASE 12.5 の場合です。

4

1 に答える 1

1

あなたがしようとしている場合

テーブルに対して実行されたすべての更新をログに記録し、IP アドレスとユーザー名までさかのぼって追跡できるようにします

トリガーは間違いなく間違った方法です。トリガーはそのために設計されたものではなく、そのために設計された他の ASE 機能があります。テーブルについてではなく、セキュリティと監視全般についてです。

  1. Sybase 監査。
    MAD テーブルよりもはるかに少ないオーバーヘッドで、少しセットアップが必要です。しかし、最も重要なことは、監査用に設計されていることです (MDA はそうではありませんでした)。また、MDA などのコーディング要件はありません。高度な設定が可能で、必要なものだけをキャプチャし、それ以上はキャプチャしないという考え方です。

  2. モニタリング。
    MDA テーブルはお勧めしませんが、それらを配置し、監視を有効にし、SQL テキストをキャプチャするための 22% のオーバーヘッドを受け入れているため... 情報は非常に一時的なものです。あなたのような関連する目的でそれらを使用するには、必要なすべての情報をアーカイブデータベースにアーカイブして、キャプチャと保存のメカニズムを作成する必要があります。これは継続的に実行する必要があり、トリガーなどとは完全に独立しています。保存されているデータの量を減らすために、その場でフィルタリングすることもできます (警告、それは巨大です)。7 日以上前のデータを消去するなど。それ自体は小さなプロジェクトであり、サードパーティから市販されているのはそのためです。

これらの機能のいずれかが配置されると、個別に、誰がいつどこからテーブルを更新したかを知りたいときはいつでも、アーカイブを検査するだけで済みます。トリガーとは関係ないか、トリガーから情報を取得するのが難しいか、通常のユーザーに管理者権限を付与します。

また、通常のセキュリティが設定されていないことを理解する必要があります。テーブルはユーザーによって直接更新されています。したがって、直接更新のアクセス許可が特定のユーザー、またはさらに悪いことにすべてのユーザーに付与されています。その結果、誰がテーブルを更新しているのか、誰がデータや参照整合性を壊しているのかを知る方法がありません。

  • 安全な方法は、トランザクション全体をストアド プロシージャに配置することです。これにより、トランザクションが不完全になる可能性がなくなります (実行速度も向上します)。また、テーブルではなく proc に対するアクセス許可を付与することで、直接の更新を排除します。時間が経つにつれて、サーバーにセキュリティを実装したい場合があります。これにより、結果を追跡して 1 つずつ閉じる必要がなくなります。これは、終わりのないプロセスです。

監査に関する限り、セキュリティが整っていれば、監査の負担も大幅に軽減されます。ストアド プロシージャの実行のみを監査する必要があります。それ以外の場合は、すべてのテーブルに対するすべての更新を監査する必要があります。

于 2010-10-24T00:07:14.600 に答える