Mostrando entradas con la etiqueta auditoria. Mostrar todas las entradas
Mostrando entradas con la etiqueta auditoria. Mostrar todas las entradas

Auditoría en Bases de Datos Sql Server

Estoy recibiendo algunas consultas a través del correo electrónico, y trato de responder lo mejor posible, a pesar que prefiero que dejen un comentario en uno de mis blogs y otra cosa es que no me apuren, los deseos de ayudar son grandes, pero no el tiempo, que siempre queda chico, este mes de Marzo ha sido muy ocupado y he descuidado mis blogs, dandome cuenta que he disminuido la cantidad de entradas, cuando mi intención era aumentarlas. Pero hoy día trataré de responder a una interesante consulta hecha por un lector, que pregunta cual sería la estructura de una tabla de auditoría para una base de datos.

La primera forma: Añadir campos a una tabla



El modo más simple de auditar una tabla es registrando cada cambio fila por fila, sin embargo también es la menos recomendable. Se basa en añadir uno o dos campos testigos que registren la fecha en que se realizen cambios y el usuario que los efectúe, sin embargo cambios en cada columna no son registrados ni auditados, sólo se registra el último usuario que haya hecho un cambio. Por ejemplo si Pilar hace un cambio en la columna "Precio" y luego Juan cambia el valor de la columna "Cantidad" sólo quedará registrado que Juan hizo un cambio. Este tipo de auditoría es algo ingenua pero que puede servir en algunos casos.

Una segunda forma: Triggers y Tablas Espejo


Sql Server tiene en los triggers (desencadenadores o disparadores) una ayuda para llevar a cabo registros de auditoría. Esta forma tiene el siguiente procedimiento:
1. Crear una tabla espejo con los mismo campos que la tabla auditada pero con campos adicionales, como el usuario que haya hecho el cambio, la fecha y la operación realizada que puede ser fila agregada, fila modificada o fila eliminada.
2.Añadir triggers INSERT, UPDATE y DELETE a la tabla origen, de modo que al efectuarse cualquiera de las operaciones indicadas, grabe el mismo registro en la tabla de auditoría, incluyendo los campos de auditoría (usuario,fecha,tipo de operacion).
Esta forma de auditoría, si bien es mejor que la anterior ya que registra cada cambio realizado y almacena un historial completo para cada fila, impone una sobrecarga de operaciones por cada fila, ya que se vuelve a registrar la misma fila con datos adicionales en caso sea insertada, actualizada o eliminada. Y a la vez aumenta el espacio a ocupar.

Manejar datos de auditoría


El almacenar datos de auditoría ocupa una gran cantidad de espacio en disco duro, y manejar esa información se hace muy complicada, especialmente si se realiza con tablas espejo. Hay que saber manejar esa información, y auditar las tablas necesarias.
Una forma de manejarla es almacenando la información de auditoría en otra base de datos. Se crea una base de datos, y preferiblemente almacenarla en otra partición u otro disco duro si la actividad es intensa. Esto aumenta la complejidad de la auditoría, ya que hay que propocionar permisos a los usuarios para grabar información en la segunda base de datos. Se podría crear una vista en la base de datos auditada que muestre los datos en la base de datos de auditoría para darle un nivel de abstracción.

Archivamiento


Generar información de auditoría es un problema para el espacio, y generar mucha data es peor aún. Hay que diseñar un plan de archivamiento de esos datos, no tenerlo es lo peor que se puede hacer.
Un plan de archivamiento podría ser simplemente separar la base de datos de auditoría y crear una nueva. La desventaja sería el extraer información de la base de datos separada. Otra sería programar un script que extraiga o inserte la información, según sea el caso, y grabarla en cintas o cd. En cualquier caso la recuperación y volcado se hace manual y complica la tarea.

Conclusión


Generar data de auditoría en una base de datos es una ventaja y a la vez un problema ya que acarrea costos en espacio de almacenamiento y tiempo en manejarla. Pero aún así es necesaria en ciertas actividades, especialmente la financiera. Como recomendación, la auditoría debería realizarse a ciertas tablas de una base de datos y no a todas, ya que complicaría aún más el proceso de administración.

9 peligros de seguridad en Sql Server

En SearchSqlServer.com dan una lista con los 9 peligros de seguridad más comunes en el trabajo de un administrador de bases de datos:

  1. Ejecutar aplicaciones con privilegios de administrador y dejar al front-end controlar la seguridad del la base de datos.
  2. Los administradores de bases de datos usan cuentas de nivel de administrador para las tareas diarias que no requieren tales privilegios.
  3. Multiples administradores tienen en sus manos los mismos sistemas.
  4. Se comparten las cuentas de administrador de Windows para manejar la base de datos.
  5. No se usan procedimientos almacenados donde son posibles.
  6. No se crean vistas de la base de datos basadas en permisos de usuarios o grupos.
  7. Los registros de auditoría no son revisados.
  8. Multiples administradores para la administración del almacenamiento y copia de seguridad de la base de datos.
  9. Nula o casi inexistente clasificación para ubicar a cada base de datos sobre el mismo nivel de importancia.
Leer el artículo original.

Auditando tablas y bases de datos en Sql Server


En Sql Server Central, publicaron un artículo donde se daban consejos para realizar una auditoría de base de da tos y realizar un seguimiento de los cambios realizados en una tabla.

La primera recomendación es agregar unos campos adicionales a la estructura de la tabla sometida a auditoría, algo como:

ModificadoPor varchar(40)
Modificado datetime
Accion char(1)

Con estos campos, que almacenan el valor de quién modificó la fila, la fecha y la acción realizada. De ese modo, se tenía un registro de los cambios en la tabla.

La segunda era crear una tabla espejo, es decir no modificar la tabla original, pero crear una tabla con la misma estructura. Digamos que si la tabla es Facturas, la tabla espejo sera Facturas_Auditoria, a la que hay que añadir los campos mencionados anteriormente. Para cada acción en la tabla original se graba una fila en la tabla de auditoría.

El creador del artículo, Steve Jones, menciona luego las ventajas y desventajas. La ventaja principal es que se puede llevar un historial fila por fila, de ese modo, se podrá saber los cambios hechos. La desventaja es una sobrecarga de transacciones, y un aumento del tamaño de la base de datos. Este tipo de auditoría también conlleva un estricto control en las aplicaciones para no obviar el paso, Jones lo recomienda para aplicaciones financieras, y no en todas las tablas, solo algunas, las más importantes.

Haz clic aquí para leer el artículo completo en inglés.