Realizar un seguimiento de los cambios hechos a los objetos de su base de datos es una parte clave de una estrategia de seguridad de bases de datos SQL o una política de cumplimiento de normas, incluyendo, entre otras, Health Insurance Portability and Accountability Act, Sarbanes-Oxley, Payment Card Industry Data Security Standard o European Union Data Protection Directive. De todas maneras, incluso si su ambiente IT no tiene que cumplir con reglas de seguridad rigurosas, quién lo ha cambiado así como el tiempo exacto de este cambio, es invaluable cuando se solucionan problemas relacionados con el esquema, como dependencias rotas. Así que, ¿cómo audita uno cambios en el esquema de SQL Server?

Simplemente archivar información para auditar una base de datos es una cosa, pero reconstruir un historial de auditoría exitosamente para proveer datos forenses significativos es otra. Es importante poder ver un historial completo de los cambios del usuario, así como poder revertir los cambios que pueden haber sido accidentales o maliciosos.

Idealmente, tal información del valor añadido puede ser obtenida sin requerir una gran cantidad de datos archivados o creando un impacto significativo en el desempeño en los servidores auditados.

En este artículo, vamos a presentar dos diferentes enfoque y soluciones para antes y después de la auditoría.

Un enfoque de auditoría continua de SQL Server debe incluir:

1. Auditoría continua
2. Recolección de datos en tiempo real
3. Habilidad de generar reportes significativos
4. Alertas de actividades no deseadas
5. Un almacenaje a prueba de modificaciones no deseadas de la auditoría de datos

En muchos casos, el requerimiento primario que debe cumplirse es que la auditoría se debe realizar con cero pérdidas de datos de auditoría..

La auditoría de bases de datos SQL Server no es usada solamente para cumplir con requerimientos de conformidad. Se ha vuelto necesaria para el análisis de acciones de bases de datos, soluciones de problemas y la investigación de actividades sospechosas y maliciosas. La auditoría también puede ayudar a evitar acciones inapropiadas de parte de los usuarios – como si tuviera un sistema CCTV en sus bases de datos.

Hay muchas técnicas de auditoría de SQL Server:

En la parte previa de la serie de artículos Métodos para auditar cambios en datos SQL Server, nosotros describimos muchas características de auditoría nativas de SQL Server – Change Tracking, Change Data Capture y Audit. Nosotros describimos sus características únicas y compartidas, cómo almacenan la información capturada, cómo proveen la información, y explicamos las ventajas y desventajas de cada característica.

Cada Administrador de Base Datos y desarrollador se esfuerza por estar en control de los servidores, bases de datos y datos SQL. Pero a veces la situación puede salirse de control y cosas inusuales comienzan a pasar.

Por ejemplo, usted ha notado que un valor de una columna específica de una tabla en su base de datos ha desaparecido. Usted ha verificado su código todo lo posible y no encontró nada que elimine el valor de la columna, los usuarios dicen que no lo eliminaron, usted ha verificado los permisos en esta tabla/columna y se dio cuenta de que ninguna eliminación desautorizada fue permitida. Pero algo está obviamente mal.

Uno de los tópicos de seguridad esenciales de SQL Server es encontrar quién hizo algo, qué y cuándo. La capacidad de proveer una historia de datos para varios propósitos de auditoría, algunos de los cuales son reforzados por leyes de Estados Unidos a través de regulaciones de cumplimiento, es una tarea seria para cualquier Administrador de Base de Datos. Dado que las políticas de negocios o las regulaciones de cumplimiento requieren la auditoría de cambios en los datos dentro de una base de datos, varias técnicas de adaptación a los requerimientos son usadas para realizar autorías a la base de datos. La común es usar desencadenadores de auditoría en bases de datos SQL Server.

Aunque las sentencias SELECT no son destructivas por naturaleza ni tampoco pueden cambiar datos o esquemas, hay muchos cases que requieren su auditoría en SQL Server. Las sentencias SELECT ejecutadas pueden indicar varios problemas actuales o potenciales, y esta es la razón por la cual es importante saber quién vio qué y cuándo.

Auditar una base de datos es el primer paso hacia mantenerse actualizado acerca de cambios en la base de datos. De todas maneras, si datos específicos y altamente sensitivos necesitan revisión, una notificación inmediata de cualquier cambio es preferible.

Mandar correos electrónicos de alerta a uno o más recipientes es una de las maneras más comunes de una notificación inmediata. Mandar correos electrónicos para cada cambio en una base de datos no es recomendado. En la mayor parte de los casos llenará su bandeja de entrada, y añadirá muchas acciones innecesarias, lo cual puede también afectar el desempeño global de la aplicación. Por lo tanto, es importante elegir los cambios de los que desea estar alerta con cuidado.