AGREGAR UN SIMPLE TRIGGER PARA AUDITAR TU BASE DE DATOS SQL SERVER

Despues de pasar muchas horas pensando, debuggiando y buscandole la vuelta a una solucion que
consistia en hacerle una auditoria a una base de datos SQL 2005, pudimos desarrollar una
herramienta llamada SQLTableHistory esta herramienta nos da la facilidad de que podemos
seleccionar las tablas que queremos auditar.

Pero navegando me encontre con una excelente solucion hecha por Jon Galloway, en la cual consiste
en crear un solo script y que este se encarge de crear los triggers necesarios para cada tabla de la
base de datos seleccionada, la diferencia con SQLTableHistory es que con nuestra herramienta
podemos seleccionar las tablas que queremos que se le haga su respectiva auditoria y con la solucion
presentada en este blog.

Aqui un ejemplo de como se verian los datos con la solucion de Jon Galloway

Con esta informacion podemos hacer reportes de una manera sencilla tales como:

 Cuales tablas han sufridos cambios recientemente.

 Cuales tablas no sufrieron cambios el pasado año.
 Cuales tablas jamaz han sufrido cambios.
 Mostrar todos los cambios a las tablas por un usuario y periodo especifico.
 Mostrar las tablas mas activas en un determinado periodo.

Con estas herramientas es posible volver al estado anterior de la tabla y volver en un punto
especifico, claro esta ya depende de las nuevas extensiones que ustedes le hagan.

Aqui os dejo el script completo que crea la tabla de auditoria y corre el script para crear los triggers a
todas las tablas de la base de datos.

USE MYDATABASE--Ponerle el nombre de la base de datos que va hacer auditada

GO

IF NOT EXISTS(SELECT * FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME= 'Audit
')

CREATE TABLE Audit

AuditID [int]IDENTITY(1,1) NOT NULL,

Type char(1),
TableName varchar(128),

PrimaryKeyField varchar(1000),

PrimaryKeyValue varchar(1000),

FieldName varchar(128),

OldValue varchar(1000),

NewValue varchar(1000),

UpdateDate datetime DEFAULT (GetDate()),

UserNamevarchar(128)

GO

DECLARE @sql varchar(8000), @TABLE_NAMEsysname

SET NOCOUNT ON

SELECT @TABLE_NAME= MIN(TABLE_NAME)

FROM INFORMATION_SCHEMA.Tables

WHERE

TABLE_TYPE= 'BASE TABLE'

AND TABLE_NAME!= 'sysdiagrams'

AND TABLE_NAME!= 'Audit'

WHILE @TABLE_NAMEIS NOT NULL

 BEGIN

EXEC('IF OBJECT_ID (''' + @TABLE_NAME+ '_ChangeTracking'', ''TR'') IS NOT NULL

DROP TRIGGER ' + @TABLE_NAME+'_ChangeTracking')

SELECT @sql =

'

create trigger ' + @TABLE_NAME+ '_ChangeTracking on ' + @TABLE_NAME+ ' for

insert, update, delete
as

declare @bit int ,

@field int ,

@maxfield int ,

@char int ,

@fieldname varchar(128) ,

@TableName varchar(128) ,

@PKCols varchar(1000) ,

@sql varchar(2000),

@UpdateDate varchar(21) ,

@UserName varchar(128) ,

@Type char(1) ,

@PKFieldSelect varchar(1000),

@PKValueSelect varchar(1000)

select @TableName = ''' + @TABLE_NAME+ '''

-- date and user

select @UserName = system_user ,

@UpdateDate = convert(varchar(8), getdate(), 112) + '' '' +

convert(varchar(12), getdate(), 114)

-- Action

if exists (select * from inserted)

if exists (select * from deleted)

select @Type = ''U''

else
select @Type = ''I''

else

select @Type = ''D''

-- get list of columns

select * into #ins from inserted

select * into #del from deleted

-- Get primary key columns for full outer join

select@PKCols = coalesce(@PKCols + '' and'', '' on'') + '' i.'' +

c.COLUMN_NAME + '' = d.'' + c.COLUMN_NAME

fromINFORMATION_SCHEMA.TABLE_CONSTRAINTS pk ,

INFORMATION_SCHEMA.KEY_COLUMN_USAGE c

where pk.TABLE_NAME = @TableName

andCONSTRAINT_TYPE = ''PRIMARY KEY''

andc.TABLE_NAME = pk.TABLE_NAME

andc.CONSTRAINT_NAME = pk.CONSTRAINT_NAME

-- Get primary key fields select for insert

select @PKFieldSelect = coalesce(@PKFieldSelect+''+'','''') + '''''''' +

COLUMN_NAME + ''''''''

fromINFORMATION_SCHEMA.TABLE_CONSTRAINTS pk ,

INFORMATION_SCHEMA.KEY_COLUMN_USAGE c

where pk.TABLE_NAME = @TableName

andCONSTRAINT_TYPE = ''PRIMARY KEY''

andc.TABLE_NAME = pk.TABLE_NAME

andc.CONSTRAINT_NAME = pk.CONSTRAINT_NAME

 
select @PKValueSelect = coalesce(@PKValueSelect+''+'','''') +
''convert(varchar(100), coalesce(i.'' + COLUMN_NAME + '',d.'' + COLUMN_NAME +
''))''

from INFORMATION_SCHEMA.TABLE_CONSTRAINTS pk ,   

INFORMATION_SCHEMA.KEY_COLUMN_USAGE c  

where  pk.TABLE_NAME = @TableName  

and CONSTRAINT_TYPE = ''PRIMARY KEY''  

and c.TABLE_NAME = pk.TABLE_NAME  

and c.CONSTRAINT_NAME = pk.CONSTRAINT_NAME

if @PKCols is null

begin

raiserror(''no PK on table %s'', 16, -1, @TableName)

return

end

select @field = 0, @maxfield = max(ORDINAL_POSITION) from

INFORMATION_SCHEMA.COLUMNS where TABLE_NAME = @TableName

while @field < @maxfield

begin

select @field = min(ORDINAL_POSITION) from INFORMATION_SCHEMA.COLUMNS where

TABLE_NAME = @TableName and ORDINAL_POSITION > @field

select @bit = (@field - 1 )% 8 + 1

select @bit = power(2,@bit - 1)

select @char = ((@field - 1) / 8) + 1

if substring(COLUMNS_UPDATED(),@char, 1) & @bit > 0 or @Type in (''I'',''D'')

begin

select @fieldname = COLUMN_NAME from INFORMATION_SCHEMA.COLUMNS where

TABLE_NAME = @TableName and ORDINAL_POSITION = @field

select @sql = ''insert Audit (Type, TableName, PrimaryKeyField,

PrimaryKeyValue, FieldName, OldValue, NewValue, UpdateDate, UserName)''
select @sql = @sql + '' select '''''' + @Type + ''''''''

select @sql = @sql + '','''''' + @TableName + ''''''''

select @sql = @sql + '','' + @PKFieldSelect

select @sql = @sql + '','' + @PKValueSelect

select @sql = @sql + '','''''' + @fieldname + ''''''''

select @sql = @sql + '',convert(varchar(1000),d.'' + @fieldname + '')''

select @sql = @sql + '',convert(varchar(1000),i.'' + @fieldname + '')''

select @sql = @sql + '','''''' + @UpdateDate + ''''''''

select @sql = @sql + '','''''' + @UserName + ''''''''

select @sql = @sql + '' from #ins i full outer join #del d''

select @sql = @sql + @PKCols

select @sql = @sql + '' where i.'' + @fieldname + '' <> d.'' + @fieldname

select @sql = @sql + '' or (i.'' + @fieldname + '' is null and  d.'' +
@fieldname + '' is not null)''

select @sql = @sql + '' or (i.'' + @fieldname + '' is not null and  d.'' +
@fieldname + '' is null)''

exec (@sql)

end

end

'

SELECT @sql

EXEC(@sql)

SELECT @TABLE_NAME= MIN(TABLE_NAME) FROM INFORMATION_SCHEMA.Tables

WHERE TABLE_NAME> @TABLE_NAME

AND TABLE_TYPE= 'BASE TABLE'

AND TABLE_NAME!= 'sysdiagrams'

AND TABLE_NAME!= 'Audit'

END

 
Para mas informacion:
Construcción de un sistema de auditoría con triggers en
Microsoft SQL Server

Por Mariano Minoli.

Introducción

La auditoria de sistemas es un punto importante a considerar en sistemas cliente / servidor en los cuales
existe una multitud de usuarios trabajando sobre una misma fuente de datos. Cuando dichos sistemas son
de pequeño porte y poseen pocos usuarios el problema podría parecer trivial, pero a medida que la
envergadura del sistema crece y (sobre todo) la cantidad y variedad de usuarios es mayor, la auditoria se
convierte en un punto difícil de manejar. En este artículo se intenta presentar dos soluciones posibles al
problema y desarrollar una de ellas en la cual solo se utiliza transact-SQL, por último se darán las bases
para automatizar la instalación de la solución presentada y algunas consideraciones y optimizaciones
posibles.

Sobre auditoría

Antes que nada habría que aclarar a que nos referimos cuando hablamos de "auditoria". En este ámbito, con
auditoria nos referimos al seguimiento de las operaciones realizadas por cada usuario, básicamente llevar un
control de "que se hace", "quien lo hace (el Usuario)", "en donde se hace", y "cuando se hace".
El concepto no es nuevo, en los entornos mainframe suele ser llamado "el login del sistema", aquel lector
que esté relacionado con la jerga entenderá que nos referimos a lo mismo, solo diferimos en la forma de
implementarlo.
También podría hallarse una cierta analogía con los eventos visualizados en la sección de Seguridad del
Visor de Eventos de Windows NT/2000.

Diferentes enfoques para un mismo problema

Primero buscaremos donde almacenar la información, mas allá de cómo hacerlo. Puede que el lector esté
pensando en una tabla en la cual se almacenen datos que contesten a las preguntas hechas en el párrafo
anterior, no vamos a contradecirlo: las dos soluciones propuestas incluyen una tabla almacenada en la base
de datos. El formato de la tabla puede variar dependiendo de las necesidades específicas del entorno,
nosotros proponemos la siguiente, a los efectos del desarrollo:
El script para la creación de la tabla es:

CREATE TABLE [dbo].[AUDIT] (

[id_evento] [int] IDENTITY (1, 1) NOT NULL ,
[tipo_evento] [char] (10) NOT NULL ,
[fecha] [datetime] NOT NULL ,
[descripcion] [char] (50) NULL ,
[usuario] [char] (30) NULL ,
[terminal] [char] (30) NULL ,
[aplicacion] [char] (30) NULL) ON [PRIMARY]GOALTER TABLE [dbo].[AUDIT] WITH NOCHECK ADD
CONSTRAINT [PK_AUDIT] PRIMARY KEY NONCLUSTERED ( [id_evento] ) ON [PRIMARY]
GO
Ahora que sabemos donde vamos a almacenar la información, necesitamos determinar como vamos a
hacerlo. Presentamos dos opciones:

1. Delegar la responsabilidad en la lógica de negocio de la aplicación.

2. Crear disparadores en cada tabla que se desee auditar.
1er opción: Delegar la responsabilidad en la lógica de negocio de la aplicación.

Con esto nos referimos a que dentro del código encargado de hacer modificaciones a los datos, se realicen
las inserciones a la tabla AUDIT, de este modo, cualquier operación generará un registro de auditoria. La
ubicación del código (responsable de las inserciones) dependerá de la arquitectura que utilice el
desarrollador, ya sea en una arquitectura de dos o tres capas, en donde se concentre la lógica de negocio de
la aplicación, allí estará el código encargado de realizar las inserciones de auditoria.

2da opción: Crear disparadores en cada tabla que se desee auditar.

De este modo, cada tabla (que se desee auditar) tendrá un disparador (o trigger) que, cada vez que detecte
una modificación en la tabla, inserte un registro en la tabla de auditoria. Si el lector desconoce el concepto
de disparador, en las secciones siguientes describiremos en detalle de que se trata, por ahora veámoslo
como "algo" que está "latente" en la base de datos que, al detectar una modificación en los datos de una
determinada tabla, ejecuta una serie de sentencias Transact - SQL previamente configuradas.

La opción que se va a desarrollar es la segunda, la decisión no es arbitraria, obedece a una serie de ventajas
que se detallan a continuación:
Primero que nada, el hecho de descargar lógica del lado del cliente suele ser PELIGROSO, en este caso las
aplicaciones se hacen mas complejas de programar y mantener. Si se usan disparadores como solución se
esta reutilizando código implícitamente, cualquier nueva aplicación que acceda a una tabla existente, será
"automáticamente" auditada sin necesidad de escribir una sola línea de código de más.
Además, hay que tener en cuenta que si el sistema es accedido a través de Webforms (ASP.Net) no será
bueno cargar al cliente de trabajo que se debería concentrar del lado del servidor.
Por último, como hemos dicho antes, es posible que existan "múltiples usuarios" accediendo de "múltiples
maneras" al gestor. Muchas de estas "maneras" pueden no ser aplicaciones propietarias, un usuario por
ejemplo podría acceder a través del Query Analyzer y ejecutar una sentencia delete a una tabla cualquiera,
si la auditoria se encuentra en el cliente que hemos programado, nunca sabremos quien fue. El lector debe
tener en cuenta que NO existe manera de modificar datos en una base de datos SQL Server y evitar que se
ejecuten los disparadores que estén asociados a estos datos.
Conceptos teóricos y construcciones utilizadas
Para poder comprender correctamente las secciones siguientes, es necesario tener claros algunos conceptos
de teoría de bases de datos y la sintaxis de algunas sentencias:

Desencadenador (trigger)
Podría definirse como un tipo especial de procedimiento almacenado que se ejecuta automáticamente
cuando un usuario intenta modificar datos sobre una tabla determinada. Los disparadores se almacenan en
la base de datos en forma similar a los procedimientos almacenados, sin embargo NUNCA son ejecutados
explícitamente por los usuarios, sólo se disparan cuando el gestor detecta una modificación.

Existen tres tipos de disparadores, uno para cada tipo de actualización:

Eliminación
Inserción
Modificación

La sintaxis que utilizaremos durante este desarrollo para la creación de disparadores es la siguiente:

CREATE TRIGGER nombre_trigger ON tabla

[WITH ENCRYPTION]
{ {FOR { [DELETE] [,] [INSERT] [,] [UPDATE] }
AS sentencia_sql [...n]}
Cabe aclarar que existen otras opciones adicionales que no son utilizadas durante este desarrollo.

Sentencia insert utilizada con un select

Debido a que no es la sintaxis más popular de un insert, nos pareció interesante explicarle que se va a
utilizar la cláusula de la siguiente manera:

Insert into TABLA _ DESTINO

Select * from TABLA _ ORIGEN
Esta sentencia inserta todos los registros obtenidos como el resultado de la consulta a la TABLA_ORIGEN en
la TABLA_DESTINO
Execute
Puede ser utilizado para ejecutar un procedimiento almacenado o (como en nuestro caso) para ejecutar un
conjunto de sentencias Transact-SQL que es pasada como un string, esto nos permite "armar" la sentencia
concatenando partes fijas con variables que van tomando distintos valores.

Las funciones getdate(), host_name(), SYSTEM_USER, APP_NAME

Usamos estas funciones para "capturar" valores que nos interesa almacenar en la tabla AUDIT. Sus
significados son:

Getdate(): Fecha-hora actual del sistema.

SYSTEM_USER: Nombre del usuario que envía una sentencia al servidor.
host_name(): Nombre de la maquina cliente desde donde se envía la sentencia.
APP_NAME: Nombre de la aplicación cliente a través de la cual se envía la sentencia.

Desarrollo
Con lo que se ha explicado hasta el momento, poco nos resta para implementar el sistema de auditoria,
simplemente hay que crear un disparador por cada tabla que se quiera auditar, el disparador tiene que
ejecutar un insert a la tabla AUDIT, veámoslo con un ejemplo. Supongamos una tabla CLIENTES, que
presenta la siguiente estructura (muy simplificada, solo para fines demostrativos):

La sentencia de creación de esta tabla es:

CREATE TABLE [dbo].[CLIENTES] (

[id_cliente] [int] NOT NULL ,
[Nombre] [char] (50) NOT NULL)
ON [PRIMARY]
GO
Para esta tabla las sentencias de creación de los disparadores son las siguientes:
CREATE TRIGGER AUDITdel ON CLIENTES
FOR DELETE
AS
Insert into AUDIT select "Delete", getdate(), "Eliminacion de un registro", SYSTEM_USER,
host_name(),APP_NAME()
CREATE TRIGGER AUDITins ON CLIENTES
FOR INSERT
AS
insert into AUDITselect "Insert", getdate(), "Insercion de un registro", SYSTEM_USER,
host_name(),APP_NAME()
CREATE TRIGGER AUDITdel ON CLIENTES
FOR UPDATE
AS
insert into AUDITselect "Update", getdate(), "Modificacion de un registro", SYSTEM_USER,
host_name(),APP_NAME()
Cabe aclarar que lo mismo se podría hacer de una manera más "amigable" desde el Administrador
Corporativo (Enterprise Manager).
Habiendo creado los tres disparadores sobre la tabla clientes, intente hacer cualquier operación que
modifique los datos de la misma, por ejemplo podría ejecutar las tres sentencias siguientes:

Insert into CLIENTES values (2356, "Juan Perez")

Go
Update CLIENTES set Nombre = "Ricardo Perez"
where id_cliente = 2356
Go
Delete CLIENTES where id_cliente = 2356
Si analiza la tabla AUDIT verá que las sentencias ejecutadas accionaron los disparadores que se habían
creado. Éstos insertaron un registro por cada modificación efectuada a la tabla. Verifique con la siguiente
consulta:
select * from AUDIT
Optimización 1: Creación de un Procedimiento Almacenado que automatice la instalación del
sistema
Con lo visto hasta el momento, ya esta en condiciones de crear sus propios disparadores sobre cada tabla
que desee auditar, ahora suponga que quiere auditar con este método la base de datos corporativa, en la
cual se alojan datos referentes a todos los subsistemas de la organización. Suponga que las tablas a auditar
son 300.

¿No le interesa la idea de automatizar la instalación de los disparadores?

Lo que se presenta a continuación es un procedimiento almacenado que encapsula la creación de los tres
disparadores para una tabla determinada que es pasada como parámetro de entrada:

CREATE PROCEDURE sp_instalarTrigger

@tabla as char(128)
as
-- Aseguramos que el parametro de entrada esté libre de espacios
set @tabla = ltrim(rtrim(@tabla))
-- Creacion del trigger para ELIMINACION
EXECUTE ('CREATE TRIGGER AUDITdel_' + @tabla +' ON ' + @tabla +' FOR DELETE AS Insert into
AUDITselect "Delete", getdate(), "Eliminacion de un registro", SYSTEM_USER,
host_name(),APP_NAME()')
-- Creacion del trigger para INSERCIONEXECUTE ('CREATE TRIGGER AUDITins_' + @tabla +' ON '
+ @tabla +' FOR INSERT AS Insert into AUDITselect "Insert", getdate(), "Insercion de un
registro", SYSTEM_USER, host_name(),APP_NAME()')
-- Creacion del trigger para MODIFICACIONEXECUTE ('CREATE TRIGGER AUDITupd_' + @tabla +' ON
' + @tabla +' FOR UPDATE AS Insert into AUDITselect "Update", getdate(), "Modificacion de
un registro", SYSTEM_USER, host_name(),APP_NAME()')
Por ejemplo, para nuestra tabla sería:
Exec sp_instalarTrigger "CLIENTES"
Un segundo paso para lograr una instalación totalmente automática podría ser crear otro procedimiento
almacenado que:
Cargue un cursor con todas las tablas de usuario a través de un select de la tabla sysobjects (con la
condición de que el campo xtype sea "U").
Luego ejecute el procedimiento almacenado antes creado por cada registro dentro del cursor.
Sin embargo debe ser cuidadoso con este enfoque de "instalación masiva" porque la sobrecarga de
procesamiento que existirá en el servidor a partir de la instalación de los disparadores podría no ser
aceptable (o deseable) en todas la tablas, mas adelante hablaremos de ello.
Optimización 2: Personalización del mensaje grabado (tablas inserted y deleted)Si analiza la tabla AUDIT
que se ha propuesto verá que uno de los campos es "descripción". Hasta el momento hemos estado
insertando una cadena fija que presenta una suerte de descripción acerca del evento que dispara el
disparador, en realidad ese campo está pensado para guardar una descripción detallada del evento ocurrido,
¿cuán detallada?, todo lo detallada que el usuario considere necesario y esté dispuesto a programar.

A continuación desarrollamos un ejemplo práctico para el disparador que controla la eliminación, en donde
utilizamos la tabla "deleted", ésta es una tabla temporal a la cual se puede tener acceso dentro de un
disparador, de este modo podemos recuperar los datos que están siendo eliminados y que han disparado la
ejecución del disparador (nótese que también se podría utilizar la tabla temporal inserted accesible desde
los disparadores para inserción).
Lo que vamos a hacer es recuperar el nombre del cliente que se está eliminando y lo vamos a guardar en el
campo descripción de la tabla AUDIT.
De este modo reformulamos la creación del disparador de la siguiente manera:

-- Primero eliminamos el trigger que se habia creado anteriormente

if exists (select * from sysobjects where id =object_id(N'[dbo].[AUDITdel_CLIENTES]') and
OBJECTPROPERTY(id, N'IsTrigger') = 1)
drop trigger [dbo].[AUDITdel_CLIENTES]
GO
-- Luego creamos el trigger para ELIMINACION con el mensaje personalizado
CREATE TRIGGER AUDITdel_CLIENTES ON CLIENTES FOR DELETE
AS
Insert into AUDIT select "Delete",getdate(), (select "Nombre eliminado: " + convert(char(15),Nombre) from
deleted) ,SYSTEM_USER, host_name(),APP_NAME()
Con este enfoque se podrían almacenar todos los datos antes de una eliminación para poder reconstruir un
registro si es necesario, aunque si su aplicación hace eliminaciones masivas (es decir de mas de dos
registros), debería replantear la inserción a la tabla AUDIT recorriendo, por ejemplo, un cursor armado con
una consulta a la tabla deleted.Aquí cabe una aclaración: el código Transact-SQL que se encuentra dentro
del trigger puede estar compuesto por bucles, condicionales, casi cualquier construcción Transact-SQL
válida, sin embargo deberá tener en cuenta que toda la demora que introduzca este código impactará
directamente en cada una de las operaciones que los usuarios hagan sobre los datos.

Encriptación de los disparadores

Una consideración que podría ser importante es la de encriptar el código de los disparadores creados, de
este modo evitará que se conozca cómo y donde se está almacenando la información de auditoria, mas allá
de que luego restrinja el acceso a la tabla AUDIT. El código debe ser encriptado al momento de la creación
del disparador a través de la cláusula "WITH ENCRYPTION", para nuestro disparador de eliminación sería:
-- Primero eliminamos el trigger que se había creado anteriormente
if exists (select * from sysobjects where id =object_id(N'[dbo].[AUDITdel_CLIENTES]') and
OBJECTPROPERTY(id, N'IsTrigger') = 1)drop trigger [dbo].[AUDITdel_CLIENTES]
GO
-- Luego creamos el trigger para ELIMINACION con el mensaje personalizado y ENCRIPTADO
CREATE TRIGGER AUDITdel_CLIENTES WITH ENCRYPTION ON CLIENTES FOR DELETE
AS
Insert into AUDIT select "Delete",Getdate(), (select "Nombre eliminado: " +
convert(char(15),Nombre) from deleted) ,SYSTEM_USER, host_name(),APP_NAME()
Conclusiones
Hemos visto como, a partir de unas simples sentencias de Transact-SQL , se puede crear todo un sistema
que realice un seguimiento muy detallado de las operaciones de los usuarios sobre los datos. Además vimos
que su diseño es flexible y puede ser personalizado para necesidades específicas.
Si desea, puede completar el desarrollo creando una interfaz gráfica que acceda a la tabla AUDIT y permita
hacer consultas con filtros configurables por el usuario, emitir reportes, etc.