Auditoría para DISABLE/ENABLE Disparadores EN SQL

Question

Necesito una forma de auditar cuando alguien intenta HABILITAR o DESACTIVAR un desencadenador en nuestra base de datos. La alternativa DDL gatillo funciona muy bien, pero sólo bajo la condición para que cuando el usuario utiliza

ALTER TABLE <tableName> ENABLE TRIGGER <triggerName> 

O

ALTER TABLE <tableName> DISABLE TRIGGER <triggerName> 

comunicado. Por lo que he determinado, el método DDL hace inútil si el usuario ejecuta las siguientes afirmaciones que no utilizan el comando ALTER:

DISABLE TRIGGER <triggerName> ON <tableName> 
ENABLE TRIGGER <triggerName> ON <tableName> 

he tenido varios pensamientos en la captura de estos eventos ninguno de ellos funciona. Uno de los cuales era si podía acceder a la tabla subyacente a la vista sys.triggers, podría colocar un disparador de inserción/actualización en esa tabla y filtrar el nombre del disparador para adquirir la auditoría; pero mi sospecha es que probablemente conduciría a una recursión infinita incluso si fuera posible.

¿Alguien aquí tiene alguna sugerencia posible para soluciones alternativas a este problema? No entiendo por qué MS permitiría versiones mejoradas de declaraciones para escapar del alcance de las auditorías. Es decir, auditar desde los métodos más simples; el uso del perfilador de SQL parece ser innecesario para esto.

Answer 1

En primer lugar abordaría esto a través de permisos. Nadie, excepto algunos dbas, debe tener permisos de tabla de modificación en prod y, por lo tanto, no puede usar enable o disable trigger. Si una aplicación lo está usando, eso debería detenerlo. No hay excusa para que ningún usuario tenga que modificar las tablas. Si quieres hacer eso, probablemente tienes un defecto de diseño. Si tienes personas que realmente desactivan los desencadenantes, definitivamente tienes un defecto de diseño. Cualquier código con un activador de desactivación debe ser una gran bandera roja durante la revisión del código. Debería ser inaceptable desactivar un desencadenador en el código de la aplicación. Esto es algo que solo debe hacer dbas que tenga la experiencia para saber cuándo hacerlo. Si está escribiendo un código de aplicación y parece necesitar deshabilitar un desencadenante para que funcione su código, entonces su código es incorrecto o el desencadenador necesita ser reescrito, deshabilitar desencadenadores debería ocurrir solo en los casos más raros.