Comunicación y Auditoría en SQL Server MSc. Alexis Cabrera Mondeja

Administración de las comunicaciones Las comunicaciones del servidor SQL son controladas por las bibliotecas de red, éstas se utilizan para pasar paquetes de red entre los clientes y un servidor que ejecute SQL Server. Las bibliotecas de red, realizan las operaciones de red necesarias para la comunicación. Un servidor puede escuchar, o supervisar, múltiples bibliotecas de red al mismo tiempo. Durante la instalación del servidor SQL, se instalan las bibliotecas de red en el sistema operativo. Si una biblioteca de red no está configurada, el servidor no podrá consultar dicha biblioteca.

Podemos realizar la administración de las comunicaciones por medio de las herramientas proporcionadas por: El Sistema Operativo El Servidor SQL

Administración comunicaciones a través del Sistema Operativo Los sistemas operativos donde se instalan los servidores SQL poseen herramientas de control de las comunicaciones, evitando exposiciones peligrosas del exterior (internet) hacia el servidor SQL. La red donde está ubicado dicho servidor, también puede aplicarse dicho control. Dentro de los múltiples sistemas que podemos encontrarnos destacamos, dos de los más empleados habitualmente: Firewall: Evitan comunicaciones del exterior sobre el Sistema operativo o la red que protegen Proxie: Evitan las comunicaciones filtrando las peticiones sobre el Sistema operativo o la red que protegen

Por norma general la mayoría de servidores SQL emplean comunicaciones de tipo TCP-IP, con conexiones a puertos conocidos: Servidores SQL Puerto TCP comunicación Microsoft SQL Server 1433, 1434, 445 MySQL Server 3306 Oracle Server 523, 532, 66 La mayor parte del software de seguridad protege las comunicaciones de tipo TCP-IP, de manera que restringe las conexiones sobre puertos concretos, salvo aquellos que sean indicados.

Comunicaciones a través de FIREWALL de Sistema Operativo Veamos el ejemplo de un firewall ubicado en el Sistema operativo Windows, y cómo configurar comunicaciones TCP-IP. Como ejemplo empleamos el Firewall del sistema operativo Windows XP. Abrir panel de control, firewall de Windows:

SQL Server Configuration Manager La herramienta gestiona las comunicaciones de las instancias en el apartado “Configuración de red de SQL Server <versión>”.

Auditoría de la actividad en un servidor SQL La auditoría de actividad de un servidor SQL debe permitir conocer las actividades que se desarrollan en el servidor SQL, tales como: Ejecución de instrucciones SQL Alteración de tablas de las Bases de Datos Intentos de acceso no autorizados a la información Analizando la información obtenida en la auditoría, se conoce el grado de autenticidad y fiabilidad de la información contenida en los servidores SQL.

Las herramientas que se usan en auditorías de actividad del servidor SQL son proporcionadas por: EL propio Servidor SQL El Sistema Operativo donde esté ubicado el servidor SQL Incluida como parte de la base de datos, tablas que permitan controlar la alteración de otras tablas, también conocidas como Tablas LOG

Tablas LOG La estrategia consiste en crear dentro de la propia base de datos tablas que permitan auditar la alteración de las tablas de la base de datos. El control de dichas tablas LOG lo realiza el servidor por medio de desencadenadores o Triggers que deben ser programados para cada situación. Los desencadenadores, disparadores o Triggers son mecanismos internos bajo programación SQL que permiten controlar la alteración de información para una tabla de una base de datos concreta. Es necesario programar las acciones que van a llevar a cabo los triggers para cada situación.

A la hora de utilizar esta técnica debemos sopesar las siguientes desventajas: Los disparadores merman el rendimiento del servidor SQL, ya que están en continuo funcionamiento y son controlados por el propio servidor. No debemos abusar del uso de disparadores a la hora de auditar tablas. Si llegar a ser paranoicos, la tabla LOG también es una tabla que puede ser alterada, por lo que se deberá tener controlado el acceso. No podemos auditar la tabla que nos ayuda a auditar. Esta técnica debe ser empleada para auditar la alteración de los datos de algunas tablas.

Create Trigger Crea un desencadenador DML, DDL o logon. Un desencadenador es una clase especial de procedimiento almacenado que se ejecuta automáticamente cuando se produce un evento en el servidor de bases de datos. Los desencadenadores DML se ejecutan cuando un usuario intenta modificar datos mediante un evento de lenguaje de manipulación de datos (DML). Los eventos DML son instrucciones INSERT, UPDATE o DELETE de una tabla o vista. Nota Estos desencadenadores se activan cuando se desencadena cualquier evento válido, con independencia de que las filas de la tabla se vean o no afectadas.

Los desencadenadores DDL se ejecutan en respuesta a una variedad de eventos de lenguaje de definición de datos (DDL). Estos eventos corresponden principalmente a instrucciones CREATE, ALTER y DROP de Transact-SQL, y a determinados procedimientos almacenados del sistema que ejecutan operaciones de tipo DDL. Los desencadenadores logon se activan en respuesta al evento LOGON que se genera cuando se establece la sesión de un usuario. Los desencadenadores se pueden crear directamente a partir de instrucciones Transact-SQL o de métodos de ensamblados que se crean en Microsoft.NET Framework Common Language Runtime (CLR) y se cargan en una instancia de SQL Server. SQL Server permite crear varios desencadenadores para una instrucción específica.

Sintaxis create trigger NOMBREDISPARADOR on NOMBRETABLA for EVENTO- insert, update o delete as SENTENCIAS

Desencadenadores DML Los desencadenadores DML se utilizan frecuentemente para imponer las reglas de negocios y la integridad de los datos. SQL Server proporciona integridad referencial declarativa (DRI) mediante las instrucciones ALTER TABLE y CREATE TABLE. Sin embargo, DRI no proporciona integridad referencial entre bases de datos. La integridad referencial se refiere a las reglas acerca de la relación entre la clave principal y la clave externa de las tablas. Para exigir la integridad referencial, utilice las restricciones de tipo PRIMARY KEY y FOREIGN KEY en ALTER TABLE y CREATE TABLE. Si existen restricciones en la tabla de desencadenadores, se comprueban después de la ejecución del desencadenador INSTEAD OF y antes de la de AFTER. Si se infringen las restricciones, se revierten las acciones del desencadenador INSTEAD OF y el desencadenador AFTER no se ejecuta.

Desencadenadores DDL Los desencadenadores DDL, al igual que los estándar, ejecutan procedimientos almacenados como respuesta a un evento. Pero a diferencia de los desencadenadores estándar, no se ejecutan como respuesta a instrucciones UPDATE, INSERT o DELETE en una tabla o vista. En cambio, se ejecutan principalmente como respuesta a instrucciones de lenguaje de definición de datos (o DDL). Entre ellas se incluyen instrucciones CREATE, ALTER, DROP, GRANT, DENY, REVOKE y UPDATE STATISTICS. Algunos procedimientos almacenados del sistema que ejecutan operaciones de tipo DDL también pueden activar desencadenadores DDL.

Desencadenadores logon Los desencadenadores logon activan procedimientos almacenados en respuesta a un evento LOGON. Este evento se genera cuando se establece una sesión de usuario con una instancia de SQL Server. Los desencadenadores logon se activan después de que termine la fase de autenticación del inicio de sesión, pero antes de que se establezca la sesión de usuario realmente. Por tanto, todos los mensajes que se originan dentro del desencadenador y que normalmente llegarían hasta el usuario, como los mensajes de error y los mensajes de la instrucción PRINT, se desvían al registro de errores de SQL Server. Para obtener más información, vea Desencadenadores logon. Los desencadenadores logon no se activan si se produce un error en la autenticación. Los desencadenadores logon no admiten las transacciones distribuidas. Se devuelve el error 3969 cuando se activa un desencadenador logon que contiene una transacción distribuida.

Consideraciones generales sobre los desencadenadores Devolver resultados En una versión futura de SQL, se quitará la capacidad de devolver resultados desde los desencadenadores. Los desencadenadores que devuelven conjuntos de resultados pueden provocar comportamientos inesperados en aplicaciones que no están diseñadas para trabajar con ellos. Evite la devolución de conjuntos de resultados desde desencadenadores en los nuevos trabajos de desarrollo y piense en modificar las aplicaciones que la usan actualmente. Para evitar que los desencadenadores devuelvan conjuntos de resultados, establezca la opción No permitir resultados de desencadenadores en 1. Los desencadenadores LOGON impiden que se devuelvan conjuntos de resultados y este comportamiento no se puede configurar. Si un desencadenador LOGON genera un conjunto de resultados, no se puede ejecutar y se rechazará el intento de iniciar sesión activado por el desencadenador.

Desencadenadores múltiples SQL Server permite que se creen varios desencadenadores para cada evento DML, DDL o LOGON. Por ejemplo, si se ejecuta CREATE TRIGGER FOR UPDATE para una tabla que ya tiene un desencadenador UPDATE, se creará un desencadenador de actualización adicional. En las versiones anteriores de SQL Server, sólo se permitía un desencadenador por cada evento de modificación (INSERT, UPDATE, DELETE) en cada tabla. Desencadenadores recursivos SQL Server permite también la invocación recursiva de desencadenadores cuando el valor RECURSIVE_TRIGGERS está habilitado mediante ALTER DATABASE.

Permisos Para crear un desencadenador DML, es necesario contar con permiso ALTER sobre la tabla o vista en la que se crea el desencadenador. Para crear un desencadenador DDL con ámbito de servidor (ON ALL SERVER) o un desencadenador logon se requiere el permiso CONTROL SERVER en el servidor. Para crear un desencadenador DDL con ámbito en la base de datos (ON DATABASE) es necesario un permiso ALTER ANY DATABASE DDL TRIGGER en la base de datos actual.

Ejemplos Un “desencadenador”, ejecuta una serie de operaciones Transact SQL al producirse una acción en la base de datos, esta acción puede ser cambios a nivel datos (DML – Data Manipulation Language) y a nivel esquema (DDL – Data Definition Language), los cambios a nivel de datos se refieren a INSERT/DELETE/UPDATE que se puedan producir en los datos de la base de datos. Los Triggers se usan generalmente para hacer auditorias sobre las tablas, y para tener un mejor control de las mismas, ya que si los datos son borrados los mismos se pueden recuperar, también se pueden usar para guardar datos de algo en especifico como las compras de un proveedor.

Creamos un trigger sobre la tabla "ventas" para el evento se inserción Creamos un trigger sobre la tabla "ventas" para el evento se inserción. Cada vez que se realiza un "insert" sobre "ventas", el disparador se ejecuta. El disparador controla que la cantidad que se intenta vender sea menor o igual al stock del libro y actualiza el campo "stock" de "libros", restando al valor anterior la cantidad vendida: create trigger DIS_ventas_insertar on ventas for insert as declare @stock int select @stock= stock from libros join inserted on inserted.codigolibro=libros.codigo where libros.codigo=inserted.codigolibro if (@stock>=(select cantidad from inserted)) update libros set stock=stock-inserted.cantidad from libros join inserted on inserted.codigolibro=libros.codigo where codigo=inserted.codigolibro else begin raiserror ('Hay menos libros en stock de los solicitados para la venta', 16, 1) rollback transaction end

Entonces, creamos el disparador ("create trigger") dándole un nombre ("DI_ventas_insertar") sobre ("on") una tabla específica ("ventas") para ("for") el suceso de inserción ("insert"). Luego se "as" colocamos las sentencias, las acciones que el trigger realizará cuando se ingrese un registro en "ventas" (en este caso, controlar que haya stock y disminuir el stock de "libros"). Cuando se activa un disparador "insert", los registros se agregan a la tabla del disparador y a una tabla denominada "inserted". La tabla "inserted" es una tabla virtual que contiene una copia de los registros insertados; tiene una estructura similar a la tabla en que se define el disparador, es decir, la tabla en que se intenta la acción. La tabla "inserted" guarda los valores nuevos de los registros. Dentro del trigger se puede acceder a esta tabla virtual "inserted" que contiene todos los registros insertados, es lo que hicimos en el disparador creado anteriormente, lo que solicitamos es que se le reste al "stock" de "libros", la cantidad ingresada en el nuevo registro de "ventas", valor que recuperamos de la tabla "inserted". "rollback transaction" es la sentencia que deshace la transacción, es decir, borra todas las modificaciones que se produjeron en la última transacción restableciendo todo al estado anterior. "raiserror" muestra un mensaje de error personalizado. Para identificar fácilmente los disparadores de otros objetos se recomienda usar un prefijo y darles el nombre de la tabla para la cual se crean junto al tipo de acción.

Utilizar un desencadenador DML con un mensaje de aviso El siguiente desencadenador DML imprime un mensaje en el cliente cuando alguien intenta agregar o cambiar datos en la tabla Clientes. USE negocios2012; GO IF OBJECT_ID (‘VENTA.tr_recordar', 'TR') IS NOT NULL DROP TRIGGER VENTA.tr_recordar; -- This trigger raises a message whenever a row is inserted or modified in Sales.Customer. CREATE TRIGGER VENTA.tr_recordar ON VENTA.Clientes AFTER INSERT, UPDATE AS RAISERROR (‘Notificar modificacion de Tabla Cliente', 16, 10);

Utilizar un desencadenador DML con un mensaje de correo electrónico de aviso Este ejemplo envía un mensaje de correo electrónico a una persona especificada (alexis) cuando cambia la tabla Clientes. USE negocios2012; GO IF OBJECT_ID (‘VENTA.TR_RECORDAR2','TR') IS NOT NULL DROP TRIGGER VENTA.TR_RECORDAR2; -- este trigger envía un e-mail cuando una fila es insertada, actualizada o eliminada en la tabla VENTA.Clientes. CREATE TRIGGER TR_RECORDAR2 ON VENTA.Clientes AFTER INSERT, UPDATE, DELETE AS EXEC msdb.dbo.sp_send_dbmail @profile_name = ‘Alexis Cabrera', @recipients = ‘acabrera@universidadecotec.edu.ec', @body = ‘Se han efectuado cambios a la tabla clientes.', @subject = 'Recordatorio'; GO

Utilizar un desencadenador DML AFTER para exigir una regla de empresa entre las tablas PedidosCabe y Vendor Debido a que las restricciones CHECK sólo pueden hacer referencia a las columnas en que se han definido las restricciones de columna o de tabla, cualquier restricción de referencias cruzadas, en este caso, reglas de negocios, debe definirse como desencadenadores. En este ejemplo se crea un desencadenador DML. El desencadenador comprueba que la solvencia del proveedor es satisfactoria cuando se intenta insertar un nuevo pedido de compra en la tabla PurchaseOrderHeader. Para obtener la solvencia del proveedor, debe hacerse referencia a la tabla Vendor. Si la solvencia no es satisfactoria, se obtiene un mensaje y no se ejecuta la inserción.

Utilizar un desencadenador DDL con ámbito en la base de datos En el ejemplo siguiente se utiliza un desencadenador DDL para impedir que se quiten sinónimos en una base de datos. USE negocios2012; GO IF EXISTS (SELECT * FROM sys.triggers WHERE parent_class = 0 AND name = ‘seguridad') DROP TRIGGER seguridad ON DATABASE; CREATE TRIGGER seguridad ON DATABASE FOR DROP_TABLE AS RAISERROR (‘Debe deshabilitar el “seguridad" para eliminar tablas!',10, 1) ROLLBACK GO DROP TRIGGER seguridad ON DATABASE;

Utilizar un desencadenador DDL con ámbito en el servidor En el ejemplo siguiente se utiliza un desencadenador DDL para impedir que se cree una base de datos en un evento CREATE DATABASE en la instancia actual del servidor, y se utiliza la función EVENTDATA para recuperar el texto de la instrucción Transact-SQL correspondiente. IF EXISTS (SELECT * FROM sys.server_triggers WHERE name = 'ddl_trig_database') DROP TRIGGER ddl_trig_database ON ALL SERVER; GO CREATE TRIGGER ddl_trig_database ON ALL SERVER FOR CREATE_DATABASE AS SELECT EVENTDATA().value('(/EVENT_INSTANCE/TSQLCommand/CommandText)[1]','nvarchar(max)') GO DROP TRIGGER ddl_trig_database ON ALL SERVER; GO

Usar un desencadenador logon El ejemplo siguiente de desencadenador logon rechaza un intento de iniciar sesión en SQL Server como miembro del inicio de sesión login_test si ya hay tres sesiones de usuario ejecutándose con ese inicio de sesión. USE master; GO CREATE LOGIN login_test WITH PASSWORD = '3KHJ6dhx(0xVYsdf' MUST_CHANGE, CHECK_EXPIRATION = ON; GRANT VIEW SERVER STATE TO login_test; CREATE TRIGGER connection_limit_trigger ON ALL SERVER WITH EXECUTE AS 'login_test' FOR LOGON AS BEGIN IF ORIGINAL_LOGIN()= 'login_test' AND (SELECT COUNT(*) FROM sys.dm_exec_sessions WHERE is_user_process = 1 AND original_login_name = 'login_test') > 3 ROLLBACK; END;

Trigger genérico para auditar cambios en una tabla El siguiente trigger permite auditar los cambios (Inserciones, Actualizaciones y eliminaciones) a una tabla. Es un trigger genérico. Es decir, el mismo trigger funciona para cualquier tabla de la base de datos. Hay que tener en cuenta solo tres cosas: 1. Se debe crear una tabla de log para almacenar la información de auditoría. 2. En el script hay que cambiar manualmente el nombre de la tabla sobre la cual se esta creando el trigger. 3. Solo funciona con tablas que tienen llave primaria.

Este trigger fue diseñado por Nigel Rivett y funciona con las versiones 2005 en adelante. He hecho cambios mínimos de forma y he traducido e incluido comentarios para hacer mas legible y entendible el script. Lo primero que hay que hacer es crear la tabla de auditoría, sobre la cual el trigger escribirá el detalle de las transacciones realizadas: CREATE TABLE dbo.logTransacciones(   TipoTrn char(1),   Tabla varchar(128),   PK varchar(1000),   Campo varchar(128),   ValorOriginal varchar(1000),   ValorNuevo varchar(1000),   FechaTrn datetime,   Usuario varchar(128)) GO

En esta tabla se almacena el tipo de transacción(I-Insert, U-Update, D-Delete), el nombre de la tabla, la llave del registro, el o los campos que han sufrido algún cambio, el valor original y el valor nuevo para las actualizaciones y por ultimo la fecha en la que se hizo el cambio y el usuario que lo ejecutó. Cualquier cambio realizado en cualquier tabla de la base de datos que tenga el trigger, será almacenado aquí. Vamos ahora a crear la tabla Cliente, que nos servirá para probar el trigger. Sobre esta tabla ejecutaremos el script para crearle un trigger y haremos los cambios para ver como se van grabando los datos en la tabla de auditoría:

CREATE TABLE dbo.Cliente( IdClienteint IDENTITY(1,1)notnull, Nombres varchar(100), Apellidos varchar(100), TipoDocumento char(3), NumeroDocumento varchar(15)) GO ALTER TABLE dbo.Cliente ADD CONSTRAIN TPK_Cliente PRIMARYKEY (IdCliente)

A continuación el script del trigger genérico A continuación el script del trigger genérico. Tener mucha precaución de actualizar manualmente el nombre de la tabla al momento de almacenar el valor de la variable @TableName: Ver ejemplo adjunto.

Auditar con herramientas del Servidor SQL La mayor parte de los servidores SQL disponibles actualmente en el mercado disponen de herramientas de auditoría, distribuidas con el software instalador de SQL. La función principal de las herramientas de auditoría del servidor SQL se centra en la recogida de información procedente de la monitorización realizada por el propio servidor, dicha información, puede ser visualizado directamente desde la herramienta de gestión administrativa del servidor SQL. También se dispone de herramientas distribuidas por terceras compañías que recopilan dicha información, y la analizan ofreciendo un informe resultante.

Veamos algunos ejemplos: Monitor de Actividad de Microsoft SQL Server El monitor de actividad obtiene información sobre las conexiones de los usuarios al Motor de base de datos y los bloqueos que mantienen. El monitor de actividad forma parte del software cliente; Ir a inicio, Microsoft SQL Server, SQL Server Management Studio Express. Una vez conectado al servidor que queramos auditar, ir a Explorador de objetos, Administración, Monitor de Actividad.

El Monitor de actividad posee tres páginas: Información del proceso contiene información acerca de las conexiones. Bloqueos por proceso se ordenan los bloqueos por conexión. Bloqueos por objeto se ordenan los bloqueos por el nombre del objeto.

Auditar Servidores con herramientas de terceros Existen multitud de herramientas que permiten realizar auditorías sobre servidores SQL. Veamos a continuación alguna característica funcional de manera resumida:

GFI Events Manager: Es un ejemplo de herramienta de auditoría de sistemas de servidores, con un módulo de auditoría para servidores Microsoft SQL server.

Posee un módulo de configuración donde indicar los datos de la auditoría: Servidores: Se indican los servidores a auditar: Servidores Web, Correo, SQL, etc. Cada uno con sus características de conexión Reglas: Se indican las reglas de auditoría, dependiendo del tipo de servidor: Alteraciones de BD, log de acceso, etc. Centraliza la información de los sucesos del sistema operativo auditado, ya que recopila dicha información y muestra en un explorador; incluye un análisis y enlace a una página web con información adicional sobre el suceso seleccionado.

Una vez configurado muestra de forma resumida el estado del sistema auditado.

Auditar con herramientas del Sistema Operativo Todos los sistemas operativos disponen de herramientas de monitorización de la actividad del sistema. Vamos a ver a continuación algunas herramientas de monitorización propias del sistema operativo Windows. Administrador de tareas Proporciona información sobre los procesos y aplicaciones que el sistema operativo está ejecutando o procesando actualmente, la actividad de red, y los servicios de sistema, presionar la combinación de teclas: Alt+Ctrl+Supr, y seleccionar Administrador de tareas.

Visor de sucesos Si uno de los subsistemas que forman parte del sistema operativo no funciona adecuadamente Windows incorpora una herramienta llamada “Visor de sucesos”, que permite analizar qué es lo que ha ocurrido con el subsistema que está causando problemas. Para abrir el visor de sucesos, ir a Inicio, Panel de control, herramientas administrativas, visor de sucesos. La aplicación organiza los sucesos en páginas, de entre ellas destacamos:

Registro de Aplicación: contiene los sucesos grabados por los programas. Por ejemplo, un programa de base de datos puede grabar un error de archivo en el registro de aplicación. Registro de Seguridad: Graba los sucesos como intentos de inicio de sesión válidos y no válidos, y sucesos relacionados con el uso de recursos como crear, abrir o eliminar archivos. Por ejemplo, se graba un suceso en el registro de seguridad cada vez que un usuario intenta iniciar sesión en el equipo. Registro de Sistema: Contiene sucesos registrados por los componentes del sistema operativo. Por ejemplo, si un servidor SQL se detiene de forma inesperada se registra dicho suceso.