Auditoría de seguridad de bases de datos SQL Server

Las siguientes implementaciones de auditoría son recomendadas al nivel de base de datos como parte de cualquier sistema de auditoría de seguridad de bases de datos:

  1. Auditoría a nivel de esquema:
    • Actividad DDL
    • Cambios hechos a los procedimientos almacenados y desencadenadores
    • Cambios en los privilegios, usuarios y atributos de seguridad
  2. Auditoría a nivel de datos:
    • Cambios en datos sensibles (actividad DML)
    • Sentencias SELECT
  3. Cualquier cambio en los ajustes de auditoría

Estos son algunas soluciones de auditoría de seguridad de base de datos nativas que pueden ayudar a cumplir estos requerimientos.

Auditoría a nivel de esquema

Los comandos DDL, desde un punto de vista de seguridad, tienen un alto potencial para uso malicioso y pueden ser fácilmente usados para comprometer cualquier base de datos del sistema.

Hay algunas maneras de auditar la actividad DDL:

  • La característica SQL Server Audit o los archivos de rastreo de SQL Server
  • Desencadenadores DDL
  • Comparación de instantáneas de esquema

Para el propósito de este artículo, no consideraremos los desencadenadores DDL y la comparación de instantáneas de esquema, sin embargo revisaremos SQL Server Audit y los archivos de rastreo.

La característica SQL Server Audit es un modo de auditoría de SQL Server nativo, basado en los eventos extendidos de SQL Server. Introducido con SQL Server 2008, es el método menos intrusivo y por tanto generalmente recomendado para la auditoría de actividades DDL. Puede almacenar los eventos de auditoría cuando sea que ocurran en el registro de seguridad o el registro de eventos de la aplicación, pero el método recomendado, el cual será descrito en este artículo, es almacenar los eventos en el archivo de auditoría.

Nota: La auditoría de actividades a nivel de base de datos, y por tanto la auditoría de seguridad de la base de datos usado SQL Server Audit, está reservada para SQL Server Enterprise y SQL Server Developer solamente.

Para establecer una auditoría de seguridad de base de datos usando SQL Audit, el primer paso es crear un objeto SQL Audit. Esto puede ser hecho usando T-SQL o vía SQL Server Management Studio.

Para crear un objeto SQL Audit que pueda ser usado para la auditoría de seguridad de la base de datos, el siguiente script T-SQL de creación puede ser usado:

USE [master]
GO

CREATE SERVER AUDIT [Audit ADW2014 DDL ]
TO FILE 
(	FILEPATH = N'C:\SQLAudits\'
	,MAXSIZE = 20 MB
	,MAX_FILES = 20
	,RESERVE_DISK_SPACE = ON
)
WITH
(	QUEUE_DELAY = 1000
	,ON_FAILURE = CONTINUE
	,AUDIT_GUID = '928b1094-b02b-437d-a5c7-8266af853b57'
)
ALTER SERVER AUDIT [Audit ADW2014 DDL ] WITH (STATE = ON)
GO

Para usar SQL Server Management Studio, localice la carpeta Security->Audits en Object Explorer y elija New Audit en el menú contextual.

En el diálogo Create Audit que será abierto, seleccione Audit destination->File del menú y determine la File path (ruta de archivo) que será usada para almacenar el archivo donde la auditoría será registrada.

Todas las opciones en este diálogo son claras y no requieren explicaciones adicionales, pero para quienes están interesados, más detalles pueden encontrarse aquí.

Una vez que el objeto de SQL Server Audit es creado, el objeto Database Audit Specifications para el objeto de auditoría creado tiene que ser configurado.

Para crear e objeto de Databse Audit Specifications para los requerimientos de auditoría mencionados anteriormente, el siguiente T-SQL puede ser usado:

USE [AdventureWorks2014]

GO

CREATE DATABASE AUDIT SPECIFICATION [ADW2014 Auditing]
FOR SERVER AUDIT [Audit ADW2014 DDL]
ADD (SCHEMA_OBJECT_ACCESS_GROUP),
ADD (SCHEMA_OBJECT_CHANGE_GROUP),
ADD (SCHEMA_OBJECT_OWNERSHIP_CHANGE_GROUP),
ADD (SCHEMA_OBJECT_PERMISSION_CHANGE_GROUP),
ADD (USER_CHANGE_PASSWORD_GROUP),
ADD (DATABASE_OBJECT_ACCESS_GROUP),
ADD (DATABASE_OBJECT_OWNERSHIP_CHANGE_GROUP),
ADD (DATABASE_OBJECT_PERMISSION_CHANGE_GROUP),
ADD (DATABASE_OPERATION_GROUP),
ADD (DATABASE_OWNERSHIP_CHANGE_GROUP),
ADD (DATABASE_PERMISSION_CHANGE_GROUP),
ADD (DATABASE_PRINCIPAL_IMPERSONATION_GROUP),
ADD (DATABASE_ROLE_MEMBER_CHANGE_GROUP)

GO

Lo mismo puede hacerse vía Object Explorer en SQL Server Management Studio. Expanda el árbol de objetos de la base de datos, haga clic derecho en Security->Database Audit Specifications y seleccione New Database Audit Specification

Más detalles acerca del objeto Create Database Audit Specifications están disponibles aquí. Siga el enlace para detalles adicionaes acerca de Grupos de Acciones de Auditoría a Nivel de Base de Datos.

Nota: DATABASE_OBJECT_CHANGE_GROUP audita solo los permisos ALTER en SCHEMA como parte de la sentencia CREATE. Para realmente auditar operaciones CREATE, ALTER o DROP en el esquema, SCHEMA_OBJECT_CHANGE_GROUP debe ser añadido a la especificación de auditoría.

Una vez que todos los requerimientos para la auditoría estén configurados, SQL Audit comenzará a recolectar y registrar cada cambio de estructura de la base de datos definido en las especificaciones de auditoría.

Auditoría a nivel de datos


Crear objetos de SQL Audit y Especificaciones de Auditoría de Base de Datos para datos es similar a lo que se indicó anteriormente y la única diferencia consiste en configurar diferentes Especificaciones de Auditoría de Base de Datos.

Después de crear un nuevo objeto de SQL Audit para la auditoría a nivel DML, que será nombrado Audit ADW2014 DML para propósitos de este artículo, el objeto debería estar asociado con el nuevo objeto Especificación de Auditoría de Base de Datos. Para el propósito de auditoría DML, las Acciones de Auditoría a nivel de Base de Datos SELECT, INSERT, UPDATE, DELETE y EXECUTE si es necesario deben ser configuradas para la auditoría. Para más información visite Acciones de Auditoría a Nivel de base de Datos.

Dado que es posible especificar sólo un objeto/principal por evento de auditoría, crear todas las especificaciones de auditoría necesarias puede ser bastante agotador e incómodo. Esto es especialmente evidente cuando se están creando especificaciones para base de datos con cantidades incluso más grandes de tablas y vistas y cuando más principales tiene que ser incluidos en la auditoría. La imagen anterior es sólo un ejemplo donde sólo unas pocas especificaciones están definidas.

Nota: El tipo de auditoría tiene que ser configurado en la clase de objeto de Base de Datos y Esquema, lo que significa que todos los objetos que pertenecen al esquema especificado serán auditados, así como todos los objetos dentro de la base de datos seleccionada, si la base de datos es especificada como clase de objeto. Esto debería ser usado con cuidado, ya que torrentes de datos innecesarios pueden ser recolectados y almacenados en los archivos .audit.

Auditar la auditoría

La manera más fácil para un atacante para permanecer inadvertido es cambiar temporalmente la definición de la configuración de auditoría o cambiar los datos recolectados en sí mismos. Para permitir el rastreo de cambios a audtorías y objetos de especificaciones de auditorías, o mejor dicho “auditar la auditoría”, el Grupo de Acciones de SQL Server Audit AUDIT_CHANGE_GROUP es introducido a partir de SQL Server 2012. Aparte de rastrear los cambios a la auditoría y los objetos de especificaciones de auditorías, este grupo también rastrea auditorías fallidas y cambios hechos a sesiones de auditorías. Una vez que se configura al nivel de Especificaciones de Auditoría de Base de Datos, auditará todos los cambios hechos a las especificaciones de auditoría de base de datos dentro de esa base de datos.

El tipo de acción de auditoría AUDIT_CHANGE_GROUP registrará un evento de auditoría cuando cualquiera de los siguientes comandos sea ejecutado:

  • Crear una auditoría de servidor
  • Crear una especificación de auditoría de servidor
  • Crear una especificación de auditoría de base de datos
  • Alterar una especificación de auditoría de servidor
  • Alterar una especificación de auditoría de base de datos
  • Alterar una auditoría de servidor
  • Quitar una auditoría de servidor
  • Quitar una especificación de auditoría de servidor
  • Quitar una especificación de auditoría de base de datos

ApexSQL Audit

ApexSQL Audit es una  herramienta de cumplimiento de normas y auditoría SQL Server capaz de auditar más de 200 eventos SQL en los niveles de SQL Server y base de datos y almacenarlos en una base de datos repositorio central a prueba de modificaciones. La información recolectada está fácilmente disponible a solicitud a través de once reportes integrados con un reporte personalizado adicional que está diseñado alrededor de filtros avanzados, lo que permite cumplir con incluso los requerimientos más demandantes del usuario.

Con ApexSQL Audit, la auditoría de seguridad de la base de datos y la actividad de datos pueden ser configuradas en un solo paso mientras que todos los cambios en los ajustes de auditoría serán rastreados por defecto.

Para hacer eso en la Interfaz Gráfica de ApexSQL Audit usado el filtro simple:

  1. Seleccione la base de datos a ser auditada usando Add database.

  2. Establezca las condiciones del filtro de auditoría requeridas para cada base de datos añadida para auditoría.

    A continuación está la lista de todas las selecciones de filtro de auditoría al nivel de base de datos incluyendo las selecciones recomendadas que deberían ser habilitadas.

  3. Presione Apply en la barra emergente en la parte superior de la pestaña y eso es todo…esto es todo lo que se tiene que hacer para configurar la auditoría de seguridad de la base de datos.

Alternativamente, para configurar la auditoría vía el filtro avanzado:

  1. Seleccione el botón de radio Advanced en la sección Filter type.

  2. Presione Para añadir la condición.
  3. Seleccione el campo de datos Database name.

  4. Presione Y añada las bases de datos para auditar usando los botones Insert.

  5. Presione De nuevo, seleccione el campo de datos Databse operations y seleccione las operaciones requeridas, por ejemplo auditoría DDL, DML, etc.

  6. Presione Apply en la barra emergente en la parte superior de la pestaña.

La condición de auditoría debería verse así:

ApexSQL ahora comenzará a recolectar los eventos auditados y a almacenarlos en la base de datos repositorio central.

Los requerimientos para rastrear cambios en los ajustes de auditoría son implementados por defecto en ApexSQL Audit y el rastreo de los ajustes de la auditoría no puede ser deshabilitado por el usuario, haciendo a los filtros de auditoría a prueba de modificaciones. Cada cambio en los ajustes de auditoría, junto con información precisa acerca de los ajustes de filtros y quién realizó el cambio, pueden ser vistos en el reporte Audit settings history

Traductor: Daniel Calbimonte

octubre 16, 2016