Audit Trail en la aplicación web utilizando el servidor sql

Question

Estamos desarrollando una aplicación web que utiliza los servidores asp.net y sql. Estamos obligados a hacer un seguimiento de auditoría para la aplicación. Según entiendo esto, una pista de auditoría sería básicamente para todos los Insertos, Actualizaciones y Eliminaciones en la base de datos ¿verdad? Ahora, la forma de abordar esto es que tengo una tabla de seguimiento de auditoría en la base de datos que se completa después de que se activa cada inserción, actualización o eliminación (escribiendo manualmente la secuencia de comandos dentro de la DAL). Sin embargo, cualquier cambio de DB directamente generado desde SQL Management studio NO se grabará (por razones obvias: P).

Para atender a eso, pude crear un disparador y eso se encarga de todo. También busqué en Google y descubrí que SQL Server tiene la capacidad de hacer un seguimiento de auditoría. Sin embargo, el problema con el uso de desencadenantes es que NO obtendré la información del usuario que inició sesión en el sitio web. Voy a obtener el usuario sql, pero no me importa dos veces, me preocupa el usuario del sitio web.

Una solución que descubrí que era a) Tengo un seguimiento de auditoría de mi aplicación web y también tengo la configuración de desencadenante. En el informe de auditoría, simplemente muestro un registro de auditoría de la aplicación web y un registro de auditoría del servidor sql. Problemas obvios con este enfoque: excesivo. Escribir en dos conjuntos diferentes de tablas en CADA DB CAMBIO.

b) Tengo una columna llamada UserId EN CADA BASE DE DATOS. Luego creo un disparador para capturar todos los cambios DB. Paso esta ID de usuario en cada tabla que cambio (insertar, actualizar, eliminar) y obtengo esta identificación del desencadenador. Retrasos obvios: columna de ID de usuario innecesario en cada tabla

Me disculpo por la publicación larga. Básicamente, necesito un registro de auditoría que registre todos los cambios de db (incluido el acceso directo a db), pero al mismo tiempo me da información de inicio de sesión para los cambios de db realizados desde la aplicación web.

Agradecerán cualquier comentario al respecto.

Muchas gracias

xeshu

Answer 1

¿Cuán probable es que no va a haber cambios legítimos realizados en la base de datos mediante la ejecución directa consultas SQL contra la base de datos ya sea a través del estudio de administración de SQL o de otro tipo. Lo recomiendo suponiendo que todos los datos de los datos se ingresan a través de su aplicación y tienen la auditoría en su capa BL. A continuación, puede limitar el acceso a la base de datos a usuarios de confianza. En última instancia, tiene que haber uno o más usuarios con permiso para alterar el esquema de la base de datos. Si esos usuarios quisieran eludir la auditoría, simplemente podrían desactivar los factores desencadenantes o falsificar la pista de auditoría. Si alguna vez hay razones legítimas para ejecutar consultas SQL directas contra la base de datos, p. Importaciones de datos poco frecuentes desde otros sistemas, etc., puede limitar esta actividad a los usuarios de confianza y asegurarse de que sus scripts de importación llenen correctamente la tabla de auditoría. Cualquier cosa que coloque demasiada carga de trabajo en sus DBA o en quienes sean los usuarios de confianza debería integrarse en la aplicación de todos modos.

Answer 2

suena como que está en la dirección correcta. Sin embargo, generalmente no tendrías una sola tabla de seguimiento de auditoría, sino una tabla de auditoría para cada tabla. Por lo tanto, para cada modificación de una fila en la Tabla A, se agrega una nueva fila a TableA_Audit que contiene el nuevo estado en la Tabla A, más la fecha y el nombre del usuario.

Normalmente se usa un disparador, pero si está almacenando el nombre de usuario de la aplicación web, no sé cómo pasar esta información a un desencadenador (¿alguien más puede ayudar?) En este caso, podría ser tentado de usar procedimientos almacenados. Para cada tabla, tenga procedimientos almacenados para insertar, actualizar y eliminar filas. Estos procedimientos almacenados llamarían cada uno a otro procedimiento almacenado que inserta la fila en la tabla de auditoría. De esta forma, transfiere fácilmente el nombre de usuario de la aplicación web al procedimiento almacenado que inserta la fila en la tabla de auditoría. Obviamente, la desventaja es tener que mantener un conjunto de procedimientos almacenados para cada tabla, lo cual puede ser un poco tedioso ya que debe asegurarse de que todos sigan las tablas (y la capa de acceso a datos de la aplicación) ya que los cambios de esquema son inevitablemente necesarios .

Tenga en cuenta que no necesita una columna de nombre de usuario en cada tabla, solo en cada tabla de auditoría.

Espero que algo de eso haya sido de utilidad.

Saludos

David

Answer 3

Estoy de acuerdo con los otros dos afiches. La conclusión es que si desea almacenar el nombre de usuario de su aplicación web (es decir, su autenticación personalizada), los activadores NO lo ayudarán a auditar lo que está sucediendo. - Advertencia a menos que pueda utilizar la Autenticación integrada

Esto es muy importante si también desea utilizar las pistas de auditoría para controlar los volúmenes de actividad del usuario, por ejemplo. La solución a esto es realizar todos los DDL a través de los procedimientos almacenados y, dentro de esos procedimientos almacenados, agregar su lógica de auditoría (si desea todos los registros escritos en T-SQL). Alternativamente, hágalo desde la aplicación y observe una de las muchas bibliotecas de registro disponibles para ASP.Net, como NLog.

Answer 4

Gracias a todos por sus respuestas. Después de algunos googlear este es el enfoque que creo que sería apropiado: Genérico tabla de auditoría

audit_table ( Id, NombreTabla, RecordID, (enlace al registro en cuestión) ModifiedBy, ModifiedOn, (Tipo I , u o D) )

Audit_Details_Table ( Id, IdAuditoría, FieldName, OldValue, NewValue)

Creo que esto debería hacerlo. ¿Alguna idea?