Cómo auditar accesos a tablas con SQL Server Audit

Saber quién accede a los datos sensibles es una de las bases de la gobernanza de datos. SQL Server Audit, una funcionalidad nativa de SQL Server, es la forma más fiable de auditar accesos a tablas: registra automáticamente cada lectura o cambio y ayuda a responder a la pregunta "¿quién vio esta información y cuándo?". Toda la configuración se hace en T-SQL y lleva pocos minutos.

Requisitos previos

• Una instancia de SQL Server (on-premises, en una VM o Azure SQL Managed Instance).
• SQL Server Management Studio (SSMS) o Azure Data Studio para ejecutar los comandos.
• Permisos de administrador — en concreto ALTER ANY SERVER AUDIT a nivel de servidor.
• Una carpeta en el servidor para guardar los archivos de auditoría, por ejemplo C:\Auditoria\.

Antes de empezar, conviene conocer las tres piezas de una auditoría: el Server Audit (donde se escriben los eventos), la Audit Specification (lo que se registra) y el destino (un archivo o el registro de Windows). Esta separación hace que el sistema sea flexible — un único Server Audit puede recibir eventos de varias bases de datos. Las configuraremos en ese orden.

Paso 1: Crear el objeto de auditoría

El primer paso es crear el Server Audit, la "caja fuerte" donde se escribirán los eventos. En este ejemplo escribimos en un archivo dentro de la carpeta preparada; SQL Server crea archivos .sqlaudit y los rota a medida que se llenan.

USE master;
GO
CREATE SERVER AUDIT Auditoria_Acessos
TO FILE (FILEPATH = 'C:\Auditoria\', MAXSIZE = 100 MB)
WITH (ON_FAILURE = CONTINUE);
GO

La opción ON_FAILURE = CONTINUE permite que SQL Server siga funcionando aunque, por algún motivo, no pueda escribir un registro — evita que la base de datos se detenga. En entornos muy regulados puede preferir SHUTDOWN, pero para empezar CONTINUE es lo más seguro.

Paso 2: Activar la auditoría

Cuando se crea, el objeto de auditoría queda desactivado. Debemos activarlo de forma explícita:

ALTER SERVER AUDIT Auditoria_Acessos
WITH (STATE = ON);
GO

A partir de este momento la "caja fuerte" está lista para recibir eventos. Solo falta indicarle qué registrar, y eso es lo que haremos en el paso siguiente.

Paso 3: Definir qué auditar

Ahora creamos una Database Audit Specification que describe las acciones a registrar. En el ejemplo queremos saber quién ejecuta un SELECT sobre la tabla dbo.Salarios de la base de datos RH — un caso típico de datos sensibles. La cláusula BY public abarca a todos los usuarios.

USE RH;
GO
CREATE DATABASE AUDIT SPECIFICATION Audit_Select_Salarios
FOR SERVER AUDIT Auditoria_Acessos
ADD (SELECT ON dbo.Salarios BY public)
WITH (STATE = ON);
GO

Puede añadir más líneas dentro de ADD (...), separadas por comas, para auditar también INSERT, UPDATE o DELETE en otras tablas. Registrar solo lo esencial mantiene los archivos pequeños y fáciles de analizar.

Consejo: evite auditar con SELECT tablas muy consultadas (como tablas de log de la aplicación). El volumen de registros crece rápido y dificulta el análisis. Empiece por las tablas con datos personales o financieros.

Paso 4: Consultar los registros

Los eventos se guardan en los archivos .sqlaudit. Para leerlos en un formato de tabla legible, use la función de sistema sys.fn_get_audit_file, indicando la ruta de los archivos con un comodín:

SELECT event_time,
       server_principal_name,
       database_name,
       object_name,
       statement
FROM sys.fn_get_audit_file('C:\Auditoria\*.sqlaudit', DEFAULT, DEFAULT)
ORDER BY event_time DESC;

Cada fila muestra el usuario, la fecha y la hora y el comando ejecutado. Puede filtrar el resultado por usuario o por período añadiendo una cláusula WHERE, algo útil cuando los archivos ya contienen muchos eventos — exactamente el rastro que necesita para investigar un acceso indebido o demostrar el cumplimiento del RGPD.

Verificar el resultado

Para confirmar que todo funciona, ejecute una consulta de prueba sobre la tabla auditada y vuelva a leer el registro:

SELECT * FROM RH.dbo.Salarios;   -- la acción que queremos capturar

Al ejecutar de nuevo la consulta a sys.fn_get_audit_file del paso anterior, debería aparecer una nueva fila con su nombre de usuario y el comando SELECT. Si esa fila aparece, la auditoría está operativa y registrando accesos en tiempo real.

Conclusión

En cuatro pasos ha creado un mecanismo que registra quién accede a los datos sensibles — un pilar esencial de cualquier política de gobernanza y un requisito habitual en auditorías de cumplimiento. El siguiente paso es enviar estos registros a un lugar centralizado, como el registro de seguridad de Windows, y definir alertas para accesos fuera del horario normal. ¿Qué tabla de su organización debería ser la primera en entrar en esta auditoría?